Wazuh Homelab SOC — Sagar Bidari

Infrastructure

Lab Architecture

The homelab runs entirely within VMware Workstation on a local machine. Three virtual machines form the core environment: a Wazuh Manager node (Ubuntu Server 22.04 LTS), an Ubuntu Desktop endpoint acting as a monitored workstation, and a Kali Linux attack VM used to simulate adversary behaviour. All VMs share a private host-only network (192.168.100.0/24) to isolate lab traffic from the production network.

┌────────────────────────────────────────────────────────────┐
│                  VMware Host-Only Network                  │
│                    192.168.100.0/24                        │
│                                                            │
│  ┌─────────────────────┐    ┌──────────────────────────┐  │
│  │  Wazuh Manager       │    │  Ubuntu Endpoint          │  │
│  │  Ubuntu 22.04 LTS    │◄──►│  (Wazuh Agent installed) │  │
│  │  192.168.100.10      │    │  192.168.100.20           │  │
│  │                      │    └──────────────────────────┘  │
│  │  ├─ Wazuh Manager    │                                  │
│  │  ├─ Wazuh Indexer    │    ┌──────────────────────────┐  │
│  │  │  (OpenSearch)     │◄──►│  Kali Linux Attack VM     │  │
│  │  └─ Wazuh Dashboard  │    │  (Wazuh Agent + tools)   │  │
│  │     (port 443)       │    │  192.168.100.30           │  │
│  └─────────────────────┘    └──────────────────────────┘  │
│                                                            │
│  Agent communication: TCP 1514 / 1515                      │
│  Dashboard UI:        HTTPS 443                            │
│  Syslog forwarder:    UDP 514                              │
└────────────────────────────────────────────────────────────┘

Wazuh agents on both the Ubuntu and Kali endpoints ship logs (syslog, auth.log, audit events) to the Manager in real time. The Wazuh Indexer stores events in OpenSearch and the Dashboard provides alert visualisation, rule management, and MITRE ATT&CK heatmaps.

Deployment

Setup & Configuration Steps

1
Provision VMs in VMware Workstation
Created three VMs (Ubuntu Server 22.04 for Manager, Ubuntu Desktop 22.04 for endpoint, Kali Linux 2024 for attacker). Configured all on a shared host-only adapter and assigned static IPs.
2
Install Wazuh Manager (All-in-One)
Used the official Wazuh 4.x all-in-one install script on the Ubuntu Server VM. Script installs Manager, Indexer (OpenSearch), and Dashboard as a single-node deployment.
3
Deploy Wazuh Agents on Endpoints
Installed the Wazuh agent package on both the Ubuntu Desktop and Kali Linux VMs. Configured /var/ossec/etc/ossec.conf on each agent to point to the Manager IP, then registered agents via agent-auth.
4
Configure Audit & Log Sources
Enabled Linux Audit Daemon (auditd) on both endpoints. Added audit rules for privilege escalation events, file writes to /etc/, and execution of suspicious binaries. Configured Wazuh to read /var/log/auth.log, /var/log/syslog, and auditd events.
5
Write Custom Detection Rules
Created a custom XML rule file at /var/ossec/etc/rules/local_rules.xml with rules targeting SSH brute-force thresholds, port scan patterns, and privilege escalation signatures.
6
Enable OpenSearch Dashboards
Logged into the Wazuh Dashboard at https://192.168.100.10, confirmed agent connectivity, and built custom dashboards for SSH authentication events, alert severity timelines, and MITRE ATT&CK heatmaps.
7
Run Simulated Attack Scenarios
Used Kali Linux tools (Hydra, Nmap, Metasploit auxiliary modules) to generate realistic attack traffic against the Ubuntu endpoint and verified each scenario triggered the expected Wazuh alerts.

# Install Wazuh Manager — all-in-one script (run as root on Ubuntu Server)
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
bash wazuh-install.sh -a

[INFO] Starting Wazuh installation assistant...
[INFO] Installing Wazuh Indexer (OpenSearch)...
[INFO] Installing Wazuh Manager...
[INFO] Installing Wazuh Dashboard...
[OK]   Installation completed. Access the dashboard at https://<MANAGER_IP>

# Start/stop/status — Wazuh Manager control
/var/ossec/bin/wazuh-control start
/var/ossec/bin/wazuh-control status

wazuh-execd    is running... (PID 1234)
wazuh-analysisd is running... (PID 1235)
wazuh-syscheckd  is running... (PID 1236)
wazuh-monitord   is running... (PID 1237)
wazuh-logcollector is running... (PID 1238)
wazuh-remoted    is running... (PID 1239)
wazuh-db         is running... (PID 1240)

# Register an agent (run on the endpoint VM)
sudo /var/ossec/bin/agent-auth -m 192.168.100.10 -A ubuntu-endpoint
INFO: Agent registered successfully. Agent ID: 001

# Tail live alerts on the Manager
sudo tail -f /var/ossec/logs/alerts/alerts.json | python3 -m json.tool

Rule Engineering

Custom Detection Rules

The default Wazuh ruleset covers many common scenarios, but practising custom rule authorship is a key SOC skill. These XML rules were written in the lab to refine alert thresholds and add detection logic for specific attack simulations.

SSH BRUTE-FORCE DETECTION — /var/ossec/etc/rules/local_rules.xml

<!-- Custom rule: SSH brute-force threshold -->
<group name="local,sshd,">

  <!-- Rule 100001: detect repeated SSH auth failures from same source -->
  <rule id="100001" level="10" frequency="8" timeframe="60">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip/>
    <description>SSH brute-force attempt: 8+ failures in 60s from same IP</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>authentication_failures,brute_force,</group>
  </rule>

  <!-- Rule 100002: SSH login after prior brute-force — possible success -->
  <rule id="100002" level="12">
    <if_matched_sid>100001</if_matched_sid>
    <if_sid>5715</if_sid>
    <same_source_ip/>
    <timeframe>300</timeframe>
    <description>Possible brute-force success: SSH login after repeated failures</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

</group>

<!-- Rule 100010: suspicious process execution via shell -->
<group name="local,linux,process,">
  <rule id="100010" level="9">
    <if_sid>80792</if_sid>
    <field name="audit.execve.a0">bash|sh|python3|perl|nc|ncat</field>
    <field name="audit.euid">0</field>
    <description>Privileged shell/interpreter spawned via auditd</description>
    <mitre>
      <id>T1059.004</id>
    </mitre>
  </rule>
</group>

Attack Simulation

Simulated Attacks from Kali Linux

The following commands were run from the Kali Linux VM against the Ubuntu endpoint to trigger detection rules and generate alerts in the Wazuh dashboard. All activity was confined to the isolated lab network.

# ─── SSH Brute-Force (T1110) — using Hydra ───────────────────────────────
kali@kali:~$ hydra -l ubuntu -P /usr/share/wordlists/rockyou.txt \
               ssh://192.168.100.20 -t 4 -V

[DATA] attacking ssh://192.168.100.20:22/
[ATTEMPT] target 192.168.100.20 - login "ubuntu" - pass "123456"
[ATTEMPT] target 192.168.100.20 - login "ubuntu" - pass "password"
[22][ssh] host: 192.168.100.20   login: ubuntu   password: lab_pass_01
1 of 1 target successfully completed

# ─── Port Scan (T1046) — Nmap SYN scan ───────────────────────────────────
kali@kali:~$ sudo nmap -sS -p 1-1024 192.168.100.20 -oN scan_results.txt

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 192.168.100.20
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
Nmap done: 1 IP address scanned

# ─── Privilege Escalation attempt via sudo exploit (T1068) ───────────────
ubuntu@endpoint:~$ sudo -l
User ubuntu may run: (ALL) NOPASSWD: /usr/bin/vim
ubuntu@endpoint:~$ sudo vim -c ':!/bin/bash'
# Root shell obtained — auditd captures execve syscall — Wazuh rule 100010 fires

# ─── Verify alerts generated on Manager ──────────────────────────────────
root@wazuh-manager:~$ grep -i "brute.force\|port.scan\|100001\|100010" \
                         /var/ossec/logs/alerts/alerts.log | tail -20
** Alert 1701234567.12345: - local,sshd,authentication_failures,brute_force,
Rule: 100001 (level 10) -> 'SSH brute-force attempt: 8+ failures in 60s'
Src IP: 192.168.100.30

** Alert 1701234598.23456: - local,linux,process,
Rule: 100010 (level 9) -> 'Privileged shell/interpreter spawned via auditd'

Findings

Detections Triggered

T1110 — SSH Brute-Force Attack Hydra credential-stuffing campaign from 192.168.100.30 against the Ubuntu endpoint. Rule 100001 fired after the 8th failed authentication attempt within a 60-second window. Severity Level 10. Alert included source IP, targeted user account, and authentication failure count.

T1046 — Network Service Discovery / Port Scan Nmap SYN scan of the Ubuntu endpoint's first 1024 ports generated a burst of TCP connection attempts logged by the kernel firewall. Wazuh correlated the log stream and raised a Level 8 alert for rapid multi-port connection attempts from a single source.

T1068 — Exploitation for Privilege Escalation Sudo misconfiguration (NOPASSWD vim) exploited to spawn a root shell. The auditd event captured the execve syscall with euid=0 and parent process vim. Custom rule 100010 fired at Level 9, referencing T1059.004 and T1068.

T1059 — Suspicious Process Execution (Command & Scripting Interpreter) Post-escalation execution of bash, python3, and nc (Netcat) under UID 0 was captured by auditd and raised further Level 9 alerts. The alert chain demonstrated process ancestry tracing from the initial sudo invocation through to the reverse shell attempt.

Framework Mapping

MITRE ATT&CK Mapping

Technique ID	Technique Name	Tactic	Wazuh Rule(s)	Alert Level
T1110.001	Password Guessing (SSH)	Credential Access	100001, 100002	10 / 12
T1046	Network Service Discovery	Discovery	40111 (built-in)	8
T1068	Exploitation for Privilege Escalation	Privilege Escalation	100010	9
T1059.004	Unix Shell Execution	Execution	100010	9
T1105	Ingress Tool Transfer (nc)	Command & Control	100010	9

Outcomes

Key Learning Outcomes

Custom Rules Written

6

XML detection rules covering SSH brute-force, privilege escalation, and suspicious process execution

MITRE Techniques Covered

5

Mapped T1110, T1046, T1068, T1059, T1105 to Wazuh alert events

Attack Scenarios Simulated

4

Brute-force, port scan, privilege escalation, reverse shell — all verified in OpenSearch Dashboards

Log Sources Configured

5

auth.log, syslog, auditd, Wazuh FIM (file integrity), and active response module

This homelab project strengthened practical skills in SIEM deployment, detection rule authoring, and attack simulation in an isolated lab environment. Working end-to-end — from infrastructure build to alert verification — provided hands-on familiarity with the analyst workflow: ingesting logs, tuning alert thresholds, reducing false positives, and mapping raw events to the MITRE ATT&CK framework for structured reporting.

WazuhHomelab SOC