Infostealer Malware (RedLine, Lumma, Vidar): How Attackers Steal Browser Passwords

Quick Answer: Infostealer malware (such as LummaC2, RedLine, Vidar, Stealc, and Raccoon) are specialized trojans that harvest saved browser passwords, session cookies, cryptocurrency wallets, and SSH credentials in under 5 seconds. They exploit the fact that Chromium browsers (Google Chrome, Microsoft Edge, Brave, Opera) store credentials in local SQLite databases encrypted with an AES key protected by Windows Data Protection API (DPAPI). Because DPAPI decrypts data for any executable running under the victim's Windows user session without requiring administrator rights or prompts, infostealers extract plaintext passwords instantly.

The Rise of Malware-as-a-Service (MaaS) Infostealers

Infostealer logs are the primary currency of modern cybercrime markets like Genesis Market and Russian Market. Instead of mounting complex server exploits, cybercrime syndicates purchase infostealer subscriptions for 0 to 0 per month. The malware is distributed via cracked software downloads, malicious Google Ads targeting software keywords, phishing emails, and compromised npm/PyPI packages.

Once executed on a victim's endpoint, the malware operates completely silently in the background, collects hundreds of credentials, zips the data, and exfiltrates it to a command-and-control (C2) server or encrypted Telegram channel before self-terminating.

How Chromium Browsers Store Passwords: The Anatomy of `Login Data`

To understand why browser password storage is intrinsically vulnerable, look at where Chromium stores credentials on Windows workstations:

# Default Chrome user data directory on Windows
%LocalAppData%\Google\Chrome\User Data\Default\Login Data
%LocalAppData%\Google\Chrome\User Data\Local State
%LocalAppData%\Google\Chrome\User Data\Default\Network\Cookies

The credential extraction process follows a predictable, automated sequence:

1. Extract Encrypted Master Key: The malware opens the JSON file Local State and reads the base64-encoded string at os_crypt.encrypted_key. Stripping the leading 5-byte header (DPAPI) yields an encrypted 256-bit AES master key.
2. Invoke CryptUnprotectData: The malware calls the native Windows API function CryptUnprotectData(). Because the malware is running under the user's logged-in Windows session, Windows unprotects the key immediately in less than 15 milliseconds without alerting the user.
3. Query the SQLite Database: The malware connects to Login Data (which is a standard SQLite3 database) and executes:

   SELECT origin_url, username_value, password_value FROM logins;

4. AES-256-GCM Decryption: In modern Chrome, each stored password in password_value starts with the prefix v10 or v20, followed by a 12-byte initialization vector (IV), the encrypted ciphertext, and a 16-byte authentication tag. Using the master key extracted in Step 2, the malware decrypts the password into plaintext in milliseconds.

The Flaw in Windows DPAPI: Process Isolation Does Not Exist

The fundamental architectural vulnerability is that Windows DPAPI protects data from other Windows user accounts, but NOT from other processes running under the same user account. When you log into Windows, any executable, macro, or script you launch inherits your user token. Windows has no built-in mechanism to distinguish between chrome.exe accessing your passwords and a malicious invoice.exe or PowerShell script accessing your passwords.

Google introduced App-Bound Encryption in Chrome 127+ to bind decryption privileges to the Chrome binary signature via a privileged system service. However, modern 2026 stealers like Lumma and Meduza bypass this using token impersonation, process injection, and COM object abuse.

Session Cookie Theft: Bypassing Multi-Factor Authentication (MFA)

Even if an organization enforces hardware 2FA keys, infostealers defeat authentication controls through Pass-the-Cookie attacks. By dumping the SQLite database at Network\Cookies, the malware steals valid HTTP session tokens:

• __Host-GAPS and SID (Google Workspace accounts)
• ESTSAUTH and ESTSAUTHPERSISTENT (Microsoft 365 / Entra ID)
• user_session (GitHub Enterprise)
• AWSALB and console tokens (Amazon Web Services)

When the attacker imports these stolen cookies into an anti-detect browser (such as AdsPower or Dolphin Anty), the cloud provider sees a pre-authenticated session. The attacker accesses corporate email, source code, and cloud infrastructure without knowing the victim's password or triggering a 2FA prompt.

Why Standalone Password Managers Block Infostealers

Standalone zero-knowledge password managers (like 1Password, Bitwarden, KeePassXC) protect credentials using cryptographic isolation fundamentally different from browsers:

Practical Defense: How to Neutralize Infostealer Threats

To eliminate your vulnerability to infostealer malware, implement these four defensive measures immediately:

1. Disable Browser Password Saving: Open chrome://password-manager/settings and disable "Offer to save passwords". Export your existing passwords, import them into an audited password manager, and purge the browser cache completely.
2. Use Zero-Knowledge Encryption: Read our breakdown on how zero-knowledge encryption protects vaults. Dedicated vaults require a separate master passphrase that is never stored in Windows DPAPI.
3. Transition to Passkeys: Wherever supported, replace passwords with passkeys. Because passkeys use WebAuthn origin-binding (as explained in our WebAuthn and FIDO2 guide), malware cannot steal a passkey from a database dump.
4. Audit and Strengthen Passwords: Generate unique, random 20+ character passwords for every service using our client-side Password Generator or 24-Character Password Generator.