A stealer log hit for your domain usually arrives with almost no context: an email address, a password, a URL, maybe a folder name with a date in it. Within a few hours you need to answer three questions. Is this a live infection or a recycled record from 2021? Which device is affected, and do you even own it? And what, exactly, do you revoke?
Plenty of pages explain what infostealer malware is and list the top families. Far fewer tell a security team what to do on the Tuesday morning the alert lands. This is that runbook, built around the two things that decide whether your response actually works: stolen session cookies, and infected machines outside your control.
A log is not a line in a spreadsheet. It is a folder harvested from one infected machine, and the credential triplet (URL, username, password) is only the part everyone looks at first. A typical package also carries browser cookies and session tokens, autofill data including addresses and partial card details, crypto wallet files, a system fingerprint (hostname, username, OS build, local IP, installed software, sometimes a hardware ID) and, from several families, a screenshot of the desktop at the moment of collection.
Read the whole folder before you read the password. The hostname tells you whether this is a domain-joined corporate laptop or someone's home PC called DESKTOP-4K7J2. The installed software list tells you whether an EDR agent was present. And the URL list, often 200 or 300 entries long, tells you every site that browser profile ever saved a credential for.
This is the part most teams skip. An infected employee browser records the internal portals it visited: the staging environment on a subdomain nobody decommissioned, the legacy VPN gateway that was supposed to be switched off after the migration, the vendor admin panel with a shared login. Security teams regularly find assets in a stealer log that never appeared in the CMDB.
Treat the log as intelligence about your external footprint, not just about one password. If a URL in that list resolves to something live that you cannot account for, you have a second finding, and it is often the more serious one. Systematic external asset discovery and mapping exists precisely because this kind of shadow IT only surfaces by accident otherwise.
Conflating these three wastes response time, and it happens constantly.
Only the third one obliges you to think about rebuilding hardware. Our broader guide to triaging leaked credentials found on the dark web covers the first two cases in more detail.
Logs move through closed channels far more than indexed marketplaces. Free "clouds of logs"get dumped into public Telegram channels as bulk archives, usually stale and heavily recycled, while the fresher material sits behind paid subscriptions, invite-only forums and per-log sales where a buyer pays for a specific corporate hostname. Named families you will see referenced in vendor reporting and in the folder structure itself include Lumma (LummaC2), RedLine, Vidar, StealC and Raccoon, each with its own log layout and naming conventions.
Here is the part that decides outcomes. Stealers exfiltrate session cookies alongside passwords. An attacker who imports a valid cookie into their own browser resumes an already authenticated session, which means no password prompt and no MFA challenge. Your reset changed a credential the attacker no longer needs.
Session revocation is a separate, explicit step. Not a footnote to the password reset. If your runbook has one line that says "rotate credentials", it is incomplete.
If the user saved passwords in Chrome or Edge, assume the whole vault is gone, not just the credential in the alert. That includes personal banking, the shared team logins nobody admits to, and the password for the password manager if it was saved in the browser. Pull the full URL list and rotate against it rather than against the single line you were sent.
Revoking sessions in Entra ID or Okta does not universally kill downstream sessions. Some SaaS applications maintain long-lived tokens independently, and revocation is a manual action in an admin console that only one person knows how to reach. Build that list now, before an incident: which of your top twenty applications honour a global sign-out, which need a separate revocation, and what the token lifetime is in each. That inventory takes an afternoon and saves you hours you will not have later.
Forty-eight hours is a deliberate window. UK GDPR Article 33 gives you 72 hours to notify the ICO where a personal data breach is likely to result in risk to individuals, so a two-day triage leaves room to make the notification decision on evidence rather than on nerves.
Verify the record is genuine and not a reformatted combolist entry. Extract the hostname, the full URL list and the log's collection metadata. Then classify the identity: internal employee, external personal account using a corporate address, contractor, or supplier staff. That classification decides everything downstream, because "rebuild the endpoint"is only available to you for the first category.
Freshness is judged on several weak signals rather than one strong one. Check the malware family against its known activity window (RedLine and META infrastructure was disrupted in Operation Magnus, announced by the Dutch National Police in October 2024, and Microsoft's Digital Crimes Unit announced action against Lumma infrastructure in May 2025, so attribution to a disrupted family points towards older collection). Compare the password against your own change records: if the account's password last changed in 2023 and the log shows the current one, that is a live problem. Check whether the URLs match your estate as it exists now or as it existed three platform migrations ago.
Isolate the device if you own it. Force session revocation at the identity provider and in the applications that need it individually. Then hunt for follow-on activity: new inbox rules, forwarding to external addresses, OAuth application grants the user did not approve, registered MFA methods, and changes to recovery email or phone. Inbox rules are the classic tell.
A worked example that lands in UK finance teams regularly: a finance assistant's home laptop picks up an infostealer, the log contains a live Microsoft 365 session cookie, and the attacker signs in without ever meeting an MFA prompt. Within the hour there is a rule moving supplier replies into a rarely used folder, and the invoice fraud runs quietly for a fortnight. The password was never the weak point.
Search for other credentials associated with the same hostname or machine ID, because one infected device usually produces more than one record. Then write the management update: what was exposed, what has been revoked, what remains outside your control, and a clear recommendation on ICO notification. Two paragraphs and a table beats a forensic report nobody reads.
Raw hit counts overstate exposure badly. The same records cycle through aggregator posts, Telegram dumps and public breach additions for years. Have I Been Pwned has ingested several large stealer log corpora, including a January 2025 addition covering around 71 million email addresses, which is why an HIBP alert on its own rarely tells you whether an infection is current. It tells you the address appeared in a corpus. Nothing more.
Deduplication and normalisation are what turn a number into intelligence. Log formats differ between families, field ordering is inconsistent, encoding is a mess, and a meaningful share of records are junk (masked passwords, truncated fields, test entries). AI-assisted parsing that clusters duplicates and strips noise before an analyst opens the file is the difference between "we have 4,000 exposed credentials"and "we have nine that matter this week".
The false negatives cut the other way. Plenty of logs are sold privately and never reach a public channel, so an empty result is not a clean bill of health.
Personal and family devices are the hardest category. No agent, no legal right to image the machine, and often a genuine business reason the person was checking webmail from home. Your only real controls are on your side: revoke, restrict, and reconsider whether that access should exist on unmanaged hardware at all.
Contractors, agency staff and supplier personnel show up under your domain or against your applications while sitting outside your authority. Classify them at triage, escalate to the supplier in writing, and revoke sessions on your side the same day rather than waiting for their reply. The supplier lessons from the Harrods breach apply directly here, and ISO 27001 accreditation tracking gives you a defensible way to evidence third-party diligence.
Executive exposure is disproportionate and deserves its own treatment. One infected home laptop belonging to a director or their assistant can surface calendar, travel plans, approval workflows and finance sign-off routines, which is why per-person risk scoring beats treating every hit as equal. We cover the selection question in detail in our piece on who to include in VIP monitoring.
Monitoring only corporate email addresses catches a fraction of the problem. Coverage needs to include domain and subdomain patterns, application URLs, named executives and key supplier domains, because the URL field is often where your exposure shows up first.
Watch the closed channels too. Much of the trade happens in private Telegram groups and invite-only forums rather than indexed marketplaces, so crawling websites alone will miss fresh corpora by weeks or months; our practical guide to monitoring Telegram for threats goes further on that. Pair it with continuous OSINT monitoring so findings route into Slack, Teams, Jira, your SIEM or the ticket queue your analysts already work from. Triage should start in minutes, not at the next review meeting.
Report the trend rather than the raw count. Weekly change summaries, per-person risk and supplier exposure give a board something to act on. A cumulative total of stealer logs mentioning your domain gives them a number that only ever goes up, and teaches everyone to ignore it.
A stealer log is the output of infostealer malware running on one endpoint, containing saved credentials, browser cookies, autofill data and a system fingerprint from that machine. A breach dump comes from a compromised service and exposes credentials for that service only. The practical difference is that a stealer log implies an infected device and live session material, so it demands endpoint containment as well as credential rotation.
No, not on its own. Stolen session cookies allow an attacker to resume an authenticated session and bypass MFA entirely, so a reset leaves them logged in. Revoke all active sessions at the identity provider and in any SaaS application holding its own long-lived token, then re-enrol MFA factors and review registered authentication methods.
Cross-check several signals rather than trusting one. Compare the exposed password against your own password change records, check whether the URLs reflect your current estate or a decommissioned one, and consider the malware family's known activity window. If the same record has appeared repeatedly in aggregator posts and public breach additions over several years, treat it as recycled until something contradicts that.
Work the controls you own. Revoke sessions and tokens for every corporate service that device touched, rotate the affected credentials, re-enrol MFA, and check for inbox rules and OAuth grants. You cannot compel a rebuild of personal hardware in most circumstances, so the follow-up conversation should cover whether that access belongs on unmanaged devices at all.
They circulate through Telegram channels, invite-only forums, subscription services and per-log sales, with much of the fresher material never reaching an indexed site. Removal is not realistic once a corpus is distributed, since copies replicate across channels immediately. The workable response is fast detection, revocation and continuous monitoring of your external attack surface, which is what DarkInvader's external attack surface management platform is built to provide.
Unlock full visibility of your external attack surface with DarkInvader’s continuous, real-time monitoring. Create your free account to discover unknown assets, detect emerging risks and stay ahead of potential threats before attackers can exploit them.
Create My Free Account
Platform 7D, New Station Street, Leeds,
LS1 4BT, United Kingdom
Mon-Fri, 9:00-17:00
Contact:
sales@darkinvader.io
+44 (0)1138805336
Last updated: 14 August 2026
©2026 DarkInvader, All Rights Reserved
