Beyond Access: Why Adversaries Mapping Your Control Loops Changes Everything About OT Defense
Last week, Dragos published its 9th annual Year in Review OT/ICS Cybersecurity Report. The headline finding is not more malware. It is not a spike in ransomware — though that rose 64% year-over-year. It is something quieter and far more dangerous: adversaries are now mapping industrial control loops at the process level.
“Instead of just prepositioning, they’re getting in place and mapping out and learning those control loops,” Dragos CEO Robert Lee told reporters. “It’s understanding things at an operational, physical process level. Not just that I have access to a wind farm.”
This is not a nuance. It represents a structural shift in adversary capability that renders conventional OT detection assumptions obsolete. If you are still asking “did malware execute on an engineering workstation?”, you are asking the wrong question. The right question is: “does someone understand our PID tuning parameters, our alarm thresholds, and the setpoint ranges that keep our physical process within safe operating limits?”
That is what control loop mapping means. And it changes everything.
What Control Loop Mapping Actually Means
A control loop in an industrial process is the closed feedback system that regulates a physical variable — temperature in a reactor vessel, pressure in a gas pipeline, rotational speed in a turbine, flow rate through a valve. It consists of sensors, a controller (typically a PLC or DCS), and actuators. The controller reads the process variable (PV) from the sensor, compares it to a setpoint (SP), computes an error signal, and adjusts the actuator output via a control algorithm — usually a PID (proportional-integral-derivative) function.
An adversary who has mapped a control loop knows several things that an adversary who has merely gained network access does not: the identity and function of every tag in the PLC’s tag database, the PID constants (Kp, Ki, Kd), the alarm limits, the interlock logic that prevents dangerous states, and the normal operating envelope of the process itself.
This is not exfiltration of documents or network diagrams. This is exfiltration of the physics-level understanding required to cause targeted, predictable physical damage — without tripping safety systems.
Dragos identified three new OT threat groups in 2025 alone — Azurite, Pyroxene, and Sylvanite — bringing the total to 26 tracked industrial threat groups globally, 11 of which were active over the past year. Azurite, linked to Chinese state activity, has been observed exfiltrating OT network diagrams, alarm data, PLC configurations, and HMI project files from manufacturing, defense, energy, and oil and gas targets across the US, Japan, South Korea, and Europe. Critically, Dragos noted that Azurite leveraged compromised edge devices to pivot to engineering workstations, then conducted malicious activity “using existing software to evade detection.”
Read that again. No malware. No zero-days. No exploit chain. Just an adversary sitting on an engineering workstation, using the vendor’s own programming software — TIA Portal, Studio 5000, EcoStruxure Control Expert — to download controller logic, browse tag databases, and study the process the way an engineer would.
The Detection Blind Spot at Purdue Level 3
This is where the Purdue Model becomes instructive, and where most OT security architectures fail.
The Purdue Enterprise Reference Architecture divides industrial networks into levels: Level 4/5 (enterprise IT), Level 3 (operations management — historians, engineering workstations, HMIs), Level 2 (supervisory control), and Level 1/0 (controllers and physical process). The engineering workstation sits at Level 3. It is a Windows machine. It runs legitimate industrial software. It connects to PLCs over industrial protocols — S7comm to a Siemens S7-1500, EtherNet/IP to an Allen-Bradley ControlLogix, Modbus TCP to a field instrument.
When an adversary uses that workstation with legitimate credentials and legitimate software, what does a signature-based detection stack see? A Windows process that has been whitelisted. A user account that is authorized. Network traffic that matches the expected protocol profile. Nothing triggers.
This is precisely how Azurite operates. Dragos reports that it “has not been observed manipulating, stopping, or modifying OT-specific software; it has only identified and exfiltrated information already on target assets.” In other words, it is doing nothing that an intrusion detection signature would flag — because it is doing nothing that looks like an intrusion. It looks like engineering.
The same pattern appears in Dragos’s incident response data: 30% of IR engagements in 2025 began as unexplained operational anomalies — not detected intrusions, but anomalies that someone eventually decided were suspicious. In many cases, limited historical data collection prevented root cause analysis entirely.
The Protocol-Level Signal
If signature-based detection cannot distinguish between a legitimate engineer downloading a PLC program and an adversary doing the same, what can?
The answer lies in the industrial protocol itself. When someone connects to a Siemens S7-1500 over S7comm and issues a “read CPU info” command, the PLC responds with its firmware version, rack configuration, and program metadata. When someone requests a block download — reading the actual control logic from the controller — the S7comm session generates a specific sequence of function codes. When an HMI polls a tag value, the Modbus transaction includes a function code (0x03 for Read Holding Registers), a starting address, and a quantity.
None of these operations are inherently malicious. But they are observable. And when observed over time, they form a pattern — a baseline of normal engineering activity: which workstations typically download logic, at what time of day, in what sequence, and against which controllers.
Passive network monitoring at the protocol layer captures every S7comm job request, every Modbus function code, every EtherNet/IP CIP connection, and every DNP3 read/write operation — without injecting a single packet onto the control network. This is not deep packet inspection in the IT sense; it is protocol dissection at Layer 7 of the Purdue model, reconstructing the industrial conversation exactly as the controller sees it.
An engineer who downloads logic from PLC-3 every Tuesday at 02:00 during a maintenance window is baseline. A connection from the engineering workstation to PLC-7 at 11:00 on a Thursday, issuing a “read all blocks” command for the first time in six months, is a deviation. Not because it triggers a signature, but because it violates the learned behavioral model.
Why This Is Harder Than It Sounds
Building that behavioral model is where most approaches fall short. OT networks are not like IT networks. They are deterministic, repetitive, and slow-changing — until they are not. A refinery that has run the same control strategy for a decade may undergo a turnaround that rewires half its I/O in a week. A water utility may add a new RTU that changes the polling pattern of its SCADA master. An adversary may wait 18 months between initial access and operational action.
A detection system that generates 400 alerts every time a maintenance crew shows up will be tuned out within a month. A detection system that relies on predefined rules for what constitutes “normal” Modbus traffic will miss the adversary who studies those rules and colors inside them.
The hard problem is not protocol parsing — S7comm, DNP3, and Modbus are well-documented. The hard problem is building a statistical model of normality that is stable enough to suppress noise from legitimate operational changes, yet sensitive enough to catch a single anomalous function code that signals an adversary learning your process.
This is fundamentally an engineering problem, not a signature-writing problem. It requires unsupervised learning over protocol telemetry — not packet counts and connection logs, but the actual industrial conversation: which tags are read, when, by whom, in what sequence, and with what deviation from historical norms. It requires understanding that a Modbus write to holding register 40001 may be a routine setpoint adjustment, while a read of holding registers 40050–40100 at 03:00 from a workstation that has never queried that range before may be reconnaissance.
From Access to Understanding: The New Threshold
The Dragos report closes with a finding that should focus every OT security team: organizations with comprehensive OT visibility contained ransomware incidents in an average of five days, compared to an industry average of 42 days.
That is not a marginal improvement. That is an order-of-magnitude difference. And it aligns with a more unsettling truth: in 2025, 25% of ICS-CERT and NVD advisories contained incorrect CVSS scores, and 26% contained no patch or mitigation from vendors. The vulnerability management playbook — patch, scan, repeat — is necessary but insufficient when a quarter of the advisories you rely on are wrong and the adversary is not exploiting vulnerabilities at all, but using legitimate engineering software.
The adversary has crossed a threshold. They are no longer satisfied with access. They want understanding. They want to know your process well enough to disrupt it with precision — or to wait, undetected, until the moment that disruption would cause maximum damage.
Maigadi was designed for precisely this problem: passive, protocol-level monitoring that builds a statistical baseline of normal industrial behavior and surfaces deviations before they become incidents. Not by looking for malware — there often is none. Not by matching signatures — the adversary is using your own tools. But by watching the industrial conversation itself, at the protocol level, and asking a single question: “Does this look like engineering — or does it look like reconnaissance?”
The difference between those two things has never mattered more.
Analysis based on the Dragos 9th Annual Year in Review OT/ICS Cybersecurity Report (2026), SecurityWeek, and Industrial Cyber reporting.