Blog post

Finding the kill switch to stop the spread of ransomware

Created:  13 May 2017
Updated:  13 May 2017
Author:  MalwareTech

Media reports today have rightly praised the efforts of MalwareTech to tackle the Wannacry cyber attack. The NCSC has been working in collaboration with a number organisations in the cyber security community, including MalwareTech and 2SEC4, to understand and mitigate the current Wannacry ransomware threat.

These industry partners have helped by offering us intelligence from the sinkholed Wannacry domain.

This sinkholed domain has prevented further infections occurring and has already resulted in preventing over 100,000 potential infections. However, this action will not remediate infections that have already occurred. Currently, the best mitigation available to prevent infection by Wannacry is the guidance presented in the following blog by MalwareTech and the latest ransomware guidance from the NCSC.


So finally, I've found enough time between emails and Skype calls to write up on the crazy events which occurred Friday, which was supposed to be part of my week off (I made it a total of 4 days without working, so there's that). You've probably read about this on several news sites, but I figured I'd tell my story.

I woke up at around 10 AM and checked onto the UK cyber threat sharing platform where I had been following the spread of the Emotet banking malware, something which 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, which is when everything started to kick off.

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 that this was going to be 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 emails which suggested to me that something this widespread was something else). I was quickly able to get a sample of the malware through Kafeine, a friend and fellow researcher, which I instantly noticed queried an unregistered domain, which I promptly registered.

With Cisco Umbrella, we can actually see query volume to the domain prior to our registration of it which shows the campaign started at around 8 AM UTC.

While the domain was propagating, I ran the sample again in my virtual environment to be met with WannaCrypt ransom page; but more interestingly was that after encrypting the fake files I left there as a test, it started connecting to random IP addresses on port 445 (used by SMB) extremely quickly. The mass connection attempts immediately made me think exploit scanner, and the fact it was scanning on the SMB port caused me to think back to the recent ShadowBroker's leak of NSA exploits containing...and SMB exploit. Obvious I had no evidence 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.

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 register several thousand of such domains in the past year.

Our standard model goes something like this.

  • Look for unregistered or expired C2 domains belonging to active malware and point it to our sinkhole (a sinkhole is a server designed to capture malicious traffic and prevent control of the infected computers by the criminals who infected them).
  • 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.
  • 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, steps 1, 2 and 3 were all one and the same, I just didn't know it yet.

A few seconds after the domain had gone live I received a DM from a Talos analyst asking for the sample I had which was scanning SMB host, which I provided. Humorously at this point we had unknowingly killed the malware so there was much confusion as to why he could not run the exact same sample I just ran and get any results. This was curious but I didn't have time to investigate, as now the sinkhole servers were coming dangerously close to their maximum load.

I then set about making sure our sinkhole server was stable and getting the expected data from the domain we had registered (at this point we still didn't know much about what the domain we registered was for, just that anyone infected with this malware would connect to the domain we now own). Sorting out the sinkholes took longer than expected due to the increasing load of a very large botnet we had sinkholed the previous week, but soon enough I was able to set up a live tracking map and push it out via Twitter here.

Around 6:23 PM (BST) I asked an employee to look into the ransomware code and verify the domain we registered would not change (some malware will periodically change the domain using an algorithm, so we needed to know what new domains to later register if that was the case), meanwhile I continued performing some updates to the sinkhole server.

After about 5 minutes he came back with the news that the registration of the domain had triggered the ransomware meaning we'd encrypted everyone's files, causing me to freak out (don't worry, this was not the case). I contacted Kafeine about it and he linked me to the following newly posted tweet made by ProofPoint researcher Darien Huss, who stated the opposite (that our registration of the domain had actually stopped the ransomware and prevented the spread).

Having heard two conflicting answers, I anxiously loaded back up my analysis environment and ran the sample....nothing. I then modified my host file so that the domain connection would be unsuccessful and ran it again.....RANSOMED.

Now you probably can't picture an adult jumping around a room with the excitement of having just been ransomwared, but this was me. The failure of the ransomware to run the first time and the success on the second meant that we had in fact prevented the spread of the ransomware and prevented it ransoming any new computer since the registration of the domain.

So why did our sinkhole cause the malware to fail?

Talos wrote a great writeup which I'll elaborate on using Darien's screenshot.

All this code is doing is attempting to connect to the domain we registered and if the connection is not successful it ransoms the system, if it is successful the malware exits. The reason was suggested to be a kill switch in case something goes wrong, but I now believe it to be anti-analysis.

In certain sandbox environments traffic is intercepted by replying to all URL lookups with an IP address belonging to the sandbox, rather than the real IP address the URL points to; a side effect of this is if an unregistered domain is queried it will respond as if it were registered.

I believe they were trying to query an unregistered domain which would appear registered in certain sandbox environments, then once they are aware they're in a sandbox the malware can exit to prevent analysis. This technique isn't unprecedented and is actually used by the Necurs trojan (they will query 5 totally random domains and if they all return the same IP, it will exit); however, because they used a hardcoded domain, registering it caused all infections globally to believe they were inside a sandbox and exit...thus we initially unintentionally prevented the spread and further ransoming of computers infected with this malware.

One thing that is very important to note is our sinkholing only stops this sample and there is nothing stopping them removing the domain check and trying again, so it's incredibly important that any unpatched systems are patched as quickly as possible. You can now even get a patch for XP.

Blog by MalwareTech

*Read the NCSC guidance on protecting your organisation from ransomware


Fred Gregory - 13 May 2017
Congratulations. Great work! SuperGeek to the rescue.
Marion Friedl - 13 May 2017
Good job, who knows how much more damage´d have been done if you hadn´t been able to switch that trojan off??? I think especially about those who use a Windows system that´s not supported anymore, like Vista (that I used on my 2 other notebooks not so long ago), if their PCs caught the trojan they couldn´t even install that Microsoft update from March the 14th that´s been mentioned on TV and radio...
Rodrigo Brenes - 13 May 2017
Could be good to know the entry point.
I have been reading that is more likely through phishing scam.
People are focusing in the cool part which is the SMB exploit to propagate.
But it is still a ransomware that will encrypt files and mounted sharefiles.
During the weekend, companies might be bombarded with phishing carrying the malicious attachment that will trigger or originate patient 0 on an office or company WW.
Could be good to have basic vectors like emails address, email domain, email subject, attachment extension and filename. That way during the weekend, companies can look at inbound emails and retrieve anything that could be suspicious before Monday.
Laura Friberg - 15 May 2017
Great work! Thank you
Kenny - 16 May 2017
People like you make our jobs ( IT Admin) that little be easier, Thanks to you and your team.
Rob Betts - 16 May 2017
Well done. Keep up the good work protecting us from these criminals. Thank you.
Artemis - 22 May 2017
Really Appreciate your help!!
NCSC Incidents Management Team - 14 Jul 2017
Thank you to everyone who took the time to read the blog and comment on it. Although we haven’t published them all, each of the responses has been taken on board and investigated where possible. The results have helped inform and develop the NCSC advice and guidance on WannaCry.
NCSC Communications Team - 28 Aug 2018
This blog is now closed to comments.

Was this blog post helpful?

We need your feedback to improve this content.

Yes No