Ever wondered how ransomware spreads? We have! In fact, at Alert Logic we focus on understanding these underlying details as it helps businesses to better prepare for and detect threats on their networks.
In a recent blog post, we talked about the outbreak of the PetrWrap ransomware campaign, which wreaked havoc across the world in June 2017. The malware was seen to compromise a number of high-profile victims such as WPP in the UK, Merck in the US, and Maersk in Denmark. Exact details on how the ransomware spread to initially infect these customers are sparse, but the indications are in the exploitation of an uncommon Ukrainian accounting software called MEDocs.
Once PetrWrap has infected a system in the target environment, the ransomware operates like a worm and attempts to spread itself automatically to nearby hosts, or even sometimes back out to the open internet. This can cause a cascade of infections within the original victim organization, but may even allow a victim to propagate the malware to other victims across the wider internet.
Victims as Pawns
The exploits and network traversal techniques which PetrWrap performs in order to move laterally (or outside of the network) have been outlined by us in the earlier blog post on the topic, but we have been digging deeper in the quest to better understand this emergent ransomware strain. One outcome from this analysis has been reconfirmation of Alert Logic’s coverage against the most damaging vectors which are used to spread the infection, as well as the specific order in which lateral movement occurs. In order of preference the ransomware attempts to connect to the following destinations:
- “127.0.0.1″
- “localhost”
- $ComputerName
- $AllLocalIPs
- $DHCPServer (if local ip via DHCP )
- $DHCPClients ( If local is DomainController )
- $AllLocalNetRanges
- $AllConnectedHosts
- $HostsInArpTable
- $AllKnownServers ( via NetServerEnum )
The interesting part about this order is the use of $AllConnectedHosts where the current connections of the host are determined via a Windows API call to GetExtendedTcpTable (programmatically like netstat -a). This is different from the next item in the list $HostsInArpTable which uses the GetIpNetTable API. What makes the call to GetExtendedTcpTable interesting is that it provides a list of all currently open connections from the host, which the ransomware then targets. So, for example, if the victim host happened to be browsing www.alertlogic.com at the time the ransomware made the API call, then the ransomware would consider www.alertlogic.com as a valid target and attempt to propagate to that destination. If that target happened to be vulnerable to any of the exploits used by the ransomware then it would jump and infect an entirely new victim rather than move laterally. This appears to be why, in some instances, folks are reporting an intermittent experience of PetrWrap infecting the open internet, whereas some others aren’t seeing the same behavior . This largely confirms discoveries made by Esentire, but there remains another twist in the tale.
When attempting to propagate on Windows versions past version 6.2 (Windows 8 and Windows Server 2012 for example), in addition to regular propagation vectors the worm makes a change to the SrvAdminAllowAnnonymousAccess API. By patching the value of the _SrvAdminNullSessionPipePermitted flag in memory via this API, the worm enables anonymous access to named pipes (called null sessions). This downgrades the security posture of the victim host by making it possible for unauthenticated external actors to gain unrestricted access to the host.
Figure 1. Subroutine enables anonymous access to named pipes
Microsoft expressly recommend against setting this flag via TechNet and in the context of this ransomware it increases the ability of an external actor (ransomware owner or not) to be able to manually gain access to the victim. This could lead to further persistence and malicious activity on the host, in addition to the documented capabilities of the worm itself.
FAT chance: Recovering Infected PetrWrap Victims
With a focus on SMB and particularly EternalBlue from the April 2017 Shadow Brokers release as a first lateral movement vector, it comes as no surprise that PetrWrap has a particular taste for Windows systems. However, it doesn’t treat all windows file systems equally, with interesting results. The code appears to concentrate on effectively detonating and encrypting data specifically on NTFS, the most common windows file system. Were a victim to use a different file system though, in our example case FAT32, the ransomware tries and fails to detonate effectively and the data is almost immediately recoverable.
Upon execution on a non-NTFS file system the ransomware modifies the system Master Boot Record (MBR). The MBR contains the information on how the file system is organized, and ultimately how the file system can be accessed and how the operating system is loaded. If the MBR is broken or corrupted in some way, then the host can’t boot into the operating system.
However, the ransomware hasn’t erased the MBR or destroyed it completely. Instead, it stores an XOR’d copy of the original MBR further on in the disk space, specifically at sector 0x22 (linear offset 0x4400). Once this has occurred, a scheduled task forces a reboot of the host and when the host powers on again it checks whether the ‘Encryption state’ flag has been set by the ransomware. This flag is positioned at offset 0x4000 and if it is set to 0x00 (which it is now because the ransomware has set that section by modifying the MBR) then the standard PetrWrap chkdsk and encryption routine runs.
When operating on a FAT file system this encryption routine fails to find the FILE markers indicative of an NTFS partition and exits, but not before setting the ‘Encryption state’ flag back to 0x01. After a second reboot, this encryption flag is checked again due to normal operation, but now it reads 0x01 instead of the 0x00 the first time the routine ran.
As a result, PetrWrap presumes that encryption has been successful, when in reality only the MBR modification and XOR has been completed. Of course, as it currently stands the host remains unusable, and will get no further in the boot process than the ransomware message, but the MBR can be recovered directly by a (relatively) simple operation.
First the host needs to be powered down and the XOR’d MBR copied from sector 0x22 (linear offset 0x4400) over sector 0 on the same disk. Then XOR these 512 bytes with the byte 0x07 and hey presto, this will recover the original MBR! With a now working MBR, the system should boot successfully.
Figure 2. A quick look on Shodan shows that the number of potential targets, a month on from initial news coverage, remains huge.
Finally, standard ransomware remediation should be performed to sanitize the system, otherwise the next time you reboot your non-NTFS host you might find you have to go through the whole process again. Organizations not only need to look at monitoring for the signs of systems excessively reaching out to servers and internet sites, but also look to identify what they expose to the internet and consider if it is required. If it isn’t required, reduce your attack surface area ASAP.
