NSA/CISA AA26-231A: Attackers Are Using AI-Written snap7 Scripts Against Internet-Exposed Siemens S7 PLCs

Introduction

On August 19 NSA, CISA, FBI, DOE, and EPA published joint advisory AA26-231A: an active campaign against Siemens S7 Series PLCs that sit on the internet or are poorly segmented from it. Actors use scanning services (Censys, ZoomEye) to find S7-200/300/400/1200/1500 CPUs, then AI-assisted Python that wraps snap7.dll / python-snap7 to look like OT monitoring software. Those tools speak S7comm and get read/write to memory, configuration, and ladder logic. The agencies' line: "This is not a theoretical risk — it is an active threat." Target sectors: critical manufacturing, energy, water, chemical, food and agriculture, commercial facilities, with DIB in the blast radius.

What Happened

S7comm on TCP 102 was never meant to face the internet. The advisory does not name a single new CVE as the whole story. It describes a capability shift: public PLC docs plus AI coding assistants plus an open-source S7 library equal working read/write tooling without a boutique ICS malware shop. Scripts masquerade as legitimate monitors. Default or empty credentials on exposed CPUs are enough for some models. Known critical/high S7 CVEs get piled on when the firmware is stale.

Observed technique list from the CSA: internet scanning for exposed PLCs; rapid AI iteration of exploit/monitor scripts; default-auth abuse; snap7-based read/write on data blocks for recon and pre-positioning; masquerading as monitoring tools.

The agencies stress the activity is broader than Siemens. Any internet-exposed PLC, any vendor, should take the same mitigations. They also flag third-party integrators with remote access — the asset owner often does not realize the CPU is reachable.

Potential impact language is ICS-standard and still the point: process disruption, safety-interlock tampering, equipment damage, stolen recipes, cascading plants.

Why It Matters

Water and manufacturing already had a brutal 2026. AI does not invent S7comm; it collapses the skill floor so more actors can poke TCP 102. If your historian, jump box, or cellular router NATs 102 to a CPU "so the vendor can support us," you are in the scan set. Read access today is the map for a write to a fail-safe tomorrow.

Who Is Affected

  • Siemens S7-200, S7-300 (including 314/315/317), S7-400, S7-1200 (1211C–1217C), S7-1500 (including F-series safety CPUs)
  • Any PLC of any vendor reachable from the internet or from IT without a real OT DMZ
  • Plants whose integrators have persistent remote paths to CPUs
  • Water, energy, chemical, food, manufacturing, commercial facilities in the US (named); everyone else with S7 on a public IP

How to Protect Yourself

1. Inventory every S7 CPU and prove it cannot be reached from the internet.

# from an IT jump host you control — TCP 102 should NOT answer from WAN
nmap -Pn -p 102 --open -iL s7_mgmt_ips.txt

Pull the list from TIA Portal / Step 7 / your CMDB. If Censys can see it, so can they. NAT off. Put engineering access on a VPN into an OT DMZ, not a 1:1 port forward.

2. Patch firmware to Siemens's current security notices for that CPU family. The advisory's first mitigations are inventory and "apply critical security patches." Match each CPU's MLFB to Siemens ProductCERT; do not assume S7-1500 current means S7-300 is fine.

3. Harden S7comm. Disable unused services. Set passwords that are not factory defaults. Prefer S7 Communication over TLS / PLC protection levels your firmware actually supports. Treat ladder-logic downloads as change-controlled — unexpected block writes are the hunt.

4. Monitor the OT network for snap7-shaped sessions.

# example: Zeek/Suricata on the OT SPAN — alert TCP 102 from non-engineering stations
# hunt python processes named like monitors on jump boxes
ps aux | grep -i snap7

Look for new "monitoring" Python on vendor laptops, 102 from internet or from IT user subnets, and logic-block changes that do not match a work order.

5. Assume an internet-exposed CPU was read. Compare current blocks to a known-good project archive. If you cannot, treat safety systems as possibly altered and run the process-safety playbook, not just an IT ticket.

Source