Agent Foskett Academy • Microsoft Sentinel • Module 3 • Lesson 30

Lesson 30 — Mapping Analytics Rules to MITRE ATT&CK

Your KQL works. The rule fires. The alert reaches the analyst.

But what adversary behaviour is the detection actually looking for?

MITRE ATT&CK mapping gives the rule security context by connecting the detected behaviour to the tactics and techniques used by real-world adversaries.

Map the behaviour you detect — not the behaviour you hope the rule detects.

Start Lesson Back to Sentinel Academy

Agent Foskett Microsoft Sentinel MITRE ATT&CK analytics rule mapping lesson

What you will learn

Learn how tactics and techniques add adversary context to a Sentinel analytics rule.

Tactics versus techniques

Mapping rule behaviour accurately

Techniques and sub-techniques

Using ATT&CK for coverage analysis

Learning objectives

Explain the difference between an ATT&CK tactic and technique.
Map analytics rule behaviour to appropriate ATT&CK entries.
Understand how mappings flow into alerts and incidents.
Avoid over-mapping detections.
Use mappings to understand detection coverage.

The investigation

A rule detects suspicious account activity and has been mapped to six different ATT&CK tactics because those tactics all sound security-related.

The rule looks impressive. The mapping is also nearly useless.

What MITRE ATT&CK adds to a detection

MITRE ATT&CK is a knowledge base that describes adversary behaviour using tactics, techniques and sub-techniques.

Microsoft Sentinel lets you associate analytics rules with the ATT&CK behaviour represented by the activity the rule detects. Those mappings then apply to alerts generated by the rule and to incidents created from those alerts.

Agent Foskett tip:

ATT&CK mapping is not decoration for the rule. It is a statement about what the evidence actually represents.

Tactic — the adversary objective

A tactic describes why an adversary is performing an action — the objective they are trying to achieve.

Examples include Initial Access, Execution, Persistence, Credential Access, Discovery and Exfiltration.

Technique — how they do it

A technique describes how an adversary may achieve that tactical objective.

Techniques can also have more specific sub-techniques that describe a narrower implementation of the behaviour.

Think objective → behaviour → detection

Adversary objective │ ▼ ATT&CK tactic │ ▼ Adversary behaviour │ ▼ ATT&CK technique │ ▼ Observable evidence │ ▼ Sentinel detection

Example — suspicious use of a valid account

Imagine an analytics rule looking for sign-in behaviour that indicates an existing account may be used improperly.

SigninLogs
| where ResultType == "0"
| where RiskLevelDuringSignIn in ("medium", "high")
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName

The ATT&CK mapping should describe the behaviour the detection actually supports. A possible technique to investigate is Valid Accounts (T1078), but the final mapping must be based on the rule's real detection hypothesis and evidence.

Start with the detection hypothesis

Before selecting ATT&CK entries, state what the rule is intended to detect in plain language.

If you cannot explain the behaviour clearly, you are not ready to map it accurately.

Then examine the evidence

Look at the tables, fields, filters and correlations used by the query.

Ask what those observations actually prove — not every attack step that might theoretically happen before or after them.

A practical mapping workflow

1. Define the detection hypothesis │ ▼ 2. Read the KQL evidence │ ▼ 3. Identify adversary behaviour │ ▼ 4. Select relevant tactic │ ▼ 5. Select technique / sub-technique │ ▼ 6. Validate the mapping │ ▼ 7. Test the resulting alert

Microsoft Sentinel rule configuration

When creating a scheduled analytics rule, the General section allows you to select the MITRE ATT&CK tactics and techniques represented by the rule.

You can select multiple mappings when the detection genuinely represents multiple behaviours.

The mapping follows the alert

The ATT&CK tactics and techniques assigned to the analytics rule apply to alerts generated by that rule.

They also apply to incidents created from those alerts, helping analysts understand the adversary context of the detection.

Rule-as-code mappings

When Sentinel analytics rules are represented as solution content, ATT&CK mappings are explicit rule properties.

tactics:
  - InitialAccess
relevantTechniques:
  - T1078
status: Available

Microsoft's current Sentinel solution schema supports MITRE ATT&CK Framework v16 for these rule properties. A published solution rule can define up to five tactics and ten relevant techniques.

More mappings are not better

A rule with one well-supported technique is more useful than a rule mapped to half the ATT&CK matrix without evidence.

Mapping everything creates the appearance of coverage without improving detection quality.

Do not map the whole attack story

Your query may detect credential dumping, for example, but an attacker could later use those credentials for lateral movement.

That does not automatically mean the credential-dumping rule should also be mapped to every possible later stage.

Detection mapping versus incident interpretation

Question	What to map
What behaviour does this rule directly detect?	The tactic and technique supported by the rule evidence.
What might the attacker do next?	Do not automatically map hypothetical future behaviour.
What happened elsewhere in the incident?	Investigate separately; other alerts may carry their own mappings.
Could the same evidence support more than one tactic?	Map multiple tactics only when the rule genuinely represents them.

Coverage becomes visible

Consistent ATT&CK mapping helps security teams understand which adversary behaviours their analytics content is designed to detect.

It can reveal areas with substantial detection content and areas where coverage deserves further investigation.

Coverage is not the same as protection

A technique appearing as covered does not prove every implementation of that technique will be detected.

The actual KQL, data sources, telemetry quality, thresholds and rule state still determine what the detection can see.

The map does not replace the evidence

Remember the Agent Foskett rule:

The ATT&CK label gives you context. The logs still have to prove what happened.

Common mistake — mapping by alert title

A dramatic alert name does not establish ATT&CK behaviour.

Read the query and understand the evidence before choosing a tactic or technique.

Common mistake — mapping possibilities

An attacker who gains access might establish persistence, escalate privileges, perform discovery and exfiltrate data.

If your rule only detects the access behaviour, those later possibilities are not evidence for extra mappings.

Common mistake — never reviewing mappings

Detection logic changes over time and the ATT&CK framework evolves.

If the query changes materially, review whether the existing tactic and technique mappings still describe the rule accurately.

Common mistake — confusing coverage with quality

Twenty mapped rules for a technique can all be poor detections.

ATT&CK coverage is useful context, but it does not replace testing, tuning and evidence-based detection engineering.

Agent Foskett investigation exercise

Your analytics rule detects:

A successful risky sign-in using an existing account, followed by suspicious activity associated with that same identity.

Write the exact behaviour the rule detects.
Identify the evidence in the query that supports that behaviour.
Find the ATT&CK technique that best describes the observed behaviour.
Select only tactics and techniques the detection can justify.
Open a generated alert and confirm the mapping makes sense to the receiving analyst.

Best practices

Start with the detection hypothesis.
Map the observed behaviour, not the imagined attack chain.
Use techniques and sub-techniques as specifically as the evidence allows.
Keep mappings understandable to the analyst receiving the alert.
Review mappings when detection logic changes.
Use ATT&CK coverage as a guide, not as proof of detection quality.

Agent Foskett takeaway

MITRE ATT&CK gives your analytics rule a common language for adversary behaviour.

But the mapping should never be more confident than the evidence. Follow the query. Follow the behaviour. Then choose the technique.

Related Agent Foskett learning

Connect Lesson 30 with analytics rule design, detection hypotheses and the evidence behind Sentinel alerts.

Lesson 29 — Microsoft Security Analytics Rules Lesson 22 — Building Scheduled Analytics Rules Lesson 25 — Entity Mapping in Analytics Rules Lesson 26 — Custom Details and Alert Enrichment Microsoft Sentinel Academy Agent Foskett Academy Microsoft Security Services

Continue learning

Continue through Module 3 — Analytics Rules.

⬅ Previous lesson

Lesson 29 — Microsoft Security Analytics Rules Review how alerts from connected Microsoft security products enter the Sentinel incident workflow.

🏠 Academy home

Microsoft Sentinel Academy Browse all available Sentinel lessons, modules and upcoming topics.

Next lesson ➡

Lesson 31 — Tuning Analytics Rules and Reducing False Positives Next, learn how to tune detections without filtering away the evidence that matters.

Mapping Microsoft Sentinel Analytics Rules to MITRE ATT&CK

Microsoft Sentinel analytics rules can be mapped to MITRE ATT&CK tactics, techniques and sub-techniques so alerts and incidents describe the adversary behaviour represented by the detection.

Microsoft Sentinel Lesson 30

This Agent Foskett Microsoft Sentinel Academy lesson explains tactics, techniques, detection hypotheses, accurate ATT&CK mapping, rule-as-code mappings, detection coverage and common MITRE ATT&CK mapping mistakes.