When the Expertise Barrier Falls: What AI-Assisted ICS Tooling Changes for Defenders
For most of the last two decades, attacking an industrial control system required a specific and expensive skill set: fluency in proprietary industrial protocols, knowledge of particular controller architectures, and the ability to write code that communicates natively with hardware designed for a factory floor rather than for the internet. That barrier kept all but the most capable actors away from programmable logic controllers at water utilities, power stations and chemical plants.
Joint advisory AA26-231A, published on 19 August 2026 by the NSA, CISA, the FBI, the Department of Energy and the Environmental Protection Agency, describes what happens when that barrier falls.
The mechanism the advisory describes
The advisory states that threat actors use internet scanning services to locate Siemens S7 controllers reachable from the public internet, then feed that targeting data into AI tools that generate functional Python interaction scripts. Those scripts rely on the open-source snap7 and python-snap7 libraries, which implement the full S7 protocol stack including TPKT, COTP and the proprietary S7comm application layer. The scripts are then disguised as legitimate operational technology monitoring software.
The advisory's own words are worth quoting precisely: using AI to generate exploitation scripts "represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools". It adds that AI enables adversaries to leverage additional attack vectors and adapt to defensive measures more quickly.
Why this is not a new vulnerability story
The agencies did not disclose a previously unknown flaw common to the S7 family. Siemens stated publicly that AA26-231A does not describe a new native vulnerability and pointed instead to configuration weaknesses already covered in its own guidance, referring customers to ProductCERT bulletin SSB-104599.
What changed is the cost of exploiting configurations that were always weak. S7comm predates modern authentication expectations. On many S7-300 and S7-400 units, and on S7-1200 and S7-1500 units where password protection and access-level enforcement were never configured, an S7comm session over TCP port 102 requires no credential. An actor who can reach that port can read data blocks, and on unprotected devices write to them, without exploiting a software bug at all.
The defender's problem is now asymmetric in a new way
When exploitation required rare expertise, defenders could reason about intent. A capable actor targeting a water utility was a signal. Now the capability is available to anyone who can describe the desired behaviour in plain language, which means the population of potential attackers against a reachable controller has expanded without any change to the controller.
This shifts the value of the two controls that the advisory places first. Asset inventory tells you what you have. Reachability analysis tells you what an unknown attacker can get to. Neither depends on knowing who the attacker is.
Detection signals worth instrumenting
The advisory names unauthorised use of snap7.dll outside approved systems as an indicator of compromise. For a utility whose SCADA platform does not use snap7, snap7 traffic on port 102 is a clear signal. Beyond that, defenders should instrument for unexpected source IPs initiating PUT/GET-style data block operations, sequential scanning across port 102 on an OT subnet, and S7comm sessions originating from hosts other than known engineering workstations.
These are protocol-level detections. They require visibility into OT traffic, which many organisations do not have by default. That gap is worth closing before an incident rather than during one.
Mitigations that do not require a patch
Because the underlying issue is configuration and reachability, several high-value actions do not wait on a vendor release. Confirm that no S7 controller is directly or indirectly reachable from the public internet, and block TCP port 102 at the IT/OT perimeter and at any cloud or remote-access gateway. Enable the controller's own access protection: password protection, defined protection levels and, where supported, certificate-based access. Restrict engineering access using MAC or IP allowlisting and multi-factor authentication for remote engineering workstations.
Where services are disabled as a hardening measure, map dependencies first. On an S7 controller, a service that appears unnecessary may be carrying remote I/O data, feeding process variables to an HMI, or providing the only diagnostic path for maintenance staff.
The uncomfortable conclusion
The advisory is notable less for the vendor it names than for the trajectory it documents. AI-assisted tooling compresses the interval between an actor identifying an exposed asset and having working read and write access to that asset's control logic. The defensive response is unglamorous and unchanged: inventory, perimeter segmentation, and eliminating default protocol exposure. What the advisory changes is how quickly those basics need to be finished.
References
- CISA, NSA, FBI, DOE and EPA, joint cybersecurity advisory AA26-231A, 19 August 2026: https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-231a
- Siemens ProductCERT bulletin SSB-104599
- OT Security Wire, "CISA Advisory AA26-231A: Active Threat Actors Use AI-Generated Exploits Against Siemens S7 PLCs", 20 August 2026: https://otsecuritywire.com/articles/cisa-aa26-231a-active-threat-siemens-s7-plcs-ai-generated-exploits/
