As the Metasploit Bluekeep exploit module released to the public in few days ago, that’s lets me experiment the exploit and analyze the network traffic and logs generated.
This article will demonstrate quick PoC video and will explain the initial RDP connection sequence of the exploit, and provide detection methods in the wire and host level.
Vulnerability Overview
CVE-2019-0708 or Bluekeep is a vulnerability in Windows remote desktop service (RDP) that allows an attacker to execute unauthenticated arbitrary code in the target machine.
PoC
in the above video showing the exploit using Metasploit framework against Windows 7 SP1 ruining in VirtualBox. exploit module Groomsize setting of 150 used and worked for me.
You can find the exploit module files in GitHub pull request below:
https://github.com/rapid7/metasploit-framework/pull/12283
Network Analysis and Detection
in this section i will not dive deeply in the RDP protocol as is it complex protocol and not well documented, but i will focus in the main characterize and indicators of the exploit.
Because RDP protocol have different types of security/encryption levels, the network analysis and detection will be different in each level. Below the setting for RDP encryption can be found in the group policy editor (gpedit.msc).
in the low level encryption setting i observed the exploit RDP initial communication happens in clear text but afterwards the the data section is encrypted.
in the high level encryption setting all RDP communication encrypted with TLS after the TLS handshake.
Standard RDP Security
When the low level encryption configured, the first stages of the RDP communication happens in clear text until the Security Exchange PDU which marked in #3. [1]
Monitoring and analyzing marked stages #1 and #2 is enough to detect the exploit.
The exploit module send negotiation request with random cookie 7 characters string and RequestdProtocols = 0x00000000 which is Standard RDP Security. [2]
The target RDP client accept the negotiation if the low level encryption configured.
Many requested virtual channels we can see here sent to the target, MS_T120 and others starts with MS_XXX.
We can crate a Snort IDS rule to trigger the string “MS_XXX” in the RDP packet to detect the exploit attempt as below:
alert tcp any any -> any 3389 (msg:"CVE-2019-0708 Bluekeep exploit attempt"; flow:established,to_server; content:"MS_XXX"; fast_pattern; sid:3000002; rev:1;)a Snort rule for the string “MS_T120” alone will trigger a scan attempt, as i observed the Bluekeep scanners requests the channel MS_T120 with normal channels and waiting for the target response.
alert tcp any any -> any 3389 (msg:"CVE-2019-0708 Bluekeep MS_T120 channel request"; flow:established,to_server; content:"MS_T120"; fast_pattern; sid:3000002; rev:1;)TLS
When the high level encryption configured, all the communication after connection confirm PDU is encrypted using TLS. Only the marked packet with red is visible.
The exploit module uses the same behavior for the the connection initiation, sending random cookie and getting same response but with RequestdProtocols = 0x00000001 (TLS). [2]
TLS handshake done after the connection initiation as shown in the picture above, and many encrypted application data transferred happens afterwards.
For a detection we can monitor the cookie, or we can use TLS client hello fingerprinting (JA3) and use netflow also to confirm.
Cookie
As the exploit module uses random cookie, we can use randomnesses score algorithms/tools to detect the random values. I’m using freq.py and it gives me good result detecting randomness.
The random values have low score while the legitimate users like Admin have high score.
We can use also another detection technique like long tail analysis least common cookie values to to filter out the legitimate cookie and discover the random cookie.
JA3
JA3 fingerprint is a great way to detect Metasploit Bluekeep exploit module TLS client hello as the exploit module uses configured TLS settings.
Above picture shows the obtained JA3 hash from the TLS client hello from Bro SSL logs.
JA3 query result in ja3er.com website shows that hash belong to Metasploit Bluekeep exploit model. Below JA3 hashes obtained from my lab:
“004556e859f3c26c5d19746b3a957c74” – Metasploit Bluekeep exploit model
“53652b2730564404986852cde177b6d9” – Bluekeep rdpscan
Netflow
Netflow is a good way to confirm the exploit if you catched random cookie or suspicious JA3 hash, i observed the exploit model uses three TCP session as below:
1- TLS session with a small number of packet (i believe this meant to check for NLA is enabled or not).
2- New TLS session with more number of packets to check if the system vulnerable to bluekeep exploit.
3- New TLS session with huge number of packets to exploit the system and send the payload.
Above picture shows Bro connection logs which is similar to netflow logs. huge number of packets and bytes sent in the third session and long duration taken.
Host Event Logs Analysis and Detection
in my experiment against Windows 7 SP1 i found only one event log that could be used as indicator of the exploit.
RDP authentication event log (event ID 1149) will generated using random user and domain as shown in the above picture. This event will show in scan and exploit attempt.
For a detection, whitelisting the domain value against your domain name will be easy and effective, or using the same approach explained before above for detection randomness or least common using long tail analysis will works also.
Windows 10 has more RDP operations logging than Windows 7, you can detect the exploit or scan attempt through the above showing event log (event ID 148) which indicate the channel MS_T120 has been requested.
Post Exploit Event Logs
Post exploit stage can be different from an attempt to another based in the payload being used with exploit. But the default payload that comes with the exploit module creates new CMD child process under spoolsv.exe.
For host-based IDS/IPS users, the kernel shellcode loads a child process to the Windows process
spoolsv.exeby default
Above quote from Rapid7 website.
Sysmon will be good choice here to detect that by monitoring (Event ID 1: Process creation).
Prevention
Microsoft released a patch to solve the issue:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708
Affected Windows systems:
- Windows 7 SP 1
- Windows Server 2008 Service Pack 2
- Windows Server 2008 Service Pack 1
- Windows Vista SP2
- Windows XP SP2
- Windows XP SP3
Notes
a lot of indicators explained in this article are subject to be changed based in exploit model being used like cookie, user and domain.
The attacker can modify the exploit model code and use custom parameters, but they are always lazy to do that.
Also the exploit model still new and a change or update in the code probably will happens and indicators might changed.
[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/261d841e-6ce3-427d-8735-7a6e6c2cfb2c
[2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/902b090b-9cb3-4efc-92bf-ee13373371e3
Well done Mansour ,keep going