At an industrial security conference this fall, I tried something different. Instead of walking an audience through one famous incident, I put twenty-three on the screen at once, every entry in the first volume of Hackopedia, and asked what they had in common. The answer was striking. The same few failures appeared again and again, and one of them more than any other: attackers moving from the business network toward the plant, or operators shutting the plant down because they feared that they would.
Then I came home and started this volume, and I held that slide to a stricter standard than the one I had used to make it. The pattern survived. It was smaller than I had said. Some of the incidents I had counted rested on reporting that no primary source supports, and I could no longer count them as confirmed.
That is this book in one story. The patterns are real, they are useful, and they deserve better evidence than our industry usually gives them.
Three goals
Hackopedia is a record of cyber incidents that reached, or threatened, the physical world: pipelines, water systems, power grids, factories, ports, and the plants that make what we eat and drink. The first volume covered 23 incidents. This one covers fifty, rebuilt from the ground up, including all 23 from the first volume. I want it to do three things.
The first is to be credible. Operational technology security has a rumor problem. The same incidents get retold at every conference and in every vendor deck, and each retelling sands off a hedge. When American Water disclosed a cybersecurity incident in October 2024, its filings said nothing about ransomware, and they still have not. Three days after the first filing, a security executive told a trade publication, "If I had to speculate, I would say that American Water was potentially the victim of a ransomware event." That was a responsible, double-hedged guess. Forty-eight days later, a vendor blog stated flatly that American Water had been targeted by a ransomware attack, citing nothing. Today it is widely repeated as fact. If you are an engineer deciding what to fix first, or an executive deciding what to fund, you deserve to know which parts of a story are known and which parts are only repeated.
The second is to learn. Fifty incidents is enough to see patterns that no single incident shows, and the patterns are more useful than the headlines.
The third is to help prevent the next one. That is the point of the other two.
What fifty incidents teach
The first lesson is how little is publicly known. The most common answer to "how did they get in?" is that nobody has said. As this volume went to press, in 25 of the 45 incidents with a real victim, no primary source states the way in. We print that silence rather than fill it, because in many entries the silence is the most important fact.
Where the record does speak, three failure modes keep appearing: systems reachable from the internet, or carrying known flaws that were never fixed; credentials that were stolen, reused, left at the factory default, or accepted alone at a remote access gateway; and attackers moving from where they first landed to systems they were never meant to reach.
The third deserves particular attention, and so does its shadow. In many of the most costly incidents in this book, the physical process was never touched. Operations stopped because the business systems the plant depended on were lost, or because the operator shut things down for fear that the attackers would move from the office network to the plant. Colonial Pipeline is the clearest case. A ransom note was found on the company's business network, and the company's own control center stopped a pipeline that, by the company's own figure, carries nearly half of the fuel consumed on the East Coast. Its chief executive told the Senate a month later that Mandiant had not confirmed any evidence that the attackers were in the operational network. The pipeline stopped because nobody could be sure they were not.
That is BlastWave's reading of the pattern rather than a finding stated in any single record, and the entries label it that way. But it is the lesson I would most like readers to take away. Lateral movement, or the fear of it, drives much of the downtime and lost revenue in operational technology. An attacker does not need to reach the controller to stop the plant. They only need the operator to be unable to prove that they could not.
The last lesson is about people. More than once, the save in these stories was made by an operator: a crew that ran a water booster station by hand when its screen stopped making sense, a utility that chose to take its own billing offline on incomplete information to protect its customers. The argument of this book is about architecture, not competence. The people in these entries were mostly doing their jobs well inside designs that gave them too little room. Where an operator acted well, the entry says so plainly.
Why a security company wrote this
BlastWave sells technology that addresses these failure modes, and you should weigh this book knowing that. We have tried to make it useful whether or not you ever buy anything from us. Each entry ends with three recommended controls in priority order, written so that any competent team could apply them with whatever tools it has. They are labeled as our analysis, kept separate from the facts above them, and never written as promises. No architecture ends the risk of attack, and you will not find a promise like that here.
What I believe, and what this book is meant to support, is that the controls that work best do not depend on knowing who the attacker is. In many of these incidents, attribution came late, came hedged, or never came at all. The defenses that would have mattered did not need to wait for it: keep critical systems from answering to the internet, stop letting a password alone open a remote session, and make sure that losing the office network does not mean losing the plant.
How to use this book
The entries are numbered FILE 001 onward across the whole series, not by industry, and grouped into industry editions so that a water engineer or a plant manager can start with their own sector. Each entry stands alone, and cross-references point to related incidents by name.
Hackopedia is also a living record. This online edition carries every source in full, a revision history for each entry, and the podcast and video for each incident, and it is updated when new filings, rulings, or official statements appear. If you find an error or a newer source, write to hackopedia@blastwave.com. We will check it, and if we were wrong, we will say so on the page.
Before the first entry comes Stuxnet. It is not one of the fifty, and the Stuxnet page explains why. I use it to show how this book works: what counts as a source, how to read the colored blocks on every entry, where our first volume fell short, and how to tell what is known from what is only believed. Every entry that follows assumes you have read it.
Cam Cullen
Chief Marketing Officer, BlastWave