What is an Infostealer?

In February 2026, a developer at Context.ai opened something they should not have. Lumma Stealer ran on their machine for a period of time nobody has publicly disclosed. It copied everything it could find: saved browser passwords, session cookies, application tokens, API keys stored locally, crypto wallet files. Then it sent all of it home.

Two months later, a Vercel employee's Google Workspace was compromised. Hundreds of organizations started rotating credentials. The infostealer log from one infected machine in February became the entry point for a breach that reached across the entire Vercel customer base.

This is how infostealers work. Not through elaborate zero-days or sophisticated exploits. Through harvesting what is already sitting on the machine.

What an Infostealer Does

An infostealer is a category of malware with a single purpose: collect and exfiltrate credentials and sensitive data as quickly as possible. It is not ransomware. It does not encrypt your files or announce itself. It runs quietly, takes what it can reach, sends the data to an attacker-controlled server, and exits.

The data an infostealer targets typically includes:

Browser credentials. Chrome, Firefox, Edge, and other browsers store saved passwords in local database files. On Windows, Chrome's password database is encrypted, but the encryption key is stored locally too, protected by the Windows Data Protection API. Infostealers pull both the database and the key and decrypt locally before exfiltrating. If you use "Save Password" in your browser, an infostealer can retrieve those passwords.

Session cookies. Cookies maintain your logged-in state on websites. An attacker with your session cookie for Gmail or GitHub does not need your password. They paste the cookie into their browser, and they are logged in as you. This is why many infostealers prioritize cookies over passwords. They bypass multi-factor authentication entirely, because the session was authenticated before the cookie was stolen.

Crypto wallets. Browser extension wallets like MetaMask store encrypted vault files locally. Infostealers copy these files. If the attacker can crack the password, they have the wallet. Hardware wallet seed phrases stored in text files or password managers also get swept up.

Application tokens. API keys, OAuth tokens, and application secrets stored in local config files or environment files on the developer's machine. The Lumma Stealer infection at Context.ai pulled Google Workspace credentials, Supabase keys, Datadog credentials, and Authkit tokens. These were not just login credentials. They were active service tokens that gave the attacker direct API access.

System information. Hostnames, installed software, running processes. This helps the attacker understand what they have and prioritize which logs to work through.

The entire collection and exfiltration process often takes seconds. By the time the user notices anything, the data is already on an attacker-controlled server.

The Infostealer-as-a-Service Ecosystem

Lumma Stealer, the malware at the center of the Context.ai breach, is not custom-built nation-state tooling. It is a commercial product. You can subscribe to it.

The infostealer market operates as a service. Developers build and maintain the malware. They sell access through subscription plans that typically include a web panel for managing infections, viewing collected logs, and filtering results by credential type. Lumma Stealer has been publicly documented since around 2022. Security researchers have analyzed its codebase, written detection signatures, and tracked its infrastructure. None of that has stopped it from running in active operations.

The business model extends downstream. Attackers who run infostealer campaigns do not always use the collected logs themselves. Many sell log access on underground markets. Buyers pay to search logs by company name, domain, or credential type. The Vercel breach likely traces to a buyer searching a Lumma Stealer log for Context.ai employee credentials and finding the right combination of service tokens to pivot further.

This is why breaches at small companies can affect large ones. The attack surface is not just your organization. It is every vendor, every contractor, every third-party tool your employees use, and every machine any of those people touch.

How Infostealers Get Installed

The infection vector for Lumma Stealer and similar tools varies, but the common paths are:

Malvertising. Fake ads on legitimate platforms that lead to malware downloads. Searches for cracked software, game cheats, or free tools frequently hit these. The download page looks plausible. The installer runs. The infostealer is bundled inside.

Phishing. Email or message attachments that execute a dropper. The dropper downloads and runs the actual infostealer payload. Corporate email filtering catches some of this, but personal email accounts used on work machines bypass it.

Fake software updates. Browser pop-ups claiming Flash or a codec needs updating. More sophisticated versions spoof update notifications for real software.

Compromised developer packages. Malicious npm packages, PyPI packages, or other package manager entries that include infostealer payloads alongside legitimate functionality. The Axios supply chain attack earlier this year used this vector. A developer installs what looks like a legitimate dependency, and the infostealer runs during the install or at runtime.

The Context.ai infection vector has not been publicly disclosed. It does not matter for the downstream lesson. One infected machine at a vendor is enough.

Why Developer Machines Are High-Value Targets

Not all infostealer logs are equal. A log from a regular user's home machine might contain a few banking passwords. A log from a developer's machine might contain:

• SSH keys for production servers
• AWS credentials in ~/.aws/credentials
• API keys in .env files and dotfiles
• GitHub personal access tokens with repo access
• Google Cloud service account JSON files
• Local copies of secrets from password managers
• Session tokens for internal tools and dashboards
  Attackers running campaigns against developer-heavy companies specifically target developers because the access multiplier is so high. One infected machine at a startup with broad internal permissions can yield access to infrastructure that serves millions of users.

Developers also tend to have more liberal security postures on their local machines. They install packages constantly. They run code from the internet regularly. They sometimes disable security tools that interfere with development. These are reasonable tradeoffs for productivity. They are also why developers are disproportionately represented in infostealer log markets.

Detection and Defense

Infostealers are designed to evade detection. They run briefly, use legitimate system processes where possible, and exfiltrate over HTTPS to blend in with normal traffic. That said, there are concrete steps that reduce exposure.

Endpoint detection and response (EDR). Modern EDR tools catch most commodity infostealers through behavioral detection. They look for processes accessing the browser credential database, attempting to read wallet files, or making unusual outbound connections. This is the highest-leverage control for stopping an infostealer before it completes exfiltration.

Short-lived credentials. If your session tokens and API keys have short expiry windows, a stolen token becomes useless faster. OAuth tokens with 15-minute lifetimes and rotating refresh tokens, combined with a revocation response when anomalous access is detected, significantly reduce the value of stolen credentials.

Hardware-backed secrets. Secrets stored in hardware security modules or managed by tools like the macOS Secure Enclave are considerably harder to exfiltrate than credentials sitting in browser storage or plain text files. For high-value keys, the inconvenience of hardware-backed storage is worth it.

Monitoring for credential use from unexpected locations. If an API key that normally comes from a CI runner in us-east-1 suddenly shows up making requests from an IP in Eastern Europe, that should trigger an alert. Most cloud providers offer this kind of anomaly detection out of the box.

Regular credential rotation. Treat long-lived credentials as a liability. Rotate API keys, service account tokens, and OAuth app secrets on a schedule, not just after incidents.

The Vercel breach happened because none of these controls stopped the downstream use of stolen tokens. The infostealer did its job in February. The attacker waited two months and then used what they had.

Related reading from the CoderOasis library: The Vercel breach breakdown follows the complete attack chain from the Lumma Stealer infection through the Vercel compromise. The What is Supply Chain Security article covers how attackers target vendor relationships to reach high-value organizations. And What is Privilege Escalation explains the technique the attacker used once they had the Context.ai support account credentials.