In 30 percent of industrial cybersecurity incident responses last year, the first sign that something was wrong wasn’t a security alert. It was someone on the operations floor noticing that something seemed physically wrong – a pressure reading that didn’t match, a pump behaving oddly, a process running slightly off from where it should be. No alarm had fired. No dashboard had flagged anything. The problem had already been in place long enough to cause a real effect before anyone in IT or security knew to look.
That detail comes from Dragos’s 2026 OT Cybersecurity Year in Review. It matters now because in August 2026, five federal agencies – CISA, NSA, FBI, the Department of Energy, and the EPA – issued a joint advisory warning that threat actors are actively using AI to generate exploitation scripts against Siemens S7 Series programmable logic controllers: the industrial computers that run water treatment plants, power facilities, manufacturing lines, chemical processors, and commercial buildings across the United States.
The advisory is CISA AA26-231A, titled “Defending Against an Active Threat to Siemens S7 Series PLCs.” The phrase they chose is “active threat” – not theoretical, not emerging, not potential. Active.
A former CISA official called this the first advisory he has seen where CISA explicitly names AI-generated scripts as the attack tool in a public cybersecurity alert. That is a meaningful distinction, and it’s worth understanding why.
The warning isn’t about a new vulnerability
The affected hardware covers the full S7 range: the S7-200, S7-300, S7-400, S7-1200, and S7-1500 – including the F-series safety controllers. The sectors named in the advisory are critical manufacturing, energy, water and wastewater, chemical, food and agriculture, and commercial facilities.
Here is what the advisory does not say: there is no new zero-day flaw. The attackers are not exploiting something Siemens just discovered and hasn’t patched. They are exploiting known vulnerabilities, weak or default credentials, and unnecessary internet exposure – problems that have existed for years and that the security community has been recommending against for years.
The news is not the vulnerability. The news is who can now use it.
How the attack chain works
The attack begins with reconnaissance. Attackers use internet-scanning services – the advisory specifically names Censys and ZoomEye – to find Siemens S7 PLCs that are directly reachable from the public internet. Facilities that have connected their industrial controllers to an internet-facing network without restricting access are advertising their presence to anyone who wants to look.
Once a target is identified, the attackers build custom Python scripts using two legitimate open-source libraries: `snap7.dll` and `python-snap7`. These are real tools used by engineers for OT monitoring and diagnostics. They communicate via the S7comm protocol, which runs on TCP port 102. The legitimacy of the libraries is precisely what makes the scripts blend in – the traffic pattern looks like normal engineering activity.
Once connected, the scripts can read and write PLC memory, access configuration data, and modify ladder logic programs – the actual instructions controlling the physical process.
The advisory lists the objectives as initial access, credential access, denial of service, and “other objectives.” That deliberately open-ended phrasing covers the range from reconnaissance and data theft all the way to direct manipulation of the industrial process itself.
Why this is different from an IT breach
The difference between IT security and OT security matters here, and it matters more than most organizations have internalized.
In an IT breach, the primary concern is data. An attacker who reaches your email server, your HR database, or your file storage has accessed something that stores and processes information. The damage is measured in exposure, in compliance costs, in recovery time.
In an OT breach, the concern is physical. A PLC doesn’t store information – it controls a pump, a valve, a heating element, a safety interlock. Writing incorrect values to PLC memory doesn’t produce a data anomaly. It produces a physical consequence: a pump that runs dry, a chemical reaction that goes outside safe parameters, a safety system that fails to engage when it should.
This is also why “patch immediately” isn’t the universal answer in OT environments the way it often is in IT. Patching an industrial controller typically requires shutting down the process it controls. That isn’t a scheduled maintenance window on a Tuesday night – it’s a planned outage with real production and operational consequences. Many ICS devices run for a decade or more without a firmware update, not because operators are negligent, but because updating them safely requires coordinating across operations, engineering, and management.
The security community has known this for a long time. What changed is what happens when that knowledge meets AI.
What AI actually changed
The joint advisory states that AI is being used to generate and iterate these exploitation scripts, and that this “dramatically reduces the technical expertise required to develop working ICS exploitation scripts.”
That sentence is the real story.
For years, sophisticated OT attacks required a narrow and difficult-to-acquire skillset: deep familiarity with industrial protocols, hands-on experience with specific hardware platforms, understanding of how physical processes are controlled and what manipulating them would actually do. Nation-state threat groups had teams with those skills. Most criminal groups didn’t – or had to invest significant time and resources to build them.
AI compresses that expertise gap. It doesn’t eliminate the need for technical skill entirely, but it turns what once required months of specialized learning into something that can be iterated quickly and experimentally, using publicly available documentation and open-source tooling that was never designed to be a weapon.
The result is a lower barrier to entry for OT-specific attacks than has ever existed before. Five agencies put that assessment in writing.
What makes this visible – or invisible
Fewer than 10 percent of OT networks worldwide have meaningful network monitoring, according to Dragos. That number explains a lot about why the first sign of a problem is often a pump behaving strangely rather than a security alert.
The advisory’s indicators of compromise are detectable, but only if you’re watching: `snap7.dll` running outside approved engineering workstations, unauthorized S7comm connections on TCP port 102, unexpected PLC configuration reads or writes. These are not exotic signals. They’re things that standard OT network monitoring would catch. But in the 90-plus percent of OT environments that don’t have it, they’re invisible until something physical happens.
The Iran-linked attacks on water utilities across at least 12 states reported in the same news window – a separate campaign, not confirmed to be connected to the S7 advisory – prompted security experts to describe the underlying exposure as “no one guarding these systems.” That’s not a technical problem. It’s a visibility problem.
What the advisory recommends – and what matters most
CISA’s mitigations are practical and don’t require patching:
Remove internet exposure. Block TCP port 102 at the network perimeter. If your S7 PLCs aren’t reachable from the public internet, the scanning phase of this attack finds nothing. This is the single highest-leverage action – the entire attack chain begins with reconnaissance against exposed devices.
Apply firmware updates where feasible, prioritizing internet-facing and DMZ-adjacent controllers.
Tighten access controls. Enable password protection on PLCs, restrict who can access engineering software, add multi-factor authentication wherever the platform supports it.
Watch for indicators. Flag `snap7.dll` running outside approved workstations. Monitor S7comm traffic for unexpected connections or unusual read/write activity. These are detectable.
Segment OT from IT. This is the foundational recommendation across every major OT security framework – Purdue Model, IEC 62443, NIST 800-82 – and it remains the most important structural defense. An OT network that’s properly isolated from IT is a dramatically harder target, independent of what vulnerabilities exist in the controllers.
Most of these recommendations aren’t new. The security community has been making them for years. What’s new is the threat actor profile, and what’s new is that five agencies have now put “active threat” on record.
What this tells you
The Siemens S7 advisory wasn’t issued because Siemens discovered a novel flaw. It was issued because the barrier to mounting a sophisticated OT attack is lower than it has ever been, and the agencies watching these threats decided the operational risk is serious enough to name publicly.
If you’re responsible for OT infrastructure, the immediate question isn’t “are we patched?” The question is: “can our PLCs be found by a Censys scan?” If the answer is yes, that is where to start.
The operators who noticed something was wrong on the plant floor before any alert fired weren’t wrong to pay attention. They just shouldn’t be the only line of defense.—
Sources: CISA Advisory AA26-231A | Tenable FAQ on Siemens S7 threat | CyberScoop | BleepingComputer | The Register | Industrial Cyber | Dragos 2026 OT Cybersecurity Year in Review
