Siemens S7 Under Active Threat: AI Lowers the Barrier to OT Attacks

The most consequential industrial-security story on 20 August is the joint NSA, CISA, FBI, DOE and EPA warning about an active threat to Siemens S7 programmable logic controllers. The advisory was released on 19 August, but its operational implications warrant a deeper follow-up: threat actors are combining AI-assisted scripts, snap7.dll or python-snap7, and Internet device search services. They disguise tooling as legitimate OT monitoring while performing reconnaissance, capability development and preparation for potential disruptive operations.

This is not a claim that an autonomous AI took over a factory. The government source says AI helps actors create and iterate code more quickly from public protocol knowledge and known vulnerabilities. Reachability still depends on familiar weaknesses: an Internet-accessible PLC, outdated firmware, weak authentication, missing segmentation or uncontrolled integrator access. AI changes the economics by shortening the path from discovering a target to producing a working, model-specific tool.

Targeted controllers and sectors

The joint advisory names S7-200, S7-300, S7-400, S7-1200 and S7-1500 families, including F-series safety controllers. The activity has most often targeted US critical manufacturing, energy, water and wastewater, chemical, food and agriculture, and commercial facilities. Those controllers are used globally, so an operator elsewhere should not mistake the report’s geography for a mitigating control.

The useful question is not simply “do we own Siemens equipment?” It is “which CPUs, on which firmware, in which zone, who can reach them, and does any route exist from an untrusted network?” Inventory must include TIA Portal and STEP 7 engineering workstations, vendor access appliances, NAT rules, service tunnels, cold spares and recovery images.

Why TCP 102 and S7comm matter

S7comm uses TCP port 102. Snap7 libraries implement functions required by legitimate integration and diagnostic tools, including reading and writing PLC memory areas. The library is not inherently malicious. Risk appears when that interface is reachable from the wrong zone and controls cannot distinguish an approved engineering station from an automated script.

According to the advisory, actors scan, query CPU properties, operate on data blocks and refine tools. Reads can reveal process configuration and control logic. Writes can alter parameters, sequences or controller logic. The outcome need not resemble conventional ransomware: it may be reduced product quality, unusual equipment wear, a process outage or manipulation of a safety-relevant condition.

What AI assistance actually changes

CISA maps exploit development to ATT&CK T1587.004 and obtaining AI capabilities to T1588.007. Public documentation, an existing protocol library and a model capable of generating code can accelerate adaptation to another CPU variant or device response. A less experienced group may correct protocol mistakes, add model handling and make a script resemble monitoring software more quickly.

AI does not remove the need for a network path. It does not automatically defeat controller protection levels, segmentation or allowlisting. Hunting for a file labelled “AI-generated” therefore misses the point. Defenders must reduce reachability, authenticate operators and workstations, monitor the meaning of S7comm operations, and verify control-logic integrity.

Detect behaviour, not a filename

The agencies recommend watching TCP 102 connections from non-engineering workstations, unusual data-block reads, write commands outside change windows and sequential IP scanning. Correlate those observations with maintenance schedules, vendor tickets and remote-access authentication. An S7comm session may be normal; a session with no owner, work order or approved source is not.

A practical hunt should include:

• Python processes and snap7.dll use outside the approved tool set;
• connections to multiple PLCs within a short interval or CPU-property enumeration;
• PUT/GET activity and data-block writes outside maintenance windows;
• activity at unusual hours or from new workstations, countries or vendor addresses;
• differences between online logic and an approved, signed offline reference;
• mode changes, restarts or process deviations immediately following network activity.

Names are weak indicators. An actor can rename a library, package a script or use a legitimate workstation. Source, destination, protocol function, timing, read/write scope and absence of an authorised change are more durable signals.

The first 24 hours

Start by determining exposure without running aggressive active scans against fragile controllers. Use firewall configuration, passive network data, CMDB records and integrator information. Block TCP 102 at the perimeter and remove direct Internet routes. Remote servicing should traverse a controlled DMZ access point with MFA, named accounts, session recording and time-bounded approval.

Then map exact firmware versions to Siemens ProductCERT advisories for each CPU. OT urgency must not become uncontrolled change. Test compatibility with the program, communication modules, drives, HMIs, libraries and rollback procedure in a representative environment. Internet-facing and DMZ-resident controllers have the highest priority.

Enable passwords and available read/write protection levels. Restrict TIA Portal and STEP 7 to authorised workstations through network policy and application allowlisting. Disable web servers, Modbus TCP, PROFINET or other services when the process does not require them. Remove default SNMP community strings. Every function reduction needs an engineering-owned process test.

Ladder-logic integrity and reference copies

A backup is not evidence if no one can say when it was created and approved. Maintain a gold copy linked to the CPU version, checksum, TIA project, dependency list and authorised change. Perform online/offline comparison in a controlled way and preserve results outside the engineering workstation.

If unauthorised logic appears, personnel and process safety come first. Isolating a PLC or changing its mode must be coordinated with operations. Preserve network telemetry, the project, remote-access logs, alarm history, an engineering-station image and change records. Uploading a “known good” copy too early can destroy evidence without removing the attacker’s access.

Source facts and Breachroad conclusions

Active targeting, affected model families, sectors, Snap7 use, ATT&CK techniques and port 102 recommendations come from the joint advisory. The agencies assess that the pattern supports reconnaissance, capability development and preparation for operational effects. They do not publish a universal exploit or say that every S7 installation is compromised.

Signed gold copies, ticket correlation, triage order and an IT–OT exercise are Breachroad conclusions. They follow from a simple operational reality: a technically hardened PLC is not enough if security, engineering, maintenance and production do not share one response process.

Teams can rehearse that response through cybersecurity training for technical organisations and then validate segmentation, remote access and monitoring in an IT security audit. The objective is not live exploitation of a PLC. It is evidence that every path to a controller has an owner, a control and a record.

Sources

• CISA, NSA, FBI, DOE and EPA — Defending Against an Active Threat to Siemens S7 Series PLCs (AA26-231A)
• Siemens ProductCERT
• MITRE ATT&CK for ICS