Ransomware? Wiper? by James Lerud
Petya? Petya 2.0? NotPetya? Petwrap? Goldeneye? Nyetya? Expetr? FamilyTimeKiller? …Ok, I made that last one up.
In case you aren’t fully caught up yet, the consensus around the security community is that Petya was a politically motivated attack targeted at Ukraine. The initial vector of infection was malware masquerading as an update to MeDoc accounting software. MeDoc is a tax reporting software specifically for companies that do business in Ukraine. This along with the fact that the “ransomware” makes a weak attempt at collecting ransom, has no decryption capability and required the attacker to compromise a very specific software vendor, led to the consensus. What does this have to do with WannaCry? The short answer is not much. Once a system is infected with Petya, the malware attempts to spread laterally in a few ways: 1) It harvests credentials and access tokens from memory similar to Mimikatz 2) Attempts to spread via WMI with harvested credentials 3) Attempts to spread via psexec with harvested credentials. 4) Attempts to spread via EternalBlue 5) Attempts to spread via EternalRomance. The only thing it has in common with WannaCry is that it can spread via EternalBlue and that it encrypts files. Unless your organization uses MeDoc software, you can breathe a sigh of relief. After that sigh, it’s time to think about lessons learned. What could you do to prepare for a future scenario where the malicious update is targeting you via a software update? Here are a few Ideas…
- If you haven’t already applied MS17-010 please stop reading and go do that.
- Test if your defenses would catch or block the modified/similar version of Mimikatz used by Petya to gather credentials.
- Know what software and versions are in use in your organization and how they update. Ideally, you should be testing updates in a lab environment before wide-scale production deployment
- Hunt for outliers, the malicious update was about 300kb in contrast to typical update size of 300 bytes.
- Limit remote management permissions to specific accounts and originating addresses.
- Determine if you are inspecting files transferred via SMB, how good is your inspection? Can you limit file transfers in any way such as by hash or signature?
- Consider if your application whitelisting policy could be tweaked to block Petya.
- Consider creating a response plan to lock down your network, or network segments, at the expense of usability temporarily. When and how you initiate the plan should be carefully considered and rehearsed
About Verodin
Verodin is the first business platform to measure, manage and improve cybersecurity effectiveness.
The Verodin Security Instrumentation Platform (SIP) enables organizations to understand and communicate cybersecurity effectiveness with quantifiable, evidence-based data. By demonstrating the impact of modern threats and malicious activities within the context of your environment, Verodin SIP proves the effectiveness of your investments, proactively identifies configuration issues in your security stack and exposes true gaps across your people, processes, and technology. Verodin provides clarity on what a threat means for you and empowers you to drive decisions and priorities with empirical data. Verodin dramatically increases the ROI of existing and future security investments and quantifiably measures if security posture is improving or regressing over time.
Learn more at verodin.com
- Malicious File Transfer: What You Need To Know About an Attacker’s Methods and Techniques To Protect Your Organization From Malware by Ursula Cowan
- Verodin LATAM Party (Porto Alegre Brazil) by Brian Contos
- Policy Evasion: Evasive Techniques You Need to Understand to Prevent Breaches and Attacks by Major General Earl Matthews USAF (Ret)
*** This is a Security Bloggers Network syndicated blog from Verodin Blog authored by Verodin Blog. Read the original post at: https://www.verodin.com/post/ransomware-wiper
