Detect Network Scans with Wazuh SIEM

Build a SIEM lab to detect nmap network scans using Wazuh and Suricata.

Introduction

30 Second Summary

Every network connected to the internet gets probed by attackers looking for open doors. Security teams rely on monitoring tools that detect these scans the instant they happen, so they can respond before real damage is done.

In this project, you will build a complete security monitoring lab on your local machine using Wazuh, an open-source SIEM. You'll deploy a monitored endpoint, scan it with Nmap, and watch real alerts appear in your dashboard.

What You'll Build

A local SIEM lab with a Wazuh server, a monitored agent running Suricata network intrusion detection, and Nmap as your attacker tool.

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

A Wazuh SIEM server (indexer, server, and dashboard) running on an Ubuntu virtual machine.
A monitored endpoint with a Wazuh agent and Suricata network intrusion detection system.
Real security alerts generated by network scans, visible and investigable in your Wazuh dashboard.
Secret Mission: Write a custom Wazuh detection rule that fires when it detects your specific scan pattern.

Are there any prerequisites?

You need a Windows PC with at least 24 GB of RAM and VirtualBox already installed. A stable internet connection is also required for downloading the Ubuntu ISO and packages during setup.

Set Up Downloads and Network

Before you can detect network attacks, you need an environment to work in. A SIEM lab requires at least two machines: one that watches for threats, and one that gets watched.

In this step, you will download the files you need, install your scanning tool, and create two virtual machines connected by a private network. This gives you a self-contained lab where you can safely simulate attacks without touching the real internet.

In this step, get ready to:

Download Ubuntu Server ISO and install Nmap on your Windows host.
Create a VirtualBox host-only network for private lab communication.
Create two virtual machines with the correct resource allocations.

Download Ubuntu Server ISO and install Nmap

You need two things downloaded before you can build the lab: the operating system for your VMs, and the scanning tool you will use to simulate an attack from your Windows host.

Open your web browser and navigate to the Ubuntu Server download page:
https://releases.ubuntu.com/noble/ubuntu-24.04.4-live-server-amd64.iso
Save the file to your Downloads folder. This is a 3.2 GB download, so it may take several minutes. You only need one ISO because both VMs use the same image.

What is Ubuntu Server?

Ubuntu Server is a Linux operating system designed to run services without a graphical desktop. It uses fewer resources than a desktop OS, which is ideal for virtual machines that need to stay lightweight.

While the ISO downloads, download Nmap 7.99 from this link:
https://nmap.org/dist/nmap-7.99-setup.exe
Once downloaded, double-click nmap-7.99-setup.exe to run the installer.

What will the installer ask you?

The Nmap installer walks you through panels for choosing an install path and selecting components. It also installs Npcap, the packet capture driver that Nmap needs to send raw network packets. Leave all checkboxes at their defaults and click through each panel.

Click through the installer, accepting all defaults. The installer will launch a secondary Npcap installer partway through. Accept its defaults too.
Once installation finishes, close the installer window.
Open a new Command Prompt by pressing the Windows key, typing Command Prompt, and pressing Enter.
Verify Nmap is installed by running this command:

nmap --version

✔️ I see Nmap version 7.99

Nmap is installed and on your PATH. You are ready to move on.

ⓧ 'nmap' is not recognized

This means your Command Prompt does not see Nmap on the system PATH. Try these fixes:

Close this Command Prompt and open a brand new one. The PATH only updates for new terminal sessions.
If a new Command Prompt still does not work, re-run the installer and make sure the Register Nmap Path checkbox is selected.
After re-installing, open another new Command Prompt and try nmap --version again.

What is Nmap?

Nmap is a network scanner. Security teams use it to discover what services are running on a network. Attackers also use it for reconnaissance, which is why SIEMs are configured to detect it.

In this project, you will use Nmap from your Windows host as the "attacker" tool. Your SIEM lab will detect these scans and raise alerts.

Create a VirtualBox host-only network

Your lab needs a private network that connects your Windows host to both VMs. A host-only network keeps all traffic isolated from the real internet, which is exactly what you want for a security lab.

Press the Windows key, type VirtualBox, and press Enter to open it.
In the VirtualBox Manager menu bar, click File.
Hover over Tools, then click Network Manager.
Click the Host-Only Networks tab at the top.
Click Create. A new network adapter appears in the list.
Note the adapter name (typically VirtualBox Host-Only Ethernet Adapter) and its IPv4 address (192.168.56.1). This is your Windows host's IP on the lab network.

What is a host-only network?

A host-only network creates a private virtual network between your Windows host and the VMs. The VMs can talk to each other and to your Windows machine, but nothing goes to the internet through this adapter.

This is perfect for a security lab because it isolates your attack traffic. When you scan a VM with Nmap, those packets stay entirely on your machine.

Don't see the Host-Only Networks tab?

If you are on an older VirtualBox version (before 7.0), the option may be under File > Host Network Manager instead. The functionality is the same. If you do not see either option, ensure VirtualBox is fully up to date.

help me find the Network Manager in my VirtualBox version

Create both virtual machines

You need two VMs: one for the Wazuh SIEM server (which needs significant resources) and one for the monitored agent (which stays lightweight). Both get two network adapters so they can reach the internet for downloads and communicate on your private lab network.

Start with the Wazuh Server VM:

In VirtualBox Manager, click New in the toolbar.
Enter Wazuh-Server as the name.
Set Type to Linux and Version to Ubuntu (64-bit).
Click Next.
Set memory (RAM) to 8192 MB (8 GB).
Set processors to 4 CPUs.
Click Next.
Select Create a Virtual Hard Disk Now and set the disk size to 50 GB. Leave it as dynamically allocated.
Click through to finish creating the VM.

Why does the server need 8 GB RAM?

The Wazuh server runs three components on one machine: the indexer (search engine for alerts), the analysis engine (detection rules), and the dashboard (web UI). Together these need at least 8 GB to run smoothly.

Now add network adapters to the Wazuh Server VM:

Select the Wazuh-Server VM in the left panel, then click Settings.
Go to the Network section.
Under Adapter 1, confirm Attached to is set to NAT. This is the default.
Click the Adapter 2 tab.
Check Enable Network Adapter.
Set Attached to to Host-Only Adapter.
Select the adapter you created earlier (VirtualBox Host-Only Ethernet Adapter) from the Name dropdown.
Click OK to save.

Now create the Agent VM:

Click New again in the toolbar.
Enter Wazuh-Agent as the name.
Set Type to Linux and Version to Ubuntu (64-bit).
Click Next.
Set memory (RAM) to 2048 MB (2 GB).
Set processors to 2 CPUs.
Click Next.
Select Create a Virtual Hard Disk Now and set the disk size to 20 GB. Leave it as dynamically allocated.
Click through to finish creating the VM.

Add network adapters to the Agent VM using the same method:

Select the Wazuh-Agent VM, then click Settings.
Go to the Network section.
Confirm Adapter 1 is set to NAT.
Click the Adapter 2 tab.
Check Enable Network Adapter.
Set Attached to to Host-Only Adapter and select the same adapter name.
Click OK to save.

Why two network adapters on each VM?

NAT lets the VM reach the internet (to download packages during setup). Host-Only lets all three machines (your Windows host, the server VM, and the agent VM) communicate on a private 192.168.56.0/24 network.

The agent VM only needs 2 GB RAM because it runs the lightweight Wazuh agent (approximately 35 MB of memory) plus Suricata. Most of the heavy processing happens on the server.

Confirm both VMs appear in VirtualBox Manager with the correct names and resource allocations.

VMs not showing the right specs?

If the RAM or CPU count looks wrong, right-click the VM and select Settings. Go to System to adjust the memory and processor count. Make sure your host has enough free RAM for both VMs to run simultaneously (8 GB + 2 GB = 10 GB for the VMs alone).

help me fix my VirtualBox VM resource allocation

Your lab foundation is in place. Next up, you will install Ubuntu Server on both VMs and configure their network addresses so they can communicate.

Install Ubuntu on Both VMs

Your two virtual machines are created and ready for an operating system. In this step, you will install Ubuntu Server on both VMs and give each a permanent address on your lab network.

A static IP means the server always lives at the same address. The Wazuh agent needs to know exactly where the server is, so its address cannot change between reboots.

In this step, get ready to:

Install Ubuntu Server 24.04 on the Wazuh Server VM and assign it a static IP.
Install Ubuntu Server 24.04 on the Agent VM and assign it a different static IP.
Verify that all three machines (Windows host, server VM, agent VM) can communicate.

Install Ubuntu on the Wazuh Server VM

The Wazuh Server VM will host the SIEM brain. It needs an operating system before you can install anything else on it.

In VirtualBox Manager, select the Wazuh-Server VM.
Click Settings > Storage.
Under Controller: IDE, click the empty disc icon, then click the disc icon on the right and select Choose a disk file.
Browse to the ubuntu-24.04.4-live-server-amd64.iso you downloaded and click Open.
Click OK to close settings, then click Start to boot the VM.

What will the Ubuntu installer look like?

The installer is a text-based menu you navigate with your arrow keys and Enter. It walks you through language, keyboard, network, storage, and user setup one screen at a time.

Select your language and press Enter.
Choose your keyboard layout and press Done.
On the installer type screen, select Ubuntu Server and press Done.
On the network screen, leave the defaults (DHCP on the NAT adapter is fine for now) and press Done.
Skip the proxy and mirror screens by pressing Done on each.
On the storage screen, leave Use an entire disk checked and press Done.
Confirm the destructive action by selecting Continue.
Set your name, server name, username, and password. Remember these credentials.
On the SSH screen, skip it by pressing Done.
On the featured snaps screen, press Done.
Wait for the installation to complete. When you see Reboot Now, select it and press Enter.

Remove the ISO before rebooting

If the VM tries to boot from the ISO again after reboot, go to Devices > Optical Drives > Remove disk from virtual drive in the VirtualBox menu bar, then reset the VM.

After the VM reboots, log in with the username and password you set during installation.

Now you need to assign a static IP to the host-only interface so the other machines always know where to find this server.

Identify your network interfaces by running this command:

ip a

What am I looking for?

You will see two interfaces besides lo (loopback). One has a 10.x.x.x IP address from NAT. The other (typically enp0s8) is the host-only adapter and may show no IP yet.

The NAT interface (typically enp0s3) gives your VM internet access. The host-only interface (enp0s8) is where you will assign a static IP for lab communication.

Check which Netplan config file exists by running:

ls /etc/netplan/

Open the netplan config file for editing by running:

sudo nano /etc/netplan/50-cloud-init.yaml

Your filename may differ

Some Ubuntu 24.04 installations name the file 00-installer-config.yaml instead. Use whatever filename appeared when you ran ls /etc/netplan/.

Delete everything in the file (select all with Ctrl+K repeated on each line) and replace it with this configuration:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.56.10/24

What does this configuration do?

enp0s3 is your NAT adapter. Setting dhcp4: true lets it automatically get an IP for internet access.

enp0s8 is your host-only adapter. You assign it 192.168.56.10/24 so the server is always reachable at that address on your private lab network.

Save the file by pressing Ctrl+O, then Enter to confirm the filename.
Exit nano by pressing Ctrl+X.
Apply the new network configuration by running:

sudo netplan apply

Verify the static IP was assigned by running:

ip a show enp0s8

You should see 192.168.56.10/24 listed under the enp0s8 interface.

Don't see the IP on enp0s8?

Make sure the YAML indentation uses spaces, not tabs. YAML is strict about whitespace.

Double-check that Adapter 2 is set to Host-Only Adapter in the VM's VirtualBox network settings.

help me troubleshoot why my netplan static IP is not applying on enp0s8

Install Ubuntu on the Agent VM

The Agent VM is the machine that will be monitored. You will repeat the same installation process but assign it a different IP address.

In VirtualBox Manager, select the Wazuh-Agent VM.
Attach the same Ubuntu ISO via Settings > Storage, just as you did for the server.
Click Start to boot the VM and walk through the same Ubuntu installer steps (language, keyboard, Ubuntu Server, use entire disk, set a username and password).
After the install completes and the VM reboots, remove the ISO and log in.

Check which netplan config file exists by running:

ls /etc/netplan/

Open the netplan config file for editing by running:

sudo nano /etc/netplan/50-cloud-init.yaml

Delete everything in the file and replace it with this configuration:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.56.11/24

What changed from the server config?

The only difference is the IP address. The server uses 192.168.56.10 and the agent uses 192.168.56.11. Both are on the same /24 subnet so they can talk to each other directly.

Save the file by pressing Ctrl+O, then Enter, then exit with Ctrl+X.
Apply the new network configuration by running:

sudo netplan apply

Verify the static IP was assigned by running:

ip a show enp0s8

You should see 192.168.56.11/24 listed under enp0s8.

Don't see 192.168.56.11?

Apply the same checks as the server. Confirm the YAML uses spaces (not tabs), the interface name matches what ip a shows, and Adapter 2 is set to Host-Only in VirtualBox.

help me troubleshoot my Agent VM netplan configuration

✔️ Awesome, I've got everything!

Great. Make sure you have saved the netplan file on both VMs and confirmed the static IPs are active.

ⓧ I'd like to double check the full code

Here is the full netplan config for the Wazuh Server VM:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.56.10/24

And here is the full netplan config for the Agent VM:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses:
        - 192.168.56.11/24

Verify connectivity between all machines

Both VMs now have static IPs on the host-only network. The final check is confirming all three machines (your Windows host, the server, and the agent) can reach each other.

On the Wazuh Server VM, ping the agent by running:

ping -c 4 192.168.56.11

You should see 4 reply lines with response times. This confirms the server can reach the agent.

On the Agent VM, ping the server by running:

ping -c 4 192.168.56.10

You should see 4 reply lines confirming the agent can reach the server.

On your Windows host, open Command Prompt and ping both VMs by running:

ping 192.168.56.10

Then ping the agent:

ping 192.168.56.11

Both commands should return replies. This confirms your Windows host can reach both VMs over the host-only network.

Why does this matter?

If pings work, your lab network is correctly configured. All three machines can communicate, which means Nmap scans from Windows will reach the agent, and the agent can report alerts back to the server.

Pings timing out?

If Windows cannot ping the VMs, make sure the host-only network adapter is enabled in VirtualBox (File > Tools > Network Manager) and that both VMs have Adapter 2 attached to the same host-only network.

If one VM cannot ping the other, confirm both VMs have their static IPs active with ip a and that the subnet (/24) matches on both.

help me troubleshoot why my VMs cannot ping each other on the host-only network

Your lab network is live and all three machines can talk to each other. Next up, you will install the Wazuh SIEM server on the server VM and access its dashboard from your Windows browser.

Install Wazuh SIEM Server

Your lab network is up and all three machines can communicate. Now it's time to install the brain of your security operation.

Wazuh is an open-source SIEM that combines three components into one platform: an indexer to store and search alerts, a server to analyze logs and fire detection rules, and a dashboard to investigate incidents visually.

In this step, get ready to:

Install Wazuh's all-in-one package on your server VM.
Retrieve your dashboard admin credentials.
Access the Wazuh dashboard from your Windows browser.

Run the Wazuh quickstart installer

The Wazuh quickstart installer handles the entire setup in one command. It installs the Wazuh Indexer (search engine for alerts), the Wazuh Server/Manager (analysis engine that triggers rules), and the Wazuh Dashboard (web interface for investigation).

On your Wazuh-Server VM terminal (the SSH session or VirtualBox console from earlier), run the installer with 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 server.
sudo bash ./wazuh-install.sh -a runs the script with root privileges.
The -a flag means "all-in-one", installing all three components on this single machine. In production, these would be on separate servers for performance. For a lab, this is perfect.

This installation takes 5-10 minutes. Wait for it to complete fully before moving on.

When it finishes, you should see output confirming all three components installed successfully. The installer also prints the admin password on screen.

Installation stuck or failed?

Make sure your VM has internet access. Run ping google.com to verify. The NAT adapter (enp0s3) provides internet, so if it's not working, check that Adapter 1 is set to NAT in VirtualBox network settings.
Confirm your VM has at least 8 GB RAM allocated. The installer needs this to run all three components. Check in VirtualBox under Settings > System > Base Memory.
If you see a disk space error, make sure your virtual disk has at least 50 GB allocated (it only uses what it needs, so the actual file on your host will be smaller).

Why is the Wazuh installer failing on my Ubuntu Server VM?

Retrieve your dashboard credentials

Wazuh generates random passwords during installation for security. You need the admin password to log into the web dashboard.

Check the installer output in your terminal. The admin password is displayed near the end of the output.
If you missed it or the output scrolled away, extract the password by running this command:

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

What does this command do?

The installer saved all generated credentials inside wazuh-install-files.tar. This command extracts and prints the password file without unpacking everything else.

Find the line for the admin user and note down the password. You will need it in the next substep.

Seeing 'No such file or directory'?

The wazuh-install-files.tar file is created in the directory where you ran the installer. Make sure you are in the same directory. Run ls to check if the file is present.
If the file is not there, the installation may not have completed successfully. Re-run the installer from the previous substep.

Help me find my Wazuh admin password after installation.

Access the Wazuh dashboard from Windows

The Wazuh Dashboard is a web interface that runs on your server VM. Since your Windows host can reach the VM over the host-only network, you can open it directly in your browser.

On your Windows host, open any web browser.
Navigate to: https://192.168.56.10

Why am I seeing a certificate warning?

Wazuh uses a self-signed certificate for HTTPS. Your browser does not trust it because no certificate authority vouches for it. This is completely safe in your own lab.

Click Advanced on the certificate warning page.
Click Proceed to 192.168.56.10 (unsafe) or the equivalent option in your browser.
Enter admin as the username.
Enter the password you retrieved in the previous substep.
Click Log In.

You should see the Wazuh main overview page. It currently shows no agents connected, which is expected. You will fix that in the next step.

What am I looking at?

This is the same interface SOC analysts use to investigate security incidents in real organizations. The dashboard aggregates data from all monitored endpoints, applies detection rules, and surfaces alerts for triage.

Once you connect an agent in the next step, this empty overview will come alive with endpoint data.

Dashboard not loading?

Make sure you typed https:// (not http://). Wazuh only serves over HTTPS.
Verify your Windows host can still reach the VM by running ping 192.168.56.10 in Command Prompt. If the ping fails, check that the Wazuh-Server VM is running.
The dashboard can take 1-2 minutes to become responsive after installation. If it timed out, wait a moment and refresh.

Help me connect to my Wazuh dashboard from my Windows browser.

Your SIEM server is live and ready to receive data. Next, you will deploy the Wazuh agent and Suricata network detection system on your second VM so it can start monitoring traffic and reporting back to this dashboard.

Deploy Wazuh Agent and Suricata

Your Wazuh SIEM server is live and the dashboard is waiting for data. Right now it shows zero connected agents, which means it has nothing to monitor.

In this step, you will deploy two pieces of software onto the agent VM. The first is the Wazuh agent, a lightweight program that collects logs and forwards them to the server. The second is Suricata, a Network Intrusion Detection System (NIDS) that inspects actual network packets for attack signatures.

In this step, get ready to:

Install the Wazuh agent and confirm it appears as Active in the dashboard.
Install Suricata and download thousands of attack signatures.
Connect Suricata's alerts into the Wazuh pipeline so they flow to the dashboard.

Install the Wazuh agent

The Wazuh agent is a lightweight program that runs on any machine you want to monitor. It collects system logs, monitors file changes, and forwards everything to the server for analysis.

In your Wazuh-Agent VM terminal, add the Wazuh repository and install the agent by running these commands:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update
sudo WAZUH_MANAGER="192.168.56.10" apt-get install wazuh-agent

What do these commands do?

The first two lines add Wazuh's package signing key and repository so your system trusts their packages.
apt-get update refreshes the package list to include the new Wazuh repo.
The WAZUH_MANAGER="192.168.56.10" environment variable tells the agent where to find the Wazuh server during installation.

When prompted to confirm the installation, type Y and press Enter.
Enable and start the Wazuh agent service by running these commands:

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

What does this do?

daemon-reload tells systemd to pick up the new service file that the install created.

enable makes the agent start automatically on every boot. start launches it immediately.

Switch to your Windows browser and return to the Wazuh dashboard at https://192.168.56.10.
Click the menu icon (☰) in the top left.
Navigate to Agents management, then click Summary.
You should see your agent listed with a green Active status.

Agent not showing as Active?

Wait 30 seconds and refresh the page. The agent takes a moment to register with the server after starting.
On the agent VM, run sudo systemctl status wazuh-agent to confirm it is running without errors.
Verify the agent can reach the server by running ping 192.168.56.10 from the agent VM.

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

Install Suricata

While the Wazuh agent monitors logs and files on the machine itself, Suricata watches the actual network packets flowing in and out. It compares traffic against thousands of known attack signatures.

Switch back to your Wazuh-Agent VM terminal.
Install Suricata from the official PPA by running these commands:

sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata -y

What is a PPA?

A PPA (Personal Package Archive) is a third-party repository maintained by the software developer. Using the official Suricata PPA ensures you get the latest stable version rather than the potentially outdated one in Ubuntu's default repositories.

The installer will ask you to confirm. Press Enter to accept.
Download the Emerging Threats signature rules by running these commands:

cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz
sudo tar -xvzf emerging.rules.tar.gz && sudo mkdir -p /etc/suricata/rules && sudo mv rules/*.rules /etc/suricata/rules/
sudo chmod 644 /etc/suricata/rules/*.rules

What are Emerging Threats rules?

Emerging Threats is a community-maintained database of thousands of attack signatures. Each rule describes a pattern of network traffic that indicates malicious activity, like a port scan or exploit attempt.

When Nmap scans the agent VM later, Suricata will compare the incoming packets against these signatures and log an alert when it finds a match.

Confirm the rules were extracted by running:

ls /etc/suricata/rules/ | head -10

You should see a list of .rules files (e.g., emerging-scan.rules, emerging-exploit.rules).

No rules files showing up?

Make sure the curl command completed successfully. If it failed, your VM might not have internet access through the NAT adapter.
Test internet connectivity with ping 8.8.8.8. If that fails, check that Adapter 1 in VirtualBox is still set to NAT.

Help me troubleshoot downloading Suricata rules on my agent VM.

Configure Suricata and connect it to Wazuh

Suricata is installed but it does not yet know which network interface to watch or where to find its rules. You also need to tell the Wazuh agent to read Suricata's alert log so the pipeline is complete.

First, confirm your host-only interface name by running:

ip a

Look for the interface with IP 192.168.56.11. It is likely named enp0s8. Note this name down.
Open the Suricata configuration file by running:

sudo nano /etc/suricata/suricata.yaml

Find the HOME_NET variable near the top of the file and set it to:
"192.168.56.0/24"
Find EXTERNAL_NET and set it to:
"any"
Find default-rule-path and set it to:
/etc/suricata/rules
Under rule-files, replace any existing entries with:
- "*.rules"
Scroll down to the af-packet section and set the interface value to your host-only interface name (e.g., enp0s8).
Save the file with Ctrl+O, press Enter, then exit with Ctrl+X.

What do these settings mean?

HOME_NET tells Suricata which IP range is your local network. Traffic from outside this range is considered external.
EXTERNAL_NET set to "any" means Suricata watches for attacks from all sources.
The af-packet interface tells Suricata which network adapter to inspect. You want it watching the host-only adapter because that is where the nmap scans will arrive.

Restart Suricata to apply the new configuration by running:

sudo systemctl restart suricata

Confirm Suricata is running by running:

sudo systemctl status suricata

You should see active (running) in green text.

Suricata failed to start?

Check the error output from systemctl status suricata for clues. A common issue is a typo in the YAML file.
YAML is whitespace-sensitive. Make sure you used spaces (not tabs) and that your edits align with the existing indentation.
Verify the interface name matches exactly what ip a showed earlier.

Help me fix a Suricata configuration error.

Now connect Suricata's output to the Wazuh agent so alerts flow to the dashboard.

Open the Wazuh agent configuration file by running:

sudo nano /var/ossec/etc/ossec.conf

Find the <ossec_config> opening tag and add the following block inside it:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

What does this block do?

This tells the Wazuh agent to read Suricata's alert log (eve.json) and forward its contents to the Wazuh server.

The json log format lets Wazuh parse each field in the alert (source IP, destination, signature) so it can apply its own detection rules on top.

Save the file with Ctrl+O, press Enter, then exit with Ctrl+X.
Restart the Wazuh agent to pick up the new log source by running:

sudo systemctl restart wazuh-agent

Confirm both services are running by checking their status:

sudo systemctl status suricata
sudo systemctl status wazuh-agent

Both should show active (running) in the output.

How does the full pipeline work now?

You just connected a three-stage detection pipeline. Suricata watches network traffic and writes alerts to eve.json.

The Wazuh agent reads eve.json and forwards those alerts to the Wazuh server. The server applies its rules and displays the alerts on the dashboard. This layered approach is how real SOC environments combine multiple detection tools.

✔️ Awesome, I've got everything!

Great. Double check that both services show active (running) and you are good to go.

ⓧ I'd like to double check the full code

Here is the block you added to /var/ossec/etc/ossec.conf on the agent VM:

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Your detection pipeline is fully wired. Next up, you will launch a real network scan from your Windows host and watch the alerts appear in your Wazuh dashboard in real time.

Scan with Nmap and Investigate Alerts

Your entire detection pipeline is now live. The Wazuh agent on your target VM is watching Suricata's alert log and forwarding events to your SIEM server.

In this step, you will play the role of an attacker. You will launch network scans from your Windows host using Nmap, then switch to the defender's chair and investigate the resulting alerts in your Wazuh dashboard.

In this step, get ready to:

Launch a SYN scan against the agent VM from your Windows host.
View Suricata-generated alerts in the Wazuh Threat Hunting module.
Investigate individual alert fields and perform your first alert triage.

Launch an Nmap scan from Windows

The SYN scan (also called a half-open scan) sends TCP SYN packets to each port without completing the full connection handshake. This makes it stealthier than a full connect scan. It is the most common technique attackers use during reconnaissance.

On Windows, the SYN scan requires administrator privileges because it sends raw packets through Npcap.

Press the Windows key to open your search bar.
Type Command Prompt.
Right-click Command Prompt in the results and select Run as administrator.
Click Yes on the User Account Control prompt.

Why run as administrator?

The -sS flag tells Nmap to craft raw TCP SYN packets. On Windows, only administrator-level processes can send raw packets through Npcap. Without elevation, Nmap falls back to a slower TCP connect scan that may not trigger the same Suricata detection signatures.

Run your first scan against the agent VM by entering this command:

nmap -sS -sV 192.168.56.11

What does this command do?

-sS performs a SYN scan (half-open). It sends a SYN packet to each port and waits for the response. A SYN/ACK reply means the port is open. A RST reply means it is closed. Nmap never completes the handshake, so fewer services log the connection.

-sV probes open ports to determine what service and version is running on each one. This is exactly what an attacker would do to map out a target before launching an exploit.

Wait 30-60 seconds for the scan to complete. You should see a table of open ports and detected services in your terminal output.

What should I see?

Nmap prints a table listing each open port, its protocol, state, and the service/version detected. The exact ports depend on what services Ubuntu has running by default (commonly SSH on port 22).

Scan seems stuck or shows no results?

Make sure you right-clicked and selected Run as administrator. Without elevation, raw packet scans may hang or behave unexpectedly.

Verify connectivity first by running ping 192.168.56.11. If the ping fails, check that both VMs are powered on and the host-only network adapter is enabled.

Help me troubleshoot my Nmap scan against 192.168.56.11

View alerts in the Wazuh dashboard

Suricata saw those unusual half-open connections flooding in from a single IP and flagged them. The Wazuh agent read those alerts from /var/log/suricata/eve.json and forwarded them to your server. Time to see the results.

Switch to your Windows browser where the Wazuh dashboard is open at https://192.168.56.10.
In the left sidebar, click Threat Hunting (under the Security operations section or main menu).
In the search bar at the top, type the following filter and press Enter:

rule.groups:suricata

You should see a list of alerts from Suricata showing detected network scan activity.

What am I looking at?

Each row is a security alert. The alerts show that Suricata detected unusual traffic patterns consistent with a port scan. You will see your Windows host IP (192.168.56.1) as the source and the agent VM (192.168.56.11) as the destination.

The Suricata rules that fired come from the Emerging Threats ruleset you installed earlier. They detected a single IP rapidly probing many ports, which is the signature of a port scan.

No alerts showing up?

Alerts can take 30-60 seconds to propagate through the pipeline. Wait a moment and refresh the page.

If alerts still do not appear, SSH into the agent VM and confirm Suricata is running with sudo systemctl status suricata. Also check that the Wazuh agent is active with sudo systemctl status wazuh-agent.

Help me figure out why my Suricata alerts are not appearing in Wazuh

Investigate and understand the alert details

Seeing alerts is only the first step. A SOC analyst needs to dig into each alert to understand what happened, who was involved, and how severe it is. This process is called alert triage.

Click on any individual alert row to expand its details.
Look for these key fields in the expanded alert:

rule.description tells you what the detection rule identified (for example, port scan activity).
data.src_ip shows the attacker's IP. This should be your Windows host: 192.168.56.1.
data.dest_ip shows the target. This should be your agent VM: 192.168.56.11.
data.alert.signature shows the specific Suricata signature that matched the traffic.
rule.level indicates severity. Higher numbers mean more serious alerts.

What is alert triage?

In a real Security Operations Center, analysts receive hundreds or thousands of alerts per day. Triage is the process of quickly reviewing each alert to determine: what was detected, who is involved, when it happened, and whether it is a real threat or a false positive.

You just completed your first triage cycle. You identified the scan source, confirmed the target, and reviewed the detection signature.

Now try a more aggressive scan to see how the alerts change.

Return to your administrator Command Prompt on Windows.
Run an aggressive scan by entering this command:

nmap -A 192.168.56.11

What does the -A flag do?

The -A flag enables aggressive scanning. It combines OS detection, version detection, script scanning, and traceroute into one command. This generates significantly more traffic and triggers additional Suricata signatures.

Wait for the scan to complete (this one may take 1-2 minutes).
Return to the Wazuh dashboard in your browser.
Refresh the Threat Hunting page. You should see new alerts with different signatures and potentially higher severity levels.

Compare the two scans

Notice how the aggressive scan generates more diverse alerts. The -A scan runs NSE scripts and OS fingerprinting probes that trigger different detection rules than the basic SYN scan. In a real investigation, seeing both port scanning AND OS fingerprinting from the same source IP tells you the attacker is in active reconnaissance.

You have just proved that your detection pipeline works end to end. An attacker scans the network, Suricata spots the malicious traffic, and Wazuh surfaces it in a dashboard where you can investigate. Next up, you will take this further by writing your own custom detection rule.

Secret mission

Write a Custom Wazuh Detection Rule

You have a working SIEM that detects scans using generic Suricata signatures. But what if you could write your own detection logic, tailored specifically to your lab environment? That is what senior SOC analysts and detection engineers do every day. In this secret mission, you will write a custom Wazuh rule that fires specifically when YOUR Windows host scans the network.

Clean Up Your Resources

This project runs entirely on your local machine using open-source tools, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Wazuh-Server VM (VirtualBox, up to 50 GB dynamic disk).
Wazuh-Agent VM (VirtualBox, up to 20 GB dynamic disk).
VirtualBox Host-Only Network (192.168.56.0/24).
Nmap 7.99 and Npcap installed on Windows.
Ubuntu Server 24.04 ISO file (~3.2 GB download).

Keep everything running

No action needed. Choose this if you are still actively experimenting with different scan types, writing new detection rules, or exploring the Wazuh dashboard.

Your VMs will continue running in the background and consuming RAM while active.
You can launch new nmap scans from Windows at any time to generate fresh alerts.
The Wazuh dashboard remains accessible at https://192.168.56.10 as long as the Wazuh-Server VM is running.

Pause - I'll come back to this later

Shut down the VMs to free up RAM and CPU on your Windows host. Your VMs and all configurations will be preserved on disk.

In VirtualBox, right-click each VM (Wazuh-Server and Wazuh-Agent) and select Close > Save State. This saves the VM's current memory state so it resumes exactly where you left off.
Alternatively, SSH into each VM and run sudo shutdown now for a clean shutdown. You will need to boot the VMs fresh next time.
To resume, open VirtualBox and start both VMs. The dashboard will be accessible again once the Wazuh-Server VM boots.

Delete - I don't want to use this again

Remove all project resources to reclaim disk space. This is not reversible.

In VirtualBox, right-click the Wazuh-Server VM and select Remove > Delete all files. This permanently deletes the VM and its virtual hard disk.
Right-click the Wazuh-Agent VM and select Remove > Delete all files.
Remove the Host-Only Network. Go to File > Tools > Network Manager. Select the Host-Only Networks tab, select your network, and click Remove.
Uninstall Nmap on Windows. Press the Windows key, type Add or remove programs, and press Enter. Find Nmap in the list and click Uninstall. Do the same for Npcap.
Delete the Ubuntu Server ISO file from your Downloads folder. Right-click ubuntu-24.04.4-live-server-amd64.iso and select Delete.

Nice Work!

You just built a fully functional security monitoring lab from scratch. You deployed a Wazuh SIEM, monitored a target endpoint with network intrusion detection, launched real attacks, and investigated the alerts like a SOC analyst.

You've learned how to:

Deploy a complete SIEM lab with a Wazuh server, indexer, and dashboard running on a local VM.
Install and configure Suricata as a network intrusion detection system feeding real-time alerts into Wazuh.
Execute Nmap reconnaissance scans and investigate the resulting security alerts in the Threat Hunting module.
Secret Mission: Write a custom Wazuh detection rule tailored to your lab environment that fires on your specific scan pattern.

Ready to quiz yourself?