WannaCry five years on: Revisiting my revelation
May 11, 2022
Five years ago, on Friday, May 12th, 2017, I had an epiphany.
Back then, I was an IT architect in Copenhagen for a large multinational energy company. I was working from home when the WannaCry ransomware variant, which weaponized a stolen NSA exploit known as EternalBlue, began its vicious rampage through hundreds of thousands of devices in more than 150 countries.
According to Andy Greenberg, the journalist who wrote the definitive account of the events, although the ransomware variant generated less than $200,000 in revenue for its authors, it inflicted losses into the billions of dollars. It closed hospitals in Great Britain, banks in Russia, a German railway, and a Spanish telecom before a researcher named Marcus Hutchins discovered its kill switch. It shook the world’s understanding of its cybersecurity in only a few hours.
It also changed the way I thought about network security forever.
My first indication that something big was happening came when I received a breaking news alert from the BBC saying Britain’s National Health Service (NHS) had suffered a major cyberattack. I curiously investigated the news and learned that far more than the NHS had been affected.
I wondered if and how my company might have been exposed. I thought of my network. Should I call in my team?
I soon discovered the malware was propagating via the server message block (SMB) protocol, an essential method for connecting users to files stored on clients and servers. If a single device was infected with the malware variant, it would quickly spread across my entire, flat network.
Now, on that particular sunny Friday evening in Copenhagen, I was connecting to the office from my home via the Zscaler Client Connector. I was actively using the platform when I began to consider the extent of my own exposure to this new malware variant. It dawned on me that I didn’t have an IP address on the network. I wasn’t using a VPN. I had no attack surface.
That’s when it hit me. For my entire career, we’d been taught that the place we were safest from cyberattacks was on the network or using a VPN, behind the castle walls – firewalls. Now, as I considered my own exposure, I realized that I was completely safe from its impact. Those we thought were the safest – those on the corporate network – were actually most in danger of infection and spreading the malware.
What have we done, I wondered?
Mitigating against misplaced trust
As architects, I began to feel that we’d failed in designing secure networks that protect users. Instead, we’d designed a structure that allowed one bad egg to spoil them all. Implicit trust, I suddenly saw, had created a huge risk. But I couldn’t allow myself to stew for too long. I had an unfolding attack to mitigate.
With my CIO’s sign-off, I began by denying any connections to the client SMB service. This relatively easy procedure left the average user unaffected. We were able to quickly push the policy out globally to tens of thousands of devices, effectively removing the attack surface from endpoints and taking devices dark.
I’d thought I found a satisfying solution until I began getting complaints from colleagues in operations. They often used the SMB protocol to connect to devices for collecting logs or using Microsoft’s Configuration Manager (SCCM) to deploy software.
Then came the second part of my epiphany. Call it a corollary to the first: I realized the same technology I was using to connect to business applications from my home while preventing lateral movement could be extended to all on-premise admins. I recognized the potential it held for securing users, preventing lateral movement, and minimizing our attack surface.
(Here I have a confession to make: Soon after the WannaCry outbreak, I anonymously remarked about my experience with Zscaler leadership under the pseudonym of “Tom” while still a customer. I am Tom!)
Learning to prevent the next WannaCry
My company was spared from the damage caused by Wannacry.
But for the remainder of my time there, we focused on reducing our attack surface. We closed down unnecessary systems and ports. We took endpoints and workloads dark. We established KPIs to track our progress in this respect, reasoning that the lower the attack surface the lower the risk. We were moving toward establishing zero attack surface, removing endpoints from the corporate network completely.
When the attacks struck, we didn’t have zero trust deployed throughout the organization. It was being evaluated as a potential solution for remote users and OT devices. But WannaCry, and the realizations that came with it, helped spur greater adoption of zero trust principles. It unfolded like a devastating, real-world proof-of-concept that eventually led to company-wide implementation.
The WannaCry ransomware variant is still with us today. According to reports, incidents involving it increased by 53% in early 2021. On the other hand, most corporate networks continue to follow the same flat design they have for decades. VPNs, many of which are dressed up by their vendors as zero trust solutions, are still endangering organizational cybersecurity in many of the same ways as in 2017.
It’s encouraging that, by most accounts, zero trust adoption is surging. But, by and large, we missed the wake-up call. We certainly didn’t learn the lessons of WannaCry in time for NotPetya and, five years on, it’s still unacceptably common to have users on-network and apps not segmented.
Since life’s most important teachings are often borne from the most difficult experiences, we'd do well to internalize past lessons to avoid future pain. The clock is ticking...
What to read next