IronSights

Technical whitepaper · Case study

Reading around ransomware: recovering data and evidence from partially encrypted files.

How a business database and a domain controller were recovered from a ransomware attack without paying and without breaking the encryption, and the validation and investigation discipline that made the outcome trustworthy.

By Ryan Balloot, Microsoft Certified: Cybersecurity Architect Expert12 July 202615 min read
Download the full whitepaper (PDF)Ransomware recovery service

Abstract

The short version of a hard recovery.

Organisations hit by ransomware are usually told that their only options are to restore from backup or to pay for a decryption key. When backups have failed and no key is available, the data is written off. This paper documents a different outcome, drawn from a real engagement, and the discipline required to reach it safely.

The enabling weakness is partial encryption: to run quickly on large files, many ransomware families overwrite only the front of each file and leave the bulk of the payload intact. Nothing in this work breaks the cryptography. The recovery reads around the damage rather than attacking the mathematics, exploiting a weak implementation rather than a weak cipher.

We then argue the central point: a recovery that reports success is not a verified recovery. And because the same reading of intact structures recovered the system logs, the effort became an investigation as well as a recovery.

Keywords: ransomware, intermittent encryption, partial encryption, data recovery, data validation, incident response, digital investigation, indicators of compromise.

Key findings

What the case actually shows.

Partial encryption is a recovery opportunity

To run fast, ransomware overwrites only the front of large files and leaves the bulk of the data intact. The recovery reads around the damage. It never breaks the cipher.

The technique fits the artefact

A database is rebuilt by page-level carving of its intact pages. A virtual disk is recovered by computing its layout and reading the intact filesystem directly: whole files, not fragments.

A recovery is not a verified recovery

Carving tools report success and hand back data that looks complete but is quietly wrong. Only reconciliation against a point-in-time baseline separates real data from artefacts.

Recovery doubles as investigation

The same reading of intact structures recovered the system logs, which established the indicators of compromise and reconstructed exactly how the attack unfolded.

The outcome

Around three-quarters of the records returned, without paying, without the attacker's key, and without breaking the encryption.

Foreseeable, and foreseen

The controls that would have prevented it were unremarkable, and a prior security assessment had predicted the attack path exactly.

The dangerous failure mode is not a recovery that errors. It is one that succeeds and lies.

The paper's central argument.

The idea in two diagrams

Read around the damage, never through it.

A LARGE FILE (database, virtual disk)ENCRYPTEDfront onlyINTACT DATA, never touchedthe bulk of the payload, left unmodified for speedRecovered by reading the file's own structure. No decryption.
Figure 1. Ransomware encrypts only the front of a large file for speed, leaving most of the data intact. The recovery reads that intact remainder using the file's own structure. It does not break the encryption.
WHY THE ENCRYPTION CANNOT BE BROKENEncrypted contentAES-256-CBCIts AES keyRSA-wrappedAttacker's RSA keyheld only by the attackerWe hold none of these keys, so we never break the encryption.We recover the data that was never encrypted in the first place.
Figure 2. The encryption is sound: file content is encrypted with AES-256-CBC, and each file's AES key is itself wrapped with the attacker's RSA key. No key is recoverable, which is why the recovery reads around the damage rather than attacking the cipher.

Inside the full paper

Nine sections, fully worked.

The complete case study, with the concrete disk offsets, the crypto construction, the validation checks, and the investigation discipline, is in the whitepaper.

Download the PDF

12 pages · ~15 min read

  1. 01

    Background

    Partial encryption, and the principle of reading around the damage rather than through it.

  2. 02

    Recovery methodology

    Establishing which regions survived, the two recovery techniques, and rebuilding.

  3. 03

    Validation

    Why a recovery that reports success is not a verified recovery, and the two checks that catch it.

  4. 04

    The engagement

    The three recovery mechanisms across a database, a domain controller, and the initial foothold.

  5. 05

    Establishing what happened

    Confirmed versus indicated, multi-source corroboration, and the credential-cascade blast radius.

  6. 06

    Results and honest limits

    What the approach returns, and plainly where it does not apply.

  7. 07

    Prevention

    The controls that would have stopped it, and the fact that the path was foreseen.

  8. 08

    Reporting obligations

    How recovery sits alongside breach-notification and payment-reporting duties.

How to cite

Balloot, R. (2026). Reading around ransomware: recovering data and evidence from partially encrypted files. IronSights, Sydney.

About the author

Ryan Balloot is the managing director of IronSights, a Sydney cyber security firm he founded out of a passion for securing small business, and a Microsoft Certified: Cybersecurity Architect Expert. Contact [email protected] or 1300 004 766.

In an incident now?

Hit by ransomware? You might not have to pay.

If your backups are gone and a ransom is on the table, talk to us before you pay. We assess what is recoverable and what your obligations are.

Ransomware data recovery→