An infostealer does not break anything. No encryption, no lateral movement, no persistence. It runs once on one laptop, copies what the browser already remembered, and leaves, often in under a minute. And the file it produces is worth more to the criminal economy than the access it had.
That file is called a log, and it is the reason this category matters far more than its noise level suggests. Flare, analysing 18.7 million infostealer logs from 2025, found that 2.05 million of them exposed enterprise identity credentials, and that 1.17 million carried both credentials and session cookies for the same account.
This is a technical breakdown for defenders and analysts, and it is worth being precise about the pictures in it. Every figure here is either a diagram drawn for this article or a generated illustration, and none of them is a screenshot of real criminal infrastructure, which is why the sample values in the log recreation are invented. The article describes what these payloads collect rather than reproducing anything runnable. Let me walk through how a log is made, dissect two campaigns that show why takedowns and browser hardening have not settled the problem, and cover exactly what to do when one of your own endpoints turns up in a log.
How a stealer log is made. The malware is disposable, and the log it produces is the thing that gets sold.
What an Infostealer Is, and Why It Works
An infostealer is malware with one job: read the credentials, cookies and tokens a machine has already saved, package them, and send them somewhere else. It is not a backdoor and it is not a remote access tool. Most families do not install persistence at all, because persistence is a detection risk and the data is only worth taking once.
The category is a service business rather than a hobby. Malpedia records Lumma Stealer as available through a malware-as-a-service model on Russian-speaking forums since at least August 2022, and Stealc as offered the same way since January 2023, assembled by borrowing from Vidar, Raccoon, Mars and Redline. Vidar itself is a fork of Arkei, and Malpedia notes it as one of the first stealers to go after two-factor authentication software.
Figure 1: The reason infostealer infections go unreported is visible in the shape of the crime. Nothing is taken away, so nothing is missing, and the user notices no change at all. What leaves the machine is a copy, and the victim usually learns about it from an external notification months later rather than from anything they saw happen.
What makes the technique work is that the theft is indistinguishable from ordinary use. Reading a browser profile is something a browser does constantly, and the files involved belong to the user. MITRE tracks the credential half of this as Credentials from Web Browsers, T1555.003, and the cookie half as Steal Web Session Cookie, T1539, and both come down to reading files the operating system already considers the user's own.
The takeaway for defenders is that the incident is finished before any alert could be triaged, so the response has to be about the credentials rather than about the machine.
The machine is the crime scene. The credentials are the crime.
The Anatomy of a Stealer Log
Strip away the family name and every infostealer runs the same six-step chain shown in the diagram above. It starts with delivery, usually cracked software, a malvertised download, or a paste-and-run lure of the kind used in ClickFix campaigns. Then execution, once, often entirely in memory. Then collection, which is the step that defines the category.
Collection is broad by design.
Saved browser logins, cookies and session tokens, autofill records, cryptocurrency wallet files, messaging application sessions, and a snapshot of the machine itself all go into the same bundle.
Exfiltration and exit is the load-bearing step, and it is the one highlighted in the diagram. Everything leaves in a single burst, and many families then remove themselves. Nothing on the machine is missing afterwards, which is precisely why almost nobody reports it. Then comes packaging, where the raw output is normalised into a structured log and sorted by domain, country and apparent account value, and finally resale, where the log enters a market.
Figure 2: The log is the unit of analysis, not the malware. A defender reading one of these sees why the standard response fails: the second file is fixed by a password reset, and the third file is not, because a session cookie proves an authentication that already happened. Sample values here are invented and the layout is drawn, not captured, but the four-part shape is the shape of the thing.
That structure is why the log matters more than the sample.
A log is not a password list. It is a session inventory.
Campaign 1: The Lumma Takedown That Did Not Hold
The largest coordinated action ever taken against an infostealer happened in May 2025, and the family it targeted was operating again within a year. Microsoft, working with Europol, the United States Department of Justice and Japan's Cybercrime Control Center, moved against approximately 2,300 domains that formed the backbone of Lumma's infrastructure, with more than 1,300 seized by or transferred to Microsoft and 300 actioned by law enforcement.
The scale of what was disrupted was documented at the same time. Microsoft identified over 394,000 infected Windows computers globally between 16 March 2025 and 16 May 2025, in the two months immediately preceding the operation.
Figure 3: Seizing infrastructure removes the premises, not the trade. The Lumma operation took down thousands of domains and the family was documented running again on new loaders within months, because what law enforcement can reach is the hosting, while the customer base, the builder and the operator relationships survive intact and simply relocate.
Nine months later the picture had changed back. Bitdefender, in an investigation covering 12 December to 12 January, reported that LummaStealer operations continued despite the 2025 disruption, and that the family was arriving through Rugmi, DonutLoader and, more recently, CastleLoader. Active infections were observed mostly in India, with further activity across the United States and Europe.
Read that pair of findings together and the lesson is about what a takedown actually removes. Domains are rentable, loaders are interchangeable, and the customer relationships that make a service business work are not held on any server that can be seized.
Disruption buys time; it does not retire a business model.
Campaign 2: The Long Fight Over Chrome's Cookie Encryption
The second campaign has no single operator, and it has been running since July 2024. Kaspersky dates the start of it precisely: Google introduced App-Bound Encryption in July 2024 with the release of Chrome version 127, tying the encryption of stored browser data to the browser application itself so that another process could not simply read the cookie database.
The response was immediate. Kaspersky records that just a couple of months after the announcement, many infostealer developers claimed they had already bypassed the protection, and the claims turned out to be broadly accurate.
Figure 4: Working out how a stealer defeats a browser protection is bench work on an isolated network, not a query against a feed. The disconnected cable is the point: a family that phones home in one burst and then removes itself has to be observed live, which is why the public timeline of these bypasses is written by a handful of research teams rather than by everyone who is affected.
The most recent turn in that fight is worth understanding because it explains why the protection is so hard to hold. In March 2026, Kaspersky reports, news broke of a stealer named VoidStealer that attaches itself to the browser process as a debugger and pauses execution at the exact moment the master key is sitting in memory in plaintext, then reads the key directly out of memory. The encryption is not broken. The key is simply collected at the one instant the browser has to have it in the clear.
That shape recurs across this whole category, and it is the reason to be careful about how browser hardening is described to a board.
Browser hardening raises the cost of the theft; it does not remove the target.
Why Infostealers Beat a Modern Security Stack
The uncomfortable finding is that having the tools installed is not the same as being covered. In its 2026 Identity Exposure Report, SpyCloud reported that 40 percent of infections occurred on endpoints protected by EDR or antivirus tools, drawn from the 13.2 million infostealer infections in its recaptured data for 2025.
Three design choices explain most of that. The malware runs once rather than persisting, which removes the behaviour most endpoint tooling is tuned to catch. It reads files the user legitimately owns, using operations the browser itself performs constantly. And it finishes and exits inside a window measured in seconds, well below the time any human triage process operates in.
Figure 5: A managed fleet is what full endpoint coverage physically looks like, and coverage of this kind is exactly what a large share of infostealer victims already had. The gap is not deployment. It is that a single run of a legitimate file read, finishing in seconds and leaving nothing behind, does not resemble the behaviour these agents were built to interrupt.
Multi-factor authentication does not close the gap either, and the reason is structural rather than a failing of any particular implementation. Multi-factor authentication protects the moment of authentication. A session cookie is the receipt for an authentication that already succeeded, so replaying one asks no question the second factor was designed to answer.
There is one rule that decides whether an infostealer response actually works, and it is worth teaching until it is reflexive:
A password reset does not end an infostealer incident. Until every session token for that identity is revoked, the attacker is still signed in.
Reinforce it with the practical habits: rotate the credential, revoke the sessions, then check what else was in the same log before deciding the case is closed.
The control that fails here is not the endpoint. It is the identity.
The Numbers Do Not Agree, and That Matters
Three organizations published infostealer measurements covering overlapping periods, and they do not tell the same story. From 18.7 million logs collected during 2025, Flare reported a 20 percent year over year decline in total infostealer infections while enterprise identity exposure rose, with more than one in ten infections already carrying enterprise single sign-on or identity provider credentials.
SpyCloud counted 13.2 million infostealer infections in its own recaptured data for 2025, exposing 642.4 million credentials, an average of 50 credentials per infection, alongside 8.6 billion cookies. Flashpoint, covering 1 January to 30 June 2026, counted 1.7 billion credentials harvested across 7.4 million compromised systems.
Those three sets do not add up, and they were never meant to. Each is one company's view of the collections it can reach, over a different window, counting a different unit. A credential is not a victim, a log is not a person, and the same stolen data is resold and recompiled repeatedly across markets, which is why SpyCloud noted as far back as May 2023 that combolists carry high levels of duplicate records and a low percentage of validity.
Figure 6: Vendor counts of stolen credentials measure the collections each vendor can reach, not the population of victims. Adding them produces a bigger number and a worse estimate, because the same records circulate through several markets and are recompiled repeatedly. The useful practice is to cite one collector at a time and carry its window and its unit into the sentence.
There is a wider corrective in the same direction. The 2026 Verizon Data Breach Investigations Report, covering incidents between 1 November 2024 and 31 October 2025, found that 31 percent of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in. Infostealers are a large and growing supply of credentials. That is not the same claim as infostealers having taken over initial access, and the difference is the sort of thing a reader will check.
So cite the collector, the window, and the unit. Everything else is a headline.
From Log to Ransomware: How the Data Gets Used
A log is not the end of a transaction, it is the beginning of one. The value in it is concentrated in a small number of records, which is why Flare found Microsoft Entra ID appearing in 79 percent of the enterprise identity logs it examined: an identity provider credential is a key to everything behind it rather than to one application.
From there the path is a market, not a group. Logs are indexed and searched by domain in the log shops that operate across Telegram and dedicated marketplaces, the interesting corporate entries are picked out and validated, and validated access is sold on to initial access brokers who resell it to whoever needs a foothold, including ransomware-as-a-service affiliates.
Each step launders the origin. The affiliate who deploys the encryptor has usually never seen the infected laptop, does not know the user's name, and bought a working login from someone who bought it from someone else. That is what makes the timeline so hard to reconstruct after the fact, and why the credential is the only thread that runs the whole length of it.
By the time a ransom note appears, the credential behind it has usually been sold twice.
How to Defend Against Infostealers
Defending against a run-once, no-persistence thief takes two layers working together: shrinking what the browser has to hand over, and shortening the useful life of whatever does get taken. Neither layer works alone, and the second one is the one most organizations have not built.
On the practical side, the highest-value controls are well established:
- Revoke sessions, never just reset the password. A reset closes the door the log's second file opens and leaves the third file working. Session revocation across every connected application has to be part of the same automated action, not a follow-up ticket.
- Alert on any non-browser process reading a browser profile directory. Legitimate browsers read their own credential and cookie stores constantly. Almost nothing else has a reason to, which makes this one of the few high-signal detections available for this category.
- Treat a Chromium browser started with remote debugging by a non-browser parent as an incident. Kaspersky and other research teams have documented the debugging and memory-reading routes to decrypted cookies, and the launch itself is far more visible than the theft that follows.
- Bind sessions to the device and shorten token lifetimes at the identity provider. A cookie replayed from unfamiliar hardware should fail rather than succeed, and a shorter token life shrinks the window a sold log stays useful in.
- Monitor your own domains in stealer log data continuously. For most organizations this is the first external signal that anything happened, and treating it as a monitoring feed rather than an occasional check is what turns it into warning rather than post-mortem.
None of this assumes the endpoint held. Every control above assumes it did not, and that assumption is the one that consistently holds.
Indicators of Compromise
The indicators below are behavioral rather than infrastructural, and that is a deliberate editorial choice rather than an omission. Infostealer command-and-control infrastructure is disposable by design, rotates within days, and republishing live host names amplifies criminal infrastructure without giving a defender anything durable to detect on. Where you do handle real network indicators, defang them in written products so they cannot be clicked, in the form stealer-c2[.]example[.]invalid, and treat every one as illustrative and time-limited. The behaviors in this table age far more slowly than any domain will. Mapped to MITRE ATT&CK v19.2, checked on 2 September 2026.
| Signal | What to look for | Why it matters |
|---|---|---|
| Browser store access | A non-browser process reading a browser profile credential or cookie database | Only the browser has a routine reason to touch those files |
| Remote debugging launch | A Chromium browser started with debugging enabled by a parent that is not a browser | A documented route to decrypted cookies, and noisier than the theft |
| Run-once binary | A freshly written executable that runs briefly and deletes itself | Matches the no-persistence design of the whole category |
| Staged archive in temp | A small archive assembled in a user temporary path and then removed | The log is packaged locally before it leaves |
| Single large outbound POST | One burst of outbound data from a workstation to a recently first-seen host | Exfiltration here is one transfer, not a long beacon |
| Session used from new geography | An existing session token used from a new country with no new authentication event | Session replay produces no login to correlate against |
| Own domain in log data | Your email domain appearing in stealer log listings or indexes | Usually the earliest external warning an organization receives |
The last row is the one worth building a process around, because it is the only signal in the table that arrives without the endpoint having been in scope. Every other row requires you to have been watching the right machine at the right minute. That row only requires you to be watching the market.
What This Means for CTI Analysts
For a threat intelligence function, the strategic point about infostealers is that the unit of analysis is the log rather than the malware. Family names rotate, builders get rewritten, and takedowns remove hosting without removing customers, so tracking this by family produces a naming exercise. Tracking it by exposure produces a warning capability: which of your domains are appearing, which identity provider the credentials belong to, whether session cookies were included, and how old the log is. That last question decides urgency more reliably than the malware family ever will.
The judgment worth building is knowing what a log entry does and does not prove. It proves a browser on some machine held that credential at some point. It does not prove the machine belonged to your organization, that the credential still works, or that anyone has used it. An analyst who states those three limits alongside the finding produces something an identity team can act on. One who reports a raw count produces an alarm nobody can size.
This is exactly the kind of judgment CTI Academy's Hunter track builds through practice rather than memorization. LeakLens puts you inside leaked and stealer-log data, so checking whether your own domains are exposed and reading what an entry actually supports becomes a workflow you have run rather than a concept you have read, and the Financial Fraud Investigation course follows the same records downstream into where the money moves. Read the chain here, then go build the reflexes. To start, explore the Cyber Threat Intelligence learning path.
Research current as of 2026-09-02. Figures reflect the reporting periods named alongside them.
Frequently Asked Questions
What is infostealer malware?
Infostealer malware is a program that reads credentials, browser cookies, session tokens and wallet files already stored on a machine, packages them, and sends them to an operator. Most families run once and remove themselves rather than persisting. The output, called a stealer log, is then sold or traded, which is where the real damage begins.
What is a stealer log?
A stealer log is the structured output of one infostealer infection on one machine. It typically contains system details, saved browser logins, cookies and session tokens, autofill records and wallet data. Logs are sorted by domain and account value, then sold in bulk or searched individually by buyers looking for a specific organization.
What is the difference between an infostealer and a stealer log?
The infostealer is the malware that runs on the victim machine. The stealer log is the file it produces and the thing that actually gets traded. Removing the malware does not remove the log, which is already in someone else's hands, so incident response has to address the exposed credentials and sessions separately.
Do session cookies bypass MFA?
Yes, in effect. Multi-factor authentication protects the moment of authentication, while a session cookie is the receipt for an authentication that already succeeded. Replaying a stolen cookie asks no question the second factor was designed to answer. Flare found 1.17 million logs in 2025 carrying both enterprise credentials and session cookies.
Does a password reset remove an infostealer infection?
No. A password reset invalidates the stolen password and does nothing to a stolen session token, which continues to work until it is explicitly revoked or expires. A complete response rotates the credential, revokes every session for that identity across connected applications, and then reviews what else appeared in the same log.
Was Lumma Stealer shut down?
No. Microsoft and international partners moved against approximately 2,300 domains in May 2025 after identifying over 394,000 infected Windows computers between 16 March and 16 May 2025. Bitdefender reported in February 2026 that operations continued, with the family arriving through Rugmi, DonutLoader and CastleLoader.
How many credentials did infostealers steal in 2026?
Flashpoint counted 1.7 billion credentials harvested across 7.4 million compromised systems between 1 January and 30 June 2026. That figure measures one company's collection over six months, not a global total, and a credential is not a victim, since the same records are resold and recompiled across markets repeatedly.
Sources
- Flare: 2026 State of Enterprise Infostealer Identity Exposure
- SpyCloud: 2026 Identity Exposure Report
- Flashpoint: 2026 Global Threat Intelligence Report: Midyear Edition
- Microsoft: Disrupting Lumma Stealer: Microsoft leads global action against favored cybercrime tool
- Bitdefender: LummaStealer Is Getting a Second Life Alongside CastleLoader
- Kaspersky: How VoidStealer bypasses Chrome's protections to hijack sessions and steal data
- Verizon Business: 2026 Data Breach Investigations Report
- The MITRE Corporation: Steal Web Session Cookie, T1539, ATT&CK v19
- Fraunhofer FKIE: Malpedia family record, Lumma Stealer