Recent Rubrik Zero Labs research emphasized how challenges with complexity and visibility stemming from data sprawl in the cloud introduce significant security challenges for IT administrators. 

Google's latest Cloud Threat Horizons report introduced a new dynamic to the conversation by illustrating how threat groups leverage those challenges—along with inherent shortcomings in cloud-native backup and recovery capabilities—to complicate victims’ recovery efforts.

 

Native Challenges for Cloud-Native Backup and Recovery

 

Despite Google’s finding, it’s important to note that threat actors are not the sole risk to cloud backups. Even without malicious intent, challenges in data governance and cloud resource management can undermine the reliability of cloud-native recovery solutions.
 

The IT and security leaders we surveyed, for example, described their key challenges across three broad areas:

 

• Lack of centralized management (30%)

• Lack of visibility and control over cloud-based data (29%)  

• Securing sensitive data across multiple environments (35%)

 

While this may on the surface seem to be three distinct problems, they stem from a single cause: Security operations teams, IT, and backup specialists tend to operate in silos that prevent the centralization of data backup and make its management overly complex. Without integration or shared platforms, communication becomes clunky and data correlation is difficult. As cloud footprints expand, visibility decreases across each silo. In the face of such complexity, unforced errors bordering on negligence occur. It’s not surprising that, as reported by Crowdstrike in its annual report, cloud intrusions rose by 26% in 2025.

But even if data sprawl is effectively addressed, cloud-native backup solutions are subject to a number of hazards which, though threat actors may use to their advantage, don’t rely on malicious exploitation to increase cost, lengthen recovery efforts, or jeopardize data integrity.

These include:

 

• Cloud provider outages– Despite high availability SLAs from major cloud providers, outages can directly impede access and operability of backup and recovery mechanisms within affected cloud environments and must be accounted for in disaster planning.  Even if backups are maintained, admins may be unable to initiate recovery, access management consoles, or provision recovery infrastructure, leading to missed RTOs.
  
  

• Vendor lock-in and data portability issues– In multi-cloud environments, organizations must plan for many types of vendor-specific recovery operations accounting for unique data formats, API dependencies, and lack of compatibility. Attempting to create, manage, and validate backup plans for a handful of cloud providers makes recovery planning more complex, time-consuming, error-prone, and costly than necessary for typically under-resourced backup teams.
  
  

• Performance limitations– Mass restoration of terabytes of data with native tooling may be subject to slowdowns from API throttling, network bandwidth limitations, and service quotas. Misconfigurations or insufficient provisioning can lead to backup jobs taking significantly longer than expected, potentially extending RTOs and leaving a larger window of data loss in the event of a failure. While scalability is a key promise of the cloud, a mass restore can lead to significant unexpected OpEx costs.

 

• Human error– A misconfigured automated script may lead to the deletion of a critical production database or an entire snapshot chain in a cloud-native backup system. If the error is not initially noticed or if recovery procedures are incorrectly executed, the consequence can be irretrievable data loss or a corrupted recovery. Misconfigurations in access control, like overly permissive IAM policies, can open backups to unauthorized access, potentially leading to malicious deletion or data exfiltration.

 

None of these inherent limitations minimize the threat malicious actors present for cloud-native backup and recovery solutions. They merely stress that malicious intent is not strictly necessary to snarl cloud recovery efforts. More often, these limitations may complicate the process and increase recovery timelines by adding management overhead and exacerbating resource constraints (both human and digital). 

 

But, as Rubrik Zero Labs and Google research suggest, malicious intent is often very much present. 

 

Rubrik Zero Labs findings show that, among IT and security leaders surveyed who had undergone a ransomware incident, nearly three-quarters (74%) reported threat actors were at least partially able to harm backup and recovery data, and for 35% that damage was total.

 

Google’s Cloud Threat Horizons report details how it has observed threat actors targeting cloud-native data backup instances to:

 

• Actively eliminate established processes for creating backups

• Delete current data and previously created backup copies

• Modify user permissions to hinder response and recovery efforts by security teams

 

"Notably," the authors write, "we are seeing financially motivated threat groups increasingly targeting backup infrastructures in support of their primary objective."

In particular, the research notes how ‘UNC2165’ (aka EvilCorp), a Russian-based, financially motivated threat actor known to deploy multiple ransomware variants, has been observed using this technique to exert pressure on its victims. Some government sources estimate UNC2165 has been able to extort more than $300 million from its victims worldwide.

 

Toward a Better Backup and Recovery Architecture

 

Meeting specified recovery time objectives (RTOs) in light of native cloud backup and recovery flaws requires additional features beyond what major providers currently offer. Centralizing backups to the greatest extent possible streamlines operations and limits opportunities for oversight that arise when backups are scattered across cloud instances. 

 

Other critical backup capabilities include:

• An isolated recovery environment (IRE) – IREs are on-demand, logically or physically air-gapped environments for secure recovery operations. These can be spun up on-demand with necessary compute and networking resources for recovery or testing. Incident response teams can then scan the IRE to identify clean recovery points and ensure no malware is reintroduced into the production environment.
  
  

• Data immutability – Immutable file systems mean that, once written, data cannot be encrypted or modified—either by malicious actors or human error. This can be achieved through an "append-only" design where new data is written out-of-place, preserving the original. All operations are conducted via authenticated APIs within a zero-trust cluster design, preventing unauthorized access or manipulation.
  
  

• Zero trust architecture – "Retention locked" backups prevent tampering with SLA policies that may seek to remove protected objects, reduce the specified time for data retention, redirect archival destinations, or delete SLA policies entirely—in other words, "never trust." Quorum authentication refers to the need to have multiple parties consent to any SLA changes according to a pre-defined chain of approval—the "always verify" element of backup architecture.  

 

These core principles for data integrity and recoverability can be enhanced by capabilities including:

• Proactive threat hunting – Proactive threat hunting within backup snapshots allows organizations to scan historical backup data to precisely identify the earliest point in time malware or an IoC first appears, avoid reinfection based on this point in time, and accelerate incident investigations–-all without impacting production systems.
  
  

• Live mount – Live mounts allow users to instantly create read/write clones of virtual machines, databases, and files directly from backups with no initial resource consumption. This assists with backup validation and testing; reduces risk in pushing updates, patches, or configuration testing; and enables off-production penetration tests, data audits, and reporting.

   

• Orchestrated recovery – Orchestration streamlines policy-driven recovery workflows that define the sequence and dependencies for failover, reducing opportunities for human error and accelerating the recovery process. When orchestration accommodates DR testing procedures, teams can test these workflows frequently to ensure readiness in the event of an incident.

   

Conclusion

 

Increasing complexity and lack of visibility associated with data sprawl in cloud environments present significant security challenges, which threat groups are actively exploiting. Financially motivated actors, in particular, are increasingly targeting backup infrastructures to impede recovery efforts and maximize their impact. 

 

Beyond malicious attacks, cloud-native backup and recovery solutions suffer from inherent issues that can severely complicate or extend recovery times. To counter these threats and deficiencies, a robust backup and recovery architecture must incorporate advanced capabilities typically lacking in out-of-the box cloud backup, none of which are more critical than an IRE and native immutability.