Bluekeep exploitation causing Bluekeep vulnerability scan to fail
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:
- masscan is run against the RDP port (3389/TCP) across the IP ranges to find devices with exposed RDP ports
- 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
3389/tcp open
| ssl-cert: Subject: commonName=something.something.something
| Not valid before: 2019-10-11T18:16:43
|_Not valid after:
|_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)
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago