From IT pivot to PLC shutdown, today's OT ransomware crews follow a repeatable playbook. Here is what we see in the field and the segmentation controls that contain the blast.
Operational technology environments are no longer collateral damage in ransomware attacks. They are the target. Ransomware operators learned years ago that when a plant stops producing, the ransom gets paid faster, larger, and with less negotiation. Manufacturing has been the most-targeted industry vertical for ransomware in every quarterly report since 2021, and energy, water, and food and beverage are catching up fast.
This is the playbook we see in the field, drawn from incident response engagements across discrete manufacturing, process industries, water utilities, and critical infrastructure. The pattern is remarkably consistent across crews — Black Basta, Akira, BlackSuit, RansomHub, and the post-LockBit splinter groups all execute variations of the same attack chain. The defenses that work against one work against most of them.
The five-phase attack chain
Phase one: initial access into IT. The entry point is rarely OT-specific. It is a phishing email opened on a corporate laptop, an internet-exposed VPN appliance with a recent CVE, an exposed RDP host, or a software supply chain compromise of a vendor with persistent access. The crews that have moved into pure access-as-a-service hand off this initial foothold to a separate ransomware affiliate within hours.
Phase two: discovery and credential theft. The operator dumps credentials from the initial host, identifies the Active Directory domain controllers, and walks the file shares looking for documents that name ICS systems, vendors, or engineers. References to "engineering," "SCADA," "historian," "DCS," "PLC," or specific vendor names (Rockwell, Siemens, Schneider, Honeywell, ABB, Yokogawa, Emerson) flag the OT side of the house. Network share documents that describe the architecture itself — including diagrams from system integrators — are gold.
Phase three: lateral movement to the engineering segment. The operator pivots through the IT-OT boundary using stolen domain credentials. In environments without strict segmentation, this is trivial. In environments with a flat domain spanning IT and OT, the entire OT engineering segment is one credential away. Even where a DMZ exists, jump hosts with shared credentials, dual-homed workstations, and unfiltered RDP between segments are common bypass paths.
Phase four: discovery of the OT DMZ and historian. The operator catalogs engineering workstations, HMIs, the data historian (PI, Ignition, Aveva, Wonderware), and any Windows-based systems exposed to the OT network. They identify backup infrastructure and disable or destroy it. They establish persistence on multiple hosts. This phase often runs days to weeks while the operator builds confidence in their access and the affiliate negotiates the ransom split.
Phase five: detonation. Ransomware deploys to engineering workstations, HMIs, the historian, and any Windows hosts in the OT DMZ. Operators lose visibility into the process. SCADA goes dark. Production stops because operators will not run a process they cannot see, and in many sectors regulation requires shutdown when monitoring fails. Pressure to pay mounts within hours, not days, because every hour of stopped production costs more than the ransom.
The PLCs themselves are usually untouched. They do not need to be. The Windows ecosystem around them is the soft target, and that is enough.
Why traditional IT controls fail in OT
Five practical realities limit what IT security teams can do in OT:
- EDR agents installed on engineering workstations or HMIs can break vendor-supported configurations, voiding warranties and support contracts. Some controllers will refuse to communicate with HMIs running unauthorized software.
- Patching requires plant downtime measured in hours or days. Maintenance windows are scarce, and patches must be tested against the specific firmware revisions of every controller in scope.
- Multi-factor authentication on a control room workstation in the middle of a shift change introduces operational friction that operations teams will refuse to accept and engineering managers will override.
- Active vulnerability scanning against ICS protocols can crash controllers. Modbus, DNP3, EtherNet/IP, and PROFINET were not designed to handle malformed or aggressive traffic, and vendor advisories explicitly warn against scanning production equipment.
- Centralized identity is rare. Each engineering workstation, HMI, and historian often has its own local accounts, vendor service accounts, and shared logins that have not rotated in years.
OT defenders need a different playbook than the IT SOC.
The architecture that actually contains a breach
The single largest determinant of whether an IT ransomware incident becomes an OT shutdown is the integrity of the IT-OT boundary. The reference model is the Purdue Enterprise Reference Architecture, and the controls that matter sit at Levels 3 and above:
- A real DMZ between Level 3 (operations) and Level 4 (enterprise IT). No workstation, no server, no service account spans the boundary. Every flow is mediated by a jump host or a data diode.
- Unidirectional gateways for high-assurance environments where data must leave OT but nothing must return. Hardware-enforced one-way replication eliminates the return path that ransomware needs.
- Strict allow-list firewall rules at the boundary. Most ransomware lateral movement traffic — SMB, WMI, RDP, RPC — has no legitimate reason to cross from IT to OT. Block by default.
- Asset visibility through passive network monitoring (Nozomi Networks, Claroty, Dragos, Tenable OT Security). These platforms understand industrial protocols, do not actively scan, and detect both new assets and protocol-level anomalies that signal an intrusion in progress.
- Privileged access workstations for engineers, with jump-host architecture, session recording, and credentials that do not exist on the engineer's laptop.
- Tested, offline, immutable backups for HMIs, historians, and engineering workstations. Backup destruction is the first thing modern ransomware crews do once they have access.
Detection and response in OT
Detection in OT is less about EDR and more about network behavior. The most reliable signals are:
- New devices appearing on the OT network that the asset inventory does not recognize.
- Unexpected protocol use — for example, SMB traffic to a controller, or outbound HTTPS from a device that should never speak to the internet.
- Engineering workstation logging into systems outside its normal pattern, or at unusual hours.
- Unsigned or unknown firmware download attempts to controllers.
- New users or scheduled tasks on Windows hosts in the OT DMZ.
When a detection fires, the response runbook is fundamentally different from IT. Containment options like host isolation can break the process. The OT IR team has to balance attacker eviction against safe-state shutdown, often coordinating with operations and safety in real time.
Maverc's OT incident response model
We pre-stage runbooks, escrow control system images, and rehearse the response with plant operations before an incident. When the call comes in, our responders work alongside your engineers — not against them. Decisions about isolating a controller, taking an HMI offline, or initiating a controlled shutdown are made jointly, with the safety implications understood by both sides.
The strongest predictor of a contained incident is not the technology in place. It is whether the OT and IT teams have practiced the response together before the bad day. Tabletop exercises, communication drills with operations, and joint runbooks for the top five OT incident scenarios separate the organizations that recover in days from the ones that lose weeks of production.
The investment case
The math is not subtle. Average OT ransomware downtime is now measured in weeks for organizations without strong segmentation, and in days for those with mature programs. Lost margin on stopped production typically dwarfs the cost of the segmentation, monitoring, and IR readiness program by an order of magnitude in the first incident.
Build the boundary. Watch the network. Rehearse the response. The crews are coming for OT, and the playbook is repeatable enough that the defense can be too.
