Reconstructing a compromised device from seven artefacts

A credential-exposure record is usually presented as a row: an address, a password, a source, a date. That shape is convenient for a database and poor for a decision, because the row is a fragment of something larger. When the source is information-stealing malware and not a breached user table, the row did not arrive on its own. It arrived alongside everything else taken from one machine at one moment, and that context tells you whether you are looking at a password somebody changed in 2019 or a laptop that is, right now, handing someone an authenticated session.

This is the structural weakness in most account takeover prevention work. The programme is built around the credential, so its instrument is rotation and its evidence is a password. Rotation does nothing to a stolen session cookie, and a stolen session cookie does not need the password. Dark web and identity exposure monitoring only becomes a takeover control when the unit of analysis shifts from the row to the device, which means reconstructing the device from the artefacts that came off it.

Seven artefact classes, and the metadata that binds them

A stealer log is a package, not a credential file, and the packages are more consistent in structure than most people expect, because a handful of families account for the bulk of what circulates. Seven classes of artefact recur.

• Credentials. The browser's saved credential store, exported as URL, username and password. The URL field carries most of the analytical weight: it is what separates a forum login from an identity-provider login.
• Cookies. Exported with domain, path, expiry and flags. A cookie for an authenticated application is a bearer of the session itself. Replaying it resumes that session; it does not open a new one. The expiry field tells you whether the window is measured in hours or months.
• Tokens. OAuth refresh tokens, API keys held in local storage, and cloud credentials written to disk by CLI tooling. These routinely outlive both the password and the cookie, and they are usually the artefact with the longest tail.
• Cards. Autofill payment data. Rarely the security incident on its own, but frequently the fastest way to establish that the machine belonged to somebody carrying a corporate card.
• Wallets. Cryptocurrency wallet files and browser extension data. Mostly a signal about the operator's monetisation model, which tells you something about how quickly the material will be resold.
• Autofill. The most under-read artefact in the set. Form field names and values: addresses, telephone numbers, employee identifiers, occasionally the answers to knowledge-based recovery questions. Autofill is where you find out whether the account recovery path is compromised as well as the account.
• Browser history. The context nothing else supplies. Which internal hostnames the person reached, which administrative consoles they use routinely, whether the machine was on a corporate network at all.

Underneath all seven sits device metadata: a machine identifier, hostname, the operating-system build, the local user profile path, an installed-software list, local and external IP addresses, timezone and locale, and in many families a screenshot of the desktop at the moment of capture. Metadata is not itself an exposure. It is the join key that turns a scatter of unrelated-looking rows into one machine.

Stale password, or live session?

This is the question that decides whether a finding is history or an incident, and three fields settle it: the capture timestamp on the log, the expiry on the cookie, and whether a refresh token exists for the same identity.

The capture timestamp deserves particular attention because it is routinely confused with the discovery date. The date you found a record describes your monitoring programme. The date the log was taken describes the attacker's position, and the interval between the two is the exact window you should be searching your own authentication logs against. A record discovered last Tuesday from a device captured fourteen months ago is a very different investigation from the same record captured a fortnight ago.

That distinction drives account takeover prevention; it does not merely inform it. Multi-factor authentication is enforced at authentication. A replayed session cookie does not authenticate; it presents a session that was already authenticated, so no second factor is requested. The two standard responses to a credential alert, forcing a password reset and confirming MFA is enrolled, leave an issued session entirely intact. Invalidating it is a separate action, in a different console, and it is the one that actually closes the door.

Cookie theft has not gone away. Application-bound encryption introduced into Chromium in 2024 raised the cost of extracting cookies on Windows meaningfully; stealer families adapted, and cookie material continues to appear in fresh logs.

One credential, or a compromised machine?

The signals that separate these two cases are visible in the log before any validation work happens. How many distinct domains appear in the credential store, a handful or several hundred? Do personal and corporate identities appear side by side? Does the browser history contain internal hostnames? Are cloud CLI credential files present in the token artefact?

The distinction matters because it changes who owns the response. A single exposed credential is an identity-team ticket. A compromised machine is an endpoint incident with a device to rebuild, a person to speak to, and a scope that includes every account that browser ever held. Resetting one password on a fully compromised laptop leaves the operator exactly where they were, with the new password arriving in the next exfiltration.

Across ShadowMap deployments we typically surface between 200 and 800 stealer-log credentials for a given customer. The number itself is not the finding. What matters is how many machines those credentials represent, because that count is invariably far smaller, and it is the one you can actually staff against.

Whose identity is this?

Email domain is a weak proxy for ownership, and three cases behave completely differently.

An employee's corporate identity, captured from a machine your organisation controls, is your incident end to end. A customer's identity, captured from a machine you have no relationship with, appears in your data only because your login URL sits in their credential store. That makes it a fraud and account-protection problem: there is no endpoint for you to rebuild, and nobody should be testing the credential on your behalf. A partner or contractor identity holding access to your extranet, VPN or a shared tenancy is the hardest of the three: you control the access but not the device, so the remediation is access revocation plus an attestation you cannot verify directly. Sorting these three apart before triage begins is what stops a credential programme producing a queue nobody owns, a failure mode we covered in the difference between forty thousand leaked credentials and the eight that still work.

A news-site password and an identity-provider password

Both are one row with the same schema, and the URL field is the entire difference.

A password saved against a consumer site is a pattern input. It tells you how this person constructs passwords and whether that construction is likely to be reused, which is genuinely useful and rarely urgent. A password saved against login.microsoftonline.com, an ADFS host, an Okta or Ping tenant, a cloud provider console, a VPN portal, an internal source-control host or a CI server is access. Build the triage rule around the URL field explicitly, and do not assume severity scoring will surface it: a generic scoring model tends to weigh the identity and the source, not the destination.

Internal hostnames appearing in a personal browser are a finding in their own right, independent of any credential attached to them. They indicate a split-tunnel configuration, an unmanaged device with network access, or an internal tool being reached from home. Any of the three warrants a conversation regardless of whether the associated password still works.

Collapsing duplicates into one event

The same log is repackaged, resold and reposted many times over, so the same identity appears across many compilations. The instinctive fix, deduplicating on address plus password, produces a clean row and destroys the evidence, because it discards the artefacts and the capture context that made the record meaningful.

The correct unit is the compromise event: fingerprint on device metadata and capture timestamp, attach every artefact recovered from that capture to it, and allow the same identity to appear in several events where a machine genuinely was hit more than once. What comes out is a case with a narrative instead of a queue of rows. That depends on provenance work upstream: telling stealer logs and combolists apart is what makes the correlation possible at all.

This is where retention earns its keep. ShadowMap holds over 12 billion records across roughly 41 terabytes of retained source material, drawn from 466 dark-web and breach-forum sources and 778 Telegram channels under collection, spanning 26 stealer families. Because the source material is kept and not discarded after parsing, an improved parser can be re-run across the history, and records that were previously orphaned rows get re-attributed to the machine they came from.

The response that follows

Each artefact implies a different action, and the sequence matters more than the completeness.

Rotate the credential first. That is necessary and, on its own, insufficient. Then revoke sessions server-side, because in several major platforms the user-facing "sign out everywhere" control does not invalidate issued refresh tokens or application passwords. Then revoke the tokens themselves: OAuth grants, personal access tokens, application passwords, API keys and any cloud CLI credentials present in the log. Re-enrol MFA if the autofill artefact could plausibly have carried recovery material. Rebuild the device, or where it is not your device, remove its access and make restoration a decision, not a formality. Cancel the cards.

Then do the step that exposure data can never do for you: search your own authentication logs for that identity, across the window from capture date to today, for successful sessions from unfamiliar networks, geographies or user agents. Credential exposure monitoring establishes what leaked and what still authenticates. Only your own logs show whether anybody used it, so find the artefact here first and then go and look there.

Account takeover prevention improves when the unit of work stops being the credential and becomes the machine. The machine is what the attacker actually holds, and reconstructing it turns a list of exposures into a small number of decisions with owners attached.

See what a device story looks like against your own domain. 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 · Stealer logs are not combolists · Responding to leaked credentials