Advisory AA26-231A: Active Threat to Siemens S7 PLCs, Exploitation Scripts Generated with AI

What the advisory says

On 19 August 2026 the National Security Agency, CISA, the FBI, the Department of Energy and the Environmental Protection Agency published joint advisory AA26-231A on an active threat against Siemens S7 Series PLCs that are exposed to the internet or insufficiently segmented.

The text is explicit on one point: "This is not a theoretical risk, it is an active threat." This is not a vulnerability bulletin, it is a description of activity already under way.

It is equally explicit on a second point, worth reading before everything else: PLC targeting activity is broader than Siemens alone. The Siemens-specific content should be understood as one subset of a wider phenomenon, and the agencies ask all PLC owners, whatever the brand, to apply the relevant mitigations.

The models under active targeting:

• S7-200 Series, all CPU variants
• S7-300 Series, all CPU variants including 314, 315, 317
• S7-400 Series, all CPU variants
• S7-1200 Series, CPU 1211C, 1212C, 1214C, 1215C, 1217C
• S7-1500 Series, all CPU variants, including F-series safety controllers

The most heavily targeted U.S. sectors are Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture and Commercial Facilities, with potential exposure in the Defense Industrial Base as well. The overlap with the European industrial base is nearly total.

How the chain works

The advisory describes a simple flow, and that is exactly why it works.

Reconnaissance through internet scanning services. The actors use platforms such as Censys and ZoomEye (T1596.005) to find exposed S7 PLCs running outdated software or otherwise poorly protected. No scanning of their own, no noise: they query a database that is already built.

AI-assisted exploit development. The actors generate scripts with AI assistance from publicly available information on S7 PLCs, iterating rapidly on the code (T1587.004, T1588.007). The advisory calls this an evolution in threat actor capabilities, because it dramatically reduces the technical expertise and time required to build working ICS tooling, and lets adversaries adapt quickly to defensive measures.

Insecure credentials. Many exposed devices have unconfigured or minimally configured authentication (T1694). It is not that authentication does not exist: it was never turned on.

Python scripts on snap7. The generated scripts incorporate the snap7.dll / python-snap7 library from public repositories (T0834) and obtain read and write access to PLC memory, configuration data and ladder logic programs over the S7comm protocol on TCP port 102.

Masquerading as monitoring tools. The scripts are deliberately built to mimic legitimate OT monitoring solutions and evade security teams (T0849).

Read and write operations on data blocks (T0893, T0821), for reconnaissance, capability testing or pre-positioning.

The agencies' assessment of that last point is the part that should matter most to anyone running a plant: this is likely persistent reconnaissance intended to prepare operational effects against critical infrastructure. Read access serves to understand the environment, in order to position for future write operations.

No new CVEs, and that is the news

The advisory names not a single CVE. Siemens, asked by the press, stated it had identified neither increased attack levels nor unknown vulnerabilities in its ICS products: the attacks exploit misconfigurations already known.

Both statements are compatible, and together they say the important thing. All the ingredients were already on the table: python-snap7 has been public for years, PLCs on the internet are a documented problem, PLC password protection has always existed and often goes unused. What changed is the cost of entry. Writing a tool that reads and writes to an S7-300 used to require industrial automation skills. It no longer does.

It is the same mechanism described in AI, from payload to APT: AI does not create novel vulnerabilities, it widens the pool of people who can exploit the existing ones. Which changes the risk profile even for organizations that considered themselves too small to interest a state actor.

What to look for: the detection opportunities

This is the most useful section of the advisory, because a script disguised as a monitoring tool generates traffic that looks like legitimate traffic. What distinguishes it is not the signature, it is the context. The agencies list five families of anomalies to hunt for:

• Anomalous S7comm behavior: connections from hosts that are not engineering workstations, unusual data block access patterns, write operations outside change windows.
• Reconnaissance indicators: sequential IP scanning on port 102, repeated connection attempts with varying parameters, enumeration of CPU properties.
• Tool artifacts: snap7.dll usage outside approved engineering workstations, Python scripts with S7comm functionality, unauthorized monitoring software installations.
• Temporal anomalies: off-hours S7comm activity, connection patterns consistent with automated scripting rather than human operators, configuration changes with no matching work order or change ticket.
• Geographic anomalies: connections originating from countries or IP ranges not associated with vendors or integrators.

The common thread is that none of these is detectable without a baseline of OT traffic. Knowing that a data block write is anomalous requires knowing what a normal day on that network looks like.

The mitigations, in order of return

The advisory lists seven groups of hardening actions. In summary, with the details that matter:

1. Immediate inventory of all S7 PLCs: verify firmware versions against the backup gold copy, identify systems reachable directly or indirectly from untrusted networks, map every workstation with TIA Portal, STEP 7 or S7 programming access.
2. Patching: firmware to the latest versions, priority to internet-facing or DMZ-resident controllers, update TIA Portal and STEP 7 as well, consult Siemens ProductCERT advisories, test in a development environment before production.
3. Segmentation: audit firewall rules for exposed S7comm services, block TCP port 102 entirely at perimeter firewalls, implement a DMZ architecture separating OT and IT, deploy unidirectional gateways for historian connections, verify there is no unauthorized routing between corporate and industrial networks.
4. Access controls: MAC/IP allowlisting on PLCs to restrict TIA Portal/STEP 7 access to authorized workstations only, PLC password protection enabled on every S7, protection levels configured (write or read/write protection), default SNMP community strings removed, application allowlisting on engineering workstations, MFA on all remote access to OT.
5. Logging and monitoring: ICS-aware intrusion detection, monitoring of all S7comm traffic on port 102 for connections outside maintenance windows, alerts on unauthorized PUT/GET operations (especially writes to data blocks and configuration memory), logging of all TIA Portal/STEP 7 connections with timestamps and source IPs, a baseline of legitimate behavior with alerting on deviations, monitoring for Python processes importing snap7.dll.
6. S7-specific hardening: disable web servers where not operationally required, disable unused protocols (Modbus TCP, PROFINET if not needed), limit simultaneous S7comm sessions through connection resources, enable complete restart protection and know-how protection where available, evaluate ladder logic changes in online and offline modes.
7. Siemens: engage technical support for guidance specific to your CPU models and firmware versions, verify patch compatibility with your environment and third-party integrations.

One warning the advisory repeats twice deserves particular attention: these mitigations are especially important for organizations working with service providers or system integrators that have remote access to PLCs, because the asset owner may simply not realize it is exposed. The agencies ask that the advisory be shared with those parties and its implementation requested.

A note for European readers: the incident reporting guidance in the advisory points to CISA, the FBI and DOE. In the EU the channel is the national CSIRT, with the notification timelines set by NIS2 for entities in scope.

Three checks to close this week

• Look for exposed port 102 from the outside, not on the segmentation spreadsheet. Include vendor remote access and the 4G routers installed for one intervention and never removed.
• Count the S7 PLCs actually present: model, firmware, who talks to them. If the number does not match the official inventory, the problem predates the advisory.
• Ask whether an S7comm write from a new host would raise an alert. If the answer is no, the advisory describes a scenario you would not be able to see.

The resource

The full advisory, with MITRE ATT&CK for ICS and D3FEND mappings in the appendices, is available here:

• Defending Against an Active Threat to Siemens S7 Series PLCs, official PDF (AA26-231A)
• CISA advisory page

The MON5 angle

The advisory's detection opportunities describe, point by point, what is only visible when OT traffic is observed continuously: S7comm connections from unexpected hosts, data block writes outside the window, scanning patterns on port 102, off-hours activity with the timing signature of a script rather than an operator.

MON5 does passive, out-of-band NDR on native industrial protocols, Siemens S7 included, with anomaly detection against the operational baseline. It is the approach that answers mitigation point 5 without touching the PLCs: no agents, no active polling, no additional S7comm sessions on controllers that only support a limited number.

The starting point, though, remains the inventory, not the tool. An OT assessment closes the three checks listed above in a few weeks, without stopping production.