Learn

Credential exposure

How to Read a Credential Exposure Report

By Alphatechs ·

An exposure report arrives, it has more rows than anyone expected, and the first instinct is to treat the row count as the finding. It is the least useful number in the document. A report's value sits in four fields that decide what you actually do: what the credential authenticated to, where the record came from, when the credential was taken as opposed to when it surfaced, and what arrived alongside it. Two of those are frequently missing, and a report without them is asking you to guess. This is how to work through one in an order that produces decisions rather than a spreadsheet nobody reopens.

The first exposure report an organisation sees usually produces one of two reactions, and both are wrong. Either the row count is alarming and everything becomes an emergency, or the rows look old and the whole thing gets filed. The number of rows is the least informative figure in the document, because it counts records rather than problems, and a single compromised laptop can contribute fifty of them.

What a report is actually for is deciding what to do. That decision turns on a small number of fields, and working through them in a sensible order converts a long list into a short set of actions.

Why the total is misleading

One infected device produces many rows. Infostealer malware takes what a browser has saved, which for an ordinary user is dozens of credentials. Fifty rows from one machine is one incident with one remediation, not fifty incidents.

One person produces many rows too. The same address appears across breach corpora, stealer logs and combolists, sometimes repeatedly as lists are reaggregated and resold. Deduplication by address and by source is the first thing worth doing, and a report that has not done it inflates its own apparent severity.

Old records keep reappearing. A credential from a breach years ago resurfaces every time somebody repackages the corpus. The appearance is new. The exposure is not.

Example credential exposure report showing asset, date, country, antivirus and malware columns

So the number that matters is not rows. It is distinct accounts whose current password is exposed, plus distinct devices that appear to be compromised. Those two figures are what you can act on, and they are almost always dramatically smaller than the row count.

The four fields that decide the response

What the credential authenticated to. A username with no service attached starts an investigation. A username with the service attached starts a fix. If the record says an address appeared alongside your own domain, that is a corporate credential and it is yours to reset. If it appeared alongside a consumer service, the question becomes whether the password was reused, which is a different conversation with a different person.

Where the record came from. Breach, stealer log or combolist. This is the field that most changes what you do, and the field most often absent. A breach-sourced credential needs a reset. A stealer-log-sourced credential means malware was reading a browser profile on a real machine, so the device comes first, because resetting a password on a still-infected endpoint produces a fresh credential in the same place the malware is reading. A combolist appearance means the pair is circulating for bulk use, which points at your login endpoint and its rate limiting rather than at one user.

When it was taken, as against when it surfaced. These are different dates and the gap between them is the part nobody likes. The surfacing date is when the record became visible to whoever is reporting it. The acquisition date is when the credential actually left. The interval is how long somebody else had a working credential while you did not know. If a report gives only one date, it is almost always the surfacing date, and treating it as the acquisition date will make an old exposure look fresh and a fresh one look handled.

What arrived alongside it. A stealer log is not just a password. It commonly includes session cookies, autofill data, and sometimes details of the machine itself. Session cookies matter disproportionately, because a stolen session can be resumed without the password and without the second factor, which means a reset and an MFA prompt both miss it. If a report mentions cookies, the response has to include session revocation, and that is a separate action from changing the password in most identity providers.

A triage order that works

Start with devices, not accounts. Group the findings by apparent source machine. Every group that looks like a single stealer log is one device to deal with, and dealing with it protects every credential in the group at once. Doing accounts first means you will redo them.

Then separate corporate from consumer. Credentials for your own domains are directly actionable. Credentials for third-party services under a work email address are a reuse question, and the only thing you can genuinely act on is whether the same password is in use anywhere you control.

Then check whether the password is current. This is the single highest-value filter and it is often skipped because it feels intrusive. A credential rotated out eighteen months ago is noise. One matching a live password is an incident. Most providers will let you test an exposed value against your directory without handling the plaintext yourself.

Then look at the dates. Anything acquired recently deserves a look at what happened in the account during the window, not just a reset. Anything acquired years ago and never rotated is a policy finding as much as an incident.

Then act, in the order that holds. Device first where malware is implicated. Session and token revocation explicitly, because in most identity providers it is not a side effect of a password change. Then the reset. Then the things a reset does not reach, which includes app passwords, attacker-registered MFA methods, OAuth application grants and mail forwarding rules.

What a report cannot tell you

Being clear about this is what keeps a report credible internally.

Whether the credential still works. Nobody tests that, and nobody should. The record says the pair existed, not that it authenticates today.

Whether the data is accurate. This material is assembled and sold by criminals. Troy Hunt's framing of the stealer log data in Have I Been Pwned is worth borrowing directly: the data is prepared and sold by criminals who provide zero guarantees as to its accuracy, and the owner of an address may never have actually visited the indicated website. The same caution applies to every commercial source, including paid ones.

Whether the infection is still live. A stealer log is a snapshot. It does not say whether that machine is exfiltrating today.

Whether this is everything. No provider sees all sources. A report describes what was found in what was searched, and the honest version says so.

Reading the absences

Two absences are worth treating as findings in themselves.

A report with no source field is asking you to guess at the most consequential decision in the process, which is whether this is a password problem or a device problem. That is a reasonable thing to raise with whoever produced it.

A report with a single date is probably giving you the surfacing date only, which means you cannot measure your own exposure window. Also reasonable to raise.

Why any of this beats a scheduled reset

The instinct, faced with a long list, is to rotate everything and move on. The current standard rules that out as a routine practice while requiring the opposite approach.

NIST SP 800-63B-4 section 3.1.1.2 states that verifiers and credential service providers shall not require subscribers to change passwords periodically, and in the same item that verifiers shall force a change if there is evidence that the authenticator has been compromised. A report is the evidence. Reading it properly is what turns a prohibition on calendar rotation into a defensible process, and the same section requires that whatever new password gets set is checked against a blocklist of known commonly used, expected or compromised values, which a mass reset performed in a hurry tends to skip.

Check your own exposure

SphereTI reports which of your domains appear in breach corpora, infostealer logs and credential lists, with the source and timing for each finding. If you want a report of your own to work through, request a free exposure report. No password is needed

Common questions

Our report has thousands of rows. Are we in serious trouble?

Probably not in proportion to that number, because rows are not incidents. A single infected device contributes a row for every credential the browser had saved, which is commonly dozens, and the same address reappears across breach corpora, stealer logs and reaggregated combolists. The two figures worth calculating are distinct accounts whose current password is exposed, and distinct devices that appear compromised. Both are usually far smaller than the row count.

Which field should we look at first?

The source type, because it decides everything downstream. A breach-sourced credential needs a password reset. A stealer-log-sourced credential means malware was reading a browser profile, so the device has to be handled before the reset, otherwise the new password lands in the same place the old one was taken from. A combolist appearance points at your authentication endpoint rather than at an individual user.

The report gives one date. Is that when the credential was stolen?

Usually not. A single date is almost always when the record surfaced to whoever is reporting it, not when the credential was taken. The difference matters because the interval between the two is how long someone else held a working credential before you knew. If the distinction is not in your report, it is a fair question to put to the provider.

Should we reset every exposed password straight away?

Not as a first move, for two reasons. Where malware is implicated the device comes first, because a reset on an infected endpoint produces a new exposed credential. And in most identity providers a password change does not end existing sessions, so an attacker holding a live refresh token or session cookie keeps access through the reset. Revoking sessions is a separate action and it belongs before the reset, not after.

How do we tell whether an exposed password is still in use?

By testing the exposed value against your own directory, which most identity platforms support without anyone handling plaintext directly. It is the highest-value filter available and it is frequently skipped. NIST SP 800-63B-4 section 3.1.1.2 also requires verifiers to compare new passwords against a blocklist of known commonly used, expected or compromised values, so the same capability serves both purposes.

Can we trust the data in a report like this?

Treat it as a strong reason to check rather than as proof. The underlying material is assembled and sold by criminals, and Troy Hunt's description of the stealer log data in Have I Been Pwned applies broadly: it comes with zero guarantees as to accuracy, and an address may appear next to a website its owner never visited. A finding justifies investigation. It does not by itself establish that an account was accessed.

Check your own exposure

Enter a work email and SphereTI checks it against known breaches and stealer logs, then shows you which credentials have been exposed. Free, and it never asks for your password.

Get your free report

Keep reading

Exposure monitoring Knowing an address appeared somewhere is not the same as knowing what to do. What the category covers, and what it does not.Surviving a reset Changing the password is not the same as ending the session. Three identity providers, and what each one leaves running.Telegram credential trade Public channels advertise, private channels deliver, and Telegram's own policy explains why. The split is architecture, not accident.