On August 19, 2026, the NSA, CISA, FBI, Department of Energy, and Environmental Protection Agency published joint advisory AA26-231A, "Defending Against an Active Threat to Siemens S7 Series PLCs". The headline detail is one the OT security community has been bracing for: attackers are using AI-generated code to build the tooling they're pointing at industrial controllers (BleepingComputer, SecurityWeek).

This isn't a novel zero-day in a Siemens product. It's something more uncomfortable: commodity attack capability against PLCs, assembled faster and by less specialized operators than before, aimed at controllers that should never have been reachable from the internet in the first place.

What the advisory actually describes

Per the advisory and the coverage of it, the threat actors are writing Python exploitation scripts that lean on the open-source snap7.dll / python-snap7 libraries to speak the S7comm protocol directly to Siemens controllers. The scripts are disguised as legitimate OT monitoring tools, and they give an operator read and write access to PLC memory, configuration data, and ladder-logic programs (BleepingComputer, TechTimes).

That combination matters. python-snap7 is a legitimate, publicly documented library that engineers use for exactly this kind of PLC communication. Nothing about it is malicious on its own — which is precisely why scripts built on it don't look like malware to endpoint tooling. There's no exploit of a memory-corruption bug here; the scripts are using the controller's own protocol to do what the protocol allows.

The reported targeting spans the S7 line broadly: the S7-200, S7-300 (including 314, 315, and 317 CPUs), and S7-400 families, plus the newer S7-1200 (CPU 1211C, 1212C, 1214C, 1215C, 1217C) and S7-1500 series — the last of which includes F-series safety controllers (TechTimes). The named critical-infrastructure sectors are Critical Manufacturing, Energy, Water and Wastewater Systems, Chemical, Food and Agriculture, and Commercial Facilities.

Why "AI-generated" is the part that matters

It's tempting to file the AI angle under hype. It isn't, for a specific and unglamorous reason: PLC attack tradecraft has historically required an operator who understands both the target protocol and the physical process well enough to do damage without immediately breaking the thing they're inside. That knowledge was a barrier. AI coding assistants lower it.

The mechanism described in the advisory is generation of Python scripts from publicly available technical information, known weaknesses, and open-source automation libraries (SecurityWeek). None of those inputs are secret. What changes is the speed and the level of specialization required to turn them into a working tool. An operator who couldn't have written a clean snap7 client from scratch a year ago can now iterate one into existence in an afternoon, disguised as monitoring software.

For defenders, the practical takeaway isn't "AI is scary." It's that the population of people capable of manipulating an exposed S7 controller just got larger, and the tooling they produce is intentionally shaped to blend in with normal engineering traffic. That raises the value of every control that assumes the attacker has to be reachable, authenticated, and expert — because increasingly they only need to be the first of those.

The exposure is self-inflicted

The scripts are the story people will remember. The reason they work is more mundane. According to the advisory coverage, the actors locate targets using internet-scanning services like Censys and ZoomEye, hunting for S7 PLCs with S7comm exposed on TCP port 102 — often running outdated firmware or default passwords (SecurityWeek, TechTimes).

A PLC answering S7comm on port 102 from a public IP is the actual vulnerability. The AI-generated client is just what shows up once the door is found standing open. This is why the advisory's priority directive isn't "patch" — it's to take internet-exposed Siemens S7 PLCs offline entirely. Firmware updates and password hygiene are follow-ups; removing internet reachability is the fix that closes the campaign's entire discovery mechanism at once.

This isn't hypothetical

The advisory lands against a real backdrop. Over the nights of July 26–27, 2026, a coordinated attack hit the operational technology of more than 30 Minnesota community water systems simultaneously. In Braham, it disabled computerized operating controls and temporarily shut down the city's well and water-treatment plant; public-works crews restored service in roughly two hours. Plymouth disconnected cellular-connected equipment at two water towers and several wastewater lift stations to stop the intrusion (Fox 9, MPR News, The Hacker News).

Related attacks on municipal water systems were reported in at least seven states that week, prompting the FBI and EPA to warn utilities nationwide; the August advisory and its coverage put confirmed water-system disruptions across at least a dozen states (TechTimes). Attribution remains unofficial — US investigators have described Iranian actors as the likely party while stressing that assessment could change (ABC News). For defensive purposes, attribution is beside the point. The exposure that made these attacks possible is the same whoever is holding the keyboard.

What to do now

The advisory's mitigations are conventional OT-hardening, and their ordinariness is the point — none of this requires new technology, only that it actually be done:

  1. Get S7 PLCs off the public internet. This is the priority directive. If a controller answers S7comm on port 102 from an external address, it's exposed regardless of firmware version. Block TCP port 102 at the perimeter and confirm there's no unintended routing between corporate and industrial networks.
  2. Kill default and weak credentials, and enable the controller's protection levels. Turn on PLC password protection and configure write/read-write protection on S7 devices so an unauthenticated S7comm session can't quietly reprogram logic.
  3. Restrict engineering access to engineering workstations. Limit TIA Portal / STEP 7 connectivity to known, authorized workstations — MAC/IP allowlisting on the PLC where supported — so a snap7-based client from an arbitrary host can't establish a session at all.
  4. Segment properly. A DMZ between IT and OT, and unidirectional gateways for data-historian feeds, remove the flat-network paths these scripts rely on after initial access.
  5. Monitor for the specific behavior. Watch for anomalous S7comm: connections from non-engineering workstations, sequential scanning on port 102, write operations outside change windows, off-hours activity, and snap7/python-snap7 artifacts on hosts that have no business running them. Because the tooling is designed to look legitimate, behavioral detection at the protocol layer matters more than signature-based endpoint controls here.

If you can't quickly answer "is any S7 controller in our estate reachable from the internet, and who can open an S7comm session to it," that gap is the campaign's entire attack surface.

Where MBCTG fits

The uncomfortable lesson in AA26-231A is that the hard part of this campaign was never the exploit — it was the exposed, poorly segmented controller waiting to be found. That's the problem our OT security services are built around: passive asset visibility to find the S7 devices and internet-facing paths you may not know you have, segmentation and protocol-level monitoring against frameworks like IEC 62443 and MITRE ATT&CK for ICS, and detection tuned to anomalous S7comm rather than malware signatures that AI-shaped tooling is designed to slip past.

Our 24/7 SOC is positioned to catch the reconnaissance and lateral-movement stages — the port-102 scanning and out-of-band engineering sessions — before they reach the point where someone is writing to ladder logic. If you run Siemens S7 controllers and haven't confirmed none of them are reachable from the internet this week, that's the one thing worth doing before anything else. Talk to an MBCTG expert.