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.
[su_box title=”About Forcepoint” style=”noise” box_color=”#336588″][short_info id=’96851′ desc=”true” all=”false”][/su_box]
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.