Build a SOC Detection Lab with Wazuh

Introduction

30 Second Summary

Every organization with a network faces threats. Security Operations Centers detect and respond to those threats in real time, but the analysts staffing them need hands-on practice with the same detection tooling they will use in production.

In this project, you will build a local SOC detection lab where your Windows machine acts as a monitored endpoint and an Ubuntu VM runs a full SIEM. You will simulate attacks and watch alerts fire in real time.

What You'll Build

A fully functional SOC detection lab with Wazuh as the SIEM, Sysmon for endpoint telemetry, custom detection rules mapped to MITRE ATT&CK, and Atomic Red Team for adversary simulation.

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

• A running Wazuh SIEM server on an Ubuntu VM, accessible via its web dashboard from your browser.
• Your Windows host reporting detailed endpoint telemetry through Sysmon and a Wazuh agent.
• A custom detection rule mapped to MITRE ATT&CK that fires an alert when you simulate an attack with Atomic Red Team.
• Secret Mission: Write a second detection rule for credential dumping (T1003) and validate it with a real adversary simulation.

Are there any prerequisites?

You should have familiarity with cybersecurity concepts and basic Linux command line skills. You also need VMware already installed on your Windows machine.

Set Up the Wazuh Server VM

Every detection lab needs a central server to collect and analyze security events from your endpoints. This is where your SIEM lives.

In this step, you will create an Ubuntu VM in VMware and install Wazuh, an open-source SIEM platform. By the end, you will have a fully operational Wazuh dashboard ready to receive endpoint data.

In this step, get ready to:

• Create an Ubuntu 24.04 VM in VMware with NAT networking.
• Install the Wazuh all-in-one server (manager, indexer, and dashboard).
• Access the Wazuh dashboard from your Windows browser.

Create the Ubuntu VM in VMware

Your Wazuh server needs a dedicated machine to run on. A virtual machine gives you an isolated environment without needing extra hardware.

• In VMware, click File in the top menu bar.
• Click New Virtual Machine to open the creation wizard.
• Select Custom (advanced) and click Next.
• On the hardware compatibility screen, leave the default and click Next.
• Select Installer disc image file (iso) and browse to your Ubuntu 24.04 LTS ISO file.
• Click Next.
• Select Linux as the guest operating system and choose Ubuntu 64-bit as the version.
• Name your VM Wazuh-Server and click Next.
• Set the number of processors to 2 and click Next.
• Set memory to 4096 MB (4 GB) and click Next.
• For network type, select Use network address translation (NAT) and click Next.
• Accept the defaults for I/O controller and disk type by clicking Next through each screen.
• Select Create a new virtual disk and click Next.
• Set the disk size to 50 GB and click Next.
• Review your settings and click Finish to create the VM.

Why NAT networking?

NAT gives your Ubuntu VM internet access (needed to download the Wazuh installer) while also letting your Windows host reach the VM's IP address on the NAT subnet. This keeps the lab self-contained on your machine.

The VM will power on and boot into the Ubuntu installer. Follow the Ubuntu Server installation prompts.

• Select your language and keyboard layout.
• Choose Ubuntu Server (minimized) when prompted for the installation type.
• Accept the default network configuration (DHCP from NAT).
• Accept the default storage layout and confirm the installation.
• Create a username and password when prompted. Remember these credentials.
• When asked about installing OpenSSH server, select Install OpenSSH server. This lets you connect to the VM from your Windows terminal later.
• Skip any additional snaps and wait for the installation to complete.
• Select Reboot Now when prompted.

After the reboot, log in with the username and password you created during installation.

• Note your VM's IP address by running this command:

ip addr show

• Look for the inet address on your network interface (usually ens33 or eth0). It will look something like 192.168.x.x. Write this IP address down.

Not seeing an IP address?

If you see only 127.0.0.1 (localhost), your network adapter might not be connected. Shut down the VM, open its settings in VMware, confirm the Network Adapter is set to NAT and the Connected checkbox is checked, then power it back on.

help me troubleshoot my VMware Ubuntu VM not getting an IP address

Install Wazuh using the quickstart installer

Wazuh's quickstart installer deploys all three server components (manager, indexer, and dashboard) on a single machine. This is ideal for a lab environment with one monitored endpoint.

• In the VMware console (or SSH into the VM from your Windows host), download and run the Wazuh all-in-one installer:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

What does this command do?

curl -sO downloads the Wazuh installation script silently. The -a flag tells the installer to deploy all components (manager, indexer, dashboard) on this single host.

The installation takes 5-10 minutes depending on your internet speed and VM performance. You will see progress messages scrolling in the terminal.

When the installation completes, the terminal displays a summary with your dashboard credentials.

• Look for the output block that looks like this:

INFO: --- Summary ---
INFO: You can access the web interface https://<WAZUH_DASHBOARD_IP_ADDRESS>
    User: admin
    Password: <ADMIN_PASSWORD>
INFO: Installation finished.

• Copy the password shown in this output and save it somewhere safe. You will need it to log into the dashboard.

Lost the password from the terminal output?

If you accidentally cleared the terminal or missed the password, you can retrieve it by running:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

This extracts the passwords file from the installation archive. Look for the admin user entry.

Installation failing or timing out?

Confirm your VM has internet access by running ping -c 3 google.com. If it fails, check that the VMware network adapter is set to NAT and connected.

If you see memory-related errors, ensure your VM has at least 4 GB RAM allocated in the VMware settings.

help me troubleshoot a failed Wazuh quickstart installation on Ubuntu

Verify the Wazuh dashboard is accessible

The Wazuh dashboard is a web interface that displays security events and alerts. You will access it from your Windows browser using the VM's IP address.

• On your Windows host, open a web browser (Chrome, Edge, or Firefox).
• Navigate to https:// followed by the VM IP address you noted earlier (for example, https://192.168.x.x).
• Your browser will show a security warning about an untrusted certificate. This is expected because Wazuh uses a self-signed certificate.
• Click Advanced and then proceed to the site (the exact wording depends on your browser).
• Enter admin as the username and paste the password you recorded from the installer output.
• Click Log in.

You should see the Wazuh dashboard load with a summary page showing 0 agents connected. This confirms your SIEM server is running and ready to receive data.

Why does it say 0 agents?

An agent is a lightweight program installed on an endpoint (like your Windows host) that collects security data and sends it to the Wazuh server. You have not installed any agents yet. That happens in the next step.

Cannot reach the dashboard?

Make sure you are using https:// (not http://). Wazuh only serves the dashboard over HTTPS.

If the page does not load at all, verify you can ping the VM's IP from a Windows Command Prompt. If the ping fails, your VMware NAT network may need to be repaired in the Virtual Network Editor.

help me access my Wazuh dashboard from my Windows host

Your SIEM server is live and waiting for data. Next up, you will install the Wazuh agent and Sysmon on your Windows host so it starts reporting security telemetry into the dashboard.

Install the Wazuh Agent and Sysmon on Windows

Your Wazuh server is running and the dashboard is live. But a SIEM with no data is like a security camera pointed at a blank wall.

In this step, you will connect your Windows host to the Wazuh server so it starts sending security logs. You will also install Sysmon, a deep telemetry tool that captures process creation, network connections, and file changes that native Windows logging misses.

In this step, get ready to:

• Install the Wazuh agent on your Windows host and confirm it reports to the dashboard.
• Install Sysmon with the SwiftOnSecurity configuration for deep endpoint visibility.
• Configure the Wazuh agent to collect Sysmon logs and verify they appear in the dashboard.

Install the Wazuh agent on your Windows host

The Wazuh agent is a lightweight service that runs on your endpoint and ships logs to the Wazuh server. The Wazuh dashboard provides a guided deployment wizard that generates the correct install command for your operating system and server IP.

• Switch back to the Wazuh dashboard in your Windows browser.
• In the left sidebar, click Agents management.
• Click Summary.
• Click the Deploy new agent button.
• Select Windows as the operating system.
• In the server address field, enter your Ubuntu VM's IP address (the same one you used to access the dashboard).
• Copy the generated install command. It will look similar to a PowerShell Invoke-WebRequest command that downloads and runs the Wazuh agent MSI.

• Open PowerShell as Administrator on your Windows host by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
• Paste and run the install command you copied from the dashboard.
• After installation completes, start the Wazuh agent service by running:

NET START WazuhSvc

What does this command do?

NET START WazuhSvc starts the Wazuh agent Windows service. Once running, the agent establishes an encrypted connection to your Wazuh server and begins sending log data.

• Return to the Wazuh dashboard in your browser.
• Navigate back to Agents management > Summary. You should see 1 active agent displayed. It may take 30-60 seconds to appear.

Don't see your agent?

Make sure you ran the PowerShell commands as Administrator. A non-elevated shell cannot install or start Windows services.

Double-check that the server address you entered in the deployment wizard matches your Ubuntu VM's IP exactly. You can verify the VM IP by running ip addr show in the VM console.

If the agent still does not appear, confirm the VM's firewall allows inbound connections on port 1514 (Wazuh agent communication port).

Need more help? Why isn't my Wazuh agent connecting to the server?

Install Sysmon with the SwiftOnSecurity configuration

Native Windows Event Logging captures basic events, but it misses critical details like full command-line arguments on process creation and outbound network connections. Sysmon fills these gaps by generating rich telemetry across dozens of event types.

What is Sysmon?

Sysmon (System Monitor) is a Windows system service from Microsoft Sysinternals. It logs process creations with full command lines, network connections, file creation time changes, and more to a dedicated Windows Event Log channel.

The SwiftOnSecurity configuration is a community-maintained XML file that tunes Sysmon to capture security-relevant events while filtering out noise. It is the standard starting config used in real SOC environments.

• Download Sysmon from the Microsoft Sysinternals page: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon.
• Download the SwiftOnSecurity config file from: https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml. Click the Raw button, then save the page as sysmonconfig-export.xml.
• Create a folder at C:\Sysmon.
• Extract sysmon64.exe from the Sysmon download into C:\Sysmon.
• Move sysmonconfig-export.xml into C:\Sysmon as well.

• Open Command Prompt as Administrator by pressing the Windows key, typing cmd, right-clicking Command Prompt, and selecting Run as administrator.
• Install Sysmon with the SwiftOnSecurity config by running these commands:

cd C:\Sysmon
sysmon64 -accepteula -i sysmonconfig-export.xml

What does this command do?

sysmon64 -accepteula -i sysmonconfig-export.xml installs the Sysmon service and driver on your machine, accepting the license agreement and loading the SwiftOnSecurity configuration. From this point on, Sysmon logs detailed telemetry for every process creation, network connection, and file change.

• Verify Sysmon is logging by opening Event Viewer. Press the Windows key, type Event Viewer, and press Enter.
• In the left panel, expand Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.
• You should see events already appearing (Event IDs 1, 3, 11, etc.). These are Sysmon capturing system activity in real time.

Don't see the Sysmon log?

Make sure you ran the install command from an elevated Command Prompt. Sysmon requires administrator privileges to install its kernel driver.

Check that both sysmon64.exe and sysmonconfig-export.xml are in the same C:\Sysmon folder. If the config file is missing or misnamed, Sysmon installs with defaults and may not create the expected log channel.

Still stuck? Help me troubleshoot my Sysmon installation.

Configure the Wazuh agent to collect Sysmon logs

Sysmon is now generating telemetry, but the Wazuh agent does not collect it by default. You need to tell the agent to read the Sysmon event channel and forward those events to the server.

• Open the Wazuh agent configuration file at C:\Program Files (x86)\ossec-agent\ossec.conf in a text editor. Right-click the file and select Open with > Notepad (run Notepad as Administrator first, or you will not be able to save).
• Find the <ossec_config> block in the file. Add the following XML inside it, near the other <localfile> entries:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

What does this configuration do?

This tells the Wazuh agent to subscribe to the Microsoft-Windows-Sysmon/Operational event channel using the eventchannel log format. The agent will read every Sysmon event and forward it to the Wazuh server for analysis and rule matching.

• Save the file in Notepad (Ctrl+S).
• Restart the Wazuh agent service to apply the new configuration by running these commands in your elevated PowerShell:

NET STOP WazuhSvc
NET START WazuhSvc

Why stop and start?

The Wazuh agent reads ossec.conf at startup. Stopping and restarting the service forces it to reload the configuration, including the new Sysmon log channel you just added.

• Return to the Wazuh dashboard in your browser.
• Click on your agent's name to open its detail view.
• Navigate to the agent's events section. You should see Sysmon events appearing with Event IDs like 1 (Process Creation), 3 (Network Connection), and 11 (File Created). It may take 1-2 minutes for events to populate.

Not seeing Sysmon events in the dashboard?

Make sure you saved ossec.conf with Notepad running as Administrator. If Notepad was not elevated, the save silently fails or writes to a different location.

Verify the XML you added is well-formed. A missing closing tag like </localfile> or a typo in Microsoft-Windows-Sysmon/Operational will prevent the agent from reading the channel.

Confirm the agent restarted successfully by running NET START WazuhSvc again. If it says the service is already running, the restart worked.

Need help? Why aren't Sysmon events showing in my Wazuh dashboard?

✔️ Awesome, I've got everything!

Great. Double check you have saved ossec.conf and restarted the Wazuh agent service.

ⓧ I'd like to double check the full code

Your ossec.conf file at C:\Program Files (x86)\ossec-agent\ossec.conf should contain the following block somewhere inside <ossec_config>:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Your Windows host is now fully instrumented. The Wazuh agent is forwarding rich Sysmon telemetry to your SIEM server in real time. Next up, you will write a custom detection rule that turns this raw data into actionable alerts.

Write a Custom Detection Rule

Your Windows host is now streaming rich Sysmon telemetry into the Wazuh SIEM. Raw logs are flowing, but without detection rules those logs are just noise.

In this step, you will write a custom Wazuh detection rule that fires an alert whenever PowerShell is spawned from CMD. This pattern is a common attacker technique mapped to MITRE ATT&CK technique T1059.001 (Command and Scripting Interpreter: PowerShell).

In this step, get ready to:

• Explore Wazuh's custom rule structure and file location.
• Write a detection rule for PowerShell execution via CMD.
• Verify the rule loads without errors after restarting the Wazuh manager.

Understand Wazuh rule structure

Wazuh uses XML-based rules to match decoded log events and generate alerts. Each rule has a numeric ID, a severity level, and detection logic that chains off a parent rule.

• Custom rules live in /var/ossec/etc/rules/local_rules.xml on the Wazuh server. This file is preserved during upgrades.
• Custom rule IDs must start at 100000 or above to avoid conflicts with built-in rules.
• The <if_sid> tag chains your rule off a parent rule. When the parent fires, Wazuh evaluates your rule's additional conditions against the same event.

What is a parent rule?

Wazuh ships with thousands of built-in rules. Rather than writing detection logic from scratch, you chain off an existing parent rule that has already decoded the event type you care about. For Sysmon Event ID 1 (process creation), the built-in parent rule is 61603. Your custom rule adds extra conditions on top of it.

• SSH into your Ubuntu VM by running this command:

ssh [[VM_USER="your-ubuntu-username"]]@[[VM_IP="your Ubuntu VM IP address"]]

Connection refused?

Make sure your Ubuntu VM is powered on in VMware and the network adapter is set to NAT. You can also use the VMware console directly instead of SSH.

help me connect to my Ubuntu VM from my Windows host

Write a detection rule for PowerShell execution (MITRE T1059.001)

Your rule will detect when powershell.exe is spawned as a child process of cmd.exe. Attackers frequently use this pattern to execute PowerShell payloads from a command prompt to evade basic logging.

• Open the custom rules file for editing by running:

sudo nano /var/ossec/etc/rules/local_rules.xml

• Add the following detection rule inside the file:

<group name="custom_sysmon,">
  <rule id="100002" level="12">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.parentImage" type="pcre2">(?i)cmd\.exe</field>
    <field name="win.eventdata.image" type="pcre2">(?i)powershell\.exe</field>
    <description>PowerShell spawned from CMD - possible T1059.001 execution</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>
</group>

What does this rule do?

Each element plays a specific role in the detection logic:

• group name="custom_sysmon," creates a named rule group so you can organize related detections together.
• rule id="100002" level="12" sets the rule ID and severity. Level 12 is a high-severity alert.
• if_sid>61603 chains off Wazuh's built-in rule for Sysmon Event ID 1 (process creation).
• The two <field> elements use case-insensitive regex ((?i)) to match cmd.exe as the parent process and powershell.exe as the spawned process.
• The <mitre> block maps the alert to MITRE ATT&CK technique T1059.001, making it visible in the framework's dashboard view.

• Save the file by pressing Ctrl+O then Enter, and exit nano by pressing Ctrl+X.
• Restart the Wazuh manager to load the new rule by running:

sudo systemctl restart wazuh-manager

• Confirm the rule loaded without errors by running:

sudo cat /var/ossec/logs/ossec.log | grep "Rule" | tail -5

You should see log lines referencing rules being read and loaded successfully. If any line mentions an error related to your rule file, double-check the XML syntax in local_rules.xml.

Seeing a rule syntax error?

The most common causes are mismatched XML tags or a missing closing </group> tag. Open the file again with sudo nano /var/ossec/etc/rules/local_rules.xml and verify every opening tag has a matching close.

Make sure the <field> elements use type="pcre2" (not pcre or regex). Wazuh 4.14.5 requires pcre2 for field-level pattern matching.

help me fix my Wazuh custom rule XML

✔️ Awesome, I've got everything!

Great. Make sure you have saved local_rules.xml and confirmed the rule loaded without errors.

ⓧ I'd like to double check the full code

Here is the complete content of /var/ossec/etc/rules/local_rules.xml:

<group name="custom_sysmon,">
  <rule id="100002" level="12">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.parentImage" type="pcre2">(?i)cmd\.exe</field>
    <field name="win.eventdata.image" type="pcre2">(?i)powershell\.exe</field>
    <description>PowerShell spawned from CMD - possible T1059.001 execution</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>
</group>

Your detection rule is live and waiting for a matching event. Next up, you will simulate the exact attack it detects using Atomic Red Team and watch the alert fire in your Wazuh dashboard.

Simulate an Attack with Atomic Red Team

In the previous step, you wrote a custom detection rule that watches for PowerShell being spawned from CMD. The rule is loaded and waiting. But how do you know it actually works?

In this step, you will install Atomic Red Team on your Windows host and use it to simulate the exact attack technique your rule detects. Then you will confirm that the alert fires in the Wazuh dashboard with the correct MITRE ATT&CK mapping.

In this step, get ready to:

• Install Atomic Red Team on your Windows host.
• Run the T1059.001 atomic test to trigger your detection rule.
• Verify the alert appears in the Wazuh dashboard with MITRE mapping.

Install Atomic Red Team on your Windows host

Atomic Red Team is a library of small, focused tests mapped to MITRE ATT&CK techniques. Each test simulates one adversary behavior so you can validate that your detection rules fire correctly.

• Open an elevated PowerShell prompt on your Windows host by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
• Set the execution policy and install Atomic Red Team by running these commands:

Set-ExecutionPolicy Bypass -Scope CurrentUser -Force
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); Install-AtomicRedTeam -getAtomics -Force

What do these commands do?

The first line sets PowerShell's execution policy to Bypass for the current user, allowing downloaded scripts to run without being blocked.

The second line downloads the Atomic Red Team installer script and immediately runs it. The -getAtomics flag downloads the full library of attack technique tests. The -Force flag skips confirmation prompts.

• Wait for the download and installation to complete. This may take a few minutes as it pulls the full atomics library.
• Confirm the installation succeeded by checking that C:\AtomicRedTeam exists. Run:

ls C:\AtomicRedTeam

• You should see folders including atomics and invoke-atomicredteam in the output.

Installation failed or directory not found?

• Make sure your PowerShell prompt is elevated (running as administrator). The installer needs admin permissions to write to C:\.
• If you see a network error, check that your Windows host has internet access. The script downloads files from GitHub.
• If your antivirus blocks the download, you may need to add an exclusion for C:\AtomicRedTeam temporarily.

Help me troubleshoot Atomic Red Team installation issues on Windows.

• Import the Invoke-AtomicRedTeam module into your current PowerShell session by running:

Import-Module "C:\AtomicRedTeam\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1" -Force

• The module loads silently. If you see no error output, it imported successfully.

Run the T1059.001 (PowerShell) atomic test

Your custom rule 100002 detects PowerShell being spawned from CMD. To trigger it, you need to create exactly that parent-child process relationship so Sysmon logs it and Wazuh matches the rule.

• Open a regular Command Prompt window (not PowerShell). Press the Windows key, type cmd, and press Enter.
• Trigger your detection rule by launching PowerShell from CMD with this command:

cmd.exe /c powershell.exe -Command "Write-Host 'T1059.001 Test'"

Why run it this way?

Your rule checks that the parent process is cmd.exe and the child process is powershell.exe. Running this from a CMD prompt creates exactly that process tree. Sysmon logs it as Event ID 1 (Process Creation), which Wazuh ingests and matches against rule 100002.

• You should see T1059.001 Test printed in the CMD window, confirming PowerShell executed.
• For a more realistic simulation using Atomic Red Team, switch back to your elevated PowerShell prompt and run:

Invoke-AtomicTest T1059.001 -TestNumbers 1

What does this test do?

This runs the first atomic test for MITRE technique T1059.001 (Command and Scripting Interpreter: PowerShell). It executes a PowerShell command that simulates adversary use of the interpreter, generating telemetry that your rule can detect.

• The test output shows each step it performs. Let it complete before moving on.

Test failed to run?

• Make sure you imported the module in the same session. If you opened a new PowerShell window, run the Import-Module command again.
• Check that C:\AtomicRedTeam\atomics\T1059.001 exists. If not, the atomics were not downloaded. Re-run the install with -getAtomics.

Help me troubleshoot why Invoke-AtomicTest is not running my T1059.001 test.

Verify the alert fired in Wazuh

The attack simulation generated Sysmon events on your Windows host. The Wazuh agent forwarded them to the server, and the manager evaluated them against your custom rule. Now you will confirm the alert appeared.

• Switch to your browser where the Wazuh dashboard is open.
• Click the menu icon in the upper left corner.
• Select Threat Hunting from the navigation menu.
• In the search bar at the top, type the following filter and press Enter:

rule.id:100002

• You should see one or more alerts with the description PowerShell spawned from CMD - possible T1059.001 execution.
• Click on one of the alerts to expand its details.
• Look for the MITRE ATT&CK section in the alert details. Confirm that technique T1059.001 is mapped.

What should I see?

The alert detail view shows the full event data including the parent image (cmd.exe), the child image (powershell.exe), the rule level (12), and the MITRE technique ID. This is the same workflow a SOC analyst follows to investigate real alerts.

Allow a few minutes for events to appear

Wazuh processes events in near real-time, but there may be a short delay between the attack simulation and the alert appearing in the dashboard. If you do not see results immediately, wait 1-2 minutes and refresh the page.

No alerts showing for rule 100002?

• Verify the Wazuh agent is still active. In the dashboard, check that your Windows agent shows as connected.
• Confirm you ran the cmd.exe /c powershell.exe command from a CMD window, not from PowerShell. The parent process must be cmd.exe for the rule to match.
• SSH into the Ubuntu VM and check if the rule loaded without errors:

sudo cat /var/ossec/logs/ossec.log | grep "Rule" | tail -5

Help me figure out why my custom Wazuh rule 100002 is not generating alerts when I run PowerShell from CMD.

You have now completed the full detection engineering cycle. You deployed a SIEM, ingested endpoint telemetry, wrote a detection rule, simulated an attack, and confirmed the alert fires with the correct MITRE ATT&CK mapping.

Secret mission

Detect Credential Dumping (T1003)

You have one detection rule firing alerts. Real SOC environments need layered coverage across multiple MITRE ATT&CK techniques. In this secret mission, you will write a second custom rule from scratch to detect credential dumping, then validate it with Atomic Red Team.

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 your VMware VM and Windows host, so there are no ongoing cloud costs.

Resources you used:

• Ubuntu VM running Wazuh (manager, indexer, dashboard) in VMware.
• Wazuh agent installed on your Windows host.
• Sysmon installed on your Windows host (C:\Sysmon).
• Atomic Red Team installed at C:\AtomicRedTeam on your Windows host.

Keep everything running

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

• Your Ubuntu VM continues running Wazuh and collecting events from your Windows host.
• Sysmon and the Wazuh agent continue logging on your Windows host. This uses minimal system resources.
• Atomic Red Team remains installed for future attack simulations.

Pause - I'll come back to this later

Shut down running processes to free up memory and disk I/O while keeping all files intact for later.

• Stop the Wazuh agent on your Windows host. Open an elevated Command Prompt and run:

NET STOP WazuhSvc

• Suspend the Ubuntu VM in VMware. Right-click the VM and select Suspend. The VM state is saved to disk and released from RAM.
• When you are ready to resume, power the VM back on and run NET START WazuhSvc in an elevated Command Prompt on your Windows host. The agent queues logs until the server is reachable.

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:

• Open Settings on your Windows host.
• Select Apps, then Installed apps.
• Find Wazuh Agent in the list, click the three-dot menu, and select Uninstall.

Uninstall Sysmon:

• Open an elevated Command Prompt and run:

cd C:\Sysmon
sysmon64 -u

Delete the Sysmon folder:

• In the same elevated Command Prompt, run:

rmdir /s /q C:\Sysmon

Delete Atomic Red Team:

• In the same elevated Command Prompt, run:

rmdir /s /q C:\AtomicRedTeam

Delete the Ubuntu VM:

• In VMware, right-click the Ubuntu VM and select Delete from Disk. This removes the VM and all associated virtual disk files.

Nice Work!

Nice Work!

You just built a fully operational SOC detection lab from scratch. Your Windows machine is now a monitored endpoint feeding real-time telemetry into a SIEM you deployed yourself.

You've learned how to:

• Deploy a full Wazuh SIEM server on an Ubuntu VM and connect your Windows host as a monitored endpoint with Sysmon telemetry.
• Write a custom detection rule mapped to MITRE ATT&CK T1059.001 that fires when PowerShell is spawned from CMD.
• Simulate real attack techniques using Atomic Red Team and verify alerts fire in the Wazuh dashboard with correct MITRE technique mapping.
• Secret Mission: Detected credential dumping (T1003) with a custom rule validated by Atomic Red Team.

Ready to quiz yourself?