A fully operational blue team home lab — three-VM architecture running Wazuh v4.7.5 as a SIEM/XDR platform on an isolated VMnet2 virtual network, with Windows audit policy hardening, Sysmon telemetry, File Integrity Monitoring, and Security Configuration Assessment producing 256+ real detection events mapped across 5 MITRE ATT&CK tactics.
- Lab Architecture
- Technologies Used
- What This Lab Detects
- MITRE ATT&CK Coverage
- Setup — Windows Endpoint Hardening
- Setup — Wazuh Server
- Setup — Agent Deployment
- Detection Evidence
- File Integrity Monitoring Results
- Security Configuration Assessment
- Lessons Learned
- Future Improvements
Three VMware Workstation virtual machines connected on an isolated VMnet2 (192.168.100.0/24) segment, completely air-gapped from the host’s primary network adapter.
┌──────────────────────────────────────────────────────────────────────┐
│ VMware Workstation — VMnet2 │
│ Isolated Lab Network │
│ 192.168.100.0/24 │
│ │
│ ┌─────────────────────┐ ┌──────────────────────────────┐ │
│ │ LABWIN10 │ │ wazuh-hit (Ubuntu 24.04) │ │
│ │ Windows 10 Edu │─agents─▶│ Wazuh Manager v4.7.5 │ │
│ │ 192.168.100.10 │ logs │ Wazuh Indexer (OpenSearch) │ │
│ │ Wazuh Agent v4.7.5 │ │ Wazuh Dashboard │ │
│ │ Sysmon installed │ │ 192.168.100.30 │ │
│ └─────────────────────┘ └──────────────────────────────┘ │
│ │
│ Telemetry Pipeline: │
│ Windows Audit Logs + Sysmon Events │
│ → Wazuh Agent (port 1514) │
│ → Wazuh Manager (correlation + rules) │
│ → OpenSearch (indexing + storage) │
│ → Wazuh Dashboard (visualization + MITRE mapping) │
└──────────────────────────────────────────────────────────────────────┘
Agent Status — confirmed active:
Agent LABWIN10 (ID 001) —
● active— 100.00% coverage — Wazuh v4.7.5 — Windows 10 Education 10.0.19045.2965 — node01 — last keepalive Mar 11, 2026 @ 19:38
| Component | Version | Role |
|---|---|---|
| VMware Workstation | 17.x | Hypervisor — isolated virtual network (VMnet2) |
| Windows 10 Education | 10.0.19045.2965 | Victim endpoint — LABWIN10 (192.168.100.10) |
| Ubuntu Server | 24.04.4 LTS | Wazuh platform host — wazuh-hit (192.168.100.30) |
| Wazuh Manager | 4.7.5 | SIEM/XDR — correlation engine, rule matching |
| Wazuh Indexer | 4.7.5 | OpenSearch 2.x — log storage and indexing |
| Wazuh Dashboard | 4.7.5 | Kibana-based UI — alerting, MITRE, FIM, SCA |
| Sysmon | 15.x | Windows endpoint telemetry (Event IDs 1, 3, 5, 7, 11, 12, 13) |
| Windows auditpol | Built-in | Fine-grained audit subcategory configuration |
| Group Policy Editor | Built-in | Audit policy and command-line logging in Event 4688 |
| Windows Event ID | Event Type | Configured Via | Result |
|---|---|---|---|
| 4624 | Successful Logon | auditpol + Group Policy | ✅ 208 events captured |
| 4625 | Failed Logon | auditpol + Group Policy | ✅ 4 events captured |
| 4688 | Process Creation (with cmdline) | auditpol + GPO registry key | ✅ Active |
| 4672 | Special Privilege Logon | auditpol | ✅ Active |
| Sysmon 1 | Process Creation | Sysmon | ✅ Active |
| Sysmon 5 | Process Terminated | Sysmon | ✅ 155 events captured |
| FIM Rule 550 | Integrity Checksum Changed (level 7) | Wazuh syscheck | ✅ 256 hits in 24h |
| FIM Rule 554 | File Added to System (level 5) | Wazuh syscheck | ✅ Active |
Wazuh’s MITRE ATT&CK module maps all detected events to adversary techniques in real time:
Real-time MITRE tactic mapping, PCI DSS compliance chart, FIM recent events, and CIS SCA benchmark — all from a single active Windows 10 endpoint.
| Tactic | Alerts | Key Techniques |
|---|---|---|
| Impact | 158 | T1565 Data Manipulation, T1499 Endpoint Denial of Service |
| Defense Evasion | 95 | T1562 Impair Defenses, T1070 Indicator Removal |
| Persistence | 53 | T1547.001 Registry Run Keys, T1543 Create/Modify System Process |
| Privilege Escalation | 53 | T1547 Boot/Logon Autostart, T1068 Exploitation for Privilege Escalation |
| Discovery | 46 | T1082 System Information Discovery, T1057 Process Discovery |
These detections come from normal Windows 10 system activity on LABWIN10. In a real attack scenario, Initial Access, Execution, Credential Access, and Lateral Movement would spike on top of this baseline — making anomaly detection meaningful.
Default Windows 10 generates almost no useful security events. Every detection in this lab required deliberate audit policy configuration first.
gpedit.msc → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies
Logon/Logoff subcategories:
Audit Logon = Success and Failure, Audit Logoff = Success and Failure, Audit Account Lockout = Success and Failure
Detailed Tracking — Process Creation:
Detailed Tracking > Audit Process Creation = Success
Object Access — File System:
Object Access > Audit File System Properties = Success and Failure (both checkboxes ticked)
Account Management:
Account Management > Audit User Account Management = Success and Failure
By default Event ID 4688 captures process creation but omits command-line arguments — making it useless for detecting PowerShell abuse and LOLBins.
Enable via Group Policy:
Administrative Templates → System → Audit Process Creation → Include command line in process creation events → Enabled
“Include command line in process creation events” = Enabled — command-line arguments now written into Event ID 4688
Enabled via registry:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit — ProcessCreationIncludeCmdLine_Enabled DWORD = 1
Policy setting explanation screen:
Policy description: “determines what information is logged in security audit events when a new process has been created… Event 4688”
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
PowerShell (Admin): auditpol /set /subcategory:“Process Creation” /success:enable — “The command was successfully executed.”
Full subcategory batch configuration:
CMD (Admin): Multiple auditpol /set commands — Security Group Management, Process Creation, Audit Policy Change, Sensitive Privilege Use, Logon, Account Lockout, Logoff, Special Logon, User Account Management — all returned “The command was successfully executed.”
Verification — full policy output:
auditpol /get /category: — Logon/Logoff = Success and Failure, Object Access: File System = Success and Failure, Privilege Use: Sensitive Privilege Use = Success and Failure, Detailed Tracking: Process Creation = Success and Failure*
Continued output — Privilege Use, Policy Change: Audit Policy Change = Success and Failure, Account Management: User Account Management = Success and Failure
Sysmon files downloaded to C:\Users\Hitansh\Downloads\Sysmon\:
Windows Explorer: Downloads/Sysmon folder — Eula (8KB), Sysmon (8.2MB), Sysmon64 (4.4MB), Sysmon64a (4.8MB) — all dated 2/21/2026
Sysmon begins capturing telemetry immediately after installation — Event Viewer confirms:
Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational: 155 events. Highlighted Event ID 5 (Process Terminated) with RuleName and UtcTime 2026-02-22 05:08:04.142. Computer: DESKTOP-BDBM5IR
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
chmod +x wazuh-install.sh
sudo bash wazuh-install.sh -a -iFirst attempt (Feb 2026): The wazuh-indexer (OpenSearch/Java) timed out during startup — insufficient heap on the VM. Installation was automatically cleaned and the VM was powered off to add more memory.
First attempt: wazuh-indexer service start timed out. “Failed to start wazuh-indexer.service — Wazuh-Indexer. Unit wazuh-manager.service could not be found.”
Second attempt (Mar 4, 2026) — successful:
Wazuh 4.7.5 complete install log: indexer ✓ (13:52:59), manager ✓ (14:06:15), Filebeat ✓ (14:06:53), dashboard ✓ (14:10:51) — “Installation finished.”
sudo systemctl status wazuh-manager --no-pager
wazuh-manager: active (running) since 2026-03-04 14:06:37 UTC. All child processes listed: wazuh-authd (46410), wazuh-db (46425), wazuh-execd (46437), wazuh-analysisd (46451), wazuh-syscheckd (46476), wazuh-remoted (46491), wazuh-logcollector (46554), wazuh-monitord (46572), wazuh-modulesd (46594)
Both wazuh-dashboard (active/running, Main PID 50740 node, Memory 266.2M) AND wazuh-indexer (active/running since 15:41:30) confirmed simultaneously
The Ubuntu Wazuh server needed its second NIC (ens37) configured on the lab subnet so LABWIN10 could reach it:
ip addr show ens37 confirms ens37 = 192.168.100.30/24 — Wazuh server reachable from LABWIN10 on VMnet2
Windows endpoint dual-NIC confirmed:
PowerShell: ipconfig /all — Ethernet0 = 192.168.100.10 (lab network), Ethernet1 = 192.168.13.133 (NAT). Both interfaces active.
VMware network adapter configuration:
VMware Virtual Machine Settings > Network Adapter > Custom: VMnet2 selected — isolates lab traffic from host network
After installation the Wazuh Dashboard showed “No API available to connect”. Debugging steps:
# Confirm API port is listening
sudo ss -tlnp | grep 55000
sudo ss -tlnp | grep 55000 → LISTEN 0 128 0.0.0.0:55000 users:((“python3”,pid=50130,fd=41)) — API port open and listening
# Confirm API responds (401 = alive, connection refused = down)
curl -k -u wazuh-wui:wazuh-wui https://127.0.0.1:55000
curl response: {“title”:“Unauthorized”,“detail”:“No authorization token provided”} — API is alive, dashboard config needed the correct IP instead of localhost
The Wazuh Dashboard generates the exact PowerShell command under Deploy new agent:
Step 4: Invoke-WebRequest to download wazuh-agent-4.7.5-1.msi with WAZUH_MANAGER=192.168.100.30, WAZUH_AGENT_NAME=LABWIN10, WAZUH_REGISTRATION_SERVER=192.168.100.30. Step 5: NET START WazuhSvc
# Run as Administrator on LABWIN10
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.5-1.msi" `
-OutFile "${env:tmp}\wazuh-agent"
msiexec.exe /i "${env:tmp}\wazuh-agent" /q `
WAZUH_MANAGER='192.168.100.30' `
WAZUH_AGENT_NAME='LABWIN10' `
WAZUH_REGISTRATION_SERVER='192.168.100.30'
NET START WazuhSvc
Windows Explorer: ossec-agent directory — active-response, bookmarks, incoming, logs, queue, rids, ruleset, shared, syscheck, tmp, upgrade, wodles — all folders created on 3/10/2026 11:11 PM
Get-Service WazuhSvc
# Status: Running Name: WazuhSvc DisplayName: Wazuh
PowerShell (Admin) on Windows 10 VM: Get-Service WazuhSvc = Running. NET START WazuhSvc = “The requested service has already been started.” Both VMs visible in VMware sidebar.
| Field | Value |
|---|---|
| Agent ID | 001 |
| Agent Name | LABWIN10 |
| Status | ● active |
| IP Address | 192.168.100.10 |
| Operating System | Microsoft Windows 10 Education 10.0.19045.2965 |
| Wazuh Version | v4.7.5 |
| Cluster Node | node01 |
| Agents Coverage | 100.00% |
| Registration Date | Mar 11, 2026 @ 19:27:30 |
| Last Keepalive | Mar 11, 2026 @ 19:38:23 |
All Wazuh capability modules loaded after the server came online:
Wazuh Dashboard Modules page: Security Information Management (Security events, Integrity monitoring), Auditing and Policy Monitoring (Policy monitoring, System auditing, Security configuration assessment), Threat Detection and Response, Regulatory Compliance
Failed Logon Events (Event ID 4625):
Before audit policy configuration, no failed logins were logged. After configuring auditpol the Security log captured:
Security log filtered for Event ID 4625 (Audit Failure) — 4 events captured at 10:46–10:47 on Feb 22, 2026. Filter dialog shows Event ID 4625 entered.
Successful Logon Events (Event ID 4624):
Event ID 4624 filter — 208 Audit Success events. Event detail: “An account was successfully logged on.” Computer: DESKTOP-BDBM5IR
Process Creation with Command Line (Event ID 4688):
Event ID 4688 Properties: SubjectUserName DESKTOP-BDBM5IR$, NewProcessName C:\Windows\SoftwareDistribution\Download\Install\AM_Delta_Patch_1.445.1840.exe — command-line logging working
Network and IP Configuration (used to verify dual-NIC lab setup):
CMD: whoami = desktop-bdbm5ir\hitansh, net user = Administrator / DefaultAccount / Guest / Hitansh / WDAGUtilityAccount, ipconfig /all = Host Name: DESKTOP-BDBM5IR, IPv4: 192.168.13.131
Wazuh FIM monitors critical Windows directories and alerts on file creation, modification, and deletion.
- Rule 550 (level 7): Integrity checksum changed
- Rule 554 (level 5): File added to the system
Time range: Mar 10, 2026 @ 19:39 → Mar 11, 2026 @ 19:39 (24-hour window) Total events: 256 hits
syscheck.path: c:\programdata\microsoft\diagnosis\eventstore.db-wal
syscheck.event: modified
rule.description: Integrity checksum changed
rule.level: 7
rule.id: 550
timestamp: Mar 11, 2026 @ 19:39:27.282
The spike at 18:00 in the timeline corresponds to Windows Update activity — this is the normal baseline a SOC analyst must understand before writing threshold-based detection rules.
Wazuh SCA runs the CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0 against LABWIN10 on every scan cycle.
SCA Profile: cis_win10_enterprise
Benchmark: CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0
PCI DSS compliance coverage detected on this single endpoint:
| PCI DSS Control | Alert Count |
|---|---|
| 2.2 (System hardening) | 395 |
| 11.5 (File integrity monitoring) | 243 |
| 2.2.5 (Remove unnecessary functionality) | 53 |
| 4.1 (Encrypt transmission) | 44 |
| 10.6.1 (Review logs) | 25 |
Wazuh automatically inventories hardware, OS, network interfaces, and open ports on every registered agent.
The agent overview and inventory data are accessible via the Agents → LABWIN10 → Inventory data tab in the Wazuh Dashboard.
Captured inventory:
- Hostname: DESKTOP-BDBM5IR
- OS: Microsoft Windows 10 Education x86_64 (10.0.19045.2965)
- CPU: 11th Gen Intel Core i3-1115G4 @ 3.00 GHz
- RAM: 2,047.05 MB
- Network interfaces: 3 (Ethernet0, Ethernet1, Loopback Pseudo-Interface 1)
- Open ports: 48 (135 RPC, 137–139 NetBIOS, 445 SMB, 3389 RDP)
- Last scan: Mar 11, 2026 @ 19:35:04
1. Default Windows 10 audit policy captures almost nothing. Without running auditpol across every relevant subcategory, process creation, privilege use, object access, and logon events never appear in the Security log. Configuration is the prerequisite.
2. Command-line logging in Event 4688 is off by default. Without setting ProcessCreationIncludeCmdLine_Enabled = 1 via registry or Group Policy, Event 4688 shows that a process ran but not what command was executed — useless for detecting PowerShell abuse.
3. Wazuh indexer requires memory headroom. The first install attempt failed because the OpenSearch/Java process timed out starting on a VM with insufficient RAM. 4GB minimum for the Wazuh server VM is required.
4. Network segmentation must be deliberate. Both the Windows VM and the Ubuntu server needed explicit VMnet2 adapter configuration. The lab network (192.168.100.0/24) and NAT network (192.168.13.0/24) coexist on dual-NIC VMs without routing conflicts only if the adapter assignments are correct.
5. FIM volume is high on a live Windows endpoint. 256 FIM events in 24 hours from entirely normal system activity. Effective detection engineering requires a baseline before writing threshold rules — otherwise everything is a false positive.
6. Wazuh API returning 401 is good news. “Connection refused” means the API is down. “Unauthorized” (HTTP 401) means the API is alive and the dashboard just needs correct JWT configuration — a critical troubleshooting distinction.
- Run Atomic Red Team simulations and verify per-technique detection coverage
- Write custom Wazuh XML detection rules for specific attack patterns (brute force, PowerShell encoded commands, LOLBins)
- Add Kali Linux as an active attacker VM — Nmap, Hydra, Metasploit against LABWIN10
- Configure Wazuh Active Response to block attacker IPs automatically
- Add Windows Server 2022 with Active Directory to simulate domain-joined enterprise attacks
- Integrate Shuffle SOAR for automated alert triage and ticket creation
- Deploy Zeek/Suricata for network-layer detection alongside host-based detection
- Build Sigma rule equivalents for all custom Wazuh detections
Wazuh v4.7.5 SIEM Administration Windows Audit Policy (auditpol) Group Policy Editor
Sysmon Windows Event Log Analysis Event ID 4624/4625/4688 File Integrity Monitoring
Security Configuration Assessment CIS Benchmarks PCI DSS MITRE ATT&CK
VMware Workstation Ubuntu Server 24.04 Multi-VM Lab Design Network Segmentation
Blue Team Operations SOC Analyst Workflow Detection Engineering
Built by Hitansh Waghela — Computer Engineering, University of Mumbai GitHub · TryHackMe · whitansh@gmail.com