A security researcher today revealed details of a newly unpatched vulnerability in Microsoft Windows Remote Desktop Protocol (RDP).
Tracked as CVE-2019-9510, the reported vulnerability could allow client-side attackers to bypass the lock screen on remote desktop (RD) sessions.
Discovered by Joe Tammariello of Carnegie Mellon University Software Engineering Institute (SEI), the flaw exists when Microsoft Windows Remote Desktop feature requires clients to authenticate with Network Level Authentication (NLA), a feature that Microsoft recently recommended as a workaround against the critical BlueKeep RDP vulnerability.
According to Will Dormann, a vulnerability analyst at the CERT/CC, if a network anomaly triggers a temporary RDP disconnect while a client was already connected to the server but the login screen is locked, then «upon reconnection the RDP session will be restored to an unlocked state, regardless of how the remote system was left.»
«Starting with Windows 10 1803 and Windows Server 2019, Windows RDP handling of NLA-based RDP sessions has changed in a way that can cause unexpected behavior with respect to session locking,» Dormann explains in an advisory published today.
«Two-factor authentication systems that integrate with the Windows login screen, such as Duo Security MFA, are also bypassed using this mechanism. Any login banners enforced by an organization will also be bypassed.»
The CERT describes the attack scenario as the following:
A targeted user connects to a Windows 10 or Server 2019 system via RDS.
The user locks the remote session and leaves the client device unattended.
At this point, an attacker with access to the client device can interrupt its network connectivity and gain access to the remote system without needing any credentials.
This means that exploiting this vulnerability is very trivial, as an attacker just needs to interrupt the network connectivity of a targeted system.
However, since the attacker requires physical access to such a targeted system (i.e., an active session with locked screen), the scenario itself limits the attack surface to a greater extent.
Tammariello notified Microsoft of the vulnerability on April 19, but the company responded by saying the «behavior does not meet the Microsoft Security Servicing Criteria for Windows,» which means the tech giant has no plans to patch the issue anytime soon.
However, users can protect themselves against potential exploitation of this vulnerability by locking the local system instead of the remote system, and by disconnecting the remote desktop sessions instead of just locking them.
A good detection technique to spot Remote Desktop Connections that are exposed to the internet is to scan RDP event logs for any events where the source IP is a non-RFC 1918 address. This provides you a good way to check for locations that may be port forwarding RDP, like work from home users.
During a recent investigation involving Remote Desktop Connections, I discovered some behavior that limited this search functionality and was contrary to what I’d observed in previous cases and seen documented in other blogs. I’ve done some testing over the last few days and thought I’d pass along what I’d found.
I refer to the following two sources whenever I need a refresher on RDP logging. They both do a great job of explaining what gets logged at the various stages of an RDP connection: Login, Logoff, Disconnect, Reconnect, etc.
During previous investigations, I’d observed Event ID 1149 in the TerminalServices-RemoteConnectionManager/Operational log occurring as soon as an RDP connection was established. This event was logged prior to credentials being entered during the login process and my interpretation was that this indicated that the RDP client has connected to the RDP host successfully. It did not indicate that a login had successfully occurred. This made Event ID 1149 very valuable as it gave you the means to spot failed logins or brute force login attempts even if auditing of failed logins was not enabled. As mentioned above, the presence of a non-RFC 1918 address in one of these logs is a good indicator that that device has been in a location with RDP exposed to the internet.
Event ID 1149 was followed by a series of other events which varied depending on whether a previous session was being reconnected and whether the authentication was successful.
During successful authentication, you observe Event ID 4624 in the Windows Security log. Note there is a 4624 event where the “Logon Type” is 3. This occurs because this connection is using Network Level Authentication. This will be followed by another 4624 Event with logon type 10 (or 7 for reconnects). (*Thanks to @securitycatnip for catching an error in the original post.)
Event ID 21 and 22 (new connections) are logged in the TerminalServices-LocalSessionManager/Operational log.
For failed logins, Event ID 1149 would be followed by Event ID 4625 in the Windows Security Log.
An important point is that Event ID 4625 ( for login failures) is not logged by default in desktop operating systems like Windows 7, 8, and 10.
During a recent investigation, I noticed that Event ID 1149 was not being logged when the login was unsuccessful. This was observed when connecting to a Windows 10 device. If the login succeeded, the 1149 event was logged as seen previously. In both cases, Event ID 261 is logged in the TS RemoteConnectionManager/Operational log but unfortunately, this doesn’t give us any information on who was attempting to connect.
After performing some additional testing and reviewing notes from previous cases, I’ve found the following. Please note, not all Operating Systems or OS versions are accounted for here as I tested what I had available.
Event ID 1149 was not logged prior to successful authentication and only occurs if authentication is successful on the following Operating Systems:
Windows Server 2012
Windows Server 2016
Windows 10 (version 1803)
Event ID 1149 was logged prior to successful authentication on the following Operating Systems:
Windows Server 2008
Windows SBS Server 2011
Additional Log Sources
I performed a timeline of the Event Logs after a series of failed and successful RDP connections to see if anything else was logged that might be helpful in identifying failed RDP login attempts. I discovered that the RemoteDesktopServices-RdpCoreTS/Operational log does log Event ID 131 when the RDP connection is first established. This occurs prior to authentication like Event ID 1149 did previously and while there is no workstation name or user account associated with this log entry, it does provide the connecting IP. Unfortunately, this log channel does not exist in Windows 7.
I touched on Network Level Authentication above when discussing the “Logon Type” field recorded in the Security log. NLA requires the client to authenticate before connecting to the host. An easy way to tell if NLA is disabled is that when connecting to a host, you see the login screen of that device before entering credentials. This allows an attacker to see who is currently logged in, other user accounts on the PC and the domain name.
NLA really should be enabled on most devices but if it is not, you can find an additional event in the TerminalServices-RemoteConnectionManager/Admin log. Event ID 1158 will also display the source IP. While this log is available in Windows 7, I was not able to generate Event ID 1158 when connecting to a Windows 7 PC without NLA.
One final tip. If you’re doing any RDP testing and want to force your client to connect without NLA, you can do so by editing the RDP connection file. To do so, save the .RDP file and open it in notepad or another text editior. Paste the following line anywhere in the file: enablecredsspsupport:i:0
If you’ve got any feedback, feel free to share. I’m still on the lookout for a good way to identify brute force RDP attempts on default Windows 7 configurations so if you’ve got any thoughts on that, let me know.
TL;DR: If the remote server allows Restricted Admin login, it is possible to login via RDP by passing the hash using the native Windows RDP client mstsc.exe. (You’ll need mimikatz or something else to inject the hash into the process)
On engagements it is usually only a matter of time to get your hands on NTLM hashes. These can usually be directly used to authenticate against other services / machines and enable lateral movement. Powershell / PSExec, SMB and WMI are usual targets to pass the hash to, but it is also possible to use it to establish a RDP session on a remote host. Searching the Internet on how to do this unfortunately always leads to using xfreerdp, but I wasn’t able to find anything on the Internet regarding how to do this directly using the provided RDP client mstsc.exe, so I had to find out on my own.
How does it work?
Interestingly, it was quite easy to find out, so here is how to do it with mimikatz (you’ll need local admin):
This will open a new RDP window. If it still shows the user you are currently logged on with, just ignore it — everything will just work 😉
Enter the domain name / IP of the target server and if the target server allows Restricted Admin Mode, you will be logged in, otherwise the server will tell you that you are not allowed to log in.
Why does it work?
RDP Restricted Admin Mode builds upon Kerberos. Taking a look at the network traffic, one can see that the RDP client requests a ticket on behalf of the impersonated user which is no problem since the hash is all we need to authenticate against Kerberos.
Restricted Admin Mode is disabled, what can I do?
A registry key controls if a server accepts Restricted Admin sessions. If you have the NTLM hash of a user that has privileges to set registry keys, you can use for example Powershell to enable it and log in via RDP afterwards: