leak_extended_database_search runs a full-text search across the entire indexed corpus and returns one row per matching record — so the same person or credential can appear many times, across many breaches. It is not deduplicated. This is the unprocessed feed.
Why you’ll see duplicates — and why that’s useful. Free leaks get repackaged endlessly: the same breach resurfaces under new names, rebundled into fresh combolists and reposted across forums and channels. So one credential showing up many times is expected, not a defect. Read it like an analyst — heavy duplication of a single leak means it’s being actively recirculated and is in many hands, which tells you the exposure is widespread and still live. Deduplicate when you need a clean count; keep the duplicates when you’re gauging how far something has spread.
- SQL dumps
- JSON exports
- CSV and Excel spreadsheets
- Plain-text files and documents
- Configuration files and logs
- Combolists (email-and-password pairs)
- Stealer-log captures
content. fileName and fileExtension tell you the format you’re looking at, and leakName, leakSource, leakSize, and leakPublishDate describe the breach it came from.
A raw record. A response is a page of records — here, the first of 8,400-plus matches for acme.com:
<kaduu:h>…</kaduu:h>insidecontentmarks where your search term matched. Withhighlight=true(quick search sets this automatically), every hit on your term is wrapped in these markers so you can find it in a wall of raw text.leakTagsis an inventory of the parent leak —password,email,ip,name,hash,sqlhere — a fast read on what kinds of data the dump holds. It describes the whole leak, not the single row.
query parameter (3–1024 characters). The default field is content, so a bare term searches the leaked text itself; scope a term to a field with fileExtension, fileName, leakId, or createdAt, and combine terms with AND, OR, and NOT.
A bare term matches the word or any token it’s part of —
acme.com hits boss@acme.com, hr.acme.com, and super-acme.com alike.
Write it out as a full request. Queries contain spaces and characters like : and [, so let curl -G --data-urlencode handle the encoding:
size (10–100, default 10) is how many records per page and page (0-based) walks through them — the envelope’s totalPages and last tell you when to stop. length (1–1000, default 500) is a different lever: it sets how many characters of each matched content snippet come back — raise it when you need more surrounding context (see the warning above). highlight=true wraps matches in <kaduu:h> tags. Results return inline — no polling.
Raw Data has a companion view over the same leak corpus.
Which breaches, and how heavily. leak_simple_database_search rolls the matches up by leak: one row per breach your term appears in, each with a resultCount of how many records matched inside it, sorted by most matches first. It’s the landscape view — instead of tens of thousands of raw rows, you see which breaches expose you and how big each hit is.
leakName, leakSource, leakSize, leakTags, cvssScore, leakPublishDate — plus resultCount. There’s no content; to read the actual records from one breach, run a Raw Data search scoped to it with leakId:<id>.
Need the original leak file or an export? Direct leak-file downloads are only for small source files under 10 MB. For larger leaks, keep the investigation in Raw Data: search
leakId:<id> to browse the indexed leak, or combine a keyword with leakId:<id> to search inside that one leak. See Downloads and exports to choose between result-set exports and original leak-file downloads.Chasing the stealer-log captures specifically? Raw Data surfaces them as raw rows alongside everything else. To search the corpus by infected machine — and pull each capture’s full bot record and screenshots — use Stealer logs instead.