How to Build an OT SIEM Lab with Labshock: A Hands-On Guide to Testable Industrial Security + Video

By /

Listen to this Post

Featured Image

Introduction:

Operational Technology (OT) security remains a high-stakes domain where traditional documentation, static diagrams, and compliance reports have long been the standard. However, industrial environments demand a shift from passive assumptions to active, testable validation. Labshock is an open-source OT security laboratory that generates real telemetry from industrial processes, PLCs, SCADA systems, and network traffic, enabling detection engineers to validate correlation rules, AI models, and SOC workflows before deployment in production environments.

Learning Objectives:

  • Objective 1: Deploy a fully functional OT/ICS cyber range with SCADA, PLC, EWS, and DMZ components using Docker.
  • Objective 2: Collect, parse, and forward OT telemetry to leading SIEM platforms including Microsoft Sentinel, Splunk ES, and Wazuh.
  • Objective 3: Develop and test custom detection rules and MITRE ATT&CK mappings in a safe, isolated environment without risking live operations.

You Should Know:

  1. Setting Up the Labshock Environment – Deploying Your OT/ICS Cyber Range

Labshock is built with Docker and provides a lightweight way to spin up a complete industrial control system environment. It includes a programmable logic controller (PLC), human-machine interface (HMI), SCADA visualization, a dedicated attacker machine (Kali Linux), and a collector service that aggregates logs from all components.

Step-by-Step Guide:

  1. Clone the repository and navigate into the directory: 
    git clone https://github.com/zakharb/labshock.git
cd labshock

  2. Review the Docker Compose configuration to understand the architecture:

    cat docker-compose.yml

3. Start all services in detached mode:

docker-compose up -d

This command launches the PLC simulator, SCADA interface, collector service, IDS, and the Kali attack machine.

4. Verify that all containers are running:

docker ps

Expected output includes labshock-plc, labshock-scada, labshock-collector, labshock-ids, and kali.

  1. Access the SCADA web interface at `http://localhost:8080` (default credentials are provided in the repository documentation).

  2. For Windows users, ensure Docker Desktop is installed with WSL2 backend enabled. Use PowerShell as administrator to check Docker status:

    docker version

Then proceed with the same commands above.

What This Does: This deployment creates a virtual industrial plant complete with simulated physical processes. The collector service gathers logs, network traffic, and events from all components, generating a continuous stream of OT telemetry that mimics a real production facility.

  1. Integrating Labshock with Wazuh – Open-Source SIEM for OT Security

Wazuh is a free, open-source SIEM and XDR platform that integrates seamlessly with Labshock’s collector. It provides log analysis, intrusion detection, and compliance monitoring, making it ideal for testing detection rules before moving to enterprise solutions.

Step-by-Step Guide:

  1. Install Wazuh using the quick start script on a separate Ubuntu 22.04 VM: 
    curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash wazuh-install.sh --generate-config-files

2. Run the all-in-one installation:

sudo bash wazuh-install.sh --wazuh-indexer node-1 --wazuh-server wazuh-1 --wazuh-dashboard dashboard-1 --start-cluster

Note the admin credentials displayed at the end of installation.

  1. Configure the Labshock collector to forward logs to Wazuh. Edit the collector configuration file: 
    docker exec -it labshock-collector vi /etc/labshock/collector.conf

Add the following lines:

[bash]
enabled = true
host = <Wazuh-server-IP>
port = 1514
protocol = udp

4. Restart the collector service:

docker restart labshock-collector

5. On the Wazuh server, verify incoming events:

sudo tail -f /var/ossec/logs/archives/archives.log | grep "labshock"
  1. Access the Wazuh dashboard at `https://` and navigate to “Security Events” to see OT telemetry appearing in real time.

What This Does: This integration enables you to validate how Wazuh parses industrial protocols like Modbus, DNP3, and S7comm. Detection engineers can now write custom rules against realistic OT traffic without risking a live plant.

  1. Developing Custom Detection Rules – Modbus Abuse in OT Networks

One of the most common attacks in OT environments is unauthorized Modbus function code execution, which can manipulate physical processes. In this section, we create a custom Wazuh rule to detect Modbus function code 15 (write multiple coils) originating from an unauthorized IP.

Step-by-Step Guide:

  1. On the Wazuh server, create a custom rule file: 
    sudo nano /var/ossec/etc/rules/local_rules.xml

2. Add the following rule:

<group name="ot,modbus,detection_engineering">
<rule id="100001" level="10">
<if_sid>31100</if_sid>
<field name="modbus.function_code">15</field>
<description>Modbus Write Multiple Coils detected from $(srcip) to PLC $(dstip)</description>
<mitre>
<id>T0883</id> <!-- Manipulation of View -->
<id>T0807</id> <!-- Command-Line Interface -->
</mitre>
</rule>
</group>
  1. Create a decoder to parse Modbus traffic from Labshock’s network logs: 
    sudo nano /var/ossec/etc/decoders/local_decoder.xml

Add:

<decoder name="modbus">
<prematch>^Modbus</prematch>
<regex offset="after_prematch">function_code="(\d+)" srcip="(\S+)" dstip="(\S+)"</regex>
<order>modbus.function_code, srcip, dstip</order>
</decoder>

4. Restart Wazuh to apply changes:

sudo systemctl restart wazuh-manager
  1. Simulate a Modbus write attack using the Kali container: 
    docker exec -it labshock-kali /bin/bash

Then run:

python3 /opt/exploits/modbus_write_single_coil.py --target 172.18.0.10 --coil 1 --value 1
  1. Verify the alert appears in Wazuh dashboard within seconds.

What This Does: This rule demonstrates how OT-specific threat detection works. Unlike IT security, where anomalies are based on network patterns, OT detection must understand industrial protocol semantics. Function code 15 on Modbus can trigger physical actions like opening a valve or starting a pump, making this a high-severity alert.

  1. Integrating with Splunk Enterprise Security – Enterprise-Grade OT SOC

For organizations using Splunk ES, Labshock provides one-click integration that delivers OT log collection, parsing, alerts, and MITRE ATT&CK detections.

Step-by-Step Guide:

  1. Install Splunk Enterprise on an Ubuntu 22.04 server (minimum 8GB RAM): 
    wget -O splunk.tgz 'https://download.splunk.com/products/splunk/releases/9.3.0/linux/splunk-9.3.0-12345678-Linux-x86_64.tgz'
tar -xzf splunk.tgz
sudo mv splunk /opt/
sudo /opt/splunk/bin/splunk start --accept-license

  2. Enable the HTTP Event Collector (HEC) on port 8088:

    /opt/splunk/bin/splunk add http-event-collector -uri https://localhost:8089 -name OT_Collector -index main -sourcetype labshock_ot

Note the HEC token generated.

  1. Configure Labshock collector to forward logs to Splunk HEC: 
    docker exec -it labshock-collector vi /etc/labshock/collector.conf

Add:

[bash]
enabled = true
url = https://<Splunk-IP>:8088/services/collector
token = <your-HEC-token>
sourcetype = labshock_ot
index = main

4. Restart the collector:

docker restart labshock-collector

5. In Splunk, search for OT events:

index=main sourcetype=labshock_ot
| stats count by protocol, src_ip, dst_ip
  1. For Splunk Enterprise Security users, deploy the OT Security Add-on to automatically map events to MITRE ATT&CK for ICS.

What This Does: This pipeline allows SOC analysts to treat OT alerts with the same workflows as IT incidents. By feeding realistic OT telemetry into Splunk, teams can practice correlation across IT and OT data sources, identifying multi-stage attacks that bridge the air gap.

  1. Validating Detection Rules with Automated Attack Simulation (CALDERA)

Manual penetration testing is not scalable. Labshock integrates with MITRE CALDERA, an automated adversary emulation platform, to continuously test your detection rules.

Step-by-Step Guide:

1. Deploy CALDERA inside the Labshock network:

docker pull caldera/caldera:latest
docker run -d --name caldera --network labshock_default -p 8888:8888 caldera/caldera
  1. Access CALDERA at `http://localhost:8888` (default credentials: admin/admin).

  2. Install the ICS plugin inside CALDERA to enable OT-specific attack profiles (e.g., TRITON, CRASHOVERRIDE):

    docker exec -it caldera bash
cd plugins
git clone https://github.com/mitre/ics-plugin
exit
docker restart caldera

  3. Create an adversary profile that includes T0883 (Modbus manipulation) and T0843 (Program Download).

  4. Run an automated operation against the Labshock PLC:

    Simulated attack script using python-modbus library
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('172.18.0.10')
client.write_coil(1, True, unit=1)

  5. Monitor Wazuh or Splunk for generated alerts and measure detection latency.

What This Does: CALDERA executes realistic adversary behaviors at machine scale. By running these automated campaigns weekly, detection engineers can identify rule gaps, false positives, and missed techniques before an actual attacker does.

What Undercode Say:

  • Testability Over Documentation: Future OT security will not be based on assumptions enshrined in PDFs and static diagrams. Instead, it will demand continuous validation inside cyber-physical environments—shifting from “best guess” to evidence-based defense.
  • Vendor-Agnostic Integration: The ability to integrate with any SIEM (Sentinel, Splunk, Chronicle, ELK, Wazuh) is critical. OT security should not depend on a single vendor’s ecosystem; it must rely on operational validation, allowing SOCs to use their existing tooling without forklift upgrades.

Analysis: The fundamental problem Zakhar Bernhardt identifies is that most OT security today is built around documentation rather than testable reality. Industrial environments are operational systems with physical consequences, yet compliance frameworks often reward static artifacts over dynamic validation. Labshock flips this by providing a sandboxed industrial environment that generates real telemetry, allowing detection engineers to break things safely. This shift from “documented security” to “testable security” mirrors the evolution of DevSecOps in IT—continuous testing is the only way to keep pace with adaptive adversaries.

Prediction:

Within five years, regulatory frameworks (e.g., NERC CIP, IEC 62443) will require evidence of continuous detection validation, not just documented policies. Organizations that fail to adopt OT cyber ranges like Labshock will face insurance denials, regulatory fines, and increased attack surface. Meanwhile, platforms like Labshock will evolve into commercially supported solutions with turnkey integrations, democratizing OT security testing for small utilities and large industrial conglomerates alike. The “documented security” era is ending; the era of “testable operational security” is beginning.

▶️ Related Video (76% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Zakharb I – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: