24/7 ransomware incident response - Dubai & United Arab Emirates +971 52 758 9336
Recovery

When the backups are encrypted too

Attackers know the backup is your plan B. That is why it is usually the first thing they encrypt, and why "our backups are gone" is rarely the whole story.

A-Lab briefing · 6 minute read · For IT managers and backup administrators

In almost every enterprise incident we see, the backup repository was encrypted before the production servers. The intruder had domain administrator rights for days, found the Veeam server or the NAS holding the backups, and dealt with it first. Shadow copies were deleted with a single command. Then the encryptor ran everywhere else. The organisation discovers the attack and the loss of its safety net at the same moment.

Why encrypted backups are often recoverable

Backup files are large. A Veeam full backup (.vbk) can be hundreds of gigabytes; a Hyper-V virtual disk (.vhdx) or a SQL Server data file often runs into terabytes. Modern encryptors do not encrypt files of that size completely, because it would take days and would be noticed. Instead they use intermittent or partial encryption: the first megabytes, then a block every few megabytes, or a fixed percentage of the file. The rest is untouched.

For a document, losing the first megabyte means losing the document. For a backup container or a database, the first megabyte is the header and index, and the content behind it is largely intact. The laboratory's work is to rebuild that structure: reconstruct the container format, locate the intact data blocks, and extract the virtual disks, databases and files they hold.

What we work with

  • Veeam Backup & Replication: .vbk full backups, .vib / .vrb incremental chains, damaged .vbm metadata, repositories on NAS or deduplication appliances.
  • Hyper-V and VMware: encrypted .vhdx, .vhd, .vmdk and flat files, checkpoint and snapshot chains.
  • Databases: Microsoft SQL Server .mdf / .ldf / .bak, MySQL and MariaDB InnoDB files, PostgreSQL clusters, Oracle data files.
  • Other backup formats: Windows Server Backup, Acronis .tib / .tibx, Commvault, Veritas, NAS snapshots, LTO tape.

What not to do

  • Do not delete encrypted backup files to "free space". They are your best source.
  • Do not start a new backup job to the same repository. It will overwrite recoverable blocks.
  • Do not run repair utilities from the backup vendor against encrypted files. They expect valid headers and can make things worse.
  • Do not restore from an older backup onto the affected storage until the encrypted data has been imaged.

What to send the laboratory

A listing of the repository (file names and sizes), the ransom note, and if possible the first 50 MB of one encrypted backup file plus a small encrypted document from the same attack. From that we can usually confirm the family, the encryption pattern and the probability of successful reconstruction before any hardware is moved.

Typical outcome. In partial-encryption cases the majority of virtual machines and databases inside an encrypted backup chain are recovered to a bootable or mountable state. The recovered data is verified with you before payment.