Stealer logs are not combolists, and the difference decides your response

A credential-exposure report puts two rows next to each other. Both carry a corporate email address. Both carry a password. Both are attributed to your domain, both have a date against them, and rendered in a table they are indistinguishable. One of them is worth close to nothing. The other is an incident that started before you opened the report.

The difference is not in the credential. It is in where the record came from — and a platform that does not carry provenance all the way through to the analyst cannot tell you which row is which. This is the most consequential distinction in credential exposure work, and it explains why two organisations can receive reports of identical size and have completely different amounts of work in front of them.

Provenance: a derived list versus a live capture

A combolist is a derived artefact. Someone takes prior breach corpora — a forum dump from 2019, a resold compilation from 2021, a scrape of an already-public aggregation — normalises them into email:password pairs, deduplicates loosely, and republishes. The purpose is credential stuffing: feed the list to a tool, spray it at login endpoints, keep whatever authenticates. Combolists are recombined and resold constantly, which is why the same address surfaces in dozens of them and why a "new" list frequently contains nothing new.

A stealer log is a primary observation. Information-stealing malware ran on a real person's machine on a real date, emptied the browser and the local application stores, packaged the output, and shipped it. Nothing about it is derived. It is not a list of credentials; it is the contents of a device at a moment in time, and the credentials are only one of the things inside it.

That distinction propagates into everything downstream. A combolist row tells you that a string associated with your domain exists somewhere in the public credential economy. A stealer log tells you that a specific machine, belonging to a specific person, was under someone else's control on a specific day — and that everything that machine had access to should be treated accordingly.

What only a stealer log carries

The password is the least interesting field. What an infostealer capture holds, and a combolist structurally cannot, is context.

The URL the credential was saved against. Browser credential stores keep the origin. That single field is the difference between "a password associated with an employee" and "the password saved against your ADFS endpoint, or your VPN portal, or a cloud console."

Session cookies and authentication tokens. These are the artefacts that survive the response most teams actually perform. Rotating a password does not invalidate an existing session. A stolen cookie with remaining validity can be replayed into an authenticated session without ever touching the login form — which means it also sidesteps the multi-factor prompt that the login form would have raised.

Autofill data, saved cards and wallets. Addresses, phone numbers, identity documents typed into a form once, payment instruments, cryptocurrency wallet material.

Browser history. Frequently the most operationally revealing artefact in the archive, because it shows which internal hostnames the machine reached — and a personal device with a history of internal admin panels is a finding in its own right, independent of any credential.

Device metadata. Operating system, locale, hardware, installed software, external IP at capture. This is what lets separate records be resolved back to one machine.

Together these are the seven artefact classes we treat as a single unit, because separated they are rows and together they are a case. That reconstruction is worth its own treatment, and gets one in reconstructing a compromised device from seven artefacts.

Why a combolist hit is usually noise and a stealer hit usually is not

A combolist entry is old by construction. It is assembled from material that was already public, and it has typically been circulating long enough that the password has been rotated, the account closed, or the address orphaned. Its residual risk is real but indirect: it is fuel for password reuse. If the same password protects something of yours, a stuffing campaign will eventually find it. That is a control problem — breached-password screening, rate limiting, MFA coverage — and not, on its own, an incident.

A stealer hit inverts every one of those properties. The material is recent relative to the capture. The password was in active use, because it was in the browser's store when the malware ran. The session material may still be valid. And the same log almost always contains more than one credential for the same person, which means the exposure is not one account but the working set of an identity.

This is why the honest headline number for a customer is not the corpus total. Across ShadowMap customers, a typical estate surfaces somewhere in the range of 200 to 800 stealer-log credentials. That is the population worth working. The relationship between that set and the far smaller number that still authenticate is the subject of forty thousand leaked credentials, eight that still work.

Twenty-six families, and what actually differs between them

ShadowMap parses material from 26 stealer families. A responder who has worked this data will recognise the recurring names — Vidar, Lumma, StealC, Rhadamanthys, Atomic and others — but the names matter less than the axes on which they differ, because those axes determine what a log can and cannot prove.

Coverage. Families differ in which browsers and profiles they read, and in which desktop applications they touch — email clients, VPN configurations, FTP clients, messaging apps, wallet extensions. When a category is absent from a log, that may mean the machine had nothing there, or it may mean the family never looked. Absence of evidence is not evidence of absence, and only family-level knowledge tells you which you are holding.

Artefact fidelity. Some families preserve cookie metadata including expiry; others flatten cookies to name-value pairs. That difference decides whether you can reason about which sessions were plausibly still live at capture, or whether you have to assume all of them were and invalidate broadly.

Log structure. Most deliveries arrive as a directory per infection — a system-information file, a credential file, per-profile cookie dumps, autofill, sometimes a desktop screenshot, sometimes a file grabber's haul of documents matching patterns. Structure is family-specific and changes between builds, which is where parsing effort actually goes.

Timestamp semantics. The date attached to a record may be capture time, packaging time, first-posting time or resale time, and the convention varies. Since the entire triage depends on how old the session material is, treating a marketplace posting date as a capture date will systematically mislead you.

Delivery. Stealers are commonly dropped by loaders, and one machine can be hit by more than one family across months. Recognising that two logs describe the same device is the difference between one case and two.

Families also come and go — law-enforcement action removes an operator and the share redistributes within weeks. But a disrupted family does not retire its logs. Captured material keeps circulating and reselling for years afterwards, which is why breadth of parsing across families matters more than tracking whichever name is currently ascendant.

Triaging the two differently

The practical consequence is that these are two workflows, not one queue.

Combolist material is a control review. Screen the affected addresses against your current password store, confirm MFA coverage on the identities involved, verify that your authentication endpoints resist stuffing at volume, and move on. It does not warrant an incident record.

Stealer material is an incident. The sequence that works: attribute the log to a device rather than to an address; invalidate every session for the identities present, not just the ones with obvious credentials; revoke tokens; rotate the credentials, in the order of what they open rather than the order they appear; cancel any payment instrument in the autofill; isolate or rebuild the endpoint; then go to your own authentication logs and look for a successful login you cannot account for. The exposure data tells you what leaked and what still works. Only your logs tell you whether anyone used it.

Both queues need a triage step before they reach a human, and this is where AI Review does its work — classifying what a record actually is and restructuring the queue by context rather than by score, with anything set aside kept in a filtered queue rather than deleted. We do not publish an accuracy figure for it. Any vendor quoting one is describing a benchmark you cannot reproduce against your own estate, and the only number that should matter to you is what the queue looks like after it runs on your domain.

Why retained source material changes the answer

ShadowMap runs its own collection rather than reselling pre-parsed output: 12 billion-plus records across roughly 41 terabytes of retained source material, drawn from 466 dark-web and breach-forum sources and 778 Telegram channels under collection.

The totals matter less than the retention. Source material is kept permanently, so when a parser improves — a new family, a changed log structure, a field we previously discarded — it is re-run across the history. Records that entered the corpus as an undifferentiated dump can later be resolved into structured device captures with cookies, history and metadata attached. The archive gets better retroactively. A platform that ingests someone else's parsed feed only ever receives what an upstream supplier managed to extract on the day, and can never revisit that decision.

What we do not publish about collection

We publish what we hold and what we can do with it. We do not publish where it comes from in any operational detail: no provider or source names, no collector identities, no channel topology, no acquisition logic, no infrastructure architecture. Describing that publicly degrades access, and access is the asset.

That is a real limitation on how far you can verify us from a web page, and we would rather state it than dress it up. The test that is available to you is a better one anyway: give a vendor a domain you own and judge what comes back — the provenance, the artefacts, the dates, and whether the output distinguishes a resold combolist row from a device that was under someone else's control last month.

Get the response playbook. The Stealer-Log and Credential Exposure Response Playbook covers the triage decision tree, the four credential states and the action each one implies, the device-level response runbook, and a first-24-hours checklist. → Download the playbook

Related: Dark web and identity exposure · Forty thousand leaked credentials. Eight that still work. · Reconstructing a compromised device