learn-cyber · lesson 4 · hands-on lab

Deploy your first agent and catch an attack

Put an agent on a machine, attack it on purpose, and watch Wazuh raise the alert. This is the moment the whole pipeline stops being theory.

Your mission You're building an MSSP to monitor hotels with Wazuh. Today the "endpoint" is a spare VM — but treat it as a hotel front-desk PC or the PMS server. What you do here is exactly what you'll do on a real hotel device, just repeated across the whole property.

What you're building today

Your server from Lesson 3 is running, but it's watching nothing — it has no agents. Today you'll enroll an agent on a second machine, confirm it reports in as Active, then trigger a real detection and watch the alert land in the dashboard.1

Key idea An agent is the collector that lives on each device (Lesson 1, step 1). To enroll, it needs exactly one thing from you: the manager IP — the address of your Lesson-3 server. Point it there, start it, and it shows up in your console.
Before you start — prerequisites

Part A — enroll the agent

Wazuh gives you a wizard that writes the install commands for you. Use it.

  1. Open the deploy wizard. In the dashboard, find "Deploy new agent" (the agent-enrollment wizard). It walks you through a few choices.

  2. Pick the OS of your endpoint (e.g. Linux / DEB or RPM to match your VM).

  3. Set the manager IP to your Lesson-3 server's address. This is the one piece of information the agent truly needs — it's how it knows where to phone home.

    Optionally assign a group here. Forward- reference: in your MSSP you'll create one group per hotel so each client's config and data stay cleanly separate — that's Lesson 6. For today, the default group is fine.

  4. Run the generated commands on the endpoint. The wizard prints an install + enrollment command tailored to your choices. Copy it and run it on the endpoint VM. Then start the agent:

    sudo systemctl start wazuh-agent

  5. Confirm it's Active. Back in the dashboard, the new agent should appear and flip to Active within a few seconds. If you prefer the command line, on the server:

    sudo /var/ossec/bin/agent_control -l

    Not showing up? Check the endpoint can reach the server on 1514/1515, and tail the agent log: sudo tail -f /var/ossec/logs/ossec.log.

Part B — trigger a real detection

Now make the pipeline fire. Pick either option — do both if you have time. Wazuh's built-in rules catch both of these out of the box.

Option A — SSH brute-force (mirrors Lesson 1)

From your attacker machine, hammer the endpoint's SSH with bad passwords. Run this several times, typing a wrong password each time:

ssh baduser@<agent-ip>
# enter a wrong password, let it fail, repeat 5–10 times

Repeated authentication failures from one source is the textbook brute-force signature. Wazuh's built-in rules decode each failed login and a correlation rule fires on the cluster of them — exactly the "fifty failures, one alert" pattern from Lesson 1.

Watch it land: in the dashboard go to Threat Hunting / Security events, filter by your agent, and watch the failed-login events roll in followed by the higher-level "multiple authentication failures" alert.

Option B — File Integrity Monitoring (FIM)

FIM watches critical files and tells you when one changes — the Integrity half of the CIA triad. Create or modify a file in a monitored path on the endpoint:

sudo touch /etc/wazuh-test-file
echo "tampered" | sudo tee -a /etc/wazuh-test-file

Then watch the Integrity Monitoring view in the dashboard for the change to appear.

FIM may run on a schedule or in real time depending on config, so the alert can take a moment. Keep it simple for now — the point is just to see a file change become an alert.

Tie it back — this is the whole business Millions of events → one alert → your triage. You just watched that compression happen on one VM. For a hotel it's the same shape — failed logins on the PMS, a changed file on a POS terminal — only across dozens of devices at once. The pipeline scales; the idea doesn't change.
You didn't write a single rule Both detections came from Wazuh's built-in ruleset — free, on by default. Lesson 5 opens that black box: how decoders and rules actually work, and how to write your own for hotel-specific systems like OPERA and your POS.

Check yourself

From memory first. You'll enroll agents and chase alerts dozens of times once you're live — burn the basics in now.

Question 1 of 3

What is the one piece of information an agent must have to enroll?

The agent needs the manager IP — the address of your Wazuh server — so it knows where to send its data. The group is optional; the manager IP is not.

Question 2 of 3

You ran the SSH brute-force. Where do you go to watch the alert?

Decoded events and the alerts they raise show up under Threat Hunting / Security events. Filter by your agent and the failed logins — then the brute-force alert — appear right there.

Question 3 of 3

What does File Integrity Monitoring (FIM) actually detect?

FIM watches critical files and flags when one is created, modified, or deleted — the Integrity leg of the CIA triad. A changed system file on a POS terminal is exactly the kind of tampering it's built to catch.

Primary source to read next
Wazuh — Getting Started and the Components overview ground how the agent and server fit together. For the detection idea itself, read the Threat hunting use case — it's the official version of what you just did by hand.
I'm your teacher — ask me anything. Agent stuck on "Never connected"? Brute-force not raising an alert? Want to know which built-in rule ID fired and why? Paste what you're seeing into the chat. Reading a real alert and tracing it back to its rule is the core skill of the job — let's practice it on yours.

You just earned: an agent reporting in as Active, and your first real Wazuh alert — triggered, found, and understood. The Lesson-1 pipeline is no longer a diagram; you watched it run.

Up next (Lesson 5): decoders and rules — how Wazuh turns a raw log line into a leveled alert, and how to write custom detections for the systems hotels actually run.

← Prev: Lesson 3 — Stand up your server · Next: Lesson 5 — Decoders & rules →

Reference: Glossary · All resources · Mission