Last updated at Thu, 25 Jul 2024 14:52:16 GMT

What’s up?

On June 4, 2019, the CERT Coordination Center (CERT/CC) released an advisory regarding discovered behavior in the Microsoft Windows Remote Desktop Protocol (RDP), which can allow an attacker to bypass the lock screen on some remote sessions. Specifically, it stated:

"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. If a network anomaly triggers a temporary RDP disconnect, upon automatic reconnection the RDP session will be restored to an unlocked state, regardless of how the remote system was left.”

CERT/CC further describes one scenario in which this technique could be used:

  1. User connects to remote Windows 10 1803 or Server 2019 or newer system using RDP.
  2. User locks remote desktop session.
  3. User leaves the physical vicinity of the system being used as an RDP client.

Microsoft was notified of this finding and has stated that the “behavior does not meet the Microsoft Security Servicing Criteria for Windows,” meaning there will be no patch available at least for the time being.

Another RDP vulnerability? Seriously?!

Kinda. It is understandable that many organizations still scrambling to ensure their systems are not vulnerable to the recent “BlueKeep” RDP wormable vulnerabilty would not be thrilled that there is yet another RDP issue they need to deal with. According to Microsoft, the issue described in this CVE is how Network Level Authentication is supposed to work in modern versions of Windows running and accessing RDP sessions. In other words, this is a weakness but not something that requires mitigation via patching.

What can you do?

For starters, you can develop a communication plan that ensures all users of RDP know to lock their own workstations when they are not in front of them and especially if they have an active RDP session established. Said communication plan should also include guidance to disconnect from RDP sessions instead of just locking the remote screen if a user needs to step away from a session for any significant length of time.

Rapid7 Managed Detection and Response team members and internal security researchers are investigating whether it might be possible to detect abnormal activity around this potential attack vector by monitoring the following Windows Events:

Event ID: 24
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session has been disconnected:”

Event ID: 25
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session reconnection succeeded:”

Event ID: 40
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Session <X> has been disconnected, reason code <Z>”

in: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

or:

Event ID: 4778
Provider Name: Microsoft-Windows-Security-Auditing
Description: “A session was reconnected to a Window Station.”

Event ID: 4779
Provider Name: Microsoft-Windows-Security-Auditing
Description: “A session was disconnected from a Window Station.”

in: %SystemRoot%\System32\Winevt\Logs\Security.evtx.

It may also be possible to detect instances of mass RDP screen unlocks by performing regular internal RDP scans (including on-connect screenshot) to ensure all systems are, indeed, locked.

Is the world ending?

Yes, in about a billion years, but definitely not because of this new RDP CVE. The CVSS base, temporal, and environmental scores for CVE-2019-9510 are all within the 4–5 range (out of 10). A big reason for that is the limited scope and “perfect storm” required to take advantage of the RDP NLA weakness. While this affects all modern versions of Microsoft Windows (Windows 10 1803, Server 2019 and later) , attackers need to be in a position to either watch for these events to take place on their own (as networks are not perfect) or initiate potentially noisy network actions to facilitate the disconnect and take advantage of a (hopefully) brief window of opportunity.

It is important to note that this is a potential vector for finely tuned targeted attacks. It’s also likely to be used by penetration testers or red teams, especially if the weakness stays in NLA-protected RDP in future Windows versions.

For now, Rapid7 Labs suggests that you focus on ensuring you’re safe from “BlueKeep” before addressing this new attack vector and focus on communication and detection vs. falling prey to any media- or industry-driven hype. If you have the inclination, you could set up an Active Directory GPO to automatically kill disconnected RDP sessions, as described here, but again, this is not a "drop what you're doing and solve this now" kind of problem—this is more along the lines of Doing Something to get your IT management off your back while you get back to work on continuous scanning and patch management and other important tasks.