Chokepoint Identification Framework
For every technique an attacker uses, ask: what must be true, and which of those conditions does the attacker have no control over? Those uncontrollable prerequisites are chokepoints. Detect the chokepoint, detect all current and future variations.
Adapted from Matt Graeber's threat research methodology at Red Canary.
The 6-Step Process
Work through these questions in order for each technique. Steps 1-3 build understanding. Step 4 identifies the chokepoint. Steps 5-6 turn it into a detection.
What is this technique at a technical level?
Define the objective. What does the attacker need to accomplish? Gain initial access? Move laterally? Evade defenses?
What must be true for it to succeed?
Identify the required components. Every prerequisite that must be satisfied, regardless of the tool used.
What does the attacker control?
The variables. Tool choice (Impacket, CrackMapExec, PsExec), obfuscation methods, infrastructure, binary names.
What can't the attacker control?
THIS IS THE CHOKEPOINTThe prerequisites from step 2 that no tool rotation, obfuscation, or variant can eliminate. These are your detection anchors.
Can we observe it?
Map to log sources and telemetry. Sysmon event IDs, ETW providers, network artifacts, EDR hooks.
What are all the variations?
Every tool and method that shares this chokepoint. One detection anchored to the invariant covers all of them.
Detection Maturity Model
Start broad, refine to production. Don't skip levels. The research rule establishes the behavioral baseline. Without it you cannot tune intelligently.
Establish visibility
Baseline understanding of the chokepoint in your environment. High false positive rate expected. Not for alerting.
process_creation
where ParentImage endswith
'services.exe'
and LogonType = 3
Reduce noise, keep coverage
Add context: parent process constraints, user filtering, timing windows. Noise drops. Coverage holds.
process_creation
where ParentImage endswith
'services.exe'
and LogonType = 3
and User != 'SYSTEM'
and Image not in
(known_service_binaries)
Production SOC alerting
High-fidelity, correlated events. Minimal false positives. Your SOC acts on these without second-guessing.
process_creation
where ParentImage endswith
'services.exe'
and LogonType = 3
and User != 'SYSTEM'
and Image not in
(known_service_binaries)
and Image path not in
(Program Files, System32)
and correlated with
EID 4624 Type 3 within 5s
Chokepoint Detection vs. Tool Detection
FRAGILE Tool Detection
- Detects a specific tool by name or hash
- Breaks when the tool is renamed or replaced
- Narrow coverage: one threat family
- Requires constant signature updates
- High long-term maintenance cost
CommandLine contains "psexec.exe"
// Bypassed by: renaming, different tools
DURABLE Chokepoint Detection
- Detects the requirement the tool must satisfy
- Survives tool rotation, obfuscation, and variation
- Broad coverage: all families sharing the chokepoint
- Durable. New tools hit the same chokepoints.
- Low long-term maintenance cost
Service creation via network logon
// Catches: psexec, wmiexec, smbexec, future tools
Chokepoint Relationship Map
How chokepoints connect to MITRE ATT&CK techniques, tactics, and tool variations. Click a tactic to filter. Click any node to explore.
Testing Your Chokepoint
Four questions. All must be yes for a valid, durable chokepoint.
Can they achieve the objective without meeting these conditions? If no, valid chokepoint.
Does this detection break if the attacker switches tools? If no, good chokepoint.
Does this detection apply to more than one tool or malware family? If yes, strong chokepoint.
Is this detection likely to remain effective without constant tuning? If yes, durable chokepoint.
Start Building
Pick a chokepoint. Apply the 6 steps. Write your first detection.