What should we do when an Azure service principal secret leaks?

Short answer

Revoke or rotate the secret now, then investigate its history of use. Deleting or editing the place where it was posted does not cancel it: a leaked client secret keeps working until it is rotated or revoked. Microsoft's September 2026 write-up of the Storm-3168 activity shows what a broadly permissioned service principal can do to an Azure environment, and in that case the destructive phase lasted about seven minutes.

Why it matters for Canadian buyers

The risk is not Canada-specific, and nothing in Microsoft's write-up is about Canadian tenants. The Canadian relevance is the legal side of a successful compromise. If a leaked credential gives someone access to personal information, PIPEDA's breach rules may apply: the Office of the Privacy Commissioner of Canada says breaches of security safeguards that pose a real risk of significant harm must be reported to the OPC and to affected individuals, and a record of every breach must be kept for two years. This is general information, not legal advice.

Also relevant to teams that rely on Azure's backup and recovery features: in this incident the attacker tried to remove backup and recovery protection locks. Recovery protections are part of your breach response, not only your disaster recovery plan.

What happened, per Microsoft

• Microsoft Security Research tracks the actor as Storm-3168, and links it to JADEPUFFER, a threat actor Sysdig discovered in July 2026 and reported as the first documented agentic ransomware operation.
• In one tenant, two compromised service principals were used. One did reconnaissance and resource discovery. The other did discovery, destruction, and credential collection.
• The first enumerated resources for about 15 hours and 30 minutes with 300+ successful read operations in early June 2026.
• The second made 150+ destructive or credential-collection attempts in 35 minutes. The destructive sequence lasted about 7 minutes and included 100+ storage account deletion attempts. Most targeted storage accounts were deleted. A Key Vault, a Function App, and an App Service plan were also deleted.
• Azure resource locks and storage account deletion protection blocked deletion of a few storage accounts. Attempts to delete Azure SQL databases failed because the attacker used an unsupported API version. Attempts to delete Site Recovery and Backup protection locks were unsuccessful.
• About 30 minutes after the last destructive action, the same principal made 30+ successful requests for storage account keys.
• What it could do followed its role assignments: a group-granted Storage Account Contributor role authorized the storage deletions; direct Contributor access authorized the application-resource deletions and one key retrieval.
• How it got in is unknown. Microsoft found that the client ID, secret and tenant ID for a service principal had earlier been posted in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was edited to remove the secret, but it stayed visible in the issue's public edit history. Microsoft says it could not confirm that this secret was used in the activity.
• Microsoft says it did not observe a ransom note or confirm data exfiltration in this activity.

What to do

• Treat any credential exposed on any public page as compromised, even if you edited or deleted it. Revoke or rotate it, then review its use. Microsoft says editing or removing the content does not invalidate the credential or remove copies kept in edit history, caches, archives, or logs.
• Search public repositories, issue and pull-request edit history, and CI logs for client secrets, storage keys, and connection strings. Rotate anything found.
• Review Azure RBAC for service principals. List those with Contributor, Storage Account Contributor, or similar broad roles, and cut each down to what the application needs. Check group-granted roles too.
• Reduce long-lived secrets. Microsoft recommends mechanisms that reduce reliance on long-lived credentials where supported; see Microsoft Entra Workload ID documentation.
• Protect backup and recovery. Put resource locks and storage deletion protection on critical resources, restrict who can change backup and recovery locks, and monitor attempts to modify or remove them.
• Turn on the relevant Microsoft Defender for Cloud plans for critical workloads (Resource Manager, Storage, Key Vault, App Service, Databases), and review the alerts Microsoft lists for each.
• Alert on bulk deletes and on bursts of storage key listing (ListKeys). This is our suggestion based on the pattern above, not a Microsoft recommendation.
• Practice the response: who can disable a service principal at 2 a.m., and how do you restore from a state the attacker could not reach.

Sources

All fetched 2026-10-29.

• Microsoft Security Research, "Storm-3168: Agentic-driven cloud attacks using compromised service principals" (Sept 25, 2026)
• Sysdig, "JADEPUFFER: Agentic ransomware for automated database extortion" (cited by Microsoft; not independently fetched)
• Office of the Privacy Commissioner of Canada, "Respond to a privacy breach at your business"

Related

• Security work
• All notes

If you want a second set of eyes on your Azure workload identities, you can book a consult.