Is this Petya, NotPetya, GoldenEye, ExPetr, or PetrWrap?
The Petya outbreak recorded on 27 June 2017 has had a significant impact on a number of global organisations, with media outlets reporting impacts as significant as the cessation of activity at the Port of Rotterdam in the Netherlands [1]. While many may be loath to think back six weeks to the trauma of May’s WannaCry outbreak, there are a number of parallels between the two incidents ranging from the global reach of the outbreak to the techniques by which the malware is spread.
Please note: This is an update to our original analysis posted on June 27, 2017.
Forcepoint Security Labs will continue to refer to this as a Petya outbreak, although other vendors have chosen to apply additional or alternative names to it.
In straightforward terms, the samples analysed have passed the ‘duck test’ https://en.wikipedia.org/wiki/Duck_test) as Petya which has previously been seen to:
- Encrypt files on disk without changing the file extension;
- Forcibly reboot the machine upon infection;
- Encrypt the Master Boot Record on affected machines;
- Present a fake CHKDSK screen as a cover for the encryption process; and
- Present a near identical ransom demand screen after completing its activities.
While the delivery and lateral movement mechanisms in this case are highly unusual, it seems plausible that the underlying ransomware code is a Petya variant attached to a novel propagation method.
Should you pay Petya's ransom demand?
We strongly recommend not paying the ransom. There is no longer a mechanism to give the victim the decryption key for paying the ransom as the email address to communicate with the attacker has been deactivated. The payment mechanism is very weak and is linked to just a single email address, which is no longer accessible. Even if a victim were to pay the ransom into the appropriate BitCoin wallet the attacker now has no means to share the decryption key.
Obtaining unencrypted files is now much more problematic, although decryption tools may soon become available from third parties.
Occasionally a business may decide to pay the ransom demand, but in the case of Petya it is no longer worthwhile.
Infection vector & protection statement
Microsoft has reported that the initial infection vector is currently believed to have been via malicious code masquerading as a legitimate software update. Owing to the inherent trust relationship associated with automatic software updates, this vector is less likely to be detected by perimeter protection.
This is a major departure from how most ransomware propagates: this current iteration of Petya avoids the use of communication vectors secured by web security gateways or email security gateways.
The samples analysed attempt to move laterally within networks by using credentials stolen from victim machines along with a combination of PSEXEC and WMIC commands and by the use of SMBv1 exploits. To date, these samples have not been observed attempting to self-propagate to other organisations, instead confining this behaviour to local networks.
However, movement between trusted networks using stolen administrative credentials valid on both the source and destination networks appears viable. It is not clear at present whether organisations that have a degree of trust between their networks and those of an external organisation (e.g. a managed service provider) are at increased exposure or not.
Overall, the nature of Petya does not come as a great surprise to Forcepoint Security Labs researchers: in October of 2016 Forcepoint Security Labs warned of the perils of rogue software updates being delivered by automated software update mechanisms in our Freeman Report. Showing significant parallels with the initial infection vector used to deliver the Petya ransomware, our Freeman report documented the dangers of a rogue software update to a legitimate code analysis tool.
We recommend vetting third-parties who deliver software updates into your environment and seek to understand what abandoned software (‘abandonware’) may still be running and accepting updates.
As confirmed on 27 June 2017 in the immediate wake of the outbreak, Forcepoint NGFW is capable of both detecting and blocking use of the SMB exploit leveraged by this attack for customers using Forcepoint NGFW within their networks.
If a secondary campaign is launched via a compromised website or malicious email, Forcepoint Web Security and Email security is in position to detect and protect against this new threat.
Posted by Forcepoint Security Labs on June 27, 2017
Déjà vu: Petya ransomware appears with SMB propagation capabilities
The Petya outbreak recorded on 27 June 2017 has had a significant impact on a number of global organisations, with media outlets reporting impacts as significant as the cessation of activity at the Port of Rotterdam in the Netherlands [1].
While many may be loath to think back six weeks to the trauma of May’s WannaCry outbreak, there are a number of parallels between the two incidents ranging from the global reach of the outbreak to the techniques by which the malware is spread.
Analysis
At the time of writing, Forcepoint Security Labs has analysed one sample associated with the outbreak (SHA256: 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745). Details of this are shown in the table below.
We are in the process of confirming an analysing additional samples and variants as they become available.
| SHA1 | 34f917aaba5684fbe56d3c57d48ef2a1aa7cf06d |
|---|---|
| SHA256 | 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745 |
| Timestamp | 2017-06-18 07:14:36 |
| Size | 353.9 KB |
The sample itself is a DLL file, launched with the hard-coded parameter ‘#1’.
Upon execution, it attempts to spread via an SMBv1 exploit before ultimately rebooting the machine, presenting a faked ‘CHKDSK’ screen, and showing the ransom message. The reboot and subsequent messages are typical of previously observed Petya behaviour.
Comment: As in the early stages of the WannaCry infection, the initial infection vector for a given organisation is unclear.
Comment: There appears to be a significant delay between running the malware and the beginning of the encryption process. Given that the malware reboots the machine, this is almost certainly to allow a reasonable amount of time to propagate across networks.
A large number of strings are hard-coded within the file, including the Bitcoin wallet used for payments, the ‘support’ email address used by the perpetrators, and the targeted file extensions. The targeted file extensions are shown below.
.3ds .7z .accdb .ai .asp .aspx .avhd .back .bak .c .cfg .conf .cpp .cs .ctl .dbf .disk .djvu .doc .docx .dwg .eml .fdb .gz .h .hdd .kdbx .mail .mdb .msg .nrg .ora .ost .ova .ovf .pdf .php .pmf .ppt .pptx .pst .pvi .py .pyc .rar .rtf .sln .sql .tar .vbox .vbs .vcb .vdi .vfd .vmc .vmdk .vmsd .vmx .vsdx .vsv .work .xls .xlsx .xvd .zip
Comment: In a further echo of WannaCry, the use of a single hard-coded BitCoin wallet for the receipt of payments is an unusual choice in that it allows easy third-party tracking of the number of ransom payments received [2].
Conclusion & recommendations
Conclusions and assessments of any far-reaching implications of an outbreak can be hard to draw early in a campaign, however it seems unlikely that this will be the last attempt to deploy a self-propagating piece of ransomware.
As ever, Forcepoint Security Labs will continue to monitor this threat.
The use of an SMBv1-based exploit to move laterally within networks ultimately means that a large number of recommendations made during the WannaCry outbreak are also applicable now. In particular:
- Ensure that available security updates are installed on all Windows machines within the organisation.
- In line with Microsoft's guidance from 2016 [3], customers should consider disabling SMBv1 on all Windows systems [4] where this will not negatively impact the function of legacy systems within the environment. If you are a Forcepoint customer please consult the following Knowledge Base Article to identify what course of action may be suitable for your product: https://support.forcepoint.com/KBArticle?id=000012832
Update: We have confirmed through internal testing that Forcepoint NGFW is capable of both detecting and blocking use of the SMB exploit leveraged by this attack (see image), however the initial vector used for propagation is still being investigated.
References
[1] http://www.ad.nl/rotterdam/grote-hack-bij-maersk-legt-rotterdamse-containerterminal-plat~a60dd307/
[2] https://blockchain.info/address/1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX
[3] https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
