AI-written snap7 scripts move the scarce resource in OT attacks from skill to exposure

A joint advisory from the NSA, CISA, the FBI and other US agencies says attackers are using AI to build exploit scripts aimed at Siemens S7 programmable logic controllers, and the agencies classify this as an active threat across energy, water, chemical and manufacturing ^[1][2][3]. A follow-up report published 2026-08-19, citing BleepingComputer and the joint advisory, names the specifics: Siemens S7-200, 300, 400, 1200 and 1500, the snap7.dll and python-snap7 libraries, S7comm as the protocol, and read/write access to PLC memory, configuration and ladder logic ^[4][5].

That follow-up came 20 days after the general public-facing PLC warning of 2026-07-30 ^[6][7]. The chain it describes has no clever part. Attackers find internet-exposed PLCs through search engines such as Censys or ZoomEye, pick devices with old software, known vulnerabilities or weak authentication, use AI to help write Python attack scripts, talk S7comm through snap7.dll or python-snap7, disguise the result as legitimate OT monitoring software, and then read memory, configuration and ladder logic, writing to them where conditions allow ^[8].

There is no phishing stage. The report says no email use has been reported in this chain and no user operation is required ^[9][10]. Discovery through Censys or ZoomEye typically leaves no trace on the victim's proxy or cloud logs ^[11]. The first thing a defender can actually see is an unauthorised snap7 client opening a PLC session ^[12].

On the capability question, the agencies are explicit: AI-generated exploitation scripts are an evolution in threat actor capability that dramatically reduces the technical expertise and time needed to produce working ICS tooling, and lets adversaries pick up additional attack vectors and adapt to defences ^[13]. If PLCs are exposed to the internet, the advisory says, they are at high risk ^[14]. The counterweight is worth holding onto: in simulations by the UK's AI Safety Institute, models have so far failed to hack OT systems on their own, and they failed not at the devices but at the IT systems sitting in front of them ^[15].

Which is exactly where the controls are. The report's mitigations are isolation of the PLC from outside networks with access limited to authorised engineering terminals, security updates and strong authentication, and an approval requirement for ladder logic and configuration changes with monitoring for differences against a baseline ^[16]. Detection needs the same shift. Because the tooling mimics legitimate monitoring software, allowlists based only on process names can miss it ^[17]. The signals that hold up are S7comm from unknown or unauthorised sources, short broad PLC enumeration, S7 communication processes with no engineering software as a parent, read/write operations outside maintenance hours, and contractor or OT management accounts used off-hours ^[18][19]. On the OT management terminals themselves, look for downloads of python-snap7 from external sources and execution of unknown monitoring tools or unauthorised scripts ^[20].

Current activity is assessed as primarily persistent reconnaissance, with potential preparation for disruption, and public reporting does not indicate successful destructive operations at individual facilities ^[21][22]. If writes do succeed, process values and control logic change, with shutdowns, equipment damage or safety incidents as the described outcome ^[23]. Plant staff would likely see it first as minor equipment malfunctions, changed displayed values, or unexpected switches to manual operation ^[24].

Watch for the first confirmed step past read access: the report's own escalation ladder ends at rewritten logic, altered equipment behaviour and persistent reconnection ^[25]. Watch also whether exposure counts for S7 devices fall after two warnings in three weeks, because that is the variable defenders still control.