A credential count is an observation. A rotation list is a decision.
“A credential of ours is in a stealer log. Which ones still open something, and what do we rotate first?”
A stealer-log report hands you a volume. Turning it into a queue takes five steps and four explicit credential states — Confirmed Working, Maybe Working, Not Working, Not Tested — so that by Monday evening every line has an owner, a date, and a reason it is on the list.
Items that needed action, from 57,300 raw records
One three-week evaluation at a mobile network operator, run alongside the incumbent feed it was being compared with. Nothing was discarded to reach 41 — the records were deduplicated, attributed to assets the operator actually owned, grouped back onto the machines they came from, and given a state each. What is left is a queue a team can work in a morning.
The Monday problem
Nobody can act on forty thousand
The number in a dark-web report is a match count against a breach corpus, and a breach corpus is mostly history. It is a real number. Almost none of it is a decision.
The question worth asking is narrower and it has two halves: which of these credentials would authenticate against something you own if somebody tried it this afternoon, and which of them sit on a machine that is still infected right now. Everything else belongs in a monitoring queue rather than an escalation. Answering either half takes work the report has not done — deduplicating rows that arrived a dozen times under a dozen names, attributing them to assets discovery has already found and attributed to you, and reassembling the artefacts back onto the device they were stolen from. Skip that work and the only available response is a blanket password reset: expensive, unpopular, and indifferent to the session cookie that made the password irrelevant.
What you act on
Four states, and only one of them is today
Every credential carries an explicit state, so triage is reading a column rather than forming an opinion. The fourth state exists because the honest answer to some rows is that nobody probed them.
| State | What it means | What follows |
|---|---|---|
| Confirmed Working | Probed against a login surface you own and authorised, and an authentication response came back. Not an inference drawn from the age or the format of the credential. | Rotate today. Then ask the second question, which is whether a session outlived the password. |
| Maybe Working | Probing was inconclusive — rate limiting, an ambiguous response, or a second-factor challenge that held. Where a challenge held, the first factor was accepted and testing stopped there. | Treat as live. A challenge that held still means the password was right, so it goes on this cycle rather than into monitoring. |
| Not Working | Probed and rejected. The credential is stale against this service — reported rather than quietly dropped, because it still says the account and its surface were once exposed. | Off the rotation list, onto the endpoint list. A dead password from a machine that is still infected is a device problem, not a password problem. |
| Not Tested | Outside authorised scope, or no safe probe exists: a consumer account, a third-party service somebody signed up to with a work address, a surface you have not authorised us to touch. | Verify internally, or with the provider that owns the endpoint. We never imply validation we did not perform. |
- Rotate today
- Assume live, this cycle
- Investigate the device
- Your check, not ours
The funnel
Five steps, and each one takes items off the list
The order matters, because every step is bounded by the one before it. Attribution is only meaningful against a deduplicated set, and testing is only permissible against something already established as yours.
-
Deduplicate
The same row, a dozen times, under a dozen names
Resellers repackage the same dumps, so a raw count is partly a measure of how many times material has changed hands. Here 57,300 raw records resolved to 11,900 unique identity–credential pairs — roughly 4.8 raw rows per pair. The headline was inflated by nearly five before anybody had assessed a single credential.
-
Attribute
A password with your brand in the address is not a password for your systems
A stealer log records the URL the credential was captured against, and matching that URL to an asset discovery has already attributed to you is what turns a brand-shaped email address into a named login surface. It cuts both ways: 2,177 of the corporate and dealer pairs pointed at third-party services staff had signed up to with a work address, not at the operator at all.
-
Reconstruct
The unit of analysis is the machine, not the row
Grouping artefacts by infected device produced 287 distinct machines carrying at least one item linked to the operator. Each became a case rather than a row: infection date, first and last observation, and the full inventory of what that machine held — credentials, cookies, tokens, autofill data, browser history, device details.
-
Test
Where it is safe and authorised, probe it
Of 3,610 corporate and dealer pairs, 1,433 targeted a login surface the operator owned and had authorised for testing. Continuous Automated Red-Teaming tested those and returned a state for each, with evidence and an audit identifier so the activity could be reconciled against the operator’s own logs. Everything else carries Not Tested, and says why.
-
Act
Forty-one items, each with an owner and a date
Twenty-three rotations, fourteen server-side session revocations and four shared dealer logins replaced with per-user accounts, routed into the service-management tool the team already ran. The rest of the estate was not reset, and the service desk was never asked to reset it.
The queue
What surfaced, and what the team does with it
Four kinds of finding come out of the same corpus and none of them route to the same place; the last row is not a finding at all, but what somebody will later ask you to evidence. Each row carries its own boundary underneath it, because a method described without its limit is the sentence that gets quoted back at us.
| What surfaced | What the team does with it | Covered in |
|---|---|---|
| A password that still authenticates against a surface you own | Rotate the same day, then check the same identity for session material — a rotation on its own does not close a compromise that came with a cookie. | Continuous Automated Red-Teaming |
| Bounded to inventory already discovered and attributed to you, and only where you have authorised testing. A credential outside that boundary is never probed and never assumed — it carries Not Tested with the reason attached. | ||
| A session set from a machine infected in the last few months | Revoke server-side at the identity provider and force re-authentication. A valid session cookie is indifferent to a password changed this morning. | Dark Web Monitoring |
| Cookies are not replayed. Scope is established from the issuing domain, path and expiry, and the finding is reported as revoke server-side. Which sessions were actually still valid is confirmed by your identity-provider logs — your verification, not ours. | ||
| The same credential also sitting in a public repository or paste | Rotate, and treat the whole commit history as public. Getting the file taken down does not close it, because anyone who cared has already cloned it. | Data Exposure Monitoring |
| Public sources only — no agent, no repository connection, no read of private code. A credential that leaked into a private repository is invisible here until the moment somebody makes it public. | ||
| A row that is attributable but changes nothing today | It moves to the filtered queue carrying the verdict that put it there, so the reasoning is inspectable rather than implicit. | AI Review |
| Nothing is deleted and nothing is hidden. A filtered row stays visible with its verdict attached, and an analyst verdict always overrides the model. | ||
| A rotation a supervisor will later ask you to evidence | Close it with a dated scan window, a named owner, a state per finding and an audit identifier for anything that was tested — in both directions, including what was confirmed dead. | Banking and financial services |
| Credential monitoring appears in supervisory expectations across several jurisdictions, and what an inspection asks for is the chain rather than the count. This is programme context, not legal advice. | ||
A password that still authenticates against a surface you own
- What the team does with it
- Rotate the same day, then check the same identity for session material — a rotation on its own does not close a compromise that came with a cookie.
- Covered in
- Continuous Automated Red-Teaming
Bounded to inventory already discovered and attributed to you, and only where you have authorised testing. A credential outside that boundary is never probed and never assumed — it carries Not Tested with the reason attached.
A session set from a machine infected in the last few months
- What the team does with it
- Revoke server-side at the identity provider and force re-authentication. A valid session cookie is indifferent to a password changed this morning.
- Covered in
- Dark Web Monitoring
Cookies are not replayed. Scope is established from the issuing domain, path and expiry, and the finding is reported as revoke server-side. Which sessions were actually still valid is confirmed by your identity-provider logs — your verification, not ours.
The same credential also sitting in a public repository or paste
- What the team does with it
- Rotate, and treat the whole commit history as public. Getting the file taken down does not close it, because anyone who cared has already cloned it.
- Covered in
- Data Exposure Monitoring
Public sources only — no agent, no repository connection, no read of private code. A credential that leaked into a private repository is invisible here until the moment somebody makes it public.
A row that is attributable but changes nothing today
- What the team does with it
- It moves to the filtered queue carrying the verdict that put it there, so the reasoning is inspectable rather than implicit.
- Covered in
- AI Review
Nothing is deleted and nothing is hidden. A filtered row stays visible with its verdict attached, and an analyst verdict always overrides the model.
A rotation a supervisor will later ask you to evidence
- What the team does with it
- Close it with a dated scan window, a named owner, a state per finding and an audit identifier for anything that was tested — in both directions, including what was confirmed dead.
- Covered in
- Banking and financial services
Credential monitoring appears in supervisory expectations across several jurisdictions, and what an inspection asks for is the chain rather than the count. This is programme context, not legal advice.
The counting
Why 57,300 was never the exposure figure
Every number on this page comes from one three-week evaluation at a mobile network operator, running alongside an incumbent feed. Counting is where a credential programme is most easily flattered, so the method sits here rather than in a footnote.
How the figures on this page were counted As of August 2026
- The unit is the unique identity–credential pair, deduplicated across every dump, repackage and reseller the same row arrived in. Raw record counts are reported separately and are never presented as the exposure figure.
- The deduplication ratio is published beside the count, so a reader can work back from the resolved figure to the raw one rather than take the collapse on trust. Report one number without the other and nobody can tell which of the two is doing the work.
- Attribution runs against the URL the credential was captured on, matched to an asset discovery had already found and attributed to the operator — not against the email domain. That is what moved 2,177 pairs out of the security queue and into a governance finding about unsanctioned services.
- A machine is the case, not a row. 287 devices carried at least one linked artefact, and recency was measured from observed infection activity: 96 of them showed activity in the trailing 120 days, which is what separates a stale password from a live compromise.
- A state is recorded only from a response actually received. Confirmed Working means an authentication response came back, and the operator held an audit identifier for every validation request so it could reconcile the activity against its own logs.
Deliberately excluded
- No subscriber or consumer credential was tested. Authenticating to a customer account is neither authorised nor appropriate, whatever the credential appears to be worth.
- The 2,177 pairs pointing at third-party services were not tested, because the operator cannot authorise testing against somebody else’s endpoint. They carry Not Tested and a note to confirm and rotate with the provider.
- Session cookies were not replayed. Scope was established from issuing domain, path and expiry and reported as revoke server-side; the operator’s own identity-provider logs later confirmed eleven of the fourteen session sets were still valid.
- No time-to-rotation service level is published or implied. What changed was the operator’s own cadence — a short weekly review of a queue in the tens, in place of a quarterly argument about a spreadsheet in the tens of thousands.
What this job draws on
The capabilities behind it, and what each one contributes
Where this job comes up most: Banking and financial services and Technology and software .
Questions buyers actually ask
Before you evaluate this
Our current feed reports 40,000 and you reported more. How is that an improvement?
It is not, and a bigger raw number is not a better product. Broader collection is why the raw count was higher; what matters is what it resolved to. In this evaluation roughly 31,000 of the incumbent’s rows traced back to two aggregated regional dumps dated 2016 and 2017, against a consumer portal that had forced a full credential reset in 2019 — dead by construction. The incumbent had no way to know that, because a credential row does not carry its own provenance unless somebody keeps the source material and can reprocess it. The number to compare vendors on is not how many records they matched. It is how many decisions they handed you, and how they arrived at them.
We already forced a password reset. Why would this still be open?
Because a password reset does not touch a session that is already authenticated. Where a stealer took cookies and tokens alongside the credential, the attacker holds an established session that survives the rotation and, in most implementations, survives the second factor as well. That is why session material is treated as its own finding with its own action — revoke server-side, force re-authentication — rather than as an attribute of the credential. It is also why the reconstructed machine matters more than the row: the credential tells you an account was exposed, and the machine tells you what else left with it.
Almost everything of ours is behind MFA. Does this still matter?
It changes the shape of the work rather than removing it. Where a probe reaches a second-factor challenge and the challenge holds, the finding is Maybe Working: the first factor was accepted, testing stopped at the challenge, and the password still needs rotating this cycle because the only thing standing between it and an account is one control. The exposure MFA does not answer is the session — a set of cookies harvested after authentication is post-MFA by definition. Those two categories are where a credential programme with good MFA coverage actually spends its time.
Do you rotate the credentials for us?
No, and the division of labour is deliberate. ShadowMap establishes the state, assembles the evidence and opens the ticket into the queue your team already works — Slack, Jira, ServiceNow or your SIEM — with the machine case and the audit identifier attached. The rotation itself stays with the team that owns the account, because that team owns the identity provider, the change window and the consequences of a reset going wrong. A discovered credential is never used beyond what authorised testing needs to establish that it is live and what it reaches.
Bring us your last credential report
One apex domain and your email domains, two business days. You get the same records back as a queue — deduplicated, attributed, grouped by machine, and carrying a state per credential, including the ones we did not test.