What the SOC Analyst path actually taught me — running my own SIEM alongside it

I finished the SOC Analyst path on Hack The Box a little while ago. There are already a lot of “my takeaways” posts about it, so I’ll try to make this one actually worth your time: I went through it while running my own purple team lab — Wazuh SIEM, my own detection rules, an environment I’d built and then attacked myself. That changed which parts stuck, and it’s an angle most reviews don’t have.

Short version — it’s a strong path. But the thing I got the most out of wasn’t any single module. It was watching a detection work, then realizing how little it takes to break it.

What it covers

The range is genuinely wide: network traffic analysis, SIEM investigation (a lot of Splunk), digital forensics, malware analysis, threat hunting, and detection-as-code with YARA and Sigma. If you come in strong on one side and weak on another — I knew defense better than forensics — it’ll fill gaps you didn’t know were there.

The SIEM and detection parts hit hardest for me, and the reason is simple: I could test them against something real the same day I read them.

The Splunk stuff translated straight into my own SIEM

This was the biggest practical win, and honestly the reason I’d tell anyone to do the path with a lab open next to them.

The detections are taught in Splunk’s SPL. I don’t run Splunk, I run Wazuh. So for a good chunk of them I didn’t just read the query — I rewrote the logic as a Wazuh rule and fired it at my own lab to see if it held.

A few carried over almost one-to-one:

• DCSync — the Splunk query keys on event 4662 with the directory-replication right and drops machine accounts. Exactly the logic I needed in Wazuh: match the replication rights, exclude the accounts ending in $ so normal DC-to-DC traffic doesn’t bury you.
• PsExec — the path catches it by watching services.exe rewrite a service’s ImagePath in the registry. That idea holds in any SIEM, because you’re not matching a tool’s name, you’re matching what the tool is forced to do.
• Recon with native binaries — clustering whoami, net, ipconfig, netstat out of Sysmon process events. I already ran a version of this, but the path tightened how I thought about it.

The thing underneath all of them clicked about halfway through: a detection is just logic plus a field mapping, and only the logic travels. Splunk calls a field Image. Wazuh calls the same thing data.win.eventdata.image. Get that wrong and you’ve got a perfectly valid rule that quietly never fires — no error, just silence. Once that landed, the whole “but it’s all Splunk” complaint people have about the path stopped mattering to me. I read the SPL as the idea and rebuilt it where I actually work.

The part I didn’t expect: I learned as much about evasion as detection

This is the bit that surprised me, coming from a path that’s supposed to be blue team.

Learning how something gets caught teaches you how it slips past, almost for free — because every detection rests on an assumption, and breaking assumptions is the whole game on the other side.

What made it stick was that the path is honest about it instead of pretending the rules are bulletproof:

• The LSASS credential-dumping detection watches for a process reading LSASS memory with a suspicious call trace — and then flat out says an attacker can slip past the filter by naming a DLL so it dodges the exclusion. The detection is real. It’s also a filter, and filters have edges.
• The PsExec detection has three layers because the first two collapse the moment the attacker renames things. The third falls back to the named pipe, which is a lot harder to hide.
• On the YARA side, matching malware by its section names is trivial to evade — the better move is measuring entropy, because that’s not a string the attacker gets to pick.

I’d already walked into this one myself. Early on I wrote a rule that matched a lateral-movement tool by its binary name, felt clever, then ran the actual tool — which randomizes every name specifically to beat that. The path kept hammering the same point from different directions: match the behavior an attacker can’t avoid, not the strings they fully control. That’s a lesson that cuts both ways, which is why I’d hand this path to a red teamer too, not just someone aiming for a SOC seat. Knowing what the defender sees is half of getting past them.

Two things worth flagging

Not everything is perfect, so:

• Some of the malware material is dated. It leans on the old textbook buckets — virus, worm, trojan — when modern malware is modular and better described by what it does than what it “is.” Ransomware is framed around the encryption, too, when the reality now is double extortion: exfiltrate first, encrypt second. That actually changes the detection priority — catching the big outbound transfer often beats catching the encryption.
• Sigma isn’t drop-in everywhere. It’s a great idea — vendor-neutral detection logic — but Wazuh has no clean import. You convert and map fields by hand, and even a clean conversion isn’t a working detection until the fields line up and the logs actually exist. Same lesson as the Splunk translation, just with more YAML.

Where it leaves me

The path did what I wanted it to. It pulled together a lot of what I’d been doing by hand, handed me detections I could port straight into my own SIEM, and — the part I didn’t see coming — changed how I think about evasion. CDSA is the next step; I’ll sit it when the timing’s right. The path was worth it on its own regardless.

If you do it, one bit of advice: don’t just read the detections. Rebuild them somewhere you can actually attack. That’s the moment they stop being SPL queries and turn into something you understand.