Wcry ransomware – Additional analysis

Introduction
Since May 12, a large number of organisations has fallen victim to the “wcry” (or “Wanacry”) ransomware, which abuses the SMB exploits / vulnerabilities that were famously released in the Shadow Brokers data dump in April 2017. Our aim in this short blog post is not to repeat existing information, but communicate some additional information that was derived by our NVISO CERT.

Note that our analysis is still ongoing and we will update our post with additional information, our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be.

In short, the ransomware appears to initially enter the environment by traditional phishing (or via systems exposing SMB to the Internet), after which it leverages aforementioned SMB RCE (Remote Code Execution) vulnerabilities (MS17-010) to spread in the network like wildfire. The combination of “standard” ransomware with a recent remote code execution exploit make for a very effective attack, which is evidenced by the impact it has caused on a global scale.

On 13 May, it was reported that wcry, before starting its encryption process, attempts to connect to a seemingly random domain name (www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com) (EDIT: On May 15th, a second kill-switch domain was found in a new sample: www[.]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com).

If these domains can be contacted, the malware stops its operations. This is most likely a kill-switch that was built in, but not effectively used, as the domain name had not been registered by the attackers. It has been registered by security researches in the meantime, hindering the ransomware’s advance. Note that the kill-switch is not proxy aware and is thus ineffective in environments where a proxy is used to access the Internet (NVISO’s analyst Didier Stevens published a quick-post on the killswitch here).

For additional background information, the following articles & blog post provide a good description of the observed wcry activity:

• https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/
• https://gist.github.com/rain-1/989428fa5504f378b993ee6efbc0b168
• https://community.sophos.com/kb/en-us/126733
• https://blog.malwarebytes.com/threat-analysis/2017/05/the-worm-that-spreads-wanacrypt0r/ (article about the worm, not the ransomware itself)

The main recommendations to prevent / limit the impact of wcry:

• Ensure Microsoft’s patch (MS17-010) is rolled out throughout your organisation (also in the internal network) to prevent the spread of the malware using the SMB exploit;
• If you cannot install the patch timely, TearSt0pper (developed by Rendition InfoSec) can be deployed to prevent the encryption from taking place;
• Ensure Windows SMB services (typically TCP port 445) are not directly exposed to the Internet;
• Implement network segmentation between different trust zones in the network;
• Ensure recent back-ups are available offline and can be easily restored;
• Upon infection: isolate any infected hosts from the network;
• Continue end-user awareness to prevent the initial compromise through phishing;
• Implement mail sandboxing solutions to block incoming malicious mail attachments.

Additional analysis
Throughout the weekend, our analysts further investigated the attack, noticing only 2 known variants of the “wcry” ransomware were uploaded from Belgium on VirusTotal. Given the global scale of the attack, this is a surprisingly low number of hits.

From an analyst perspective, the malware does not take big efforts to obfuscate itself and a simple static analysis (e.g. looking for strings) comes up with a large number of strings that could be used in YARA rules:

• The ransomware manual language files that are dropped: (*.wnry)
• It uses icacls to change permissions, using the following hard-coded command: “icacls . /grant Everyone:F /T /C /Q“
• Unicode string in the executable “WanaCrypt0r”
• The ransomware creates a Windows registry value to ensure persistence (survival upon reboot). We observed different variants of this behaviour, 2 examples are below:

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v obsbeuqp321″ /t REG_SZ /d “\”C:\WINDOWS\system32\tasksche.exe\”” /f

cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v “mzaiifkxcyb819” /t REG_SZ /d “\”C:\tasksche.exe\”” /f

Note the creation of the “taschsche.exe” executable, which is different from the normal “taschsche.exe” (part of Windows).

Update 1

As stated, on networks where a proxy is the only way to access the Internet (e.g. corporate networks), the killswitch will not work because the code is not proxy aware. This means that the malware will attempt to resolve the killswitch domain name with internal DNS, and if it receives a DNS reply with an IP address, it will proceed with an HTTP request. It will not connect to the proxy.

Corporations are configuring internal DNS with the killswitch domain name and an internal sinkhole as mitigation. This prevents the sample from activating, provided that the sinkhole server sends a reply.

The reply can be a 404, that will work too. It can even be a single character x send via the TCP connection, that is fine too. But something has to be replied, just opening the connection and closing it, without sending anything to the malware, will result in activation of the malware.

FYI: this was tested via dynamic analysis with sample 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec and with our own custom code simulating the killswitch test in the malware.

Our analysis is still ongoing and we will update our post with additional information, as our CERT team is advising NVISO’s customers as we speak. Should you have any questions or require emergency support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or incidents@nviso.be. We would be happy to help!