Why the Most Damaging OT Attacks Look Like Legitimate Engineering
A controls engineer badges in at 06:40, opens the vendor’s programming software on the engineering workstation, and pushes a small setpoint adjustment to a PLC on the process floor. Every credential checks out. Every tool is the one the vendor shipped. Every packet is a valid, standard protocol message. The historian logs the change under the engineer’s own user ID, and the shift report calls it routine.
Nothing in that sequence trips an alarm — and that is precisely the problem. The most consequential intrusions into industrial networks over the last several years did not announce themselves with a novel virus or a corrupted file an antivirus engine can match. They looked, on the wire and in the logs, exactly like the legitimate engineering work that happens on that network every day.
Three intrusions, three different sectors, one shared signature: none. However each attacker got in — and whether or not malware was involved along the way — the action that actually reached the process looked exactly like legitimate engineering. They used what was already there: the tools, the credentials, and the protocols.
Volt Typhoon — the intrusion that never dropped malware
In May 2023, CISA, the FBI, and the NSA issued a joint advisory describing a state-sponsored actor, later tracked as Volt Typhoon, observed inside U.S. critical infrastructure networks. The most striking observation was not the scope of the activity but the method: the actor relied on legitimate tools and valid credentials, deliberately avoiding malware to remain invisible. The stated goal was pre-positioning — establishing quiet, persistent access to communications, energy, and transportation networks for potential future use.
For a defender, this is the hardest kind of intrusion to confront. There is no file to quarantine, no hash to block, no malware family to look up. There are only authorized sessions doing authorized-looking things, spread across a long horizon.
Triton — the safety system, reached through its own tools
In 2017, investigators reconstructed an intrusion at a petrochemical facility in Saudi Arabia that targeted the plant’s safety instrumented system — the last automated line of defense designed to drive the process to a safe state. The attackers did not fight their way in with an exploit chain that left a trail of foreign code in the control network. They reached the safety system through its own engineering workstation and the TriStation protocol the system uses to receive configuration.
The attack triggered emergency shutdowns and prompted one of the most-studied OT investigations on record. The instructive part is the mechanism itself: the path the attackers took was the same path a vendor engineer would take on a routine maintenance visit.
FrostyGoop — a heating outage sent over standard Modbus
In January 2024, a district energy company in Lviv, Ukraine, lost control of its heating for roughly two days — cutting heat to more than 600 apartment buildings in the middle of winter. Public reporting and subsequent technical analyses traced the disruption to malware, since named FrostyGoop, that issued commands over Modbus TCP — one of the oldest and most widely deployed protocols in industrial automation — to the facility’s heating controllers.
The Modbus messages themselves were valid. What made them destructive was not an exotic technique but the simple fact that a system was in a position to write to those controllers, and did.
The common thread: trusted tooling is the attack surface
Strip away the individual details and the three incidents share one shape. In each, the attacker’s entry point and movement were indistinguishable, at the packet and log level, from legitimate engineering activity. Different sectors, different protocols, different years — the same structural weakness.
This is what “living off the land” means in operational technology. The term is borrowed from IT, where an adversary conducts an intrusion using the tools, credentials, and functionality already present on a system rather than bringing their own malware. In OT, that means the engineering workstation, the vendor’s PLC programming software, legitimate remote-access sessions, and the control protocols themselves.
The engineering workstation deserves particular attention. It sits at the junction between the IT and OT worlds — connected to both — and it holds the credentials and the software that can reach the controllers. Every one of these incidents passed through, or centered on, that workstation. It is the pivot point, and in most plants it is the least-watched device in the room.
Why a signature can’t see an attack that looks like normal engineering
A signature answers one question: does this match something we already know is bad? Living-off-the-land attacks are engineered around the inverse — can we stay inside the envelope of what is already known to be good?
That is a meaningful distinction, not a minor one. A file hash can only block a file someone has already seen. A rule can only fire on a condition someone has already written down. An adversary using your own vendor software, your own credentials, and your own protocols never leaves the “known-good” envelope — so the known-bad detectors never fire. This is not a failure of those tools; it is the limit of their premise.
If there’s no malware, what do you detect?
If the individual actions are all legitimate, the only thing left that separates an attack from normal operation is behavior — the relationships between actions, their context, and their deviation from the network’s established normal.
Consider what a behavioral baseline can flag:
- A write to a process setpoint arriving at 03:00 from a workstation that has only ever issued writes during scheduled maintenance windows.
- A Modbus write to a heating controller originating from a device that has never communicated with that controller before.
- A configuration change to a safety system outside a scheduled, controlled engineering window.
None of these require the command itself to be “malicious.” They require knowing what normal looks like for this specific network — which device talks to which, on what schedule, with which function codes — and noticing when that pattern bends.
Can’t a watchful operator catch this?
The operator is, and always will be, the single most important detection capability in any plant. In 2021, an attacker used a legitimate remote-access tool to reach the HMI of a water treatment plant in Oldsmar, Florida, and raised the sodium hydroxide setting to a dangerous level. An operator watching the screen in real time caught the change and reversed it — because a human was in the loop at the right moment.
But resting on human vigilance alone is fragile. Operators are busy, screens are dense, and a well-timed change that looks routine is exactly what a careful attacker counts on. Vigilance is necessary; it is not a plan. A plan requires something watching the network continuously, in the way no person — and no signature database — realistically can.
The question to ask before the next quiet intrusion
This is the problem Maigadi was built to address.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.
When an attacker works with your own tools, the signal isn’t in the tool — it’s in the behavior around it. That is what a passively-learned baseline is built to surface.
The question worth asking before the next quiet intrusion is simple: if an authorized session started moving toward your controllers tomorrow morning, would anything in your network notice — or would it just look like a normal Tuesday?
Maigadi Networks provides passive, signature-less network detection and response for OT/ICS environments. We help operators see when a trusted device starts doing something it has never done before — before that behavior becomes an incident.