rdp-sec-check.pl script but we were out of luck since some of the newer versions of windows operating systems shared the same configurations as XP and 2003. Another option was to use nmap fingerprinting scripts to detect the OS but these scripts take long time and don’t scale well.
The last method that came to our mind was to connect via RDP, take a screenshot and analyze it to detect the underlying OS. I had the experience of sliding windows and finding an image inside another bigger image and I knew it’s rather easy to implement using a library like open-cv.
I did a little bit of research and found rdpy, which is a python library that can handle RDP and is written with twisted, it also happens to have screenshot capability. But in action I found some downsides to this script, twisted error handling is not very well implemented, it gets stuck in loops on some IP addresses and throws errors here and there mostly on XP and 2003 targets. We kept searching for replacements when my colleague found this repo: sticky_keys_hunter. It uses rdesktop linux software to remote desktop and try to test for presence of a specific backdoor which was not of our interest, what was interesting to us though was the fact that it could take screenshots of its remote session, with a little bit of modification we turned this bash script into what we wanted.
The final bundle is available on this repo: DetectOSViaRDP.
I’ll skip the setup part and go straight to the scripts’ description. We had an IP list from masscan, we stored it in a text file with one address per line:
We use rdpss.sh script to iterate over these IP addresses and take screenshots, you can fine-tune LIMIT variable in rdpss.sh to achieve more parallel sessions (we tested up to 50 and we could test 75 IP addresses per minute on a low end virtual machine).
This script saves the images under ./images directory with their IP addresses as their file names.
Now that we have the screenshots, we prepare some small images that are unique to each operating system’s remote desktop screen:
Operating System
Image used
Purpose
Windows Server 2003
Detect OS
System is joined in a domain or is domain controller
Options menu is open (We have to toggle it open to see if the system is part of domain)
Windows XP
Detect OS
Using open-cv, we search for these images inside taken screenshots. This is done using DetectOS.py.
We passed the directory of all screenshots and our marker image and the script returned the list of IP addresses with that specific image inside their screenshot.
We also manually verified our results over a dataset of 11655 IP addresses for windows XP and 2003 and the result was satisfactory:
FP: 0 %
FN: 0.2 %
Next step was to find out whether the OS was part of a domain or not, sometimes you’ll have to interact with the session and click on “options” button to open the menu that lists the domain name that the system is a part of so we modified our script to send 4 tabs and 1 enter button to achieve this. We used rdesktop and xdotools to achieve this, the original idea came from stickyKeysHunter script.
We used ipinfodb.com API to get latitudes and longitudes of our scanned IP addresses, we then used gmplot to plot these locations on google map (link).
We were not the only people in the infosec community aware of this threat, while we were preparing our results 0patch came out with a closed source patch which seems to install their proprietary client to mitigate this vulnerability. Couple of days ago a company named enSilo also released a closed source patch (link), they used hot patching to manipulate the in memory winlogon process to fix the vulnerable code.
Update: Our initial analysis made us believe enSilo’s patch is adding itself to browser history for advertisement purposes but it turned out to be wrong, their patch looks innocent, we apologize for this false assumption. There’s also one upside to their solution and it’s that you still get to use smart card authentication and it doesn’t disable the whole feature to mitigate the vulnerability.
We kept doing our research and found a person pointing out to a command that unregisters the vulnerable dll (gpkcsp.dll) under a blog post, shout out to FrankUnderwood2020. It turned out to be a good solution. It does disable smart card authentication but if you are using that you’re screwed anyway. You can unregister this dll and revert to username and passwords which most people are using if you absolutely can’t upgrade the OS.
To run this command you have to have admin privileges, if you don’t it will still tell you it succeeded but vulnerability won’t go away.
regsvr32 /u c:\windows\system32\gpkcsp.dll
To verify it, you can use the following command and you should see this result: ERROR: The system was unable to find the specified registry key or value.
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Gemplus GemSAFE Card CSP v1.0"
Running the exploit on a vulnerable system:
After unregistering gpkcsp.dll:
This report is a part of telescam project. In this independent/personal project we try to address Telegram messenger scam campaigns and increase public knowledge on their techniques, but since Wannacry had a great impact we also decided to publish a report alongside this project here. Our goal was to increase public knowledge on these issues and try to minimize their impact.
Update (14-June-2017): Microsoft released a patch for Windows XP and Windows Server 2003 operating systems addressing EsteemAudit and other unaddressed exploits by shadowbrokers. Now the best solution if you absolutely can’t upgrade would be to apply official patches.
CVE-2017-0176: EsteemAudit
CVE-2017-7269: ExplodingCan
CVE-2017-8487: EnglishmanDentist