Skip to content

Ransomware leak sites: what a claim means, and what to do

A leak-site claim is a post on a ransomware group's own website naming an organisation it says it has attacked; this guide covers how reliable such claims are, how they are matched to an organisation and the first steps if yours is named.

By the TrustSek editorial team · Last reviewed

Module
Ransomware exposure · 20%
Trackers
Two, independent
Claim within 12 months
Critical

Most ransomware groups now steal data before they encrypt it, and many run a public website where they name the organisations they say they have attacked. Those claims are read by journalists, researchers, insurers and, increasingly, by customers checking their suppliers.

This guide explains what a claim is and is not, how claims are collected and matched to an organisation, where matching goes wrong, and what to do if your organisation appears. It is not legal advice. If you are dealing with an incident now, bring in your incident response provider and legal counsel first, and come back to this later.

What a leak-site claim is

A leak site is a website run by a ransomware group, usually reachable only through Tor. When a victim does not pay, or to add pressure during negotiation, the group posts the victim's name, often with a countdown, a description of the data it says it holds, and sample files. If the deadline passes, the group may publish the data.

A post is a claim by a criminal group. It is usually, but not always, accurate:

  • Usually accurate, because a group that names victims it never attacked loses the credibility its extortion depends on.
  • Sometimes wrong or misleading. Groups repost old incidents, claim data that came from an earlier breach or from a supplier, exaggerate what they took, or name a parent company when a subsidiary was hit. Some groups have posted fabricated claims to look more active.

Not every attack appears on a leak site. Victims who pay, or who are still negotiating, are often not posted. The absence of a claim is not evidence that nothing happened.

Why insurers and customers pay attention

A leak-site claim is one of the few signals about a past incident that anyone can see from the outside:

  • Insurers and brokers read it as evidence that an intrusion succeeded, and ask what has changed since. Expect questions about how the attacker got in, whether that route is closed, and whether backups and access controls have been improved.
  • Customers and procurement teams doing supplier assessments ask whether their own data was affected, and whether you told them in time.
  • Regulators may ask whether the incident was reported where it had to be.

A claim does not decide any of these conversations, but it starts them. It is better to know about it, and have answers ready, before someone else raises it.

How claims are tracked

Leak sites move, go offline and change format often, so most people follow them through trackers: services that visit the leak sites, record each post with the group name and date, and publish the list. Two independent examples are ransomware.live and RansomLook. Both are public.

Using two trackers matters. Each misses posts the other catches, and when both independently record the same post, the claim is corroborated. TrustSek searches both and merges a post seen on both into one claim, so it is never counted twice.

False positives and name collisions

Matching a leak-site post to a real organisation is harder than it looks. Posts name victims in different ways: a full legal name, a trading name, a domain, a brand, sometimes a misspelling. Common problems:

  • Shared names. Many companies in different countries share a name, or a name that differs only in the legal suffix. A post about a company abroad can look like a claim against yours.
  • Related entities. A post may name a group company, a former owner or a supplier that held your data, rather than your organisation itself.
  • Other companies in the text. Posts often mention customers or partners of the victim. Being mentioned is not being claimed.
  • Trading names. A victim posted under a brand name the matcher does not know is missed entirely.

TrustSek matches conservatively. An organisation name is compared only with the victim name or title of a post, never with the free text, because post descriptions routinely name other companies. The domain is matched too. The trade-off is deliberate: fewer false matches, at the cost of occasionally missing a victim posted under an unfamiliar name.

If you see a claim that looks like yours, check the post itself on the tracker: the group, the date, the domain, the country and sector the post gives, and any sample file names. If you believe TrustSek has matched your organisation wrongly, write to support@trustsek.com with the details.

If your organisation is named

Stay calm and work in order. A claim can be days or weeks old by the time you see it, so the first question is whether you already know about the incident.

If it is new to you, treat it as an active incident.

  1. Start your incident response plan and bring in your incident response provider. If you have cyber insurance, the policy often names the providers to use and sets conditions for notifying the insurer promptly, so read it and call the insurer or broker early.
  2. Preserve evidence before cleaning anything up: logs, affected systems, the leak-site post and its timestamp. Let your responders collect the post and any published data; downloading leaked data yourself can create its own legal and security problems.
  3. Find the way in and close it. A claim usually means data left your network. Restoring from backups does not undo that, and the same access is often sold on to other groups. Reset credentials, review remote access and look for persistence.
  4. Report the crime to the police.
  5. Leave contact with the group to your responders and counsel. Decisions about engaging with the group, or about payment, have legal and sanctions implications and are not for an individual to make.

Bring in legal counsel and your data protection officer early, because the notification clocks may already be running:

  • Personal data (GDPR). If personal data may have been accessed or taken, the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to people (GDPR Article 33). In Sweden that authority is IMY, Integritetsskyddsmyndigheten. Where the risk to people is high, they must also be told (Article 34). Every breach must be documented, including those not notified.
  • NIS2. Organisations covered by NIS2, in Sweden through cybersäkerhetslagen, have separate duties to report significant incidents, starting with an early warning within 24 hours (NIS2 Article 23). See NIS2.
  • Contracts. Customer contracts and data processing agreements often require you to inform customers within a set time. If you process data for others, tell them without undue delay so they can meet their own duties.

Prepare what you will say. Customers, staff and possibly the press will ask. Say what you know, what you are doing and when you will update them. Do not speculate about the attackers' claims.

If it is a known past incident, make sure the record shows what was done: how the attacker got in, that the route is closed, which notifications were made and when. That is what an insurer or customer will ask for when they see the claim.

How TrustSek reports it

TrustSek's ransomware exposure module searches the organisation name and domain against the two trackers during every scan. It is a reading at one point in time. What a scan reports:

What the scan findsFindingSeverity
A claim whose most recent post is within the last 12 monthsActive ransomware claimCritical
A claim older than 12 monthsHistorical ransomware claimHigh
No matching post on either trackerNo finding

A recent claim is serious enough to set a minimum score on its own, in the High band or above, regardless of the rest of the domain. The finding says how many trackers recorded the claim and, where the data has them, which group posted it and how many separate incidents were found. Its confidence is highest when both trackers agree, and lower when only one records the post or the name match is weaker. A claim stays on the record because the incident happened. Its severity drops once the most recent post is more than 12 months old; fixing the cause does not remove it, which is why the record of what you did matters.

Each tracker ends a scan as Found, No match, Failed or Not checked. Only No match on both means neither tracker has a matching post, and even then, as above, that does not prove no attack took place. The methodology explains how severity, confidence and score floors work.

In short

A leak-site claim is a criminal group's statement, usually accurate but not always. Check the post itself before acting. If it is new to you, treat it as an incident: responders, evidence, the way in, police, insurer. Involve legal counsel and your DPO at once, because the GDPR clock runs from when you become aware. Keep a record of what was done, because that is what others will ask for.

Check whether your organisation is named on a leak site

See what the two leak-site trackers hold for your organisation today, alongside email security, TLS and the rest of the outside-in score.

Free, no sign-up. Takes about 30 seconds.

Sources