Recovering Data the Ransomware Couldn't Reach

Case Brief

The client is one of India's leading insurance-survey and loss-assessment firms — the people who inspect and value claims for insurers. Their entire working archive lived on a single 8 TB drive: years of survey reports, spreadsheets of assessments, scanned bills, claim photographs, e-mail, and their Tally accounting books. One morning it was all gone — every file renamed with a .Funder extension and a ransom note in every folder. The business had, in effect, stopped.

The encrypted drive was couriered to Straightarc Technologies. This is the honest, step-by-step account of how we got the data back — without ever decrypting a single file — and it is written so that another victim, or another responder, can follow the same path. Every step names the tool we used and shows exactly how to run it.

127,852 files encrypted  ·  197.39 GB of live data  ·  0 files decrypted  ·  39,636 recovered in full

How to read this article. Wherever you see a hex screenshot, each colour marks a different field and a legend explains it in plain English. Wherever you see a Run it card, that's the actual command — with variants for a whole drive, a single file, or a chosen subset. The full toolkit is linked at the end.

The Low Point — When I Had Given Up

I will be candid, because the story only makes sense this way. When the drive first landed on my desk, I did the obvious things, and found nothing usable. The files were high-entropy noise. There were no backups I could restore, no shadow copies, no recovery tool that returned anything but garbage. I genuinely believed the data was gone, told myself the case was closed, and set it aside.

A few days later I couldn't let it go. I decided to stop trying to recover files and instead understand the enemy — to read the ransomware at the level of individual bytes and let the malware tell me what it had, and had not, actually done. That decision is where every recovery in this article begins.

1. What ransomware is this?

Ransomware leaves a calling card. Two things tell you which family you're dealing with: the extension it appends to every file (here, .Funder) and the ransom note it drops (here, Funder_Help.txt). The note also carries a victim ID and the attackers' contact e-mails — your first indicators of compromise (IOCs).

We took the note and one encrypted sample to ID Ransomware — a free service that matches these fingerprints against a database of known families. It identified the strain as Proxima (also called BlackShadow) and, importantly, confirmed there is no free decryptor.

2.  Is there any way to just undo it? (Failure #1)

Before anything clever, you exhaust the easy wins. We searched for a vendor decryptor, a leaked key, a flaw write-up — nothing existed for this build. Proxima's cryptography (we'll dissect it in Part D) is done correctly, which means the only key that can decrypt these files is one held by the attackers. So we crossed decryption off the list and asked a different question: *what survived?*

3. Volume Shadow Copies (Failure #2)

Windows quietly keeps point-in-time snapshots called Volume Shadow Copies — the machinery behind 'Restore previous versions'. If they survive an attack, recovery is trivial. Most ransomware deletes them first. We checked anyway.

4. Conventional file-recovery tools (Failure #3)

Undelete/carving tools (the kind you'd use after an accidental format) look for *deleted originals* still sitting in free space. They returned nothing meaningful here — and understanding why was the turning point of the whole case.

5. The realisation: this is *in-place* encryption

There are two ways ransomware can encrypt a file. The naive way is copy-then-delete: read the original, write a new encrypted copy, delete the original — which leaves the original recoverable in free space. The efficient way is in-place: overwrite the file's own bytes where they already sit, then rename it. Proxima does the second.

We proved it from timestamps. If the file were a freshly-written copy, its creation time would be the attack date. Instead, 98.8% of the encrypted files kept their original, pre-attack creation date — they are the same files, overwritten in place. The consequence is blunt: there are no deleted originals to carve back. Conventional recovery was always going to fail.

6. The backups were encrypted too (Failure #4 — the real gut-punch)

The client ran Quick Heal, whose continuous-backup feature keeps copies of protected files. Our best hope. But when we looked, the backup archives themselves carried the .Funder extension — the ransomware had encrypted the backups as well, including the backup's own index. We contacted Quick Heal; their answer was that the backup was encrypted and there was no chance.

7. Clues from the USN journal

NTFS keeps a change journal (the USN journal) — a running log of every file created, renamed, or deleted. Even after an attack it often survives, and it gave us two things: a list of the tools the attacker dropped, and the timing/naming pattern of the encryption itself. It's the first place we read for clues before touching the file contents.

# Whole journal (from the mounted volume's $Extend\$UsnJrnl:$J)
python3 usn_parse.py UsnJrnl_J.bin
# Filter to one file's history
python3 usn_parse.py UsnJrnl_J.bin --name "report.docx"
# Filter to a keyword subset (e.g. attacker tools)
python3 usn_parse.py UsnJrnl_J.bin --grep "mimikatz|anydesk|.Funder"

8. Getting raw access to the drive, and mapping it

To read the disk beneath the operating system we mounted it as a raw block device in Linux (via WSL). In plain terms: instead of asking Windows for 'files', we open the disk as one long ribbon of bytes and interpret the filesystem ourselves.

# take the disk offline in Windows so WSL can own it
Set-Disk -Number <N> -IsOffline $true
wsl --mount \\.\PHYSICALDRIVE<N> --bare
# in WSL, make the partition readable
sudo chmod o+r /dev/sdX2

Then we extracted and parsed the $MFT (Master File Table) — NTFS's index of every file: its name, size, dates, and exactly which disk clusters hold its bytes. Windows' own tools were far too slow across 1.3 million records, so we pulled the raw $MFT and parsed it in Python. This table is the map every later step depends on.

# Whole volume
python3 parse_mft.py /dev/sdX2  > mft_meta.json
# Inspect one file's record
python3 parse_mft.py /dev/sdX2 --inode 290315
# List a subset by extension
python3 parse_mft.py /dev/sdX2 --ext .Funder

9. How the cipher works (in plain terms, then in detail)

In plain terms: for every file, the malware invents a brand-new secret number, uses it to scramble the file, then throws that secret away — keeping only a locked copy that only the attacker's master key can open. Because the secret is unique per file and is destroyed after use, there is no shortcut: no shared key, no pattern, nothing to guess.

In detail: for each file Proxima generates a fresh Curve25519 key pair and a ChaCha20 nonce using CryptGenRandom (Windows' strong random-number generator). It performs an ECDH key exchange between that throwaway private key and the attackers' public key (baked into the malware) to derive a 32-byte shared secret, and uses that secret directly as the ChaCha20 key. After encrypting, it wipes the throwaway private key and the shared secret from memory, and writes only the throwaway *public* key into a footer. To decrypt, the attacker recombines their *private* master key with that public key — which no one else has.

We identified this scheme by dissecting the footer (below) and matching it to public analysis of the Proxima/BlackShadow family. See RFC 8439 (ChaCha20) and RFC 7748 (Curve25519) for the primitives.

Why we could never decrypt. Each file has its own key; the key generator is cryptographically strong; the same file never reuses a keystream; and known-plaintext doesn't break ChaCha20. Every route to the key is a dead end — we tested them all.

10. Entropy — how we found the surviving plaintext

Here's the insight that saved the case. Entropy measures randomness: encrypted data looks perfectly random (entropy near 8.0 bits/byte); ordinary file data is structured and measures lower (~6.7). By scanning entropy across a file, we can literally *see* where the ciphertext ends and the original, untouched plaintext begins.

That seam sits at a fixed offset — 0x60000, i.e. 393,216 bytes (384 KiB). Proxima encrypts only the first 384 KiB of a typical file and leaves the rest alone. For anything larger than 384 KiB, the tail is your original data, verbatim.

11. Big files are encrypted in more than one place

One subtlety we had to get right: Proxima does not always stop at 384 KiB. The footer (next section) holds a chunk counter, and the amount encrypted grows with it. Small files: just the first 384 KiB. Large files: multiple encrypted regions, and beyond a point the whole file. This is why recovery has to be driven by the file's structure, not a fixed offset — we scan each file for surviving format markers rather than blindly cutting at 384 KiB.

12. The 72-byte footer

Appended to the very end of every encrypted file is a 72-byte footer — the malware's own record of how to (for the attacker) unlock that file. Reading it is what let us confirm the whole scheme.

13. Carving the tails

Now that we knew large files keep an intact plaintext tail, we swept the whole drive and extracted every surviving tail — 44,240 files, 172 GB of original bytes hiding behind the encrypted headers.

# Whole drive
python3 extract_all.py /dev/sdX2 --out ./tails
# One file
python3 extract_all.py /dev/sdX2 --file "video.mp4.Funder"
# A subset by type
python3 extract_all.py /dev/sdX2 --ext .jpg,.pdf,.mp4

14. Rebuilding images and videos

A tail on its own isn't a working file — it's missing the *header* the encryption ate. For videos, we synthesised a fresh container header and re-attached the intact moov index from the tail. The rebuilt clips play after a few seconds of glitch (the encrypted lead-in), then run clean. For images, we carved embedded JPEGs directly from the plaintext regions.

File-format references used here: ISO/IEC 14496-12 (MP4/MOV base media format) and ITU-T T.81 (JPEG).

# One video from its tail
python3 reconstruct_video.py video.tail --ref sample.mp4 -o video_fixed.mp4
# Batch a folder of tails
python3 reconstruct_video.py --dir ./tails/video --ref sample.mp4
# Whole recovered set
python3 reconstruct_video.py --dir ./tails/video --ref sample.mp4 --all

15. Documents: images yes, text no — and the gap that mattered

Modern Office files (.docx, .xlsx, .pptx) are really ZIP archives of XML and media. The bad news: the XML that holds your text and numbers lives at the front of the file — inside the encrypted 384 KiB — so the actual document text was unrecoverable. The good news: embedded images often sit further in, in the plaintext, so we could rebuild picture-only versions of many documents. We recovered images extensively and Word files with their pictures intact.

But there was a conspicuous hole: we could not recover a single Excel spreadsheet this way — and for a loss-assessment firm, the spreadsheets *are* the work. That gap is exactly what sent us back to the 'hopeless' Quick Heal backups. Format references: ECMA-376 / Office Open XML and the PKWARE ZIP APPNOTE.

# One document
python3 repair_files2.py "report.docx.Funder" -o ./repaired
# A subset/folder
python3 repair_files2.py --dir ./tails/office -o ./repaired
# Whole drive via the MFT map
python3 repair_files2.py --mft mft_meta.json --dev /dev/sdX2

16. The idea that reopened the case

The missing Excel files nagged at me. Then it clicked: the Quick Heal backups were encrypted by the same ransomware, the same header-only way. If ordinary files kept a plaintext tail, the backup archives had to keep one too — and a backup archive is nothing but a *wrapper around an original file*. If we could understand that wrapper's structure, we could reach inside and pull the originals out. So we set out to reverse-engineer the backup file format.

17. Decoding the Quick Heal `.cfa` backup format

Each Quick Heal backup file is a .cfa archive. By comparing many of them at the byte level we recovered the format completely. There are two variants. Small files are stored compressed: a 4-byte magic QHBK, a 4-byte original size, then a standard zlib/DEFLATE stream of the whole original file. Large files are stored raw — the original's bytes verbatim, no wrapper.

The compressed payload is a zlib stream — the 78 9C you see is its header; inside is a DEFLATE bitstream and a trailing Adler-32 checksum. Specs: RFC 1950 (zlib) and RFC 1951 (DEFLATE). Recovery is then trivial and lossless: skip the 8-byte header, inflate, and you have a byte-perfect original. Full field tables are in Appendix A.

18. Mass recovery from the backups

With the format understood, we swept every backup archive and extracted the originals — deduplicating the many historical versions Quick Heal keeps down to unique files. This single step recovered the bulk of the business: 39,636 original files in full fidelity — including the Excel spreadsheets that had eluded every other method.

23,530 PDFs  ·  9,481 Word / other docs  ·  6,740 spreadsheets  ·  39,636 total, full fidelity

# Whole backup store (all types)
python3 cfa_extract.py /dev/sdX2 --out ./recovered
# Only certain types (e.g. Excel)
python3 cfa_extract.py /dev/sdX2 --types xls,xlsx
# A single backup file
python3 cfa_extract.py --file "Bill.xls_177660.cfa"

19. The Tally problem

Tally (India's ubiquitous accounting software) stores each company's books as a set of cryptically-named data files (TranMgr.900, Company.900, and so on). We had recovered all of them from the backups — but they arrived as a giant, undifferentiated pile. Which file belonged to which company? Without that, the accounts were just noise.

20. Decoding the backup index

Quick Heal keeps a master index (cfrdb) that maps every backup archive to its origin — the snapshot it came from, the original filename, and a sequential backup ID. The index was itself encrypted, but header-only, so its record table survived in the plaintext tail. We reverse-engineered the record layout and read it: each ~98-byte record ties a backup ID to a path like snapshot \ set \ originalname_ID.cfa.

21. Rebuilding the entire directory tree

The backup ID was the thread that stitched everything together. It appears both in the index and in each .cfa filename, so — with the index decoded — we could place every recovered file back into its original folder structure, and regroup the Tally files into their 28 company folders by snapshot cluster. We rebuilt the client's entire E:\ layout as it had existed before the attack.

# Rebuild Tally companies
python3 tally_reconstruct.py --index cfrdb.tail --out ./tally
# Rebuild the full tree
python3 tree_rebuild.py --recovered ./recovered --index cfrdb.tail --out ./recovered_tree
# One company / subset
python3 tally_reconstruct.py --index cfrdb.tail --company "<name>"

22. The scorecard

0 files decrypted  ·  39,636 recovered in full  ·  42.9 GB partially salvaged  ·  28 Tally companies rebuilt

23. The lesson

Modern ransomware cryptography is not a lock you pick. Proxima's ChaCha20/Curve25519 scheme is sound; we could not, and did not, break it. The recovery came from everything the malware left exposed — the plaintext tails its header-only encryption couldn't reach, and above all the backup store it encrypted the same lazy way, which therefore still contained recoverable originals.

If you take one thing from this: don't fight the crypto — enumerate the untouched. Shadow copies, security-software backup stores, plaintext tails of large files, deleted-but-present data. The biggest win in this case came from the one place everyone — including the backup vendor — had written off as hopeless.

For fellow victims. Every script referenced in this article is published as a toolkit so you can attempt the same recovery on a .Funder-hit drive. See Appendix B for the full list and the download link. Work on a copy of the disk, never the original.

Closing

One last carve, for completeness: we turned the same deleted-space recovery on the intruder's *own* tools. Evidence of mimikatz and the NirSoft PassView credential suite surfaced in unallocated clusters — confirming what was run on the machine — but the attacker had wiped the kit: the toolkit archive and the ransomware encryptor binary itself had been deleted and their clusters overwritten, so those could not be recovered. In other words, the attacker's toolkit was not found intact on the system; only the traces it left behind.

This article covered how we got the data back. It deliberately did *not* cover how the attackers got in — the intrusion, how long they lurked, the tools they used, and the attribution. That investigation is a story of its own, and we will publish it separately in our next article, focused on the DFIR (Digital Forensics & Incident Response) analysis of the compromise.

— *Prince Komal Boonlia, CEO, Straightarc Technologies.*