Akira Ransomware Analysis — 101bd45a…c3c9

Oct 11, 2026 · @Shaddy

The sample is a 64-bit C++ ransomware that brands itself Akira. It encrypts files in place with ChaCha8 and KCipher-2, wraps each file’s keys with an embedded RSA-4096 public key, and renames files to .akira. Its per-file keys come from a Yarrow generator seeded only with the machine’s uptime counter, so they can be recovered without the RSA key. Our decryptor did this on the sample’s real output, including a fully independent blind test on files we had not seen, where 6 of 7 in-scope files came back hash-exact. The same decryptor, unchanged, did the same on a second build of this codebase. Both blind runs left one large PDF partly decrypted; a PDF stage-2 fallback added afterwards recovers both hash-exact.

At a glance

A single self-contained PE does everything. There is no network C2, no persistence and no data exfiltration in this binary. The theft claimed in the note is not done by this file.

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

• Encrypts local, mapped and UNC paths using a multi-threaded IOCP pipeline.
• Deletes Volume Shadow Copies through WMI-launched PowerShell.
• Force-closes processes holding target files open, using Restart Manager. System processes are spared.
• Uses hybrid crypto: per-file ChaCha8 + KCipher-2 keys, sealed with an embedded RSA-4096 public key.
• Uses three encryption modes (full, first-N-percent, striped), chosen by file extension and size.
• Drops a ransom note in every traversed folder.

Execution flow

The main thread does all set-up once, then hands files to encryptor threads that each run the same pipeline. Everything after step 4 is asynchronous C++20 coroutines on an asio IOCP pool.

In -l mode the run stops after step 2 and only logs the drive list. A file that fails to open even after Restart Manager is logged and skipped.

Command line and targeting

Targets come from exactly one source, in priority order: an explicit path, then a share list, then a drive sweep. The parser is argh-style with no registered parameters. A value must be attached with =; -p C:\x is read as a bare flag, and the sample then falls back to sweeping all drives. We observed this live.

Target classification, per root (FUN_140042c50):

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

The drive sweep (FUN_1400766e0) uses GetLogicalDriveStringsW + GetDriveTypeW and skips CD-ROM and no-root-dir volumes. Its loop is compiled with a fixed bound (cmp rsi, 0x2C), so only the first five drive letters are ever visited. A sixth or later volume (for example H: when C:–G: exist) is not encrypted in sweep mode.

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

Thread pools are sized from the logical CPU count N. N is first doubled when it is below 5 (and treated as 2 when it is 1). Then 30% of N go to root-folder parsers, 10% (at least 1) to folder parsers, and the rest to encryptors. A 2-vCPU VM therefore gets 1 / 1 / 2.

Pre-encryption actions

Three steps run once, in this order, before any file is touched. They are skipped in -l (list-only) mode.

1. Skip list update (FUN_14006ecf0). Adds .akira and .arika to the extension skip set, so encrypted and in-progress files are never re-encrypted.
2. Protected-process snapshot (FUN_140070c30). WTSEnumerateProcessesW lists running processes, and the PIDs whose names match the 20-name protected set are stored. These PIDs are later exempt from Restart Manager shutdown.
3. Shadow-copy deletion (FUN_140071d80 → FUN_140071620).
   • Decodes a 76-byte stack string with ((0x39−b)·0x0B) mod 0x7F into powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject".
   • Launches it through COM/WMI in ROOT\CIMV2: Win32_Process.Create, with Win32_ProcessStartup.ShowWindow = 0 (hidden) and CreateFlags = 0. PowerShell therefore appears as a child of WmiPrvSE.exe, not of the ransomware.
   • Opens the returned PID with SYNCHRONIZE and waits up to 15 s. The PID is read as a 16-bit value, so the wait silently fails for PIDs above 32767.
   • The decoded string was confirmed live in the debugger. We forced the call to return so the VM’s shadow copies survived.

Restart Manager unlocking (FUN_140070e30) runs per file, only when the file cannot be opened:

1. RmStartSession, then RmRegisterResources on the file, then RmGetList to get the processes holding it.
2. If any holder is the ransomware itself or a protected PID, it calls RmEndSession and gives up on that file.
3. Otherwise it calls RmShutdown(session, RmForceShutdown), which kills the holders (database engines, Office, backup agents), and the open is retried.

Nothing else runs beforehand: no service stops, no event-log clearing, no firewall or boot-configuration changes, no persistence.

File selection and encryption modes

Every file that survives the exclusions gets one of three modes. Each mode encrypts some regions in place, in 0xFFFF-byte chunks. The mode is decided in the folder parser (FUN_1400b5fb0) and the per-file coroutine (FUN_1400ae840):

1. Extension in the database set → mode 0, Full: the whole file.
2. Otherwise, extension in the VM/disk-image set, or file size above 2,000,000 bytes → mode 2, Part: striped regions.
3. Otherwise → mode 1, Spot (the binary’s own name): only the first percent % of the file.

Within every encrypted 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.

Full-mode extensions (153). The list is decoded from obfuscated .rdata tables built by FUN_140003680 into set 0x1400f5e60; each table uses its own affine (a·b + c) mod 127 key:

.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

Forced-Part extensions (20). Built by FUN_140034500 into set 0x1400f5e38 from stack strings, each with its own key:

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

Cryptography

Each file gets four fresh random values, generated by a weakly seeded PRNG. They drive two stream ciphers and are sealed with RSA-4096. Every primitive below was reproduced in Python and matched against data captured live from the running sample.

The 91-byte RSA plaintext:

The RSA context has its own Yarrow instance for PKCS#1 padding, seeded the same QPC-only way (FUN_14007bbe0). The private key never touches the victim, so recovery cannot come from the RSA side.

Encryption flow. One uptime reading per value is all the randomness a file’s keys get. ChaCha8 and KCipher-2 then share each region’s chunks, and the RSA-sealed blob ends up in both the journal and the footer.

Encrypted file format and on-disk artifacts

An encrypted file is the original file, partly or fully encrypted in place, followed by a 512-byte RSA footer and renamed to .akira. The file grows by exactly 512 bytes. A per-file .arika journal exists only while encryption is in progress.

Per-file sequence (FUN_1400ae840), confirmed live:

1. Open the target; if it is locked, run Restart Manager unlocking and retry.
2. Create the journal <dir>\<name.ext>.arika with CreateFileW(GENERIC_READ|GENERIC_WRITE|DELETE, share R/W, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED).
3. Write the journal header at offset 0.
4. Encrypt the regions for the chosen mode. Before and after each chunk, overwrite journal bytes 0–8 with a progress record.
5. Append the 512-byte RSA footer at offset = original size (FUN_1400b5a20).
6. Rename the open handle to <name.ext>.akira with SetFileInformationByHandle(FileRenameInfo), then DeleteFileW the journal.

Because the journal carries the RSA blob and progress, files caught mid-encryption by a crash or kill stay decryptable by the operator. The folder parser also skips any file whose .arika already exists, so a restarted run does not double-encrypt it.

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.
• Log file: Log-<dd>-<mm>-<YYYY>-<HH>-<MM>-<SS>.txt in the process’s working directory, written by an spdlog-style file_logger. Lines include “This is local disk:”, “Number of threads to encrypt =”, “file rename failed. System error:”, and per-file failures such as “Failed to make full encrypt! (“.
• Process: a hidden powershell.exe spawned by WmiPrvSE.exe for shadow-copy removal.

Ransom note, verbatim:

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.

Windows API calls by behaviour

Every malicious behaviour uses ordinary imports called straight through the import table. Nothing is resolved at runtime: the only GetProcAddress and LoadLibraryExW callers are CRT and STL helpers. Call sites come from Ghidra cross-references to 49 imports; the key ones were checked against their callers and decompiles.

Three imports 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:

1. WTSEnumerateProcessesW
2. WMI Win32_Process.Create
3. RmShutdown
4. overlapped ReadFile/WriteFile
5. SetFileInformationByHandle rename

Weaknesses and recovery outlook

The RSA side is sound, but every symmetric key is a deterministic function of one boot-relative timestamp. Recovery without paying is therefore possible. We verified the weakness and recovered keys from the sample’s real output in a controlled test (next section).

A practical recovery attempt would run in four steps:

1. Estimate the QPC value at encryption time from the boot time (kernel boot events, LastBootUpTime) and each .akira file’s timestamps.
2. Brute-force the key2 seed, then the iv2 seed a small delta later, testing the first-chunk header.
3. Walk backwards from the key2 seed to the iv1 and key1 seeds.
4. Decrypt with the models in this report.

The cost grows linearly with the uptime window and the gap span. Measured speeds and a cost table are in the next section.

Open question: QPC frequency differs on some hardware. The code handles any frequency, but non-10 MHz hosts give seeds that are not multiples of 100, which changes the search space.

Decryptor and key recovery

We built a decryptor that restores files encrypted by this sample, and a seed brute-forcer that recovers per-file keys without the operator’s RSA key. Both work on the sample’s real output: three files it encrypted in our VM (one per mode) were recovered from a seed window and decrypted byte-exact.

Decryption in plain English. The ransomware’s weak spot is how it picks its keys. It doesn’t use real randomness: each key is built from the computer’s uptime, counted in 100-nanosecond steps. Guess the uptime at the moment a file was encrypted and you can rebuild that file’s keys. Each file gets two keys, each with a companion value; most files only need the first key.

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 tells you its uptime when encrypted, to within a few milliseconds.
2. Guess the key. Try every uptime value in that few-millisecond window, about 90,000 candidates. Each one rebuilds the 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: roughly 380 million pairs in total.
4. Check each guess. Every PDF starts with %PDF-1., and every PNG starts with the same 16 bytes. Decrypt the file’s first few bytes with each pair; the pair that produces the right header is the correct one.
5. Decrypt the file. With the right pair, decrypt the whole file, strip the 512 bytes the ransomware appended, and the original is back byte for byte.

Steps 2–4 are the slow part: about 30 minutes per file on our 20-thread analysis host in pure Python, or about 20 seconds with the optional numba engine (akira_fast.py, 40–45M seed pairs per second). All four run-5 files re-ran hash-exact in 16–26 s each. The ransomware’s master RSA key is never needed.

The tool is akira_decrypt.py: single file, Python 3.8+, standard library only, at D:\MalwareAnalysisVMs\AI-MalwareAnalysis\cases\2026-10-11_101bd45ab673_akira-ransomware\06-decryptor. It never overwrites unless told to (--force). Run it on copies of the encrypted files.

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.

Decryption flow. Whatever the key source, the tool ends up with the same four values. It then replays the sample’s own chunk plan with both keystreams, so a decrypted file matches the original byte for byte.

How recover works. Every value the sample uses is the first 16 bytes of one fresh Yarrow draw, seeded only by uptime in nanoseconds. One table of candidate seeds therefore serves all four values.

1. Stage 1. For each key2 seed in the uptime window and each candidate gap to the iv2 seed, run KCipher-2 over the first ciphertext bytes and compare with the known file header (at least 8 bytes, a 64-bit filter). This alone is enough for Spot files.
2. Stage 2. For Full and Part files, walk back from the key2 seed to the iv1 and key1 seeds. The test is the first ChaCha chunk: known bytes, or a zeros/text heuristic. For a PDF, if that finds nothing, the same window is searched again with two PDF tests (object headers from the xref, or continuing a page-content stream’s deflate); see Stage-2 fallback for PDFs.
3. Chaining. Seeds only increase, so one solved file brackets the next. It also reveals the real seed-to-seed gap, which narrows every later search.

Native seed gap (measured). The search cost depends on how far apart a file’s seeds are. Run 4 measured this without any seed breakpoints: a small logger patched into the sample’s own QueryPerformanceCounter wrapper recorded all 84 seeds of 21 files on 2 encryptor threads. Decrypting two of those files with the logged values proved they were the real seeds, and the timer path was checked free of debugger hooks.

Consecutive seeds are about 0.4 ms apart. The floor 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, so recover now defaults to --gap 3800:8000.

The search runs about 150,000 KCipher-2 pair tests per second on the 20-thread analysis host in pure Python. The pair count is the key2 window in ticks times the gap span, so the uptime estimate is now what drives the cost.

On the two native-run files, a ±0.25 ms key2 window and the default gap window found the true pair among 21 million candidates in 70 s and 85 s.

Finding the window from victim timestamps. An .akira file’s last-write time lands 0.45–5.36 ms after its key2 seed (median 1.39 ms, all 21 run-4 files). The sample’s own operator log confirms it times itself with QPC: its final 423038 ms line is exactly main-end minus main-start QPC. So key2 ≈ (mtime − FILETIME of QPC 0) × 100, and recover --qpc-offset … --mtime … builds the window from that. How well the offset is known decides the cost:

One solved file then pins the offset for every other file of that boot. The ransom note’s creation time bounds a folder’s keys from below (--floor). Measured in 04-dynamic/05-timestamp-seed-anchors.md; a blind test found the gap_00 seeds from mtime and offset alone in 28 min.

Limits:

• The operator-key path is tested only with our own RSA key.
• The native seed gap was measured on one 2-vCPU VM. A faster or slower victim CPU shifts it, so widen –gap toward 3800:30000 if a search finds nothing.
• Seed recovery needs a predictable header for stage 1, and plaintext-looking content in the first ChaCha chunk (or known bytes there) for stage 2. In run 6 and on build 2 that check found nothing on real PDFs. The PDF stage-2 fallback now recovers both; other large compressed files (Office documents, archives, video) may still come back only partly decrypted.

Does it work? Yes, on the sample’s own output. The three .akira files the live sample produced in run 3 started as zero-filled files, so a correct decryption must give back exactly that many zero bytes. The demo was re-run on 2026-10-11 from the case folder, and its log is artifacts/decryptor-demo-2026-10-11.txt.

One thing it cannot show: decryption through the operator’s RSA private key works only with our own test key, because the real one is not available.

Blind recovery of real files (run 5). On a freshly reverted VM, the live sample encrypted a PDF, a DOCX and two PNG screenshots. Only the shadow-copy and target-folder gates were in place, with no seed capture. Each file was then attacked with only what a responder has:

• its .akira copy and last-write time;
• the QPC offset measured on the same boot after the attack;
• known plaintext from the file type: the PNG header, %PDF-1. (7 bytes), or the DOCX’s first ZIP header rebuilt from its unencrypted central directory.

The fourth file was a seed-gap outlier: its key2 and iv2 seeds were 26,718 ticks (2.67 ms) apart, close to the 27,109-tick outlier from run 4. The default pass (gaps ≤ 8,000 over the whole note-bounded window) missed it. A second pass with recover --anchor iv2 found it in 1,240 s, decrypting it hash-exact. That pass bounds iv2 instead of key2, at 2.5 ms before the mtime to 0.1 ms after, and tries gaps of 8,001–30,000 (572 M pairs). On all four files iv2 sat 0.8–1.8 ms before the mtime, so this second pass is the recommended follow-up whenever the default misses. Details: 04-dynamic/06-run5-blind-real-files.md.

Independent blind test (run 6). Six of seven in-scope files were recovered hash-exact, all by the default pass in about 25 s each. Before encryption we froze the driver (run6_blind_recover.py, SHA-256 ae0df7df…), the decryptor (870c6db9…) and the rules: pass 1 with the defaults, an automatic --anchor iv2 pass 2 on a miss, and fixed known bytes per file type. After a full VM revert the analyst placed eight files we had not seen. Their original hashes were sealed and read only after recovery. The same two safety gates were applied, then every breakpoint was removed. The post-run QPC offset agreed within 69 ticks across seven pairs.

The PDF is over 262,140 bytes, so its encrypted half also holds ChaCha8 chunks. Its KCipher-2 keys were found, but stage 2 (iv1/key1 gaps 3,105–8,000, 24 M pairs) found no key that its zeros/text check accepts. This risk was written into the protocol before the run. The cause was settled afterwards: the check rejects compressed PDF data, and the seeds were inside the window (Stage-2 fallback for PDFs, below). No file needed pass 2, and iv2 sat 0.55–1.86 ms before the mtime. Two inputs repeat run 5, the DOCX and the 125745 PNG; they were encrypted with new keys. Details: 04-dynamic/07-run6-independent-blind.md.

Second build (build 2, run 1). Build 1’s decryptor, unchanged (870c6db9…), recovered 6 of 7 in-scope files from a second build hash-exact. Every file was found by the default pass in 15–30 s. The build is SHA-256 988776358d0e45a4907dc1f4906a916f1b3595a31fa44d8e04e563a32557eb42 (MD5 4aecef9ddc8d07b82a6902b27f051f34).

The static comparison showed the same key generation. There is no CSPRNG import. The per-value seed function FUN_140082c90 turns QPC×100 into a decimal string and seeds a new Yarrow with it. FUN_140036730 makes the same four draws (key1 32 B, iv1, key2, iv2) and builds the same 91-byte blob, which goes into the 512-byte RSA footer. The ChaCha constants, the 2,000,000-byte Part threshold, the CLI and the note are the same. Three things changed: the string-obfuscation constants (the shadow-copy command decodes with ((0x32 − b)·0x2A) mod 0x7F), the chat code 6729-HK-NIZN-WOPQ, and the operator RSA key. The gates were the WMI executor FUN_140078890, which was forced to return, and the root queue FUN_14007ac00, where r8 was checked.

The run followed the run-6 protocol. The driver (fc5d69fd…) differs from run 6’s only in the tool path, and it was frozen before detonation. After a revert, the analyst placed the files. A sealed pre-listing was taken, and the Ghidra copy imported before encryption matches it in all 13 hashes. No breakpoints were set during encryption. The operator log shows 2 threads and 36,814 ms. The QPC offset agreed within 111 ticks across 7 pairs.

The PDF stopped at the same ChaCha8 stage-2 limit as run 6’s PDF, and was recovered afterwards (below). iv2 sat 0.91–1.91 ms before the mtime, and pass 2 never ran. The dynamic run therefore confirms what the static comparison could not: the mode and chunk layout, the cipher details and the timing. Details: case 2026-10-13_988776358d0e_akira-build2, 04-dynamic/01-b2run1-protocol.md.

Stage-2 fallback for PDFs (added 2026-10-14). Both PDFs are now recovered hash-exact. Their ChaCha8 seeds were inside the default window; the zeros/text check rejected the right key because the first ChaCha chunk starts in compressed data. In the run-6 PDF the whole ChaCha region (bytes 65,535–196,605) is one 291 KB page-content stream, and the check accepts 0 of 971 genuine 64-byte windows of it. After stage 1, the KCipher-2 chunks and the unencrypted tail are readable, which allows two PDF tests:

• xref: the cross-reference tables or streams give the exact offset of every N G obj header. Headers inside a ChaCha chunk are exact known plaintext, and the ChaCha8 keystream block at any offset can be computed directly, so each candidate costs one 64-byte block. The test is used only if every header in readable bytes sits where the xref says, and a candidate needs 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 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.

Seeds: run 6 566543569000, 566543980000, 566544406300, 566544820400; build 2 1219626222000, 1219626650700, 1219627041700, 1219627450300. All gaps are 3,910–4,287 ticks, ordinary for this sample.

Both tests are in akira_decrypt.py as a fallback. recover --stage2 auto (the default) runs the zeros/text check first and, for a .pdf, the PDF tests when it finds nothing; --stage2 pdf runs only them; --stage2 heuristic keeps the old behaviour. The default command line recovered both files hash-exact (8 min 16 s and 4 min 52 s), and the deflate test alone also solves the build-2 PDF. Tests: selftest 8/8, real outputs 15/15, round trip 29/29, and the new synthetic test_pdf_stage2.py 3/3. Neither test fits every PDF (no objects inside the ChaCha chunks plus a binary stream at the boundary), and other large compressed types have no stage-2 test yet. The blind results stay 6 of 7, because the frozen decryptor lacked the fallback; with it, 7 of 7 in-scope files on each build are recoverable. Details: 06-decryptor/stage2-investigation/ in both case folders.

The decryption routine. The full script is attached below as akira_decrypt.py (also in the case folder under 06-decryptor), 1,601 lines (version of 2026-10-14, with the PDF stage-2 fallback), SHA-256 091701682454a75dfb57324e29a6270977186f68209a7c3a93178ab76fe9fc4b. It is stored as .txt because the doc store does not accept .py; rename it after downloading. The core is short: regenerate the four values, rebuild the sample’s chunk plan, and XOR each chunk with the right keystream.

[image: akira_decrypt.py (attached as .txt)]

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

def decrypt_stream(fin, fout, size, mode, percent, keys):
    key1, iv1, key2, iv2 = keys
    k2 = KCipher2(key2, iv2)                    # RFC 7008
    cc = ChaChaSample(key1, iv1)                # 8 rounds, key1[:16] twice, iv1[:8]
    copy_first(fin, fout, size)                 # body without the 512-byte footer
    for off, n, cipher in chunk_plan(mode, percent, size):
        fin.seek(off)
        plain = (k2 if cipher == "k2" else cc).xor(fin.read(n))
        fout.seek(off); fout.write(plain)
    fout.truncate(size)

This excerpt is condensed for reading. In the script, copy_first is an inline loop, and journal handling, logging and argument checks are left out here. ChaChaSample.xor starts every chunk on a fresh 64-byte block, which reproduces the sample discarding partial blocks. recover prints key1 with its upper 16 bytes as zeros: ChaCha never reads them, so they are not searched.

Indicators of compromise

All indicators below come from this binary or were observed in the controlled run; none are taken from external reporting. The binary has no network, registry, mutex or service indicators: it opens no sockets, writes no registry keys and creates no named mutex.

Detection

The most reliable early signal is the WMI-spawned PowerShell shadow-copy deletion, which happens before any file is encrypted. After that, mass .arika creation followed by .akira renames is unmistakable. The YARA 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*)) )
}

Behavioural detections:

MITRE ATT&CK mapping:

Analysis notes

Findings come from static analysis in Ghidra 12.1.2 and six controlled runs of this build, plus one of a second build (988776358d0e…), under x64dbg in an isolated Windows VM, followed by snapshot reverts. Crypto was checked by re-implementing each primitive in Python and comparing against live captures.

• Run 1 used -p <path>. It escaped the folder because of the argh parsing behaviour above and was stopped early.
• Run 2 used --encryption_path=<folder> -localonly. A breakpoint on the root-folder queue checked the target before any encryption. The shadow-copy call was forced to return.
• Test files: zero-filled zero_small.txt (0x3000 B), zero_db.sqlite (0x30000 B) and zero_big.bin (3,000,000 B), so ciphertext equals keystream.

• Not covered: share-file input was read statically only; no live run used --share_file. Part mode with percent < 50 was not exercised.

• Run 3 encrypted zero-filled e2e_small.txt, e2e_db.sqlite and e2e_big.bin while their seeds and RSA blobs were captured. Those real .akira files are the regression fixtures for the decryptor and the seed brute-forcer.
• Run 4 measured the native seed gap with no seed breakpoints.
  • An in-process logger on the sample’s QueryPerformanceCounter wrapper recorded every reading, and an exit trap kept the finished process alive for reading.
  • Re-attaching stalled on a ScyllaHide dialog, so the encryption ran attached with no breakpoints; the only debug events were thread and DLL events, with no exceptions.
  • The timer path was confirmed unhooked.
• Run 5 encrypted four analyst-provided real files with no seed capture, after the same two safety gates; all four were recovered blind, hash-exact (the fourth by an iv2-anchored second pass). Read-only PowerShell probes, launched from x64dbg, collected file times, clock pairs and boot events on the VM for the timestamp study.
• Run 6 was the independent re-test: after a full revert, eight analyst-chosen files were encrypted with no seed capture, under rules frozen beforehand. Six of seven in-scope files were recovered blind and hash-exact. The PDF’s ChaCha chunks were not recovered in the blind run (the PDF stage-2 fallback recovered them afterwards), and the MP4 had no known-plaintext rule. Probes were run with x64dbg’s init command, because LoadBinary drops command-line arguments.
• Build 2 (988776358d0e…, case 2026-10-13_988776358d0e_akira-build2): a static comparison with this build, then one run under the run-6 protocol, decrypted with this build’s decryptor unchanged. 6 of 7 in-scope files were hash-exact; the PDF’s ChaCha chunks were not recovered in the blind run, and the PDF stage-2 fallback recovered them afterwards.

Function map (image base 0x140000000):

The Python re-implementations used for validation became the decryptor and seed brute-forcer described in Decryptor and key recovery.