Hijacked Azure Identities Destroyed 100+ Storage Accounts in Just 7 Minutes

Microsoft has published details of an attack that should change how UK businesses think about cloud backup. Over an 18–hour period in early June 2026, the group Microsoft tracks as Storm–3168 compromised two Azure service principals — machine identities — belonging to a single cloud tenant, and used them for what Microsoft describes as “extensive Azure–focused resource destruction” and credential collection. The destructive phase lasted roughly seven minutes. In that window the attacker attempted to delete more than 100 Azure Storage accounts, most of them successfully, along with an Azure Key Vault, a Function App and an App Service plan.

Two details elevate this from an incident report to something worth a board conversation. The first is where the attacker went deliberately: straight at the recovery infrastructure. Microsoft observed more than 30 successful “ListKeys” requests against Azure Site Recovery–related storage accounts, and multiple attempts — unsuccessful — to delete Azure Site Recovery locks and Azure Backup protection locks. This was not opportunistic vandalism. Somebody knew that the backups were the thing that mattered and tried to remove the mechanism protecting them. The second is what stopped part of it: resource locks. Some of those 100–plus storage account deletions failed because a lock was in place. A configuration setting that most organisations have never enabled is the reason this incident has survivors.

What Microsoft observed

The operation used two compromised service principals belonging to the same tenant, working in sequence rather than in parallel. The first spent approximately 15 hours and 30 minutes on reconnaissance, completing more than 300 successful read operations across Azure virtual machines, subscriptions, resource groups and other resources. That is a long time to be inside a tenant doing nothing but looking, and it is the most important number in the report for anyone thinking about detection.

The second service principal began roughly 90 minutes after the first and behaved quite differently. It read Azure VMs and resource groups across two subscriptions in five seconds, then spent time hunting for exposed credentials in Azure App Service configuration stores — which is to say, looking for the next set of keys inside the environment it had just mapped. Credential collection of this kind is how a single compromised identity becomes several.

The destruction, when it came, was compressed into about seven minutes. More than 100 storage accounts targeted, most deletions succeeding, some blocked by resource locks, plus a Key Vault, a Function App and an App Service plan from the same resource group. Alongside that ran the attack on recoverability: over 30 successful ListKeys requests against Site Recovery–related storage accounts, and repeated failed attempts to remove Site Recovery locks and Backup protection locks.

On how the identities were taken in the first place, Microsoft is candid: it does not know exactly how Storm–3168 hijacked the service principals. It did note that an employee at the affected organisation had previously exposed client IDs, client secrets and tenant IDs in plaintext in a public GitHub issue. That is a striking fact and an obvious candidate, but Microsoft has not stated it was the vector and neither should anyone else. It is worth reporting precisely because the general lesson holds either way: a client secret in a public repository is a standing invitation, whether or not it was the one used here.

Attribution and intent both need care. Microsoft tracks this attacker as Storm–3168, the same group Sysdig threat hunters identified in July 2026 as running the first–ever documented agentic ransomware infection, in which an LLM drove the entire extortion operation autonomously. That is a genuinely significant piece of context about the actor. It is not a claim that this Azure intrusion was itself LLM–driven, and the report does not say so. Equally, on intent: no ransom note was ever sent and no confirmed data exfiltration was observed in this specific incident. Microsoft’s assessment is that the combination of resource destruction, interference with recovery mechanisms and credential collection is “consistent with tactics that can support ransomware and extortion operations” — which is a statement about pattern, carefully phrased, rather than a conclusion about motive.

Eighteen hours, reconstructed

Microsoft’s reconstruction is unusually granular, and the shape of it is the lesson. Each stage below is drawn from the observed activity.

The asymmetry in that timeline is the entire operational lesson. Detection had roughly 15 hours of opportunity and destruction took seven minutes. No realistic incident response process interrupts a seven–minute deletion spree; by the time a human reads an alert the storage accounts are gone. But a service principal performing 300 read operations across subscriptions it does not normally touch, over the better part of a day, is an anomaly that a monitoring rule can catch — and that is where the achievable win sits. You are not going to outrun the destruction. You can notice the reconnaissance.

Which controls would actually have helped

The chart below is an indicative planning model — not measured data — ranking controls by how much they would have blunted this specific attack chain. It is ordered to make a point that the incident demonstrates directly.

The last bar is the one worth dwelling on, and it is not a criticism of firewalls. Perimeter controls remain essential for plenty of other threats. They are close to irrelevant here, because nothing about this attack crossed a network boundary in a way a perimeter device could evaluate. The attacker authenticated to the Azure management plane as a legitimate identity and issued legitimate API calls. There was no exploit, no malware and no lateral movement across a network in the traditional sense. The security boundary that failed was an identity, and identity is not a place you can put a firewall in front of.

The fourth bar is the only one with direct evidence behind it in this incident. Resource locks are cited by Microsoft as the reason some of the 100–plus storage account deletions failed, and as the reason the attempts to remove Site Recovery and Backup protection locks were unsuccessful. That is a rare thing in security reporting: a named, cheap, widely available control observed to have worked against a capable adversary in a real intrusion. Most organisations have not enabled it, usually because locks are mildly inconvenient during legitimate change work.

Eighty–six per cent of the attack was someone looking around

Divide the reconnaissance by the total duration and the operation’s real character becomes clear. Fifteen and a half hours out of eighteen was observation.

Framed that way, the incident stops being a story about how fast cloud resources can be destroyed and becomes a story about a detection window that was left open for most of a day. Three hundred read operations from a machine identity is not subtle in retrospect. Service principals normally have narrow, repetitive behaviour — a deployment pipeline touches the same resource group, a monitoring agent queries the same metrics, a backup job writes to the same account. An identity that suddenly enumerates virtual machines across multiple subscriptions is doing something it has never done before, and that is a detectable signature rather than a subtle one.

Why it went unnoticed is not mysterious, and it is the same reason it would go unnoticed in most UK organisations. Machine identities are excluded from almost everything that protects human accounts. They do not get multi–factor authentication, because there is nobody to prompt. They do not trigger impossible–travel or unfamiliar–location alerts, because they have no normal location. They rarely appear in access reviews, because access reviews are built around leavers and joiners. They are created during a project, granted whatever permissions made the deployment work that afternoon, and then never looked at again — frequently outliving the project, the developer and sometimes the supplier who set them up.

The five–second enumeration by the second identity deserves a note of caution alongside the reading above. It is consistent with automation, and this actor is known for automation — Sysdig documented the group running an LLM–driven extortion operation two months earlier. But a shell script also completes API calls in five seconds, and Microsoft has not characterised this activity as agent–driven. The reason the distinction matters practically is that it changes nothing about the defence: whether a human, a script or a model is issuing the calls, the control that helps is the same one, and it is limiting what the identity is permitted to do.

Where UK businesses carry this exposure

The rows below reflect where identity and recovery exposure typically sits in a UK organisation running cloud workloads, with badges indicating how much attention each usually needs.

The first row is the one to fix first, and it is a design question rather than a product purchase. The principle is that the identity which can write a backup must not be the identity which can delete it, and ideally the backup should sit outside the tenant that the workload identity can reach at all. Azure’s immutability and soft–delete features, Backup protection locks and Site Recovery locks all serve this end, and this incident shows an attacker attempting to strip exactly those protections — and failing. Separation of the credential is what makes that failure reliable rather than lucky.

The eighth row is marked low only because it is genuinely easy to resolve, not because it is unimportant. Secret scanning is a solved problem with free and built–in options, and the specific exposure Microsoft recorded here — client IDs, client secrets and tenant IDs in plaintext in a public GitHub issue — is worth noting carefully. Many organisations scan code and forget that issues, pull request comments, wiki pages, commit messages and build logs are all published surfaces too. A secret pasted into an issue while debugging is exactly as exposed as one committed to a file, and considerably less likely to be found by a scanner that only reads source.

What closing this gap costs

The bands below are indicative planning figures for UK businesses hardening cloud identity and recovery — not quotes. The variable that moves them most is the number of subscriptions and identities, not headcount.

The first row is deliberately cheap because the highest–value action in this entire story is nearly free. Applying resource locks to storage accounts, key vaults and recovery services is a configuration change, and it is the control Microsoft reports as having blocked deletions during an active intrusion. The reason most organisations have not done it is that locks create friction when somebody legitimately wants to delete something — which is, when stated plainly, precisely the property you are trying to buy.

Two ways to hold a cloud tenant

The honest summary of the difference is that the right–hand column accepts friction. Locks make deletion harder for your own engineers. Least privilege means a deployment occasionally fails with a permissions error. Separated backup credentials mean an extra step in a restore. Every one of those costs something in daily convenience, and every one of them is what stood between this organisation and losing its recovery capability along with its storage. The seven–minute destruction phase is not survivable through response speed; it is survivable through decisions taken months earlier that made the destruction incomplete.

Why this changes the backup conversation

The received wisdom on ransomware resilience has been the 3–2–1 rule and its descendants: multiple copies, multiple media, one off–site. Cloud migration made that feel easier, because geo–redundant storage and cross–region replication deliver copies and locations almost for free. This incident exposes the flaw in that comfort. Geographic redundancy protects against a data centre problem. It does nothing whatsoever against an identity that is authorised to delete the resource, because the replica is deleted along with the primary by the same authenticated API call. Redundancy is not the same property as immutability, and the cloud made the first one cheap while leaving the second one an opt–in.

That is why the relevant modern test is not how many copies you hold but how many distinct credentials would have to be compromised to destroy all of them. If the answer is one, the number of copies is irrelevant. This reframing also explains why the attacker’s behaviour was so purposeful: more than 30 ListKeys requests against Site Recovery storage and repeated attempts on Backup protection locks is an adversary working through exactly this logic from the other side, looking for the copy that cannot be reached and trying to make it reachable.

For organisations pursuing Cyber Essentials, there is a scoping point worth raising with an assessor rather than discovering at assessment. Machine identities are user accounts in every meaningful sense — they authenticate, they hold privileges, they can destroy data — and the scheme’s user access control requirements are built around the principle of least privilege and the removal of unnecessary accounts. Service principals routinely escape that discipline because they are created by developers, live in a cloud portal rather than a directory anybody reviews, and have no leaver process attached. An estate with forty unowned service principals holding subscription–level roles is carrying an access control problem, whatever the certificate says about the laptops.

Finally, the forward–looking concern. This actor is the one Sysdig documented running an LLM–driven extortion operation in July 2026. Whether or not automation of that kind drove the Azure activity, the direction is not in doubt: reconnaissance that took a human fifteen hours is the kind of task automation compresses dramatically. The defensive implication is that the detection window this incident left open — the fifteen quiet hours — should not be assumed to exist next time. Controls that limit what an identity can do hold their value regardless of how fast the attacker moves. Controls that depend on somebody noticing in time do not.

The story at a glance

This story connects to several we have covered recently, and the thread is that the things protecting you are increasingly identities and configurations rather than boundaries. The Gemini autonomous hacking research and the NCSC’s adversary simulation work is the essential companion — the same question of what changes when attack activity is machine–driven, and this is the group Sysdig documented running an LLM–led extortion operation. The Kiteworks shutdown warning made the case for knowing what your systems hold and who can reach them; here the answer to “who can reach them” was an unowned machine identity. The ICO’s £12.7m TikTok fine turns on the same distinction between a stated protection and a working one. Ofcom’s investigations into VoIP number misuse apply “know your customer” discipline to a supply chain, which is the external version of knowing your own identities. And Ofcom’s AI ground rules for telecoms show a regulator trying to set expectations for a technology moving faster than its governance.

Frequently asked questions

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.