Mitigation Tools for Microsoft's "Bluekeep" Vulnerability
May 23rd, 2019
Microsoft, in its latest patching cycle, fixed a vulnerability in the remote desktop (RDP) protocol. This vulnerability, identified as CVE-2019-0708 and dubbed “Bluekeep,” allows an attacker to perform remote code execution on vulnerable systems. This vulnerability is highly critical and is considered as severe as the SMBv1 vulnerability in the WannaCry attacks back in 2017. The severity of Bluekeep could present significant problems for cybersecurity teams. The following is a breakdown of the information we currently have at our disposal, as well as some useful tools to help mitigate the vulnerability.
Technical Details of the Bluekeep Vulnerability
Security researchers and hackers alike are currently racing to build a working POC to exploit this vulnerability. Since Microsoft did not release any technical details regarding the nature of this CVE, researchers are attempting to reverse engineer the patch that Microsoft issued to understand the vulnerable component of the RDP protocol.
Two companies have released a working POC of this vulnerability, Kaspersky and McAfee. Kaspersky managed to show a working POC on an XP computer and McAfee succeeded in pinpointing the vulnerable part in the RDP protocol.
The problem lies in the binding of virtual channels in the RDP protocol session initialization. The vulnerability occurs prior to the security handshake in the protocol, which enabled this vulnerability to be wormable. At a high-level, it allows an attacker to try to establish a virtual channel named “MS_T120” with a different channel than was intended. MS_T120 is probably an internal channel name that was used for an obscure purpose that was not documented as part of the RDP protocol. The vulnerability lies in the termdd.sys file of the RDP driver.
A regular RDP connection shouldn’t contain an attempt to connect to the MS_T120 channel. This means that with a high probability, any RDP connection that tries to connect to MS_T120 is a connection that should be considered malicious or at least suspicious.
The identification method above has been tested against the Kaspersky POC and was proven correct. The POC connection contained a request to open the MS_T120 channel whereas a regular RDP connection did not.
A number of mitigation tools have been released over the past few days to help teams identify vulnerable machines.
1. Snort Rule
McAfee has issued a Snort rule to identify the RDP traffic that contains the vulnerable string that is in the base of this CVE:
You can use this rule to scan for any RDP traffic that tries to connect to “MS_T120”. This rule can theoretically be used to track even historical connections that used the “MS_T120” channel, depending on the organization and the level of its network traffic logs. With that said, please note that if the RDP traffic is TLS encrypted it you wouldn’t be able to use this indicator.
McAfee has released a more detailed explanation of the CVE.
2. Vulnerability Scanner
Security researchers have released a scanner that can be run against open RDP connections. The scanner tries to open the MS_T120 channel:
This scanner can be used to discover vulnerable RDP connections. If MST_120 is open, the computer is vulnerable. Please note that this scanner was not tested on a wide scale, so there is a chance that it could crash certain operating systems and RDP versions. Please consider this before using it against business-critical systems.
There is also a Metasploit module based on the above scanner.
3. Suricata Rule
Ncc Group Infosec have created a Suricata rule to detect the MS_T120 channel connection:
4. Sigma Rule #1
Markus Neis from Swisscom has created a Sigma rule to detect suspicious outbound RDP connections. Rule #1 was written before the MS_T120 channel was known and was built to detect the general RDP attack vector as per the MITRE ATT&CK technique T1201.
5. Sigma Rule #2
Andrii Bezverkhyi, the CEO of SOC Prime (a threat detection marketplace), has written an article which covers the currently known detection methods (updated May 22, 2019). He also offers another Sigma Rule and some Elastic and ArcSight recipes to detect statistical anomalies that can indicate a misuse of RDP with relation to the vulnerability.
Both Sigma rules can be implemented in SIEM systems to try to identify any suspicious RDP connections that relate to the vulnerability.
6. IP Blacklist
Security firms started to track IPs that scan for this vulnerability. Although it’s a crude tool with a chance for false positives, it can still be beneficial to block these IPs in your firewall.
Cisco reported on the following IPs:
- 184.108.40.206 - Known scanner of other vulnerabilities, high volume
- 220.127.116.11 - High volume
- 18.104.22.168 - Low volume
Symantec reported on the top three scanning IPs:
- 22.214.171.124 - distant 3rd
Hackers are already attempting to take advantage of this vulnerability. Applying the latest Monthly Rollup or Security Only patch, or disabling RDP altogether, are the safest courses of action. The above tools and information will help track any vulnerable machines or even historical events that might exploit this vulnerability (although no evidence for that currently exists). IntSights will continue to monitor this issue and will update accordingly.
Many of the details included in this post were shared within the Cyber Threat Alliance (CTA). IntSights would like to extend its gratitude to all members of the CTA for their continued collaborative efforts.
Learn how to proactively protect your organization from cyberattacks in our Digital Risk for Dummies ebook.
Stay up to Date!
Subscribe to the blog to stay up to date with all the latest industry news and updates from IntSights.