Mapping Azure detections to MITRE ATT&CK

Start with Azure signal families

Azure does not give you one neat finding catalogue. A useful ATT&CK map starts by separating the signals by job: Defender for Cloud alerts describe suspicious activity and risky resource posture, Entra ID sign-in logs describe identity behaviour, and Azure Activity logs describe control-plane changes.

Keep those families separate in your source data. If a Sentinel rule joins Entra sign-ins to Activity Log writes, record both sources. The ATT&CK technique can be the same, but the evidence is different and analysts need to know which log proved the behaviour.

Map Defender for Cloud alerts

Defender for Cloud alerts are the closest Azure equivalent to GuardDuty findings. They already carry alert names, affected resource IDs, tactics, severity and entities. That makes them good candidates for a direct mapping table, as long as the table records why the alert supports the technique.

For example, an alert about suspicious VM extension execution is better mapped to Command and Scripting Interpreter than to a generic execution bucket. An exposed management port alert is usually a precondition signal, not proof of active scanning unless the alert text names inbound scan activity.

• Map by alert type first, not by severity. Severity changes with Microsoft tuning; the behaviour behind the alert is more stable.
• Store the affected resource type. A Kubernetes alert and a VM alert may land on the same technique but need different runbooks.
• Keep posture findings separate from runtime detections so coverage reports do not overstate live detection capability.

Map Entra ID sign-ins and audit logs

Most Azure intrusions pass through identity. Entra ID sign-in logs cover failed MFA, risky locations, impossible travel, unfamiliar sign-in properties and service-principal activity. Those signals often map to Valid Accounts, Brute Force, MFA abuse patterns and cloud-account discovery.

Audit logs matter for privilege movement. Role assignment changes, consent grants, app credential additions and conditional-access edits can show persistence or privilege escalation. Do not bury those events under a single 'identity anomaly' label; map the action to the technique the attacker would gain from it.

Map Azure Activity Log writes

Azure Activity logs show who changed the control plane: network security groups, storage-account settings, key vault policies, diagnostic settings and role assignments. These are the audit trail for cloud defence evasion and impact paths.

Treat Activity Log writes as high-value context even when they are not enough for a detection by themselves. Disabling diagnostic settings, opening a management port or changing a key vault access policy may be benign during maintenance. Paired with a fresh privileged sign-in or Defender alert, the same event becomes much more interesting.

• Record the operation name and target resource type.
• Map destructive writes, logging changes and public exposure changes separately.
• Tag whether the mapping is direct detection evidence or correlation context.

Use coverage as a review loop

A good Azure ATT&CK map is not a static spreadsheet. Review it when Microsoft adds Defender alerts, when your team enables a new log table in Sentinel, and when incident reviews show that an attacker action was visible but unmapped.

DCV keeps that loop practical by storing the mapping beside the platform and SIEM context. The output is a coverage view that says which Azure techniques have direct alerts, which depend on correlation and which still need a rule or logging change.

def evidence_kind(source):
    if source in {'DefenderForCloudAlert', 'EntraRiskySignIn'}:
        return 'direct-detection'
    if source in {'AzureActivityWrite', 'EntraAuditChange'}:
        return 'correlation-context'
    return 'needs-review'

Related library pages

• library · attack
• glossary · mitre-attack
• glossary · siem
• library · sigma