Stealer logs are the easiest path to a data breach

A senior engineer at a small AI startup, on his personal computer, attempts to install a Roblox auto-farm script. Six weeks later, Vercel, the company behind Next.js and Turbopack and roughly six million weekly framework downloads, was being held for a $2 million ransom with 580 of its employee records exfiltrated and listed for sale on BreachForums.

The malware that did this? An infostealer that costs about $250 a month. The whole supply chain that produced that outcome is a few dollars and a credit card away from anyone with a grudge. That asymmetry is the thing this post is about.

For a long time, a "data breach" meant a SQL table. A million rows of hashed passwords lifted out of someone's production database, traded on a forum, eventually surfacing on RaidForums or BreachForums. That model still exists. It is not the most productive way attackers get into companies any more.

The most productive way is one socially engineered employee, one infected personal computer, and a stealer log. A stealer log is not itself a breach. It is the easiest, cheapest, and most reliable path to one. The next several pages walk through four cases that prove this is not a fluke.

What is actually inside a stealer log

Some vocabulary first, because the wider security press still uses "infostealer" loosely. Infostealers are commodity malware. The current heavyweight families, RedLine, Raccoon, Lumma, StealC, Vidar, Meta, sell as a service through Telegram and dedicated forums at roughly $50 to $500 per month depending on tier. The operator does not write the malware. They subscribe to it, point it at a delivery channel (cracked software, malicious GitHub repositories, fake game cheats, sponsored Google ads spoofing legitimate download pages), and collect the output.

The output, per victim, is a single zipped folder. That folder contains, at minimum:

• Every credential the browser ever saved, in cleartext.
• Every live session cookie for every site the user is logged into. Google, Microsoft 365, Slack, GitHub, AWS, Okta, Discord, Steam, banking portals, password managers.
• Autofill data: physical addresses, phone numbers, and full credit card details when the browser was allowed to save them.
• Crypto wallet files and seed phrases from common browser-extension wallets.
• FTP, SFTP, and VPN client configs. Discord, Telegram, and Steam tokens. Game launcher tokens.
• A list of every program installed on the machine, the operating system version, the timezone, the GPU model, the public IP, and the approximate geolocation.
• A screenshot of the desktop at the moment of harvest. Often more than one.

That is the artefact. It is the user's entire digital footprint at a single instant in time. What makes it dangerous, and what separates it from the old database-dump model, is that almost all of that data is live state. A password hash from a leaked database is something an attacker has to crack and then credential-stuff against a thousand other sites hoping to land one. A session cookie inside a stealer log is something the attacker pastes into a browser. They are now that employee. They are inside the employee's Slack, their Okta tile, their GitHub, their corporate admin panel, without ever needing the password and frequently without triggering MFA, because the session is already authenticated.

Operators rarely work the logs themselves. They sell in bulk on Telegram and forums, by the hundred or the thousand, sorted by harvested domain. The buyer searches the bundle for whichever credential is most valuable, walks in, takes what they want.

Archetype 1: The vendor of a vendor (Vercel / context.ai)

Vercel's April 2026 breach is the most current and most instructive example, because nothing about it was sophisticated. In late February 2026, a developer at a small AI productivity SaaS called context.ai downloaded a Roblox auto-farm script onto a personal machine. The download was Lumma stealer. The same machine was signed into the developer's corporate Google Workspace. InfoBreach captured the resulting log on 2026-02-27 at 05:42:49 UTC ( available to signed-in users here ); among the harvested credentials were the keys to context.ai's Google Workspace.

Here is where the supply chain unfolds. context.ai's product is itself an OAuth app that other companies install into their Google Workspaces to run AI tasks against Workspace data. Using the stolen Workspace credentials, the attacker compromised context.ai's OAuth application itself. That single takeover handed them a path into every Workspace that had authorised context.ai. Vercel later said the campaign potentially affected hundreds of users across many organisations; one of those users was a Vercel employee, who had installed context.ai in their own Workspace.

Through the compromised OAuth app, the attacker took over that Vercel employee's Google account, then moved laterally inside Vercel: into Linear, into internal deployment dashboards, and into Vercel's environment variable store. Variables that engineers had not marked as "sensitive" were enumerated in cleartext, and the information gleaned from them was used to escalate further. The attacker exfiltrated 580 Vercel employee records (names, emails, account status, activity timestamps), claimed access to source code, NPM tokens, and GitHub tokens, and demanded a $2 million ransom. The listing went up on BreachForums on April 19, 2026 under the name ShinyHunters, though the actual ShinyHunters group has denied involvement. Vercel CEO Guillermo Rauch described the attacker as "strikingly fast" and almost certainly AI-accelerated. Full timeline in Vercel's April 2026 security incident bulletin .

Read that chain again. Vercel was not phished. Vercel's identity provider was not breached. Vercel's code was not backdoored. A developer at a vendor of a vendor downloaded a cheat for a video game, on a personal computer, and six weeks later one of the most critical pieces of the JavaScript ecosystem was being ransomed for two million dollars. The only thing standing between this and a global NPM supply-chain attack was the attacker's preference to sell rather than weaponise.

If your threat model still ends at "the attacker has the password," you are modelling 2018. The attacker has the password, the MFA cookie, the device fingerprint, the saved Bitwarden vault, and a copy of every other site that user was logged into at the same time.

Archetype 2: Personal device, corporate Slack compromise (Disney / NullBulge)

The Disney internal Slack leak from 2024 is the same pattern in a more theatrical wrapper. In early 2024, Ryan Mitchell Kramer, a 25-year-old from Santa Clarita, California, posted a Python program on GitHub and other online platforms that purported to be an AI art generation tool. The program secretly dropped a malicious executable that gave Kramer access to whichever machine ran it. Between April and May 2024, a Disney employee downloaded and ran the tool on their personal computer. That machine held an online account where the victim had stored login credentials and passwords for both their personal and work accounts, including Slack.

Using those harvested credentials, Kramer logged into the victim's Slack and gained access to non-public Disney Slack channels. In May 2024 he downloaded approximately 1.1 terabytes of confidential data from thousands of channels. Two months later, in July 2024, he contacted the victim by email and Discord while posing as a member of a fake Russia-based hacktivist group he called "NullBulge", and threatened to leak both Disney's data and the victim's personal information. When the victim did not respond, on July 12, 2024 he published the Slack archive along with the victim's bank, medical, and personal records on multiple platforms.

Kramer agreed to plead guilty on May 1, 2025 to one count of accessing a computer and obtaining information, and one count of threatening to damage a protected computer. Per his plea agreement, at least two other people also ran the malicious tool and had their machines compromised. DOJ filing: Santa Clarita man agrees to plead guilty to hacking Disney employee's computer . "NullBulge" wasn't a sophisticated APT. It was one guy who uploaded a fake image generation tool. The fallout? A Fortune 100 company's internal communications.

Archetype 3: Dormant credentials, used years later (Snowflake / UNC5537)

The largest stealer-log-driven event in recent memory was a credential-harvesting campaign Mandiant tracks as UNC5537. Between late 2023 and mid-2024, the group pulled Snowflake customer credentials out of public and dark-web infostealer log dumps and authenticated against customer Snowflake instances that had not enforced MFA. Mandiant and Snowflake jointly notified approximately 165 organisations. Public victims include Ticketmaster (~560 million records), AT&T (~110 million call records), Santander, Advance Auto Parts, LendingTree, and Neiman Marcus.

Two numbers from Mandiant's report are worth sitting with. 79.7% of the compromised accounts had prior infostealer credential exposure. The earliest Snowflake credential they recovered from a stealer log was first stolen in November 2020, almost four years before it was finally used to log in. Mandiant explicitly attributed initial compromise in several incidents to contractor laptops being used for personal activities including gaming and pirated software downloads. The same pattern that fed Lumma into context.ai eight months later.

From the report: "Mandiant's investigation has not found any evidence to suggest that unauthorized access to Snowflake customer accounts stemmed from a breach of Snowflake's enterprise environment. Instead, every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials." Snowflake was never breached. 165 of its customers effectively were. Full report: UNC5537 targets Snowflake customer instances for data theft and extortion .

The chilling number is the four-year gap. A credential that sat in a stealer log since November 2020, traded who knows how many times across markets, finally got used in 2024 to exfiltrate roughly 560 million Ticketmaster records. The half-life of a stealer-log credential is measured in years, not weeks. A password rotated six months ago does nothing if the stolen artefact also contained the long-lived refresh token.

Archetype 4: Infrastructure, not data (Orange Spain / RIPE NCC)

The Orange Spain incident is the one that demonstrates the stakes are not just data. In January 2024, an Orange Spain employee's computer was infected with Raccoon stealer. The log carried, among other things, that employee's login for the RIPE NCC portal at https://access.ripe.net under the address [email protected]. That account was a RIPE administrator for Orange Spain's autonomous system, the entity that announces Orange Spain's IP ranges to the rest of the internet via BGP. InfoBreach has the log on file ( available to signed-in users here ).

Four months later, on January 3, 2024, a threat actor going by Ms_Snow_OwO obtained these credentials, logged into RIPE, and modified the AS number assigned to Orange Spain's IP space. The result was a 50% traffic loss across Orange Spain for hours, while the company scrambled to regain control of its own BGP announcements. One log, one country's second-largest carrier, half its traffic gone.

The punchline is the password. The credential protecting BGP for one of Spain's largest ISPs, sitting in the log, was ripeadmin. The stealer was almost unnecessary at that point. Any sufficiently curious attacker who guessed the email address would have been five minutes away from the same outcome through a password reset flow or a dictionary attack. The stealer simply made it instant.

The defender's math

There is a window between when a credential lands in a stealer log and when an attacker actually uses it. That window is your entire opportunity.

On the upper bound, the Snowflake campaign drew from credentials harvested as far back as 2020, roughly four years of dormancy. On the lower bound, supply-chain operators like the one who hit Vercel moved within weeks of the initial infection. Different ends of the same spectrum, but both share a property: the log existed long before the attack did. For months, sometimes years. But it's always before. If you are watching the right place, you can be ahead of the attacker every time.

Three operational consequences for anyone running a SOC or owning third-party risk:

• Vendor exposure now includes vendor employees' personal machines, and every OAuth app they ship. Your supplier's SOC 2 is irrelevant if one of their engineers installs a cracked plugin at home and that machine carries a session cookie into your tenant the next morning. And if that supplier publishes an OAuth app that your own employees have authorised, their compromise becomes your compromise; Vercel is the textbook example. You need to be watching for stealer logs that mention your vendors' corporate domains, and you need an audited list of which third-party OAuth apps your Workspace actually trusts.
• Credential rotation alone is not enough. Stealer logs include cookies, tokens, and refresh material. If a user appears in a log you have to invalidate sessions, not just force a password reset. A password reset against a log-derived session is a no-op.
• Detection has to start at the log, not the intrusion. By the time you have an intrusion you have already lost the window. Treat appearance in a log as a P1, not a quarterly hygiene chore. The IR clock starts when the log appears, not when your EDR finally lights up.

What InfoBreach actually does

This is the philosophy behind how we built the platform. A stealer log is not another row to match an email against. It is a structured artefact: credentials, cookies, autofill, system metadata, the user's installed software, the malware family, the timestamp of compromise, and every other domain that user was authenticated to at the moment the log was taken. We expose all of that, because the moment you treat it as "one more password leak" you have already underestimated it.

If you run a security team

Stand up monitors for every corporate domain you operate, every vendor domain you depend on (especially the small SaaS tools your engineers install OAuth apps from), and every contractor email that touches your environment. When a log appears, you receive the structured contents, not just a binary notification. Push session cookies and credential hashes into your SOC via the API, correlate against IdP, VPN, and SSO logs in the same hour, and rotate before the attacker imports the cookie. Audit your entire workforce in a single query through bulk lookup. If the Vercel chain had been caught at the context.ai engineer's log appearing on 2026-02-27, the supply-chain compromise that followed six weeks later does not happen. The same goes for the 165 Snowflake victims, every one of whom had a window of months or years between credential theft and credential use.

If you are an individual

Your work email, your personal email, your old gaming accounts. Search them all in the free search surface. If any of them shows up in a recent log, assume every credential that browser ever remembered is in someone else's hands: rotate passwords, revoke sessions, pull your saved Chrome or Bitwarden vault apart, and re-key anything sensitive. Then put a monitor on your address so the next time you appear in a log, you find out the same week, not six months later when someone tries to drain your bank.

Stealer logs are how attackers get inside companies now. They are also how they get inside individual people's lives. The difference between "an inconvenience" and "a federal indictment" is usually whether anyone was watching the log.

Sources

• Vercel, April 2026 security incident bulletin .
• Hudson Rock / infostealers.com, Breaking: Vercel breach linked to infostealer infection at context.ai .
• SOCRadar, Vercel breach: hacker claims to sell stolen data in potential global supply chain attack .
• Mandiant / Google Cloud, UNC5537 targets Snowflake customer instances for data theft and extortion .
• Hudson Rock, Infostealer infection of an Orange employee results in BGP disruptions ; BleepingComputer, Hacker hijacks Orange Spain RIPE account to cause BGP havoc .
• U.S. Attorney's Office, Central District of California, Santa Clarita man agrees to plead guilty to hacking Disney employee's computer .