secskills
secskills / defense / investigating-azure-incidents

investigating-azure-incidents

defense verified 2026-07-26

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.

$ /plugin install secskills-defense $ /plugin install secskills-core

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

When NOT to Use

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.

SourceScopeRetention (default)What it holds
Azure Activity LogSubscription control plane90 days unless exportedEvery ARM write/action/delete: roleAssignments, runCommand, listKeys, deployments
Resource / diagnostic logsPer-resource data planeNone until enabledBlob reads, Key Vault SecretGet, NSG flow -- only if a diagnostic setting ships them to a workspace
Log Analytics workspaceWherever logs are shippedWorkspace-configuredAzureActivity, AzureDiagnostics, StorageBlobLogs, AZKVAuditLogs tables
Entra sign-in / audit logsTenant identity plane30 days (export for more)Who authenticated the SP/MI, from where, CA/MFA context, credential adds
Microsoft SentinelWhatever it ingestsPer-tableCorrelated 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, map persistence, then contain everything at once. Live mining or active exfil is the exception -- stop the damage and accept the trade.

Activity Log Deep-Dive (KQL)

The AzureActivity table is the authoritative control-plane record. Learn its fields:

Microsoft.Authorization/roleAssignments/write. This is what you hunt on.

call from inside Azure are the IMDS-theft signature (below).

Microsoft.KeyVault, Microsoft.Authorization.

is enumeration: the attacker mapping what the stolen principal can reach.

pivot on it to expand a single suspicious event into its full sequence.

// Enumeration storm -- authorization failures by operation
AzureActivity
| where TimeGenerated > ago(7d)
| where ActivityStatusValue == "Failure"
| summarize n = count() by Caller, OperationNameValue, CallerIpAddress
| order by n desc

// Expand one event's full correlated sequence
AzureActivity
| where CorrelationId == "<correlation-id>"
| project TimeGenerated, OperationNameValue, ActivityStatusValue, ResourceId
| order by TimeGenerated asc

Canonical Attacker Operations to Hunt

Grep the timeline for these OperationNameValue patterns -- they are the shape of nearly every Azure intrusion.

Microsoft.Authorization/roleAssignments/write granting Owner, Contributor, or User Access Administrator (UAA can grant itself anything). Watch for custom-role creation (Microsoft.Authorization/roleDefinitions/write) that hides * actions behind an innocuous name.

Activity Log: a new secret or certificate on an app registration gives persistent, MFA-independent access. Correlate to the Entra audit log ("Add service principal credentials" / "Update application - Certificates and secrets management").

system-assigned identity used to call ARM. The MI's object ID appears as Caller from an unexpected CallerIpAddress.

Microsoft.Compute/virtualMachines/runCommand/action and Custom Script Extension (Microsoft.Compute/virtualMachines/extensions/write installing CustomScript) run attacker code as SYSTEM/root without any RDP/SSH.

Functions), Automation Runbooks, and Logic Apps as scheduled backdoors that re-mint credentials or re-grant roles.

storage account or vault rather than the subscription, easy to miss in a top-level review.

AzureActivity
| where TimeGenerated > ago(14d)
| where OperationNameValue has_any (
    "roleAssignments/write", "roleDefinitions/write",
    "runCommand/action", "virtualMachines/extensions/write")
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ResourceId
| order by TimeGenerated asc

The CLI equivalent filters the same operations: az monitor activity-log list --start-time &lt;t&gt; --query "[?contains(operationName.value,'roleAssignments/write')]".

Identity-Plane Correlation

The Activity Log names the principal but not the human behind it. Map the service principal or managed identity object ID back to Entra to see the authentication context -- this is the cross-plane step, and it usually means opening investigating-m365-entra.

// Where did this service principal / managed identity actually sign in from?
AADServicePrincipalSignInLogs
| where ServicePrincipalId == "<sp-or-mi-object-id>"
| where TimeGenerated > ago(30d)
| project TimeGenerated, AppId, ServicePrincipalName, IPAddress,
    ResourceDisplayName, ResultType
| order by TimeGenerated asc

// For an interactive user: sign-ins around the abusive Activity Log calls
SigninLogs
| where UserPrincipalName == "attacker@contoso.com"
| project TimeGenerated, IPAddress, Location, AppDisplayName,
    ConditionalAccessStatus, AuthenticationRequirement, ResultType

Check conditional-access status and whether MFA was actually satisfied -- a service principal bypasses interactive CA entirely, which is exactly why attackers pivot to SP/MI credentials.

Managed-Identity and SSRF Credential Theft

The Azure analogue of AWS IMDS theft: an SSRF or foothold on a VM / App Service reads the Instance Metadata Service to lift the managed identity's token, then uses it elsewhere.

http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

The signature is unmistakable: the managed identity's calls appear in AzureActivity from a CallerIpAddress that is not the resource's own outbound IP. The token is minted for that resource, so any call from an unrelated or external IP means the token left the box.

AzureActivity
| where TimeGenerated > ago(7d)
| where Caller == "<managed-identity-object-id>"
| summarize ops = count() by CallerIpAddress, OperationNameValue
| order by ops desc     // flag IPs that are not the VM's egress

Correlate the theft window with NSG flow logs (if enabled) for the outbound SSRF and the reuse source. On App Service the token endpoint uses IDENTITY_ENDPOINT with a header secret rather than 169.254.169.254 -- the same off-resource-use logic applies.

Defender for Cloud Alert Triage

Defender for Cloud is a starting pistol, not the investigation. Each alert maps to a hypothesis you confirm in the Activity Log and diagnostic logs.

Alert (representative)Implication
Crypto-mining / Digital currency mining behaviorA VM is talking to a mining pool -- a principal with deploy rights was compromised.
Anomalous resource deployment / unusual RunInstances-equivalentAttacker spinning up compute, often in an unused region.
Suspicious sign-in / access from a Tor or known-malicious IPThe stolen principal called from attacker infrastructure.
Managed identity / metadata credential exfiltrationThe IMDS theft above -- confirm off-resource token use.
Access from anomalous location on a storage account / Key VaultData-plane access from an unexpected geography.
az security alert list -o table
az security alert show --location <loc> -n <alert-name> -g <rg>

An alert older than the 90-day Activity Log window still carries the principal and IPs -- pivot on those even after the raw events have aged out.

Data-Theft Detection

Microsoft.Storage/storageAccounts/listKeys/action and regenerateKey hand the attacker a full-access key that works outside RBAC and outside the Activity Log thereafter.

time-boxed exfil URL that leaves no per-object control-plane trail.

StorageBlobLogs shows GetBlob volume by caller.

allow anonymous/blob public access is exfil staging.

Microsoft.Compute/snapshots/write then /beginGetAccess/action mints a SAS download URL for a full disk image.

to enumerate, then data-plane SecretGet reads (in AzureDiagnostics / AZKVAuditLogs, only if logging was enabled).

// Control-plane data-theft indicators
AzureActivity
| where TimeGenerated > ago(14d)
| where OperationNameValue has_any (
    "storageAccounts/listKeys", "storageAccounts/regenerateKey",
    "listAccountSas", "listServiceSas",
    "snapshots/write", "snapshots/beginGetAccess")
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ResourceId

// Key Vault data-plane reads -- only present if diagnostics were on beforehand
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName in ("SecretGet", "KeyGet", "VaultGet")
| project TimeGenerated, CallerIPAddress, identity_claim_upn_s, OperationName, id_s

Anti-Forensics the Attacker Attempts

A capable attacker tries to blind you. The key operations to hunt -- and their defeat:

Microsoft.Insights/diagnosticSettings/delete stops data-plane logs from reaching the workspace.

diagnostic setting that ships the Activity Log to a workspace or storage.

destroy the artifact and its logs.

The defeat is the same shape as an AWS org trail: a tenant-level export to a central, locked destination the compromised principal cannot reach -- immutable-storage (WORM/legal-hold) blob export, or Sentinel ingestion in a segregated workspace with delete protection and resource locks. When export is immutable, the attacker's own diagnosticSettings/delete call is logged there before it takes effect, so cleanup becomes evidence rather than a gap. If you lack it, record the blind window as a scoping limitation.

AzureActivity
| where TimeGenerated > ago(14d)
| where OperationNameValue has_any (
    "diagnosticSettings/delete", "Microsoft.Insights/diagnosticSettings/write")
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ResourceId

Evidence Preservation

snapshots so they cannot be deleted.

``bash az snapshot create -g &lt;rg&gt; -n IR-2026-042-osdisk \ --source &lt;os-disk-id&gt; --tags case=IR-2026-042 legal-hold=true az lock create --name IR-2026-042-hold --lock-type CanNotDelete \ --resource-group &lt;rg&gt; --resource-name IR-2026-042-osdisk \ --resource-type Microsoft.Compute/snapshots ``

retention -- run the CLI/KQL and save the JSON to a preserved, locked store.

before collection if the incident may become a regulatory or litigation matter.

Containment

Do it all at once, after scoping. Partial containment alerts the attacker.

app, disable it and roll its credentials:

``bash az ad sp update --id &lt;app-id&gt; --set accountEnabled=false # remove attacker-added secrets/certs az ad app credential reset --id &lt;app-id&gt; ``

For a user, disable the account and force a reset in Entra, then revoke sessions (below).

``bash az role assignment delete --assignee &lt;object-id&gt; \ --role Owner --scope /subscriptions/&lt;sub-id&gt; ``

-- Revoke-MgUserSignInSession / az ad user ...), because disabling alone leaves issued tokens valid up to an hour.

deleting it, so disk and memory survive for analysis (az network nsg rule create ... --access Deny --direction Outbound --protocol '*').

every outstanding SAS and access key at once:

``bash az storage account keys renew --account-name &lt;acct&gt; -g &lt;rg&gt; --key primary az storage account keys renew --account-name &lt;acct&gt; -g &lt;rg&gt; --key secondary ``

Automation runbooks, custom roles, and resource-scoped role assignments -- only after they are documented.

Reach for Azure CLI and KQL in Log Analytics / Sentinel for the investigation itself; MicroBurst and ROADtools for understanding the TTPs an attacker would run (and what each leaves behind); and Microsoft's Unified Audit correlation when the Azure story crosses into M365.

Rationalizations to Reject

is control plane only. Blob reads, secret fetches, and DB queries are data-plane operations that are invisible unless diagnostic logging was enabled beforehand. Absence there is not evidence of no exfil.

a subset of behaviors and depends on the right plan and coverage. Absence of a finding is not evidence of absence -- the Activity Log timeline is authoritative.

stay valid up to an hour, and any service-principal credentials or role assignments the attacker created survive the disable. Revoke sessions and audit every persistence mechanism.

design, not a guarantee. SSRF/IMDS theft lifts the token off the resource; the off-resource CallerIpAddress is precisely the signature to hunt.

runCommand on VMs, read storage keys, and mint SAS tokens -- code execution and data theft without ever touching role assignments. Trace what the role can reach; do not assume.

deploy rights was compromised -- the same access could exfiltrate data or escalate through roleAssignments/write. Mining is the visible symptom, not the scope.

is the Activity Log's default retention, your visibility limit -- not the attacker's timeline. Record it as a scoping gap and check the workspace / immutable export for longer retention.

References