AI-Generated Attack Scripts Targeting Siemens S7 PLCs: Detection and Hardening Guide for OT Defenders

U.S. cybersecurity agencies have issued a warning that threat actors are actively using AI-generated scripts to target Siemens S7 series programmable logic controllers (PLCs) deployed across U.S. critical infrastructure. This is not a theoretical exercise in AI hype — it represents a measurable shift in the OT threat landscape: the barrier to entry for attacking industrial control systems has collapsed. Actors who previously lacked the specialized knowledge to craft S7comm protocol interactions can now generate functional attack tooling in hours rather than months.

If you operate water, energy, manufacturing, or transportation environments with Siemens S7-300, S7-400, S7-1200, or S7-1500 controllers, treat this as an active threat condition, not an advisory to file away. The defensive guidance below reflects how we are hunting for this activity in client environments today.

Why This Matters: The AI Force-Multiplier Effect on OT Threats

Historically, attacking a Siemens S7 PLC required non-trivial expertise: understanding the S7comm/S7comm-plus protocol (TCP/102), TSAP addressing, function codes for start/stop (0x28/0x29), block uploads/downloads, and credential handling. That expertise acted as a natural filter limiting the attacker pool.

Large language models have demolished that filter. Open-source libraries like python-snap7 make PLC interaction a handful of lines of code, and AI assistants can now produce working scripts that:

• Enumerate S7 PLCs on a network by probing TCP/102
• Read PLC status, order codes, and module information (SZL reads)
• Upload and download logic blocks (program manipulation)
• Issue CPU start/stop commands — a direct path to process disruption
• Brute-force or replay PLC access credentials
• Modify data blocks controlling setpoints, timers, and I/O states

The result: commodity criminal crews, hacktivists, and low-tier state proxies can now run playbook-grade OT intrusions that were previously the domain of sophisticated actors. Expect volume to increase.

Technical Analysis: What the Attack Chain Looks Like

Affected Products

• Siemens SIMATIC S7-300 / S7-400 — legacy but ubiquitous; weak or absent authentication on S7comm
• Siemens SIMATIC S7-1200 / S7-1500 — S7comm-plus with improved integrity controls, but still targetable, especially when firmware is outdated or protection levels are misconfigured
• Engineering workstations running TIA Portal, STEP 7 (Classic), or WinCC — the typical initial foothold and pivot point into the control network

Typical Attack Chain (Defender's View)

1. Initial access — usually IT-side: phishing, exposed remote access (RDP/VPN), or compromised vendor accounts. The PLC itself is rarely the entry point.
2. Discovery — AI-generated Python/PowerShell scripts scan OT VLANs for hosts listening on TCP/102. Snap7-based scripts issue SZL (System Status List) reads to fingerprint CPU model, firmware, and module inventory.
3. Interaction — depending on intent: read operations for reconnaissance, block download for logic theft, or block upload / CPU stop for sabotage.
4. Impact — altered process logic, manipulated I/O, or halted CPUs. In safety-adjacent processes this can be physically destructive.

Exploitation Requirements

No memory-corruption exploit is required for much of this activity — that is the uncomfortable truth. S7comm on legacy CPUs provides no authentication by default. Any host with network reachability to TCP/102 and valid TSAP parameters can issue privileged function codes. The "vulnerability" being weaponized by AI-generated scripts is primarily architectural exposure plus weak access protection configuration.

Exploitation Status

• Confirmed in-the-wild activity per the U.S. government warning — this is an active campaign, not a proof-of-concept.
• No CVE is associated with this advisory; it describes adversary technique and tooling evolution, not a single patchable flaw. Monitor CISA ICS advisories for related Siemens disclosures as they emerge.

Detection & Response

The core detection philosophy: in a well-architected OT environment, only a small, known set of engineering workstations and HMIs should ever speak S7comm. Anything else talking to TCP/102 — especially scripting interpreters — is high-fidelity signal. AI-generated attack tooling leans heavily on Python (snap7) and PowerShell, which makes it detectable at the endpoint layer even when network monitoring is thin.

Sigma Rules

---
title: Scripting Interpreter Initiating S7comm PLC Connection
id: 4b7c2e91-6a3d-4f58-b1e9-8c2d5a7f3e41
status: experimental
description: Detects Python, PowerShell, or other scripting engines initiating outbound connections to TCP/102 (Siemens S7comm). AI-generated PLC attack tooling is typically delivered as Python (snap7) or PowerShell scripts; legitimate S7comm traffic originates from TIA Portal, STEP 7, WinCC, or HMI processes — never from interpreters.
references:
  - https://www.bleepingcomputer.com/news/security/us-warns-of-ai-powered-attacks-on-siemens-plcs-in-critical-infrastructure/
  - https://attack.mitre.org/techniques/T0855/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.discovery
  - attack.t0855
  - attack.ics
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 102
    Image|endswith:
      - '\python.exe'
      - '\pythonw.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\node.exe'
      - '\perl.exe'
      - '\ruby.exe'
  condition: selection
falsepositives:
  - Rare: custom-built plant diagnostics tooling using snap7 (should be inventoried and allow-listed, not ignored)
level: high
---
title: Snap7 or S7 PLC Scripting Library Execution
id: 9d1e5f38-2b4a-4c76-a3d2-7f8e1b4c6a29
status: experimental
description: Detects process command lines referencing snap7 or S7 protocol interaction functions. Threat actors using AI-generated scripts against Siemens S7 PLCs commonly rely on the python-snap7 library; its presence on non-engineering hosts is strong malicious signal.
references:
  - https://www.bleepingcomputer.com/news/security/us-warns-of-ai-powered-attacks-on-siemens-plcs-in-critical-infrastructure/
  - https://attack.mitre.org/techniques/T0859/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t0859
  - attack.ics
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'snap7'
      - 's7client'
      - 'Cli_Connect'
      - 'PlcStop'
      - 'PlcHotStart'
      - 'UploadBlock'
      - 'DownloadBlock'
      - 'pip install python-snap7'
  condition: selection
falsepositives:
  - Legitimate use on dedicated engineering workstations running approved diagnostics (restrict by host allow-list)
level: critical
---
title: TCP 102 Port Scanning Across Multiple Hosts
id: 2c8f4a17-5e9b-4d31-9f67-1a3c8e2b5d94
status: experimental
description: Detects a single source host initiating TCP/102 connections to many distinct destinations in a short window — consistent with AI-generated PLC discovery/enumeration scripts sweeping OT segments.
references:
  - https://www.bleepingcomputer.com/news/security/us-warns-of-ai-powered-attacks-on-siemens-plcs-in-critical-infrastructure/
  - https://attack.mitre.org/techniques/T0846/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.discovery
  - attack.t0846
  - attack.ics
logsource:
  category: firewall
detection:
  selection:
    dst_port: 102
  condition: selection | count(dst_ip) by src_ip > 5
timeframe: 5m
falsepositives:
  - Authorized OT asset inventory scans from the designated management server (allow-list its IP)
  - HMI/SCADA polling in flat networks — a segmentation finding in itself
level: high

KQL — Microsoft Sentinel / Defender

This query assumes Windows endpoints across IT and the OT DMZ are onboarded to Defender, and/or firewall logs are ingested into CommonSecurityLog. It hunts for non-engineering hosts speaking S7comm and for scripting interpreters touching TCP/102.

// Hunt: Suspicious S7comm (TCP/102) activity from scripting engines or unauthorized hosts
// Maintain a watchlist of authorized engineering workstations / HMIs and substitute below
let AuthorizedS7Hosts = dynamic(["EWS-01","EWS-02","HMI-PLANT-A","SCADA-HIST-01"]);
let ScriptInterpreters = dynamic(["python.exe","pythonw.exe","powershell.exe","pwsh.exe","node.exe","wscript.exe","cscript.exe"]);
let EndpointHits =
    DeviceNetworkEvents
    | where TimeGenerated > ago(24h)
    | where RemotePort == 102
    | where InitiatingProcessFileName in~ (ScriptInterpreters)
    | project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
              RemoteIP, RemotePort, InitiatingProcessAccountName
    | extend Source = "Defender-Endpoint";
let FirewallHits =
    CommonSecurityLog
    | where TimeGenerated > ago(24h)
    | where DestinationPort == 102
    | where DeviceAction in ("allow","allowed","Accept","permit")
    | summarize ConnCount = count(), DistinctPLCs = dcount(DestinationIP)
              by SourceIP, SourceHostName, bin(TimeGenerated, 1h)
    | where DistinctPLCs > 3   // fan-out enumeration behavior
    | extend Source = "Firewall";
union EndpointHits, FirewallHits
| where DeviceName !in~ (AuthorizedS7Hosts) or Source == "Firewall"
| sort by TimeGenerated desc

Tune the AuthorizedS7Hosts list to your environment before deployment — this is the single most important step for keeping fidelity high. In most plants the legitimate S7 talker count is under ten hosts.

Velociraptor VQL

Deploy this as a hunt across DMZ jump hosts, engineering workstations, and any Windows assets with OT reachability. It identifies live TCP/102 sessions attributable to non-standard processes — exactly what snap7-based attack scripts produce.

-- Hunt: Identify processes holding active connections to Siemens S7 PLCs (TCP/102)
-- Flags anything that is not a known engineering application (TIA Portal, STEP 7, WinCC)
LET legit_s7_proc = `(?i)(s7tgtopx|S7oiehsx|Portal|WinCC|CCProjectMgr|onlinemanager|siemens)`
SELECT Pid,
       Ppid,
       Name,
       CommandLine,
       Exe,
       Username,
       Laddr.IP AS LocalIP,
       Laddr.Port AS LocalPort,
       Raddr.IP AS PLC_IP,
       Raddr.Port AS PLC_Port,
       Status AS ConnState
FROM netstat()
WHERE Raddr.Port = 102
  AND Status =~ 'ESTABLISHED|SYN'
  AND NOT Name =~ legit_s7_proc

Any row returned from a host that is not an approved engineering station warrants immediate triage: capture the process binary, hash it, pull the script from CommandLine, and check the PLC for unauthorized block uploads/downloads.

Remediation / Hardening Script

This PowerShell script performs two defensive functions from a management host: (1) audits which hosts on a given OT subnet currently accept S7comm connections, building your exposure inventory, and (2) on Windows jump/engineering hosts, creates outbound firewall rules restricting TCP/102 to an authorized PLC list — cutting off script-based lateral interaction.

# =============================================================
# S7 PLC Exposure Audit + Egress Hardening (run elevated)
# Part 1: Discover hosts listening on TCP/102 in the target subnet
# Part 2: Restrict outbound S7comm to an authorized PLC allow-list
# =============================================================

$OTSubnet   = "10.10.20.0/24"          # <-- your PLC VLAN
$AuthorizedPLCs = @(                   # <-- only PLCs this host should manage
    "10.10.20.11","10.10.20.12"
)

# --- Part 1: Exposure audit ---
$range = 1..254 | ForEach-Object { "10.10.20.$_" }
$openPLCs = foreach ($ip in $range) {
    $r = Test-NetConnection -ComputerName $ip -Port 102 -WarningAction SilentlyContinue -InformationLevel Quiet
    if ($r) { $ip }
}
Write-Host "[+] Hosts exposing S7comm (TCP/102):" -ForegroundColor Yellow
$openPLCs | ForEach-Object { Write-Host "    $_" }
$openPLCs | Out-File "$env:USERPROFILE\Desktop\s7_exposure_audit_$(Get-Date -f yyyyMMdd).txt"

# --- Part 2: Egress hardening (run on engineering/jump hosts) ---
# Default-deny outbound TCP/102, then permit only authorized PLCs
New-NetFirewallRule -DisplayName "OT-S7-DenyAll-Outbound" `
    -Direction Outbound -Protocol TCP -RemotePort 102 -Action Block `
    -Profile Any -Description "Block S7comm egress except allow-listed PLCs (AI-script mitigation)" | Out-Null

foreach ($plc in $AuthorizedPLCs) {
    New-NetFirewallRule -DisplayName "OT-S7-Allow-$plc" `
        -Direction Outbound -Protocol TCP -RemotePort 102 -RemoteAddress $plc `
        -Action Allow -Profile Any | Out-Null
}
Write-Host "[+] Outbound S7comm restricted to: $($AuthorizedPLCs -join ', ')" -ForegroundColor Green

# --- Part 3: Check for snap7 artifacts on this host ---
$snap7 = Get-ChildItem -Path C:\ -Recurse -Filter "snap7.dll" -ErrorAction SilentlyContinue -Depth 6
if ($snap7) {
    Write-Host "[!] snap7.dll found on this host — investigate before approving:" -ForegroundColor Red
    $snap7.FullName
}

Remediation and Strategic Hardening

There is no patch for this campaign because there is no single CVE — the fix is architectural and procedural. Prioritize in this order:

1. Segment and broker access now. Enforce a deny-all / allow-by-exception posture for TCP/102 between zones. Only named engineering workstations and HMIs should reach PLCs. If you can scan your PLC VLAN from a general user subnet today, that is your finding.
2. Set S7 access protection. On S7-1200/1500, configure the CPU protection level to at least "HMI access" with a strong password; disable PUT/GET communication where not operationally required. On legacy S7-300/400 with no native auth, compensating network controls are your only line — treat them as such.
3. Update Siemens firmware per current advisories. Track the Siemens ProductCERT portal (https://cert-portal.siemens.com/productcert/html/index.html) and CISA ICS advisories (https://www.cisa.gov/news-events/cybersecurity-advisories?f%5B0%5D=advisory_type%3A93) for S7 family updates. Subscribe to both feeds.
4. Eliminate interpreter sprawl in the OT DMZ. Python, Node, and unapproved PowerShell execution should not exist on jump hosts or engineering workstations. Use application control (WDAC/AppLocker) to enforce it — this directly breaks the AI-generated-script delivery model.
5. Monitor protocol behavior, not just ports. Deploy an OT-aware IDS (Zeek with an S7comm parser, or a commercial OT NDR) and alert on PLC function codes: CPU stop, program upload/download, and password-change operations from any source.
6. Snapshot PLC logic and diff it. Maintain known-good backups of all PLC programs via TIA Portal/STEP 7 and compare running blocks against baseline on a schedule. Unauthorized block uploads/downloads are the sabotage mechanism — you need to detect drift, not just intrusions.
7. Exercise your OT IR playbook. AI-generated tooling means faster, sloppier, and more frequent intrusions. Tabletop a "rogue script issued PLC stop" scenario with your plant operators this quarter, and define who has authority to isolate the control network.

Bottom Line

The significance of this warning is not that AI exists — it is that OT intrusion capability has been commoditized. The defenders who absorb this well will be the ones who already treated "any unauthorized host speaking S7comm" as a fire alarm. If you cannot answer, right now, which ten hosts in your environment are allowed to talk to your PLCs on TCP/102, that is where your work starts this week.

Related Resources

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