Listen to this Post
Introduction:
For over a year, Friedrich-Alexander-Universität Erlangen-1ürnberg (FAU) has been the first German university to integrate Labshock—a hands-on OT/ICS cybersecurity lab environment—into its academic curriculum, transitioning from conceptual discussions to a full working environment for students. Now, Zakhar Bernhardt, Founder & CEO of Labshock Security and Architect at Primion, returns to FAU’s Summer School to deliver a pivotal message: OT security must be testable, not documented. This article unpacks the technical core of that philosophy, providing actionable commands, configuration steps, and detection strategies for securing industrial control systems in an era where machine behavior—not just network packets—defines the attack surface.
Learning Objectives:
- Understand the architectural difference between IT and OT security, including the Purdue Model and the role of PLCs, SCADA, and industrial protocols.
- Deploy a Docker-based OT security lab (Labshock) in under 10 minutes for safe attack simulation and defensive validation.
- Master essential Linux and Windows commands for OT network scanning, Modbus enumeration, firewall hardening, and SIEM integration.
- Apply MITRE ATT&CK for ICS mapping to detect and mitigate real-world threats like rogue commands and denial-of-service.
- Develop detection logic grounded in operational reality, distinguishing faults from attacks through evidence and system behavior.
- Deploying a Full OT/ICS Cyber Range with Labshock (Linux & Windows)
Labshock is a practical, environment-driven platform for learning and practicing OT and ICS security using real industrial components, real protocols, and real telemetry. It is not a simulator; it is a controlled OT security laboratory that provides a ready-to-use environment to learn, simulate, and test defensive strategies. The platform replaces legacy virtualization with a simple, Docker-based solution, reducing setup time from hours to minutes.
Step‑by‑Step Guide:
Prerequisite: Install Docker and Docker Compose.
For Linux (Ubuntu/Debian):
sudo apt update && sudo apt install -y docker.io docker-compose sudo systemctl enable --1ow docker sudo usermod -aG docker $USER
For Windows (PowerShell as Administrator):
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All Install-Module -1ame DockerMsftProvider -Force Install-Package -1ame Docker -ProviderName DockerMsftProvider -Force Restart-Computer
Deploy Labshock:
git clone https://github.com/zakharb/labshock cd labshock docker compose up -d
Within minutes, you have a full OT/ICS cyber range with SCADA, PLC, Engineering Workstation (EWS), and DMZ segments. Minimum requirements: CPU 2, RAM 2G, HDD 10G; maximum: CPU 4, RAM 8G, HDD 20G. Labshock includes a built-in trial mode with a 5-minute initialization delay and a 40-minute session limit (unlimited restarts).
- Industrial Protocol Visibility: Capturing and Analyzing Modbus Traffic
Modbus is one of the most abused protocols in industrial systems. Understanding its function and potential risks is critical for OT security. Labshock provides pre-configured environments with Modbus TCP traffic, allowing analysts to inspect protocol behavior safely.
Step‑by‑Step Guide:
Capture Modbus Traffic with tshark (Linux):
tshark -i eth0 -Y "modbus" -V
This command captures live traffic on interface eth0, filters for Modbus packets, and provides verbose output including function codes and data payloads.
Enumerate Modbus Devices with Labshock:
Within the Labshock environment, use the built-in scanning tools to discover PLCs on the OT network. A typical scan identifies devices, their register maps, and coil states—critical for understanding the control logic before any security testing.
Modbus Read Command (using modbus-cli):
modbus read --ip=192.168.1.100 --register=0 --count=10
This reads 10 holding registers starting at address 0 from a PLC at IP 192.168.1.100. Always perform such actions in isolated lab environments only.
3. Simulating PLC Attacks and Validating Defensive Strategies
OT security is not only cyber; it is control, signal, and machine behavior. Attack simulation must be safe, and detection must be validated against process impact.
Step‑by‑Step Guide:
Simulate a Modbus Write Command (Potential Attack):
Using a Python script or modbus-cli, you can write to a PLC coil to simulate a pump start/stop:
modbus write --ip=192.168.1.100 --coil=0 --value=1
Note: This command is for educational use in isolated Labshock environments only.
Monitor with Labshock’s Built-in IDS:
Labshock integrates Intrusion Detection System (IDS) solutions for real-time monitoring and security analysis. The IDS monitors network traffic and detects suspicious activities in industrial control environments. To view IDS alerts:
docker logs -f labshock-ids
Test Detection Logic:
Labshock is built around event-driven OT security understanding: hands-on first, theory when needed; focus on system behavior, not tools; learn from real events, not synthetic alerts; distinguish faults from attacks through evidence.
4. OT SIEM Integration: Log Normalization and Correlation
Security Information and Event Management (SIEM) in OT environments requires understanding operational and safety impact, not just IT-style log aggregation. Labshock provides SIEM-focused visibility, analysis, and correlation.
Step‑by‑Step Guide:
Deploy ELK Stack for OT Log Monitoring:
docker pull sebp/elk docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -it --1ame elk sebp/elk
This deploys Elasticsearch, Logstash, and Kibana for log aggregation and visualization.
Normalize OT Logs:
Within Labshock, event and telemetry collection is pre-configured. Logs from PLCs, SCADA, and network devices are normalized and contextualized. Use the following to view normalized logs:
docker exec -it labshock-elasticsearch curl -X GET "localhost:9200/_cat/indices?v"
Write Correlation Rules:
Labshock enables writing correlation of security-relevant signals. A simple correlation rule might alert when a Modbus write command to a critical coil occurs outside of scheduled maintenance windows. This is configured via the Labshock SIEM interface or custom scripts.
- OT Network Hardening: Linux iptables and Windows Firewall Commands
Network segmentation is a core OT cybersecurity principle. Never allow direct access from the corporate network to PLCs, SCADA, or other control devices.
Step‑by‑Step Guide:
Linux iptables for OT Subnet Isolation:
Block all forwarding between IT (eth0) and OT (eth1) interfaces iptables -A FORWARD -i eth0 -o eth1 -j DROP iptables -A FORWARD -i eth1 -o eth0 -j DROP Whitelist only Modbus traffic (TCP/502) from a specific OT subnet iptables -A FORWARD -p tcp --dport 502 -s 192.168.10.0/24 -j ACCEPT iptables -A FORWARD -p tcp --dport 502 -d 192.168.10.0/24 -j ACCEPT
These commands establish a basic policy, allow only specific necessary traffic to an OT network segment, and log any denied packets.
Windows PowerShell Firewall Rules:
Block inbound SMB traffic (common attack vector) on port 445
New-1etFirewallRule -DisplayName "Block SMB OT" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Block
Ensure firewall is active
Set-1etFirewallProfile -Profile Domain,Public,Private -Enabled True
Audit existing rules for industrial protocols like Modbus (port 502)
Get-1etFirewallRule | Where-Object { $_.DisplayName -match "Modbus|502" }
These commands create mandatory firewall rules using the built-in NetSecurity module to dynamically block traffic.
- MITRE ATT&CK for ICS Mapping and Detection Engineering
Understanding adversary behavior in OT environments requires mapping to the MITRE ATT&CK for ICS framework. Common techniques include Unauthorized Command Message (T0855), Modify Controller Tasking (T0821), and Denial of Service (T0814).
Step‑by‑Step Guide:
Run MITRE ICS Check Script (if available in Labshock):
python3 mitre_ics_check.py --target=PLC_IP
This script checks for common ICS attack techniques mapped to the MITRE framework.
Build Detection Logic:
Labshock’s philosophy emphasizes building detection logic grounded in operational reality. For example, to detect a potential Modbus write attack (T0855), monitor for unexpected writes to holding registers that control physical processes. A simple detection rule in pseudo-code:
IF (modbus.write.function_code == 6 OR 16) Write Single or Multiple Registers
AND (modbus.write.register IN CRITICAL_REGISTERS)
AND (modbus.write.timestamp OUTSIDE MAINTENANCE_WINDOW)
THEN ALERT("Potential Unauthorized Command - T0855")
7. PLC Programming Fundamentals for Security Professionals
Zakhar Bernhardt emphasizes that before you write PLC logic, you need to understand what you control—a signal is not just data, a tag is not just a variable, a PLC output represents machine state. This is where OT security starts: from system behavior, not from exploit tools.
Step‑by‑Step Guide (Conceptual within Labshock):
- Understand the Automation Stack: Sensor → PLC Input → PLC Memory → Logic Execution (Cyclic Scan) → Output → HMI Tag → Physical Process.
- Write a Simple Ladder Logic Program: Within Labshock’s PLC Programming zone, create a basic program that reads a sensor input and controls a motor output. This builds understanding of how process state translates to network traffic.
- Correlate PLC Logic with Network Traffic: Use Wireshark to capture Modbus traffic while the ladder logic executes. Observe how a change in sensor state generates a specific Modbus read request, and how the PLC’s response updates the HMI.
- Simulate an Attack on Your Own Logic: After understanding the normal behavior, attempt to write a rogue Modbus command to change the motor state. Observe the impact on the physical process simulation and the corresponding IDS alert.
What Undercode Say:
- Key Takeaway 1: OT security must be testable, not documented. Theory and documentation are insufficient; hands-on validation in a safe, isolated lab environment is essential for building transferable skills.
- Key Takeaway 2: Understanding system behavior precedes security testing. You cannot secure what you do not understand. PLC logic, SCADA visualization, and industrial protocol behavior form the foundation of any effective OT security program.
Analysis (Extended):
The FAU Summer School talk underscores a critical paradigm shift in cybersecurity education. For decades, IT security has relied heavily on documentation, compliance checklists, and theoretical risk assessments. OT security, however, deals with physics, machinery, and real-world consequences. A misconfigured firewall in IT might lead to data loss; a misconfigured PLC in OT can lead to physical damage, environmental harm, or loss of life. Zakhar Bernhardt’s message—that OT security must be testable—directly addresses this gap. Labshock provides the mechanism: a Docker-based, repeatable, and isolated environment where students and professionals can safely “break” industrial systems to learn how to defend them. The platform’s evolution from a single lab to a “World of Labshock” with structured progression across industries and maturity levels reflects the growing complexity of OT threats. The inclusion of PLC programming within the learning path is particularly notable; it acknowledges that effective detection engineering requires understanding the control logic that generates the network traffic. As OT/ICS environments become increasingly connected and targeted by sophisticated adversaries, the ability to simulate, test, and validate security controls in a realistic setting is no longer optional—it is imperative.
Prediction:
- +1 The integration of platforms like Labshock into university curricula will accelerate the development of a new generation of OT security professionals who possess both theoretical knowledge and practical, hands-on experience, significantly raising the baseline security posture of critical infrastructure.
- +1 The Docker-based, low-resource deployment model of Labshock will lower the barrier to entry for OT security training, enabling small and medium-sized enterprises to develop in-house OT security capabilities without massive capital investment in physical testbeds.
- -1 As more professionals gain access to realistic OT attack simulation tools, the risk of misuse—whether through accidental misconfiguration or malicious intent—will increase. Strict adherence to isolated lab environments and ethical guidelines will be paramount.
- +1 The emphasis on PLC programming and system behavior over tool-centric pentesting will lead to more resilient OT architectures, as defenders will be better equipped to distinguish between operational faults and cyber attacks, reducing false positives and improving incident response times.
- -1 The rapid proliferation of AI-driven anomaly detection in OT may outpace the development of foundational system understanding, potentially leading to over-reliance on black-box alerts and a decline in deep, manual forensic analysis skills. Balancing automation with fundamental knowledge will be critical.
▶️ Related Video (80% 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 ✅
