Stealer logs are the easiest path to a data breach
Commodity malware on one personal computer now yields more usable access than most database breaches. What an infostealer takes in a single sweep, how the archive is packaged and sold, and why rotating a password does not close it.
A breach used to mean a database. Someone took the user table, it circulated, and the questions afterwards were which service lost it and how many rows went with it. Stealer logs do not fit that shape. The material comes off one person's computer rather than out of one company's database, and it arrives complete: every password the browser had saved, the cookies for whatever sessions were open, the card details sitting in autofill, and a fingerprint of the machine itself. Nobody had to breach a company to produce it. Somebody had to install a game cheat.
The economics are the whole argument. A subscription to commodity stealer malware costs less than a seat of business software, the operator does not have to write any of it, and the target is not the company: it is one laptop belonging to one person who keeps work credentials in the same browser profile as everything else. Attacking a company directly means finding a way in, defeating its controls, and staying quiet inside a monitored network. Buying a log means signing in. Incident response organised around the question "which service leaked" never sees the second path, because no service leaked.
What an infostealer is
An infostealer is commodity malware with one job: make a single sweep of a machine and leave. It is not ransomware and it is not trying to persist. There is no encryption, no ransom note, no dwell time to detect. The run takes seconds, the output is uploaded, and the process exits.
It is also a product. Families are rented by subscription, which is why so many exist and why the person operating one is rarely the person who wrote it. Lumma, one of the most widely deployed families of recent years, was advertised from roughly $250 a month for basic access, with higher tiers up to an all-inclusive licence that let a buyer resell it. Microsoft's own analysis of StealC and Amadey describes the same division of labour: one crew builds and sells the stealer, another crew sells the distribution, and a third buys the output. The skill barrier sits at the level of a credit card.
How it reaches the machine
Delivery is unglamorous and it has not needed to change. Cracked applications and keygens, game cheats, and fake installers for real software are the constants. Microsoft records SEO poisoning and malicious advertising as the most common route for that traffic: a page or a sponsored result that outranks the thing it imitates, so the victim installs a stealer while looking for a legitimate tool. Campaigns through 2026 have impersonated download pages for utilities as ordinary as archive tools, text editors and language runtimes.
The newer pattern removes the download entirely. A page presents what looks like a verification step or an error, and the fix is a command the visitor is told to paste into the Windows Run box or a terminal. Proofpoint, which named the technique ClickFix, has tracked campaigns using it to deliver Lumma and several other payloads. Nothing suspicious is downloaded, because the pasted command uses tools that already ship signed on the machine to fetch the payload itself.
Delivery does not need to be commodity either. In 2024 Ryan Mitchell Kramer published a program on GitHub that claimed to generate AI art and instead handed him access to any machine that ran it. A Disney employee ran it on a personal computer that held credentials for both personal and work accounts, including Slack. Kramer used them to reach non-public internal channels and take roughly 1.1 terabytes of data, then posed as a member of a hacktivist group he invented, called NullBulge, to extort the victim before publishing the archive along with the victim's bank and medical records. He agreed to plead guilty in May 2025. That was a bespoke remote access tool rather than a rented stealer, which makes the shape of it more interesting, not less: the delivery lure and the payoff were identical to a commodity infection. A personal machine, a fake tool, a saved credential store, corporate access.
What one sweep takes
In a single pass a stealer copies the browser credential store, the session cookies, the autofill entries, saved cards, cryptocurrency wallet files and browser extension wallets, tokens for desktop chat and game clients, and a fingerprint of the machine: operating system, hardware, locale, installed software, public address, sometimes a screenshot of whatever was on screen.
The part worth sitting with is that this is not one password from one site. It is everything the browser was holding, at one instant, from one person who was probably signed into work and everything else at the same time.
The archive, and where it goes
The sweep writes its output as an archive, one folder per victim, laid out much the same way every time: a passwords file, a directory of cookies, an autofill dump, a system information file. That bundle is the stealer log. The term names a packaging format, not a kind of incident, and that distinction matters when reading a claim about one. A log is evidence that a machine was swept. It is not by itself evidence that any particular company was attacked.
Logs are exfiltrated to a bot, collected in bulk, and then distributed. In practice that means Telegram: channels posting free archives to advertise a paid tier, subscription clouds selling the rest, and forums where the same material is resold again. Some of it gets flattened into combolists, reduced to email and password lines with the machine context thrown away, which is how one log ends up feeding several markets at different prices.
That provenance is worth keeping rather than discarding. Every row on our device surface carries the platform it was distributed on, the channel or bot that carried it, the archive filename exactly as whoever posted it named the file, the date it was posted, and the date it reached the index.
A log is not a bigger breach row
A breach row is one service, one identifier, one moment, and it is usually a password that has to be cracked and then replayed against other sites in the hope that something lands. A log is one machine and every credential the browser had, plus the live state around them.
Session cookies are the reason the two are not comparable. A valid session cookie can be loaded into another browser and replayed, and the site treats the request as an already authenticated session. It does not ask for the password, so rotating the password does not close it, and it does not re-run the second factor, because the second factor was satisfied when the session was created. Multi-factor authentication protects the act of signing in. Cookie replay skips signing in.
This is why the usual advice, change your password, is a partial answer at best. Password rotation addresses one row of one file in the archive. It does nothing about the cookies, nothing about the refresh and client tokens, and nothing about the wallet files. Closing a log means invalidating sessions, not just changing secrets.
The corporate path is the personal machine
One person, one browser profile, work credentials saved next to a games launcher. That is the entire mechanism, and its consequences scale badly.
Vercel disclosed in April 2026 that an attacker had reached internal systems, and traced the entry to Context.ai, a third-party AI tool. In Vercel's account, the attacker used access gained through that tool to take over an employee's Google Workspace account, then reached Vercel environments and environment variables that had not been marked sensitive. Context.ai's own notice, reported by The Hacker News, says Vercel was not a customer at all: a Vercel employee had signed up for its office suite using their enterprise account and granted broad permissions in the process. Hudson Rock reported that a Context.ai employee had been compromised by Lumma Stealer in February 2026, that the harvested credentials included Google Workspace along with keys for Supabase, Datadog and Authkit, and that the logs showed the same user searching for and downloading Roblox auto-farm scripts. An actor using the ShinyHunters name claimed the theft, published a file of 580 employee records and discussed a $2 million ransom; BleepingComputer could not independently verify the file, and Google Threat Intelligence assessed the actor as likely an imposter borrowing an established name.
Trace that backwards. A game cheat on one developer's machine at a small vendor, and the eventual subject of the incident is a company that was not even that vendor's customer.
The same mechanism reaches infrastructure. Hudson Rock traced the credential behind the January 2024 Orange Spain outage to a Raccoon-type infection on an employee's machine dated to September 2023. On 3 January 2024 an actor going by Snow used that stored RIPE portal login, protected by the password ripeadmin and no second factor, to reassign authority over Orange Spain's IP prefixes to an unrelated autonomous system and enable RPKI validation against it, which stopped the company's own address space being announced correctly and broke routing for roughly ninety minutes. One saved credential on one desktop, and a national carrier lost control of its routing.
Dates on a log are collection dates
Two honest limits, because they change how a record should be read.
There is no strain attribution. The provider carries no malware family attribution, so nothing on a device record here identifies which stealer produced a capture, and guessing at one would be inventing evidence.
There is also no infection date. Every date on a record is a collection date: when the archive was posted, and when it reached the index. A machine can be swept months before its log is ever published, and archives are reposted and recompiled long after that. A record dated last week is not evidence of a compromise last week.
The gap runs the other way too, and it is long. In Mandiant's account of the campaign it tracks as UNC5537, credentials pulled from infostealer logs were used against Snowflake customer tenants that had not enforced multi-factor authentication, with roughly 165 organisations notified. At least 79.7% of the accounts the actor used had prior credential exposure, and the earliest infostealer infection date associated with a credential it used was November 2020, close to four years before it was spent. Mandiant found no evidence that Snowflake's own environment had been breached. Every incident traced back to a customer credential taken somewhere else.
What response has to change
Detection has to start at the log rather than at the intrusion. By the time there is an intrusion the useful window has already been spent, and that window is frequently measured in months. Appearance in a log is the event worth alerting on, not the login that eventually follows it.
Revocation has to replace rotation as the default action. A password reset against a stolen session is close to a no-op. The response to a log is invalidating every session for that identity, rotating the tokens the archive would have carried, and treating the machine as untrusted rather than cleaned.
Third-party risk now includes other people's household computers. A supplier's security programme says nothing about what one of its engineers installs at home on the machine where the work browser profile lives, and a permission that one employee granted to a small tool can carry a compromise into an organisation that never contracted with either party.
The question is no longer only which service leaked. It is which machines belonging to which people were swept, what those browsers were holding at the time, and which of those sessions is still valid.