Detect a Brute-Force Attack with Wazuh

Deploy a SIEM, simulate a brute-force attack, and write a custom detection rule.

Introduction

30 Second Summary

Every time you log in to an online account, a system somewhere is watching for suspicious activity. Security teams use dedicated monitoring tools to catch hackers in the act, often within seconds of an intrusion attempt.

In this project, you will deploy a real SIEM (Security Information and Event Management) system on your own machine, simulate a brute-force attack, and write a custom detection rule that catches it.

What You'll Build

A complete SOC (Security Operations Center) detection pipeline running locally on your Windows machine using Wazuh, an open-source SIEM that monitors your endpoint in real-time and alerts on suspicious activity.

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

  • A running Wazuh SIEM stack (manager, indexer, and dashboard) deployed via Docker Compose on your local machine.
  • A custom detection rule you wrote from scratch that detects brute-force login attempts and maps to MITRE ATT&CK technique T1110.
  • A completed incident detection workflow covering attack simulation, alert triage, rule creation, and dashboard investigation.
  • Secret Mission: Configure Wazuh Active Response to automatically block an attacker's IP after repeated failed logons.

Are there any prerequisites?

You need a Windows PC with at least 16 GB of RAM. No prior cybersecurity experience is required.

This guide includes full setup instructions for every tool you need, including Docker Desktop and Git.

Install Docker Desktop and Git

The Wazuh SIEM stack runs as a set of Docker containers on your machine. You need Docker Desktop to run those containers and Git to download the official Wazuh configuration files.

In this step, you will install both tools and confirm they work by running a test container.

In this step, get ready to:
  • Install Docker Desktop with the WSL 2 backend.
  • Install Git for Windows.
  • Verify Docker can run containers successfully.
Install Docker Desktop for Windows

Docker Desktop provides the container runtime that runs the Wazuh manager, indexer, and dashboard as isolated services on your machine.

  • Open PowerShell by pressing the Windows key to open your search bar.
  • Type PowerShell and press Enter to open it.
  • Check if Docker is already installed by running this command:
docker --version

✔️ I see a version number

Docker is already installed on your machine. You can skip ahead to the Git installation below.

ⓧ Command not found

Docker is not installed yet. Follow these instructions to install it.

  • Open your browser and go to https://www.docker.com/products/docker-desktop/.
  • Click the Download for Windows button to download the installer.
  • Run the downloaded installer file.
  • When the configuration screen appears, ensure Use WSL 2 instead of Hyper-V is checked. This is the default option.
  • Click Ok to proceed with the installation.
  • When the installer finishes, restart your PC if prompted. The restart is required for WSL 2 features to complete their configuration.
  • After restarting, Docker Desktop launches automatically. Wait until the whale icon appears in your system tray (bottom-right of your taskbar).

What is WSL 2?

WSL 2 (Windows Subsystem for Linux 2) is a lightweight Linux environment built into Windows. Docker Desktop uses it to run Linux containers natively on your Windows machine without a full virtual machine.

  • Once Docker Desktop is running, reopen PowerShell and verify the installation by running:
docker --version
  • You should see a version number printed in the output.
  • Also confirm Docker Compose is available by running:
docker compose version

You should see a version number for Docker Compose as well. Both commands returning version numbers confirms Docker Desktop is installed correctly.

Docker command not recognized after install?

  • Make sure Docker Desktop is fully running. Look for the whale icon in your system tray.
  • Close and reopen PowerShell after the install. PowerShell needs a fresh session to pick up the new PATH entries.
  • If you skipped the restart, restart your PC now. WSL 2 features require a reboot to finish setup.

Help me troubleshoot why Docker is not recognized in PowerShell after installing Docker Desktop on Windows.

Install Git for Windows

Git is the version control tool you will use to download the official Wazuh Docker deployment files from GitHub.

  • In PowerShell, check if Git is already installed by running:
git --version

✔️ I see a version number

Git is already installed. You can skip ahead to the Docker verification below.

ⓧ Command not found

Git is not installed yet. Follow these instructions to install it.

  • Open your browser and go to https://git-scm.com/downloads/win.
  • Download the standalone installer for your system (64-bit for most machines).
  • Run the downloaded installer.
  • Accept the default settings on each screen by clicking Next through the wizard.
  • Click Install, then Finish when complete.
  • Close and reopen PowerShell so it detects the new Git installation.
  • Verify by running:
git --version

You should see a version number confirming Git is installed.

Git command not recognized?

  • Close and reopen PowerShell. The installer adds Git to your PATH, but only new terminal sessions pick it up.
  • If it still does not work, open the Git installer again and ensure the option to add Git to your system PATH is selected.

Help me troubleshoot why Git is not found in PowerShell after installation.

Verify Docker is running

Docker Desktop must be actively running (not just installed) for containers to start. This final check confirms the full stack is working.

  • Look at your system tray (bottom-right of your taskbar). You should see the Docker whale icon. If it is animated or shows "starting", wait until it settles.
  • If Docker Desktop is not running, open it by pressing the Windows key, typing Docker Desktop, and pressing Enter.
  • Run a test container to confirm everything works end-to-end:
docker run hello-world

What does this command do?

This command downloads the official hello-world image from Docker Hub and runs it in a new container. The container prints a confirmation message and exits.

If you see "Hello from Docker!" in the output, your Docker installation can pull images, create containers, and run them. This is exactly what the Wazuh stack needs to work.

  • You should see output that includes the line "Hello from Docker!" confirming that containers can start successfully.

Seeing an error when running hello-world?

  • If you see "docker daemon is not running", Docker Desktop has not finished starting. Wait for the whale icon to stop animating, then try again.
  • If you see a network error, check your internet connection. Docker needs to download the hello-world image from Docker Hub.
  • If you see a permissions error, make sure you are running PowerShell as your normal user (not as Administrator) and that Docker Desktop is set to start without admin rights.

Help me fix an error when running docker run hello-world on Windows.

Your tools are ready to go. Next up, you will use Docker Compose to deploy the full Wazuh SIEM stack with a single command.

Deploy the Wazuh SIEM Stack

Your development environment is set up with Docker and Git ready to go. Now you'll bring the actual SIEM online.

Wazuh provides a pre-configured Docker Compose setup that launches three services working together: a manager to process events, an indexer to store data, and a dashboard for visual investigation. Without this stack running, there's nothing to receive and analyze the security events from your machine.

In this step, get ready to:
  • Clone the official Wazuh Docker repository.
  • Generate TLS certificates and launch the three-container stack.
  • Log into the Wazuh dashboard and confirm it's live.
Clone the Wazuh Docker repository

The Wazuh project publishes an official Docker repository with everything you need to run the stack. You'll clone a specific version branch to ensure a consistent setup.

  • Move to your Desktop by running this command in PowerShell:
cd ~\Desktop
  • Clone the Wazuh Docker repository at version v4.14.5 and navigate into the single-node directory by running these commands:
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.5
cd wazuh-docker/single-node/
  • Confirm the repository was cloned by running:
ls

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

Clone failed or directory not found?

Make sure Docker Desktop is still running in the background. The whale icon should be visible in your system tray.

If git returns "not recognized", close and reopen PowerShell so it picks up the PATH changes from the Git installation.

Help me troubleshoot the clone

Generate TLS certificates and start the stack

The Wazuh components communicate over encrypted channels. Before starting the stack, you need to generate TLS certificates that each service uses to verify the others.

  • Generate the TLS certificates by running this command:
docker compose -f generate-indexer-certs.yml run --rm generator

What does this command do?

The -f generate-indexer-certs.yml flag tells Docker Compose to use a special file that only runs a certificate-generation container. The --rm flag removes the container once it finishes, since it's only needed for this one-time task.

  • Start the full Wazuh stack in the background by running:
docker compose up -d

What does this command do?

The -d flag runs the containers in detached mode, so they keep running in the background while you continue working in PowerShell. This command pulls the Wazuh Docker images (manager, indexer, dashboard) and starts all three containers.

The Wazuh indexer takes about one minute to fully start. You may see log messages about the dashboard waiting for the indexer. This is normal.

  • Wait 2-3 minutes, then verify all containers are running:
docker compose ps

You should see three containers all showing a status of running:

  • single-node-wazuh.manager-1
  • single-node-wazuh.indexer-1
  • single-node-wazuh.dashboard-1

Containers not all showing running?

If a container shows restarting or exited, wait another minute and run docker compose ps again. The indexer can take time to initialize.

If containers still fail after 3-4 minutes, check that Docker Desktop has enough memory allocated. The Wazuh stack needs at least 4 CPU cores and 8 GB RAM available to Docker.

Help me troubleshoot my containers

Access the Wazuh dashboard

With all three containers running, the Wazuh dashboard is ready for you to explore. The dashboard is your primary investigation interface as a SOC analyst.

  • Open your web browser and navigate to https://localhost:443.
  • Your browser will show a security warning about the self-signed certificate. Click Advanced and then Proceed (or the equivalent in your browser) to continue.
  • Log in with username admin and password SecretPassword.
  • Explore the dashboard homepage showing security event summaries and module cards.

Why a self-signed certificate warning?

The TLS certificates you generated earlier are self-signed, meaning they weren't issued by a trusted certificate authority. Your browser flags this because it can't verify who issued them.

For a local lab environment, this is perfectly safe to proceed through.

🙋‍♀️ Dashboard not loading?

If the page times out, the dashboard container may still be initializing. Wait another minute and refresh.

If you see a connection refused error, confirm all three containers are running with docker compose ps in PowerShell. Port 443 on your machine maps to the dashboard's internal port 5601.

Help me get the dashboard working

Your SIEM is live. Next up, you'll connect a real endpoint to it by installing the Wazuh agent on your Windows machine.

Install the Wazuh Agent on Your Windows Host

Your Wazuh SIEM stack is live and waiting for data. The manager, indexer, and dashboard are all running, but they have nothing to monitor yet.

In this step, you will install the Wazuh agent directly on your Windows machine. The agent collects security events (login attempts, file changes, system activity) and forwards them to the manager for analysis. Once connected, your own endpoint becomes a live data source for the SIEM.

In this step, get ready to:
  • Identify the network address the agent uses to reach the manager.
  • Download and install the Wazuh agent on your Windows host.
  • Verify the agent appears as connected in the Wazuh dashboard.
Identify the manager connection address

The Wazuh agent needs to know where to send security event data. It connects to the manager over ports 1514 and 1515.

Since Docker Desktop exposes the manager's ports on your host machine, the agent can reach the manager at 127.0.0.1 (localhost). No complex networking is needed.

  • Confirm the manager ports are exposed by running this command in your PowerShell window:
docker compose ps

What am I looking for?

In the output, find the single-node-wazuh.manager-1 row. You should see port mappings including 0.0.0.0:1514-1515->1514-1515/tcp. This confirms the manager is listening for agent connections on your host's 127.0.0.1.

Download and install the Wazuh agent

The Wazuh agent installs as a Windows service that runs in the background. You will install it using the official MSI package and point it at 127.0.0.1 so it connects to your local Docker manager.

Why the MSI installer?

The MSI format lets you pass configuration variables (like the manager address) at install time. This means the agent is ready to connect as soon as the installation finishes.

The installer requires administrator privileges to register the agent as a Windows service.

  • Press the Windows key to open your search bar.
  • Type PowerShell and look for Windows PowerShell in the results.
  • Right-click Windows PowerShell and select Run as administrator.
  • Click Yes on the User Account Control prompt that appears.
  • Navigate to your Downloads folder by running this command:
cd ~\Downloads
  • Install the Wazuh agent and configure it to connect to 127.0.0.1 by running this command:
msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="127.0.0.1"

What does this command do?

msiexec.exe /i tells Windows to install the specified MSI package.

/q runs the installation silently (no GUI prompts). WAZUH_MANAGER="127.0.0.1" configures the agent to send data to your local Docker manager.

  • Wait about 10-15 seconds for the silent installation to complete. You will not see any output if it succeeds.
  • Start the Wazuh agent service by running this command:
NET START WazuhSvc
  • You should see a message confirming the service started successfully.

What is WazuhSvc?

WazuhSvc is the Windows service name for the Wazuh agent. Once started, it runs in the background and continuously collects security events from your machine. It forwards these events to the manager over an encrypted channel.

🙋‍♀️ Seeing an access denied error?

Make sure you opened PowerShell as Administrator (right-click, Run as administrator). The MSI installer and service commands require elevated privileges.

If you see a message that the file was not found, confirm you are in your Downloads folder and that the MSI file finished downloading completely.

Help me troubleshoot the Wazuh agent installation on Windows.

Verify the agent is connected in the dashboard

The agent should automatically register with the manager and start sending events. You can confirm this in the Wazuh dashboard.

  • Switch back to the Wazuh dashboard in your browser at https://localhost:443.
  • In the left sidebar, click Agents management.
  • Click Summary.
  • Wait 1-2 minutes for your Windows host to appear in the agents list.
  • Confirm that your agent shows a Connected status.
  • Click on your agent's name to open its detail page. You should see security events already flowing in.

What events am I seeing?

The Wazuh agent immediately starts collecting Windows security logs, system events, and file integrity data. You may see events related to service starts, user logon activity, and system configuration changes. These are normal events from your own machine.

🙋‍♀️ Agent not showing up?

Give it a full 2 minutes. The agent needs time to register and sync with the manager.

If it still does not appear, return to your Administrator PowerShell and check the service status by running Get-Service WazuhSvc. Confirm the status shows Running.

Help me get my Wazuh agent to connect to the manager.

Your endpoint is now a live data source for your SIEM. Next up, you will simulate a brute-force attack against your own machine and investigate the resulting alerts in the dashboard.

Simulate a Brute-Force Attack and Investigate Alerts

Your SIEM is live and your Windows agent is reporting security events in real time.

Now it is time to put the system to work. In this step, you will simulate a brute-force login attack against your own machine, generating real Windows security events. Then you will investigate those alerts in the Wazuh dashboard, examining the evidence exactly as a SOC analyst would during an incident.

In this step, get ready to:
  • Simulate a brute-force attack by generating 10 failed Windows logon attempts.
  • Investigate the resulting alerts in the Wazuh dashboard.
  • Correlate the events using the dashboard's threat hunting capabilities to identify the attack pattern.
Simulate failed Windows logon attempts

When someone tries to log in to a Windows machine and fails, Windows generates a security event with ID 4625. This is the exact event that real brute-force attacks produce.

You will use a PowerShell loop to rapidly create 10 failed logon attempts against your own machine. The Wazuh agent will detect each failure and forward it to the manager.

  • Open a new PowerShell window by pressing the Windows key, typing PowerShell, and pressing Enter.
  • Generate 10 failed logon attempts by running this command:
for ($i=1; $i -le 10; $i++) { net use \\127.0.0.1\IPC$ /user:fakeuser "WrongPassword$i" 2>$null; net use \\127.0.0.1\IPC$ /delete 2>$null }

What does this command do?

This loop runs 10 iterations. Each iteration attempts to connect to your machine's IPC$ share using a fake username and an incorrect password.

Each failed attempt generates a Windows Event ID 4625 ("An account failed to log on"). The Wazuh agent picks up these events from the Windows Security log and forwards them to the Wazuh manager for analysis.

  • Wait 1-2 minutes for the Wazuh agent to forward the events to the manager.

You will not see any visible output in PowerShell from this command. The events are generated silently in the Windows Security log behind the scenes.

Not sure if the events were generated?

You can verify events locally by opening Event Viewer (press the Windows key, type Event Viewer). Navigate to Windows Logs then Security. Look for events with Event ID 4625 and the username fakeuser.

If you do not see any 4625 events, make sure you ran PowerShell as a regular user (not Administrator) and that the WazuhSvc service is still running.

help me figure out why my brute-force simulation did not generate Event ID 4625 events

Investigate the brute-force alerts in the dashboard

The Wazuh manager matches incoming events against its built-in ruleset. Rule 18106 specifically detects Windows logon failures (Event ID 4625). Your simulated attack should have triggered this rule multiple times.

  • Switch back to the Wazuh dashboard in your browser at https://localhost:443.
  • Click on your Windows agent in the agents list to view its events.
  • Navigate to the Security events tab for your agent.
  • In the search bar, type rule.id:18106 and press Enter to filter for Windows logon failure alerts.
  • You should see multiple alerts appearing. Click on any alert to expand its full details.

What should I see in the alert details?

Each alert contains rich event data that a SOC analyst uses during investigation. Key fields to look for include:

  • Timestamp showing when the failed logon occurred.
  • Target username fakeuser confirming who the attacker tried to authenticate as.
  • Source IP address showing where the attempt came from.
  • Failure reason explaining why the logon was rejected.
  • Rule level (around 4-5) indicating the severity Wazuh assigned to this individual event.

🙋‍♀️ Not seeing any alerts with rule.id 18106?

Wait 2-3 minutes after running the simulation. The agent collects events in batches and forwards them to the manager periodically.

Make sure the time range filter in the dashboard covers the period when you ran the simulation. Expand the time range to the last 15-30 minutes if needed.

Confirm your agent still shows a Connected status in Agents management > Summary. If it shows disconnected, restart the service with NET START WazuhSvc in an Administrator PowerShell.

help me troubleshoot why Wazuh is not showing rule 18106 alerts after my brute-force simulation

Correlate events using the Threat Hunting view

Individual alerts tell you something went wrong. Correlation shows you the bigger picture. When you view multiple failed logon events together on a timeline, the burst pattern becomes an obvious indicator of automated brute-force activity.

  • Click the upper-left menu icon in the dashboard and navigate to Explore > Discover.
  • Make sure the index pattern is set to waz-alerts-*.
  • In the search bar, type rule.id:18106 to filter your results.
  • Look at the histogram at the top of the page. You should see a spike of events clustered together within a short time window.
  • Expand one of the events and click the JSON tab to see the full structured data including any MITRE ATT&CK mapping.

Why does the burst pattern matter?

A single failed logon happens all the time. People mistype passwords. But 10 failures from the same source within seconds is a clear indicator of automated attack behavior.

This is exactly the pattern that SOC analysts look for during threat hunting. The current rule level is low (4-5) because each event is just one failed logon. In the next step, you will write a custom rule that detects this burst pattern and raises the severity to level 10.

You have just completed a full attack simulation and investigation workflow. Next up, you will write a custom detection rule that catches this burst pattern automatically and assigns it a high severity level.

Write a Custom Detection Rule for Brute-Force Attacks

In the previous step, you saw individual failed logon alerts (rule 18106) appearing at a low severity level. A single failed login isn't necessarily suspicious. People mistype passwords all the time.

What makes brute-force attacks stand out is the pattern: multiple failures happening rapidly from the same source. In this step, you'll write a custom Wazuh rule that detects this pattern and fires a high-severity alert mapped to the MITRE ATT&CK framework.

In this step, get ready to:
  • Author a custom detection rule inside the Wazuh manager container.
  • Restart the Wazuh manager to load the new rule.
  • Re-run the brute-force simulation and verify your custom alert fires in the dashboard.
Access the Wazuh manager and add the custom rule

Wazuh stores custom detection rules in a file called local_rules.xml inside the manager. You'll open a shell into the manager container, then use the vi text editor to add your rule.

  • Open a shell inside the Wazuh manager container by running this command in PowerShell:
docker exec -it single-node-wazuh.manager-1 bash

Your prompt changes to something like root@<container-id>. You're now inside the container.

  • Open the local rules file by running:
vi /var/ossec/etc/rules/local_rules.xml

What is vi?

vi is a terminal-based text editor available in most Linux containers. You'll use three basic commands: press i to start typing (insert mode), press Esc to stop typing, and type :wq then Enter to save and quit.

  • Press i on your keyboard to enter insert mode. You should see -- INSERT -- appear at the bottom of the screen.
  • Paste the following custom rule into the file:
<group name="custom_brute_force,">
  <rule id="100002" level="10" frequency="5" timeframe="60">
    <if_matched_sid>18106</if_matched_sid>
    <description>Brute force attack detected: multiple Windows logon failures within 60 seconds.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

What does this rule do?

id="100002" assigns a unique ID in the user-defined range (100000-120000). level="10" sets the severity to high, making this alert stand out during triage.

frequency="5" timeframe="60" means the rule fires when the child rule triggers 5 or more times within 60 seconds. if_matched_sid points to rule 18106, which is Wazuh's built-in rule for Windows logon failures.

The <mitre> block maps this detection to MITRE ATT&CK technique T1110 (Brute Force). This mapping helps SOC analysts quickly understand the attack category during an investigation.

  • Press Esc to exit insert mode.
  • Type :wq and press Enter to save the file and quit vi.

✔️ Awesome, I've got everything!

Great. Your custom rule is saved inside the manager container.

ⓧ I'd like to double check the full code

Your local_rules.xml file should contain exactly this:

<group name="custom_brute_force,">
  <rule id="100002" level="10" frequency="5" timeframe="60">
    <if_matched_sid>18106</if_matched_sid>
    <description>Brute force attack detected: multiple Windows logon failures within 60 seconds.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Seeing an error when saving?

If vi shows an error about a read-only file, make sure you typed :wq (colon, w, q) and not just wq. The colon enters command mode.

If you accidentally entered text in the wrong place, press Esc then type :q! to quit without saving. Then re-open the file and try again.

help me fix a vi editing error in the Wazuh manager container

Restart the Wazuh manager to load the new rule

Wazuh only reads its rules files at startup. You need to restart the manager for your new rule to take effect.

  • Exit the container shell by running:
exit
  • Restart the Wazuh manager container from your PowerShell by running:
docker restart single-node-wazuh.manager-1
  • Wait about 30 seconds for the manager to fully restart. Confirm it's running by running:
docker compose ps

You should see all three containers showing a "running" status, including single-node-wazuh.manager-1.

Manager container not restarting?

Make sure you exited the container shell first (ran exit). If docker compose ps shows the manager as "restarting" in a loop, there may be a syntax error in your XML rule file. Re-enter the container with docker exec -it single-node-wazuh.manager-1 bash and check the file for missing closing tags or stray characters.

help me troubleshoot why my Wazuh manager container won't restart after adding a custom rule

Re-run the brute-force simulation and verify the custom alert

Your custom rule is now live. Time to trigger it by repeating the brute-force simulation from the previous step, then confirming the alert appears in the dashboard.

  • Open a new PowerShell window and re-run the brute-force simulation by running:
for ($i=1; $i -le 10; $i++) { net use \\127.0.0.1\IPC$ /user:fakeuser "WrongPassword$i" 2>$null; net use \\127.0.0.1\IPC$ /delete 2>$null }

Why re-run the simulation?

Your custom rule (100002) uses frequency="5" and timeframe="60". It needs 5 or more failed logon events (rule 18106) to fire within a 60-second window. The 10 rapid-fire attempts from this loop exceed that threshold.

  • Switch back to the Wazuh dashboard in your browser at https://localhost:443.
  • Navigate to your agent's security events.
  • Filter for rule.id 100002. You should see your custom alert appear within 1-2 minutes.
  • Click on the alert to expand the full event details. Confirm you see:
  • Rule ID: 100002.
  • Level: 10.
  • Description: "Brute force attack detected: multiple Windows logon failures within 60 seconds."
  • MITRE ATT&CK technique T1110 mapped in the alert details.

Don't see rule 100002 alerts?

Wait a full 2 minutes after running the simulation. The manager needs time to correlate the events and fire the frequency-based rule.

If alerts still don't appear, verify the manager restarted successfully (docker compose ps shows "running"). Then re-enter the container and check your XML for typos. Common issues: a missing closing </rule> tag, a mistyped if_matched_sid value, or extra whitespace inside attribute values.

help me figure out why my custom Wazuh rule 100002 isn't firing

You've just written a detection rule from scratch that correlates multiple events into a single high-severity alert. This is exactly how SOC analysts build custom detections for their environment. Next up, you'll take on the Secret Mission and configure automated response to block attackers the moment your rule fires.

Secret mission

Configure Active Response to Block the Attacker

You've built detection. Now build automated containment. Configure Wazuh's Active Response to automatically block an attacker's IP address the moment your brute-force rule fires. This is how real SOC teams turn alerts into action without waiting for a human to intervene.

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

Resources you used:

  • Three Docker containers (single-node-wazuh.manager-1, single-node-wazuh.indexer-1, single-node-wazuh.dashboard-1) using approximately 4-6 GB RAM total.
  • Wazuh agent installed as a Windows service (WazuhSvc).
  • The wazuh-docker repository folder on your Desktop.

Keep everything running

No action needed. Choose this if you're still actively building or want to continue exploring Wazuh's features like vulnerability detection, compliance dashboards, and file integrity monitoring.

  • The Docker containers persist your data across restarts. Your custom detection rule and active response configuration remain intact inside the manager container.
  • The Wazuh agent continues running as a Windows service, reporting security events to the manager.
  • Docker Desktop and Git remain installed on your machine.

Pause - I'll come back to this later

Shut down the running containers to free up memory. Your data and configuration are preserved, so you can restart later without losing anything.

  • Open PowerShell and navigate to the deployment directory by running:
  • Stop the Wazuh containers by running:
cd ~/Desktop/wazuh-docker/single-node/
docker compose stop
  • Stop the Wazuh agent service by running:
NET STOP WazuhSvc
  • When you're ready to come back, restart the stack by running:
cd ~/Desktop/wazuh-docker/single-node/
docker compose start
NET START WazuhSvc

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes your containers, volumes, custom rules, and the Wazuh agent.

  • Stop and remove all Wazuh containers and volumes. Open PowerShell and run:
cd ~/Desktop/wazuh-docker/single-node/
docker compose down -v
  • Uninstall the Wazuh agent. Make sure the original MSI installer is in your working directory (the folder where you downloaded it), then run:
msiexec.exe /x wazuh-agent-4.14.5-1.msi /qn
  • Delete the cloned repository folder from your Desktop by running:
Remove-Item -Recurse -Force ~/Desktop/wazuh-docker
  • Optionally, uninstall Docker Desktop if you no longer need it. Open Settings, select Apps, then Installed apps. Find Docker Desktop and click Uninstall.

Nice Work!

Nice Work!

You just built a complete Security Operations Center detection pipeline on your own machine. From deploying a production-grade SIEM to writing custom detection rules and investigating real alerts, you've walked through the exact workflow SOC analysts perform every day.

You've learned how to:

  • Deploy a Wazuh SIEM stack (v4.14.5) using Docker and connect a live endpoint agent reporting real-time Windows security events to the manager.
  • Simulate a brute-force attack generating Windows Event ID 4625 alerts and investigate them in the SIEM dashboard using the Threat Hunting module.
  • Author a custom detection rule (ID 100002) that correlates multiple failed logons within a time window and maps to MITRE ATT&CK technique T1110 (Brute Force).
  • Secret Mission: Configured Active Response to automatically block attacker IPs when your custom rule fires, implementing detection-to-containment in seconds.

Ready to quiz yourself?