In this project, I built a complete Security Operations Center (SOC) home lab to simulate real-world cyberattacks and monitor them in real-time. This lab demonstrates how to identify an attacker's origin, map behaviors to the MITRE ATT&CK framework, and implement proactive detection using Auditd.
The Architecture
I used Proxmox to host my virtual environment, consisting of three primary machines:
- Wazuh Manager (Ubuntu): The central nervous system for log collection and analysis.
- Attacker (Kali Linux): Used to launch automated brute-force attacks.
- Victim (Debian): The target systems monitored by Wazuh agents.
Phase 1: The Brute Force Simulation
To test the detection capabilities, I used Hydra on my Kali machine to launch a password-guessing attack against the victim.
Detection & Investigation
- Wazuh immediately flagged the activity on the Threat Management dashboard.
- The Smoking Gun: I identified the attacker's IP address (data.srcip) as 10.0.0.10.
Narrative: "I identified the attacker's IP address as 10.0.0.10, allowing me to isolate all activity originating from the malicious host".
Phase 2: Mapping to MITRE ATT&CK
A key part of professional incident response is understanding the tactic used by the adversary.
| Field Name | Data Value | Professional Significance |
|---|---|---|
| rule.mitre.id | T1110 | Identifies the specific Brute Force technique1313. |
| rule.mitre.tactic | Credential Access | Categorizes the attacker's ultimate goal14141414. |
| data.srcip | 10.0.0.10 | Provides the Attacker's Identity for blocking1515. |
Incident Timeline Analysis:
- Baseline: Normal system activity prior to midnight.
- Anomaly: A sharp Y-axis increase (Count > 500) marking the "Detection Phase".
- Resolution: The "Mitigation Phase" where the malicious IP is blocked, causing the alerts to drop off.
Phase 3: Proactive Traps with Auditd
Standard logs are great, but for high-security environments, I implemented the Linux Audit Framework (Auditd) to set behavioral traps.
I configured a "watch" on sensitive system files. When I tested the trap using wazuh-logtest, I verified that Wazuh correctly groups these messages (Rule 80700) for further alerting
# Example Auditd Trap for /etc/shadow
type=SYSCALL msg=audit(...): exe="/usr/bin/cat" key="shadow_access"
Challenges Overcome
Setting up the lab wasn't without hurdles. I encountered a "Missing location element" (Error 1902) in the ossec.conf file on the Debian agent. By using wazuh-logcollector -t to validate the XML syntax, I identified the missing tag and successfully restarted the service.
Top comments (0)