Microsoft says an AI-linked attacker destroyed Azure resources through compromised service principals

Microsoft says Storm-3168 used compromised Azure service principals to automate a destructive attack against an organisation’s cloud environment, deleting storage accounts and application resources while attempting to interfere with recovery systems. The incident is a sharp warning that exposed workload credentials can turn routine cloud permissions into a demolition crew with remarkably little patience.

Microsoft AI Watch analysis

What happened

Microsoft Security says Storm-3168, also linked to the JADEPUFFER operation, carried out more than 150 destructive or credential-collection actions in 35 minutes. The activity targeted Azure Storage accounts, Key Vault, Function Apps, App Service resources and virtual machines. More than 100 storage-account deletion attempts were made, with most succeeding.

The attacker also tried to delete Azure SQL databases, although those attempts failed because it used an unsupported API version. It attempted to remove or interfere with backup and recovery protections, and successfully requested storage-account keys from more than 30 accounts. Microsoft says it did not observe a ransom note or confirm successful data exfiltration in this activity.

Microsoft describes the wider operation as an example of AI-orchestrated attacks, but its detailed account establishes automated or scripted execution more firmly than it establishes exactly how much AI was involved in this particular sequence. The company says one compromised identity spent about 15 hours enumerating the victim’s environment, while another moved from discovery to destructive actions within seconds.

Why it matters

The reported entry point was not a cinematic zero-day. Microsoft says a client ID, client secret and tenant ID had previously been exposed in plaintext in a public GitHub issue. Editing the issue did not invalidate the secret because its edit history remained accessible. Microsoft could not confirm that this exposure was the route used in the incident, but the defensive lesson is concrete: publicly exposed credentials should be treated as compromised and rotated immediately.

The attack also shows why recovery systems cannot be treated as decorative furniture. Resource locks and deletion protection blocked some operations, while broad permissions allowed others to succeed. Least privilege, protected backups, workload-identity monitoring and rapid credential rotation are not glamorous controls, but neither is rebuilding a cloud estate from the ashes.

Our read

This is a meaningful computing-security story because Microsoft provides a detailed account of automated discovery, privilege use, resource destruction and attempted credential collection in Azure. The AI label deserves scrutiny, not blind acceptance. The practical threat is already clear without dressing every script in a futurist cape: compromised service principals can move quickly and cause extensive damage when permissions are too broad.

Organisations running Azure should audit service-principal permissions, rotate any exposed secrets, protect recovery resources separately from production workloads and check logs for rapid enumeration followed by deletion or key-retrieval attempts. The useful question is not whether an attacker used a fashionable model. It is whether your controls would stop the next identity with a short fuse.

What to watch

• Whether Microsoft or the victim publishes evidence clarifying the role of AI in the activity.
• Further Storm-3168 probing of Azure App Services and cloud identities.
• Attempts to delete backup locks, recovery resources or other resilience controls.
• Whether exposed secrets remain usable in public edit histories, caches or archives. Sources and evidence: Microsoft Security’s 25 September investigation is the basis for the incident details, timings, affected Azure resources and mitigation guidance. Microsoft says it did not confirm successful data exfiltration or the initial compromise route.

Discussion spark: Should cloud platforms block destructive service-principal actions by default, or would that create too much friction for legitimate automation?

not affiliated with or endorsed by Microsoft