WannaCry post-outbreak analysis

Many of the technical aspects of the WannaCry ransomworm outbreak on Friday 12 May 2017 are well documented by this point: the primary means by which the malware spread appears to have been the use of the DoublePulsar and EternalBlue code released by the Shadow Brokers earlier this year and patched as part of Microsoft's MS17-010 update on 14 March 2017.

As we noted in our initial blog post on the topic (https://blogs.forcepoint.com/security-labs/wannacry-ransomware-worm-targets-unpatched-systems), WannaCry's ability to self-propagate marks something of a watershed moment in the evolution of ransomware. Whereas previous variants have relied on social engineering tactics to infect users (e.g. e-mail campaigns with malicious URLs or attachments), once WannaCry started to spread it had the capacity to affect users without any need for human intervention, often resulting in an office full of machines displaying the now-familiar ransom demand window. In this post we will examine the malware's self-propagation capabilities in further detail.

Forcepoint NGFW first provided protection against the exploit now known as EternalBlue as part of dynamic update 105, released 9 May 2007, under the signature name 'SMB-TCP_CHS-Windows-Server-Message-Block-Vulnerability'.

EternalBlue attacks detected by Forcepoint NGFW

Propagation

The malware sample analysed follows the basic steps shown below when infecting a new system:

Of note is that the worm functionality is only activated when the malware is started in service mode (i.e. with two or more arguments):

Once running in worm mode, it creates parallel threads to propagate both on the internal network and to external IP addresses.

Internal Propagation

The malware calls GetAdaptersInfo to identify the local 'seed IP' based on the current IP and subnet mask. It then creates a number of additional threads to scan the IP addresses for the availability of port 445/TCP. If this port is found to be open, it attempts to use the EternalBlue exploit, waiting ten minutes to see if the exploitation attempt has succeeded. If the thread times out, it terminates and a new one is created to try the next address.

If after the first EternalBlue attempt the presence of the DoublePulsar backdoor is detected, the malware will attempt to use this instead. Otherwise, further EternalBlue attempts will be made.

In the sample analysed, the number of internal propagation threads was capped at ten (see image below). After the initial ten threads are spawned, the malware will sleep until one of those threads terminates before attempting to spread to another address.

External Propagation

Attempts to propagate externally occur concurrently with the internal propagation attempts, but in a slightly different manner. For the purposes of spreading to IP addresses external to the organisation, the malware creates 128 threads, one-by-one, each two seconds apart. These threads employ an IP generation function using srand() - seeded with the current thread ID, time, and tick count - and random() to generate a /24 subnet to scan (see image below). If an open SMB port is found, a new thread is started calling the same EternalBlue /DoublePulsar exploit function as used internally but with a sixty minute timeout.

Implications

Comment: A significant implication of this method of propagation is that the malware requires a 'bridgehead' into the network with a routable IP address. As few organisations assign routable addresses to their workstations, it seems highly likely that the bridgehead machine in most cases would have been a server of some sort exposing SMB services to the Internet. The malware's use of the DoublePulsar backdoor may also suggest that a degree of 'piggy-backing' was involved: organisations already compromised by earlier activity - e.g. the cryptocurrency mining botnet discovered only as a result of the WannaCry outbreak [1] - will potentially have been infiltrated via this pre-existing backdoor.

That each instance of the worm functionality spawns threads scanning a total of 128 external subnets goes a long way to accounting for the rapid spread of the malware: in organisations where large numbers of workstations were affected and where permissive firewall policies were in place, it appears that every one of these infected machines may have been trying to infect up to 128 routable /24 subnets a piece.

Protection statement

Forcepoint customers are protected against this threat via NGFW at the following stages of attack:

Stage Four (Exploit Kit) - The EternalBlue exploit attempts are blocked.

Conclusion

As of the time of writing, the reported rate of infections appears to have subsided significantly. Furthermore, much feared 'round two' variants have either not materialised or failed to have the same impact as the Friday's initial outbreak. Nonetheless, what are presumably ransom payments continue to trickle into the three hard-coded Bitcoin wallets used by the campaign: totalled up, the three wallets contained approximately BTC 32.5 (USD $55,000 approx.) late on Monday 15 May 2017 and this figure has risen to BTC 39.0 (USD $68,000 approx.) as of 12:00 UTC on Tuesday 16 May 2017.

Comment: For a campaign with such significant and global reach the financial returns for the actors are relatively low. Figures obtained from the Bitcoin wallets used suggest that fewer than 200 ransom demands have been paid out of over 200 000 machines reportedly affected [2]. The amount contained in the Bitcoin wallets is, of course, also related to the ransom amount demanded by the attackers, with a USD $300 ransom appearing very low compared to recent campaigns observed demanding over ten times this amount [3].

Perhaps the most striking potential outcome of this campaign is the damage it has likely done to other malicious actors wishing to capitalise on organisations who had yet to respond to the exploits published by the Shadow Brokers earlier this year: while other campaigns also used the EternalBlue exploit, they managed to do so while keeping a low profile. The intensely high profile nature of this attack will likely see much of the EternalBlue attack surface - which malicious actors were no doubt hoping would remain available for as long as possible - closed sooner rather than later.