The objective here is to examine the behavior of the Metasploit BlueKeep Module, which targets the CVE-2019-0708 vulnerability. Our aim is to pinpoint signatures that can be used to create a Snort rule for detecting bluekeep attack.
Both the NCC Group and Talos Intelligence have released Snort rules for identifying the CVE-2019-0708 exploit. However, their detection methods rely on content transmitted under encryption, which is only accessible using specific decryption software or appliances.
In this analysis, the focus will be on the unencrypted portion of the communication.
1. RDP Communication
To begin, it is crucial to understand the fundamentals of RDP communication, as it is the protocol used in this exploit.
You can access the relevant documentation here.
1.1 Connection Initiation
The client begins the connection process by sending a Class 0 X.224 Connection Request PDU to the server (refer to section 2.2.1.1). In response, the server sends back a Class 0 X.224 Connection Confirm PDU (refer to section 2.2.1.2). From this stage onward, all subsequent data exchanged between the client and server is encapsulated within an X.224 Data Protocol Data Unit (PDU).
1.2 Client MCS Connect Initial PDU
Starting with the “Client MCS Connect Initial PDU with GCC Conference Create Request,” messages are transmitted with some level of encoding.
1.3 Identifying Unencrypted Data
The optimal point to detect unencrypted data from the Metasploit code is during the Connection Request PDU.
1.4 Client X.224 Connection Request PDU
For further details, refer to the Client X.224 Connection Request PDU Documentation.
2. Code Implementation
The connection request PDU is constructed in the lib/msf/core/exploit/rdp.rb file using the following method:
By examining the behavior of the exploit, it is evident that the initial step involves invoking the fingerprint method with the following parameters:
rdp_fingerprint()
rdp_check_protocol(RDPConstants::PROTOCOL_SSL | RDPConstants::PROTOCOL_HYBRID | RDPConstants::PROTOCOL_HYBRID_EX)
This causes the [requested_protocols].pack(‘L<’), of the pdu_negotiation_request(), to results on “0b 00 00 00”.
The options of the RequestedProtocols are:
PROTOCOL_RDP = 0
PROTOCOL_SSL = 1
PROTOCOL_HYBRID = 2
PROTOCOL_RDSTLS = 4
PROTOCOL_HYBRID_EX = 8
These values are transmitted in a 32-bit format.
Initially, the value “0b 00 00 00” is sent when the rdp_fingerprint is called for the first time. This occurs due to the application of the “OR” operator on the constants with their default values:
RDPConstants::PROTOCOL_SSL | RDPConstants::PROTOCOL_HYBRID | RDPConstants::PROTOCOL_HYBRID_EX1 OR 2 OR 80001 OR 0010 OR 1000 = 1011 = \x0B
Consequently, the [requested_protocols].pack('L<') generates “0b000000”.
Per the RDP Negotiation Request (RDP_NEG_REQ) documentation, this requested_protocol value activates all three options: [PROTOCOL_SSL, PROTOCOL_HYBRID, PROTOCOL_HYBRID_EX]. The last option triggers the “Early User Authorization Result PDU.”
This occurs only during the initial round, after which the code executes the rdp_fingerprint method again. On the second attempt, it completes successfully.
Following the second “Verifying RDP protocol” step, the “Send data” section displays a payload ending with “01000000,” indicating the standard use of requestedProtocols without employing the “Early User Authorization Result PDU.”
After that, the protocol proceed with the connection and the exploit follow its flow.
The key point is that the initial RDP Negotiation Request PDU sent with the Early User Authorization Result PDU set is not typical behavior. This is neither seen in the Windows RDP Client nor in Linux clients such as Remmina.
Therefore, this specific piece of data in the unencrypted part of the communication serves as the most effective signature for detecting the BlueKeep Metasploit Module.
3. Detect Bluekeep Attack
Based on the above analysis, we can make it very easy to make Snort and Sax2 rules to detect Bluekeep, and below we have listed the rules for two intrusion detection systems.
3.1 Snort Rule
#content:”|03 00|” -->TPKT Header version 03, reserved 00
#content:”|43 6f 6f 6b 69 65 3a 20 6d 73 74 73 68 61 73 68 3d|” --> ‘Cookie: mstshash=’
#content:”|0b 00 00 00|” -->requested_protocols
####################################################################alert tcp any any -> any 3389 (msg:”Metasploit Bluekeep”; flow:to_server,established; content:”|03 00|”; offset:0; depth:2; content:”|43 6f 6f 6b 69 65 3a 20 6d 73 74 73 68 61 73 68 3d|”; distance:9; within:17; content:”|0b 00 00 00|”; distance: 13; reference:url,github.com/alexandrevvo/snort_rules/blob/master/metasploit_bluekeep; sid:100000012;)
3.2 Sax2 Rule
For more information on how to create a Sax2 detection rule, please refer to the documentation “Detect EternalBlue Exploit via Sax2 IDS“