Intelligence · Proprietary collection

Stealer-log monitoring that answers which credentials still open something

ShadowMap runs its own stealer-log collection rather than reselling a feed, and keeps the raw source material permanently. That means two things a feed cannot do: it tells you which credentials still open something, and it improves your history every time our extraction improves.

Request an exposure snapshot How to evaluate this

app.shadowmap.com/org/acmecorp/dark-web

ACMECORP

Dark Web Monitoring

Monitoring

Breach and credential records

12B+

Raw source material retained

~41TB

CONFIRMED WORKING

Probed and it authenticated. The account is reachable with this credential now.

MAYBE WORKING

Probing was inconclusive — rate limiting, an MFA interstitial, or an ambiguous response.

NOT WORKING

Probed and rejected. The credential is stale against this service.

NOT TESTED

Outside authorised scope, or no safe probe exists for the service.

12B+

Breach and credential records

~41TB

Raw source material retained

200–800

Stealer-log credentials surfaced in a first scan

A typical band. Where you land depends on headcount, sector and how long people have been reusing passwords — and the count is not the point. What matters is how few still work, and which of those reach production.

The gap

A row in a feed cannot tell you whether the machine is still infected

The standard product in this category is a list of address-and-password pairs matched against your domain. It answers one question, and it is not the question you have.

A matched pair tells you a credential was stolen at some point. It does not tell you whether it still authenticates, what else came off the same machine, or whether that machine is still sending. Much of what circulates is combolist material — old breach corpora recycled, merged and resold, where the same credential reappears for years under a new filename and each reappearance looks like a fresh incident. Stealer logs are different in kind: they are the output of malware running on a specific device at a specific moment, and everything in one log came off one machine. Treating the two as the same feed is how a queue fills with noise while the live compromise sits inside it, indistinguishable.

The mechanism

One infected machine, seven kinds of evidence

A row-per-credential view loses the machine. We assemble the artefacts belonging to a single compromised device into one case, so you can tell a stale password from a live session.

Artefacts recovered from one infected device, assembled into a single compromise case The corpus band shows why retention matters: a machine compromised eighteen months ago can surface an artefact this month because the parser improved — not because anything new was stolen.

What you act on

Every credential carries its state

Volume is not a finding. A credential is probed and given one of four explicit states, so your queue is the ones that still open something rather than the ones that exist.

Every credential carries its state
State	What it means	What follows
Confirmed Working	Probed and it authenticated. The account is reachable with this credential now.	Rotate today, and check for session persistence.
Maybe Working	Probing was inconclusive — rate limiting, an MFA interstitial, or an ambiguous response.	Treat as live until you have checked it yourself.
Not Working	Probed and rejected. The credential is stale against this service.	Still evidence of a compromised device. Investigate the endpoint.
Not Tested	Outside authorised scope, or no safe probe exists for the service.	Verify internally. We never imply validation we did not perform.

Key

Act now
Assume live
Lower urgency
Needs your check

The evidence

What comes off an infected machine, and what each artefact changes

Most tools flatten everything a stealer takes into one credential list. These are held apart, because the remediation is different for each and a password reset closes only the first row.

Artefact	What it is	What it changes about your response
Credentials	Address-and-password pairs taken from the browser store and from any client the stealer could read.	Rotate, and rotate everywhere the password was reused rather than only where it was found. This is the row every product covers.
Session cookies	Live authenticated sessions lifted from the browser, for whatever the user was signed in to at the time.	Revoke sessions. A password reset on its own does not end a stolen session, and an attacker holding a valid cookie never sees your login page.
This is the artefact most often missing from a credential-only feed, and the one most likely to make the password reset irrelevant.
Tokens	OAuth refresh tokens and similar long-lived grants issued to applications the user had authorised.	Revoke the grant at the identity provider. A refresh token can survive a password change and an MFA re-enrolment, because neither of those revokes it.
The device record	Hostname, operating system, installed software and the stealer family that took it, with the infection date.	Decide whether this is a managed endpoint or a personal machine. The answer changes who can act — your EDR reaches one of them.
Infostealer infections frequently land on a home or family device that corporate credentials were typed into, which is precisely where endpoint controls do not reach.
Autofill data	Saved form data — corporate addresses, personal details, and whatever else the browser had been asked to remember.	Treat as the social-engineering payload. It is what makes a follow-on approach to this person, or to their colleagues, convincing.
Browser history	The URLs the machine reached, including internal tools and admin consoles that are not publicly discoverable.	Read it as reconnaissance the attacker already has. It names your internal systems, and it tells you which of them to watch.
Cards and wallets	Payment card data and cryptocurrency wallet artefacts found on the device.	Route to fraud operations rather than to identity. For a card issuer, exposure scoped to your own BIN ranges is a different alert to a staff exposure.
Source attribution	Stealer family, infection date, exfiltration destination, ingest source and a confidence position, carried on the match itself.	Severity and sequencing. An infection dated this week and one dated two years ago justify very different responses to the same credential.
Attribution is on the record rather than in a separate report, because a triage decision made without it is a guess about how urgent the row is.

Credentials

What it is: Address-and-password pairs taken from the browser store and from any client the stealer could read.
What it changes about your response: Rotate, and rotate everywhere the password was reused rather than only where it was found. This is the row every product covers.

Session cookies

What it is: Live authenticated sessions lifted from the browser, for whatever the user was signed in to at the time.
What it changes about your response: Revoke sessions. A password reset on its own does not end a stolen session, and an attacker holding a valid cookie never sees your login page.

This is the artefact most often missing from a credential-only feed, and the one most likely to make the password reset irrelevant.

Tokens

What it is: OAuth refresh tokens and similar long-lived grants issued to applications the user had authorised.
What it changes about your response: Revoke the grant at the identity provider. A refresh token can survive a password change and an MFA re-enrolment, because neither of those revokes it.

The device record

What it is: Hostname, operating system, installed software and the stealer family that took it, with the infection date.
What it changes about your response: Decide whether this is a managed endpoint or a personal machine. The answer changes who can act — your EDR reaches one of them.

Infostealer infections frequently land on a home or family device that corporate credentials were typed into, which is precisely where endpoint controls do not reach.

Autofill data

What it is: Saved form data — corporate addresses, personal details, and whatever else the browser had been asked to remember.
What it changes about your response: Treat as the social-engineering payload. It is what makes a follow-on approach to this person, or to their colleagues, convincing.

Browser history

What it is: The URLs the machine reached, including internal tools and admin consoles that are not publicly discoverable.
What it changes about your response: Read it as reconnaissance the attacker already has. It names your internal systems, and it tells you which of them to watch.

Cards and wallets

What it is: Payment card data and cryptocurrency wallet artefacts found on the device.
What it changes about your response: Route to fraud operations rather than to identity. For a card issuer, exposure scoped to your own BIN ranges is a different alert to a staff exposure.

Source attribution

What it is: Stealer family, infection date, exfiltration destination, ingest source and a confidence position, carried on the match itself.
What it changes about your response: Severity and sequencing. An infection dated this week and one dated two years ago justify very different responses to the same credential.

Attribution is on the record rather than in a separate report, because a triage decision made without it is a guess about how urgent the row is.

Why a feed cannot do this

We keep the raw material, so old data gets better

A reseller only ever has what its supplier chose, or was able, to parse at the time. We retain the source archives permanently and re-run improved parsers against them.

Worked example

A machine compromised eighteen months ago

What was extracted at the time: Usernames and passwords. The archive was password-protected and partially malformed, so everything past the credential block was skipped.
What was actually in it: Session cookies, an OAuth refresh token, autofill data including a corporate address, and browser history showing which internal tools the machine reached.
What changed: Our extraction improved. Because we still held the archive, we re-ran it — and the token was still valid. Nothing new was stolen; we simply became able to read what we already had.

The number

Where two hundred to eight hundred comes from

The band above the fold is a first scan, and a first scan clears history rather than describing a month. Being precise about what is counted matters here, because a product that counts rows can report any number it likes.

How the first-scan band is counted As of August 2026

The unit is a distinct credential attributed to your domains, deduplicated across every log, combolist and paste it appears in. One password recycled through six aggregations is one finding, not six.
The window is the first scan, which reaches back through the retained corpus. Steady-state months run far lower — the backlog is a one-off, new infections are not.
The band is wide because what drives it is your organisation rather than our method: headcount, how long the domain has existed, how much work happens on personal devices, and how much password reuse has accumulated.
The count is not the deliverable. Every credential carries one of four published states, and the queue worth working is the confirmed and the inconclusive — not the total.

Deliberately excluded

Material that cannot be attributed to your organisation or its people. Whatever it matched, it is not counted for you.
Consumer accounts belonging to staff that reach nothing of yours, unless you have asked for them to be in scope.
Exposure you already knew about and already had on a rotation plan when monitoring started.
Repeat appearances of a credential already counted. A combolist reissued under a new filename does not produce a second finding.

Where it goes next

A credential is a lead, not a conclusion

Dark-web findings are most useful when something tests them. Leaked credentials are probed against the access paths that actually matter to you.

Collect

Sources under continuous collection

Automated discovery of new sources and channels, automated handling of archives including password-protected material, and broad artefact extraction into our own store.
Attribute

Correlate to your identities and assets

Exposure is split by whose it is — corporate, customer or partner — and by what it reaches: cloud, ADFS, Azure AD, infrastructure access paths.
Validate

Probe, where it is safe and authorised

Continuous Automated Red-Teaming tests the credential and moves confirmed ones to a working state. Not every credential is testable, and the ones that are not say so.
Act

Into the queue you already use

Findings route to Slack, Jira, ServiceNow or your SIEM with the device case attached, rather than as a row in a spreadsheet.

The response

What the first week looks like when an executive turns up in a log

The reason artefacts are held apart is that they are acted on at different hours by different people. This is the sequence a senior-executive exposure actually runs through.

Hour 0

The match lands with its evidence

A credential attributed to a named executive appears in fresh stealer-log material. The alert carries the device case, not a row: what else came off the same machine, when it was infected, and which family took it.

Hour 0–1

Establish what is actually exposed

Credentials alone, or cookies and tokens with them. That distinction decides whether this is a password reset or a session-revocation exercise, and getting it wrong costs the rest of the week.

Hour 1–2

Contain at the identity provider

Revoke sessions, force the reset, revoke outstanding application grants, and tighten conditional access for the affected identity. Findings route into Okta, Entra ID or your ticketing queue with the evidence attached.

Hour 2–4

Read the reconnaissance

Browser history from the same device names the internal tools the machine reached. Those are the systems to watch, and the list came from the attacker's own copy rather than from your architecture diagram.

Hour 4–24

Deal with the machine

The infection is frequently on a personal or home device that corporate credentials were typed into — outside the reach of your endpoint controls. Confirming whether it is still sending is a separate job from rotating the password.

Day 1–7

Watch what follows

Executive exposure is often the opening move. Watch for impersonation registrations targeting the same person and for access being offered on that basis, and probe the rotated credentials to confirm the rotation actually closed the path.

Where this gets sharper

Dark Web Monitoring works from one correlated exposure model

Continuous Automated Red-Teaming Leaked credentials are probed and confirmed ones move to Confirmed Working. Four states are published per credential: Confirmed Working, Maybe Working, Not Working and Not Tested.

Where this has already run

Dark Web Monitoring, in engagements we can talk about

An engagement where this did the work, and what it changed.

Twenty-three rotations the same day, and a queue small enough to review weekly

From 57,300 leaked credential records to 23 accounts worth rotating today

Read the story

All customer stories

Questions buyers actually ask

Before you evaluate this

What is the difference between a stealer log and a combolist?

A combolist is an aggregation — old breach corpora merged, deduplicated badly and recirculated, where the same credential resurfaces for years under new filenames and each resurfacing looks like a new incident. A stealer log is the output of malware that ran on one machine at one moment, so everything in it belongs together: the credentials, the cookies, the tokens, the browser history and the device itself. That is why we assemble a log into a device case rather than splitting it into rows. If your current feed cannot tell you which of the two a finding came from, every combolist reissue arrives looking like a fresh compromise.

Everyone claims billions of records. Why is yours different?

Agreed, and the number is not the argument. Most vendors licence the same aggregated corpora, so the count mostly measures who they bought from. Two things separate ours: we keep the raw material, so when our extraction improves our history improves with it; and what we hand you is not a row count but a compromised device, with the credentials, cookies, tokens and access paths that belong together. The closing question for any incumbent is whether they can reprocess their own history. Most cannot, because they never had it.

Do you test the credentials you find?

Where it is safe and authorised, yes — and every credential carries an explicit state so you can see exactly what was and was not tested. Confirmed Working means it authenticated. Not Tested means we did not probe it, and we never imply validation we did not perform.

Which sources do you collect from?

We describe the collection at the level of what it does — automated source discovery across thousands of groups and sources, automated and password-protected archive handling, broad artefact extraction, and correlation to your identities and assets. We do not publish source names, channel topology or collection methods, because publishing them is how collection gets blocked.

Who else does this

Compared honestly

Where dark web monitoring is concerned, the real alternatives are the broad digital-risk platforms:

ShadowMap vs Cyble The unified agentic cybersecurity platform Read the comparison → ShadowMap vs CloudSEK Predictive Attack Graph Platform for the AI Era Read the comparison →

All five vendors side by side · What the same coverage costs assembled from separate tools

Find out how many of your credentials still work

One apex domain, two business days, a written snapshot. No call required.

Request an exposure snapshot See Pricing