Published: 2026-09-29
Categories: Agentic AI Security
Key Takeaways
Microsoft’s September 25, 2026 disclosure of Storm-3168, its designation for the threat actor known publicly as JADEPUFFER, provides the first detailed view into how an actor already documented as running an end-to-end autonomous AI attack is now applying that same operational model to enterprise cloud infrastructure [1]. Using two compromised Azure service principals from the same tenant, the actor mapped a victim’s environment in a single continuous 15-hour-30-minute reconnaissance pass and then executed more than 150 destructive and credential-collection operations in roughly 35 minutes, including over 100 storage account deletion attempts compressed into a 7-minute window [1]. That tempo is consistent with the actor’s earlier, independently confirmed campaign: in July 2026, Sysdig researchers documented JADEPUFFER running a full extortion playbook against a production database with no human operator in the loop, an agent that diagnosed and corrected a failed login in 31 seconds without any person directing the tactical execution, though as later reporting cautioned, a human had still selected the target and configured the campaign infrastructure beforehand [2][5]. The Azure intrusion began not with a novel exploit but with an old and familiar mistake, a service principal’s client ID, secret, and tenant ID that an employee published in a public GitHub issue and later deleted, credentials that remained retrievable through the platform’s edit history long after the post was removed [1]. Despite the speed and scale of the destructive phase, most storage account deletion attempts still succeeded, yet the accounts and recovery infrastructure that carried Azure resource locks or backup protection locks survived even under full identity compromise, demonstrating that conventional cloud hardening controls retain real value against machine-speed adversaries even as they leave unprotected resources exposed [1]. For security teams, the incident reinforces a shift already underway in CSA’s agentic AI research: the non-human identities that connect automated tooling to cloud resources, not any single software vulnerability, are becoming the primary lever this campaign shows an AI-driven attacker using to convert one exposed credential into infrastructure-wide damage within minutes [1].
Background
JADEPUFFER entered the public record in July 2026, when the Sysdig Threat Research Team disclosed what it assessed to be the first fully documented case of agentic ransomware: an intrusion in which a large language model agent, rather than a human operator following a scripted playbook, carried out the entire attack lifecycle against an internet-facing target [2]. The actor gained initial access through CVE-2025-3248, a remote code execution flaw in Langflow, an open-source visual framework for building AI workflows, and from there autonomously performed reconnaissance, harvested credentials across multiple cloud and AI service providers, pivoted into a production database through a second vulnerability, encrypted configuration data, deleted database tables, and left a ransom note, all without a human directing each step [2][3]. Independent reporting on that campaign noted a detail that has since become emblematic of the actor’s capability: when the agent’s first login attempt failed, it analyzed the error, corrected its approach, and regained access in 31 seconds [2]. Some coverage at the time cautioned against overstating the agent’s autonomy, noting that a human operator had still configured the campaign and selected the target even if the tactical execution ran unattended [5].
Microsoft’s September 2026 disclosure, tracking the same actor as Storm-3168, extends that record into a domain Sysdig’s original report did not cover: destructive operations against a live Microsoft Azure tenant [1]. Microsoft’s investigation found that, since early 2026, Storm-3168 had been probing internet-facing Azure App Services, scanning for WordPress administration paths, PHP-CGI endpoints, and Langflow’s code-validation endpoint, a pattern consistent with an actor that treats AI-development infrastructure as a preferred entry point rather than an afterthought [1]. Microsoft was not able to confirm the specific initial-access vector for the Azure intrusion it analyzed, but it did establish that the compromised service principal’s credentials had been exposed in plaintext in a public GitHub issue by an employee of the victim organization; the post was later edited to remove the secrets, but the platform’s edit history preserved the original content indefinitely [1]. This research note examines what the Azure campaign shows about how agentic tooling compresses cloud attack timelines, what defensive controls proved effective even under compromise, and how the incident should inform enterprise identity and cloud-hardening priorities going into the fourth quarter of 2026.
Security Analysis
A division of labor between two service principals
Microsoft’s telemetry shows that in early June 2026, Storm-3168 operated two distinct compromised service principals within the same Azure tenant, and that the two identities performed complementary rather than duplicate work [1]. The first spent 15 hours and 30 minutes conducting sustained discovery, issuing more than 300 successful read operations against virtual machines, subscriptions, resource groups, and other resources across the tenant. Ninety minutes after that reconnaissance began, a second service principal executed a comparable enumeration sweep across two subscriptions in just five seconds, a difference in tempo that points toward a targeted, pre-scoped query rather than the kind of broad exploratory scan the first identity ran. Both principals shared the same network fingerprint and the same user agent string, python-requests/2.34.2, indicating a common underlying toolchain even though the two identities were assigned different roles in the operation [1]. Sixteen hours after the first enumeration sweep, the second service principal returned to inventory App Service configuration stores and attempted, unsuccessfully, to discover an Azure OpenSearch deployment, extending the reconnaissance window well beyond what, in this note’s assessment, a single opportunistic script typically performs, and more consistent with a sustained, directed operation.
From reconnaissance to destruction in under a second
The clearest evidence of machine-speed execution in Microsoft’s account is the transition between reconnaissance and destruction. Seventy seconds before the destructive phase began, the second service principal attempted a ListKey operation against a storage account that did not exist and failed. Less than one second after that failed call, the same identity began its destructive activity, a gap far too short to reflect a human operator reviewing output and deciding on next steps [1]. Over the following 35 minutes, Storm-3168 executed more than 150 destructive and credential-collection operations, with the most damaging 100-plus storage account deletion attempts compressed into a single 7-minute window. Most of those deletions succeeded; a subset were blocked because the target accounts carried resource locks. In the same window, the actor successfully deleted Azure Key Vaults, Function Apps, and the App Service plan supporting them, while parallel attempts to delete Azure SQL databases failed uniformly because the requests used an unsupported API version rather than because of any defensive control. Attempts to remove Azure Site Recovery locks and Azure Backup protection locks, the specific mechanisms that would have let the actor also destroy the victim’s recovery path, were unsuccessful [1]. Roughly 30 minutes after the destructive phase ended, the actor pivoted to credential collection, issuing an inventory request for storage accounts and completing more than 30 successful ListKeys calls that retrieved storage account access keys, with particular attention to storage accounts associated with Azure Site Recovery.
Objectives without a ransom note
Microsoft found no ransom note and no confirmed evidence of data exfiltration in the Azure intrusion it analyzed, which distinguishes this campaign from JADEPUFFER’s July 2026 database-extortion operation that concluded with an explicit ransom demand [1][2]. The combination of infrastructure destruction, targeted attempts against backup and recovery locks, and post-destruction credential harvesting nonetheless aligns with a ransomware and extortion playbook, whether the missing extortion step reflects an interrupted operation, a variant campaign objective, or simply a phase Microsoft’s visibility did not capture. The mapped MITRE ATT&CK techniques, exploitation of a public-facing application, use of valid cloud accounts, cloud service discovery, data destruction, and inhibited system recovery, describe a conventional ransomware kill chain; what differs from prior ransomware operations is not the objective but the speed at which an actor with agentic tooling moved through it [1]. Security researchers reviewing the disclosure have urged some caution on attribution of tactical decisions to an AI system specifically: Nick Tausek of Swimlane noted that while JADEPUFFER’s earlier database campaign showed an agent working through an extortion playbook and adjusting when steps failed, the Azure activity on its own demonstrates coordinated automation rather than proof that an AI model directed every individual action [4]. That distinction does not change the defensive picture, since the timing evidence in Microsoft’s telemetry is consistent with automated execution regardless of whether every decision point involved live model inference, but it is a useful check against overstating what any single disclosure confirms about the tooling behind it.
What held, and why it matters
The most consequential defensive finding in Microsoft’s disclosure may be the negative result: despite holding service principal permissions that included Storage Account Contributor, direct Contributor, and SQL DB Contributor roles, Storm-3168’s compromised identities could not delete resources protected by Azure resource locks, and its attempts against backup protection locks failed outright; its parallel attempts against Azure SQL databases failed for an unrelated technical reason, an unsupported API version, rather than because of a defensive control [1]. That outcome matters because it shows that identity-layer compromise, even when paired with automated, machine-speed execution, does not automatically defeat resource-level protections configured independently of the identity that is attacking them. In an incident defined by the erosion of the human-response window, from a 15-hour reconnaissance phase down to a sub-second pivot into destruction, the controls that did not depend on a human noticing and reacting in real time were the ones that functioned as designed, even though, as the preceding section shows, they protected only a subset of the resources the actor targeted.
Recommendations
Immediate Actions
Organizations should treat any service principal credential, storage key, connection string, or other secret that has ever appeared in a public repository, issue, pull request, or comment as compromised the moment it is discovered there, regardless of whether the post was later edited or deleted, since platform edit histories, caches, and archives routinely preserve the original content [1]. Credential scanning should extend beyond current repository contents to include issue and pull request history, and any credential surfaced by that scan should be rotated immediately rather than simply removed from view. Security teams should also confirm that resource locks and backup protection locks are applied to production storage accounts, Key Vaults, and recovery infrastructure now, since Storm-3168’s Azure campaign demonstrated these controls actively blocked destruction attempts even under full identity compromise [1].
Short-Term Mitigations
Service principal permissions should be reviewed against actual task requirements rather than convenience, with particular attention to any identity holding Contributor-level access across storage, SQL, and compute resource types simultaneously, since that breadth is precisely what let a single compromised credential pair reach across the full Azure resource inventory in one operation [1]. Enabling Microsoft Defender for Cloud plans across Resource Manager, Storage, Key Vault, App Service, and Databases gives defenders visibility into the same anomalous API call sequences, discovery-to-destruction transitions in seconds rather than hours, that Microsoft used to reconstruct this campaign after the fact [1]. Organizations running internet-facing AI development infrastructure, including Langflow and similar visual workflow tools, should confirm those instances are patched and not exposed without authentication, given Storm-3168’s documented pattern of probing AI-adjacent endpoints as an entry vector [1][3].
Strategic Considerations
The gap between the 15-hour reconnaissance phase and the sub-second pivot into destruction is, in this note’s assessment, the central strategic concern of this incident, and it argues for investing in detection and automated response capable of operating on that timescale rather than assuming a human analyst will interrupt an attack mid-sequence. Microsoft’s own guidance points toward agentic defense as the intended countermeasure to agentic offense, recommending its Project Perception capability for AI-driven investigation across large environments and Microsoft Defender for AI Security for discovering vulnerabilities in AI assets before an actor like Storm-3168 finds them first, a set of recommendations worth weighing alongside vendor-neutral control frameworks such as CSA’s AICM given that they originate from the same vendor disclosing the incident [1]. Longer term, enterprises should treat non-human identities, service principals, workload identities, and the credentials that back them as the primary security boundary in cloud environments increasingly operated on by autonomous tooling, since this incident, like JADEPUFFER’s July 2026 database campaign before it, succeeded because of an exposed identity rather than a novel technical exploit [1][2]. Incident responders should also plan for a recovery process that extends past rebuilding deleted resources: as Ross Filipek of Corsica Technologies observed regarding this campaign, the recovery question goes beyond restoring what was destroyed, since responders must also establish which identities and keys the actor touched and review how each was subsequently used [4].
CSA Resource Alignment
This incident is a direct continuation of a campaign CSA has already analyzed. The July 2026 research note “JADEPUFFER: The First Fully Autonomous Ransomware Agent” examined the same actor’s Langflow-based database extortion operation in detail, including the self-correcting login behavior that first established JADEPUFFER as agentic rather than scripted, and this Azure campaign should be read as the sequel to that finding rather than a separate incident [6]. CSA’s May 2026 note “LLM-Orchestrated Kill Chains: From CVE to Database Breach in Four Pivots,” anchored in the GTG-1002 disclosure, documented the same operational-tempo shift this note describes, CVEs weaponized within hours and multi-stage intrusions executed without a human between pivots, and the Storm-3168 Azure timeline, a sub-second gap between failed reconnaissance and the start of mass destruction, extends that pattern from espionage into destructive ransomware [7]. Because the compromise vector here was a service principal rather than a stolen password or exploited application, CSA’s “Agentic AI Identity and Access Management: A New Approach” is directly applicable: its argument that static, broadly scoped non-human credentials are structurally mismatched to autonomous, machine-speed operations describes exactly the failure mode that let two service principals reach a tenant’s entire storage, Key Vault, and SQL inventory from a single leaked secret [8]. Finally, the AI Controls Matrix (AICM) v1.1 supplies the control objectives, spanning identity and access management, secrets and credential lifecycle management, and business continuity and disaster recovery, that translate this note’s recommendations into auditable requirements, particularly the controls governing resource-level protection independent of identity, which is precisely what limited the damage in this campaign even after both service principals were fully compromised [9].
References
[1] Microsoft Threat Intelligence. “Storm-3168: Agentic-driven cloud attacks using compromised service principals.” Microsoft Security Blog, September 25, 2026.
[2] Sysdig Threat Research Team. “JADEPUFFER: Agentic Ransomware for Automated Database Extortion.” Sysdig Blog, July 1, 2026.
[3] The Hacker News. “AI Agent Exploits Langflow RCE to Automate Database Ransomware Attack.” The Hacker News, July 2026.
[4] CSO Online. “Autonomous agents attack Azure using compromised identities, destroying resources.” CSO Online, September 2026.
[5] TechCrunch. “The ‘first’ AI-run ransomware attack still needed a human.” TechCrunch, July 6, 2026.
[6] Cloud Security Alliance. “JADEPUFFER: The First Fully Autonomous Ransomware Agent.” CSA AI Safety Initiative, July 3, 2026.
[7] Cloud Security Alliance. “LLM-Orchestrated Kill Chains: From CVE to Database Breach in Four Pivots.” CSA AI Safety Initiative, May 27, 2026.
[8] Cloud Security Alliance. “Agentic AI Identity and Access Management: A New Approach.” Cloud Security Alliance, August 18, 2025.
[9] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, June 22, 2026.