Microsoft says compromised application accounts were used to map Azure resources, delete many of them, target recovery controls, and request storage keys. Azure administrators should review access and rotate exposed credentials.
In 60 seconds
- Azure organizations should review application-account permissions, exposed secrets, and backup protections.
- Ask your cloud administrator whether your organization uses service principals, which are application accounts for Azure access.
- Rotate any publicly exposed cloud credential immediately; deleting the original post is not enough.
- Do not make broad permission changes or delete resources during an investigation without an administrator’s plan.
Who should care and what to do today
This report mainly matters to businesses, schools, libraries, and government offices that use Microsoft Azure for websites, databases, storage, or other applications. A service principal is a non-human account that lets an application work with Azure resources. Microsoft 365 users without Azure responsibilities should ask their organization’s administrator whether this applies to them.
Ask the person who manages your cloud systems whether your organization uses service principals. If it does, have them review which accounts can delete resources, access storage keys, or change backup and recovery settings. They should also check whether a client secret, which is a password used by an application, appeared in source code, configuration files, public repositories, or issue trackers.
If a cloud credential was publicly exposed, Microsoft says to revoke or rotate it immediately and investigate its past use. Do not assume that editing or deleting the original post, file, or ticket makes the credential safe. Do not make broad permission changes or delete resources while trying to investigate.
What Microsoft observed
Microsoft reported Azure activity associated with JADEPUFFER, which Microsoft tracks as Storm-3168. The company said two compromised service principals in one tenant, or Azure environment, first performed cloud discovery. That means they built an inventory of subscriptions, virtual machines, resource groups, and other resources.
Microsoft said the second identity then attempted more than 150 destructive or credential-collection-related operations. The destructive sequence lasted about seven minutes. Most targeted Azure Storage accounts were deleted, along with an Azure Key Vault, a Function App, and an App Service plan. Attempts to delete several Azure SQL databases failed because the activity used an unsupported application programming interface version.
The activity also targeted recovery-related protections, including Azure Site Recovery locks and an Azure Backup protection lock. Microsoft said the identity made more than 30 successful requests for storage account access keys. Those keys could provide access to sensitive data, so their exposure should be treated seriously.
What is confirmed, and what is not
Microsoft said the compromised identities followed permissions they already had. One had a Storage Account Contributor role through a group, while direct Contributor access allowed other application-resource deletions and one key retrieval. The report shows how an application account with more permission than it needs can increase the damage from a compromised secret.
Microsoft linked the possible initial exposure to a client ID, client secret, and tenant ID that had appeared in plain text in a public GitHub issue. However, Microsoft could not confirm that this exposed secret was used in the activity described. The company also observed separate probing of Azure App Service targets, but said those targets did not overlap with the affected subscriptions.
Microsoft did not observe a ransom note or confirm successful data theft in the activity described. The report says the deletion of resources, attempts to interfere with recovery, and collection of credentials were consistent with tactics that can support ransomware and extortion. That describes the activity’s potential, not a confirmed completed ransomware event.
Practical checks for Azure administrators
Microsoft recommends reviewing service-principal and other workload-identity permissions and applying least privilege. In plain terms, each application account should have only the access its job requires. Pay particular attention to permissions that allow deletion or access to storage keys.
Review where application secrets are stored. Microsoft advises against putting service-principal credentials, storage keys, connection strings, or similar secrets in source code, configuration files, public repositories, or issue trackers. Public exposure can remain a problem through edit history, caches, archives, logs, or other copies.
Protect backup and recovery resources separately from ordinary cloud workloads, and monitor attempts to change or remove their safeguards. Microsoft also recommends relevant Microsoft Defender for Cloud protections for critical Azure workloads. These are organization-level controls for administrators, not settings most home users can enable themselves.
The report describes activity in one impacted tenant and related observations. It does not say that every Azure customer was affected, identify a software version requiring a patch, or confirm a compromise of your organization. Administrators should use their own Azure activity records and Microsoft’s linked guidance to determine whether their environment shows related activity.
Does this affect me?
- Who may be affected
- Organizations using Microsoft Azure for applications, storage, databases, virtual machines, or other cloud workloads, especially those using service principals. Microsoft 365 users without Azure responsibilities should ask their organization’s administrator whether this guidance applies.
- How to check
- Ask your Azure administrator whether service principals are in use, then review their permissions, storage-key access, public secret exposure, and activity involving deletion or recovery settings.
- What to do
- Revoke or rotate any exposed service-principal or storage credential immediately, and investigate its historical use, following Microsoft’s guidance.
- What to avoid
- Do not assume deleting an exposed post removes the risk, and do not make broad permission changes or delete cloud resources without an administrator-led investigation.
Common questions
Does this mean my Azure account was hacked?
No. Microsoft reported activity in one impacted Azure tenant and did not say that every Azure customer was affected. Your Azure administrator should review activity records, service-principal permissions, and exposed credentials to determine whether your environment shows related signs.
What is a service principal?
It is a non-human account used by an application or automated job to access Azure. It can have permissions such as reading storage or deleting resources. If its secret is exposed or the account has excessive permissions, an attacker may be able to use those permissions.
Is this a ransomware incident?
Microsoft described resource deletion, attempts to interfere with recovery protections, and collection of storage keys as activity consistent with tactics that can support ransomware and extortion. It did not observe a ransom note or confirm successful data theft in the activity described.
What if a cloud secret was posted online and later removed?
Treat it as compromised. Microsoft says editing or deleting the original location does not invalidate the credential because copies may remain in edit history, caches, archives, logs, or other systems. Revoke or rotate it immediately and investigate its past use.
Primary source
This article is based on Microsoft Security Research’s September 25, 2026 post, “Storm-3168: Agentic-driven cloud attacks using compromised service principals”: https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/. See the original post for technical details, detection names, and Microsoft’s mitigation guidance. Read the complete original source.
Concerned this may affect your computer or account?
Bring the exact alert, device, product, and timeline. Leon will help separate urgent action from noise.
Article history: Published Sep 25, 2026 at 2:16 pm EDT. Updates and corrections are noted here when material facts change.
