I'm a third-year Cybersecurity student, and I'm aiming at Blue Team work — SOC Analyst first, then DFIR, then eventually threat hunting and detection engineering. The problem with that career path when you're still in college is obvious: nobody hands a sophomore a real SIEM and a real incident to work. So I built one.
This post is a walkthrough of Glasshouse, a home SOC lab I built to simulate exactly what a junior SOC analyst does on the job: collect logs, get attacked, catch it, and write it up. I'm not going to pretend everything went smoothly, because it didn't — and honestly, the parts that broke taught me more than the parts that worked first try.
The setup
Three machines, bridged onto the same network so traffic actually has to travel between them instead of staying inside one hypervisor:
- Windows 10 VM (victim) — 4GB RAM, 60GB disk, running Sysmon with the SwiftOnSecurity config. Sysmon is the piece that makes Windows logging actually useful for detection — process creation with full command lines, registry modifications, network connections, the works.
- Kali (attacker) — running on a separate physical laptop rather than as another VM on the same box, connected over the same home WiFi via bridged networking. I wanted the attack traffic to be real network traffic, not loopback.
- Ubuntu Server VM (the brain) — self-hosted Wazuh, running the manager, indexer, and dashboard all on one box.
The Windows machine ships its Sysmon and Windows Event logs to the Wazuh agent, which forwards them to the manager, which indexes and correlates them, which shows up on the dashboard. Simple pipeline in theory. Not simple in practice.
Everything that broke (and why I'm glad it did)
If I only listed the finished architecture, this section wouldn't exist — and it's the most useful part of the project. Along the way:
- VirtualBox corrupted itself badly enough that I switched to VMware entirely
- I locked myself out of the Ubuntu box and had to recover the password
- The Ubuntu disk was undersized for Wazuh's indexer and needed an LVM resize
- A Wazuh install got into a broken state and had to be wiped and reinstalled clean
- Moving Kali to a separate physical laptop meant re-IPing the whole lab network
And the one that mattered most: after everything was "installed," Wazuh wasn't actually collecting Sysmon events at all. The dashboard was just quiet. I dug into ossec.conf on the Windows agent and found the Sysmon event channel simply wasn't configured to be collected — an easy thing to miss, an easy thing to fix once you know to look, and exactly the kind of "why is nothing showing up" troubleshooting that real SOC work is full of.
Once that was fixed, I confirmed the full pipeline end-to-end: Sysmon → Agent → Wazuh Manager → Dashboard. Logs flowing.
Attacking my own lab
Detection you haven't tested is just a hope. So I ran five techniques from the Atomic Red Team library against my own Windows box, mapped to MITRE ATT&CK, and checked whether Wazuh actually caught each one — not just "did an alert fire" but "does the telemetry tell a real story."
| Technique | What it does | Result |
|---|---|---|
| T1059.001 — Encoded PowerShell | Base64 -EncodedCommand execution |
Caught, decoded, and documented |
| T1003.002 — Credential dumping | Exporting SAM/System/Security registry hives | Caught — 2 of 3 hives exported; the Security hive was blocked by permissions, which is actually the realistic outcome |
| T1547.001 — Registry persistence | RunOnce key persistence | Caught by both Sysmon's own tagging and Wazuh's rule engine |
| T1055 — Process injection | Classic injection technique | Never even ran — Windows Defender blocked it outright |
| T1083 — Discovery | Recursive dir /s enumeration |
Caught via the enumeration pattern |
That T1055 result is worth pausing on. It's tempting to want every technique to "succeed" so you have a detection to show off, but Defender blocking it before Wazuh even got a chance is a legitimate defense-in-depth story — the lab isn't just testing my SIEM, it's testing the whole stack.
The standout result, though, was a Hydra brute-force attack launched from Kali against the Windows box. Individual failed logons on their own aren't interesting — but Wazuh correlated them into a single "Multiple Windows Logon Failures" alert (T1110), and that correlation then triggered Windows' own account lockout mechanism (T1531). Watching an attack get caught and automatically contained, using nothing but Sysmon, Wazuh's correlation rules, and Windows' built-in lockout policy, was the most satisfying moment of the whole project.
Where I hit a real wall
The built-in Wazuh rule that caught the SAM/System/Security export (T1003.002) is generic — it flags registry hive exports in general, not credential dumping specifically. I wanted to write a custom rule that would fire specifically on that credential-dumping pattern.
I couldn't get it working. The XML was valid, I tried several different rule approaches, and it just never fired. Rather than fudge a fake success or quietly drop it from the writeup, I documented it as an open item. I'd rather show a real unresolved problem than a lab that pretends everything worked — because in an actual SOC, not everything resolves cleanly in one sitting, and knowing how to document a stuck detection is its own skill.
Dashboards and hunting
With the attack data sitting in Wazuh, I built a 3-panel dashboard — Alerts Over Time, Top MITRE Techniques, and Alerts by Agent — to get a SOC-analyst's-eye view of the lab at a glance.
Then I wrote and validated 5 manual threat-hunting queries against my own data, covering:
- Encoded PowerShell execution
- Registry hive exports
- Suspicious parent-child process relationships
- Persistence via registry run keys
- Brute-force logon patterns
Every query returned real hits against the attacks I'd already run — proof the queries actually work, not just that they're syntactically valid.
What's left
The infrastructure and attack work is done. What's left is writing it up properly:
- A one-page incident report for each attack (the kind of artifact a SOC analyst or DFIR responder actually produces after an incident)
- A main README tying the whole project together
- Pushing the full thing to GitHub as Glasshouse
I'm also weighing two stretch goals once the core writeup is done: adding Suricata for network-based detection, and taking another run at that custom Wazuh rule with fresh eyes.
Why I built this
I can't get a SOC job to get SOC experience, so I built the experience myself — including the parts that broke. If you're on the same Blue Team path and stuck at "how do I get hands-on without a job," this is the answer: stand up a target, attack it, and make yourself prove the detection actually caught it. The infrastructure pain is not a detour from that goal — it is the goal.
The full repo, with all the detection rules, hunting queries, and incident writeups, will be up on GitHub soon: https://github.com/the-opalgupta/Glass-House
I'm a Blue Team–focused Cybersecurity student and Blue Team Lead at my college's cybersecurity club. If you're working through something similar, I'd love to hear how your setup differs from mine.
Top comments (0)