Every victim listing, from countdown to removal.

Follow leak-site listings by group, sector, country, deadline and claimed size. Files stay references, and leaked data is never downloaded.

The ransomware view in the product: the board of victim listings, with one listing open showing its status, victim, timeline, deadline and evidence.

Product screen with fictional data

Ransomware leak site monitoring, without touching the data.

Listings from the leak sites you follow land on one board: victim, group, country, sector, deadline, claimed size, mirrors and status.

Get alerted when a supplier or partner appears.

The ransomware board in the product: one row per victim listing with its group, country and sector, disclosure date, deadline, claimed size, mirrors and status.
The same board with one listing open: its status, victim, country and sector, a timeline with the deadline, first and last time seen, and the evidence for the capture.
The ransomware board in the product: one row per victim listing with its group, country and sector, disclosure date, deadline, claimed size, mirrors and status.
The same board with one listing open: its status, victim, country and sector, a timeline with the deadline, first and last time seen, and the evidence for the capture.

What each row of the board carries

  • Who the listing names
  • The group that posted it
  • Country and sector, checked
  • When the listing went up
  • The group’s deadline
  • The size the group claims
  • Mirrors on record
  • Where the listing stands

What an open listing shows

  • Status, as the leak site shows it
  • Country and sector, checked
  • The group’s deadline
  • Evidence for this capture

Product screen with fictional data

The victim profile, kept apart from the claim.

{{PRODUCT_NAME}} records who a listing names and where they are based, and keeps the group’s own words and numbers exactly as the group wrote them.

  1. Country, checked

    Inferred from the listing and checked against a fixed list of countries. A city or a region never passes as a country.

  2. Sector, from a fixed list

    Each victim is placed in one industry from a fixed list, so sectors stay comparable from one group to the next.

  3. Empty rather than wrong

    When the listing does not say, the field stays empty instead of guessing.

  4. The claim, untouched

    The group’s description and claimed size are kept word for word, next to what {{PRODUCT_NAME}} recorded.

Recorded by {{PRODUCT_NAME}}

One listing open in the product: the victim, its country and sector, the group and source, a timeline with the deadline and evidence, and the group’s own description below.

Written by the group

Recorded by {{PRODUCT_NAME}}

One listing open in the product: the victim, its country and sector, the group and source, a timeline with the deadline and evidence, and the group’s own description below.

Written by the group

Product screen with fictional data

From countdown to publication, on the record.

Listings change: timers run out, proof is added, mirrors appear, entries vanish. Each change is captured again, with a new page hash.

Listed with a timer

The group posts the victim with proof and a deadline. The listing is first seen minutes later.

Proof added, mirrors appear

Hours before the deadline, more proof and two mirrors appear. A new capture records the change.

Deadline passes, data published

The timer runs out and the listing turns to published, with every file kept as a reference.

Taken down, still on record

When the entry disappears, the record and every earlier capture stay, with the last time it was seen.

  1. CountdownEvidenceev_5b20e7a1Listed with a timerThe group posts the victim with proof and a deadline. The listing is first seen minutes later.
    The listing as first captured: status countdown, the deadline days away, no modification yet, and its first evidence.
  2. CountdownEvidenceev_5b9c4d18Proof added, mirrors appearHours before the deadline, more proof and two mirrors appear. A new capture records the change.
    The same listing hours before its deadline: still a countdown, modified that afternoon, with new evidence.
  3. PublishedEvidenceev_5ba1f063Deadline passes, data publishedThe timer runs out and the listing turns to published, with every file kept as a reference.
    The same listing after its deadline: status published, the deadline minutes ago, and new evidence.
  4. RemovedEvidenceev_5d0e9b42Taken down, still on recordWhen the entry disappears, the record and every earlier capture stay, with the last time it was seen.
    The same listing after it was taken down: status removed, last seen the evening before, and its last evidence.

Product screen with fictional data

Files stay references. Nothing is downloaded.

The group publishes names, sizes and links. {{PRODUCT_NAME}} keeps them as defanged references and reads the file listing, never the files.

  • Defanged references

    Every file and mirror link is stored defanged, so nobody opens one by accident.

  • Counted, not opened

    Totals come from the published listing: how many files, how large, and in which folders.

  • Mirrors on record

    Every mirror the group lists is recorded with the listing, in the same defanged form.

No download control

The interface has no control that fetches leaked data, for any role.

A victim’s leak-site facts in the product: deadline, status, claimed size, the published file and mirror links shown defanged, and the folder listing with file counts and sizes.
A victim’s leak-site facts in the product: deadline, status, claimed size, the published file and mirror links shown defanged, and the folder listing with file counts and sizes.
Product screen with fictional data

How leak sites are reached and kept healthy.

Leak sites are slow, unstable and change without notice. Collection is built to fail safe and to notice every change.

  1. Managed Tor egress

    Onion sites are reached only through a managed Tor route. If the route is not safe, nothing is fetched.

  2. Plain page capture

    Most leak sites are read as plain HTTP pages. A browser is used only where a site needs one.

  3. Families share a parser

    Sites built the same way share one listing parser. Each site’s own details live in a short declaration.

  4. One record per victim

    One listing page becomes one record per victim, without visiting each victim’s page.

  5. Captured at every change

    Each version of the page is stored with its hash, so any earlier state can be shown.

Silence is never mistaken for safety.

  • An empty page is never read as zero new victims. It raises a health alert.

  • A running countdown brings the next capture forward to its deadline.

  • When a site changes its layout, the source is flagged instead of going quiet.

See it on your own sources.

Tell us what you need. We will walk you through a live capture, from post to sealed record.

Request a briefing

Prefer email? Write to {{CONTACT_EMAIL}}.