A Simple Story About Why Security Rules Fail in the Real World
How It Started
A security engineer spent two weeks building what seemed like a perfect detection rule.
The rule was simple: if Microsoft Word launches PowerShell, fire an alert. This is a classic attack pattern — a malicious Word document runs a macro, the macro launches PowerShell, PowerShell does the damage. The engineer tested it in the lab. It worked every time. They felt confident, closed the ticket, and moved on. Three months later, the company had a breach. The rule never fired. The attacker was inside the network for six hours before anyone noticed.
Here is exactly what went wrong — and why it matters to every security team.
Attack Explanation
Step 1: Victim receives phishing email Attachment: invoice_july.docmStep 2: Victim opens file, clicks "Enable Macros" ← This single click starts everythingStep 3: Macro runs silently in the background Attacker now has accessStep 4: Six hours pass undetected ├── Network explored ├── Passwords stolen └── Files sent to attacker's cloud storageStep 5: Attacker logs into a server using stolen passwords ← THIS triggers an unrelated alert ← Too late. Damage already done.
Three Reasons the Rule Failed
Reason 1: The Attacker Used a Different Tool
The rule watched for Word launching PowerShell. The attacker used mshta.exe instead — a legitimate Windows program that does a similar job. Same result, different tool. Rule never fired.
Think of it like this:
Your security camera watches the front door. The burglar came in through the back window. The camera worked perfectly. It just watched the wrong entrance.
Windows has dozens of built-in tools an attacker can use instead of PowerShell — mshta, wscript, rundll32, regsvr32. Attackers know this list by heart. The rule only covered one item on a very long menu.
Reason 2: The Attack Came Through a Different Parent
The rule required Word to be the direct parent of the suspicious process.
But the Word document had an embedded Excel object inside it. When the macro ran, the actual process chain looked like this:
Word opened the document └─ Word asked Excel to handle the embedded object └─ Excel launched mshta.exe ← the malicious process
The rule was watching for:
Word → PowerShell (expected)
What actually happened:
Word → Excel → mshta.exe (reality)
The rule needed both conditions to be true at the same time. Neither was. The attacker used a middleman — Excel — that the rule wasn’t watching
Reason 3: The Rule Existed. The Data Didn’t.
This is the most painful one.
While the engineer was testing in the lab, the IT team quietly pushed a new configuration to all 400 company computers to reduce storage costs. That new configuration accidentally removed the monitoring that the security rule depended on.
What the engineer believed:├── Sysmon is running ✓├── Rule exists in the SIEM ✓└── We are protected ✓ ← WRONGWhat was actually true:├── Sysmon is running ✓├── Rule exists in the SIEM ✓└── Data never reaches SIEM ✗
The rule was perfect. The data pipeline was silently broken. Nobody knew — until the incident.
Silence doesn’t mean safety. Silence might mean your monitoring is broken and you can’t tell the difference.
What They Fixed
| Problem | Fix |
|---|---|
| Only watched PowerShell | Now watches all known attacker tools |
| Only watched Word as parent | Now watches Word, Excel, Outlook, OneNote |
| Only looked one level up | Now traces three levels up the process chain |
| Only tested in lab | Now runs live weekly tests on real computers |
| No pipeline monitoring | Now alerts if log volume drops by 20% |
The biggest long-term change was the hardest one: stop trying to list all the bad things. Start learning what normal looks like — and alert on everything that isn’t normal.
This article is part of the Blue Team Autopsies series — stories about security configurations that should have worked, and the specific reasons they 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