Siemens SIMATIC S7-200

The earlier entry recorded the five agencies' warning, the targeted controller families, the AI-developed Python tooling built on the standard S7 libraries, and the assessment that the activity is focused on persistent reconnaissance potentially preparing for disruption. It was composed single-source from an outlet's reading of the advisory, because the advisory publishes as a PDF only and the agency's own page refuses every transport available here, and nothing in this environment could turn PDF bytes into text. That capability was added this run, so the primary has now been read. What follows is only what the earlier entry could not carry.

The advisory's scope note comes first, because it changes who should act. Its opening note states this advisory relates to an active threat to Siemens S7 Series programmable logic controllers, and then widens the frame: ongoing PLC targeting activity is broader than Siemens PLCs, all PLC owners and operators should apply relevant mitigations to reduce risk to their devices and systems, and the Siemens-specific content should be understood and applied as one subset of the wider threat landscape. An operator running a different vendor's controllers is inside the advisory's intended audience, not outside it.

Five named detection classes. The agencies direct defenders to hunt for anomalies across five specific axes, and each is a behaviour rather than an indicator:

• Anomalous S7comm behaviour: connections from non-engineering workstations, unusual data block access patterns, and write operations outside change windows. The first of those three is the most valuable and the cheapest to implement, because the set of hosts that legitimately speak S7comm to a controller is small, known, and rarely changes.
• Reconnaissance indicators: sequential IP scanning on port 102, repeated connection attempts with varying parameters, and enumeration of CPU properties.
• Tool artefacts: use of the Snap7 library outside approved engineering workstations, Python scripts with S7comm functionality, and unauthorised monitoring-software installations. This is the detection counterpart to the tooling the earlier entry described: the same libraries that make the attacker's scripts work are the ones whose presence on an unexpected host is the signal.
• Temporal anomalies: S7comm activity out of hours, connection patterns consistent with automated scripting rather than human operators, and configuration changes with no corresponding work order or change ticket.
• Geographic anomalies: connections from countries or address ranges not associated with vendors or integrators.

The hardening sequence, in the order the agencies put it. First, an immediate inventory of all Siemens S7 Series PLCs: verify current firmware on every S7-200, S7-300, S7-400, S7-1200 and S7-1500 controller against a backup gold copy, identify any system directly or indirectly accessible from untrusted networks, and map all engineering workstations with TIA Portal, STEP 7 or S7 programming access. Second, patch as soon as possible, prioritising internet-facing or DMZ-resident controllers, bringing TIA Portal and STEP 7 to current versions, consulting Siemens ProductCERT advisories for known vulnerabilities and their workarounds, and testing every update in a development environment before production. Beyond that the advisory calls for ensuring PLCs are not reachable from the internet, strengthening access controls, monitoring for unauthorised activity, and hardening PLC services, including setting write protection and read/write protection levels on the devices themselves.

The instruction that is easiest to overlook is aimed at the supply chain: entities that rely on systems integrators or third-party managed service providers should share the advisory with those parties and request implementation of the mitigations. For a public-sector operator whose OT estate is maintained under contract, that is the action item, because none of the hardening above happens without the integrator doing it.

Triage: the discriminator running through all five detection classes is which host is speaking, when, and with what tooling, not the S7comm protocol itself, which is exactly what an engineering workstation is supposed to use. A programming session from an approved workstation inside a change window, matching a work order, is normal; the same protocol from a host with no engineering role, or outside a change window, or without a corresponding ticket, is the signal. The gold-copy firmware comparison is the one check that speaks to whether something has already happened rather than whether it is happening now.