NotPetya and learning the lessons of WannaCry

I recently wrote about my experience working as an IT architect for a Copenhagen-based multinational energy firm during the WannaCry ransomware attacks of May 2017.

I didn’t know it at the time, but WannaCry was only a dress rehearsal for what turned out to be the single most destructive cyberattack of all time, one that would do some of its greatest damage at Maersk, which was less than five kilometers along the waterfront from where I then sat. At the time Maersk was the largest shipping company in the world, responsible for shipping tens of millions of tons of cargo to over 130 countries on nearly 800 vessels. 

When NotPetya first began turning its screens black five years ago, the news reached me as whispers from colleagues. Something major was underway at the shipping giant, which was a customer of my firm. I heard from colleagues, friends, and business associates at Maersk that a cyberattack was underway. 

Details were scarce, so searched online to see if the company had made any statements or if the attack was making the news.  Nothing. On Twitter, I found an employee had tweeted a photo of Maersk employees milling around black screens. I zoomed in. There, on one of the screens, was clearly legible red text on a black background:

“Oops, your important files have been encrypted…

Send $300 in Bitcoin to the following address…” 

After more cursory research, I realized the attack had to be related to Petya: same note, same malware family. If it propagated the same way as WannaCry – if it shared the same attack vector – my company was safe. We’d already addressed the EternalBlue exploit WannaCry used to hop from one device to another. Exhale. I reported to management that we appeared to be safe from whatever was affecting Maersk. 

A lot like ransomware

I was sitting with a software vendor two weeks earlier listening to a description of some interesting technology. An auditor had suggested we should be encrypting data at rest, and now I was hearing about a solution that, with the right privileges and a click of the button, could use Windows Management Instrumentation (WMI) to encrypt all data written to a hard drive at scale. 

Hmm, I thought. That sounds a lot like ransomware. Always trying to think like an attacker, I contacted a colleague in Germany to suggest closing down this capability since it could potentially be used against us, but we decided to first look into who was using it to minimize disruption. 

Establishing a kill chain

By now, more information was circulating on the internet. Researchers were investigating and sharing information about the malware’s code, behavior, and attack vectors. They discovered that, though the variant was similar to a piece of malware called Petya first seen in 2016, it was not in fact that variant. It was christened, creatively, NotPetya. 

I knew from experience that stopping the initial compromise was too difficult, so I considered how I could limit the blast radius. This new piece of apparent ransomware could propagate via a different attack vector: WMI. If it discovered the SMB vulnerability had been patched, it would target the same function used by the legitimate capability my vendor was looking to sell me on. Contrary to the widespread belief that Maersk was infected after failing to patch the same vulnerability EternalBlue exploited, NotPetya was a different animal altogether. My team and I had finished disabling WMI by that evening.

NotPetya also made use of a widely known tool designed by a French researcher and dubbed “Mimikatz.” Mimikatz took advantage of an intentional Windows function to retrieve plaintext passwords stored in memory. Once armed with an admin password, the malware could propagate using a legitimate connection. It wasn’t, it turned out, a vulnerability at all. Aside from credential theft, everything else was on the level. 

NotPetya also relied on all admin passwords across a network being the same to spread. Again, I phoned an associate in Germany and asked if that was the case with our network. No, he told me, we employed a tool that managed a unique admin password for each endpoint. We’d dead-ended NotPetya once again. 

The lesson for IT admins here is that it wasn’t a single point of failure that allowed NotPetya to wreak the havoc it did. For it to spread successfully, it needed:

1. Either an open SMB port on an unpatched device
2. Or enabled WMI functionality
3. And for endpoints using the network to share the same admin password

If these conditions were not met, the NotPetya kill chain was broken. 

A fate worse than ransomware?

NotPetya, it turned out, was also not ransomware. The note was a ruse. There was never meant to be any way to recover encrypted data. The industry would come to call it “destructionware.” 

Destructionware makes little sense from the point of view of the financially-motivated cybercriminal. But that wasn’t who was behind the NotPetya attacks. Analysts would eventually discover that a shadowy group of state-backed actors known as Sandworm was responsible for unleashing it on the world. Russia was already in a hot war with Ukraine, and many saw NotPetya as an act of cyberwar.

Beyond paralyzing one of the world’s largest shipping magnates, the worm quickly spilled over and spread "from hospitals in Pennsylvania to a chocolate factory in Tasmania." Damages reportedly exceeded $10 billion. It sparked lawsuits over the ultimate responsibility of issues of ransomware insurance where “acts of war” are concerned.

Zero trust, zero attack surface

Both WannaCry and NotPetya took advantage of remote code execution (RCE) vulnerabilities to gain a foothold on the network and spread across devices. It seemed obvious to wonder what RCE might be next, and the likely candidate involved vulnerabilities with Microsoft’s Remote Desktop Protocol (RDP).

But whereas shutting down SMB was relatively painless – only a few admins used it at all – hundreds of admins used RDP to access every server and every client machine. Shutting it down would require a massive reeducation effort and a shift in our operating model. I decided it was worth the effort to pursue eliminating such a glaring section of our attack surface. 

If WannaCry showed the importance of reducing the attack surface wherever possible, NotPetya drove home the necessity of eliminating it altogether. Short of that, there would always be a new RCE to exploit. The next zero day would always be right around the corner. I could tolerate a compromised endpoint or even a little data loss. But this wave just went to show that massive, network-wide attacks were the focus for well-resourced cybercriminals. 

Zero trust was the only logical way I could see to stop those attacks. Though it wasn’t easy, the potential doomsday scenario my managers and colleagues had just witnessed made accepting change easier. We broke things. We reduced the attacked surface. While it was an adjustment, it wasn’t worse than the alternative experienced by so many victims of NotPetya. 

For me, WannaCry's lesson was driven home by NotPetya: we must embrace change and calculate controlled risk if we are to limit the damage from uncontrollable disasters. 

What to read next

In the aftermath of WannaCry, our concept of the network has to change

WannaCry five years on: Revisiting my revelation