Your incident response plan was written for an attacker who isn’t coming
- Lindsay Timcke

- May 11
- 2 min read
Most IR playbooks assume an hours-to-days timeline. Detect, triage, contain, eradicate, recover. I’ve sat on the other side of that diagram. The timeline doesn’t match what a competent operator actually does.
Here’s what the first ninety minutes look like from the attacker’s seat. Initial access lands, usually a phish, sometimes credentials bought from an infostealer log six weeks ago. Five minutes in, I’m running BloodHound against your AD, mapping every path to Domain Admin without touching a single tool your EDR flags. Ten minutes, I’ve kerberoasted three service accounts and queued the hashes for offline cracking. Twenty, I’ve dumped LSASS and pulled credentials for everyone who logged in this week. Forty, I’m moving laterally on legitimate creds, your detections see a sysadmin doing sysadmin things. Sixty, I have a foothold on your file server, your backup infrastructure, and one box in the DMZ. Ninety, I’ve established persistence through a scheduled task, a WMI event subscription on a different host, and a registry run key on a third, three independent mechanisms on three different machines. If I am feeling bold I will lastly shut down backups :) Then I go quiet.
That’s the part your plan misses. By the time your SOC opens a ticket, I’m not there. I’m waiting. Days, sometimes weeks. When you find the scheduled task and celebrate the eviction, the WMI subscription is still alive and I haven’t logged in from that infrastructure since the day I planted it.
What I’d change if I were rewriting your IR plan:
Stop measuring response in hours and start measuring it in attacker actions. If your tabletop assumes the adversary is still typing when you contain, you’re rehearsing a fantasy. Build scenarios where the operator left forty-eight hours ago and the only evidence is a beacon that hasn’t called home yet.
Treat eviction as a hypothesis, not a milestone. Every persistence mechanism you remove, assume there are two more you didn’t find. Hunt for the second and third before you declare the incident closed. The operator who spent ninety minutes establishing access didn’t spend it building one backdoor.
Run detection engineering against recon and lateral movement, not the payload. By the time something explodes on disk, the engagement is lost. The window where you can actually catch a competent operator is the twenty minutes they spent looking like a sysadmin.
Most eviction declarations I’ve reviewed were premature. The operator was already gone, and the second mechanism was already waiting.
Plan for the attacker who left, not the one you hope is still there.
