# JadePuffer Storm-3168 Wiped Azure in 7 Min — Audit Now > Source: > Published: 2026-09-28 21:17:21+00:00 JadePuffer’s Storm-3168 campaign wiped an Azure tenant in seven minutes. The entry point was a service principal secret an employee had posted in a public GitHub issue — then edited out. The edit did nothing. GitHub’s edit history preserved the original content. Microsoft’s post-incident finding is worth quoting directly: “Removing or redacting an exposed secret does not invalidate it.” If you have ever put Azure service principal credentials in a public GitHub issue, PR comment, or wiki page and then deleted them, rotate those credentials today. ## What GitHub Edit History Means for Your Credentials Most developers know not to commit secrets to a repo. Far fewer know that editing or deleting GitHub issue content leaves the original visible in the edit history — accessible to anyone with a browser. [Storm-3168 exploited exactly this gap](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/). The victim posted a client ID, client secret, and tenant ID in a public issue, caught the mistake, and edited the issue to remove them. By the time the edit happened, the credentials had already been scraped. This applies beyond issues. PR review comments, release notes, wiki pages, and discussion posts all maintain edit history in GitHub. Any secret that appeared in any of these contexts — at any point — should be treated as compromised, regardless of whether it was subsequently removed. ## How the Attack Unfolded The attacker was patient. Using two compromised service principals, [Storm-3168 spent 15.5 hours mapping the tenant before destroying it](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/). The first principal executed 300-plus enumeration operations across subscriptions, VMs, resource groups, storage accounts, and Key Vaults. The second ran rapid VM and resource group discovery. App Service configurations were enumerated. Then, 70 seconds after that final reconnaissance pass, the destructive phase began. The seven-minute window was not luck. It was the product of 15 hours of preparation. Five parallel deletion tokens executed simultaneous operations across resource types. The first targets were Azure Site Recovery locks and Azure Backup protection locks — removed deliberately, before anything else. Without recovery infrastructure, restoration becomes impossible even when backups physically exist. Storage accounts followed. Key Vaults. Function Apps. App Service Plans. Azure SQL databases survived only because the attacker used an outdated API version that couldn’t issue the delete call — an inadvertent save, not a design choice. ## Why Service Principal Secrets Are the Wrong Tool For Azure-hosted workloads — App Service, Function Apps, VMs, AKS — service principal client secrets are unnecessary. They exist because developers reach for a familiar pattern: generate a credential, store it somewhere, use it to authenticate. The problem is that “store it somewhere” is exactly where it leaks. Environment variables get logged. Config files get committed. GitHub issues get written. And once a static secret is out, it stays out until explicitly rotated. [Managed Identity](https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/service-principal-managed-identity) eliminates this entirely. Azure manages the credential, rotates it automatically, and injects it into the runtime environment. There is nothing to store, nothing to commit, and nothing to leak. For the Azure Python SDK, the migration is often a single line: ``` # Before: static secret in code or environment credential = ClientSecretCredential(tenant_id, client_id, client_secret) # After: managed identity — zero credentials in code credential = DefaultAzureCredential() ``` If your workload runs outside Azure — on-premises, in another cloud — Managed Identity is not an option. Use Workload Identity Federation instead: an external identity provider issues short-lived tokens tied to a specific workload, with no static secret to harvest or rotate. ## Protecting Recovery Infrastructure The lesson that gets less attention than credential hygiene: Storm-3168 targeted recovery locks first. Site Recovery and Backup protection locks were the first resources deleted. An attacker that wipes your storage and leaves your recovery infrastructure intact has left you a chance. An attacker that removes your recovery locks first has not. Place recovery infrastructure in a separate resource group with tighter RBAC. Apply `CanNotDelete` resource locks on backup vaults and recovery vaults independently. Enable Microsoft Defender for Resource Manager to alert on lock removal operations — that is the attack’s first detectable action and your earliest opportunity to respond. ## Three Actions to Take Today **Scan historical repository content.** Run [truffleHog](https://github.com/trufflesecurity/trufflehog) or gitleaks across your repositories — including commit history and GitHub issues, not just the current HEAD. Any public repository that has ever touched Azure configuration is in scope. **Rotate anything that was ever exposed.** If a service principal secret appeared in any public GitHub content at any point — even briefly, even after an edit — treat it as compromised and rotate it now. Do not check whether attackers actually saw it. Assume they did. This is the core lesson from [JadePuffer’s original Langflow campaign](https://byteiota.com/jadepuffer-agentic-ransomware-langflow-developers/) and from Storm-3168: static secrets with a public history have no grace period. **Enable Defender workload protections.** This attack ran for 15 hours before detection. Defender for Storage, Resource Manager, Key Vault, and Databases each provide behavioral coverage for what Storm-3168 did. Bulk ARM deletes combined with lock removal is the attack’s signature — and Defender for Resource Manager can alert on it in real time.