CyberBlue: a containerised SOC lab for blue team training

A training platform, and the warnings that come with it

CyberBlue is described as a comprehensive, containerised cybersecurity learning platform that brings together open source tools for SIEM, DFIR, CTI, SOAR and network analysis. The readme puts the label on it several times over: a learning and training platform, an educational and testing environment only, and a purpose badge that reads EDUCATION ONLY.

The security notice is the part to read first, because it is unusually blunt about what the project is not. There are no security guarantees and it is not suitable for processing real sensitive data or monitoring production systems. All tools use well-known default passwords, with admin and cyberblue given as the examples. Authentication on the portal has been removed for ease of lab access. It is beta software for learning purposes. The list of things to never use it for is short and absolute: processing any sensitive, confidential or production data.

The legal disclaimer says the software is provided as is for educational purposes, with no warranty or guarantee of security, that users are solely responsible for ensuring appropriate use in isolated lab environments, and that the maintainers are not liable for damages or security incidents resulting from use or misuse.

The listed appropriate use cases are training courses and certifications, security tool evaluation and testing, academic institutions and research labs, isolated home labs, SOC analyst skill development, and capture-the-flag exercises.

That framing is the honest one, and it is also what makes the project useful. A lab that carries no real data and uses default credentials is exactly what you want for a student, and the fact that the readme says so in capitals rather than in a footnote is a sign of a maintainer who understands where the risk is.

The version is 1.0-beta, described as the initial release, the licence is MIT per the readme badge, and the website is cyberblue.co.

Fifteen-plus tools, one compose file

The tool inventory is what the platform actually is, and it is organised by the job a tool does in a SOC.

For SIEM and monitoring there is Wazuh for host-based intrusion detection and log analysis, Suricata for network intrusion detection and prevention, and EveBox for Suricata event and alert management. For DFIR and forensics there is Velociraptor for endpoint visibility and digital forensics, Arkime for full packet capture and network analysis, and Wireshark as the protocol analyser. For threat intelligence there is MISP and the MITRE ATT&CK Navigator for threat modelling and visualisation. For SOAR and automation there is Shuffle for orchestration, TheHive as the incident response platform, and Cortex as the observable analysis engine.

The utilities and management layer has CyberChef, Portainer for container management, FleetDM as a device management and osquery fleet manager, and Caldera for adversary emulation.

Two tools are installed directly on the host rather than in containers, and the readme explains why in each case. YARA is installed on the host with no container overhead, with 523 or more curated rules from the Yara-Rules project at /opt/yara-rules/, used as yara -r /opt/yara-rules/malware_index.yar /path/to/file, and it is said to work with Velociraptor, TheHive and Cortex as well as the command line. Sigma's CLI is also on the host, with 3,047 or more detection rules from SigmaHQ at /opt/sigma-rules/, used to convert rules to Wazuh, OpenSearch or Elasticsearch format with sigma convert -t opensearch_lucene --without-pipeline rule.yml.

The reason those two sit on the host is the need to scan the filesystem and to convert rule files, and running them natively avoids copying volumes into a container for the privilege of doing it.

What the compose file shows about the architecture

The docker-compose.yml in the repository root is the clearest description of how the platform fits together, and it is worth reading before installing.

The portal service is built from the ./portal directory with its own Dockerfile, is named cyber-blue-portal, and publishes two ports, 5500 for HTTP and 5443 for HTTPS. Its environment sets FLASK_ENV=production, ENABLE_HTTPS=true, SSL_CERT_PATH and SSL_KEY_PATH pointing into a mounted ./portal/ssl directory, HOST_IP and the install directory and user, and a SECRET_KEY whose default value is a literal placeholder string that says to change it in production. ADMIN_PASSWORD defaults to cyberblue123.

The volume list is the interesting part. The portal mounts /var/run/docker.sock, which gives the container control of the Docker daemon on the host, and it mounts the Velociraptor, Wazuh agent, Fleet agent and Caldera agent directories, the YARA and Sigma rule directories on the host, and /var/log. Those mounts are how agent deployment and rule sharing work, and they are also why the platform must live on an isolated host.

Portainer runs from the stock portainer/portainer-ce:latest image with the same Docker socket mount, publishes 9443 for its own interface, and publishes 8001 for the underlying Portainer API, with a comment in the file noting that the port was changed to avoid a conflict with Velociraptor. The MITRE ATT&CK Navigator is built from ./attack-navigator with port 7013 mapped to the container's 4200. Wireshark runs from a linuxserver image with NET_ADMIN added and host networking.

Every service joins a network called cyber-blue, and the services use restart: unless-stopped. The Makefile in the repository root reduces the whole thing to three targets: init runs sudo bash cyberblue_init.sh, up runs sudo docker compose up -d, and down runs sudo docker compose down.

The Makefile at the repository root reduces the whole platform to three targets:

sudo bash cyberblue_init.sh
sudo docker compose up -d

and to shut it back down:

sudo docker compose down

Sample data, and the parts that live on the host

The readme's feature list makes the point that this is pre-populated, and that is what makes it a learning environment rather than an empty set of dashboards.

There is sample data included: Arkime with network captures and Suricata with more than fifty thousand events. There is a generate-pcap-for-arkime.sh script in the repository root for producing capture data, and a separate ARKIME_SETUP.md document. The detection content is pre-installed as well, with the YARA and Sigma rule sets described above already in place.

The configuration is partly done for you too, with automatic network detection and setup, and the .env.example file shows the scope of it. For MISP there is a base URL of https://127.0.0.1:7003. For Velociraptor there are VEL_USER and VEL_PASSWORD, the latter defaulting to cyberblue. For Suricata there is SURICATA_INT set to eth0. For Arkime the example sets the admin password to admin, the hostname to localhost, CAPTURE to off, the capture interface to eth0 and the viewer on, and it configures OpenSearch with OS_VERSION 2, a node named os01, and OS_JAVA_MEM set to 512m, with a commented reminder to adjust docker-compose.yml as well if a second node is added.

The .env.example also carries a Yeti section, with a Redis host, an ArangoDB host and database, an HS256 auth algorithm, token expiry values, a Timesketch endpoint and a bloomcheck endpoint, and a comment noting that an empty secret produces an error at startup.

The repository root shows how much of this is shell. Besides the compose file there is cyberblue_install.sh, install-prerequisites.sh, setup-prerequisites.sh, install_docker.sh, install_caldera.sh, force-start.sh, update-network-interface.sh, verify-post-reboot.sh, and a set of fix scripts for Arkime, Docker external access, Fleet, VMware compatibility and Wazuh services. That list is itself information about the project: each of those scripts exists because a specific deployment of this stack hit a specific problem.

Where CyberBlue is the wrong choice

The first limitation is stated by the project, and it is the reason to treat this as a lab tool and nothing else. There are no security guarantees, the tools use well-known default passwords, portal authentication is removed, and the software must not process sensitive or production data. A platform whose own readme tells you not to point it at real systems is not a monitoring platform, and adopting it as one is not a configuration mistake you can fix later.

The second is the Docker socket. The portal and Portainer both mount /var/run/docker.sock, which is effectively root on the host by another route. Combined with default credentials, no authentication and a bridge to the Velociraptor, Wazuh, Fleet and Caldera agent directories, an exposed instance of this platform is an open door. It belongs on a lab VM, on an isolated VLAN, and nowhere else.

The third is the composition itself. You are assembling fifteen or more independently versioned upstream projects, each with its own release cycle, its own configuration format and its own breaking changes, into one compose file. When Wazuh changes an environment variable or TheHive changes its API, the platform does not update itself, and the fix is a pull request against a third-party stack. There is no upstream dependency resolution to save you, so the maintenance burden scales with the number of tools rather than with the number of features you use.

The fourth is the version state. It is version 1.0-beta, described as the initial release, the repository publishes no GitHub releases, and the last push was on 2026-04-18, so nothing has moved for some months. A lab that will be used by a class of students should be pinned and tested, and the beta status means the compose file may still change shape.

The fifth is that the toolset is a snapshot of one author's choices. Caldera is an adversary emulation platform, which is standard in a blue team lab because you need to generate the attacks you then detect, but it is worth being clear-eyed that this platform can simulate adversary activity as well as help you find it, and the readme's warnings about isolation apply to that as much as to the default credentials.

Editorial conclusion

CyberBlue fits a training scenario where the goal is to learn SOC tooling on a realistic stack, since the platform assembles more than fifteen tools with sample network captures, tens of thousands of Suricata events and thousands of detection rules already in place, which is a job that would otherwise take days of individual installs. It is the wrong choice for anything touching production, because the readme states there are no security guarantees, all tools ship with well-known default passwords and portal authentication is removed for lab access. Before deploying it, read the security notice in full, change the default credentials and the secret key, keep it on an isolated network, and note that the last push was on 2026-04-18 with version 1.0-beta and no GitHub releases published.

Frequently asked questions

Official sources

1. cyberblu3s/CyberBlue on GitHub
2. Issues
3. README