Set Up a SIEM with Wazuh

Deploy a Wazuh SIEM and monitor your Windows machine for threats.

Introduction

30 Second Summary

Every time you download a file, visit a website, or install an app, your computer generates a trail of activity. Security teams use that trail to catch threats before they cause damage.

In this project, you will build a fully operational SIEM (Security Information and Event Management) system that monitors your Windows machine for suspicious activity, detects file changes in real time, and fires custom alerts mapped to real-world attacker techniques.

What You'll Build

A complete SIEM lab environment where your Windows machine is monitored by a Wazuh server running in VirtualBox, with custom detection rules that identify threat behaviors and map them to the MITRE ATT&CK framework.

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

  • A running Wazuh SIEM instance (server, indexer, dashboard) deployed in a virtual machine on your local machine.
  • A Windows agent connected to your SIEM, with File Integrity Monitoring actively detecting file changes in real time.
  • A custom detection rule that identifies file deletion via File Explorer and maps it to MITRE ATT&CK techniques.
  • Secret Mission: Detect a simulated persistence attack by monitoring the Windows Registry Run key and writing a high-severity custom alert.

Are there any prerequisites?

You need a Windows machine with at least 40 GB of RAM to run the Wazuh virtual machine comfortably alongside your normal workload. No prior cybersecurity experience is required. This guide walks you through every tool installation from scratch.

Set Up VirtualBox and the Wazuh Virtual Machine

A SIEM needs a central server to collect and analyze security events from all your machines. In this project, you'll run the Wazuh server inside a virtual machine on your Windows computer.

To get started, you'll install VirtualBox (the software that runs virtual machines), import the pre-built Wazuh appliance, and confirm the Wazuh dashboard loads in your browser.

In this step, get ready to:
  • Install VirtualBox on your Windows machine.
  • Import the Wazuh virtual appliance and start the VM.
  • Access the Wazuh dashboard in your browser.
Install VirtualBox on Windows

VirtualBox is a free tool from Oracle that lets you run entire operating systems inside your current computer. You'll use it to host the Wazuh server without needing a second physical machine.

  • Press the Windows key to open your search bar.
  • Type VirtualBox and check whether it appears in the results.

✔️ VirtualBox opens

You already have VirtualBox installed. Skip ahead to the next substep where you import the Wazuh OVA.

ⓧ It doesn't appear

  • Open your browser and go to the VirtualBox downloads page:
  • https://www.virtualbox.org/wiki/Downloads
  • Click the Windows hosts link to download the installer.
  • Once downloaded, double-click the installer file to launch the setup wizard.
  • Click Next through each screen, accepting the defaults.

What about the driver warnings?

Depending on your Windows configuration, you may see warnings about unsigned drivers during installation. Click Continue or Install for these prompts. VirtualBox needs these drivers for USB and networking support.

  • Wait for the installation to complete, then click Finish.
  • Press the Windows key, type VirtualBox, and press Enter to open it.

VirtualBox won't open or install fails?

Make sure you ran the installer as an Administrator. Right-click the installer file and select Run as administrator. If you have a previous VirtualBox version installed that seems broken, uninstall it first from Settings > Apps, reboot, then try installing again.

Need more help? Help me troubleshoot my VirtualBox installation on Windows.

Import the Wazuh OVA

Wazuh provides a pre-built virtual appliance (an OVA file) that bundles the Wazuh server, indexer, and dashboard on Amazon Linux 2023. Instead of installing each component manually, you import one file and everything is ready.

How big is the download?

The OVA file is several gigabytes. The download may take a few minutes depending on your internet speed. While it downloads, keep VirtualBox open and ready.

  • In VirtualBox, click File in the top menu bar.
  • Click Import Appliance.
  • Click the folder icon next to the file path field and navigate to where you downloaded wazuh-4.14.5.ova.
  • Select the file and click Open.
  • Click Next, then click Import.
  • Wait for the import to finish. This may take 2-3 minutes.

Before starting the VM, you need to change the graphics controller setting. Without this change, the VM window can freeze.

  • In the VirtualBox main window, right-click the newly imported Wazuh VM and select Settings.
  • Click Display in the left panel.
  • If you see a simplified view, click Expert at the top-left of the settings window to switch to Expert mode.
  • Change the Graphics Controller dropdown to VMSVGA.
  • Click OK to save.

Avoid time skew

You can also prevent time drift by going to Settings > System, switching to Expert mode, clicking the Motherboard sub-tab, and enabling Hardware Clock in UTC Time under Features. This is optional but recommended.

  • With the Wazuh VM selected, click Start (the green arrow) to boot the VM.
  • Wait for the login prompt to appear. This may take 1-2 minutes on first boot.
  • Log in with username wazuh-user and password wazuh.

Why these credentials?

The Wazuh OVA ships with a pre-configured user account. The wazuh-user account has sudo privileges, so you can run administrative commands when needed. Direct root login is disabled for security.

  • Find the VM's IP address by running this command inside the VM:
ip a
  • Look for the IP address on the main network interface (typically enp0s3 or similar). It will look like 192.168.x.x or 10.0.x.x.
  • Write down this IP address. You will use it throughout the rest of the project.

Don't see an IP address?

If the interface only shows 127.0.0.1 (localhost), the VM is not connected to your network. Shut down the VM, go to Settings > Network, change Attached to to Bridged Adapter, and start the VM again.

Still stuck? Help me get a network IP address on my Wazuh VirtualBox VM.

Access the Wazuh dashboard

The Wazuh dashboard is a web interface where you'll view security alerts, manage agents, and investigate threats. It runs inside the VM and is accessible from your Windows browser.

  • On your Windows machine, open your web browser.
  • Navigate to the following URL, replacing the IP with your Wazuh VM's IP address:
https://[[WAZUH_VM_IP="your Wazuh VM IP address"]]
  • Your browser will show a security warning about the certificate. This is expected for a fresh local installation using a self-signed certificate.
  • Click Advanced (or Show details depending on your browser), then click Proceed or Continue to site.
  • Log in with username admin and password admin.

What is a self-signed certificate?

The Wazuh dashboard uses HTTPS to encrypt traffic. Since the certificate was generated locally (not by a trusted authority like Let's Encrypt), your browser warns you. This is safe for a local lab environment.

You should now see the Wazuh dashboard overview page showing 0 agents connected. This confirms the server, indexer, and dashboard are all running correctly inside your VM.

Dashboard won't load?

Make sure the VM is still running (check the VirtualBox window). Double-check you typed the correct IP address from the ip a output. The dashboard can take 1-2 minutes to become available after the VM boots.

If you see a connection timeout, your Windows machine may not be able to reach the VM. Verify both are on the same network by pinging the VM IP from PowerShell.

Still can't connect? Help me access my Wazuh dashboard from my Windows browser.

Your SIEM server is up and running. Next, you'll connect your Windows machine as a monitored endpoint by deploying the Wazuh agent.

Deploy the Wazuh Agent on Your Windows Machine

Your Wazuh server is up and running, but a SIEM without data sources is like a security camera with no lens. It needs endpoints sending it logs and events to be useful.

In this step, you will install the Wazuh agent on your Windows machine and connect it to the server. Once connected, your PC becomes a monitored endpoint that reports security events back to the SIEM in real time.

In this step, get ready to:
  • Install the Wazuh agent on your Windows machine using PowerShell.
  • Verify the agent appears as active in the Wazuh dashboard.
Download and install the Windows agent

The Wazuh dashboard has a built-in wizard that generates the exact install command for your server's IP address. You will use this to download the agent installer and run it from PowerShell.

  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Agents management > Summary.
  • Click Deploy new agent.
  • Select Windows as the operating system.

The dashboard displays a download link for the MSI installer and a pre-filled installation command containing your server's IP address.

  • Click the download link to save wazuh-agent-4.14.5-1.msi to your computer (it will likely go to your Downloads folder).
  • Press the Windows key to open your search bar.
  • Type PowerShell, then right-click Windows PowerShell and select Run as administrator.
  • Click Yes on the User Account Control prompt that appears.

Why run as administrator?

The Wazuh agent installs a Windows service and modifies system-level configuration. These operations require elevated privileges, which is why you need the Administrator version of PowerShell.

  • Navigate to your Downloads folder by running this command:
cd ~\Downloads
  • Install the Wazuh agent and point it at your server by running this command:
msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="[[WAZUH_VM_IP="your Wazuh VM IP address"]]"

What does this command do?

msiexec.exe is the Windows installer utility. The /i flag tells it to install the specified MSI package. The /q flag runs a silent install (no GUI prompts).

WAZUH_MANAGER tells the agent which server to report to. Replace the IP with the one you found using ip a in the previous step.

  • Start the Wazuh agent service by running this command:
Start-Service wazuhsvc
  • Confirm the service is running by running this command:
Get-Service wazuhsvc

You should see the service listed with a status of Running.

Service not starting?

Make sure you ran PowerShell as Administrator. A regular PowerShell session cannot start system services.

Double-check that the WAZUH_MANAGER IP matches the one from your Wazuh VM. If you entered the wrong IP during install, you can uninstall and reinstall with the correct IP.

Help me troubleshoot my Wazuh agent service not starting on Windows

Verify the agent connection

The agent automatically registers with the Wazuh server when the service starts. It may take 30 to 60 seconds for the dashboard to reflect the new connection.

  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Agents management > Summary.
  • Wait up to 60 seconds, then refresh the page if needed.
  • Your Windows machine should appear as a connected agent with an Active status.
  • Click on the agent to view its details: hostname, OS, agent version, and last keep-alive timestamp.

What is the keep-alive timestamp?

The Wazuh agent sends periodic heartbeat messages to the server to confirm it is still online. The keep-alive timestamp shows when the last heartbeat was received. If this timestamp stops updating, the server marks the agent as disconnected.

Agent not showing up?

Make sure the Wazuh VM is still running in VirtualBox. If the VM lost network connectivity, the agent cannot reach the server.

Verify the agent service is still running by returning to your Administrator PowerShell window and running Get-Service wazuhsvc. If it stopped, run Start-Service wazuhsvc again.

Help me troubleshoot my Wazuh agent not appearing in the dashboard

Your Windows machine is now a monitored endpoint reporting to the Wazuh SIEM. Next up, you will configure File Integrity Monitoring to detect changes to specific files and directories in real time.

Configure File Integrity Monitoring

Your Windows machine is now reporting to the Wazuh server as an active agent. The next goal is to tell Wazuh exactly what to watch on your machine.

File Integrity Monitoring (FIM) tracks changes to files and directories on your endpoints. It detects when files are created, modified, or deleted, and reports those events back to the SIEM. In this step, you will create a test directory, configure the Wazuh agent to monitor it, and verify the initial scan appears in the dashboard.

In this step, get ready to:
  • Create a test directory with a sample file on your Windows machine.
  • Configure the Wazuh agent to monitor the directory with whodata auditing.
  • Verify the FIM baseline scan appears in the dashboard.
Create a test directory and configure FIM

Before Wazuh can monitor anything, it needs a target directory to watch. You will create a folder called C:\siem-test with a sample file inside it, then point the Wazuh agent at that folder.

  • Create the test directory and a sample file by running these commands in your Administrator PowerShell window:
mkdir C:\siem-test
echo "sensitive data" > C:\siem-test\secret.txt

What do these commands do?

  • mkdir C:\siem-test creates a new folder at the root of your C: drive.
  • echo "sensitive data" > C:\siem-test\secret.txt writes the text "sensitive data" into a new file called secret.txt.
  • Confirm the directory and file exist by running:
ls C:\siem-test

You should see secret.txt listed in the output.

Don't see the file?

Make sure you are running PowerShell as Administrator. Without elevated permissions, the mkdir command may fail silently at the C: root.

help me troubleshoot creating the siem-test directory on Windows

Now you need to tell the Wazuh agent to watch this new directory. The agent's behavior is controlled by its ossec.conf configuration file.

  • Open the Wazuh agent configuration file by running this command in your Administrator PowerShell:
notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"
  • In Notepad, press Ctrl+F to open the Find dialog.
  • Search for <syscheck> to locate the File Integrity Monitoring configuration block.
  • Inside the <syscheck> block, add the following line on a new line below the opening <syscheck> tag:
<directories check_all="yes" whodata="yes" report_changes="yes">C:\siem-test</directories>

What does this configuration do?

  • check_all="yes" monitors all file attributes including size, permissions, ownership, timestamps, and checksums.
  • whodata="yes" uses the Windows audit subsystem to capture who made the change and which process they used. This is richer than basic change detection.
  • report_changes="yes" records the exact content that was added or removed from text files, giving you a diff of every modification.

Why whodata instead of realtime?

Wazuh offers two real-time monitoring modes. The realtime option detects changes instantly but only tells you that something changed.

The whodata option goes further by tapping into the Windows audit subsystem. It captures the username, the process (like notepad.exe or explorer.exe), and the timestamp. This is the kind of detail a security analyst needs to investigate incidents.

  • Save the file in Notepad by pressing Ctrl+S.
  • Close Notepad.

Can't save the file?

If you see an "Access is denied" error, it means Notepad was not opened from an Administrator PowerShell session. Close Notepad, confirm your PowerShell window title says "Administrator", and run the notepad command again.

help me fix the access denied error when saving ossec.conf

Restart the agent and verify FIM is active

Configuration changes only take effect after the agent service restarts. Once restarted, the agent performs an initial baseline scan of every monitored directory.

  • Restart the Wazuh agent to apply the new configuration by running this command in your Administrator PowerShell:
Restart-Service -Name wazuh

What does a baseline scan do?

When FIM starts monitoring a new directory, it first records the current state of every file inside it. This "baseline" becomes the reference point. Any future change is compared against this snapshot to determine what was added, modified, or deleted.

  • Wait approximately 30 seconds for the agent to reconnect and complete the baseline scan.
  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Endpoint security in the left sidebar.
  • Click File Integrity Monitoring.
  • Click Events.

You should see an initial scan event for the C:\siem-test directory showing secret.txt was recorded as a new file.

Don't see any FIM events?

  • The baseline scan may take up to 60 seconds. Refresh the page and wait a bit longer.
  • Confirm that you saved ossec.conf before restarting the service. Open the file again and verify your <directories> line is present inside the <syscheck> block.
  • Make sure the <directories> line is not placed outside the <syscheck>...</syscheck> tags. It must be nested inside them.

help me troubleshoot why FIM events are not appearing in the Wazuh dashboard

Your SIEM is now actively watching C:\siem-test for any changes. Next up, you will trigger real file changes and investigate how Wazuh turns them into security alerts.

Trigger and Investigate FIM Alerts

Your File Integrity Monitoring is configured and has completed its baseline scan. Wazuh now knows what "normal" looks like for your C:\siem-test directory.

In this step, you will simulate the kind of file activity an attacker might perform. You will modify a sensitive file, drop a new payload, and delete evidence. Then you will investigate the resulting alerts in the Wazuh dashboard to see exactly what was captured.

In this step, get ready to:
  • Generate file modification, creation, and deletion events in your monitored directory.
  • Investigate the resulting alerts in the Wazuh dashboard.
  • Trace the data flow from the Windows audit subsystem to the dashboard alert.
Generate file change events

You need to trigger three types of file events so Wazuh can demonstrate its detection capabilities. Each action represents something an attacker might do on a compromised system.

  • On your Windows machine, open C:\siem-test\secret.txt in Notepad.
  • Add the text modified by attacker on a new line at the end of the file.
  • Save the file and close Notepad.
  • Wait 5 seconds before the next action.

Why wait between actions?

The 5-second pauses ensure that Wazuh processes each event as a distinct alert. Without the pause, multiple changes can merge into a single detection event.

  • Create a new file in the monitored directory by running this command in PowerShell:
echo "malware payload" > C:\siem-test\payload.txt
  • Wait 5 seconds.
  • Open File Explorer and navigate to C:\siem-test.
  • Select payload.txt, then press the Delete key on your keyboard.

Why delete using File Explorer?

Deleting via File Explorer means the explorer.exe process performs the action. Wazuh's whodata audit captures the exact process name responsible for the deletion. In Step 5, you will write a custom rule that specifically detects deletions made through File Explorer.

You will not see any visible confirmation on your Windows machine yet. The next substep walks you through finding these events in the Wazuh dashboard.

Investigate the alerts in the dashboard

Every file operation you just performed generated a security alert in Wazuh. You will now locate and examine these alerts to understand what the SIEM captured.

  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to File Integrity Monitoring.
  • In the search bar, enter the following filter to show only FIM alerts:
rule.id: is one of 550,553,554

What do these rule IDs mean?

Each rule ID maps to a specific type of file event that Wazuh detected:

  • Rule 550: File modified.
  • Rule 553: File deleted.
  • Rule 554: File added.
  • You should see three alerts corresponding to the file modification, file creation, and file deletion you performed.
  • Click on any alert row to expand its details.

Each expanded alert shows the file path, the user who made the change, the process that performed the action, and the timestamp.

  • Find the modification alert (rule ID 550) for secret.txt and expand it.
  • Look at the syscheck.diff field. This shows the exact content that was changed in the file.

What is syscheck.diff?

Because you enabled report_changes in your FIM configuration, Wazuh stores the before-and-after content of modified files. The syscheck.diff field shows what was added or removed. This is invaluable for forensic investigations.

  • Now find the deletion alert (rule ID 553) for payload.txt and expand it.
  • Notice that the process field shows explorer.exe as the process that deleted the file.

Not seeing all three alerts?

FIM alerts with whodata enabled should appear within a few seconds. If alerts are missing, try these fixes:

  • Wait 30 seconds and refresh the dashboard. Whodata events are near-real-time but network latency can cause a brief delay.
  • Confirm the filter is typed exactly as shown: rule.id: is one of 550,553,554. The syntax is case-sensitive.
  • Check the time range filter in the top-right corner of the dashboard. Make sure it covers the last 15 minutes or more.

Help me troubleshoot missing FIM alerts in my Wazuh dashboard.

Understand the data flow

Take a moment to look at the rule.groups field in any of your expanded alerts. It shows syscheck, which confirms these alerts came from the FIM module.

How did Wazuh detect these changes?

The full detection pipeline works in four stages:

  • The Windows audit subsystem captures the file event (who changed what, using which process).
  • The Wazuh agent on your machine collects the audit event and forwards it to the Wazuh server.
  • The server matches the event against built-in detection rules (550, 553, 554).
  • The dashboard displays the resulting alert with all enriched details.

This is the core loop that every SIEM uses. Endpoints generate telemetry, a central server correlates it against rules, and analysts investigate the results in a dashboard.

You have proven that your SIEM detects file changes in real time and captures forensic-quality detail about who did what. Next, you will write a custom detection rule that targets a specific attacker behavior and maps it to the MITRE ATT&CK framework.

Write a Custom Detection Rule

In the previous step, you investigated FIM alerts and saw how Wazuh's built-in rules detect file changes.

Built-in rules cover general scenarios, but real security teams write custom rules to detect specific threats relevant to their environment. In this step, you will write a custom detection rule that identifies file deletion via File Explorer and maps it to MITRE ATT&CK techniques.

In this step, get ready to:
  • Create a custom rule file on the Wazuh server that maps to MITRE ATT&CK techniques.
  • Test the rule by triggering a file deletion from File Explorer.
  • Verify the custom alert fires in the Wazuh dashboard with the correct severity and technique mapping.
Create the custom rule file on the Wazuh server

Custom rules live on the Wazuh server in /var/ossec/etc/rules/. You will SSH into the Wazuh VM, switch to root, and create a new rule file.

  • Open PowerShell on your Windows machine.
  • SSH into the Wazuh VM by running this command:
ssh wazuh-user@[[WAZUH_VM_IP="your Wazuh VM IP address"]]
  • When prompted for the password, enter wazuh.
  • Switch to root by running:
sudo -i

Connection refused or timed out?

Make sure your Wazuh VM is still running in VirtualBox. Check the VM IP address matches what you entered.

help me troubleshoot SSH connection issues to my Wazuh VM

  • Create the custom rule file by running:
nano /var/ossec/etc/rules/fim_win_delete.xml
  • Paste the following custom rule into the editor:
<group name="syscheck">
  <rule id="100003" level="8">
    <if_sid>553</if_sid>
    <field name="process_name">explorer.exe$</field>
    <description>A user deleted a monitored file using File Explorer - possible evidence tampering</description>
    <mitre>
      <id>T1070.004</id>
      <id>T1485</id>
    </mitre>
  </rule>
</group>

What does this rule do?

This rule builds on top of Wazuh's built-in rule 553 (file deleted). It only fires when the deletion was performed by explorer.exe, which means someone manually deleted the file using File Explorer.

The <mitre> block maps this behavior to two MITRE ATT&CK techniques: T1070.004 (Indicator Removal: File Deletion) and T1485 (Data Destruction). This mapping helps security analysts instantly understand the attacker's likely intent.

  • Save the file by pressing Ctrl+O, then Enter to confirm the filename.
  • Exit the editor by pressing Ctrl+X.

Why rule IDs above 100000?

Wazuh reserves rule IDs below 100000 for built-in rules. User-defined rules should use IDs in the 100000-120000 range to avoid conflicts with current and future built-in rules.

Seeing a permission denied error?

Make sure you ran sudo -i before creating the file. The /var/ossec/etc/rules/ directory requires root access.

help me fix permission issues writing to the Wazuh rules directory

✔️ Awesome, I've got everything!

Great. Double check you saved the file before moving on.

ⓧ I'd like to double check the full code

Here is the complete fim_win_delete.xml file for comparison:

<group name="syscheck">
  <rule id="100003" level="8">
    <if_sid>553</if_sid>
    <field name="process_name">explorer.exe$</field>
    <description>A user deleted a monitored file using File Explorer - possible evidence tampering</description>
    <mitre>
      <id>T1070.004</id>
      <id>T1485</id>
    </mitre>
  </rule>
</group>
Apply and test the custom rule

The Wazuh manager needs a restart to load new rule files. After restarting, you will trigger the rule by deleting a file via File Explorer.

  • Restart the Wazuh manager to load the new rule by running this command (still as root on the Wazuh VM):
systemctl restart wazuh-manager
  • Wait about 10 seconds for the manager to fully restart.

Seeing an error about invalid rule syntax?

If the manager fails to restart, there is likely a typo in your XML file. Open the file again with nano /var/ossec/etc/rules/fim_win_delete.xml and compare it character-by-character with the code above. Make sure all tags are properly closed.

help me debug why my Wazuh custom rule file has invalid XML syntax

  • Switch back to your Windows machine.
  • Create a test file in the monitored directory by opening PowerShell and running:
echo "evidence" > C:\siem-test\evidence.txt
  • Wait 5 seconds for the agent to register the new file.
  • Open File Explorer and navigate to C:\siem-test.
  • Delete evidence.txt using File Explorer (right-click the file and select Delete, or select it and press the Delete key).

Why File Explorer and not the command line?

Your custom rule specifically matches explorer.exe as the process. If you deleted the file using PowerShell, the process would be powershell.exe instead, and your custom rule would not fire.

Verify the custom alert fires
  • Return to the Wazuh dashboard in your browser.
  • Navigate to File Integrity Monitoring.
  • Search for alerts using the filter: rule.id:100003.

You should see your custom alert with level 8 and the description you wrote.

  • Expand the alert to examine the details.

The alert shows your custom description, the MITRE ATT&CK technique IDs (T1070.004: Indicator Removal: File Deletion, T1485: Data Destruction), the user who performed the deletion, and confirmation that explorer.exe was the process.

What is MITRE ATT&CK mapping?

MITRE ATT&CK is a knowledge base of adversary tactics and techniques. By tagging your alert with technique IDs like T1070.004 and T1485, you give security analysts instant context about what an attacker might be trying to accomplish.

In a real SOC, analysts use these mappings to prioritize alerts and understand the stage of an attack.

Not seeing the custom alert?

Make sure you deleted the file using File Explorer, not from the command line. The rule only matches explorer.exe as the process name.

Also confirm the Wazuh manager restarted successfully. SSH back into the VM and run systemctl status wazuh-manager to check its status.

help me troubleshoot why my custom Wazuh rule is not firing

Secret mission

Detect a Persistence Attack via Registry Monitoring

Real attackers don't just steal data. They establish persistence so they can come back later. In this challenge, you'll monitor the Windows Registry Run key (a favorite hiding spot for malware) and write a high-severity detection rule that catches simulated persistence attacks.

Clean Up Your Resources

Clean Up Your Resources

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

Resources you used:

  • VirtualBox VM running the Wazuh OVA (uses disk space on your machine).
  • Wazuh agent installed on your Windows machine (uses approximately 35 MB RAM).
  • Test directory C:\siem-test and test files.
  • Custom rule files on the Wazuh server (fim_win_delete.xml and fim_registry_persist.xml).

Keep everything running

No action needed. Choose this if you are still actively experimenting with detection rules or want to keep monitoring your machine.

  • The Wazuh VM uses approximately 8 GB RAM while running.
  • The Wazuh agent continues to run in the background on your Windows machine, using approximately 35 MB RAM.
  • VirtualBox itself remains installed on your machine. You can use it for other virtual machines in the future.

Pause - I'll come back to this later

Shut down the VM to free up RAM on your machine. The Wazuh agent on Windows will queue events and sync when the server returns.

  • In the Wazuh VM terminal, run the following command to safely shut it down:
  • Alternatively, in VirtualBox, right-click the Wazuh VM and select Close > Save State. This preserves the VM's current state so you can resume instantly.
  • The Wazuh agent on Windows will continue running. It queues events locally and forwards them once the server is available again.
sudo shutdown -h now

When you are ready to return, open VirtualBox and start the Wazuh VM. It will resume accepting events from your agent.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to fully clean up.

  • Uninstall the Wazuh agent from your Windows machine. Open Settings > Apps > Installed apps.
  • Find Wazuh Agent in the list, click the three-dot menu (More), and select Uninstall.
  • Delete the Wazuh VM in VirtualBox. First, make sure the VM is powered off.
  • In VirtualBox Manager, right-click the Wazuh VM in the machine list and select Remove.
  • In the confirmation dialog, click Delete all files to remove the VM and its disk images from your machine.
  • Delete the test directory by opening PowerShell and running:
rmdir /s /q C:\siem-test

What about VirtualBox itself?

VirtualBox is a general-purpose tool you may want to keep for future projects. If you do want to remove it, go to Settings > Apps > Installed apps, find Oracle VirtualBox, and select Uninstall.

Nice Work!

Nice Work!

You just built a fully operational SIEM lab from scratch. Your Windows machine is now a monitored endpoint reporting security events to a Wazuh server, complete with custom detection rules that map to real-world attacker techniques.

You've learned how to:

  • Deploy a complete Wazuh SIEM (server, indexer, dashboard) in VirtualBox and enroll your Windows machine as a monitored endpoint with a live agent connection.
  • Configure File Integrity Monitoring with whodata auditing to detect file creation, modification, and deletion in real time, then investigate alerts in the dashboard to understand the full data flow from endpoint to alert.
  • Write a custom detection rule that identifies evidence tampering (file deletion via File Explorer) and maps it to MITRE ATT&CK techniques T1070.004 and T1485.
  • Secret Mission: Detected a simulated persistence attack by monitoring the Windows Registry Run key and firing a high-severity custom alert mapped to T1547.001.

Ready to quiz yourself?