WHAT COULD HAPPEN IN AN OT CYBER ATTACK
From first access to physical consequence — the timeline no one wants to see unfold.
Cyber attacks on industrial environments are not abstract events. They follow predictable progressions, they exploit specific configuration and process weaknesses, and they produce consequences that range from production loss to safety incidents. Understanding what actually happens — step by step — is the foundation of effective defence.
Why OT Attacks Are Different From IT Attacks
The fundamental distinction between an IT cyber attack and an OT cyber attack is consequence. An IT attack that encrypts business data causes financial loss, reputational damage, and operational disruption — all serious, but recoverable. An OT cyber attack that manipulates an industrial control system can cause consequences that are physical, irreversible, and potentially life-threatening: a chemical plant releasing a toxic substance, a power grid destabilising, a water treatment system delivering contaminated water, or a high-pressure pipeline rupturing.
This is not hypothetical. CRASHOVERRIDE cut power to approximately 200,000 homes in Ukraine in 2016. The TRITON malware targeted the Safety Instrumented System at a petrochemical facility — the last line of automated defence against a catastrophic process incident. The Oldsmar water treatment attack attempted to increase the concentration of sodium hydroxide in the water supply to a level that could cause serious harm to consumers.
Understanding the realistic progression of an OT cyber attack — what an adversary does, in what order, and why — is not an exercise in fear. It is the prerequisite for building defences that can actually interrupt that progression before consequences become irreversible.
The average dwell time for an adversary in an OT environment before detection is measured in months, not days. Adversaries conducting pre-positioning campaigns — like Volt Typhoon — may maintain persistent access for years while waiting for the right operational or geopolitical moment to act.
The OT Kill Chain: Stage by Stage
The adversary gains their first foothold. Common vectors include spear-phishing targeting IT staff with OT access, exploitation of an internet-exposed remote access interface, compromise of a vendor or integrator with OT network access, or a supply chain-compromised software or firmware update. At this stage, the adversary may be in IT systems only, with OT as a future objective.
The adversary maps the environment: network topology, asset types, firmware versions, communication protocols, and the relationship between control system components and physical processes. This phase can last weeks or months and leaves minimal trace if not specifically monitored for. The adversary is learning how the facility works before they touch anything that matters.
The adversary moves from IT systems toward OT, exploiting weak segmentation, dual-homed historian servers, compromised vendor credentials, or a jump host with OT network access. Once in the OT environment, the adversary repeats discovery to understand which assets control which physical processes and how to manipulate them.
For sophisticated attacks, the adversary develops or deploys malware or scripts tailored to the target environment — specific PLC models, specific process conditions, specific safety system configurations. CRASHOVERRIDE and TRITON were purpose-built for their targets. Less sophisticated attacks use readily available tools and living-off-the-land techniques. The adversary waits for the optimal moment.
The adversary executes their objective: disrupting a process, causing physical damage, triggering a safety incident, exfiltrating process data, or establishing persistent access for future use. The action may be immediate and visible — ransomware that locks HMIs — or slow and subtle: gradual manipulation of process setpoints that will only produce a consequence when conditions are exactly right.
Three OT Attack Scenarios and Their Operational Consequences
Scenario one: A ransomware operator compromises an engineering workstation via a phishing email targeting an engineer who also uses their workstation for business email. The ransomware encrypts the engineering workstation and spreads to the historian server. The HMI loses its connection to the historian. Operators lose trend visibility and switch to manual operation. The ransomware operator demands payment. Even if OT devices themselves are unaffected, the facility may operate in a degraded, higher-risk state for days while recovery proceeds — and the manual operation period itself introduces safety risk.
Scenario two: A state-sponsored actor pre-positions in an energy utility's IT network for eight months, using valid credentials obtained through a supply chain compromise. During this period, they map the OT network, identify the specific RTUs controlling substation switching, and develop a script that can issue rapid open-close commands that will damage transformer equipment. On a cold winter evening, they execute. Multiple substations lose power. Recovery requires physical transformer replacement — a process measured in weeks, not hours.
Scenario three: An insider — a disgruntled contractor with retained access credentials — connects remotely to a water treatment facility's SCADA system and increases the dosing setpoints for a treatment chemical to dangerous levels. The change is subtle enough that automated alarms, set to detect rapid changes, do not trigger. The manipulation is only discovered when a field operator notices an unexpected consumption pattern in the chemical storage tank three days later — after treated water has already been distributed.
The Conditions That Allow Attacks to Progress to Consequence
OT attacks do not succeed because adversaries are unstoppable. They succeed because specific conditions inside the target environment allow each stage of the kill chain to proceed without interruption. Each condition is a decision point where defence is possible.
No Visibility Into Early-Stage Activity
Discovery and reconnaissance phases — where adversaries spend the most time — are the easiest to detect with appropriate OT network monitoring and the hardest to detect without it. Organisations without OT-specific detection give adversaries months of unobserved dwell time to learn the environment.
Weak IT/OT Boundary Allows Lateral Movement
Flat or poorly segmented network architectures mean that a compromised IT asset can communicate directly with OT assets. Each lateral movement step an adversary must take is an opportunity for detection; removing those steps by flattening the architecture removes the opportunities with them.
Vendor and Contractor Access Is Unmonitored
Legitimate remote access paths used by vendors and contractors are routinely exploited by adversaries who have compromised those vendors or obtained their credentials. If vendor sessions are not monitored and logged in real time, adversarial activity using legitimate credentials is indistinguishable from authorised maintenance.
Safety Systems Are Not Architecturally Independent
When Safety Instrumented Systems share network segments with process control systems, an adversary who has compromised the BPCS can reach the SIS — the last line of automated defence. TRITON demonstrated that sophisticated actors specifically target this configuration.
Response Plans Are Not Calibrated for OT Consequences
IT-focused incident response plans that reach OT incidents often recommend actions — isolating systems, shutting down servers — that can cause operational consequences as serious as the attack itself. Without OT-specific response procedures, the response to an attack can compound the damage.
Where Defenders Can Interrupt the Kill Chain
Intervention Opportunities
- Initial access: MFA and hardened remote access to block credential-based entry
- Discovery: OT network monitoring to detect reconnaissance activity before lateral movement
- Lateral movement: Network segmentation to constrain the blast radius of a compromised asset
- Pre-positioning: Integrity monitoring and change detection on OT configurations and firmware
- Action on objectives: OT-specific incident response with pre-defined isolation and manual operation procedures
What Happens Without Intervention
- Adversary dwells undetected for months, learning the environment thoroughly
- Lateral movement proceeds from IT to OT without a control point
- OT environment mapped and target assets identified without raising alarms
- Capability deployed and waiting for optimal conditions to execute
- Consequence unfolds with operators responding reactively and without a tested plan
OT Attack Stages: Detection and Defence Mapping
| Kill Chain Stage | Adversary Activity | Detection Method | Primary Defence |
|---|---|---|---|
| Initial Access | Phishing / credential abuse / vendor compromise | Email security / auth log anomaly detection | MFA + privileged access management + vendor access controls |
| Discovery | Network scanning / protocol enumeration | OT network monitoring for anomalous traffic patterns | Passive IDS tuned to OT protocol baselines |
| Lateral Movement | Exploitation of flat network / dual-homed assets | East-west traffic monitoring / firewall log analysis | Zone segmentation + conduit-controlled traffic |
| Pre-Positioning | Malware deployment / configuration modification | File integrity monitoring / OT config change detection | Application whitelisting + change management controls |
| Action on Objectives | Process manipulation / ransomware / SIS attack | Process anomaly detection / safety alarm correlation | OT incident response plan + manual operation capability |
When the Attack Hits: What Operations Actually Experiences
The technical progression of an OT attack is only part of the story. What operators, engineers, and managers actually experience during and immediately after an OT cyber incident is a crisis that combines technical uncertainty, operational pressure, and communication breakdown simultaneously.
Operators may first notice the attack not through a security alert but through anomalous process behaviour — a valve that is not responding, a setpoint that has changed without an operator command, an HMI that has lost communication with a field device. Without prior training and pre-established criteria for what constitutes a potential cyber event, the initial response is likely to treat the symptom as a technical fault rather than a security incident, delaying the escalation that would bring in the people with the right expertise.
When the incident is recognised as a cyber event, the response team faces decisions under pressure that the organisation has almost certainly not explicitly pre-answered: do we isolate this PLC and risk losing process control, or do we maintain connectivity and risk further adversarial access? Do we shut down the process now, or do we attempt to operate manually while the investigation proceeds? Who authorises these decisions? How do we communicate with regulators, customers, and the public? Every minute spent debating these questions is a minute the adversary — or the physical process consequence — continues to progress.
The most important security investment for consequence prevention is often not a technical control — it is a pre-agreed, rehearsed decision tree for the hardest choices an OT incident forces: isolate or maintain, shut down or manual operate, contain or notify first.
Building Defences That Interrupt the OT Kill Chain
Defence does not require stopping every stage of an attack. It requires making enough stages difficult or visible that the adversary either cannot reach their objective or is detected before they do.
Visibility and Early Detection
Deploy the monitoring capability that makes early-stage adversary activity visible. Without this, organisations are reliably detecting OT incidents only after physical consequences have begun.
Lateral Movement Containment
Implement the architectural controls that limit an adversary's ability to move from IT to OT and from one OT zone to another — reducing the blast radius of any initial compromise.
Response Readiness
Build and test the organisational capability to respond to an OT cyber incident with speed, coordination, and pre-resolved decision authority — so that the response does not compound the consequences of the attack.
Questions Worth Sitting With
The scenarios in this article are not hypothetical constructs. They are drawn from documented incidents. These questions are worth asking before your facility becomes the next case study.
If an adversary has been present in your OT environment for the last three months conducting reconnaissance, what evidence would you have found by now — and are you looking for it?
At which stage of the OT kill chain does your current security programme provide a meaningful control that would interrupt adversary progression?
Have your operations and engineering teams ever worked through what manual operation looks like during a cyber incident — and do they know the criteria under which they should switch to it?
If your HMI went dark at 2am tonight, what is the first call your on-call operator makes — and does the person on the other end of that call have OT-specific incident response experience?
What is the worst physical consequence a cyber event could cause at your facility — and does your current security investment reflect the severity of that consequence?