The Cyber Kill Chain, Read as a Hunting Map

The kill chain gets criticized a lot in modern security circles—too linear, too focused on perimeter-style intrusions, doesn’t map cleanly onto cloud-native attacks or insider threats. Some of that criticism is fair. But dismissing the model entirely throws out something genuinely useful for hunters: a structured way of asking “where in this sequence would evidence actually exist, and which stage gives me the best odds of catching something.”

Why Linear Doesn’t Mean Useless

Yes, real intrusions loop back, skip stages, or run multiple stages in parallel—an attacker might be doing reconnaissance on one part of the network while already established in another. The model’s value for hunting isn’t that it perfectly describes every intrusion’s actual sequence. It’s that each named stage corresponds to a distinct category of attacker action, and each category has different telemetry associated with it. Using the kill chain as an organizing structure for hunt hypotheses, rather than a literal prediction of attack sequence, is where it earns its keep.

Reconnaissance and Weaponization: Mostly Invisible, With One Exception

The earliest stages—reconnaissance and weaponization—happen largely outside your visibility, on infrastructure and systems you don’t control. There’s limited direct hunting value here for most organizations, with one real exception: external reconnaissance sometimes touches your own infrastructure directly, port scans against your perimeter, or DNS enumeration against your domains. A hunt hypothesis worth running periodically checks external-facing logs for scanning patterns against infrastructure that isn’t publicly advertised—say, an internal subdomain that shouldn’t be discoverable but shows up in scan traffic anyway, which can indicate either a misconfiguration or active targeted reconnaissance worth investigating further.

Delivery and Exploitation: Where Detection Usually Lives, Hunting Adds Less

Delivery (phishing, exploited public-facing services) and exploitation (the payload actually executing) are stages where automated detection tends to be reasonably mature—email security gateways, EDR behavioral detection on exploit patterns. Hunting still adds value here, but it’s more about catching what detection missed than being the primary defense at this stage. A useful hunt hypothesis: review email security logs for delivered-but-not-blocked messages containing indicators similar to known phishing infrastructure, checking whether any recipients subsequently showed anomalous authentication behavior—catching the cases where delivery succeeded and detection didn’t flag it, but no obvious compromise followed either, which is worth knowing about even without a confirmed incident.

Installation and Command-and-Control: The Highest-Value Hunting Territory

This is where hunting earns its keep the most, in my experience running programs across different environments. Installation (persistence mechanisms) and command-and-control (ongoing communication with attacker infrastructure) generate telemetry that’s genuinely hard for attackers to fully suppress, and it’s exactly the territory where hypothesis-driven hunting—rather than signature-based detection—catches things automated tooling misses.

Persistence mechanisms in particular are worth heavy hunting attention because attackers need something that survives a reboot, and there are only so many ways to achieve that on a given OS—scheduled tasks, registry run keys, service creation, WMI event subscriptions. A hunt hypothesis cycling through each of these mechanisms methodically, checking for anomalies in each, covers ground that a single detection rule per mechanism often misses because attackers vary the specific implementation while the underlying mechanism stays limited to a known set of options.

Command-and-control hunting benefits enormously from the DNS and proxy log sources discussed in earlier pieces on the data ecosystem—beaconing patterns, even when disguised well, tend to show up in connection timing regularity or destination reputation that’s cheap to check against.

Actions on Objectives: Late, But Not Too Late

The final stage—data exfiltration, destructive action, whatever the actual objective was—is late in the game, but hunting here still has real value, particularly for catching staging behavior before the final objective completes, as discussed in the ransomware piece. A hunt hypothesis focused on unusual data movement patterns, even without a specific prior alert, can catch an intrusion at this stage before the most damaging action actually finishes.

Using the Model as a Coverage Check, Not a Rulebook

The most practical use of the kill chain for a hunting program isn’t running through it stage by stage on every single hunt—it’s periodically auditing your hunting backlog against it and asking honestly which stages you’ve actually built hunt hypotheses for versus which ones you’ve quietly never covered. Say a program audit reveals that 80% of recent hunts have focused on installation and command-and-control, with almost nothing addressing actions-on-objectives—that’s a coverage gap worth deliberately correcting, not because every stage deserves equal attention, but because an unexamined gap is worse than a deliberately deprioritized one.

Build a coverage map

For every stage, list one relevant behavior, required telemetry, existing prevention, existing detection, and a hunting opportunity. Mark stages as visible, partially visible, or blind. Do not assume an intrusion follows the model once or in order; use the map to expose coverage gaps and possible pivots.

The Kill Chain is useful as a question set: where could we observe, interrupt, or investigate this operation? It is not proof that every attacker follows a neat linear sequence.