Post-Block Blindness
- Category
- Detection & Response Process
- Published
- Jun 29, 2026
- Updated
- Aug 28, 2026
The Failure
An endpoint detection control blocks a technique — a binary execution, a lateral movement attempt, the start of encryption. The alert gets classified as “blocked,” therefore “handled.” No one reconstructs what preceded the block (how the attacker got into position to attempt the technique) or what followed it (what they’re doing now with the access they still hold).
The pattern is structural, not accidental: the triage process measures the alert’s status, not the adversary’s state. The queue rewards closing alerts, the tool presents the block as a final verdict, and no step in the process requires establishing a timeline. But a block is a data point about a technique at a given moment — not a conclusion about the intrusion. The control did its job; the process stops right where its own job began.
Why It Matters
An attacker who gets blocked doesn’t give up: they learn. The block costs them one technique; they pivot to another, often less well covered. Meanwhile, the defense considers the matter closed — that’s the asymmetry of this pattern: the same event informs the attacker and reassures the defender.
In practice: initial access is retained (valid credentials, an open session, a persistence mechanism already in place), progression continues through other means, and actual discovery happens weeks later, often at the point of impact. The window between the block and discovery is dwell time handed over for free.
The cost gets paid a second time during the investigation: you find the “blocked” alert, closed without analysis. The signal existed — timestamped, localized, actionable — and triggered no investigation. That’s the most common and most avoidable finding in post-mortems.
How to Identify It
Take the last ten alerts closed with a “blocked” or “quarantined” verdict, and check for each one:
- is there any record of investigation beyond the tool’s verdict — where the binary came from, which account was involved, what happened on the machine in the 30 minutes before and after?
- did the analyst check whether the same technique was attempted elsewhere?
Then question the process itself:
- does your triage procedure formally distinguish “the technique was blocked” from “the intrusion is over”?
- does a block on a server, a domain controller, or a privileged account trigger different handling than a block on an office workstation?
Simple measure: the rate of “blocked” alerts that led to a context search. If it’s close to zero, the pattern is present — regardless of how good the tooling is.
Fix Before the Incident
Set an explicit process rule: a block opens an investigation, it doesn’t close one.
- Define a minimum contextualization standard for post-block handling: origin of the file or action, account involved, machine timeline over a window bracketing the event, a search for the same technique across the rest of the estate.
- Prioritize by asset and by account, not by verdict: a block on an infrastructure server or an administrative account escalates automatically, even if it “succeeded.”
- Write a short post-block playbook with clear escalation thresholds: recurrence on the same machine, end-of-chain technique (encryption, backup deletion), a privileged target.
- Measure time-to-context and the post-block escalation rate, not just closure time — what you measure is what the team optimizes for.
If You’re Already in an Incident
The block history becomes a primary investigative source:
- review every block over the available retention period (90 days if possible) for the machines and accounts in scope: they often date the intrusion more precisely than the alert that triggered the incident;
- treat every past block as a free timeline data point — machine, account, technique, timestamp — and fold it into the incident timeline;
- treat machines with a history of blocks as scope to check first, even if nothing else was observed on them;
- never assume a blocked technique didn’t succeed elsewhere through another path: look for the technique’s objective (lateral movement, privilege escalation), not just its form.
The opposite reflex — dismissing blocks because they “worked” — reproduces the pattern during the incident itself.
Related Controls
- CIS Controls v8 — 17.4
- CIS Controls v8 — 17.8
- NIST CSF 2.0 — DE.AE-02
- NIST CSF 2.0 — RS.AN-03
- ISO 27001:2022 — A.5.25
- ISO 27001:2022 — A.5.26