The credential that runs an application can also be the credential that deletes the recovery path. Microsoft reports that activity tracked as Storm-3168 used two compromised Azure service principals to enumerate a tenant, delete cloud resources and request storage account keys. The observed activity included attempts to interfere with backup and recovery resources. That is a direct secret-handling problem: a non-human identity may have access to both production data and the keys needed to restore it.
Microsoft associates the activity with JADEPUFFER, a cluster Sysdig documented earlier in 2026. The public material describes observations in an impacted tenant, not a named victim statement. Treat the technical sequence as a warning to test your own controls, not as evidence that every Azure organization has been hit.
What Microsoft observed
In its September 25 research, Microsoft says one compromised service principal enumerated virtual machines, subscriptions, resource groups and other resources for about 15 hours and 30 minutes, with more than 300 successful read operations. A second principal then performed discovery, destructive operations and credential collection. Microsoft observed more than 150 destructive or credential-collection operations over 35 minutes; the main destructive sequence lasted about seven minutes.
The reported sequence included more than 100 storage-account deletion attempts, deletion of an Azure Key Vault, a Function App and an App Service plan, and unsuccessful attempts against Azure SQL databases and recovery protection. The same service principal later made more than 30 successful ListKeys requests for storage accounts. Microsoft says resource locks and storage-level deletion protection blocked some deletion attempts, while other resources were deleted.
Microsoft did not report a ransom note or confirm successful data exfiltration in this activity. It describes the combination of destruction, recovery interference and key collection as consistent with tactics that can support ransomware or extortion. That is an assessment of the observed behavior, not proof of a completed theft or a public attribution of the original credential exposure.
Independent context, with the boundary kept clear
Sysdig independently documented a July Azure incident in which an attacker started with one leaked service principal client secret and moved across Entra roles, Azure RBAC, Key Vault access policies, bearer keys and Microsoft Graph permissions. Sysdig says that operation ended with tenant-owner access and persistence across multiple identities. Microsoft identifies JADEPUFFER as the cluster Sysdig discovered, so the reports are materially related; they do not prove that the July and June activity involved the same tenant or the same exposed secret.
The useful common fact is narrower: a service principal is a non-human identity with an application credential, and its permissions can cross boundaries that are monitored by different teams. A password-reset checklist that covers only human users will miss it.
Build a service-principal recovery record
- List the identities that can touch recovery material. Inventory service principals, managed identities, application registrations, certificates, client secrets, federated credentials and workload identity bindings. For each one, record an owner, purpose, last use, subscriptions, resource groups, Key Vault permissions and the ability to grant or change access.
- Review all five views of activity. Correlate service-principal sign-ins and Entra audit logs with Azure Activity logs, Key Vault diagnostic logs, application-permission changes and storage data-plane activity. A legitimate API call can still be an incident when the identity, source, timing or resource is wrong.
- Contain the identity first. Disable the compromised service principal or remove its active credentials through a controlled change, then preserve the sign-in and activity evidence. Do not delete the application registration before you know which logs, owners and dependent workloads you still need.
- Rotate at every issuer and dependency. Replace client secrets and certificates, storage account keys, SAS material, Key Vault secrets, database credentials and tokens reachable from the identity. Revoke the old values explicitly and test that they fail; removing a secret from a repository or configuration file does not invalidate a credential that was already issued.
- Separate recovery from the identity under review. Keep backup administration, deletion protection and break-glass access behind independently controlled identities. Use resource locks and recovery safeguards where they fit the service, but test who can remove those safeguards and whether the test is logged.
- Prefer identities without a shared long-lived secret. Migrate suitable workloads to managed identities or short-lived federated credentials, reduce role scope and remove unused principals. A safer credential is still not safe when nobody owns its permissions or its replacement process.
Recovery values need a separate route
During a cloud incident, the person who rotates a storage key or client certificate may need to hand a temporary value to the engineer who updates a workload. Keep that value out of the incident ticket and the shared bridge. Record the non-secret identifier, issuer, owner, timestamp and validation result instead. Verify the recipient using a known route and use a clean administrative device if the original endpoint is part of the investigation.
After the old value has been revoked, Secretus can deliver a small replacement credential through a one-time encrypted link. It can reduce the number of persistent copies during the handoff, but it cannot discover an over-permissioned service principal, protect an exposed Azure tenant or replace a managed secret store. The recovery record should end with evidence that the old credential fails, the new one works only where intended, and recovery resources remain independently protected.