Background
In mid-May 2019, Microsoft released a patch for “BlueKeep”, describing it as a “Remote Desktop Services Remote Code Execution Vulnerability”. In real terms, this means that an attacker could connect to a vulnerable system using RDP and, after sending a specially crafted request, had the ability to execute arbitrary code on the victim endpoint. After successful exploitation, an attacker would have the ability to install programs, manipulate data, or create new accounts with full use rights.
Triggering the bug
As the vulnerability occurs pre-authentication and requires no user interaction, it is ‘wormable’. This means any future malware exploiting this vulnerability could self-propagate from victim endpoint, similar to how WannaCry spread in 2017.
BlueKeep is triggered in ‘termdd.sys’, when a specially crafted data packet is sent into the MS_T120 channel structure. This terminates the channel due to a corrupted data error, triggering a use-after-free bug as the channel control structure is empty, leading to a system crash.
Figure 1: Flow diagram of how BlueKeep is triggered
Exploitation in the wild
When the vulnerability was made public in mid-May, it caused an initial rise in fake Proof-of-Concepts delivering malware, RATs and CobaltStrike. At the same time, there was an increase in mass internet scanning for port 3389, but due to the delay in release of a weaponized Proof-of-Concept (which would only cause BSOD) and the well-timed notification and patching shared by Microsoft, most systems were quickly patched.
While there seems to be a rise of publicly open RDP systems since mid-May, there still have been no reports of widespread infection or breaches with BlueKeep.
Figure 2: Shodan shows 5M+ RDP systems online
Figure 3: Censys shows 3M+ RDP systems online
While there have been no reported breaches, there have been reports of more RDP brute force attacks taking place than usual, some of which we have detected in our client perimeter networks with LMNTRIX Detect – our network monitoring security solution.
Detection Status
Despite Microsoft’s proactive patch release and the delay of a workable weaponized Proof-of-Concept exploiting BlueKeep, we knew it was of high importance to create a detection mechanism specific to this vulnerability. If only a single endpoint remained unpatched, it would be prone to BlueKeep. To ensure our clients’ networks remained protected, we updated our endpoint protection specifically to detect this vulnerability.
While LMNTRIX Respond sensors were able to detect the spawning of a remote shell (as derived from MITRE Attack Techniques T1093 – Process Hollowing, and T1094 – Customer C&C Protocol), as BlueKeep caused system crashes, the resulting alert was an “endpoint offline” notification which created too much noise to investigate properly.
Our analysts kept looking for the next best option.
With the available research at hand, we knew what to look for in the packets so turned to deep packet network monitoring. Still, we felt this was not enough for a real-world implementation. The RDP server should accept connections from systems running any version of Remote Desktop over SSL/TLS, with NLA(Network Level Authentication) not enabled, for the exploits to work.
Following more advanced engineering and research, we upgraded our LMNTRIX Hunt service to perform decryption and deep packet inspection on live network traffic to successfully detect BlueKeep exploit attempts. The ability to download PCAP also allows analysts to replay the events and perform further investigations.
Final Thoughts
Even in cases like BlueKeep where patches have been rapidly released, it is still important for security vendors to update their solutions to mitigate the threat of exploitation. Not only does one unpatched device put the rest of the client network at risk, but each new vulnerability belies a potential trend in future malware development.
Regardless, the first step should always be to patch systems. Microsoft has also released the following recommendations to further mitigate the threat from BlueKeep.
• Block TCP port 3389 at firewalls, especially any perimeter firewalls exposed to the internet.
• Enable Network Level Authentication. With NLA enabled, attackers would first have to authenticate to Remote Desktop Services in order to successfully exploit the vulnerability.
• Disable Remote Desktop Services if they are not required.
On 2019-07-24
