Building a Home SOC Lab
Source: Dev.to
Overview
In this project I built a complete Security Operations Center (SOC) home lab to simulate real‑world cyberattacks and monitor them in real‑time. The lab demonstrates how to identify an attacker’s origin, map behaviors to the MITRE ATT&CK framework, and implement proactive detection using Auditd.
Architecture
The virtual environment is hosted on Proxmox and consists of three primary machines:
| Machine | OS | Role |
|---|---|---|
| Wazuh Manager | Ubuntu | Central nervous system for log collection and analysis |
| Attacker | Kali Linux | Launches automated brute‑force attacks |
| Victim | Debian | Target system monitored by Wazuh agents |
Detection & Investigation
To test detection capabilities, Hydra on the Kali machine launched a password‑guessing attack against the victim.
- Wazuh immediately flagged the activity on the Threat Management dashboard.
- Smoking gun: The attacker’s IP address (
data.srcip) was identified as10.0.0.10, allowing isolation of all activity originating from the malicious host.
Narrative
“I identified the attacker’s IP address as
10.0.0.10, allowing me to isolate all activity originating from the malicious host.”
Understanding the adversary’s tactic is a key part of professional incident response.
Relevant Fields
| Field | Data Value | Professional Significance |
|---|---|---|
rule.mitre.id | T1110 | Identifies the specific Brute Force technique |
rule.mitre.tactic | Credential Access | Categorizes the attacker’s ultimate goal |
data.srcip | 10.0.0.10 | Provides the attacker’s identity for blocking |
Incident Timeline Analysis
- Baseline: Normal system activity prior to midnight.
- Anomaly: Sharp increase in event count (> 500) marking the Detection Phase.
- Resolution: Mitigation Phase – the malicious IP is blocked, causing alerts to drop off.
Auditd Integration
Standard logs are useful, but for high‑security environments I implemented the Linux Audit Framework (Auditd) to set behavioral traps.
Example Auditd Rule for /etc/shadow
type=SYSCALL msg=audit(...): exe="/usr/bin/cat" key="shadow_access"I configured a watch on sensitive system files. Using wazuh-logtest, I verified that Wazuh correctly groups these messages (Rule 80700) for further alerting.
Troubleshooting
During setup I encountered a “Missing location element” (Error 1902) in the ossec.conf file on the Debian agent. The steps to resolve:
- Run
wazuh-logcollector -tto validate the XML syntax. - Identify the missing
<location>tag. - Add the required tag and restart the Wazuh agent service.