Compromised application identities can destroy resources in Azure
Two application identities in the same tenant ran more than 150 destructive operations in 35 minutes and deleted most of over 100 storage accounts.
What happened
Microsoft describes how Storm-3168 used two application identities in the same tenant. With them it ran more than 150 destructive or credential-theft operations in 35 minutes: it deleted most of over 100 storage accounts, a Key Vault, a Function App and an App Service plan. Resource locks and delete protection saved part of the storage, and attempts to remove the locks protecting Azure Backup and Site Recovery failed. A secret for the application was published in a public GitHub repository, although Microsoft does not confirm that this was the entry point.
Why it matters
The damage did not come through a person’s account but through an application identity with broad permissions that nobody was watching: that kind of account has no second factor and does not stand out when it is used. In 35 minutes, years of work can be undone if a service credential accumulates privileges and nobody monitors what it does. That the locks saved part of the storage is proof that the barriers put in place before the incident are the ones that really count.
What we recommend
Limit the privileges of application identities, store and rotate their secrets outside the code and protect resources and backups with locks and immutability. A secret in a public repository must always be rotated, whether or not it is confirmed as the entry point. And review who can remove those locks, because a permission that overrides them leaves the protection on paper only.
Related service: infraestructura-cloud · copias-recuperacion
Want to know how it affects you?
We review your environment and tell you what to prioritise, with no commitment.