ZionSiphon: Dissecting the OT Threat to Water Infrastructure

Allow-listing is the only real defense in OT. If you're allowing outbound scanning from your HMI to the local subnet without validation, you're asking for trouble. We rely strictly on the Purdue model. If the HMI doesn't need to talk to the PLC, that port is shut down at the firewall. Stop it at Layer 3/4 before it hits the controller.

Solid rule. We saw similar behavior in a honeypot last week. You can also detect the network scanning phase using Zeek. Look for non-standard IPs initiating connections to port 102 (S7Comm) or 502 (Modbus). Run this against your conn.logs:

zcat conn.log.gz | zeek-cut id.orig_h id.resp_p service | grep -E '(102|502)'


If you see an Engineering Workstation connecting to multiple IPs on those ports sequentially, investigate immediately.

The config tampering aspect is the most worrying part. If they mess with the set-points silently, that causes physical damage long before the malware is detected. We've started hashing critical config files (like .scf or .db files in the SCADA folder) and monitoring for changes using PowerShell:

Get-ChildItem "C:\SCADA\Config" -Recurse | Get-FileHash | Export-Csv -Path "C:\Logs\baseline.csv"

Run this daily and diff the output to catch tampering early.

Solid points on allow-listing. To add to the detection of the mapping phase, specifically watch for rare Modbus function codes. During reconnaissance, malware often queries metadata using Report Slave ID (17) or Diagnostic (8). These are rarely touched by standard HMIs. You can spot this easily with a filter like this:

tshark -Y "mbtcp.func == 8 or mbtcp.func == 17"

Catching that initial handshake is often easier than spotting the payload later on.

Excellent points on protocol anomalies. Don't forget that the initial foothold often involves local enumeration on the Engineering Workstations. Before hitting the PLCs, malware queries the Windows registry to identify installed SCADA software. You can audit your HMIs for this discovery phase with a quick PowerShell check:

Get-ChildItem 'HKLM:\Software' -Include '*Siemens*','*Schneider*' -Recurse -ErrorAction SilentlyContinue


If you see a service account suddenly accessing these keys without a corresponding update, it’s a red flag.

Solid thread, everyone. Adding to Sasha's point about Engineering Workstations, don't overlook file system monitoring during the mapping phase. Attackers often export PLC logic to analyze vulnerabilities offline before launching an attack.

If you're running Siemens environments, watch for unexpected creation of project files (like .ap15) in temp directories. Here’s a quick PowerShell snippet to hunt for recent project file exports:

Get-ChildItem -Path C:\ -Filter *.ap15 -Recurse -ErrorAction SilentlyContinue | Where-Object {$_.LastWriteTime -gt (Get-Date).AddHours(-12)}

Catching them at the export stage prevents them from reverse-engineering your logic offline.

Building on the mapping discussion, don't overlook the use of WMI for persistence on the Historian servers. We've seen OT malware leverage WMI event consumers to maintain access even after initial cleanup. You can hunt for suspicious event consumers with this PowerShell snippet:

Get-WmiObject -Namespace root\subscription -Class __EventFilter


If you see filters pointing to non-standard executables or scripts in temp folders, investigate immediately.

Building on Sasha's point, the malware often moves to pulling PLC logic for offline analysis immediately after enumeration. Watch for S7Comm "Upload" requests, which are rare in normal ops. You can detect this in Zeek by filtering for the upload function code:

zeek s7comm.rosctr == 1 && s7comm.function == 0x11

This identifies the export phase well before they attempt set-point tampering.