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 rather than 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 is what 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 is the device rather than the row, 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 not a credential file. It is a package, 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 the session rather than establishing a new one, and 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. It is the thing 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.

The reason this determines account takeover prevention rather than merely informing it is that 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 — force a password reset, confirm 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 is also a current problem rather than a historical one. 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 is not the finding. The operationally useful question 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 — it is a fraud and account-protection problem, it is not an endpoint you can rebuild, and it is emphatically not a credential anyone should be testing 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. It is worth building the triage rule around the URL field explicitly rather than assuming severity scoring will surface it, because 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 — worth 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 — deduplicate 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 rather than a queue of rows, which is also why provenance work matters upstream — the distinction between stealer logs and combolists 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 rather than 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 — 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 treat restoration as a decision rather than 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. Whether anybody used it is a question only your logs answer, and the correct order is to find the artefact here and then go and look there.

Account takeover prevention improves when the unit of work stops being the credential and becomes the machine — because the machine is what the attacker actually holds, and reconstructing it is what 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