accounts_database_search is the searchable index of those records. Every row is one leaked credential — a login, a password, and the website it opens — pulled from combolists and stealer logs and tagged with the leak it came from.
Unlike Filtered credentials, this has no domain restriction — it’s the right tool for a single address on a public domain (jdoe@gmail.com), or for searching by the website a credential was used on rather than by org.
Search the account index
It’s a Lucene query, just like Raw Data — but the default field islogin, and the fields are credential-shaped: login, password, website, leakId, createdAt. Combine with AND, OR, NOT.
Send it as the
query parameter (3–1024 characters). Because queries contain : and [, let curl -G --data-urlencode handle the encoding:
page and size (up to 100 a page) and sorted by createdAt descending — newest exposures first.
Reading the results
A response is a page of credential rows. Searchingwebsite:acme.com here returns 19 hits — the first page:
login/password— the credential. The password is in the clear here; some leaks carry a hash instead.website— the URL the credential was used on or captured from.leakName,leakId,leakSize,leakTags— the source leak (here a URL-login-password combolist — noteurlin the tags).leakPublishDate/leakDiscoverDate— when the leak surfaced, and when DarknetSearch found it.cvssScore— a severity rating for the source leak.createdAt— when this row was indexed; the default sort key.
Read the three columns together.
login is the identity, password is in plaintext, and website is the exact surface the credential opens — here, every row points at https://acme.com/login, so that login page was harvested wholesale (a stealer log or URL-login-password combolist). Watch the logins for service give-aways: owa. is webmail, rdp. is remote desktop, a vpn. host is your VPN — each is an exposed front door, not just a mailbox. Because the passwords are in the clear, treat every row as a working credential until it’s rotated.When the credential came from a stealer log, there’s more behind it. The ULP feed shows you the one triple. If the row was harvested by info-stealer malware, the whole machine was emptied — other saved logins, live session cookies, a screenshot. Stealer logs searches that corpus by infected machine and hands you the full capture.
Filter an org’s breach feed instead
account_breaches is a second view of the same kind of data — scoped and filtered rather than free-text searched. Instead of a Lucene query it takes structured filters and returns {count, results} with {leak_date, login, password, leak_source, website} rows, not deduplicated.
Filter by any combination of:
website— the domain (case-insensitive contains)login— an email address or username (case-insensitive contains)password— case-sensitive containsleak_source— the breach nameleak_date_after/leak_date_before— a date range
account_breaches when you want a plain “every breach row for this domain, email, or password” feed with date and source filters; reach for accounts_database_search when you want the full Lucene query and the richer per-leak metadata.
Aggregate the exposure
When you want totals instead of rows, pair the feed with Leaks Analysis:leaked_credentials_stats— unique exposure counts, split by combolists vs. stealer logstop_risky_users— the most-exposed accountsexternal_service_login_stealer_logs— stealer-log exposure on external services