Under shadowy circumstances, a self-replicating virus with a ransomware payload wreaked havoc across the globe over the weekend. The virus, dubbed WannaCrypt or WCry, is based on what was believed to be a previously unknown exploit, or “zero-day,” code-name EternalBlue by the NSA. The actual operating code for EternalBlue was discovered on an NSA proxy server sometime in 2016 by the hacker group known as Shadow Brokers, and was dumped into public on the internet on April 14.
Where things start to get shadowy is the fact that Microsoft released a patch for the EternalBlue exploit a month earlier, in their March release of patches. The question becomes how did Microsoft know to patch this (and other of the NSA-held exploits) before the exploits were made public? Unraveling the timeline, Shadow Brokers may have inadvertently assisted in this process by their previous dump of the NSA materials in January. In the January 2017 dump, the code names of many of the NSA exploits were shown in file directories even though the actual code in that directory was held back until April. This leads to speculation that the NSA may have given Microsoft a heads-up on EternalBlue in January, and Microsoft got very, very busy.
It’s also speculated that this could be the cause of the unprecedented skip of the February Patch Tuesday release from Microsoft, which hasn’t been adequately explained. Was Microsoft so intent on fixing this exploit that it caused them to release no patches at all for February, pushing out the schedule to March which then included a fix for EternalBlue? It certainly seems plausible.
An interesting side note on WCry: It was disabled by a very alert security researcher in the UK known as MalwareTech (MT). Using the Cisco Umbrella security tool, MT noticed that when WCry was allowed to execute in a sandbox environment, it was reaching out to an unregistered domain. This is a technique that’s commonly used by malware to try to detect when it’s being operated in a security sandbox. In a native environment, contacting an unregistered domain will result in no response, while in a sandbox every query will respond from the same IP address. This is used to detect that the malware is being run in a sandbox, and the exploit will protect itself by not executing further, thus hiding its methodology-the malware authors don’t want their secrets revealed to security researchers.
MT quickly checked the domain name being used, saw it was unregistered and quickly applied for and received the domain. Now, when WCry runs in a native environment, it does get a response when it doesn’t expect one, and shuts itself off. This simple registration of a single domain effectively shut down WCry from any further encryption and ransom cycles. This flaw and another noted bug in the way WCry tries to run code to generate random Bitcoin wallets, but the code is faulty and it reverts to one of 3 hardcoded wallets, suggests that this package was rushed into the market without adequate testing. I wouldn’t take comfort in this, because those bugs are easily fixed and tied into a different exploit package. You can expect to see improved variants of this exploit to appear, probably sooner rather than later.
How can you protect yourself against these attacks? They still often start with tried-and-true phishing attacks, so as always don’t open attachments you’re not expecting, even from people you know. One common exploit technique is to search a compromised system for any and all email addresses, and send an attack email to them with the exploit package attached. Since this email comes from someone who has been in previous contact with the new victim, it’s an attack based on social engineering and taking advantage of a previously trusted relationship. It’s also a good idea to equip yourself with active ransomware prevention, such as offered by Sophos Intercept X. Contact us at INCS to find out more, [email protected] or 704-362-1682 option 1.
