JadePuffer Agentic AI Attacks on Azure: Detection, Hunting, and Hardening Guide for Cloud Defenders

In 15 years of incident response, I've watched attackers industrialize every stage of the kill chain — exploit kits, ransomware-as-a-service, initial access brokers. What the JadePuffer campaign represents is the next logical step, and it's one defenders need to internalize immediately: agentic AI tooling is now running hands-on-keyboard-equivalent intrusions against Azure tenants, and it's conducting reconnaissance, credential theft, and destructive operations at machine speed.

Per reporting by BleepingComputer, the JadePuffer encryption-based incident operator is targeting Azure tenants with agent-driven attacks that enumerate the environment, harvest credentials, and — critically — destroy core cloud components. This is not cryptomining or data staging for extortion alone. Resource destruction inside a tenant means business interruption measured in days to weeks if your recovery posture is weak, and permanent data loss if your backup architecture shares the blast radius of your production tenant.

What makes agent-driven attacks operationally different from the intrusions most SOC playbooks were built for:

Velocity. Reconnaissance that used to take an operator hours compresses into minutes. Your detection-to-containment window shrinks accordingly.
Parallelism. An agent can enumerate subscriptions, query role assignments, and probe storage accounts simultaneously across regions — generating a burst pattern that is itself a detection opportunity.
Legitimate tooling. These attacks run through native Azure interfaces — Azure CLI, Az PowerShell, REST API calls, and cloud shell sessions — which means signature-based detection is largely useless. Behavioral analytics on control-plane activity is the only viable layer.

If you run production workloads in Azure, treat this as an active-threat scenario, not a think piece. The sections below give you the detection engineering and hardening steps to act on today.

Technical Analysis: How JadePuffer-Style Agent Attacks Unfold

No CVE underpins this campaign — this is identity- and control-plane abuse, not a software vulnerability. The attack chain, based on the reported TTPs, follows a pattern we've seen in hands-on cloud intrusions, now automated:

1. Initial Access via Credential Compromise

The entry vector is stolen or phished credentials — typically a user or service principal with contributor-level or higher rights on a subscription. Token theft from developer endpoints (where Azure CLI caches refresh tokens in %USERPROFILE%\.azure on Windows or ~/.azure on Linux/macOS) remains one of the most reliable paths into a tenant. Once the agent holds a valid token, it inherits every permission that identity carries — no exploit required.

2. Automated Reconnaissance

The agentic layer shines here. Expect rapid-fire execution of enumeration commands:

az account list, az account subscription list — tenant and subscription mapping
az ad user list, az ad sp list — identity inventory
az role assignment list --all — privilege mapping to find escalation paths and high-value targets
az resource list, az vm list, az storage account list, az keyvault list — asset discovery
az network nsg list, az network public-ip list — network exposure mapping

In Microsoft Graph / ARM telemetry, this appears as an abnormal density of read operations from a single principal in a short window — often from an IP address or ASN with no prior history for that identity, and frequently with a user-agent string indicating programmatic CLI/PowerShell access outside normal change windows.

3. Credential Expansion

With contributor or owner rights, the agent pivots to credential harvesting: listing Key Vault secrets (az keyvault secret list / show), extracting connection strings from app services, pulling automation account credentials, or creating new service principals with secrets for persistence (az ad sp create-for-rbac). New credential creation on existing service principals is a classic persistence move that survives password resets of the originally compromised user.

4. Destructive Actions

The reported endgame is destruction of core components. In Azure control-plane terms, that means:

Microsoft.Compute/virtualMachines/delete
Microsoft.Resources/subscriptions/resourcegroups/delete (the nuclear option — deletes everything inside)
Microsoft.Storage/storageAccounts/delete
Microsoft.Sql/servers/databases/delete
Microsoft.KeyVault/vaults/delete (especially dangerous if purge protection is disabled — the vault and its secrets are unrecoverable after purge)
Deletion of backup vaults and recovery services vaults first, to foreclose recovery

That last point deserves emphasis: disciplined destructive actors — automated or human — remove recovery capability before they destroy production. If you see Microsoft.RecoveryServices/vaults/delete or backup policy deletion in your activity log, you are likely already mid-incident.

Exploitation Status

This campaign is confirmed active in the wild per the source reporting. There is no patch because there is no vulnerability — the mitigation surface is identity hygiene, conditional access, control-plane monitoring, and recovery architecture. Because no CVE applies, no CISA KEV entry exists; your compensating controls are the entire game.

Detection & Response

The strongest signal in this campaign is the temporal pattern: an identity performing a burst of enumeration followed by deletions it has never performed before, from unfamiliar infrastructure. The detections below target that pattern and its constituent behaviors.

Sigma Rules

These rules target Azure Activity Logs (control plane) ingested into your SIEM. Tune the deletion rule against known automation service principals in your environment before enabling at high severity.

YAML

---
title: Azure Mass Resource Deletion by Single Principal
id: 9f2c8a41-6b3d-4e7a-b512-8c4d9e2f1a07
status: experimental
description: Detects a single principal performing multiple Azure resource deletion operations in a short window, consistent with destructive attacks such as the JadePuffer campaign targeting Azure tenants.
references:
  - https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/
  - https://attack.mitre.org/techniques/T1485/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1485
  - attack.t1490
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName|contains:
      - 'MICROSOFT.COMPUTE/VIRTUALMACHINES/DELETE'
      - 'MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE'
      - 'MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE'
      - 'MICROSOFT.SQL/SERVERS/DATABASES/DELETE'
      - 'MICROSOFT.KEYVAULT/VAULTS/DELETE'
      - 'MICROSOFT.RECOVERYSERVICES/VAULTS/DELETE'
      - 'MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/DELETE'
    resultType: Success
  condition: selection
falsepositives:
  - Legitimate infrastructure teardown via IaC pipelines (Terraform destroy, Bicep deployments) — exclude known pipeline service principals
  - Dev/test subscription cleanup automation
level: high
---
title: Azure Backup or Recovery Services Vault Deletion
id: 3d7e1b92-5a4f-4c8d-9e61-2b8f7c3a5d19
status: experimental
description: Detects deletion of Azure Recovery Services or Backup vaults. Destructive operators commonly remove recovery capability before destroying production resources, as reported in the JadePuffer campaign.
references:
  - https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1490
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName|contains:
      - 'MICROSOFT.RECOVERYSERVICES/VAULTS/DELETE'
      - 'MICROSOFT.RECOVERYSERVICES/VAULTS/BACKUPPOLICIES/DELETE'
      - 'MICROSOFT.DATAPROTECTION/BACKUPVAULTS/DELETE'
  condition: selection
falsepositives:
  - Decommissioning activity during migration projects — validate against change records
level: critical
---
title: New Credentials Added to Azure Service Principal
id: 6b1f4e83-2c9a-4d5b-a738-9e2d6f4b8c31
status: experimental
description: Detects addition of new secrets or certificates to Azure AD service principals, a persistence technique used after initial compromise to survive credential resets, consistent with credential-expansion behavior in the JadePuffer campaign.
references:
  - https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/
  - https://attack.mitre.org/techniques/T1098.001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1098.001
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName:
      - 'Add service principal credentials'
      - 'Add service principal certificate'
      - 'Update application - Certificates and secrets management'
  condition: selection
falsepositives:
  - Legitimate secret rotation by application teams — correlate with change management tickets and known pipeline identities
level: high

KQL — Microsoft Sentinel Hunting

This query identifies the agentic burst pattern: a principal executing an anomalous density of enumeration read operations followed by destructive write operations within a rolling window. Run it as a hunting query first, tune the thresholds to your environment, then promote it to an analytics rule.

KQL — Microsoft Sentinel / Defender

// Hunt: Agentic recon burst followed by destructive Azure control-plane actions
// JadePuffer-style: rapid enumeration -> credential access -> resource destruction
let Lookback = 7d;
let ReconWindow = 1h;
let DestructiveOps = dynamic([
    "MICROSOFT.COMPUTE/VIRTUALMACHINES/DELETE",
    "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE",
    "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE",
    "MICROSOFT.SQL/SERVERS/DATABASES/DELETE",
    "MICROSOFT.KEYVAULT/VAULTS/DELETE",
    "MICROSOFT.RECOVERYSERVICES/VAULTS/DELETE",
    "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/DELETE"
]);
let ReconOps = dynamic([
    "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCES/READ",
    "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/READ",
    "MICROSOFT.COMPUTE/VIRTUALMACHINES/READ",
    "MICROSOFT.STORAGE/STORAGEACCOUNTS/READ",
    "MICROSOFT.KEYVAULT/VAULTS/READ",
    "MICROSOFT.KEYVAULT/VAULTS/SECRETS/READ"
]);
let Destructive =
    AzureActivity
    | where TimeGenerated > ago(Lookback)
    | where OperationNameValue in~ (DestructiveOps)
    | where ActivityStatusValue == "Success"
    | summarize FirstDelete=min(TimeGenerated), DeleteCount=count(),
                DeletedResources=make_list(ResourceId, 25)
      by Caller, CallerIpAddress, SubscriptionId;
let Recon =
    AzureActivity
    | where TimeGenerated > ago(Lookback)
    | where OperationNameValue in~ (ReconOps)
    | summarize ReconCount=count(), FirstRecon=min(TimeGenerated), LastRecon=max(TimeGenerated),
                DistinctOps=dcount(OperationNameValue)
      by Caller, CallerIpAddress, SubscriptionId;
Destructive
| join kind=inner Recon on Caller, SubscriptionId
| where FirstRecon < FirstDelete
| where datetime_diff('minute', FirstDelete, FirstRecon) <= 60
| where ReconCount >= 50   // tune: baseline your normal admin enumeration volume first
| project Caller, CallerIpAddress, SubscriptionId, FirstRecon, ReconCount, DistinctOps,
          FirstDelete, DeleteCount, DeletedResources
| order by FirstDelete asc;

For endpoint-side hunting (token theft precursor — the agent harvesting Azure CLI credentials from a developer workstation), this Defender query catches suspicious processes touching the Azure token cache:

KQL — Microsoft Sentinel / Defender

// Hunt: Non-Azure processes reading the Azure CLI token cache (token theft precursor)
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any ("\\.azure\\", "\\.Azure\\")
| where FileName in~ ("msal_token_cache.json", "accessTokens.json", "azureProfile.json", "msal_token_cache.bin")
| where not(InitiatingProcessFileName has_any ("az", "azps", "pwsh.exe", "powershell.exe", "Code.exe", "msedge.exe", "MsMpEng.exe"))
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FolderPath, FileName, AccountName
| order by TimeGenerated desc;

Velociraptor VQL — Endpoint Hunt for Azure Token Theft

When you suspect a compromised developer or admin endpoint was the intrusion source, hunt fleet-wide for anomalous processes accessing Azure CLI credential material:

VQL — Velociraptor

-- Hunt: Processes accessing Azure CLI token cache files (potential token theft)
-- Deploy as a hunt across developer/admin workstations
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)\\.azure\\\\|msal_token_cache|accessTokens\\.json|keyvault secret|az ad sp|create-for-rbac'
  AND NOT Exe =~ '(?i)\\\\AzureCli\\\\|\\\\PowerShell\\\\|\\\\WindowsAzure\\\\'
ORDER BY CreateTime DESC

VQL — Velociraptor

-- Hunt: Recent modification of Azure credential cache files by unexpected writers
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=['C:/Users/*/.azure/msal_token_cache*', 'C:/Users/*/.azure/accessTokens.json', '/home/*/.azure/msal_token_cache*', '/home/*/.azure/accessTokens.json'])
WHERE Mtime > now() - 86400
ORDER BY Mtime DESC

Hardening & Verification Script

Run this from an authenticated Az PowerShell session with sufficient rights to audit. It surfaces the highest-risk misconfigurations that make destructive campaigns like JadePuffer effective: missing resource locks, disabled Key Vault purge protection, over-privileged role assignments, and stale service principal credentials.

PowerShell

#Requires -Modules Az.Resources, Az.KeyVault, Az.Accounts
# JadePuffer defensive posture audit - Azure tenant hardening verification
# Run with an account holding Reader at tenant root scope + Key Vault Reader where possible

$ErrorActionPreference = 'Continue'
$report = [System.Collections.Generic.List[object]]::new()

function Add-Finding($Category, $Resource, $Issue, $Severity) {
    $report.Add([pscustomobject]@{
        Category = $Category; Resource = $Resource; Issue = $Issue; Severity = $Severity
    })
}

# 1. Identify Owner/Contributor assignments - the blast radius of any single compromised identity
Write-Host "[*] Auditing privileged role assignments..." -ForegroundColor Cyan
$subs = Get-AzSubscription
foreach ($sub in $subs) {
    Set-AzContext -SubscriptionId $sub.Id | Out-Null
    $privileged = Get-AzRoleAssignment | Where-Object {
        $_.RoleDefinitionName -in @('Owner','Contributor','User Access Administrator')
    }
    foreach ($ra in $privileged) {
        Add-Finding 'RBAC' "$($sub.Name): $($ra.DisplayName)" \
            "Holds $($ra.RoleDefinitionName) at scope $($ra.Scope)" 'Review'
    }

    # 2. Check for resource locks on critical resource groups
    Write-Host "[*] Checking resource locks in $($sub.Name)..." -ForegroundColor Cyan
    $rgs = Get-AzResourceGroup
    foreach ($rg in $rgs) {
        $locks = Get-AzResourceLock -ResourceGroupName $rg.ResourceGroupName -ErrorAction SilentlyContinue
        if (-not $locks) {
            Add-Finding 'ResourceLock' $rg.ResourceGroupName \
                'No CanNotDelete lock - resource group fully deletable by any Contributor' 'High'
        }
    }

    # 3. Key Vault purge protection - without it, deleted vaults are permanently unrecoverable
    Write-Host "[*] Checking Key Vault soft-delete/purge protection..." -ForegroundColor Cyan
    $vaults = Get-AzKeyVault -ErrorAction SilentlyContinue
    foreach ($v in $vaults) {
        if (-not $v.EnablePurgeProtection) {
            Add-Finding 'KeyVault' $v.VaultName 'Purge protection DISABLED - vault can be permanently destroyed' 'Critical'
        }
        if (-not $v.EnableSoftDelete) {
            Add-Finding 'KeyVault' $v.VaultName 'Soft delete DISABLED' 'Critical'
        }
    }
}

# 4. Stale / multi-credential service principals - persistence surface
Write-Host "[*] Auditing service principal credentials..." -ForegroundColor Cyan
$sps = Get-AzADServicePrincipal -ErrorAction SilentlyContinue
foreach ($sp in $sps) {
    $creds = Get-AzADAppCredential -ObjectId $sp.Id -ErrorAction SilentlyContinue
    $spCreds = Get-AzADSpCredential -ObjectId $sp.Id -ErrorAction SilentlyContinue
    $all = @($creds) + @($spCreds)
    if ($all.Count -gt 1) {
        Add-Finding 'ServicePrincipal' $sp.DisplayName "$($all.Count) credentials present - validate all are expected" 'Medium'
    }
    foreach ($c in $all) {
        if ($c.StartDateTime -lt (Get-Date).AddDays(-365)) {
            Add-Finding 'ServicePrincipal' $sp.DisplayName 'Credential older than 12 months - rotate' 'Medium'
        }
    }
}

$report | Sort-Object Severity, Category | Format-Table -AutoSize
$report | Export-Csv -Path ".\azure_jadepuffer_posture_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
Write-Host "[+] Audit complete. Findings exported to CSV." -ForegroundColor Green

PowerShell

# Apply CanNotDelete locks to production resource groups (run per subscription)
# Adjust the -ResourceGroupName filter to target production RGs
$productionRGs = Get-AzResourceGroup | Where-Object { $_.ResourceGroupName -like '*prod*' }
foreach ($rg in $productionRGs) {
    New-AzResourceLock -LockName "PreventDeletion-ProdLock" `
        -LockLevel CanNotDelete `
        -ResourceGroupName $rg.ResourceGroupName `
        -LockNotes "Destructive-attack mitigation - requires Owner to remove lock before deletion" `
        -Force
    Write-Host "[+] Lock applied to $($rg.ResourceGroupName)" -ForegroundColor Green
}

# Enable purge protection on all Key Vaults (cannot be disabled once set - this is intentional)
Get-AzKeyVault | ForEach-Object {
    if (-not $_.EnablePurgeProtection) {
        Update-AzKeyVault -VaultName $_.VaultName -ResourceGroupName $_.ResourceGroupName -EnablePurgeProtection
        Write-Host "[+] Purge protection enabled on $($_.VaultName)" -ForegroundColor Green
    }
}

Remediation & Defensive Priorities

There is no patch to deploy — the remediation here is architectural. Prioritize in this order, because it mirrors the attack chain:

1. Kill the initial access path (identity).

Enforce phishing-resistant MFA (FIDO2/passkeys or certificate-based auth) for all accounts with any Azure role assignment. TOTP and push MFA are being bypassed routinely via AiTM phishing kits that feed token theft.
Deploy Conditional Access policies requiring compliant devices and approved client apps for Azure management plane access. Block legacy auth tenant-wide if you have not already.
Enable Continuous Access Evaluation so revoked tokens die in near-real-time rather than living out their full lifetime.

2. Shrink the blast radius (privilege).

Audit every Owner/Contributor assignment. Migrate standing privilege to PIM-eligible assignments with approval and time-bound activation. An agent that steals a PIM-eligible-but-inactive identity gets nothing.
Move to subscription-scoped management groups with deny assignments on destructive operations for non-break-glass identities where feasible.

3. Make destruction hard and reversible (recovery architecture).

Apply CanNotDelete resource locks on every production resource group and on Recovery Services vaults. Locks require an explicit removal step — which generates an auditable, alertable control-plane event that buys you detection time.
Enable soft delete and purge protection on all Key Vaults and Recovery Services vaults. Purge protection is irreversible once enabled — that is a feature, not a bug.
Ensure backups land in a separate tenant or subscription with separate identity boundaries. Backups governed by the same credentials as production are not backups; they are a second copy awaiting the same attacker.
Configure Azure Backup vault immutability and multi-user authorization (MUA) for vault-critical operations — MUA requires a second identity's approval for destructive backup operations, which directly defeats single-credential destruction.

4. See it coming (detection).

Stream Azure Activity Logs, Entra ID sign-in and audit logs, and Defender for Cloud alerts to your SIEM with retention sufficient for IR (minimum 90 days hot). The KQL and Sigma content above is your starting point — baseline your IaC pipeline principals first so they don't drown the signal.
Alert with page-the-on-call severity on: Recovery Services vault deletion, Key Vault purge, resource group deletion outside change windows, and create-for-rbac-equivalent credential creation events.
Enable Microsoft Defender for Cloud (CSPM + workload protection) and Entra ID Protection if licensing permits — both generate detections for anomalous control-plane behavior and token-theft indicators that complement the custom rules above.

5. Rehearse the worst case. Tabletop this specific scenario with your infrastructure team: an identity with Contributor rights begins deleting production resource groups at 02:00 Saturday. Can you revoke sessions tenant-wide in under 15 minutes? Do you know the exact restore order for identity, network, and data? Have you ever actually restored from your cross-tenant backups? If the answer to any of these is no, that is your gap — not a missing detection rule.

If You Suspect Active Compromise

Revoke all sessions for the affected identity immediately: Revoke-AzADUserRefreshToken (or the Entra portal "Revoke sessions" action), then disable the account.
Rotate every credential the identity could have touched — service principal secrets, Key Vault contents, storage account keys, connection strings. Assume enumeration equals exfiltration.
Audit the activity log for the preceding 30 days minimum: new service principals, new credentials on existing apps, changed role assignments, modified NSG rules, and any deletions.
Preserve logs before making sweeping changes — export Activity, Sign-in, and Audit logs to offline storage for forensic analysis.
Engage your IR retainer. Destructive cloud incidents move fast, and the difference between a bad day and an existential one is measured in how quickly containment happens relative to the agent's execution loop.

The uncomfortable truth about agentic attacks is that they punish exactly the things cloud teams have been deferring: standing privilege, flat backup architectures, and control-plane logs nobody reads. JadePuffer is the forcing function. Close those gaps before an agent closes them for you.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub