WhatsApp 
Recently, an IT company in the south of the Netherlands contacted us urgently after being affected by an attack by the Akira ransomware.
The all-too-common scenario began with the massive encryption of files on their VMware ESXi infrastructure, followed by an abrupt server crash in the middle of the encryption process.
Given the extent of the damage, the decision was made to pay the ransom, in the hope of quickly recovering the data… But, as is often the case with hacker groups, the promise of a straightforward recovery fell short again!
Indeed, despite the delivery of an official decrypter by the attackers, several large files refused to be decrypted.
The decryptor crashed or produced partially corrupted files. At the same time, the NAS containing the critical backups was still unavailable, as it was still being processed by a data recovery company.
According to the information gathered, the hardware had probably been sent abroad, which is why delays were so long.
The attacked company’s IT partner then copied the encrypted VMDK files directly from the ESXi datastore to an external hard disk. These files were then forwarded to us for further recovery.
As you can imagine, the situation was tense: production halted, backups inaccessible, and the decryptor partially inoperative. We had to act quickly and methodically!
Learn more about Akira ransomware on our dedicated site, SOS Ransomware.
A first lead: VBK files on the NAS
A first analysis focused on .vbk files, i.e. Veeam backups that had been recovered from the NAS by a colleague. His report was optimistic: all files were rated as “good”. However, our own test tool tells a very different story…
In fact, only three files were found to be usable. These were incremental files, very small in size (less than 10 MB), all password-protected by Veeam. We were able to extract the list of virtual machines contained in one of them, but were unable to recover any exploitable data. Beyond 5% of the structure, all we find are incoherent, unusable blocks.
An unreliable decryptor and damaged files
At the same time, we launched a series of tests on the encrypted VMDK files. The situation is particularly complex, as the ESXi server, the initial target of the attack, no longer restarts. This means that Akira’s encryption executable – the ransomware itself – is no longer accessible, making it impossible to restart any operation from the source system. On the other hand, we do have the decryptor supplied by Akira, together with a decryption key.
Here are the instructions provided by Akira:
unlocker.exe -p=”path_to_unlock
unlocker.exe -s=”C:\paths.txt”
where “paths.txt” is a list of paths for the decryptor, each path on a new line
ESXi commands:
- chmod +x unlocker
- ./unlocker -p=”/vmfs/volumes”
The tool restores a first file without difficulty. But as soon as the second file is restored, the process fails. Analysis reveals that the files concerned do not have an Akira footer, i.e. the signature added at the end of an encrypted file, which is necessary for the decryptor to function correctly. It also appears that the encryption was interrupted in the middle of certain zones, probably due to the sudden crash of the server. As a result, the official decryptor doesn’t know how to handle these partially encrypted files, and abandons them in error.
The cybersecurity company involved in this case then tried to contact the cybercriminals for technical assistance. To no avail. The Akira forums on the darkweb are now closed, and there seems to be no response from the group. As one analyst from the cyber cell involved put it, not without bitterness: “Our ‘lazy bastards’ are already sunbathing by the pool, mission accomplished”.
The choice of an in-house, tailor-made solution We decided to take matters into our own hands and take a close look at how the decryptor worked. After several hours of analysis, we were able to identify the encryption mechanism used. We note in particular that the process relies on keys that have to be extracted manually, and that the file structure is altered in a non-homogeneous way, due to the server’s unexpected shutdown. Each file therefore has a different signature, with non-standard encryption ranges.
With this in mind, we decided to develop our own decryptor. The objective is simple: to dynamically adapt our tool to the specificities of each file, by identifying the encrypted zones, reconstructing the data blocks and manually injecting the necessary keys. After a conclusive POC test on a sample file, we proceeded to decrypt all the files supplied.
Result: files recovered in less than 48 hours
Less than two days after the start of our intervention, we were able to deliver all the decrypted files to our customer. This solution, developed entirely in-house, proved not only faster, but also more reliable than the initial option of waiting for the NAS to return. It enabled targeted, controlled and, above all, guaranteed recovery.
The fruit of a collective success
This case shows, once again, that paying a ransom, in the case of ransomware, never guarantees complete recovery. It also illustrates the importance of human and technical expertise in dealing with complex situations, where the tools provided by attackers fail.
We would like to thank all the teams involved – technical, sales, IT partners and cybersecurity specialists – who worked tirelessly to achieve this result. This case reminds us that, when it comes to cyber resilience, there’s strength in numbers!
Are you a victim of ransomware? Don’t wait to contact our teams! We are mobilized 24/7/365 to fight cyber risks…
