AI-Generated Exploits vs Siemens S7 PLCs: Reading AA26-231A

On the nights of 26 and 27 July 2026, more than thirty community water and wastewater systems across Minnesota were probed and manipulated over the same weekend, and one city's treatment plant was temporarily taken offline. Three weeks later, five US federal agencies — the NSA, CISA, the FBI, the Department of Energy and the EPA — put out a joint advisory that named the accelerant: attackers are now using AI to write the exploit code aimed at internet-exposed Siemens S7 programmable logic controllers. The advisory, AA26-231A, does not hedge. "This is not a theoretical risk — it is an active threat."

That sentence is worth sitting with, because the security industry has spent two years debating whether AI would ever produce a working exploit against a real target. The debate is over. It did, against the one class of device that is hardest to defend and least able to defend itself: an industrial controller that regulates the pressure in a drinking-water main.

What advisory AA26-231A actually says

Strip the phrase "AI-powered" — which the wire coverage leaned on — and read what the agencies actually documented. Threat actors are generating custom Python tooling that speaks to Siemens S7 PLCs using the open-source python-snap7 library and the underlying snap7.dll. The scripts communicate over S7comm, the native Siemens protocol, and are packaged to look like legitimate OT monitoring software. Once connected, they read and write PLC memory, configuration data, and ladder-logic programs — the actual control code that decides whether a pump runs or a valve opens.

The models affected span nearly the entire installed base: S7-200, S7-300 (the 314/315/317 CPUs), S7-400, the S7-1200 line (1211C through 1217C), and the S7-1500 series — including the F-series safety controllers whose entire job is to prevent a process from reaching a dangerous state. Targeting spans Water and Wastewater, Energy, Critical Manufacturing, Chemical, Food and Agriculture, and Commercial Facilities.

The agencies' own summary is the part defenders should quote to their boards:

The combination of known vulnerabilities, accessible exploitation libraries, and AI-assisted development creates a high-probability attack scenario against inadequately protected PLC installations.

Read that as an equation. None of the three inputs is new. python-snap7 has been on GitHub for years. The S7comm weaknesses are a decade old. What changed is the third term — the cost of turning the first two into a working, target-specific tool dropped to near zero.

Why Siemens S7 is the perfect target for an AI exploit-writer

There is a reason the models converged on this protocol, and it is not sophistication. It is the opposite.

Classic S7comm — the dialect spoken by the S7-300 and S7-400 families that still run a large share of the world's water and energy infrastructure — has no concept of a user or a session. There is nothing to authenticate against. Reaching the device on TCP port 102 (ISO-TSAP) is the authorization. If you can route a packet to it, you can issue commands to it. The newer S7-1200 and S7-1500 lines added access-protection levels and optional TLS, but in the field they are routinely deployed at the default level with legacy PUT/GET communication enabled for backwards compatibility, which reopens the same door.

Now layer on exposure. Public Shodan data still shows on the order of 74,000 ICS devices directly reachable from the open internet, many running default or absent credentials. The attackers do not even need to scan for them: the advisory notes reconnaissance through commercial internet-scanning services like Censys and ZoomEye, which have already indexed port 102 for them.

For a language model asked to "write a Python tool that reads and writes ladder logic on a Siemens S7-300 over S7comm," this is close to the easiest offensive task imaginable:

• The protocol is documented and stable.
• A mature library (python-snap7) already wraps it.
• There is no authentication logic to defeat — no fuzzing, no memory corruption, no exploit primitive to develop.
• Thousands of live, addressable targets are pre-indexed by third parties.

The AI is not discovering a zero-day here. It is doing something more corrosive: it is removing the last remaining barrier — the specialised OT knowledge and the hours of scripting — that used to keep a mid-tier threat actor away from a control system. That is the real content of AA26-231A.

From Aliquippa to Minnesota: the pattern the AI just accelerated

This is not the first time an Iran-aligned group has walked into a US water utility through a PLC. In November 2023, the persona CyberAv3ngers, attributed to the IRGC's Cyber Electronic Command, compromised at least 75 internet-exposed Unitronics Vision-series PLCs across the US, Israel, the UK and Ireland. One of them regulated a booster station at the Municipal Water Authority of Aliquippa, Pennsylvania. The entire "exploit" was the device's shipped default password. CISA documented it in advisory AA23-335A.

The 2026 Minnesota wave — 30-plus systems in a single weekend, again with suspected CyberAv3ngers involvement — is the same playbook with the effort removed. In 2023, hitting 75 devices across four countries was a manual campaign. In 2026, generating a per-family Siemens script and pointing it at a Censys export is an afternoon. The delta between those two operations is exactly the delta an AI assistant closes.

	Aliquippa, Nov 2023	Minnesota, Jul 2026
Target	Unitronics Vision PLC	Siemens S7 PLCs
Entry	Shipped default password	Internet exposure + weak/default creds
Tooling	Manual, hands-on-keyboard	AI-generated python-snap7 scripts
Scale	~75 devices, a campaign	30+ systems in one weekend
Disguise	None	Packaged as OT "monitoring" tools

What "AI-generated" actually changes

It is tempting to dismiss this as marketing — the agencies putting "AI" in a headline. That reading is wrong, and the operational details show why.

First, the skill floor collapses. Writing a correct S7comm client that manipulates ladder logic without bricking the CPU used to require someone who understood both the protocol and the process. A model that has ingested the python-snap7 docs and a few forum threads produces that tool on request, and iterates when it throws an error.

Second, the tooling is shaped to blend in. The advisory specifically flags that the scripts masquerade as legitimate OT monitoring software. An engineer glancing at a process running python-snap7 and polling PLCs sees exactly what a real historian or SCADA poller looks like. The malicious read/write blends into the legitimate read/write.

Third, and most important for defenders: none of this is patchable on your schedule. You cannot reboot a water treatment PLC on a Tuesday to install a fix. Many affected devices are years past their last firmware update and will never receive another. The vendor advisory's own top recommendation is not "patch" — it is "make sure the controllers are not accessible from the internet." When the primary mitigation is "unplug it from the thing it should never have been plugged into," you are managing a design-era exposure, not a software bug.

Remediation

Treat AA26-231A as a hunt-and-harden mandate, not a patch ticket. The full Cybersecurity Advisory PDF is the authoritative source; the runbook below is the operational distillation.

1. Am I affected? Inventory every S7-200/300/400/1200/1500 in the estate — including F-series safety controllers. From an engineering host, confirm which respond on TCP/102:

nmap -Pn -p 102 --open <ot-subnet>/24

Then check whether any of those addresses are reachable from outside your OT boundary. Search your own external footprint on Shodan/Censys for port:102 and your ASN/IP ranges. Any hit is an incident, not a finding.

2. Patch — the exact fixed state. There is no single CVE fix here; the "patch" is a configuration and firmware posture:

• Update S7-1200/1500 firmware to the current release and set the access-protection level to "Full protection" (no anonymous access).
• Disable legacy PUT/GET communication on S7-1200/1500 unless a specific application requires it.
• Set a strong PLC password and TIA Portal project protection; retire any device still at factory defaults.
• For S7-300/400, which cannot enforce authentication, treat firmware hardening as insufficient on its own and move straight to isolation.

3. Can't patch now? — compensating controls.

• Remove port 102 from any internet-facing path. No S7comm should ever traverse the perimeter.
• Enforce a hardware or firewall segmentation boundary; permit S7comm only from named engineering workstations via explicit allow-list ACLs.
• Deploy a data diode or unidirectional gateway for any monitoring that must cross from OT to IT.
• Restrict who can reach the engineering VLAN; kill flat networks where a compromised HMI can talk to every controller.

4. Hunt for compromise — signals and ATT&CK for ICS. The write side of S7comm is where the damage lives. Hunt for it on the wire and in engineering logs:

• New TCP/102 sessions from hosts that are not designated engineering stations — map to T0883 (Internet Accessible Device) and T0812 (Default Credentials).
• S7comm write / program-download function codes to controllers outside a change window — T0843 (Program Download) and T0836 (Modify Parameter).
• STOP-CPU command messages issued outside maintenance — T0855 (Unauthorized Command Message), a precursor to T0814 (Denial of Service).
• Inbound connections from known Censys/ZoomEye scanner ranges hitting port 102.
• A process named or behaving like OT monitoring software but originating from an unexpected host or user — the "disguised tool" signature.

5. Eradicate + verify. If you find unauthorised writes: capture the current ladder logic, compare it byte-for-byte against your known-good engineering baseline, and re-download the verified program from source control — never trust the copy on the device. Rotate every PLC and engineering-station credential. Then confirm clean after re-segmentation, by verifying that no external path to port 102 remains and that only allow-listed hosts appear in fresh S7comm session logs.

The network is the only place you'll see this

Here is the uncomfortable truth AA26-231A forces: you cannot put an agent on an S7-300. There is no EDR for a controller from 2009. The device speaks a protocol with no login, it cannot be patched on your timeline, and the malicious traffic is shaped to look like the monitoring traffic you expect. The only surface where an unauthorised write to ladder logic, a STOP-CPU command, or a scanner sweep across port 102 becomes visible while it is happening is the network itself.

That is precisely the case Zero Hunt's AI Traffic Analysis was built for. A proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, and application fingerprinting — runs locally on the appliance GPU at 2.7+ Gbit/s, with no cloud callback. It reads OT/ICS protocol anomalies behaviourally: an S7comm write command from a host that has never spoken S7comm before, a program download outside a change window, the fan-out signature of a script sweeping port 102 across a subnet. It flags the manipulation as it crosses the wire — not in the next morning's SIEM digest, by which time a pump has already run dry.

The complement is finding the exposure before the adversary's AI does. Zero Hunt's 10-agent generative swarm with change-triggered campaigns treats a newly internet-exposed PLC as a trigger: a new asset on the perimeter launches a full validation campaign within the hour, and the Recon and Exploit agents prove which of your S7 controllers are actually reachable and default-credentialed — the same reasoning the attacker's model runs, executed on your side first, with every finding ECDSA-signed for the EPA, AWIA and NIS2 evidence trail that water and energy operators now have to produce. The attacker automated the exploit-writing. The only durable answer is to automate the seeing and the validating — continuously, on the one surface a PLC cannot hide from.