Skip to main content

Resources

Guides, templates, and educational content about this site may be hacked.

Downloads

Free, no obligation. We email a confirmation link, then the file.

Guides and templates

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

Data comes back one of four ways: a backup restore that has actually been verified, a free decryptor for the family you are really dealing with, forensic recovery of what survives on the disk, and — last, and only as a last resort — the ransom. Each turns on a fact about your environment that can be established rather than guessed, and none of them is worth doing until the estate is clean.

What ransomware negotiation actually looks like

The sanctions question comes before the price question, and it decides whether there is anything to discuss at all. What a negotiation channel does, in the order it does it: who is on the other end under a ransomware-as-a-service model, why proof of decryption has to be run on files you choose, what a deletion promise is and is not, and why the six-hour CERT-In filing runs whatever is happening in the chat.

Which ransomware is this, and what the family name decides

You know you are encrypted. You do not yet know by what — and the questions that follow are all questions about the family: whether a free decryptor already exists for it, whether its operator publishes stolen data, whether the group appears on a sanctions list. Three things the payload left on your screen name it, two free services will read them for you, and none of it needs a vendor or a tool you do not have.

Business email compromise — the money left this morning

A payment went to an account that was not your supplier's. The instinct is to chase the money, and that is right — but a BEC is a mailbox intrusion first and a fraud second, and the two run on different clocks. What to do in the first hours, in what order, and why the mailbox investigation cannot wait for the recovery attempt.

How they got in — and why your logs decide whether you can answer

The morning after, the question is how. A short list of entry classes, each confirmed from a different record — and every one of those records is a log with a retention window set by whoever runs the infrastructure. Where that window is shorter than the intrusion, the honest finding is 'root cause undetermined' — and this is how to write one.

Website defacement, or a Google warning on your site: the first hour

A replaced homepage, or a Chrome warning on your site. What to copy before you touch the server, and the CERT-In clause that puts a defaced site on a six-hour clock.

What the ransom decision actually turns on

By the time the question reaches you it is usually framed as pay or don't. It is really five separate findings, and four of them can be established in the first two days: which strain it is, whether a decryptor already exists, whether your backups actually restore, and whether data left the building. The six-hour CERT-In filing is due either way.

Preserve it before you rebuild

Powering the machine off, restoring from backup, re-imaging, and quietly cleaning up: four reasonable instincts, each of which destroys something no technique recovers afterwards. What each one takes with it, and a preservation sequence a system owner can work through with what they already have — before anyone with a forensics kit arrives.

The six-hour report: what actually gets sent, and who else you owe

You noticed at 09:40. CERT-In is due by 15:40. What goes in the six-hour report, who sends it, and which other regulators are owed a filing too.

The first hour, and the first seventy-two

The order to work in from the moment you find out: what to stop doing, what to preserve, who to call, and what CERT-In's Direction (ii) of 28 April 2022 requires within six hours of noticing an incident or being brought to notice about it. Preservation comes before remediation — a rebuilt server is an answer nobody can reconstruct.