Listen to this Post
Introduction:
Operational Technology (OT) environments are inherently dynamic—PLC logic changes, firmware updates roll out, and new devices join the network. Yet most security labs freeze these systems into static snapshots, creating a dangerous gap between lab representation and real-world runtime. This disconnect breeds false confidence, broken detection rules, and validation drift that attackers can silently exploit.
Learning Objectives:
- Understand why static OT labs fail to simulate real industrial process behavior and how “drift” undermines security testing.
- Learn to implement a continuous validation loop using executable environments, with hands-on commands for monitoring PLC logic and network flows.
- Master techniques to align detection rules with live process states, including Linux/Windows tools for replaying anomalies and verifying correlation logic.
You Should Know:
- Building an Executable OT Environment – From Snapshots to Runtime
Static labs are built once and rarely re-executed, causing detection tests to drift as the real system evolves. An executable environment treats the lab as a living system where PLCs, SCADA, network flows, and detection pipelines run together continuously.
Step‑by‑step guide to create a minimal executable OT testbed:
- Set up a virtualized PLC simulator (e.g., OpenPLC or MatrikonOPC Simulation Server).
- Deploy a SCADA interface (e.g., Grafana + Modbus exporter or Ignition trial).
- Mirror live network traffic into the lab using `tcpreplay` or `tshark` loop.
Linux commands to capture and replay OT traffic:
Capture Modbus/TCP traffic from a live interface (adjust interface and port) sudo tcpdump -i eth0 -s 0 -c 1000 -w ot_traffic.pcap port 502 Replay the captured traffic into your lab environment (e.g., to 192.168.1.100) tcpreplay --intf1=eth1 --loop=1 ot_traffic.pcap Monitor live Modbus queries in real time tshark -i eth1 -Y "modbus" -T fields -e modbus.func_code -e modbus.data
Windows PowerShell alternative (using PcapNg and replay tools via WSL or Npcap):
Install Npcap and WinPcap-compatible tools, then use: & "C:\Program Files\Npcap\Wireshark\tshark.exe" -i 2 -Y "modbus" -T fields -e modbus.func_code
- Detecting Drift – Comparing Lab State Against Live PLC Logic
When PLC logic changes or firmware updates occur, the static lab snapshot becomes invalid. Continuous testing means every change triggers re-validation.
Step‑by‑step to detect logic drift:
- Extract live PLC logic using a tool like `plcscan` or `snap7` library.
- Hash the current logic and compare with the last validated lab version.
3. Automate validation on every scan cycle.
Linux command to fetch and compare PLC logic (using snap7 example):
Install snap7 Python library
pip install python-snap7
Create a script to read DB blocks (replace IP and rack/slot)
cat > check_plc.py << EOF
import snap7
client = snap7.client.Client()
client.connect('192.168.1.10', 0, 1)
db_data = client.db_read(1, 0, 100) read DB1, start 0, size 100
with open('/tmp/plc_db1.bin', 'wb') as f:
f.write(db_data)
client.disconnect()
EOF
python3 check_plc.py
Compare with baseline (copy baseline as /tmp/baseline.bin)
cmp -l /tmp/baseline.bin /tmp/plc_db1.bin | wc -l count differences
Windows (using Python and snap7, same script; or Modbus poll tool):
Using Modbus Poll (free version) from command line via automation tool Compare log output fc /b baseline.bin current.bin
- Replaying Detection Rules – Validating Correlation Logic in Runtime
Correlation logic loses context when the lab environment doesn’t match live process states. Every rule must be replayable against current runtime data.
Step‑by‑step to replay and validate a Suricata rule against fresh OT traffic:
- Write a test rule (e.g., detect unusual Modbus function code 0x10).
2. Capture fresh traffic from the live environment.
- Replay the traffic and check if the rule fires as expected.
Suricata rule example (save as `local.rules`):
alert tcp any any -> any 502 (msg:"Modbus Write Multiple Registers"; flow:to_server; modbus.func_code:16; sid:1000001; rev:1;)
Replay and validate:
Replay pcap and run Suricata in offline mode sudo suricata -r ot_traffic.pcap -S local.rules -l ./suricata_output/ Check alerts cat suricata_output/fast.log | grep "1000001"
- Automating the OT Security Loop – Build, Run, Change, Validate, Repeat
Inspired by Labshock’s execution‑based direction, the security loop must behave like an engineering system with physical consequences. Automation ensures every change triggers validation.
Step‑by‑step CI/CD pipeline for OT environments (using GitLab CI or Jenkins):
- Store lab configuration as code (Dockerfiles for SCADA, Ansible playbooks for network topology).
- On every change (e.g., PLC logic update), spin up a fresh lab instance.
- Run automated test suite – detection rules, anomaly injection, flow validation.
4. Report drift if test fails.
Example GitHub Actions workflow snippet:
name: OT Lab Validation on: push jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Deploy OT lab with docker-compose run: docker-compose -f ot-lab.yml up -d - name: Inject known anomaly (e.g., malformed Modbus) run: python test_inject.py --target plc_simulator --anomaly type=corrupt - name: Run detection rules run: suricata -r replay.pcap -S rules/ -l logs/ - name: Compare alerts with baseline run: diff expected_alerts.txt logs/fast.log
- Hardening Against Drift – Continuous Monitoring and Documentation Override
Teams often trust stale documentation instead of runtime reality. Replace static diagrams with live asset inventories and real‑time network maps.
Step‑by‑step to implement live OT asset inventory:
- Deploy passive monitoring (e.g., Zeek, GRASSMARLIN) to discover PLCs, HMIs, RTUs.
- Push discovered assets to a version‑controlled JSON file.
- Alert when new devices appear or old ones vanish.
Linux – Zeek script to log all Modbus/TCP conversations:
Install Zeek
sudo apt install zeek
Enable Modbus analyzer in local.zeek
echo 'protocol_analysis_ports += { { "modbus", 502 } };' >> local.zeek
Run live capture on interface eth0
sudo zeek -i eth0 local.zeek
Check generated conn.log and modbus.log
cat modbus.log | zeek-cut uid modbus.func
Windows – Using PowerShell to poll SNMP for PLCs:
Get SNMP system name for a PLC (requires SNMP enabled)
Get-SnmpOid -IPAddress 192.168.1.10 -Oid .1.3.6.1.2.1.1.5.0 -Community public
Loop through subnet
1..254 | ForEach-Object { Get-SnmpOid -IPAddress "192.168.1.$($_)" -Oid .1.3.6.1.2.1.1.1.0 -Timeout 500 -ErrorAction SilentlyContinue }
6. Training and Tooling for Executable OT Security
To operationalize continuous testing, teams need hands‑on courses and tools that emphasize runtime validation over static documentation.
Recommended training paths:
- SANS ICS410 (ICS/SCADA Security Essentials) – includes lab exercises with live PLC simulators.
- INE’s OT Security Course – covers Modbus, DNP3, and detection rule writing.
- Open‑source tool stack:
OpenPLC,GRASSMARLIN,Zeek OT plugin, `Node-RED` for SCADA simulation.
Quick lab setup script (Linux) to learn concepts:
Launch a complete training environment in Docker docker run -d --1ame ot-lab -p 502:502 -p 8080:8080 \ -e PLC_PROGRAM=simple_cycle \ ghcr.io/ot-simulator/labshock-demo:latest Test connectivity nmap -p 502 localhost --script modbus-discover
What Undercode Say:
- Key Takeaway 1: Static OT labs are a liability—without runtime execution, small drifts accumulate into false confidence that attackers love. Continuous validation loops are the only way to keep detection and correlation logic aligned with live process behavior.
- Key Takeaway 2: The shift from “description layer” to “execution layer” transforms OT security from documentation‑based to evidence‑based. Teams must adopt engineering discipline (build→run→change→validate→repeat) and automate replay of every rule against current state.
Analysis (10 lines):
This post by Zakhar Bernhardt cuts to the core failure of traditional OT security labs: they model the past, not the present. Industrial systems evolve constantly—PLC logic updates, firmware patches, and new field devices change the attack surface daily. Yet most labs freeze a snapshot, causing detection rules to silently go stale. The proposed solution, executable environments, mirrors modern DevOps practices but applied to physical consequences. Continuous testing forces every anomaly to be validated against current process state, eliminating the trust gap between documentation and runtime. This approach directly addresses the “drift” problem that leads to missed intrusions (e.g., TRISIS, CrashOverride). Adoption requires a cultural shift from periodic assessments to live validation pipelines. Tools like tcpreplay, Suricata, and Zeek become the backbone of OT testing. The biggest barrier is legacy equipment that cannot be easily virtualized—but partial simulation is better than frozen diagrams. Ultimately, the post argues that runtime is the only truth in OT security.
Prediction:
- +1 OT security teams will increasingly adopt “validation as code,” integrating CI/CD pipelines with PLC simulators, reducing mean time to detect drift from months to minutes.
- +1 Open‑source tooling around executable OT environments will flourish, lowering the barrier for small manufacturers to implement continuous testing without expensive vendor lock‑in.
- -1 Legacy industrial sites with no virtualizable PLCs will remain vulnerable; false confidence from static labs may persist, leading to breaches that could have been caught by runtime validation.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Zakharb Labshock – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
