{"id":9600,"date":"2026-09-28T14:22:22","date_gmt":"2026-09-28T14:22:22","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9600"},"modified":"2026-09-28T14:22:22","modified_gmt":"2026-09-28T14:22:22","slug":"autonomous-agents-attack-azure-using-compromised-identities-destroying-resources","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9600","title":{"rendered":"Autonomous agents attack Azure using compromised identities, destroying resources"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Jadepuffer, an autonomous AI attacker first identified in July, has expanded into Azure environments, using compromised digital identities to enumerate resources, delete cloud assets and collect other credentials, according to Microsoft.<\/p>\n

The activity includes \u201cextensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration,\u201d Microsoft said in a blog post about Storm-3168, also known as Jadepuffer. Service principals are unique machine identities given to applications running within Azure.<\/p>\n

\u201cThe destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services,\u201d Microsoft said in the blog post, \u201cStorm-3168: Agentic-driven cloud attacks using compromised service principals<\/a>.\u201d<\/p>\n

The campaign was first reported in July<\/a> by Sysdig, which described Jadepuffer as an AI-driven operation capable of executing attack steps autonomously, including exploitation, credential access and destructive activity.<\/p>\n

Two identities, split roles<\/h2>\n

Microsoft said it observed two compromised service principals in the same tenant, with one performing reconnaissance and the other carrying out discovery, destructive actions and credential collection.<\/p>\n

One of the identities spent more than 15 hours enumerating virtual machines, subscriptions, resource groups and other resources, making more than 300 successful read operations, the company said.<\/p>\n

A second service principal enumerated resources across multiple subscriptions within seconds and later conducted additional discovery, Microsoft said.<\/p>\n

The timing and division of activity \u201cstrongly indicates automated or scripted execution,\u201d the company said.<\/p>\n

Nick Tausek, lead security automation architect at Swimlane, said the pattern aligns with earlier observations of the campaign\u2019s behavior.<\/p>\n

\u201cJadepuffer\u2019s earlier database attack showed an AI agent working through an extortion playbook and adjusting when steps failed,\u201d Tausek said. \u201cMicrosoft now traces the group into Azure, where compromised service principals mapped resources before a seven-minute burst of destruction.\u201d<\/p>\n

Destructive sequence lasted minutes<\/h2>\n

After the two agents had completed their reconnaissance they began to create mayhem, conducting more than 150 destructive or credential-related operations over about 35 minutes.<\/p>\n

The main destructive sequence lasted about seven minutes and included more than 100 attempts to delete storage accounts, most of which were successful, the blog post said.<\/p>\n

The attackers also deleted an Azure Key Vault, Function App and App Service plan tied to the same resource group, Microsoft said.<\/p>\n

Attempts were also made to delete Azure SQL databases and backup-related protections, including Azure Site Recovery locks and backup protection locks, the company said.<\/p>\n

Tausek said the speed and coordination of the activity could challenge traditional response models.<\/p>\n

\u201cAt that speed, an AI SOC needs to connect identity activity with cloud changes before the damage spreads,\u201d he said.<\/p>\n

Credential access followed destruction<\/h2>\n

About 30 minutes after the destructive activity, the same service principal requested storage account access keys, making more than 30 successful ListKeys requests, Microsoft said.<\/p>\n

The requests included storage accounts associated with recovery services, the blog post said.<\/p>\n

Microsoft said the combination of resource deletion, attempts to interfere with recovery mechanisms and credential collection is \u201cconsistent with tactics that can support ransomware and extortion operations.\u201d<\/p>\n

The company said it did not observe a ransom note or confirm data exfiltration in the activity.<\/p>\n

Ross Filipek, CISO at Corsica Technologies, said the sequence of destruction followed by credential access raises additional response challenges.<\/p>\n

\u201cThe recovery question here goes beyond rebuilding what was deleted,\u201d Filipek said. \u201cThe attackers later requested storage account keys, potentially giving them another route to data.\u201d<\/p>\n

\u201cResponders need to establish which identities and keys were touched, then review their use before trusting restored services,\u201d he said.<\/p>\n

Possible credential exposure<\/h2>\n

Microsoft said it could not confirm the initial access vector but found that credentials associated with a compromised service principal had previously been exposed in plaintext in a public GitHub issue.<\/p>\n

The secret was later removed but remained accessible in the edit history, the company said.<\/p>\n

\u201cPublicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure,\u201d Microsoft said.<\/p>\n

Filipek said the finding highlights a common risk in cloud environments.<\/p>\n

\u201cA cloud credential remained visible in a GitHub issue\u2019s edit history after someone removed it from the post,\u201d he said. \u201cFor an IT team, it\u2019s a useful warning about how a routine cleanup can leave an account exposed.\u201d<\/p>\n

\u201cOnce attackers hold an application identity, their activity can look like ordinary cloud administration,\u201d he said.<\/p>\n

Focus on automation and scale<\/h2>\n

Microsoft said \u00a0the activity reflects \u201ca broader shift toward AI-orchestrated attacks,\u201d where threat actors can coordinate operations across cloud environments with \u201cgreater speed and scale.\u201d<\/p>\n

Tausek said the Azure activity shows coordinated execution, though not necessarily proof that each step was directed by AI.<\/p>\n

\u201cI agree with Microsoft\u2019s warning about AI-orchestrated attacks, though the Azure evidence shows coordinated automation rather than proving AI directed each step,\u201d he said.<\/p>\n

\u201cAgentic AI can help analysts piece together that sequence and prepare containment while people approve the consequential actions,\u201d he added.<\/p>\n

Identity and recovery controls in focus<\/h2>\n

Microsoft recommended that organizations protect workload identities, enforce least-privilege access and secure backup and recovery resources to reduce risk from similar activity.<\/p>\n

Tausek said organizations can reduce exposure by rotating exposed secrets, limiting service principal permissions and protecting backup systems before attackers gain access.<\/p>\n

Filipek said response planning across teams is also critical.<\/p>\n

\u201cThat takes coordination between development, cloud operations and incident response,\u201d he said. \u201cIf those teams wait until an outage to work out who owns the credentials, they\u2019ll lose valuable time.\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Jadepuffer, an autonomous AI attacker first identified in July, has expanded into Azure environments, using compromised digital identities to enumerate resources, delete cloud assets and collect other credentials, according to Microsoft. The activity includes \u201cextensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration,\u201d […]<\/p>\n","protected":false},"author":0,"featured_media":9601,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9600","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9600"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9600"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9600\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9601"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9600"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9600"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9600"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}