JadePuffer ransomware group uses AI agents to attack Azure and destroy cloud resources

[Golden Crow]

BleepingComputer reports that Microsoft has uncovered attacks on Azure cloud environments carried out with the help of AI agents. The group behind them uses JadePuffer ransomware and is tracked by Microsoft as Storm-3168. Microsoft's security team found two attacks in June, and cloud security firm Sysdig had already written about JadePuffer's emergence in July. This looks like one of the clearest real world examples yet of criminals using agentic AI

The attackers got in using two compromised service principals, the security identities that let applications and automated tools log in to Azure. The credentials for one of them had appeared in a public GitHub issue before the attack, which was probably how they got in. AI agents then automated much of the attack, from reconnaissance and stealing credentials to moving through systems, setting up persistence and encrypting data

The destructive phase lasted just seven minutes. In that time, the attackers targeted more than 100 storage accounts plus Key Vaults, Function Apps, virtual machines and App Services. They made over 30 requests for storage account keys, most of which succeeded, and removed backup recovery protections to make restoration harder. An attempt to delete Azure SQL databases failed only because the tools used unsupported API versions

Some damage was prevented by Azure resource locks and storage account protections that the victims had in place. Microsoft recommends turning on cloud workload protection, scanning public repositories for leaked secrets and checking permissions against the principle of least privilege. Those are basics, but the speed of this attack shows why they matter so much

This lands in a month full of stories about AI agents going wrong, but this time it is not an accident. Seven minutes to wreck a cloud environment is terrifying. Are security teams ready for attacks that move this fast? And does anyone still leave credentials lying around on GitHub?

JadePuffer agentic AI attacks target Azure, destroy cloud resourceswww.bleepingcomputer.com

[BackRowBob]

The failed SQL deletion is almost funny. The AI tooling used an unsupported API version, so the databases survived

Attackers relying on agents inherit their bugs too. Not a defence anyone should count on though

[Leah]

Resource locks saving part of the environment is a great reminder to turn them on. They take minutes to set up. Most teams skip them because they get in the way of deployments. That convenience can cost you everything

[Emma72]

Makes the Reco funding news this week look well timed. Knowing which identities and agents exist in your environment is step one

Most companies could not list all their service principals if you asked them. That has to change quickly

[Bayley_US]

Credentials in a public GitHub issue again. Every year the same mistake causes the same disaster. Secret scanning tools exist and are often free. There is no excuse for not using them

[Merchant89]

Seven minutes is faster than most security teams can even acknowledge an alert. By the time a human looks at the dashboard, the damage is done. Defences have to be automated now. There is no other way to keep up

[NightHarbour91]

Microsoft deserves credit for publishing the details. Other cloud customers can check for the same indicators now

Sharing attack chains like this helps everyone defend better. Plenty of vendors would have kept quiet

[TripleH19]

This is exactly what security people predicted when agents became popular. Criminals do not need to hire skilled hackers when an agent can run the playbook. The barrier to entry for serious attacks has dropped massively. Expect a lot more of this next year

[Shannon44]

Removing backup protections first shows planning. Whoever built the playbook knew exactly how Azure recovery works. The AI just executed it at speed. That is the scary part of agentic attacks. Human expertise goes into the design, and the machine handles the speed

[ElectricPilgrim]

Least privilege is the lesson here. A service principal with enough rights to delete over a hundred storage accounts should not exist in most setups. Split permissions so no single identity can wreck everything

It is tedious to set up properly. It is far less tedious than rebuilding from scratch