Five US Agencies Warn

On August 19, 2026, five US agencies put their names on the same document: NSA, CISA, the FBI, the Department of Energy and the Environmental Protection Agency. The subject is active targeting of Siemens S7 series programmable logic controllers in US critical infrastructure, and the notable detail is the tooling. Attackers are running AI-generated Python exploitation scripts that talk native S7comm to the controller and are packaged to look like legitimate OT monitoring software.

Read the capability description carefully, because it is the whole story: read and write access to PLC memory, configuration data, and ladder logic programs. That is not a denial of service or a nuisance crash. That is control of the process logic, with the ability to change what a controller does and to lie to the operator about it.

Which devices are in scope

The advisory names five product families: S7-200, S7-300, S7-400, S7-1200 and S7-1500. That range spans roughly two decades of Siemens automation hardware. The S7-200 and S7-300 lines are long past their design assumptions about network exposure and were built when the security model was a locked cabinet and an air gap. The S7-1200 and S7-1500 have real access protection features, but they ship in configurations where those features are optional and are frequently deployed with them off.

Underneath those families the advisory is more specific than the headline suggests. It covers the S7-300 across all CPU variants and names the 314, 315 and 317 explicitly, the S7-1200 across the 1211C, 1212C, 1214C, 1215C and 1217C, and the S7-1500 across all variants including the F-series safety controllers. That last one deserves its own sentence. An F-series CPU is what holds the safety instrumented function, the interlock that stops the process when a human would be hurt. Read and write access to a safety controller is a different category of problem to read and write access to a batch sequencer, and any inventory that lumps them together is hiding the part that matters.

No CVE identifiers are called out in the advisory, and that is deliberate. Most of this activity is not exploitation of a named memory corruption bug. It is abuse of documented protocol functionality against devices that were never supposed to be reachable from the internet in the first place.

The intrusion chain

The reported sequence is short, which is part of why it works.

• Reconnaissance with commercial internet scanning services, specifically Censys and ZoomEye, to enumerate exposed Siemens PLCs.
• Target selection favoring devices running outdated firmware, devices with known critical or high severity vulnerabilities, and devices with weak or absent authentication.
• Interaction over the S7comm protocol on TCP port 102 using the snap7.dll and python-snap7 libraries.
• Read and write operations against PLC memory, configuration blocks and ladder logic.
• Persistence of access and continued observation of the process, packaged inside binaries presented as OT monitoring utilities.

There is no phishing stage in this chain, no macro, no initial access broker. The exposure is the initial access. If your controller answers on 102/TCP from an arbitrary source address, the attacker has already completed the hard part of most intrusions before writing a line of code.

What the AI part actually changes

Ignore the headline framing for a moment. Large language models do not grant new access to a PLC and do not defeat access protection. What they change is who can write competent OT tooling and how fast. Historically, S7comm exploitation required someone who understood ladder logic, data block layout, Siemens addressing conventions and the protocol quirks between the S7-300 and the S7-1500. That was a small population, mostly nation state teams and a handful of researchers.

An AI assistant that can produce working python-snap7 code compresses that learning curve from months to hours. The result is a wider pool of capable operators, faster iteration against a target, and tooling tailored to a specific site rather than reused off the shelf. For defenders, the practical consequence is that indicator based detection ages faster. Two campaigns against two utilities may share zero file hashes because the scripts were generated per target.

Reconnaissance now, disruption later

The agencies characterize the observed activity as focused on persistent reconnaissance, potentially preparing attackers for disruption. That framing matters for how you triage. The stated risk set includes data theft, equipment damage, extended downtime and safety incidents, but the current behavior is mapping and dwelling, not detonating.

This is consistent with the pattern set elsewhere. Hackers hit Minnesota water utilities in July 2026, and Iranian linked actors targeted Rockwell Automation PLCs in April 2026. Small water and wastewater systems keep surfacing in these reports for the same reason every time: minimal staff, remote access for a contract operator, and controllers reachable from the internet because that was the cheapest way to support them.

Do these five things

• Inventory every S7 controller including the ones behind an integrator's cellular gateway. Devices nobody remembers are the ones that answer on 102/TCP.
• Remove internet exposure. Query Censys and Shodan for your own public ranges and for your integrators' ranges. If a controller must be reached remotely, put it behind an authenticated VPN or a jump host with MFA, never a port forward.
• Apply current Siemens firmware and check the Siemens ProductCERT feed for advisories covering your specific families. The older S7-300 and S7-400 units may have no patch path, which makes segmentation the only control you have.
• Enable PLC access protection. Set write protection and password levels on S7-1200 and S7-1500, and disable unused services. Verify the keyswitch or protection level is not sitting in a permissive state after the last commissioning visit.
• Log and alert on S7comm write functions. Any write to a data block or program block from a source that is not the engineering workstation is worth a page, and stop or run mode changes should be alarmed in the historian, not just the SCADA HMI.

The S7-specific hardening the advisory asks for

The five items above are the ones that decide whether this campaign reaches you. The advisory also lists controller-level settings that most sites never touch after commissioning, and they are worth a maintenance window:

• Know-how protection and complete restart protection. Know-how protection encrypts the block so the logic cannot be read back off the controller; restart protection stops an attacker forcing the CPU through a restart to clear a state. Both are Siemens features already in the firmware, off by default.
• Limit simultaneous S7comm sessions. A controller that accepts one engineering session at a time is a controller an unattended script cannot quietly join alongside the real engineer.
• Disable the built-in web server and any unused protocols, including Modbus TCP and PROFINET, where the process does not need them. Every enabled protocol is a second way in that your S7comm monitoring does not watch.
• Allowlist engineering access by MAC and IP for TIA Portal and STEP 7, and remove default SNMP community strings while you are in there.
• Verify running firmware against a known-good backup rather than trusting the version string the device reports.
• Application allowlisting on every engineering workstation, which is the control that actually stops an unapproved snap7 script from running in the first place.
• Unidirectional gateways for historian traffic where the data only needs to flow one way, and a check that no unauthorised route exists between the corporate and industrial networks.
• Compare ladder logic online against offline, which is how a change that never went through a work order becomes visible.

One more instruction in the advisory is easy to skip and worth acting on: send it to your integrators and managed service providers and ask them to implement it. The document is marked TLP:CLEAR, so you can forward it without restriction. Asset owners frequently do not know their integrator has standing remote access to a controller, and that is the exposure this campaign is built on.

Siemens ProductCERT publishes model-specific hardening guides, and the advisory tells asset owners to contact Siemens for their exact CPU rather than generalising across the range. That is good advice: the protection levels on an S7-1500 do not mean what they mean on an S7-300.

Four more hunt criteria come straight from the advisory and cost nothing to add once you are logging S7comm at all: sessions outside the maintenance window, sessions from an unexpected geography, unauthorised PUT and GET operations against data blocks, and snap7 imports on any host that is not a declared engineering workstation. The last one is an endpoint query rather than a network one, and it is the cheapest of the four to run today.

Also shipped in a standard deployment

• Engineering and SCADA Windows hosts. PowerShell, RDP from a non-jumpbox source, removable media, engineering tools launched outside a window, SCADA services stopped.
• IT to OT correlation. An endpoint alert, admin grant or removable media on a SCADA host, chained to a subsequent OT write from that host.
• Segmentation and flow. Firewall allows into and out of the OT zone, cross-subnet scanning, firewall rule and ACL changes, VLAN and MAC changes on critical ports, device config changed outside a window.
• Behavioural agents. Setpoint drift, control writes nobody can attribute to a person, integrator laptops that never left, silent devices, load divergence.
• Claroty and Dragos ingest, correlated alongside everything else rather than in a second console.

We have covered this pattern all year

RedEye has worked industrial control systems for years. We track federal advisories as they publish, brief local utilities and operators on what applies to them, and build the detection content before the next one lands.

It does map to ATT&CK, and that is the usable part

The advisory carries two appendices most coverage skips. Every behaviour is mapped to MITRE ATT&CK for ICS and Enterprise, version 19, and the countermeasures to MITRE D3FEND 1.5.0. If you are writing detections rather than reading headlines, this is the part to work from:

• T1596.005 Search Open Technical Databases: Scan Databases, the Censys and ZoomEye stage
• T1587.004 Develop Capabilities: Exploits, and T1588.007 Obtain Capabilities: Artificial Intelligence, the AI-assisted iteration
• T1694 Insecure Credentials, devices with default or minimal authentication
• T0834 Native API, the snap7 scripts themselves
• T0893 Data from Local System and T0821 Modify Controller Tasking, the read and write operations on data blocks
• T0849 Masquerading, the tooling dressed as OT monitoring software

The D3FEND side maps the mitigations: D3-HCI inventory, D3-SU patching, D3-NI isolation, D3-NAM access mediation, D3-CH credential hardening, D3-PM platform monitoring, D3-NTA traffic analysis and D3-ACH configuration hardening. If your control framework speaks either language, this advisory drops straight into it.

The limit of this advisory

No threat actor is named, no CVE is listed, no exposure count is published, and no file hashes are provided. Defenders are being handed a behavior pattern and told to go look. That is thin for anyone hoping to run a detection rule and move on, and it makes attribution and prioritization harder for teams juggling limited OT maintenance windows.

What the advisory does give you is a specific protocol, a specific port, five specific product families and seven sectors. That is enough to run an exposure audit this week. If the answer to "how many S7 controllers of ours answer from the public internet" is anything other than zero, and you can prove it, you have found the finding. The AI angle is the part that will get quoted. The port forward is the part that will get you breached.

If you find something, here is where it goes

The advisory names the reporting routes, which saves an hour when the answer to the exposure question is not zero. CISA's 24/7 Operations Center takes [email protected] or 1-844-Say-CISA (1-844-729-2472). The FBI takes it through IC3 or your local field office. Energy sector entities have their own route at [email protected], and Siemens ProductCERT is reachable at [email protected]. Include the date and time, what the activity was, what equipment was involved, and a named point of contact.