Listen to this Post
Introduction:
In industrial control systems (ICS), the Programmable Logic Controller (PLC) and Human-Machine Interface (HMI) collectively define what constitutes “normal” operational behavior – not the physical turbine itself. This disconnect creates a dangerous blind spot: attackers can manipulate control logic or inject malicious commands that shift the system’s baseline without triggering alarms, while the turbine continues running under a false sense of normalcy. Zakhar Bernhardt’s analysis of a GE MS5002E gas turbine simulation exposes how weak OT SIEM monitoring fails to track command sequences, state changes, or user attribution, leaving critical infrastructure vulnerable to stealthy sabotage.
Learning Objectives:
- Understand how PLCs and HMIs construct operational “normality” independently from physical process limits
- Identify monitoring gaps in OT environments, including missing sequence awareness and alerting for unauthorized command changes
- Learn to implement testable security controls for the control layer using simulation labs, SIEM enrichment, and active verification techniques
You Should Know:
- The PLC-HMI Control Loop: How “Normal” Is Defined and Manipulated
In a GE MS5002E-class turbine, the PLC executes a control cycle every 10 milliseconds, reading sensors (speed, temperature, pressure) and adjusting fuel valves, air flow, and guide vanes. The HMI displays a green “normal” indicator based entirely on PLC logic – not on turbine physics. If an attacker modifies the PLC’s threshold values or suppresses error flags, the HMI will continue showing normal operations even as the turbine approaches dangerous conditions.
Step‑by‑step guide to capture and analyze PLC commands:
- On Linux – Use `tcpdump` to capture Modbus/TCP traffic (default port 502) between PLC and HMI:
sudo tcpdump -i eth0 -s 1500 -w plc_traffic.pcap 'tcp port 502'
- On Windows – Install Wireshark and apply display filter `modbus && ip.addr ==
` to isolate command writes (Function Codes 5, 6, 15, 16). - Decode command sequences – Use `tshark` to extract register writes:
tshark -r plc_traffic.pcap -Y "modbus.func_code == 6" -T fields -e modbus.ref_num -e modbus.word_cnt -e modbus.data
- Create a baseline – Record normal command sequences over one hour. Any deviation (e.g., writing to critical holding registers outside scheduled maintenance) should raise an alert.
-
Detecting Anomalous State Changes with Open‑Source OT SIEM
The original post highlights that “monitoring is weak – no clear alert, no understanding of sequence, no visibility who changed what.” To close this gap, you need to forward PLC state changes to a SIEM with sequence detection.
Step‑by‑step guide using Wazuh + Modbus collector (Linux):
- Install Wazuh manager and agent on a secured jump host connected to the OT network mirror port.
- Deploy a Python script using `pymodbus` to poll critical registers every 500 ms:
from pymodbus.client import ModbusTcpClient import syslog client = ModbusTcpClient('<PLC_IP>') while True: rr = client.read_holding_registers(40001, 4) syslog.syslog(syslog.LOG_INFO, f"State: {rr.registers}") - Configure Wazuh’s `ossec.conf` to monitor syslog and trigger alerts when register values change outside predefined safe ranges.
4. Implement sequence detection using Sigma rules:
title: Unauthorized Fuel Valve Write condition: select modbus.ref_num==41234 and user!="operator"
5. Forward all logs to a central time-series database (e.g., InfluxDB) to visualize command timelines per user session.
- Simulating OT Attacks in a Controlled Lab Environment
The post provides a Gasflow Terminal Lab simulation at https://lnkd.in/d_pXa45e. Use this to practice attack scenarios without risking physical equipment.
Step‑by‑step lab setup and attack simulation:
- Download the lab simulation (requires registration via Discord at https://lnkd.in/dwdMR9K6).
- Deploy the virtual PLC (Codesys or OpenPLC) and HMI (ScadaBR) on a VMware or VirtualBox host.
- Simulate a state‑change attack – Using a Kali Linux VM, run `modbus-cli` to write a false speed value:
modbus-cli write 192.168.1.100 502 1 40101 30000 Sets turbine RPM to 30,000 (over-speed)
- Observe that the HMI continues showing “normal” because the PLC does not log who changed the register.
- Simulate a replay attack – Capture a legitimate “increase fuel” command with `tcpdump` and replay it using `tcpreplay` during a maintenance window to test if the OT SIEM detects out‑of‑sequence commands.
- Document that no alerts are generated in the default lab configuration – exactly the gap the post describes.
4. Strengthening OT SIEM Visibility with Command Attribution
To solve “no visibility who changed what,” you must integrate identity management at the control layer.
Step‑by‑step guide for Windows-based HMI logging:
- Enable Process Tracking and Audit Logon on the Windows HMI machine (Local Security Policy > Audit Policy).
- Use PowerShell to forward security events (ID 4688 – process creation, 4624 – logon) to a syslog server:
wevtutil get-log Security /p:true > C:\logs\security.evtx
- Install NXLog community edition and configure it to send events to an OT SIEM (e.g., Graylog or Splunk):
<Input in> Module im_msvistalog Query <QueryList><Query Id="0"><Select>EventID=4688</Select></Query></QueryList> </Input>
- Correlate each Modbus write (source IP, timestamp) with a Windows logon session (user ID). Without this mapping, an attacker who compromises an HMI session remains anonymous.
- Test by changing a turbine parameter from the HMI and verifying that the SIEM displays “User: BERNARDT\operator changed register 40101 from 12000 to 30000”.
5. Hardening PLC Access Control and Network Visibility
The post states: “OT security must test control layer – who sends commands, who changes state, who sees it.” Prevention is not enough; continuous verification is required.
Step‑by‑step hardening commands (PLC vendor‑agnostic):
- Disable unused PLC protocols – On Siemens S7, set the protection level to “Hard” and disable ISO-over-TCP port 102. For Rockwell, use the controller’s security configuration tool to block unauthenticated CIP connections.
- Deploy 802.1X on OT switches – Authenticate every PLC and HMI before granting network access. Use FreeRADIUS on a hardened Linux server:
sudo apt install freeradius nano /etc/freeradius/3.0/clients.conf
Add each OT device’s MAC address as a trusted client.
- Implement passive network monitoring – Span port on the main switch to a Raspberry Pi running `zeek` (formerly Bro) with the `modbus` plugin:
zeek -r capture.pcap modbus cat modbus.log | zeek-cut modbus.function modbus.exception
- Automated response – Integrate zeek alerts into a SOAR playbook that quarantines the offending switch port using SNMP‑set commands.
-
Testing the Control Layer with Red Team Scripts
Zakhar Bernhardt emphasizes that “OT security must be testable, not just documented.” Use the lab to run automated attack simulations.
Example Python script to fuzz Modbus registers (run only in lab):
from pymodbus.client import ModbusTcpClient
import random
target = "192.168.1.100"
client = ModbusTcpClient(target)
for reg in range(40001, 40050):
value = random.randint(0, 65535)
client.write_register(reg, value)
print(f"Wrote {value} to register {reg}")
client.close()
After fuzzing, check if the HMI logs any of these changes or if the turbine simulation enters a failure mode without alarms. The absence of alerts confirms the monitoring gap.
7. Mastering OT Security with the Labshock Masterclass
The post announces a free Masterclass: “Gas Station Systems – deeper into process logic, turbine, HMI, SCADA and OT security.” Register via https://www. .com/posts/zakharb_labshock-share-7460764972109758464-8DPq (partial link; join Discord for full access). The Masterclass covers live demonstrations of command injection into the control loop and how to build a testable OT security framework using the Gasflow Terminal Lab.
What Undercode Say:
- Key Takeaway 1: The PLC and HMI define “normal” independently from physical limits. If an attacker manipulates the control logic, the turbine’s operational state becomes decoupled from actual physics, yet the HMI continues displaying green indicators – a silent failure that no traditional IDS will detect.
- Key Takeaway 2: Most OT SIEM deployments focus on perimeter events or network anomalies but ignore sequence awareness and command attribution. Without logging who changed which register at what time, incident responders cannot distinguish between a legitimate operator action and a malicious command replay from a compromised engineering workstation.
Analysis: Zakhar Bernhardt’s post highlights a foundational flaw in current OT security practice: documenting security policies without making them testable. The Gasflow Terminal Lab simulates a real GE turbine control system, proving that even when PLC and HMI are present, the monitoring layer remains blind to state‑change sequences. This gap is not academic – it directly enables attackers to slowly alter operational parameters (e.g., increasing fuel flow by 1% every hour) until the turbine enters an unsafe regime, all while the HMI reports “normal.” Closing this gap requires shifting from passive log collection to active verification: replaying recorded commands in a sandbox, enforcing signed Modbus transactions, and auditing every control cycle for deviations from a learned baseline. Until then, any OT environment that relies solely on vendor HMIs for situational awareness is running on blind trust.
Expected Output:
The article provides a blueprint for identifying and mitigating weak OT monitoring through simulation, SIEM enrichment, network capture, and automated testing. It directly applies Zakhar Bernhardt’s insights to practical Linux/Windows commands, lab exercises, and hardening steps, enabling security teams to transform “documented security” into testable, verifiable control layer protection.
Prediction:
Within 18 months, regulatory frameworks (e.g., NERC CIP, IEC 62443) will mandate continuous validation of control layer integrity, requiring OT operators to prove that their SIEM can detect sequence‑level anomalies and command attribution failures. We will see a surge in “control layer red teaming” as a service, where providers like Labshock use simulated turbines and gas terminals to benchmark real‑world monitoring gaps. Artificial intelligence will be applied to learn normal command sequences from PLC logs, flagging even subtle deviations that human engineers might dismiss. However, the fundamental challenge – that the PLC defines reality – will persist, pushing the industry toward immutable control logs and hardware‑rooted attestation of each control cycle.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zakharb Otsiem – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
