Detect a Brute-Force Attack with Wazuh

Deploy a home SOC lab and catch a live brute-force attack using Wazuh SIEM.

Introduction

30 Second Summary

Every time a company detects a hacker trying to break in, there is a Security Operations Center (SOC) analyst behind the scenes investigating the alert. The tool that makes this detection possible is called a SIEM, and it is the most in-demand skill in SOC hiring today.

In this project, you will deploy your own enterprise-grade SIEM on a virtual machine and monitor your Windows laptop as a real endpoint. You will then launch a brute-force attack from Kali Linux and investigate the resulting alerts exactly like a SOC analyst on shift.

What You'll Build

You run a Hydra attack from your Kali VM, switch to the Wazuh dashboard, and watch hundreds of alerts flood in as your SIEM catches every failed login attempt in real time.

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

  • A working SIEM dashboard showing security events from your own Windows machine, with your laptop reporting as a monitored endpoint streaming logs in real time.
  • A detected brute-force attack you launched yourself, generating hundreds of alerts mapped to MITRE ATT&CK technique T1110 that you can walk through from source IP to verdict.
  • A complete SOC analyst investigation where you filter alerts, identify the attacker's IP and targeted account, and close the case as a true positive with no compromise.
  • Secret Mission: write a custom detection rule that triggers on your specific attack pattern and deploy it to your SIEM.

Are there any prerequisites?

You need a Windows laptop with at least 24 GB of RAM, VirtualBox installed, and a Kali Linux VM already set up. You should also be comfortable with basic Linux commands (cd, ls, sudo) and networking fundamentals like IP addresses and ports.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your cybersecurity journey.

Set Up Your Ubuntu Server VM

Your SIEM needs a dedicated host to run its server components. Wazuh bundles an indexer, a manager, and a dashboard into a single deployment. Running all of that on a separate virtual machine keeps it isolated from your Windows host.

In this step, you will create an Ubuntu Server VM in VirtualBox, configure networking so all your lab machines can talk to each other, and then install Wazuh using a single quickstart command.

In this step, get ready to:
  • Create an Ubuntu Server 24.04 VM in VirtualBox with the correct hardware settings.
  • Configure bridged networking so your VMs and Windows host share one network.
  • Install Wazuh via the quickstart script and access the web dashboard.
Download Ubuntu Server and create the VM

You need the Ubuntu Server ISO image to install the operating system inside your new VM.

While the ISO downloads, set up the VM in VirtualBox.

  • Open VirtualBox Manager.
  • Click New in the toolbar to start the Create Virtual Machine wizard.
  • Enter Wazuh-Server as the VM name.
  • Set the Type to Linux and Version to Ubuntu (64-bit).
  • Set Base Memory to 4096 MB (4 GB RAM).
  • Set Processors to 2 CPU cores.
  • On the Virtual Hard Disk page, select Create a Virtual Hard Disk Now and set the disk size to 50 GB. Leave the Pre-Allocate Full Size option unchecked (this creates a dynamically allocated disk).
  • Click Finish to create the VM.

Your new VM appears in the VirtualBox Manager list on the left. Now attach the Ubuntu ISO so the VM can boot from it.

  • Select Wazuh-Server in the list, then click Settings.
  • Go to Storage.
  • Under Controller: IDE, click the empty disk icon.
  • On the right side, click the small disk icon next to Optical Drive and select Choose a disk file.
  • Navigate to and select the ubuntu-24.04.4-live-server-amd64.iso file you downloaded.
  • Click OK to close settings.
  • Click Start to boot the VM.

What happens when the VM boots?

The Ubuntu Server installer launches as a text-based interface. You navigate it using the arrow keys, Tab, and Enter. There is no graphical desktop.

The installer walks you through several prompts. Accept defaults on these initial screens:

  • Select your language (English) and press Enter.
  • If prompted to update the installer, select Continue without updating.
  • Accept the default keyboard layout and select Done.
  • On the network screen, accept the defaults (the installer auto-configures via DHCP) and select Done.
  • On the proxy and mirror screens, leave them empty and select Done on each.
  • For storage, leave Use an entire disk checked, select Done, then confirm the destructive action.

The next screens require your own information and one critical selection.

  • On the Profile screen, enter a username, server name (e.g. wazuh-server), and a password you will remember.
  • On the SSH screen, press the spacebar to check Install OpenSSH server, then select Done.
  • On the Snaps screen, select Done without selecting any snaps.
  • Wait for the installation to complete, then select Reboot Now.

Remove the ISO before reboot

If the VM tries to boot from the ISO again after reboot, power off the VM, go to Settings > Storage, remove the ISO from the optical drive, and start the VM again.

After the VM reboots, you see a login prompt. Log in with the username and password you set during installation.

  • Confirm your VM has network access by running:
ip addr show

You see one or more network interfaces listed with IP addresses. Note the IP address on the enp0s3 interface (it looks something like 10.0.2.15). This is your VM's current IP. It will change once you switch to bridged networking in the next substep.

Don't see an IP address?

If your interface shows no IP, the DHCP assignment may have failed. Try running sudo dhclient and then ip addr show again.

Help me troubleshoot my VM's network connection.

Configure bridged networking

Right now, VirtualBox defaults to NAT networking. Your Windows host cannot reach the VM directly on NAT. Switching to a Bridged Adapter places the VM on the same local network as your host and your Kali VM, so all machines can communicate.

  • Shut down the Ubuntu VM by running:
sudo shutdown now
  • In VirtualBox Manager, select Wazuh-Server and click Settings.
  • Go to Network.
  • Under Adapter 1, change Attached to from NAT to Bridged Adapter.
  • In the Name dropdown, select your Windows host's active network adapter (typically your Wi-Fi or Ethernet adapter).
  • Click OK.
  • Click Start to boot the VM again.
  • Log in and check your new bridged IP address by running:
ip addr show

This time, your enp0s3 interface shows an IP on your home network (something like 192.168.1.x or 10.0.0.x). Write this IP down. You will use it for the rest of the project.

  • Open Command Prompt on your Windows host.
  • Confirm your Windows machine can reach the VM by running:
ping [[VM_IP="your Ubuntu VM's IP address"]]

You should see reply packets coming back. This confirms your Windows host and the Ubuntu VM are on the same network.

Ping times out or shows no reply?

Make sure you selected the correct host adapter under Bridged Adapter > Name. If you are on Wi-Fi, select your wireless adapter.

Also confirm the VM booted fully and got a DHCP lease (check ip addr show shows an IP that matches your home network range).

Help me fix my bridged network connection.

Install Wazuh via the quickstart script

Now that your Windows host can reach the VM, you can work more comfortably over SSH instead of the small VirtualBox console window. SSH lets you copy and paste commands directly.

  • On your Windows machine, open Command Prompt or PowerShell and connect to your VM by running:
ssh [[UBUNTU_USER="your Ubuntu username"]]@[[VM_IP="your Ubuntu VM's IP address"]]
  • When prompted, type yes to accept the host fingerprint.
  • Enter your Ubuntu password.

You are now logged into your Ubuntu VM remotely from Windows. You should see a terminal prompt with your username and hostname.

  • Update the system packages by running:
sudo apt update && sudo apt upgrade -y

This downloads and installs the latest security patches. It takes a minute or two depending on your internet speed.

Why update before installing Wazuh?

Running system updates first ensures your package lists are current and dependencies resolve cleanly. Wazuh's installer expects an up-to-date system.

  • Install Wazuh using the quickstart script by running:
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

What does this command do?

The curl -sO part downloads the Wazuh install script silently. The sudo bash ./wazuh-install.sh -a part runs it with the -a flag, which tells it to install all components on a single host: the Wazuh indexer, the Wazuh manager, and the Wazuh dashboard.

This takes 5 to 15 minutes depending on your hardware and internet speed. Let it run to completion without interrupting.

Do not close this terminal window

The installer prints the admin credentials at the very end of its output. If you close the terminal before copying them, you will need to reset the password manually. Keep the terminal open and scroll up after it finishes.

When the installer finishes, it prints output containing:

  • The username admin.
  • A generated password.
  • The URL https://<your-VM-IP> where the dashboard is accessible.
  • Copy the admin password and save it somewhere safe (you will use it shortly).

Installer fails or hangs?

If the installer fails with memory errors, your VM may not have enough RAM allocated. Shut down the VM, increase RAM to 4 GB in VirtualBox settings, and try again.

If it fails with network errors, confirm your VM can reach the internet by running ping google.com. If that fails, check your bridged adapter is connected to an active network interface.

Help me fix the Wazuh installer.

Before you open the dashboard, what do you expect to see when you visit that URL in your browser?

  • On your Windows machine, open a web browser.
  • Navigate to https:// followed by your VM's IP address (the one from ip addr show earlier).
  • You will see a certificate warning because Wazuh uses a self-signed certificate. Click Advanced and then Proceed (or Accept the Risk depending on your browser).
  • Enter admin as the username and paste the password from the installer output.
  • Click Log In.

You see the Wazuh dashboard loaded in your browser. This confirms the indexer, manager, and dashboard are all running correctly on your Ubuntu VM.

Your SIEM is live. Next up, you will explore the dashboard to understand how alerts, agents, and rules fit together before connecting any endpoints.

Explore the SIEM Dashboard

Your Wazuh server is live and the dashboard is waiting for you. Before you start enrolling endpoints and generating alerts, you need to understand what you are looking at.

A SIEM dashboard without context is just noise. This step is where you build the mental model of how agents, alerts, and rules fit together so you can read the signals when a real attack lands.

In this step, get ready to:
  • Navigate the dashboard sections to understand where agents, alerts, and raw events live.
  • Explore the built-in detection rules and identify the ones that will catch brute-force attacks later.
Navigate the main dashboard sections

The Wazuh dashboard organizes security data into distinct sections. You need to know three of them before moving forward.

  • Switch to the browser window where you logged into the Wazuh dashboard at the end of the last step.
  • In the left-hand navigation menu, click Agents management, then click Summary.
  • Confirm that the Agents page shows 0 connected agents. This is expected because you have not enrolled any endpoints yet.

What is Agents management?

This section shows all the endpoints (servers, laptops, workstations) reporting into your SIEM. Each enrolled machine appears here with its status, OS, and last check-in time.

Right now it is empty because only the Wazuh server itself exists. In the next step you will enroll your Windows laptop, and it will appear here as an active agent.

  • In the left-hand navigation menu, find the Endpoint security section and click Threat Hunting.
  • Observe the Threat Hunting module. This is where security alerts appear when something suspicious happens on a monitored endpoint. You may already see a handful of system-level events generated by the Wazuh server monitoring itself.

Why does the server generate its own events?

Wazuh monitors itself. The server agent (agent ID 000) tracks its own processes, file changes, and authentication attempts. These system-level events prove the pipeline is working end to end before you even enroll another machine.

  • Look for Security events in the navigation menu and click it.
  • This is the raw log feed. Every event collected from every endpoint appears here before any rule processing. Threat Hunting shows you filtered, rule-matched alerts. Security events shows you everything.
Check the built-in detection rules

Wazuh ships with over 3,000 pre-built detection rules mapped to the MITRE ATT&CK framework. These rules detect common attack patterns without you configuring anything.

  • In the left-hand navigation menu, expand Management and click Rules.
  • In the search bar at the top of the Rules page, type brute force and press Enter.

Before you look at the results, take a moment. How many rules do you think Wazuh has specifically for brute-force detection?

  • Review the search results. You should see multiple rules listed with descriptions and severity levels.
  • Find rule ID 5712. Its description reads something like "SSHD brute force trying to get access to the system." This rule detects SSH brute-force attacks on Linux endpoints.
  • Find rule ID 5551. This is another SSH-related brute-force rule that catches repeated authentication failures.
  • Find rule ID 60122. This one detects Windows logon failures. It is the rule that will fire when you attack your Windows machine's RDP service later in this project.

What do these rule IDs mean for your project?

Rule 5551 and 5712 detect SSH brute-force attacks on Linux. Rule 60122 detects Windows logon failures (Event ID 4625). When you launch your attack from Kali later, these rules fire automatically and generate alerts in the Threat Hunting module.

Each rule is also mapped to a MITRE ATT&CK technique. Rule 5712 maps to T1110 (Brute Force). This means when it fires, the alert carries that technique tag. This is how SOC analysts quickly classify what kind of attack they are looking at.

What is MITRE ATT&CK?

MITRE ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques. Every known attack pattern gets a unique ID (like T1110 for Brute Force).

Security tools like Wazuh map their detection rules to these IDs so analysts can speak a common language when discussing threats. You will see this mapping in action when you triage alerts in Step 5.

You have now confirmed that Wazuh has the detection rules ready to catch the brute-force attack you will launch in Step 4. The Agents page shows 0 connected agents, which is the gap you close in the next step.

Can't find the Rules section?

The Rules section lives under the management area of the left navigation. If your side menu is collapsed, click the hamburger icon (three horizontal lines) in the top left to expand it. Look for a section related to management, then click Rules.

If searching for "brute force" returns no results, make sure you are in the Rules section and not Threat Hunting. The search in Threat Hunting filters alerts, while the search in Rules filters rule definitions.

Help me find the brute force rules in Wazuh

Your SIEM is installed, you know where alerts show up, and you have confirmed the detection rules are ready. Next up, you will enroll your Windows laptop as a monitored endpoint so those rules have real data to work with.

Enroll Your Windows Machine as a Monitored Endpoint

In the last step, you explored the Wazuh dashboard and saw 3,000+ detection rules ready to fire. But right now, those rules have nothing to monitor.

A SIEM without endpoints is like a security camera pointed at an empty room. In this step, you will enroll your Windows laptop as a monitored endpoint so its authentication logs, process events, and security data flow into Wazuh in real time.

In this step, get ready to:
  • Enable Remote Desktop on your Windows machine so it can receive RDP login attempts.
  • Install the Wazuh agent on Windows and connect it to your SIEM server.
  • Confirm your machine appears as an active endpoint streaming security events.
Enable RDP and note your Windows IP address

Later in this project, you will launch a brute-force attack against your Windows machine's RDP service. For that attack to generate detectable login events, Remote Desktop needs to be turned on first.

  • Press the Windows key to open your search bar.
  • Type Remote Desktop settings and press Enter.
  • Toggle Remote Desktop to On.
  • Click Confirm in the pop-up dialog.

Don't see the Remote Desktop toggle?

Remote Desktop is only available on Windows Pro and Enterprise editions. If you are on Windows Home, this feature is not available in Settings. You can upgrade to Windows Pro through Settings > System > Activation, or check if your machine already has Pro by searching for winver in the Start menu.

help me figure out if my Windows edition supports RDP

Now you need to find your Windows machine's IP address on the local network. Your Kali VM will use this IP to target the attack later.

  • Open a Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
  • Find your local IP address by running this command:
ipconfig
  • Look for the IPv4 Address under your active network adapter (usually Ethernet adapter or Wireless LAN adapter Wi-Fi). It looks something like 192.168.1.x or 10.0.0.x.
  • Write this IP address down. You will need it in the next step when launching the attack from Kali.

How do I know which adapter to look at?

You want the adapter that connects you to the same network as your VMs. Since you set VirtualBox to Bridged Adapter, all your machines share the same network. Pick the adapter that shows a Default Gateway (usually your router's IP like 192.168.1.1).

Install the Wazuh agent on Windows

The Wazuh agent is a lightweight service that collects security events from your machine and sends them to the SIEM server. Once installed, every login attempt, process start, and system change gets forwarded for analysis.

  • Download the Wazuh agent installer from this link: wazuh-agent-4.14.7-1.msi.
  • Save the file to your Downloads folder (the default location).

Now you need to run the installer from an Administrator PowerShell so it can register with your Wazuh server.

  • Press the Windows key, type PowerShell, right-click Windows PowerShell, and select Run as administrator.
  • Click Yes on the User Account Control prompt.
  • Navigate to your Downloads folder by running this command:
cd ~\Downloads
  • Install the Wazuh agent and point it to your Ubuntu VM by running this command:
msiexec.exe /i .\wazuh-agent-4.14.7-1.msi /q WAZUH_MANAGER="[[UBUNTU_VM_IP="your Ubuntu VM IP address"]]"

What does this command do?

  • msiexec.exe /i tells Windows to install the specified MSI package.
  • /q runs the install silently (no wizard pop-ups).
  • WAZUH_MANAGER tells the agent where to find your Wazuh server. This is the IP address of your Ubuntu VM.
  • Start the Wazuh agent service by running this command:
NET START WazuhSvc

You should see a message confirming the service started successfully.

Seeing 'Access is denied' or the service won't start?

  • Make sure you opened PowerShell as Administrator (the title bar should say Administrator: Windows PowerShell).
  • If you see a message that the service name is not valid, confirm the MSI installed correctly by checking that C:\Program Files (x86)\ossec-agent exists.
  • Double-check that the IP address you used for WAZUH_MANAGER matches your Ubuntu VM's IP (the one you SSH into).

help me troubleshoot my Wazuh agent installation on Windows

Confirm enrollment in the Wazuh dashboard

The agent is running, but you need to confirm the SIEM actually sees it. This is the same check a SOC team runs after deploying an agent to a new corporate laptop.

  • Switch back to the Wazuh dashboard in your browser.
  • Click Agents management in the left sidebar.
  • Click Summary.

How long does enrollment take?

The agent typically appears within 1-2 minutes of starting the service. If you do not see it immediately, wait a moment and refresh the page.

Before you check the result, what do you expect to see on the Agents page now that your agent service is running?

  • Refresh the Summary page. You should see 1 active agent listed with your Windows computer's hostname.
  • Click on your agent's name to open its details.

You should see recent security events already streaming in from your Windows machine. These are real Windows Event Log entries being collected in real time.

Agent not appearing after 2 minutes?

  • Verify the agent service is running. In your Administrator PowerShell, run Get-Service WazuhSvc and confirm the status shows Running.
  • Confirm your Windows machine can reach the Ubuntu VM. Run ping followed by your Ubuntu VM's IP in Command Prompt.
  • If the ping fails, check that both machines are on the same network (Bridged Adapter in VirtualBox) and the VM is powered on.

help me figure out why my Wazuh agent isn't connecting to the server

Your Windows laptop is now a monitored endpoint. Every login attempt, service change, and security event flows into your SIEM. Next up, you will put this monitoring to the test by launching a real brute-force attack from Kali.

Launch a Brute-Force Attack from Kali

Your SIEM is watching your Windows machine, but so far nothing malicious has happened. The Threat Hunting module sits empty because there is nothing to hunt.

Time to change that. You will deliberately create the exact problem a SOC analyst faces on shift: a flood of authentication failures from an attacker trying to guess passwords. This is where the SIEM proves its value.

In this step, get ready to:
  • Configure your Kali VM networking so it can reach your Windows machine.
  • Launch a brute-force attack against Windows RDP using Hydra.
  • Observe the resulting alerts flood into the Wazuh Threat Hunting module.
Configure your Kali VM networking

Your Kali VM needs to sit on the same network as your Windows laptop so Hydra can reach the RDP port. You will set the adapter to Bridged mode, just like you did for the Ubuntu VM.

  • In VirtualBox, select your Kali Linux VM (do not boot it yet).
  • Click Settings at the top.
  • Go to Network.
  • Set Attached to to Bridged Adapter.
  • Click OK and boot your Kali VM.

Once Kali finishes booting and you are logged in, confirm it can reach your Windows machine by running this command in the Kali terminal:

ping [[WINDOWS_IP="your Windows IP address"]]
  • You should see replies coming back from your Windows IP. Press Ctrl+C to stop the ping after a few replies.

Why Bridged Adapter?

Bridged Adapter puts the VM directly on your home network, giving it a real IP address on the same subnet as your Windows laptop. This means all three machines (Windows, Ubuntu, Kali) can communicate without extra routing configuration.

Not getting replies?

Make sure you selected the correct physical network adapter in the Name dropdown under Bridged Adapter (choose your active Wi-Fi or Ethernet adapter).

Also confirm Windows Firewall allows ICMP (ping) traffic. If pings are blocked but RDP works, you can proceed. Test RDP connectivity directly with nmap -p 3389 <your Windows IP> instead.

Need more help? Help me troubleshoot my Kali VM networking in VirtualBox

Create a password list and launch the attack

Hydra is a password-cracking tool that comes pre-installed on Kali Linux. It works by trying a list of passwords against a target service, one by one.

  • Create a file containing 10 fake passwords by running this command in your Kali terminal:
echo -e "password1\n123456\nletmein\nadmin\nqwerty\npassword123\niloveyou\nwelcome\nmonkey\ndragon" > passwords.txt
  • Confirm the file was created by running:
cat passwords.txt

You should see all 10 passwords listed, one per line.

What is this password list?

In a real attack, threat actors use wordlists containing thousands (or millions) of common passwords. Your list has just 10 entries so the attack finishes quickly while still generating enough failed login events for the SIEM to detect.

Now launch the brute-force attack against your Windows RDP service by running:

hydra -l badguy -P passwords.txt rdp://[[WINDOWS_IP="your Windows IP address"]] -t 1

What does this command do?

  • -l badguy sets the username Hydra tries to log in with. This is a fake account that does not exist on your machine.
  • -P passwords.txt points Hydra to your password list.
  • rdp:// tells Hydra to attack the RDP service on your Windows machine.
  • -t 1 limits Hydra to a single thread. This is required for RDP because multiple simultaneous threads break RDP authentication.

You will see Hydra attempt each password one at a time. Every attempt will fail because the account "badguy" does not exist on your Windows machine. Each failure generates a Windows Event ID 4625 (failed logon) that your Wazuh agent captures.

Hydra not connecting?

If Hydra reports connection errors, confirm RDP is still enabled on your Windows machine (Settings > System > Remote Desktop > toggle should be On).

Also verify your Windows Firewall allows inbound RDP on port 3389. If you changed your Windows IP, use the updated address.

Still stuck? Help me troubleshoot Hydra RDP connection issues

Watch the alerts fire in real time

Every failed RDP login from Kali generates a Windows Event ID 4625 that your Wazuh agent streams to the server. Wazuh correlates these events against its built-in rules and fires alerts.

Before you check the dashboard, what do you think you will see in the Threat Hunting module? How many alerts do you expect from 10 password attempts?

  • Switch back to the Wazuh dashboard in your Windows browser.
  • Click Threat Hunting in the left navigation menu.
  • In the search bar at the top, type this filter and press Enter:
rule.id:(60122 OR 60204)

You should see multiple alerts listed, each one corresponding to a failed RDP login attempt from your Kali machine. The source IP in each alert matches your Kali VM's address.

What are rules 60122 and 60204?

Rule 60122 detects a Windows logon failure event. Rule 60204 triggers when multiple logon failures indicate a brute-force pattern. Both are pre-built Wazuh rules mapped to MITRE ATT&CK technique T1110 (Brute Force).

Not seeing any alerts?

Alerts can take 1-2 minutes to appear after the attack completes. Click the refresh icon in the Threat Hunting module and wait a moment.

If no alerts appear after 2 minutes, confirm your Wazuh agent is still active. Go to Agents management and check that your Windows agent shows Active status.

Still no alerts? Help me figure out why Wazuh is not showing brute-force alerts

Your SIEM just proved it works. A flood of failed login attempts triggered real alerts without you configuring a single detection rule. Next up, you will triage and investigate these alerts exactly like a SOC analyst on shift.

Triage and Investigate the Alerts Like a SOC Analyst

Your attack worked. The Wazuh dashboard is lit up with alerts from the brute-force attempt you just launched from Kali.

But detecting an attack is only half the job. A SOC analyst must triage those alerts, investigate the details (who, what, when, where), and document findings. This is the skill employers actually test for in interviews.

In this step, get ready to:
  • Filter alerts using a rule ID query to isolate brute-force activity from the noise.
  • Investigate individual alert details to identify the attacker, target, and MITRE ATT&CK technique.
  • Determine a verdict and document findings like a real incident report.
Filter and triage the brute-force alerts

Right now, the Threat Hunting module is showing a mix of all security events from your Windows agent. You need to filter down to only the brute-force alerts so you can focus your investigation.

  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Threat Hunting in the left sidebar (if you are not already there).
  • Click the search bar at the top of the events list.
  • Type the following filter and press Enter:
rule.id:(60122 OR 60204)

What does this filter do?

This query tells Wazuh to show only alerts triggered by rule 60122 (Windows logon failure) and rule 60204 (multiple Windows logon failures). These are the built-in detection rules that fire on failed RDP authentication attempts.

Everything else (system events, agent check-ins, configuration changes) disappears, leaving only the brute-force activity.

The list now shows only alerts from your attack. Take a moment to count how many alerts fired.

  • Click on any single alert row to expand its details.
  • In the expanded view, identify these five fields:
  • Source IP - this is your Kali machine's IP address.
  • Target account - the username the attacker tried, which is badguy.
  • Windows Event ID - 4625 (failed logon attempt).
  • Timestamp - when the attempt occurred.
  • Rule description - a human-readable summary of what triggered the alert.

What is Event ID 4625?

Windows logs a 4625 event every time someone fails to authenticate. Each failed password attempt from Hydra generated one of these events. The Wazuh agent on your Windows machine captured every single one and forwarded it to the SIEM.

Not seeing any alerts after filtering?

Make sure you typed the filter exactly as shown, including the parentheses and the word OR in uppercase. The filter is case-sensitive.

Also check the time range in the top-right corner of the dashboard. If it is set to "Last 15 minutes" and your attack was longer ago, expand it to "Last 1 hour" or "Today".

help me troubleshoot why my brute-force alerts are not showing in the Wazuh Threat Hunting module after filtering by rule.id:(60122 OR 60204)

Map the attack to MITRE ATT&CK

You have identified the source and target of the attack. Now you need to classify it using the industry standard framework that SOC teams worldwide use to categorize adversary behaviour.

  • In the expanded alert details, look for the MITRE ATT&CK section.
  • You will see the technique ID T1110 listed, which maps to Brute Force.
  • Note the tactic category as well. This falls under Credential Access in the MITRE ATT&CK framework.

What is MITRE ATT&CK T1110?

MITRE ATT&CK is a globally recognised knowledge base of adversary tactics and techniques. T1110 (Brute Force) describes attacks where an adversary tries many passwords to guess valid credentials.

Wazuh automatically maps its detection rules to the relevant MITRE technique. This means you do not have to manually look up the classification. The SIEM does that work for you.

This is exactly how you would document the finding in an incident report: "Brute-force attempt detected from [source IP] targeting [account] at [time], mapped to MITRE ATT&CK T1110."

Where does the MITRE data come from?

Each Wazuh rule can include a <mitre> block in its XML definition that specifies the relevant technique ID. When the rule fires, the alert inherits that mapping. You can see this in the JSON view of any alert under the rule.mitre field.

Determine the verdict

Detection and classification are complete. The final step in the SOC analyst workflow is to determine a verdict: is this a true positive (real attack) or a false positive (harmless activity that looks suspicious)?

The key question is: did the attacker actually get in? A failed brute-force is serious but contained. A successful one is a full compromise.

  • Clear the current filter in the search bar.
  • Search for Event ID 4624 (successful logon) from the same source IP by looking for alerts that show your Kali IP and a successful authentication event.

Before you check the results, pause and predict: do you think any login attempt succeeded? Remember, Hydra tried 10 fake passwords against a non-existent account.

  • Check the results. You should find zero Event ID 4624 entries from your Kali IP address.

No successful logons from the attacker IP. The attack was detected and contained.

How would you document this verdict?

As a SOC analyst, you would close this alert with the following finding:

  • Verdict: True positive - confirmed brute-force attempt.
  • Source: Kali VM IP address.
  • Target: account badguy on Windows endpoint.
  • Technique: MITRE ATT&CK T1110 (Brute Force).
  • Event: Windows Event ID 4625 (failed logon).
  • Outcome: No successful logon (Event ID 4624) from attacker IP. No compromise.

This is the exact workflow a Tier 1 SOC analyst performs on every shift.

You have now completed the full investigation lifecycle: detect, triage, investigate, classify, and verdict.

Secret mission

Write a Custom Detection Rule

Wazuh's built-in rules detected your attack, but real SOC teams write custom rules tuned to their environment. Can you write a detection rule that triggers specifically on 5+ RDP failures from the same source IP within 60 seconds?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs. The main consideration is RAM usage when your VMs are running.

Resources you used:

  • Ubuntu Server VM (Wazuh-Server) in VirtualBox. Running locally, no cost.
  • Wazuh agent service on your Windows laptop. Lightweight background service.
  • Remote Desktop enabled on Windows. This was turned on for the attack simulation.
  • Kali Linux VM. Already existed before this project.

Keep everything running

No action needed. Choose this if you are still actively building or want to continue practising SOC analyst workflows.

  • Your Wazuh-Server VM uses approximately 2-3 GB RAM when idle. Stop it from VirtualBox when you are not using it to reclaim memory.
  • The Wazuh agent on Windows is lightweight and runs quietly in the background.
  • Remote Desktop remains enabled on your Windows machine. Be aware this is an open attack surface on your network.
  • Your Kali VM is unchanged from before the project.

Pause - I'll come back to this later

Shut down your VMs to free up memory while keeping everything intact for later.

  • In VirtualBox, right-click the Wazuh-Server VM and select Close > Power Off.
  • The Wazuh agent on Windows will queue events locally. When you start the Ubuntu VM again, the agent reconnects and syncs automatically.
  • Consider disabling Remote Desktop while paused. Open Settings > System > Remote Desktop and toggle it to Off.

Delete - I don't want to use this again

Remove all project resources completely and start fresh.

  • Uninstall the Wazuh agent from Windows. Open an Administrator PowerShell and run the command below.
msiexec.exe /x wazuh-agent-4.14.7-1.msi /qn
  • Delete the Ubuntu Server VM. In VirtualBox, right-click the Wazuh-Server VM, select Remove, then click Delete all files in the confirmation dialog. This permanently removes the VM and its virtual disk.
  • Disable Remote Desktop on Windows. Open Settings > System > Remote Desktop and toggle it to Off. Click Confirm when prompted.
  • Delete the password list on Kali. Open a terminal in your Kali VM and run:
rm ~/passwords.txt
  • Your Kali Linux VM existed before this project and is unaffected. No action needed there.

Nice Work!

Nice Work!

You just built a fully functional home SOC lab from scratch. You deployed an enterprise-grade SIEM, monitored your own machine, launched a real attack, and investigated the alerts exactly like a SOC analyst on shift.

You've learned how to:

  • Deploy a Wazuh SIEM on an Ubuntu Server VM and enroll your Windows laptop as a monitored endpoint streaming security events in real time.
  • Launch a brute-force attack from Kali Linux using Hydra against Windows RDP and watch hundreds of alerts fire in the Threat Hunting module.
  • Triage and investigate alerts like a SOC analyst, mapping the attack to MITRE ATT&CK technique T1110 (Brute Force), identifying the source IP and target account, and determining a verdict.
  • Secret Mission: Wrote a custom detection rule that triggers on 5+ RDP failures from the same source IP within 60 seconds, deployed it to the Wazuh server, and verified it fires on a live attack.

Ready to quiz yourself?