Labshock builds a containerised OT lab for ICS defenders

A lab of real OT components, not a protocol simulator

Labshock is described as a practical, environment-driven platform for learning and practicing Operational Technology and ICS security using real industrial components, real protocols and real telemetry. The README is emphatic about one distinction: Labshock is not a simulator, it is a controlled OT security laboratory.

That distinction drives the whole design. The stated goal is to enable safe experimentation with industrial systems that are normally inaccessible, fragile or safety-critical in production. A simulator produces plausible-looking packets on demand; a lab built from real components produces the traffic and the fault behaviour that detection engineers actually have to recognise.

The audience list is specific: OT and ICS security professionals, blue team and detection engineers, pentesters moving into OT, students and researchers learning industrial security, and organisations building OT security maturity. The learning philosophy in the README says it plainly: focus on system behavior, not tools, learn from real events rather than synthetic alerts, and distinguish faults from attacks through evidence.

That last point is the one that separates this from a generic capture-the-flag. The goal is not to break a controller, it is to write detection logic that survives contact with a noisy environment where a pump failure and an intrusion look similar in the logs.

The repository itself is thin. It holds the README, a LICENSE file, images, the oilsprings directory and a docker-compose.yml, which tells you the heavy lifting happens inside images pulled from a registry rather than in scripts you run.

The Portal container mounts the Docker socket to start labs

The architecture is visible in the compose file, which is the most informative document in the repository. Two services are declared, plus a bridge network and a named volume for portal configuration.

The Portal is the entry point and the command center for the World of Labshock. Its service definition:

services:
  portal:
    image: zakharbz/labshock-portal:latest
    ports:
      - '443:443'
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portal-data:/app/config/
    networks:
      - portal_network

Two details matter. The Portal is published on host port 443, so the web interface is served over TLS on the standard HTTPS port. And it mounts the Docker socket from the host, which is what gives it the ability to launch and stop lab services, start and stop components and build custom lab setups on demand. That design is what makes a single compose project expand into a full range.

The second service is the launcher:

  launcher:
      image: zakharbz/labshock-launcher:latest
      volumes:
        - /var/run/docker.sock:/var/run/docker.sock:ro
        - ./docker-compose.yml:/data/docker-compose.yml:ro
      command: ["tail", "-f", "/dev/null"]

The launcher holds a read-only view of the Docker socket and of the compose file itself, and its command is a tail that does nothing. It exists as a stable container the Portal can exec into when it needs to bring up further services. The launcher mounts the socket read-only while the Portal mounts it read-write, which is a deliberate difference in privilege.

SCADA and PLC speak the protocols defenders actually meet

The services are the substance of the lab. The SCADA service is described as the eyes of Labshock and supports Modbus RTU and TCP, Ethernet/IP, BACnet IP, OPC UA, WebAPI, MQTT and S7. The PLC service is the brain, and each service has its own wiki page with usage details.

The protocol list is the part that should drive the adoption decision. Detection rules in OT are written against specific industrial protocols, and a range that only speaks one of them teaches the wrong reflexes. Modbus has no authentication, MQTT is used pervasively for telemetry bridging, and OPC UA and BACnet IP behave differently enough that rule logic written for one will not transfer to another.

Alongside SCADA and PLC, the README lists an EWS and a DMZ in the range layout, plus SIEM-focused visibility, analysis and correlation as a stated capability. The capability list mentions capture of traffic, testing of SIEM rules and refinement of IDS detection, event and log generation from OT environments, log normalization and contextualization, and correlation of security-relevant signals.

That is a detection engineering environment rather than an exploitation environment. The value proposition is that you can replay or generate industrial events and watch how your SIEM treats them, then iterate on the rule.

World of Labshock turns labs into a progression system

Version 2, released as the World of Labshock, expanded the project from isolated environments into a connected path with structure, zones and guided learning. The stated aim is progression across industries, across architectures and across maturity levels.

The Portal implements that as a game-shaped interface. According to the README you can track progression from Level 1 to 60, with XP, achievements and skills earned through hands-on actions. There is a world map of ten zones, each representing a new layer of OT security complexity, and the interface shows your current location with zone-specific quests, guides and contextual explanations. Theory and practical playbooks are tied to the zones, quests and labs, and objectives define what to do next and which concepts you unlock.

This is worth judging on its merits rather than taste. A gamified structure solves a real problem in OT training: the field is large, entry points are unclear, and experienced engineers arrive knowing more than the linear material assumes. Progression across architectures and maturity levels gives a shared vocabulary between a newcomer and a senior detection engineer.

The risk is that the game layer sits on top of a small number of actual labs, so a learner who rushes to level 60 may map a handful of environments repeatedly. The README does not publish a catalogue of lab scenarios, so treat the zone count as a curriculum shape rather than as a count of distinct environments.

Docker on the host and a two CPU floor

The requirements are short and worth reading literally. The README says to install Docker, that is all, then gives a minimum of 2 CPUs, 2G of RAM and 10G of disk, and a maximum of 4 CPUs, 8G of RAM and 20G of disk. The maximum reads more like a recommended ceiling than a hard limit.

Those numbers are modest because the range is containerised rather than a rack of hardware. Everything runs as Docker images, so the host only needs to run Docker and the images do the rest.

The install path itself is documented outside the repository. The README links a Quickstart guide in the project wiki, and that guide is where the actual command sequence lives. The repository gives you the compose file that defines the Portal and launcher services, and the wiki gives you the steps to bring them up, configure the environment and start your first lab. There is no install script in the tree to run, and no package to install.

Other resources the project points to sit alongside the wiki: a project website, a playlist of video walkthroughs on YouTube, a support Discord and a LinkedIn page for updates. The Discord is the practical route for questions, since lab setup on a specific host is where people get stuck.

One operational warning belongs here as well. The README repeats that you are running the lab at your own risk, that it is intended for educational and lawful testing in isolated environments, and that the author is not responsible for damage, data loss or legal issues.

Trial mode puts a 40 minute clock on every session

Licensing is unusual enough to deserve its own section, because it changes how you plan your work. Labshock is free to explore with a built-in trial mode and no licence is needed to get started. When you run it without a licence it starts in trial mode with a 5-minute initialization delay, a 40-minute session limit and unlimited restarts.

For a learning platform this is defensible: short sessions suit a self-guided curriculum, and restarting is cheap because the environment is defined in containers. For detection engineering it is more awkward. Writing and refining a SIEM rule is rarely a 40-minute activity, and the 5-minute startup cost applies to every restart, so a day of iterative work against a lab will be spent waiting.

The README states that long-term use, education and enterprise deployments need to be arranged directly with the author, and the site and Discord are the routes for that conversation. The repository's own licence field is a custom licence that GitHub cannot classify, with the terms in the LICENSE file, so the licence for the code itself is separate from the commercial terms for extended use.

Because the repository also ships a World of Labshock release as v2 on 2026-03-02 alongside Labshock v2.1.5 on 2026-01-17 and a v2.1.4 beta on 2026-01-03, the versioning spans both the lab environment and the learning layer, which is worth checking against the documentation you follow.

Labshock against a flat simulation or vendor hardware

There are two other ways to get OT traffic in front of your detection tooling, and each differs from Labshock in a way that matters.

The first is a flat simulator, where a tool generates protocol conversations without running the equipment. The cost is realism. A simulator will tell you that a Modbus write occurred, but the timing, the retries, the noise from other traffic and the state left behind by a fault are the parts a rule has to survive, and those are exactly what a simulator abstracts away. The README's insistence that this is not a simulator is a claim about that gap.

The second is vendor hardware or a vendor-provided range, which gives maximum fidelity and a real physical process, at the price of procurement, physical safety procedures and availability. Labshock sits between the two: real protocols and real telemetry from real components, running as containers you can create and destroy.

The practical trade-off is that the OT community often combines them. Use a containerised range for rule development and iteration, where you want a fresh environment in seconds, and reserve physical hardware for validating that the rule works against the actual process behaviour.

The one thing a containerised range cannot give you is the safety and process dimension of real hardware, so anything involving actual actuation risk still belongs on an approved rig.

Maintenance state and what the repository does not cover

The repository is not archived, and the last push was on 2026-05-28. Releases are frequent by the standards of infrastructure projects: the World of Labshock release v2 on 2026-03-02, Labshock v2.1.5 on 2026-01-17 and the v2.1.4 beta on 2026-01-03. The default branch is main.

What the repository does not contain is worth noting, because it shapes what you can audit yourself. The top level contains the README, the LICENSE, a .gitattributes file, images, the oilsprings directory and docker-compose.yml. There is no source tree for the services, no build scripts, no test suite and no CI configuration to read. The services arrive as published images tagged latest, and the compose file references zakharbz/labshock-portal and zakharbz/labshock-launcher without pinned digests.

Two consequences follow. First, you cannot pin a specific build of the lab environment through the repository alone, since the images are referenced by the latest tag, so environment changes are possible between runs. Second, an audit of what runs inside the containers depends on the images rather than on this source tree, and the custom licence in the LICENSE file governs the repository contents.

If reproducibility and inspection of the range matter to your evaluation, treat the pinned image versions and the published documentation as the artifacts to review, and confirm with the author what changes between tagged releases.

Editorial conclusion

Adopt Labshock for OT detection engineers, blue teams and pentesters moving into ICS who need real protocol traffic and event logs to test SIEM rules against. Do not use it as a production range or an attack tool against systems you do not own, since the project states it is for educational and lawful testing in isolated environments only, and remember that every session is capped at 40 minutes without a licence. Verify first that Docker is installed and that your host meets the minimum of 2 CPUs, 2G RAM and 10G disk, then follow the Quickstart guide in the project wiki. The last push was on 2026-05-28.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zakharb/labshock on GitHub