SOC Threat Detection Lab with Wazuh

Deploy Wazuh XDR, simulate a brute-force attack, and write an incident report.

Introduction

30 Second Summary

Every time you log into an online account, security teams are watching for suspicious login attempts behind the scenes. If someone tries to guess your password hundreds of times, a Security Operations Center (SOC) detects and stops that attack before it succeeds.

In this project, you will build a complete SOC threat detection lab using Wazuh XDR. You'll deploy a security server, monitor a Linux endpoint, simulate a real brute-force attack, and produce a professional incident report.

What You'll Build

A SOC threat detection lab that mirrors the workflow of an MSP security engineer, from deploying security tooling to documenting incidents for clients.

By the end of this project, you'll have:

  • A running Wazuh XDR server monitoring a Linux endpoint via an enrolled agent.
  • Detected and investigated a simulated brute-force attack using the Wazuh dashboard and MITRE ATT&CK mappings.
  • A professional incident report documenting the attack timeline, techniques, and remediation recommendations.
  • Secret Mission: Write a custom detection rule and configure an active response to automatically block the attacker's IP.

Are there any prerequisites?

You'll need basic Linux command-line familiarity and an understanding of SSH. You'll also need VirtualBox installed and at least 10 GB of free RAM on your host machine to run two virtual machines simultaneously.

Deploy the Wazuh XDR Server

Every SOC lab starts with the monitoring server. Wazuh is an open-source XDR platform that collects logs from endpoints, correlates them against thousands of detection rules, and maps alerts to the MITRE ATT&CK framework.

In this step, you will import the pre-built Wazuh OVA into VirtualBox, configure the VM settings, and verify the dashboard is accessible. This gives you a fully operational XDR server ready to receive agents.

In this step, get ready to:
  • Import the Wazuh OVA and configure VirtualBox settings.
  • Log into the Wazuh dashboard.
  • Verify network connectivity between your VMs.
Import the Wazuh OVA into VirtualBox

The Wazuh OVA bundles the manager, indexer, and dashboard into a single appliance. Importing it gives you a working server in minutes instead of hours.

  • In VirtualBox, click File in the top menu bar.
  • Click Import Appliance.
  • Browse to the wazuh-4.14.5.ova file you downloaded and select it.
  • Click Finish (or Import) and wait for the import to complete.

What does importing an OVA do?

An OVA is a pre-packaged virtual machine image. VirtualBox unpacks it and creates a new VM with all the software already installed and configured. The Wazuh OVA includes Amazon Linux 2023, the Wazuh manager, indexer, and dashboard, all pre-wired to work together.

Now you need to adjust two settings to prevent the VM from freezing or drifting out of sync.

  • Select the newly imported Wazuh VM in the VirtualBox sidebar.
  • Click Settings.
  • Click Display.
  • At the top-left of the settings window, switch from Basic to Expert mode.
  • From the Graphics Controller dropdown, select VMSVGA.

Why VMSVGA?

Other graphics controllers can cause the Wazuh VM window to freeze. The Wazuh documentation specifically recommends VMSVGA to avoid this issue.

  • Still in Settings, click System.
  • Switch to Expert mode again if it reverted to Basic.
  • Click the Motherboard tab.
  • Under Features, enable Hardware Clock in UTC Time.
  • Click OK to save all settings.

Why enable UTC time?

VirtualBox can cause the guest VM's clock to drift when it synchronizes time. Enabling the UTC hardware clock prevents time skew, which is critical for accurate alert timestamps in your SOC lab.

Now start the VM and log in.

  • Select the Wazuh VM and click Start (the green arrow).
  • Wait for the login prompt to appear in the VM console window.
  • Log in with username wazuh-user and password wazuh.

VM window is black or frozen?

Power off the VM, go back to Settings > Display, and confirm the Graphics Controller is set to VMSVGA. Other controllers (VBoxVGA, VBoxSVGA) can freeze this appliance.

Also confirm your host machine has at least 10 GB of free RAM. The Wazuh OVA allocates 8 GB by default.

help me troubleshoot my Wazuh OVA not booting in VirtualBox

Access the Wazuh dashboard

The Wazuh dashboard is a web interface where you will hunt threats, view alerts, and manage agents. To access it, you first need the server's IP address.

  • Find your Wazuh server's IP address by running this command in the VM console:
ip a

What am I looking for?

Look for an inet address on the main network interface (usually eth0 or enp0s3). It will look something like 192.168.1.105/24. The part before the / is your Wazuh server IP.

  • On your host machine, open a web browser.
  • Navigate to the Wazuh dashboard URL, substituting your IP:
https://[[WAZUH_IP="your Wazuh server IP address"]]
  • Your browser will show a certificate warning because the dashboard uses a self-signed certificate. Click Advanced and then Proceed (or Accept the Risk) to continue.
  • Log in with username admin and password admin.

You should see the Wazuh dashboard server overview showing 0 agents enrolled.

Can't reach the dashboard?

Make sure you are using https:// (not http://). The dashboard only responds on HTTPS.

If the page times out, confirm your host machine and the Wazuh VM are on the same network. Check the VM's network adapter setting (covered in the next substep).

help me access my Wazuh dashboard

Verify the network configuration

Both your Wazuh server VM and your Ubuntu VM need to be on the same network so they can communicate. The Wazuh OVA defaults to Bridged Adapter, but you should confirm this.

  • In VirtualBox, select the Wazuh VM (you can leave it running).
  • Click Settings > Network.
  • Confirm that Attached to is set to Bridged Adapter.
  • If it is set to NAT or another option, change it to Bridged Adapter and click OK.
  • Repeat this check for your Ubuntu 22.04 VM to ensure it is also set to Bridged Adapter.

Why Bridged Adapter?

Bridged Adapter places both VMs on your host machine's physical network. They receive IP addresses from your router's DHCP server and can communicate directly, just like two physical machines on the same LAN.

NAT mode isolates each VM behind its own virtual router, which would prevent the Wazuh agent from reaching the server.

Your Wazuh XDR server is up and running. Next up, you will enroll your Ubuntu VM as a monitored endpoint so the server has something to protect.

Enroll a Linux Endpoint as a Wazuh Agent

Your Wazuh XDR server is running and the dashboard is accessible. Now you need something for it to monitor.

In a real SOC environment, an agent is a lightweight piece of software installed on every endpoint (laptop, server, workstation) that collects logs and forwards them to the central XDR platform for analysis. In this step, you will install the Wazuh agent on your Ubuntu VM so it becomes a monitored endpoint reporting back to your server.

In this step, get ready to:
  • Prepare your Ubuntu VM with network connectivity and SSH enabled.
  • Install and register the Wazuh agent on your Ubuntu endpoint.
  • Verify the agent appears as Active in the Wazuh dashboard.
Prepare your Ubuntu VM

Before installing the agent, your Ubuntu VM needs to be on the same network as the Wazuh server. Both VMs must use a Bridged Adapter so they can communicate directly over your local network.

  • In VirtualBox, select your Ubuntu 22.04 VM.
  • Click Settings, then select Network.
  • Set the Attached to dropdown to Bridged Adapter.
  • Select the same host network interface that your Wazuh server VM uses (your active Ethernet or Wi-Fi adapter).
  • Click OK to save and start the Ubuntu VM.

Why Bridged Adapter?

A Bridged Adapter makes the VM appear as a separate physical device on your local network. Both VMs get their own IP addresses on the same subnet, so they can communicate directly. If you use NAT instead, each VM gets an isolated network and cannot reach the other.

Once the Ubuntu VM boots, log in and find its IP address.

  • Open a terminal inside the Ubuntu VM.
  • Find your Ubuntu VM's IP address by running:
ip a
  • Look for the inet address on your main network interface (usually enp0s3 or similar). This is your Ubuntu VM's IP address. Write it down.
  • Verify connectivity to your Wazuh server by running:
ping [[WAZUH_SERVER_IP="your Wazuh server IP address"]]
  • You should see replies coming back. Press Ctrl+C to stop the ping.

Not getting ping replies?

Make sure both VMs are set to Bridged Adapter on the same host interface. If you are using Wi-Fi, bridging can be unreliable on some systems. Try using a wired Ethernet connection if available.

Also confirm your Wazuh server VM is still running. You can check by looking for it in the VirtualBox Manager window.

Help me troubleshoot why my Ubuntu VM cannot ping my Wazuh server VM in VirtualBox. Both are set to Bridged Adapter.

Now install the SSH server so the Wazuh agent can monitor SSH authentication logs.

  • Install and start the OpenSSH server by running:
sudo apt update && sudo apt install -y openssh-server

Why install openssh-server?

The SSH server generates authentication logs every time someone tries to connect. These logs are exactly what the Wazuh agent monitors to detect brute-force attacks. Without SSH running, there is nothing for the agent to report on in the next step.

  • Confirm SSH is running by checking its status:
sudo systemctl status ssh
  • You should see active (running) in green text. Press q to exit the status view.
Install and register the Wazuh agent

With the Ubuntu VM online and SSH running, you can now install the Wazuh agent. The agent connects to your Wazuh server and begins forwarding security logs for analysis.

  • Install the required prerequisites by running:
sudo apt-get install gnupg apt-transport-https

What are these prerequisites?

The gnupg package lets your system verify cryptographic signatures on packages you download. The apt-transport-https package allows apt to fetch packages over HTTPS. Both are needed to securely download the Wazuh agent from its official repository.

  • Add the Wazuh GPG key to verify package authenticity by running:
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg

What does this command do?

  • Downloads Wazuh's official GPG key from their package server.
  • Imports it into a dedicated keyring file at /usr/share/keyrings/wazuh.gpg.
  • Sets permissions so apt can read the keyring when fetching packages.
  • Add the Wazuh package repository by running:
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
  • Update your package list and install the Wazuh agent by running:
sudo apt-get update && sudo WAZUH_MANAGER="[[WAZUH_SERVER_IP="your Wazuh server IP address"]]" apt-get install wazuh-agent

What does WAZUH_MANAGER do?

The WAZUH_MANAGER environment variable tells the agent which server to connect to during installation. The installer writes this IP into the agent's configuration file at /var/ossec/etc/ossec.conf so the agent knows where to send its logs.

Seeing a GPG or repository error?

If you see a GPG signature error, the key import may have failed silently. Re-run the GPG key import command above and confirm it prints no errors.

If apt-get update fails to reach the Wazuh repository, confirm your Ubuntu VM has internet access by running ping 8.8.8.8. If that fails, check your Bridged Adapter and host network connection.

Help me fix a GPG or repository error when installing the Wazuh agent on Ubuntu

  • Enable and start the Wazuh agent service by running:
sudo systemctl daemon-reload && sudo systemctl enable wazuh-agent && sudo systemctl start wazuh-agent

What do these three commands do?

  • daemon-reload tells systemd to re-read all service unit files (including the new Wazuh agent service).
  • enable configures the agent to start automatically on boot.
  • start launches the agent immediately. It will connect to your Wazuh server and begin forwarding logs.
  • Confirm the agent is running by checking its status:
sudo systemctl status wazuh-agent
  • You should see active (running) in the output. Press q to exit.
Verify enrollment in the dashboard

The agent is running on your Ubuntu VM and should now be reporting to the Wazuh server. Time to confirm it appeared in the dashboard.

  • Switch back to your browser where the Wazuh dashboard is open.
  • Click the upper-left menu icon.
  • Navigate to Agents management, then select Summary.
  • Confirm your Ubuntu agent appears in the list with an Active status.

Agent not showing as Active?

It can take 30-60 seconds for the agent to register and appear. Refresh the dashboard page and wait a moment.

If the agent still does not appear, verify from the Ubuntu VM that it can reach the Wazuh server on port 1514 (agent communication) and port 1515 (enrollment). A firewall on either VM could be blocking the connection.

Help me troubleshoot why my Wazuh agent is not appearing in the dashboard

You should now see 1 active agent enrolled in the dashboard. The Wazuh server is monitoring your Ubuntu endpoint in real time.

Your monitoring infrastructure is complete. You have a Wazuh server watching over a live endpoint. Next up, you will simulate a real-world brute-force attack against this endpoint and watch the alerts roll in.

Simulate a Brute-Force Attack

Your Wazuh XDR server is monitoring a live endpoint. Now it is time to give it something to detect.

In this step, you will simulate a real-world SSH brute-force attack against your Ubuntu VM. You will use Hydra, a parallelized login cracker used by penetration testers to test password strength. The attack will generate failed login attempts that the Wazuh agent forwards to the server in real time.

In this step, get ready to:
  • Prepare the Wazuh server VM as an attacker machine with Hydra installed.
  • Execute an SSH brute-force attack against the Ubuntu endpoint.
  • Verify the attack generated authentication failure logs.
Prepare the attack tools

You will use the Wazuh server VM as your "attacker" machine. The Wazuh OVA runs Amazon Linux 2023, so it has SSH client access and can install additional tools.

  • SSH into the Wazuh server from your host terminal (or open a new terminal window) by running this command:
ssh wazuh-user@[[WAZUH_SERVER_IP="your Wazuh server IP address"]]

When prompted for a password, enter wazuh.

Why use the Wazuh server as the attacker?

In a real SOC scenario, attacks come from external IPs. For this lab, using the Wazuh server as the attacker keeps things simple. Both VMs are already on the same bridged network, so they can communicate directly.

  • Install Hydra on the Wazuh server by running:
sudo yum install -y hydra

What does this command do?

This uses yum (the Amazon Linux 2023 package manager) to install Hydra. The -y flag automatically confirms the installation prompt.

You should see package download progress followed by a "Complete!" message.

Seeing "No package hydra available"?

Make sure you are on the Wazuh server VM (Amazon Linux 2023), not the Ubuntu VM. The Ubuntu VM uses apt, not yum.

If the EPEL repository is not enabled, try sudo yum install -y epel-release first, then retry the Hydra install.

Help me install Hydra on Amazon Linux 2023 in my Wazuh VM.

  • Create a password list file that Hydra will use during the attack by running:
echo -e "password1\npassword2\npassword3\nletmein\nadmin123\nqwerty\n123456\npassword\nroot\ntoor" > passwords.txt

What does this command do?

The echo -e command interprets the \n sequences as newlines, creating a file with 10 passwords (one per line). These are common weak passwords that real attackers try during dictionary attacks.

Wazuh rule 5712 triggers after 8 failed SSH attempts from the same IP within 2 minutes. Having 10 passwords ensures the brute-force detection rule fires reliably.

  • Confirm the file was created correctly by running:
cat passwords.txt

You should see 10 passwords listed, one per line.

Execute the SSH brute-force attack

With Hydra installed and your password list ready, you will now launch the attack. Hydra will attempt to log in to the Ubuntu VM's SSH service using a non-existent username (badguy) with each password from your list.

  • Run the brute-force attack against the Ubuntu endpoint:
hydra -l badguy -P passwords.txt [[UBUNTU_VM_IP="your Ubuntu VM IP address"]] ssh

What does this command do?

  • -l badguy sets the login username to badguy (a user that does not exist on the Ubuntu VM).
  • -P passwords.txt tells Hydra to try every password in the file.
  • The IP address is your Ubuntu VM target.
  • ssh specifies the protocol to attack.

Let Hydra complete. It should report all 10 attempts as failed, which is expected because the user badguy does not exist on the target system.

What should I see?

Hydra will display each login attempt and finish with a summary showing 0 valid passwords found. This is the correct outcome. The goal is not to crack a password. The goal is to generate failed authentication events that trigger Wazuh detection rules.

Hydra hangs or shows connection errors?

Confirm your Ubuntu VM is still running and reachable. From the Wazuh server, try ping followed by the Ubuntu VM IP to check connectivity.

Verify that openssh-server is running on the Ubuntu VM. SSH into the Ubuntu VM separately and run sudo systemctl status sshd to confirm it is active.

Help me troubleshoot Hydra not connecting to my Ubuntu VM over SSH.

Verify the attack generated logs

The Wazuh agent on your Ubuntu VM is forwarding authentication logs to the Wazuh server in real time. Before moving to the dashboard, confirm the raw logs exist on the endpoint.

  • Open a separate terminal or SSH session into your Ubuntu VM.
  • Check the authentication log by running:
sudo tail -20 /var/log/auth.log

What does this command do?

The tail -20 command shows the last 20 lines of /var/log/auth.log. This is the file where Linux records all authentication events, including failed SSH login attempts.

You should see multiple entries containing "Failed password for invalid user badguy" from the Wazuh server IP address. These are the login attempts Hydra just generated.

Not seeing failed login entries?

Make sure you are checking the log on the Ubuntu VM, not the Wazuh server. The /var/log/auth.log file exists on the target machine that received the SSH attempts.

If the log is empty, wait 30 seconds and try again. There can be a short delay between the attack finishing and the log entries being written.

Help me find the failed SSH login entries in my Ubuntu VM logs.

The attack is complete and the evidence is in the logs. Next up, you will hunt this threat in the Wazuh dashboard and see how the platform automatically correlates these events with MITRE ATT&CK techniques.

Hunt the Threat in the Wazuh Dashboard

Your simulated attack has generated dozens of failed login attempts, and the Wazuh agent has forwarded every one of those logs to the server in real time.

Now comes the part that makes a SOC engineer valuable: hunting the threat. You will use the Wazuh Threat Hunting module to find the brute-force alerts, examine the details that matter for an investigation, and see how they map to the MITRE ATT&CK framework.

In this step, get ready to:
  • Navigate to the Threat Hunting module and filter for brute-force alerts.
  • Analyze alert details including attacker IP, rule severity, and frequency.
  • Correlate findings with MITRE ATT&CK technique T1110.
Navigate to Threat Hunting

The Threat Hunting module is where Wazuh surfaces security alerts for investigation. You will filter the alerts down to the specific rules that detect SSH brute-force patterns.

  • In the Wazuh dashboard, click the upper-left menu icon (the hamburger menu).
  • Navigate to Threat Hunting.
  • In the search bar at the top, enter this filter:
rule.id:(5551 OR 5712)
  • Press Enter or click Refresh to apply the filter.

You should see a list of alerts appear in the results table. These are your brute-force detection events.

What are rules 5551 and 5712?

Rule 5712 fires when Wazuh detects 8 failed SSH attempts from the same IP within 2 minutes for a non-existent user. It is a level 10 alert (high severity).

Rule 5551 is a related rule for multiple authentication failures. Together, they cover the brute-force detection pattern.

Not seeing any alerts?

Make sure the time range in the upper-right corner of the dashboard covers the period when you ran Hydra. Try setting it to Last 1 hour or Today.

If alerts still do not appear, confirm the agent is active by checking Agents management > Summary and verifying the Ubuntu agent shows as Active.

Why aren't my brute-force alerts showing in the Threat Hunting module?

Analyze the alert details

Each alert contains structured data that tells you exactly what happened, who did it, and which endpoint was targeted. This is the information you would use to build an incident report.

  • Click on one of the rule 5712 alerts to expand its details.
  • Locate the following key fields in the expanded alert:
  • rule.mitre.id shows T1110 (the MITRE ATT&CK technique ID for Brute Force).
  • rule.mitre.tactic shows Credential Access (the attacker's goal category).
  • rule.mitre.technique shows Brute Force (the specific technique name).
  • data.srcip shows the attacker's IP address (your Wazuh server IP).
  • agent.name shows your Ubuntu endpoint's hostname.
  • Observe the frequency information. Rule 5712 triggered because 8 failed attempts from the same IP occurred within 2 minutes.
  • Scroll through the results and also look for rule 5710 alerts. These are the individual failed login events with description sshd: Attempt to login using a non-existent user.

Why do both rule 5710 and 5712 appear?

Rule 5710 fires for each individual failed SSH login attempt (level 5). Rule 5712 is a correlation rule that fires once Wazuh sees 8 of these 5710 events from the same source IP within 2 minutes, escalating the severity to level 10.

This two-tier approach means Wazuh captures the raw events AND the high-confidence brute-force pattern. A SOC analyst uses the 5712 alert as the starting point, then drills into the 5710 events for the full timeline.

Correlate with MITRE ATT&CK

The alerts are automatically mapped to MITRE ATT&CK technique T1110 (Brute Force) under the Credential Access tactic. This mapping happens because Wazuh's built-in rules include MITRE metadata.

What is MITRE ATT&CK?

MITRE ATT&CK is a globally recognized knowledge base of adversary tactics, techniques, and procedures. Enterprise SOC teams use it as a common language to categorize and communicate threats.

When your alert says T1110 / Credential Access / Brute Force, any security professional in the world immediately knows the attack category, the attacker's goal, and the method used. This standardized mapping is what makes your incident report professional and actionable.

  • Confirm that the rule 5712 alert shows T1110 in the rule.mitre.id field.
  • Confirm that the tactic is Credential Access and the technique is Brute Force.
  • Note the data.srcip value. This is your Wazuh server's IP, which acted as the attacker machine.

You now have all the data points needed to write a professional incident report: attacker IP, target endpoint, timestamps, rule severity, and MITRE ATT&CK classification.

You have hunted down a real brute-force attack using the same tools and workflow a SOC engineer uses daily. Next up, you will turn these findings into a professional incident report that documents the full attack lifecycle.

Write a Professional Incident Report

You have detected and investigated a real brute-force attack using the Wazuh dashboard. The alerts, timestamps, and MITRE ATT&CK mappings are all in front of you.

Now it is time to turn that raw alert data into a professional incident report. This is the deliverable that a SOC Engineer at an MSP sends to clients after an investigation. The report documents what happened, when it happened, what the impact was, and what to do next.

In this step, get ready to:
  • Create the incident report structure with key metadata fields.
  • Document the attack timeline and impact analysis using data from the Wazuh dashboard.
  • Write actionable remediation recommendations with MITRE ATT&CK references.
Create the incident report structure

Every professional incident report starts with a header section that gives readers the key facts at a glance. This header tells the client what happened, which asset was affected, and how the attack was detected.

  • On your host machine (not inside a VM), open any text editor you prefer.
  • Create a new file and save it as incident-report.md on your Desktop.
  • Copy the following report header template into your file:
# Incident Report

## Header

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-001 |
| Date/Time | [[FIRST_ALERT_TIME="timestamp of first alert from Wazuh dashboard"]] |
| Severity | High (Level 10) |
| Affected Asset | [[UBUNTU_VM_HOSTNAME="your Ubuntu VM hostname or IP"]] |
| Attack Type | SSH Brute-Force (MITRE ATT&CK T1110 - Credential Access) |
| Source IP | [[WAZUH_SERVER_IP="your Wazuh server IP (the attacker)"]] |
| Detection Method | Wazuh XDR Rule 5712 (8 failed SSH attempts from same source IP within 2 minutes) |

What does each field mean?

  • Incident ID is a unique reference number for tracking this event across your organization.
  • Severity maps directly to the Wazuh alert level. Level 10 is classified as High because it indicates a confirmed pattern of malicious activity, not just a single failed login.
  • Detection Method explains exactly how the XDR system caught the attack. Rule 5712 fires after 8 failed attempts from the same source within 2 minutes.
  • Fill in the Date/Time field using the timestamp from the first Rule 5710 alert you saw in the Wazuh Threat Hunting module.
  • Fill in the Affected Asset with your Ubuntu VM's hostname or IP address.
  • Fill in the Source IP with the attacker IP shown in the alert's data.srcip field.

Finding timestamps in the dashboard

Switch back to the Wazuh dashboard's Threat Hunting module. Click on the earliest Rule 5710 alert to expand its details. The timestamp field at the top of the expanded alert gives you the exact date and time.

Document the timeline and analysis

The timeline section tells the story of the attack in chronological order. Clients and managers read this to understand what happened and when, without needing to look at raw logs themselves.

  • Add the following timeline and analysis sections below your header in incident-report.md:
## Timeline

| Time | Event | Rule ID |
|------|-------|---------|
| [[FIRST_5710_TIME="timestamp of first Rule 5710 alert"]] | First failed SSH login attempt (invalid user "badguy") | 5710 |
| [[SUBSEQUENT_TIMES="timestamps of subsequent 5710 alerts"]] | Continued failed SSH login attempts from same source IP | 5710 |
| [[RULE_5712_TIME="timestamp of Rule 5712 alert"]] | Brute-force detection threshold reached (8 attempts in 2 min) | 5712 |
| [[LAST_ALERT_TIME="timestamp of last alert"]] | Attack ceased (all password attempts exhausted) | 5710 |

## Impact Assessment

- **Authentication outcome**: No successful authentication occurred.
- **Data exposure**: None. The attacker never gained access to the system.
- **Service impact**: SSH service remained available throughout the attack.
- **Detection time**: The brute-force pattern was detected automatically by Wazuh Rule 5712 within 2 minutes of the first failed attempt.

## Root Cause Analysis

- **Primary cause**: SSH service exposed with password authentication enabled.
- **Contributing factor**: No IP-based rate limiting or account lockout configured on the endpoint.
- **Attack vector**: Direct SSH connection over port 22 from the internal network.

Why include impact assessment if nothing was breached?

Confirming that no breach occurred is just as important as documenting one. The impact assessment tells the client they can relax about data exposure while still taking the underlying vulnerability seriously.

The root cause section shifts focus from "what happened" to "why it was possible." This drives the recommendations you will write next.

  • Fill in the timeline timestamps by referencing the alert details in the Wazuh Threat Hunting module.
  • Save incident-report.md.

Your report now documents the full attack story from first contact to detection to cessation.

Write recommendations

Recommendations are the most valuable part of an incident report. They transform a reactive investigation into a proactive improvement plan. Each recommendation should be specific, actionable, and tied back to the root cause or the MITRE ATT&CK technique.

  • Add the following recommendations section at the bottom of incident-report.md:
## Recommendations

### Immediate (0-24 hours)

- Block the source IP at the firewall level to prevent further attempts.
- Review all authentication logs for successful logins from the same source IP to rule out compromise.

### Short-Term (1-7 days)

- Enable Wazuh Active Response to automatically block IPs after brute-force detection (Rule 5712).
- Configure account lockout after 5 failed attempts on the endpoint.
- Restrict SSH access to known IP ranges using firewall rules.

### Long-Term (1-30 days)

- Disable password-based SSH authentication entirely.
- Enforce key-based authentication only for all SSH connections.
- Implement multi-factor authentication (MFA) for SSH access.
- Deploy network-level rate limiting on port 22.

## MITRE ATT&CK Reference

- **Technique**: T1110 - Brute Force
- **Tactic**: Credential Access (TA0006)
- **Description**: Adversary attempted to gain access by systematically trying multiple passwords against the SSH service.
- **Detection rule**: Wazuh Rule 5712 (sshd: brute force trying to get access to the system. Non existent user.)

Why three recommendation tiers?

Tiered recommendations (immediate, short-term, long-term) help clients prioritize their response. The immediate actions stop the bleeding. Short-term actions prevent the same attack from succeeding next time. Long-term actions harden the environment against the entire class of attack described by MITRE ATT&CK T1110.

  • Save incident-report.md.
  • Read through the complete report from top to bottom. Verify that every timestamp, IP address, and rule ID matches what you see in the Wazuh dashboard.

Timestamps don't match?

If the timestamps in your report look inconsistent, return to the Wazuh Threat Hunting module and sort alerts by time (oldest first). The earliest Rule 5710 alert is your start time. The Rule 5712 alert is when detection fired. The last Rule 5710 alert after 5712 is when the attack stopped.

help me match my Wazuh alert timestamps to my incident report timeline

✔️ Awesome, I've got everything!

Great. Double check you have saved your file and that it contains all five sections: Header, Timeline, Impact Assessment, Root Cause Analysis, and Recommendations.

ⓧ I'd like to double check the full report

Here is the complete report template for comparison:

# Incident Report

## Header

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-001 |
| Date/Time | [[FIRST_ALERT_TIME="timestamp of first alert from Wazuh dashboard"]] |
| Severity | High (Level 10) |
| Affected Asset | [[UBUNTU_VM_HOSTNAME="your Ubuntu VM hostname or IP"]] |
| Attack Type | SSH Brute-Force (MITRE ATT&CK T1110 - Credential Access) |
| Source IP | [[WAZUH_SERVER_IP="your Wazuh server IP (the attacker)"]] |
| Detection Method | Wazuh XDR Rule 5712 (8 failed SSH attempts from same source IP within 2 minutes) |

## Timeline

| Time | Event | Rule ID |
|------|-------|---------|
| [[FIRST_5710_TIME="timestamp of first Rule 5710 alert"]] | First failed SSH login attempt (invalid user "badguy") | 5710 |
| [[SUBSEQUENT_TIMES="timestamps of subsequent 5710 alerts"]] | Continued failed SSH login attempts from same source IP | 5710 |
| [[RULE_5712_TIME="timestamp of Rule 5712 alert"]] | Brute-force detection threshold reached (8 attempts in 2 min) | 5712 |
| [[LAST_ALERT_TIME="timestamp of last alert"]] | Attack ceased (all password attempts exhausted) | 5710 |

## Impact Assessment

- **Authentication outcome**: No successful authentication occurred.
- **Data exposure**: None. The attacker never gained access to the system.
- **Service impact**: SSH service remained available throughout the attack.
- **Detection time**: The brute-force pattern was detected automatically by Wazuh Rule 5712 within 2 minutes of the first failed attempt.

## Root Cause Analysis

- **Primary cause**: SSH service exposed with password authentication enabled.
- **Contributing factor**: No IP-based rate limiting or account lockout configured on the endpoint.
- **Attack vector**: Direct SSH connection over port 22 from the internal network.

## Recommendations

### Immediate (0-24 hours)

- Block the source IP at the firewall level to prevent further attempts.
- Review all authentication logs for successful logins from the same source IP to rule out compromise.

### Short-Term (1-7 days)

- Enable Wazuh Active Response to automatically block IPs after brute-force detection (Rule 5712).
- Configure account lockout after 5 failed attempts on the endpoint.
- Restrict SSH access to known IP ranges using firewall rules.

### Long-Term (1-30 days)

- Disable password-based SSH authentication entirely.
- Enforce key-based authentication only for all SSH connections.
- Implement multi-factor authentication (MFA) for SSH access.
- Deploy network-level rate limiting on port 22.

## MITRE ATT&CK Reference

- **Technique**: T1110 - Brute Force
- **Tactic**: Credential Access (TA0006)
- **Description**: Adversary attempted to gain access by systematically trying multiple passwords against the SSH service.
- **Detection rule**: Wazuh Rule 5712 (sshd: brute force trying to get access to the system. Non existent user.)

Secret mission

Custom Rule and Active Response

You have detected a brute-force attack. But detection alone is not enough. In a real SOC environment, the next step is automated response. In this secret mission, you will write a custom Wazuh detection rule with elevated severity and configure active response to automatically block the attacker's IP using firewall-drop.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally in VirtualBox, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Wazuh Server VM (VirtualBox).
  • Ubuntu 22.04 VM (VirtualBox).
  • Downloaded wazuh-4.14.5.ova file on host machine.
  • Incident report file on host machine.

Keep everything running

No action needed. Choose this if you are still actively building or plan to extend the lab (e.g., adding more agents, writing additional custom rules, or testing other attack scenarios).

  • Your Wazuh Server VM and Ubuntu VM will continue running in VirtualBox.
  • The active response firewall-drop rule will remain active, so the Wazuh server IP is still blocked on the Ubuntu VM. To unblock it, wait for the 600-second timeout to expire or restart the Wazuh agent on the Ubuntu VM.
  • Your incident report and the downloaded OVA file remain on your host machine.

Pause - I'll come back to this later

Shut down both VMs to free up RAM and CPU on your host machine. Your VM disks and configurations are preserved for next time.

  • In VirtualBox, right-click the Wazuh Server VM and select Close, then Power Off.
  • Right-click the Ubuntu 22.04 VM and select Close, then Power Off.
  • When you are ready to resume, start both VMs from VirtualBox and verify connectivity with a ping between them.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes your VMs, alert history, custom rules, and active response configuration.

  • In VirtualBox, right-click the Wazuh Server VM and select Remove. When prompted, choose Delete all files to remove the virtual disk.
  • Right-click the Ubuntu 22.04 VM and select Remove. Choose Delete all files again.
  • Delete the downloaded OVA file from your host machine. On macOS/Linux, open a terminal and run:
rm ~/Downloads/wazuh-4.14.5.ova

On Windows, open PowerShell and run:

Remove-Item ~\Downloads\wazuh-4.14.5.ova
  • Delete your incident report file from wherever you saved it on your host machine.

Nice Work!

Nice Work!

You just built a complete SOC threat detection lab from scratch. You now have hands-on experience with the exact security operations lifecycle that enterprise SOC teams follow every day: deploy, monitor, detect, respond, and document.

You learned how to:

  • Deployed a Wazuh XDR server and enrolled a Linux endpoint as a monitored agent using the Wazuh agent enrollment workflow.
  • Simulated a real-world SSH brute-force attack using Hydra and hunted the resulting alerts in the Wazuh Threat Hunting module, correlating them with MITRE ATT&CK technique T1110.
  • Produced a professional, client-facing incident report documenting the full attack timeline, impact assessment, and actionable remediation recommendations.
  • Secret Mission: Wrote a custom detection rule and configured active response to automatically block attacker IPs using firewall-drop in real-time.

Ready to quiz yourself?