Microsoft details Storm-3168, the JADEPUFFER-linked actor that used stolen service principals to delete Azure storage in minutes and harvest keys.

Microsoft just published the first detailed look at what JADEPUFFER does inside Azure. Sysdig first spotted the group’s activity in July 2026 and called it the first documented agentic ransomware operation. Microsoft tracks the same actor as Storm-3168, and its new report shows how fast this crew moves once it holds valid cloud credentials.

The attack involved two compromised service principals from the same tenant. These are non-human identities that applications use to communicate with Azure. One was used for reconnaissance, while the other focused on discovery, destruction and credential theft. It was a clear division of tasks between the two identities.

The reconnaissance began in early June 2026. The first identity spent about 15 hours and 30 minutes listing virtual machines, subscriptions, resource groups and other resources, completing more than 300 successful read operations. About 90 minutes later, the second identity carried out similar activity across two subscriptions in just five seconds. Both identities used Storm-3168 infrastructure, the same network fingerprint and the same user agent, python-requests/2.34.2.

“About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.” reads the report published by Microsoft. “70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.”

Sixteen hours later, the second identity checked App Service configuration stores, possibly hunting for exposed credentials, and tried to find Azure OpenSearch resources without luck. Seventy seconds after that, it asked for the keys of a storage account that doesn’t exist. Less than a second after that failed request, the deletion started.

In 35 minutes the identity attempted more than 150 destructive or credential related operations, and the destructive part itself ran about seven minutes. It tried to delete over 100 storage accounts and succeeded with most of them. It also deleted a Key Vault, a Function App, and an App Service plan from the same resource group, all of which appeared to support that one app.

Not everything was deleted. Azure resource locks and storage account deletion protection prevented the attackers from removing several storage accounts. Microsoft says this shows that independent security controls can still protect resources even when a compromised identity has broad admin privileges.

The attackers also tried to delete several Azure SQL databases at the same time, but all the attempts failed because the script used an unsupported API version for that resource type. In this case, a simple technical error ended up blocking part of the attack.

The attackers also targeted backup and recovery systems. The compromised identity made several unsuccessful attempts to remove Azure Site Recovery locks and Azure Backup protection locks. It also targeted storage accounts with names related to Terraform and backups, suggesting that the attackers were trying to make recovery more difficult.

Half an hour after the last deletion, the same identity came back for keys. It inventoried the storage accounts and sent more than 30 successful ListKeys requests, including for accounts tied to Azure Site Recovery. One storage account in the same resource group as the deleted Key Vault and Function App was spared during the cleanup, then hit with a successful key request later.

Microsoft says it can’t confirm how the identity was first compromised. It did find that the client ID, client secret, and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the impacted organization.

“The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated.” continues the report. “We could not confirm whether this secret was used for the activity described here.”

The report also describes separate probing from Storm-3168 linked infrastructure since the start of the year. The targets were Azure App Services belonging to different customers, and the paths included WordPress administration, PHP-CGI, LangFlow’s code validation endpoint at /api/v1/validate/code, and other web shell style locations. None of those targets overlapped with the affected subscriptions, and Microsoft found no route from an App Service to Azure Resource Manager credentials for this tenant. The three IP addresses tied to the probing and malicious requests are 45.131.66[.]106, 34.153.223[.]102, and 64.20.53[.]230.

Why call it automated? The timing, the split between two identities, and overlapping token streams point to scripted execution.

“The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.” Microsoft states.

The destructive identity used five unique tokens, four for deletion and one for storage inventory and key retrieval, and two of the deletion tokens were active at the same time for 70 seconds. One focused on storage deletion, the other on a mix of storage and SQL.

The permissions match what the identity already had. A group-granted Storage Account Contributor role covered the storage deletions. Direct Contributor access covered the three application resource deletions and one key retrieval, and direct SQL DB Contributor access covered the failed SQL attempts. The attackers didn’t need to escalate anything, because the access was already there.

Microsoft describes the pattern as consistent with ransomware and extortion, but with a caveat. It didn’t see a ransom note or confirm data exfiltration in this case. What it did see is destruction, interference with recovery, and collection of keys that could open the door to data theft later.

The advice starts with the boring part. Treat any credential exposed on the public internet as compromised, revoke or rotate it, and check its history of use. Keep secrets out of code, config files, repositories, and issues, and give service principals only the permissions their apps need.

Turn on the relevant Defender for Cloud plans for Resource Manager, Storage, Key Vault, App Service, and Databases. Restrict access to backup and recovery resources, and watch for attempts to change or remove their protection. Microsoft also points defenders toward Project Perception for AI agents that investigate at machine speed, and MDASH for finding AI assets and their weak spots.

“Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.” concludes the report.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, JADEPUFFER)

A 2017 UK assessment warned that police data on Microsoft Azure could face foreign access risks. The risks may still exist.

A Guardian investigation has surfaced a 2017 document signed off by then City of London police commissioner Ian Dyson, who also held the title of senior information risk owner for the entire country. That document reviewed 15 risks tied to moving police data onto Microsoft Azure. The files in question include criminal records, victim statements, internal emails, information from more than 40 UK police forces, and some material exceeding standard “official” classification, meaning it may sit at “secret” or “top secret” level.

The assessment was clear. It said Microsoft software had vulnerabilities that could eventually be exploited by cybercriminals and other attackers. It also pointed to a more specific and worrying risk: “US government insiders.”

“In doing so, officers accepted that “US government insiders” would be able to see the data, and that it could be “transmitted worldwide”, with “the extent of this … unknown”. According to five specialists who reviewed the Guardian’s findings, the risks identified in that document persist today. Almost every UK police force now depends on Microsoft Azure, and the UK government spends at least £1.9bn on Microsoft software each year.”” states The Guardian.

“There is a risk of compromise of sensitive data shared by, or taken from, Microsoft by the US government being released by US government insider attackers.” reads the document.

This wasn’t a general concern. It was a specific threat identified eight years ago by the official responsible for data-handling standards in British policing. Five experts who reviewed the same assessment for The Guardian said the risks are still relevant today.

The proposed protections were fairly simple: use Microsoft’s built-in encryption, keep servers updated and let individual police chiefs decide whether to use the service. But experts interviewed by The Guardian, including Microsoft engineers, said encryption does not prevent Microsoft employees from accessing the data. They also said it would not necessarily prevent the US government from obtaining it.

Which is exactly the geography problem Dave Michels, a researcher at Queen Mary University of London’s Cloud Legal Project, pointed to. Microsoft’s cloud infrastructure spans over 100 countries, and pieces of a single file can end up stored across several of them, Sweden to Ethiopia, for instance. Microsoft has started offering EU customers assurances that data stays within European borders, but Michels called the whole focus on data location somewhat beside the point, since the people who can access the data matter more than the servers holding it.

Legally, the situation becomes more complicated. Under the US CLOUD Act, American authorities can require US-based companies to provide data they control, even when that data is stored outside the United States. In some cases, companies can also be prevented from telling the customer about the request.

Microsoft, Amazon and Google have said they would challenge such requests when possible. But, as international law professor Douwe Korff pointed out:

“The risk is obvious, even though the providers of the cloud and the government both have an interest in talking it down” Douwe Korff, professor of international law told The Guardian.

Which brings us to the part that reads like a contradiction under pressure. Police officials told the Guardian the data stays in the UK and that Microsoft can’t share it without permission. Microsoft, meanwhile, told Police Scotland back in 2023 that data can leave the UK and that it cannot guarantee data sovereignty. Those two statements aren’t compatible, and nobody seems eager to reconcile them out loud.

Every single UK police force has now put its data, wholly or partly, on Microsoft’s cloud, despite all of this being on record since 2017. One former senior policing source summed up the current state of visibility pretty starkly:

“All the security guys I worked with when this policy came in expected a big breach by now, and we know it will take that to change the police’s position.” a source told The Guardian. “The truth is, however, the level of logging and information in the cloud systems would not necessarily tell us if there was a problem. We really don’t know if the data has been breached or not.”

That’s the key point. It’s not saying, “we checked and everything is fine,” or “there has been no incident.” It’s saying that the available logs and monitoring might not detect a breach even if one happened.

For anyone responsible for sensitive data in a large cloud environment, that’s an important warning. In a security assessment, saying “we would probably know if something went wrong” isn’t enough without evidence that the monitoring can actually detect it.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Microsoft Azure)