--- title: JadePuffer's automated Azure attacks: what happened and... description: Microsoft Security Research detailed two June attacks by ransomware operator JadePuffer (Storm-3168) against Azure environments, using compromised service... canonical: https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: JadePuffer's automated Azure attacks: what happened and what stopped them | daily.dev og:description: Microsoft Security Research detailed two June attacks by ransomware operator JadePuffer (Storm-3168) against Azure environments, using compromised service... og:url: https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe og:image: https://api.daily.dev/og/posts/yEWFfHUWE.png og:image:alt: JadePuffer's automated Azure attacks: what happened and what stopped them og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # JadePuffer's automated Azure attacks: what happened and what stopped them **[Collections](https://daily.dev/sources/collections)** · 2 min read · 0 upvotes · 0 comments ## Summary Microsoft Security Research detailed two June attacks by ransomware operator JadePuffer (Storm-3168) against Azure environments, using compromised service principals to enumerate resources and then executing a roughly seven-minute destructive burst that deleted over 100 storage accounts and targeted Key Vaults, Function Apps, VMs, App Services, and Site Recovery backup locks. Some destruction attempts failed due to resource locks or an unsupported API version. About 30 minutes later, the attacker requested storage access keys, suggesting a possible follow-on data access phase. Initial access vector is unconfirmed, but credentials from at least one compromised service principal were found exposed in a public GitHub issue, including in its edit history. Microsoft recommends rotating exposed secrets, enabling cloud workload protections, enforcing least-privilege RBAC, applying resource locks, and auditing backup configurations. ## Content Microsoft Security Research documented two attacks in June by JadePuffer, a ransomware operator tracked internally as Storm-3168 and first identified by Sysdig in July. The attacker used compromised Azure service principals to enumerate resources across subscriptions, then launched a destructive burst lasting roughly seven minutes. During that window, the attacker deleted over 100 Azure Storage accounts and made attempts against Key Vaults, Function Apps, Virtual Machines, and App Services. Some storage accounts survived because Azure resource locks were in place. The attacker also tried to remove Azure Site Recovery backup locks to block restoration, though attempts to delete Azure SQL databases and strip recovery locks failed due to an unsupported API version. About 30 minutes after the destructive phase, the same compromised identity requested storage account access keys, which suggests the attacker may have been positioning for data access in a follow-on operation. Microsoft couldn't confirm the initial access vector, but found that credentials tied to at least one compromised service principal had been exposed in plaintext in a public GitHub issue. The credentials remained visible in the edit history even after someone removed them from the post itself. The speed and coordination across the seven-minute burst point to automated or scripted execution rather than a human working manually through a console. ## What Microsoft recommends - Rotate any exposed secrets immediately, including checking edit histories on public repositories - Enable cloud workload protections and scan for leaked credentials - Enforce least-privilege RBAC so compromised service principals can't reach unrelated subscriptions - Apply resource locks to storage accounts and backup resources to slow destructive operations - Audit backup and recovery configurations regularly, since attackers specifically targeted Site Recovery locks ## Questions this post answers ### How did the JadePuffer ransomware attack on Azure actually happen? Attackers using a compromised Azure service principal enumerated resources across subscriptions, then ran a roughly seven-minute automated destructive burst that deleted over 100 Azure Storage accounts and attempted to hit Key Vaults, Function Apps, Virtual Machines, App Services, and Site Recovery backup locks. Some storage accounts survived because resource locks blocked deletion, and attempts against Azure SQL databases failed due to an unsupported API version. _Teams hardening Azure against automated ransomware bursts follow incident breakdowns like this on daily.dev._ ### How were the credentials used in the JadePuffer Azure attack compromised? Microsoft could not confirm the exact initial access vector, but credentials tied to at least one compromised service principal were found exposed in plaintext in a public GitHub issue. Notably, the credentials remained visible in the post's edit history even after someone removed them from the visible text, meaning simple deletion did not fully remediate the leak. _Anyone auditing repos for leaked secrets keeps up with cases like this on daily.dev._ ### How can I protect Azure storage accounts from mass deletion during a ransomware attack? Apply Azure resource locks to storage accounts and backup resources, since locks specifically slowed the JadePuffer attack and let some storage accounts survive a destructive burst that deleted over 100 others. Also enforce least-privilege RBAC so a compromised service principal cannot reach unrelated subscriptions, and regularly audit backup and Site Recovery configurations since attackers targeted recovery locks directly. _Engineers locking down Azure backups against destructive attacks track defenses like these on daily.dev._ ## Similar posts on daily.dev - [JadePuffer crims hijacked Azure identities and used them to blow up cloud resources](https://daily.dev/posts/jadepuffer-crims-hijacked-azure-identities-and-used-them-to-blow-up-cloud-resources-cb71k5ngf) · The Register · 0 upvotes · 0 comments - [Microsoft Self-Service Password Reset abused in Azure data theft attacks](https://daily.dev/posts/microsoft-self-service-password-reset-abused-in-azure-data-theft-attacks-wzksyvp0l) · BleepingComputer · 0 upvotes · 0 comments - [JadePuffer Signals a New Era of AI-Driven Ransomware](https://daily.dev/posts/jadepuffer-signals-a-new-era-of-ai-driven-ransomware-rvacyt3ln) · Security Boulevard · 0 upvotes · 0 comments - [JadePuffer: The First Successful LLM-Driven Ransomware Attack](https://daily.dev/posts/jadepuffer-the-first-successful-llm-driven-ransomware-attack-ttpa7zod8) · Dark Reading · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#azure](https://daily.dev/tags/azure), [#ransomware](https://daily.dev/tags/ransomware) [View this post on daily.dev](https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"JadePuffer's automated Azure attacks: what happened and what stopped them","url":"https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe"},"datePublished":"2026-09-28T16:56:45.963Z","dateModified":"2026-09-28T16:57:26.880Z","description":"Microsoft Security Research detailed two June attacks by ransomware operator JadePuffer (Storm-3168) against Azure environments, using compromised service...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6b7eaae8324f175fccdbe6c07d7683b5?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6b7eaae8324f175fccdbe6c07d7683b5?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,azure,ransomware","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"JadePuffer's automated Azure attacks: what happened and what stopped them"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/jadepuffer-s-automated-azure-attacks-what-happened-and-what-stopped-them-yewffhuwe#faq","mainEntity":[{"@type":"Question","name":"How did the JadePuffer ransomware attack on Azure actually happen?","acceptedAnswer":{"@type":"Answer","text":"Attackers using a compromised Azure service principal enumerated resources across subscriptions, then ran a roughly seven-minute automated destructive burst that deleted over 100 Azure Storage accounts and attempted to hit Key Vaults, Function Apps, Virtual Machines, App Services, and Site Recovery backup locks. Some storage accounts survived because resource locks blocked deletion, and attempts against Azure SQL databases failed due to an unsupported API version. Teams hardening Azure against automated ransomware bursts follow incident breakdowns like this on daily.dev."}},{"@type":"Question","name":"How were the credentials used in the JadePuffer Azure attack compromised?","acceptedAnswer":{"@type":"Answer","text":"Microsoft could not confirm the exact initial access vector, but credentials tied to at least one compromised service principal were found exposed in plaintext in a public GitHub issue. Notably, the credentials remained visible in the post's edit history even after someone removed them from the visible text, meaning simple deletion did not fully remediate the leak. Anyone auditing repos for leaked secrets keeps up with cases like this on daily.dev."}},{"@type":"Question","name":"How can I protect Azure storage accounts from mass deletion during a ransomware attack?","acceptedAnswer":{"@type":"Answer","text":"Apply Azure resource locks to storage accounts and backup resources, since locks specifically slowed the JadePuffer attack and let some storage accounts survive a destructive burst that deleted over 100 others. Also enforce least-privilege RBAC so a compromised service principal cannot reach unrelated subscriptions, and regularly audit backup and Site Recovery configurations since attackers targeted recovery locks directly. Engineers locking down Azure backups against destructive attacks track defenses like these on daily.dev."}}]} ```