How I accidentally stopped a global Wanna Decryptor ransomware attack

I’ve finally found enough time between e-mails and Skype calls to write up the crazy events that occurred over Friday, which was supposed to be part of my week off. You’ve probably read about the Wanna Decryptor (aka WannaCrypt or WCry) fiasco on several news sites, but I figured I’d tell my story.

I woke up at around 10am and checked onto the UK cyber threat sharing platform where I had been following the spread of the Emotet banking malware, something that seemed incredibly significant until today. There were a few of your usual posts about various organisations being hit with ransomware, but nothing significant... yet. I ended up going out to lunch with a friend, meanwhile the WannaCrypt ransomware campaign had entered full swing.

When I returned home at about 2:30, the threat sharing platform was flooded with posts about various NHS systems all across the country being hit, which was what tipped me off to the fact this was something big. Although ransomware on a public sector system isn’t even newsworthy, systems being hit simultaneously across the country is. (Contrary to popular belief, most NHS employees don’t open phishing e-mails, which suggested that something to be this widespread it would have to be propagated using another method.)

I was quickly able to get a sample of the malware with the help of Kafeine, a good friend and fellow researcher. Upon running the sample in my analysis environment I instantly noticed it queried an unregistered domain, which I promptly registered.

Using Cisco Umbrella, we can actually see query volume to the domain prior to my registration of it, which shows that the ransomware campaign started at around 8am UTC.

While the domain was propagating, I ran the sample again in my virtual environment to be met with the WannaCrypt ransom page. But even more interesting was that, after encrypting the fake files I left there as a test, the malware started connecting out to random IP addresses on port 445 (used by SMB).

The mass connection attempts immediately made me think exploit scanner, and the fact it was scanning on the SMB port caused me to look back to the recent Shadow Broker leak of NSA exploits containing... an SMB exploit. Obviously I had no evidence yet that it was definitely scanning SMB hosts or using the leaked NSA exploit, so I tweeted out my findings and went to tend to the now-propagated domain.

Sample I found scans SMB after dropping WannaCrypt. Can anyone confirm it's the same thing? P2P spreading ransomware would be significant. pic.twitter.com/zs5Td4ovvL

— MalwareTech (@MalwareTechBlog) May 12, 2017

Now one thing that’s important to note is the actual registration of the domain was not on a whim. My job is to look for ways we can track and potentially stop botnets (and other kinds of malware), so I’m always on the lookout to pick up unregistered malware control server (C2) domains. In fact I registered several thousand of such domains in the past year.

Our standard model goes something like this.

1. Look for unregistered or expired C2 domains belonging to active botnets and point it to our sinkhole (a sinkhole is a server designed to capture malicious traffic and prevent control of infected computers by the criminals who infected them).
2. Gather data on the geographical distribution and scale of the infections, including IP addresses, which can be used to notify victims that they’re infected and assist law enforcement.
3. Reverse engineer the malware and see if there are any vulnerabilities in the code which would allow us to take over the malware/botnet and prevent the spread or malicious use, via the domain we registered.

In the case of WannaCrypt, step one, two, and three were all one and the same, I just didn’t know it yet.