As reported by The Hacker News, Microsoft has detailed a destructive Azure campaign attributed to JADEPUFFER (tracked by Microsoft as Storm-3168) that leveraged compromised service principals to systematically delete cloud infrastructure — including Storage Accounts, SQL databases, Key Vaults, and recovery protection locks — over an 18-hour window in early June 2026.

Cloud Security Alert: What stands out in this incident isn't the initial compromise.

What stands out in this incident isn't the initial compromise. It's the operational discipline afterward: two distinct service principals were used for clearly separated roles — one conducting 300+ read operations for reconnaissance over 16 hours, and a second executing destructive writes and credential harvesting 90 minutes later. That's tradecraft consistent with a deliberate, multi-stage cloud-native operation, not a spray-and-pray ransomware deployment.

The Real Story: Destruction Without Extortion

JADEPUFFER first gained notoriety through Sysdig's reporting as the first end-to-end LLM-orchestrated ransomware operation, exploiting CVE-2025-3248 in Langflow and deploying the Go-based ENCFORGE strain against AI infrastructure. But this Azure operation marks a notable divergence from that playbook: there is no mention of encryption or ransom notes in the destructive phase. The attackers deleted resources outright. They targeted recovery protection locks — the exact mechanism designed to prevent exactly this kind of destruction.

This pattern aligns more closely with wiper operations than with financially motivated ransomware. When threat actors remove recovery safeguards before destroying resources, the objective is permanence — ensuring the victim cannot reconstruct their environment. That has strategic-disruption implications that go beyond a single tenant's data loss.

Why Service Principals Are the Soft Underbelly

Service principals are the non-human identities that power automation, CI/CD pipelines, and inter-application trust in Azure. They're also the least-governed identity type in most environments. The JADEPUFFER operation exposes three systemic failures:

  • Over-permissive role assignments: A service principal used for read-only discovery shouldn't also be capable of deleting Key Vaults or removing resource locks. The principle of least privilege is routinely violated for service principals because developers default to Contributor or Owner roles to avoid breakage.
  • No anomaly detection on identity behavior: 300+ read operations over 16 hours from a service principal that normally performs a handful of operations is a glaring signal — but only if someone is watching. Most organizations lack baseline behavioral profiles for their non-human identities.
  • Recovery locks as a false safety net: The attackers specifically deleted recovery protection locks. These locks protect against accidental deletion, but they can be removed by any identity with sufficient RBAC permissions — meaning they don't protect against a compromised privileged principal. This is a critical architectural blind spot.

The most dangerous identity in your Azure environment isn't a compromised user — it's a service principal with Owner-level permissions that nobody has audited in 18 months.

Broader Implications for AI Infrastructure Security

JADEPUFFER's evolution from LLM-driven ransomware to cloud-destructive operations signals that adversaries are refining their approach to AI-adjacent infrastructure. The initial Langflow CVE-2025-3248 exploitation demonstrated that AI tooling with internet-facing exposure is a viable entry point. Now the follow-on Azure operation shows that the downstream blast radius extends well beyond the AI stack itself — into core cloud infrastructure, backups, and recovery mechanisms.

Organizations running AI/ML infrastructure on Azure should assume that a compromise of any exposed AI service (Langflow, Nacos, vector databases, model endpoints) can cascade into full tenant destruction if service principal governance is weak.

Shield53 Recommendations

  • Audit all service principals immediately. Run Get-AzRoleAssignment across all subscriptions and flag any principal with Owner or Contributor at subscription scope. Replace with custom roles scoped to the specific resource group or action set required.
  • Implement conditional access for service principals. Restrict sign-in to specific IP ranges (your build agents, approved automation hosts) and require authentication strength policies where supported.
  • Enable Microsoft Defender for Cloud's threat protection on all resource types — especially Key Vault and SQL — and configure alerting for anomalous bulk read operations, which preceded the destructive phase in this attack.
  • Move recovery protection locks to resource-level deny assignments where possible, or implement a secondary backup strategy (cross-region, cross-tenant, or third-party immutable storage) that doesn't rely on Azure RBAC for protection.
  • Patch CVE-2025-3248 in Langflow and audit all internet-facing AI infrastructure. If you cannot patch, remove the service from internet exposure entirely.
  • Establish behavioral baselines for service principals using Microsoft Sentinel or equivalent SIEM. Alert on read-operation counts exceeding 2x the 30-day rolling average for any non-human identity.
  • Review and rotate all credentials associated with service principals created before June 2026 — especially any that may have been exposed to the Langflow attack surface.