AI-generated snap7 scripts work only where port 102 still answers without a credential

snap7 implements the S7 stack end to end: TPKT framing, COTP connection setup, and the proprietary S7comm application layer above it ^[3]. A caller supplies a target, a data block number, an offset and a length. What the advisory describes as AI output sits on top of that, so the agencies' claim is about time. Generating exploitation scripts with AI "represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools", the advisory said ^[5]. It also says AI lets adversaries use additional attack vectors and adapt to defensive measures more quickly ^[6].

Why such a script works at all is much older. S7comm predates modern authentication expectations ^[9]. 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 ^[9]. An actor who reaches that port can read data blocks, and on unprotected devices write to them, without exploiting a software bug ^[10].

Siemens and the agencies are describing different objects, and both accounts hold. Siemens said publicly that AA26-231A does not describe a new native vulnerability, and referred customers to configuration weaknesses already covered in ProductCERT bulletin SSB-104599 ^[8]. The advisory bears that out: it disclosed no previously unknown flaw common to the S7 family ^[7]. One party is talking about product state; the other is talking about who can now afford the attack, and the write-up puts it as the population of potential attackers against a reachable controller expanding with no change to the controller ^[18].

That ordering explains why the advisory puts asset inventory and reachability analysis ahead of everything else ^[11]. The work it implies is unglamorous, and none of it waits on a firmware release: confirm that no S7 controller is directly or indirectly reachable from the public internet, block TCP port 102 at the IT/OT perimeter and at any cloud or remote-access gateway, turn on the controller's own password protection and protection levels, and restrict engineering access with MAC or IP allowlisting plus multi-factor authentication for remote workstations ^[15].

On detection, the advisory names unauthorised use of snap7.dll outside approved systems as an indicator of compromise ^[12]. For a utility whose SCADA platform does not use snap7, snap7 traffic on port 102 is a clear signal ^[17]. If your platform does use snap7, the indicator is your own software. The dev.to analysis adds three more: unexpected source IPs initiating PUT/GET-style data block operations, sequential scanning across port 102 on an OT subnet, and S7comm sessions from hosts other than known engineering workstations ^[13]. All of them are protocol-level, and they require visibility into OT traffic that many organisations do not have by default ^[14].

The hardening has its own bill. Before disabling a service on an S7 controller, map its dependencies: the service that looks unnecessary may be carrying remote I/O data, feeding process variables to an HMI, or providing the only diagnostic path for maintenance staff ^[16].

The account of the advisory carries no count of internet-reachable S7 controllers and no confirmed intrusion ^[20]. That number is one each operator has to produce for its own plant.