Azure Subscription Compromise Playbook: Contain and Evict an Attacker From Azure

When an attacker holds a privileged role in an Azure subscription, they can run code on every virtual machine, read Key Vault secrets, mint storage keys and plant role assignments that survive a password reset. A subscription compromise lives in the resource plane: Azure RBAC, managed identities, Automation accounts, VM Run Command, Key Vault and storage, all recorded in the Activity Log. This playbook covers how the incident shows up, the triage questions for the first hour, containment in priority order, eradication of attacker persistence, recovery, the evidence to preserve and when notification rules apply. It is written for cloud security teams, incident responders and Azure platform owners. The Entra ID tenant itself (sign-ins, Conditional Access, app registrations) is covered in the Identity Provider Tenant Compromise Playbook, and cross-cloud principles in the Cloud Incident Response Guide; this page stays on the subscription.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Azure documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Export the Activity Log first. Azure keeps Activity Log events for 90 days; if no diagnostic setting sends them to a workspace or storage account, start the export before you change anything.
• Role assignments are the persistence. Review every assignment at management group, subscription, resource group and resource scope, including managed identities and anyone holding elevated root scope access.
• Treat workload identities as suspects. Managed identities on VMs, Automation accounts and Function apps act with their own roles, so code an attacker planted can keep acting after every human credential is reset.
• Rotate what was readable. Any secret, key or certificate in a Key Vault the attacker could read, and any storage account key they could list, must be rotated, not just reviewed.
• Contain before you clean. Remove access paths in a planned order so the attacker cannot see you coming and re-establish access through one you have not closed yet.

How the incident shows up

Subscription compromises are often found through cost, a Microsoft Defender for Cloud alert or an unexpected change. The table lists signals that point at the resource plane.

Defender for Cloud also lists alerts for known Azure offensive toolkits, such as code execution on VMs and key extraction from vaults; any of these warrants opening this playbook. The initial access is usually T1078.004 Cloud Accounts: a stolen user or service principal credential, often via the tenant. See the Azure Monitor, Activity Log and Diagnostic Settings Guide for collection setup.

Triage questions

1. Which principal did it? From the Activity Log Caller field, is it a user, a service principal or a managed identity? A managed identity points at compromised code or a compromised resource, not a stolen password.
2. Is the tenant also compromised? Check for elevate access entries in the Entra audit log (service filter Azure RBAC (Elevated Access)) and for new app credentials. If yes, run the identity provider tenant playbook in parallel.
3. What scope does the principal hold? A role at management group or root scope puts every subscription under it in scope, not just the one where the alert fired.
4. Is the Activity Log being retained? Is there a diagnostic setting to a Log Analytics workspace, storage account or event hub, and has anyone changed or deleted it?
5. What secrets could be read? List Key Vaults the principal could reach (RBAC data roles or access policies) and whether SecretGet calls occurred.
6. Which workloads ran attacker code? Identify VMs with Run Command or extension changes, Automation accounts with new runbooks, and Function or App Service deployments in the window.
7. Is personal or regulated data in scope? Databases, storage accounts and backups reachable by the principal decide the notification path.

Containment priorities

Work top down, and coordinate timing so the main access paths close together. Record every action with a timestamp.

1. Preserve the logs: create or confirm a diagnostic setting that exports the subscription Activity Log to a workspace or storage account the attacker's principal cannot reach. Turn on Key Vault AuditEvent logging if it was off.
2. Disable the compromised principal: for a user, block sign-in and revoke sessions in Entra ID; for a service principal, remove its credentials or disable it; for a managed identity, remove its role assignments (a system-assigned identity cannot be disabled without changing the resource).
3. Remove attacker role assignments: on each scope, open Access control (IAM), Role assignments, and use the Privileged tab to see Owner, Contributor and User Access Administrator holders. Download the assignments as CSV or JSON first for evidence. Delete unknown custom role definitions.
4. Remove root scope elevation: on the Entra ID Properties page use Manage elevated access users; any unexpected holder must set Access management for Azure resources to No, or an administrator removes the assignment with PowerShell, CLI or REST.
5. Stop attacker compute: stop (do not yet delete) unrecognised VMs and scale sets, so disks remain for forensics. Disable new Automation runbooks, schedules and webhooks.
6. Block execution paths: restrict who holds Microsoft.Compute/virtualMachines/runCommand/action and extension write permissions while the investigation runs; an Azure Policy assignment with the deny effect at subscription scope can block new resource types or regions.
7. Protect critical resources: apply CanNotDelete resource locks to Key Vaults, backup vaults and logging workspaces to slow destructive actions.

Expect the attacker to notice. Prioritise closing the paths that give the most control (Owner and User Access Administrator assignments, elevated access, service principal credentials) in one window.

Eradication

• Role assignments: compare current assignments at every scope against your infrastructure as code or a known good export. Remove anything without an owner and change record. Check managed identities through each identity's Azure role assignments view.
• Key Vault contents: rotate every secret, key and certificate the attacker could read, starting with the ones that grant further access (database passwords, service principal secrets, API keys). Review access policies and RBAC data roles on each vault. See the Azure Key Vault Security Guide.
• Storage keys and SAS: regenerate both storage account keys using Microsoft's key1 then key2 process. This revokes account and service SAS tokens signed with those keys; user delegation SAS tokens are not affected and need their signing identity contained instead. Where applications allow it, disallow Shared Key authorization. See the Azure SAS Tokens Security Guide.
• Automation accounts: review every runbook, schedule, webhook and stored credential; delete what you did not create; rotate stored credentials; reduce the account's managed identity roles to least privilege.
• Virtual machines: review Run Command activity in the Activity Log (managed run commands are also resources you can list on the VM) and installed extensions. Rebuild VMs that ran attacker code from a trusted image rather than cleaning them.
• App and function deployments: redeploy from source control; review deployment credentials and app settings for planted secrets or outbound endpoints.
• Service principal and app credentials: rotate client secrets and certificates for any service principal with roles in the subscription. See the Azure RBAC and Service Principals Guide.
• Attacker resources: after evidence capture, delete unrecognised resources in every region, then review the cost report against the previous billing period.

Recovery

1. Restore known good configuration: redeploy from infrastructure as code; restore data from backups taken before the first attacker action, after checking backup vault integrity.
2. Re-enable access in stages: grant roles back through Privileged Identity Management with time-bound eligible assignments rather than permanent active ones.
3. Harden the paths used: move remaining service principal secrets to managed identities or federated credentials; put Run Command and extension rights behind custom roles; require Azure Policy guardrails for regions and SKUs.
4. Raise detection: keep Defender for Resource Manager and Defender for Key Vault enabled, alert on elevate access through a Microsoft Sentinel analytics rule from the Azure RBAC (Elevate Access) template, and alert on new Owner assignments.
5. Watch for return: monitor the caller IPs, user agents and principals seen in the incident for at least 30 days.

Measure recovery with a few indicators: time from first alert to principal disabled, count of privileged permanent assignments (target falling towards zero), percentage of subscriptions with Activity Log export, number of Key Vault secrets rotated against those in scope, and spend returned to baseline.

Rebuild or clean: decision points

• Rebuild the subscription: when the attacker held Owner or User Access Administrator for days, the logs have gaps, or infrastructure as code can recreate the estate. A new subscription with clean role assignments removes persistence you did not find.
• Clean in place: when access was short, scoped to a resource group, and the Activity Log is complete for the whole window, so every change can be accounted for.
• Small organisations: one or two subscriptions without infrastructure as code usually clean in place, with VMs rebuilt and every secret rotated; engage Microsoft support and an incident response partner early.
• Large estates: treat management group scope as the blast radius, run triage per subscription in parallel, and use Azure Policy at management group scope to hold guardrails while teams work.

Evidence to preserve

Store evidence in a separate subscription or storage account with immutability where possible, and record hashes and chain of custody. NIST SP 800-53 AU-9 (protection of audit information) and AU-11 (retention) frame the requirement.

Notification triggers

• Personal data: under GDPR Article 33 (and the UK GDPR), a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless it is unlikely to result in a risk to individuals; Article 34 covers telling affected people when risk is high.
• NIS2 entities: essential and important entities in the EU follow Article 23: an early warning within 24 hours of becoming aware of a significant incident and an incident notification within 72 hours, under national transposition.
• Listed US companies: SEC Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident within four business days of determining materiality.
• Contracts and customers: customer and partner agreements often set shorter notice periods than law.
• Microsoft: open a support case for abuse or billing review, and report abuse of your resources against third parties.

See the Breach Notification Laws by Country Guide for other jurisdictions.

Framework mapping

Practitioner checklist

• Every subscription exports its Activity Log to a workspace or storage account outside the reach of everyday admins.
• Key Vault AuditEvent logging is on for every vault.
• Defender for Resource Manager and Defender for Key Vault alerts route to the SOC.
• A Sentinel or SIEM rule alerts on elevate access and new Owner or User Access Administrator assignments.
• A known good export of role assignments exists for each management group and subscription.
• Run Command and extension write permissions are limited by custom role.
• Responders have break-glass access tested quarterly, independent of the possibly compromised tenant admins.
• The runbook names who disables principals, who rotates Key Vault secrets and who decides on notification.
• Storage accounts disallow Shared Key authorization where applications allow it.
• Budgets and cost anomaly alerts exist for every subscription.

Standards and references

• Microsoft Learn: Alerts for Azure Resource Manager
• Microsoft Learn: Azure Monitor activity log
• Microsoft Learn: Elevate access to manage all Azure subscriptions and management groups
• Microsoft Learn: List Azure role assignments using the Azure portal
• Microsoft Learn: Azure Key Vault logging
• Microsoft Learn: Manage storage account access keys
• Microsoft Learn: Run scripts in your VM by using Run Command
• Microsoft Learn: Azure Automation account authentication overview

Related NHI Mgmt Group resources: Cloud Incident Response Guide, Identity Provider Tenant Compromise Playbook, Azure Managed Identities Security Guide, Cryptojacking Incident Response Playbook.