Architecture

The lab runs on a VMware-based hypervisor with dedicated VMs for each function:

• Wazuh Manager + Dashboard — central SIEM collecting logs from all agents via the Wazuh agent on each endpoint VM
• Suricata IDS — network tap running on a dedicated interface, feeding alerts into Wazuh via Filebeat
• Wireshark capture host — promiscuous-mode capture on the lab’s internal virtual switch
• Kali Linux attacker — isolated on a separate VLAN from the victim VMs; used to generate traffic and test detection coverage
• Ubuntu 24.04 targets — two VMs acting as victim hosts: one hardened baseline, one intentionally misconfigured to study detection gaps

What’s Monitored

• File integrity monitoring on sensitive directories (/etc, /var/log, auth files)
• Brute-force and credential-stuffing detection via sshd log rules
• Port scan detection via Suricata rules tuned against nmap SYN and UDP scans
• Reverse shell callback detection via outbound connection rules
• Lateral movement indicators: unusual cron additions, SUID changes, new user creation

Attack Simulations Run

Nmap full-port scans, Hydra SSH brute-force, Metasploit exploit/multi/handler sessions, manual SUID exploitation on the misconfigured VM, and Kali’s evil-winrm connectivity tests. Each simulation produced Wazuh alerts that were triaged, documented, and used to refine detection rules.

What Was Detected and How

Wazuh alert categories that fired from the Kali simulations:

• Brute-force / authentication failure — Hydra SSH attacks trigger authentication_failures rule group; Wazuh aggregates repeated sshd failures and fires a high-severity alert when the threshold is crossed within the configured time window
• Port scan detection — Suricata ET ruleset catches nmap SYN and UDP scans by pattern; Suricata alerts feed into Wazuh via Filebeat, appearing under the suricata rule group with scan classification metadata intact
• Suspicious process execution — Metasploit post-exploitation payloads executing from non-standard paths trigger suspicious_execution and shells rule categories; process parent-child relationships that don’t match baseline behavior surface here
• SUID abuse — manual SUID exploitation on the misconfigured VM is caught by file integrity monitoring rules watching /usr/bin and /usr/local/bin for setuid bit changes
• Lateral movement indicators — unexpected cron modifications, new user creation, and home directory changes outside normal provisioning patterns fire under system_anomaly and policy_changed rule groups
• Reverse shell callbacks — outbound connections from victim VMs to the Kali listener IP on non-standard ports flagged by Suricata connection tracking rules

Each alert category was tuned iteratively: initial rules produced both gaps (missed events) and noise (false positives against background system activity). Rule thresholds, exclusion conditions, and field match criteria were adjusted against real attack traffic until signal-to-noise was usable for triage.

For the full methodology behind how these detections were built and how incident response is practiced in the lab, see the Security Operations Methodology writeup.

The lab is an ongoing project — rule tuning and new attack modules added continuously, with focus shifting toward advanced detection scenarios and VCP-DCV lab work.