Dark web brokers are repackaging old breaches as fake corporate data leaks

Dark web data brokers are selling recycled breach data as if it came from fresh corporate intrusions, creating false alarms for security teams and targeted organizations. The activity is especially visible in Chinese-language cybercrime forums and Telegram channels, where brokers advertise large datasets tied to banks, investment firms, and other companies.

A new Group-IB report says many of these listings are not evidence of new breaches. Instead, brokers combine records from older leaks, generated fields, inconsistent translations, and public identifiers, then market the result as newly stolen corporate intelligence.

The tactic works because the data is not always completely fake. Some names, phone numbers, email addresses, or password hashes may belong to real people. The problem is that those records often come from unrelated past incidents, not from the company named in the dark web post.

Why old breach data is being sold as new

Lead data brokers rely on volume, urgency, and confusion. They post large numbers of claims in short time frames, often with screenshots of spreadsheets and record counts that look impressive at first glance.

Group-IB tracked five prominent sources in Chinese-language environments: Exchange Market, also known as Deepmix, Chang’An Sleepless Night, Aiqianjin, Yiqun Data, and Phoenix Overseas Resources. These sources advertise alleged datasets through dark web marketplaces and Telegram channels.

The goal is not always to prove a real intrusion. The goal is often to sell access to low-quality lead data, create fear around a named organization, or force security teams to spend time validating claims that do not point to a new compromise.

Broker tactic	What it does	Why it misleads defenders
Recycled breach records	Uses data from older public leaks.	Real identifiers make the dataset look credible.
Generated fields	Adds artificial or inconsistent data to inflate volume.	Large record counts create urgency.
Misleading victim names	Attaches the dataset to a company that may not own the records.	Security teams may assume a new incident occurred.
Machine-translated headers	Uses awkward or inconsistent field names.	The dataset can appear international or corporate at first glance.
High-volume posting	Publishes hundreds of claims each month.	Analysts lose time separating real threats from noise.

Facebook and Eatigo data appear in repackaged listings

One common source is the 2021 Facebook dataset. The Have I Been Pwned Facebook breach record says more than 500 million Facebook users had data made available for download, with phone numbers being the main value of the dataset.

That kind of older dataset is useful to brokers because phone numbers and names still look convincing years later. A security team may see a real phone number in a sample and assume the broker has fresh customer data from the named company.

Group-IB also found password hashes that traced back to the Eatigo breach. The Have I Been Pwned Eatigo breach record says the restaurant reservation service exposed 2.8 million accounts, including names, phone numbers, email addresses, social media profiles, genders, and passwords stored as unsalted MD5 hashes.

Why these claims waste security teams’ time

False leak claims can still create real operational cost. When a company appears in a dark web listing, security teams must check whether the claim is real, notify internal stakeholders, review logs, compare customer records, and sometimes prepare legal or communications responses.

If the data turns out to be recycled, those hours were spent on noise. The bigger risk is that analysts may miss real incidents while chasing low-quality broker posts.

The Group-IB analysis says these claims can divert analytical resources from legitimate threats and create major time sinks for organizations that lack a structured validation process.

How organizations can validate a claimed leak

The first step is to compare the broker’s sample fields with the organization’s real data model. A genuine customer database usually has familiar field names, data types, record patterns, and internal identifiers that match how the organization stores information.

Security teams should also check whether the sample records actually belong to customers, employees, partners, or systems tied to the named company. One matching email address or phone number does not prove a breach, especially when other fields point to unrelated datasets.

• Compare field names against real internal database schemas.
• Check whether sample emails, phone numbers, and IDs match real records.
• Look for machine-translated headers or unnatural field names.
• Search for the same records in known old breach datasets.
• Check whether record counts match realistic business volumes.
• Review logs for signs of access before escalating the claim.
• Document confidence levels instead of treating every listing as confirmed.

Why real personal data can still be misleading

Recycled data can cause confusion because it often contains real personal information. A phone number from the Facebook leak or a password hash from Eatigo can make a spreadsheet look authentic, even when the records have no link to the named company.

The Facebook breach listing shows why phone-number datasets remain useful for scammers and brokers long after the original incident. Names, locations, relationship statuses, employers, and phone numbers can support social engineering even without passwords.

The Eatigo breach listing also shows why old password hashes can resurface in unrelated claims. Brokers can mix exposed credentials with fresh-looking labels to make a dataset appear more valuable than it is.

What makes a dark web data claim suspicious

Organizations should look for patterns that suggest lead data rather than a real corporate breach. These include inconsistent languages, unrealistic record counts, generic spreadsheet screenshots, missing internal identifiers, and records that map to well-known historic leaks.

Another warning sign is repeated high-volume posting by the same source. A broker claiming hundreds of unrelated major breaches every month is more likely selling compiled lead data than fresh corporate access.

Red flag	Why it matters
Sample data contains only public identifiers	Names and phone numbers may come from old leaks or scraping.
Field names look machine-translated	Real internal systems usually use consistent naming conventions.
Records do not match customer databases	The data may have been stitched together from unrelated sources.
Seller posts hundreds of claims monthly	The volume is unlikely to represent real fresh breaches.
Only screenshots are provided	Images can hide inconsistencies and prevent easy validation.

How companies should respond without panic

Companies should treat every credible-looking claim as something to validate, not something to immediately confirm. The right response starts with evidence collection, sample analysis, and internal comparison.

Security teams should define an escalation threshold before a claim appears. That threshold may include confirmed matches to internal-only fields, recent access logs, verified employee or customer records, or signs of unauthorized database activity.

• Create a triage playbook for dark web leak claims.
• Separate low-confidence lead data from confirmed breach evidence.
• Use threat intelligence tools to cross-reference old leaks.
• Keep legal, privacy, and communications teams informed without over-escalating early claims.
• Track repeat brokers and assess their credibility over time.
• Prioritize claims that include internal-only fields or recent system artifacts.

Why this trend matters

Repackaged breach data creates a fog around real security incidents. It helps dishonest brokers sell low-quality datasets, pressures companies into unnecessary investigation work, and makes dark web monitoring harder to interpret.

The best defense is not to ignore leak claims. The best defense is to validate them with structure and evidence. Companies that can quickly compare samples to known breaches and internal records will spend less time chasing false alarms.

Dark web leak claims will continue to rise because old data remains easy to reuse and cheap to package. Security teams should expect more recycled datasets, more inflated record counts, and more misleading corporate labels.

The practical response is clear: verify before escalating, cross-check against historic breach data, and focus analyst time on claims backed by real internal evidence.

FAQ