They didn’t just lock the doors — they burned the house and the spare keys. That blunt image captures the new reality facing organizations running workloads in Microsoft Azure and other cloud platforms: attackers now aim to delete backups as part of multi-stage intrusions, turning recoverable incidents into potential catastrophes. When adversaries can exfiltrate data, encrypt systems, and erase recovery points, the question after an attack isn’t simply “Can we restore?” but “Is there anything left to restore?”
Why delete backups has become a core tactic
Microsoft’s advisory on the group it tracks as Storm-0501 lays out the playbook. Instead of a single, noisy encryption event, the adversary moved quickly through a compromised environment, used cloud-native tools and APIs to pivot into the cloud, stole data for extortion, and then deliberately sabotaged recovery mechanisms. Snapshots and managed backups were deleted or altered; configurations were changed to prevent rollbacks. The result: dossiers that can be monetized and a diminished or destroyed path to restoration.
This escalation matters because many organizations treat cloud snapshots and managed backups as a reliable safety net. If production systems are encrypted or corrupted, those backups are supposed to be the final line of defense. But when attackers specifically target those safety nets, the entire recovery model can collapse.
How attackers accomplish it
Two factors make this approach feasible. First, cloud-native does not equal secure by default. If an attacker gains sufficient privileges, they can use the same APIs and management planes that legitimate operators use—effectively weaponizing platform convenience. Second, poor privilege management and inadequate segmentation let adversaries assume roles capable of modifying or deleting recovery points. Those architectural weaknesses transform cloud controls into attack tools.
Why defenders are facing a harder threat
Ransomware operations are evolving into a triad: exfiltrate, encrypt, and erase. By stealing data, attackers gain leverage even if a victim can restore systems. By deleting backups, they increase coercive pressure. For defenders, this means paying a ransom may still fail to recover lost information; refusing to pay can mean permanent data loss. Incident response becomes far more complex and costly, and regulatory obligations can be triggered when critical data is irrecoverably lost.
Practical defenses: how to reduce the risk of delete backups attacks
– Enforce least privilege and separation of duties: Limit who can access backup systems and who can use management or API functions that affect snapshots and retention policies. Role-based access controls and strict administrative workflows reduce the blast radius of a compromised account.
– Maintain immutable and offline backups: Immutable storage, WORM (write-once-read-many) configurations, and air-gapped or offline copies prevent attackers from erasing backups using standard cloud management paths. Ensure these copies are isolated from the production management plane.
– Log and monitor backup-related activity: Treat deletion or configuration changes to backups as high-risk events. Collect and retain logs, enable real-time alerts for changes to recovery points, and integrate those signals into SOC workflows and incident playbooks.
– Harden identities and sessions: Require multifactor authentication, conditional access, and short-lived credentials for accounts with backup privileges. Monitor privileged sessions and consider just-in-time elevation to minimize standing access.
– Test recovery from isolated copies: Regularly validate that you can restore from immutable, offline, or out-of-band backups. Exercise full rebuild scenarios to understand timelines and dependencies.
– Segment and protect management planes: Isolate backup management from general administrative scopes. Use separate accounts, networks, and controls for backup administration so that a single compromised operator cannot easily delete recovery points.
– Document and plan for regulatory obligations: For regulated industries and critical infrastructure, work with legal and compliance teams to understand reporting duties and resilience expectations if backups are targeted or destroyed.
Trade-offs and operational realities
Implementing offline or immutable backup strategies brings operational friction and cost. Small and medium enterprises may struggle with the expense and expertise required to maintain multiple isolated recovery paths. Immutable backups complicate legitimate maintenance tasks and can introduce restore delays. Still, these trade-offs are often preferable to the alternative: exposed recovery mechanisms that can lead to catastrophic loss and prolonged downtime.
Policy and industry implications
Regulators and sector authorities are already warning organizations to assume that skilled adversaries will target backups. This reality increases the case for prescriptive controls in cloud environments: mandatory segmentation of management roles, enforced multi-factor authentication for backup accounts, and minimum resilience standards for critical services. Public policy and vendor practices must evolve together to ensure convenience features in cloud platforms are not easily turned into attack vectors.
Conclusion: don’t let convenience become complacency
The Storm-0501 case is a warning shot: attackers will adapt and will exploit cloud-provider features unless defenders intentionally design to prevent such abuse. To avoid situations where attackers can delete backups and leave organizations with nothing to restore, defenders must harden identity, architecture, and recovery strategies now. Protect backups as crown jewels—immutable, monitored, and isolated—and test those protections regularly. If backups can be erased as easily as production data, it’s not the cloud that failed: it’s the security design, and the work to fix it is both urgent and achievable.
