Post cover image

June 12, 2026

I Built a SOC Home Lab Using Wazuh SIEM — Here’s Everything I Learned

From zero to detecting real attacks in a VirtualBox lab — custom rules, MITRE ATT&CK mapping, and 496 alerts generated

Pa1cosmic

4 min read

If you're trying to break into cybersecurity as a SOC Analyst, you've probably heard the advice a hundred times: build a home lab. But most guides stop at "install Kali and run Nmap." I wanted something closer to what an actual SOC environment looks like — a real SIEM, real agents, real alerts, and real detection engineering.

So I built one. Here's the full breakdown.

What I Built

A four-VM VirtualBox lab running Wazuh SIEM v4.12.0 as the core platform:

Machine Role IP Ubuntu Server 26.04 LTS Wazuh Manager + Dashboard + Indexer 192.168.56.10 Kali Linux 2026.2 Attacker / Wazuh Agent 192.168.56.20 Metasploitable 2 Vulnerable Target 192.168.56.30 Windows 10 Additional Endpoint —

The network is split into two adapters per VM: NAT for internet access (downloads, updates) and an Internal Network named SOC-LAB for isolated SOC communications. This mirrors real network segmentation.

Why Wazuh?

Wazuh is open-source, free, and covers almost everything a SOC analyst actually uses day-to-day:

  • Log collection and normalization
  • Threat detection and alerting
  • File Integrity Monitoring (FIM)
  • Vulnerability detection
  • Threat hunting
  • Compliance mapping (PCI-DSS, HIPAA, GDPR, TSC)
  • MITRE ATT&CK integration

It runs on a standard Linux server and exposes a full web dashboard. For a home lab, it's the most realistic SIEM option available without spending money.

Setting Up the Server

I installed Ubuntu Server 26.04 LTS (Linux 7.0 kernel, 5-year LTS) on a VirtualBox VM with 6GB RAM and a 50GB virtual disk. Then I used the Wazuh All-in-One installer:

curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh
chmod +x wazuh-install.sh
sudo ./wazuh-install.sh -a

This automatically deploys all three components — Manager, Dashboard, and Indexer. It takes 20–30 minutes.

Challenges I Hit (and Fixed)

RAM issue: The installer threw a warning about insufficient resources. My VM was at 4GB. Bumped it to 6GB — installation ran fine.

Indexer went read-only: After some time the Wazuh Indexer hit a "flood-stage watermark exceeded" error and entered read-only mode. Ran df -h and realized Ubuntu was only using 24GB of a 50GB disk due to LVM not being auto-expanded. Fixed it:

sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

Dashboard not accessible from host: My lab had no Host-Only adapter so I couldn't reach the dashboard from my Windows host. Solution: open the dashboard from inside the Kali VM browser at https://192.168.56.10. Works perfectly.

Enrolling the Kali Agent

From the Wazuh dashboard I used the Deploy New Agent wizard — it auto-generates the exact install command with your manager IP and agent name baked in:

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.12.0-1_amd64.deb \
  && sudo WAZUH_MANAGER='192.168.56.10' \
     WAZUH_AGENT_NAME='kali-attacker' \
     dpkg -i ./wazuh-agent_4.12.0-1_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Within a minute, kali-attacker appeared in the Endpoints panel as Active — Agent ID 001, Kali GNU/Linux 2026.2, Wazuh v4.12.0.

Detection Engineering — Writing Custom Rules

This was the part I was most excited about. Wazuh ships with 4,491 built-in rules. You extend them at /var/ossec/etc/rules/local_rules.xml.

I wrote two custom rules:

Rule 100001 — SSH Auth Failure from Specific IP

<rule id="100001" level="5">
  <if_sid>5716</if_sid>
  <srcip>1.1.1.1</srcip>
  <description>sshd: authentication failed from IP 1.1.1.1</description>
  <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
</rule>

Rule 100500 — Nmap Reconnaissance Detection

<rule id="100500" level="5">
  <match>nmap</match>
  <description>Nmap reconnaissance Detected</description>
  <group>recon,custom,</group>
</rule>

After writing the rules:

sudo /var/ossec/bin/wazuh-analysisd -t   # validate syntax
sudo systemctl restart wazuh-manager      # apply

I then ran an Nmap scan from Kali against the server and immediately saw 2 hits for rule.id:100500 in the Wazuh Discover view. The rule was working.

Why this matters for job hunting:_ Detection engineering — writing rules that catch real attacker behavior — is one of the most valued skills in SOC roles. Being able to show you've written and validated custom rules is a strong portfolio differentiator._

Simulating Attacks

I ran a series of attack simulations from Kali Linux to generate meaningful alerts:

File Integrity Monitoring (FIM)

# Create, modify, change permissions, delete — all watched by Wazuh FIM
echo "hacked" | sudo tee -a /etc/wazuh-test.txt
sudo touch /etc/resume-test.txt
echo "modified by pavan" | sudo tee -a /etc/resume-test.txt
sudo chmod 777 /etc/resume-test.txt
sudo rm /etc/resume-test.txt

Every one of these actions simulates something a real attacker does post-compromise: dropping backdoor files, modifying configs, making files world-writable.

Privilege Escalation

sudo whoami
sudo su

These triggered Rule 5402 — Successful sudo to ROOT executed with full compliance tagging: HIPAA 164.312.b, PCI-DSS 10.2.5, TSC CC6.8/CC7.2/CC7.3.

SSH Brute Force

hydra -l root -P passwords.txt ssh://192.168.56.10

What Wazuh Detected

After running all simulations, here's the alert summary:

Rule ID Description Level MITRE Technique 5402 Successful sudo to ROOT executed 3 T1548.003 5501 PAM: Login session opened 3 T1078 5502 PAM: Login session closed 3 T1078 100500 Nmap reconnaissance Detected (custom) 5 T1046

Total alerts: 496 Level 12+ alerts: 1 Authentication successes monitored: 48

MITRE ATT&CK Coverage

The Threat Hunting dashboard mapped detected activity to four ATT&CK techniques:

  • T1078 — Valid Accounts (dominant)
  • T1548.003 — Sudo and Sudo Caching
  • T1136 — Create Account
  • T1562 — Disable or Modify Tools

This is the same kind of mapping a real SOC analyst uses during threat investigation.

Threat Hunting Workflow

The Wazuh Discover interface lets you filter, pivot, and drill into raw events. I used it to:

  1. Filter by agent.name: kali-attacker
  2. Search by rule.id:5402 to isolate privilege escalation events
  3. Expand individual alerts to see full field context — agent IP, dstuser, firedtimes, rule level, compliance tags
  4. Cross-reference timing of events to reconstruct the attacker's session timeline

This is exactly what L1 SOC analysts do during alert triage.

Skills This Project Built

Skill How SIEM Deployment Installed and configured Wazuh All-in-One Detection Engineering Wrote custom XML rules, validated and deployed Threat Hunting Investigated 496 alerts in Wazuh Discover Log Analysis Analyzed PAM, sudo, syslog, sshd events Linux Administration LVM expansion, service management, networking MITRE ATT&CK Mapped real detections to ATT&CK techniques Compliance Reviewed PCI-DSS, HIPAA, GDPR rule mappings Agent Management Enrolled and verified Wazuh agents

What's Next

The lab is running but there's more to build:

  • Vulnerability Detection — enable CVE feeds and scan for outdated packages
  • Active Response — auto-block brute force IPs via firewall rules
  • Suricata Integration — add network IDS for deeper traffic analysis
  • Metasploitable Agent — deploy Wazuh agent and simulate FTP/web attacks
  • Custom Dashboards — build views for FIM, auth events, recon activity
  • SOAR — connect Wazuh to TheHive or Shuffle for automated playbooks

Final Thoughts

Building this lab taught me more in a few weeks than months of theory. You go from reading about PAM events to actually watching them roll in live. You write a rule in XML, validate it, restart the manager, run an Nmap scan, and see your own detection fire. That feedback loop is what makes things stick.

If you're targeting SOC Analyst roles, this is the kind of project that separates your resume from someone who only did TryHackMe rooms. It shows you can set up infrastructure, troubleshoot real problems, and engineer detections — not just run tools someone else built.

The full project report and rules are on my GitHub: github.com/Pavan-glitch22

Tags: cybersecurity soc wazuh siem blue-team detection-engineering homelab mitre-attack linux infosec