In light of several reports showing that the number of unpatched RDP servers on the internet is still very high, despite warnings by experts and government agencies, we recorded a video that shows a proof-of-concept BlueKeep attack using an exploit developed by Christophe Alladoum of SophosLabs’ Offensive Research team. We hope this video convinces individuals and organizations who still haven’t patched that the BlueKeep vulnerability is a serious threat. BlueKeep affects computers running Windows XP, Windows 7, Windows Server 2003, and Windows Server 2008.
The exploit works in a completely fileless fashion, providing full control of a remote system without having to deploy any malware. It also doesn’t require an active session on the target.
The development of this exploit came about as the result of an arduous process of reverse-engineering the patch released by Microsoft in May to examine what it was trying to fix. Microsoft themselves did not release any information about BlueKeep to companies that are part of its MAPP program – other than a request that everyone install the update with minimal delay.
Sophos will not be releasing the PoC to the public out of an abundance of caution. If someone was able to weaponize the PoC, any of the machines currently vulnerable to BlueKeep would instantly become targets of opportunity for an attacker who could leverage the method to deliver malware or, well, do anything that the administrative owner of a vulnerable Windows computer could do with that computer.
Microsoft considers the BlueKeep vulnerability so dire, they have taken the unusual step of releasing patches intended to protect versions of their operating system that no longer receive regular updates and have reached “end of life,” such as Windows XP.
SophosLabs Offensive Research does research work on software vulnerabilities that affect the platforms on which our products run. The team is focused on producing examples of exploits that other teams can use to build in protection against those exploit methods.
Building the PoC
Several other security analysts have already published their own proof-of-concept code, but that public code (so far as anyone publicly knows) is only capable of crashing Windows, triggering a “Blue screen of death” (BSOD) error. This type of attack renders the computer unusable until it reboots; Technically it is a form of denial of service attack.
The method we’ve built is not just a DoS. After running the exploit code, a hypothetical attacker can launch a command shell that appears prior to login, on the Windows login screen. Our researcher who worked on developing the exploit PoC chose to use a technique that was somewhat different than the publicly-released PoC code.
It’s also a different method than the one used in functional (ie., exploits that do not cause crashes) PoCs that have been developed by at least one other security company. That company also refrained from sharing their explot code, but published video demonstrating it working.
The technique demonstrated in the SophosLabs video involves replacing an executable called utilman.exe (part of the Windows operating system) with another trusted Windows component, the command shell, cmd.exe. The utilman binary is responsible, in part, for enabling or disabling Windows’ accessibility features, which users can access on the login screen by clicking an icon, even before anyone logs in. The button is labeled Ease Of Access in Windows. In this case, it’s surprisingly accurate.
The MITRE ATT&CK framework, which documents exploitation techniques, classifies this under category T1015. Users can invoke the accessibility functions from either an icon on the login screen, or with the Windows+U key combination. Utilman.exe, launched by winlogon.exe, has SYSTEM level privileges; By replacing one signed Microsoft binary with another, the replacement also gets those privileges.
What’s in the video
The first 45 seconds of video shows the researcher running a Windows 7 virtual machine, demonstrating the use of the accessibility features on the Windows login screen (which brings up a small menu of options to assist the disabled), and then demonstrates a failed login with an incorrect password.
At about 45 seconds in, the researcher launches the attack using the PoC script, called exploit.py. As the video is showing the PoC running in real time, nothing happens for roughly the next 20 seconds until 1:06, at which time the script attempts to start an RDP session to the targeted VM. The actual exploit takes about a minute to complete; We’ve edited the wait time out of the video.
Within a few seconds, the connection has completed. The output from the researcher’s console indicates that the PoC has opened a connection. During this time, the exploit is being used to perform the exe replacement. By 1:10, the console informs the researcher that “if there was no crash, a SYSTEM shell is awaiting via the accessibility menu.”
By 1:20 in the video, the researcher has made a second RDP connection to the target machine, again attempted to log in with the incorrect password, and then invokes the elevated command shell (running with NT AUTHORITY\SYSTEM credentials) by clicking the Ease Of Access menu icon.
Not just dangerous, but wormable-dangerous
All the proof-of-concept does, in the video, is allow someone in an interactive session over RDP to launch a command shell with SYSTEM privileges. That’s pretty bad, but the tool leveraged by this team to launch the exploit, the rdpy framework, allows anyone to instrument any RDP interaction, such as clicking buttons or sending synthetic keypresses.
With very little effort, a malicious threat actor could fully automate the whole attack chain, including synthetically “typing” commands into the shell, or simply passing commands to the shell.
That would be extremely bad, as it would allow rapid-fire attacks targeting any system hosting RDP to the outside world. It wouldn’t necessarily succeed in the case of the patched devices, but an attack like this falls into the category of “spray and pray” – the attackers are not choosy about who they target, and some percentage of machines will be vulnerable.
It’s worth noting that we’re not the only company in the security industry that’s discovered at least one way to exploit this vulnerability, and as previously mentioned, other independent vulnerability researchers have been working on developing exploits of their own.
So please, if you haven’t already updated your Windows computers, do so right now. We feel it’s only a matter of time before someone weaponizes this, and the best defense you might have is that patch.
In addition, please close any firewalls that expose RDP (no matter what port it is running on, though its default is 3389/tcp) to the open internet.
Sophos detection
Sophos published a technical support bulletin to our Community forums that describes the protections in place for customers and partners. Customers of recently-acquired Rook Security will have the following intrusion detection rule available, as well.
2027369 || ET EXPLOIT [NCC GROUP] Possible Inbound RDP Exploitation Attempt (CVE-2019-0708) || url,github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt || url,portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708 || cve,2019,0708
SophosLabs thanks Mark Loman for sacrificing his virtual machine to this research