Akira Ransomware Recovery Service: Decryptor Status, Real Cases and What's Recoverable

Akira emerged in March 2023, with suspected ties to former Conti affiliates. Its most common entry point is brute-forcing Cisco VPN devices that rely on single-factor authentication, alongside known VPN and firewall vulnerabilities (including CVE-2019-6693 and CVE-2022-40684). By late September 2025 the group had claimed about $244 million in ransom proceeds, according to the joint CISA / FBI advisory updated on November 13, 2025.

We have worked on Akira cases ourselves — an SAP-on-Oracle database and a Veeam backup among them. This page explains what Akira does to files and what that means for recovery, using what we actually measured.

The original Akira, written in C++, appends a .akira extension and drops an akira_readme.txt ransom note; it was built on Conti V2 source code, and a free decryptor for this early variant was released by Avast in June 2023. A rewrite in Rust followed within months, distributed as megazord.exe and switching to a .powerranges extension — a different encryption implementation that the earlier decryptor does not address.

The newer Akira_v2 uses .akira, .powerranges, .akiranew or .aki, with fn.txt or akira_readme.txt as the ransom note. Linux builds target VMware ESXi hosts, and in June 2025 Akira encrypted Nutanix AHV virtual machine disks for the first time. The extension your files carry is the first clue to which variant you are dealing with — and whether any public decryptor applies at all.

For the Akira versions seen in attacks today, no public decryptor works, and paid "Akira decryptor" offers online are usually scams. That does not mean the data is lost: Akira often encrypts large files only in part, and the parts it did not encrypt can be recovered without the key.

We built our own tools for exactly this. AS Ransomware Analysis Studio identifies the Akira variant and measures which parts of each file are encrypted; AS VBK Recovery Studio rebuilds Akira-encrypted Veeam backups; AS SQL Recovery & Repair Studio recovers the tables of encrypted SQL Server databases. The real cases below were recovered with them.

Akira uses hybrid encryption: a ChaCha20 stream cipher for the data, with the key protected by RSA. Properly implemented, that cannot be broken. But Akira chooses full or partial encryption depending on the file's type and size, and on large files — databases, virtual disks, backup files — partial encryption is common: only some regions of the file are encrypted, the rest is left as it was.

That is where recovery comes from. The unencrypted regions still hold real data. Whether it can be used depends on what was hit: if the encrypted regions destroyed the structures that describe the file (a database's catalog, a backup's metadata), the data has to be rebuilt or carved instead of simply opened.

A customer's Veeam full backup of a server (.vbk, 43 GB, renamed .vbk.akira) would not open in Veeam. Measured directly, the first part of the file was encrypted: at least the first 64 MB, with the file header, both snapshot slots and the first metadata banks. The backup was compressed, so every data block carries its own checksum.

Newer Veeam backups keep further generations of their metadata tables deeper in the file, and in this backup they had survived about 42 GB in. AS VBK Recovery Studio found and read them, rebuilt the map of the virtual disk, and placed the tables whose index pages were lost by their content, guided by the NTFS file table inside the disk. The result was the server's 466 GB virtual disk with both volumes: C: (199 GB) and D: (266 GB, the data volume with accounting and database files). Of 142,624 data blocks, 140,143 were verified intact; 2,481 blocks (about 2.6 GB) were lost to the encryption.

The rebuilt disk was exported as a VHDX file. Windows mounted the D: volume read-only and reported it healthy; C:, whose system files lay partly in the encrypted region, is browsed and saved in the program itself. In a check with independent reader software, 354 of 412 sampled files opened correctly. Files that had blocks in the encrypted regions are damaged or missing: this is recovery of what Akira left, not decryption.

Not every Akira-hit backup goes this way. Another Akira-encrypted backup we examined had been made without compression and had no surviving metadata anywhere; there only file carving is possible, without the original names and folders. The free edition of the program shows which situation yours is before you buy anything.

A healthcare technology company's SAP-on-Oracle environment was hit by Akira, which encrypted the production database — its Oracle export (DMP) and datafiles, around 2.5 TB in total. We worked directly from the encrypted Oracle files and recovered and repaired the database back to a consistent, working state.

We recover data from Akira-encrypted SQL Server, Oracle and SAP databases, VMware ESXi and Hyper-V virtual disks, Veeam backups and file servers, remotely for clients anywhere or in our lab in Tamil Nadu, India. You send copies of a few encrypted files; the free assessment tells you exactly what will be recovered before any work starts, and if nothing can be recovered you pay nothing.

Choose the speed you need: 24/7 emergency (1 to 3 business days, a team working around the clock), urgent (3 to 7 business days) or standard (7 to 14 business days). Call or WhatsApp us to start.

Isolate the affected systems, but do not wipe, reinstall or "clean" anything yet, and do not run random decryptors on your only copy. Keep the ransom note and a few encrypted files together with, if you have them, unencrypted copies of the same files from before the attack — comparing the two shows exactly how the files were encrypted.

Then establish what is really recoverable before deciding anything else: which variant it was, how much of each important file (databases, virtual disks, backups) was encrypted, and what the surviving regions still contain. That assessment is what we do first in every Akira case.