Build a SOC Home Lab with Wazuh

Deploy a full Wazuh SIEM stack, simulate attacks, and write custom detection rules.

Introduction

30 Second Summary

Every time you log in to an app, download a file, or connect to Wi-Fi, your devices generate events that security teams monitor for threats. The tool they use to collect, analyze, and alert on these events is called a SIEM (Security Information and Event Management).

In this project, you will build a complete SOC home lab by deploying Wazuh SIEM on your Windows machine using Docker. You will simulate a brute-force attack, triage the alerts it generates, and write your own custom detection rule.

What You'll Build

A fully functional Wazuh SIEM stack (Manager, Indexer, and Dashboard) running locally via Docker, with a connected agent monitoring your Windows host for real-time threat detection.

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

A running Wazuh SIEM deployment with Manager, Indexer, and Dashboard containers communicating securely.
Detected and triaged a simulated brute-force attack with alerts mapped to MITRE ATT&CK technique T1110.
Authored a custom detection rule and validated it fires correctly in the Wazuh dashboard.
Secret Mission: Enable File Integrity Monitoring and write a rule that alerts when critical files are modified.

Are there any prerequisites?

You need a Windows machine with at least 16 GB of RAM and familiarity with the command line. Basic networking concepts (IP addresses, ports) and comfort reading simple scripts will help you move through the project smoothly.

Install WSL 2 and Docker Desktop

The Wazuh SIEM stack runs as a set of Docker containers. Docker Desktop on Windows requires WSL 2 (Windows Subsystem for Linux) as its backend engine to run Linux containers.

In this step, you will install WSL 2 with the Ubuntu distribution, install Docker Desktop with the WSL 2 backend, and confirm both are ready for the Wazuh deployment.

In this step, get ready to:

Install WSL 2 with the Ubuntu distribution.
Install Docker Desktop with the WSL 2 backend enabled.
Verify both tools are running correctly.

Enable WSL 2 on your Windows machine

WSL 2 lets you run a full Linux environment directly on Windows without a separate virtual machine. Docker Desktop uses this Linux environment to run containers.

Press the Windows key to open your search bar.
Type PowerShell.
Right-click Windows PowerShell and select Run as administrator.
If a User Account Control prompt appears, click Yes to allow it.

Check whether WSL is already installed by running this command:

wsl --version

✔️ I see version 2.1.5 or later

Your WSL version meets the minimum requirement for Docker Desktop. You can move on to the next substep.

⨯ I see an older version

Your WSL is installed but outdated. Update it to the latest version by running this command:

wsl --update

After the update completes, run wsl --version again to confirm you now see version 2.1.5 or later.
If prompted to restart your computer, do so and then re-open PowerShell as Administrator.

⨯ Command not found

WSL is not installed on your machine yet. Install it by running this command:

wsl --install

What does this command do?

This single command enables the WSL feature, downloads and installs the latest WSL kernel, and installs the default Ubuntu distribution. It sets WSL 2 as the default version automatically.

When the installation finishes, restart your computer as prompted.
After restarting, an Ubuntu terminal window may open asking you to create a Linux username and password. Enter any username and password you like. These are local to your Linux environment.
Once set up, close the Ubuntu window and re-open PowerShell as Administrator.
Run wsl --version to confirm you see version 2.1.5 or later.

What is WSL 2?

WSL 2 runs a real Linux kernel inside a lightweight virtual machine managed by Windows. This gives you full compatibility with Linux tools and commands directly on your Windows machine.

Docker Desktop uses this Linux kernel to run containers. Without WSL 2, Docker cannot function on Windows Home editions.

Still seeing an error after running wsl --install?

Make sure hardware virtualization is enabled in your BIOS/UEFI settings. Most modern machines have it enabled by default, but some require you to toggle it manually.

You can check by opening Task Manager, going to the Performance tab, and looking for Virtualization: Enabled at the bottom.

Help me troubleshoot WSL installation errors on Windows.

Download and install Docker Desktop

Docker Desktop provides the container engine that will run your entire Wazuh SIEM stack. It uses the WSL 2 backend you just set up to manage Linux containers.

Open your web browser and go to the Docker Desktop download page:
https://docs.docker.com/desktop/setup/install/windows-install/
Click the download button to get the Docker Desktop installer.
Run the downloaded Docker Desktop Installer.exe file.
When the installer prompts you for configuration, ensure the Use WSL 2 instead of Hyper-V option is selected.
Complete the installation and restart your computer if prompted.

After your computer restarts, launch Docker Desktop.
Press the Windows key, type Docker Desktop, and press Enter.
Wait for Docker Desktop to fully start. The whale icon in your system tray (bottom-right corner) will stop animating when it is ready.
If Docker Desktop shows a service agreement, accept it to continue.

Is Docker Desktop free?

Docker Desktop is free for personal use, education, open source, and small businesses. Since you are using it for personal learning, no paid subscription is required.

Docker Desktop won't start?

Make sure WSL 2 is fully installed and working before launching Docker Desktop. Run wsl --version in PowerShell to confirm.

If you see an error mentioning virtualization, ensure hardware virtualization is enabled in your BIOS settings and that the hypervisor is enabled at Windows startup.

Help me get Docker Desktop running on Windows with WSL 2.

Verify Docker is working

With Docker Desktop running, you need to confirm that the Docker command-line tools are accessible from PowerShell.

Open a new PowerShell window (it does not need to be Administrator this time).
Check the Docker version by running this command:

docker --version

Check the Docker Compose version by running this command:

docker compose version

✔️ Both commands return version numbers

Docker is installed and working correctly. Both docker --version and docker compose version returned version information without errors.

You are ready to deploy the Wazuh stack in the next step.

⨯ Command not found or error

If PowerShell does not recognize docker, try these fixes:

Make sure Docker Desktop is running. Look for the whale icon in your system tray.
Close your PowerShell window and open a new one. Docker adds itself to your system PATH during installation, but existing terminals need to be restarted to pick it up.
If you just installed Docker Desktop, try restarting your computer and launching Docker Desktop again before opening PowerShell.

Help me troubleshoot Docker not being recognized in PowerShell.

Why both commands?

The docker command runs individual containers. The docker compose command orchestrates multiple containers together from a single configuration file.

You will use docker compose to start the entire Wazuh stack (Manager, Indexer, and Dashboard) as one unit.

Your development environment is ready. Next up, you will deploy the full Wazuh SIEM stack using Docker containers.

Deploy the Wazuh SIEM Stack

Your Windows machine now has WSL 2 and Docker Desktop ready to go. The next goal is to deploy the full Wazuh SIEM stack, which consists of three components that work together: a Manager, an Indexer, and a Dashboard.

Getting three separate services to communicate securely could be complex. The Wazuh team provides a Docker Compose configuration that handles all the networking and encryption for you. You'll have a production-style SIEM running in minutes.

In this step, get ready to:

Set the required kernel parameter and clone the Wazuh repository.
Generate SSL certificates and start the SIEM containers.
Verify the deployment through the Wazuh dashboard.

Open WSL and configure the kernel parameter

The Wazuh Indexer is built on OpenSearch, which requires a specific Linux kernel setting to handle memory-mapped files. Without this setting, the Indexer container will crash on startup.

Switch back to your PowerShell window and enter WSL by running this command:

wsl

Your terminal prompt changes to a Linux-style prompt, confirming you're now inside your Ubuntu environment.

Set the required kernel parameter for the Wazuh Indexer by running:

sudo sysctl -w vm.max_map_count=262144

You should see vm.max_map_count = 262144 printed back, confirming the change took effect.

What is vm.max_map_count?

This setting controls how many memory-mapped areas a process can use. The Wazuh Indexer needs a large number of these areas to manage its search indexes efficiently.

The default value (65530) is too low and causes the Indexer to fail immediately on startup. Setting it to 262144 gives the Indexer the memory space it needs.

Permission denied?

If you see a permission error, make sure you included sudo at the start of the command. WSL will prompt you for your Linux user password the first time you use sudo in a session.

Help me fix a permission error when setting vm.max_map_count in WSL

Clone the Wazuh Docker repository

Wazuh provides an official Docker repository with pre-configured Compose files for deploying the full stack. You'll clone a specific version tag to ensure a stable deployment.

Navigate to your home directory and clone the Wazuh Docker repository by running these commands:

cd ~
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.5
cd wazuh-docker/single-node/

What do these commands do?

cd ~ moves you to your Linux home directory so the repository lands in a predictable location.

git clone ... -b v4.14.5 downloads the Wazuh Docker configuration pinned to version 4.14.5. The -b flag checks out that specific release tag.

cd wazuh-docker/single-node/ moves into the single-node deployment directory, which contains the Compose file for a standalone setup.

Confirm the clone succeeded by running:

ls

You should see files including docker-compose.yml and generate-indexer-certs.yml in the output.

Git clone failed?

Make sure Docker Desktop is still running. If you see a network error, check your internet connection and try the clone command again.

If you see git: command not found, install Git inside WSL by running sudo apt update && sudo apt install git -y, then retry the clone.

Help me fix a git clone error in WSL for the Wazuh Docker repository

Generate certificates and start the stack

The Wazuh components communicate over encrypted TLS connections. Before starting the stack, you need to generate the SSL certificates that each component uses to authenticate with the others.

Generate the SSL certificates for secure inter-component communication by running:

docker compose -f generate-indexer-certs.yml run --rm generator

What does this command do?

This spins up a temporary container that generates all the TLS certificates the Wazuh components need. The --rm flag removes the container once it finishes, since its only job is to create the certificate files.

The certificates are saved to a Docker volume that the other containers will read from when they start.

Start the full Wazuh stack in the background by running:

docker compose up -d

This command starts all three containers: the Manager, the Indexer, and the Dashboard. The -d flag runs them in detached mode so your terminal stays free.

Wait approximately 1-2 minutes for all containers to fully initialize. The Indexer takes the longest because it needs to set up its search indexes.

Verify all three containers are running by running:

docker ps

You should see three containers listed with status "Up" or "healthy": single-node-wazuh.manager-1, single-node-wazuh.indexer-1, and single-node-wazuh.dashboard-1.

Containers not showing as healthy?

If a container shows "starting" or "unhealthy", wait another minute and run docker ps again. The Indexer can take up to 2 minutes on first boot.

If a container has exited, check its logs with docker logs single-node-wazuh.indexer-1. The most common issue is the vm.max_map_count setting not being applied. Re-run the sudo sysctl -w vm.max_map_count=262144 command and restart the stack with docker compose up -d.

Help me troubleshoot Wazuh Docker containers that won't start

Verify the deployment in your browser

The Wazuh Dashboard provides a web interface where you'll triage alerts and manage detection rules throughout this project. Let's confirm it's accessible.

Open your web browser and navigate to https://localhost.
You will see a browser security warning about the self-signed certificate. Click Advanced, then click Proceed to localhost (or equivalent in your browser) to continue.
Enter admin in the Username field.
Enter SecretPassword in the Password field.
Click Log In.

You should see the Wazuh dashboard homepage with zero agents connected. This confirms the entire stack is running and communicating correctly.

Why the certificate warning?

The certificates you generated earlier are self-signed, meaning they weren't issued by a trusted Certificate Authority. Your browser doesn't recognize them as trusted, so it shows a warning.

This is completely normal for a local lab environment. In production, you would use certificates from a recognized authority like Let's Encrypt.

Dashboard not loading?

Make sure you're using https:// (not http://). The Dashboard only serves traffic over HTTPS on port 443.

If the page times out, verify the dashboard container is running with docker ps in your WSL terminal. If it shows as still starting, wait another minute and refresh.

Help me access the Wazuh dashboard at localhost

Your SIEM stack is live. Next up, you'll enroll a monitoring agent so Wazuh has real telemetry to analyze.

Enroll a Wazuh Agent

Your Wazuh SIEM stack is up and running, but it has no visibility into your system yet. A SIEM without data sources is like a security camera with no lens.

To give Wazuh something to monitor, you need to install an agent on your Windows host. The agent collects security events (login attempts, file changes, process launches) and sends them to the Wazuh manager over an encrypted channel on port 1514.

In this step, get ready to:

Install the Wazuh agent on your Windows machine.
Start the agent service and confirm it is running.
Verify the agent appears in the Wazuh dashboard.

Download and install the Wazuh agent

The Wazuh agent runs natively on Windows so it can access host-level security events. A containerized agent cannot monitor the host system directly, which is why you install this one outside of Docker.

Download the Wazuh agent 4.14.5 MSI installer from the official packages page by visiting this URL in your browser:
https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi
The file is named wazuh-agent-4.14.5-1.msi. Save it to a location you can find easily (your Downloads folder is fine).

Why install the agent outside Docker?

The Wazuh documentation states that a containerized agent cannot directly access or monitor the host system. By installing the agent natively on Windows, it can capture real Security Event logs (like failed logins) that your SIEM needs to detect attacks.

Open PowerShell as Administrator by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
Navigate to the folder where you downloaded the MSI file. If it is in your Downloads folder, run:

cd ~\Downloads

Install the Wazuh agent and point it at your local manager by running this command:

.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="127.0.0.1"

What does this command do?

The /q flag runs a quiet (unattended) install with no GUI prompts.

The WAZUH_MANAGER="127.0.0.1" variable tells the agent where to find the Wazuh manager. Since Docker Desktop exposes container ports to localhost, 127.0.0.1 reaches the manager container on ports 1514 (events) and 1515 (enrollment).

Wait about 10-15 seconds for the installation to complete silently.
Confirm the agent files exist by checking the default install path:

ls "C:\Program Files (x86)\ossec-agent"

You should see a list of files and folders in the ossec-agent directory, including ossec.conf and wazuh-agent.exe.

Not seeing the agent files?

Make sure you ran PowerShell as Administrator. The MSI installer requires elevated privileges.
Verify you are in the correct directory where the .msi file was downloaded. Run ls and confirm wazuh-agent-4.14.5-1.msi is listed.
If you get an execution policy error, try running cmd /c before the command: cmd /c wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="127.0.0.1".

Still stuck? Help me troubleshoot the Wazuh agent installation on Windows.

Start the Wazuh agent service

The installer placed the agent files on disk, but the service is not running yet. You need to start it so the agent begins sending events to the manager.

Start the Wazuh agent service by running this command in your Administrator PowerShell:

Start-Service wazuhsvc

Verify the service is running by checking its status:

Get-Service wazuhsvc

You should see the Status column showing Running for the wazuhsvc service.

What is wazuhsvc?

This is the Windows service name for the Wazuh agent. Once running, it continuously collects Windows Security events, Sysmon data, and other logs, then forwards them to the Wazuh manager over an encrypted TCP connection on port 1514.

Service not starting?

If you see an error about the service not being found, the installation may not have completed. Re-run the MSI install command from the previous substep.
If the service starts but immediately stops, check that the Wazuh manager container is still running. Switch to your WSL terminal and run docker ps to confirm all three containers are up.

Need help? Help me troubleshoot the wazuhsvc service not starting on Windows.

Verify the agent in the Wazuh dashboard

The agent is now running and should have automatically enrolled with the manager. Time to confirm it shows up in the dashboard.

Switch back to the Wazuh dashboard in your browser at https://localhost.
In the left sidebar, click Agent management.
Click Summary.
You should now see one active agent listed. This is your Windows machine.
Click on the agent to view its details, including OS information and connection status.

What should I see?

The agent summary page shows your Windows hostname, the operating system version, the agent version (4.14.5), and its status as Active. If the agent still shows as disconnected, wait 1-2 minutes and refresh the page. The initial enrollment handshake can take a moment.

Agent not appearing in the dashboard?

Confirm the agent service is running by re-running Get-Service wazuhsvc in PowerShell.
Check that the Wazuh manager container is listening on port 1515 (enrollment). In WSL, run docker ps and look for port 1515 in the ports column.
If you changed Docker settings or restarted Docker Desktop since deploying the stack, the containers may have stopped. Re-start them with docker compose up -d from the ~/wazuh-docker/single-node/ directory in WSL.

Still stuck? Help me troubleshoot why my Wazuh agent is not appearing in the dashboard.

Your Wazuh SIEM now has eyes on your system. Next up, you will simulate a real attack and watch the alerts roll in.

Simulate a Brute-Force Attack and Triage Alerts

Your Wazuh agent is enrolled and reporting telemetry to the manager. The data pipeline is live, but a SIEM with no alerts is like a security camera pointed at an empty wall.

In this step, you will simulate a real-world brute-force attack against your Windows machine. This generates the same kind of alerts a SOC analyst would triage on day one of the job.

In this step, get ready to:

Simulate a brute-force attack using failed login attempts.
Locate brute-force detection alerts mapped to MITRE ATT&CK T1110.
Triage individual alerts like a Tier 1 SOC analyst.

Generate failed authentication events

Windows logs every failed login as Security Event 4625 (Failed Logon). The Wazuh agent monitors these events and forwards them to the manager for analysis.

You will use the net use command to attempt network logins with invalid credentials. Each failed attempt creates an Event 4625 that the Wazuh agent picks up automatically.

Open PowerShell on your Windows machine by pressing the Windows key, typing PowerShell, and pressing Enter.
Run the brute-force simulation loop by pasting this command:

for ($i=1; $i -le 10; $i++) { net use \\127.0.0.1\IPC$ /user:fakeuser "WrongPassword$i" 2>$null }

What does this command do?

The for loop runs 10 iterations, each attempting a network login to the local IPC$ share.
Each attempt uses a fake username (fakeuser) and a different wrong password (WrongPassword1 through WrongPassword10).
The 2>$null suppresses error output so your terminal stays clean.
Each failed attempt generates a Windows Security Event 4625 that the Wazuh agent forwards to the manager.

The command runs silently and your prompt returns after all 10 attempts complete. This takes a few seconds.

Command not running?

Make sure you are running regular PowerShell (not WSL). This command must run on your Windows host.
If you see a red error message, check that the double backslashes before 127.0.0.1 are present. The UNC path requires them.
Confirm the Wazuh agent is still running by checking Get-Service wazuhsvc shows status Running.

Help me troubleshoot my brute-force simulation command in PowerShell

Find brute-force alerts in the MITRE ATT&CK view

After ingestion, Wazuh automatically maps detected threats to the MITRE ATT&CK framework. The failed login events you just generated will appear under technique T1110 (Brute Force).

Wait 1-2 minutes for the events to be ingested by the Wazuh manager and indexed.
Switch to the Wazuh dashboard in your browser (https://localhost).
In the left sidebar, look under the Threat detection and response section.
Click MITRE ATT&CK.
You should see technique T1110 (Brute Force) highlighted with associated alerts.
Click on T1110 to view the associated alerts showing your simulated attack.

What is MITRE ATT&CK T1110?

MITRE ATT&CK is a global framework that categorizes adversary behaviors into tactics and techniques. T1110 (Brute Force) covers attacks where an adversary systematically guesses credentials to gain access. By mapping alerts to ATT&CK techniques, Wazuh gives you instant context about what type of attack is occurring.

Don't see T1110 in the dashboard?

Events can take up to 2 minutes to appear after ingestion. Wait and refresh the page.
Confirm your agent is active by checking the agent count on the main dashboard page. It should show 1 active agent.
Make sure you ran the PowerShell loop on your Windows host, not inside the WSL terminal.

Help me figure out why my brute-force alerts are not showing up in the Wazuh MITRE ATT&CK view

Triage individual alerts

Alert triage means examining each alert to understand the who, what, when, and how of an incident. This is exactly what a Tier 1 SOC analyst does every day.

Click on one of the individual alerts associated with T1110.
Examine the full JSON event data. Look for the following key fields:

rule.id tells you which Wazuh rule fired.
rule.level indicates the severity (higher numbers mean more critical).
rule.description gives a human-readable explanation of the alert.
data.win.eventdata.targetUserName shows which account the attacker targeted.
timestamp records when the event occurred.

What should I document?

Practice documenting your findings the way a SOC analyst would write up an incident. Note the attack source (127.0.0.1 in this case), the target account (fakeuser), the number of attempts (10), and the MITRE technique (T1110). This is the foundation of incident response documentation.

Note the rule IDs, severity levels, and source IPs from the alerts you examined.
Try filtering alerts in the dashboard by typing rule.id in the search bar to narrow down specific alert types.

Filter by specific fields

The Wazuh dashboard search bar supports field-based filtering. Typing a field name like rule.id followed by a value helps you isolate specific alert types from the noise. This skill is essential when triaging hundreds of alerts in a real SOC.

You have detected and triaged your first attack. Next, you will write a custom detection rule that catches this exact brute-force pattern with higher precision.

Write a Custom Detection Rule

You have successfully simulated a brute-force attack and triaged the resulting alerts in the Wazuh dashboard. Now it is time to move from detection to detection engineering.

Wazuh ships with built-in rules that catch common threats, but real SOC teams write custom rules tailored to their environment. In this step, you will author your own correlation rule that detects brute-force patterns, assign it a high severity level, and map it to the MITRE ATT&CK framework.

In this step, get ready to:

Access the Wazuh manager container and navigate to the custom rules file.
Write a custom correlation rule with MITRE ATT&CK T1110 mapping.
Test the rule by re-running the brute-force simulation and confirming alerts fire in the dashboard.

Access the Wazuh manager container

Custom detection rules live inside the Wazuh manager container at /var/ossec/etc/rules/local_rules.xml. You need to open a shell session inside the container to edit that file.

Switch back to your WSL terminal and open a shell inside the Wazuh manager container by running this command:

docker exec -it single-node-wazuh.manager-1 bash

Navigate to the rules directory by running:

cd /var/ossec/etc/rules/

Open local_rules.xml for editing by running:

vi local_rules.xml

Prefer nano?

If you are more comfortable with nano, run nano local_rules.xml instead. The editing steps below work the same way regardless of which editor you choose.

Why edit rules inside the container?

The Wazuh manager process runs inside this Docker container. It reads rule files from /var/ossec/etc/rules/ at startup. Editing the file inside the container ensures the manager can load your custom rule when it restarts.

Write your custom detection rule

You will create a correlation rule that fires when 5 or more failed logon events come from the same source IP within 60 seconds. This is the pattern a real attacker generates during a brute-force attempt.

If using vi, press i to enter insert mode.
Delete any existing placeholder content in the file.
Paste the following custom rule into the file:

<group name="custom_brute_force,">
  <rule id="100001" level="12" frequency="5" timeframe="60">
    <if_matched_sid>60122</if_matched_sid>
    <same_srcip />
    <description>Custom: Multiple Windows logon failures from same source (possible brute force)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,</group>
  </rule>
</group>

What does this rule do?

Here is what each part of the rule means:

id="100001" assigns a custom rule ID within the allowed range of 100000 to 120000, avoiding conflicts with built-in rules.
level="12" sets the alert severity to high (Wazuh levels go from 0 to 15).
frequency="5" timeframe="60" means the rule triggers after 5 matching events occur within a 60-second window.
<if_matched_sid>60122</if_matched_sid> correlates with Wazuh's built-in Windows logon failure rule.
<same_srcip /> groups the events by source IP address, so only repeated failures from the same attacker trigger the alert.
<mitre><id>T1110</id></mitre> maps the rule to MITRE ATT&CK technique T1110 (Brute Force).

Save the file. In vi, press Esc, type :wq, and press Enter.
Exit the container shell by running:

exit

You are now back in your regular WSL terminal.

Restart the Wazuh manager to load the new rule by running:

docker exec -it single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart

Wait about 30 seconds for the manager to fully restart and reload all rules.

Seeing an error about invalid XML?

If the manager fails to restart, there may be a typo in your XML. Re-enter the container and check that all angle brackets and closing tags are correct. Pay special attention to the trailing commas inside the name and <group> attributes. Wazuh requires them.

Help me debug this XML syntax error

✔️ Awesome, I've got everything!

Great. Double check you saved the file and that the manager restart completed without errors.

ⓧ I'd like to double check the full code

Here is the complete local_rules.xml file that should be inside the manager container at /var/ossec/etc/rules/local_rules.xml:

<group name="custom_brute_force,">
  <rule id="100001" level="12" frequency="5" timeframe="60">
    <if_matched_sid>60122</if_matched_sid>
    <same_srcip />
    <description>Custom: Multiple Windows logon failures from same source (possible brute force)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,</group>
  </rule>
</group>

Test your custom rule

The best way to validate a detection rule is to trigger the exact behaviour it watches for. You will re-run the same brute-force simulation from the previous step and verify your custom rule fires.

Open a new PowerShell window on your Windows host.
Re-run the brute-force simulation by running this command:

for ($i=1; $i -le 10; $i++) { net use \\127.0.0.1\IPC$ /user:fakeuser "WrongPassword$i" 2>$null }

What does this simulate?

This loop generates 10 failed login attempts against your local machine with an invalid username. Each attempt creates a Windows Security Event 4625 (Failed Logon) that the Wazuh agent picks up and forwards to the manager.

Your custom rule correlates 5 of these from the same IP within 60 seconds and fires a level 12 alert.

Wait 1-2 minutes for the events to be ingested and correlated by the manager.
Return to the Wazuh dashboard in your browser at https://localhost.
Navigate to the Threat intelligence section.
In the search bar, filter alerts by typing rule.id: 100001 and pressing Enter.

You should see alerts from your custom rule 100001 at level 12 severity, confirming your detection rule works.

No alerts showing for rule 100001?

Check these common causes:

Make sure you waited at least 1-2 minutes after running the simulation. The indexer needs time to process events.
Verify the Wazuh agent service is still running. Open PowerShell and run Get-Service wazuhsvc to confirm its status shows Running.
Confirm the manager restarted successfully. In WSL, run docker exec -it single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control status and verify all processes show as running.

Help me troubleshoot why my rule is not firing

Your custom detection rule is now live and proven. You have gone from consuming alerts to engineering them. This is the core skill that separates a SOC analyst from a detection engineer.

Secret mission

Enable File Integrity Monitoring (FIM)

You have built detection for brute-force attacks. Now extend your SOC lab with another core SIEM capability: File Integrity Monitoring. Configure Wazuh to watch a directory for changes, trigger real file events, and write a custom rule that maps to MITRE ATT&CK T1565 (Data Manipulation).

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 with free, open-source tools, so there are no ongoing costs.

Resources you used:

Docker containers (Wazuh Manager, Indexer, Dashboard) using disk space and RAM.
Wazuh agent service running on Windows.
The wazuh-docker directory in WSL (cloned repository and data volumes).
The fim-test directory on your Desktop (Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with your SOC home lab.

Leave Docker Desktop running. The Wazuh containers use approximately 4-6 GB RAM when active.
The Wazuh agent continues collecting telemetry from your Windows host.
You can keep testing new detection rules and simulating attacks at any time.

Pause - I'll come back to this later

Shut down running processes to free up memory while keeping your files and configuration intact. You can restart everything later.

Stop the Wazuh agent service on Windows by opening PowerShell as Administrator and running:
Stop the Docker containers by opening a WSL terminal and running:

Stop the Wazuh agent service:

Stop-Service wazuhsvc

Stop the containers (from the single-node directory in WSL):

cd ~/wazuh-docker/single-node/
docker compose down

Restarting later

To resume, open WSL and run docker compose up -d from the ~/wazuh-docker/single-node/ directory. Then restart the agent with Start-Service wazuhsvc in PowerShell.

Delete - I don't want to use this again

Remove all project resources and start fresh. This deletes your custom rules, agent configuration, and indexed data.

Stop and remove the Docker containers and their data volumes. Open a WSL terminal and run:

cd ~/wazuh-docker/single-node/
docker compose down -v

What does the -v flag do?

The -v flag removes the Docker volumes that store the Wazuh indexer data and configuration. Without it, your indexed alerts and settings persist even after the containers are gone.

Remove the cloned repository directory in WSL:

rm -rf ~/wazuh-docker

Uninstall the Wazuh agent from Windows. Open PowerShell as Administrator and run:

msiexec.exe /x wazuh-agent-4.14.5-1.msi /qn

Where is the MSI file?

This command requires the original wazuh-agent-4.14.5-1.msi file to be in your current directory. Navigate to the folder where you downloaded it in Step 3 before running the command.

Remove the FIM test directory from your Desktop. In PowerShell, run:

Remove-Item -Recurse -Force "$env:USERPROFILE\Desktop\fim-test"

Optionally, uninstall Docker Desktop if you no longer need it. Open Windows Settings, go to Apps, then Installed apps. Find Docker Desktop and click Uninstall.

Nice Work!

Congratulations! You have built a complete SOC home lab from scratch using Wazuh SIEM on your own machine.

You now have a working security operations environment that demonstrates the end-to-end SIEM pipeline: log collection, attack detection, alert triage, and custom rule authoring.

Here's what you learned:

Deployed a production-grade SIEM stack (Manager, Indexer, Dashboard) using Docker, demonstrating infrastructure and containerization skills.
Simulated a brute-force attack and triaged the resulting alerts in the Wazuh dashboard, practicing the core SOC analyst workflow.
Authored a custom detection rule with MITRE ATT&CK mapping, demonstrating detection engineering capability.
Configured File Integrity Monitoring and wrote targeted rules for file change detection mapped to MITRE ATT&CK T1565.

Ready to quiz yourself?