VMDK Data Recovery After an Akira Ransomware Attack
VMDK Data Recovery
Environment:
VMware estate backed up by Nakivo to a 12-bay Synology RS3621RPXs, RAID 5, BTRFS
Attack:
Akira ransomware
Data at Risk:
Approximately 11TB of virtual machine backups encrypted, the remainder deleted
Complication:
Roughly 15TB written to the same volume the day after the attack
Result:
99.91 percent recovered on the priority database server
A multi-site enterprise organization experienced an Akira ransomware attack that disrupted access to critical virtualized systems and placed significant portions of its production environment at risk. Approximately 11TB of virtual machine backups held on the customer’s Nakivo repository were encrypted. The remaining backups were deleted.
The same attack encrypted the production virtual machines, leaving the organization without the data needed to restore business operations.
Within days, the organization engaged their cyber insurance carrier and an incident response firm. Conventional restoration methods returned portions of the environment, but could not recover several priority virtual machines. The incident response firm escalated to DriveSavers Data Recovery to determine whether usable data could still be recovered from the affected storage, and whether damaged virtual machine disks could be reconstructed.
By the time the drives reached DriveSavers, ransomware encryption was no longer the only problem.
Engineering analysis using our proprietary virtual disk recovery tool identified approximately 15TB of data written to the volume the day after the attack—after the Nakivo backups had already been deleted. Those writes proved consequential.
Deleting a file on BTRFS does not erase its contents. Filesystems of this kind typically mark the affected blocks as available for reuse while the data itself remains in place until something is written over it. The writes performed after the attack were allocated to blocks that the deleted backups occupied.
Further engineering analysis indicated that substantially more of the targeted information, and potentially all of it, could likely have been recovered had the affected storage remained unchanged.
The volume that arrived at DriveSavers therefore contained a mixture of original intact data, ransomware-encrypted data, deleted and reallocated data, newly written information, damaged filesystem structures, and blocks that had been partially overwritten. Approximately 3,600 files totaling 16.1TB remained active, 99% of which were VMware virtual disks and snapshots with extensions rewritten to .AKIRA.
One characteristic of the attack improved the outlook. The encryption algorithm used in this incident did not encrypt whole files. It encrypted approximately 15% of each file in three bands, which on the large VMDKs presented as roughly 5% front-end encryption. Substantial regions of every virtual disk therefore remained intact. Block-level analysis was required to identify those intact regions.
A remote evaluation confirmed the project scope and was used to determine whether recovery could be completed remotely or would require in-lab work. Recovering this data meant reading all twelve drives at the sector level, including regions the filesystem no longer referenced, and remote access to a running NAS generally reaches the logical volume rather than the underlying physical media. Remote recovery was not possible. An engineer collected the drives at San Francisco International Airport on the following Sunday evening.
All twelve drives were imaged within 24 hours of arrival, and every subsequent operation ran against those images. The original media remained as received throughout, which preserved the evidentiary state while analysis proceeded.
Scanning approximately 120TB one image at a time would not have been viable. Engineers divided the work into terabyte ranges and ran ten scans simultaneously, which brought throughput to the limits of the hardware itself. A second set of images was subsequently built on a second system so that extractions could proceed on both machines concurrently.
As data was deleted, BTRFS had begun clearing the layer that maps stored data to its physical locations. About 7TB of that map was affected, producing unusable output from otherwise readable storage. Engineers determined that the affected regions had been contiguously allocated before deletion, which made manual reconstruction possible. Rebuilding the map by hand restored access to roughly 5TB of backup data that the filesystem had already released.
A damaged VMDK file is rarely simply readable or unreadable. Engineers separated intact regions from those that were encrypted, corrupted, partially overwritten, or structurally damaged. The three highest-priority machines carried five or six restore points each, the most recent taken shortly before the attack, for a total of 35 VMDK files. Damage affected 3–5% of each of those files. On one of the three, the encryptor had not reached the virtual disk files at all.
Where backup data alone did not cover a dataset, engineers merged in the unencrypted regions of the production virtual disks. That approach was effective, though it required caution. Two of the three priority machines also carried snapshot files, which have no one-to-one relationship with the data they represent. The structures that mapped the snapshot files to the data they represented were located within the encrypted regions. Using the production virtual disks to fill gaps could therefore introduce older data and produce corruption that would be difficult to trace afterward. Engineers assessed the risk to each dataset rather than merging by default.
DriveSavers collaborated with the IR firm and the client to establish in advance which environment the disks would be imported into. Extracted file-level data was returned first over the network, so the customer could access specific files while the remaining work continued. Whole VMDK files suitable for reimport followed.
DriveSavers ran the engagement as seven separately scoped sub-engagements with multiple engineers working in parallel, so the highest-priority systems could be worked and returned ahead of the remainder of the environment.
DriveSavers advised the incident response firm and the customer throughout that reconstructed VMDKs could not be guaranteed to boot. At least one recovered virtual machine booted. The remainder were returned as recovered data and repaired disks.
Each repaired virtual disk was accompanied by a block-level report identifying which regions of the disk were sound and which carried unrecoverable damage, with object, file, directory and byte counts for each. For technical teams rebuilding an environment, that type of reporting provides considerably more information than a designation of recovered or not recovered. It lets administrators assess the quality of a recovered image and determine whether additional application-level recovery, file extraction, or rebuilding is needed.
When a backup application cannot complete a restore, the underlying data may still be present on the storage. This repository had been encrypted, emptied, and then written over before it reached a recovery specialist, and block-level reconstruction still returned the systems the business needed most.
Recovering virtual machine data under those conditions requires specialized knowledge, proprietary tooling and custom development against the specific filesystem involved. When ransomware hits production systems and backup infrastructure at the same time, specialized ransomware data recovery can provide a technical path that conventional restoration cannot.
Facing a similar situation? Contact DriveSavers at 1 (888) 282-2227.
English (United States) 
English (Australia) 
French (France) 
English (UK) 
French (Canada) 
English (Canada) 
Spanish (Mexico) 
German 
Dutch 
Italian 
Finnish 
Polish 
Norwegian 
Swedish 
Danish 
Spanish (Spain) 
Chinese 
Japanese 
German (Austria)