MITRE ATT&CK for Hunters: Beyond the Matrix Poster

Half the security offices I’ve seen have an ATT&CK matrix poster on the wall somewhere, and roughly none of those posters get updated or actually referenced during real hunt planning. That’s the gap worth closing—ATT&CK Navigator specifically is a working tool, not decoration, and used properly it becomes the backbone of both planning what to hunt and documenting what’s already been covered.

Navigator as a Coverage Map, Not Just a Reference

The core function worth using deliberately is Navigator’s layer system—the ability to color-code techniques based on some property you assign, like “hunted in the last quarter” versus “never tested” versus “covered by an automated detection already.” Building and maintaining a layer specifically tracking your own hunting coverage turns the abstract matrix into a genuinely useful management tool, answering the question raised back in the kill chain piece: which stages and techniques have you actually built hunt hypotheses for, versus which ones you’ve quietly never touched.

Say a program maintains a coverage layer and finds that out of roughly 200 sub-techniques relevant to their environment, only 35 have ever been the subject of an actual hunt, heavily clustered around a handful of tactics like execution and persistence, with almost nothing tested under discovery or collection. That visual gap, made obvious by the color-coding, is a far more actionable prioritization signal than a vague sense that “we should probably hunt more broadly.”

Building Layers From Threat Intelligence, Not Just Internal Activity

A second highly practical use: building a layer from a specific actor’s documented technique usage, pulled from public ATT&CK group profiles or your own intelligence sources, and overlaying it against your coverage layer to see exactly where the gaps are for a specific threat relevant to your organization. Say your sector analysis (from the earlier capstone piece) identified a specific actor cluster as a meaningful risk—building a Navigator layer of that actor’s known techniques, then comparing it against your hunting coverage layer, immediately surfaces which of their specific techniques you’ve never actually tested for, turning a strategic risk assessment into a concrete, prioritized hunting to-do list.

Sub-Techniques Matter More Than People Initially Realize

A common mistake with ATT&CK adoption is operating only at the parent technique level and ignoring the sub-technique breakdown, which loses a lot of the model’s actual precision. Take a technique like process injection—the parent technique captures the general idea, but the sub-techniques underneath it (different injection methods with genuinely different telemetry signatures) matter enormously for actually building a working hunt query. A hunt hypothesis built at the parent-technique level alone tends to be too vague to query effectively, echoing the same testability problem covered in the piece on hypothesis quality—pushing down to the sub-technique level is often what makes a hypothesis actually specific enough to run.

Mapping Your Own Findings Back Into the Framework

Every confirmed hunt finding, whether it came from IOC pivoting, behavioral anomaly, or TTP-based investigation, should get mapped back to its corresponding ATT&CK technique and sub-technique as part of your standard documentation. This isn’t busywork—it’s what makes your own hunt history queryable by technique later, which matters enormously when a new piece of intelligence arrives describing an actor using a specific technique and you want to quickly check whether you’ve encountered anything matching that pattern before, even under a different investigation’s name.

Data Source Mappings: The Underused Part of the Framework

ATT&CK’s documentation for each technique includes recommended data sources—specifically what kind of telemetry would reveal that technique. This connects directly back to the earlier piece on mapping your own data ecosystem, and it’s worth using ATT&CK’s data source guidance as a cross-check against your own inventory. Pull the data sources ATT&CK recommends for techniques you haven’t hunted yet, and compare them against what you’re actually collecting—this often surfaces logging gaps you hadn’t previously connected to a specific hunting priority, turning “we should probably collect more” into “we specifically need Sysmon Event ID 8 configured to hunt for this documented technique cluster.”

Treating the Framework as Living Infrastructure

The mistake that turns ATT&CK into wallpaper is treating it as something you consult once during onboarding and then forget. Used as living infrastructure—a maintained coverage layer, updated after every hunt cycle, cross-referenced against fresh intelligence regularly—it becomes the connective tissue between everything else covered across this series: risk prioritization, intelligence translation, hunt documentation, and detection engineering feedback, all mapped to a shared, common vocabulary.

Build four separate layers

Create layers for relevant threat behavior, available telemetry, validated detection coverage, and completed hunts. Do not merge them into a single “covered” color: having logs, a query, and a tested detection are different claims. Add dates, evidence links, owners, and confidence so the map can be maintained.

ATT&CK gives teams a shared language. It becomes operationally useful only when every colored cell has a defined meaning and evidence behind it.