AI did not make ICS attacks possible. It made them ordinary.

On August 20 I argued that the phrase autonomous AI attack was doing work the evidence did not support. The unattended runs in that campaign failed, people did the compromising, and what had actually become cheap was choosing targets.

Then five US agencies published an advisory saying threat actors are using AI to generate working exploitation scripts against industrial controllers at water plants, power facilities and chemical sites [1].

So I went to read it, partly to find out whether I had been wrong.

What happened

On August 19, 2026, the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency jointly published AA26-231A [1]. The agencies say threat actors are conducting reconnaissance and capability development against US Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools. They call this an active threat rather than a theoretical risk [1].

The targeting is broad across the S7 range: S7-200, S7-300, S7-400, S7-1200 and S7-1500, the last including F-series safety controllers [1]. Sectors named are Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities, with the Defense Industrial Base noted as a user of the same equipment [1].

The method is unglamorous. Actors use internet scanning services, Censys and ZoomEye are named, to find exposed or poorly segmented controllers. They take advantage of devices with default or minimal authentication. And they use AI assistance to generate Python scripts built on snap7.dll and python-snap7, public open source automation libraries, which give read and write access to PLC memory, configuration and ladder logic over the S7comm protocol [1].

Three things the advisory does not say, which the headlines did. It does not report a successful compromise. It does not report an operational impact. And it does not name an actor or a country [1][3].

What it reports is preparation. The agencies assess the activity is likely persistent reconnaissance intended to develop capability and position for future effects, with read access used now to understand environments before any write operations later [1].

Why this matters

What made ICS attacks rare was knowledge. Attacking a PLC has never been technically hard once you can reach it. What kept the population of capable attackers small was knowing S7comm, knowing how data blocks are addressed, knowing what ladder logic looks like and what changing it would do. That is specialist knowledge that took years to acquire and did not transfer from IT.

Generating a Python script against a documented library using published vulnerability information is exactly the kind of task a language model does well. The advisory’s own framing is that this dramatically reduces the technical expertise and time required [1].

So that position survives, and I want to be precise about why rather than just claiming it. This is still code generation rather than autonomous compromise. Nobody has demonstrated a model finding a novel flaw or running an intrusion end to end. But it lands harder here than the same capability would in IT, for the reason above. Removing a knowledge barrier matters most in the one place where knowledge was the barrier.

Exposure that was survivable because few could act on it is now exposure that many can. Every small water authority and food plant that reasoned nobody would bother with them was, without quite saying so, betting on attacker scarcity. That bet is worse than it was.

The disguise is the clever part. Scripts are built to mimic legitimate OT monitoring solutions [1]. In an environment where reading PLC data blocks is exactly what monitoring software does all day, a tool that reads data blocks is not anomalous. Behaviourally it does what the real thing does, which leaves a rule nothing to catch it on.

I covered a related advisory on August 15, where attackers changed IP addresses and passwords on exposed water sector controllers. That was disruption. This is the stage before it.

Technical breakdown

The advisory sets out the sequence plainly, and it is worth reading as a chain because almost every step is preventable at the first two.

The advisory’s detection guidance is more concrete than most, and worth lifting directly. On reconnaissance, look for sequential IP scanning on port 102, repeated connection attempts with varying parameters, and enumeration of CPU properties. On tooling, look for snap7 library usage outside approved engineering workstations, Python scripts with S7comm functionality, and unauthorised monitoring software installations [1].

Every one of those depends on knowing what normal looks like on your control network. If you cannot list which machines are supposed to talk to your controllers, none of the detections above can be written.

What defenders should do Monday morning

Immediate, within 24 hours. Inventory every S7 controller and record its firmware version, which is the advisory’s first recommended action [1]. In parallel, answer one question: is anything on port 102 reachable from outside your network? Check from outside rather than from a configuration file, because the gap between those two answers is where this threat lives.

Near term, this week. Find every controller still using default or unset authentication and fix it. Then ask your integrators and service providers what remote access they hold into your control network, because the advisory specifically flags asset owners who do not realise third-party access has exposed them [1]. Build the S7comm baseline: which hosts legitimately speak to controllers, and alert on the rest.

Structural, this quarter. Work through the joint guidance on primary mitigations for operational technology, which is the general version of everything above [2]. Then take the wider point the advisory makes in its own opening note: this activity is broader than Siemens, and the same reasoning applies to any PLC you own [1]. Treat this as a prompt to fix the class of problem rather than one vendor’s share of it.

Checklist

• Every S7 controller inventoried with firmware version recorded
• External check performed for anything answering on port 102
• PLCs removed from internet exposure, remote access behind VPN or gateway
• Default and unset PLC authentication identified and changed
• Third-party integrator remote access enumerated and documented
• Baseline built of hosts permitted to speak S7comm
• Alerting for S7comm from anything outside that baseline
• Hunting for snap7 library use outside approved engineering workstations
• Same review extended to non-Siemens PLCs in the estate

The barrier that was doing the work

Security in industrial environments has quietly rested on obscurity for decades, and not the useless kind. The protocols are old, poorly documented in public, and unlike anything an IT attacker has seen. That genuinely reduced the number of people who could do damage, even while the devices themselves stayed wide open.

It was never a control. It was a moat, and the profession knew it and mostly declined to say so, because the alternative was expensive.

What an advisory like this really announces is that the moat is being drained by something nobody has to be clever to use. The vulnerabilities are the same ones that have been in these devices for years. The exposure is the same exposure that has been documented in advisory after advisory. The only variable that changed is how many people can turn that into a working script, and that variable was the one holding the whole arrangement together.

The mitigations have not changed either, which is the uncomfortable part. Get the controllers off the internet and put credentials on them. That advice is older than the threat, and it was affordable when it was first given.