When the PLC Configuration Is the Attack: What the Water Sector Campaign Reveals About OT Detection

A pump station in Georgia loses pressure. An operator in Minnesota watches the cursor move on its own, changing PLC settings they didn’t authorise. A utility discovers the ladder logic running on its controllers doesn’t match the last known good — someone modified it remotely, from an IP address nobody recognised.

No malware. No exploit. No zero-day. Just a legitimate engineering connection that shouldn’t have been there.

This is what the coordinated campaign targeting US water utilities has looked like since late July 2026. The FBI has now confirmed incidents in at least seven states; reporting from ABC News puts the count at twelve or more. At least thirty community water systems in Minnesota alone were targeted on July 26 and 27. Georgia’s Clayton County Water Authority reported a pump station disruption that reduced water pressure. Michigan confirmed a “small number” of impacted communities. The operational effects range from nuisance to genuinely dangerous: loss of pressure, flooding, and — in theory — untreated groundwater seeping into distribution pipes.

And the attackers didn’t need anything sophisticated. They logged in to internet-exposed Rockwell Automation MicroLogix 1100 and 1400 series PLCs, changed IP addresses and passwords, and in at least one case modified the PLC project files themselves — ladder logic discrepancies spotted across multiple sites.

What makes this attack different?

Most discussions of OT cybersecurity frame the threat in terms of malware. Stuxnet. Industroyer. Triton. The language is one of payloads — a malicious binary, a crafted packet, a weaponised vulnerability.

This campaign doesn’t fit that frame. The attackers used the PLC’s own engineering interface. The same software an integrator uses. The same commands an operator would issue during maintenance. Every packet was valid. Every operation was authorised — from the PLC’s perspective. The only thing that was wrong was who was doing it, and when.

This is living-off-the-land at Purdue Level 1 — the field device layer where process physics meets digital control. And it exposes a hard truth about detection at this level: if your defence relies on signatures, you are blind to it.

Why signatures can’t see this

A signature-based detection system works by matching known-bad patterns. A hash of a malicious binary. A specific byte sequence in a network packet. An indicator of compromise from a previously documented campaign.

Now consider what the water sector attackers did:

Connected to a PLC over Ethernet/IP — a perfectly valid industrial protocol
Authenticated (or didn’t need to, because the PLC had no password)
Issued standard configuration commands: change IP, set password, modify rung logic
Disconnected

Every single one of those operations is legitimate in some context. There is no “malicious configuration change” byte signature, because from the protocol’s perspective, a configuration change is a configuration change — whether it comes from a control engineer at 10 AM on a Tuesday or from a threat actor in a foreign country at 2 AM on a Sunday.

Signatures catch what’s been seen before. This campaign didn’t need anything that hadn’t been seen before. It needed only things that hadn’t been seen here.

What behavioral detection at Level 1 would see

A network-level behavioral detection system — one that learns what normal looks like for each device on the OT network — would flag this campaign on multiple independent signals:

Connection geography. A device that has never communicated with that PLC before opens a connection. Not a known engineering workstation. Not the SCADA server. An unfamiliar IP — potentially from a hosting provider or a foreign geolocation. That’s a baseline deviation, and a high-confidence one.

Operation sequencing. The sequence of operations — connect, change IP, set password, modify logic, disconnect — doesn’t match any known maintenance window or authorised change control pattern. Even if the connecting device were authorised, the sequence is anomalous.

Configuration velocity. A PLC that has held the same configuration for months suddenly undergoes three or four changes in the span of minutes. Normal OT environments don’t work that way. Engineers plan changes. They test. They validate. They don’t reconfigure a production PLC in a three-minute sprint and vanish.

Ladder logic integrity. The PLC’s running program no longer matches the known-good baseline. This is the strongest signal — and the one the FBI specifically flagged in its July 30 alert, noting that “at least one organization reported modified PLC project files after noticing ladder logic discrepancies.” A detection system that baselines the logical behaviour of field devices at commissioning catches the change immediately, without needing to know whether the new rung is “malicious” or not. The very fact that it’s different is the signal.

None of these signals requires a signature. None requires prior knowledge of an adversary’s TTPs. Each is visible simply by knowing what normal looks like and flagging the deviation.

Is this just a water problem?

The water sector is the canary. The attack template — find an internet-exposed PLC, connect with legitimate engineering software, reconfigure, disappear — works identically in manufacturing, in energy distribution, in building automation, in transport.

Censys reported roughly 10,000 Rockwell, Siemens, and Schneider PLCs visible on the public internet. Not all are vulnerable. But every one that is represents a field device that an attacker can touch without ever needing an exploit. The FBI alert explicitly noted that “similarities in network setup provided by third parties may provide MCA the opportunity to multiply successes when vulnerable network and hardware setups exist across customers” — which is to say, the integrator who configured thirty identical water systems for thirty small municipalities created thirty identical attack surfaces.

This is not a water problem. It is a Level 1 visibility problem. And it is everywhere.

The takeaway for OT defenders

The water sector campaign is clarifying because it strips away the layers we normally wrap around OT security discussions. There is no exotic malware to reverse-engineer. No supply chain compromise to unravel. Just a field device, exposed to the internet, receiving configuration commands from someone who shouldn’t be there.

Three things follow for anyone responsible for OT defence:

First, remove PLCs from direct internet exposure. This is the FBI and CISA’s first recommendation, and it should be treated as non-negotiable. A gateway, a jump host, a properly authenticated VPN — anything that mediates the connection and logs who connected. The raw PLC has no business being addressable from the public internet.

Second, baseline your Level 1 behaviour. You cannot detect anomalous configuration changes if you don’t know what normal configuration looks like. Every PLC, every RTU, every field device that touches a physical process should have a known-good behavioural baseline — not just a static asset inventory, but a dynamic understanding of which devices talk to which, on what protocols, at what cadence, with what command patterns.

Third, treat configuration changes as detection events. A PLC password change is not an administrative detail. It is a signal. A ladder logic modification is not just an engineering operation. It is a signal. In the water sector campaign, these were the only signals — and they were enough, for the organisations that had the visibility to see them.

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.