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

Encrypted data comes back along four paths, and we work them in this order: a backup restore, a free decryptor, forensic recovery of what survives on the disk, and last, the ransom.

That order is 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 order follows from what each path needs to work. 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 only what happens to have survived. The fourth path is the only one that needs the attacker to cooperate.

The first three run concurrently. They draw on different parts of the estate, so none has to wait on the others. The order decides which answer you act on when more than one comes back.

What follows sets out what each path depends on, and what we do on it. The pay-or-not decision itself is covered separately.

Path 1: the backups

Everyone has an answer to "Do you have backups". It comes from a console, a contract or a colleague's recollection, and in most cases it has never been tested.

The question is whether a restore has been performed and verified, and on what date. A backup set that has never been restored is untested, whatever the console says. One that was restored last quarter, opened, and found to hold the data it claimed to hold has been tested, and the date tells you how recent that test is.

The second question is whether the backup was reachable from the compromised network. An operator whose leverage rests on your inability to restore will have gone looking for 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. A no has to rest on something about the copy itself: immutability, an offline copy, or a credential boundary the compromised estate cannot cross. A policy document does not establish that. Go and look at the configuration.

A third fact 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. The logs establish when the intrusion began, and the same log review answers how they got in.

What to do now, while it can still change the outcome:

• Pick a file that matters: a database, not a text document. 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 puts the data straight back where the payload can reach 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, that is your recovery. The other three paths stop mattering, 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. Checking whether yours is one of them costs nothing.

One place to check 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. The instruction on the page says what it does: "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. Working out the family is what the check is for, so you do not have to arrive with it: 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 behaviours, 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 only good for the day you got it. Record the date you checked, and check again.

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 run as one assessment, because whichever comes back positive first decides how the data returns. Neither ends the recovery: the gate below applies either way.

Path 3: forensic recovery

"Forensic recovery" covers a narrow set of techniques. Be exact about what they reach.

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 is the whole basis of the path, and it turns on one 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 survive is a per-host question. Check 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, so what comes back is whatever survived. And it competes with the machine's own ordinary use: NIST says the operating system "can overwrite any portion of or the entire deleted file at any time".

Every hour a compromised host stays in service, new writes compete for those blocks. Taking it out of service stops the clock. Leaving it running costs you data that was still recoverable. What to take, and in what order, is set out here.

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

Path 4: the ransom, last

Our position on payment is published on the parent page. What follows is why this path comes fourth.

The three paths above establish whether this one arises at all. 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 decision is the client's. We assess the paths and we say what we think. If a client decides to explore the fourth path, screening comes before any contact with the operator: the group, its known aliases and any wallet address, against the OFAC, UN and EU listings. That is set out below. The call turns on the strain, the decryptor, the restore test, whether data left, and the commercial pressure you are under. It is set out in the ransom decision.

Before anything comes back: the gate

None of the four paths should be run 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. From our own methodology: "Environment validated clean before bringing systems back online."

The full sequence, covering 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.

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 set out what that covers.

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." That matters in an active recovery: the deadline lands while the recovery findings are still arriving, and it is the 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.

Here is each of the three, described by the body that publishes it.

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 covers 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 proof of decryption means, what is asked for and in what order, and what is recorded at each step are 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

How a ransomware response runs, and what is delivered at the end, is on Security Brigade's ransomware response page.