On September 25, 2026, Microsoft published a threat report on an actor it tracks as Storm-3168, which it says used agentic, AI-driven automation to break into an Azure environment and delete cloud resources. Security outlets have linked the activity to a group called JadePuffer. The most useful detail for ordinary businesses is not the AI angle. It is how the attackers got in: a set of cloud credentials that had been posted in a public GitHub issue.
This article walks through what Microsoft reported, what “agentic” means here, and the specific steps that would have limited the damage. It draws on Microsoft’s own write-up, and where we describe details, we attribute them to that report. Microsoft noted it could not confirm that the GitHub exposure was the definitive cause of the breach, so treat that link as the likely entry point rather than a proven one.
What happened, in short
According to Microsoft, the attacker used stolen credentials for Azure service principals, which are non-human identities that applications and scripts use to access cloud resources. Once inside, the activity followed a clear sequence: discover what exists, delete it, then try to collect more credentials.
| Stage | What Microsoft observed |
|---|---|
| Early June 2026 | A first service principal enumerated Azure resources for about 15.5 hours, with more than 300 read operations. |
| About 90 minutes later | A second service principal began enumerating across two subscriptions. |
| Roughly 16 hours after initial access | Enumeration of App Service configuration stores. |
| A 7-minute destructive burst | More than 100 attempts to delete storage accounts, plus deletion of a Key Vault and Function App. |
| About 30 minutes after | More than 30 ListKeys requests to collect credentials. |
The attacker also targeted recovery controls. Microsoft reports attempts against Azure SQL databases, Site Recovery locks, and Backup protection locks were unsuccessful, but the majority of targeted storage accounts were deleted, along with one Key Vault, one Function App, and one App Service plan.
Why Microsoft calls it “agentic”
Microsoft points to several signs that this was not a person typing commands. The activity used five distinct tokens with specialized roles, overlapping activity that suggests parallel execution, and work divided across multiple service principals. In one case, a failed ListKey operation was followed by destructive activity in less than a second. The behavior also spanned many resource types in a logical discovery-then-destruction order.
The takeaway is speed. A defender who checks alerts a few times a day cannot respond to a 7-minute deletion burst. That shifts the emphasis from reacting to an attack toward making the attack fail by design: fewer exposed secrets, narrower permissions, and protected backups.
The entry point: a secret in a GitHub issue
Microsoft says a service principal’s credentials, meaning a client ID, secret, and tenant ID, were exposed in a GitHub issue by an employee. The secret was later edited out of the issue, but it stayed visible in the public edit history. Microsoft’s guidance is blunt: publicly exposed credentials remain usable until they are revoked or rotated. Deleting the text does not un-leak the secret.
This is the same lesson that shows up in many breaches. Attackers do not need to defeat your defenses if a working key is sitting in a public place. For more on how leaked personal data gets abused, see our guides on the IDScan.net data breach and AI voice cloning scams.
What to do about it: a practical checklist
Microsoft’s report lists mitigations. Here they are, translated into steps a small team can act on:
- Never put secrets in repositories, issues, tickets, or config files. Use a secrets manager, and turn on secret scanning in your code host if it is available.
- If a secret is ever exposed, revoke or rotate it immediately. Do not rely on editing or deleting the post. Assume it was copied.
- Apply least privilege to service principals. A non-human identity that only needs to read one storage account should not be able to delete subscriptions’ worth of resources.
- Protect backups and recovery settings. Restrict who can change backup protection and locks, and monitor for changes. In this incident, those controls were among the things that held.
- Turn on cloud threat detection. Microsoft recommends enabling Defender for Cloud plans covering Resource Manager, Storage, Key Vault, App Service, and Databases.
- Add resource locks and soft delete where available for critical assets, so a burst of delete calls cannot remove them permanently.
Items 1 to 5 come directly from Microsoft’s report. Item 6 is a general best practice and is not something the report claims would have stopped this specific attack.
What this means if you are not a large enterprise
You do not need a big cloud footprint for this to apply. Freelancers and small companies often have a few automation scripts using long-lived keys, and those are exactly the kind of credentials that end up pasted into an issue or a chat. A short audit is worth an afternoon: list every API key or service account you use, delete the ones you do not recognize, and rotate the rest.
Basic account hygiene still matters too. Strong sign-in methods reduce the chance that a human account becomes the first step, and our explainer on passkeys versus passwords covers how to switch safely. Keep your devices updated as well, as we outline in our post on Apple’s September 2026 security update.
Frequently asked questions
What is a service principal?
It is an identity used by applications, scripts, and automation to access Azure resources, rather than a human user. Because it is not tied to a person, it often has no multi-factor prompt, which makes leaked secrets especially dangerous.
Is Storm-3168 the same as JadePuffer?
Several security outlets report Storm-3168 as linked to a group called JadePuffer. Microsoft’s report uses the Storm-3168 designation.
Did the attackers use ransomware?
Microsoft’s report, as summarized here, describes reconnaissance, resource deletion, and credential collection. It does not describe a ransom demand in the sections we reviewed.
If I remove a leaked key from a public post, am I safe?
No. Edit histories and copies can preserve it. Revoke or rotate the secret right away.
Sources: Microsoft Security Blog, September 25, 2026; coverage by BleepingComputer and The Hacker News.
