Storm-0501 Azure Cloud Ransomware: Detecting Tenant Hijacking, Backup Destruction, and Key Vault Encryption Abuse

The ransomware playbook has fundamentally changed, and Storm-0501 is the proof. This financially motivated threat actor — tracked by Microsoft Threat Intelligence and the subject of recent Tenable research — has abandoned the classic model of deploying encryptor binaries to endpoints. Instead, Storm-0501 conducts cloud-first encryption campaigns that hijack entire Azure tenants: escalating from a compromised on-premises foothold to Global Administrator in Microsoft Entra ID, systematically dismantling every recovery mechanism the victim has (resource locks, immutability policies, Azure Backup), exfiltrating data, and then encrypting data at rest using the victim's own Azure Key Vault infrastructure — holding the keys hostage.

This matters because your endpoint detection stack is nearly blind to it. There is no malicious EXE to quarantine, no suspicious binary hash to block. The attacker uses legitimate Azure control-plane operations — the same API calls your cloud administrators make every day — executed with your own privileged credentials. The only reliable defense is detection engineering against the Azure activity plane itself: the configuration changes, deletions, and permission escalations that precede the encryption event. That is precisely the gap Tenable One Cloud Exposure's AI-powered threat stories are designed to close, correlating individual low-fidelity signals into a unified campaign narrative.

If you operate Azure workloads with hybrid identity, treat this as an active, in-the-wild threat requiring immediate detection coverage — not a theoretical exercise.

Technical Analysis

Threat Actor Profile

Storm-0501 is a financially motivated cybercrime group with historical ties to ransomware operations (previously associated with on-premises encryptor deployment). Microsoft has documented the group's evolution into cloud-native operations targeting Azure environments. Their campaigns are distinguished by a deliberate shift away from endpoint encryption toward total tenant hijacking, where the blast radius is the entire cloud estate rather than individual machines.

Attack Chain — Defender's View

Phase 1 — On-premises foothold and credential theft. Storm-0501 typically gains initial access through compromised credentials or unpatched on-premises systems, then moves laterally to harvest credentials with cloud synchronization value. Hybrid environments are the soft underbelly: a domain admin or a compromised Entra Connect (Azure AD Connect) synchronization account is often the bridge from on-prem to cloud control.

Phase 2 — Entra ID privilege escalation. Using stolen credentials (frequently against accounts without MFA or with legacy authentication), the actor authenticates to Entra ID and escalates to Global Administrator. This is the pivotal moment: Global Admin can elevate to Azure RBAC User Access Administrator at the root management group scope, granting effective control over every subscription in the tenant.

Phase 3 — Defensive countermeasure destruction. This is the signature behavior. Before any data is touched, Storm-0501 methodically neutralizes recovery and resistance mechanisms:

• Deletes Azure resource locks (Microsoft.Authorization/locks/delete) on resource groups, storage accounts, and Key Vaults
• Modifies or deletes immutability policies on blob storage (time-based retention and legal hold policies) — Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/write and /delete
• Disables or deletes Azure Backup policies and protected items (Microsoft.RecoveryServices/vaults/backupPolicies/delete, stopping protection on VMs and file shares)
• Disables soft delete and purge protection on Key Vaults, enabling permanent destruction of encryption keys and secrets

Each of these operations, in isolation, can look like routine administration. Together, in sequence, from a single principal — that is a ransomware staging operation.

Phase 4 — Data access and exfiltration. The actor grants itself access to storage accounts and Key Vaults (often via Key Vault access policies or RBAC assignments), then exfiltrates sensitive data for double extortion — frequently using legitimate tooling such as AzCopy or Azure Storage Explorer, which blends into normal data movement.

Phase 5 — Cloud-native encryption. Rather than dropping an encryptor, Storm-0501 abuses Azure's own encryption-at-rest architecture: creating attacker-controlled keys in the victim's Key Vault (or rotating customer-managed keys), re-encrypting data so only attacker-held key material can decrypt it, then deleting or exfiltrating the original key versions. Recovery without the attacker becomes cryptographically impossible — and because backups, locks, and immutability were destroyed in Phase 3, there is no fallback.

Exploitation Status

Confirmed active in-the-wild campaigns. This is not theoretical TTP research — Microsoft Threat Intelligence has documented Storm-0501 intrusions against real organizations, and Tenable's research reflects detection content built against observed attack patterns. No CVE is associated with this campaign; the actor exploits misconfiguration, weak identity hygiene, and the inherent power of legitimate Azure control-plane APIs, not a software vulnerability. There is nothing to patch. There is only configuration hardening and behavioral detection.

Why Static Rules Fail

A single locks/delete event is noise — admins remove locks during legitimate change windows daily. The Tenable One Cloud Exposure approach — AI-powered threat stories that chain identity escalation, defensive destruction, and data manipulation into one narrative — reflects the correct detection philosophy: correlate the sequence, not the signal. The Sigma and KQL detections below are built to fire on the individual high-fidelity components of that sequence; your SOC (or an MDR provider) should be treating any co-occurrence from a single principal within hours as a critical incident.

Detection & Response

Sigma Rules

The following rules target the Azure activity log (control plane). Forward Azure Activity Logs to your SIEM via Azure Monitor diagnostic settings before deploying these.

---
title: Azure Resource Lock Deletion - Ransomware Staging Indicator
id: 8f3c2a1d-4b7e-4e9f-b6a1-9d2e5c7f3a01
status: experimental
description: Detects deletion of Azure resource locks, a hallmark of Storm-0501 pre-encryption staging where recovery guardrails are removed before data destruction.
references:
  - https://www.tenable.com/blog/detecting-cloud-ransomware-in-azure-with-tenable-ones-cloud-detection-and-response
  - https://attack.mitre.org/techniques/T1485/
author: Security Arsenal
date: 2026/06/15
tags:
  - attack.impact
  - attack.t1485
  - attack.defense_evasion
  - attack.t1562
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName: 'MICROSOFT.AUTHORIZATION/LOCKS/DELETE'
    properties.statuscode: 'OK'
  condition: selection
falsepositives:
  - Legitimate change management windows where locks are removed intentionally
level: high
---
title: Azure Backup Protection Disabled or Policy Deleted
id: 2d9e4b6c-8a1f-4c3d-a7e2-5f8b1c4d6e09
status: experimental
description: Detects deletion of Azure Backup policies or disabling of backup protection on protected items, consistent with Storm-0501 destruction of recovery options prior to encryption.
references:
  - https://www.tenable.com/blog/detecting-cloud-ransomware-in-azure-with-tenable-ones-cloud-detection-and-response
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/06/15
tags:
  - attack.impact
  - attack.t1490
logsource:
  product: azure
  service: activitylogs
detection:
  selection_policy:
    operationName:
      - 'MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPPOLICIES/DELETE'
      - 'MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPFABRICS/PROTECTIONCONTAINERS/PROTECTEDITEMS/DELETE'
  selection_disable:
    operationName: 'MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPFABRICS/PROTECTIONCONTAINERS/PROTECTEDITEMS/WRITE'
    properties.eventDataId|contains:
      - 'StopProtection'
      - 'Disable'
  condition: 1 of selection_*
falsepositives:
  - Decommissioning workloads legitimately removing backup protection
level: critical
---
title: Azure Storage Immutability Policy Removed or Key Vault Purge Protection Disabled
id: 6c1f8a3e-2d5b-4f9a-b8c4-7e1a3d5f9b02
status: experimental
description: Detects removal of blob immutability policies or disabling of Key Vault purge protection, both precursor actions to permanent data destruction in cloud encryption campaigns.
references:
  - https://www.tenable.com/blog/detecting-cloud-ransomware-in-azure-with-tenable-ones-cloud-detection-and-response
  - https://attack.mitre.org/techniques/T1485/
author: Security Arsenal
date: 2026/06/15
tags:
  - attack.impact
  - attack.t1485
  - attack.defense_evasion
  - attack.t1562
logsource:
  product: azure
  service: activitylogs
detection:
  selection_immutability:
    operationName:
      - 'MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/IMMUTABILITYPOLICIES/DELETE'
      - 'MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/IMMUTABILITYPOLICIES/WRITE'
  selection_keyvault:
    operationName: 'MICROSOFT.KEYVAULT/VAULTS/WRITE'
    properties.requestbody|contains:
      - '"enablePurgeProtection": false'
      - '"enablePurgeProtection":null'
      - '"enableSoftDelete": false'
  condition: 1 of selection_*
falsepositives:
  - Dev/test environment teardown where immutability is intentionally removed
level: high

KQL — Microsoft Sentinel / Defender

The highest-value hunt is correlation: a single principal performing two or more destructive/defense-evasion categories within a 24-hour window. That multi-signal pattern is what Tenable's threat stories model, and it is nearly noise-free in practice. This query assumes Azure Activity Logs are streamed to Sentinel (AzureActivity table) and Entra ID AuditLogs are connected.

// Storm-0501 pre-encryption staging: correlate destructive control-plane ops by single principal
let window = 24h;
let suspiciousOps = dynamic([
  "MICROSOFT.AUTHORIZATION/LOCKS/DELETE",
  "MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPPOLICIES/DELETE",
  "MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPFABRICS/PROTECTIONCONTAINERS/PROTECTEDITEMS/DELETE",
  "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/IMMUTABILITYPOLICIES/DELETE",
  "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/IMMUTABILITYPOLICIES/WRITE",
  "MICROSOFT.KEYVAULT/VAULTS/ACCESSPOLICIES/WRITE",
  "MICROSOFT.KEYVAULT/VAULTS/KEYS/CREATE",
  "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
]);
AzureActivity
| where TimeGenerated > ago(window)
| where OperationNameValue in~ (suspiciousOps)
| where ActivityStatusValue =~ "Success"
| summarize
    DistinctOps = dcount(OperationNameValue),
    Ops = make_set(OperationNameValue, 50),
    FirstOp = min(TimeGenerated),
    LastOp = max(TimeGenerated),
    ResourceCount = dcount(ResourceId),
    Subscriptions = make_set(SubscriptionId, 10)
  by Caller, CallerIpAddress
| where DistinctOps >= 2
| extend RiskNote = iif(DistinctOps >= 3, "CRITICAL - likely ransomware staging", "HIGH - investigate immediately")
| sort by DistinctOps desc;

// Companion hunt: Global Admin / privileged role assignment in Entra ID AuditLogs
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName in~ ("Add member to role", "Add eligible member to role")
| mv-expand TargetResources
| where tostring(TargetResources.modifiedProperties) has_any ("Global Administrator", "User Access Administrator", "Owner")
| extend InitiatedBy = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources.userPrincipalName, Result
| sort by TimeGenerated desc;

Tune the DistinctOps >= 2 threshold against your environment. In most tenants, legitimate administrators touch backup policies and locks in the same day perhaps a handful of times per quarter — every hit deserves analyst eyes.

Velociraptor VQL — Endpoint Hunt

Storm-0501's control-plane abuse is frequently executed from compromised on-premises systems using Azure CLI, Az PowerShell, or AzCopy — often under contexts that never touch those tools normally. This artifact hunts for that tooling execution and the Azure CLI token cache that follows interactive authentication (a prime target for token theft enabling the cloud pivot).

-- Hunt for Azure CLI / AzCopy execution and Azure token cache artifacts (Storm-0501 tooling)
LET proc_hunt = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)az\.exe|azcopy|AzureCLI'
   OR CommandLine =~ '(?i)az (storage|keyvault|backup|lock|role)|azcopy (copy|sync)'

LET token_cache = SELECT FullPath, Size, Mtime, Atime
FROM glob(globs='C:/Users/*/.azure/msal_token_cache*',
          accessor='ntfs')
WHERE Mtime > now() - 86400 * 7

SELECT * FROM proc_hunt
UNION ALL
SELECT NULL AS Pid, FullPath AS Name, NULL AS CommandLine,
       FullPath AS Exe, NULL AS Username, Mtime AS CreateTime
FROM token_cache

A workstation running az storage blob download or az keyvault key create that has no documented Azure administration role is an immediate escalation — that is the exact bridge Storm-0501 walks from endpoint to tenant.

Verification & Hardening Script

This PowerShell script audits the exact defensive controls Storm-0501 destroys, so you can verify current posture and identify gaps before an attacker does. Run with an account holding Reader over target subscriptions (requires the Az module).

# Storm-0501 Defensive Posture Audit — verify locks, immutability, backup, Key Vault protections
Connect-AzAccount -UseDeviceAuthentication

foreach ($sub in (Get-AzSubscription)) {
  Set-AzContext -SubscriptionId $sub.Id | Out-Null
  Write-Host "`n=== Subscription: $($sub.Name) ===" -ForegroundColor Cyan

  # 1. Resource locks — flag RG and resource groups WITHOUT CanNotDelete locks
  $locks = Get-AzResourceLock
  $rgs = Get-AzResourceGroup
  $unlocked = $rgs | Where-Object { $_.ResourceGroupName -notin ($locks.ResourceGroupName) }
  Write-Host "Resource groups without locks: $($unlocked.Count) / $($rgs.Count)" -ForegroundColor $(if($unlocked){'Yellow'}else{'Green'})

  # 2. Key Vault soft delete + purge protection (MUST be enabled)
  Get-AzKeyVault | ForEach-Object {
    $kv = Get-AzKeyVault -VaultName $_.VaultName
    if (-not $kv.EnableSoftDelete -or -not $kv.EnablePurgeProtection) {
      Write-Host "[CRITICAL] $($kv.VaultName): SoftDelete=$($kv.EnableSoftDelete) PurgeProtection=$($kv.EnablePurgeProtection)" -ForegroundColor Red
      # Enable (purge protection is irreversible once on - that is the point)
      Update-AzKeyVault -VaultName $kv.VaultName -EnablePurgeProtection -EnableSoftDelete -ErrorAction SilentlyContinue
    }
  }

  # 3. Storage account immutability posture
  Get-AzStorageAccount | ForEach-Object {
    $sa = Get-AzStorageAccount -ResourceGroupName $_.ResourceGroupName -Name $_.StorageAccountName
    if (-not $sa.EnableAccountLevelImmutability) {
      Write-Host "[WARN] $($sa.StorageAccountName): no account-level immutability policy" -ForegroundColor Yellow
    }
  }

  # 4. Recovery Services vaults — verify soft delete is on
  Get-AzRecoveryServicesVault | ForEach-Object {
    $p = Get-AzRecoveryServicesVaultProperty -VaultId $_.ID
    if ($p.SoftDeleteFeatureState -ne "Enabled") {
      Write-Host "[CRITICAL] RSV $($_.Name): soft delete is $($p.SoftDeleteFeatureState)" -ForegroundColor Red
      Set-AzRecoveryServicesVaultProperty -VaultId $_.ID -SoftDeleteFeatureState "Enable"
    }
  }

  # 5. Recent destructive operations (last 7 days) - rapid triage
  $start = (Get-Date).AddDays(-7)
  Get-AzActivityLog -StartTime $start -WarningAction SilentlyContinue |
    Where-Object { $_.OperationName.Value -match 'locks/delete|backupPolicies/delete|immutabilityPolicies/(write|delete)' -and $_.Status.Value -eq 'Succeeded' } |
    Select-Object EventTimestamp, Caller, @{n='Op';e={$_.OperationName.Value}}, ResourceId |
    Format-Table -AutoSize
}

Remediation

Because this campaign exploits configuration weakness rather than a software CVE, remediation is an architectural hardening exercise. Prioritize in this order:

1. Identity — close the bridge from on-prem to cloud (highest priority).

• Enforce phishing-resistant MFA (FIDO2/passkeys or certificate-based) for all privileged roles — Global Administrator, User Access Administrator, Owner, Contributor. Storm-0501's escalation path dies here.
• Deploy Microsoft Entra Privileged Identity Management (PIM) with just-in-time elevation and approval workflows for Global Admin. Standing Global Admin assignments should trend to zero.
• Disable legacy authentication tenant-wide via Conditional Access. Audit the Entra Connect sync account — restrict its permissions to the documented minimum and monitor it like a Tier-0 asset.
• Apply Conditional Access token protection and sign-in risk policies to cloud management portals.

2. Data protection — make destruction irreversible-by-design.

• Enable purge protection and soft delete on every Key Vault (purge protection cannot be disabled once enabled — this is a one-way ratchet that defeats key destruction).
• Enforce immutability policies (WORM) on critical blob containers and use account-level immutability on storage accounts holding crown-jewel data. Time-based retention with a locked policy cannot be shortened or removed, even by a Global Admin.
• Enable soft delete on Recovery Services vaults and use multi-user authorization (MUA) on backup vaults, which requires a second authorized identity (via Resource Guard) to approve disabling protection — directly defeating Storm-0501's single-identity backup destruction.
• Apply CanNotDelete resource locks on Key Vaults, storage accounts, and Recovery Services vaults. Locks are a speed bump, not a wall — but combined with detection on locks/delete, they are a tripwire.

3. Detection & monitoring — wire the tripwires.

• Stream Azure Activity Logs, Entra ID AuditLogs, and Key Vault diagnostic logs to your SIEM (Sentinel or equivalent). Deploy the detections above.
• If you run Tenable One, enable Cloud Exposure / Cloud Detection and Response and review the generated threat stories for Storm-0501 patterns — the correlation of identity escalation with defensive destruction is the core value. Validate that the relevant detection alerts are enabled and routed to your SOC queue, not just the console.
• Alert on any Microsoft.KeyVault/vaults/keys/create by identities outside your approved key-management group — attacker-controlled key creation is the encryption trigger.

4. Recovery readiness.

• Maintain an out-of-tenant backup copy (cross-tenant or offline/immutable) for critical data. Any backup reachable with the same Global Admin credential is not a backup — it is a hostage.
• Test restoration of Key Vault-protected and immutability-protected data quarterly. Document break-glass recovery that assumes total tenant compromise.

5. Response triggers.

• Treat any single principal executing two or more of: lock deletion, backup policy deletion, immutability modification, Key Vault purge-protection change, or privileged role assignment within 24 hours as a potential active intrusion. Immediate actions: revoke the principal's sessions (Entra ID revokeSignInSessions), rotate credentials, snapshot Key Vault key inventory, and engage IR before any encryption activity completes. In cloud ransomware, you are racing a control-plane timeline measured in hours, not days.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub