You do not learn detection engineering by reading about it. You learn it by generating a real attack, watching whether your sensors caught it, and fixing the gap when they didn't. That loop needs a lab — and the good news is a capable one costs nothing if you already own a laptop with 16 GB of RAM, or roughly $300–$500 for a dedicated mini-PC that runs 24/7.
This guide builds a full blue-team lab from scratch: Wazuh 4.14.x as the SIEM/XDR core, Suricata as the network IDS, a Sysmon-instrumented Windows endpoint, and a Kali attacker running Atomic Red Team to safely fire MITRE ATT&CK techniques at it. You get three deployment paths — VirtualBox on an existing PC, a Docker single-node stack, and a Proxmox mini-PC build — with every command laid out to copy and paste.
By the end you will have log collection, network IDS, endpoint telemetry, working detections and a repeatable attack-and-detect workflow. This is a lab, not a production SOC: keep it isolated from your home network and never point internet-facing services at it.
◈ Table of Contents
01 · What a Home SOC Lab Is — and Why Build One
Phase 1 / 11A Security Operations Center lab is a self-contained set of virtual machines that reproduces the three things a real SOC runs on: telemetry (endpoint and network logs), a SIEM to centralise and correlate that telemetry, and a target and threat so you have something to detect. The point is not to defend real assets — it is to practise the analyst loop: an alert fires, you pivot through the evidence, you decide true-positive or false-positive, and you write or tune a rule so the next occurrence is caught faster.
Commercial SIEM licences run into five figures a year, which is exactly why open-source Wazuh anchors this build. It ships file-integrity monitoring, vulnerability detection, log analysis, MITRE ATT&CK mapping and pre-written rulesets that parse Sysmon and Suricata out of the box — for the price of the hardware it runs on.
SOC Analyst Trainees
Practise triage on real alerts — process-injection, brute force, suspicious PowerShell — before you ever touch a production console.
Detection Engineers
Write a rule, fire the matching Atomic Red Team test, confirm it triggers, then tune out false positives. The whole detection lifecycle in one box.
Blue Teamers
Rehearse incident response — isolate a host, pull the timeline, verify eradication — on disposable VMs you can revert with a snapshot.
Students & Certs
Hands-on evidence for CompTIA Security+, BTL1 and SC-200 study — a lab you can screenshot for a portfolio recruiters actually respect.
Treat every VM as disposable. Take a clean snapshot of each machine the moment it is configured and working. When an attack simulation trashes a host — and it will — you revert in seconds instead of rebuilding for an hour.
02 · Lab Architecture & Budget Tiers
Phase 2 / 11The whole lab is four VMs on one isolated virtual network. The SIEM does the heavy lifting, so it gets most of the RAM; the endpoints and attacker are deliberately lightweight. Below is the architecture, followed by three budget tiers so you can build with whatever you have.
Allocate resources to match each VM's job. Wazuh's indexer is Java/OpenSearch-based and memory-hungry; everything else is modest. These are working figures for a single-analyst lab.
| VM | Role | vCPU | RAM | Disk | IP |
|---|---|---|---|---|---|
| Wazuh | SIEM: indexer + manager + dashboard | 2–4 | 4–8 GB rec | 50 GB | 10.10.10.20 |
| Win11 | Victim endpoint, Sysmon telemetry | 2 | 4 GB | 40 GB | 10.10.10.30 |
| Ubuntu | Suricata network IDS + Linux agent | 1–2 | 2 GB | 25 GB | 10.10.10.40 |
| Kali | Attacker / red-team tooling | 2 | 2–4 GB | 30 GB | 10.10.10.50 |
Wazuh's indexer will refuse to start with less than ~2 GB free. 4 GB is a hard floor for the SIEM VM; 6–8 GB makes the dashboard usable. If your host has only 16 GB total, run the endpoints one at a time rather than all four at once.
Pick the tier that matches your wallet. The zero-dollar path is real — it runs on the laptop you already own — it just can't run 24/7.
| Tier | Cost | Hardware | Trade-off |
|---|---|---|---|
| Zero | $0 | Existing PC/laptop, 16 GB RAM, VirtualBox | No 24/7 uptime; close other apps while labbing |
| Budget | $200–350 | Used mini-PC / SFF (e.g. i5, 16–32 GB, 512 GB SSD) | Runs headless 24/7; buy a second-hand enterprise SFF |
| Comfort | $400–500 | New/refurb mini-PC, 32 GB RAM, NVMe, Proxmox | Room to add pfSense, a domain controller, more agents |
Second-hand enterprise small-form-factor PCs (Dell OptiPlex Micro, Lenovo ThinkCentre Tiny, HP EliteDesk Mini) are the sweet spot: 32 GB of DDR4 and an NVMe slot for well under $300, and they idle near-silent under 15 W.
Everything below is free and open source or free-to-use. Pin the exact versions in a notes file so a rebuild is deterministic.
| Software | Version (Sep 2026) | Purpose |
|---|---|---|
| Wazuh | 4.14.x (4.14.7 stable) | SIEM/XDR: agents, rules, dashboard |
| Ubuntu Server | 24.04 LTS | Host OS for Wazuh & Suricata VMs |
| Suricata | 7.x | Network IDS/IPS & EVE JSON logs |
| Sysmon | v15.x + SwiftOnSecurity / Sysmon Modular config | Rich Windows endpoint telemetry |
| Kali Linux | 2026.x | Attacker toolkit |
| Atomic Red Team | current | Safe, atomic MITRE ATT&CK tests |
| VirtualBox / Proxmox VE | 7.1 / 9.x | Hypervisor |
03 · Method 1 — VirtualBox on Your Existing PC
Phase 3 / 11This is the zero-dollar path and the one most people should start with. VirtualBox is free, cross-platform, and its Host-Only network is perfect for keeping the lab off your real LAN. We create an isolated network, spin up the Ubuntu VM that will host Wazuh, then install Wazuh's all-in-one package on it.
Install VirtualBox and its Extension Pack, then define a Host-Only network. Every lab VM attaches to this network and to nothing else — no bridging to your home router.
Do NOT enable the VirtualBox Host-Only DHCP server if you want fixed IPs — assign static addresses inside each guest instead. Mixed DHCP + static is the #1 cause of "my agent can't find the manager" in home labs.
Download the Ubuntu Server 24.04 ISO, create a VM with 2 vCPU / 6 GB RAM / 50 GB disk, and attach the host-only adapter. You can do it in the GUI, or scripted with VBoxManage below.
Complete the Ubuntu installer, then give the VM a static address. On 24.04 that means a netplan file:
Wazuh's assisted installer deploys the indexer, manager and dashboard on a single node in one command. This is the fastest way to a working SIEM.
When it finishes it prints the admin password. Capture it — you need it for the dashboard and for the password tool later.
- Browsing https://10.10.10.20 shows the Wazuh login (self-signed cert warning is expected)
- You can log in as admin with the generated password
sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboardshows all three active
Snapshot the Wazuh VM right now, labelled "clean-siem". If a later change breaks the stack, revert to this instead of re-running the installer.
04 · Method 2 — Wazuh via Docker (Single-Node)
Phase 4 / 11If your SIEM host already runs Docker, the single-node stack is cleaner than the bare-metal installer: three containers (indexer, manager, dashboard) defined in one Compose file, easy to tear down and rebuild. This is my preferred path on a dedicated mini-PC.
Install Docker Engine and the Compose plugin, then apply the same kernel setting the indexer requires. Without vm.max_map_count the indexer container crash-loops immediately.
Wazuh publishes an official wazuh-docker repository. Check out the tag that matches your version, then run the one-shot certificate generator before starting the stack.
Change the default admin and kibanaserver passwords in docker-compose.yml and the internal users file before exposing the dashboard to anything. The stock credentials are public knowledge.
The repo ships a complete Compose file; the annotated version below shows the shape of the single-node stack so you understand what each service does. Adjust the RAM limits and passwords, then bring it up.
docker compose psshows manager, indexer and dashboard as running- https://SIEM-IP:443 serves the Wazuh dashboard login
curl -k -u admin:PASS https://localhost:9200returns indexer cluster JSON
05 · Method 3 — Proxmox VE on a Dedicated Mini-PC
Phase 5 / 11For an always-on lab, a Type-1 hypervisor on dedicated hardware beats VirtualBox on your daily driver. Proxmox VE is free, manages all your lab VMs from one web UI, and its snapshot/clone workflow is ideal for rebuilding attack targets. Use this method if you bought the Budget or Comfort tier hardware.
Flash the Proxmox VE 9 ISO to a USB stick, install it on the mini-PC, then switch to the free no-subscription repository so apt updates work without a licence.
Add a second, internal-only Linux bridge (vmbr1) with no physical NIC attached. Every lab VM lives on this bridge, isolated from your home LAN, while Proxmox itself stays reachable on vmbr0.
Leave the lab bridge with no gateway to the internet. When a VM genuinely needs updates, temporarily attach a second NIC on vmbr0, patch, then detach it. An air-gapped attack lab can't accidentally scan the neighbourhood.
Proxmox's qm CLI scripts VM creation. Upload the Ubuntu ISO to local storage first, then create and start the SIEM VM on the lab bridge.
From here the OS install, static IP and Wazuh deployment are identical to Method 1 (§3.2–3.3) or Method 2 (Docker). Clone this VM template to spin up the Windows, Ubuntu-IDS and Kali guests faster.
06 · Initial Wazuh Configuration
Phase 6 / 11With the SIEM running by whichever method, harden the defaults and confirm the manager is ready to accept agents. Never leave a lab with stock passwords — you will eventually expose it by accident.
Wazuh ships a password-change tool that updates the indexer, dashboard and API users consistently. Run it before anything else.
Check the manager service and query the REST API. A healthy API response means agents will be able to enrol.
Where to look in the dashboard
07 · Core Configuration — Endpoints & IDS
Phase 7 / 11A SIEM with no data is a login page. This phase wires up the telemetry that makes the lab worth having: the Wazuh agent plus Sysmon on Windows, a Linux agent on the Ubuntu box, and Suricata generating network alerts.
Install the Wazuh agent MSI on the Windows 11 VM, pointing it at the manager. The dashboard's "Deploy new agent" wizard generates this exact command with a group and enrollment key.
Within a minute the agent appears in Endpoints Summary as Active.
Sysmon is what turns bland Windows logs into attacker-grade telemetry: process creation with command lines and hashes, network connections, DNS queries and image loads. Use a community config — SwiftOnSecurity for a clean baseline, or Olaf Hartong's Sysmon Modular for ATT&CK-tagged events.
Now tell the Wazuh agent to forward the Sysmon channel. Edit C:\Program Files (x86)\ossec-agent\ossec.conf and add a localfile block:
Sysmon's default (no config) logs almost nothing useful and floods you with noise on the wrong things. Never run it bare — always deploy a curated config and review it against your detection goals.
The Ubuntu VM plays two roles: a monitored Linux endpoint and the network IDS. Install the Wazuh agent, then Suricata, then update its rules.
Point Suricata at the lab interface and enable EVE JSON output, which Wazuh reads natively.
08 · Integration & Network Design
Phase 8 / 11Now connect the pieces so telemetry lands in one place and the attacker can safely reach the victims. This is where the collection of VMs becomes an actual SOC.
Add a localfile block to the Ubuntu agent's ossec.conf so the manager ingests Suricata's EVE log. Wazuh's built-in Suricata decoder parses it automatically.
Verify the pipeline end-to-end before moving on: curl http://testmynids.org/uid/index.html from a victim triggers the ET rule "GPL ATTACK_RESPONSE id check returned root", which should surface in Wazuh within seconds. If it doesn't, the break is between Suricata and the agent — check EVE output is enabled.
Keep the lab off your production LAN. On the zero-dollar VirtualBox build, host-only already isolates it. For a mini-PC build, add pfSense or OPNsense as a router VM if you want inter-VLAN rules and a place to practise firewall log analysis.
| Segment | Subnet | Hosts | Rule |
|---|---|---|---|
| SIEM | 10.10.10.20 | Wazuh | Accept agent traffic (1514/1515/55000) |
| Victims | 10.10.10.30–40 | Win11, Ubuntu | Reachable from attacker; egress denied |
| Attacker | 10.10.10.50 | Kali | Reach victims; no internet during attacks |
Never bridge the attacker VM to your real network. Atomic Red Team runs genuine offensive techniques; a misconfigured bridge means you are scanning and potentially exploiting hosts you don't own. Host-only or an internal bridge, always.
Import the official Kali VirtualBox/VMware image or install from ISO, attach it to the lab network only, and confirm it can reach the victims.
That nmap scan is your first real detection test. Move to the dashboard and look for the connection spike; if Suricata has scan rules enabled you'll see a port-scan alert too.
09 · Advanced — Attack, Detect & Tune
Phase 9 / 11This is the phase you actually built the lab for. Fire a known ATT&CK technique with Atomic Red Team, confirm the detection, and when it's missing, write the rule that catches it. Repeat forever — that repetition is detection engineering.
Atomic Red Team is a library of small, precise tests mapped to MITRE ATT&CK. Install the PowerShell module on the Windows victim (not the attacker — the tests run locally to generate the telemetry you want to detect).
Run Atomic Red Team only on a snapshot you can revert, and disable/exclude Defender for the test window if it quarantines the atomics before Sysmon logs them. Revert the snapshot when finished — some tests deliberately leave persistence behind.
Start with T1059.001 (PowerShell) and T1003.001 (LSASS memory access) — both produce clear Sysmon telemetry and map to rules Wazuh already ships.
| ATT&CK ID | Technique | Sysmon Event | Expect in Wazuh |
|---|---|---|---|
| T1059.001 | PowerShell execution | Event 1 (process create) | Rule 92052 / PowerShell alerts |
| T1003.001 | LSASS memory dump | Event 10 (process access) | Credential-access alert |
| T1053.005 | Scheduled task | Event 1 + 4698 | Persistence alert |
| T1547.001 | Registry Run key | Event 13 (reg set) | Autostart alert |
Once events land, practise pivoting. In the Wazuh dashboard's Discover view you filter with a simple query; if you also run Splunk in your lab, the equivalent SPL is below. Every hunt starts with a hypothesis you can express as a query.
When a technique fires with no alert, that's a detection gap — the whole reason to have a lab. Add a custom rule to local_rules.xml on the manager, restart, and re-run the atomic to confirm it triggers.
Test rule syntax offline before restarting the whole manager: echo 'sample log line' | sudo /var/ossec/bin/wazuh-logtest shows exactly which rule and decoder match, so you tune in seconds instead of restart cycles.