Build1 publisher2 min readPublished
Storm-3168 deleted Azure storage and a Key Vault in seven minutes using a service principal's existing roles
Microsoft says Storm-3168 used a compromised service principal to delete Azure storage accounts, a Key Vault and an App Service plan in about seven minutes. The deletions ran on roles it already held, so role scope and locks had to exist before the credentials leaked.
The Engineer · Build desk
What happened
- Two compromised service principals worked the same victim tenant in parallel, one on reconnaissance and the other on enumeration and, later, deletion.
- The attacker also tried to delete Site Recovery and backup protection locks, and those attempts failed.
- About 30 minutes after the deletions, the same principal re-enumerated storage accounts and made more than 30 successful ListKeys requests for access keys.
- Microsoft has not confirmed how the attacker obtained the service principal credentials in the first place.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A stolen token reaches only what its role assignment allows, so a principal without delete rights on storage or Key Vault leaves those resources out of the attacker's reach.
- exposure Restoring the deleted accounts does not end the incident, because keys pulled for surviving storage accounts have to be treated as in the attacker's hands until rotated.
- decision Removing a leaked secret from a repository leaves copies in commit history, caches and archives, so the response to exposure has to be revocation and rotation in Entra ID.
Once the attacker had the credentials, every step in Microsoft's account is an Azure Resource Manager call. The account comes from a dev.to summary of the Microsoft Security Research report [1]. According to that summary, the attacker called the ARM API directly from Storm-3168-related infrastructure, using the principals' own access tokens [12]. The deletions used RBAC permissions the principals already held [3].
The summary lists three preconditions [15]. The first is a token or client secret that can authenticate to the Azure API. The second is a role that permits deletion, such as Storage Account Contributor or Contributor. The third is missing or thin protection on the targets, such as resource locks, soft delete or immutable backups [15].
The seven-minute figure covers only the core deletion sequence [4]. Before it, the first principal spent about 15.5 hours on more than 300 read and reconnaissance operations [6]. The second principal came back about 16 hours after its first enumeration, ran more reconnaissance, and then started deleting [8]. So the reading phase lasted roughly 130 times as long as the core deletions [1]. Deletion and key collection together took about 35 minutes [9]. More than 100 storage account deletions were attempted, and several succeeded [18].
The Azure Activity Log shows it all in a short window: the storage account deletes, the ListKeys calls, the Key Vault and Function App deletions and the failed lock removals [14]. I think the timeline calls for two kinds of control. Seven minutes is too short for a person to step in, so what protects you during the deletions is whatever locks, soft delete and role scope were configured beforehand. A responder only had time during the hours of service-principal reads.
The case for token revocation is weaker in this record. The summary cites Microsoft Learn's page on continuous access evaluation for workload identities as a reference [21]. It also says the report's statements on the limits of locks and token containment were corrected after publication [19]. The summary does not reproduce the corrected text. Its mitigations ask for service principal RBAC cut to the minimum resources and actions, with Managed Identities and workload identity options preferred [17]. I'd rehearse revocation as a response step. Prevention belongs in role scope and locks, the controls the preconditions list names [15].
The report's title calls these "agentic-driven cloud attacks" [1]. The summary says a correction clarified how confident Microsoft is that AI was involved [20]. The second principal enumerated virtual machines and resource groups across two subscriptions in about five seconds [7]. That is quick for a person and unremarkable for a for-loop.
What to watch
- Microsoft confirming the initial access vector for the two service principals' credentials.
- The corrected passage on the limits of locks and token containment, which would show whether continuous access evaluation for workload identities could have cut the tokens off mid-sequence.
- Whether the storage keys collected through the 30-plus ListKeys requests turn up in follow-on access against the same tenant.