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