One Indonesian-language advertisement offers contact details of online-casino players in four quality tiers. Each tier has its own price list in rupiah, for blocks of rows from hundreds to tens of thousands. The seller promises unlimited replacement of invalid or unresponsive contacts and adds two words: “no tester” (DB-E026).
An English-language forum post offers a database from a single services business. It shows no price, accepts escrow and pastes tables of sample rows (DB-E021). Both posts look like breach database sales in a keyword count, yet they sell different things, and their terms say which. This piece compares those terms and then asks how many separate advertisers stand behind the pattern.
Half of the “Sale” Posts Are Not Offers
Among the posts we fetched for this chapter, our fixed rules labelled 2,303 as sale offers. An AI reader working separately from the rules read 126 of them in full, drawn across platforms and languages. Only 68 of the 126 were a seller’s own offer (54% unweighted, 95% interval 45% to 62%; 53% after weighting to the platform and language mix).
The others were channel directories, news, recruitment advertisements and lookup output (21), marketplace-bot digests (10), and replies or bumps (8). The companion piece on relay cards and news retellings covers those post types, and the main investigation reads what leak claims actually list.
Repetition dominates the volume. One Chinese-language one-line advertisement for “first-hand global databases” appears 576 times after normalisation, which is 25% of the kept sale posts. Thirteen templates with five or more near-copies account for 802 posts (35%), so a substantial part of the post volume comes from a few repeated templates; these are not counts of distinct products.
The coded offers show the same concentration: the 13 breach-database offers are 13 distinct texts from 11 channels. The 16 lead lists are 16 texts, yet they come from only 12 template keys and 9 channels. Eight of them, all the rupiah row-block tier lists, are near-copies of one advertisement from one channel. We count advertisements, not sellers or sales, so for lead lists the channel is the safer unit.
Offer Terms Side by Side
Of the 68 offers, 13 sell data from one organisation and 16 sell marketing or lead lists, and each cell gives channels first and posts second. Counts are small, so they indicate a pattern and not a market share.
| Term | Organisation breach database (11 channels, 13 posts) | Marketing lead list (9 channels, 16 posts) |
|---|---|---|
| What is sold | Records that the advertisement attributes to one organisation. | Contact rows for outreach, grouped by market or category. |
| Validity or freshness promise | 2 of 11 channels (2 of 13 posts). | 7 of 9 channels (14 of 16 posts). |
| Guarantee, replacement or escrow | 2 of 11 channels (2 of 13 posts). | 4 of 9 channels (11 of 16 posts). |
| Sample offered or shown | 7 of 11 channels (9 of 13 posts). | 7 of 9 channels (7 of 16 posts). |
| Sample refused | 0 of 11 channels (0 of 13 posts). | 2 of 9 channels (8 of 16 posts). |
| Price amount stated | 4 of 11 channels (5 of 13 posts). | 5 of 9 channels (12 of 16 posts). |
| Unit not stated | 6 of 11 channels (6 of 13 posts). | 3 of 9 channels (3 of 16 posts). |
| Unit tiered by block of rows | 0 of 11 channels (0 of 13 posts). | 1 of 9 channels (8 of 16 posts). |
Not every contrast survives de-duplication. The row-block tier unit comes from one advertiser, so it describes an advertisement and not a type of product. Sample refusal appears in two of nine lead-list channels (five of 12 templates) and in none of the breach-database channels, which is a thin but consistent difference.
The validity promise survives best: 2 of 11 breach-database channels against 7 of 9 lead-list channels, and 2 of 13 against 10 of 12 templates. By template the intervals separate (4% to 42% against 55% to 95%); by channel they overlap slightly (5% to 48% against 45% to 94%).
The guarantee gap points the same way (2 of 11 channels against 4 of 9) but its intervals overlap. Offering a sample, stating a price and omitting the unit do not separate the two groups at all.
What the Terms Reveal About the Product
A sample does not distinguish the two products, because lead-list sellers offer samples in 7 of 9 channels. The stronger distinction in this sample is an advertised validity promise. DB-E026 also promises replacement of invalid or unresponsive contact rows; replacement is not universal across the selected lead-list offers.
The validity promise is the term that most consistently marks this product. In DB-E026, the advertised product is contact data expected to be reachable, with a replacement promise attached. We did not test the records or observe a purchase.
Where sellers refuse a free test, we interpret it as protecting the product, since a sample of contacts is itself usable contacts. The sellers themselves do not state this reason. A Chinese-language advertisement pairs “no free test” with “after-sales guaranteed” (DB-E027), and another seller caps samples at a few hundred lines, on request only (DB-E024).
A breach-database seller promises a file and little else. The typical offer sells the whole database, shows rows, lists what the file contains and carries no guarantee. DB-E022 is an example: a file-by-file inventory, rows shown and a “starting at” price. Only two of the 13 mention escrow or a guarantee, namely DB-E021 and DB-E023, so those two are exceptions and not the norm.
With no validity promise, the sample is the only evidence the buyer can verify, and forum readers do verify it, as the main investigation documents from their replies. In short, a lead list sells contactability, anchored by a validity promise that a replacement clause sometimes reinforces. A breach database sells a claim about a file, backed by whatever the sample proves.
One confound limits this. Thirteen of the 16 lead lists were on Telegram and eight were Indonesian-language, while breach databases split 7 forum and 6 Telegram. Some of the contrast may reflect venue norms and not the product, and our data cannot separate the two.
Are Lead Lists Just Relabelled Breach Data?
The strongest alternative is that “lead list” is a sales label on stolen data, so the different terms are packaging only. Some records point that way, although none proves it. One seller offers contact data attributed to customers of a single company and says it is “not selling the database” (DB-E024), yet the post does not state the origin. Another advertisement lists provenance words such as scraped, crawled, hijacked and obtained through intrusion (DB-E027).
A bundle sold once pairs property-owner lists with a large consumer-platform database (DB-E032), which fits the alternative. Other lead products make no breach claim, such as a consumer email list for one country sold as “fresh” marketing data with free lists as a funnel (DB-E033).
The evidence cannot show where any of the 16 lead lists came from. Provenance words are the seller’s, and we tested no file. It can show something narrower: the terms describe how data is being sold, and a post’s origin claim is a separate question to assess on its own.
Does the Split Extend to Accounts and Bundles?
A reasonable test of the argument is whether products that must keep working after payment carry a promise. Three records fit that pattern, although three is too few to count as a result.
- Verified accounts are priced per account with a 30-day insurance (DB-E031).
- A mixed-data channel is sold by subscription period, with weekly updates and escrow (DB-E028).
- A lookup bot sells credits and per-report answers, not a file (DB-E030).
Each sells something that must keep functioning, and the first two come with a promise about it. Identity-document and KYC offers are covered in the Fraud chapter and its identity-offer investigation, and credential files belong to the stolen credentials chapter.
Reading a Sale Post by Its Terms
The terms determine what each team should do with a post that mentions its organisation or customers.
- Victim organisation. A seller’s post alone does not establish a compromise of your systems. If the sample matches your field names, record structure and data months, treat it as a candidate incident and involve incident response and counsel, and do not contact the seller. Our glossary entry on data breaches covers the next steps.
- Fraud team. The lead lists in our read targeted casino players, loan and insurance prospects and consumers, not one customer base. If a post attributes contact rows to your customers, the product on offer is contact data. Establish which fields the post lists and whether your customers’ channels show unusual outreach; the post does not show how the contacts would be used.
- Privacy and legal team. A post is a seller’s claim and may carry no origin at all (DB-E024), or no breach claim (DB-E033). Notification duties depend on your own findings and jurisdiction, so use the sample and your own logs to decide, not the post’s wording.
The terms also tell you which question to ask first. A breach-database sale asks whether the file is real, and a lead-list sale asks whether these people are about to be contacted. The first goes to incident response and legal, the second to the fraud and customer-protection teams.
Brandefense dark web monitoring and the data leak detection use case cover sale posts that name your brand. The Data Breach and Leaks chapter holds the wider evidence, and the Cybercrime Report 2026 hub links the other chapters.
Scope and Method
The read covers posts created from 1 January to 27 October 2026 in Brandefense’s Blackhole collection, where Telegram supplies 1,667 of the 2,303 kept sale posts and forums 632. The 126 posts are a quota sample by platform and language, with at most two posts per ad template. One AI reader coded them, with no second rater, so category shares carry wide intervals and unknown coding bias.
All terms are asking terms: we observed no purchase, tested no file and computed no prices. Currencies are named only where an ad names them. Forum post dates are partly day and month swapped, so this piece makes no month-by-month statement. Invisible characters occur in 30% of the kept sale posts, so repetition counts use normalised text.
Why AI agents. Brandefense Blackhole, our cybercrime database, collects around 17 to 23 million dark web and Telegram posts a month. Reading that volume by hand, and linking a recruitment ad on one forum to a leak-site claim on another and a price list in a Telegram channel weeks later, is beyond what a human team can do alone.
Claude Opus 5.5 prepared the research: it searched the data, sorted and translated posts and drafted the text. Codex Astra then checked every number against the dataset files and tested each claim, and anything that did not hold was removed.
Brandefense analysts reviewed and approved the findings.
