AI-Built Exploits Are Probing Siemens S7 PLCs: What AA26-231A Means for Critical Infrastructure

Someone is actively probing internet-exposed Siemens S7 PLCs in U.S. critical infrastructure, and they are using AI to write the tools. That is the core finding of joint advisory AA26-231A, released August 19, 2026 by the NSA, CISA, FBI, Department of Energy and EPA.

Five agencies do not co-sign an advisory over a theoretical risk. The authors say so plainly: this is an active threat, not a hypothetical one. The activity spans energy, water and wastewater, food and agriculture, chemical, critical manufacturing and commercial facilities.

For anyone who runs or secures a plant floor, this one is worth an hour of your time this week. Here is what the activity looks like, why the AI piece matters, and what to do about it.

How the activity works

The tradecraft is simple, which is exactly the problem. Per the advisory, the actors work through a short, repeatable chain:

1. Find targets. Internet scanning services such as Censys and ZoomEye surface S7 controllers that are exposed or poorly segmented, often running old firmware.
2. Get in. Many of those devices have default or minimal authentication, so no exploit is needed at all.
3. Build the tool. AI generates Python scripts around snap7.dll and python-snap7, open-source libraries that legitimate integrators use every day.
4. Blend in. The scripts are dressed up to look like ordinary OT monitoring software.
5. Read, then write. Over S7comm on TCP port 102, the tools read and write PLC memory, data blocks, configuration and ladder logic.

The agencies assess this as persistent reconnaissance and capability development. Read access maps the process today. That map is what an actor needs to write to the controller later, at a time of their choosing.

Why the AI angle matters, and what it doesn't change

Snap7 has made S7comm easy to script for well over a decade. What AI changes is speed and skill. A low-skill actor can now go from a scan result to a working read/write tool in an afternoon, then rework it when a defense blocks them.

That erases a quiet assumption many small operators have relied on: that nobody sophisticated would bother with a rural water plant or a single production line. Sophistication is no longer the gate. Exposure is.

“Sophistication is no longer the gate. Exposure is.”

What AI does not change is the physics of the attack. The actor still needs to reach TCP port 102, still needs weak or missing authentication, and still has to generate S7comm traffic that a watching defender can see. Every one of those is something you control.

Who is exposed

The advisory names five controller families, spanning legacy installs to current safety PLCs:

The F-series line deserves a second look. Safety controllers govern interlocks and emergency shutdowns, and the advisory lists manipulation of those systems among the possible impacts.

The agencies are also clear that this is broader than Siemens. Any PLC owner should treat the guidance as applying to their fleet.

The gap we see most often is third-party access. An integrator's remote connection, set up years ago for convenience, can leave a controller reachable without the owner knowing it. The advisory calls this out directly and asks owners to share it with their integrators and service providers.

What to do now

The advisory lists seven hardening steps. If you can only start on a few this week, start here, roughly in this order:

1. Know what you own. Inventory every S7 controller and its firmware version, and check it against your gold-copy backups. Map every engineering workstation with TIA Portal or STEP 7 access.
2. Close the front door. Audit firewall rules for TCP port 102 and block it at the perimeter. A PLC should never answer the internet.
3. Find the side doors. List every vendor and integrator with remote access. Require MFA, and confirm there is no unplanned routing between corporate and plant networks.
4. Turn on what's already there. Enable PLC password protection and Siemens protection levels. Restrict programming access to approved workstations by IP or MAC allowlisting.
5. Watch the right signals. The advisory's detection guidance is specific. Alert on:
   • S7comm connections from anything that isn't an approved engineering workstation
   • PUT/GET writes to data blocks or configuration memory
   • Activity outside maintenance windows, or changes with no work order behind them
   • Python processes importing snap7.dll
   • Sequential scanning on port 102
6. Patch with care. Update firmware and engineering software, prioritizing anything Internet-facing or in a DMZ. Test first; an outage you cause yourself is still an outage.
7. Trim the attack surface. Disable onboard web servers, unused protocols and default SNMP community strings.

If you see signs of this activity, report it to CISA (contact@cisa.dhs.gov, 1-844-729-2472) or the FBI via IC3. Energy-sector entities should also follow their DOE reporting requirements.

How ThreatSpire helps

ThreatSpire was built by practitioners who have spent more than 25 years defending energy, utility and industrial environments, including NERC CIP programs. We know a plant can't just reboot for a patch, and that the integrator's laptop is often the real perimeter. Our work maps directly to this advisory:

• OT exposure assessment. We find what an attacker's scanner would find first: internet-reachable controllers, open port 102, forgotten vendor tunnels and flat paths between IT and OT.
• Asset and access inventory. We build the PLC, firmware and engineering-workstation inventory the advisory asks for, plus a register of every third party with remote access.
• Segmentation and hardening. We design DMZ and access-control changes that close the gaps without disrupting operations, and we work alongside your integrators to implement them.
• Early-warning deception. Our platform's honeypots give you a tripwire. An adversary probing for S7 targets touches a decoy before production, and you learn about it on your terms.
• Threat intelligence for OT. We track campaigns like this one and translate them into specific detections and actions for your environment, not generic bulletins.
• Compliance alignment. For NERC CIP and other regulated entities, we tie these fixes to the evidence auditors expect, so security work and compliance work move together.

Sources