Skip to main content
Playbook · PDF · Gated

A stealer-log report tells you what leaked. It does not tell you what to do.

A response runbook for the security lead holding a fresh credential-exposure report and a working day to spend on it. What to establish in the first 24 hours, how to triage by credential state rather than by volume, why the infected machine rather than the credential row is the unit of response, and what to say upward before you know the answer.

Written for security operations leads, incident responders and the identity team they have to go and find on the first afternoon. It assumes a report in front of you, from any provider — not a ShadowMap subscription.

Get the playbook Request an exposure snapshot

What's inside

Six chapters, in the order you will need them

The order is the argument. Attribution means nothing before deduplication, sequencing means nothing before triage, and the conversation upward is written last because it depends on what the five chapters before it have established.

  1. Hour zero

    The first 24 hours, in the order they have to happen

    What to establish before anybody touches a password: whether the material is a fresh collection or a repackaged dump, which of the addresses are actually yours, which machines the artefacts came off, and what you can safely say internally while all three are still open. The sequence is written so that the first action does not destroy the evidence the second one needs.

  2. Triage

    Sort by state, not by volume

    The decision procedure behind the four published credential states — what evidence justifies each one, who is allowed to establish it, what to do when a second-factor challenge holds rather than fails, and why a credential that was probed and rejected still generates work rather than closing a row.

  3. Dating

    A stale password, or a machine that is compromised right now

    How to separate a credential that leaked years ago from a live infection: what the capture URL tells you that the email domain does not, how infection recency is read from the artefacts themselves, and the signals that mark an entry as historic dump material rather than something stolen this quarter.

  4. The unit

    You respond to a device, not to a row

    Why the infected machine is the thing that gets an owner and a case number, and the credential row is only one symptom of it. Includes the full artefact inventory for a single machine, what each artefact establishes on its own, and which of them survive a password reset untouched.

  5. Sequencing

    Rotation, session invalidation, endpoint investigation

    Three actions, three different owners, and an order that is not the obvious one. Rotation without server-side session invalidation leaves an authenticated attacker in place; an endpoint investigation opened too late loses the only evidence of how the machine was infected in the first place. Set out with the decision points and with what to hand the endpoint team.

  6. The conversation

    What to tell an executive, and what not to promise

    A short script for the first briefing upward: what you can state on day one and stand behind on day five, which questions to decline until you have evidence, and the specific promises — a final number, a completion date, an assurance that nothing was accessed — that are the ones people regret making.

Stealer-Log and Credential Exposure Response Playbook

We'll email you a confirmation link. Click it and the playbook downloads — no call, and no waiting on a sales follow-up to release the file.

By downloading, you agree to receive relevant communications. We respect your privacy.

Mid-incident and cannot wait for an email? The triage model the playbook is built on is set out ungated on leaked credentials response, and the collection behind it on Dark Web Monitoring.

The triage model

Volume is the wrong axis to sort on

These four states are not gated and never have been — they are published on the capability page and the use-case page already. What the playbook adds is the part that is harder to reproduce: what evidence justifies each state, who is entitled to establish it, and what happens to a row once it carries one.

What this playbook is, and what it is notCaution As of August 2026
  • An operational runbook written for the person holding the report. It assumes you own the identity provider, or can reach whoever does, on the day you read it.
  • Every validation step in it is bounded to what is safe and authorised. Probing a login surface you do not own, or have not been authorised to touch, sits outside the procedure — and the playbook says so at each of the points where it would be tempting.
  • The states it uses are the states ShadowMap publishes, so a customer reading a finding and a non-customer reading this playbook are working in the same vocabulary rather than two that nearly match.

Deliberately excluded

  • No time-to-rotation service level, published or implied. The playbook sets out a sequence and its decision points; how long your change window takes is a fact about your organisation, not about ours.
  • No accuracy or false-positive figure. Where a step turns on a judgement, the playbook names whose judgement it is rather than attaching a number to it.
  • It is not legal advice and it is not a notification procedure. Whether an exposure is notifiable, to whom, and by when are questions for your counsel and your regulator.
  • We do not rotate anything for anybody. The playbook is written on the assumption that the team owning the account owns the reset, the change window and the consequences of one going wrong.
The four published credential states, what each one means, and what follows from it
StateWhat it meansWhat follows
Confirmed Working Probed against a login surface you own and have authorised, and an authentication response came back. Never an inference drawn from the age, the format or the source 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 and work it this cycle. A control that stopped the probe is not evidence the password is dead.
Not Working Probed and rejected. Stale against this service — recorded rather than quietly dropped, because it still says the account and its surface were exposed at some point. Off the rotation list and 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 nobody has authorised anyone to touch. Your check, or the provider that owns the endpoint. Validation that was not performed is never implied.
Key
  • Rotate today
  • Assume live, this cycle
  • Investigate the device
  • Your check, not ours

Only one of the four is today's work, which is the entire reason the vocabulary exists. Where a state was established by probing, that probing is Continuous Automated Red-Teaming, run where it is safe and authorised and never beyond it.

The conversation upward

Two questions you will be asked, and the promises to refuse

Neither of these is hypothetical, and neither is really a technical question. They are the two moments at which a credential incident is most often described in terms that cannot be defended a week later.

01 Day one

“How bad is it? Give me a number.”

What is being asked for
A figure and a reassurance, ideally before the end of the meeting — because the person asking has to go and tell somebody else something, and an empty answer travels badly.
The answer that unravels
The count off the front of the report. It is the one number available on day one and the one least likely to survive the week: it is a match count against a corpus that is largely history, before deduplication, before attribution to anything you own, and before a single credential has been assessed. Quote it and you will spend the rest of the incident explaining why the number keeps going down.
The answer that holds
That a report exists, that a raw match count is not an exposure figure and precisely why, what you will have established by a stated hour, and what is happening in the meantime. A checkpoint you can keep is a better answer than a number you cannot, and it buys the working day that the triage actually needs.
02 Day three

“We reset the passwords. Are we clear now?”

What is being asked for
Confirmation that the reset closed it, so the incident can be declared over and everybody drawn into it can go back to the work they were doing.
Why it does not hold
A password reset does not touch a session that is already authenticated. Where the 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 with it. The reset is necessary and it is not sufficient, and the distance between those two words is where this conversation usually goes wrong.
What to say instead
That rotation is done, that server-side session invalidation is a separate action with a separate owner, and that the machine the artefacts came off is its own investigation. Then the point that is hardest to make and worth the most: what has not been established yet, and what would establish it.

Two worked examples. The chapter itself is written as a script — the wording for each answer, the questions to decline until you have evidence, and the checkpoint to offer in place of the number you are being asked for.

The unit of response

One machine, seven artefacts, and a reset that touches one of them

A stealer takes whatever the browser will give it. Presented as a row per credential, that becomes a handful of findings which look unrelated to each other; assembled back onto the device they came off, they become one compromise, with one owner and one date. This is the inventory the playbook works from.

Artefacts recovered from a single infected device, what each establishes, and where the response to it lives
ArtefactWhat it establishesWhere the response lives
Credentials That an account was exposed and, once probed where it is safe and authorised, whether the password still opens anything today. Continuous Automated Red-Teaming
The one artefact a password reset actually closes — which is why a response that stops at rotation is the most common way an incident gets reopened a fortnight later by somebody reading a login alert.
Cookies That an authenticated session existed and may still. Issuing domain, path and expiry establish what it reached and how long it was good for. Dark Web Monitoring
Cookies are not replayed in order to test them. Scope is read from the cookie itself and the finding is reported as revoke server-side; whether a given session was still valid is confirmed against your own identity-provider logs — your verification, not ours.
Tokens That access can persist with no password involved at all. A refresh token keeps working after the credential it was minted alongside has been rotated. Dark Web Monitoring
Usually the artefact that explains why access continued after a reset everyone had agreed was complete. It is revoked at the issuer rather than at the account, which is a different console and often a different team.
Cards That the compromise reached past your systems into the person’s own exposure, which changes the conversation you have with them. Leaked credentials response
Rarely a corporate finding and never an irrelevant one. In practice it is what persuades a device owner that the infection was real and personal, and that is frequently what gets the machine handed over for investigation the same day.
Wallets That the stealer reached material the user was actively guarding — which makes it a useful signal about how deep the infection went. Leaked credentials response
Treated as evidence about the machine rather than as a corporate asset. What matters to your incident is not the wallet; it is what the wallet’s presence says about everything else the stealer was able to read.
Autofill data What the browser was configured to hand over on request: addresses, identifiers, and the corporate email address that ties an apparently personal machine back to your organisation. Dark Web Monitoring
Often the artefact that establishes attribution when the credential itself is registered to a personal address — and reliably the one people are most surprised to learn was in the log at all.
Browser history Which internal tools that machine actually reached. The difference between a credential that exists and a credential sitting in front of something that matters. Continuous Automated Red-Teaming
History is what turns a list into a prioritised queue, and it is bounded by the same rule as everything else here: it informs testing against surfaces you own and have authorised, and against nothing outside them.

Artefacts recovered from a single infected device, what each establishes, and where the response to it lives

Credentials

What it establishes
That an account was exposed and, once probed where it is safe and authorised, whether the password still opens anything today.
Where the response lives
Continuous Automated Red-Teaming

The one artefact a password reset actually closes — which is why a response that stops at rotation is the most common way an incident gets reopened a fortnight later by somebody reading a login alert.

Cookies

What it establishes
That an authenticated session existed and may still. Issuing domain, path and expiry establish what it reached and how long it was good for.
Where the response lives
Dark Web Monitoring

Cookies are not replayed in order to test them. Scope is read from the cookie itself and the finding is reported as revoke server-side; whether a given session was still valid is confirmed against your own identity-provider logs — your verification, not ours.

Tokens

What it establishes
That access can persist with no password involved at all. A refresh token keeps working after the credential it was minted alongside has been rotated.
Where the response lives
Dark Web Monitoring

Usually the artefact that explains why access continued after a reset everyone had agreed was complete. It is revoked at the issuer rather than at the account, which is a different console and often a different team.

Cards

What it establishes
That the compromise reached past your systems into the person’s own exposure, which changes the conversation you have with them.
Where the response lives
Leaked credentials response

Rarely a corporate finding and never an irrelevant one. In practice it is what persuades a device owner that the infection was real and personal, and that is frequently what gets the machine handed over for investigation the same day.

Wallets

What it establishes
That the stealer reached material the user was actively guarding — which makes it a useful signal about how deep the infection went.
Where the response lives
Leaked credentials response

Treated as evidence about the machine rather than as a corporate asset. What matters to your incident is not the wallet; it is what the wallet’s presence says about everything else the stealer was able to read.

Autofill data

What it establishes
What the browser was configured to hand over on request: addresses, identifiers, and the corporate email address that ties an apparently personal machine back to your organisation.
Where the response lives
Dark Web Monitoring

Often the artefact that establishes attribution when the credential itself is registered to a personal address — and reliably the one people are most surprised to learn was in the log at all.

Browser history

What it establishes
Which internal tools that machine actually reached. The difference between a credential that exists and a credential sitting in front of something that matters.
Where the response lives
Continuous Automated Red-Teaming

History is what turns a list into a prioritised queue, and it is bounded by the same rule as everything else here: it informs testing against surfaces you own and have authorised, and against nothing outside them.

The column nobody prints is the date. Each of these carries the machine it came off and, where we have it, when that machine was seen — which is what separates a decade-old dump entry from an infection that is still running, and what an exposure snapshot annotates for your own domain.

Questions before you hand over an address

Fair things to ask about a gated file

We are not a ShadowMap customer. Is the playbook still usable?

Yes. It is written against a report rather than against our console, and the report can be from any provider. The four credential states are published vocabulary rather than a product feature, so where your provider does not state a state per credential, the playbook gives you the questions to put to them and what an acceptable answer looks like. The sequencing chapter assumes only that you can reach whoever owns your identity provider on the day you read it.

We already forced a password reset. Is there anything left to do?

Almost certainly. A reset does not touch a session that is already authenticated, and where cookies and tokens were taken alongside the credential the attacker holds an established session that survives both the rotation and, in most implementations, the second factor. Session material is treated in the playbook as its own finding with its own action — revoke server-side, force re-authentication — rather than as an attribute of the credential. The machine those artefacts came off is a third piece of work again, and it is the one most often skipped.

How is this different from the exposure snapshot?

The playbook is a procedure and it is the same procedure for everybody. The exposure snapshot is a finding about your domain specifically: we run ShadowMap against one apex domain and send back what is already reachable from outside, with the credentials deduplicated, attributed and grouped by the machine they were stolen from. Reading the playbook first and then requesting a snapshot is the sequence we would suggest, because the second one arrives in the shape the first one taught you to read.

What do you do with my email address?

We email you a confirmation link, and the playbook downloads when you click it — that step exists because the file used to be released to anyone who typed an address, and most of them were not addresses. Beyond that we may follow up once about what prompted the download. We ask for nothing about your estate to send you the file, and requesting the playbook is not a scan of anything.

The playbook assumes you already have a report. If you do not, start with one.

One apex domain, two business days, a written snapshot of what is already reachable from outside — with the credentials deduplicated, attributed to assets we can tie to you, grouped by the machine they were stolen from, and annotated with the stealer family and infection date where we have them.

Request an exposure snapshot How the states are established