The first post in this series made the case for detecting the part of an attack that can’t change. The second walked through one chokepoint entry. The third zoomed out to the attack-chain level and looked at where unrelated operators land on the same techniques. This one is about the part that does change.

The Trends page tracks the movement around a chokepoint: which payload cradles are gaining use, which exploit campaigns are moving from recon to weaponization, and which infrastructure traits survive after a fake download domain gets burned. The chokepoint tells you where to anchor a detection. Trend data tells you what needs tuning around that anchor right now.

TL;DR for busy defenders

• Treat trend data as a tuning input, not an internet-wide prevalence score. Keep the detection pinned to the invariant and use the movement around it to decide which variations need attention.
• For ClickFix, anchor on the unusual parent → interpreter relationship. Keep network-fetch and inline decode-and-execute coverage in parallel, and don’t retire an old cradle rule just because its line briefly drops to zero.
• For exposed edge devices, watch the change from reconnaissance to weaponized exploitation. Check your inventory, patch state, and appliance logging before chasing source IPs.
• A fake software domain is the start of a masquerading hunt, not the finish. Pivot through reused favicons, signers, and backend paths, then move the final detection to execution behavior that survives the next brand or domain change.

A note on the data: this is a best-effort analysis, and it may be incomplete. I’m one person aggregating sources that cover different windows and have different blind spots. Some records and classifications will be incomplete or wrong, and the findings may change as the datasets improve.

The point is what defenders can do with the data available to them. Free sources, paid sources when they’re affordable, and datasets we collect ourselves can expose a technique shift or an infrastructure pattern before the same activity reaches our own environment. It won’t predict every campaign, but a repeated pattern can give us time to verify visibility and decide whether to tune a hunt or close an exposure before it reaches us.

A trend needs to change a defensive decision

Security reports are full of rising percentages. A technique is up, a malware family is down, and some sector is being targeted more than another. Those numbers can be useful, but only if they lead to a decision. Otherwise they are threat-intelligence trivia.

The Trends section is built around a stricter test: after reading the data, what would I deploy, tune, validate, or prioritize differently?

That also means the pages are not trying to measure the entire internet. Each dataset has a collection boundary. ClickGrab sees what its crawlers find. Defused sees what reaches its decoys. My software-impersonation data sees what a set of passive hunts and public reports can validate. Those are three different windows, not three interchangeable prevalence studies. The collection method stays attached to the result so a defender can judge what the number actually supports.

ClickFix: watch the delivery method rotate

The ClickFix trend analysis combines two datasets that cover different parts of the problem. MHaggis ClickGrab provides nightly crawl volume across more than 25,000 sites. ClickFix Hunter provides the per-domain clipboard commands needed to classify what the lure tells the victim to run.

One gives scale. The other gives behavior. Putting them together turns a pile of malicious domains into a time series of execution choices.

The cradle chart is the easiest example of why this matters. IWR and IEX dropped as WebClient and curl rose in December 2025, then IWR returned in March. If I had treated the first drop as the end of IWR-based delivery and removed the rule, I would have created the gap myself. Tradecraft does not move in one direction. Operators reuse whatever is cheap and working again.

The same data catches larger changes. MSIExec delivery jumped to 87 percent of observed domains in November, which broke PowerShell-only coverage while leaving the clipboard-to-execution chokepoint intact. By May 2026, 92 percent of observed domains carried no URL in the clipboard command. Inline encoded payloads removed the network fetch that many ClickFix detections expected. A WebDAV variant went farther and used conhost --headless with a UNC path, avoiding both PowerShell and an HTTP URL in the pasted command.

None of those changes make ClickFix undetectable. They tell us which layer became brittle.

How to use it: keep the unusual parent-to-interpreter rule as the anchor, then run parallel coverage for the current delivery branches. That means a network-fetch rule for traditional cradles, decode-and-execute coverage for Base64 and hex-XOR payloads, and process creation coverage for MSIExec, mshta, and headless conhost from Run-dialog or terminal context. Use the monthly chart to change the priority and expected volume of those hunts, not to delete coverage when a line temporarily reaches zero.

The data also helps with validation. If a campaign rotates from IWR to curl, replay both branches in the lab. A chokepoint claim is stronger when a new variation arrives and the behavioral rule still fires. If it does not, the trend page has found a real coverage gap instead of another string to add to a blocklist.

Defused: separate scanning from committed exploitation

The edge-device exploit analysis starts with Defused Cyber honeypot telemetry. The current page covers 25,420 high and critical exploit attempts across more than 25 decoy types, collected in two windows from March 14 through May 19, 2026. More than 50 CVEs appear in the aggregate.

Raw volume is the obvious chart to build from that data, but it is not the most useful one. A spike can be one scanner retrying, a public proof of concept spreading, or several operators moving into weaponized exploitation. Those situations should not produce the same response.

The page splits targeted reconnaissance from alerts Defused classified as weaponized exploitation. That creates an early-warning question: for which CVEs did probing appear before the first exploit, and how much time separated them? It also keeps a high-volume scan from looking more operationally important than a lower-volume campaign that has already reached webshell deployment.

The Cisco SD-WAN activity is a good example. The honeypots recorded operators moving through reconnaissance, authentication bypass, webshell upload, and cryptominer deployment. At that point the useful output is no longer “these IPs scanned a decoy.” It is the set of requests and state changes each operator had to produce to cross those stages.

How to use it: first, intersect the targeted products with your external inventory. If a decoy type is heating up and you own the same product, confirm exposure and patch state before writing a rule. Then validate that the product’s authentication, HTTP, file-write, and outbound network logs reach the SIEM. Build detection around the exploit’s required request or state change, and add an egress hunt for an appliance reaching a new payload host. Source IPs are enrichment. They are not the durable part of the detection.

The recon-versus-exploit split is also useful for prioritization. A rising recon line can move a CVE into the next hunt cycle before weaponization reaches your environment. A confirmed exploit chain should move it out of the backlog entirely. This is one of the few places where a public honeypot can directly inform patching, telemetry, and detection work without pretending its hit count is a global victim count.

Masquerading infrastructure: turn one fake site into a hunt

The software-impersonation page is the dataset I am still building. It tracks infrastructure that impersonates legitimate software brands to deliver a fake installer or a paste-to-run command. The current view combines five validated hunts across five brands with an aggregate IOC pipeline. Two hunts have confirmed payload delivery.

This dataset starts closer to the analyst workflow than the other two. Find one suspicious download page, validate the delivery chain with passive public telemetry, then ask which artifacts can find its siblings. A stolen favicon may lead to other fake domains. A code-signing identity may connect rotated binaries. A reused PHP tracking path can expose the same affiliate kit on another brand.

The current hunts show two delivery models aimed at the same general audience. One campaign used a fake ChatGPT installer, gated the download behind JavaScript, staged it on a CDN, and signed the binary with a shell-company certificate. Another cloned Claude Code install pages and gave Windows and macOS users different paste-to-run commands. One puts a signed file in Downloads. The other tries to skip the file and borrow the trust users already place in terminal installation commands.

Those require different endpoint detections, but the infrastructure research can still produce durable pivots. The fake ChatGPT page reused the real OpenAI favicon, which made favicon-hash hunting useful. Its JavaScript called a repeatable tracking backend and returned a per-visitor download URL. The installer signer outlived any one landing-page domain. On the ClickFix side, mshta retrieving a remote HTA and curl piped into a shell survive a change from Claude to whichever developer tool the kit copies next.

The failed pivots belong in the dataset too. A Notion favicon search produced thousands of legitimate third-party sites because Notion is widely embedded and used as a publishing backend. That is not a bad hunt result. It tells me favicon reuse is not selective enough for that brand, so the hunt needs title, domain-pattern, file-download, or execution context instead.

How to use it: start with a confirmed lure and keep discovery separate from validation. Use a favicon, certificate, redirect path, analytics ID, or backend endpoint to find candidates. Confirm which candidates actually deliver a file or command. Then translate the delivery behavior into an endpoint or proxy hunt: a newly downloaded signed installer executing from a user’s Downloads directory, correlated with recent browser download activity; mshta fetching from a non-enterprise domain; or curl piped to a shell from a terminal. Block the confirmed domains, but do not mistake that cleanup step for the detection.

What your own dataset needs

The three pages use different sources, but they pass through the same basic process. Start by defining what one row means. Is it a crawled site, a clipboard command, a honeypot alert, a validated campaign, or an IOC copied from another feed? Keep the collection dates, gaps, filters, and source attached. Without that context, a chart can look precise while measuring something nobody can explain.

The observations also need an attack-chain position. The point is not to force every row into ATT&CK. It is to separate the rotating choices from the required steps. For ClickFix, the cradle family rotates while user-driven execution stays fixed. For an edge exploit, the CVE and scanner rotate while the target still has to accept a request, change state, and often retrieve a payload. For masquerading infrastructure, the brand and domain rotate while the operator still has to stage something and persuade the victim to execute it.

From there, test whether a movement is a trend or one campaign passing through the collection window. The May Base64 spike in ClickFix looked enormous, but most of it came from one token in one campaign and collapsed the next month. Hex-XOR persisted across several months. Those should not receive the same weight in a roadmap.

The last step is attaching a defensive action. Every chart should end in a rule to tune, a log source to validate, an exposure to patch, or a hunt to run. If the conclusion is only “activity increased,” the analysis is not finished.

The three views belong together

Chokepoints, Attack Chains, and Trends are three views of the same detection problem.

A chokepoint asks what an attacker must do. An attack chain asks where different threats converge. A trend asks how the implementation around those fixed points is moving. The first gives the rule its anchor, the second helps decide where to spend engineering time, and the third tells you when the surrounding logic needs another look.

Start with the Trends landing page, pick the dataset closest to the telemetry you own, and trace one finding all the way to a defensive change. For ClickFix, that might be adding inline decode-and-execute coverage. For edge devices, it might be confirming that appliance HTTP logs exist before the next exploit wave. For a fake software site, it might be turning one domain into a signer or favicon hunt, then moving the final detection to the execution layer where brand rotation matters less.

TL;DR for busy defenders

• The five ransomware operators on the page use different tools, but all five converge on command and scripting interpreters (T1059), inhibit system recovery (T1490), and data encrypted for impact (T1486).
• Treat that overlap as a priority signal. The more unrelated actors depend on the same technique, the more detection coverage placed there can do for you.
• Write against the chokepoint row at the bottom of the matrix, not one actor’s tool inside a cell. Track new tools as variations unless they change the prerequisite itself.
• Follow the related chains upstream. Infostealer or AiTM activity can be the warning for the ransomware or identity-domination chain that consumes the stolen access next.

Different actors, same boxes

In my first post I discussed the concept of pinning detections to invariants instead of things an attacker can control; in the second post I went through my ClickFix chokepoint and explained how a defender could leverage it. This post zooms out to a whole kill chain, focusing on five ransomware actors, and the page that lines them up.

Why do unrelated threat actors keep landing on the same techniques? This is most likely caused by creating your own tools, using cracked or open source tools. Regardless, an operator who copied nothing is still subjected to the protocols of the environment they’re operating in. When a LockBit affiliate and a nation-state actor both dump LSASS, stop the backup service, and execute remote commands via SMB on another endpoint, they aren’t imitating each other; they’re obeying the same constraints. Convergence is architecture, not coincidence, and the spot where every threat is forced to converge is another way to think about where to invest your detection effort.

The ransomware attack chain explained

The ransomware attack chain is a great place to see it: five operators who share nothing but a business model (BlackBasta, LockBit 3.0, Akira, Alphv/BlackCat, Play). The whole approach is adapted from Kaspersky’s Common TTPs of Modern Ransomware (2022), which analyzed eight ransomware groups and found they all ran the same core kill chain no matter the tooling. This chain rebuilds that overlap analysis from 260 procedures across 36 reports through the Kitsune and ORKL pipeline.

The first view drops all five onto the full kill chain, every technique any of them used as a card with a dot per actor. It’s deliberately busy, and that’s the point: initial access alone shows five different techniques, so nobody converges on how they get in. The orange-bordered cards highlight when a TTP is used by all actors. Out of dozens, three light up: command and scripting interpreter (T1059) at execution, inhibit system recovery (T1490) and data encrypted for impact (T1486) at the end. Run code, neutralize recovery, encrypt. Everywhere else the threat actors diverge; here they can’t.

The graph also filters by actor. Select the two still active, Akira and Play, and nineteen cells light as shared, a common theme through execution, discovery, credential access, lateral movement, and impact. These two actors are otherwise unrelated, yet run nineteen of the same techniques.

From convergence to chokepoint to variation

Cells converge for two reasons. Sometimes the platform forces it: you can’t skip running code, killing recovery, or encrypting, so a detection there can’t be evaded. Other times a technique just isn’t worth avoiding, so nearly every actor takes the same cheap, reliable road, RDP for lateral movement or vssadmin for shadow-copy deletion. Either way the cell lights up across actors, and that’s your cue to look closer.

Looking closer takes two moves, and they line up with steps four and six of the project’s framework. First, name the chokepoint inside the convergence, the invariant the technique depends on, written to survive a tool swap: inhibit-recovery isn’t “vssadmin ran,” it’s “a SYSTEM-level process deleted the shadow copies.” That’s what the page’s per-stage chokepoint cards state, with the signals that expose each one. Second, track the variations inside it, every tool that satisfies that one prerequisite: vssadmin delete shadows, wmic shadowcopy delete, a PowerShell Win32_Shadowcopy call, a raw write to the volume. The variations are where evasion and false positives live, so you tune against them without moving the detection off the invariant.

The bottom shows the shape of the attack path

The third view is the table that names the page: five operators down the side, five stages across, each cell holding that actor’s tooling. The same actor filter drives it, so selecting actors lights their rows and fades the rest. Take the two still active, Akira and Play: their rows light up with completely different tooling (Akira on PowerTool and a Zemana driver, Play on GMER and IOBit) running the very same five stages.

The three rows dimmed behind them are already gone: BlackBasta inactive, LockBit disrupted, Alphv defunct, their tooling dead with the brand. Akira, the most prolific operator in the 2026 reporting (about 22% of cases per Sophos), runs nothing its predecessors ran and still lands in the same five boxes. The bottom row, labeled The Chokepoint, hasn’t moved. Detections written against the cells would have been rewritten several times in two years. If your detection approach maps the bottom row, you’d need to write a rule only once (an oversimplification of course, but trying to make a point).

From a matrix cell to a deployed rule

Let’s zoom in on the credential-access column. The bottom-row invariant is Elevated process reads memory/registry containing credential material, and the prime example is usually dumping LSASS. The chokepoint entry behind it lists two dozen tools (Mimikatz, comsvcs.dll, the built-in dumpers in Cobalt Strike and Sliver) and collapses them to one requirement:

A process must open a kernel-mediated handle to lsass.exe and read its virtual memory to extract credential material

For any user-mode credential dumper, this generally holds: NtOpenProcess has to cross into the kernel for the handle, and the kernel’s ObRegisterCallbacks fires on every request, standard API or direct syscall. The kernel emits Sysmon Event ID 10 when it does, so one telemetry source sits under all two dozen tools. A trimmed analyst-tier cut:

title: 'LSASS Credential Dump: Non-Standard Process with Dump Mechanism and Suspicious Access Rights'
logsource:
  category: process_access
  product: windows
detection:
  selection_lsass_target:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'
      - '0x1010'
  selection_dump_mechanism:
    CallTrace|contains:
      - 'dbgcore.dll'
      - 'dbghelp.dll'
      - 'UNKNOWN'
  # selection_nonstandard_source and filter_os_core elided for brevity
  condition: >
    (selection_lsass_target and selection_dump_mechanism and selection_nonstandard_source and not filter_os_core)
level: high

Reading the Sigma above, TargetImage is the invariant; GrantedAccess and CallTrace lift it out of the noise. It isn’t quite one rule (handle-duplication tools like HandleKatz and kernel-mode BYOVD reads shift or skip the handle), but those are variations on the chokepoint, not escapes from it. Which is why the same chokepoint ships at three tiers, scoped to exactly this behavior:

Tier	What it keys on for LSASS	False positives
Research	Any process opening a handle to lsass.exe (Sysmon EID 10)	High: AV, EDR, and backup agents all touch it
Hunt	EID 10 with a dump access mask (0x1010/0x1FFFFF) and a dbghelp/dbgcore/UNKNOWN CallTrace	Medium: some admin and forensic tooling
Analyst	The above, plus a source outside System32/Program Files, known-good filtered	Low: production alert

Start at the Research tier to confirm you even see EID 10 on lsass in your environment, then add context to climb to Hunt and Analyst. The invariant never changes across the three. That shape does two jobs at once: every known variant funnels through it, and when a new tool deviates from it, you’re seeing emerging tradecraft before it has a name.

What next year’s tradecraft does to the chain

These five ransomware operators are from a 2024-2025 snapshot. The real test is what happens when something genuinely new shows up, and three examples from this year each drop into a row that was already on the page.

Remote ransomware. Adversaries run the encryptor from an unmanaged box (an IoT device, a webcam) and encrypt managed shares over SMB, so process-based EDR is fairly blind to it. Sophos, which named it, tracks it up more than 50% in a year. It looks like an EDR bypass, but the impact invariant doesn’t vanish, it relocates: encryption still needs file writes, so the chokepoint moves to a flood of file renames from one remote source. New technique, same row, but you can identify it from a different data source. In this case, it would be file audit events (5140/5145 etc.) instead of process telemetry.

BYOVD EDR killers. The defense-evasion cells already list Backstab and a Zemana driver; the 2026 version is bigger. ESET documented the Gentlemen gang’s EDR-killer suite, its GentleKiller framework alone carrying eight-plus variants, each abusing a different vulnerable driver. Two more 2025 actors crowd into the same cell: WarLock (Storm-2603) cycles the Antiy, NsecSoft, and Rising drivers, and DragonForce brings the TrueSight and Hangzhou Shunwang ones. Different actors, but they all share the same move. Every one still loads a signed-but-vulnerable driver to reach the kernel, and that driver load is the chokepoint.

Legitimate RMM. Microsoft’s 2025 Digital Defense Report ties remote-management tooling to 79% of ransomware incidents. The product rotates (AnyDesk, ConnectWise, Atera), but an RMM installed outside the IT workflow is the invariant, in the same initial-access box the five tracked actors sit in.

The chains predict each other

The ransomware page’s last section lists related chains, and that housekeeping is the most forward-looking thing on it. Infostealers feed ransomware; AiTM feeds account takeover. Each chain produces exactly the input the next one needs: a stealer harvests credentials, a broker resells them, another group detonates an encryptor. One chain’s output is the next chain’s prerequisite.

That makes the map directional, and a directional map predicts. Detect the infostealer collection chokepoint, a non-browser process reading Chrome’s credential store, and you’re looking at the front of a pipeline whose far end is ransomware. Detect AiTM token theft and the next thing to watch is identity-domination credential access and new mailbox rules. If you can detect one chain, it could serve as an early warning for future activity.

Lastly, due to the efficiency in RaaS ecosystems, dev cycles have shortened. Mandiant’s M-Trends 2026 puts the median handoff from access broker to ransomware operator at 22 seconds, down from more than eight hours. By the time the operator logs in there’s nothing left to react to, so the upstream detection is the warning you actually get to use. The cases are on the record: infostealer credentials behind the 2024 Snowflake breach (165+ orgs), RansomHub running ClickFix to stealer to broker to ransomware, Scattered Spider going AiTM to an Okta session to ransomware. Same seam every time, and that seam is a chokepoint you already know how to detect.

Gentlemen, WarLock, and DragonForce are already lining up the same way: three actors, three different vulnerable drivers, one chokepoint under all of them. I’ll give that cluster its own post.

TL;DR for busy defenders

• Read the invariant first. For ClickFix, the chain is clipboard write → user pastes into an interpreter → outbound connection. The rest of the entry explains how to observe each stage.
• Pick the stage your telemetry can support instead of betting everything on one event. Clipboard ETW may be out of reach, while Sysmon process creation and network events are already available.
• Use the Variations section to find where a rule’s scope changes. Windows Terminal adds wt.exe as a parent, while DNS-based delivery replaces the expected HTTP callback with nslookup.
• Deploy the Research tier first, tune toward Hunt and Analyst, then validate the result with the emulation script. Pair the detection with a preventive control that breaks the same stage.

The hero: the invariant and the at-a-glance read

The top of every entry leads with the invariant, the thing that doesn’t change. For ClickFix:

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

Around it sit the badges: tactic (Initial Access), the ATT&CK mapping (T1204.004, malicious copy-paste), priority (HIGH), prevalence (HIGH), and detection difficulty (LOW).

How to use it: the one line is the whole reason the entry exists; instrument that and you’re not chasing tool names. The badges are triage. Prevalence and priority tell you whether to work it this sprint; difficulty sets your expectations going in; the T-ID drops straight into your ATT&CK coverage map so you know where this sits against everything else.

Attack Chokepoints: the invariant split into stages

The entry doesn’t hand you one rule. The Attack Chokepoints section breaks the invariant into the stages the attacker has to move through, and each stage is its own detection opportunity. For ClickFix:

1. Clipboard Seeding: the lure page writes a command to the clipboard via JavaScript and shows paste instructions. Both must be true; the 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 for the payload.

Each stage carries the invariant, the observable (e.g. Sysmon EID 1: interpreter with ParentImage = explorer/browser/wt.exe), a “why it can’t be bypassed” note, the exact log sources, a maturity tier, and a real true-positive example.

How to use it: pick the stage your telemetry already covers. Clipboard ETW out of reach? Interpreter Execution is plain Sysmon process creation. If one stage is blind in your environment, the other two still fire. You’re never betting the detection on a single event. The “why can’t bypass” line tells you which signals survive a lure redesign and which are cosmetic.

Variations: proof the chokepoint holds, and where parents change

The Variations section tracks nine variants: the original ClickFix, FileFix, TerminalFix, DownloadFix, the JackFix/GlitchFix/ConsentFix family, WebDAV ClickFix, InstallFix, a Windows Terminal version, and a DNS-based one. Each shows the lure the user sees, a defanged copy of the payload, and a one-line mapping back to the same chokepoint.

Expand any variant and the entry embeds a live preview of the lure itself. A few of the distinct ones:

How to use it: this section does two jobs. First it’s evidence: every lure since 2024 still funnels through clipboard seeding, interpreter execution, and a network callback. The constant held. Second, and more practically, it flags the variants that move the goalposts on your rules: the Windows Terminal variant parents off wt.exe instead of explorer.exe, and the DNS-based one swaps HTTP for nslookup. If your hunt only watches browser and explorer parents, this is where you find out what you’re missing.

Detection Strategy: rules at the tier your SOC can run

Detection Strategy gives the same logic at three maturity tiers, plus pre-execution layers (an ETW clipboard-write rule and an IOK rule on the lure page). For ClickFix:

• Research: any interpreter making an outbound connection, no parent filter. High FP, for building your baseline.
• Hunt: parent = browser / explorer.exe / wt.exe spawning an interpreter. Medium FP.
• Analyst: the hunt filter plus encoded or suspicious command-line content (-enc, FromBase64String, IEX, net use, nslookup). Low FP, SOC alert.

Every rule spells out its goal, the log sources you need, the logic in plain pseudocode, the expected FP rate, the use case, and the full Sigma YAML to copy.

How to use it: deploy at the tier you can actually operate. Start at Research to learn what legitimate interpreter traffic looks like in your environment, then climb to Hunt and Analyst as you tune. The FP rate and use case decide whether a rule belongs in a hunt or a paging alert. That’s the part that determines whether a detection survives contact with a real SOC.

Prevention Opportunities: stop it before it executes

Prevention Opportunities covers the controls that break the chain rather than just catch it: block browsers and shells from spawning interpreters (mshta.exe, wscript.exe, powershell.exe, cscript.exe), restrict the Run dialog and enforce PowerShell Constrained Language Mode, and DNS-filter freshly registered domains. Each control names exactly what it interrupts in the chain.

How to use it: detection catches it, control stops it. Pair every detection you deploy with a preventive ask to your endpoint team. Spawn control, for instance, breaks ClickFix at interpreter execution even when the user does paste and hit Enter.

Raw Log Samples: what the telemetry looks like

Raw Log Samples shows the real events the chain produces: Sysmon EID 1 (powershell.exe spawned by chrome.exe with an -EncodedCommand), EID 22 (the DNS query from the interpreter), and EID 3 (the outbound connection to a non-RFC1918 IP), all with full fields.

How to use it: know the exact event shape before you go looking. Confirm your pipeline is capturing ParentImage, CommandLine, DestinationIp, and the rest; tune your field extractions against these samples; and keep them as the “what good looks like” reference when you validate a rule.

Emulation: fire the chain yourself

Emulation gives a lab-only PowerShell script that reproduces the behavior (an encoded command plus a benign outbound request to example.com), mapped to the Atomic Red Team technique, with safety notes.

How to use it: I don’t deploy a detection I’ve never watched fire. Run this in an isolated VM, watch your rule trigger (or fail to), fix it, then ship. It closes the loop between “wrote a rule” and “confirmed it works against the behavior.”

OSINT Pivots: hunt the infrastructure

OSINT Pivots gives ready-to-run URLScan and VirusTotal queries: URLScan for navigator.clipboard.writeText co-occurring with “Verify”, “I am not a robot”, or “Win+R”, and VT Intelligence for nslookup + PowerShell or encoded-PowerShell droppers.

How to use it: go proactive. Run these to surface live lures and staging infrastructure, enrich what you find, and feed it to your blocks. Each query carries a note on what it catches and how to widen it. Swap “Win+R” for “Terminal” and you’re hunting TerminalFix.

Related Chokepoints and References

The Related Chokepoints section links the entries this commonly chains with (Renamed RMM Tools, Ransomware Service Manipulation), and References lists the primary sources behind the entry (Proofpoint, Microsoft, Huntress, MITRE T1204.004, ClickGrab, and others).

How to use it: follow the kill chain instead of stopping at one step, and go to the primary sources when you need to verify a claim or brief someone who wasn’t in the weeds with you.

That’s the whole shape

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

Take it for a test drive: the ClickFix entry.

TL;DR for busy defenders

• Pin detections to the action a threat actor has to perform, not the filename, hash, or tool they control. Credential dumping still has to reach credential material even when Mimikatz disappears.
• Start with the Research-tier rule to learn what normal looks like in your environment. Refine it into a Hunt rule, then promote it to an Analyst alert once the false positives are understood.
• Use Attack Chains to find where unrelated threats converge. Use Trends to see which variations around those fixed points need tuning.
• ClickFix is the working example: clipboard write → user execution → network activity. Cover more than one stage, pair the detection with prevention, and watch it fire in a lab before shipping it.

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.

WTF is a chokepoint?!

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 have traverse the chokepoint in a specific manner. This 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 and Joshua Prager from SpectreOps. Both research methodoligiesa (work through what has to be true for it to succeed, then find the step the attacker can’t control) resonated 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.

The speed to develop more tradecraft at a higher velocity increases each year, even more so now with the wide adoption of LLMs. 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. Palo Alto’s 2026 Unit 42 Global Incident Response Report puts a number on the sharp end of that curve: the fastest quartile of intrusions went from initial compromise to data theft in 285 minutes in 2024, and just 72 minutes in 2025. You have a shorter window to catch an intrusion, so the detection needs to be located where a threat actor needs to make contact with the environment in order to progress to their objective.

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.

The RaaS ecosystem has commoditized the entire Ransomware operation pipeline. The UK’s NCSC and NCA mapped the supply chain: every function below can be run by a different actor and sold to the others as a service. Specialization is exactly why the end-to-end attack got fast, and it’s also why the tooling at any single stage is so disposable.

When focusing on chokepoints, unrelated threats naturally 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.

Cataloguing Chokepoints

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 refine as needed.

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 a threat actor can’t change or is expensive to change; 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. We’ll dive deeper into Attack Chains and Trends in a future post.

Case Study: ClickFix

The idea crystallized for me with ClickFix. The ClickFix threat has dominated headlines for the past few years Huntress, and the variants just kept coming: FileFix, TerminalFix, DownloadFix, each with a different lure. If you only pay attention to the variations, you’ll be chasing them forever. 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 process, 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.

If you’ve reverse-engineered a technique down to its invariant, please contribute! Detection Chokepoints.