I Ran 50 Attack Simulations Against My Own Lab. Here Is What Got Caught.

I Ran 50 Attack Simulations Against My Own Lab. Here Is What Got Caught. | raghv.dev

Running attacks against other people's networks is not an option when you are learning. Running them against your own lab is the whole point of building one. Over the past stretch I ran more than 50 attack simulations against my home SOC lab, mapped each one to MITRE ATT&CK, and wrote down what the SIEM caught, what it missed, and what I had to tune. Short version: Wazuh caught most of the loud attacks out of the box, missed most of the quiet ones, and the gap between the two taught me more than the simulations themselves.

My lab build is covered in Building My Home SOC Lab. The short version: four nodes, a Wazuh manager collecting logs, a Windows domain with Active Directory, Linux targets, and a Kali box doing the attacking.

How I Ran the Simulations

Every simulation followed the same loop:

Pick one ATT&CK technique and read how it actually works before touching a keyboard.
Run it from the Kali box against a lab target.
Go to the Wazuh dashboard and hunt for the alert. If nothing fired, go to the raw logs and find the evidence by hand.
Write a custom rule or tune an existing one until the technique produces a clear alert.
Record the technique ID, the event IDs involved, and whether the final state was caught, caught after tuning, or still a gap.

That last step matters. A simulation you cannot find in your own logs is a finding, not a failure to hide.

What Got Caught Cold

The noisy attacks lit up the dashboard with default rules, no tuning needed.

SSH brute force (T1110.001) fired within seconds. Hundreds of failed logons from one source is exactly the pattern Wazuh ships rules for. I wrote this one up as a full investigation: LAB-001: SSH Brute Force. The individual failed logon alerts appeared first, then the correlation rule stacked them into a proper brute force alert.

Port scanning and service discovery (T1046) showed up through a mix of firewall logs and repeated connection patterns. Not one clean alert, but the evidence was all there in the raw events once I knew the timeframe.

Account creation and privilege changes (T1136, T1098) on the Windows side were caught through Security event IDs 4720 and 4732. Creating a user is loud. Adding that user to Administrators is louder. Wazuh flagged both with default content.

Malware style process behaviour, encoded PowerShell and suspicious parent child process chains, fired through a combination of event 4688 process creation logging and PowerShell script block logging in event 4104. The decoded script content in 4104 is the single richest evidence source in the whole lab.

What Slipped Through at First

This is the part that changed how I think about detection.

Slow password spraying (T1110.003). When I spread the attempts out, one or two failed logons per account per hour, the brute force correlation rule never fired. The rule counts failures inside a short window. Stay under the window and you are invisible to it. Every individual 4625 was sitting in the logs. Nothing joined them together. I had to write a rule that counts failed logons per source across a much longer timeframe, and a second one that counts distinct accounts targeted from one source, which is the real spray pattern.

Kerberoasting (T1558.003) produced no alert at all in the default setup. The ticket request is a normal Kerberos event, 4769, and it only looks wrong when you check the encryption type. RC4, 0x17, on a service ticket is the tell. I covered the full fix in the Kerberoasting walkthrough, including the custom Wazuh rule that watches for exactly that.

DNS tunnelling (T1071.001) was invisible until I started collecting DNS query logs properly. A SIEM cannot alert on data it never receives. Once the DNS logs were flowing, long subdomain queries stood out fast. Before that, nothing. The lesson keeps repeating in this lab: most detection gaps are logging gaps first.

Living off the land activity, certutil downloads, rundll32 calling out, bitsadmin transfers, mostly blended into normal admin noise. Single events fired here and there, but nothing that would make an analyst stop scrolling. These are still my weakest detections, and I would rather admit that than pretend a green dashboard means coverage.

What I Tuned

The tuning work fell into three buckets:

Thresholds. Brute force rules rewritten for two patterns: many failures fast, and few failures spread across many accounts.
Custom rules for quiet techniques. Kerberoasting via 4769 with RC4. Service installs via 7045. Account creation followed by a group add inside ten minutes, chained as a composite alert.
Noise reduction. Windows event logs are verbose and most of it is worthless. I spent as much time suppressing repeat noise, chatty services, health check logons, my own admin activity from the Kali box during setup, as I did writing new detections. An analyst who gets 400 alerts a day reads none of them. Getting the lab down to a feed I would actually trust was real SOC work, not housekeeping.

The Honest Scorecard

Out of 50 plus simulations: the majority were caught by default rules or light tuning. A meaningful minority, mostly the slow and quiet techniques, needed custom rules after I found them by hand in the logs. A handful around living off the land behaviour are still partial. That spread matches what working analysts describe in real environments, which is exactly why the lab is worth running. Vendor demos do not tell you where your blind spots are. Attacking your own network does.

Next in the lab: chaining techniques into one multi stage run, persistence through detection, and treating it like a real incident from first alert to written report.