Back to Intelligence

ICS Patch Tuesday: Schneider Electric, Siemens, AVEVA, and Rockwell Automation Advisories — Defender's Patching and Detection Guide

SA
Security Arsenal Team
September 9, 2026
11 min read

This month's coordinated ICS Patch Tuesday brought security advisories from four of the biggest names in industrial automation: Schneider Electric, Siemens, AVEVA, and Rockwell Automation. Collectively, these vendors dominate the PLC, HMI, SCADA, and engineering workstation market — which means the flaws disclosed this week sit inside the control environments of power utilities, manufacturing plants, water treatment facilities, and oil and gas operations worldwide.

Here's the uncomfortable reality I've watched play out across dozens of OT engagements: the moment a coordinated ICS disclosure drops, exploit development begins. Nation-state actors and ransomware affiliates alike mine ICS advisories for vulnerable components because they know OT patch cycles are measured in months, not days. The window between disclosure and weaponization is your window to act — and it closes fast.

If you operate any Schneider Electric EcoStruxure products, Siemens SIMATIC/SINEC infrastructure, AVEVA HMI/SCADA software, or Rockwell FactoryTalk/Studio 5000 environments, treat this as a priority-one vulnerability management event.

What Was Disclosed

The March 2026 ICS Patch Tuesday cycle includes fixes from:

  • Schneider Electric — patches for vulnerabilities across its industrial control and energy management product lines, including critical-severity issues requiring immediate attention.
  • Siemens — its monthly SIMATIC/SINEC advisory bundle covering flaws in automation controllers, industrial networking components, and engineering software.
  • AVEVA — updates addressing vulnerabilities in its HMI/SCADA portfolio (historically including products like System Platform, InTouch, and Edge — verify applicability against the published advisory).
  • Rockwell Automation — fixes for flaws affecting its control and visualization product families.

Critical-severity ratings in ICS advisories typically mean one or more of the following: unauthenticated remote code execution, authentication bypass on management interfaces, or privilege escalation paths that bridge the IT/OT boundary. Review each vendor advisory against your actual deployed inventory — do not assume you're unaffected because you run "older versions."

Exploitation Status

At the time of disclosure, these flaws are patched vulnerabilities with published technical details — which historically is the trigger point for reverse-engineering and PoC development. ICS-targeting actors (including groups tracked under designations like VOLTZITE and other state-nexus clusters) have repeatedly demonstrated the ability to weaponize ICS advisories within weeks. Monitor CISA's ICS-CERT advisories page and the Known Exploited Vulnerabilities (KEV) catalog daily for the next 30 days; ICS entries landing in KEV carry federal remediation deadlines and signal confirmed exploitation.

Why OT Patching Is Different — and What to Do About It

I've led IR engagements where the patching delay — not the vulnerability itself — was the root cause of compromise. OT environments face legitimate constraints: validated change windows, uptime requirements, vendor certification requirements, and safety interlocks. But "we can't patch" is not a security strategy. The compensating-control model is:

  1. Patch what's patchable now — engineering workstations, HMI servers, historians, and jump hosts on the OT DMZ. These are Windows boxes and are the primary initial-access surface.
  2. Compensate for what isn't — network segmentation enforcement, protocol-aware monitoring, application allowlisting on HMIs, and strict conduits between Purdue levels.
  3. Detect what slips through — behavioral monitoring tuned to ICS attack patterns, because exploitation of these flaws will look like abnormal engineering-software behavior, not commodity malware.

Detection & Response

Exploitation of flaws in engineering software and control system components almost always manifests as one of a few observable behaviors: engineering software spawning unexpected child processes, unauthorized connections to PLC/HMI services over OT protocols (Modbus/TCP 502, S7comm/102, EtherNet-IP/44818), or anomalous SMB/RPC traffic crossing the IT/OT boundary. The detections below target those behaviors — they are technique-based and will remain valuable long after this specific patch cycle.

Sigma Rules

YAML
---
title: Engineering or HMI Software Spawning Unexpected Child Process
id: 8f2c4a1d-3b5e-4f7a-9c1d-2e6b8a0f4d7c
status: experimental
description: Detects ICS engineering or HMI software (Siemens, Schneider Electric, AVEVA, Rockwell) spawning shells or script interpreters, a common post-exploitation artifact when vulnerabilities in these applications are abused for code execution.
references:
  - https://www.securityweek.com/ics-patch-tuesday-schneider-electric-siemens-fix-critical-flaws/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\S7tgtopx.exe'           # Siemens TIA Portal
      - '\S7hspinx.exe'           # Siemens TIA Portal
      - '\ArchestrA.exe'          # AVEVA System Platform
      - '\aaLogger.exe'           # AVEVA
      - '\Studio5000.exe'         # Rockwell Studio 5000
      - '\FTViewSE.exe'           # Rockwell FactoryTalk View
      - '\SoMachine.exe'          # Schneider EcoStruxure Machine Expert
      - '\ControlExpert.exe'      # Schneider EcoStruxure Control Expert (Unity Pro)
      - '\UnityPro.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
      - '\certutil.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor installers and update mechanisms briefly spawning script interpreters during legitimate updates
level: high
---
title: Inbound Connection to OT Protocol Ports from Non-Engineering Host
id: 4b7e1c92-6a3d-4f8e-b2c5-9d1e7a3f0b6e
status: experimental
description: Detects network connections to well-known OT protocol ports (Modbus, S7comm, EtherNet/IP) initiated by processes outside expected engineering software. Exploitation of ICS vulnerabilities frequently culminates in unauthorized control traffic to PLCs and HMIs.
references:
  - https://www.securityweek.com/ics-patch-tuesday-schneider-electric-siemens-fix-critical-flaws/
  - https://attack.mitre.org/techniques/T0885/   # MITRE ATT&CK for ICS: Commonly Used Port
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.ics.t0885
  - attack.lateral_movement
logsource:
  category: network_connection
  product: windows
detection:
  selection_port:
    DestinationPort:
      - 102      # S7comm (Siemens)
      - 502      # Modbus/TCP (Schneider and others)
      - 44818    # EtherNet/IP (Rockwell)
      - 20000    # DNP3
      - 2222     # EtherNet/IP implicit messaging
  filter_known_engines:
    Image|endswith:
      - '\S7tgtopx.exe'
      - '\Studio5000.exe'
      - '\ControlExpert.exe'
      - '\UnityPro.exe'
      - '\SoMachine.exe'
      - '\RSLinxNG.exe'
  condition: selection_port and not filter_known_engines
falsepositives:
  - Legitimate OPC gateways, historians, and protocol converters — build a per-site allowlist of approved source hosts before enabling at high level
level: high

KQL Hunt — Microsoft Sentinel / Defender

This query hunts for two things in one pass: engineering/HMI software spawning interpreters on OT-adjacent Windows assets, and any non-allowlisted process initiating connections to OT protocol ports. Tune the KnownOTSources list to your environment's approved engineering workstations and historians before operationalizing.

KQL — Microsoft Sentinel / Defender
let KnownOTSources = dynamic(["ENGWS01", "HISTORIAN01", "OPCGW01"]);   // replace with your approved OT hosts
let OTProcesses = dynamic(["s7tgtopx.exe", "studio5000.exe", "controlexpert.exe", "unitypro.exe", "somachine.exe", "archestra.exe", "ftviewse.exe", "rslinxng.exe"]);
let InterpreterProcs = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "certutil.exe"]);
union isfuzzy=true
(DeviceProcessEvents
| where InitiatingProcessFileName has_any (OTProcesses)
  and FileName has_any (InterpreterProcs)
| extend Detection = "Engineering software spawned interpreter"
| project TimeGenerated, Detection, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName),
(DeviceNetworkEvents
| where RemotePort in (102, 502, 44818, 20000, 2222)
  and not (InitiatingProcessFileName has_any (OTProcesses))
  and not (DeviceName in~ (KnownOTSources))
| extend Detection = "Unexpected process connecting to OT protocol port"
| project TimeGenerated, Detection, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort)
| order by TimeGenerated desc

For environments forwarding OT firewall or sensor logs via CEF/Syslog, add this boundary-crossing hunt:

KQL — Microsoft Sentinel / Defender
let OTSubnet = dynamic(["10.20.0.0/16", "172.30.0.0/16"]);   // replace with your OT/Purdue L2-L3 ranges
CommonSecurityLog
| where DestinationPort in (102, 502, 44818, 20000)
| where ipv4_is_in_range(DestinationIP, toscalar(OTSubnet[0])) or ipv4_is_in_range(DestinationIP, toscalar(OTSubnet[1]))
| where not (ipv4_is_in_range(SourceIP, toscalar(OTSubnet[0])) or ipv4_is_in_range(SourceIP, toscalar(OTSubnet[1])))
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by LastSeen desc

Velociraptor VQL — Endpoint Hunt on Engineering Workstations

Deploy this artifact across engineering workstations, HMI servers, and OT jump hosts to surface suspicious process trees and unexpected listeners — the forensic residue of exploitation attempts against unpatched ICS software.

VQL — Velociraptor
-- Hunt for interpreter processes parented by ICS engineering/HMI software
-- and for unexpected listeners on OT protocol ports.
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|wmic|certutil)\.exe'
  AND Ppid IN (
      SELECT Pid FROM pslist()
      WHERE Exe =~ '(?i)(s7tgtopx|studio5000|controlexpert|unitypro|somachine|archestra|ftviewse|rslinxng)'
  )
VQL — Velociraptor
-- Identify processes listening on OT protocol ports that are not known engineering software
SELECT Pid, Name, Path, Address, Port, Status
FROM netstat()
WHERE Port IN (102, 502, 44818, 20000, 2222)
  AND NOT Path =~ '(?i)(siemens|schneider|rockwell|aveva|wonderware)'

Remediation Script — Patch Verification and Compensating Hardening

Run this on Windows-based engineering workstations and HMI servers to inventory installed vendor software versions (so you can map them against the vendor advisories), verify patch currency, and apply compensating firewall controls restricting OT protocol ports to approved hosts only while patching is scheduled.

PowerShell
# ============================================================
# ICS Patch Tuesday Response — Inventory + Compensating Controls
# Run as Administrator on engineering workstations / HMI servers
# ============================================================

# --- Step 1: Inventory installed ICS vendor software and versions ---
$vendors = 'Siemens','Schneider Electric','AVEVA','Rockwell Automation','AVEVA Group','Wonderware'
$installed = Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
             HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* -ErrorAction SilentlyContinue |
             Where-Object { $_.Publisher -and ($vendors | ForEach-Object { $_ } | Where-Object { $Publisher = $_; $false }) -eq $null }

# Cleaner enumeration:
$icsSoftware = foreach ($hive in @('HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
                                    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*')) {
    Get-ItemProperty $hive -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -and ($vendors | Where-Object { $_.DisplayName -match $_ -or $_.Publisher -match $_ }) } |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate
}
$icsSoftware | Sort-Object Publisher, DisplayName | Format-Table -AutoSize
$icsSoftware | Export-Csv -Path "$env:TEMP\ICS_Software_Inventory_$(hostname).csv" -NoTypeInformation
Write-Host "[+] Inventory exported to $env:TEMP\ICS_Software_Inventory_$(hostname).csv — compare DisplayVersion against the vendor advisories." -ForegroundColor Green

# --- Step 2: Confirm recent hotfix installation state ---
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, InstalledOn | Format-Table -AutoSize

# --- Step 3: Compensating control — restrict OT protocol ports to approved engineering hosts ---
# Replace with your approved engineering workstation / historian IPs
$ApprovedOTSources = @('10.20.10.15','10.20.10.16')   # <-- EDIT BEFORE RUNNING

foreach ($rule in @(
    @{Name='OT-Restrict-Modbus-TCP502';    Port=502},
    @{Name='OT-Restrict-S7comm-TCP102';    Port=102},
    @{Name='OT-Restrict-EtherNetIP-44818'; Port=44818}
)) {
    if (-not (Get-NetFirewallRule -DisplayName $rule.Name -ErrorAction SilentlyContinue)) {
        New-NetFirewallRule -DisplayName $rule.Name -Direction Inbound -Protocol TCP `
            -LocalPort $rule.Port -RemoteAddress $ApprovedOTSources -Action Allow `
            -Profile Any -Description "Allow OT protocol only from approved engineering hosts (compensating control pending patching)" | Out-Null
        # Explicit block for all other sources on the same port
        New-NetFirewallRule -DisplayName "$($rule.Name)-BlockOthers" -Direction Inbound -Protocol TCP `
            -LocalPort $rule.Port -Action Block -Profile Any `
            -Description "Block all other inbound sources on OT port pending patch deployment" | Out-Null
        Write-Host "[+] Applied compensating firewall rules for TCP/$($rule.Port)" -ForegroundColor Green
    } else {
        Write-Host "[=] Rule $($rule.Name) already exists — skipping." -ForegroundColor Yellow
    }
}

# --- Step 4: Verify Windows Firewall is enforcing on all profiles ---
Get-NetFirewallProfile | Where-Object { $_.Enabled -eq $false } | ForEach-Object {
    Set-NetFirewallProfile -Name $_.Name -Enabled True
    Write-Host "[!] Firewall profile $($_.Name) was DISABLED — re-enabled. Investigate why." -ForegroundColor Red
}

Write-Host "`n[DONE] Review the inventory CSV against the current Schneider/Siemens/AVEVA/Rockwell advisories and schedule patching for any vulnerable versions." -ForegroundColor Cyan

Remediation Priorities

Immediate (this week):

  1. Pull the vendor advisories and map them to your asset inventory. Start with CISA's ICS advisories page (https://www.cisa.gov/news-events/cybersecurity-advisories) plus each vendor's security portal: Schneider Electric's security notification portal, Siemens ProductCERT (https://www.siemens.com/global/en/products/services/cert.html), AVEVA's security advisories, and Rockwell Automation's Product Security Advisory Index. Match fixed versions against your installed base using the inventory script above.
  2. Patch IT-facing and DMZ assets first. Historians, OPC gateways, remote access jump hosts, and any HMI reachable from the corporate network are the highest-risk targets. These are typically standard Windows workloads — patch them on your normal cycle, not your OT cycle.
  3. Verify segmentation at the IT/OT boundary. Exploitation of these flaws is only catastrophic if an attacker can reach the vulnerable component. Confirm firewall rule bases actually enforce Purdue model separation — I've assessed environments where "segmented" OT networks had dozens of legacy any-any rules.

Short term (30 days):

  1. Schedule OT-layer patching through change control. Controllers and embedded components require vendor-validated update procedures and maintenance windows. Get them on the calendar now — "we'll get to it next quarter" is how 2025 advisories become 2027 incidents.
  2. Deploy the detection content above. The Sigma rules and KQL queries target exploitation behavior, not specific bug signatures — they'll catch weaponization of these flaws whenever it appears.
  3. Monitor CISA KEV. Any of these CVEs landing in KEV triggers a federal remediation deadline for FCEB agencies and should trigger an emergency patch cycle for everyone else.

Strategic:

  1. Establish an OT-aware vulnerability management cadence. Monthly ICS Patch Tuesday review, quarterly OT asset inventory reconciliation, and a documented compensating-controls standard for assets that can't be patched. If your vuln management program ends at the IT/OT boundary, you don't have a vuln management program — you have half of one.

Final Word

Coordinated ICS disclosures from Schneider Electric, Siemens, AVEVA, and Rockwell Automation in a single cycle means a significant attack surface just got publicly documented. The defenders who treat ICS Patch Tuesday with the same urgency as Microsoft Patch Tuesday — inventory, prioritize, patch the reachable layer, compensate everywhere else, and monitor for weaponization — are the ones who don't end up in an IR retainer call with me six weeks from 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.