Backup & Privacy · Published 2026-09-29

AI Agent Attack Wiped 100+ Cloud Storage Accounts in Minutes

Direct answer up front, then the trade-offs that matter. This page covers cloud storage attack and answers: How do I secure a NAS on my network?.

By Lillian · Senior Editor, Buying Guides

Beat: Buying guides · How we review

Quick Answer

On 25 September 2026, Microsoft published its first detailed account of Storm-3168 — the cloud activity of the actor Sysdig named JADEPUFFER — showing how two stolen Azure service principals deleted more than 100 storage accounts in roughly seven minutes, then collected storage access keys and tried to remove the locks protecting backups (Microsoft Security Blog, accessed 2026-09-29). For anyone who keeps the only copy of family photos, client footage or work files with one provider, the practical lesson is not that cloud storage is broken. It is that delete permissions and backup copies should never depend on the same credential.

Key Takeaways

Microsoft tracks the group as Storm-3168 and links it to JADEPUFFER, which Sysdig described in July 2026 as the first documented ransomware operation run end to end by a language-model agent (BleepingComputer, accessed 2026-09-29).
The destructive burst covered more than 100 storage account deletion attempts and lasted about seven minutes; most of the targeted accounts were deleted (Microsoft Security Blog, accessed 2026-09-29).
Backup and recovery were explicit targets. The same identity made unsuccessful attempts against Azure Site Recovery locks and an Azure Backup protection lock (The Hacker News, accessed 2026-09-29).
What survived was protected in advance. Azure resource locks and storage-account deletion protection blocked a few deletions even though the compromised identity held broad administrative permissions (Microsoft Security Blog, accessed 2026-09-29).
The likely entry point was a service principal secret posted in plaintext in a public GitHub issue. It was edited out but stayed readable in the public edit history (Microsoft Security Blog, accessed 2026-09-29).

What happened: 100+ storage accounts deleted in minutes

Microsoft Security Research described one affected Azure tenant. Two compromised service principals from that tenant split the work. A service principal, for readers who do not work in cloud administration every day, is a non-human identity that an application or an automation job uses to log in to Azure — close in spirit to a machine account or a long-lived API key.

The first identity spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups and other resources, completing more than 300 successful read operations (Microsoft Security Blog, accessed 2026-09-29). Roughly 90 minutes into that run, the second identity enumerated virtual machines and resource groups across two subscriptions in five seconds. Both used the same infrastructure fingerprint and the identical user agent string python-requests/2.34.2, which Microsoft reads as evidence of scripted or automated execution rather than a person typing commands.

Sixteen hours later the second identity read App Service configuration stores, possibly hunting for more credentials. Less than a second after a failed key request against a storage account that did not exist, deletion began. Over the following 35 minutes the identity attempted more than 150 destructive or credential-collection operations. The core destruction lasted about seven minutes and included more than 100 storage account deletion attempts, most of which succeeded (Microsoft Security Blog, accessed 2026-09-29). An Azure Key Vault, a Function App and an App Service plan in the same resource group were deleted as well.

Two things did not go the attacker's way. Parallel attempts to delete Azure SQL databases all failed because the script used an API version that the SQL resource type does not accept. More importantly for this discussion, several storage accounts survived because Azure resource locks and account-level deletion protection had been configured before the incident (Microsoft Security Blog, accessed 2026-09-29). Some 30 minutes after the destruction stopped, the same identity issued more than 30 successful key requests, including against storage accounts tied to Site Recovery (Pivot News, accessed 2026-09-29).

A seven-minute sequence, at a glance

Stage	What the Microsoft record shows	Duration
Reconnaissance	One compromised service principal enumerated virtual machines, subscriptions and resource groups, with 300+ successful read operations	About 15.5 hours
Second discovery pass	A second service principal mapped virtual machines and resource groups across two subscriptions	About 5 seconds
Destruction	100+ storage account deletion attempts, most successful, plus a Key Vault, Function App and App Service plan	About 7 minutes
Credential collection	30+ successful key requests, including Site Recovery storage accounts	~30 minutes after deletion

Microsoft did not observe a ransom note and did not confirm data theft, but it described the combination of deletion, interference with recovery mechanisms and credential collection as consistent with tactics that can support extortion (The Hacker News, accessed 2026-09-29). External analysts quoted in coverage of the report were more measured about the "AI" framing than the headline implies. Nick Tausek of Swimlane told CSO Online that the Azure evidence shows coordinated automation rather than proving that a model directed each step, a qualification worth keeping in mind when the story is summarised as an AI agent "deciding" to wipe a company (Pivot News, accessed 2026-09-29).

What it means for home and creator storage

Very few households and small studios run Azure tenants, so it is fair to ask why an enterprise cloud incident should matter to someone choosing a two-bay NAS or a cloud photo plan. The answer sits in the shape of the attack rather than in the name of the platform.

The campaign was not clever. It relied on a credential that had been exposed in public, permissions broader than the job required, and a recovery layer that depended on the same identity that had already been stolen. Those three weaknesses are just as common outside enterprise IT. A household shares a single account password across family members. A creator leaves a cloud storage token in a script on a public repository. A home server exposes its administration interface to the internet with the default port. The difference here is only speed: an automated client can turn a valid credential into mass deletion in minutes, well inside the window in which a human would normally notice a login alert and react to it.

That reframes what a local device is for. A NAS or a home server is not automatically safer than a cloud bucket, and the comparison should never be framed as cloud bad, local good. A badly configured box on the open internet is its own risk. What a second, independently controlled copy buys you is a different set of failure modes. A deleted cloud bucket is recovered from something outside that account, or it is not recovered at all. When the account that holds the primary data also holds the only backup copy, one stolen secret becomes a single point of total loss, whether the storage lives in a data centre or on a shelf.

There is a second, quieter lesson about recovery data specifically. The actor did not only delete primary storage; it went after the protections that exist to make deletion reversible. In household terms, that is the difference between losing a laptop and losing the laptop plus the external drive that held the only backup, on the same evening. Offline copies, or copies held under separate credentials that the primary account cannot modify, are what break that chain. Microsoft made the point plainly: the defensive window opens long before an attack, not during it (Microsoft Security Blog, accessed 2026-09-29).

Cloud-only vs local-first backup: what this changes

The useful question is not which storage is best in the abstract. It is which failure mode you are willing to live with.

Consideration	Cloud storage account	Local NAS or home server	Hybrid, both copies
Loss if one credential leaks	Bulk deletion from the account is possible in minutes, as this case shows	Physical access or a compromised exposed interface is required	Neither copy can be destroyed through a single login
Recovery after mass deletion	Depends on provider retention, soft delete and account-level locks	Depends on RAID, snapshots and your own spare drives	Depends on whichever copy stayed reachable
Recovery layer under attack	This incident attempted to remove Site Recovery and Backup locks	Shares the device, so it needs its own separate protection	Keeps copies under different credentials and locations
Ongoing cost	Subscription, scaling with capacity	Hardware up front, electricity, maintenance	Both
Who can see the data	The provider under its terms	Only whoever holds the device	Split across both, deliberately

(The column for cloud storage reflects Microsoft's account of this intrusion; the NAS column reflects ordinary configuration choices, not a tested result.)

What to watch: the limits and open questions

Several parts of the story are unresolved, and they are worth stating rather than smoothing over.

Microsoft could not confirm that the exposed service principal secret was the actual way in. The client ID, client secret and tenant ID had appeared in a public GitHub issue and stayed readable in the edit history after being redacted, which is a strong lead and not a proof (Microsoft Security Blog, accessed 2026-09-29). The SQL database deletions failed on an API version mismatch, and the report notes the identity would otherwise have had permission to carry them out — luck, not design. One storage account in the same resource group as the deleted resources was left untouched, and Microsoft does not explain why. The report also notes no ransom note and no confirmed exfiltration, so the extortion motive is inferred from the pattern rather than confirmed by a demand.

None of the individual techniques involved a software vulnerability. That matters for anyone tempted to read the incident as a patching problem. The controls that helped were identity governance, least privilege and independently protected recovery copies. Microsoft's recommendations follow the same line: revoke and rotate any credential exposed in public, remove secrets from repositories and issue trackers, scope service principals to the minimum they need, put locks and deletion protection on anything that must be recoverable, and monitor for unusual patterns such as a burst of reads followed by deletes from one identity (Microsoft Security Blog, accessed 2026-09-29).

The same guidance translates to a home setup with almost no translation. Rotate anything you have ever pasted into a forum or a public repository, give the backup job its own credentials rather than reusing the main account, keep at least one copy offline, and test that a restore actually works before you need it. It is unglamorous work, and it is the part of this story that a single automation window cannot take away.

Frequently Asked Questions

What exactly is a service principal, and why does it matter here?

A service principal is a non-human identity that an application, script or automation job uses to authenticate to a cloud platform, much like a service account on a traditional network. It matters here because the whole incident ran on two of them: once the credentials were valid, the attackers inherited whatever permissions those identities had, including the ability to delete storage accounts. In a home setup the equivalent is a long-lived API token or app password that a backup job uses, which is why those tokens deserve the same care as a login password.

Is ransomware a real risk for a home NAS?

It is a documented one, and it does not require anyone to target you specifically. Automated scanning finds exposed administration interfaces and weak passwords without a human choosing a victim, and the recovery step is where home setups usually fail, because the only backup often sits on the same device or in the same account. The defensive pattern from this Azure case applies directly: keep deletion-capable permissions narrow, and keep at least one copy that the primary account cannot modify.

Should I expose my NAS to the internet?

Exposing it directly is the riskiest option and rarely the one people actually need. Most households are better served by remote access through a VPN or the manufacturer's relay service than by opening an administration port, and the difference is that a relay or tunnel does not hand an anonymous scanner a login prompt to attack. If remote access is essential, change default ports and accounts, enable two-factor authentication where it exists, and treat every token that touches the device as a credential worth rotating.

What are the minimum protections worth setting up first?

Four things, in order. Give the backup path its own credentials, separate from the account you use day to day. Keep one copy offline or under separate access, so a compromised login cannot reach it. Put deletion protection or equivalent retention on anything you would not want an automated process to erase. Then rotate anything you have ever published by mistake, even if you deleted it afterwards, because a redacted secret in a public edit history is still a working key.

Sources

Storm-3168: Agentic-driven cloud attacks using compromised service principals — Microsoft Security Blog, https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/ (accessed 2026-09-29)
JadePuffer agentic AI attacks target Azure, destroy cloud resources — BleepingComputer, https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources (accessed 2026-09-29)
JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources — The Hacker News, https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html (accessed 2026-09-29)
Storm-3168 deleted Azure resources using hijacked service principals — Pivot News, https://pivotnews.ai/security/storm-3168-deleted-azure-resources-using-hijacked-service (accessed 2026-09-29)
Storm-3168 (JADEPUFFER) Destructive Azure Cloud Campaign via Compromised Service Principals — Enigma Global, https://www.enigma-global.com/preview/report/storm-3168-jadepuffer-destructive-azure-cloud-campaign-via-compromised-service-mujhyy1m-qed1 (accessed 2026-09-29)
Storm-3168 Cloud Attack Campaign — CraftedSignal Threat Feed, https://feed.craftedsignal.io/briefs/2026-09-storm-3168-azure (accessed 2026-09-29)

Run your own 5-year cost comparison with the on-site calculator

信息型内容且无合作相关标签 → 不放商业位

Open the cost calculator →