Microsoft Says an Azure Attack Was "Agentic-Driven." Its Own Evidence Says "Scripted."
Storm-3168 tore through one Azure tenant in 35 minutes of destruction. The mechanism proof in Microsoft's own post is timing correlation, not an AI agent — and the rewrite desks already dropped the hedge.
The claim
On September 25, 2026, Microsoft's threat intelligence team published a post titled "Storm-3168: Agentic-driven cloud attacks using compromised service principals." The headline attributes a destructive Azure incident to an AI agent. The body text is more careful than the title: Microsoft's own evidentiary language is that the observed pattern "strongly indicates automated or scripted execution" — a phrase that describes a script, not an agent.
The coordinated timing, division of labor, and overlapping token usage across the two service principals strongly indicates automated or scripted execution.
Within hours, rewrite coverage dropped even that hedge. Cyberpress.org's headline reads "Storm-3168 Uses Compromised Service Principals to Launch Agentic Attacks on Azure Cloud" — no qualifier, no caveat. The label travels faster than the evidence underneath it. This piece checks what Microsoft actually released against what the "agentic" claim requires, and lines it up against the one report that coined the term for this actor group in the first place: Sysdig's July JADEPUFFER research, which is where "agentic" started meaning something specific.
What Microsoft actually released
One impacted tenant. Two compromised service principals. A timeline built entirely from Azure control-plane telemetry — read/write API calls, token issuance, timestamps. No code, no payload, no prompt, no model output.
The Storm-3168 incident, by Microsoft's own clock
- First service principal begins reconnaissance15 hours 33 minutes of activity, 300+ successful read operations across the tenant.
- Second service principal enumerates assetsVMs and resource groups across two subscriptions mapped in 5 seconds.
- App Service config stores inspectedFollowed by a failed OpenSearch lookup — possibly hunting for exposed secrets.
- Failed ListKey attemptTargeted a storage account that did not exist.
- Destructive sequence begins100+ storage account deletion attempts inside roughly 7 minutes.
- 150+ destructive or credential-collection operationsStorage, SQL, Key Vault, Function App and App Service-plan targets; SQL deletions all failed — but because of an unsupported API version, not a security control.
- 30+ successful ListKeys requestsAgainst surviving storage accounts.
| Released | Not released |
|---|---|
| 3 IP addresses (App Service probing / malicious ARM requests) | Any agent artifact — code, prompt, model output, binary |
| A detections table (Defender XDR / Defender for Cloud alerts) | Confirmed initial-access vector |
| 5 MITRE ATT&CK mappings (T1190, T1078.004, T1526, T1485, T1490) | A ransom note or confirmed data exfiltration |
| Control-plane timing/correlation across two service principals | Independent corroboration that this specific incident used an LLM |
What the gap actually prevents you from concluding
- No confirmed initial-access vector means you can't point defenders at a specific entry point to close — the GitHub-secret lead is plausible, not proven.
- No ransom note and no confirmed exfiltration means the business-impact claim rests on destruction alone, not extortion — a materially different threat model than "agentic ransomware."
- No agent artifact (prompt, model call log, binary) means the "agentic" label in this specific incident rests entirely on timing and coordination inference, not on anything that distinguishes a script from a model.
- Resource locks and storage-level deletion protection blocked "few" of the targeted accounts — most succeeded, so the mitigation story here is partial, not a save.
The independent check: where the "agentic" label actually came from
Microsoft's post links this actor to JADEPUFFER, which Sysdig first documented on July 1, 2026 as "the first documented agentic ransomware operation." That original report is where the term earned its evidentiary weight — and it's worth being fair to it, because its evidence is genuinely different in kind from what Microsoft released in September.
Two reports, two different evidence bars
- Self-narrating payloads: Base64-encoded Python saturated with natural-language commentary explaining why each action is taken, including ROI-style target prioritization
- A 31-second window between a failed admin-login attempt (19:34:36 UTC) and a correctly re-diagnosed, working fix (19:35:18 UTC)
- Comprehension of planted free-text context — an action that only makes sense if the text was read and understood, recurring across sessions weeks apart
- Entry via CVE-2025-3248, an unauthenticated Langflow RCE — a real, named, exploitable vulnerability
- Explicit admission: "we have no visibility into JADEPUFFER's system prompt or agent configuration"
- Coordinated timing and overlapping token usage across two service principals
- Division of labor between a reconnaissance identity and a destructive identity
- Own language: pattern "strongly indicates automated or scripted execution"
- No payload content, no natural-language artifacts, no code shown
- Attribution to JADEPUFFER rests on linking this tenant's pattern to Sysdig's prior work, not on new mechanism evidence inside this incident
The link between the two reports isn't just the actor name — it's a specific bug. Storm-3168's September infrastructure was also observed probing Langflow's code-validation endpoint, /api/v1/validate/code, against App Service targets — though Microsoft states plainly those probed targets "did not overlap with the affected Azure subscriptions," so it isn't the entry point for this incident. It is, however, confirmed as JADEPUFFER's entry point in July: an internet-facing Langflow instance exploited via the same endpoint, tracked in our own index as CVE-2025-3248 — CVSS 9.8, EPSS 99.99th percentile, in CISA's KEV catalog, with two public exploit writeups already available. One 18-month-old unauthenticated-RCE bug is the connective tissue across both reports, whether or not it was used in September.
Disclosure
Both vendors in this story sell products that benefit from the "agentic threat" framing: Microsoft's Defender/MDASH stack and Sysdig's Falco/Sysdig Secure line both market agentic-attack detection. That doesn't make either report's underlying telemetry wrong, but the framing serves a product line on both sides of this comparison — worth holding in mind when a vendor's headline is more confident than its evidence section. This piece was also drafted using LLMs from labs — including Microsoft — that appear in the broader AI-security beat we cover; we carry that disclosure on every ledger-style piece we write about AI-attributed security claims.
Verdict
The falsifier: a payload sample, command log, or model-call trace from this specific September incident showing natural-language reasoning, self-correction, or comprehension of planted context — the same class of artifact Sysdig produced for JADEPUFFER in July. Absent that, "strongly indicates automated or scripted execution" is the most precise sentence in Microsoft's own post, and it belongs in the headline more than "agentic-driven" does.
CVE and KEV data current as of 2026-10-12