I woke up this morning to the long anticipated news that Bluekeep exploitation is happening in the wild.  As some of you may recall, back in August I wrote a diary demonstrating a way to scan for Bluekeep vulnerable devices.  So the next thing I did was check my Bluekeep scan results and was presented with this graph.

It appeared that not only was exploitation nearly 100% successful, but that the exploit was patching against the Bluekeep vulnerability presumably to prevent subsequent exploits from taking over the machine.  

As the day went on I was able to review some the the research about this exploit that had been published over the last couple of days.  Some here.  They all say similar things; Monero miner running out of C:\Windows\System32\spool\svchost.exe etc., but no mention of disabling the vulnerability.  I contacted a couple of researcher friends and they confirmed that they were not seeing the vulnerable RDP disappearing after exploitation.

As detailed in my August 6 diary, my Bluekeep scan script works in two stages:

1. masscan is run against the RDP port (3389/TCP) across the IP ranges to find devices with exposed RDP ports
2. rdpscan is run against any devices found by step 1 to determine if the exposed RDP is vulnerable to Bluekeep

A little digging and I discovered that masscan was no longer detecting the open RDP sessions on the vulnerable, and presumable exploited, devices.  Running nmap against the same devices detected the open RDP port.

PORT     STATE SERVICE       VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Service
| ssl-cert: Subject: commonName=something.something.something
| Not valid before: 2019-10-11T18:16:43
|_Not valid after:  2020-04-11T18:16:43
|_ssl-date: 2019-11-04T16:56:40+00:00; 0s from scanner time.

I was at a loss.  Then one of my colleagues Mo suggested, that if the exploited device is running a Monero miner, the substantial increase in CPU may be causing the device to respond to the probe slower and perhaps masscan is timing out before a response is received.

By default masscan waits 10 seconds for a response.  Increase that timeout to 30 seconds:

/usr/bin/masscan -p3389 -v --wait 30 <IP>

and masscan is able to discover the exposed, and presumably exploited, Bluekeep vulnerable RDP ports.

Just goes to show that you can't always trust your tools when conditions change.

The improved Bluekeep scan script should be:

-----

#!/bin/bash

#create a date parameter for the various files so scans run on different dates don't overwrite each other.

TDATE=`date +%Y%m%d`

 

# put your IPs or IP ranges you would like to scan in scan_ips.txt 

# this will be used as the input to masscan

# the output file is rdpips-<DATE>.txt

echo "executing masscan"

/usr/bin/masscan -p3389 --wait 30 -v -iL scan_ips.txt > rdpips-$TDATE.txt

 

#the output from the masscan will be used as the input to rdpscan

#the output file will be RDP_results-<DATE>.txt

echo "executing rdpscan"

rdpscan --file rdpips-$TDATE.txt > RDP_results-$TDATE.txt

-----

I am not sure if there is a mechanism here that could be used to reliably detect exploited devices.  But maybe.

 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)