The Most Dangerous OT Attacks Don't Break In — They Log In

An operator badge-swipes into the control room at two in the morning. They sit down at the engineering workstation, open the HMI, and upload a modified PLC configuration — one that disables a safety interlock, or changes a pump threshold, or rewrites a setpoint. Then they leave.

No malware was installed. No exploit was triggered. No vulnerability was exploited. The operator used their own legitimate credentials on a workstation they’re authorised to access, running software they use every day. Every security log shows an authenticated, authorised session.

And every signature-based detection tool in the stack sees nothing wrong.

OT security has spent the last decade getting better at keeping outsiders out. Network segmentation, firewalls, DMZ architectures, patch management programmes, vulnerability scanners, endpoint detection — most plants have some version of this stack. The industry has built increasingly sophisticated defences against the external attacker model: someone on the internet, using malware or an exploit, trying to pivot from IT to OT.

But the operator at 2AM didn’t come from the internet. They walked through the front gate.

This is not a hypothetical. The record of OT incidents involving legitimate access — whether by a malicious insider, a compromised credential, or a contractor who should no longer have access — is longer than most engineers realise. And it stretches back more than two decades.

Four incidents that should keep OT engineers awake

Maroochy Shire, Australia — 2000

In early 2000, the Maroochy Shire Council in Queensland, Australia, experienced a series of unexplained sewage discharges. Over several weeks, millions of litres of raw sewage spilled into local parks, rivers, and the grounds of a coastal hotel. Pump stations would activate without command. Alarms would trigger and then clear themselves.

The culprit was Vitek Boden, a former contractor who had worked on the council’s SCADA system. After his application for a permanent position was rejected, Boden used a laptop and a radio transmitter — equipment he knew how to use because he had helped install the system — to access the sewage control network remotely. He issued commands using the same radio protocols the legitimate operators used. He did this at least 46 times before being caught.

No malware. No exploit. Just someone who knew the system, had the tools, and logged in.

This is widely regarded as the first documented case of a SCADA system being used maliciously by an insider. The incident prompted the Australian government to commission one of the first formal post-mortems of a SCADA security incident, and it shaped early thinking about the insider threat in industrial control environments — a risk that, more than two decades later, the industry still struggles to detect systematically.

Oldsmar, Florida — 2021

On February 5, 2021, an operator at the Oldsmar water treatment plant watched a mouse cursor begin moving across his screen. Someone had connected to the plant’s HMI via TeamViewer — remote access software the plant had installed and maintained for operational convenience. The remote user navigated to the sodium hydroxide control and increased the setpoint from roughly 100 parts per million to 11,100 ppm. That level of sodium hydroxide — also known as lye — is corrosive and dangerous at those concentrations.

The operator watched it happen in real time and immediately corrected the change. The public water supply was never at risk because of the system’s inherent dwell time and buffering. But the mechanism was instructive: an attacker had reached deep into the OT environment using nothing but remote desktop software that was placed there legitimately, by the plant’s own staff, for a valid operational purpose.

The FBI and CISA issued a joint advisory. No arrests have been made. The attacker’s identity remains unknown.

German Steel Mill — 2014

In its 2014 annual report, Germany’s Federal Office for Information Security (BSI) described an incident at an unnamed steel mill that would become one of the most cited cases in OT security. Attackers used a spear-phishing campaign to harvest credentials from employees. Once inside the corporate IT network, they pivoted through to the production network — the OT environment — and gained access to the control systems managing a blast furnace.

The result was what the BSI described as “massive physical damage.” Operators lost the ability to shut the furnace down properly. The attack did not use SCADA-specific malware. It did not exploit an OT protocol vulnerability. It ran on stolen credentials and knowledge of how the IT-to-OT bridge worked.

Dallas, Texas — 2017

At approximately 11:30 PM on April 7, 2017, every emergency siren in the city of Dallas — all 156 of them — activated simultaneously. They blared for over 90 minutes. 911 centres were inundated with thousands of calls from residents who thought an air raid or tornado was imminent.

The attacker had not penetrated a firewalled network or deployed malware. They had exploited knowledge of the radio repeater tones used to activate the siren control system — a system designed for reliability and reach, not authentication. The City of Dallas later confirmed the attacker used a technique that required “specific knowledge” of the radio infrastructure.

No signature. No exploit. Just someone who understood how the system was controlled, and had the means to send the right signal.

The common thread

These four incidents span continents, decades, and industries — water, wastewater, metals, and municipal emergency management. They have exactly one thing in common: in none of them would a signature-based detection system have raised an alarm.

A signature matches a known pattern — a hash, an IP address, a byte sequence, a C2 domain. But a legitimate engineering session looks the same whether the operator is troubleshooting a faulty pump or disabling a safety interlock. The protocol — Modbus, DNP3, S7comm — doesn’t annotate intent. A Modbus write to a coil looks identical regardless of the operator’s motive.

This is the structural limitation of signature-based detection in OT. It is not that signatures are useless. It is that they are inherently backward-looking — they catch what has been seen before. A disgruntled employee, a compromised contractor account, or a hijacked remote-access session using valid credentials has no signature to match. The activity is, by every traditional security definition, legitimate.

What you’d need to see it

To catch the 2AM operator, a detection system needs to notice that something is different — not that something is bad in a previously catalogued way.

This operator normally works the day shift. Why are they in the plant at 2AM?
This engineering workstation normally communicates with PLCs 3, 7, and 12. Why is it suddenly writing to PLC 19?
This Modbus function code is normally issued 40 times an hour during operations. Why is it being issued 200 times in five minutes?
This controller’s configuration has not been modified in 18 months. Why is a write command targeting its logic table right now?

None of these observations requires a signature. None of them requires decrypting anything or deep-packet-inspecting a proprietary protocol. They all require the same thing: a baseline of what’s normal, and the ability to notice when reality diverges from it.

That’s the behavioural detection model. It doesn’t ask “is this malware?” — it asks “is this supposed to be happening right now?” The second question catches things the first one misses by design.

The operator’s perspective

Every OT engineer reading this has had the same experience: you’re on shift, you notice something odd on the HMI, and you act. You call someone. You override a setpoint. You investigate. The human operator is, and always will be, the most important detection and response capability in any plant.

But you’re not there at 2AM unless you’re the one at the workstation.

The operator who stopped Oldsmar did so because they happened to be watching the screen at the right moment. That is not a detection strategy — it’s luck. And the difference between a near-miss and a front-page story should not rest on whether the right person glanced at the right screen at the right second.

Closing the gap

Maigadi is an OT/ICS network detection and response 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 engineering workstation starts communicating with a PLC it has never touched before, Maigadi flags it. When a write command arrives at a controller at an unusual time, from an unusual source, at an unusual frequency — it’s surfaced. Not because it matches a known attack pattern, but because it doesn’t match the learned baseline of how your plant actually operates.

The 2AM operator scenario isn’t a thought experiment. It has happened, in different forms, in Queensland, in Florida, in Germany, and in Texas. It will happen again. The question is whether your detection stack will see it — or whether you’re relying on someone glancing at the right screen at the right time.