Backups May Be Compromised -- Cannot Trust for Recovery
Backup integrity is uncertain. The attacker may have been present in the environment long enough to have compromised backup copies, planted persistence mechanisms in backup images, or encrypted/deleted backup repositories.
Signals
- •The attacker dwell time exceeds the backup retention window, meaning all available backups may contain attacker artifacts
- •Backup admin console shows recent changes to backup jobs, retention policies, or repository credentials
- •Ransomware deleted or encrypted backup volumes (Veeam, Commvault, cloud backup storage)
- •No offline or immutable backup copies are confirmed to exist
Pivot Actions
- 1.Identify the last known-clean date from the investigation timeline and compare against available backup restore points
- 2.Validate backup integrity by restoring to an isolated sandbox environment and scanning for known IOCs before production recovery
- 3.Check for immutable or air-gapped backup copies (tape, object-lock S3 buckets, offline Veeam repositories) that the attacker could not reach
- 4.Perform a differential analysis: compare a suspect backup image against a known-good baseline to identify unauthorized changes
- 5.If no clean backup exists, plan a rebuild-from-scratch approach with hardened configurations rather than restoring a potentially compromised image
Alternate Evidence Sources
- •Immutable cloud backups (S3 Object Lock, Azure Immutable Blob) that cannot be modified post-creation
- •Offline tape backups stored at an offsite facility
- •Configuration-as-code repositories (Terraform, Ansible, GPO exports) enabling clean rebuilds without relying on disk-image backups