Microsoft Threat Intelligence describes Storm-3168 activity involving compromised service principals in Azure. The Microsoft Security Blog from 25 September 2026 links the activity to JADEPUFFER and reports Azure-focused resource destruction, reconnaissance, and credential collection. For small and midsized organizations, this matters whenever applications, automations, or backups rely on long-lived secrets: according to Microsoft, a disclosed or overprivileged service principal secret can remain usable until it is revoked or rotated.
What Microsoft reported on 25 September 2026
Microsoft observed two compromised service principals in the same tenant. One principal performed more than 300 successful read operations over about 15 hours and 30 minutes. A second principal enumerated resources across two subscriptions in five seconds, searched for configuration data, and then moved into destructive activity. Microsoft names Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services as affected target types.
This is not a general product launch and Microsoft does not publish a future deadline. The concrete action is to treat exposed secrets as compromised immediately, review workload identities, and protect critical Azure resources against deletion and misuse.
Why service principals matter for SMB security
Service principals are often used for scripts, integrations, backup tools, CI/CD pipelines, or administrative automation. They do not sign in like normal users, but they can hold broad permissions. In the Storm-3168 case, Microsoft says a client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue. The issue was later edited, but Microsoft stresses that removing or redacting the location does not invalidate the secret.
- Publicly exposed secrets must be revoked or rotated, not merely removed from the location where they were found.
- Roles at subscription or resource-group scope can enable destructive actions when a service principal is compromised.
- Configuration stores, storage keys, and Key Vaults matter because they can open additional access paths.
- Backup and recovery protection controls belong in the same review as production resources.
Urgency: review now, not at a deadline
Microsoft does not give a Storm-3168 deadline; it describes a fast sequence after reconnaissance. The destructive sequence lasted about seven minutes and included more than 100 deletion attempts against Storage Accounts. Overall, the compromised principal attempted more than 150 destructive or credential-related operations in 35 minutes. For smaller teams, that means a monthly permission review is not enough if a long-lived secret is already outside the environment.
The first review should therefore focus on active secrets, unusual sign-in and Azure Resource Manager activity, and broad role assignments. Microsoft Entra ID and Microsoft Entra Workload ID provide the identity layer; Microsoft Defender and Defender for Cloud provide signals for resources, storage, Key Vault, App Service, and Resource Manager.
Which protections Microsoft recommends
Microsoft’s guidance is practical: protect workload identities and secrets, enforce least privilege, safeguard recovery resources, and enable relevant Defender for Cloud plans for critical workloads. Microsoft Learn describes Entra Workload ID as a service for managing and helping secure identities for digital workloads such as apps and services. The Azure RBAC best-practices article recommends granting only the access users or security principals need and avoiding broad roles at broad scopes.
According to Microsoft Learn, Defender for Cloud is a cloud-native application protection platform with CSPM and workload-protection capabilities. In the Storm-3168 context, Microsoft specifically names Defender for Resource Manager, Storage, Key Vault, App Service, and Databases as relevant coverage.
Concrete next steps for administrators
- Export all app registrations and service principals with active client secrets, then sort them by age, usage, and permission scope.
- Immediately revoke and rotate secrets that were placed in public or unsuitable internal locations, then investigate historical use.
- Reduce Contributor, Owner, Storage, and SQL roles for service principals at subscription and resource-group scope.
- Review resource locks, deletion protection, and backup protection for critical storage, Key Vault, database, and recovery resources.
- Correlate Defender for Cloud alerts for Resource Manager, Storage, Key Vault, App Service, and Databases with the affected identities.
For a Microsoft Security Assessment, this becomes a clear test case: which workload identities could delete production or recovery-relevant resources today, and would that activity be noticed in time?
Official Microsoft sources
- Microsoft Security Blog: Storm-3168 and compromised service principals
- Microsoft Learn: Microsoft Entra Workload ID documentation
- Microsoft Learn: Microsoft Defender for Cloud overview
- Microsoft Learn: Best practices for Azure RBAC
If you want to check whether your workload identities, secrets, and Defender signals are ready for this kind of cloud attack, we can support a focused review – get in touch.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
