📦 Decryptor, detections and the full case files are in the Source repository. Samples use password infected.

Key findings

• The encryptor seeds a fresh Yarrow-256 generator for every key with one thing only: the machine’s uptime counter, written as a decimal string.
• That turns “guess a 128-bit key” into “guess when the file was encrypted, to a few milliseconds”. The operator’s RSA key is never needed.
• In a blind test on a freshly reverted VM, we recovered all four real files (a PDF, a DOCX and two PNG screenshots) byte-for-byte, SHA-256 identical, using only what an incident responder would have. Three took about 30 minutes each; one timing outlier needed a second, 21-minute pass.
• A second, fully independent run repeated the test on files the analyst picked and we had not seen, with every recovery rule fixed before encryption. Six of seven in-scope files came back SHA-256 identical in about 25 seconds each. For the seventh, a 482 KB PDF, the frozen tool found its main keys but not the key for its ChaCha8-encrypted middle.
• A second build (988776358d0e…) generates its keys the same way. The unchanged decryptor recovered six of its seven in-scope files hash-exact, again in about 25 seconds each, and stopped on a large PDF at the same point.
• Both PDFs are now recovered hash-exact. Their keys were inside the search window all along; the generic check simply cannot recognise compressed data. A PDF-aware check, added to the decryptor after the runs, closes the gap: 7 of 7 in-scope files on each build are recoverable. The blind scores stay 6 of 7, because the frozen tool did not have it.
• It works best on a machine that has not been rebooted, or from a memory image. After a reboot, the first file becomes a multi-day search.

How this page is organised. Part I (sections 01–08) is the story: what the sample does, where its cryptography breaks, and how we got real files back. Part II (sections 09–18) is the full reverse engineering behind it: every function, structure, constant and measurement, with the addresses to check them yourself. Sections 19–21 hold the indicators, detections and downloads.

Part I · The story

01 · A self-contained C++ encryptor that calls itself Akira

The binary is a 64-bit Windows executable written in modern C++ (C++20 coroutines on the asio I/O library), with the Nettle crypto library compiled in. It brands itself Akira: .akira extension, akira_readme.txt notes and Akira onion addresses. This build has no command-and-control, no persistence and no data theft. It encrypts and leaves. The data theft its note claims is not done by this file.

Every finding in this post comes from our own static analysis in Ghidra and controlled detonations under x64dbg in an isolated VM: six runs of this build and one of a second build. Each cryptographic primitive was re-implemented in Python and matched against data captured from the running sample.

02 · From launch to .akira in six moves

1. Reads its targets from --encryption_path=, a share list (--share_file=), or, with neither, a sweep of the first five drive letters. -localonly skips network shares. A bare -p is silently ignored, which turns a targeted run into a whole-machine run.
2. Opens an operator log named Log-DD-MM-YYYY-HH-MM-SS.txt in its working directory.
3. Deletes Volume Shadow Copies by asking WMI to start a hidden powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject". The PowerShell process appears as a child of WmiPrvSE.exe, not of the ransomware.
4. Frees locked files with the Restart Manager, force-closing whatever holds them while sparing a built-in list of 20 system processes.
5. Drops akira_readme.txt in each folder it enters, then hands files to a pool of encryptor threads (two on our 2-CPU VM).
6. Encrypts each file in place, appends a 512-byte RSA footer and renames it to name.akira. A temporary name.arika journal lets an interrupted file be resumed and is deleted afterwards.

03 · Strong ciphers, fed by a stopwatch

Each file gets four fresh 16-byte values, generated back to back: key1, iv1, key2 and iv2. Each value comes from its own new random generator, and every generator is seeded the same way.

Key generation, per file. Everything below the first row is sound cryptography. The first row decides everything.

Three modes, chosen by extension and size

The sample rarely encrypts a whole file. It reads the file in 0xFFFF-byte chunks. The first and last chunk of each encrypted region use KCipher-2, and the chunks in between use ChaCha8.

04 · A 128-bit key with a few thousand possible values

The uptime counter ticks ten million times a second. If you know when a file was encrypted to within one second, there are only 10⁷ possible seeds for each key, and every seed gives exactly one key. If you know it to within a few milliseconds, there are tens of thousands.

The four values of a file are also generated in a fixed order and very close together. On our test VM, consecutive seeds were about 0.4 ms apart (median 4,121 ticks between key2 and iv2; 20 of 21 files under 8,000). So once you have one value, the next is never far away. Section 17 shows how we measured this without disturbing the sample.

Why the RSA layer does not help the attacker here

The RSA-4096 footer protects the keys from anyone without the operator’s private key. But we never need to open it. We rebuild the keys from the same uptime values the sample used, so the strong outer layer is simply bypassed.

05 · Decryption in plain English

Guess the uptime at the moment a file was encrypted and you can rebuild that file’s keys. Many files only need key2 and iv2: at the default 50%, a Spot-mode file under about 250 KB is encrypted in at most two chunks, and both use KCipher-2.

1. Narrow down when the file was encrypted. On the still-running victim machine, read its clock and its uptime counter at the same moment to learn how one converts to the other. The encrypted file’s “last modified” time then gives its uptime at encryption to within a few milliseconds.
2. Guess the key. Try every uptime value in that window, about 90,000 candidates for a 9 ms window. Each candidate rebuilds a key exactly as the ransomware did.
3. Guess the companion value. It was made about 0.4 ms after the key, so for each key candidate try the next few thousand uptime values. That is roughly 380 million pairs in total.
4. Check each guess. Every PDF starts with %PDF-1., every PNG with the same 16 bytes. Decrypt the first few bytes with each pair; the pair that produces the right header is the right one.
5. Decrypt the file. Replay the sample’s own chunk plan with the recovered keystream, strip the 512-byte footer, and the original is back byte for byte.

Steps 2–4 are the slow part. In pure Python they took about 30 minutes per file on our 20-thread analysis host. With the optional compiled engine (pip install numpy numba) the same search takes about 20 seconds. In the decryptor this is one command:

python akira_decrypt.py recover report.pdf.akira \
    --qpc-offset 134362707471549158 \
    --mtime 134362716175578720 \
    --known-hex 255044462d312e \
    --out report.pdf

--qpc-offset is the clock-to-uptime offset from step 1 and --mtime the file’s last-write time, both as Windows FILETIME values. --known-hex here is %PDF-1.. The values shown are from our run-5 PDF.

If the first pass misses. Occasionally the companion value comes much later than usual (section 06). Run a second pass anchored on the companion instead. On all eighteen files whose keys we have found so far, across both builds, it landed 0.5–1.9 ms before the file’s timestamp, so you can afford to try much larger gaps:

python akira_decrypt.py recover photo.png.akira \
    --qpc-offset 134362707471549158 \
    --mtime 134362716175680085 \
    --anchor iv2 --mtime-window 2.5:0.1 --gap 8001:30000 \
    --out photo.png

Large PDFs need nothing extra. When the generic ChaCha8 check finds nothing in a .pdf, recover retries the same window with two PDF-specific checks (section 18). That took 2–6 minutes per file in pure Python.

06 · Real documents recovered blind, in three runs across two builds

Run 5. For the first test we reverted the VM, placed four real files in a folder, and let the sample encrypt them with no hooks and no breakpoints in its crypto path. Two safety gates stayed in place: the shadow-copy deletion was skipped, and the target folder was confirmed before anything ran. Afterwards we used only what a responder would collect:

• the .akira files and their last-write times;
• one clock reading (system time and uptime counter together) taken on the same boot, after the attack;
• known bytes from the file type, or from the file itself: the standard PNG header, %PDF-1., and for the DOCX the first ZIP header rebuilt from its central directory, which Spot mode leaves unencrypted.

The fourth file: a timing outlier. The first pass searched the whole span from 2 ms before the ransom note to just after the file’s own timestamp, allowing any gap up to 8,000 ticks between the two seeds, and found nothing in 81 minutes. Its seeds turned out to be 26,718 ticks (2.67 ms) apart, almost seven times the usual 0.4 ms. That fits the one outlier we measured earlier (27,109 ticks), on a VM that had been up for only 15 minutes. The second pass searched from the companion value, which still sat 0.93 ms before the timestamp, and allowed gaps from 8,001 to 30,000 ticks. It found the keys in 21 minutes, and the decrypted screenshot was SHA-256 identical to the original.

Run 6: a fully independent re-test

Run 5 had a weakness: we designed the second pass while solving its fourth file. So we ran the whole test again, with three changes:

• Rules fixed in advance. Before anything was encrypted, we recorded the SHA-256 of the decryptor, the search engine and the recovery script, together with the rules they apply: the default pass, an automatic second pass if it misses, and which known bytes to use for each file type. The run log prints the same hashes, so nothing could be tuned afterwards.
• Files we had not seen. After a full VM revert, the analyst chose eight files and placed them in the target folder. The hashes of the originals were sealed before encryption and read only after every file had been processed.
• Nothing in the crypto path. As in run 5, the same two safety gates were applied, then every breakpoint was removed. One clock reading after the attack gave an offset whose seven samples agreed within 7 µs.

What run 6 shows.

• Six of seven in-scope files are hash-exact. All six were found by the default pass in about 25 seconds each, against roughly 30 minutes per file in run 5. That covers every file without ChaCha8 chunks.
• No timing outlier this time. The widest seed gap was 5,570 ticks, so the automatic second pass never ran.
• The timestamp anchor held. The companion value sat 0.55–1.86 ms before each file’s last-write time.
• The JPEG rule worked first time. This run tested it for the first time, and all three JPEGs recovered.
• Two inputs repeat run 5: the DOCX and one screenshot. They were encrypted with fresh keys, and the search uses nothing from a file except its type header, so they still count.

The PDF: a limitation we predicted

The PDF is over 262 KB, so the middle of its encrypted half is ChaCha8, not KCipher-2. We found its KCipher-2 keys in 22 seconds, so the first and last 64 KB of the encrypted half decrypted correctly. The ChaCha8 search tested 24 million candidate pairs. It accepts a key only if the output looks like zeros or plain text, and nothing passed. We flagged this risk in writing before the run. The MP4 was out of scope because no fixed header rule exists for it yet.

A second build, same flaw

A different Akira-branded build, SHA-256 988776358d0e45a4907dc1f4906a916f1b3595a31fa44d8e04e563a32557eb42, was the next test. It is the same C++ codebase recompiled with new string-obfuscation constants, a new victim chat code and its own operator RSA key. We read its code before running it:

• Same random source. It imports no secure random API. Each key and IV still comes from a fresh Yarrow-256 seeded with nothing but the uptime counter, written as a decimal string (FUN_140082c90 in this build).
• Same key set and footer. It draws the same four values in the same order (FUN_140036730), packs them into the same 91-byte blob, and wraps that in the same 512-byte RSA footer.
• Same file handling. It keeps the same ciphers, the same 2,000,000-byte Part-mode threshold and the same command-line options.
• Different hiding. Its shadow-copy command decodes with different constants, ((0x32 − b)·0x2A) mod 0x7F, but it is the same command.

We then repeated run 6 exactly:

• a fresh revert;
• the analyst’s files;
• the original hashes sealed before encryption;
• the same two safety gates, located in this build’s own code (the WMI executor FUN_140078890 forced to return, the root queue FUN_14007ac00 checked);
• no breakpoints during encryption.

Recovery used build 1’s decryptor byte-for-byte unchanged.

The result matches build 1.

• Every file without ChaCha8 chunks came back hash-exact, all on the default pass.
• The timestamp anchor held. The companion value sat 0.9–1.9 ms before each file’s timestamp, and the second pass never ran.
• The large PDF stopped at the same ChaCha8 limit.

Reading the code showed the key generation was the same. This run confirmed what reading code cannot: the chunk layout, the cipher details and the timing all line up.

The two PDFs, recovered afterwards

After both runs we went back to the two PDFs to settle the open question: was the right ChaCha8 key outside the search window, or did the check fail to recognise it? It was the check. Both PDFs’ seeds sat inside the default window, with ordinary gaps of 3,910–4,287 ticks. In the run-6 PDF the whole ChaCha8 region (bytes 65,535–196,605) is one 291 KB compressed page-content stream, and the zeros/text check accepts 0 of 971 genuine 64-byte windows of it.

Once the KCipher-2 chunks are decrypted, most of a PDF’s structure is readable again, which allows two PDF-specific tests (detail in section 18):

Both tests now run automatically inside recover. With them, 7 of 7 in-scope files on each build are recoverable. We still report the blind runs as 6 of 7, because the tool frozen for those runs did not include the fallback, and changing a score after the fact would undo the point of freezing the rules.

Earlier validation

Before the blind test, the decryptor reproduced byte-exact output for real .akira files from all three modes (Spot, Full and a 3 MB Part file). Keys rebuilt from captured seeds matched the keys inside the sample’s own RSA plaintext blob, and a seed off by a single tick produced garbage. An earlier blind run on another file found its seeds from the timestamp alone in 28 minutes. Current test suites: 8/8 built-in checks, 15/15 on real sample output, 29/29 round trips, 3/3 synthetic PDF stage-2 cases.

07 · When this recovery will and will not work

This is a real weakness, but it is a timing attack. Everything depends on knowing when each file was encrypted. Read these before promising anyone their data back.

Critical Do not reboot the victim

The clock-to-uptime offset must come from the same boot the ransomware ran in: a live, un-rebooted machine, or a memory image taken before shutdown (it holds both clocks). After a reboot, Windows only records the boot time to about half a second; on our VM it was 352 ms off. The first file then needs a search window around a second wide, which takes days with our Python tool.

Critical File timestamps must survive

The .akira file’s last-write time is the anchor. Copy files with their timestamps preserved, or record them before copying. Restoring from backup, re-saving, or timestomping destroys the anchor. The search then falls back to the run’s time span, which is far more expensive.

Required Known bytes at the start of the file

The check in step 4 needs at least 7 bytes of plaintext at offset 0. Most document, image, archive and database formats have a fixed header, but plain text and some proprietary formats do not. Video formats such as MP4 have no rule in the tool yet.

Partial Large files: ChaCha8 middle

Spot files over about 262 KB, database files (Full mode) and files over 2 MB (Part mode) also use ChaCha8, which needs key1 and iv1. The generic check accepts a ChaCha8 key only if the output looks like zeros or text. PDFs now have a fallback that needs either objects inside the ChaCha8 chunks or a page-content stream crossing into them; a PDF with neither (for example a binary image stream at the chunk boundary) still fails. Other large compressed files, such as Office documents, archives and video, can come back partly decrypted.

Cost Seconds per file, if the window is tight

Each file needs its own search: about 20 seconds on a 20-thread host with the compiled engine, or 30 minutes in pure Python. The cost grows with the time window. After a reboot (a window of about a second), building the candidate keys alone takes tens of minutes per file. A GPU port would help there, and we have not built one.

Not guaranteed Timing outliers

One of our four run-5 files had its two seeds 2.67 ms apart instead of about 0.4 ms, so the standard search missed it. A second pass anchored on the companion value, with gaps up to 30,000 ticks, recovered it in 21 minutes. In run 6, none of the seven files was an outlier. Busy or freshly booted machines will produce more such files, and an even longer stall would fall outside that second pass too.

Scope Measured on one setup

Seed spacing and timestamp behaviour were measured on one 2-CPU VM running with a 1 ms system timer. A slower or faster CPU shifts the spacing. Hosts at the default 15.6 ms timer tick, and very large files, need wider windows; neither was tested.

Scope Two builds tested

The method is validated on two builds of the same C++ codebase: 101bd45a… and 98877635…. Other Akira-branded encryptors, such as builds from other codebases or later rewrites, may generate keys differently. Check the key generation in the code before relying on this method for another sample.

Scope Operator key path untested

The decryptor can also open the RSA footer with the operator’s private key, should it ever leak. That path is tested only with our own RSA key pair, since the real key is not available.

08 · Preserve the clock before anything else

1. Do not reboot or power off the affected machine. Isolate it from the network instead.
2. Capture memory if you can, then record a clock pair with the snippet below. Run it a few times and keep the median.
3. Collect, with timestamps intact: the .akira files, every akira_readme.txt (its creation time marks when a folder started), the operator’s Log-*.txt, and the System event log.
4. Work on copies, smallest and most important files first.

Add-Type @'
using System; using System.Runtime.InteropServices;
public static class Clk {
  [DllImport("kernel32.dll")] public static extern bool QueryPerformanceCounter(out long c);
  [DllImport("kernel32.dll")] public static extern bool QueryPerformanceFrequency(out long f);
  [DllImport("kernel32.dll")] public static extern void GetSystemTimePreciseAsFileTime(out long ft);
}
'@
$f = 0L; $q0 = 0L; $ft = 0L; $q1 = 0L
[void][Clk]::QueryPerformanceFrequency([ref]$f)
[void][Clk]::QueryPerformanceCounter([ref]$q0)
[Clk]::GetSystemTimePreciseAsFileTime([ref]$ft)
[void][Clk]::QueryPerformanceCounter([ref]$q1)
$q = [long](($q0 + $q1) / 2)
"freq=$f  qpc=$q  filetime=$ft  offset=$($ft - $q)"

With a 10 MHz counter (freq=10000000, the usual value) the offset is simply FILETIME minus the counter, and it goes straight into --qpc-offset. On other frequencies, scale the counter to 100 ns units first. The full collector, collect_clock_and_times.ps1, also records file timestamps, ransom notes and the operator log.

Part II · Technical analysis

Everything below is from our own work on build 1 (101bd45a…) unless marked otherwise. Addresses are static, against Ghidra’s image base 0x140000000; on the VM the image loaded at a different ASLR base on each boot, so live addresses were rebased. Ghidra function names (FUN_…) are kept so you can follow along in your own database.

09 · Static profile

Capabilities, all confirmed in code and most also observed live:

• encrypts local, mapped and UNC paths with a multi-threaded IOCP pipeline;
• deletes Volume Shadow Copies through WMI-launched PowerShell;
• force-closes processes holding target files open, using Restart Manager, sparing system processes;
• hybrid crypto: per-file ChaCha8 + KCipher-2 keys, sealed with an embedded RSA-4096 public key;
• three encryption modes (Full, Spot, Part), chosen by file extension and size;
• a ransom note in every traversed folder.

10 · main() and the thread pools

The CRT entry at 0x1400855b8 reaches main at 0x14004ca40 (FUN_14004ca40). main does all one-time set-up, then hands work to three thread pools. Everything after the pools start is C++20 coroutines on an asio I/O completion port.

1. Logging (FUN_14004c6f0). An spdlog-style file_logger writing Log-%d-%m-%Y-%H-%M-%S.txt in the working directory. The start time is taken with QueryPerformanceCounter at 0x14004d505.
2. Command line (FUN_140053d70). GetCommandLineW and CommandLineToArgvW, then an argh-style parser (section 11).
3. Targets, from exactly one source in priority order: the explicit path, then the share file (FUN_140041fc0), then the drive sweep (FUN_1400766e0). In -l mode the run stops here, after logging the drive list.
4. Pre-encryption steps, run once: skip-list update (FUN_14006ecf0), protected-PID snapshot (FUN_140070c30), shadow-copy deletion (FUN_140071d80 → FUN_140071620). Section 12.
5. Crypto init. The RSA-4096 public key is imported from DER at 0x1400ee010 (FUN_14007ba90 / FUN_140081ac0). The RSA context gets its own Yarrow instance for PKCS#1 padding (FUN_14007bbe0), seeded the same QPC-only way as the file keys.
6. Thread pools (FUN_1400737d0), sized from GetSystemInfo.
7. Root-folder queue (FUN_140073950). Each root is queued here; r8 holds the root as a std::wstring. This was our dynamic safety gate: a breakpoint here showed exactly which root would be encrypted, before any file was touched.
8. Folder parsers (FUN_1400b5fb0, FUN_1400b81d0) apply the exclusions, drop akira_readme.txt (FUN_140042420), set the force-Full and force-Part flags and enqueue each file with FUN_140074480(queue, path, fullFlag, partFlag, ctx, percent, …). The two flags land in task fields +0x49 and +0x4a.
9. Per-file coroutine (FUN_1400ae840), section 14.
10. main waits for the pools, logs the elapsed time (end QPC at 0x14004e06f) and exits. No self-deletion and no persistence.

Thread-pool sizing. With N logical CPUs, N is first doubled when it is below 5 (and treated as 2 when it is 1). Then 30% of N become root-folder parsers, 10% (at least one) folder parsers, and the rest encryptors. A 2-vCPU VM therefore gets 1 / 1 / 2, which matches the two encryptor threads we saw interleave in run 4. The log line Number of threads to encrypt = records the result.

The final log line is the run time in milliseconds. In run 4 it read 423038 ms, which is exactly (main-end QPC − main-start QPC) / 10⁴. That is how we know the sample’s own stopwatch is the same counter that seeds its keys.

11 · Command line and targeting

The parser is argh-style with no registered parameters, so a value must be attached with =. -p C:\x (with a space) is read as a bare flag -p followed by a stray positional argument. The path comes out empty and the sample falls back to sweeping every drive. We saw this live in run 1, which escaped its folder and had to be stopped.

Target classification (FUN_140042c50), per root:

• X: with a mounted local volume → “This is local disk:”.
• X: reported as DRIVE_REMOTE, or a no-root-dir mapped share resolved with WNetGetConnectionW (FUN_1400429f0) → “This is network disk:”.
• A UNC path (PathIsNetworkPathW) → network path.
• Anything else → “Not allowed disk”, skipped.

The drive sweep only reaches five drives. FUN_1400766e0 walks the buffer from GetLogicalDriveStringsW and filters with GetDriveTypeW, skipping CD-ROM and no-root-dir volumes. Its loop is compiled with a fixed bound, cmp rsi, 0x2C, that ends the walk after the fifth drive letter. A sixth or later volume (H: when C:–G: exist) is never encrypted in sweep mode. We confirmed this in the disassembly only, not in a live run.

Exclusions are exact-match lookups in std::set containers built by static initializers:

The set initializers are FUN_1400018a0 (folders) and FUN_140001ac0 (extensions).

12 · Pre-encryption actions

Three steps run once, in this order, before any file is touched. They are skipped in -l mode. Nothing else runs beforehand: no service stops, no event-log clearing, no firewall or boot-configuration changes.

1 · Skip-list update (FUN_14006ecf0). Adds .akira and .arika to the extension skip set, so encrypted and in-progress files are never encrypted twice.

2 · Protected-PID snapshot (FUN_140070c30). WTSEnumerateProcessesW (0x140070c79) lists running processes, and the PIDs whose names match the 20-name protected set are stored. These PIDs are exempt from the Restart Manager kill below.

3 · Shadow-copy deletion (FUN_140071d80 → FUN_140071620).

• A 76-byte stack string is decoded with ((0x39 − b)·0x0B) mod 0x7F into powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject". We confirmed the decoded string in x64dbg memory.
• FUN_140071620 runs it through COM/WMI rather than CreateProcess: CoInitializeEx, CoCreateInstance, CoSetProxyBlanket, then Win32_Process.Create in ROOT\CIMV2. PowerShell therefore appears as a child of WmiPrvSE.exe, which breaks naive parent-child detection.
• The window is hidden through Win32_ProcessStartup, straight from the decompile:

bstrString    = SysAllocString(L"ROOT\\CIMV2");
bstrString_01 = SysAllocString(L"Win32_Process");
bstrString_02 = SysAllocString(L"Win32_ProcessStartup");
...
local_90.n2.vt = 0x13;  local_90._8_4_ = 0;            /* VT_UI4 0  */
(**(code **)(*(longlong *)local_100 + 0x28))(local_100.Lo64, L"CreateFlags", 0, &local_90);
local_78.n2.vt = 0x11;  local_78._8_1_ = 0;            /* VT_UI1 0 = SW_HIDE */
(**(code **)(*(longlong *)local_100 + 0x28))(local_100.Lo64, L"ShowWindow", 0, &local_78);

• FUN_140071d80 then opens the returned ProcessId with SYNCHRONIZE (OpenProcess at 0x140071f50) and waits up to 15 s (WaitForSingleObject at 0x140071f66). The PID is cast to a 16-bit value first, so on a host where PowerShell gets a PID above 32,767 the wait silently fails and encryption starts without waiting for the deletion to finish.
• In every run we forced FUN_140071620 to return immediately, so the VM’s shadow copies survived.

Per file, only when needed: Restart Manager (FUN_140070e30). The per-file coroutine calls this only when CreateFileW fails with error 0x20 (ERROR_SHARING_VIOLATION) or 0x21 (ERROR_LOCK_VIOLATION):

1. RmStartSession, RmRegisterResources on the file, then RmGetList (twice: size, then data) for the processes holding it.
2. If any holder is the ransomware itself or a protected PID, RmEndSession and give up on that file.
3. Otherwise RmShutdown(session, RmForceShutdown) at 0x140071024, which kills the holders (database engines, Office, backup agents), and the open is retried. A file that still fails is logged and skipped.

13 · String obfuscation: an affine map mod 127

Only the three most signature-worthy string groups are hidden. Each string (or table) is decoded byte by byte with its own constants, in the form ((±(b − K))·M) mod 0x7F or (a·b + c) mod 127:

The database list took some work. Ghidra’s decompiler timed out on FUN_140003680 (a huge static initializer), and inline Ghidra scripts were disabled in our setup. So we exported the function’s full disassembly (1.65 MB) and a 40,000-byte .rdata dump, and parsed both on the host. Each table’s key was solved by UTF-16 known plaintext (every entry starts with . and ends with a NUL), then checked against the whole table.

Everything else is plaintext: the log strings, the note, the CLI option names and .akira. Those make good detection anchors (section 20).

.4dd .4dl .accdb .accdc .accde .accdr .accdt .accft .adb .ade .adf .adp .arc .ora .alf .ask .btr .bdf
.cat .cdb .ckp .cma .cpd .dacpac .dad .dadiagrams .daschema .db .db-shm .db-wal .db3 .dbc .dbf .dbs
.dbt .dbv .dbx .dcb .dct .dcx .ddl .dlis .dp1 .dqy .dsk .dsn .dtsx .dxl .eco .ecx .edb .epim .exb .fcd
.fdb .fic .fmp .fmp12 .fmpsl .fol .fp3 .fp4 .fp5 .fp7 .fpt .frm .gdb .grdb .gwi .hdb .his .ib .idb .ihx
.itdb .itw .jet .jtx .kdb .kexi .kexic .kexis .lgc .lwx .maf .maq .mar .mas .mav .mdb .mdf .mpd .mrg
.mud .mwb .myd .ndf .nnt .nrmlib .ns2 .ns3 .ns4 .nsf .nv .nv2 .nwdb .nyf .odb .oqy .orx .owc .p96 .p97
.pan .pdb .pdm .pnz .qry .qvd .rbf .rctd .rod .rodx .rpd .rsd .sas7bdat .sbf .scx .sdb .sdc .sdf .sis
.spq .sql .sqlite .sqlite3 .sqlitedb .te .temx .tmd .tps .trc .trm .udb .udl .usr .v12 .vis .vpd .vvv
.wdb .wmdb .wrk

.vdi .vhd .vmdk .pvm .vmem .vmsn .vmsd .nvram .vmx .raw .qcow2 .subvol .bin .vsv .avhd .vmrs .vhdx
.avdx .vmcx .iso

14 · The per-file pipeline

Each queued file runs through one coroutine, FUN_1400ae840. We confirmed every step live. The excerpts are from Ghidra’s decompile of that function (artifacts/ghidra/FUN_1400ae840_per_file_coroutine.decompile.c in the case folder), lightly cleaned up for reading: casts dropped, NULL and INVALID_HANDLE_VALUE named, comments added.

Open. Read-only is cleared first (attrs ^ 1), then the file is opened for read, write and delete (0xC0010000), OPEN_EXISTING, overlapped (0x40000080). On a sharing or lock violation it calls the Restart Manager routine and tries again:

DVar18 = GetFileAttributesW(pWVar36);
if ((DVar18 != 0xffffffff) && ((DVar18 & 1) != 0)) {
  SetFileAttributesW(pWVar36, DVar18 ^ 1);              /* drop FILE_ATTRIBUTE_READONLY */
}
hFile = CreateFileW(pWVar36, 0xc0010000, share, NULL, 3, 0x40000080, NULL);
DVar18 = GetLastError();
if (hFile == INVALID_HANDLE_VALUE) {
  if ((cVar14 == '\0') && (DVar18 - 0x20 < 2)) {         /* 0x20 / 0x21: file is locked */
    uVar21 = FUN_140070e30(pWVar32);                     /* Restart Manager force shutdown */
    if ((char)uVar21 != '\0') {
      hFile = CreateFileW(pWVar32, 0xc0000000, 3, NULL, 3, 0x40000080, NULL);

Choose the mode. The two flags set by the folder parser decide first, then the size. Right after this, the coroutine reads the clock (FUN_140078dd4) and calls the key generator FUN_140036740:

if (*(char *)(task + 0x49) == '\0') {                       /* not a database extension */
  if ((*(char *)(task + 0x4a) != '\0') || (2000000 < size)) {
    mode = 2;                                               /* Part: VM extension or > 2,000,000 B */
  } else {
    mode = 1;                                               /* Spot: the first percent% */
  }
} else {
  mode = 0;                                                 /* Full: database extension */
}
...
FUN_140078dd4();                                            /* QPC read: per-file start */
uVar22 = FUN_140036740(ctx, keys);                          /* four Yarrow draws + RSA wrap */

(Here the task fields are also renamed: task + 0x49 / + 0x4a are the force-Full / force-Part flags from the folder parser, size is param_1[0xb8].)

The three modes in numbers. Each mode encrypts one or more regions in place, in 0xFFFF-byte chunks. Within every region the first and last chunk use KCipher-2 and the chunks between use ChaCha8.

At the default p = 50, Part mode covers only 40% of the file in four 10% stripes; 60% stays plaintext. Spot mode on a small document leaves its second half untouched. Those plaintext regions are what made the DOCX recoverable in runs 5 and 6: its ZIP central directory sits at the end of the file, unencrypted, and it tells us exactly what the first local header looked like.

Journal. Before encrypting, FUN_1400adb00 creates <name.ext>.arika with CreateFileW(GENERIC_READ|GENERIC_WRITE|DELETE, share R/W, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED) at 0x1400adc3f and writes a 532-byte header. Before and after each chunk, bytes 0–8 are overwritten with a progress record.

Encrypt. Reads and writes go through asio’s overlapped ReadFile (0x140040993, FUN_1400407e0) and WriteFile (0x14004075d, FUN_1400405b0) on an I/O completion port. Each chunk is XORed with its keystream and written back at the same offset.

Seal and rename. FUN_1400b5a20 appends the 512-byte RSA footer at offset = original size. Then the open handle is renamed and the journal deleted:

BVar17 = SetFileInformationByHandle((HANDLE)param_1[0x1a], FileRenameInfo, pvVar37, (DWORD)local_ab8);
if (BVar17 == 0) {
  DVar18 = GetLastError();
  ... "file rename failed. System error:" ...
}
...
if (param_1[0xe1] != 0) {
  pWVar32 = (LPCWSTR)FUN_14003ac10(param_1 + 0xdf);         /* <name.ext>.arika */
  DeleteFileW(pWVar32);
}

On-disk structures.

An encrypted file is therefore always exactly 512 bytes larger than the original, and the original size is recoverable from the file length alone. Because the journal carries the RSA blob and the progress mark, a file caught mid-encryption by a crash or a kill stays decryptable by the operator, and our decryptor can handle it too (--journal). The folder parser skips any file whose .arika already exists, so a restarted run does not encrypt a file twice.

Other artifacts.

• Ransom note: akira_readme.txt, written with std::ofstream into every folder the parsers enter (FUN_140042420). The text is plaintext at 0x1400ef060.
• Operator log: Log-<dd>-<mm>-<YYYY>-<HH>-<MM>-<SS>.txt in the working directory. Typical lines: “This is local disk:”, “Number of threads to encrypt =”, “file rename failed. System error:”, “Failed to make full encrypt! (“.
• Process: a hidden powershell.exe spawned by WmiPrvSE.exe.

Hi friends,

Whatever who you are and what your title is if you're reading this it means the internal infrastructure of your company is fully or partially dead, all your backups - virtual, physical - everything that we managed to reach - are completely removed. Moreover, we have taken a great amount of your corporate data prior to encryption.

Well, for now let's keep all the tears and resentment to ourselves and try to build a constructive dialogue. We're fully aware of what damage we caused by locking your internal sources. At the moment, you have to know:

1. Dealing with us you will save A LOT due to we are not interested in ruining your financially. We will study in depth your finance, bank & income statements, your savings, investments etc. and present our reasonable demand to you. If you have an active cyber insurance, let us know and we will guide you how to properly use it. Also, dragging out the negotiation process will lead to failing of a deal.
2. Paying us you save your TIME, MONEY, EFFORTS and be back on track within 24 hours approximately. Our decryptor works properly on any files or systems, so you will be able to check it by requesting a test decryption service from the beginning of our conversation. If you decide to recover on your own, keep in mind that you can permanently lose access to some files or accidently corrupt them - in this case we won't be able to help.
3. The security report or the exclusive first-hand information that you will receive upon reaching an agreement is of a great value, since NO full audit of your network will show you the vulnerabilities that we've managed to detect and used in order to get into, identify backup solutions and upload your data.
4. As for your data, if we fail to agree, we will try to sell personal information/trade secrets/databases/source codes - generally speaking, everything that has a value on the darkmarket - to multiple threat actors at ones. Then all of this will be published in our blog - https://akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion.
5. We're more than negotiable and will definitely find the way to settle this quickly and reach an agreement which will satisfy both of us.

If you're indeed interested in our assistance and the services we provide you can reach out to us following simple instructions:

1. Install TOR Browser to get access to our chat room - https://www.torproject.org/download/.
2. Paste this link - https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id.onion.
3. Use this code - 6188-EA-ABYW-YGRG - to log into our chat.

Keep in mind that the faster you will get in touch, the less damage we cause.

15 · Cipher internals

Every primitive below was re-implemented in Python and matched against data captured live from the running sample. Those re-implementations became the decryptor.

Two details that cost us time.

• ChaCha’s key size. The key buffer is 32 bytes and the “expand 32-byte k” constant sits right next to “expand 16-byte k” in .rdata, so a 256-bit ChaCha20 is the obvious guess. It is wrong. Key setup is called with kbits = 0x40, which takes the 16-byte branch, and the round loop runs four double-rounds. Only the live keystream comparison settled it. The upper 16 bytes of key1 are never read, which is why recover does not search them and prints them as zeros.
• KCipher-2’s tables. The four α-multiplication tables do not all use one polynomial (amul0 fits 0x1C3). Our first model assumed a single polynomial and failed the RFC vector. We rebuilt all four tables by GF(2)-linearity from the eight basis entries of each table read from the binary.

The 91-byte RSA plaintext.

The RSA context has its own Yarrow instance for PKCS#1 padding (FUN_14007bbe0), seeded the same QPC-only way. That does not help recovery, because the private key never touches the victim. Recovery has to come from the symmetric side, and it can.

The embedded public key. RSA-4096, e = 65537, DER at VA 0x1400ee010. SHA-256 of the DER RSAPublicKey: a40a55f2600b9199181bc6c0778e64b2e75145c4e6f715da6d23a72407539aaa; the modulus begins c2f8f4dbbe7da09f7c991d69e00b4466. It identifies the operator key pair; build 2 carries a different one. Both PEM and DER copies are in the case artifacts/.

16 · Windows API map

Call sites come from Ghidra cross-references to 49 imports; the key ones were checked against their callers and decompiles.

Three imports that look suspicious but are library code:

• TerminateThread (0x1400365e0) is in asio’s thread join. It runs only when asio’s terminate flag is set; otherwise asio queues an APC and waits.
• IsDebuggerPresent appears only on CRT fail-fast paths.
• WSAStartup is asio’s winsock initialiser; no socket is ever created.

For hunting, the useful API sequence is WTSEnumerateProcessesW → WMI Win32_Process.Create → RmShutdown → overlapped ReadFile/WriteFile → SetFileInformationByHandle rename.

17 · Measuring the seeds without touching them

The whole recovery rests on two numbers: how far apart a file’s four seeds are, and how far the file’s timestamp sits from them. Our first captures used a breakpoint on each seed, which inflated the gaps to 10–500 ms and made them useless. Run 4 measured them natively.

An in-process logger on the sample’s own clock. The sample reads the counter through one tiny wrapper, FUN_140078dd4, 25 bytes long:

sub  rsp, 28h
lea  rcx, [rsp+30h]
call [QueryPerformanceCounter]
mov  rax, [rsp+30h]          ; <- tail at 0x140078de3 patched: mov rax, stub / jmp rax
add  rsp, 28h
ret

We overwrote its tail with a jump into a small stub in an RWX allocation. The stub reloads the counter value, takes the caller’s return address from [rsp+28h] and the thread ID from gs:[48h], reserves a 32-byte slot with lock xadd, stores (QPC, caller, TID) there and returns the unchanged value. The cost is a few nanoseconds per call and no debug event. To keep the finished process around long enough to read the buffer, the first two bytes of ntdll!RtlExitUserProcess were patched to EB FE (jump to self).

48 8B 44 24 30 4C 8B 44 24 28 65 44 8B 0C 25 48 00 00 00 49 BA <buf> 41 BB 01 00 00 00
F0 45 0F C1 1A 41 81 FB 88 13 00 00 73 13 49 C1 E3 05 4D 01 D3 49 89 43 40 4D 89 43 48
4D 89 4B 50 48 83 C4 28 C3

The safety gates were armed first (WMI executor forced to return, root folder confirmed), then every breakpoint was deleted. During encryption the debugger log shows thread and DLL events only: no exceptions and no breakpoint hits. Two of the 21 resulting files were decrypted with the logged values × 100 as seeds and came back as their all-zero originals, which proves the hook recorded exactly the seeds the sample used.

What the log showed. 129 counter reads, each caller in its own role:

All 84 seeds increase monotonically, with two encryptor threads interleaving. The gaps, in 100 ns ticks:

The floor of about 3,900 ticks is the time one Yarrow-256 seeding takes on the CPU, so it scales with the victim’s hardware. The rare long gaps come from the two encryptor threads competing for CPU. For key2 → iv2, 18 of 21 gaps were under 5,100 ticks and 20 of 21 under 8,000, which is where recover’s default --gap 3800:8000 comes from.

Timestamps as anchors. Run 4’s 21 files, with their seeds known exactly, let us score every timestamp a responder might have. The live clock offset (precise system time minus QPC, seven pairs agreeing within 12 µs) gave:

The footer write sets the last-write time, just before the coroutine returns. The creation time is the original file’s (the sample overwrites in place) and carries no information. Other anchors from the same run:

After a reboot the offset has to come from boot records, and those are coarse:

The error is one constant per boot, though. Once the first file is solved its seeds pin the offset to about ±2.5 ms, and every other file of that boot costs the same as the live case.

18 · Inside recover

akira_decrypt.py is a single Python 3.8+ file using only the standard library (1,601 lines, SHA-256 091701682454a75dfb57324e29a6270977186f68209a7c3a93178ab76fe9fc4b). It never overwrites a file unless told to (--force).

Without a footer key the tool infers mode and percent the way the sample does: from the extension lists and the 2,000,000-byte threshold. --percent and --mode override this.

The core is short. Regenerate the four values, rebuild the sample’s chunk plan, and XOR each chunk with the right keystream (condensed from the script):

def keys_from_seeds(seeds):                    # key1, iv1, key2, iv2
    out = []
    for s, n in zip(seeds, (32, 16, 16, 16)):
        y = Yarrow256()                         # fresh instance per value
        y.seed(s.encode("ascii"))              # seed = uptime in ns as text
        out.append(y.random(n))
    return tuple(out)

def regions(mode, percent, size):
    if mode == 0: return [(0, size)]                          # Full
    if mode == 1: return [(0, percent * size // 100)]          # Spot
    div, blocks = (3, 2) if percent < 50 else (5, 4)          # Part
    blk = (percent * size // 100) // div
    stride = (size - blocks * blk) // div
    return [(i * stride, blk) for i in range(blocks)]

def chunk_plan(mode, percent, size):            # same order as the sample
    for start, length in regions(mode, percent, size):
        off = 0
        while off < length:
            n = min(0xFFFF, length - off, size - (start + off))
            cipher = "k2" if off == 0 or length <= off + n else "chacha"
            yield start + off, n, cipher
            off += n

ChaChaSample.xor starts every chunk on a fresh 64-byte block, which reproduces the sample discarding partial blocks; the KCipher-2 keystream runs on across chunks.

The search. Every value is the first 16 bytes of one fresh Yarrow draw, so one table of candidate seeds serves all four values.

1. Stage 1, KCipher-2. For each key2 seed in the window and each candidate gap to the iv2 seed, run KCipher-2 over the first ciphertext bytes and compare with the known header. At least 7–8 bytes are needed; 8 bytes is a 64-bit filter. A stress run over 20,012,001 pairs found the single true pair with no false positives. This alone solves Spot files under about 262 KB.
2. Stage 2, ChaCha8. For files with ChaCha8 chunks, walk back from the key2 seed to the iv1 and key1 seeds and test the first ChaCha chunk: known bytes, or the zeros/text heuristic.
3. Stage 2 fallback for PDFs. If that finds nothing in a .pdf, the same window is searched again with two PDF tests (below).
4. Chaining. Seeds only increase, so one solved file brackets the next and reveals the real seed-to-seed gap on that machine.

Engines. In pure Python the search runs about 150,000 KCipher-2 pair tests per second on our 20-thread host. With numpy and numba installed, akira_fast.py compiles the stage-1 kernel and reaches 40–97 million pairs per second; building the Yarrow table (about 2,000 seeds per second per core) then becomes the bottleneck. Search cost in pure Python, by how well the key2 seed is known:

The two PDF tests. After stage 1 the KCipher-2 chunks and the unencrypted tail of a PDF are readable, so its structure can be used as known plaintext inside the ChaCha8 chunks:

• xref. The cross-reference tables or streams give the exact offset of every N G obj header. A header that falls inside a ChaCha chunk is exact known plaintext, and the ChaCha8 keystream block at any offset can be computed directly, so each candidate costs a single 64-byte block. The test is used only if every header in readable bytes sits where the xref says, and a candidate must match at least 90% of the in-chunk headers.
• deflate. A compressed page-content stream that starts in readable bytes and runs into the first ChaCha chunk. zlib is primed with the readable part, each candidate’s output continues it, and the inflated text must be valid page-content syntax (numbers, names, strings, operators with the right operand count). A candidate is accepted only if the whole stream then inflates with a valid Adler-32.

recover --stage2 auto (the default) runs the generic check first and the PDF tests only when it finds nothing; --stage2 pdf runs only the PDF tests; --stage2 heuristic keeps the old behaviour. A synthetic test suite (test_pdf_stage2.py) covers an xref-solvable PDF, a deflate-solvable PDF, and a binary-stream PDF where neither applies and the tool correctly reports failure.

Validation of the tool itself.

How we ran the sample

All runs were on an isolated Windows VM under x64dbg, reverted to a clean snapshot afterwards. Two safety gates were used in every run from run 2 onward: the WMI executor FUN_140071620 was forced to return (so shadow copies survived), and a breakpoint on the root-folder queue FUN_140073950 confirmed the target before anything was encrypted. The launch line was always --encryption_path=<folder> -localonly.

Not covered: --share_file was read statically only, and Part mode with percent below 50 was never exercised.

Function map

19 · Indicators of compromise

All indicators come from the binaries or from our controlled runs. The binary has no network, registry, mutex or service indicators: it opens no sockets, writes no registry keys and creates no named mutex.

20 · Catch it before the first file

The earliest reliable signal is the shadow-copy deletion: PowerShell started by WmiPrvSE.exe with Win32_Shadowcopy and Remove-WmiObject on its command line. It happens before any file is touched. After that, a burst of .arika creations followed by .akira renames is unmistakable.

YARA. The rule uses only strings and constants confirmed present in this binary. It has not been run against a wider corpus.

rule Akira_Win64_Encryptor_101bd45a
{
    meta:
        description = "Akira-branded x64 encryptor (asio/C++20, ChaCha8 + KCipher-2, RSA-4096)"
        sha256      = "101bd45ab673fd6547386dff4339f1649e61b9f5c318260d365f766fbdc2d3c9"
        date        = "2026-10-11"
    strings:
        $n1 = "akira_readme.txt" ascii
        $n2 = ".arika" ascii
        $l1 = "write_encrypt_info error:" ascii
        $l2 = "(Full begin) Cipher is not initialize!" ascii
        $l3 = "asio::create_auto_save_file error:" ascii
        $l4 = "Failed to make spot encrypt! (" ascii
        $l5 = "Number of thread to root folder parsers = " ascii
        $c1 = "--encryption_percent" wide
        $c2 = "--share_file" wide
        $c3 = "-localonly" wide
        $k2 = { 00 00 00 00 1A 6D 08 B6 34 DA 10 AF 2E B7 18 19 }   // KCipher-2 amul0 table
        $cc = "expand 32-byte kexpand 16-byte k" ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 3MB and
        ( (1 of ($n*) and 4 of ($l*, $c*)) or ($k2 and $cc and 3 of ($l*, $c*)) )
}

21 · Decryptor, scripts and rules

The tools are standard-library Python 3.8+ and PowerShell.

Shayan Ahmed Khan · Lead Threat Detection & Response

All analysis was performed on an isolated lab VM that was reverted after every run. Findings are from our own reverse engineering and controlled detonations of the samples identified above.

← Back to all analyses