Blue Team Autopsies — Article 2
Not because the tools missed it. Not because the logs were empty. The logs were full. Every move the attacker made was recorded, timestamped, sitting in the SIEM from Day 1. The IR team didn’t need to go digging when they finally got called in. They just scrolled back and watched it happen.
That’s the part that sticks with you. Not the breach itself. The scroll.
The attacker was in the network for 22 days.
What Was Actually Happening Inside the Network
I want to be specific about what happened here, because “the SIEM had the data” is one of those things people say without really unpacking what it means. So let me unpack it.
Day 1, 9:14 AM — someone logs into the VPN. Valid credentials. Right username, right password. Nothing looks wrong except the IP — Eastern Europe. This particular employee had never once logged in from outside the country. Four years of history, all domestic. That fact was sitting in the authentication logs and not a single rule was checking it. So the login went through, no alert, completely clean.
Next day they started looking around. Ran net user /domain. Ran net group "Domain Admins" /domain. Standard stuff — it’s what attackers do when they want to understand the layout, figure out who has the keys, plan their next move. Windows flagged every one of those commands. Event IDs 4661, 4662 — they exist specifically for this. All logged. Nobody watching.
Then came the slow part, Days 5 through 18. Files started moving to a staging folder. Not a big dump — that would’ve been obvious. Small amounts. 200MB one week, 350MB a few days later, a gap, then 180MB, then 420. Spread out deliberately, always under whatever threshold might have triggered something. The account had legitimate access to those files — finance records, legal docs, engineering stuff — so nothing looked wrong on the surface. There was no baseline for what “normal” looked like for that account, so there was nothing to compare it against.
Days 19 through 21, the files left. Three sessions, always late at night, always after 11. Uploading to attacker-controlled cloud storage. Here’s the thing though — the destination domain was already in the company’s threat intelligence feed. Flagged. The DNS logs had every single query to it. Both pieces of information were in the same SIEM. Nobody had written a rule that connected them.
Day 22, an analyst got a gut feeling about some outbound traffic. Not a rule. Not automation. A person, following their instinct. IR confirmed the breach within hours.
Twenty-two days.
Everything Was Logged. Nothing Was Covered.
I keep coming back to this table because I think it’s the most honest summary of what went wrong:
| What Happened | In the Logs? | Any Rule Covering It? |
|---|---|---|
| VPN login from a country this user never used | Yes | No |
| Standard account running domain enumeration | Yes | No |
| 1,847 files accessed that account never touched before | Yes | No |
| DNS queries to a flagged exfil domain | Yes | No |
| Malicious file dropped on an endpoint | Never happened | 47 rules waiting for it |
That last row. Forty-seven rules, all pointed at something the attacker never did.
Three Failures That Made This Possible
Failure 1 — The Team Was Still Fighting a 2019 Threat Model
All the detection work was built around catching malware — bad hashes, suspicious process names, known file signatures. Solid work. Genuinely. Just completely beside the point when the attacker walks in with a real password and uses tools that shipped with Windows. There was no weapon to detect. The metal detector was perfect. The attacker had a badge.
Failure 2 — Empty Queue Meant Clean Network. It Didn’t.
The analysts cleared their queue every day. Dashboard was green. Internally that read as: we’re fine. But a detection rule only catches what you thought to write a rule for. If the attacker does something outside that set — different tool, different path, slower pace — the rule produces nothing. And silence looks identical whether your network is clean or whether someone’s been quietly inside it for three weeks.
I genuinely think this is the most dangerous assumption in security operations right now. Not the sophisticated attacks. The assumption that if nothing fired, nothing happened.
Alert queue empty → No rules matched → Threats outside rule coverage go unseen.
The queue being empty tells you what your rules found. It tells you nothing about what they missed.
Failure 3 — The Intelligence Was Paid For. Never Used.
The feed was ingested. The domain was in it. The DNS queries were in the logs. Two facts, same platform, zero connection between them. This happens more than anyone wants to admit — organisations buy threat intelligence, tick the box, and never actually operationalise it into live detection logic. It’s just data in a table at that point. It doesn’t protect anything.
What They Fixed After the Breach
| Gap | Fix |
|---|---|
| No VPN geography baseline | First login from any new country triggers immediate alert |
| Domain enumeration by standard users | Event IDs 4661/4662 alert on any non-privileged account |
| No file access volume detection | Alert fires if daily access exceeds 3× the user’s 90-day average |
| Threat intel not joined to DNS | DNS query to any IOC in the feed → high-severity alert, case opened automatically |
| No threat hunting programme | Two structured hunts per week; each analyst owns one active hypothesis |
| Coverage never audited | Monthly log source vs. rule coverage review — gaps formally tracked |
But honestly the biggest change wasn’t technical.
They stopped telling leadership “we closed 340 alerts this week.” They started telling them “68% of our log sources have active detection coverage.” Those are completely different numbers and they tell completely different stories. The first one sounds busy. The second one tells you the actual shape of your blind spots.
When leadership saw that percentage for the first time, the conversation about resourcing changed immediately.
Three Questions to Ask Your Team This Week
1. Which log sources do we ingest that have zero detection rules using them?
Go find out. The answer will surprise you.
2. When did we last run an actual threat hunt — not alert triage, a real hypothesis driven into raw data?
If you can’t name a date, you haven’t run one.
3. For every threat intel feed we’re paying for — which SIEM rule operationalises it?
If you can’t point to the rule, the feed isn’t protecting you. It’s just costing you money.
The Line That Should Stay With You
22 days. Fully staffed SOC. SIEM running. Evidence logged from Day 1.
Nobody asked the right questions.
If you’re an analyst — your most valuable work isn’t the alerts you close. It’s the threat that never generated one that you go find anyway.
If you’re a threat hunter — the space between your rules isn’t empty just because no alert fired there. Go look.
If you’re a security manager — you’re probably measuring how busy your team is. Start measuring how much of your environment they can actually see.
This article is part of the Blue Team Autopsies series — stories about security that should have worked, and exactly why it didn’t.
Disclaimer: The scenario described in this article is fictional and constructed for educational purposes only. It is based on common real-world attack patterns and detection failures but does not represent any specific organization or confirmed incident. Technical details are illustrative. Nothing here constitutes legal, compliance, or security advice. Always test detection changes in your own environment before deploying to production.
Leave a Reply