# PurpleLab, a detection engineering lab that ships a real Windows VM

> Krook9d/PurpleLab is an AGPL-3.0 lab environment for detection engineers, built as a Flask web interface over OpenSearch with a real Windows Server 2019 VM running Sysmon and Winlogbeat, so a Sigma rule or a MITRE ATT&CK technique can be exercised against actual telemetry rather than a mock.

**Krook9d/PurpleLab** —  PurpleLab is an efficient and readily deployable lab solution, providing a swift setup for cybersecurity professionals to test detection rules and undertake various security tasks, all accessible through a user-friendly web interface

- Repository: https://github.com/Krook9d/PurpleLab
- Stars: 747 · Forks: 127
- Language: PHP
- License: AGPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/krook9d-purplelab

## What PurpleLab is for

PurpleLab is described as an efficient and readily deployable lab solution that gives cybersecurity professionals a swift setup for testing detection rules and undertaking various security tasks through a user-friendly web interface. The README's own framing is a comprehensive cybersecurity lab for creating and testing detection rules, simulating attacks and training analysts.

The word that distinguishes this from a rule validator is real telemetry. The lab is built around a virtual machine with an actual operating system generating actual events, which is what lets a detection engineer see whether a rule fires on the behaviour it is meant to catch rather than on a hand-written log line that somebody wrote to match the rule.

The pages in the table of contents map onto the workflow. There is a Home page with dashboard indicators, a Hunting page, a MITRE ATT&CK page, a Malware page, a Sharing page, a Sigma page, a Rule Lifecycle page, a Health page and an Admin page. The MITRE ATT&CK page is described as an interactive interface for the framework with technique discovery by technique ID, and the Sigma page presumably handles rule validation and testing against the collected data.

The Rule Lifecycle page is the one that suggests the ambition. A rule that is written, tested, deployed, and then produces noisy alerts in production has a lifecycle, and a tool that tracks that lifecycle treats detection engineering as an engineering discipline rather than as writing a regex.

There is also a Splunk app in the table of contents, which tells you the project anticipated people who do not use OpenSearch and wanted a way to consume the same data.

The licence is AGPL-3.0, the primary language is PHP, the default branch is main, and the last push was on 2026-08-22 with the most recent release being PurpleLab V3.0.0 in June 2025.

## The VM, the logging stack and the search backend

The README lists what the automatically configured VM contains, and it is worth reading as the specification of what a useful test environment needs.

The base is Windows Server 2019 with an administrator account, and the README gives the credentials as oem and oem. Sysmon is installed with the SwiftOnSecurity configuration, which is the community configuration for the Sysmon tool and gives detailed process and network events rather than the default set. Winlogbeat OSS 7.12.1 is set up to send logs automatically to OpenSearch.

The attack simulation side is Atomic Red Team with the full test suite, and there is a Python environment with the Chocolatey package manager, the PowerShell-YAML module for YAML file processing, and pre-configured directories for samples, malware uploads and uploads. Windows Defender exclusions are configured for the testing scenarios, which is necessary because the real antivirus would otherwise delete the payloads the tests need.

The Windows Defender exclusions point at the real operational concern with this kind of lab. Detection testing means running things that endpoint security products are designed to stop, so the exclusions are not a shortcut but a requirement, and anyone deploying this has to be sure they are in a disposable environment.

The backend is OpenSearch and the hunting page gives direct access to OpenSearch Dashboards, specifically the Discover view, where you can examine the automatically collected VM logs alongside simulated log data and security events. Sysmon events with detailed process and network information are what most Windows detection work is built on.

The Home page summarises the same data as indicators: event count from the Windows Server VM, unique IP addresses detected in the logs, the count of MITRE ATT&CK techniques and sub-techniques, and the log distribution from the VM collection. Those four numbers are a reasonable summary of whether the pipeline is working, and the Health page presumably gives a more detailed view of the components.

## Installation, accounts and the ELK configuration

The installation section of the table of contents breaks into requirements, installation steps, accounts setup, ELK configuration and VM logs configuration, and that structure tells you the deployment is not a single script.

The reference to ELK configuration in a project that uses OpenSearch is a leftover from the project's earlier shape, when the stack was Elasticsearch, Logstash and Kibana. The Elastic and OpenSearch split has happened, and the naming is what remains.

The accounts setup section describes creating users with an analyst level of N1, N2 or N3, an avatar under 1 MB, and a password of at least eight characters with uppercase, lowercase, a number and a special character. So there is a role model, and the levels map onto analyst seniority, which suggests the lab is intended to be used by more than one person with different responsibilities.

Running it is a Flask server started with a specific interpreter path:

```bash
sudo /opt/purplelab-venv/bin/python /home/$(logname)/app.py
```

The use of an absolute path into a virtual environment, and the substitution of the logged-in user's name for the home directory, tell you the intended deployment shape. The application is expected to live in a user's home directory, with its dependencies in a dedicated virtual environment under /opt, and the sudo suggests the lab runs as a service or under a different account than the one logged in interactively.

The repository layout backs that up. There is a Web/ directory holding the application, an ansible/ directory for the configuration management, scripts/, a cache/, csv/, an enterprise-attack/ directory for the MITRE data, Downloaded/ and uploads/ for the lab's data, Documentation/ and MD_image/ for the README assets, and an install.sh at the root. The Ansible directory is the significant one, because it means the lab is meant to be configured rather than hand-assembled, and reconfiguration is a legitimate thing to do when the underlying software changes.

## How it fits against the alternatives

The alternatives for testing detection rules fall into three groups, and they differ in how much fidelity you buy.

The first is a rule validator. Sigma has a specification and several validators, and a validation failure tells you the rule is malformed. That is a fast check and it belongs in a pull request, but it says nothing about whether the rule detects anything, because the validator has never seen an event.

The second is a synthetic log environment. Detonate, Atomic Red Team run against a real endpoint, and libraries of canned event data all produce a controlled set of events without a full operating system. Detonate is the strongest of these and is a serious alternative, because it runs the adversary behaviour for real. What PurpleLab adds on top is the persistence, the web interface and the ATT&CK and Sigma workflow around it, which matters if several analysts are working in the same environment.

The third is your own infrastructure. A detection engineer with a spare virtual machine can install Sysmon and check the rule by hand. The advantage is that the environment is exactly the one you run in production, which matters when the question is whether a rule fires on your fleet's specific configuration. The disadvantage is that it is not reproducible, and the answer depends on who set up the machine that day.

What PurpleLab offers is a middle ground: a real Windows endpoint, a real log pipeline, and a repeatable configuration. The cost is the operational weight. It is a virtualised stack with a web application, a search backend, an ELK or OpenSearch configuration and a VM, and the installation section is structured like a deployment guide rather than a one-liner. It is a lab you stand up, not a tool you call.

The AGPL licence is worth noting for a project you deploy internally. The obligation bites if you modify it and let users interact with it over a network, which is a narrower case for an internal lab than for a hosted product, but it is the kind of thing a company checks before putting a tool on its network.

The most recent release, V3.0.0 in June 2025, with the last push in August 2026, suggests a project in maintenance rather than active development, which is worth knowing before you plan around it.

## Conclusion

Adopt PurpleLab if you write detection rules and need a repeatable place to test them against real endpoint telemetry. Skip it if you only need a Sigma validator, since that is a much smaller job with a much smaller installation. Verify first by checking that the requirements are met on the host, since the lab is a full virtualised stack rather than a library, and by running one known-bad Atomic Red Team test to confirm the log pipeline reaches OpenSearch before you trust a rule test result.

## FAQ

### What is PurpleLab and who is it for?

It is a cybersecurity lab for creating and testing detection rules, simulating attacks and training analysts, with a user-friendly web interface. It is aimed at detection engineers and security teams who need a repeatable place to exercise rules against real telemetry.

### What is in the automatically configured Windows VM?

Windows Server 2019 with an oem and oem administrator account, Sysmon with the SwiftOnSecurity configuration, Winlogbeat OSS 7.12.1 sending logs to OpenSearch, Atomic Red Team for attack simulation, a Python environment with Chocolatey, the PowerShell-YAML module, pre-configured samples and upload directories, and Windows Defender exclusions for the test scenarios.

### How do you start the PurpleLab web application?

It is a Flask server started with sudo /opt/purplelab-venv/bin/python /home/$(logname)/app.py, using a dedicated virtual environment under /opt and the application in a user's home directory.

### What does the PurpleLab home page show?

Key performance indicators from OpenSearch: the event count from the Windows Server VM, the unique IP addresses detected in the logs, the count of MITRE ATT&CK techniques and sub-techniques, and the log distribution from the VM collection. The hunting page then gives direct access to OpenSearch Dashboards and the Discover view for the raw events.

### What licence is PurpleLab released under?

AGPL-3.0, with the repository on the main branch and the most recent release being PurpleLab V3.0.0 in June 2025, followed by pushes to the repository through August 2026.

## Sources

- [Issues](https://github.com/Krook9d/PurpleLab/issues)
- [Krook9d/PurpleLab on GitHub](https://github.com/Krook9d/PurpleLab)
- [License: AGPL-3.0](https://github.com/Krook9d/PurpleLab/blob/main/LICENSE)
- [README](https://github.com/Krook9d/PurpleLab/blob/main/README.md)
- [Releases](https://github.com/Krook9d/PurpleLab/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/krook9d-purplelab