Email: contact@nordcs.de
Phone: +49 176 240 73665
Address: Rheinpromenade 11, 40789, Monheim am Rhein
NSA, CISA, FBI, DOE and EPA warn of an active campaign using AI-generated Python tooling against Siemens S7 PLCs. Why signature and volume-based detection miss it, and what to baseline instead.
On 19 August 2026, the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency published a joint advisory that engineers responsible for industrial control systems should read in full: AA26-231A, "Defending Against an Active Threat to Siemens S7 Series PLCs." It describes an active, ongoing campaign, not a theoretical risk. And the detail that makes it worth a deep technical look is not the vulnerability, it's the tooling. The traffic hitting these controllers is valid S7comm. No malformed packets, no memory corruption, nothing a signature-based IDS is built to catch.
Threat actors are targeting the full Siemens S7 Series line: S7-200 (all CPU variants), S7-300 (including the 314, 315 and 317 models), S7-400, S7-1200 (CPU 1211C through 1217C) and S7-1500, including the F-series safety controllers. The sectors most affected are critical manufacturing, energy, water and wastewater, chemical, food and agriculture, and commercial facilities. Siemens S7 PLCs also appear in the Defense Industrial Base.
The tradecraft, mapped to MITRE ATT&CK for ICS and Enterprise, breaks down like this:
Reconnaissance (T1596.005): actors use internet scanning services, Censys and ZoomEye specifically, to find Siemens S7 PLCs that are exposed directly to the internet or poorly segmented from IT networks.
Resource development (T1587.004, T1588.007): exploit code is developed and rapidly iterated using AI assistance. The advisory is explicit that this is the significant shift, AI collapses the time and expertise needed to go from a public vulnerability writeup to working ICS exploitation tooling, and to reshape that tooling once a defender deploys a detection.
Execution (T0834): AI-generated Python scripts built on the open-source snap7.dll / python-snap7 library talk to the PLC over S7comm.
Evasion (T0849): the tools are deliberately shaped to masquerade as legitimate OT monitoring software.
Lateral movement (T1694): where authentication on the PLC is default or minimally configured, no exploit primitive is even required to get read/write access.
Collection (T0893) and impact (T0821): actors read data blocks, memory, configuration data and ladder logic for reconnaissance, and write to them, which the authoring agencies assess is likely pre-positioning for future disruptive effects rather than opportunistic vandalism.
Every one of those steps produces syntactically correct S7comm on TCP/102. A signature engine has nothing to match against, because there is no malformed Job/Ack-Data exchange to flag, the protocol is being used exactly as specified. Flow-level anomaly detection tuned on packet volume or byte counts fares no better: a script quietly polling fifty data block addresses once a minute is indistinguishable, by volume, from a historian or SCADA client doing its job. This is the core engineering problem the advisory surfaces without stating it outright, the signal that separates attacker from operator is not in the payload. It's in who is allowed to do what.
Network layer, baseline S7comm per client identity rather than per subnet. For every legitimate engineering workstation, HMI and historian, define which functions it is allowed to call, read var (function code 0x04) versus write var (0x05), which data block numbers and offsets belong to its role, and during which change windows writes are expected. Once that baseline exists, the high-value alerts become cheap to define: any write from a source that has only ever read, any first-time source/PLC pairing, CPU property enumeration, or sequential connection attempts across TCP/102 within a cell. These are the detections in D3FEND's Network Traffic Analysis and Platform Monitoring categories that the advisory itself points to.
Host layer, the engineering workstation is the better chokepoint than the wire. Application allowlisting plus alerting on any process importing snap7.dll that is not sanctioned TIA Portal or STEP 7 gives a single, high-fidelity artifact. That one signal is usually enough to separate "the integrator is doing scheduled maintenance" from "someone is scripting your plant," which is a distinction that pure network telemetry struggles to make on its own.
Controller layer, treat the PLC itself as an asset to harden, not just monitor. Enable protection levels and know-how protection where the CPU supports it, disable the web server and any communication protocol you don't operationally need, cap simultaneous S7comm connection resources, and keep an offline gold-copy of the ladder logic so you can diff online against offline state instead of trusting the PLC to accurately describe itself if it has been tampered with.
Perimeter, this one is unglamorous but it's where most of the exposure in this campaign actually originates: block TCP/102 at the perimeter, verify no exposed engineering interface is reachable from the internet, and audit remote access paths used by systems integrators and managed service providers. The advisory notes explicitly that many asset owners in these findings did not know their PLC was internet-reachable in the first place, often because a third party had set up remote access on their behalf.
For teams running an IEC 62443 programme, this advisory maps cleanly onto requirements you likely already have on a roadmap: SR 1.1 and SR 1.2 in 62443-3-3 for identification of human and software users, which is exactly what per-client S7comm baselining operationalizes; SR 5.1 for network segmentation; SR 6.2 for continuous monitoring; and 62443-2-4 for the security requirements you should be placing on integrators and service providers with remote access to your PLCs. If you're building or updating a threat and risk assessment for an OT asset that includes S7 Series controllers, this campaign is a concrete, citable threat scenario for the attacker analysis, not a hypothetical.
It's worth being precise about what AI is and isn't doing in this campaign. It is not generating novel vulnerabilities or zero-days, every technique listed uses known weaknesses, default credentials and internet exposure. What it's industrializing is the boring, previously time-consuming work: correlating public vulnerability data with a specific CPU model, writing working protocol client code, and re-shaping that code when a defense changes. That's a capability uplift for a much larger population of less-skilled actors, which is precisely why the authoring agencies are treating this as urgent rather than niche.
Defenders have access to the same kind of lever, and this is a legitimate, low-risk place to use it. A model is genuinely useful for reconciling an asset inventory against firewall rules and change tickets, for enriching an S7comm alert with the context an analyst needs to triage it in seconds instead of minutes, or for summarizing which of your PLCs fall inside the models named in this advisory. What doesn't belong is a model anywhere in the control loop that can act on the PLC. Keep AI strictly advisory in the read path. A false positive from a detection model costs you an analyst's time; a false action from a model with write access to a controller costs you an availability or safety incident.
If you own Siemens S7 Series PLCs, the advisory's own priority order is a reasonable place to start: inventory every S7-200 through S7-1500 device and its firmware version against your gold copy, confirm none are directly internet-reachable, verify protection levels and access controls are actually configured rather than assumed, and get ICS-aware monitoring in place on TCP/102 if you don't have it. Then move to the identity-based baselining above, because patching and segmentation close the door this specific campaign is using, but per-client S7comm behavior baselining is what catches the next one.
Sources
Full advisory PDF, including MITRE ATT&CK for ICS and D3FEND mappings
Email: contact@nordcs.de
Phone: +49 176 240 73665
Address: Rheinpromenade 11, 40789, Monheim am Rhein
E-Mail: contact@nordcs.de
Telefon: +49 176 240 73665
Adresse: Madrider Str. 7, 60327 Frankfurt a. Main, Germany
