NotPetya: Good Practices Final Exam

June 27, 2017, 9:45am

Petya has struck and InfoSec Twitter is in full crisis mode. Petya appears to be very sophisticated and I have heard many exploits given for it's methods of spreading and I'm going to touch on each one. I am not here to prove that each one of these things is true about Petya but just going over how each one of these things can be prevented in the future.

Update, June 27, 2017, 10:10am: It is now being called NotPetya by Kapersky who decided it is unrelated. Either way this stuff still applies. 

CVE-2017-0199

I have heard that it is using CVE-2017-0199, which I wrote about here, as an initial entry to networks via email. This has been mentioned once or twice. It bypasses macros in Microsoft Office, but there are patches available and my notes show how to break code execution if you're really paranoid.

Update: Loki, a different ransomware, might be using CVE-2017-0199 and not Petya. Even still...
Update, June 27, 2017, 10:30am: Petya/NotPetya is definitely not using CVE-2017-0199. A different attack happened at the same time causing confusion.

SMBv1 (ETERNALBLUE)

You were warned. And then Wannacry happened. And you still have SMBv1 enabled when you don't need it. Ned Pyle, the project manager in charge of SMB at Microsoft, has been warning you for years to get rid of SMBv1. aka.ms/stopusingsmb1

Update, June 27, 2017, 10:45am: Ned has a list of things that still need SMBv1: aka.ms/stillneedsmb1

WMI/PSEXEC

Okay, this is the one that will be catching a lot of people off guard. What this means is that it is collecting the password hashes of all the accounts on the current machine and then using those to authenticate and move laterally through a network. This is a basic tactic used by active attackers for quite a while, but I have not seen it in malware until now.

This is why I call Petya an exam in good practices. If an administrator has logged into or authenticated to a machine they might leave their credentials in memory, allowing them to be captured and used by this attack. This will give them administrative privileges on all other workstations the infected workstation can connect to if the account it attempts to use has admin privileges on the remote workstation.

Microsoft has a guide for designing a network, and the procedures to accompany that domain design here. Basically Domain Admins only authenticate and get used from special machines with specific users/privileges available and only connect remotely to specified core servers. On end-workstations a combination of Local Administrator Password Solution (LAPS) and using administrative accounts sparingly prevent leaving administrative credentials behind on computers.

LAPS changes the local administrative account's password to something random on each machine and keeps that information in Active Directory for access by admins, which means that if that password is compromised it cannot be used for local administrative access to other machines on the network.

Update, June 27, 2017, 11:15am: I back through the Privileged Access Workstation material from Microsoft to fish out an important table about what types of logons leave your credentials behind. You can read it here.
Update, June 27, 2017, 11:30am: Assuming you have not left Domain Admin credentials behind, you can deploy a policy to stop remote authentication using local administrator accounts. Guide here.
Update, June 27, 2017, 12:45pm: (Not)Petya shares code with Mimicatz, which explains how it is stealing local credentials.

Thoughts

So I made this post because Petya is a perfect example of what I've been trying to prevent in my work at the law firm I'm contracting for. Prevention of lateral movement, and general hardening by removing stuff like SMBv1 and applying all the correct patches in a timely manner. I understand that many organizations might struggle with aspects of this, but they're called best practices because if you can follow them they will serve you the best.

Anyways, that's my hot-take on Petya. Feel free to judge me publicly on Twitter.

Update, June 27, 2017, 10:10am: Design thought: NotPetya's initial targets appear to be unpatched systems, and then it uses dumped credentials to pivot onto patched systems. Clever.