JADEPUFFER Uses Stolen Service Principals to Destroy Azure
Microsoft Threat Intelligence tracks JADEPUFFER-linked attackers using compromised Azure service principals to delete cloud resources. Audit your tenant's non-human identities now.

Microsoft Threat Intelligence is tracking a campaign in which JADEPUFFER-linked attackers gained access to Azure environments through compromised service principals and used that access to delete cloud resources, according to The Hacker News’ reporting published September 28, 2026.
Service principals are non-human identities in Microsoft Entra ID used to authenticate applications and automated workloads. A compromised service principal gives an attacker API access to Azure subscriptions without needing user credentials, and that access often persists longer than it should because service principal secrets are not rotated as frequently as user passwords.
JADEPUFFER’s earlier campaign involved EncForge ransomware that encrypted AI model checkpoints and vector databases for extortion. Destructive resource deletion via Entra service principals is a different track: no ransom negotiation, just gone. Whether this is the same operation or a parallel campaign is not yet confirmed in the reporting.
What to do
Audit your service principal inventory. Microsoft Entra lists all service principals in your tenant. Any with Owner, Contributor, or User Access Administrator roles on production subscriptions deserves scrutiny. Remove credentials for anything unused or unrecognized.
Check Azure Activity Logs for recent deletion events. Look for Microsoft.Resources/subscriptions/resourceGroups/delete and storage or compute deletion operations from the past 30 to 90 days. Deletion from a service principal identity with no corresponding deployment pipeline activity is worth investigating.
Rotate service principal secrets. Secrets can live for up to two years by default. Shortening the rotation window reduces how long stolen credentials stay usable.
Enable resource locks on critical workloads. Azure resource locks can block deletion even for principals with Contributor access. Combined with soft delete on key vaults and storage accounts, they give you a recovery window if deletion does happen. Microsoft’s resource lock documentation covers implementation.
For additional Azure attack context from this period, see the Fortune 500 Azure data theft campaign from August and the Azure AI Foundry CVSS 10.0 privilege escalation patched last week. Non-human identity hygiene is the common thread across all three.
Found this useful? Share it.


