In This Article
- What Storm-3168 did inside one Azure tenant
- Why an Azure service principal is worth stealing
- What held, and why the attacker's roles could not remove it
- Six controls for your own service principals
- What examiners expect from your backups
- How ABT hosts Azure for financial institutions
- Frequently Asked Questions
Many banks, credit unions, and mortgage companies run part of their daily work in Microsoft Azure: a hosted loan origination system, a document archive, the reporting database that refreshes before the branches open, the backups that run overnight. Software does most of that work, and software signs in with an identity of its own.
In Azure, that identity is usually a service principal, an application's own account in Microsoft Entra ID, Microsoft's cloud identity service, with its own credential and its own permissions. It lets a nightly job write files and a reporting app read a database without anyone typing a password. Whatever an Azure service principal is allowed to do, anyone holding its credential can do too.
On September 25, 2026, Microsoft Security Research published a report on what it calls agentic-driven cloud attacks, showing what that power looks like in an attacker's hands. In one organization's Azure tenant, an actor Microsoft tracks as Storm-3168 used two compromised service principals to map the environment, then made more than 100 storage account deletion attempts in about seven minutes.
Most of the targeted storage accounts, which hold files and data, were deleted. So were a key vault, which holds secrets and keys, and the cloud app it appeared to support, called a function app. About 30 minutes later, the same identity came back for the access keys to storage accounts that were still there.
The useful part of the report is what survived. A few storage accounts were protected by resource locks or deletion protection, and those deletions failed. Locks on backup and recovery resources held too.
What Storm-3168 did inside one Azure tenant
Microsoft links Storm-3168 to JADEPUFFER, which its report describes as "a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation." The Azure activity ran in stages, and the pace of each stage is the first lesson.
One compromised service principal enumerated subscriptions, resource groups (containers that hold related resources), and virtual machines, with more than 300 successful read operations.
A second service principal listed virtual machines and resource groups across two subscriptions in five seconds.
The second identity enumerated App Service configuration stores, which Microsoft says may have been a search for exposed credentials, then asked for the keys to a storage account that didn't exist.
More than 100 storage account deletion attempts. A key vault, a function app, the App Service plan that appeared to support it, and most targeted storage accounts were deleted.
More than 30 successful requests for storage account access keys, including accounts tied to Azure Site Recovery, Microsoft's service for keeping workloads running through outages.
Across 35 minutes, the same identity attempted more than 150 destructive or credential-collection operations. Microsoft counted five separate access tokens for it, two of them deleting within the same 70-second window. It concludes that the timing and division of work "strongly indicates automated or scripted execution."
The attacker went after recovery as well as production. Microsoft reports deletion attempts against Azure Site Recovery locks and Azure Backup protection locks, and storage accounts with backup- and Terraform-themed names among the targets. The attempts on the locks failed.
Every attempt to delete the organization's Azure SQL databases failed too, for a reason no institution should count on. The attacker's requests used a version of Azure's management interface, or API, that the database resource type doesn't support.
Three limits belong beside those facts. Microsoft kept the organization and its industry anonymous. It observed no ransom note and couldn't confirm that any data left the environment. And it describes the activity as consistent with tactics that can support ransomware and extortion, a narrower statement than calling it a ransomware attack.
Which identities could do this in your Azure environment?
ABT hosts Azure environments for banks, credit unions, and mortgage companies. A specialist can walk through your service principals and the roles they hold.
Why an Azure service principal is worth stealing
An Azure service principal gets its permissions through role assignments, the same way a person does. It differs from a person's account in the ways that matter to an attacker. Microsoft lists them: workload identities, the identities that applications use to reach resources, "Can't perform multifactor authentication," "Often have no formal lifecycle process," and "Need to store their credentials or secrets somewhere."
Service principal
The identity an application uses in a Microsoft Entra tenant. Azure role assignments decide which resources it can read, change, or delete.
Client secret
A password-like string an application presents to sign in as its service principal. Anyone who copies it can sign in the same way.
Managed identity
An identity Azure manages for a resource such as a virtual machine or function app. The application gets tokens without a stored credential.
Workload identity federation
A trust between Microsoft Entra ID and another identity provider, such as GitHub, so a workload can sign in without a stored secret.
Resource lock
An Azure setting that blocks deleting (CanNotDelete) or changing (ReadOnly) a resource through Azure Resource Manager, the management layer that creates, updates, and deletes Azure resources. A lock applies across all users and roles. Changes made through the resource's own data endpoints, such as deleting the data inside a storage account with its key, sit outside the lock.
The report shows how a credential like that can escape. Microsoft found that the organization's client ID, client secret, and tenant ID had been posted in plaintext in a public GitHub issue by an employee. The issue was edited to remove the secret, but the secret stayed readable in the issue's public edit history.
Microsoft could not confirm whether this secret was the way in. Its guidance holds either way: "Removing or redacting an exposed secret does not invalidate it."
Leaked secrets are common. GitGuardian's State of Secrets Sprawl 2026 report counted 28,649,024 new secrets in public GitHub commits in 2025, and its announcement puts the increase at 34% over the year before. The same announcement reports that 64% of the valid secrets it found in 2022 were still not revoked in 2026. In Microsoft's words, publicly exposed credentials "remain usable until revoked or rotated."
Scope is the second lesson. Microsoft says the attacker's operations "followed the identity's existing Azure role assignments." A group-granted Storage Account Contributor role authorized the storage deletions. Microsoft Learn describes that role as one that "Provides access to the account key, which can be used to access data via Shared Key authorization."
Direct Contributor access covered the key vault and the function app, and SQL DB Contributor covered the database attempts. One credential held the power to delete and the power to read.
The Microsoft 365 version of this problem is the user account that runs software. Our guide to the forgotten service accounts a password spray found covers that side.
What held, and why the attacker's roles could not remove it
Set the outcomes side by side and a pattern appears. The targets Microsoft reports as surviving a deletion attempt had a protection outside the attacker's roles, with one exception that came down to luck.
Deleted or exposed
- Most of the storage accounts targeted for deletion
- A key vault, a function app, and its App Service plan
- Storage account access keys, returned by more than 30 successful requests after the deletions
Survived by attacker error
- Azure SQL databases, where every deletion attempt failed on an unsupported API version
Held
- A few storage accounts protected by resource locks or deletion protection
- Azure Site Recovery locks
- Azure Backup protection locks on storage accounts
Microsoft calls the locks "independent safeguards that remain effective even when a compromised identity has broad administrative permissions." Azure's own role definitions explain why. The Contributor role excludes every authorization write and delete, and Storage Account Contributor can only read authorization objects, such as role assignments and locks.
Removing a lock takes Microsoft.Authorization/locks permissions, which the Owner and User Access Administrator roles hold. ABT's reading: the roles that let this identity delete storage and read keys didn't include taking a lock off.
Deletion without a lock is harder to undo than many teams expect. Microsoft Learn says a deleted storage account can be recovered only if it was deleted within the past 14 days and no new account has taken its name. It adds that "Recovery is a best-effort attempt." If the resource group is gone too, it has to be recreated first; Microsoft says recovering a resource group isn't possible.
Key vaults fare better: soft delete is on by default for new vaults, can't be turned off once enabled, and keeps a deleted vault recoverable for 7 to 90 days. Purge protection, which stops anyone from permanently erasing a deleted vault early, is optional and off by default.
Microsoft's report sums up its own advice in one line: organizations reduce exposure "by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections." The incident shows why the third item matters as much as the first two. Once a credential is in an attacker's hands, the controls still standing are the ones its roles cannot change. As a Tier-1 Microsoft Cloud Solution Provider serving more than 750 financial institutions, ABT recommends designing locks, locked backup vaults, and a second approver into every Azure workload from the start, alongside least-privilege roles.
Six controls for your own service principals
These six controls follow the order of the attack: the credential, the roles behind it, and the resources it can reach. Start with the inventory, because every other control depends on knowing which identities exist and what they hold. Put the ones that can reach customer information first: the identities behind the loan origination system, the document archive, and the reporting database.
List each app registration and service principal, its owner, its credentials and their expiry dates, and every Azure role assignment it holds. Review first any identity nobody on staff can explain.
Use managed identities for workloads that run in Azure and workload identity federation for GitHub Actions and other outside platforms.
Grant the smallest role at the smallest scope the application needs. Storage Account Contributor includes the account keys, and Contributor at subscription scope reaches every resource in the subscription.
Put Delete locks on production storage accounts, key vaults, and backup and recovery resources, then confirm your backups still run. A lock on a resource group covers everything inside it, including resources added later.
Use an Azure Backup immutable vault with the setting locked, soft delete that stays on, and multi-user authorization through a Resource Guard. Turn on purge protection for key vaults.
Enable the Microsoft Defender for Cloud plans Microsoft names for these workloads, watch for leaked credential detections, and rotate any secret that appears in public, even after the post is edited.
Managed identities remove the secret entirely; in Microsoft's words, "Credentials aren't even accessible to you." For code that deploys from GitHub, workload identity federation trades a GitHub token for a Microsoft Entra token. Microsoft says the approach "eliminates the risk of leaking secrets or having certificates expire." Where a credential must remain, Microsoft recommends a certificate over a client secret, managed in Azure Key Vault.
Test locks before you apply them broadly. Microsoft warns that "Applying locks can lead to unexpected results." Among its examples, backups fail when a cannot-delete lock sits on the resource group Azure Backup creates for restore points, and a lock on a resource group stops Resource Manager from cleaning up old deployment history. Lock the production and recovery resources you name, confirm the backups still run, then widen the scope.
Two settings shrink what a stolen credential is worth. With Shared Key authorization disallowed on a storage account, Microsoft says "Azure Storage rejects all subsequent requests to that account that are authorized with the account access keys," so stolen account keys stop working there. Before you disallow it, check the shared access signature (SAS) tokens, which grant limited access to storage, and the applications Microsoft lists. For backups, Azure Backup's immutable vault can be locked "to make it irreversible," which keeps an attacker from switching immutability off.
Service principals that stay need watching. Microsoft's report names Defender for Resource Manager, Storage, Key Vault, App Service, and Databases as the Defender for Cloud plans to consider for critical workloads. Microsoft Entra ID Protection flags workload identity credentials checked in "in public code artifact on GitHub," and customers without Workload Identities Premium "still receive all detections with limited reporting details." Conditional Access for workload identities can block a service principal registered in your own tenant by location or risk, which requires Workload Identities Premium licenses.
When a secret leaks, rotate first and investigate second. Microsoft's guidance is to treat publicly exposed credentials as compromised "even if the original location has subsequently been edited or deleted." Apps that users consent to also create service principals in your tenant, which our guide to OAuth consent phishing covers from the attacker's side.
What examiners expect from your backups
Storm-3168 went after recovery as well as production, and recovery is where examiner expectations get specific. The Federal Financial Institutions Examination Council (FFIEC) addresses it directly in its Business Continuity Management (BCM) booklet. The Office of the Comptroller of the Currency (OCC) announced the booklet in Bulletin 2019-57.
BCM should include the ability to protect offline data backups from destructive malware or other threats that may corrupt production and online backup versions of data.
The booklet's examination procedures check for the same measure under Objective 6. The expectation for recovery dates back further. When the OCC issued the FFIEC's destructive malware statement as Bulletin 2015-20, it wrote that management "is expected to maintain sufficient business continuity planning processes to ensure the rapid recovery, resumption, and maintenance of the institution's operations after a cyber attack involving destructive malware."
The booklet speaks of offline backups, and an Azure Backup vault is online. ABT reads the booklet's concern as backups that production, and any identity running it, can't reach or corrupt. In Azure the closest controls are the ones in control five: a locked immutable vault, soft delete that stays on, and a second approver for destructive changes. Bring that configuration to your examiner and auditor and settle together whether it meets the offline expectation or an additional offline copy is needed.
Our guide to Azure disaster recovery for financial institutions covers the rest of the recovery plan.
Access controls sit under a separate rule for each kind of institution:
- Banks: the Interagency Guidelines Establishing Information Security Standards, which each federal banking agency has adopted, call for "Access controls on customer information systems, including controls to authenticate and permit access only to authorized individuals." The Federal Deposit Insurance Corporation (FDIC) version is 12 CFR Part 364, Appendix B.
- Federally insured credit unions: Part 748 Appendix A from the National Credit Union Administration (NCUA), its Guidelines for Safeguarding Member Information, call for "Access controls on member information systems, including controls to authenticate and permit access only to authorized individuals."
- Mortgage companies and other institutions under Federal Trade Commission (FTC) jurisdiction: the FTC Safeguards Rule, which covers mortgage lenders, mortgage brokers, and non-federally insured credit unions among others, requires controls that "Limit authorized users' access only to customer information that they need to perform their duties and functions." It also requires controls "designed to monitor and log the activity of authorized users."
These rules are written about individuals and authorized users. ABT reads the same least-privilege standard as covering the service principals acting inside those systems, since each one can reach customer information on its own. For the ransomware side of the same exam conversation, see our guide to ransomware protection for financial institutions.
How ABT hosts Azure for financial institutions
The six controls above are ongoing work, and whoever runs your Azure environment day to day should be able to show you where each one stands. ABT is a Tier-1 Microsoft Cloud Solution Provider with more than 750 financial institution customers and a 25-year operating history. It manages Microsoft 365 tenants and hosts Azure environments for credit unions, banks, and mortgage companies.
Through Private System Hosting, ABT runs custom and legacy systems on dedicated Azure deployments in your own subscription, with the same security architecture ABT uses for Calyx PointCentral hosting, and integrations can route through ABT MortgageExchange. Each subscription is enrolled in Microsoft Defender for Cloud, and ABT reviews the Defender for Cloud score with your team every quarter and remediates findings against its standard baseline. Azure Backup writes nightly snapshots to geo-redundant storage, backups are monitored daily, and restores are tested every quarter and documented in a backup test log. Virtual machine and application logs flow into Microsoft Sentinel, Microsoft's cloud security monitoring service.
NetworkGuardian turns on Microsoft Defender for Cloud across the Azure environment ABT hosts and runs, keeps watch over its security posture, and raises an alert when Defender for Cloud surfaces a risk. It covers the Azure side.
If you want to start with the tenant, ABT's free Security Assessment reviews your Microsoft 365 configuration across six areas, including identity and access, and compares the results with ABT's benchmark of more than 750 financial institutions. Most assessments finish within two weeks. It connects through a read-only service principal that is provisioned with your consent and removed when the assessment ends, so ABT's own access follows the least-privilege advice in this article.
Host your Azure workloads with ABT, in your own subscription
Storm-3168's destructive sequence took about seven minutes, so the time to decide which identities can delete your resources is before a credential is stolen. Talk with ABT about the identities, roles, and locks in your Azure subscriptions, or start with a free Security Assessment of your Microsoft 365 tenant.
Frequently Asked Questions
An Azure service principal is the identity an application uses in a Microsoft Entra tenant. It signs in with a client secret, a certificate, or a federated credential, and Azure role assignments decide which resources it can read, change, or delete. Anyone who holds its credential can do whatever those roles allow.
Microsoft reported on September 25, 2026 that Storm-3168 used two compromised service principals in one Azure tenant. After hours of reconnaissance, one identity made more than 100 storage account deletion attempts in about seven minutes, deleted a key vault and a function app, and later made more than 30 successful requests for storage account keys.
Not with the Contributor role alone. Removing a lock requires Microsoft.Authorization/locks permissions, which the Owner and User Access Administrator roles include. The Contributor role excludes authorization writes and deletes, and Storage Account Contributor can only read authorization objects. A Delete lock therefore stays in place against an identity that holds only those roles.
Treat an exposed client secret as compromised. Microsoft says removing or redacting an exposed secret does not invalidate it, so rotate or revoke the credential immediately and investigate how it has been used. Then move the workload to a managed identity or workload identity federation where you can, so no stored secret is left to leak.
Sometimes. Microsoft Learn says recovery is possible only if the account was deleted within the past 14 days, no new account has taken its name, and its resource group exists or is recreated, and it calls recovery a best-effort attempt. Microsoft recommends resource locks to keep storage accounts from being deleted in the first place.
The FFIEC's Business Continuity Management booklet says business continuity management should include the ability to protect offline data backups from destructive malware that may corrupt production and online backup versions of data, and its examination procedures check for it. The OCC also expects rapid recovery of operations after a destructive malware attack.