StashGrid

Home › The Stash

Lab 08 — Watch your own machine: enroll a Wazuh agent and catch real alerts

LabSeptember 23, 2026

IntermediateIdea buildTime ~45 minTool Wazuh agentNeeds Wazuh lab + Lab 00Cost freeExam CySA+ · Security+ · CC

0 / 6 steps

The goal

Connect your Kali VM to the Wazuh SIEM you already built, make a little harmless noise on purpose, and watch Wazuh catch it — then read each alert the way a SOC analyst does: what fired, how serious it is, and which MITRE ATT&CK technique it maps to. By the end you will have a monitored machine and your first real detections.

Your machines only. Everything here happens on the Kali VM from Lab 00 and the Wazuh stack from the Wazuh lab. The “noise” in step 05 is ordinary mistakes — a wrong password, a throwaway user — made on purpose on a box you own. Never install a monitoring agent on, or generate test alerts against, a machine that isn’t yours.

Why this lab. A SIEM with nothing reporting to it is an empty dashboard. The agent is the small program on each machine that reads its logs, watches its files and ships events to the manager. Enrolling one, and proving it works, is the first thing anyone does after standing Wazuh up — at home or at work.

Before you start. Your Wazuh stack from the Wazuh lab should be running and you should be able to log in to the dashboard. Your Kali VM from Lab 00 should be on the same computer, using VirtualBox’s default NAT network. Take a snapshot of Kali first — you are about to install software on it.

Steps

01Get the VM and the manager talking

The agent needs to reach the Wazuh manager on two ports: 1515 to enroll, and 1514 to send events. The Wazuh lab publishes both on your computer. From inside a VirtualBox NAT VM, your own computer is always reachable at one fixed address: 10.0.2.2.

In a Kali terminal, check both ports answer:

$ nc -zv 10.0.2.2 1515 && nc -zv 10.0.2.2 1514

Two “open” or “succeeded” lines mean you are good. If you are using a bridged adapter or a separate machine instead, swap 10.0.2.2 for your computer’s own IP address everywhere in this lab.

Why check first. Nine out of ten “my agent never shows up” problems are the network, not Wazuh. Proving the path before you install anything means that if something fails later, you already know it isn’t this.

02Give Wazuh a log it can read

Recent Kali releases keep logs only in the systemd journal, with no classic /var/log/auth.log. The Wazuh agent decides which log files to watch when it is installed, based on what exists on disk at that moment — so create the file first.

$ sudo apt install -y rsyslog && sudo systemctl enable --now rsyslog

Then confirm it exists:

$ ls -l /var/log/auth.log

Why this matters. auth.log is where Linux records logins, sudo use and account changes — the raw material for most of the detections you will see today. A SIEM can only detect what it is actually fed, and “the log we thought we were collecting wasn’t there” is a real, common gap.

03Enroll the agent

Let the dashboard write the install command for you — it picks the agent version that matches your manager, which matters. In the Wazuh dashboard, open the agents / endpoints summary and click Deploy new agent. Choose:

  • Package: Linux, DEB amd64
  • Server address: 10.0.2.2
  • Agent name: kali-lab

The wizard shows a one-line command that downloads the agent package and installs it with WAZUH_MANAGER and WAZUH_AGENT_NAME already filled in. Copy it from the wizard and run it in Kali. Then start the agent and make it survive reboots:

$ sudo systemctl daemon-reload && sudo systemctl enable --now wazuh-agent

Why use the wizard. An agent must not be newer than the manager it reports to. The wizard reads your manager’s version and hands you a matching package, which rules out the most confusing enrollment failure before it can happen.

04Prove it is reporting

Check from both ends. On Kali, the agent’s own log says whether it reached the manager:

$ sudo grep -i "connected to the server" /var/ossec/logs/ossec.log | tail -n 3

You want a line ending in the manager’s address and 1514/tcp. Then in the dashboard, kali-lab should appear in the agents list with status Active within a minute or two.

Why both ends. “The service is running” and “the data is arriving” are different claims. Checking the agent log and the manager’s view separately tells you which half to fix if they disagree.

05Make some noise on purpose

Now give Wazuh something to see. Each of these is an everyday mistake or admin task, done deliberately on your own VM.

Fail sudo three times. Run this and type a wrong password at every prompt until it gives up:

$ sudo -k && sudo true

Create an account, then delete it. New accounts are a classic thing attackers do to keep access, so SIEMs watch for them:

$ sudo useradd -M sg-labtest && sudo userdel sg-labtest

Try to log in as someone who doesn’t exist. Start Kali’s SSH server, attempt a login with a made-up username (press Enter at the password prompts, then Ctrl+C), and stop the server again straight away:

$ sudo systemctl start ssh && ssh nosuchuser@localhost
$ sudo systemctl stop ssh

Why these three. Failed privilege use, new accounts and logins for unknown users are among the most common early signs of someone probing or settling into a machine. Generating them yourself, safely, is how you learn what “normal” alerts look like before you ever see a real one.

06Find the alerts and read the ATT&CK mapping

In the dashboard, open Threat Hunting and filter to your agent. This search bar filter shows only events from your VM:

agent.name:kali-lab

Open one of the alerts from step 05 and read four fields:

  • rule.description — what Wazuh thinks happened, in plain words
  • rule.level — severity from 0 to 15; higher means look sooner
  • rule.id — the exact rule that fired, so you can look it up
  • rule.mitre.technique and rule.mitre.id — the ATT&CK technique it maps to

Then open the MITRE ATT&CK view for the same agent and see your three bits of noise laid out as techniques and tactics. Expect things in the neighbourhood of brute force, account creation and valid-account use — but trust what your dashboard shows over this sentence.

Why this matters. ATT&CK is the shared language of detection. “We saw failed sudo” is a log line; “we saw activity mapped to a known technique, at this severity, on this host” is something a team can prioritise, compare and report on. That translation is the everyday work of a SOC analyst.

Lab complete

You have a monitored machine, a proven path from agent to manager, and your first real detections — each one read, rated and mapped to ATT&CK. That is the loop every SOC runs, just at home scale.

If it didn’t work

  • nc times out on 10.0.2.2. Check the Wazuh stack is up (docker compose ps in the single-node folder) and that the VM’s network adapter is NAT. On Windows, allow Docker Desktop through the firewall if it asks.
  • The agent never appears, and ossec.log mentions a version error. The agent is newer than the manager. Remove it with sudo apt remove --purge wazuh-agent and reinstall using the command the wizard gives you.
  • It appears but stays “Never connected” or “Disconnected”. Enrollment on 1515 worked but events on 1514 are not getting through. Re-run the step 01 check for 1514, then sudo systemctl restart wazuh-agent.
  • The agent is Active but step 05 produced nothing. The agent was installed before auth.log existed, so it isn’t watching it. Add this inside the <ossec_config> block of /var/ossec/etc/ossec.conf, then restart the agent: <localfile><log_format>syslog</log_format><location>/var/log/auth.log</location></localfile>
  • The alerts are there but the time looks wrong. Widen the dashboard’s time picker to the last hour, and check the VM’s clock matches your computer’s.

Your turn — no walkthrough

Catch a file change. Wazuh’s file integrity monitoring is already watching system folders on your agent, but on a slow schedule. Using the Wazuh documentation (allowed) and not this page, make it watch one folder of your choosing in real time, then create, edit and delete a file in it and find all three events in the dashboard.

Keep the evidence. Write a four-line incident note for any one alert from this lab: the time, the host, what happened (the rule description in your own words) and the ATT&CK technique — then a fifth line saying whether it was expected and why. That shape is exactly what a SOC ticket looks like.

Clean up

Make sure SSH is stopped on Kali (sudo systemctl stop ssh) and the test user is gone (id sg-labtest should say “no such user”). If you want the agent off the VM, run sudo apt remove --purge wazuh-agent, then remove kali-lab from the agents list in the dashboard so it doesn’t sit there as disconnected. Or keep it — a permanently monitored lab box is useful for every lab after this one.

Before you leave — prove it

Without scrolling up: one, which two ports does an agent need, and what is each for? Two, why did we create auth.log before installing the agent? Three, pick one of your alerts — what was its level, and which ATT&CK technique did it map to?

If the third answer comes from your own screen rather than this page, you have done the part that matters.

What you learned

  • Agents — what they do, and how one reports to a manager
  • Ports 1515 and 1514 — enrollment versus event traffic, and testing both with nc
  • Log sources — why auth.log has to exist before a SIEM can use it
  • Version matching — agent never newer than manager
  • Reading an alert — description, level, rule ID and ATT&CK mapping
  • Safe test signals — generating known-good noise to learn what alerts look like

Put it on your resume. Enrolled a Linux endpoint in Wazuh, generated test activity and triaged the resulting alerts by severity and MITRE ATT&CK technique. Change it to match what you actually did.

Tried it? Tell us

Nova built this lab from Steven’s ideas, and most StashGrid labs haven’t had a full run yet. If a step broke, behaved differently for you, or you know a better way, tell us. Ideas for the next lab are welcome too — no promises on timing.

NextLab 09 — Read your own logs: first-response triage→

Go deeper

Original walkthrough, written against the official Wazuh documentation for a single-node Docker deployment. Menu names in the dashboard shift between Wazuh versions — if a button here has moved, trust your dashboard, and tell me so I can fix the page.