Forty thousand leaked credentials, or eight? The number that matters

The first credential-exposure report an organisation receives is almost always a shock, and almost always for the wrong reason.

The number is large. Suppose the report says forty thousand records — the figure is illustrative, and a real one lands anywhere across a wide range. Employee addresses, customer addresses, partner addresses, and addresses belonging to people who left the company in 2017. The first reaction is that something has gone badly wrong. The second reaction — the more damaging one — is to ask whether the number can be made smaller before the board sees it.

Both reactions misread what the report is for.

Of those forty thousand, the number that matters on Monday morning might be eight. Eight credentials that still authenticate against something the organisation owns. Both figures are illustrative. It is the gap between them that is the point. The remainder is history: passwords rotated years ago, addresses that no longer resolve to an account, rows duplicated across a dozen resold breach compilations. Useful as context. Not a task.

The entire discipline of credential exposure is the work of getting from forty thousand to eight, and then acting on the eight before somebody else does.

Why the big number is the wrong number

Volume is the metric a credential feed can produce without doing anything difficult. Match a domain against a corpus, count the hits, render the chart. It requires no attribution, no validation and no judgement, which is precisely why so many reports lead with it.

It is also why so many credential programmes stall. A queue of forty thousand items has no natural first action. It cannot be worked, so it is not worked, and it becomes a quarterly appendix. Meanwhile the handful of rows that would have taken an afternoon are sitting inside it, indistinguishable from the noise.

The organisations that get value from this data reversed the question early. Not how exposed are we, which has no operational answer, but which of these still opens a door.

It helps to separate the corpus from the workload, and here there is an observed figure rather than an illustrative one. Across our deployments, the stealer-log portion — credentials taken from live, infected machines rather than from historical breach dumps — typically runs to between 200 and 800 credentials per customer. That is the population worth reasoning about: not the headline total, and not a single-digit handful either. It is a triage exercise rather than a programme.

What a stealer log actually contains

Most people's mental model of a leaked credential comes from breach dumps: a company is compromised, a user table escapes, addresses and password hashes circulate. That data ages quickly. By the time it is public it has usually been rotated, and its residual value to an attacker is mostly as fuel for credential stuffing somewhere else.

Information-stealing malware produces something categorically different, and the difference is the whole argument.

A stealer runs on a person's machine and empties the browser. It does not take one password from one site. It takes the saved credential store, the session cookies, the authentication tokens, the autofill entries, the saved cards and wallets, the browsing history, and a profile of the device itself — hostname, username, operating system, locale, external IP at the time of capture. Then it packages the lot and ships it.

Two consequences follow, and both matter more than the password does.

The first is that a session cookie is not a credential; it is the result of one. It is issued after the authentication challenge has been satisfied, which means a stolen, unexpired session token can be replayed without a password and without a second factor. Multi-factor authentication is not a mitigation for this class of theft. It is the step the attacker skipped.

The second is context. A single log can contain a person's corporate SSO password, a live session for the same identity, the internal hostnames they visited, and enough surrounding detail to establish which of their accounts are worth trying first. It is not a row in a table. It is a snapshot of somebody's working life at a moment in time.

ShadowMap operates its own collection against this material rather than relying solely on pre-parsed third-party output. We hold 12 billion-plus records across roughly 41 terabytes of retained source data, drawn from 466 distinct dark-web and breach-forum sources and 778 Telegram channels under collection, spanning 26 stealer families. The totals are less interesting than the retention: source material is kept permanently, so when our parsers improve we re-run them across the history. New extraction capability makes old data better. A reseller only ever receives what an upstream supplier managed to parse on the day.

The four states a credential can be in

A credential in ShadowMap is not a row with a severity attached. It carries a state, and the state is the thing you work from.

• Confirmed Working. Tested against an authorised target, and it authenticated. This is where the illustration's eight would sit.
• Maybe Working. The test was inconclusive — a login flow that neither accepted nor cleanly rejected, or an endpoint behind protections that make a definitive answer unsafe to obtain.
• Not Working. Tested and rejected. Still worth keeping: a password that fails today tells you about a pattern, and a pattern tells you something about the next one.
• Not Tested. Out of authorised scope, no reachable authentication surface, or belonging to an identity we cannot attribute to you with confidence.

The last state deserves emphasis, because it is the one most feeds quietly do not have. A credential belonging to one of your customers, or to an employee's personal account on a third-party service, is not something anyone should be testing. It remains exposure — password reuse makes it a plausible route into your estate — but it is not a login attempt we will make on your behalf. Reporting it as untested is the honest answer, and an untested finding with a stated reason is more useful than a confident one that was never checked.

How a credential gets tested, and what we will not do

Validation in ShadowMap is contextual, controlled and non-destructive. It is not a generic exploitation engine pointed at a production estate.

For credentials specifically, the platform establishes whether the identity maps to an authentication surface inside your authorised scope, attempts authentication using logic built for that surface, records the outcome with evidence, and moves the finding into a state. Where a credential authenticates, the finding carries what it reached: the affected service, the access available, the blast radius.

Validation is also not switched on at go-live. Onboarding begins with discovery and enumeration, and your inventory is built and confirmed first. Validation is introduced progressively, within the scope set by the agreement and the onboarding configuration. Authorisation here is contractual, not casual.

There are things this deliberately does not do. It does not attempt authentication against systems outside your authorised scope. It does not run public exploit code against production. It does not test credentials belonging to your customers. Any vendor claiming that every signal in every category has been validated before it reached you is describing something that cannot be done across phishing, brand mentions, threat feeds and media monitoring simultaneously. What can be done — and what is worth paying for — is validating the classes where validation is safe, authorised and decisive, and being explicit about the rest.

Seven artefacts, one machine

The second thing that separates a useful credential programme from a large one is correlation.

Take the working credentials — the eight, to stay with the illustration. Treated as isolated findings, they produce eight password resets and eight closed tickets. Correlated back to the devices they came from, a different picture usually appears: three of them came from the same machine, alongside live session cookies for two more services, autofill data containing a corporate card, and browsing history showing internal hostnames that should not have been reachable from a personal device.

That is not eight password resets. It is one compromised endpoint, one session-invalidation exercise, one card to cancel, and one uncomfortable conversation about how an internal hostname ended up in a home browser.

Reconstructing that picture requires the artefacts to have been kept together — credentials, cookies, tokens, cards, wallets, autofill and browsing history, tied to device metadata. It is the difference between a list and a case.

What the working credentials actually change about your response

A confirmed working credential is not a password-reset ticket. It is evidence of access that already exists outside your control, and the order of response matters.

Revoke, not just rotate. Changing a password does not terminate an active session. If a session cookie or refresh token was captured alongside the credential, the holder stays authenticated until that token expires or is explicitly revoked server-side. In an OAuth or OIDC estate that means invalidating refresh tokens as well as sessions; in most SaaS applications it means an administrative sign-out-all-sessions action rather than a self-service reset.

Then look in your own logs. Review authentication records for the affected identity from the capture date onwards, weighting source IP, ASN and user agent more heavily than failure counts. Successful and unremarkable is what this looks like from the inside.

Treat the endpoint as compromised, not the account. A machine that surrendered its browser credential store surrendered everything else the browser held. Removing the detected sample is not the same as restoring trust in the device.

Then ask why the credential was there at all. If the machine was unmanaged or personal, the finding is about access policy rather than malware, and it will recur until that is addressed.

What a credential check cannot tell you

Credential exposure monitoring establishes what has leaked and what still authenticates. It does not tell you whether anyone used it. That answer lives in your authentication logs, and the correct sequence is almost always: identify the working credential here, then go and look there for a successful login you were not expecting.

Timestamps deserve the same caution. The date a log appears in collected material is the date it became visible to us, not the date the machine was infected. Logs circulate privately, get resold, and surface late. Treat the capture date as the latest point at which you should assume the credential left the device, not the beginning of the exposure window.

And no corpus is complete. Credentials that never left the machine, never appeared in collected material, or were taken by an operator who does not trade will not be here. A vendor implying otherwise is selling a number rather than a control.

The eight, not the forty thousand

If there is one thing to take from this, it is that a credential-exposure programme should be judged by the size of the queue it produces, not the size of the corpus it searched. A report that hands you forty thousand rows has moved the work to you. A report that hands you eight — with evidence of what each one opens, and the device story behind them — has done the work.

The organisations that struggle with this data are the ones that wanted the number to look better. The ones that get value from it are the ones that wanted to know which eight.

See your own number. The Exposure Snapshot checks a single apex domain against our credential and stealer-log corpus and returns what we hold, with identifiers masked. No agents, no credentials, no access to your systems. → Request an Exposure Snapshot

Related: Dark web and identity exposure · How validation works