Protect yourself against CVE-2019–0708 aka #BlueKeep using Azure Sentinel and Microsoft Defender ATP
On May 14th 2019, Microsoft’s Security Response Center issued guidance that a vulnerability was found in Remote Desktop Services, formerly known as Terminal Services, allowing an unauthenticated hacker to execute code on the target system. Windows 7, Windows Server 2008 and 2008 R2 are affected.
Microsoft issued a fix and advised to patch directly because the vulnerability is ‘wormable’ and to prevent a situation such as with WannaCry and others. Underlining the importance of the CVE is the fact that Microsoft backported the fix to Windows XP and Windows Server 2003. The vulnerability was nicknamed BlueKeep in the infosec community.
In this article we’ll show you how Azure Sentinel and Microsoft Defender ATP can help you get more background information on the CVE, show you which systems are affected, and how to detect when the CVE is exploited.
Patch Management is still a #1 priority
A good patch management strategy is commonly listed as one of the basics of an organizational cybersecurity strategy. Unfortunately, we still see companies not regularly patching their systems. This has a number of reasons: a lack of technical staff can make updating a little scary, undermanned IT staff can become busy with problems perceived to be ‘more important’, and an often heard answer is that some updates can cause performance issues or ‘break stuff’. Regardless of the reasons why an organization may procrastinate when it comes to patching, it’s a critical process that needs to be in place.
The good news is that Microsoft Azure provides Update Management as a service. It’s technically part of Azure Security Center and uses the Microsoft Management Agent on your servers (which will likely already be there for monitoring, security management and other tasks) to report status and execute the fixes. If you’re in a hybrid world and want to cover your on-premises servers, Microsoft’s System Center Configuration Manager (SCCM) together with Microsoft Intune is a great option as well.
Microsoft Defender ATP knows more about the CVE
When a CVE is reported, one of the first things you’ll likely be doing is searching for more background information on this exploit. A good starting point could be the article that MSRC issued, or the corresponding document on MITRE’s website.
But if you’re using Microsoft Defender ATP, there is a section called Threat Analytics where the MDATP team regularly posts important information. On the day MSRC issued the guidance, the MDATP team put up an article about the CVE called “Wormable RCE vulnerability in RDP”. It has key insights, tasks that can be used for mitigation, links to the fixes, and much more. The best part though are the integrated dashboards: the page shows you which machines in your environment are exploitable.
The MDATP team also provides a KQL query that can identify machines with relatively intense outbound network activity on the common RDP port (TCP/3389) which you can use to find processes that might be scanning for possible targets or exhibiting worm-like behavior.
let listMachines = MachineInfo
| where OsVersion == “6.1” //Win7 and Srv2008
| distinct MachineId;
NetworkCommunicationEvents
| where RemotePort == 3389
| where Protocol == “Tcp” and ActionType == “ConnectionSuccess”
| where InitiatingProcessFileName !in~ //filter some legit programs
(“mstsc.exe”,”RTSApp.exe”, “RTS2App.exe”,”RDCMan.exe”,”ws_TunnelService.exe”,”RSSensor.exe”
“RemoteDesktopManagerFree.exe”,”RemoteDesktopManager.exe”,”RemoteDesktopManager64.exe”,
“mRemoteNG.exe”,”mRemote.exe”,”Terminals.exe”,”spiceworks-finder.exe”,
“FSDiscovery.exe”,”FSAssessment.exe”)
| join listMachines on MachineId
| project EventTime, MachineId, ComputerName, RemoteIP, InitiatingProcessFileName,
InitiatingProcessFolderPath, InitiatingProcessSHA1
| summarize conn=count() by MachineId, InitiatingProcessFileName, bin(EventTime, 1d)How does the exploit work?
If you’d get into the nitty gritty details of how the RDP protocol works and why it is that on Windows 7, Windows Server 2008 and 2008 R2 it can be exploited, check out this write-up from Matt and Aaron. TL;DR: it’s not the protocol but the implementation on those OS’s.
A quick query at Shodan reveals that there are at least 2+ Million machines connected to the internet that publicly expose RDP at the default port of 3389. Most of them in the US and China, and about 130K of them are hosted on Amazon AWS. Rob Graham argues that around 950K of them are vulnerable for BlueKeep. Bad Packets report the number of RDP scans per country.
GreyNoise is actively monitoring and at the time of this writing observing sweeping tests for systems vulnerable to BlueKeep from several dozen hosts around the Internet. Interesting fact: that activity has been observed from exclusively TOR exit nodes and is likely being executed by a single actor.
Besides disabling RDP and port 3389 when it’s not needed, another important workaround would be to enable Network Level Authentication (NLA) on systems running Windows 7, Windows Server 2008 and 2008 R2. With NLA turned on, an attacker would first need to authenticate to Remote Desktop Services using a valid account on the target system before the attacker could exploit the vulnerability.
To identify assets at risk, refer to the following table by Dragos:
PRO TIP: Are you red teaming and want to get more information of the OS/system you are connecting to? If you get prompted for a login for RDP before login screen, enter .\guest no password and it bumps you to login screen. Thanks Kevin!
Azure Cloud Shell & PowerShell can help
Now, if you’re running your Windows VM’s in Azure, you might want to have a look at your Network Security Groups (NSG’s). This is the time where you will want to evaluate if having that port 3389 opened up to the internet is a good idea. (Answer: nope).
Here’s a PowerShell script to check all of your Azure Subscriptions, and for each resource group query all the NSG’s to see if 3389 is open:
$subs = az account list — query “[].id” -o tsvforeach( $sub in $subs ){az account set -s $sub$nsgList = az network nsg list — query “[].{Name:name, ResourceGroup:resourceGroup}” | ConvertFrom-Jsonforeach( $nsg in $nsgList ) {$rules = az network nsg rule list — nsg-name $nsg.Name -g $nsg.ResourceGroup — query “[?destinationPortRange==’3389'].{Name:name, ResourceGroup:resourceGroup}” | ConvertFrom-Json$rules}}
PRO TIP: You can use Azure Cloud Shell to run this script!
PRO TIP: Another option to look at is the just released ‘Adaptive Network Hardening’ feature of Azure Security Center. It learns the network traffic and connectivity patterns of your Azure workloads and provides you with NSG rule recommendations for your internet-facing virtual machines.
InfoSec community at work
The bigger danger at this stage is the exploitation of CVE-2019–0708 once inside the organization to quickly compromise hosts and for Lateral Movement. And since the first real exploit proof of concept is publicly out there reported by Chase Dardaman, we will leverage Azure Sentinel to build detection for BlueKeep.
So how do you start detecting potential BlueKeep related behavior? Markus Neis at Swisscom shared a Sigma rule to the GitHub repo for addressing Lateral Movement technique T1210 (exploitation of Remote Services) within 24 hours of the CVE becoming public knowledge. The same day, SOC Prime’s Roman Ranskyi also published a Sigma rule with detection logic extending to Masquerading technique T1036 and Network Service Scanning technique T1046.
Recently, Adam also shared his findings that account name AAAAAAA in a 4625 Windows Event is a potential indicator of people downloading this BlueKeep scanner from GitHub and running it without modification against an RDP server. Florian Roth then turned this into a Sigma rule.
How to detect BlueKeep exploit usage in Azure Sentinel
Azure Sentinel keep help detect BlueKeep. By sourcing information from the intelligent security graph, Azure Security Center, and many other sources, Microsoft’s coud SIEM can provide detection. Using the combined knowledge of the InfoSec community, it is easy to add the appropriate Alert Rules.
Here’s the KQL query to detect suspicious outbound RDP connections. It detects non-standard tools connecting to TCP port 3389 indicating possible lateral movement:
Event| parse EventData with* ‘Data Name=”RuleName”>’ RuleName ‘<’* ‘Data Name=”UtcTime”>’ UtcTime ‘<’* ‘Data Name=”ProcessGuid”>’ ProcessGuid ‘<’* ‘Data Name=”ProcessId”>’ ProcessId ‘<’* ‘Data Name=”Image”>’ Image ‘<’* ‘Data Name=”User”>’ User ‘<’* ‘Data Name=”Protocol”>’ Protocol ‘<’* ‘Data Name=”Initiated”>’ Initiated ‘<’* ‘Data Name=”SourceIsIpv6">’ SourceIsIpv6 ‘<’* ‘Data Name=”SourceIp”>’ SourceIp ‘<’* ‘Data Name=”SourceHostname”>’ SourceHostname ‘<’* ‘Data Name=”SourcePort”>’ SourcePort ‘<’* ‘Data Name=”SourcePortName”>’ SourcePortName ‘<’* ‘Data Name=”DestinationIsIpv6">’ DestinationIsIpv6 ‘<’* ‘Data Name=”DestinationIp”>’ DestinationIp ‘<’* ‘Data Name=”DestinationHostname”>’ DestinationHostname ‘<’* ‘Data Name=”DestinationPort”>’ DestinationPort ‘<’* ‘Data Name=”DestinationPortName”>’ DestinationPortName ‘<’*| where ((EventID == “3” and DestinationPort == “3389”) and not(Image endswith “\\mstsc.exe”or Image endswith “\\RTSApp.exe”or Image endswith “\\RTS2App.exe”or Image endswith “\\RDCMan.exe”or Image endswith “\\ws_TunnelService.exe”or Image endswith “\\RSSensor.exe”or Image endswith “\\RemoteDesktopManagerFree.exe”or Image endswith “\\RemoteDesktopManager.exe”or Image endswith “\\RemoteDesktopManager64.exe”or Image endswith “\\mRemoteNG.exe”or Image endswith “\\mRemote.exe”or Image endswith “\\Terminals.exe”or Image endswith “\\spiceworks-finder.exe”or Image endswith “\\FSDiscovery.exe”or Image endswith “\\FSAssessment.exe”or Image endswith “\\MobaRTE.exe”or Image endswith “\\chrome.exe”))
PRO TIP: You will need to have SwiftOnSecurity’s Sysmon configuration installed on the RDP / TS machines you will be protecting / monitoring.
Here’s the KQL query to detect the use of a scanner by zerosum0x0 that discovers targets vulnerable to BlueKeep:
SecurityEvent| where (EventID == “4625” and AccountName == “AAAAAAA”)
PRO TIP: Both KQL queries can be found on our GitHub repo.
Summary
Considering all the above, the top 3 things you can do as a defender are:
- Deploy proactive detection.
- Rigorously patch or mitigate the vulnerability.
- Keep track on the situation development following input from researchers your trust.
Microsoft security really is more than 1+1. When using a combination of Azure Sentinel, Azure Security Center, Microsoft Defender ATP, and Microsoft Intune, you get an integrated approach to protecting, detecting and responding to threats like BlueKeep.
Happy hunting!
— Maarten Goet, MVP & RD
