As reported by SecurityAffairs, Microsoft's detailed analysis of Storm-3168 — the threat actor also tracked as JADEPUFFER by Sysdig — reveals something that should unsettle every cloud security team: once attackers hold valid service principal credentials, the window between infiltration and destruction can be measured in seconds, not days.

Ransomware Alert: As reported by SecurityAffairs, Microsoft's detailed analysis of Storm-3168 — the threat actor also tracked as JADEPUFFER by Sysdig — reveals something that should unsettle every cloud security team: once attackers hold valid service principal credentials, the window between infiltration and destruction can be measured in seconds, not days.

The operational tempo described in this report is what makes it genuinely alarming. The second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. The destructive phase — deleting over 100 storage accounts, a Key Vault, a Function App, and an App Service — ran approximately seven minutes. Traditional ransomware playbooks that involve lateral movement, privilege escalation, and staging simply don't apply when the attacker already holds a non-human identity with broad permissions in a cloud control plane.

Why Non-Human Identities Are the Soft Underbelly

Service principals and managed identities are the connective tissue of modern cloud environments. Applications, CI/CD pipelines, automation tools, and integrations all rely on them. Yet they are routinely over-privileged, rarely rotated, and almost never monitored with the same rigor applied to human accounts. Storm-3168's abuse of two service principals from a single tenant — one dedicated to reconnaissance, the other to destruction and credential harvesting — illustrates exactly how attackers exploit this gap.

The reconnaissance phase lasted roughly 15.5 hours and involved over 300 read operations. That's a detectable signal, but only if someone is watching. The attacker was mapping the tenant's topology, identifying high-value resources, and confirming the permissions available to the stolen identity. Once the second identity began its work, the pace shifted from methodical to breakneck.

The entire destructive campaign — from final inventory operation to deletion of 100+ storage accounts — was complete in under 40 minutes. That's faster than most security teams' mean time to acknowledge an alert.

The 'Agentic Ransomware' Designation Matters

Sysdig's classification of JADEPUFFER as the first documented agentic ransomware operation deserves attention. This isn't a human operator clicking through an Azure portal. The attacker used scripted, automated operations via python-requests/2.34.2, with a clear division of labor between two compromised identities. The scripting is purpose-built for speed — enumerate, harvest credentials, destroy, repeat. This is ransomware logic applied to cloud infrastructure destruction, and it represents an evolution that defenders need to account for.

Notably, the attacker also probed Azure App Service configuration stores, likely hunting for exposed credentials that could enable further lateral movement or persistence. The failed attempt to retrieve keys from a non-existent storage account suggests the script was operating on assumptions or prior reconnaissance data — an interesting indicator that the operation may have been partially templated rather than fully dynamic.

Who Is Most at Risk

  • Organizations with over-privileged service principals — Contributor or Owner-level permissions on subscriptions create a single point of catastrophic failure
  • Environments without Azure Monitor or SIEM integration — the 15-hour reconnaissance window was a detection opportunity that requires active monitoring to exploit
  • Multi-subscription Azure tenants — Storm-3168's enumeration spanned multiple subscriptions, meaning a single compromised identity can have blast radius across an entire organizational boundary
  • Teams storing credentials in App Service configuration — the attacker's deliberate hunt for these stores indicates they're a known high-value target

Shield53 Recommendations

Shield53 Recommendations
Audit all service principals immediately. Enumerate every non-human identity in your Azure tenant. Identify which have Contributor, Owner, or storage account-level permissions. Remove unused principals and reduce permissions to least privilege.
Implement detection rules for anomalous service principal activity. Flag rapid bursts of read operations (300+ in under 24 hours), ListKey operations on storage accounts, and bulk deletion attempts. Azure Activity Log + Microsoft Sentinel (or equivalent SIEM) should alert on these patterns in real time.
Enable Azure AD Conditional Access for service principals. Restrict service principal authentication to expected IP ranges, locations, or resource contexts. Block authentication from unexpected infrastructure.
Rotate service principal secrets and certificates. If your organization hasn't rotated credentials for service principals in the last 90 days, treat this as a priority. Implement automated rotation where possible.
Deploy resource-level deletion protections. Enable Azure Resource Manager locks on critical storage accounts and Key Vaults. Configure soft delete and blob versioning on storage accounts to enable rapid recovery.
Hunt for the user agent string python-requests/2.34.2 in your Azure sign-in and activity logs. While not inherently malicious, its presence in service principal authentication events warrants investigation.
Review App Service configuration for exposed credentials. Storm-3168 specifically targeted these. Move secrets to Key Vault references and ensure no plaintext credentials remain in app settings.

The broader implication is clear: cloud ransomware is evolving from encryption-based extortion to infrastructure destruction as a pressure tactic. When attackers can wipe 100 storage accounts in seven minutes using valid credentials, the perimeter is irrelevant — identity governance is the security program.