Threat Intelligence

09:40 PM
Connect Directly

WannaCry's 'Kill Switch' May Have Been a Sandbox-Evasion Tool

Massive ransomware worm attack appears to have come with a poorly planned anti-analysis feature.

The WannaCry ransomware "kill switch" a security researcher commandeered on Saturday that ultimately curbed the epidemic spread of the attack worldwide may not have been a kill switch after all, some security experts now believe.

Kevin Mandia, CEO of FireEye, said in an interview today that FireEye found four domains created by the attackers, and that rather than kill switches, the domains appear to be set up for evading virtual machines and sandboxes.

"A kill switch is the least elegant way not to run in a VM. They picked domains that don't exist," Mandia said. "Security tools do this [including FireEye's]: it serves up fictional domains to see the behaviors of the malware running. They didn't want to run the ransomware on VMs, and not have [those victims] pay the ransom."

A UK security researcher who goes by the handle @MalwareTech late last week inadvertently saved the day when he registered a domain whose address he spotted in the WannaCry malware, a move than resulted in a kill switch effect, sinkholing the infected machines that called out to that domain address. A second domain was found and sinkholed earlier this week.

The sinkholing of the two registered WannaCry domains helped dramatically slow the spread of the initial attack, but experts worry that a wave of new variants will continue the spread of the attacks since not all organizations will apply the security updates to Windows to close the flaw WannaCry exploits, nor close open 445 Internet ports for their machines' Windows SMB protocol.

Security researchers from multiple companies, including Google, Kaspersky Lab, and Symantec all have found common code in the WannaCry malware and that of the North Korea nation-state hackers behind the mega breach of Sony, the Lazarus Group.

Fidelis Cybersecurity Services' John Bambenek says it's unclear what the attackers intended with the domain functions. Like Mandia, he also thinks it could be a VM-evasion feature. "It could be used as part of an anti-VM technique," he says. "The intent might have been to use them as a kill switch, in which case they really only needed to register them once they wanted to kill the infection. If I were doing this attack, likely I would have preregistered the domains and only point them to a site once I wanted to shut it down."

He notes that many security sandbox and malware analysis engines string along attackers by resolving DNS requests from infected machines. That way, "the malware will attempt to beacon and communicate, so researchers have richer intelligence to work with," says Bambenek, who is manager of threat intelligence systems at Fidelis.

The attackers could have been attempting that technique. "If you know how DNS should respond in your malware, you can use deviations from that as a defensive measure" in order to evade detection, he says.

In a blog post on Saturday, @MalwareTech recounted his experience of registering the WannaCry domain, and how it ultimately quelled that attack variant. The malware tries to connect to the registered domain: if the connection is unsuccessful, it shakes down the machine for ransom. If it gets a handshake, it "exits" the victim's machine, he said.

He said he now believes the domain was not a kill switch to stop the attack if it got out of control, but instead "a badly thought out anti-analysis" tool.

"I believe they were trying to query an intentionally unregistered domain which would appear registered in certain sandbox environments, then once they see the domain responding, they know they’re in a sandbox [and] the malware exits to prevent further analysis," he wrote. WannaCrypt used one hardcoded domain, so when the researcher registered the domain, "it caused all infections globally to believe they were inside a sandbox and exit…thus we initially unintentionally prevented the spread and and further ransoming of computers infected with this malware."

Meantime, organizations worldwide continue to clean up, patch, and triage infections, as well as worry about another similar attack. The good news was that the attack didn't take down critical infrastructure, or wipe data, for example, experts say.

"It could have been far worse," Mandia said.

Still unknown is the initial attack vector for the ransomware worm. Mandia's theory is that the attackers already had a foothold in a small telecommunications firm, for example, or even a home user infecting his or her organization.

Either way, WannaCry exposed some painful realities, according to Mandia. The SMB propagation method of the worm shows there are more SMB holes in the Internet than there should be, he said. "I would expect 95% of enterprises would be blocking that. It shouldn't have worked" with SMB, he said.

WannaCry also demonstrated how a nation-state (the US National Security Agency) tool could be abused if stolen or leaked like the so-called EternalBlue toolkit was, he noted. "You don't have to be that smart" to pull off this type of attack with access to a nation-state tool, he said.

"It was an indiscriminate attack, so it's going to take a lot of work to figure out who did this," he said.

And there are plenty of targets still in the bullseye: New data from Rapid7's Project Sonar scan today found more than one million Internet-connected devices that expose SMB on port 445, the exact doorway used by WannaCry. Some 800,000 of those ports belong to the Windows environment.

Rapid7 also spotted a major spike in scans for open 445 ports using another of its tools. "MS17-010 will continue to be a vector used by attackers, whether from the WannaCry malware or from something else," blogged Roy Hodgman, senior software engineer for Rapid7.

Related Content:


Kelly Jackson Higgins is Executive Editor at She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/28/2017 | 10:45:04 PM
Re: I don't believe it was anti-sandbox either... it was a self-safety
I'm not sure that it tells us about thier relative sophistication, because we dont have any of their other work to compare it to. I'm also not sure that attrbution of source or skill is a critical factor here. 

As I see this, the area where it is useful is in realizing that if they used some kind of safe switch so it couldnt attack it's creators in the lab, then perhaps the same could be used in our environments to help the defense as well. It would be a trivial matter for any organization to make the noted DNS entry properly resolve to a sinkhole in house, which would be enough to trigger the safey on this malware, and protect the organization, regardless of what happenes with the real DNS entry out in the world (which has been attacked by some jerks that want to bring it down).

Maybe it's useful in these attacks to look for signs and indicators of built in lab safety that may have been in the code and left in, so we can replicate the safeties at the same time we fight the malicious code.
Kelly Jackson Higgins
Kelly Jackson Higgins,
User Rank: Strategist
5/23/2017 | 10:35:32 AM
Re: I don't believe it was anti-sandbox either... it was a self-safety
Interesting, root1657. Does that tell you the attackers are more or less sophisticated than if it were an anti-sandbox measure?
User Rank: Apprentice
5/22/2017 | 12:58:42 AM
I don't believe it was anti-sandbox either... it was a self-safety
I've been reading a lot of analysis, and I think the domain check was a method to prevent self infection (on the part of the threat actor). Doing this would be an effective safety on the weapon in your own evil lab, as you could use a few ficticious domains for this safety check, and have them resolve in house. Bombs and rockets usually dont arm until they are away from the laucher, so why should they design malware any differently?
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
To Click or Not to Click: The Answer Is Easy
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  11/14/2018
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2018-11-14
PRIMX ZoneCentral before 6.1.2236 on Windows sometimes leaks the plaintext of NTFS files. On non-SSD devices, this is limited to a 5-second window and file sizes less than 600 bytes. The effect on SSD devices may be greater.
PUBLISHED: 2018-11-14
Centreon 3.4.x has XSS via the resource name or macro expression of a poller macro.
PUBLISHED: 2018-11-14
Centreon 3.4.x allows SNMP trap SQL Injection.
PUBLISHED: 2018-11-14
CKEditor 4.x before 4.11.0 allows user-assisted XSS involving a source-mode paste.
PUBLISHED: 2018-11-14
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote attackers to crash Asterisk via a specially crafted DNS SRV or NAPTR response, because a buffer size is supposed to match an expanded length but actually matches a compressed lengt...