Post cover image
Figure 2. Wazuh SIEM components running on the Ubuntu server.

September 4, 2026

Building a Practical Windows Threat Detection Lab with Wazuh, Kali Linux, and Ubuntu

From Attack Simulation to SIEM Detection: An End-to-End Cybersecurity Monitoring Lab

By Riad Hossain

9 min read

Cybersecurity cannot be learned effectively by simply installing security tools. A realistic defensive-security environment should demonstrate how an event is generated, collected, transported, detected, and investigated.

In this project, I built a small virtualized security monitoring environment using Kali Linux, Windows 10, Ubuntu, and Wazuh SIEM.

The primary objective was to create an end-to-end detection pipeline where controlled security activities performed from Kali Linux generate telemetry on a Windows endpoint, which is then collected by the Wazuh Agent and analyzed centrally through Wazuh.

The project follows the complete security-monitoring lifecycle:

Generate → Collect → Detect → Investigate

1. Lab Architecture

The lab was deployed using VMware virtual machines connected through a NAT-based virtual network.

Environment

System Role IP Address

Kali Linux Attacker / Security Testing Workstation192.168.235.172

Windows 10 Monitored Endpoint192.168.235.177

Ubuntu Wazuh SIEM Server192.168.235.152

The Ubuntu server hosts the Wazuh single-node stack:

  • Wazuh Manager
  • Wazuh Indexer
  • Wazuh Dashboard

The Windows endpoint runs the Wazuh Agent, which forwards security telemetry to the Wazuh Manager.

Architecture Flow

Controlled Security Testing
                           │
                           ▼
                ┌─────────────────────┐
                │     Kali Linux      │
                │  192.168.235.172    │
                │ Attacker / Testing  │
                └──────────┬──────────┘
                           │
                           │ Network Activity
                           ▼
                ┌─────────────────────┐
                │     Windows 10      │
                │  192.168.235.177    │
                │ Monitored Endpoint  │
                └──────────┬──────────┘
                           │
                           │ Wazuh Agent
                           ▼
                ┌─────────────────────┐
                │       Ubuntu        │
                │  192.168.235.152    │
                │                     │
                │  Wazuh Manager      │
                │  Wazuh Indexer      │
                │  Wazuh Dashboard    │
                └─────────────────────┘

Figure 1. Complete virtualized cybersecurity lab architecture.

Show the VMware environment or your architecture diagram containing all three machines and their roles.

2. Deploying the Wazuh SIEM Infrastructure

The Ubuntu server was configured as the central security monitoring platform.

The Wazuh single-node deployment consists of three primary services:

  1. Wazuh Manager — receives and processes security events.
  2. Wazuh Indexer — stores and indexes security data.
  3. Wazuh Dashboard — provides visualization and investigation capabilities.
None

The screenshot should clearly show the Wazuh Manager, Indexer, and Dashboard containers running. This provides evidence that the core SIEM infrastructure is operational.

Wazuh default credentials:

user: admin | password : SecretPassword

Commands:

sudo systemctl stop docker
sudo systemctl status docker
sudo systemctl start docker
sudo systemctl status docker
docker ps -a
docker start single-node-wazuh.indexer-1
# verify
docker ps | grep single-node-wazuh.indexer  #up ..
docker logs --tail 30 single-node-wazuh.indexer-1

docker start single-node-wazuh.manager-1
docker ps | grep single-node-wazuh.manager
docker logs --tail 30 single-node-wazuh.manager-1
sudo ss -lntup | grep -E '1514|1515|55000'

docker start single-node-wazuh.dashboard-1
docker ps | grep single-node-wazuh
docker logs --tail 50 single-node-wazuh.dashboard-1
sudo ss -lntp | grep ':443'

#test locally
curl -k -I https://127.0.0.1
https://192.168.235.152
#Final Wazuh Status
docker ps -a | grep single-node-wazuh
#output
Wazuh Dashboard    Up
Wazuh Indexer      Up
Wazuh Manager      Up
None

3. Validating Network Connectivity

Before performing security testing, communication between the systems was validated.

Connectivity was tested in both directions where appropriate.

#kali -> Ubuntu
ping 192.168.235.152

#Kali -> Windows
ping 192.168.235.177

#windows -> Ubuntu
ping 192.168.235.152
None None None

Include a clean terminal/PowerShell screenshot showing successful connectivity. Successful network connectivity between the lab components.

This confirms that the attacker workstation, monitored endpoint, and SIEM infrastructure can communicate across the virtual network.

4. Deploying the Wazuh Agent on Windows

The Windows 10 machine was configured as the monitored endpoint.

The Wazuh Agent was installed and configured to communicate with the Wazuh Manager at:

# Ubuntu IP
192.168.235.152

#command in ubuntu
docker exec single-node-wazuh.manager-1 /var/ossec/bin/agent_control -l

After installation, the Wazuh service was started and configured to run automatically.

Show:


# command in windows powershell
msiexec.exe /i "$env:TEMP\wazuh-agent-4.12.0.msi" /q WAZUH_MANAGER="192.168.235.152" WAZUH_AGENT_NAME="dale"

Get-Service WazuhSvc

The expected state is:

Status : Running
StartType : Automatic
None

5. Validating Agent-to-Manager Communication

Running the Wazuh service alone does not prove that telemetry is reaching the SIEM.

Therefore, communication between the Windows Agent and Wazuh Manager was separately validated.

The Wazuh Agent communicates with the Manager through the Wazuh agent communication ports.

Show the Windows connectivity test:

# command in windows powershell
Test-NetConnection 192.168.235.152 -Port 1514
Test-NetConnection 192.168.235.152 -Port 1515

The important result is:

TcpTestSucceeded : True
None

6. Verifying the Agent from the Wazuh Manager

The next validation step was performed from the Ubuntu Wazuh Manager.

The objective was to confirm that the endpoint was not only connected at the network level but was also recognized by the Wazuh Manager.

Show the Wazuh Manager agent list or the relevant agent_control output.

Commands:

# Ubuntu
#Check the wazuh manager container
docker ps | grep single-node-wazuh.manager

#list of all registered wazuh agents
docker exec single-node-wazuh.manager-1 /var/ossec/bin/agent_control -l

#get detailed information about the windows agent using ID
docker exec single-node-wazuh.manager-1 /var/ossec/bin/agent_control -i 002
None

The screenshot should demonstrate:

  • Windows agent registration
  • Agent name
  • Agent ID
  • Active status
  • Windows operating system

This provides stronger evidence than simply showing that the Wazuh service is running.

7. Verifying Windows Security Telemetry

The Wazuh Agent was configured to monitor Windows event logs, including:

  • Application
  • Security
  • System

The agent logs confirmed that Windows event monitoring was active.

Check the Wazuh Agent log — Windows

Open PowerShell as Administrator on your Windows 10 VM and run:

#This shows the latest 100 lines of the Wazuh Agent log
Get-Content "C:\Program Files (x86)\ossec-agent\ossec.log" -Tail 100

Select-String -Path "C:\Program Files (x86)\ossec-agent\ossec.log" -Pattern "Application|Security|System|eventchannel"

#Check whether the Wazuh Agent is running — Windows
Get-Service WazuhSvc

#Verify the Windows Event Logs directly — Windows
Get-WinEvent -ListLog Application,Security,System |
Format-Table LogName, IsEnabled, RecordCount

#Check the Wazuh configuration — Windows
notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"

Look for entries such as:
<localfile>
    <location>Application</location>
    <log_format>eventchannel</log_format>
</localfile>

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

<localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
</localfile>

#The Wazuh Agent log confirms that Windows event channels are being monitored for centralized security telemetry.
Select-String -Path "C:\Program Files (x86)\ossec-agent\ossec.log" -Pattern "Application|Security|System"
None None None None

The screenshot should demonstrate that the agent is monitoring Windows event logs and performing security monitoring functions.

8. Testing File Integrity Monitoring

File Integrity Monitoring (FIM) was tested using a dedicated directory:

C:\CYBR4810-Test

A controlled file was created and modified.

For example:

New-Item "C:\CYBR4810-Test\evidence.txt" -ItemType File -Force
Set-Content "C:\CYBR4810-Test\evidence.txt" "Initial test"
Add-Content "C:\CYBR4810-Test\evidence.txt" "Modified during testing"

Additional controlled operations can include file renaming and deletion.

Show the corresponding syscheck event inside Wazuh Dashboard.

Ideally, this should clearly display:

  • Agent name
  • File path
  • Event/action
  • Timestamp
  • Integrity-monitoring information

Wazuh detecting file-integrity changes on the Windows endpoint.

This creates a complete evidence chain:

File Modification → Windows Endpoint → Wazuh Agent → Wazuh Manager → Wazuh Dashboard

9. Testing Windows Event Collection

A controlled Windows Application event was generated to validate event collection.

The test event used a dedicated provider/source so that it could easily be identified during investigation.

Example:

eventcreate /T INFORMATION /ID 100 /L APPLICATION /SO CYBR4810 /D "CYBR4810 Wazuh telemetry test"

The event was then verified locally:

Get-WinEvent -FilterHashtable @{
    LogName='Application'
    ProviderName='CYBR4810'
} -MaxEvents
None

Show the generated event in PowerShell or Windows Event Viewer.

10. Confirming the Same Event in Wazuh

Generating an event locally is only half of the test.

The important question is:

Did the event travel from Windows to Wazuh successfully?

The corresponding event was therefore searched for inside the Wazuh Dashboard.

Show the event inside Wazuh Dashboard.

Windows Event
       ↓
Wazuh Agent
       ↓
Wazuh Manager
       ↓
Wazuh Indexer
       ↓
Wazuh Dashboard
None None

11. Simulating a Controlled Authentication Failure

To demonstrate security-event detection, a controlled SMB authentication failure was generated from Kali Linux against the Windows test machine.

This was performed only against the isolated lab environment.

The objective was not to perform brute-force activity, but to generate a small number of controlled authentication failures and observe the resulting security telemetry.

Example:

smbclient -L //192.168.235.177 -U admin

An intentionally incorrect password was supplied.

None

Show the Kali Linux terminal containing the controlled authentication attempt.

12. Investigating the Windows Security Log

After generating the authentication failure, the Windows Security log was examined.

A failed authentication event can be investigated using Event ID 4625, where applicable.

Example:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
} -MaxEvents 10 |
Format-List TimeCreated, Id, ProviderName, Message

Windows Authentication Event

None

Show the corresponding Windows Security event.

The screenshot should make the following information visible where available:

  • Event ID
  • Timestamp
  • Account information
  • Failure information
  • Source/network information

This proves that the simulated activity generated security telemetry at the endpoint.

13. Detecting the Authentication Event in Wazuh

The final stage was to determine whether the authentication event was successfully collected and made available for centralized investigation.

The Wazuh Dashboard was searched for the corresponding Windows security event.

None

Show the Wazuh event corresponding to the authentication failure.

The screenshot should ideally display:

  • Windows agent
  • Event ID
  • Source
  • Timestamp
  • Rule information
  • Severity/level where available
  • Relevant authentication details

This is one of the most important screenshots in the project because it connects the simulated activity directly to the SIEM detection.

14. End-to-End Attack-to-Detection Evidence

At this point, the project has demonstrated the complete detection pipeline.

The workflow is:

┌──────────────────────┐
│   Kali Linux         │
│ Controlled Activity  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   Windows 10         │
│ Endpoint Telemetry   │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   Wazuh Agent        │
│ Event Collection     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   Wazuh Manager      │
│ Event Processing     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   Wazuh Indexer      │
│ Event Storage        │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   Wazuh Dashboard    │
│ Detection & Analysis │
└──────────────────────┘
CONTROLLED TEST
                         │
                         ▼
                 Kali Linux (Attacker / Testing)
              192.168.235.172
                         │
                         │ SMB authentication
                         ▼
                 Windows 10
                         │
                         │ Event ID 4625
                         ▼
                 Wazuh Agent
                    ID 002
                    "dale"
                         │
                         │ TCP 1514
                         ▼
              Ubuntu Wazuh Manager
                192.168.235.152
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
       Wazuh alert logs       Wazuh Indexer
              │                     │
              └──────────┬──────────┘
                         ▼
                 Wazuh Dashboard
                         │
                         ▼
              Security Event Details

Complete Detection Chain

Here changed victim IP (192.168.235.177 → 192.168.235.184)

Embedded content

For the most professional presentation, create a single evidence collage containing:

A. Kali attack/activity ↓ B. Windows Security/FIM event ↓ C. Wazuh Dashboard detection

This is the most important visual in the article because it demonstrates that the project is not simply a collection of installed tools — it is a functioning detection pipeline.

15. Evidence-Based Security Monitoring

One of the main lessons from this project is that cybersecurity monitoring should be validated through evidence rather than assumptions.

For every security test, I followed three levels of verification:

Level 1 — Activity Generation

Was the security activity actually performed?

Example: Kali generated a controlled SMB authentication failure.

Level 2 — Endpoint Evidence

Did the Windows endpoint record the activity?

Example: Windows generated the corresponding Security event.

Level 3 — SIEM Detection

Did the Wazuh platform receive and expose the telemetry?

Example: The event became searchable and visible in the Wazuh Dashboard.

This approach provides much stronger validation than simply stating that a SIEM or security agent has been installed.

16. Lessons Learned

Building this environment provided practical experience in several areas of defensive cybersecurity:

  • SIEM deployment and administration
  • Windows endpoint monitoring
  • Wazuh Agent configuration
  • Security-event collection
  • File Integrity Monitoring
  • Windows Security event analysis
  • Controlled attack simulation
  • Centralized log investigation
  • Endpoint-to-SIEM telemetry pipelines
  • Evidence-based security validation

More importantly, the project reinforced the difference between tool deployment and security monitoring.

Installing Wazuh does not demonstrate a working SOC capability. The real validation occurs when a controlled activity generates an endpoint event, the agent collects it, the SIEM processes it, and an analyst can investigate the resulting telemetry.

17. Future Improvements

This lab provides a foundation that can be expanded into a more advanced SOC environment.

Future work could include:

  • MITRE ATT&CK technique mapping
  • Custom Wazuh detection rules
  • Brute-force detection
  • PowerShell activity monitoring
  • Malware behavior simulation
  • Network intrusion detection
  • Vulnerability management
  • Threat hunting
  • Incident-response playbooks
  • Automated alert enrichment
  • Security dashboards and metrics
  • Multi-endpoint monitoring
  • Attack-chain correlation

The goal is to gradually evolve the environment from a basic SIEM laboratory into a more complete Security Operations Center simulation.

Conclusion

This project demonstrates an end-to-end Windows threat-detection workflow using Kali Linux, Windows 10, Ubuntu, and Wazuh.

Rather than focusing only on installation, the project validates each major component through practical testing and visual evidence.

The complete workflow can be summarized as:

Security Activity → Endpoint Telemetry → Agent Collection → SIEM Processing → Centralized Detection → Investigation

The screenshots throughout this project provide evidence that each stage of the pipeline is functioning and establish a reproducible methodology for testing defensive-security capabilities.

For me, this lab represents another step toward developing practical expertise in SOC operations, threat detection, SIEM engineering, incident response, and defensive cybersecurity.