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

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.

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.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. 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

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.

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?

Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.

Published: 2017-05-09NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.