An alert lands on a Tuesday morning: four sets of employee credentials have appeared in stealer logs, and one of them carries the exact login URL for your remote access portal. The password is current. The capture date is three weeks old. Somebody asks the obvious question, "so we just reset them?"

No. Resetting the password is roughly a third of the job, and it is the easy third. What follows is a practical runbook for the first 72 hours after infostealer-harvested credentials surface, written for the situation you will actually face: an infected device you do not own, a session cookie that walks past MFA, and a data set that may be genuinely fresh or may be a two-year-old corpus wearing a new name.

What Is Actually Inside a Stealer Log (And What Is Not)

An infostealer is commodity malware that runs once on a machine, harvests everything of value from browsers and the file system, exfiltrates it, and often deletes itself. The output is a folder, and that folder is the log.

Open one and you typically find:

• Exported browser credential stores, usually as plain text, with the username, the password and the URL the credential was saved against.
• Cookie and session token files pulled from every browser profile on the device, including active authenticated sessions.
• Autofill data, saved card details, and sometimes crypto wallet files.
• A system information file naming the machine, the OS build, the installed software, the hardware ID, the country and the external IP address at the moment of capture.
• A screenshot of the desktop taken at infection, which tells you far more about the environment than most defenders expect.

RedLine, Lumma, Vidar, Raccoon and StealC account for a large share of the volume traded, and their outputs differ in structure and completeness rather than in kind. Law enforcement has landed real blows on this market: Operation Magnus disrupted RedLine and META in October 2024, and Microsoft's Digital Crimes Unit, working with international law enforcement, moved against Lumma infrastructure in May 2025. Successors and rebuilds filled the space quickly. Treat any assumption that a takedown reduced your exposure with scepticism.

The System Information File Is Your Best Asset

Almost nobody writes about this file, and it is the single most useful artefact in the log for a defender. The machine name tells you whether the device follows your corporate naming convention. The installed software list tells you whether your EDR agent and VPN client were present. The external IP tells you whether the capture happened on a home broadband connection, a corporate egress range, or an airport network in another country. That is how you establish, within minutes rather than days, whether you are dealing with a managed endpoint, a BYOD device, or a home PC that a family member shares with your finance director.

What a Log Does Not Prove

A stealer log is not evidence that your systems were breached. It is a snapshot of one device at one moment. That distinction changes who owns the response: this is an identity and access incident, not a platform compromise, and the corrective actions sit with your identity provider and your session controls rather than with a forensic investigation of your servers.

The URL field is where the value sits. A conventional breach dump tells you an email address and a hash. Have I Been Pwned's ingestion of multiple stealer log corpora, each containing tens of millions of unique email addresses paired with the specific website the credential was entered on, made this difference visible to the wider industry. The URL tells you precisely which of your applications the stolen password opens.

How Infostealer Logs Reach Attackers: The Distribution Chain

Infection routes are mundane and almost always outside your policy perimeter. Cracked software and licence key generators. Game cheats. Fake browser update prompts on compromised sites. Malicious search advertisements sitting above the legitimate download for a well-known utility. ClickFix-style lures that instruct the user to paste a command into the Windows Run box to "verify"they are human. Trojanised installers linked from YouTube video descriptions.

Once exfiltrated, logs enter a resale economy. Some are sold individually. Far more are bundled into subscription "cloud of logs"services where buyers pay monthly for a search interface across millions of records. The same corpus is repackaged, restitched and rebranded repeatedly, which is why a "new 2025 breach"frequently contains credentials that were remediated in 2023.

Telegram now functions as the shop window. Free sample dumps are posted publicly in open channels purely as advertising for paid private ones. Dark web Telegram monitoring so surfaces exposure days before the same records reach a forum listing or a paste site, and for a defender those days are the whole game.

Initial access brokers and ransomware affiliates buy logs with specific search terms in mind. They are not interested in your employee's streaming subscription. They query the URL field for VPN gateways, RDP portals, Citrix endpoints and SSO sign-in pages, then sell validated access on to whoever wants it.

The First 72 Hours: A Triage Runbook

Hour 0 to 4: Validate Before You Escalate

Do not page the incident team yet. Open the system information file and check the capture timestamp, the external IP and the machine name. Compare the credential set against your historic leaked-credential data. If the same username and password pair appeared in a corpus you handled eighteen months ago, you are looking at recycled content, and the correct response is to confirm the earlier remediation held rather than to restart it.

Then check whether the password is current in your directory. A stale password with a fresh capture date is a different problem from a current password with an old one.

Hour 4 to 24: Identify the Human, Then Kill the Sessions

Map the credential to a person and the device to an owner. Reset the password, yes, but the action that actually closes the door is a global session revocation. In Microsoft Entra ID that is the revoke sessions action against the user object, which invalidates refresh tokens; do the same in Google Workspace, your VPN concentrator, and any SaaS application that manages its own sessions independently of your identity provider. Those independent sessions are the ones teams forget.

Re-register MFA if the log shows the browser profile was authenticated. Check whether any device is currently joined or registered under that identity that the user does not recognise.

Hour 24 to 72: Find Out What Happened in the Gap

The interesting window is between the capture date and your detection date, and it is often weeks long. Pull sign-in logs for that period and look for unfamiliar device fingerprints, sign-ins from IP ranges the user has never used, and impossible travel. Then check the things attackers set up to keep access after a reset:

• Inbox rules that forward or auto-delete mail, particularly rules with single-character names.
• OAuth application grants consented since the capture date.
• New MFA methods enrolled, especially authenticator apps registered from an unfamiliar location.
• Mail delegation, mailbox permissions and any newly created API tokens or app passwords.

If customer personal data sits behind any account touched in that window, involve your data protection lead early. UK GDPR Article 33 gives you 72 hours to notify the ICO of a reportable personal data breach, and that clock starts when you become aware, not when you finish investigating.

The Awkward Conversation About the Device

Most of the time the infected machine is not yours. It is a personal laptop, a contractor's own kit, or a household gaming PC where a teenager and a parent share the same Chrome profile. You cannot wipe it, you cannot image it, and you may not even be told the truth about what is on it.

The only safe assumption is that everything typed into that browser is gone: work credentials, personal banking, supplier portals, the lot. Your policy needs a documented response path for exposure you cannot remediate at the endpoint, because "instruct the user to run a scan"is not a control.

Why Password Resets Alone Do Not Close the Exposure

Session cookies are the part that gets missed. An attacker who imports a stolen cookie into their own browser resumes an already-authenticated session, and the identity provider never issues a fresh authentication challenge because, as far as it is concerned, authentication already happened. MFA is bypassed entirely. Your reset changed a password the attacker no longer needs.

Controls that actually degrade the value of a stolen cookie:

• Conditional Access policies that bind sessions to compliant or hybrid-joined devices, so a replayed token from an unknown machine fails the policy.
• Token protection in Microsoft Entra, which cryptographically binds a token to the device it was issued to. Check its current availability and supported scenarios before you build a plan around it.
• Shorter session lifetimes and sign-in frequency policies on high-value applications, accepting the user friction that comes with them.
• Continuous access evaluation, so revocation propagates in near real time rather than at token expiry.

Then map reuse. The password in that log almost certainly opens a supplier portal, a legacy application nobody has decommissioned, and several personal accounts that will be used to reset the corporate ones. The NCSC's password guidance is the sensible anchor for the policy conversation that follows.

When a Credential Alert Becomes an Asset Discovery Finding

Read the URL fields properly and you will find login pages you did not know were live: a staging subdomain, a supplier extranet from a project that ended in 2021, an old webmail interface still resolving. Attackers found those blind spots by reading the same logs. Feeding those URLs into external asset discovery turns a single credential alert into unknown asset discovery, and decommissioning the forgotten portal reduces future risk in a way the reset never will.

Separating Real Exposure From Noise in Leaked Credential Data

A large share of "new"dumps are recycled corpora restitched and rebranded. The tells are consistent: no system information files, uniform formatting across every record, no capture timestamps, and email domains distributed far too evenly to have come from real infections. Genuine stealer output is messy, inconsistent between families, and carries device context.

Deduplication against a historic leaked-credential database is the difference between an alert queue nobody opens and a list of ten accounts that genuinely need action this morning. Skip it and your team spends three days resetting credentials remediated two years ago, then quietly stops trusting the feed. That loss of trust is the real damage.

Classify records before you route them. An employee identity goes to identity and access management. A customer record goes to your data protection lead and possibly to the ICO clock. A supplier record goes to your third-party risk process. Risk-score by person too: a finance director with card autofill and a treasury portal in the URL field is not the same incident as a contractor whose only corporate entry is a training platform. OSINT and dark web monitoring across forums, marketplaces and Telegram channels is what makes that classification possible at speed.

One-off scans do not work here, because logs surface weeks or months after infection. The realistic sequence: a cracked media tool is installed at home on a Tuesday, the log is bundled into a subscription service within a week, and the VPN URL inside it is queried by an initial access broker six weeks later, long after the machine was cleaned and forgotten.

Building a Standing Programme Around Infostealer Exposure

Credential findings belong inside a continuous threat exposure management cycle, not in a ticket queue reviewed at the Thursday meeting. Scope, discover, prioritise, validate, mobilise, then repeat, with stealer log findings feeding the discovery and prioritisation stages directly.

Route alerts into Slack, Teams, Jira or your SIEM so that reset and session revocation happen in hours. Measure time to revoke, not time to acknowledge.

Extend the same thinking to suppliers. A managed service provider's infected engineer, holding delegated admin into your tenant, is your incident. ISO 27001 certification tells you a supplier has a management system; it does not tell you their engineers' laptops are clean. Ask instead whether they monitor their own workforce for credential exposure and how fast they revoke sessions. Our partner programme exists partly because MSPs need this visibility across their own client estates.

Management reporting should show exposed identities over time, median time to revoke, repeat offenders, and the applications that keep reappearing in URL fields. That last metric is the one that drives real change, because it points at the portal you should retire.

If you have no baseline at all, start there. A free DarkInvader account gives you an initial view of credential exposure and external footprint before you commit to continuous coverage, and you can compare that against ongoing monitoring options once you know what is actually out there.

Frequently Asked Questions

What are stealer logs and how do they differ from a data breach?

Stealer logs are the harvested output of infostealer malware running on an individual device, containing saved browser passwords, cookies, autofill data and a system information file describing the machine. A data breach is a compromise of an organisation's systems. The key difference for defenders is that a log records the exact URL each credential was entered on, so you learn precisely which of your applications is exposed.

How do I check if my company appears in stealer logs?

Have I Been Pwned supports domain-level searching of ingested stealer log corpora for verified domain owners, which is a reasonable free starting point. For continuous coverage you need monitoring across criminal forums, marketplaces and Telegram channels, with deduplication against historic data so you are not reacting to recycled records.

Does changing passwords remove the risk from a stealer log?

No. Session cookies and refresh tokens captured in the log allow an attacker to resume an authenticated session without ever entering the password, bypassing MFA. You must force a global session revocation across your identity provider and any application managing its own sessions, then re-check MFA registrations and OAuth grants.

How long after an infostealer infection do logs usually appear for sale?

There is no fixed interval, and anyone quoting one precisely is guessing. In practice logs commonly reach subscription services within days to weeks of capture, then circulate and get resold for months or years afterwards, which is why detection frequently happens long after the malware has been removed.

What should we do when the infected device is a personal, unmanaged laptop?

Assume every credential and session stored in that browser is compromised and act on the identity side: reset, revoke all sessions, re-enrol MFA and review activity since the capture date. You cannot verify remediation on a device you do not control, so restrict that identity's access to compliant devices through Conditional Access until the user can work from managed equipment.