Thinking in MITRE ATT&CK

Why it matters

Every detection on the Range asks you to name a technique. That is the same job a SOC does when it triages an alert, writes an incident report or tunes a rule: turn raw events into a precise, shared description of attacker behavior.

A correct mapping tells the next analyst what to look for next. If you know the tactic an action served, you know which stage of the intrusion you are in and which evidence should exist before and after it.

What analysts see

In practice ATT&CK reaches you in three places.

• Alerts and detection rules that already carry a technique tag. Treat the tag as a hypothesis, not a verdict.
• Raw telemetry with no tag at all: a process start, a logon, a network connection. Here you do the mapping yourself.
• Reports and handoffs, where the technique list is how you summarize what happened for someone who was not there.

The Range tests the second case: you see the telemetry and supply the mapping.

Core concept

Tactics are the attacker's goals: gaining access, running code, staying in, getting more privilege, avoiding detection, finding things, moving around, collecting, taking data out, causing impact. Techniques are the ways each goal is achieved. Sub-techniques are specific variants of a technique.

Technique IDs look like Txxxx; sub-techniques add a suffix, Txxxx.yyy. When a sub-technique exists for what you saw, the parent ID alone is incomplete.

One action can serve more than one tactic. A new account can be persistence and also a way to get privilege. Name the technique the evidence proves, and use the tactic to reason about what came before and after.

Map the behavior, not the tool. The same utility can serve routine administration or an intrusion; the evidence around it (who ran it, what it touched, what followed) decides the technique.

Evidence makes a mapping defensible. A technique without the fields that prove it is a guess; the fields without a technique are a description. You need both.

Keep four things apart. An indicator is a value you can match, such as a file hash, an IP address or a domain; a match says the value was seen, not what was done. An event is what one log recorded. A behavior is your reading of what the events show someone doing. A mapping is the ATT&CK technique that the behavior supports. Each step needs the one before it, and "not enough evidence to map yet" is a valid answer. The annotated example below has no indicator at all, which is common: many intrusions are found through behavior, not through a known-bad value.

Annotated examples

How to investigate

1. 1.

   Describe the behavior in plain words first.

   "The audit log was cleared on a server" is easier to map correctly than a raw event.

2. 2.

   Pick the tactic.

   Ask what the attacker gained by doing it at that moment of the intrusion.

3. 3.

   Find the technique in the TTP Catalog.

   Read the "Detect it in Elastic" section and check the telemetry it describes exists in your lab's Monitoring Coverage.

4. 4.

   Check for a sub-technique.

   If the catalog lists variants, decide which one your evidence supports; don't stop at the parent.

5. 5.

   Collect the proving fields.

   Host, account, process or event, and time. Note them as evidence before you submit.

6. 6.

   Choose the ID from the search box.

   Typing from memory invites a wrong digit; the search box only offers real IDs.

Common mistakes

• Mistake: Mapping the tool instead of the behavior.

  InsteadAsk what the tool was used to achieve here.

• Mistake: Stopping at the parent technique.

  InsteadCheck the catalog for sub-techniques and pick the one the evidence supports.

• Mistake: Trusting an alert's technique tag.

  InsteadTreat it as a hypothesis and confirm it in the telemetry.

• Mistake: Submitting a technique with no evidence.

  InsteadPair every technique with the fields that prove it.

• Mistake: Confusing tactic and technique.

  InsteadThe tactic is the goal; the technique is how it was done.

• Mistake: Mapping a step that had no attacker effect.

  InsteadFailed attempts and normal admin work need context before they count.

• Mistake: Treating an indicator match as a finding.

  InsteadFind the event it appeared in and what happened around it before you call it malicious.

• Mistake: Mapping when the evidence is thin.

  InsteadWrite that there is not enough evidence to map yet, and note what would settle it.

Field references

Apply it in a Case

On your next case, write one line per detection before you search: the behavior in plain words, then the tactic. Only then open the TTP Catalog.

• First LightSkills: Evidence and reportingTelemetry: Windows
• GhostwriterSkills: Evidence and reportingTelemetry: Windows · Sysmon
• DragnetSkills: Evidence and reporting

References

• MITRE ATT&CK Enterprise matrix · MITRE
• Tactics · MITRE ATT&CK
• Getting started with ATT&CK · MITRE
• Elastic Common Schema reference · Elastic