Scanning for Bluekeep vulnerable RDP instances
Since the Microsoft Remote Desktop Protocol (RDP) vulnerability CVE-2019-0708, commonly knows as BlueKeep, was first announced in May of 2019, the security industry has been holding their breath waiting for the worse case scenario. Scanning for vulnerable RDP instances began almost immediately after the announcement. Since then a number of exploits for BlueKeep have been seen that can crash vulnerable systems, but the anticipated wormable exploit hasn't yet materialized.
Now that both Immunity's Canvas and Rapid7's Metasploit have working exploits in their penetration testing tools you have to believe that it is only a matter of time until the bad guys have one as well.
It would be nice to say that the number of systems running a vulnerable RDP instance has decreased since the vulnerability announcement, but for the IP space I have been tracking I have only seen a decrease of about 10% in vulnerable systems over the last 90 days.
If you are a security administrator and want to find the BlueKeep vulnerable systems on your network, how would you go about it? For the Bluekeep vulnerability it is relatively easy. With access to a *nix box with the high speed scanner masscan and the rdpscan tool installed along with their dependencies, it is a very easy bash script.
I called this bash script scan_bluekeep.sh
-----
-----
As the comments state, place your IP addresses or ranges to be scanned in the file scan_ips.txt. This will be used as the input file for this script. The output will be two files:
* The masscan output file will be rdpips-<DATE>.txt, all IPs found with RDP open on port 3389 * the rdpscan output file will be RDP_results-<DATE>.txt, the rdpscan result showing each detected RDP instance and whether or not rdpscan believes they are vulnerable to BlueKeep
Checking the rdpscan output in RDP_results-<DATE>.txt you will generally find one of 3 results:
1.2.3.4 - SAFE - Target appears patched
or
1.2.3.4 - VULNERABLE - got appid
there is also an UNKNOWN result, which is usually one of:
1.2.3.4 - UNKNOWN - RDP protocol error - receive timeout
1.2.3.5 - UNKNOWN - no connection - connection closed (RST)
Concentrate on resolving the VULNERABLE results and you will sleep much better when the wormable exploit finally hits.
-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)
Comments