Active Threat to Siemens S7 PLCs: AI-Accelerated Exploitation of Exposed ICS — Detection and Hardening Guide

A joint cybersecurity advisory from multiple U.S. government agencies confirms what many of us in OT security have been dreading: unattributed threat actors are actively conducting reconnaissance — and likely pre-positioning for future disruptive operations — against Siemens S7 Series programmable logic controllers (PLCs) exposed across critical infrastructure sectors. The accelerant is artificial intelligence. Attackers are using AI to generate and rapidly refine exploitation scripts targeting known weaknesses in the S7 platform, compressing what used to require deep ICS protocol expertise into an afternoon of prompt engineering.

There is no single CVE to patch here, and that is precisely the point. The S7 attack surface being targeted is a composite of known, long-documented protocol weaknesses (the S7comm protocol's lack of authentication by design) and unnecessary internet exposure — flat network architectures, PLCs reachable from corporate IT segments, and in the worst cases, devices answering on the public internet on TCP/102. The mitigation is architectural, not a patch cycle. If you operate S7-300, S7-400, S7-1200, or S7-1500 controllers anywhere in your environment, this advisory applies to you, and the time to verify segmentation is now — not after a pre-positioned actor decides to go loud.

Technical Analysis

Affected Products and Platforms

The advisory centers on the Siemens SIMATIC S7 family, which remains one of the most widely deployed PLC lines in global critical infrastructure:

• SIMATIC S7-300 / S7-400 — legacy workhorses still dominant in manufacturing, water treatment, and energy
• SIMATIC S7-1200 / S7-1500 — current-generation controllers with integrated PROFINET/Ethernet interfaces
• Associated engineering and HMI components communicating via S7comm (TCP/102, ISO-TSAP/RFC1006) and S7comm-Plus

No new vulnerability is disclosed in this advisory. There is no CVE and no CVSS score because the weakness is structural: the classic S7comm protocol performs no cryptographic authentication of clients. Any host that can reach TCP/102 on an S7 PLC can issue connection setup, read/write memory blocks, start/stop the CPU, and upload or download program logic, subject only to the PLC's optional (and historically weak) password protection.

How the Attack Works — Defender's View of the Chain

The observed activity follows a predictable reconnaissance and staging pattern:

1. Discovery. Actors scan for hosts answering on TCP/102 (S7comm) and related ICS ports (502/Modbus, 44818/EtherNet-IP) using internet-wide scan data (Shodan/Censys-derived target lists) and direct probing.
2. Fingerprinting. S7comm connection setup (COTP Connection Request followed by S7 Setup Communication) reveals module type, hardware/firmware version, and CPU state via SZL (System Status List) reads — all trivially scripted.
3. AI-accelerated script generation. Threat actors feed publicly available protocol documentation and existing open-source S7 tooling into LLMs to produce functional interaction scripts — memory reads, block enumeration, CPU stop commands — without ever having touched a PLC. This lowers the skill floor dramatically and increases the volume and polish of probing traffic defenders will see.
4. Pre-positioning. Establishing persistent, low-and-slow access paths into OT segments for future disruptive action: logic modification, forced I/O states, or CPU stop at a time of the actor's choosing.

Exploitation Status

This is confirmed active, in-the-wild activity documented in a multi-agency U.S. government advisory — not theoretical research. Reconnaissance against exposed S7 devices is occurring now across multiple critical infrastructure sectors. No CISA KEV entry exists because there is no single CVE; the advisory itself is the authoritative signal. Treat any S7 PLC reachable from outside a tightly controlled OT enclave as actively targeted.

Detection & Response

The highest-fidelity detection opportunity is simple: legitimate S7comm traffic has a very short, well-known list of authorized talkers (engineering workstations, HMIs, SCADA servers, historians). Any TCP/102 connection outside that allowlist is suspicious by definition. Build detections around that principle and they will be quiet, precise, and actionable.

Sigma Rules

---
title: Unauthorized Host Initiating S7comm Connection to PLC
id: 3f7a2c91-5b8d-4e6a-9c21-7d4f8a2b6e01
status: experimental
description: Detects network connections to TCP/102 (Siemens S7comm) from hosts outside the authorized engineering/HMI allowlist. Any non-allowlisted source talking S7comm is high-fidelity reconnaissance or staging behavior consistent with the active S7 PLC threat campaign.
references:
  - https://www.tenable.com/blog/frequently-asked-questions-about-the-active-threat-to-siemens-s7-series-plcs
  - https://attack.mitre.org/techniques/T0883/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.discovery
  - attack.t0883
  - attack.ics
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 102
    Initiated: 'true'
  filter_authorized_talkers:
    SourceIp:
      - '10.20.30.10'   # Replace: authorized engineering workstation(s)
      - '10.20.30.11'   # Replace: HMI / SCADA server(s)
  condition: selection and not filter_authorized_talkers
falsepositives:
  - Newly deployed HMI or engineering workstation not yet added to allowlist
  - Legitimate vendor remote access sessions (should be brokered and logged separately)
level: high
---
title: Scripting Runtime Connecting to PLC Over S7comm
id: 8c1e5b47-2d9f-4a3b-8e60-1f7c3a9d5b22
status: experimental
description: Detects scripting interpreters (Python, PowerShell, Node) initiating outbound connections to TCP/102. Adversaries are using AI-generated Python scripts (snap7-style tooling) to interact with S7 PLCs; legitimate S7comm sessions originate from TIA Portal, WinCC, or SCADA binaries, not script interpreters.
references:
  - https://www.tenable.com/blog/frequently-asked-questions-about-the-active-threat-to-siemens-s7-series-plcs
  - https://attack.mitre.org/techniques/T0855/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t0855
  - attack.ics
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 102
    Image|endswith:
      - '\python.exe'
      - '\python3.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\node.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
falsepositives:
  - Rare custom OT data-collection scripts approved by engineering (validate and allowlist by host)
level: critical

KQL (Microsoft Sentinel / Defender)

// Hunt: unauthorized or unusual S7comm (TCP/102) activity across IT/OT boundary
// Requires Defender for Endpoint network events and/or firewall logs ingested as CommonSecurityLog
let AuthorizedS7Talkers = dynamic(["10.20.30.10", "10.20.30.11"]); // <-- Replace with your engineering/HMI allowlist
let Lookback = 7d;
union isfuzzy=true
    (DeviceNetworkEvents
    | where TimeGenerated > ago(Lookback)
    | where RemotePort == 102
    | extend SourceIP = LocalIP, DeviceName_ = DeviceName, RemoteIP_ = RemoteIP, Process = InitiatingProcessFileName),
    (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort == 102
    | extend SourceIP = SourceIP, DeviceName_ = DeviceName, RemoteIP_ = DestinationIP, Process = "firewall-observed")
| where SourceIP !in (AuthorizedS7Talkers)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            ConnectionCount = count(), DistinctTargets = dcount(RemoteIP_),
            Processes = make_set(Process, 10)
    by SourceIP, DeviceName_
| order by DistinctTargets desc
// Escalate immediately: any row here is a non-authorized host probing S7 PLCs

Velociraptor VQL

-- Hunt for active or recent connections to S7comm (TCP/102) from endpoints,
-- and identify the owning process to catch script-based PLC interaction tooling.
SELECT Pid,
       Name,
       Exe,
       Username,
       CommandLine,
       netstat().RemoteAddress.IP AS RemoteIP,
       netstat().RemoteAddress.Port AS RemotePort,
       netstat().Status AS ConnState
FROM pslist()
WHERE netstat().RemoteAddress.Port = 102
  AND netstat().RemoteAddress.IP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\168\.)'

Remediation / Exposure Discovery Script

#!/bin/bash
# Security Arsenal - S7 Exposure Discovery & Emergency Containment
# Run from a Linux sensor/jump host with visibility into OT-adjacent segments.
# 1) Discover any host answering on S7comm (TCP/102) across your ranges.
# 2) Flag anything reachable from non-OT subnets. 3) Apply emergency edge blocks.

OT_RANGES="10.30.0.0/16 10.40.0.0/16"          # <-- Replace with your OT subnets
EDGE_FW="edge-fw-01.corp.local"                 # <-- Replace with your firewall
REPORT="s7_exposure_$(date +%Y%m%d_%H%M).txt"

echo "[*] Scanning for S7comm (TCP/102) responders..." | tee "$REPORT"
nmap -Pn -n -sT -p102 --open -oG - $OT_RANGES 2>/dev/null \
  | awk '/Ports: 102\/open/{print "[EXPOSED S7]", $2}' | tee -a "$REPORT"

# Also check the usual companion ICS ports often exposed alongside S7
echo "[*] Checking companion ICS ports (502 Modbus, 44818 EtherNet/IP, 20000 DNP3)..." | tee -a "$REPORT"
nmap -Pn -n -sT -p502,44818,20000 --open -oG - $OT_RANGES 2>/dev/null \
  | awk '/Ports:/{print "[ICS EXPOSURE]", $2, $0}' | tee -a "$REPORT"

# Emergency containment: deny inbound TCP/102 at the IT/OT boundary except allowlist
# (nftables example -- adapt for your firewall platform before running)
read -p "Apply emergency TCP/102 deny rule on boundary? [y/N] " confirm
if [[ "$confirm" == "y" ]]; then
  ssh "admin@$EDGE_FW" 'nft add rule inet filter forward tcp dport 102 \
    ip saddr != { 10.20.30.10, 10.20.30.11 } counter drop'
  echo "[+] Emergency deny rule applied. Review $REPORT and begin PLC isolation." | tee -a "$REPORT"
fi

echo "[*] Done. Any [EXPOSED S7] host reachable outside a controlled OT enclave must be isolated TODAY."

Remediation

Because there is no patch, remediation is a segmentation and exposure-elimination exercise. Execute in this order:

1. Remove S7 PLCs from direct internet exposure — immediately. Search Shodan/Censys for your public IP ranges and ASN on port 102. If any S7 device answers from the internet, take it offline or place it behind a firewall today. This is the single highest-impact action in the advisory.
2. Enforce strict IT/OT segmentation. S7comm (TCP/102) should be reachable only from a documented allowlist of engineering workstations, HMIs, and SCADA servers — enforced at a boundary firewall or industrial DMZ, not by VLAN ACLs alone. Deny-by-default everything else into the OT enclave.
3. Eliminate or broker remote access. No direct vendor RDP/VPN into OT. Route all third-party access through a jump host with MFA, session recording, and time-bound credentials.
4. Apply Siemens hardening guidance. Follow the Siemens SIMATIC Security guidelines and the operational guidance in the joint CSA: enable S7-1500 access protection passwords and configured protection levels, disable unused protocols/services (PUT/GET communication where not required on S7-1200/1500), update PLC firmware to current Siemens releases via TIA Portal, and apply Siemens ProductCERT advisories as published at siemens.com/productcert.
5. Deploy passive OT monitoring. You cannot run agents on a PLC. Use passive network monitoring (ICS-aware IDS/NDR) with S7comm protocol dissection to baseline authorized talkers and alert on deviations — unauthorized function codes, block uploads, CPU stop commands, and SZL reconnaissance reads.
6. Instrument the endpoints around the PLCs. Deploy the Sigma/KQL/VQL detections above on engineering workstations and IT/OT boundary systems. Script interpreters touching TCP/102 is a near-perfect signal in most environments.
7. Prepare IR playbooks for OT. Define, in advance, who has authority to disconnect an OT segment, what safe-state procedures exist for each process, and how you will validate PLC logic integrity (known-good project backups for comparison in TIA Portal) after a suspected intrusion.
8. Watch for the AI-driven volume increase. Assume probing cadence and script sophistication will keep rising. Detections based on who is allowed to talk — rather than signatures of specific scripts — are the only durable defense, because the scripts themselves will mutate faster than signatures can follow.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub