DEV Community: Luna Meadows

Glasshouse — Building a Home SOC Lab From Scratch (and Attacking It Myself)

Luna Meadows — Thu, 06 Aug 2026 09:15:58 +0000

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.

Blue Watch: in all its glory

Luna Meadows — Fri, 24 Jul 2026 10:12:51 +0000

Spent the last few weeks building something I've wanted to understand properly for a while: how a SIEM actually thinks.

Not using one. Building one.

Blue Watch is a mini SIEM I built from scratch in Python. No fancy platform, no black box, just logs, regex, and a lot of "wait, why isn't this matching."

Here's what building it actually taught me:

Logs are messy. Every source speaks its own language, sshd says one thing, sudo says another, Apache says something else entirely. Parsing is just teaching Python to translate all of it into one shared vocabulary.

Normalization is the real magic. Once every event looks the same underneath (same fields, same shape), detection stops caring where the log came from. Write one rule, it works everywhere.

Automation is just patience, structured. Rules living in a config file instead of buried in code meant I could add a whole new log source later without touching my detection logic at all. Past me set that up without even realizing how much time it'd save future me.

Turns out good architecture is a bit like good code and good rhyme,
get the structure right once, and it'll scale with time.

Genuinely one of the more satisfying builds I've done. Watching a brute force attack chain get reconstructed automatically, timestamped, scored, and MITRE-tagged, from a file I wrote myself, hit different.

If you're learning security or building your own detection tooling, what's the one concept that finally "clicked" for you the way normalization did for me?
Go check it out yourself :)

Blue Watch, Day 4-6: From Alerts to a Story

Luna Meadows — Mon, 20 Jul 2026 13:05:28 +0000

If you've been following along, Blue Watch is my mini-SIEM: parse logs, detect suspicious patterns, generate alerts, all config-first. Day 1-3 got me a parser, a rules file, and a detector that fires four correct alerts on my test attack scenario with zero false positives.

Four alerts is nice. But four alerts sitting in a list still isn't an incident. That's what the last three days were about: turning raw alerts into a score, and a score into a story.

*The problem: one attacker, four disguises
*
My test scenario has a single attacker brute-forcing admin, spinning up a backdoor user shelly, and reading /etc/shadow. But the alerts that come out of the detector don't know they're all the same person. One alert is tagged by IP. Another is tagged by username. Without something to unify them, my "incident" looks like four unrelated blips instead of one attacker's full campaign.

That's the job of scorer.py.

build_ip_to_user_map() and get_entity()

First step: figure out which IPs and users actually belong together. build_ip_to_user_map() walks the event stream and links every IP to the users who logged in from it.

Then get_entity() decides who an alert really "belongs to," in priority order:

first_user if the alert carries one (this covers privilege-escalation alerts, where the original attacker identity matters more than whoever they became)
user, if present
otherwise, the IP mapped back to a user via the map from step one

That fallback chain is the whole trick. It's the difference between four disconnected alerts and one entity with four alerts against its name.

Scoring severity into a single number

Once every alert has an owner, score_alerts() sums up severity points per entity:

low: 20
medium: 50
high: 70
critical: 100

Then score_to_level() converts the total back into a human label: LOW, MEDIUM, HIGH, or CRITICAL. Simple, but it's the layer that turns "a pile of alerts" into "a number a human can triage against."

The output layer

Two ways to see the result:

save_alerts_json() writes a structured output/alerts.json — machine-readable, ready to feed into whatever comes next.
print_report_table() renders the same data as a clean terminal table, for when I just want to glance at it.

Run against the test scenario, everything unifies the way it should: admin → 290 points → CRITICAL, with all four alerts correctly attributed to one entity. Exactly what four separate, disguised alerts should have added up to.

Day 6: the timeline

Scoring answers "how bad is this?" The last piece answers "what actually happened, in order?"

timeline.py is deliberately small:

build_timeline() sorts every event chronologically. The nice trick here: ISO 8601 timestamps sort correctly as plain strings, so there's no datetime parsing needed — just a string sort.
print_timeline() renders the play-by-play with generic field display, meaning it doesn't need special-case logic for each event type. Any event shape that comes out of the parser just... prints.

The payoff is the full 12-event story, in order, with luna's ordinary login sitting exactly where it should — mid-sequence, clearly harmless noise next to the actual attack. That's the detail I was hoping for: a good detector doesn't just catch the bad stuff, it also stays quiet about the normal stuff sitting right next to it.

Building Blue Watch: a tiny SIEM with a big attitude

Luna Meadows — Sun, 19 Jul 2026 21:50:35 +0000

Okay so I'm building a mini SIEM. If you just went "a mini what?" same energy I had a week ago.
A SIEM (Security Information and Event Management system) is basically the thing that watches your logs, notices when something shady is happening, and yells about it. Big companies pay big money for big versions of this. I am making a smol one, called Blue Watch, mostly out of stubbornness and curiosity.
Rule number one I set for myself: config over code. Detection logic should live in a config file, not be hardcoded spaghetti buried in if statements. Future me will thank present me. Probably.

Step zero: fake my own crime scene
Before writing a single line of detection logic, I needed logs to detect things in. Real-world logs are messy and you never actually know the "right answer" — so instead I hand-crafted a single deliberate attack story and wrote it out as a realistic auth.log file, syslog-style timestamps and all:

🕵️ An attacker brute-forces their way into an admin account (lots of failed logins, then... success)
🐚 Admin (now compromised) creates a sneaky new user — a classic "leave myself a backdoor" move
🔓 That new backdoor account immediately goes digging somewhere it really shouldn't
👩‍💻 Meanwhile, a totally innocent employee logs in from a normal IP at roughly the same time, just doing her job

That last one was the important bit — I needed to know my detector could tell the difference between an attacker and someone just... checking their email.

Day 1: teaching myself regex, the hard way
I will be honest: I did not know regex before this. Now I have opinions about it.
I built a parser that reads raw log lines and pulls structure out of chaos using named capture groups, character classes, and way too much trial and error. Three different line "shapes" (logins, privilege escalations, account creations) each needed their own pattern.
The real win wasn't the regex though — it was writing a normalize() step that takes whatever any of the three patterns spat out and mushes it into one consistent event shape. Doesn't matter which log line it came from, downstream code doesn't need to care.
Bugs squashed along the way: unterminated strings, mysterious NoneType crashes (regex didn't match, oops), off-by-one group numbering, and — my personal favorite — an IndentationError caused by tabs sneaking in next to spaces like a tiny gremlin.

Day 2: rules as data, not dogma
This was the fun part. Instead of writing "if failed login count > 5" buried somewhere in Python, I moved every detection rule into a YAML file. Each rule even gets tagged with a real MITRE ATT&CK technique ID, because if I'm going to pretend to be a security engineer I might as well pretend properly.
Ended up with four rules covering: repeated failed logins, repeated suspicious IP activity, privilege escalation right after login, and — the spiciest one — persistence via account creation (a.k.a. "the attacker just planted a way back in").

Day 3: the detector finally detects something
Two core functions carried the whole day:

One that groups events by any field a rule asks for (a user, an IP, whatever) and checks it against a threshold — so one function now powers multiple rules instead of copy-pasted near-duplicates.
One that checks whether event A is followed by event B within some time window, using real datetime math instead of vibes.

And then — the best kind of bug — a false positive. My privilege-escalation rule was matching people to each other's activity just because the timing lined up. My innocent employee's login was accidentally getting blamed for the backdoor account's actions, purely by coincidence of timestamps. Fixed it by adding a same_user toggle to the rule config, since some sequences genuinely need "same person did both things" and others (like sudo → new account) very much don't.

End result: all four rules fired exactly once each, correctly reconstructing the entire attack from first failed login to backdoor to the shadow file — and zero false alarms on the one honest person in the logs. 🎉
What's next
Day 4 is scorer.py — turning a pile of individual alerts into one aggregate threat score per user/IP, so instead of "here are 4 alerts," Blue Watch can say "hey, this person is very clearly the problem."
More soon 👁️🔵
xoxo

Following along? This is a build-in-public series — feedback, questions, and "actually you should use X instead" comments always welcome.