Ransomware and data encryption: a bit of history
For years, criminals operating under ransomware attacks have been encrypting victims’ files directly from Windows operating systems. The effort of ransomware distribution has always been quite high, considering that during the final stages of the attack, the fastest and most effective method possible must be adopted.
The difficulties that can be encountered during this last phase, the most critical for those on the other side of the fence, are many, such as:
- Servers down (failure or maintenance)
- Antimalware/EDRs that block ransomware execution
- Network problems or interruptions
- Being discovered by the company or the SOC, if any.
For these reasons, during the past two years, various criminal groups have begun to develop and distribute to their affiliates new versions of their ciphers that also include Linux versions and with them VMWare ESXi hypervisors.
In this way, once the criminals obtain the credentials of the virtualization infrastructure, they turn off the Virtual Machines (VMs) and execute the ransomware directly from the virtualization hosts.
This encryption methodology, while much faster and more effective, fortunately has another side of the coin that can sensitively help victims.
Encryption and data recovery: premises
Encryption algorithms, while optimized and widely used, are extremely effective but also slow on large amounts of data. For this reason, developers have considered encrypting only a portion of VMDK files, often between 30 and 50 percent of the totality.
Usually the initial part of the disk where the partition information resides is encrypted, and depending on the type of ransomware and the algorithms adopted, portions of the disk are encrypted every few Mb/Gb.
Depending on how the data are arranged on disk, the type of data and the size of the disks/space used, file recovery can be attempted within VMDK disks.
Recovery can be carried out in two ways:
- by manually searching the MFT file traces of the NTFS file system where the file/folder information resides on disk and its location, and by manually rebuilding sector 0;
- by carrying out the carving of the files.
In the first case, if everything goes as it should, it is possible to reconstruct the volume and “browse” through its contents using special tools, thus keeping the original file names. In the second, you need to know exactly what type of files to recover (extensions) in order to create special signatures for each type.
Signatures include the header and footer of a file, and data recovery software goes in search of the pairing, thus recovering in a “raw” way everything that was found. While it is true that all files have a header, not all, however, have a footer, this is because those who developed certain software/files designed the structure differently, thus not having a “static” mode but a more dynamic one.
Thus, in the case of carving, it is not possible to trace the original names of the recovered files, considering that no table (MFT) is present and the recovery software proceeds in a more low-level mode.
Data recovery: analysis
During a recent engagement, a major company in the engineering industry commissioned Cyberoo Docetz* to recover data from its virtual disks (VMDK files), which had been previously encrypted through the execution of Akira ransomware by malicious actors.
*Cyberoo Docetz is CYBEROO’s Business Unit that focuses on guiding companies through the Cybersecurity process through services such as Incident Response, VA/PT, Risk Assessment, etc.
After an initial discussion with the customer, VMDK disks were copied from local data stores and put on dedicated external USB disks, then shipped to Cyberoo Docetz to assess the feasibility of recovering data and, if so, to proceed accordingly.
The customer delivered to Cyberoo eight VMDK disks encrypted with Akira ransomware and partitioned MBR/GPT:
| DISK | FILE SYSTEM | DIMENSION |
| Disk 1 | NTFS | 1,5 TB |
| Disk 2 | NTFS | 3,00 TB |
| Disk 3 | NTFS | 700 GB |
| Disk 4 | NTFS | 150 GB |
| Disk 5 | NTFS | 130 GB |
| Disk 6 | NTFS | 100 GB |
| Disk 7 | NTFS | 350 GB |
| Disk 8 | NTFS | 150 GB |
All VMDK files had been renamed with .akira suffix.
Data recovery: process
Cyberoo Docetz manually analyzed each individual VMDK file, searching for the MFT file and, if positive, reconstructing sector 0.
After processing, having found a good validity rate of the MFT file of the Windows operating systems, the original tree was reconstructed and a good amount of the data within could be extracted.
Figure 1 – Screenshots of 4 disks opened with industry standard software
As can be seen from the image above, which is an excerpt, the numbers of files that could be extracted from the encrypted VMDKs and delivered later to the client are shown in parentheses.
On the other three virtual disks (the larger ones), the partition could not be recovered; therefore, carving was attempted with poor results, as the types of files requested by the client that were saved on these disks adopt a particular structure and the footer could not be determined with certainty.
Figure 2 – EExtract of a retrieved MFT record
Figure 3 – Sector 0 of an encrypted disk
In the figure above, obtained by opening a VMDK file using a hexadecimal editor, you can see the randomness of the (encrypted) data.
Akira ransomware data recovery: conclusion
Analysis of this kind suggests that in some cases, when ransomware runs outside of endpoint operating systems and thus directly impacts virtual machine disks on data stores, there is a possibility of recovering some of the contents of those disks, also considering the fact that ransomware often does not perform encryption on the entire file, but depending on the type encrypts only parts of the file, in a predetermined pattern.
