Reading Data Recovery — the UK’s No.1 Ransomware Data Recovery Specialists (25+ years)

We deliver forensic-grade ransomware triage, containment, and data recovery for laptops, desktops, external drives, NAS/RAID and virtualised environments. We handle cases involving families such as LockBit, REvil/Sodinokibi, Conti/Black Basta lineages, Dharma/Phobos, STOP/Djvu, Medusa, Makop, and many others. Our approach is evidence-preserving, clone-first, and controller-aware—we stabilise storage, acquire pristine images, and then pursue decryption or non-decrypt recovery paths in parallel to maximise outcome.

What we actually do (process overview)

1. Incident intake & isolation — Safely power down infected systems, capture volatile artefacts (RAM, handle lists, key material), preserve chain-of-custody.

2. Forensic imaging — Hardware write-blocked, hash-verified images of all affected volumes (HDD/SSD/NVMe/RAID).

3. Strain identification — Classify by extension, note, binary signatures, and crypto artefacts; map kill-switches and known decryptors.

4. Parallel strategy — (a) Cryptanalytic/decryption path and (b) non-decrypt reconstruction (snapshots, journals, databases, partial file rebuilds).

5. Recovery & verification — Sample-open validation, hash manifests, structured delivery; optional evidence bundle for insurers/law enforcement.

We never modify originals; all work is performed on forensic images.

25 techniques we use to recover from ransomware (with technical detail)

Format: Technique — Why it works / What we do in the lab

1. Family & crypto-profile fingerprinting — Static triage of notes, extensions, PE imports, and config blocks identifies cipher-suite (e.g., ChaCha20+RSA-2048, AES-256-GCM+ECC). This tells us if public decryptors exist, whether hybrid per-file keys are used, and where to hunt for session keys or nonces.

2. Known-good decryptors & config extraction — When a strain has a vetted decryptor (or a leaked builder/config), we extract victim ID, campaign key, and per-file metadata to feed the tool. Our wrappers validate output with per-file hashes and auto-skip corrupted headers.

3. Private lab decryptors (flawed variants) — We maintain proprietary modules for specific mis-implementations (e.g., IV reuse, CTR counter resets, truncated MACs). These attack logic errors rather than the cipher, enabling plaintext recovery without the private key in some variants.

4. GPU-accelerated keyspace attacks (weak KDFs/password gates) — For strains that gate decryption behind a human password or a weak KDF (PBKDF2 with low iteration count, custom SHA loops), we distribute attacks across multi-GPU rigs with mask/rule/PRINCE heuristics and domain wordlists. We strictly target the wrapper credential, not strong asymmetric keys.

5. In-memory key harvesting — Live response/RAM images are parsed for key schedules, NaCl boxes, OpenSSL EVP contexts, Windows DPAPI blobs, and process heaps. Keys or decrypted session states sometimes persist post-encryption; we carve them and replay decryption on images.

6. Volume Shadow Copy & snapshot restoration — If VSS wasn’t fully purged (or was blocked by ACL issues), we mount snapshot diffs from clones and extract pre-incident versions. On NAS/VM stacks (ZFS/Btrfs/APFS/VMware), we enumerate snapshots and clone them out read-only.

7. Journal-led file system rollback — NTFS $LogFile/$UsnJrnl, APFS snapshots/OMAP, EXT journal and XFS log allow rollback to a consistent prior state for many small files, even when payloads were encrypted. We replay journals on images to reconstruct directories and metadata.

8. Database-aware salvage — For SQL Server/Exchange/SQLite/QuickBooks/etc., we use WAL/redo logs and page-level checks to rebuild consistent databases, neutralising encrypted pages where possible and salvaging intact objects (tables, mailboxes, ledgers).

9. Partial file reconstruction (media & docs) — Many lockers encrypt only file headers/first N MB (“partial encryption” for speed). We repair PDF/JPEG/Office headers and rebuild MP4/MOV moov atoms from mdat, recovering playable media even when the header region is encrypted.

10. Differential recovery via dedup/backup stores — Corporate shares with block-level dedup (Windows Server, Veeam repositories, ZFS) often retain earlier block versions. We extract pre-incident chunks by content hash and rehydrate files without an online backup server.

11. Cloud version restoration — OneDrive/Google Drive/Dropbox maintain previous versions and server-side recycle bins. We map local paths to cloud object IDs and bulk-restore pre-incident revisions with rate-limited tooling, independent of the infected endpoint.

12. Misused randomness & IV/key reuse attacks — We test for nonce collisions (AES-GCM/CTR, ChaCha20) across encrypted files. Reused IVs leak XOR of plaintexts; with known-plaintext headers (file magic, OOXML ZIP central directory), we can recover chunks.

13. RSA/ECC implementation flaws — We search for short exponents, shared-prime RSA, or reused ephemeral keys in ECDH (Curve25519/secp256r1). Entropy or PRNG seeding bugs can allow private-key recovery; we run GCD/sca tests across captured public keys.

14. Config mistakes in builders — Some campaigns embed raw private keys or decryptor URLs in the binary or note. We statically extract configs and verify against C2/recovery logic—occasionally yielding direct decryption capability for that campaign.

15. Offline-key family handling (e.g., STOP/Djvu) — When a strain falls back to a global “offline key”, public keys or known offline secrets exist for portions of the corpus. We partition files by key ID and apply the correct decryptor paths only where viable.

16. Negotiated key ingestion (client-direct) — If a client (via counsel/insurer) obtains a decryptor/key from actors, we validate it in a sandbox, snapshot the environment, and run decryption offline on clones with tamper-checks, then verify outputs by hashes and file-open tests.

17. Restore from cold/offline media — We inventory USB disks, NAS snapshots that were air-gapped, and previous workstation images. Even partial restores (user profiles, project repos) greatly reduce downtime while we pursue cryptanalysis for the remainder.

18. Virtualisation rollbacks — For Hyper-V/ESXi, we mount VM-level snapshots, copy out VMDK/VHDX prior states, or reconstruct guests by stitching base + delta disks, ignoring the encrypted delta.

19. Forensic carving of plaintext artefacts — Lockers often miss temp folders, cache stores, and thumbnail databases. We carve for JPEG/Office/ZIP/RAW signatures in unallocated space/slack and recover intact payload fragments that evade the encryptor.

20. Email & collaboration system recovery — For M365/Exchange, we export pre-incident mailbox versions and SharePoint/Teams document versions via eDiscovery/graph flows; for on-prem, we replay EDB/JET logs on image copies.

21. Domain posture & propagation cut-off — We harden AD/Group Policy (disabling scheduled tasks/PS scripts used by actors), rotate credentials, and isolate storage so ongoing encryptor daemons can’t re-touch already recovered data.

22. RAID/NAS metadata rebuild first, decrypt second — On multi-disk systems we virtually reassemble arrays (mdadm/LSI/Adaptec/ZFS/Btrfs), fix parity/metadata, then target encryption artefacts. A stable volume is prerequisite to any cryptanalytic attempt.

23. File-type–specific repair pipelines — Custom repair for Office OOXML, AutoCAD DWG, Photoshop/Lightroom catalogs, FCP/ProRes containers—rebuilding internal indexes where only headers/TOCs were hit.

24. Key escrow & DPAPI recovery — Windows DPAPI master keys and domain backup keys can decrypt app secrets (e.g., cloud sync tokens, vaults). We leverage domain DPAPI backup to regain app access for version restores.

25. Metrics-driven triage & stop-loss — We quickly estimate recoverability: encryption coverage %, snapshot viability, key prospects. This informs whether to focus on non-decrypt restores or invest GPU/RAM for crypto attacks, reducing downtime and cost.

Important realities (straight talk)

• Modern crypto is strong. When actors used correctly implemented AES/ECC/RSA and scrubbed keys, decryption without keys is typically infeasible. Our wins often come from implementation mistakes, key artefacts, partial-encryption behaviour, or independent data versions (snapshots/cloud/dedup).

• We never run decryptors on live infected hosts or originals; everything runs on cloned media with hash verification and audit logs.

• If negotiation is pursued, it is always client-direct with legal/insurer oversight. We only validate any keys/tools obtained and perform safe bulk decryption.

Why Reading Data Recovery

• 25 years of incident response and forensic data recovery across consumer, enterprise and RAID/NAS/VM platforms.

• Proprietary decrypt/repair tooling for specific variants and multi-GPU infrastructure for credential/KDF attacks where appropriate.

• Deep file-system, database and media-container expertise to recover data even when decryption is not possible.

• Evidence-grade process: write-blocked imaging, SHA-256 manifests, and deliverables suitable for insurers and law enforcement.

Next steps (free diagnostic)

1. Isolate affected machines from the network; do not delete files or “clean” disks.

2. Contact us for rapid intake. We’ll advise on RAM capture (where safe) and collection.

3. Send storage to us (anti-static bag inside a padded envelope or small box), or book a courier/drop-off. We’ll perform a free diagnostic and present clear recovery options.

Reading Data Recovery — trusted partner for ransomware investigation, decryption and data restoration.