Breaking Out of the AppSec Bubble

I’ve spent years in AppSec — finding bugs in code, running threat models, integrating scanners into CI/CD pipelines. And for a long time I told myself that was enough. Harden the app, ship the finding, move on.

Then I asked myself an honest question: if something got through, would I have any idea what that looks like from the detection side?

No. So I decided to build a SOC lab and find out.

The plan

Four VMs on a host-only network inside VirtualBox on my Windows machine. 32 GB RAM total, which is enough to run everything simultaneously except the Kali attacker box, which I only spin up when actually simulating attacks.

• VM 1 — Security Onion (192.168.56.10) — the SIEM. Suricata for network IDS, Zeek for traffic analysis, Elastic/Kibana for dashboards and querying.
• VM 2 — Ubuntu tools (192.168.56.20) — Wazuh, TheHive, MISP, Velociraptor server.
• VM 3 — Windows victim (192.168.56.30) — the machine I run attacks against and monitor.
• VM 4 — Kali (192.168.56.40) — attacker box, only up during simulations.

Security Onion first because everything else feeds into it.

Why Security Onion

It’s an all-in-one Linux distro for threat hunting and monitoring. Evaluation mode bundles Suricata, Zeek, and the Elastic Stack into a single install. For a home lab, that’s ideal — one VM and you have a working SIEM with network telemetry.

From an AppSec perspective it maps onto things I already understand. Suricata runs signature-based detection — it knows what SQLi payloads look like on the wire, what scanner fingerprints look like, what C2 beaconing patterns look like. Zeek logs every HTTP request with method, URI, user agent, and response code. That’s a feed I know how to read. The tooling is different but the concepts aren’t.

What broke

Adapter bonding killed the install

Security Onion needs two dedicated interfaces: one for management, one for monitoring. I gave it two VirtualBox adapters — NAT for internet access and Host-Only for the lab network — and started the install.

What I didn’t know: Security Onion bonds interfaces for monitoring. It grabbed the NAT adapter, removed its IP and default route, and the installer couldn’t reach the internet.

curl: (6) Could not resolve host: sigs.securityonion.net

The routing table made it obvious once I knew where to look — all traffic was trying to exit through the Host-Only adapter, which has no internet gateway.

Fix: add a third adapter. A second Host-Only adapter gives Security Onion a dedicated monitoring interface, leaves the NAT adapter completely alone, and the install runs cleanly.

During setup: management NIC goes to the first Host-Only adapter, monitor NIC goes to the second. NAT doesn’t get touched.

VirtualBox virtual switch dropped packets silently

Install finished, all services showed running, web UI completely unreachable. Ping timed out. Running tcpdump on the Host-Only interface inside the VM showed zero packets arriving — not even ICMP.

The adapter showed UP and the IP was correctly assigned. VirtualBox’s virtual switch was just not delivering packets. Deleting and recreating the Host-Only network in VirtualBox’s Network Manager fixed it. The virtual switch had gotten into a bad state.

If packets aren’t arriving at the interface, the problem is upstream of the OS. tcpdump tells you that immediately.

What it actually looks like

Once it was up I spent time in the SOC dashboard exploring. The Zeek HTTP logs were immediately familiar — every request logged with method, URI, user agent, status code. I started thinking about what path traversal attempts look like in those fields, what fuzzer patterns look like, how you’d write a detection for specific injection signatures. Same mental model, different tool.

What’s genuinely different is the workflow. AppSec is mostly individual findings — here’s a vulnerability, here’s how to fix it. SOC work is about event sequences across multiple sources. One failed login is noise. Fifty failed logins from the same IP followed by a successful one is a story. Building that pattern-recognition is the actual work of this project.

Next up

Wazuh on VM 2, Sysmon on the Windows victim, then Atomic Red Team. The loop I’m building toward: run an ATT&CK technique, then hunt for it in the SIEM. Did Suricata catch it? Did Zeek log the traffic? Did Sysmon catch the process? If not, why not?

Part 2 is about why default Windows event logging is almost useless for threat hunting, and what Sysmon actually gives you.