/investigating-azure-incidents

name: investigating-azure-incidents
description: Investigate security incidents in Microsoft Azure (resource and subscription control plane) -- reconstruct attacker activity from the Azure Activity Log and resource/data-plane diagnostic logs, anchor the investigation on the identity that made the calls (a user, service principal, or managed identity), trace privilege escalation through role assignments, hunt managed-identity token abuse and VM run-command code execution, and detect storage or Key Vault data theft while correlating back to Entra sign-in logs. Use when responding to a suspected Azure resource compromise, anomalous Azure Activity Log entries, a Microsoft Defender for Cloud alert, managed-identity or service-principal abuse, a crypto-mining VM, or storage-account exfiltration.
verified: 2026-07-26

Investigating Azure Incidents

In Azure the control plane logs almost everything through Azure Resource Manager, so an incident is reconstructed from the Activity Log and the resource/data-plane logs, anchored on the identity that made the calls -- a user, a service principal, or a managed identity. The recurring trap is that identity lives in Entra while the damage lives in the subscription: you must correlate across both planes, because the Activity Log tells you *what* was done to a resource but the Entra sign-in log tells you *who* held the token and from where.

When to Use

• Suspected Azure resource compromise -- a subscription, resource group, or VM behaving as though someone else controls it
• Anomalous Azure Activity Log entries -- writes from unfamiliar callers, IPs, or regions, or an `AccessDenied` storm that looks like enumeration
• A Microsoft Defender for Cloud alert -- crypto-mining, anomalous resource deployment, suspicious sign-in, or IMDS token theft
• Managed-identity or service-principal abuse -- tokens minted for an app or VM being used from somewhere they should never appear
• A crypto-mining VM -- an unexpected spend spike, GPU/large SKUs, or new deployments in regions you do not operate in
• Storage-account or Key Vault exfiltration -- key regeneration, SAS-token minting, public-access changes, disk-snapshot sharing, or secret dumps

When NOT to Use

• **The compromise is Entra identity / M365 mailbox, not Azure resources** (though you will often need both) -- use `investigating-m365-entra`
• **The incident is in AWS** -- use `investigating-aws-incidents`
• **The incident is in Google Cloud** -- use `investigating-gcp-incidents`
• **You are the attacker against the tenant, not the responder** -- use `attacking-entra-id`
• **The pivot is specifically into AKS / Kubernetes** -- use `attacking-eks-gke-aks`; for defending the cluster, `defending-kubernetes`
• **The general IR process and host-level response** -- use `responding-to-incidents`

Log Sources and Where They Live

Establish what you have before you query. Missing logs are a finding, not a reason to skip the question.

| Source | Scope | Retention (default) | What it holds | | --- | --- | --- | --- | | Azure Activity Log | Subscription control plane | 90 days unless exported | Every ARM write/action/delete: `roleAssignments`, `runCommand`, `listKeys`, deployments | | Resource / diagnostic logs | Per-resource data plane | None until enabled | Blob reads, Key Vault `SecretGet`, NSG flow -- only if a diagnostic setting ships them to a workspace | | Log Analytics workspace | Wherever logs are shipped | Workspace-configured | `AzureActivity`, `AzureDiagnostics`, `StorageBlobLogs`, `AZKVAuditLogs` tables | | Entra sign-in / audit logs | Tenant identity plane | 30 days (export for more) | Who authenticated the SP/MI, from where, CA/MFA context, credential adds | | Microsoft Sentinel | Whatever it ingests | Per-table | Correlated hunting across all of the above, incidents, watchlists |

**The trap:** the Activity Log is a *control-plane* record. Data-plane operations -- reading a blob, fetching a Key Vault secret, querying a Cosmos DB -- are **not** in the Activity Log at all. They exist only if a diagnostic setting was configured on that resource *before* the incident. Absence in the Activity Log is never evidence that data was untouched (see Rationalizations).

Confirm what is actually being logged before you trust a gap: `az monitor diagnostic-settings subscription list` (is the Activity Log exported beyond 90 days?) and `az monitor diagnostic-settings list --resource <id>` (does this storage account / vault ship data-plane logs anywhere?).

First-Hour Triage

Three moves, in order: scope the caller identity, pull its recent activity, preserve before you contain.

**Scope the caller identity.** Resolve the report -- a Defender alert, a billing spike, a suspicious deployment -- to the identity in the `caller` / `identity` fields of the Activity Log. That principal (a UPN, or a service principal / managed identity object ID) is the anchor for everything else.

# Everything a specific caller did across the subscription control plane
az monitor activity-log list --caller attacker@contoso.com \
  --start-time 2026-07-01T00:00:00Z -o json

# Who holds what right now -- role assignments are the escalation surface
az role assignment list --all --include-inherited \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator']" -o table

**Pull recent activity from KQL** if a Log Analytics workspace exists -- it is faster and richer than the CLI once you are past the first look:

AzureActivity
| where TimeGenerated > ago(7d)
| where Caller == "attacker@contoso.com"
| project TimeGenerated, OperationNameValue, ActivityStatusValue,
    CallerIpAddress, ResourceProviderValue, ResourceId, CorrelationId
| order by TimeGenerated asc

**Preserve, then contain.** An attacker who sees a role assignment revoked mid-operation will burn persistence you have not found. For anything but active, ongoing damage: snapshot disks, export the relevant logs,