Between Detection and Action: Why Living-Off-The-Land Attacks Break the OT Response Playbook

There is a number that has been making the rounds in OT security circles this year and it sounds like progress: nearly half of ICS security teams now report detecting threats in under 24 hours. Five years ago, the industry benchmark was measured in weeks — sometimes months. By that standard, 24 hours is a genuine operational achievement.

But there is a second number that nobody celebrates: the gap between detection and containment in OT environments remains measured in days, not hours. And for a specific class of attacks — the ones that do not use malware at all — that gap can stretch even further, because the operator looking at the alert cannot tell whether what they are seeing is an attack or just a Tuesday.

These are living-off-the-land attacks, and they are reshaping what OT incident response actually means.

What “living off the land” looks like in an OT environment

In IT, living-off-the-land — LotL — means an attacker using tools already present on the system: PowerShell, WMI, PsExec, the native command shell. No malware dropped. No virus signatures to match. The attacker’s activity blends into the background noise of legitimate administration.

In OT, the concept is the same but the toolset is different — and more dangerous. Instead of PowerShell, the attacker uses the engineering software already installed on the workstation. Instead of WMI, they issue Modbus function codes or S7comm job requests. Instead of PsExec, they use the vendor’s own remote maintenance tool — the same one the integrator used last week during routine commissioning.

A write to a coil from an engineering workstation is not suspicious on its own. That is what engineering workstations do. A firmware upload initiated from a known IP address on the correct subnet, using the correct protocol, during working hours — every field in the SIEM looks normal. The only thing that makes it an attack is the intent behind it. And intent does not show up in a signature.

This is why LotL attacks in OT are so hard to detect — and, more importantly, so hard to act on once detected. The alert does not say “malicious firmware upload detected.” It says “firmware upload initiated from engineering workstation.” The operator now has to answer a question that no dashboard can answer for them: was that the controls engineer doing their job, or an adversary doing theirs?

The containment gap: why you cannot just pull the plug

In IT incident response, the containment playbook is well-established: isolate the affected host, revoke credentials, block the C2 IP, snapshot the disk, begin forensics. These steps are measured in minutes. They are disruptive, but the disruption is to a server or a workstation — not to a physical process.

In OT, containment is a fundamentally different problem. You cannot isolate a PLC the way you isolate a domain controller. That PLC might be controlling a turbine, a valve manifold, or a chemical feed system. Disconnecting it means stopping the process — and stopping the process might mean a safety incident, an environmental release, or a production outage measured in millions per hour.

This is the containment gap: the space between knowing something is wrong and knowing enough to act safely. And LotL attacks exploit this gap ruthlessly. The attacker knows the operator will hesitate because the activity looks legitimate. Every minute the operator spends verifying — calling the controls engineer, checking the maintenance schedule, pulling the shift log — is a minute the attacker spends moving closer to their objective.

The SANS Institute captured this dynamic precisely in a March 2026 analysis: “While detection and containment times have improved across some industrial sectors, remediation and safe recovery remain persistent challenges. This gap highlights a core reality many organizations are still grappling with: ICS/OT incident response is fundamentally different from traditional IT incident response.”

What closes the gap: context, not just alerts

If the containment gap is a question of context — “do I know enough to act?” — then the solution is not more alerts. It is better answers to the questions the operator actually needs to ask when an alert fires.

A passive network detection platform that has learned the environment’s normal communication patterns can answer three questions that a signature-based tool cannot:

“Has this device ever done this before?” A firmware upload from an engineering workstation is only interesting if that workstation has never uploaded firmware before — or if it is uploading firmware at 3AM on a Sunday, or if it is uploading to a PLC it has never communicated with. The baseline answers the question that the signature cannot ask.

“What else changed at the same time?” An attacker executing a LotL campaign rarely makes a single move. They scan. They enumerate. They read registers they have no business reading. A passive monitoring platform that correlates across devices and protocols surfaces the pattern — the constellation of small anomalies that, taken together, look nothing like normal engineering activity.

“Is the process still healthy?” This is the question that matters most when deciding whether to isolate. If the process is still running within normal parameters — polling cycles maintaining their rhythm, status exchanges continuing at their expected cadence — the operator has time to investigate before escalating. If the process baseline has shifted, the calculus changes. Passive monitoring of the control-plane traffic provides this health signal without adding any load to the devices being monitored.

The LotL-ready detection layer

Three practical steps for OT teams building their capability against living-off-the-land attacks:

First, accept that signatures will miss the attacks that matter most. LotL attacks use legitimate tools over legitimate protocols. By definition, there is no malware signature to match. Invest in behavioral detection that learns what normal looks like — per device, per protocol, per time of day — and flags deviations, not signatures.

Second, build containment playbooks that account for operational context. The question is not just “how do we isolate this device?” but “what happens to the process if we do?” Map your critical control loops and document the operational consequence of isolating each device. Do it now, during peacetime. During an incident is not the time to discover that the PLC you just disconnected was the one running the cooling system.

Third, treat every alert as a decision point, not a verdict. An alert from a behavioral detection platform is a hypothesis — “this looks different from normal.” It is not a conviction. Arm your operators with the context they need to investigate: which devices are involved, what changed, when it changed, and whether the process is still running normally. The goal is not to eliminate false positives — it is to make every alert investigable in under five minutes.

The bottom line

The OT security community has made real progress on detection speed. Twenty-four hours is a number worth acknowledging. But detection without safe containment is just awareness — and awareness alone does not stop an adversary who is already inside the control loop, issuing commands that look exactly like the ones the controls engineer issued yesterday.

Living-off-the-land attacks do not break into your network. They log in. They do not drop malware. They use your own tools. And they count on the operator hesitating — on the gap between the alert and the action stretching long enough for the objective to be achieved.

Closing that gap is not about faster dashboards or louder alarms. It is about better context. A passive, behavioral monitoring layer that can tell the operator not just that something changed, but what changed, on what device, and whether the process is still healthy — that is what turns a 24-hour detection window into a 24-minute containment decision.

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.