Ransomware recovery: the paths out, in the order they are tried

Encrypted data comes back along four paths, and our published position works them in one order: a backup restore, a free decryptor, forensic recovery of what survives on the disk, and — last — the ransom.

They are worked in that order, and the order is not a preference. As published: "We first assess all alternative recovery paths — backup restoration, free decryptors, forensic recovery — before any discussion of ransom payment as a last resort."

The reason the order runs that way is structural. A backup restore returns the estate as it stood at whichever restore points still exist, and needs nobody's cooperation. A public decryptor also needs nobody's cooperation, but it returns only what was encrypted, file by file, at whatever speed the tool runs. Forensic recovery returns what happens to have survived, which is not the same as what you need. The fourth path is the only one that requires a counterparty with an interest in the outcome.

Working them in order does not mean working them one at a time. All three are established concurrently, because each is a separate question against a separate part of the estate and none of them has to wait on the others. What the order governs is which answer you act on when more than one comes back.

This page is about what establishes each path, and what we do on each one. What the pay-or-not decision itself turns on is a separate question.

Path 1 — the backups

"Do you have backups" is not the question. Whatever answers it — a console, a contract, a colleague's recollection — has been answering it since long before the incident, and the answer has never been tested.

The question is whether a restore has been performed and verified, and on what date. Those are two different facts about the same system, and only the second one is evidence. A backup set that has never been restored is an assertion; a backup set that was restored last quarter, opened, and found to contain what it claimed to contain is a finding, and the date on it tells you how stale the finding is.

The second question is whether the backup was reachable from the compromised network, and it deserves to be asked plainly rather than assumed away. An operator whose entire leverage is your inability to restore has a direct interest in the copies that would let you. Anything an account taken from your estate could authenticate to is inside the estate for this purpose — a share, a backup server on the same domain, a cloud bucket whose credentials sit on a compromised host. What makes the answer to that question a no is a property of the copy rather than of the policy behind it — immutability, an offline copy, or a credential boundary the compromised estate cannot cross. It is a question about configuration, so it is answered by looking rather than by reconstructing anything.

There is a third fact, and it is the one that decides what a successful restore actually returns you to: the retention window against the start of the intrusion. A restore point that predates the earliest evidence of compromise gives you your data without the way in. A restore point from inside the compromise gives you both. Establishing when the intrusion began is a logs question, and it is the same logs question that answers how they got in.

What to do with all of that now, while it can still change the outcome:

• Pick a file that matters — a database, not a text document — and restore it to isolated infrastructure. Open it. Write down what you restored, where to, and whether it worked.
• Do not run that test onto the live estate. A restore into an environment you are still containing can put the payload's target back within reach of it.
• Freeze the backup schedule before any of this. A scheduled run can overwrite the restore point you are about to depend on.

If the restore works and the restore point is clean, the recovery is a restore. The remaining three paths become academic, and the work moves to the pre-restore gate below.

Path 2 — a free decryptor

Some ransomware families have a public decryption tool. That happens for reasons outside your incident — a flaw in the implementation, keys that became public, an infrastructure seizure. None of them is anything you can influence, which is why it is a lookup rather than a project. Whether yours is one of them is a question with an answer, and the answer costs nothing.

One place that answer lives is No More Ransom, which describes itself as "an initiative by the National High Tech Crime Unit of the Netherlands' police, Europol's European Cybercrime Centre, Kaspersky and McAfee…". Its Crypto Sheriff tool takes two encrypted files and the ransom note, and its instruction is exactly the job: "To help us define the type of ransomware affecting your device, please fill in the form below. This will enable us to check whether there is a solution available."

Two things follow from how the repository works.

The check depends on the family identification. A decryptor is written for a family, and a family is identified from the note, the extension, the encryption behaviour and the artefacts left on the host. That identification is what the check is for, and it is not something you have to arrive with — the tool reads it off the files you upload. What you can add to it, and where else to check, is its own piece of work. Our published scope for it is "Identify the specific ransomware variant, its known behaviors, and available decryption options."

The answer has a date on it. No More Ransom says so itself: "At the moment, not every type of ransomware has a solution. Keep checking this website as new keys and applications are added when available." A negative result is a negative result as at today, which is a reason to record the date you checked and to check again rather than to treat the door as closed.

Our published scope for this path is "Evaluate whether free decryptors exist, assess backup integrity, and determine the fastest path to data recovery" — the two questions sit in one assessment because whichever of them comes back positive first is the one that decides how the data returns. Neither of them ends the recovery — the gate below is the same either way.

Path 3 — forensic recovery

"Forensic recovery" covers a specific and bounded set of things, so it is worth being exact about what it reaches.

What it can reach. When a program deletes a file, the file's contents are not scrubbed off the disk. NIST's Guide to Integrating Forensic Techniques into Incident Response puts it plainly: "When a file is deleted, it is typically not erased from the media; instead, the information in the directory's data structure that points to the location of the file is marked as deleted. This means that the file is still stored on the media but is no longer enumerated by the OS. The operating system considers this to be free space and can overwrite any portion of or the entire deleted file at any time." The same section names two other places content survives: file slack space, the unused remainder of an allocation unit, which "may hold residual data such as portions of deleted files"; and free space, which NIST defines as "the area on media that is not allocated to any partition; it includes unallocated clusters or blocks" and describes as space that "often includes space on the media where files (and even entire volumes) may have resided at one point but have since been deleted. The free space may still contain pieces of data."

That paragraph is the whole basis of the path, and it points at one specific fact about your incident: whether the original file was overwritten where it lay, or whether a new encrypted file was written and the original deleted. In the second case the original content can still be sitting in unallocated space, unreferenced and intact, until the operating system reuses the blocks. In the first case it is not there to find.

Windows adds a second place to look. A shadow copy is, in Microsoft's own words, "a consistent shadow copy (also known as a snapshot or a point-in-time copy) of the data that is to be backed up", made by the Volume Shadow Copy Service. Whether any shadow copies still exist on a given host is a question about the state of that host, and it is answered on the host itself — which is why it is worth asking before the host is touched further.

What it cannot reach. Forensic recovery does not decrypt anything — an encrypted file recovered from unallocated space is still an encrypted file. It cannot reconstruct content whose blocks have been overwritten, by the payload or by anything else. It works host by host and file by file rather than restoring an estate, so what comes back is what survived, not what you would have chosen. And it competes with the machine's own ordinary use: NIST's sentence says the operating system "can overwrite any portion of or the entire deleted file at any time".

That is the operational consequence worth acting on. Continued use of a compromised host is what puts those blocks back in play. Taking a host out of service is what stops new writes competing for those blocks; carrying on with it is what spends the option. What is capturable is capturable now and no later — what to take, and in what order, is set out here.

Our published scope names this path in terms: "Recover data from backups, decryption tools, or forensic recovery methods to restore business operations."

Path 4 — the ransom, last

The parent publishes the firm's position on payment, and it is not neutral — it is answered there in terms. What this page owes you is why this path is fourth and not first.

Two things sit beside that and neither softens it.

The first is that the three paths above are what establish whether this one is even a question. A payment made while the backup restore was untested, or before the family was identified and checked against a public repository, is a payment made without knowing what was being bought.

The second is that the decision is the client's. We assess the paths and we say what we think. If a client decides to explore the fourth path, the first step is not a message to the operator — it is screening the group, its known aliases and any wallet address against the OFAC, UN and EU listings, and that is set out below. What we do not do is make the call for you. What the call actually turns on — the strain, the decryptor, the restore test, whether data left, and the commercial pressure that was in the room from minute one — is set out in the ransom decision.

Before anything comes back: the gate

None of the four paths is worth running into a compromised estate.

Restoring data onto systems that still carry the attacker's access returns you to hour zero with the same doors open, the same accounts valid and the same persistence in place. Eradication comes before restoration: the footholds go, the credentials that were valid during the compromise are treated as compromised, and systems are rebuilt and hardened before reconnection. On our own methodology: "Environment validated clean before bringing systems back online."

The full sequence — what to preserve, who to call, what is filed by hour six, and what has to be true before anything is restored — is the first seventy-two hours. This page does not repeat it.

What we do

Security Brigade runs full-lifecycle ransomware response. As published: "Not just containment. We manage the entire incident from the first call to full recovery and beyond." The four paths above are worked by the same team that contains the incident and files the notification. The sections below are what that covers; the engagement itself is linked at the foot of this page.

The six-hour filing, drafted and filed by us

Ransomware is on the CERT-In list by name. Annexure I to the Directions of 28 April 2022 lists twenty types of reportable cyber security incident and item (v) is "Malicious code attacks such as spreading of virus/worm/Trojan/Bots/ Spyware/Ransomware/Cryptominers". Direction (ii) reads: "Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents."

We take full ownership of that filing. As published: "We draft, file, and manage your mandatory CERT-In 6-hour incident notification on your behalf with full ownership." In an active recovery that matters for a practical reason — the deadline lands in the middle of the window where the recovery findings are still arriving, and it is the piece of work that slips when everyone in the room is looking at the encrypted fileserver.

The duty itself stays with your entity. CERT-In's own FAQ answers the question directly, at Q 13: "Any entity which notices the cyber security incident, shall report to CERT-In. The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with." We do the work; the obligation remains yours.

Negotiation and settlement, and the screening that comes first

Nothing goes to the operator until the screening is done. The group, its known aliases and any wallet address involved are screened against the U.S. Department of the Treasury's Specially Designated Nationals and Blocked Persons list, published by its Office of Foreign Assets Control (OFAC); the United Nations Security Council Consolidated List; and the European Union's consolidated list of individuals, groups and organisations subject to EU financial sanctions, before payment is discussed. The check, and its result, is recorded.

Those three lists, described by the bodies that publish them.

OFAC, part of the U.S. Department of the Treasury, on the first: "Published by OFAC, the SDN list contains the names of individuals, entities and groups designated by OFAC as well as the listing of maritime vessels and aircraft that are blocked by OFAC."

The United Nations Security Council, on the second: "The Consolidated List includes all individuals and entities subject to measures imposed by the Security Council."

And the European Commission, on the third: "The consolidated list of individuals, groups and organisations subject to EU financial sanctions, which DG FISMA manages and updates whenever necessary, reflects the officially adopted texts published in the Official Journal of the EU."

With the screening done and recorded, the service is the channel and the settlement:

• We open and run the channel with the threat actor on your behalf — the demands for proof of decryption, the management of the timeline, and the movement on price.
• We handle settlement where a payment is authorised: crypto acquisition, transfer, and verification that what was delivered decrypts.
• The pay or do-not-pay decision remains yours, and our published default is against it.

What the process looks like from the inside — what proof of decryption means, what is asked for and in what order, and what is recorded at each step — is set out separately.

If this is happening now

Security Brigade has been CERT-In empanelled since 2008. We respond 24/7.

+91 22 4164 2220

The engagement itself — how a ransomware response runs and what is delivered at the end — is on Security Brigade's ransomware response page.