What an infostealer actually does

An infostealer is a malware family whose entire purpose is one-shot exfiltration. It lands on a victim machine, sweeps every credential store it can find — browser-saved passwords and cookies, autofill data, password-manager databases that happen to be unlocked, FTP and SSH config files, crypto wallets, Discord and Telegram session tokens, Steam, gaming launchers — packages it into a folder called a "log", and ships it to a command-and-control server. Then it usually deletes itself.

No persistence, no lateral movement, no ransomware payload. The economics are different: the attacker who deploys the stealer is rarely the attacker who uses the credentials. Logs are sold in bulk on marketplaces — Russian Market, the various Telegram log channels, Genesis-successor sites — for a few dollars each, then bought by initial access brokers, credential-stuffing operations, ransomware affiliates, and crypto thieves. Customers who deploy dark web monitoring usually justify the spend on stealer-log coverage alone.

The 2026 cast of characters

The infostealer landscape consolidated after the May 2024 LummaC2 leak and the 2025 RedLine takedown attempt, but enough variants survived that the market is still healthy. The families to know:

  • Lumma (LummaC2): still the highest-volume stealer in distribution despite multiple takedown attempts. Sold as MaaS with active development
  • RedLine: long-running, fragmented after 2025 disruption but several forks are active
  • Vidar: Russian-origin, heavy crypto-wallet focus
  • Raccoon v2: revived after the original's pause, popular for cookie theft
  • StealC: cheaper alternative, common in cracked-software distribution
  • Atomic (AMOS): macOS-specific, distributed via fake software updates and brew packages
  • Meduza: newer entrant with strong Telegram-based delivery infrastructure

How victims get infected

Phishing is part of it, but the dominant delivery vector in 2026 is search-engine poisoning combined with malvertising. The attacker pays for a Google Ads slot ranking for a popular software name ("Notion", "OBS Studio", "Cisco AnyConnect"), the ad leads to a typosquat download page, and the binary is signed with a stolen certificate. The victim never opens an email. Other major vectors include cracked software on warez sites, fake Cloudflare/CAPTCHA "verify you are human" pages that instruct the user to paste a PowerShell command, and trojanized Chrome extensions.

Why this matters even for "consumer" infections

A stealer log from an employee's personal laptop is an enterprise breach when that laptop has corporate browser sessions. Hybrid work has blurred device boundaries so completely that any contractor laptop, BYOD device, or family computer with cached SSO cookies for your tenancy is a route in. Session cookies bypass MFA — which is exactly why phishing-resistant MFA bound to a device matters. Most successful 2025 ransomware intrusions traced back to a session cookie sold on a stealer marketplace within 48 hours of the original infection.

Token theft via stealer logs is now the dominant initial access vector for ransomware affiliates targeting English-speaking enterprises. Microsoft and Mandiant both confirmed this in their 2025 incident retrospectives.

Controls that actually reduce stealer risk

  1. Short-lived sessions: force re-authentication at 4–8 hours for sensitive apps; stealer logs become stale faster than they can be sold
  2. Phishing-resistant MFA bound to device (WebAuthn / passkeys / FIDO2) — cookies stolen from one device cannot be replayed on another
  3. Browser policy: disable saved passwords on managed devices; use enterprise password manager with MFA on the vault
  4. EDR with credential-theft rules: detect process access to browser SQLite databases, LSASS, and known stealer C2 patterns
  5. Continuous infostealer-log monitoring (a major reason for digital risk protection spend)
  6. Conditional access policies that bind sessions to device posture and source IP — see our zero trust implementation guide
  7. For developers: never store cloud credentials in plain files; use SSO-fronted CLI tools and short-lived tokens