Microsoft Azure Account Compromised: Complete Incident Response and Recovery Guide

An unfamiliar sign-in from São Paulo. Virtual machines spinning up in Australia East — a region you have never touched. An email from Microsoft warning of suspicious activity on your subscription. Your Azure account is under attack, and the clock is running.

Azure breaches have unique characteristics that make them especially dangerous. Microsoft Azure is deeply integrated with Microsoft 365, Teams, SharePoint, and Outlook. A compromised Azure account often means a compromised email account, compromised files, compromised communications — the blast radius extends far beyond just cloud infrastructure. Understanding this scope is critical to your response.

This guide is your complete Azure incident response playbook, covering the Microsoft-specific tools, APIs, and remediation steps that most generic cloud security guides miss.

Understanding the Azure Attack Surface

Azure compromises typically occur through one of these vectors:

Entra ID (formerly Azure AD) credential theft: Phishing attacks targeting Microsoft 365 login pages, credential stuffing using leaked password databases, or MFA fatigue attacks (spamming push notifications until a tired user taps Approve)
Exposed service principal credentials: Client secrets or certificate private keys for App Registrations committed to code repositories or stored in unprotected configuration files
Managed Identity abuse: SSRF attacks against the Azure Instance Metadata Service (IMDS) to steal managed identity tokens from Azure VMs or App Services
OAuth application consent phishing: Attackers trick users into granting OAuth permissions to malicious third-party applications that then maintain persistent access
Overprivileged legacy authentication: Basic authentication protocols (IMAP, SMTP, older Exchange) bypass MFA and can be exploited if not blocked

Phase 1: First 15 Minutes — Immediate Containment

Step 1: Check Microsoft Defender XDR for Active Incidents

Before making any changes, check the Microsoft Defender portal (security.microsoft.com) for active incidents and alerts. This gives you an immediate overview of what Microsoft's systems have already detected. Look at the Incidents queue and sort by severity. Active attack campaigns will often already be flagged here with timeline and affected assets.

Step 2: Disable Compromised Entra ID Accounts

Navigate to Microsoft Entra admin center (entra.microsoft.com) → Users → All users. Identify compromised accounts. For each compromised user:

Click the user → click "Revoke sessions" to invalidate all active tokens immediately
Block sign-in (toggle "Account enabled" to No)
Reset the password from an admin account
Check "Authentication methods" and verify no attacker-added phone numbers or authenticator apps were added

Using Microsoft Graph or Azure CLI to revoke sessions at scale:

# Using Azure CLI — revoke all refresh tokens for a user
az ad user revoke-sign-in-sessions --id user@yourdomain.com

# Block a user's sign-in
az ad user update --id user@yourdomain.com --account-enabled false

# List all recent risky sign-ins (requires Entra ID P2)
az rest --method GET   --url "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers"   --query "value[?riskLevel=='high'].{user:userPrincipalName, risk:riskLevel, state:riskState}"

Step 3: Revoke App Registrations and Service Principal Credentials

Navigate to Entra admin center → App registrations and look for applications you do not recognize. Also check Enterprise applications for third-party apps with permissions you did not grant. For any suspicious App Registration:

Navigate to "Certificates & secrets"
Delete all client secrets (note their IDs and expiry dates first)
Delete any certificates you did not register
For legitimate apps, rotate secrets immediately

# List all App Registrations and their credentials
az ad app list --all --query "[*].{name:displayName, appId:appId, createdDateTime:createdDateTime}" --output table

# List all service principal credentials (secrets and certificates)
for appId in $(az ad app list --all --query "[*].appId" --output tsv); do
  echo "App: $(az ad app show --id $appId --query displayName -o tsv)"
  az ad app credential list --id $appId --output table 2>/dev/null
done

# Delete a specific credential from an App Registration
az ad app credential delete --id APP_OBJECT_ID --key-id CREDENTIAL_KEY_ID

Step 4: Identify and Stop Unauthorized Azure Resources

Navigate to Azure Portal → All resources and sort by "Created" date. Look for virtual machines, storage accounts, or other resources created in the past 24-72 hours that you did not create. Check all subscriptions — attackers frequently use regions you do not normally operate in.

# List all VMs across all subscriptions
az vm list --all --query "[*].{name:name,location:location,resourceGroup:resourceGroup,vmSize:hardwareProfile.vmSize}" --output table

# List all resources created in the last 24 hours
az resource list   --query "[?createdTime >= '2026-03-14T00:00:00Z'].{name:name,type:type,location:location,created:createdTime}"   --output table

# Check for resources in unusual locations
az resource list --query "[*].location" --output tsv | sort | uniq -c | sort -rn

Step 5: Set Spending Limits and Budget Alerts

Navigate to Cost Management → Budgets and create a budget with alerts at 80%, 100%, and 120% of your expected spend. If you are in an active breach, set the budget to your current month's spend and enable email alerts. This will notify you of continued unauthorized spending immediately.

Phase 2: First Hour — Comprehensive Forensics

Step 6: Analyze Azure Activity Logs

The Azure Activity Log records all control-plane operations (resource creation, deletion, configuration changes). Navigate to Azure Monitor → Activity log and filter by the past 72 hours. Sort by "Operation" and look for Create and Delete operations on compute resources, role assignment changes, and policy modifications.

# Query Activity Log for recent role assignments
az monitor activity-log list   --start-time 2026-03-13T00:00:00Z   --offset 24h   --query "[?operationName.localizedValue contains 'Microsoft.Authorization/roleAssignments/write'].{time:eventTimestamp, operation:operationName.localizedValue, caller:caller, resource:resourceId}"   --output table

# Look for VM creation events
az monitor activity-log list   --offset 48h   --query "[?operationName.value == 'Microsoft.Compute/virtualMachines/write'].{time:eventTimestamp, caller:caller, vm:resourceId}"   --output table

# Look for storage account creation (data exfiltration staging)
az monitor activity-log list   --offset 48h   --query "[?operationName.value == 'Microsoft.Storage/storageAccounts/write'].{time:eventTimestamp, caller:caller, storage:resourceId}"   --output table

Step 7: Review Entra ID Sign-In Logs

Navigate to Entra admin center → Monitoring → Sign-in logs. Filter for the attack timeframe and look for:

Sign-ins from unusual locations (countries where you have no employees)
Sign-ins at unusual times (middle of the night in your timezone)
Failed MFA followed quickly by a successful sign-in (MFA fatigue attack)
Sign-ins using legacy authentication protocols (shown as "Client app: Other clients")
Multiple sign-ins from different countries within a short timeframe (impossible travel)

# Query sign-in logs via Microsoft Graph API
az rest --method GET   --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=createdDateTime ge 2026-03-13T00:00:00Z and riskLevelAggregated eq 'high'"   --query "value[*].{user:userPrincipalName, ip:ipAddress, location:location.city, time:createdDateTime, status:status.failureReason}"

Step 8: Check for Suspicious OAuth Application Consents

OAuth application consent phishing is a common Azure attack where users are tricked into granting excessive permissions to a malicious application. The application then uses these permissions to read emails, access SharePoint files, or make API calls — all without needing the user's password.

Navigate to Entra admin center → Enterprise applications → All applications. Look for applications with names like "PDF Converter", "Helpdesk Tool", or other generic names that users might click. Filter by "User consent" and look for apps recently granted high permissions like Mail.ReadWrite, Files.ReadWrite.All, or full_access_as_user.

# List all OAuth app grants with high permissions
az rest --method GET   --url "https://graph.microsoft.com/v1.0/servicePrincipals?$expand=oauth2PermissionGrants"   --query "value[*].{app:displayName, consent:oauth2PermissionGrants}"

# Revoke all OAuth grants for a specific service principal
az rest --method DELETE   --url "https://graph.microsoft.com/v1.0/oauth2PermissionGrants/GRANT_ID"

Step 9: Check Azure Key Vault Access

Azure Key Vault stores secrets, certificates, and encryption keys. If the attacker accessed Key Vault, they may have exfiltrated credentials for databases, APIs, and other services. Navigate to Key Vault → Monitoring → Diagnostics settings and check if audit logging was enabled. Check the Key Vault Access Policy or RBAC assignments for unauthorized principals.

# Check Key Vault access policies
az keyvault show --name YOUR_VAULT_NAME   --query "properties.accessPolicies[*].{objectId:objectId, permissions:permissions}"   --output json

# Check recent Key Vault operations via diagnostic logs
az monitor log-analytics query   --workspace YOUR_LOG_ANALYTICS_WORKSPACE   --analytics-query "AzureDiagnostics | where ResourceType == 'VAULTS' | where OperationName contains 'SecretGet' | project TimeGenerated, CallerIPAddress, OperationName, identity_claim_oid_g"

Phase 3: Identifying and Closing Persistence Mechanisms

Step 10: Audit All Role Assignments

Attackers commonly add themselves to privileged Azure RBAC roles or Entra ID directory roles to maintain persistent access. Check both:

# List all role assignments across all subscriptions
az role assignment list --all   --query "[*].{principal:principalName, role:roleDefinitionName, scope:scope, principalType:principalType}"   --output table

# Look specifically for Owner and Contributor assignments to external accounts
az role assignment list --all   --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor'].{principal:principalName, type:principalType, scope:scope}"   --output table

Also check Entra admin center → Roles and administrators for unauthorized Global Administrator, Privileged Role Administrator, or Application Administrator assignments.

Step 11: Check for Automation Runbooks and Logic Apps

Attackers may use Azure Automation Runbooks or Logic Apps as persistence mechanisms — these can run code on a schedule or trigger, maintaining access even after the initial credentials are changed.

# List all Automation Accounts and Runbooks
az automation account list --query "[*].{name:name,resourceGroup:resourceGroup}" --output table

# List runbooks in an automation account
az automation runbook list   --automation-account-name YOUR_ACCOUNT   --resource-group YOUR_RG   --output table

# List all Logic Apps (check for recently created ones)
az logic workflow list   --query "[*].{name:name,resourceGroup:resourceGroup,state:state,createdTime:changedTime}"   --output table

Phase 4: Recovery and Remediation

Step 12: Delete Unauthorized Resources

For unauthorized resource groups (the most common container for attacker-created resources), delete the entire resource group to remove everything at once:

# Delete an unauthorized resource group (and all resources in it)
az group delete --name UNAUTHORIZED_RG_NAME --yes --no-wait

# Lock down a subscription by setting a restrictive policy
az policy assignment create   --name "deny-unauthorized-regions"   --policy "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"   --params '{"listOfAllowedLocations":{"value":["eastus","westus2"]}}'

Step 13: Rotate All Credentials

After removing unauthorized access, rotate all credentials that could have been compromised:

Reset all Azure Active Directory user passwords and require MFA re-registration
Rotate all App Registration client secrets and certificates
Rotate all storage account access keys and connection strings
Rotate all secrets in Azure Key Vault and update consuming applications
Regenerate all function keys for Azure Functions
Rotate all API Management subscription keys
Rotate SQL/PostgreSQL/MySQL passwords and update connection strings

Phase 5: Azure Billing Dispute

Step 14: Submit a Fraudulent Charges Dispute

Navigate to Azure Portal → Cost Management → Cost analysis to identify all unauthorized charges. Then open a support request at portal.azure.com → Support → New support request. Select "Billing" as the issue type and "Fraudulent or unexpected charges" as the sub-type.

Microsoft has a dedicated Azure billing fraud team. In your request, include:

The incident timeline with specific dates and times
Evidence from Activity Logs showing unauthorized resource creation
Confirmation that you have revoked all compromised credentials
List of unauthorized resources and their associated costs
Your remediation steps and new security controls

Microsoft typically processes billing disputes within 5-10 business days. For urgent cases with large amounts, request escalation to a billing specialist. Keep all communication in writing for your records.

Phase 6: Azure Security Hardening

Entra ID Zero Trust Principles

Enable Conditional Access policies requiring MFA for all users, all applications, from all locations — no exceptions. Require compliant devices for privileged operations
Enable Identity Protection (requires Entra ID P2) with automatic risk-based policies: high-risk sign-ins require MFA, high-risk users are blocked
Block legacy authentication protocols (SMTP AUTH, IMAP, POP3, Basic auth) using Conditional Access — these bypass MFA entirely
Implement Privileged Identity Management (PIM) for just-in-time access to privileged roles. No one should have permanent Global Administrator — use PIM to grant it for specific tasks with approval workflows
Enable SSPR (Self-Service Password Reset) with authentication method verification to prevent account takeover via password reset flows

Subscription and Resource Controls

Enable Microsoft Defender for Cloud (free tier) on all subscriptions for continuous security posture management. Enable Defender for servers, Defender for storage, and Defender for Key Vault on production subscriptions
Enable Azure Policy to enforce allowed regions, required tags, allowed VM sizes, and deny public IP addresses where not needed
Use Azure Blueprints or Bicep templates for consistent, auditable environment setup that enforces security by default
Enable Azure Monitor Diagnostic Logs for all critical resources (Key Vault, Storage, SQL, Application Gateway) and ship them to a Log Analytics workspace in a separate, locked-down subscription

Detection Capabilities

Deploy Microsoft Sentinel as your SIEM — it ingests Entra ID sign-in logs, Azure Activity logs, Microsoft 365 audit logs, and third-party logs, and provides out-of-box detection rules for common Azure attack patterns
Enable all Microsoft Defender XDR workloads: Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps
Set up Azure Monitor Alerts for: new role assignment at Owner level, service principal credential added, Key Vault access denied (brute force), new Logic App created, MFA disabled for a user

Network and Application Security

Enable Azure Firewall Premium with threat intelligence filtering and TLS inspection for outbound traffic from VMs
Disable public RDP and SSH access — use Azure Bastion for secure, browser-based access without exposing port 3389 or 22
Use Private Endpoints for all PaaS services (Storage, SQL, Key Vault, Service Bus) to eliminate public internet exposure
Enable the Azure IMDS instance metadata service token requirement on all VMs — set Metadata.EndpointAccess to "Enabled" with HttpTokens "required" to prevent SSRF-based credential theft

Azure breaches that originate from Entra ID (formerly Azure AD) have a much larger blast radius than pure infrastructure breaches — they often compromise email, SharePoint documents, Teams conversations, and Power Automate workflows as well. The integrated Microsoft 365 environment is both Azure's greatest feature and its greatest security challenge. Defense-in-depth with Conditional Access, PIM, Defender, and Sentinel is the only way to adequately protect it.

Need help implementing Azure Zero Trust security, running an Azure security assessment, or responding to an active Azure incident? Contact ZeonEdge's cloud security team for immediate assistance.