A fully isolated, four-VM Security Operations Center lab built from free and open-source tools and validated end to end against live attack scenarios. It runs a Wazuh 4.14.5 SIEM, a Sysmon-instrumented Windows endpoint, a dedicated Suricata + Zeek network sensor, Nessus vulnerability scanning, and custom Python threat-intelligence integrations (VirusTotal, AbuseIPDB, AlienVault OTX), all exercised by a Kali Linux attacker running scripted reconnaissance, brute-force, and malware scenarios.
Stack: Wazuh · OpenSearch · Sysmon · Suricata · Zeek · Nessus Essentials · Kali Linux · Nmap · Hydra · VirusTotal · AbuseIPDB · AlienVault OTX · MITRE ATT&CK · Python · PowerShell · VirtualBox · Ubuntu Server · Windows 10
Most home labs stop at "install the SIEM, see an alert." This one goes further: it documents the infrastructure failures, detection-engineering decisions, and threat-intelligence tradeoffs that only show up when you push a lab until things break and then fix them from the evidence. Every custom rule was tested before it was trusted, every integration was built to fail honestly rather than fake a result, and every attack was validated end to end from packet to dashboard.
The full 72-page report is in docs/full-report.pdf. This README is the fast tour.
Host: ASUS ROG G16 (Windows 11, VirtualBox 7.1, Hyper-V compatibility mode)
Isolated host-only network: 192.168.56.0/24 (no NAT, no internet route)
wazuh-mgr win10-endpoint nsm-sensor
192.168.56.10 192.168.56.20 192.168.56.50
Wazuh 4.14.5 Wazuh agent + Sysmon Suricata 8.0.3
SIEM (all-in-one) (SwiftOnSecurity cfg) + Zeek 8.0.8
indexer + dashboard File Integrity Mon. ET Open ruleset
kali-attacker
192.168.56.40
Nmap · Hydra · EICAR
The manager, endpoint, and sensor each report into a single Wazuh SIEM. The Kali host sits on the same isolated segment with no route out, so every attack is contained and every source address is easy to attribute in the logs.
- SIEM operation and detection engineering — deploying Wazuh end to end, authoring and validating custom rules, and tuning out false positives.
- Endpoint detection — Sysmon with the SwiftOnSecurity configuration, file integrity monitoring, and process/network/file telemetry mapped to MITRE ATT&CK.
- Network security monitoring — a dedicated Suricata + Zeek sensor integrated into the SIEM alongside endpoint telemetry.
- Vulnerability management — authenticated and unauthenticated Nessus scanning, including diagnosing a failed Windows credentialed scan.
- Threat-intelligence enrichment — custom Python integrations that score source addresses (AbuseIPDB, OTX) and file hashes (VirusTotal), with escalation rules that encode a deliberate judgment about each source.
- Attack simulation and validation — reconnaissance, SSH brute force, and a malicious-file scenario, each validated from the raw event to the escalated alert.
- Incident triage — root-causing alerts, correlating multi-source signals, and separating true positives from noise.
Custom Wazuh rules authored for this lab (see detection/):
| Rule ID | Level | Purpose |
|---|---|---|
| 100100 | 0 | Suppresses a noisy svchost false positive from built-in rule 61618 |
| 100210 | 3 | Records every AbuseIPDB enrichment result |
| 100211 | 10 | Escalates when AbuseIPDB confidence ≥ 50 |
| 100220 | 3 | Records every AlienVault OTX enrichment result |
| 100221 | 10 | Escalates when an address appears in ≥ 1 OTX threat pulse |
| 100300 | 3 | Retains Zeek connection events (Wazuh ships no rule for them) |
The rules follow a deliberate base-and-escalation pattern: a level-3 rule records every enrichment so nothing is lost, and a level-10 rule chained beneath it fires only when the reputation crosses a threshold.
Two custom Python integrations (integrations/) bridge Wazuh to reputation services that ship no native support. Both read the source address from an alert, skip any non-public address before spending an API call, and write structured enrichment back into the SIEM.
The most instructive result came when both sources were queried on the same public address at the same moment:
- AbuseIPDB returned a confidence score of 0 (its scoring window had aged the reports out).
- AlienVault OTX returned 26 threat pulses (its pulse count is cumulative and retained the history).
That disagreement is the point. Threat intelligence is contextual, not authoritative. One source scores recent reports, the other counts historical associations, and an analyst has to understand why they differ rather than trust a single number. The full breakdown is in attacks/README.md.
All three scenarios were run from the Kali attacker and validated in the SIEM (attacks/README.md):
- Reconnaissance — an Nmap TCP SYN scan, detected by Suricata and Zeek, retained by custom rule 100300.
- SSH brute force — a Hydra password-guessing run, correlated by Wazuh into a layered chain (rules 5710 → 5758 → 5712) and enriched with live threat intelligence.
- Malicious file — an EICAR test file dropped into a file-integrity-monitored folder on the endpoint, hashed, checked against VirusTotal (62 of 67 engines), and escalated to a level-12 alert with PCI DSS and GDPR compliance mappings.
- A detection is only as trustworthy as the pipeline beneath it. Rule 100300 fired correctly on Zeek events, yet none reached the dashboard until a field-mapping conflict in the indexer was traced and fixed with an ingest pipeline. A firing rule is not the same as a visible alert.
- Threat intelligence is contextual, not authoritative. The same address read as clean on one source and malicious on another; the analyst weighs both.
- Infrastructure failure is part of detection work. A vulnerability feed that filled the disk, a flood-stage read-only block, and a stalled forwarder each hid data or took the SIEM down. Each was diagnosed from evidence and documented with a fix.
- Layered detection produces layered signals. One brute force surfaced as failed logins, a max-attempts condition, and a correlated alert at once. Knowing which to triage on matters more than the alert count.
- Honest scoping beats faking completeness. Enrichment correctly returned nothing for the internal attacker, and that null result was documented rather than hidden.
.
├── README.md This file
├── detection/ Custom Wazuh detection rules + explanation
│ ├── local_rules.xml
│ └── README.md
├── integrations/ Custom Python threat-intel integrations
│ ├── custom-abuseipdb.py
│ ├── custom-otx.py
│ └── README.md
├── attacks/ Attack scenarios and their validation
│ └── README.md
└── docs/
├── full-report.pdf The complete 72-page lab report
└── screenshots/ Selected evidence
The complete build, phase by phase, with every troubleshooting step and figure, is in docs/full-report.pdf (72 pages).
The Python integrations receive their API keys as command-line arguments from the Wazuh manager configuration; no keys are stored in this repository. The integration blocks in the report show the keys redacted.
Built and operated independently by Yamin Salahi as a demonstration of Tier 1 SOC and detection-engineering readiness.