It could have happened to us...Frank Breedijk
There, I said it. We could just as easily have been a victim of NotPetya as any of the poor folks that did get hit. And what about you? We have listed some questions for you to consider at the end of this blog.
Our CSIRT team did a post-incident analysis, a common practise at Schuberg Philis with regards to major incidents. Besides the usual questions like: ‘What damages did we incur?’ (none) and ‘How did we act’, we also tried to find out; ‘Was this just luck or skill?’ and; ‘What would have happened to us if we would have hosted a M.E.Docs system?’
NotPetya was different
NotPetya used a similar technique as WannaCry for lateral movement, but in many aspects, it was completely different. In a way, NotPetya was a perfect example of a so called ‘Blended threat’.
Initial infection (the way the first node got infected) used a supply chain attack. Somebody managed to compromise the update system of M.E.Docs and package their malicious code into a legitimate update, signed by the vendor. When the victims downloaded and installed these updates, they got a little more than they bargained for and, since the signatures where completely valid, they had no reason to assume that they installed anything but a legitimate update.
We know that most likely the bad guys had backdoor access to these affected systems for some time, before they released the ‘ransomware worm-stage' of their attack.
The worm part of NotPetya consisted of a combination of several attack techniques. Obviously NotPetya used the same EternalBlue attack that we also witnessed in WannaCry, but it also used more clever attacks. First of all, it used a technique also used in the Mimikatz tool to dump recently used credentials from memory. These credentials were then used to attack other systems via the built-in Windows Management Instrumentation (WMI) tools or, if WMI could not be found, via PSExec which was built into NotPetya.
The encryption/scrambling of the hard drive itself also contained a social engineering aspect. The system was first brought down by causing a blue screen of death (BSoD) error condition, followed by a screen that looked as if the system was checking its hard drive for errors and a notice to deter users from powering off the system.
Why we could have been hit
First and foremost, we could have been hit because we currently do not have any mechanisms to detect malicious updates, other than checking vendor supplied signatures. We are getting pretty used to regularly updating our systems, but if those updates themselves cannot be trusted, all bets are off.
Secondly, apart from limiting administrative privileges as much as possible, we did not take a lot of measures to prevent the memory scraping built into Mimikatz and NotPetya.
Thirdly, while we did patch against EternalBlue, WMI and PSExec are tools using the regular built-in capabilities of Windows. No amount of patching would have worked against abusing them.
Are we doomed?
No, we are not doomed, but NotPetya has given us an insight into how sophisticated attacks are getting and that attacks in the future are going to get even more advanced. We suggest that you run the same exercise as we did.
Ask yourself the question: ‘What would have happened if we had been a M.E.Doc user?’
Don’t forget to consider the following:
- How was our incident coordination, can we act fast enough, can we act effectively, did we panic, could we prevent panic?
- Do we still need to have SMBv1 active, have we limited administrative privileges to those that need it, do we have one common local administrator password or is it limited to single systems?
- What can we do to protect the master boot record?
- How are different zones in the network isolated, can domain controllers be used to hop across zones?
Good luck, sometimes you have to take it over skill.