What a stealer log contains
An infostealer has a narrow job: run once, collect everything the machine can use to authenticate, send it out, and stop. It usually arrives through cracked software, malicious ads, fake installers or phishing, not through a sophisticated intrusion. Microsoft's description of Lumma is typical: it spread through phishing emails and malicious online advertising, often impersonating trusted brands, and took passwords, card details, bank account data and cryptocurrency wallets. Our explainer on infostealer malware covers how the malware itself works.
The output is a stealer log: one folder per infected machine. The layout varies by family, but most contain the same parts.
A passwords file. Every login the browser had saved, as a list of website, username and password, usually in plaintext.
A cookies folder. The browser's session cookies, which can let an attacker continue a signed-in session without the password at all. Session cookie theft explains why these are often worth more than the passwords.
Autofill data. Names, addresses, phone numbers and sometimes card details the browser was asked to remember.
A system profile. Hostname, operating system, IP address, installed software and antivirus, often a screenshot, and the date of infection.
Logs are then sold or shared in bulk, in dark web markets and in Telegram channels.
Why breach checks miss stealer logs
A breach notification service indexes databases that companies have lost. It answers the question "which services leaked an account I hold?" A stealer log answers a different one: "which devices that held my logins were infected?" Nothing at your company has to be breached for your credentials to appear.
The device is often not yours either. Verizon's 2025 Data Breach Investigations Report found that only 30% of the systems in the infostealer logs it analysed were enterprise-licensed devices, and that 46% of the systems with corporate logins in them were non-managed. That is the contractor's laptop, the family computer, the personal phone with the work email on it. Your endpoint tools never saw those infections, and a breach check will not see them either.
How stealer log search works
Searching stealer logs means matching your identifiers against parsed records, and there are two directions to search in.
By email domain. Find every record where the username is an address at your domain. This finds your staff, wherever they were logging in.
By website domain. Find every record where the saved login was for a site you run: your VPN, your admin panel, your customer portal. This finds people who log in to your systems with personal addresses, including contractors and customers, which an email search misses.
Have I Been Pwned's API is a useful reference point because it documents both directions plainly. It stores the website domain and email address from each stealer log entry, offers lookups by email, by email domain and by website domain, and requires a Pro subscription and a verified domain for all of them.
How to read a stealer log report
A usable report entry answers five questions. Our guide to reading a credential exposure report goes through each in detail.
Whose credential is it? The account, and whether it belongs to staff, a contractor or a customer.
For which system? The website domain the login was saved for. A login for your single sign-on provider matters more than one for a newsletter.
Is it still usable? Whether a password was captured, whether session cookies were present, and whether those sessions could still be live.
From which machine, and when? The infection date and the device profile. Several records with the same device identifier mean one infection, not several incidents.
Where did it surface, and when? The source and the date it was found. The gap between infection and discovery tells you how long the credential has been exposed.
What checkers and APIs can and cannot show
Free and low-cost checkers are a reasonable first look, but know their limits before treating a clean result as an all clear.
Have I Been Pwned is open about its own. Its stealer log API returns no passwords, stores only website domains rather than full URLs, and returns nothing for entries without a website domain it can parse. Those are sensible privacy choices, and they mean the service can tell you that an address was captured but not whether the captured password still works.
Every service also sees only what it collects and parses. Different vantage points produce very different numbers. Microsoft counted over 394,000 Windows computers infected by Lumma between 16 March and 16 May 2025. Over almost the same weeks, from 20 March to 20 May 2025, Alphatechs observed 881,387 compromised systems across all stealer families, 242,091 of them attributed to Lumma. Neither number is wrong. They come from different collection points, which is the point: coverage is the product.
What monitoring adds to a one-off search
A search tells you what was exposed up to today. Monitoring is the standing version, and it involves four things.
Collection. Pulling new logs from markets, forums and channels as they are posted, not when they are eventually aggregated and resold.
Matching. Searching each new log by email domain and by website domain, so contractor and customer logins are found as well as staff ones.
Context. Establishing which credential, for which system, from which machine, and when.
Alerting. Telling someone in time to act, with enough detail to act without further research.
The scale, in measured numbers
Alphatechs' analysis of the Lumma disruption window gives a sense of the volume. Across the 60 days from 20 March to 20 May 2025 it recorded 881,387 compromised systems, 26,758 of them infected on the busiest single day, 11 May 2025. It also recorded 786,041 antivirus installations across those compromised systems. Endpoint protection was widely present, and infections happened anyway, which is why prevention cannot replace knowing what has already left.
Disruption does not end the problem either. In our own data from Albania, RedLine's share of labelled infostealer detections rose from 52% to 88% twelve to eighteen months after Operation Magnus seized its infrastructure. Our Remus stealer research recorded 63,770 detections of a single family in eight days.
In one recent month of SphereTI data for the United States, 10,100 records were counted by malware family. Two thirds of them (6,620) carried no family label. Of the 3,480 that did, RedLine accounted for 1,521, Remus for 1,159 and Meta for 675. RedLine and Meta, the two families Operation Magnus targeted in October 2024, still made up 2,196 of the labelled total, well over a year after the takedown.
What to do when your domain appears
Speed matters more than thoroughness in the first hour, because the credential is already in circulation. In order:
Revoke sessions first. Invalidate active sessions and tokens for the affected accounts. This is the step most often skipped, and the one that closes the cookie. What survives a password reset lists what a reset alone leaves open.
Then rotate the credential, and any other credential reused alongside it.
Treat the device as compromised, not just the account. The log tells you which machine it came from, and if it is a personal device, the owner needs to know.
Check the rest of the log. One infection rarely exposes one account. The same file may hold the VPN login, the admin panel and the cloud console.
Look for use. Check sign-in logs for the affected accounts from the infection date onwards, since an attacker with the log may already have tried. If you are weighing up services to do this continuously, our guide to evaluating dark web monitoring providers sets out what to ask.
SphereTI monitors credential exposure across breach data, infostealer logs and credential lists, and reports which of your domains appear, where the credential came from and when it surfaced. Request a free exposure report. No password is needed.