Skip to main content
A stealer log is what info-stealer malware carries off a machine it infected: every password the browser had saved, the cookies, the autofill and form data, the system fingerprint — and usually a screenshot of the desktop at the moment of infection. Stealer logs searches the credential corpus by that capture. Each result is one infected machine, not one credential. That’s the difference from the other three approaches. Raw Data, the ULP feed, and Filtered credentials flatten a stealer log into individual login / password / website rows and fold them into everything else. This one keeps the capture whole and hands you the link back to it: the full bot record and the screenshots, fetched on demand.
A stealer-log record stands for a whole machine, not a single credential. The match surfaced because info-stealer malware ran on someone’s device and exfiltrated its browser — so one record represents everything that machine held: every saved login, every session cookie, the autofill, the screenshots, not just the credential your query matched. That’s why the response hands you a link to the full capture instead of a single row. The endpoints below are built around pulling that whole record.

​
How it works

Stealer logs is an asynchronous, organization-scoped flow — the same create → poll → read shape as Filtered credentials, not the one-shot Lucene query of Raw Data or the ULP feed. You submit a search, poll the task until it’s ready, read the matched records, then fetch each capture behind the URLs those records hand you. All four endpoints live under the Leaks tag in the API reference.
1

Create the search

stealer_logs_search starts the task. The body is a single query — a domain, email, or username, 3–1024 characters. It comes back with a task id and a status.
2

Poll until it's ready

Fetch the task with stealer_logs_search_task, passing the id as the task_id path segment, until status reads ready.
Status moves pending → in_progress → ready. Two other values can come back:
  • incomplete_ready — usable results are available, but from a partial run. Read them the same way; the counts tell you how much landed.
  • failed — the search couldn’t complete. Submit it again.
The task carries two counts as it fills in: total_matched_records is how many raw stealer-log records matched your query, and total_results is how many result entries are ready to read.
3

Read the matched records

stealer_logs_search_results returns the page of records. The parameter is search_id — the same value as the task id from step 1 (the name differs; the number doesn’t).
The envelope paginates with page and size (default 100, max 1000). Mind the nesting: the outer object is {count, next, previous, results}, and results is itself an object — {status, results: [...]}. The records you want sit at results.results.

​
What each record gives you

A record describes one stealer-log capture and, most importantly, points you to the full data behind it.
  • content — the slice of the capture that matched your query. Here that’s a saved-password block: two internal Acme services logged in from the same infected machine, both with the same reused password. This is a preview, not the whole log.
  • botid_url — a URL to the full bot record for that machine: the complete JSON the stealer exfiltrated. This is where the real data is.
  • stealer_pics_urls — URLs to the screenshots the stealer captured, usually the desktop at infection time. Often the fastest way to identify whose machine it was and what they had open.
  • leak_name, leak_source, file_name, leak_size, leak_tags, cvss_score — the source and shape of the leak it came from. leak_tags like stealer,cookie,autofill,system tell you what classes of data the capture holds.
  • leak_publish_date, leak_discover_date, item_created_at — when the log surfaced, when DarknetSearch found it, and when this record was indexed.
  • item_id, leak_id — stable identifiers for the record and its parent leak.

​
Pull the capture

This is the step that makes stealer logs different: the record is an index entry, not the payload. The actual stealer data lives behind botid_url and stealer_pics_urls, and you fetch each one yourself. The bot record. GET the botid_url exactly as the record returned it to pull the full JSON for that machine — everything the stealer took, not just the block that matched. Depending on the stealer family and what the machine held, a bot record typically covers the host and system fingerprint, every browser-saved credential, cookies (including live session tokens), autofill and saved form data, and sometimes crypto-wallet or application data.
The screenshots. Fetch each entry in stealer_pics_urls the same way to retrieve the image.
Fetch what you need while the search is fresh, and treat it as sensitive. These URLs point to hosted captures on separate storage — pull the bot records and screenshots you intend to act on rather than assuming a link will resolve indefinitely. Fetch each one as the record hands it to you: some are pre-authorized links, others may want your bearer token — the live response is the source of truth for the exact shape of the bot JSON and how each link authenticates. And a bot record is raw stolen data about a real person’s machine — handle and store it accordingly.

​
Export the results

Two ways to get the full set out of the API — page the records yourself, or have the export system build you a file. Page through the results. The results call is the export — raise size to its maximum of 1000 and follow the envelope’s next link until it’s null. Every page carries the same records, botid_url and stealer_pics_urls included, so you can collect the whole set and then fetch the captures you want.
Build a downloadable file. For a single file instead of pages, hand the search to the platform’s export service. Stealer logs is a registered export service — and it exports the resolved captures, paging the detail records for you server-side, so the file holds the full records rather than the index rows. It’s an async job: find the service, create the export, poll, download.
1

Find the service

Export services have no fixed id — each environment assigns one when its catalog is seeded, so you look it up at request time rather than hard-coding it. list_export_services returns the catalog; every entry carries an id alongside its stable identifiers and config. Match the stealer-logs entry by its name, StealerLogs:
Read the id off that entry for the next call. allowed_types are the file formats you can ask for, and args spells out what to pass — here, a required search_id.
2

Create the export

create_export takes that service id, a type from allowed_types (json, csv, or xlsx), and args holding the search_id of a finished search — the same id you read results by. It returns an export id and a status.
3

Poll until it's complete

Fetch the job with get_export by id until status is COMPLETE. It moves IN_PROGRESS → COMPLETE, or FAILED.
4

Download

download_export by id returns the file once the job is COMPLETE.
list_exports lists your export jobs, filterable by status, type, service, and date.

​
List past searches

stealer_logs_search_tasks returns the searches your organization has run, most recent first, paginated with page and size. Use it to pick a search_id back up without re-running the search.

​
When to reach for it

Use stealer logs when the machine is the unit you care about — you want the whole capture from an infected device, the screenshots, and the full list of what was on it. When you only need the credentials themselves, the other three approaches are faster: look one identity up in the ULP feed, track your owned domains with Filtered credentials, or read the raw dump with Raw Data. Start from Find leaked credentials if you’re deciding between them.