What Storm-3168 Proves—and What It Does Not: Azure Permissions Powered a Seven-Minute Destruction Burst

Storm-3168: compromised service principal, existing Azure roles, and independent deletion safeguards — Cover: A compromised workload identity can reach resources through existing roles. An independent safeguard can block a covered operation. Original conceptual artwork: Tech Trend Insight. Primary source.

Microsoft’s September 25, 2026 Storm-3168 disclosure documents a fast, coordinated Azure intrusion built on compromised service principals and permissions the tenant had already granted. The strongest conclusion supported by the published telemetry is that the operation was automated or scripted. The report does not present the model traces, prompts, agent configuration, or self-narrating payloads needed to establish that a large language model selected the Azure actions. Microsoft Security Research’s report therefore supports an identity-and-authorization finding more strongly than an AI-attribution finding.

Microsoft links Storm-3168 to JADEPUFFER and frames the broader campaign as AI-orchestrated. The narrower distinction here is between that attribution and what the published Azure records independently demonstrate.

The immediate engineering lesson is concrete: a workload identity that can inventory production resources, delete them, or retrieve storage keys remains dangerous regardless of whether the operator is a script, an AI agent, or a human using automation.

The evidence boundary

Confirmed by Microsoft: Two compromised service principals divided reconnaissance, destruction, and credential collection. Timing, parallel activity, and overlapping token streams strongly indicated automated or scripted execution.
Attributed separately: Sysdig assessed an earlier JADEPUFFER database-extortion incident as an end-to-end LLM-driven operation. That assessment concerned a different Langflow and database environment, not Microsoft’s Azure telemetry.
Inferred: Automation amplified permissions already assigned to the compromised identities. This conclusion follows from Microsoft’s mapping of the observed operations to existing Azure role assignments.
Open: Microsoft did not determine the initial-access path, confirm that a publicly exposed GitHub secret was used, confirm data exfiltration, or observe a ransom note.
Proposed, not measured: Defensive validation exercises described later in this article have not been performed by Tech Trend Insight.

Two identities split the work

Microsoft observed the activity in one impacted tenant in early June 2026. The first compromised service principal conducted broad discovery for about 15 hours and 30 minutes, completing more than 300 successful read operations against virtual machines, subscriptions, resource groups, and resources.

About 90 minutes after that enumeration began, the second principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both identities used Storm-3168-linked infrastructure, the same network fingerprint, and the python-requests/2.34.2 user agent. About 16 hours later, the second identity enumerated App Service configuration stores and unsuccessfully looked for Azure OpenSearch resources.

Seventy seconds after its final inventory operation, that principal unsuccessfully requested a key for a nonexistent storage account. Destructive activity began less than one second later.

Observed stage	Microsoft-reported activity	Evidence limit
Extended discovery	300+ successful reads over about 15 hours 30 minutes	One tenant’s incident telemetry, not a mapping-speed benchmark
Rapid second-identity discovery	Two subscriptions enumerated in five seconds	Shows compressed execution, not why each action was chosen
Destructive and credential-related window	150+ attempted operations over 35 minutes	Combines operations from this incident only
Main deletion burst	100+ storage-account deletion attempts in about seven minutes	Microsoft says most targeted accounts were deleted
Later credential collection	30+ successful `ListKeys` requests about 30 minutes after the final destructive activity	Keys could enable data access; Microsoft did not confirm exfiltration

The main destructive sequence lasted about seven minutes. It included more than 100 storage-account deletion attempts, most of which succeeded. The identity also deleted an Azure Key Vault, a Function App, and an App Service plan belonging to the same resource group.

In parallel, the principal attempted to delete multiple Azure SQL databases. Every attempt failed because the request used an unsupported API version for the Azure SQL Database resource type. Microsoft also observed unsuccessful attempts to delete Azure Site Recovery locks and Azure Backup protection locks.

About 30 minutes after the final destructive action, the identity inventoried storage accounts and issued more than 30 successful ListKeys requests, including requests involving Azure Site Recovery-related storage accounts.

Swipe the diagram horizontally to read all labels.

Figure 2. Two-identity sequence adapted from Microsoft’s reported observations. Breaks omit activity and the spacing is not to scale; counts describe this incident, not a performance benchmark. Primary source.

The authorization chain explains the blast radius

Microsoft traced the activity to existing Azure role assignments rather than to an authorization bypass:

A group-granted Storage Account Contributor role authorized the destructive storage operations.
Direct Contributor access authorized deletion of the Key Vault, Function App, and App Service plan, plus one additional successful key retrieval.
Direct SQL DB Contributor access authorized the SQL deletion attempts.

That last distinction matters. The SQL requests did not fail because Azure denied authorization; they failed because the actor selected an unsupported API version. A malformed hostile request is attacker error, not an effective defensive control.

A few storage accounts survived because Azure resource locks or storage account-level deletion protection blocked the requests. Microsoft did not publish a per-resource mapping showing which mechanism protected each surviving account, so the effectiveness of either safeguard cannot be quantified separately from the report. What the incident does establish is that an independently enforced deletion barrier succeeded where broad workload-identity permissions otherwise allowed destruction.

What defenders should take from these outcomes

Failure mode: Broad workload-identity discovery — Observed outcome: Hundreds of successful reads — Defensive interpretation: Reduce effective scope, including group-derived assignments
Failure mode: Storage deletion — Observed outcome: Most targeted accounts deleted — Defensive interpretation: Broad storage roles can become bulk-destruction authority
Failure mode: SQL deletion — Observed outcome: Authorized requests failed on an unsupported API version — Defensive interpretation: Do not treat request defects as resilience
Failure mode: Storage-key retrieval — Observed outcome: 30+ successful ListKeys operations — Defensive interpretation: Restrict key retrieval and reduce dependence on Shared Key access
Failure mode: Locked or deletion-protected accounts — Observed outcome: Some deletion attempts blocked — Defensive interpretation: Preserve safeguards outside routine application permissions

Swipe the diagram horizontally to read all labels.

Figure 3. Existing Azure roles mapped to observed operations and outcomes. The SQL failures resulted from an unsupported API version, not denied authorization. Some storage deletions were blocked by independent safeguards; the report does not quantify each safeguard separately. Primary source.

Resource locks interrupt specific control-plane paths

Azure Resource Manager locks apply restrictions across users and roles. In Microsoft’s terminology, CanNotDelete permits authorized reads and modifications but blocks deletion; ReadOnly also blocks updates. Locks apply to Azure control-plane operations, not generally to data-plane activity.

For storage accounts, that boundary creates three distinct decisions:

Use CanNotDelete when account deletion is the threat path. It allows configuration changes while preventing deletion of the storage-account resource.
Consider ReadOnly when configuration changes and new key retrieval must also be blocked. List Keys is an HTTPS POST operation, so a ReadOnly lock prevents it.
Design data protection separately. A storage-account lock does not stop containers or blobs from being deleted or overwritten through data-plane operations.

A ReadOnly lock also does not neutralize storage keys that a client already possesses. Microsoft states that a client holding the account keys when the lock is applied can continue using them to access data. Newly blocked List Keys requests therefore close one credential-retrieval route without revoking credentials already obtained.

Microsoft’s storage-account lock guidance additionally warns that Azure Files and Table service workloads previously using account keys may become inaccessible under a ReadOnly lock. Approved application traffic should therefore be tested before production rollout rather than assuming that a stricter lock is operationally harmless.

Swipe the diagram horizontally to read all labels.

Figure 4. Effect of storage-account resource locks. “Not blocked” means the lock itself does not stop that path; it does not imply access is authorized. Existing account keys are not revoked by a ReadOnly lock. Primary source.

Removing a leaked secret does not invalidate it

Microsoft found that one compromised service principal’s client ID, client secret, and tenant ID had previously appeared in plaintext in a public GitHub issue posted by an employee of the affected organization. The issue was edited to remove the secret, but the value remained accessible through the public edit history.

Microsoft could not confirm that the exposed secret enabled this intrusion. That uncertainty must be preserved: the GitHub evidence is a plausible exposure path, not a demonstrated initial-access chain.

The remediation requirement is nevertheless unambiguous. Editing or deleting public content changes where a secret is visible; it does not change whether Microsoft Entra will accept the credential. Microsoft recommends treating public credentials as compromised, promptly revoking or rotating them, and investigating their historical use because copies may remain in edit histories, caches, archives, or logs.

Microsoft Entra defines applications, service principals, and managed identities as workload identities. A managed identity is a special type of service principal that removes the need for developers to manage credentials.

Where the documented scenario supports it, workload identity federation can also avoid stored application secrets by establishing trust between Microsoft Entra and tokens from an external identity provider. Microsoft lists supported scenarios including GitHub Actions, Kubernetes workloads, selected Azure compute workloads using app identities, Google Cloud, AWS, Azure Pipelines, SPIFFE/SPIRE, and other external compute platforms.

These options reduce secret-management exposure; they do not automatically reduce authorization. A managed or federated identity with excessive Azure roles can still exercise those roles. Credential design and permission design must therefore be reviewed separately.

Swipe the diagram horizontally to read all labels.

Figure 5. A hypothetical response sequence separating public visibility from the old secret’s validity. Revoking a secret and containing already-issued tokens are distinct checks. Microsoft did not confirm that the GitHub exposure caused this intrusion. Primary source.

Swipe the diagram horizontally to read all labels.

Figure 6. Credential design and effective authorization are separate controls. Managed identity or federation can reduce stored-secret exposure while excessive role assignments remain dangerous. The rings show scope conceptually, not a measured reduction. Primary source.

Backup recovery is not deletion prevention

A resource lock determines whether selected control-plane changes may proceed. Azure Backup soft delete determines whether supported deleted backup data or vaults remain recoverable. Neither control should be treated as proof that the other exists.

Microsoft’s current Secure by Default with Soft Delete documentation, checked September 26, 2026, specifies a 14-day default soft-delete retention period, configurable from 14 to 180 days. The default 14-day period carries no additional retention charge for vaulted backups; regular backup charges apply to additional retention days. Microsoft documents different billing behavior for operational disk backups and VM backup snapshots, for which billing continues according to the resource cost.

The same documentation records important scope limits as of this check:

Its supported-regions table lists Recovery Services vault support as generally available across all Azure public regions and national clouds.
Backup vault support is listed as generally available in Australia East, West Central US, and East Asia, and in public preview across the remaining Azure public regions and national clouds.
Soft delete is not currently supported for operational backups of blobs or Azure Files shares.
Operational disk backups and VM backup snapshots can be accessed and deleted before the soft-delete period expires.

Preview is not equivalent to universal enforcement. The documentation warns that older APIs can still bypass the newer soft-delete behavior in preview regions. In generally available Recovery Services vault regions, the documented behavior is enforced across API versions. Check the actual client and API combination, not just a portal badge. API considerations.

Recovery assurance therefore requires validation of the actual vault type, region, workload, retention setting, client or API behavior, authorization boundary, and restore process. “Backup enabled” is not evidence that the organization can recover from this threat path.

Swipe the diagram horizontally to read all labels.

Figure 7. Retention, undelete, restore and verification are different recovery checkpoints. The period and behavior depend on the supported backup type and configuration. Tech Trend Insight has not performed the proposed recovery tests. Primary source.

Why “agentic” is not yet an Azure telemetry conclusion

Microsoft observed five unique tokens issued to the service principal used for destruction and credential collection. Four supported deletion, while the fifth handled storage inventory and key retrieval. Two deletion tokens were active during the same 70-second period: one focused on storage deletion, while the other mixed storage and SQL deletion.

Microsoft’s technical assessment is carefully worded: the timing, division of work across identities, and overlapping token streams strongly indicate automated or scripted execution.

The report does not publish an LLM model identifier, system prompt, agent trace, natural-language decision record, or self-correcting payload from this Azure operation. The Azure evidence is therefore compatible with several execution models: deterministic scripting, an LLM-driven agent, a human-directed automation framework, or a hybrid workflow. The available telemetry does not distinguish among them.

Sysdig’s July 1, 2026 JADEPUFFER report provides a useful contrast—but only as a separate, attributed case. Sysdig assessed a Langflow-to-database extortion operation as end-to-end LLM-driven based on self-narrating payloads, natural-language reasoning, real-time adaptation, and failure-specific corrections. In one documented sequence, a failed login was followed by a coordinated corrective payload within 31 seconds.

Those artifacts are materially different from fast Azure API activity alone. Sysdig’s evidence supports Sysdig’s LLM attribution in its own environment; it is not direct proof that an LLM controlled the Storm-3168 Azure operation.

Proposed validation exercises

The following are proposed lab exercises, not tests performed by Tech Trend Insight. They should use isolated subscriptions, disposable identities, approved test data, and no production credentials.

Reconstruct effective permissions. Model direct, inherited, and group-derived assignments for representative service principals, then verify which Azure Resource Manager operations each identity can perform.
Test lock behavior independently. Compare CanNotDelete and ReadOnly against account deletion, configuration changes, List Keys, and approved application traffic. Include Azure Files and Table clients where applicable.
Exercise recovery end to end. Delete an approved backup item, confirm its soft-deleted state, undelete it, restore it, and verify that protection resumes under the actual vault, region, workload, retention, client, and API conditions.
Run a credential-invalidation drill. Use only a disposable value, simulate a controlled disclosure, revoke or rotate the associated credential, and measure detection-to-invalidation time.
Compare execution telemetry in isolation. Run functionally equivalent scripted and agent-driven workflows to study observable differences. Such a comparison could improve detection research, but it cannot retroactively prove how Storm-3168 was controlled.

The production decision rule

Do not approve a workload identity for production merely because its credential is hidden.

If the identity can both enumerate a production estate and delete critical resources or retrieve storage keys:

reduce its effective role scope, including group-derived access;
replace stored credentials with managed identity or workload identity federation where Microsoft documents support;
restrict or disable Shared Key authorization where the workload permits it;
enforce deletion safeguards outside the identity’s routine permissions; and
prove recovery under the actual vault, region, workload, retention, API, and cost conditions.

Storm-3168 does not demonstrate that an LLM bypassed Azure authorization. It demonstrates that compromised workload identities can turn ordinary, permitted Azure operations into rapid control-plane destruction—and that attacker mistakes are not defensive controls.

Primary sources and verification

Incident observations are attributed to the original researchers. Diagrams and operational conclusions are Tech Trend Insight’s editorial synthesis, not new incident telemetry. Sources checked September 26, 2026.

Tech Trend Insight