June 12, 2026
I Built a SOC Home Lab from Scratch Here’s Everything I Learned A practical walkthrough of building…
If you have been studying cybersecurity through courses and certifications, you already know the theory. But theory alone will not get you…
Hammad Khan | SOC & Pentesting
4 min read
I Built a SOC Home Lab from Scratch Here's Everything I Learned A practical walkthrough of building a real ELK Stack SIEM, writing detection rules, simulating attacks, and hunting threats on your own machine.
If you have been studying cybersecurity through courses and certifications, you already know the theory. But theory alone will not get you hired. What changed everything for me was building a real, working SOC environment on my own machine from zero, with no budget, using free tools. Here is exactly what I built, what I learned, and how you can do the same.
What Is a SOC Home Lab and Why Does It Matter: A Security Operations Center home lab is a personal environment where you simulate enterprise security monitoring. You ingest real logs, write detection rules, simulate real attacks, and hunt for threats exactly like a working SOC analyst does every day on the job. Hiring managers and freelance clients cannot verify that you watched a course. They can verify a GitHub repository with 20+ commits, real configuration files, detection rules, and screenshots of alerts firing. That is the difference between a candidate and a hire.
The Lab Architecture: My lab runs entirely on VirtualBox with three machines communicating over an isolated Host-Only network. The Ubuntu Server at 192.168.56.101 is the SIEM server running the full ELK Stack. The Kali Linux machine at 192.168.56.100 is the attacker. My Windows host runs Sysmon and Winlogbeat to ship Windows telemetry into the SIEM.
The complete stack: Elasticsearch 8.19 stores and indexes every log event. Kibana provides the dashboard and SIEM interface. Logstash handles the log parsing pipeline. Filebeat ships Linux auth and syslog data. Winlogbeat ships Windows Event Logs. Sysmon with the SwiftOnSecurity config captures deep Windows telemetry every process creation, network connection, registry change, and file modification. By the time everything was running the lab was ingesting over 500,000 real security events.
Building the Detection Layer: Once logs were flowing I wrote six KQL detection rules directly in Kibana, each mapped to a MITRE ATT&CK technique: Brute Force SSH detection triggers when five or more failed authentication events occur within five minutes from the same source IP. This maps to T1110 and is the most immediately testable rule you can write. Privilege Escalation detection watches for sudo activity from non-administrative users and maps to T1548. Lateral Movement detection alerts on successful SSH sessions from internal network IPs, mapping to T1021.004. Suspicious Process Execution catches bash spawning download tools like curl or wget, mapping to T1059. Multiple Failed Authentication watches for username enumeration attempts across different accounts. PowerShell Abuse on Windows uses Winlogbeat and Sysmon Event ID 1 to catch encoded PowerShell execution, mapping to T1059.001.
The First Real Attack: I ran a brute force SSH attack from Kali using Hydra targeting the Ubuntu server. In under ten seconds Hydra generated 1,197 failed login attempts. Every single one appeared in Elasticsearch, ingested by Filebeat from the auth.log file. The detection rule fired. The alert appeared in Kibana Security. I had a timestamp, a source IP, a target username, and an event count — exactly what a real SOC analyst sees during an incident.
That moment is when hands-on learning becomes real understanding. Threat Hunting With Real Data After the simulations I ran three formal threat hunts using the data already in the SIEM. Threat hunting is not waiting for alerts it is proactively searching through logs looking for signs of compromise that rules may have missed.
Hunt one confirmed the brute force pattern: 1,197 failed attempts from a single IP targeting the root user, all within a ten second window on June 4th. Hunt two found 891 sudo events across the lab period and identified a critical logging gap sudo commands were not being fully captured in the message field, meaning privileged activity could not be fully audited. This is a real security finding. Hunt three established a baseline of 69 successful SSH sessions over thirty days, giving me a reference point for future anomaly detection.
Finding a security gap during a threat hunt and documenting it as a recommendation is exactly the kind of work that separates junior analysts from strong candidates.
What the GitHub Repository Looks Like: Everything built in this lab lives in a public GitHub repository with organized folders for configs, detection rules, dashboards, attack simulations, threat hunt reports, screenshots, and a final professional lab report.
soc-home-lab/ ├── configs/ All service configurations ├── detection-rules/ 6 KQL detection rules ├── dashboards/ 4 exported dashboards ├── attack-simulations/ 6 attack reports ├── threat-hunts/ 3 hunt reports ├── screenshots/ All evidence screenshots └── reports/ This report
Employers and clients who visit the repository see real configuration files, exported Kibana dashboards, detection rules with MITRE mapping, and documented attack simulations with screenshots. That is verifiable, permanent proof of hands-on skill.
What No Course Will Teach You: Log volume is brutal in ways you cannot appreciate until you see it. Your first instinct is to alert on everything. Your second instinct, after drowning in false positives from cron jobs and internal SSH sessions, is to understand why threshold tuning and baselining is where real SOC skill actually lives. Sysmon changes your understanding of Windows security entirely. Once you see it capturing parent processes, full command line arguments, file hashes, and network connections at the process level, you understand why every serious enterprise SOC deploys it on every endpoint. Documentation is an underrated technical skill. Writing clear, professional reports for every attack simulation and threat hunt forced me to articulate what I actually found and why it matters. That skill transfers directly to client deliverables and incident reports.
Where to Start If You Want to Build Your Own: Start with VirtualBox and download Ubuntu Server 22.04 and Kali Linux. Follow the official Elastic documentation for ELK installation. Configure Filebeat to ship your auth.log file first it is the fastest path to real data. Write your first detection rule for brute force authentication failure. Run Hydra from Kali and watch the alert fire. That first alert is the moment everything becomes real.
I am documenting this entire journey in a detailed handbook covering every command, every concept, and every screenshot from lab setup through threat hunting. The complete lab is already public on GitHub.
https://github.com/HK101-cyber
If you are building something similar or have questions about the setup, drop them in the comments. Happy to help.