Everything in This ICS Campaign Is a Decade Old Except the Part That Wrote the Exploit

On August 19, five US federal agencies — NSA, CISA, FBI, the Department of Energy and the Environmental Protection Agency — issued advisory AA26-231A, Defending Against an Active Threat to Siemens S7 Series PLCs. It covers every generation of the family, from the S7-200 through the S7-1500, including F-series safety controllers, across critical manufacturing, energy, water and wastewater, chemical, food and agriculture, and commercial facilities.

The technical content of the campaign is, on its face, unremarkable. Actors query internet scanning services — Censys, ZoomEye — for hosts with port 102 exposed. They find Siemens S7 PLCs running outdated firmware or sitting on default and minimally configured credentials. Then they talk S7comm to them with Python scripts built on snap7 and python-snap7, which are open-source libraries anyone can pip install. That gives them read and write access to PLC memory, configuration data, and ladder logic programs.

Every component in that chain has been available for a decade. Port 102 exposure is one of the most recognisable finds on Shodan. python-snap7 has been on PyPI since 2013. Known S7 weaknesses are documented in public advisories.

So the advisory is not telling us about a new vulnerability. It is telling us that the last thing standing between those ingredients and a working ICS capability has been removed — and it is the first US government advisory to say so about AI-generated code targeting industrial controllers.

The moat was never the vulnerability. It was the expertise

Ask why a decade-old exposure has not already been industrialised and the honest answer, the one OT security has leaned on without ever writing it in a risk register, is scarcity of people.

Writing a tool that speaks S7comm to a live controller and does something useful — rather than faulting the CPU and announcing itself — has historically required a rare stack: the protocol, the vendor's addressing model, the semantics of a data block in a particular plant, ladder logic, and enough process engineering to know which register actually matters. That skill set sits in a small population, and most of it is employed. Volume attacks stayed in IT because that is where the labour was cheap.

The agencies state the change directly. AI-assisted development is "dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts," and lets adversaries "rapidly leverage additional attack vectors and adapt to defensive measures." Their assessment of the campaign's purpose is worth reading twice: this is persistent reconnaissance and capability development — read access used to understand target environments, "enabling preparation and positioning for future write operations to cause disruption."

Nobody is pretending a language model brings process engineering judgment to the table. It does not need to. It needs to close the gap between the exposure is public and the tool exists, and that gap is where a great deal of ICS risk has been parked, unpriced, for years. It is the same compression we wrote about when the exploit window collapsed on the enterprise side, and the same effect that let an autonomous agent find and exploit a Snowflake CI/CD flaw five days after it merged. What is new is that it has now arrived in the one environment that cannot respond with a patch cycle.

Because that is the second half of the problem. The IT answer to a capability shift is to ship fixes faster. A water district cannot. The controller is in service, the firmware upgrade needs a process outage, the integrator who wrote the logic may no longer exist, and on an S7-200 there is no meaningful authentication to turn on in the first place.

What the campaign is actually built to defeat

The line in the advisory that deserves the most attention is not about AI at all. The scripts are disguised as legitimate OT monitoring software.

That is a deliberate choice, and it is aimed squarely at how OT detection is normally done. A plant network is not a place where you can freely deploy heavy security agents, so visibility tends to be a passive network tap plus a rule set. Rule sets recognise things that have been seen before. A Python tool generated for one target, named plant-telemetry-collector, importing the same snap7 library your real historian imports, and issuing the same ReadVar calls your HMI issues all day, has not been seen before — and is not, in any signature sense, malicious.

Look at what serious hunting guidance for this campaign actually asks defenders to do, and the pattern is unmistakable. Burns & McDonnell's 1898 & Co. threat hunt plan for AA26-231A recommends: maintain a living controller inventory and an approved-engineering-workstation baseline; treat classic S7comm (protocol ID 0x32) reaching an S7-1500 that normally speaks S7CommPlus as a finding; treat a programming-device role TSAP (high byte 0x01) presented by a host that is not an engineering station as a finding independent of what it does next; escalate WriteVar (0x05), PLCStop (0x29), and any download or upload block sequence; and correlate every S7 operation outside the known read-set against change records, where anything uncorrelated is a finding. It also, pointedly, forbids active probing of the controllers themselves — you may not scan your own PLCs, because the scan is a process risk.

Read that list again. Not one item is a description of an attack. Every single one is a description of normal — the approved hosts, the expected protocol dialect, the client role that belongs on this segment, the read-set that operations actually uses, the change record that authorises a write. The finding is generated by the delta.

That is the structural lesson of this advisory, and it generalises well beyond Siemens: when the adversary's tooling is generated per-target and dressed as a legitimate utility, enumerating what is permitted outperforms enumerating what is bad. Detection by badness assumes the attacker's artefacts repeat. AI-assisted development is precisely the technique that stops them repeating.

We already know what the write half of this looks like when someone stops rehearsing, incidentally. In late July 2026, more than 30 Minnesota water utilities were hit in a coordinated campaign; the intrusions used no novel exploit and no custom malware — just controllers reachable from the internet. Attackers changed device IP addresses and set passwords, locking operators out of their own systems and forcing plants to manual operation. Those were Rockwell MicroLogix units, not Siemens, and it was a different campaign. It is a fair preview of what AA26-231A means by positioning for future write operations.

The uncomfortable symmetry

There is a second reading of this advisory that most coverage has skipped.

The adversary's advantage here came entirely from an AI assistant with unconstrained reach — one that would happily take public vulnerability research, a scanning result, and a protocol library, and return a functioning tool that impersonates plant software. No inventory, no owner, no logged record, no policy about what it may be pointed at.

Your organisation has that same capability deployed right now. It is being used by engineers and by agents, and it has reach into the exact material an S7 campaign wants: network diagrams, historian queries, ladder logic exports, integrator handover documents, jump-host credentials. In most organisations it was rolled out by a product or automation team, runs on a static key, and has no security owner — which is, structurally, the identical failure to the internet-facing PLC nobody had on a list.

What to do in the next week

1. Enumerate exposure passively, and keep doing it. Check Shodan, Censys and Netlas for your own address space and your integrators' — port 102, Siemens banners — and require two independent ownership signals before you attribute a hit. Do not port-scan the controllers.
2. Build the two baselines the hunt depends on: a controller inventory with model and firmware, and an approved-engineering-workstation list. Neither is a security product; both are prerequisites for every detection above.
3. Hunt for the masquerade on the hosts you can see. A process named monitor, telemetry, collector or watchdog connecting to port 102; snap7.dll or libsnap7 loaded on a non-engineering host; a Python process importing snap7 from a user-writable path.
4. Snapshot and diff your logic. On S7-1200/1500 the S7CommPlus session encryption defeats function-code inspection, so gold-copy comparison of controller code is the control that still works.
5. Register your own AI tooling the way you are about to register your PLCs — with an owner, a scope, and a record of what it was asked to do.

Where Obiguard fits: Governance AI is a positive-permission model for the AI layer

Let us be exact about scope: Obiguard does not secure PLCs and does not parse S7comm. The controller work above is OT engineering, and no AI governance product substitutes for it.

What Obiguard applies is the same principle, to the layer this advisory shows adversaries exploiting on their side and most organisations running ungoverned on theirs. Obiguard Governance AI is built as a positive-permission model for AI access — allow-lists that operate at four levels, binding each credential to specific model IDs, tools, external domains, and invoking identities. That is the enumerate-the-permitted design, expressed for AI exactly as the approved-workstation baseline expresses it for a plant network. A generated tool reaching an unlisted domain is a denial, not a signature miss.

Three parts of that matter directly here:

An inventory with an owner. Every AI agent and tool-call is registered with a named owner, a business function and an assigned policy set. The reason nobody had the exposed PLC on a list is the reason nobody has the automation team's assistant on a list — agent governance is the specific use case.

Inspection before egress. Every prompt passes the inspection layer with sensitive-data redaction, block-lists, and jailbreak and prompt-injection detection. Where the concern is engineers pasting network diagrams, credentials, or ladder logic into a consumer assistant, Obichat is the sanctioned on-ramp — running in your own tenant, with per-workspace model allow-lists and an exportable activity log — which then lets you block direct egress to consumer AI endpoints at the firewall instead of hoping.

A record that survives the incident. The audit ledger keeps an immutable per-call record of prompt, response, tool calls, model, agent ID and initiating identity. That is the artefact that answers "what did our AI tooling touch, and on whose behalf" — the same question the advisory is asking about the controllers.

On the telemetry half, Obiguard SOC does not see the plant floor, but it does see the estate the masquerading tool has to live on. Logs, host metrics and distributed traces stream in over OpenTelemetry with a one-command Kubernetes daemonset for EKS, GKE and AKS; detection fires from live log volume and rule matches with no detection rules to author first — which matters when nobody has written content for this campaign yet — and every incident carries a full evidence timeline linked back to the raw log events. Threat Intelligence cross-checks findings against CISA KEV and FIRST.org EPSS on a schedule, so a controller-adjacent CVE moving into the actively-exploited column surfaces against your estate rather than in a newsletter.

The agencies' own assessment is that this is reconnaissance, not disruption — capability being built, not used. That is the most useful thing in the advisory, because it is a statement about time you still have. Enumerate what is permitted, on the plant network and in the AI layer both, while the permitted set is still something you get to define. Explore Governance AI or talk to us about what your AI credentials are currently allowed to reach.