A ransomware note on a Monday morning is bad enough. Finding that the backups have also been deleted, encrypted or made unreachable can turn a contained IT incident into a business-threatening outage. So, can hackers access cloud backups? Yes. Cloud storage does not automatically make a backup untouchable. If an attacker gains the right credentials, exploits excessive permissions or compromises the system managing the backups, they may be able to destroy the very data needed for recovery.
The risk is not that cloud backups are inherently unsafe. A well-configured cloud backup service can be significantly more resilient than a single external drive in the office. The danger lies in treating a cloud backup account as separate from the rest of the business security environment. Attackers do not need to defeat the cloud provider itself if they can simply sign in as an administrator.
Can hackers access cloud backups through stolen credentials?
This is one of the most common attack paths. A criminal may steal a Microsoft 365, Google Workspace, cloud storage or backup administrator password through phishing, malware, a reused password or a previous data breach. Once signed in, they will look for valuable systems, privileged accounts and recovery options.
In a ransomware incident, this reconnaissance often happens quietly before any files are encrypted. The attacker may identify where backups are stored, learn how long deleted data is retained, disable alerts and attempt to remove restore points. If the same account can administer both live business systems and backups, one stolen password can give them a route to both.
Multi-factor authentication makes unauthorised access harder, but it is not a complete answer. Attackers can use convincing phishing pages to capture session cookies, pressure staff into approving a login prompt, or take control of an employee’s email account first. Strong authentication needs to be combined with restricted privileges, clear alerting and close investigation of unusual sign-in activity.
The ways attackers target cloud backups
Not every cloud backup attack looks the same. Understanding the method helps a business choose controls that address the real failure point rather than relying on a vague assurance that data is ‘in the cloud’.
Deleting backup data and restore points
An attacker with sufficient access may delete backup jobs, retention policies, snapshots or individual restore points. Some platforms have a retention window during which deleted material can be recovered, but this varies by service and configuration. If a deletion is not detected quickly, the window may expire before the business realises its recovery options have gone.
Encrypting synchronised files
A cloud sync folder is not necessarily a backup. If ransomware encrypts documents on a staff computer and the encrypted versions synchronise to cloud storage, clean copies can be overwritten. Version history may help, but it has limits and should not be confused with a dedicated, tested backup strategy.
Compromising the backup management console
Backup consoles are high-value targets because they control schedules, storage locations, retention and recovery. Attackers may alter policies so backups silently fail, redirect jobs, disable immutability, or create new administrator accounts for later use. A backup that has been failing for weeks offers little protection when the incident begins.
Targeting backup software and infrastructure
A cloud destination does not remove the need to secure the servers, agents and credentials that send data there. Malware on a server may steal backup credentials or interfere with backup processes. Vulnerable backup software can also provide a route into the wider environment if it is exposed to the internet or left unpatched.
Misusing shared accounts and excessive permissions
Small businesses often rely on convenience: a shared administrator login, one person with unrestricted access, or a single account used for email, cloud storage and backup administration. This reduces accountability and makes incident containment harder. It also gives an attacker more capability than they need if they compromise that account.
What makes a cloud backup recoverable after ransomware?
The most valuable backup is not the most recent copy. It is the copy that remains clean, available and verifiably restorable when an attacker has control of part of your environment.
Immutability is central to this. An immutable backup cannot be changed or deleted for a defined retention period, even by an administrator who would normally manage the backup system. Different providers use different names, such as object lock, write-once-read-many storage or immutable vaults. The technical detail matters less than the outcome: an attacker who steals credentials should not be able to erase every recovery point.
However, immutability must be configured correctly. It is worth checking which data is protected, how long the retention lock lasts, who can change it, and whether a separate security role can override the setting. A short retention period may not protect a business where attackers remain undetected for several weeks.
Separation is equally important. Backup administration should not depend solely on the same accounts used to run everyday systems. Use separate privileged accounts, strong multi-factor authentication and least-privilege access. Where possible, protect the backup platform with a distinct identity arrangement so a compromise of the main business tenant does not automatically compromise recovery data.
A practical model is the 3-2-1-1-0 approach. Keep at least three copies of important data, on two different types of storage, with one copy held off-site, one copy offline or immutable, and zero errors confirmed through regular recovery testing. It is not a magic formula, but it exposes a common weakness: many organisations have multiple copies that all remain accessible through the same administrator account.
Detection matters before recovery
Ransomware groups increasingly target backups deliberately. By the time ransom demands appear, the attacker may have spent days or months inside the network. During that period, warning signs can include unfamiliar administrator accounts, failed backup jobs, large deletion events, changed retention policies, impossible-travel logins and repeated authentication failures.
These events need investigation, not just an alert buried in a dashboard. An active security operations function connects identity activity, endpoint evidence, cloud logs and backup changes to determine whether the business is facing a misconfiguration, an employee mistake or hostile intrusion.
How to protect cloud backups without creating a recovery problem
Security controls should make recovery safer, not make it so complicated that staff cannot use it during an outage. Start by identifying the data that would stop operations if lost: customer records, accounts, case files, design work, email, databases and line-of-business systems. Confirm where each item is backed up, how long copies are retained and who can authorise deletion.
Then review the accounts that control the backup platform. Remove shared logins, apply multi-factor authentication, restrict administrator rights and ensure emergency recovery credentials are securely held outside normal daily use. Do not leave those credentials only in an email inbox or password vault controlled by the potentially compromised tenant.
Use immutable storage for critical backups and maintain at least one recovery path that an attacker cannot alter through routine administrative access. For some organisations, this may be a protected cloud vault. For others, it may include an offline copy. The correct balance depends on data volume, recovery-time requirements, regulatory obligations and budget.
Finally, test restoration. A green tick beside a backup job proves only that data was copied somewhere. It does not prove the data is complete, uncorrupted, free from malware or recoverable within an acceptable timeframe. Test a file restore, a mailbox restore and, where relevant, a full server or application recovery. Record what failed, how long it took and what would need to change during a real incident.
If you suspect your backups have been targeted
Do not immediately delete evidence or begin restoring systems. First, contain the incident by isolating affected devices and restricting suspicious accounts. Preserve logs, identify which backup sets may be clean and stop automated synchronisation or deletion processes that could spread the damage.
Recovery should begin only after the attack route is understood and access has been secured. Restoring data into an environment that still contains the attacker’s persistence mechanism can result in a second compromise. Digital forensics, credential resets, malware removal and recovery planning need to work together.
Cloud backups are a powerful part of business continuity, but only when they are treated as a defended recovery system rather than remote storage. The right question is not simply whether a backup exists. It is whether an attacker could reach it, alter it or prevent you using it when the business needs it most.
