Secrets in Backups and Snapshots: Find and Retire Credentials in Dumps and Disk Images

Every backup, database dump and disk snapshot is a frozen copy of the secrets that were live when it was taken, and most secrets programmes never look there. A VM snapshot holds configuration files, private keys and cached credentials; a database dump can hold role passwords and application API keys stored in tables; a memory-inclusive checkpoint can hold whatever the operating system had in RAM. These copies are retained for months, shared across accounts for recovery and copied into test environments, yet they rarely appear in secret scanning or rotation inventories. This guide treats backups and snapshots as a secret store in their own right: where secrets hide in them, how they leak, how to scan them safely, how to decide what to rotate, and which cloud settings stop accidental sharing. It is for cloud, platform, backup and identity teams. Backup encryption, immutability and restore testing are covered elsewhere and linked rather than repeated.

Key takeaways

• A backup outlives the rotation. Rotating a key in production does not remove it from last month's snapshot; any secret that is still valid and still inside a retained copy is exposed for as long as the copy exists.
• Sharing settings are the usual leak. Public or cross-account snapshot sharing and long-lived export URLs give whole disks to people outside the owning team.
• Snapshot permissions are data permissions. Google Cloud warns that a principal able to read a snapshot can restore it into a project it controls, including one in another organisation.
• Scan copies, not production. Restore into an isolated account, scan for secrets, then decide per finding whether to rotate, accept or delete the copy.
• The real fix is upstream. Secrets fetched at runtime from a manager, with short lifetimes, do not survive in images and dumps as usable credentials.

Where secrets hide in backups and snapshots

The Secret Sprawl Measurement Guide counts surfaces such as repositories and chat; backups multiply each of them. The table lists the copy types that most often carry usable credentials.

Database dumps deserve a specific check. PostgreSQL documents that pg_dumpall dumps global objects including database roles, and offers a --no-role-passwords option so that role passwords are not written; without that option, the dump carries the stored role password values. Other engines have equivalents, so check how each dump tool treats users and credentials before treating a dump as harmless. Container images share many of these traits; see Secrets in Container Images.

Memory state is a separate risk. Microsoft documents that a Hyper-V standard checkpoint "takes a snapshot of the virtual machine and virtual machine memory state", while a production checkpoint, the default, takes no snapshot of memory state. Other hypervisors offer similar memory options. A memory file can hold credentials that never touched disk, so restrict memory captures to documented troubleshooting and delete them afterwards.

How secrets in copies get exposed

• Public sharing: AWS warns against sharing any RDS manual snapshot containing private information as Public, because public visibility lets all AWS accounts restore it. Public EBS snapshots and AMIs carry the same risk for whole disks.
• Cross-account and cross-project restore: an RDS manual snapshot can be shared with up to 20 AWS accounts; Google Cloud notes that the compute.snapshots.useReadOnly permission is enough to restore snapshot data into a project the principal controls.
• Export URLs: Azure lets an operator export a managed disk or snapshot through a SAS URL, with a default expiry of 3,600 seconds and a maximum of 60 days since 15 February 2025. A URL pasted into a ticket is a bearer credential to the whole disk. See the Azure SAS Tokens Security Guide.
• Stolen backup credentials: in the LastPass Breach 2022 the attacker obtained the cloud access keys and decryption keys for backup storage and read backups of customer vault data. Backups protected by keys that sit in a reachable vault are only as safe as that vault.
• Attacker-made snapshots: ATT&CK T1578.001 Create Snapshot describes adversaries creating snapshots or backups within a cloud account, and T1537 Transfer Data to Cloud Account covers moving data to another account they control, including through sharing and creating backups.
• Restores into weaker environments: refreshing test or analytics systems from production copies brings live production secrets along with the data.

Cloud controls that stop accidental sharing

Platforms are listed alphabetically. Each section lists customer-side settings, based on the provider documentation checked in November 2026, plus practical steps for applying them.

Amazon Web Services

• Block public access for EBS snapshots: a Regional, account-level setting with two modes. "Block all sharing" treats already-public snapshots as private; "Block new sharing" stops new public sharing but leaves existing public snapshots available. It can be set through an AWS Organizations declarative policy, after which accounts cannot change it locally. It does not cover private sharing or EBS-backed AMIs, which have their own block public access setting.
• RDS snapshot sharing: public visibility is available only for unencrypted manual snapshots; encrypted snapshots are private, and snapshots encrypted with the default AWS KMS key cannot be shared. Encrypting with a customer managed key therefore removes the public option.
• AWS Config rules: ebs-snapshot-public-restorable-check (periodic) flags snapshots with RestorableByUserIds set to all; rds-snapshots-public-prohibited (configuration change trigger) flags public RDS DB and cluster snapshots.

Google Cloud

• Snapshot IAM: grant compute.snapshots.useReadOnly and compute.instantSnapshots.useReadOnly only to principals trusted to read and restore the data, since either permission allows restore into a project the principal controls, including in another organisation.
• Separate backup projects: keep snapshot schedules and their IAM in projects with a small administrator set, distinct from application projects.
• Review role grants: include custom roles in the review, because a custom role can carry the read-only use permission without an obvious name.

Microsoft Azure

• Short export lifetimes: keep disk export SAS expiry short (the portal default is one hour; the platform maximum is 60 days) and revoke access with the "Cancel export" action or the revoke-access operation once the copy is complete. The DiskState property shows whether a SAS is active.
• Microsoft Entra ID for downloads: require Entra ID authentication on disk download so Azure checks the caller's identity and Azure RBAC permissions, not just possession of the URL.
• Private import and export: a disk access resource with a private endpoint restricts managed disk import and export to clients on your virtual network through Azure Private Link.

For platform backup services, see the AWS Backup Security Guide and the Azure Backup and Recovery Services Vault Security Guide; the Backup Identity Isolation Guide covers the operator accounts.

How to scan backups and snapshots safely

Scanning a copy means handling everything inside it, so the scan environment must be at least as protected as production.

1. Inventory first: list snapshots, images, dumps and export locations per account, project and subscription, with owner, age, sharing state and retention. Unowned copies older than their retention go straight to deletion review.
2. Build an isolated scan account: a dedicated account or project with no outbound internet, no peering to production and logging of every restore. Restore or mount copies there, read-only.
3. Scan file systems and dumps: run a secret scanner that supports file system targets across the mounted volume and extracted archives, and add your own patterns for internal token formats. Use more than one detector where possible; OWASP recommends correlating results from multiple tools.
4. Check validity, not just presence: for each finding, determine whether the credential is still active (provider key status, last-used data, expiry). A rotated key in an old snapshot is low risk; a live key is an incident.
5. Sample, then widen: start with the newest copy of each golden image and each production database, then the oldest retained copy, then shared or exported copies. That brackets the time range of exposure.
6. Tear down: destroy restored volumes after the scan and keep only the findings report, with secret values masked.

Rollback and safety: scanning is read-only, but remediation is not. Never delete a copy that is the last good restore point until a newer clean copy has been tested; see the Backup and Recovery Testing Checklist.

Deciding what to do with a finding

Small versus large organisations: a small team can scan every golden image and the latest backup of each production database quarterly and rotate anything live. A large estate should scan images in the build pipeline, scan new snapshots on a sample basis, and rely on short-lived credentials so that old copies hold expired secrets by design. See Dynamic Secrets and Ephemeral Credentials Guide.

Preventing secrets from entering copies

• Fetch at runtime: applications read secrets from a secrets manager or workload identity at start-up rather than from files on disk, so disk snapshots hold references, not values. The Secrets Management Guide covers the patterns.
• Build images clean: OWASP warns against hardcoding secrets with Docker ENV or ARG; the same rule applies to VM image builds. Scan images before publishing.
• Dump without credentials: use options such as --no-role-passwords for PostgreSQL globals, exclude credential tables from analytics extracts and mask secrets in non-production refreshes.
• Prefer application-consistent captures: use production checkpoints or equivalent, so memory is not saved unless there is a documented reason.
• Encrypt with keys the copy's readers cannot reach: CP-9(8) in NIST SP 800-53 calls for cryptographic protection of backup information; key custody is covered in the Database Backup Security Guide.

Where identity fits

Two identity questions decide the blast radius. First, which non-human identities can create, copy, share or restore snapshots: backup service roles, automation accounts and disaster recovery pipelines often hold these rights across every account. Second, which credentials found inside copies belong to non-human identities that are rarely rotated, such as service account keys and integration tokens. Treat snapshot permissions as privileged access, review them with your other entitlements and link each finding back to the owning identity in your NHI inventory.

Detection and measurement

Log and alert on the actions that move a copy out of its owner's control:

• Sharing changes: snapshot and image attribute changes that add accounts or make a copy public, and any change to block public access settings.
• Copies and restores in unusual places: copy or restore of snapshots into accounts, projects or Regions outside your list; new snapshots created by identities that do not normally create them (ATT&CK T1578.001).
• Export activity: disk export SAS generation in Azure and downloads of snapshot data, with the caller identity.
• Configuration compliance: the AWS Config rules above, and equivalent policy checks in other clouds, as standing controls.

Common failure patterns

• Rotation without retention review: a key is rotated after a leak, but an unrotated older key remains valid inside a retained snapshot.
• Golden image with a baked credential: one secret in a base image appears in every instance and every snapshot taken from them.
• Export URLs that outlive the task: a long-lived SAS URL for a disk is shared in a ticket and never revoked.
• Backup keys stored next to the access they protect: as in the LastPass case, the keys for backups sit in a vault reachable from a single compromised person.
• Test refresh from production: production connection strings and API keys land in a test system with broad developer access.
• Scanning in production: mounting copies into a shared tools account spreads the secrets further.

Framework mapping

Practitioner checklist

• Inventory snapshots, images, dumps and exports with owner, age, sharing and retention.
• Enable snapshot and image block public access in every account and Region, enforced centrally.
• Restrict snapshot read and restore permissions to a small set of named identities.
• Keep disk export URLs short-lived, require identity-based download and revoke after use.
• Scan golden images and the newest and oldest production backups in an isolated account.
• Check each finding for validity and rotate live credentials by exposure level.
• Dump databases without credential values where the tool allows it, and mask secrets in test refreshes.
• Move applications to runtime secret retrieval so new copies hold no values.
• Alert on sharing changes, cross-account copies and unusual snapshot creation.

Standards and references

• OWASP: Secrets Management Cheat Sheet
• MITRE ATT&CK: Modify Cloud Compute Infrastructure, Create Snapshot (T1578.001)
• AWS: Block public access for Amazon EBS snapshots
• AWS: Sharing a DB snapshot for Amazon RDS
• Google Cloud: Best practices for disk snapshots
• Microsoft Learn: Download a Windows VHD from Azure
• Microsoft Learn: Using checkpoints to revert virtual machines
• PostgreSQL: pg_dumpall

Related NHI Mgmt Group resources: Secret Sprawl Measurement Guide · Directory Listing and Exposed Backup Files Guide · Backup Security and Immutable Backup Guide · Crash Dumps and Core Dumps Guide