Wazuh Hands-on Labs¶

Choose the route that fits your available time and computing resources. Use the Interactive Lab for a short guided investigation, or the Full Lab to build and operate a complete Wazuh workflow in virtual machines.

Hands-on proof of concept

Build it. Detect it. Improve it.

Start with one Wazuh server and one Ubuntu endpoint, prove that a recognisable file change reaches Wazuh, then investigate the evidence and validate a useful improvement. Add the wider PoC integrations only after the core route works.

⏱ 4–7 hours core ◆ Guided beginner ✓ Evidence required

Start building

Self-hosted · Several hours

Wazuh Full Lab

Installation required

How this differs from the guided journeys

This is not a screenshot-by-screenshot procedure. It gives you outcomes, commands, and success checks while leaving room to investigate. Your addresses, software versions, field names, and results may differ from the original PoC.

Use an isolated, authorised environment

Generate activity only on systems you own or are authorised to test. Review the expected system change and cleanup method first, and take a snapshot before modifying files, services, packages, accounts, or firewall rules.

Before you begin

You need: an x86-64 computer with virtualisation enabled, administrator access, approximately 16 GB of available RAM, 160 GB of free disk space, and temporary internet access for authorised downloads.

How to use this lab

Complete one session at a time. Stop when a checkpoint fails; fix that boundary before continuing or adding another endpoint, log source, or response action.

Recommended first

Beginner Core Lab¶

Use one all-in-one Wazuh server and one Ubuntu endpoint. Complete all three activities with this pair before adding another source.

Expected time: 4–7 hours across three sessions.

Optional extension

Complete PoC¶

After the core checkpoint passes, add Windows and Sysmon, a FortiGate relay, an IDS integration, archive storage, or active response using the linked guides.

Expected time: one or more additional sessions.

Session 1Build and snapshot2–3 hours
Session 2Connect and detect1–2 hours
Session 3Investigate and improve1–2 hours

Objective¶

You are a junior SOC analyst validating file-change monitoring for a small environment. Build the core Wazuh topology, onboard one endpoint, generate a known file change, trace it through the evidence, and publish a focused view that another analyst can use.

The beginner route consists of:

one Wazuh manager, indexer, and dashboard on an all-in-one server;
one Ubuntu endpoint running the Wazuh agent; and
an isolated network connecting the two systems.

Use the optional Complete PoC only when the two-machine route works reliably.

01

Activity 1: Build the environment¶

Download checklist¶

Record the filename, version, architecture, checksum, licence condition, and download date for every item.

Required for the Beginner Core Lab¶

Item	Purpose	Authoritative source
VMware Workstation Pro, demonstrated	Hypervisor used for the screenshots; another x86-64 hypervisor is suitable if it provides isolated virtual networking and snapshots	Broadcom installation and download guidance
CentOS Stream 9 ISO	Demonstrated operating system for the Wazuh server	CentOS Stream downloads
Ubuntu Server ISO	Operating system for the monitored endpoint	Ubuntu releases
Wazuh central and agent packages	Central platform and endpoint collection	Wazuh offline installation

Evaluation and vendor access

Some downloads require registration or licence acceptance. Record those constraints before building the lab.

Create the virtual machines¶

VM	Suggested lab allocation	Demonstrated address
WazuhServer	4–8 vCPU, 8–16 GB RAM, 100 GB disk	`10.0.0.20`
UbuntuEndpoint	2 vCPU, 4 GB RAM, 40 GB disk	`10.0.0.26`

Enable hardware virtualisation and install VMware Workstation or an equivalent x86-64 hypervisor with isolated networking and snapshot support.
Create an isolated lab network. Provide NAT only while a machine needs authorised download or update access.
Create the Wazuh server and Ubuntu endpoint VMs, attach the recorded ISOs, and install each operating system.
Configure hostnames, static addresses, gateway, DNS, and time synchronisation. Adapt the entire address plan consistently if required.
Install guest tools where appropriate and apply the selected OS baseline.
Confirm the two VMs can reach each other and only the required lab and update services.
Take a clean base-os snapshot before installing Wazuh.

Milestone 1Two machines onlineBoth hosts have recorded addresses, synchronised clocks, working lab connectivity, and a clean snapshot.

Optional PoC machines and downloads

Add these only after the Beginner Core Lab works:

Optional item	Purpose
Windows Server evaluation ISO and Sysmon	Windows endpoint and additional process telemetry
Ubuntu rsyslog relay and FortiGate	Network-log ingestion path
Snort or Suricata host	IDS alert integration
Kali	Optional administration or controlled test workstation

Use the vendor minimum for FortiGate, 2–4 vCPU and 4–8 GB RAM for Windows, and 2 vCPU and 4 GB RAM for optional Linux systems. Record the address and snapshot for every system you add.

Expected result The Wazuh server and Ubuntu endpoint start with synchronised clocks, recorded addresses, working connectivity, and a recoverable base-os snapshot.

02

Activity 2: Connect and verify¶

Follow the checkpoints in order. Keep this page open and return after each linked journey.

Wazuh is onlineInstall Wazuh, open the dashboard, and verify the manager, indexer, and Filebeat services.
The endpoint is connectedInstall the Linux agent on Ubuntu and confirm its status is active.
The test path is monitoredAdd the dedicated lab directory to the agent's file-integrity configuration.
The first event arrivesCreate the harmless file below, then find the change by agent, path, and execution time.
The baseline is recoverableRecord the working state and take a working-wazuh-core snapshot.

On the Ubuntu endpoint, create a dedicated test directory:

sudo install -d -m 0755 /opt/cdk-wazuh-lab

Add this entry inside the <syscheck> section of /var/ossec/etc/ossec.conf:

<directories check_all="yes" report_changes="yes" realtime="yes">/opt/cdk-wazuh-lab</directories>

Restart the agent, confirm it is active, and record the current time:

sudo systemctl restart wazuh-agent
sudo systemctl is-active wazuh-agent
date -Is

Generate two harmless, recognisable file changes:

echo "approved lab change" | sudo tee /opt/cdk-wazuh-lab/assessment.txt
echo "second approved change" | sudo tee -a /opt/cdk-wazuh-lab/assessment.txt

Open File Integrity Monitoring in the Wazuh dashboard and use a narrow time range around the commands. Filter by your Ubuntu agent and /opt/cdk-wazuh-lab/assessment.txt. If needed, search for the file-integrity rule IDs 550, 553, and 554. Record the timestamp, agent.name, syscheck.path, syscheck.event, rule.id, and rule.level fields shown in your environment.

Milestone 2First event explainedYou generated a known file change and traced it from the Ubuntu endpoint into an explainable Wazuh record.

Extend the working core with another source

Choose only one extension at a time:

add a Windows agent and Sysmon using Endpoint agents;
collect one network source using Network logs;
add a Snort or Suricata source using IDS integrations;
enable wider event storage only when the investigation requires archives; or
test active response only after defining the target, exclusions, duration, and rollback.

Repeat the source → agent or relay → manager → dashboard checkpoint before adding another integration.

Expected result The Ubuntu agent is active, the controlled file changes appear in Wazuh with the expected endpoint and path, their useful fields are recorded, and the working core has a recovery snapshot.

03

Activity 3: Investigate and improve¶

Restore or clone the working-wazuh-core snapshot from Activity 2. Confirm the dashboard opens, the Ubuntu agent is active, and the known file-integrity event is still searchable before continuing.

Investigation scenario¶

You are the junior analyst reviewing an approved change on a monitored Linux endpoint. Determine what changed, when it happened, which evidence supports the conclusion, and what remains unknown. The goal is an evidence-based assessment, not to label the authorised test as an incident.

Set a narrow time range around the event generated in Activity 2.
Filter by your Ubuntu agent and the full path to assessment.txt.
Open one event and confirm its raw fields before relying on dashboard labels.
Record any field-name substitutions that differ from this guide.

Use a filter equivalent to the following, adapting it to the fields available in your dashboard:

agent.name:"<your-ubuntu-agent>" AND syscheck.path:"/opt/cdk-wazuh-lab/assessment.txt"

Answer these questions:

What changed, and when did it happen?
Which endpoint and path were involved?
Which raw fields support the conclusion?
Did Wazuh alert on the event, archive it only, or miss part of the activity?
Which rule ID and level influenced the result?
What evidence would increase your confidence?
Is the behaviour malicious, suspicious, or benign in this authorised context?

Record the reasoning before deciding:

Hypothesis	Supporting evidence	What remains unknown	Decision
The monitored file was changed during the approved test	Add the agent, path, timestamps, event type, and rule details you observed	Note any missing process, user, or wider host context	Record your evidence-based classification

Improve and validate¶

Save a dashboard view filtered to the Ubuntu endpoint and the dedicated lab path. Give it a clear title such as CDK - monitored file changes and add a short description explaining the question it answers.

Run a positive test:

echo "positive validation" | sudo tee -a /opt/cdk-wazuh-lab/assessment.txt

Then create a benign comparison outside the monitored path:

echo "routine note" | sudo tee /tmp/cdk-benign.txt

Confirm that the positive event appears in the saved view and that the benign comparison does not appear as the same scoped finding. Record the expected and actual result for both tests.

Try a more advanced improvement

After the saved-view route works, choose one optional improvement:

create a narrowly scoped custom child rule;
tune a frequency threshold using repeatable test data;
reduce a demonstrated false positive;
refine a decoder for an incompletely parsed event;
add a useful MITRE ATT&CK mapping; or
configure a notification with a clear owner and purpose.

Record the file changed, rule or decoder ID, reason, validation command, and rollback. Repeat both a positive and comparable benign test. Automated active response remains optional and should be attempted only after its target, duration, exclusions, and recovery path are understood.

Write the analyst handoff¶

Keep the note short enough for another analyst to scan. Include:

Who and where: endpoint, account if known, and monitored path;
What happened: the connected file activity and time window;
Evidence: useful raw fields, rule ID, level, and saved filter;
Decision: your classification and why it fits the approved context;
Unknowns: missing process, user, intent, or wider-scope evidence; and
Validation: the improvement, positive result, and benign comparison.

Milestone 3Improvement validatedAnother analyst can open your saved view, understand the finding and its limits, and reproduce the positive and benign checks.

Expected result You can connect the Wazuh event to raw evidence, support a defensible conclusion, and demonstrate that the saved view distinguishes the monitored test from an unrelated file.

Treat active response as an optional extension

Automated containment is not required for this challenge. Use it only when the target, duration, exclusions, rollback, and recovery path are understood.

Full Lab evidence checklist¶

This checklist applies to the self-hosted Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

Do not aim to match every screenshot or complete every optional integration. Collect evidence that proves your selected route works:

Core downloads, two-machine topology, address plan, time synchronisation, and snapshots.
Central-service health and the active Ubuntu agent.
The controlled file-integrity event with agent, path, timestamp, event type, rule ID, and level.
The saved investigation filter, evidence-based conclusion, and remaining unknowns.
The saved-view improvement with positive and benign-comparison results.
The analyst handoff, cleanup confirmation, and any differences from the original PoC.

0 of 6 recorded Mark each item when you have saved the evidence.

Clean up¶

On the Ubuntu endpoint, remove the temporary files:

sudo rm -f /opt/cdk-wazuh-lab/assessment.txt /tmp/cdk-benign.txt

If the monitored directory was created only for this lab, remove its <directories> entry from /var/ossec/etc/ossec.conf, restart the Wazuh agent, and confirm it is active. Remove the empty directory or restore the working snapshot if appropriate. Confirm the Wazuh central services and endpoint have returned to the recorded baseline. Retain screenshots, filters, and conclusions only when they contain no sensitive information.