A fully functional Security Operations Center (SOC) lab built on a single laptop using Oracle VirtualBox. This project was built to learn how a real SOC operates — detection, monitoring, alerting, and automated response — using entirely open source tools.
Most SOC learning stops at theory. This project is an attempt to actually build the pipeline — from a suspicious event being detected at the network layer, all the way through to an endpoint being automatically isolated without touching a console.
Everything runs inside VirtualBox. No physical hardware. No cloud servers. One laptop.
| Zone | Subnet | Purpose |
|---|---|---|
| WAN | DHCP | OPNsense internet access for updates only |
| LAN | 192.168.1.0/24 | Attacker machine (Kali) + Windows victim |
| OPT1 / DMZ | 192.168.2.0/24 | Vulnerable web app (DVWA) isolated from LAN |
| Tool | Role | Type |
|---|---|---|
| OPNsense | Perimeter firewall | Open source |
| Suricata | IDS/IPS engine (runs inside OPNsense) | Open source |
| Wazuh | SIEM — log collection, dashboards, alerting | Open source |
| DVWA | Vulnerable web app — attack target in DMZ | Open source |
| LimaCharlie | EDR — endpoint telemetry and isolation | Cloud (free tier) |
| Tines | SOAR — automated response playbooks | Cloud (free tier) |
| osTicket | Incident ticketing system | Open source |
| Kali Linux | Attacker machine | Open source |
Deployed Wazuh using the pre-built OVA in VirtualBox. Configured internal networking so all VMs forward logs to a central dashboard.
Enabled Suricata inside OPNsense. Wrote custom rules to detect ICMP floods and Nmap SYN scans. Tested three enforcement modes: log-only, log-and-block, silent block.
Configured three network zones. Created rules to allow ICMP between LAN and DMZ but block HTTP. Verified enforcement from Kali and checked live firewall logs.
Deployed DVWA on a Kali VM placed in the DMZ. Used as the attack target for SQL injection, XSS, and brute force simulations.
Deployed osTicket on Ubuntu using the LAMP stack. Every SIEM alert maps to a trackable ticket with an owner and audit trail.
Configured Suricata rules in all three modes and tested using Nmap from Kali. Observed how each mode affects visibility in OPNsense logs and Wazuh.
Forwarded OPNsense and Suricata logs into Wazuh. Built a custom Kibana dashboard showing top source/destination IPs, alert severity, blocked vs allowed traffic, and a live alerts table.
Installed the LimaCharlie sensor on a Windows VM. Triggered a network isolation command from the cloud console and watched a live ping to Google drop instantly.
Integrated Wazuh with Discord via a custom Python webhook script and with Email via Postfix and Gmail SMTP relay. All alerts sent to both channels.
Built an end-to-end automated workflow:
- LimaCharlie detects a malicious tool (LaZagne) on the Windows VM
- Alert forwarded to Tines via webhook
- Tines posts an interactive message to Slack with [Yes] / [No] buttons
- Analyst clicks Yes — Tines calls LimaCharlie API — endpoint is isolated
- Confirmation sent back to Slack
| Attack | Tool | Target | Detected By |
|---|---|---|---|
| Nmap SYN scan | Nmap | DVWA / Windows VM | Suricata → Wazuh |
| ICMP flood | Ping | DVWA | Suricata → Wazuh |
| SQL Injection | Browser / manual | DVWA | Wazuh (web logs) |
| Brute Force | Browser / manual | DVWA | Wazuh |
| Credential harvesting | LaZagne | Windows VM | LimaCharlie → Tines → Slack |
LaZagne is an open source credential recovery tool. It was used here strictly in a controlled lab environment to test detection capability.
1. LaZagne executed on Windows VM
2. LimaCharlie sensor detects the process by hash / filename
3. Detection & Response rule fires — alert sent to Tines via webhook
4. Tines posts to Slack with [Yes] / [No] prompt
5. Analyst clicks Yes — Tines calls LimaCharlie API
6. Windows VM is isolated from the network
7. Confirmation posted back to Slack
Open source is enterprise-grade when configured properly. Wazuh, Suricata, OPNsense, and osTicket replicate what commercial SOC tools do. The gap is in support and polish, not capability.
Architecture matters more than tools. Network segmentation, log forwarding design, and alert thresholds are what determine whether a SOC produces signal or noise.
Automation is not optional. Manually checking dashboards and switching between consoles is too slow. Connecting detection to response programmatically is why SOAR exists.
Built as an academic project to understand SOC operations hands-on. All attack simulations were performed in an isolated lab environment.