Using Firepower to defend against encrypted RDP attacks like BlueKeep

Cisco’s research group Talos posted an interesting article that looks at exploitation through encrypted channels (Original article found HERE). I am asked often about this type of attack. In summary, the concern is that most organizations have a network IPS however, that IPS will not be able to see encrypted attacks. This means SSL decryption is required in order to evaluate traffic or the IPS will be blind.

My thoughts on this concern are to first think about the entire attack. Reputation security does not depend on SSL. It ranks the “trustworthiness” of a source and drops known malicious sources. For example, if bank has been online for 2 hours, hosted for GoDaddy and only has sent traffic to your organization, I assure you its not a bank. A good test for this is the website “ihaveabadreputation.com”. If you see a block page, you have reputation security. If you don’t, then anybody can stand up a website and start attacking you.

Any technology that evaluates which comes over the internet is not impacted by SSL. For example, scanning all files that are downloaded for malicious intent would not be impacted by SSL. Evaluating how the endpoints interact with the network and the Internet would not be impacted by SSL.

This means only the traffic between the endpoint and network is at risk of encrypted attacks. The best way to address this is to consider decryption options. Vendors such as F5, Radware and A10 offer appliances that can be dedicated for this task. Also many next-generation firewalls such as Cisco Firepower offer decryption capabilities, which is covered in the Talos article. Consider these concepts as you evalurate the threat to encrypted attacks.

Here is the article from Talos ….

Microsoft recently released fixes for a critical pre-authentication remote code execution vulnerability in Remote Desktop Protocol Services (RDP). Identified as CVE-2019-0708 in May’s Patch Tuesday, the vulnerability caught the attention of researchers and the media due to the fact that it was “wormable,” meaning an attack exploiting this vulnerability could easily spread from one machine to another. This was discussed at length in episode 54 of our ‘Beers with Talos’ podcast.

Cisco Talos started reverse-engineering work immediately to determine how exactly RDP was vulnerable. Talos wrote and released coverage as soon as we were able to determine the vulnerability condition. SID 50137 for SNORT® correctly blocks exploitation of CVE-2019-0708 and scanning attempts that leverage this vulnerability.

This rule prevents exploitation of CVE-2019-0708 by blocking any RDP connection that attempts to use the “MS_T120” virtual channel. The RDP protocol defines virtual channels that can be used to transfer different kinds of data (e.g. clipboard, audio, etc.). In addition to these client-specified channels, Microsoft creates the “MS_T120” channel in the Windows RDP system. Clients are not expected to create the “MS_T120” channel. A remote unauthenticated attacker can exploit CVE-2019-0708 by sending crafted data to this internal channel.


Since RDP servers are not aware of which virtual channels the client supports, the client provides a list of desired channels in the connect-initial packet at the start of the RDP session.

Client –> Connection Request –> Server
Client <– Connection Confirm <– Server
— Optionally switch transport to TLS —
Client –> MCS connect-initial –> Server
Client <– MCS connect-response <– Server

It is possible to specify in the RDP connection request that the client is TLS capable. In most cases, this causes the server to switch the connection to TLS after the Connection Confirm packet. This means that Cisco Firepower will only scan the virtual channel list in the encrypted case if TLS decryption is set up for RDP.

While the aforementioned Snort rule can help protect against BlueKeep, it is still possible for attackers to carry out an encrypted attack — essentially sneaking past users and remaining undetected. Unless users set up TLS decryption for RDP on their Firepower device, there is a chance an attacker could exploit CVE-2019-0708 to deliver malware that would have the potential to spread rapidly.

The following is a guide to set up RDP decryption on Cisco Firepower. This guide specifically applies to Windows Server 2008 instances (newer versions of Windows Server are not vulnerable to BlueKeep). Additionally, Windows 7 only allows setting up a custom RDP certificate in the registry. It is possible to export the self-signed RDP certificate and private key in Windows 7 but this requires using the mimikatz tool as the private key for the auto-generated certificate is marked as “not exportable”. Considering these hurdles, we focused on Windows Server 2008 for this guide.

*Note this procedure requires an inline Firepower device that supports SSL decryption. For more information, visit: Cisco Next-Generation Intrusion Prevention System (NGIPS) – Cisco.

Steps for RDP Decryption

1. Determine the certificate used by the RDP server
In Windows Server 2008, TLS certificates for RDP are configured in “Remote Desktop Session Host Configuration.”

See the full article at https://blog.talosintelligence.com/2019/05/firepower-encrypted-rdp-detection.html to learn how to setup Cisco Firepower