Cloud backup security is becoming part of the ransomware conversation because attackers increasingly understand that recovery is what gives a business the power to refuse a ransom.
Microsoft recently documented activity linked to a threat actor it tracks as Storm-3168. The campaign used compromised cloud identities and agentic techniques to delete Azure resources, collect credentials, and target resources associated with backup and recovery.
The important detail is not that AI magically “deleted the cloud.”
The attackers used permissions that were already available to the compromised identity.
If the stolen identity can delete production data, storage accounts, or recovery resources, the attacker may be able to use that same authority against your ability to recover.
What Did Microsoft Observe?
Microsoft Security Research reported Azure-focused destructive activity associated with JADEPUFFER, a threat actor previously reported as part of an agentic ransomware operation.
The compromised service principal already had cloud roles that permitted destructive actions.
Microsoft observed deletion of Azure resources and attempts to interfere with recovery-related assets. The activity included Azure Storage Accounts with names associated with backup or Terraform infrastructure and targeting of Azure Site Recovery-related resources.
The attackers also attempted to retrieve storage-account keys and delete Azure SQL databases. Microsoft said the observed SQL deletion attempts were unsuccessful because of an unsupported API version.
Microsoft did not report a ransom note or confirm successful data exfiltration in the activity it analyzed.
That nuance matters.
This was destructive cloud activity consistent with ransomware-aligned objectives, not proof that every cloud backup service is easily erasable.
Why Attackers Target Recovery
Ransomware creates leverage by making recovery difficult.
If a business can quickly restore clean systems and data, the attacker loses much of that leverage.
That is why Microsoft’s ransomware guidance has long warned that attackers may try to:
- Delete backups
- Stop backup jobs
- Disable recovery tools
- Delete shadow copies
- Steal backup credentials
- Damage documentation required for recovery
Cloud infrastructure changes the tools, but not the objective.
The attacker wants the business to believe there is no way back.
A Cloud Backup Is Still Controlled by an Identity
Cloud services feel different from an external hard drive sitting next to a server.
However, cloud systems still depend on accounts, permissions, roles, policies, and administrative actions.
Someone can create a backup, change its retention, and may be able to delete it.
The security question is: Who?
If the same administrator account controls production resources and backup deletion, one stolen identity may create too much power.
Least Privilege Applies to Backup Administrators
Microsoft’s Storm-3168 investigation highlighted the role of existing Azure permissions.
The attacker did not need to invent new authority. It used permissions already assigned to the compromised service principal.
That makes least privilege one of the most important backup controls.
Businesses should avoid giving everyday accounts broad rights to:
- Delete recovery points
- Disable backup protection
- Change retention
- Remove recovery vaults
- Access backup encryption keys
- Control production and backups with the same identity
High-impact backup actions should require stronger authorization than ordinary daily work.
Soft Delete Creates Recovery Time
Microsoft recommends soft-delete protections for Azure Backup.
Soft delete can retain backup data for a period after someone attempts to delete it, creating an opportunity to recover from accidental or malicious deletion.
This turns immediate destruction into a reversible action.
That delay can be extremely valuable during an incident.
However, a feature only helps if it is enabled, monitored, and understood before the attack begins.
Use Multiple-User Authorization for Dangerous Actions
Microsoft also recommends multi-user authorization for Azure Backup.
The idea is straightforward.
One compromised administrator should not be able to perform the most destructive recovery actions alone.
Critical changes can require additional authorization through a separate control.
This is similar to requiring two people to approve a large financial transfer.
Backups are valuable enough to deserve the same thinking.
Protect Backup Credentials Separately
A backup account should not share passwords with ordinary employee accounts.
Use unique credentials and a business password manager.
Use MFA wherever supported.
Keep recovery credentials out of documents stored on the same systems they are meant to recover.
For especially sensitive environments, separate backup administration from normal system administration.
Password-first security matters because attackers often look for credentials before they look for backup files.
Immutable and Append-Only Storage Can Reduce Risk
Modern backup services increasingly use storage designs that prevent existing recovery points from being modified.
Microsoft 365 Backup, for example, uses append-only backup storage to prevent malware or client processes from overwriting existing restore-point data.
Azure also offers controls designed to make backup deletion and modification harder.
No feature removes the need for good administration.
However, immutability and deletion protections reduce the number of ways one compromised account can destroy recovery options.
Your Recovery Documentation Needs Protection Too
Microsoft specifically warns that ransomware actors may target the documents a business needs to recover.
That can include:
- Network diagrams
- Administrator contacts
- Recovery procedures
- Backup instructions
- Configuration records
- Vendor support information
If all of those documents live in the same compromised environment, the business may have backups but no clear path to use them.
Keep critical recovery information somewhere accessible during an outage.
A Backup Has Not Proven Anything Until You Restore It
Microsoft recommends periodic test restores.
SofTouch Systems makes the same distinction repeatedly because it matters:
Backup success is not the same as recovery success.
A dashboard can report green checkmarks every night while nobody has tested whether the right files, systems, or accounts can actually be restored.
Businesses should know:
- What is backed up
- How long recovery points are retained
- Who can delete them
- How long a restore should take
- Which recovery point would be used after ransomware
- Whether a recent restore test succeeded
What Should a Small Business Do Now?
- Identify every backup system. Include cloud, endpoint, server, and Microsoft 365 recovery tools.
- Review who can delete backups. Broad administrator rights deserve scrutiny.
- Separate backup credentials. Do not reuse ordinary business passwords.
- Enable deletion protections. Use soft delete, immutability, or multi-user authorization where available.
- Protect recovery documentation. Make sure instructions survive the same incident.
- Test a restore. Confirm that recovery actually works.
- Monitor changes. Backup policy changes and deletion attempts should generate attention.
Frequently Asked Questions
It can target cloud backups or recovery resources if the attacker obtains sufficient permissions. Well-designed backup services include protections such as soft delete, immutability, separate authorization, and recovery grace periods to make destructive actions harder or reversible.
No. Microsoft observed destructive Azure activity that targeted storage and recovery-related resources and could impair recovery. The report did not say that every backup was successfully deleted.
A service principal is a non-human identity used by applications and automation to access cloud resources. Like a user account, it can become dangerous if compromised and granted excessive permissions.
Separate credentials reduce the chance that one stolen employee or administrator account gives attackers control over both production systems and recovery copies.
The right frequency depends on business risk, but testing should happen regularly enough that the company can confidently meet its recovery goals. Critical systems usually justify more frequent testing.
Your Backup Is Part of Your Security Perimeter
The Storm-3168 activity shows why businesses should stop treating backups as passive storage.
Backups have identities, permissions, policies, and administrative controls.
Attackers know that.
SofTouch Systems helps small Texas businesses review backups, endpoint protection, administrator access, and recovery readiness without enterprise complexity.
If you are unsure who can delete your backups or when your business last tested a restore, start with a free backup and recovery check.
Your backup should survive the same attacker your production systems did not.
Sources:
- Microsoft Security: Storm-3168 agentic-driven cloud attacks
- Microsoft Learn: Protect Azure backups from ransomware
- Microsoft Learn: Ransomware backup and recovery planning
Discover more from SofTouch Systems
Subscribe to get the latest posts sent to your email.