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.
You are looking at a directory of files that all end in something you have never seen before, and a text file that was not there yesterday.
You know you have been hit. You do not know by what.
Get that answer early. Everything that follows turns on the family. Is there a free decryptor for this one? Does this operator publish what it takes? Is the group behind it named on a sanctions list? None of those can be asked until the family is named.
Three things name it, and the payload wrote all three: the extension, the note, and the contact route inside the note. Record whichever of them is in front of you. The services take one, two or all three, and reading them needs no tool and no licence.
Before anything else: the filing does not wait for the answer
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, 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."
The clock started when you noticed, and the identification runs alongside the filing. Give the filing to somebody who is not doing the identification: what actually goes in it, and who else is owed one.
The three identifiers
These are the three things the free identification services ask for. Write them all down before anyone re-images anything.
1. The extension appended to the encrypted files
Look at a directory of documents. Where the original names are intact with something added to the end, that added string is the identifier: invoice-april.xlsx has become invoice-april.xlsx.<something>. Where the filename has been replaced instead, the replacement pattern is what you record.
Record it exactly: the punctuation, the capitalisation, the length. If the added string differs from host to host, or contains what looks like an identifier or an email address, record two or three examples, and note where each came from.
The extension on its own can point at more than one family. ID Ransomware's own FAQ says why: "Many ransomware have similar 'signatures' in common, such as sharing the same extension on files. This makes it difficult to be 100% certain in some cases. Results are ordered by how many matches there are to prove it may be a particular ransomware."
So treat it as one of three inputs.
2. The ransom note, and its filename
The note is the file that appeared beside your data. ID Ransomware describes it as "The file that displays the ransom and payment information."
Two things identify it. Record both.
Its filename. The payload chose that name when it ran, which is what makes it identifying. Record it exactly as it appears, extension included, and note whether the same name repeats across directories, shares and hosts, or changes.
Its contents. The demand draws the eye, but read past it: look for a victim or campaign identifier, an instruction on how to make contact, and whatever branding the family puts on its own note. Copy the text out whole, do not summarise it, and keep it with the filename.
Do not delete the note. It is evidence, and it is the input to the identification.
3. The contact channel
Where the note gives a route back to the operator, that route is an identifier in its own right. Three shapes come up most often:
- A Tor address, a long string ending in
.onion, reachable only through the Tor browser. Copy the string; do not visit it yet. - An email address, sometimes several, sometimes on services chosen for the purpose.
- A chat portal, a web address that opens a session keyed to the identifier in your note.
Record whichever you have, character for character. Both identification services take these strings. Crypto Sheriff asks for "any email, website URL, onion or/and bitcoin address", and ID Ransomware takes contact addresses where no note is available. A Tor address or a portal URL is attacker-chosen, and far more distinctive than a three-character extension.
Opening the channel is a separate decision. It comes after identification, and it carries different consequences: what actually happens when the channel is opened.
Two free services that will read those three for you
Both are free and public, and both take the identifiers you just recorded. Neither needs access to your environment.
ID Ransomware
id-ransomware.malwarehunterteam.com, run by MalwareHunterTeam. Its own line: "Upload a ransom note and/or sample encrypted file to identify the ransomware that has encrypted your data."
What it accepts. Three fields, and the third takes no file at all:
| Field | The site's own description |
|---|---|
| Ransom Note | "The file that displays the ransom and payment information." |
| Sample Encrypted File | "A file which has been encrypted, and cannot be opened." |
| Addresses | "Optionally, you may enter any email addresses or hyperlinks the ransomware gives you for contact (if there is no ransom note)." |
What it returns. A family name, or several ranked by how many signatures matched, and a pointer to whether a known decryption route exists. It says plainly what it will not do: "Can you decrypt my data? No. This service is strictly for identifying what ransomware may have encrypted your files. It will attempt to point you in the right direction, and let you know if there is a known way of decrypting your files."
What it will not take. Malware. "This service will only assess the ransom note, and encrypted files to determine the ransomware."
On 2 September 2026 the site stated it detects 1186 different ransomwares and published the full list of names on the same page, with a footer reading "App v1.10.1, Updated 08/31/2026". Check the number on the day; it moves.
No More Ransom's Crypto Sheriff
nomoreransom.org. The project describes itself: "The 'No More Ransom' website is an initiative by the National High Tech Crime Unit of the Netherlands' police, Europol's European Cybercrime Centre, Kaspersky and McAfee with the goal to help victims of ransomware retrieve their encrypted data without having to pay the criminals."
Crypto Sheriff is its identification form. Its own instruction: "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. If there is, we will provide you with the link to download the decryption solution."
What it accepts.
- Up to two encrypted files, uploaded: "size cannot be larger than 1 MB".
- The strings from the note: "Type below any email, website URL, onion or/and bitcoin address you see in the RANSOM DEMAND. Note: Be especially accurate with the spelling."
- Or the note file itself: "Or upload the file (.txt or .html) with the ransom note left by criminals".
What it returns. The identification, and a direct link to a decryption tool where the project holds one. That link is the difference between the two services.
Its Report a Crime page hands victims to a national reporting route country by country. The CERT-In filing an Indian entity owes runs on its own clock and its own channels, published in Direction (ii) itself: email incident@cert-in.org.in, phone 1800-11-4949, fax 1800-11-6969.
Ransomwhere is a payment tracker
ransomwhe.re is Ransomwhere, "the open, crowdsourced ransomware payment tracker" built by Jack Cable, which collects Bitcoin addresses used to receive ransom payments and publishes the dataset. It will not identify your strain, and its submission form publishes what you send: "By submitting, you acknowledge that all contents of your report (besides your email, if submitted) will be made publicly available", with addresses "made public 90 days after being submitted".
Useful later to a researcher, but not in hour one.
What not to hand over while you are identifying
The phrase "upload a sample encrypted file" hides a decision, and it should be taken deliberately, not by reflex at 02:00.
The payload wrote the note and the extension, not you. The extension is a string of punctuation; the note is the attacker's own text. Read the note first for the victim or campaign identifier, and decide whether that identifier goes over with it. It is the only part of those two inputs that is about you.
An encrypted business file is still your data. The contents are unreadable, but the filename, the path it sat in and its size are yours, and they can describe a client, a matter or a deal. ID Ransomware states its own handling plainly: "Any uploaded files are immediately analysed against the database of signatures. If results are found, they are immedietely deleted. If no results are found, the uploaded files may be shared with trusted malware analysts to help with future detections, or identifying a new ransomware." And: "With that said, I cannot guarantee files are kept 100% confidential. The data is temporarily stored on a shared host."
So decide, and decide before you drag anything into a browser:
- Start with the note and the strings. Add a file only if the identification is still ambiguous without one.
- If you upload a file, pick one whose name and path say nothing: a test document, an image from a sample folder, anything encrypted in the same pass whose existence is not a fact about your business.
- Take the decision at the level where data leaves the organisation. In a regulated entity that is not the administrator holding the mouse.
And do not power the machine off to stop the encryption while you work this out. The evidence that answers the other questions (when it started, what ran, whether anything left) is partly in memory and partly in logs that a re-image ends. What to preserve before anyone rebuilds.
The free decryptor question
This is the reason identification comes first: where a decryptor exists, it ends the decision before any commercial conversation starts.
No More Ransom publishes decryption tools contributed by law enforcement and industry, listed alphabetically by family, each with the name of the organisation that built it. Counted on the page on 2 September 2026, it listed 183 named families and 222 downloadable tools. Tools are added, so re-read the figures on the day.
How to check. Two routes. The first needs the family name you established above; the second does not:
- Open the Decryption Tools page and search the family name in its search box. If a tool is listed, the family name will be there under its own heading.
- Or run Crypto Sheriff, which does the identification and the lookup in one pass, and returns the download link where one exists.
Two things the project says about this, in its own words. On whether yours will be there: "At the moment, not every type of ransomware has a solution. Keep checking this website as new keys and applications are added when available."
And on running one, from the top of the Decryption Tools page: "IMPORTANT! Before downloading and starting the solution, read the how-to guide. Make sure you remove the malware from your system first, otherwise it will repeatedly lock your system or encrypt files. Any reliable antivirus solution can do this for you."
That second one is the operational point. A decryptor does not remove what let the payload run, and running it on a host the attacker still holds returns you to where you started.
Security Brigade's scope for this step is "Evaluate whether free decryptors exist, assess backup integrity, and determine the fastest path to data recovery".
What the family name buys you, once you have it
Three things, and the rest of the week runs on them.
Whether the files can come back without paying. The decryptor question above, answered. It costs nothing to check, and it comes first.
Whether this is also a data breach. Some operators encrypt. Others take a copy first and run a site where victims are named and the data published. What the family is known for tells you where to look, and it changes the shape of the incident. Ransomware is Annexure I item (v). Where data was taken as well as encrypted, items (xi) Data Breach and (xii) Data Leak describe it too. Tick all of them, and a different set of people need to know.
The family name tells you what to look for. What happened to you is answered from your own evidence (outbound volumes, staged archives, access to shares in the hours before the payload) and from watching the places publication would appear. Our capability for the second half is "Dark Web Leak Monitoring — Continuous scanning of ransomware leak sites, forums, and marketplaces for your organisation's data." Treat a claim by the operators that data was taken as unverified, and treat the absence of one the same way.
Whether the group is on a sanctions list. This is where the family name stops being a technical detail. Individuals, groups and entities are named on published sanctions listings: the US Treasury's Specially Designated Nationals and Blocked Persons List, the United Nations Security Council Consolidated List, and the EU's consolidated list of individuals, groups and organisations subject to EU financial sanctions. OFAC describes its own, in FAQ 18: "As part of its enforcement efforts, OFAC publishes a list of individuals and companies owned or controlled by, or acting for or on behalf of, targeted countries. It also lists individuals, groups, and entities, such as terrorists and narcotics traffickers designated under programs that are not country-specific. Collectively, such individuals and companies are called 'Specially Designated Nationals' or 'SDNs.' Their assets are blocked and U.S. persons are generally prohibited from dealing with them." Cyber-related sanctions are one of the programmes it administers.
We run the check as a separate step, before a payment is discussed. Where we run a ransomware negotiation it is full-service. We open and run the channel with the threat actor, and we handle settlement: crypto acquisition, transfer, and verification of decryption. Before payment is discussed we screen the group, its known aliases and any wallet against the OFAC SDN, UN and EU listings, and we record the check.
The short version
- File at hour six. Ransomware is Annexure I item (v); Direction (ii) puts it on six hours, and the identification runs alongside the filing.
- Record three things: the extension appended to encrypted files, the ransom note's filename and its full text, and the contact channel (Tor address, email or portal), character for character.
- Run them through ID Ransomware (
id-ransomware.malwarehunterteam.com), which takes a note, an encrypted file, and the contact addresses where no note is available, and returns a family name or a ranked set of candidates. - Run them through Crypto Sheriff (
nomoreransom.org), which takes up to two encrypted files under 1 MB, the strings from the note, or the note file itself, and returns the decryption tool where the project has one. - Decide before you upload anything of yours. The note and the extension were written by the attacker. An encrypted file's name and path were written by you.
- Check the decryptor list before any commercial conversation. Free, immediate, and it can end the decision.
- Remove the malware before running a decryptor, or it encrypts again.
- Then ask the three family questions: decryptor, leak site, sanctions listing.
Once you have the family, the decision that follows has five inputs and four of them are establishable.
If you are in the middle of this now, we respond 24/7 on +91 22 4164 2220.
About the authors
Shalabh D
Lead — Managed Security Services
Security researcher and penetration tester passionate about making the internet safer. Active CTF player, bug bounty hunter, and hands-on practitioner across web, network, and application security.
Abhinav A
Lead — VAPT & Security Assessments
Leads Security Brigade's VAPT delivery team, having progressed from Security Consultant to Team Lead. Has executed advanced penetration tests across BFSI, fintech, QSR and telecom.
Continue reading
All articles →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, only as a last resort, the ransom. Each one turns on a fact about your environment you can establish before you commit to it, 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.
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.