*** NOTE: UPDATE -- version 2.0 is on the street - new information at the end of this blog! ***
I have used a variety of tools for this blog but I especially want to thank JoeSecurity for access to a complete analysis (https://joesecurity.org/reports/report-db349b97c37d22f5ea1d1841e3c89eb4.html and an excellent blog with deeper analysis at https://www.joesecurity.org/blog/8272382563145970396) in the JoeSandbox tool which provides us with both static and dynamic analysis. I also want to thank AlienVault OTX for the set of crowd-sourced indicators in Figure 1. Finally, there are good analyses at the Malwarebytes blog and the Talos Intelligence blog.
A comment about the OTX indicators... WannaCry was sinkholed recently - by mistake, by all accounts, but a happy mistake for sure - and the current version is dead. However, it was able to be sinkholed due to an error in the WannaCry code's "kill switch".
A researcher going by the name of MalwareTech found that one of the command and control domains was unregistered so he registered it in his own name. WannaCry has a built-in kill switch that knows when it is being sinkholed and it commits malware suicide.
The kill switch is the presence of an unregistered domain. The malware tries to connect to it and if it can't - because there is no route to the domain - it continues with its infection. If it can, it assumes that it has been compromised and it stops the attack. Ergo, no more WannaCry. For now. MalwareTech took advantage of that and the ransomware did the malware equivalent of jumping off a cliff with all other copies/potential infections racing right behind. We'll get a bit deeper into the kill mechanism shortly.
Ransomware that uses the .wcry extension was first reported - as far back as I could find - on 11 February, 2017 on a Tweet by @RemovethreatPC. In March Microsoft issued security updates for the SMB server. CVEs 2017-0143 - 0148 were issued as well. The CVEs address the part of the ransomware that is particularly deadly and a bit unique. Behaving as a worm would, the malware can take advantage of ports 139 and 445 to move laterally through the enterprise.
It is quite likely that the coders will fix the bug and start the game over from scratch. That certainly will mean that hashes we have now are no good going forward and we have no idea about the other indicators, though we can imagine that they will change as well.
Working through the Blockchain we see transactions going to one of the ransomware's bitcoin wallets going back to the 12th of May. As of 13:58 GMT the wallet still was receiving ransom payments. As near as I can tell from the blockchain the attackers have yet to get rich. For three days their haul of about US$33K is interesting but not spectacular, indicating about 19 infections that paid up. In the context of the number of infected machines reported that hardly is impressive.
According to our Recorded Future portal that (May 12th) is when the activity first was recorded. The 13th was the big day and there still was activity on the 14th even though the bug was supposedly dead. Note that this is open source intelligence and reports references to the .wcry file type (as well as all of the names under which the ransomware goes) and is not a number that relates to particular infections.
So, for now - recognising that by the time this is published the ball game may have changed - here is how the bug works and what to do about it. Figure 2 shows The Classification chart from JoeSandbox's analysis.
WannaCry Classification Graph from JoeSandbox
Notice that it's strong points are as an Evader (may bypass the OS and may use anti-reversing) and as Ransomware (AES 2048-bit encryption and Microsoft's Enhanced Cryptographic Provider). However, it lends itself to use in phishing attacks and spyware as well as being a Trojan/Bot.
It also incorporates functionality to delete shadow drive data:
Deletes Shadow Drive Data Process Creation
A file called @WanaDecryptor@.exe (in the sample analysed by JoeSandbox) is downloaded into a subdirectory of C:\ProgramData. In our sample the path was C:\ProgramData\ywepvofkuzu108\@WanaDecryptor@.exe.
There are multiple variants of the ransomware in the wild. For example, our sample did not contain a file called t.wry, a file that was observed by US-CERT. Once the ransomware is decrypted by the loader (t.wry in the US-CERT sample), US-CERT observed that it is loaded into a parent process and it performs the file encryption of the user's files. Because it is running as part of the process the DLL is not exposed to malware scans. The encryption is 2048-bit AES with a random key generated for each target file.
The ransomware checks with the domain that is supposed to be unregistered and, if it is, the infection continues.
HTTP traffic detected: GET / HTTP/1.1Host: www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.comCache-Control: no-cache
Next, it installs TOR:
File created: C:\ProgramData\ywepvofkuzu108\TaskData\Tor\tor.exe
It survives reboots by starting Windows services, creating an autostart registry key and a start menu entry, and saves files to the start menu directory. To ensure persistence, the ransomware drops PE files in the Windows directory, installs a Chrome extension, may possibly modify Windows boot settings, drops visual basic files, creates new files in the system32 directory, starts the executables it dropped into the Windows directory and modifies the Windows boot settings.
Data obfuscation is not sophisticated where it exists at all. WannaCry can dynamically determine API calls, detecting anti-malware and sandboxing, generate new code, likely by unpacking malware, giving the PE files invalid checksums and documenting sections of PE code with non-standard names. It also registers its own exception handler, checks for kernel debuggers and detects other debuggers.
However, you should note that just because it can do these things does not mean that it is actively engaged in obfuscation using all of these techniques. In fact, we found that the API calls are innocuous (and very few were executed) and, although it can detect a virtual machine (often used for sandboxing), there is no indication that it actually applies the detection to evasion or obfuscation. Finally, it is not unusual for software to check for kernel debuggers so this capability, too, does not ensure obfuscation or evasion.
One thing that we expected - assuming anti-malware evasion - was a list of tools that it wanted to avoid. Typically this is checked for in the Registry. We found no such list. Recalling that this is not new ransomware (the core ransomware without the worm spreading capability) and that it was not particularly successful, we begin to see why.
The ransomware spreads by enumerating the files in a directory, creating a COM task schedule object and gathers information about the behaviour of file infection.
On the network side it contacts the following IPs (remember that this relates to the sample run in JoeSandbox... your mileage may vary):
IPs Contacted by our JoeSandbox Sample
Back to the kill switch (recall that if it detects that debuggers or an API it sees as threatening to it, WannaCry could kill itself, but there is no specific indication that it takes advantage of this capability), based upon open source evidence the URL that was registered was:
You can see in Figure 4 that it is one of the IPs contacted by the malware and Figure 5 shows where it is in the behaviour tree:
Initial domain contact in the JoeSandbox behaviour tree
It does not expect this domain to be registered but if it is all infection activity stops. On 12 May 2017 this URL became owned by MalwareTech and began to sinkhole WannaCry. Figure 6 shows this in the JoeSandbox analysis and Figure 7 shows the DNS activity in Cisco's Investigate.
Figure 6 - JoeSandbox http packet activity showing WannaCry querying what it thought was an unregistered domain
Cisco Investigate Whois and DNS activity
Note that the DNS queries started on 12 May where they peaked. Actual first queries were at about 0700 GMT on the 12th. They dropped to zero on 13 May at around 1700.
The ransomware exhibits worm activity in that it can move horizontally through an enterprise. In addition to exploiting SMB (ports 139 and 445) it is looking for machines already compromised with the DOUBLEPULSAR backdoor (https://www.symantec.com/security_response/writeup.jsp?docid=2017-042122-0603-99). Failing that it will use ETERNALBLUE (https://en.wikipedia.org/wiki/EternalBlue -- also an NSA exploit like DOUBLEPULSAR released by ShadowBrokers) to exploit SMB.
Making sure that you have patched all Windows computers, including those back to XP, Vista and 2003, and ensuring that ports 139 and 445 are not open to the outside or, in fact, anywhere that they are not explicitly needed should help you for now. Of course, make sure that your malware scanners are up-to-date.
But, remember, WannaCry is a work-in-progress and we can expect to see a new version of it shortly. There certainly is enough of it in the wild to be reversed by bad guys as well as legitimate researchers such as MalwareTech.
****** UPDATE - 14 May -- The Game's Afoot Again ******
Swati Khandelwal, blogging for The Hacker News, (http://thehackernews.com/2017/05/wannacry-ransomware-cyber-attack.html) on 13 May exposes version 2.0. I won't do more than summarise here and I recommend his blog which is quite interesting.
Now another security researcher has captured a sample and decoded a new kill-switch domain which he registered in the same way as MalwareTech did. This slowed down the infection as one would expect. Pseudo-code as reported by Khandelwal here (courtesy of The Hacker News): figure 8
Checking the new domain (ifferfsodp9ifjaposdfjhgosurijfaewrwergwea.com) in Investigate we see that it went into operation at around 0800 of the 14th. It peaked at about 1,600 DNS queries per hour at 1300 on the 14th. The new variant is the same as the old one but with a new kill-switch domain (so hashes, obviously, will be different from the earlier version).
Be aware - if I haven't said this enough already - that there are two processes (broadly speaking) going on here. One is the ransomware. It is not new and only is moderately wicked. But by itself, it's just ransomware with no special talents. The new wrinkle - and the thing that has made this deadly - is its worm behaviour. The kill-switch effects only the worm behaviour, not the ransomware behaviour. So what we have is an existing, not particularly successful, ransomware stitched to a couple of stolen NSA tool sets. Now it's starting to get interesting again. What makes it interesting is that the old ransomware now has wings and that is not a good thing.
So at the end of the day, certainly, do everything you're reading about - including here - to protect against the worm part, but don't forget that you have to protect against the ransomware too.
Adding to this update are more uncertainties. For example, Costin Raiu, from Kasperski reports that his team is seeing several samples with no network kill-switch. Both Raiu and researcher Matthieu Suiche (who discovered the new kill-switch) agree that the new 2.0 version may the work of someone other than the original coders. There is a possibility that the new stuff is corrupted but that is not an issue to take lightly since it is likely that someone will fix the bugs if there are any.
So, one more time: Patch all of your Windows boxes, disable SMBv1 where you can and make sure your AV is up to date.
Tools Used in This Blog:
Cisco Umbrella Investigate