A recent U.S. government advisory has put industrial control system (ICS) operators on notice: threat actors are actively deploying AI-generated exploit and reconnaissance scripts against internet-exposed Siemens S7 Series programmable logic controllers (PLCs). This is not a theoretical risk — it represents a measurable shift in the economics of OT attacks. Adversaries who previously lacked the specialized protocol knowledge required to interact with Siemens' proprietary S7comm protocol can now use large language models to generate functional attack tooling in minutes, dramatically lowering the barrier to entry for targeting operational technology.
For defenders, the implications are serious. S7 Series PLCs (S7-300, S7-400, S7-1200, S7-1500) are deployed across manufacturing, energy, water treatment, and building automation environments worldwide. Any S7 device reachable from the internet — or from a poorly segmented corporate network — must be treated as a live target. If you operate Siemens PLCs, this advisory demands an immediate exposure audit and a review of your OT network monitoring posture.
Technical Analysis
Affected Products
The advisory focuses on the Siemens SIMATIC S7 family:
- S7-300 / S7-400 — legacy PLCs still widely deployed in brownfield environments; these devices largely lack modern authentication and encrypted protocol support
- S7-1200 / S7-1500 — newer controllers with improved security features, but frequently deployed with default or weakened configurations
- Devices communicating over S7comm (TCP/102) and S7comm Plus (S7-1200/1500, also TCP/102)
No specific CVE is cited in this advisory — the threat is not a single vulnerability but an attack methodology: AI-generated scripts that automate S7comm interaction, including device fingerprinting, memory read/write operations, credential brute forcing against PLC access levels, and in some cases stop/start commands or logic block manipulation. Tools such as the open-source Snap7 library have long enabled this class of interaction; what has changed is that AI code generation now lets low-skill actors produce working scripts against the protocol on demand, and lets skilled actors scale their tooling rapidly.
How the Attack Works (Defender's View)
The typical attack chain against an exposed S7 PLC follows this pattern:
- Discovery — Attackers scan for TCP/102 using internet-wide scanning services (Shodan, Censys) or direct scanning. Exposed S7 PLCs are trivially enumerable; historical Shodan data consistently shows thousands of indexed S7 devices.
- Fingerprinting — AI-generated scripts issue S7comm
SZL(System Zone List) read requests to pull module identification, hardware/firmware version, and device name — the same reconnaissance primitive used by Snap7-based tooling. - Access — Legacy S7-300/400 devices offer no meaningful authentication. S7-1200/1500 devices support protection levels, but weak or default passwords remain common. Scripts can brute force or bypass password checks on older firmware.
- Manipulation — With read/write access established, attackers can read I/O states and memory blocks (M, DB areas), upload/download logic blocks, and issue PLC stop commands — causing process disruption without ever touching an IT system.
The exploitation requirement is minimal: network reachability to TCP/102. There is no phishing, no endpoint compromise, no user interaction. If your PLC answers an S7comm handshake from an untrusted source, the attacker's script is already inside your control loop.
Exploitation Status
Per the government advisory, this activity is confirmed in-the-wild — attackers are actively using AI-generated tooling against exposed S7 devices. No CISA KEV entry applies because no discrete CVE is at the center of this campaign; the threat is technique-driven. That distinction matters for your defensive strategy: there is no patch to race. The remediation is architectural — exposure elimination, segmentation, and monitoring.
Detection & Response
This is a technical ICS threat, so the detections below focus on the observable behaviors of S7comm-targeting activity: unauthorized connections to TCP/102, S7 protocol reconnaissance from non-engineering workstations, and PLC stop/download commands. A critical caveat: PLCs themselves do not generate endpoint telemetry. Your detection surface is the network — OT firewalls, network sensors, SPAN/TAP-fed IDS, and any host-based visibility on engineering workstations and DMZ jump hosts.
Sigma Rules
The following rules target host-side telemetry from engineering workstations and servers that legitimately communicate with PLCs. Connections to TCP/102 from any process outside an approved allowlist of engineering software (TIA Portal, WinCC, STEP 7, OPC servers) is a high-fidelity signal in a well-inventoried environment.
---
title: Unauthorized Process Connecting to Siemens S7comm Port 102
id: 3f9a2b71-6c48-4d1e-9a55-7b2c8e4f1a09
status: experimental
description: Detects network connections to TCP/102 (Siemens S7comm) initiated by processes outside the approved engineering software baseline. AI-generated S7 attack scripts (typically Python using snap7) will appear as python.exe, script interpreters, or unknown binaries connecting to PLC port 102.
references:
- https://attack.mitre.org/techniques/T0883/
- https://attack.mitre.org/techniques/T0846/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.ics
- attack.t0846
- attack.t0883
logsource:
category: network_connection
product: windows
detection:
selection_port:
DestinationPort: 102
filter_approved:
Image|endswith:
- '\S7tgtopx.exe'
- '\Portal.exe'
- '\WinCCExplorer.exe'
- '\S7otbxdx.exe'
- '\OpcEnum.exe'
condition: selection_port and not filter_approved
falsepositives:
- OPC UA/DA middleware or SCADA historians not yet added to the approved process baseline
- Asset inventory scanners approved by the OT team
level: high
---
title: Script Interpreter Spawning S7comm Client Tooling
id: 8c1d4e62-2f7a-4b39-a016-9d5e3c7b2f84
status: experimental
description: Detects Python or other script interpreters loading or referencing snap7, the library most commonly used by AI-generated scripts to interact with Siemens S7 PLCs. Presence of snap7 references on non-engineering systems is a strong indicator of unauthorized PLC interaction tooling.
references:
- https://attack.mitre.org/techniques/T0807/
- https://attack.mitre.org/techniques/T1059.006/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.ics
- attack.t0807
- attack.t1059.006
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains:
- 'snap7'
- 's7client'
- 'S7Server'
- 'Cli_ConnectTo'
- 'plc.stop'
- 'db_read'
- 'db_write'
filter_engineering_hosts:
Computer|startswith:
- 'EWS-'
- 'ENG-WS-'
condition: selection and not filter_engineering_hosts
falsepositives:
- Authorized OT engineers running legitimate snap7-based diagnostics from engineering workstations (baseline by host naming convention)
- Approved red team or penetration testing activity
level: high
---
title: Python Script Execution from User-Writable Directories on OT-Adjacent Hosts
id: b57e3c94-1a68-4f2d-8e31-6c9b5d2a7f13
status: experimental
description: Detects execution of Python scripts from temporary or user-writable paths on hosts with OT network access. AI-generated attack scripts are frequently dropped and run from %TEMP%, %APPDATA%, or %USERPROFILE% on jump hosts and DMZ systems adjacent to the control network.
references:
- https://attack.mitre.org/techniques/T0859/
- https://attack.mitre.org/techniques/T1059.006/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.ics
- attack.t0859
- attack.t1059.006
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\python.exe'
- '\python3.exe'
- '\pythonw.exe'
- '\powershell.exe'
selection_path:
CommandLine|contains:
- '\AppData\Local\Temp\'
- '\AppData\Roaming\'
- '\Users\Public\'
- 'C:\Temp\'
condition: selection_img and selection_path
falsepositives:
- Legitimate automation scripts run by OT administrators — baseline expected script paths per host
- Software installers using embedded Python
level: medium
Tuning guidance: The value of these rules is directly proportional to the quality of your engineering software inventory. Before enabling rule one at high severity, build the approved-process list from your actual TIA Portal, WinCC, and OPC deployments. In environments without that inventory, start with the snap7-specific rule — it is the highest-fidelity, lowest-noise signal of the three.
KQL Hunting (Microsoft Sentinel / Defender)
This query hunts across firewall/syslog telemetry (CommonSecurityLog, ingested via CEF from OT firewalls and network sensors) and Defender for Endpoint network events for unauthorized communication with S7 PLCs on TCP/102. It is designed to catch both internet-facing exposure and internal lateral movement toward the control network.
let S7Port = 102;
let ApprovedSources = dynamic(["10.10.20.15", "10.10.20.16"]); // Engineering workstations / OPC servers - replace with your baseline
union isfuzzy=true
(CommonSecurityLog
| where DestinationPort == S7Port
| where not(SourceIP in (ApprovedSources))
| summarize ConnectionCount = count(),
DistinctSources = dcount(SourceIP),
SourceIPs = make_set(SourceIP, 20),
Devices = make_set(DeviceVendor, 10)
by DestinationIP, DestinationPort
| extend Telemetry = "Firewall/CEF"),
(DeviceNetworkEvents
| where RemotePort == S7Port
| where not(RemoteIP has_any (ApprovedSources)) or isempty(RemoteIP)
| summarize ConnectionCount = count(),
Processes = make_set(InitiatingProcessFileName, 20),
CommandLines = make_set(InitiatingProcessCommandLine, 20)
by DeviceName, RemoteIP, RemotePort
| extend Telemetry = "Defender-Endpoint")
| sort by ConnectionCount desc
A second query for spotting scanning behavior — a single source touching multiple PLC destinations on TCP/102 within a short window is characteristic of the AI-generated reconnaissance scripts described in the advisory:
CommonSecurityLog
| where DestinationPort == 102
| where TimeGenerated > ago(24h)
| summarize PLCTargets = dcount(DestinationIP),
TargetList = make_set(DestinationIP, 50),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by SourceIP
| where PLCTargets >= 3
| sort by PLCTargets desc
Velociraptor VQL
For endpoint forensics on engineering workstations, DMZ jump hosts, or any Windows system with OT network access, this artifact hunts for processes holding live connections to TCP/102 — useful for triaging a suspected rogue S7 client:
-- Hunt for processes with active or recent connections to Siemens S7comm (TCP/102)
-- and cross-reference with process metadata to identify rogue S7 clients
SELECT Pid, Name, Path, CommandLine, Username,
Netstat.RemoteAddress AS RemoteIP,
Netstat.RemotePort AS RemotePort,
Netstat.Status AS ConnStatus
FROM netstat()
WHERE Netstat.RemotePort = 102
OR Netstat.LocalPort = 102
For a broader sweep looking for snap7 artifacts dropped on disk (AI-generated scripts are often delivered with the snap7 DLL alongside the .py file):
-- Search for snap7 client/server libraries and Python S7 tooling on disk
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
'C:/Users/*/snap7*.dll',
'C:/Users/*/*/snap7*.dll',
'C:/ProgramData/**/snap7*.dll',
'C:/Windows/Temp/**/snap7*.dll',
'C:/Users/*/*.py'
])
WHERE FullPath =~ '(?i)snap7|s7client|s7_'
OR (FullPath =~ '\.py$' AND Size < 50000)
Remediation Script
This Bash script audits and locks down network exposure of S7 PLCs. It performs three functions: (1) scans defined OT subnets for devices answering on TCP/102 to inventory exposure, (2) applies host-level firewall rules on a Linux-based OT gateway/jump host to restrict S7comm to an approved source list, and (3) verifies the rules are active.
#!/bin/bash
# Security Arsenal - S7 PLC Exposure Audit and S7comm Access Restriction
# Run on the OT gateway/firewall host or a scanning host with OT network reachability
# Tested on RHEL/Ubuntu with iptables and nmap installed
set -euo pipefail
# ---- CONFIGURATION ----
OT_SUBNETS="10.10.30.0/24 10.10.40.0/24" # Your PLC subnets - EDIT BEFORE RUNNING
APPROVED_S7_SOURCES="10.10.20.15 10.10.20.16" # Engineering workstations / OPC servers - EDIT
S7_PORT=102
REPORT="s7_exposure_audit_$(date +%Y%m%d_%H%M%S).txt"
echo "=== S7 Exposure Audit ===" | tee "$REPORT"
# ---- STEP 1: Inventory exposed S7 devices ----
echo "[*] Scanning OT subnets for devices answering on TCP/${S7_PORT}..." | tee -a "$REPORT"
for SUBNET in $OT_SUBNETS; do
nmap -Pn -p "$S7_PORT" --open -oG - "$SUBNET" 2>/dev/null | \
awk '/Ports:/{print "EXPOSED:", $2, "->", $0}' | tee -a "$REPORT"
done
echo "[+] Exposure inventory complete. Any host listed above reachable from untrusted networks is a finding." | tee -a "$REPORT"
# ---- STEP 2: Restrict S7comm to approved sources on this gateway ----
echo "[*] Applying iptables rules: S7comm permitted only from approved sources..." | tee -a "$REPORT"
for SRC in $APPROVED_S7_SOURCES; do
iptables -C OUTPUT -p tcp --dport "$S7_PORT" -s "$SRC" -j ACCEPT 2>/dev/null || \
iptables -A OUTPUT -p tcp --dport "$S7_PORT" -s "$SRC" -j ACCEPT
echo " ALLOW: ${SRC} -> any PLC :${S7_PORT}" | tee -a "$REPORT"
done
# Default deny for all other S7comm egress from this gateway
iptables -C OUTPUT -p tcp --dport "$S7_PORT" -j DROP 2>/dev/null || \
iptables -A OUTPUT -p tcp --dport "$S7_PORT" -j DROP
echo " DENY: all other sources -> :${S7_PORT}" | tee -a "$REPORT"
# ---- STEP 3: Verify ----
echo "[*] Active S7comm rules:" | tee -a "$REPORT"
iptables -L OUTPUT -n -v | grep "dpt:$S7_PORT" | tee -a "$REPORT"
echo "=== Done. Report saved to $REPORT ==="
echo "NOTE: Persist rules with 'iptables-save > /etc/iptables/rules.v4' (Debian) or"
echo " 'service iptables save' (RHEL). Mirror this policy on all OT perimeter firewalls."
Remediation
Because this threat is technique-driven rather than a single patchable vulnerability, remediation centers on exposure elimination and architectural hardening. Prioritize in this order:
1. Eliminate internet exposure — this week. Query Shodan and Censys for your public IP ranges and ASNs against port 102. Any S7 device answering on the public internet is an emergency. Remove the NAT/firewall rule, place the device behind the OT perimeter, and if the device was exposed for any meaningful period, treat it as potentially compromised: review its logic blocks against a known-good backup and consider firmware re-flash.
2. Enforce segmentation per IEC 62443 zones and conduits. PLCs should sit in a dedicated control zone, reachable only from engineering workstations and SCADA/OPC servers through a monitored conduit (OT firewall or unidirectional gateway where feasible). Default-deny all other traffic to TCP/102. The detection rules above only work well when the approved-communicator list is small — segmentation makes that list small by design.
3. Harden the S7 devices themselves.
- S7-1200/1500: Set the PLC protection level to at least "HMI access" (password required for read/write) or "No access (complete protection)" where operationally possible. Rotate any default or shared passwords. Disable PUT/GET communication if not required — this legacy access method bypasses protection levels on some firmware revisions.
- S7-300/400: These devices cannot be meaningfully hardened at the protocol level. If replacement is not funded, they must be behind a hardened conduit with strict source filtering, and every connection to them must be logged and alerted.
- Apply current Siemens firmware per the Siemens ProductCERT advisories at https://www.siemens.com/global/en/products/services/cert.html — while this campaign is not CVE-centric, current firmware closes known S7comm weaknesses the same AI-generated tooling can leverage.
4. Deploy protocol-aware monitoring. Signature-based IDS will not parse S7comm. If budget allows, deploy an OT-aware monitoring platform (Nozomi, Dragos, Claroty, or open-source Zeek with the icsnpp-s7comm analyzer from CISA's ICS protocol parser suite) at the control-zone aggregation point. At minimum, alert on any new source MAC/IP initiating S7comm sessions and on PLC stop/download function codes from non-engineering sources.
5. Build and maintain the engineering asset inventory. The highest-fidelity detections in this article depend on knowing exactly which hosts and processes are authorized to talk to your PLCs. If you cannot produce that list today, that is your first project.
6. Brief incident response on OT-specific playbooks. A PLC stop command or logic manipulation event is not handled like an IT incident — pulling network cables can itself halt physical processes. Ensure your IR retainer and playbooks include safe PLC isolation, logic verification, and recovery procedures before you need them.
The Bottom Line
AI-assisted exploit generation has removed the skill barrier that historically protected OT environments from opportunistic attackers. The S7 protocol's weaknesses are well-documented, and now any motivated actor can produce working attack tooling against it. Defenders cannot wait for a CVE and a patch cycle — the mitigation is exposure management, segmentation, and monitoring, and the time to validate all three is now.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.