Proud Moment: WannaCry Collaboration
Despite Friday’s global ransomware fiasco, I went to sleep that night feeling more proud than distraught. This blog highlights how Wanna Decryptor united InfoSec researchers across the Internet in a classic battle of Good vs. Evil.
In case you haven’t been tracking the story, a group called The Shadow Brokers released several hacking tools on April 14th, 2017. Among these tools were exploits and implants which reportedly belonged to the NSA. A handful of these exploits were 0-day vulnerabilities which allowed an attacker to remotely execute malicious code on Windows hosts with SMB v1 exposed (whether directly to the internet or internally on a LAN). Thankfully, Microsoft provided security patches to their supported operating systems on March 14th, 2017. Immediately after this release, Greg Linares started reverse engineering the patches to discover what Microsoft had fixed. Based on what he discovered, he warned how these vulnerabilities could be used to “worm” — or automatically spread — across the internet.
Unfortunately, worms of the past demonstrate how slowly consumers and organizations will patch their systems, even when the consequences are dire. Case in point is the Conficker Worm which started exploiting systems nearly a decade ago, but is still found in the wild today. With this in mind, Kevin Beaumont dropped a grave warning about the inevitable:
Cue Wanna Decryptor
Although she probably didn’t know it, Gabriela Nicolao initially sounded the alarm on an incoming flood of ransomware infections. The variant was called Wanna Decryptor, but is also known as WanaCrypt0r, wcry, and WannaCry.
Four days later, several mailing lists and threat sharing platforms started overflowing with reports of mass ransomware infections across Europe and Asia. The media quickly picked up on this, and news of a “cyber-attack” on the UK’s National Health System (NHS) spread like wildfire. However, it was security researchers like the MalwareHunterTeam who initially sounded the alarms:
Over the next few hours, the InfoSec community continued to fill Twitter with new details about this attack. Understanding the propagation method was highest on the agenda for most researchers like Autumn Good and ens.
As predicted, the attackers were worming across the internet and encrypting data for ransom in the process 😞 During this same time period, the Payload Security team posted details about WannaCry’s ability to delete the Volume Shadow copies and backups, use .VBS files, and create a Run Key based persistence mechanism.
To aid other researcher’s analysis, Lauri Love released a decrypted copy of the core DLL used by WannaCry. Shortly after, Hacker Fantastic posted a functioning sample for the masses and VirusShare offered to host any new samples on their FTP.
Despite an amazing effort, the causalities were massive by late morning.
University Computer Labs: ✅
Nissan’s Production Line: ✅
Control Systems, ATMs, and Storefronts: ✅ ✅ ✅
By the afternoon of May 12th, the security community had switched gears into prevention mode. Although patching was the obvious solution, this wasn’t an option for unsupported versions of Windows XP, Server 2003, and 8. In Microsoft’s advisory, they suggested an alternative method to workaround this vulnerability which involved disabling “SMB v1/CIFS File Sharing Support”.
Unfortunately, many users and organizations reported repercussions after disabling SMB v1. Some of these include failing print servers and services like netlogon, dfs, and workstation refusing to start. As a result, several makeshift preventative solutions emerged.
Pre-creating the Mutex
In software development, there is a often a need to coordinate mutually exclusive access to a shared resource. To synchronize this access, a mutex object is used. Malware authors often create a mutex to prevent themselves from infecting the same victim twice. In ransomware, a mutex often prevents the malware from re-encrypting a host’s files. With this in mind, I proposed a solution to pre-create the mutex to fake future infections into terminating before encrypting the files:
Earlier in the day, JR0driguezB did the heavy lifting and discovered the mutex MsWinZonesCacheCounterMutexA.
Giuseppe `N3mes1s` followed up with confirmation that WannaCry would not run if the mutex was pre-created and released two lines of PowerShell to temporarily “immunize” a system against existing variants.
Didier Stevens also discovered Global\MsWinZonesCacheCounterMutexA0 could be used to achieve the same effect.
I've seen reports that WannaCry uses a mutex with name Global\MsWinZonesCacheCounterMutexA. The samples I analyzed all…blog.didierstevens.com
Within an hour, the InfoSec community came together and matured a theoretical idea into to functioning proof of concept capable of neutering this global nuisance. For those not comfortable with setting up a persistent PowerShell script, Minerva released an installer to help you out.
Another creative solution came from Florian Roth which abused a built-in debugging feature to prevent the statically named WannaCry executables from running.
For those not familiar with this technique, the Image File Execution Options (IFEO) key is a centralized configuration location for adjusting how images (processes) are executed. Under IFEO, you can create subkeys with values to automatically attach a specified debugger to troubleshoot a process. By setting this Debugger value to “taskkill /F /IM ” instead of a legitimate debugger, explorer.exe will instead execute the command “taskkill.exe /F /IM %NAMEOFTHEKEY%”. This command kills the specified process if it’s already running and prevents future processes with this name from ever running.
Once again, another slick tactical solution to prevent this current variant of WannaCry from infecting unpatched systems.
The most impressive of these short-term preventative solutions was an unexpected byproduct of MalwareTechBlog’s registration of the iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com domain. Although his goal was to interfere with the command and control of the compromised hosts, the presence of this domain actually acted as a kill switch. This result was first discovered by Darien Huss:
The above subroutine attempts an HTTP GET to this domain, and if it fails, continues to carry out the infection. However if it succeeds, the subroutine exits. The domain is registered to a well known sinkhole, effectively causing this sample to terminate its malicious activity.
With this domain sinkholed, it’d be easy to mistake this as the end of WannaCry. Unfortunately, there are several scenarios which could limit the effectiveness of the kill switch. One of these scenarios was brought to light by Didier Stevens involving the presence of a proxy.
As elegantly stated in the blog, WannaCry’s InternetOpenA function uses the access type INTERNET_OPEN_TYPE_DIRECT which causes all domain names to be resolved locally instead of retrieving the proxy configuration. As a result, WannaCry is not “proxy-aware” and will fail to correctly verify if the kill switch domain is active.
Similarly, domain resolution issues could cause the same effect. Notably, several security products blacklisted the kill switch domain before realizing the ramifications of this action. Thankfully, the InfoSec community quickly identified these issues and they were largely corrected on May 13th.
Lastly, malicious actors could release modified variants which use a different kill switch domain or skip the kill switch check completely. Ironically, that’s exactly what happened.
Early on May 14th, Costin Raiu reported a version of WannaCry which did not call out to the kill switch. After careful analysis and collaboration with Matt Suiche, it was confirmed that someone modified the existing version of WannaCry to skip the domain check and remove the URL.
Later in the day, Benkow moʞuƎq’s honeypot picked up a new WannaCry variant on which he also passed to Matt for analysis. In this version, they discovered a new kill switch domain was in use, so they quickly registered it:
The Out-Of-Support Patch
Despite all the excellent work documented above, these all treated the symptom of the infection rather than the cause. With a day or two of re-engineering, WannaCry v3.0 could be created to evade each of these preventative solutions (change up the mutex, rename the process names, and ditch the kill switch). Thankfully, Microsoft also realized this and stepped up to the table with a patch for Windows XP, Server 2003, and 8.
Considering Microsoft’s titanic push towards Windows 10, I was slightly surprised to see this. In case you’re still looking for these patches, they’ve also been lumped under KB4012598 and are available on Microsoft’s update servers.
Although the excitement has largely died down, I don’t think it’s safe to declare it’s over. History shows that patches alone are rarely enough to stop a vulnerability from being exploited. Additionally, there are hundreds of thousands of embedded devices running Windows CE which will never receive these updates. Just as previous circumstances predicted this infection, it’s safe to assume another is right around the corner (maybe SSH next time?).
Despite all this negativity and uncertainty, I can still rest easy knowing the InfoSec community put aside its crazy differences and political views to stand up for the greater good of the Internet. For that, I’m sincerely proud to be apart of you.
If you have any suggestions, comments, or corrections, please reach out to me on Twitter. I’d love for this moment to be preserved and highlight all the hidden heroes who helped lay the smack down on WannaCry. Despite only lasting a few days, this response effort has been one of the most motivational things I’ve helped with (including my time at NSA and serving in Afghanistan). Thank you for taking the time to read this blog. -Kyle