Every active ransomware operation in 2026 runs at least one leak site. The site is where stolen data is published when victims refuse to pay, where new victims are listed during the negotiation period, and where the operator’s PR efforts (such as they are) play out. For threat intelligence, journalism, breach response, and academic study, leak-site tracking is one of the most consequential OSINT specialties.
It is also one of the most ethically complex. The data on these sites is typically stolen; downloading it is sometimes illegal in jurisdictions with computer-misuse laws regardless of the downloader’s intent; and engaging with the criminal infrastructure carries practitioner risks. The discipline has converged on a set of techniques and conventions that work within these constraints.
The landscape of leak sites
Most ransomware leak sites are hosted on Tor hidden services with .onion addresses. A smaller number are on the clearnet, sometimes deliberately, sometimes because operators have been forced off Tor.
A leak site typically contains:
A roster of victims. Organisations that the group has compromised, with countdowns to data publication and a brief description of what was stolen.
Sample data. Small extracts of stolen data shown publicly to demonstrate authenticity and create pressure.
Full data dumps. After the negotiation deadline expires, the complete stolen data is published.
Communications. The group’s contact information, sometimes including chat-portal URLs for victim negotiations.
PR. Statements about specific victims, broader threats, or the group’s operational status.
Active leak sites in 2026 include those operated by Akira, Play, RansomHub, BlackBasta (in various forms post-leak), Cl0p (mostly active during their campaigns), Medusa, Lynx, and many smaller operators. The list shifts continuously as operations rebrand and disappear.
The tracking community
Several public projects monitor leak sites systematically:
Ransomwatch (ransomwatch.telemetry.ltd). Publicly accessible aggregator that monitors a wide set of leak sites and publishes the data in a structured format. The associated GitHub repository at github.com/joshhighet/ransomwatch contains the scraping infrastructure.
DarkFeed.io. Commercial threat-intelligence service with leak-site coverage as a core feature.
Recorded Future, Mandiant, Kela, Flashpoint. Major threat-intelligence firms with their own monitoring infrastructure feeding clients.
Various academic and research projects. Cybersecurity research labs at universities maintain monitoring datasets.
National CERT and law-enforcement monitoring. Most major countries’ cybersecurity agencies monitor leak sites; some publish summaries publicly.
Independent researchers. A small community of journalists and analysts (Brian Krebs, several active accounts on infosec social media, the team at The Record) provides continuous reporting.
A monitoring workflow
For an analyst building leak-site monitoring:
Identify the active leak sites. The list shifts; cross-reference with multiple sources (Ransomwatch, RansomLook, ransomware tracking forums) to maintain coverage.
Set up Tor access. The standard tool is Tor Browser; for automated monitoring, scripted access via the Tor SOCKS proxy with a controlled-frequency scraper.
Periodic snapshots. Cron-driven retrieval of the leak site’s index pages at appropriate intervals (hourly to daily depending on the site’s update cadence). Store HTML snapshots for historical analysis.
Diff detection. Compare consecutive snapshots to identify new victim listings, updated data, or changes in site structure.
Alert pipeline. Notify analysts of new victims, particularly when the victim is a customer of the analyst’s organisation or in a sector being tracked.
Authenticate findings. Cross-reference newly listed victims with public information about the organisation and recent breach indicators.
Document. The leak-site data, the source URL, the timestamp, and the verification trail are part of the deliverable.
The discipline is operational rather than glamorous. Done well, it produces an early-warning capability that often beats victim’s own breach disclosure timelines.
What the data is useful for
Several distinct downstream uses:
Breach victim notification. When a customer’s organisation is listed before they have publicly acknowledged the breach, the threat-intelligence team can alert affected stakeholders. CISA’s StopRansomware.gov and several private services do this.
Threat-actor attribution. Patterns in the leak-site listings help analysts attribute attacks to specific groups. The wording used in ransom notes, the format of the leak site, the structure of the chat portals, and the sequence of victims all carry attribution signals.
Trend analysis. Aggregate counts of victims by sector, by geography, by group give a real-time view of where ransomware operations are focusing. The Coveware quarterly reports, the Sophos State of Ransomware annual surveys, and several academic papers use leak-site data as one input.
Research on ransomware economics. Analysing the time between victim listing and data publication, the rate at which victims appear and disappear (suggesting payment), and the size of data dumps gives empirical signal on the underlying economics.
Journalistic investigations. Public attention to specific high-impact victims often starts from leak-site listings.
Ethical and operational considerations
Several important constraints:
Downloading stolen data is dangerous and often counterproductive. Researchers have specific permissions and protections; casual download by unaffiliated investigators may carry legal risk in some jurisdictions, even when the intent is research. The leak-site listing itself (the metadata) is generally accessible without downloading the underlying data.
Engaging with operators is a research-only activity. Negotiating with the group, providing them with information, or interacting through their chat portals carries operational and legal risks that have to be managed deliberately.
Verifying claims is essential. Operators sometimes post inflated victim claims, recycled victim listings, or fabricated data. Treating any leak-site post as gospel without verification produces bad analysis.
Some leak sites are honeypots. Law enforcement infiltration of operations (Hive, LockBit, others) has on multiple occasions produced situations where the leak site is being operated, in part, by investigators rather than the criminal group. Operating under that assumption is wise.
OPSEC matters. Researchers monitoring criminal infrastructure should operate from non-attributable systems. Tor is the minimum; many practitioners use additional layering. The 2024 cases of researchers being targeted in retaliation for public reporting underline the point.
A worked example
A practical scenario: an analyst at a critical-infrastructure organisation builds a monitoring pipeline.
Sources. The analyst identifies the dozen most active leak sites currently operating, plus a watchlist of recently retired groups that may rebrand.
Infrastructure. The analyst sets up Tor on a dedicated VM, configures hourly cron jobs to retrieve each site’s index page through Tor, stores raw HTML snapshots in a versioned store.
Parsing. Each leak site has a custom parser to extract victim names, listing dates, countdown timers, and any sample-data references. The parsers are brittle (sites change layouts) and require continuous maintenance.
Storage. Findings flow into a structured database with per-victim records: name, listing date, group, status, data-publication date, publicly available IOCs.
Alerting. A daily report summarises new listings, particularly any matching the organisation’s watchlist (own organisation, key customers, key suppliers, sector peers).
Triage. New listings trigger a research process: is the victim genuinely listed, what is publicly known about the breach, what is the recommended action.
Reporting. Weekly summaries to security leadership; quarterly trend reports.
The pipeline takes a meaningful initial investment to build and ongoing maintenance, but produces capability that few organisations have natively.
What the data does not provide
Several limitations worth understanding:
Leak sites overstate. Operators sometimes list victims who never paid and never had data published, simply for pressure. The "listed but never resolved" outcome is common.
Leak sites understate. Many ransomware victims pay and never appear on a leak site. Leak-site data is a sample of the broader ransomware economy, not a census.
Attribution is imperfect. Multiple operations have been linked to the same underlying actors through leaks (Conti to Black Basta, DarkSide to BlackMatter to BlackCat). Leak-site data alone is insufficient for high-confidence attribution.
Some operations operate without leak sites. Pure-encryption groups without double extortion exist; their activity is not captured by leak-site monitoring.
The longer trend
Ransomware leak-site tracking has moved from informal practice to professional discipline over the past five years. The infrastructure (Ransomwatch, commercial feeds, academic projects) has matured. The methodology has been documented. The community of practitioners has grown.
The threat side has also evolved. Operators have responded to monitoring by introducing access controls, captchas, and gated leak sites that are harder to scrape. The ongoing cat-and-mouse continues.
For organisations with even moderate threat-intelligence ambitions, leak-site monitoring is now a feasible internal capability, with off-the-shelf data feeds available and structured methodology documented. The work is steady, requires operational discipline, and produces real value: early warning of breaches affecting partners and customers, situational awareness of the ransomware ecosystem, and empirical input to broader threat analysis.
The discipline is indelibly tied to a criminal economy. Tracking it is part of what bounds it.