The constant, up top

Every entry leads with the invariant, the thing that doesn’t change. For ClickFix it’s:

Clipboard write → user pastes into interpreter → outbound C2 connection.

Alongside it you get the quick read on the technique: severity (HIGH), prevalence (HIGH), detection difficulty (LOW), and the ATT&CK mapping (T1204.004, malicious copy-paste). That one line is the whole reason the entry exists. It holds across every variant the project tracks, so if you instrument it, you’re not chasing names.

The chokepoint, broken into stages

The entry doesn’t hand you a single rule. It breaks the invariant into the stages the attacker has to move through, and each stage is its own detection opportunity:

1. Clipboard Seeding: the lure page writes a command to the clipboard via JavaScript and shows paste instructions. Both have to be true; that co-occurrence is the tell.
2. Interpreter Execution: a script interpreter spawns as a child of explorer.exe, a browser, or wt.exe.
3. Second Stage Retrieval: the interpreter reaches out to attacker infrastructure to pull the real payload.

The reason this matters: if one stage is blind in your environment, you still have two more shots at it. You’re not betting the detection on a single event.

Detection at the tier your SOC can actually run

Each stage carries rules at the maturity tiers, and, where it’s possible, earlier pre-execution options like an ETW clipboard-write rule or an IOK rule on the lure page itself. For every rule the entry spells out:

• Goal: what the rule is trying to catch
• Log / Data Sources: what you need to be collecting for it to work
• FP Rate: how noisy it’ll be
• Use Case: when to deploy it (baseline, hunt, or production alert)
• Detection Logic: the condition in plain pseudocode
• Bypass Risk: how it can be evaded, stated honestly
• Sigma rule: the full YAML, copy it or pull it from GitHub

So you’re not just told “detect ClickFix.” You’re told what to deploy, where, and what it’ll cost you in noise, which is the part that decides whether a detection survives contact with a real SOC.

Variations: the proof the chokepoint holds

The entry tracks nine variants: the original ClickFix, FileFix, TerminalFix, DownloadFix, the JackFix/GlitchFix/ConsentFix family, WebDAV ClickFix, InstallFix, a Windows Terminal version that parents off wt.exe, and a DNS-based one that stages its payload through nslookup to dodge URL filtering. Each one shows the lure the user sees, a defanged copy of the clipboard payload, and a one-line note that it routes through the same chokepoint.

That’s the point of the section. It’s not a list to memorize: it’s evidence. Every new lure since 2024 still funnels through clipboard seeding, interpreter execution, and a network callback. The constant held.

The evidence, and a way to generate it yourself

Two sections I lean on the most. Raw Log Samples shows the real Sysmon events the chain produces: process creation (the interpreter spawning), the DNS query, and the outbound network connection, so you know exactly what you’re looking for before you go looking. And Emulation gives you a lab-only script that reproduces the behavior, so you can fire the chain in a controlled box and confirm your rules actually trigger. I don’t deploy a detection I’ve never watched fire, and this is how you avoid having to.

Rounding it out, OSINT Pivots gives URLScan and VirusTotal queries to hunt the infrastructure, and Related Chokepoints links out to the entries this commonly chains with (Renamed RMM Tools, Ransomware Service Manipulation) so you can follow the kill chain instead of stopping at one step.

That’s the whole shape

Invariant up top, staged detections in the middle, variants and raw telemetry to back it, emulation to test it. Every chokepoint in the project is built the same way; ClickFix is just a good one to learn on. Pick the stage your telemetry already covers, deploy the Research-tier rule, watch it in your environment, and climb from there.

Browse it for yourself: the ClickFix entry.

A better way to think about it is to flip the question. Instead of asking what the attacker is using, ask what part of this they can’t change.

What a chokepoint actually is

The term comes from military strategy. You force an opponent into a narrow passage they have to move through to reach their objective, and that bottleneck is where you hold the advantage: they can’t bring their full strength through it. It isn’t a new idea in detection engineering, either. The chokepoint language I use comes straight out of Matt Graeber’s threat research at Red Canary. The way he framed how to research a technique (work through what has to be true for it to succeed, then find the step the attacker can’t control) stuck with me, and it’s genuinely how I think about threats now. That step they can’t control is the chokepoint, and it’s where durable detection lives.

Take credential theft from LSASS. There are a lot of tools that do it (Mimikatz, comsvcs.dll, ProcDump, Nanodump, the credential-dumping built-ins in just about every C2 framework) and they all use different code, different syscalls, and different tricks to stay quiet. But every one of them has to do the same thing:

Open a handle to lsass.exe and read its memory to get at the credential material.

The kernel mediates that handle. You can’t read the memory without it. The tooling has rotated for over a decade (the LOLBin era, direct syscalls, handle duplication, BYOVD PPL bypasses) and that one step never moved. It can’t, because it’s the mechanism of the technique. That’s the chokepoint.

Detection is a game of economics

Anchoring to an invariant isn’t only about durability: it’s about who pays. A detection pinned to a tool is a free reset for the attacker: rename it, recompile it, swap the whole framework, and your rule is dead at no cost to them. A detection pinned to the step they can’t skip makes every evasion attempt cost real engineering time. Time is money on both sides of this, and the whole game is to spend theirs instead of yours.

That trade gets more lopsided every year, because the offense keeps getting cheaper and faster. The 2020 ransomware chain was a manual, roughly 10–14-day affair: break in, run discovery, dump credentials, escalate, move laterally, then deploy. The 2025 version is broker-enabled and squeezed to under 48 hours, with whole phases (discovery, recon, often privilege escalation) skipped because someone else already did them. Mandiant’s M-Trends 2025 shows the same thing in aggregate: median dwell time has fallen year over year. You have far less window to catch an intrusion, so the detection had better sit on something that’s always present, not on a name you’d need luck to recognize in time.

And the inputs have commoditized. Infostealer logs are now a routine first step into a network (HudsonRock, Red Canary), and Initial Access Brokers sell that foothold pre-enriched: privilege level, access type, even which EDR is running in the environment (Cyberint). The tooling layered on top rotates constantly precisely because it’s cheap and interchangeable, which is the exact reason a detection pinned to it keeps dying.

A chokepoint is where you flip that math. Because unrelated threats overlap on the same invariant steps, one detection placed there covers many actors at once, and one log source ends up catching many techniques: you pay the engineering cost once, on the part that can’t change, instead of re-paying it for every renamed tool. And because you’re reasoning about what has to be true for the technique to work, you can usually see the next variation coming before it even has a name.

That’s the bet the whole project makes: when the tooling rotates and the TTPs evolve, the chokepoint remains.

So I built a place to keep them

Detection Chokepoints is a free, open knowledge base built around that one question, applied across techniques. Right now there are 13 chokepoint entries spanning six ATT&CK tactics (initial access, execution, defense evasion, credential access, lateral movement, and persistence) with more on the way.

Each entry isn’t a single rule. It breaks the technique down to its invariant, the observable that exposes it, the log sources that cover it, and the actual detection logic. And the rules come at three maturity tiers, because where you deploy a detection matters as much as whether it’s correct:

Tier	What it’s for
Research	Broad baseline, high noise: for establishing visibility, not for alerting
Hunt	Behavioral context, moderate noise: for periodic sweeps and analyst triage
Analyst	Production-ready, low noise: for the alert that pages someone

The tiers exist because the most common way a good detection idea dies is someone dropping the high-fidelity rule straight into an environment that was never baselined, drowning in false positives, and ripping it out. Start at Research, learn what normal looks like in your environment, then climb.

Beyond the chokepoint entries, Attack Chains look at where unrelated actors converge on the same kill-chain stage: when several groups all route through the same step, that overlap is your priority, because the adversaries effectively voted on it for you.

Trends

Chokepoints tell you what’s invariant; Trends tell you what’s moving. This section is data-driven analysis of how the landscape is shifting (which delivery families are accelerating, which evasions are showing up, which variant is about to become the dominant one) so you can tune the Hunt-tier rule before the wave instead of after the incident.

The methodology that ties all of it together lives in the Framework section: every technique gets worked through the same three questions: what’s its scope (one technique, or a chain of them?), what variations exist or could plausibly exist, and what prerequisites have to be true for it to work at all. That last question is where the chokepoint falls out: the prerequisite that can’t be designed away. I’ll give Attack Chains and Trends a closer look in their own post.

The example that made it click

The idea crystallized for me with ClickFix. I spent a while pulling that family apart for Huntress, and the variants just kept coming: FileFix, TerminalFix, DownloadFix, each with a different lure. Chase the variants and you’re back on the treadmill. But step back and they all funnel through the same place: a user is talked into running a command, a scripting interpreter executes it under explorer.exe or a browser, and a second stage comes down from the network. Detect that shape and you catch the variants that haven’t been named yet. If you want to see what that looks like as an actual entry (the staged detections, the Sigma rules, the emulation script) I walked through the ClickFix one here.

Where to start

None of this replaces keeping up with tooling. But if you’re underwater and don’t know where to begin, start with what the attacker can’t avoid. Pick a chokepoint, deploy the Research-tier rule, watch it for a week to learn your noise, and climb the tiers from there. When the tool rotates next month, your detection is still sitting on the part that can’t change.

It’s all open on GitHub. If you’ve reverse-engineered a technique down to its invariant, or you spot one I’ve gotten wrong, I’d genuinely like to hear it: Detection Chokepoints.