RMFInsider

Every entry-level applicant has a certificate. Almost none of them have a SOC analyst home lab Wazuh build they can actually walk an interviewer through. That gap is exactly why this project matters: it converts “I studied Security+” into “I deployed a SIEM, attacked my own environment, and found the alerts” — a five-minute answer that beats a resume full of logos with nothing behind them.

This is Portfolio Project #1 from our full Zero to Hired roadmap, and it’s the project people ask about most, so here’s the whole build as a standalone walkthrough. If you haven’t read the plan this sits inside, start with the 6-month cybersecurity career plan and the Security+ SY0-701 study plan that precedes this build — this lab is designed to happen right after you pass the exam, while the momentum is still there.

Why a SOC analyst home lab with Wazuh beats another certificate on your resume

Wazuh is a free, open-source security monitoring platform — GPLv2 for the core engine, Apache 2.0 for the OpenSearch-based indexer and dashboard components. No license paywall on the self-hosted version, which means the only cost to build this lab is your time. That matters because it removes the last excuse: you don’t need a budget to build this, just a weekend and a laptop that meets the minimum specs below.

A hiring manager can’t verify what you memorized for an exam. They can absolutely verify a GitHub write-up with screenshots of real alerts firing against attacks you ran yourself. That’s the entire value proposition of this project: it’s evidence, not a claim.

It’s also a direct rehearsal for the job itself. Tier 1 SOC work is largely: watch a dashboard, recognize a pattern, follow a playbook, escalate what doesn’t fit. Building this lab means you’ve already done a small version of that loop before anyone pays you to do it — you generated the traffic, you watched it hit the dashboard, and you had to figure out why the rule fired. That’s the job, at a smaller scale.

Hardware and VM requirements

Wazuh’s current stable release is 4.14.5 (April 2026), running on the 4.x version line, with a 5.0 beta in progress — stick with the stable 4.x release for a lab build. It installs on Ubuntu, Debian, RHEL, AlmaLinux, Rocky, Amazon Linux, or openSUSE using the official all-in-one quickstart installer, which puts the manager, indexer, and dashboard on a single host — the standard deployment model for a lab.

Resource	Minimum for a lab	Notes
CPU	2 vCPU	Fine for a handful of agents
RAM	4 GB minimum	Scale to 8 GB once you’re past a handful of agents — the indexer is memory-hungry
Storage	50 GB	SSD strongly recommended for dashboard responsiveness

If you’re assembling a dedicated lab machine rather than running this in VirtualBox on your daily driver, our budget home lab buying guide walks through what’s actually worth buying under $500 versus what you can skip.

On the agent side, Wazuh officially supports Windows across all modern versions, the major Linux distributions, macOS, and Docker containers — with verified support for Windows 11 and current Ubuntu, Debian, and RHEL releases. That breadth matters for this build because it means the two-endpoint setup below (one Windows, one Linux) mirrors what a real mixed-OS corporate environment looks like, not a toy scenario built around whatever happens to be easiest to install.

Install the Wazuh manager

Spin up your manager host first — Ubuntu is the most documented option and the easiest to troubleshoot when something doesn’t come up cleanly. Run the official all-in-one installer script, which handles the manager, the indexer, and the dashboard in one pass rather than requiring you to stand up each component by hand. Once it completes, confirm you can log into the Wazuh dashboard over HTTPS and see an empty “Agents” list — that empty list is your baseline, and everything from here is filling it in.

Snapshot this VM immediately once it’s stable. You will break things intentionally later in this build, and a clean snapshot means a bad configuration costs you five minutes to roll back instead of a reinstall.

Give the manager host time to settle before moving on — the indexer component in particular takes a minute or two to fully initialize after the installer finishes, and logging in too early can make it look like the install failed when it’s actually still starting services. If the dashboard doesn’t load on the first attempt, wait, then retry before you start troubleshooting.

Enroll your first agents (Windows + Ubuntu)

Wazuh agents support Windows (all modern versions, including 11), major Linux distributions, macOS, and Docker containers. For this build, enroll two agents:

• An Ubuntu Server VM — stand it up as a second host on the same network as your manager, install the Wazuh agent package, and point it at your manager’s address during enrollment.
• A Windows VM — a free evaluation build from the Microsoft Evaluation Center works fine. Install the Wazuh Windows agent the same way, confirm it registers, and check that Windows Event Log data is flowing into the dashboard.

Confirm both agents show as “Active” in the dashboard before moving on. An agent that shows “Never connected” almost always means a network or firewall issue between the agent and the manager, not a Wazuh configuration problem — check that first: confirm both VMs are on the same network segment, that the manager’s IP is reachable from the agent, and that nothing on either host is blocking the enrollment and communication ports before you start second-guessing the agent install itself.

Generate attack telemetry and build 3 detections

A monitoring platform with nothing to monitor doesn’t prove anything. Add a third VM — a Kali Linux attacker box — and generate real telemetry against your two endpoints, entirely inside your isolated lab network:

• Detection 1 — reconnaissance: run an nmap scan from Kali against both endpoints. Confirm the scan shows up in Wazuh as a detected event, and understand which rule fired and why.
• Detection 2 — brute force: attempt an SSH brute-force attack against a test account on your Ubuntu VM using Hydra. Watch the authentication-failure alerts accumulate and trigger a Wazuh brute-force detection rule.
• Detection 3 — credential access: run a credential-access test against the Windows VM, staying strictly inside your isolated lab. Find the corresponding alert and trace it back to the specific behavior that triggered it.

Screenshot every alert as you generate it. For each one, write one sentence explaining why the rule fired — that sentence is the difference between “I saw an alert” and “I understand detection logic,” and it’s the sentence an interviewer is actually listening for.

Run each attack more than once, changing one variable each time. Scan with different nmap flags and compare what shows up in the dashboard. Try the brute-force attempt against a locked-down account versus one with a weak password policy. Small variations like this teach you far more about how the underlying detection rules actually work than running the same attack once and moving on — and they give you more material for the write-up.

Turn the lab into a portfolio write-up

The build isn’t the deliverable — the write-up is. Publish it on GitHub with four sections: an architecture diagram (even a simple one showing your three VMs and the manager), your setup steps, each attack paired with its detection screenshot, and a short “what I’d tune next” section showing you understand this isn’t a finished product.

That last section matters more than it looks. Anyone can follow a tutorial. Showing you know what you’d improve — tuning a noisy rule, adding a fourth detection, extending retention — is what separates a checklist exercise from genuine understanding, and it’s usually the detail that gets a follow-up question in an interview instead of a polite nod.

Post the write-up to LinkedIn the same week you finish it. “Tell me about a time you worked with a SIEM” is one of the most common questions in a SOC analyst interview, and after this project you have a real, specific, 90-second answer instead of a description of what you read about in a course.

Keep the lab running after you finish the write-up rather than tearing it down. A live environment gives you a place to test new ideas — a fourth detection rule, a different attack technique, an integration you read about — without starting from zero each time. The lab that’s still running six months later, with new entries added to its GitHub journal, tells a much stronger story in an interview than a one-time project you built and then deleted.

None of this requires a paid Wazuh Cloud subscription or professional support contract — those exist for organizations that want a managed deployment, but the self-hosted, fully open-source path covers everything in this build with zero licensing cost.

This lab is one of five portfolio projects in the full six-month plan — vulnerability management, phishing analysis, Active Directory, and a scripting project follow it. The complete build order, plus the study plan and job-search machine that come after it, is in Zero to Hired, our $29 roadmap for going from zero experience to a signed offer.