Azure Resource Group deletion (T1485 — Data Destruction, T1531 — Account Access Removal) is a high-impact action that deletes all resources within the group in a single API call. Attackers use this for ransomware-style destruction or to cover tracks after exfiltrating data. Resource Group delete requires Contributor or Owner role at the Resource Group or Subscription level — its presence indicates significant privilege access by the actor.
Response priority: assess whether the deletion was authorized (DevOps teardown, cost management), assess recovery viability from backups or soft-delete, and identify how the actor obtained delete permissions.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWA Resource Group delete operation (Microsoft.Resources/resourceGroups/delete) cascades to all child resources — VMs, databases, storage accounts, App Services — within the group. Azure Activity Logs capture the initiator's identity, IP address, and timestamp. The operation is asynchronous: deletion typically completes in 15–60 minutes. Some resources (soft-delete enabled Key Vault, Recovery Services Vault backups) survive a Resource Group deletion if protected.
| Field | Value |
|---|---|
| MITRE Technique | T1485 — Data Destruction, T1531 — Account Access Removal |
| Log Sources | AzureActivity, AuditLogs (Entra ID), AzureMetrics |
| Operation Name | Microsoft.Resources/resourceGroups/delete |
| Required RBAC | Contributor or Owner at Resource Group or Subscription scope |
| Detection Priority | CRITICAL if production resource group — potential destructive attack |
02 — IDENTIFICATION
2 INDICATORSAzure Activity Logs record the identity (UPN or Service Principal), client IP, and caller timestamp for every Resource Group delete operation. This determines whether the deletion was authorized (matching a change ticket) or unauthorized (compromised account, rogue administrator, or malicious Service Principal).
- 1Navigate to Monitor → Activity log. Filter by Operation: Delete resource group and set time range to Last 24 hours.
- 2Review
Event initiated by: note whether this is a user UPN, a Service Principal (App Registration), or a Managed Identity. - 3Check the caller IP address against known corporate IPs and approved automation pipeline IPs — a foreign IP or cloud provider IP (Azure compute IP) is a high-risk indicator.
- 4Cross-reference the deletion time against the change management system for an authorized change ticket covering this resource group.
- 5Run the KQL below in Sentinel to correlate the Resource Group deletion with any RBAC role assignments added to the caller's account in the preceding 24 hours (privilege escalation path).
| Caller Identity | Meaning | Action |
|---|---|---|
| User UPN (no ticket) | Unauthorized deletion by compromised or rogue admin account | REVOKE ACCESS NOW |
| Service Principal | Automated pipeline or compromised SP with delete rights | Disable SP, investigate pipeline |
| Managed Identity | Azure-managed identity with delete role — check VM/App it runs on | Review MI role assignments |
| User UPN (with ticket) | Authorized teardown — verify ticket scope matches deleted RG | Verify & document |
Azure Resource Group deletion is irreversible for most resource types once the deletion cascade completes. Time is critical — if the deletion is in progress (operation shows Accepted or Running), attempt to cancel via the Azure CLI: az group delete --name RG_NAME --no-wait cannot be cancelled once committed, but you can attempt to re-deploy from ARM templates immediately.
Legitimate Resource Group deletions require pre-existing Contributor or Owner rights. If the deletion was unauthorized, the attacker either compromised an account that already had delete rights, or escalated privileges by adding an RBAC role assignment shortly before the deletion. AuditLogs records every RBAC change with the actor who made the assignment.
- 1Navigate to Entra ID → Monitoring → Audit logs. Filter by Activity: Add member to role or Add app role assignment in the 48 hours before the deletion event.
- 2Identify if the deletion caller was granted Contributor or Owner on the subscription or resource group within the preceding 24 hours by an account that should not have that capability.
- 3Run the KQL below to find all RBAC role assignments (AzureActivity) in the subscription in the 48 hours before the deletion.
- 4Check if the RBAC assignment was made by a different account than the deletion caller — this indicates a two-actor attack: one account escalates, another destroys.
- 5Review the escalating account's sign-in history for anomalous IP or location that would indicate it was compromised.
Enable Azure Resource Locks (Management group / Subscription / RG → Locks → Add → Delete lock) on all production Resource Groups as a preventive control. A Delete lock requires an explicit lock removal step (which is itself logged) before deletion can proceed — this creates a detectable two-step operation even for authorized deletions.
03 — CONTAINMENT
IMMEDIATE ACTION- 1If the caller is a user account: disable it in Entra ID immediately — Users → [User] → Block sign-in and revoke all sessions.
- 2If the caller is a Service Principal: disable the App Registration — App registrations → [App] → Properties → Enable application = No.
- 3Remove all RBAC role assignments that granted the caller Contributor/Owner: Subscriptions → [Sub] → Access control (IAM) → Role assignments → Remove.
- 4Check for any remaining bulk delete operations in progress across other resource groups: re-run the AzureActivity KQL for
Microsoft.Resources/resourceGroups/deletefor all subscriptions. - 5Identify any data exfiltration that may have preceded the deletion: check Azure Storage diagnostic logs for bulk download operations in the 6 hours before the deletion.
04 — ERADICATION
CLEANUP- 1Assess recovery options: check Azure Backup Vault for VM backups, check Azure SQL geo-redundant backups, check Key Vault soft-delete (90-day retention by default even after RG delete).
- 2If ARM templates exist in DevOps or GitHub: initiate resource re-deployment from last known good state. Contact the application team for RTO/RPO assessment.
- 3Apply Resource Locks to all remaining production Resource Groups: RG → Locks → Add → Lock type: Delete.
- 4Audit all Contributor and Owner role assignments at subscription scope: remove any accounts or Service Principals that should not have subscription-level delete rights.
- 5Enable Defender for Cloud for the subscription to alert on future destructive operations: Defender for Cloud → Environment settings → [Subscription] → Defender plans → Enable.
- Caller account/SP disabled and RBAC revoked
- All other production Resource Groups confirmed with Delete Lock applied
- Subscription-level Owner/Contributor assignments audited and trimmed
- Recovery path assessed and recovery initiated if required
- Defender for Cloud alerts enabled on subscription
05 — ESCALATION
ESCALATION PATHS| Condition | Severity | Action | Notify |
|---|---|---|---|
| Production RG deleted, no ticket, no recovery | SEV1 | Full IR, disable caller, notify exec, recovery | SOC Lead → CISO → CTO → CEO |
| Production RG deleted, recovery viable | SEV1 | IR + parallel recovery track, 72h breach check | SOC Lead → CISO → App Team |
| Non-production RG, unauthorized caller | SEV2 | Disable caller, RBAC audit, investigate path | SOC Lead → Cloud Security |
| Authorized DevOps deletion, dev/test RG | INFO | Verify ticket, apply lock to prod, close | None |
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.