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?
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
6 Reasons Why Employees Violate Security Policies
Ericka Chickowski, Contributing Writer, Dark Reading,  10/16/2018
Getting Up to Speed with "Always-On SSL"
Tim Callan, Senior Fellow, Comodo CA,  10/18/2018
Register for Dark Reading Newsletters
White Papers
Latest Comment: Too funny!
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
PUBLISHED: 2018-10-16
Z-BlogPHP (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.