Data Exposure and the Dark Web

Stealer Logs and Infostealer Malware

8 min read·Updated 2026-04-20
TL;DR

Infostealer malware infects a machine, scrapes every saved password, browser cookie, crypto wallet, and authentication token it can find, and uploads the lot to an attacker. The exfiltrated data ends up in dark web markets as a "stealer log" priced anywhere from a few dollars to a few hundred. These logs are now the most common starting point for ransomware, business email compromise, and account takeover attacks.

What stealer logs actually are

A stealer log is a structured dump of everything an attacker found on a compromised machine. The format varies between malware families, but the contents are remarkably consistent:

  • Saved browser credentials. Every username and password your browser remembered, decrypted and exported.
  • Browser cookies. Including session cookies that allow attackers to bypass MFA by reusing your active sessions.
  • Autofill data. Names, addresses, credit card numbers, anything stored in browser autofill.
  • Crypto wallet files. Desktop wallets are favourite targets because the contents are immediately monetisable.
  • System information. OS version, installed software, antivirus status, IP address, geolocation.
  • Screenshots and webcam captures. Some stealers grab these for later extortion or context.
  • Files matching keywords. Documents containing "password", "wallet", "seed", "passport" and similar terms get hoovered up wholesale.
  • VPN and FTP credentials. Anything stored in client applications.
  • Discord, Telegram, Steam tokens. Communication and gaming accounts hold significant resale value.

A single stealer log can contain hundreds of credentials and dozens of active session cookies. Multiply that by ten thousand infected machines per day across the major stealer families, and the scale starts to make sense.

Why this matters more than ever

Five years ago, the dominant initial access vector for serious attacks was either phishing (slow, hit-or-miss) or buying credentials from older breach dumps (often outdated, behind MFA). Both are still around. But stealer logs have changed the economics in a way that defenders have not fully caught up with.

The shift is significant for three reasons:

Stealer logs include sessions, not just passwords. A leaked password from a 2019 breach is almost always behind MFA today. A session cookie from yesterday's stealer log is usually not. The attacker imports the cookie into their own browser and is logged in as you. No MFA prompt, no anomaly detection alert, no signal that anything is wrong.

The data is fresh. Stealer markets get restocked every day. The credentials, sessions, and access tokens reflect what the user is actually using right now, not what they were using before they rotated.

The price is low. A single infected employee at a target company sells for around ten to fifty dollars on most stealer markets. Targeted searches by company domain make finding the right victim trivial. For attackers, there has never been a cheaper way to get a working foothold.

The result: stealer logs are now the most common starting point for ransomware deployment, business email compromise, and high-value account takeover. The Conti leaks, several major retail breaches, and a long list of recent ransomware incidents all started with a stealer log purchase.

How infections actually happen

Most infostealer infections come from one of a small set of vectors:

  1. Cracked software. Pirated games, cracked Adobe products, "free" versions of paid software. The crack does not just bypass licensing. It also installs Lumma, RedLine, or Vidar in the background.
  2. YouTube tutorials and Discord links. Particularly aimed at younger users. A tutorial promises a free game cheat, links to a download, the download is a stealer.
  3. Fake software updates. "Your browser is out of date." The update is a stealer.
  4. Malvertising. Search ads pointing to lookalike download pages for popular software (Notion, OBS, AnyDesk, etc.).
  5. Phishing emails with payloads. Less common than browser-based delivery but still present.
  6. Compromised software supply chain. Less frequent but increasing. A real software update gets backdoored upstream.

The takeaway: most infections start with the user actively running something they should not have. Antivirus signatures help, but the malware authors continuously rotate builds to evade detection. Browser security warnings help less than you would hope, because the user is by this point determined to install whatever it is.

The major stealer families

Knowing the names is useful because they affect detection signals and traffic patterns:

  • Lumma Stealer (the dominant family in 2024 to 2026). Aggressive development, frequent updates, sold as a service starting around 250 dollars per month.
  • RedLine Stealer. Older, very widely distributed. Many of the underground markets are full of RedLine logs.
  • Vidar. Also long established, evolved versions are still actively distributed.
  • StealC. Newer entry, similar capabilities to Lumma.
  • Raccoon Stealer. Operations were disrupted by law enforcement, but successor variants exist.
  • Atomic Stealer (AMOS). macOS-targeted infostealer, growing fast as Mac usage in business has grown.

Each one has its own command and control infrastructure, its own monetisation network, and its own slightly different log format. From a defender's standpoint they all do roughly the same thing.

Where stealer logs end up

The lifecycle of a stealer log is short and predictable:

  1. Day zero. Malware exfiltrates the log to a C2 server controlled by the operator.
  2. Day zero to one. Operator filters the logs and uploads the high-value ones to private channels.
  3. Day one to seven. Logs appear on Telegram channels (the dominant marketplace today), Russian Market, 2easy, and other underground platforms. Buyers can search by domain, country, software installed, and other filters.
  4. Day seven onwards. Older logs get bundled into larger dumps and sold cheaply, then eventually leak publicly and get scraped by various security and analytics firms.

The defender window is short. By the time a log shows up in a free public dump, attackers who care have already used it.

How to detect compromised users

Detection requires monitoring of stealer log markets, which is not something you can do casually. The actionable signals are:

  • Corporate email addresses appearing in fresh logs. This is the highest-value signal. If alice@yourcompany.com shows up in a Lumma log dumped yesterday, Alice has an infected machine right now.
  • Active session cookies for your applications. Sessions are time-limited, so this is also urgent. If the log contains a valid session cookie for your SSO or VPN, you need to invalidate it before someone else uses it.
  • Credentials for your VPN, SSO, or cloud admin consoles. These get checked into stealer logs constantly. Any of them appearing for an employee account is an incident.
  • Customer credentials for your platform. If your customers' credentials show up, they are vulnerable to account takeover. Forced password reset is the standard response.
  • Executive personal devices. Some of the worst incidents start with a personal device of a senior executive being infected. Personal Gmail, social media, or banking accounts get compromised, and the lateral move into corporate accounts follows.

The challenge is volume. Tens of thousands of new logs appear every day, most irrelevant to any specific organisation. The work is filtering them down to the ones that matter to you.

How to remediate

When a credible stealer log compromise is detected, the response sequence is roughly:

  1. Identify the device. Which physical machine produced this log? The system fingerprint and IP address in the log usually narrow it down. If the user's hostname is in the log, you can identify it directly.
  2. Isolate the device. Network quarantine, EDR isolation, or in the worst case unplug it.
  3. Rotate every credential the device touched. Not just the ones in the log. Anything that was saved in the browser. Anything used in the past month or so. Assume everything is compromised.
  4. Invalidate every session. Force re-authentication on SSO, VPN, cloud admin consoles, email, and anything else where a session cookie could grant access.
  5. Reimage the device. Stealers often install secondary payloads. Cleaning the malware does not guarantee the machine is clean.
  6. Review what the attacker could have accessed. Look for suspicious logins, MFA approvals from unfamiliar locations, or new mailbox rules added to email accounts.
  7. Notify affected parties. If customer data was reachable from the compromised account, notification obligations may apply.

The faster you move, the smaller the blast radius. A stealer log used within an hour of theft is a worst-case scenario. Most attackers move slower, and a same-day response usually contains the incident before it escalates to ransomware or wire fraud.

Best practices

  • Continuous stealer log monitoring for your domain. Daily at minimum. Real-time is better. The signal degrades fast.
  • Force MFA everywhere. Yes, sessions can bypass MFA. But raising the bar on the credentials themselves still helps.
  • Use phishing-resistant MFA where you can. FIDO2 keys, passkeys, or device-bound credentials defeat session theft because the cryptographic session cannot be replayed off the original device.
  • Limit the lifetime of high-value sessions. Cloud admin consoles, financial systems, and similar should expire sessions in hours, not weeks.
  • Block known malware delivery domains. DNS-level blocking catches a lot of stealer infections at the click stage.
  • Restrict installation of unsigned software on corporate devices. Cracked software cannot run if your endpoints will not execute it.
  • Educate users about cracked software and shady downloads. Especially developers, who are sometimes more cavalier about what they install.
  • Monitor for executive personal device compromise. Personal devices used for any work-related access are part of your attack surface whether you formally manage them or not.

What does not work

A few common controls underperform against stealer logs and are worth flagging:

  • Password complexity rules. The malware does not crack passwords. It steals them already in cleartext from the browser.
  • Periodic password rotation. By the time the next rotation happens, the stolen credential has already been used.
  • Detecting unusual login locations. A reused session cookie does not trigger a login event, so location-based alerts often miss it.
  • Antivirus alone. Modern stealer builds are designed to evade signature-based AV.

This is not to say these controls are useless. They help against other threats. Just do not rely on them as the primary defence against infostealer malware.

ScruteX monitors stealer log markets continuously and alerts when your employees or customers appear in fresh dumps.

Learn more