What the ransom decision actually turns on

The question arrives already framed as a binary, usually by somebody who needs an answer in the next few hours: do we pay or not?

It is not one question. It is five findings, and four of them are establishable — not guessable — inside the first forty-eight hours. A decision made before the four are in is a decision made on the fifth alone — the commercial pressure, which was in the room from the first minute.

This page is about the four. It is not about our view of whether you should pay; that is answered on our ransomware response page, and it is a different subject from what the decision turns on.

Before anything else: the clock is running and it does not wait for this

Ransomware is on the six-hour list by name.

Annexure I to the CERT-In Directions of 28 April 2022 lists twenty types of cyber security incident that must be reported to CERT-In, and item (v) is "Malicious code attacks such as spreading of virus/worm/Trojan/Bots/ Spyware/Ransomware/Cryptominers". Direction (ii) requires any service provider, intermediary, data centre, body corporate and Government organisation to 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".

Where data was taken as well as encrypted, items (xi) Data Breach and (xii) Data Leak describe it too. Tick all of them.

Two things follow, and they matter to the decision.

The filing is due at hour six, and CERT-In provides in terms for filing on what you hold at the time. FAQ Q 30: "The entities may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In." Send what you have at hour five.

And the deadline sits in the middle of the window where the four findings arrive. Nobody gets to work the decision first and file afterwards. Assign the filing to a different person from the one running the recovery, now, or it will slip while everyone is looking at the encrypted fileserver.

For a SEBI regulated entity there is a further consequence. Annexure-O of the CSCRF classifies a "ransomware attack" as Critical in Table 35, in terms. Clause A.4 reinforces it from another direction: "Any cyber incident that results in disruption, stoppage or variance in the normal functions/ operations of systems of the entity thereby impacting normal/ regular service delivery and functioning of the entity, must be classified as High or Critical incident." Two consequences follow, and they are separate. Table 36 attaches an interim report at 3 days, mitigation measures at 7, a root cause analysis at 30 and a VAPT at 45 to an incident reported to SEBI, running from the date it was reported or you were brought to notice of it — those run whatever the severity. What the Critical classification adds is clause 4.1: for all incidents classified High or Critical, the RE shall submit a forensic audit or investigation report. The severity is not a judgement call for this event type.

Finding 1 — which strain, and what is already known about it

Every subsequent question depends on this one, and it is usually answerable in hours.

The ransom note, the file extension, the encryption behaviour and the artefacts left on the host generally identify the family. That identification is not a curiosity: for a given family there is often a public body of knowledge about whether the encryption has been implemented correctly, whether keys have leaked or been seized, whether the operators have historically supplied working decryptors, and whether "the operators" is even a stable group rather than an affiliate using a rented toolkit.

Security Brigade's published scope for this is "Identify the specific ransomware variant, its known behaviors, and available decryption options."

The reason to do it first is that it can end the decision. Which is finding 2.

Finding 2 — does a free decryptor already exist

Some families have one, because the encryption was implemented badly, or keys were published, or law enforcement seized infrastructure and released them. Whether yours is among them is a question with an answer, and the answer is free.

This is a checkable fact, not an optimistic hope, and it is checked against the strain from finding 1. Our published scope: "Evaluate whether free decryptors exist, assess backup integrity, and determine the fastest path to data recovery."

Check it before any commercial conversation. A payment made for a family whose decryptor is already public buys something that was available for nothing.

Finding 3 — do the backups actually restore

Not "do we have backups". Not "the console says the job succeeded". Restore something, to somewhere isolated, and open it.

This is the finding that is easiest to feel certain about without having tested it, and the four ways it goes wrong are worth naming because each is discovered late:

• The backups completed but were never restore-tested, and a restore fails or produces unusable data.
• The backups are on infrastructure the attacker also reached, and were encrypted or deleted before the payload ran. Backups are a target in their own right, not collateral.
• The retention window is shorter than the intrusion, so every available restore point is inside the compromise and puts the way in back with the data.
• The most recent clean restore point is old enough that the data gap is itself the business problem, which turns a technical question into a commercial one.

Test the restore on a system that is isolated from production. A restore test performed onto the live estate during an active incident can re-expose the environment you are trying to contain.

Until this finding is in, nobody knows what is actually being bought.

Finding 4 — did data leave

Encryption is the visible half. Whether data was taken is the half that determines what you are exposed to after recovery, and it is a separate investigation from the restore.

It is answered from evidence: outbound volumes, connections to unfamiliar destinations, archives staged on hosts that have no reason to hold them, access to file shares and databases in the hours before the payload. That evidence lives in logs, and the logs are subject to a retention window. Pull them now, before the window moves past the start of the intrusion.

A claim by the operators that data was taken is not evidence that it was, and the absence of a claim is not evidence that it was not. Both are assertions by a party with an interest in the answer.

This finding also changes the regulatory picture rather than just the commercial one: an event that is item (v) alone and an event that is items (v), (xi) and (xii) are different filings, and for a SEBI RE exfiltration of market sensitive data appears in Table 35's Critical row in its own right.

Finding 5 — the pressure, named out loud

The fifth input is not technical and does not arrive on a timeline. It is the cost of the outage per day, the contractual commitments coming due, the customers already asking, and the board's tolerance for a public incident.

It is legitimate. It is also the only one of the five that is present from minute one and grows louder every hour, which means an undisciplined process weights it far above the four findings that are still being established. That is the failure mode: the decision is not made badly on the evidence, it is made before the evidence.

Write down, at hour six, what the four findings are expected to say and when. Then decide when they arrive.

What a decision record should contain

Whatever is decided, the record is what a board, an insurer, a regulator or a customer will ask for, and it is easier to write contemporaneously than to reconstruct.

• The strain, and how it was identified.
• Whether a public decryptor exists for it, and when that was checked.
• The restore test: what was restored, where to, and whether it opened.
• What the evidence says about data leaving, and the basis for that finding.
• Who made the decision, on what information, and at what time.
• The filings made, with channel and timestamp.

Whichever way it goes, the recovery work is the same

A decryptor — supplied or public — decrypts files. It does not remove the access that let the payload run, the accounts that were created, or the persistence that will still be there next month. Recovery is not decryption.

Our published eradication scope is to "systematically remove all attacker footholds including backdoors, persistence mechanisms, compromised accounts, and malicious code". That work is the same whether the files came back from a backup, from a public decryptor, or from anywhere else, and skipping it is what produces the second incident four weeks later.

The short version

• File at hour six. Ransomware is Annexure I item (v); Direction (ii) puts it on six hours. Send what you have — FAQ Q 30 provides for the follow-up.
• Identify the strain, because everything else depends on it.
• Check for a public decryptor before any commercial conversation.
• Restore something and open it, on isolated infrastructure. "We have backups" is not a finding.
• Investigate whether data left, from your own logs, not from what you are told.
• Name the commercial pressure as an input rather than letting it act as the answer.
• Do the eradication either way, or the next one is already scheduled.

If you are in the middle of this now, we respond 24/7 — +91 22 4164 2220.