Infostealer logs have evolved from an underground commodity into an operational security problem. For defenders, finding an exposed credential is only the beginning. In today’s reality many security analysts start their morning with an alert: an employee’s corporate email address has appeared in a newly collected infostealer log.
The log contains a username and password for a corporate SaaS application. There are browser cookies, meaning live sessions that can be exploited, and several other saved, in files, credentials.
A personal employee computer got infected by Vidar located hundreds of miles from the company’s offices. Now what?
Resetting the exposed password seems obvious. But that may not solve the problem. If the stealer captured an authenticated session cookie, an attacker may already have a way into the application without needing the password or another MFA prompt. If the employee reused corporate credentials on a personal computer, the endpoint that created the exposure may not even be managed by the organization.
And somewhere in an underground Telegram channel, the same information may already be available to an initial access broker, ransomware affiliate, or opportunistic attacker.
This is the operational challenge security teams increasingly face with infostealer logs.
According to Flare Research’s Practitioner’s Guide to Monitoring Stealer Logs, approximately 46% of stealer logs containing corporate credentials originate from likely unmanaged or personal devices. Flare also estimates that exposure involving credentials and sessions for major productivity SaaS and cloud services is growing approximately 29% annually.
For defenders, the question is no longer simply whether they should monitor infostealer logs.
The harder question is: How do you separate a meaningless old password from an identity compromise that could be happening right now?
The needle among millions of needles
Infostealers such as RedLine, Lumma, Vidar and other malware families are designed to harvest information stored on infected systems.
Depending on the malware and configuration, that can include saved browser passwords, cookies, autofill information, cryptocurrency wallets, system information, VPN configurations and other authentication artifacts.
These are packaged to be sold under as an infostealer log, when a single infection can produce hundreds or thousands of individual records. Multiply that across a global malware ecosystem and defenders quickly encounter a scale problem.
While defenders need to process and validate everything, the attackers only need one valid valuable set of credentials. As Flare describes the problem, this isn’t finding a needle in a haystack. It is finding a specific needle among millions of needles in millions of haystacks.
While stealer logs historically circulated through underground forums and marketplaces, Flare’s research estimates that roughly 90% of logs now appear on Telegram, where public channels can advertise samples and private subscription channels can provide access to fresher datasets.
Infostealer logs can hand attackers a live, authenticated session that skips the password and MFA prompt entirely.
Flare monitors stealer logs across the dark web and Telegram in real time, so you can flag exposed corporate identities and sessions before they turn into account takeover.
Free 2-Week Trial
A password isn’t always the most dangerous thing in the log
With the vast amount of data in multiple channels, it’s hard to prioritize the risk level. If you work for a large corporate you are working with thousands of employees, if you start your day with two alerts, how can you establish what is riskier?
The first alert may involve employees’ old password for a consumer website appears in a six-month-old stealer log, whereas the second alert may have been collected yesterday and contains the employee’s corporate identity credentials and an authenticated browser session for the organization’s identity provider.
While both may be labeled as employee credential exposures, they are completely different.
This is why practitioners should prioritize monitoring around assets that tell them something about the potential impact, for instance corporate domains and subdomains, enterprise identity providers, session cookies, VPN and RDP endpoints, and cloud consoles.
Identity providers deserve particular attention, since a compromised SSO identity (Microsoft Entra ID, Okta, Google Cloud Identity, etc.) can open a path to multiple connected applications. Where possible, automated verification and mitigation further strengthen this protection.
The peril in session cookies
When a user successfully authenticates, an application can issue a session cookie, so they don’t have to authenticate with every request.
If malware steals that authenticated session, an attacker may potentially replay it.
So, if the attackers get ahold of a session cookie, and an infostealer collects them, they don’t necessarily need to log in. Stolen credentials alone still require authentication, creating an opportunity for defenders to detect or block the login, however, a valid session cookie may remove that step entirely. This effectively bypasses MFA.
The first 60 seconds
Flare recommends an initial assessment immediately after discovering potentially relevant stealer data, followed by risk scoring and validation.
The objective isn’t to conduct the entire incident investigation in the first few minutes. It is to determine how quickly the organization needs to react.
A useful first question is: What exactly was stolen? An analyst should determine when the infection occurred, what system produced the log, how many corporate credentials are present, and whether authenticated sessions were captured.
Then add business context.
A credential for testserver.company.com shouldn’t necessarily receive the same priority as one for finance.company.com.
Similarly, an exposed identity belonging to a marketing intern shouldn’t automatically be handled identically to an administrator with access to the identity provider, cloud console and production infrastructure.
The illustrative framework in Flare’s guide therefore places enterprise identity credentials combined with session cookies at critical severity, with a suggested response target of under one hour. VPN/RDP access combined with multiple corporate credentials is classified as high severity because of its lateral movement potential.
From exposure to investigation
Suppose our hypothetical employee’s log contains an Entra ID credential, corporate SaaS passwords and browser cookies, the next question is whether someone has already used them.
Defenders can correlate the exposed identity with authentication telemetry: successful and failed logins, unexpected geographies, unusual devices, unfamiliar IP addresses and access to resources outside the employee’s normal behavior.
They should also determine whether the stolen information is still usable. Has the password changed since the infection? Has the session expired? Is the account still active?
Flare’s recommended investigation workflow expands the analysis to include browser fingerprint information, the complete saved-credential inventory, information about the infected system, and additional artifacts such as VPN configurations or SSH keys.
Who is the employee? What can their identity access? Was the infected machine corporate or personal? Was this one infection or evidence of a broader campaign?
Authentication logs should then be examined across the systems accessible to that identity, prioritizing the most sensitive resources first.
Defenders should specifically look for behaviors indicating that exposure has progressed into account takeover: authentication from unexpected locations, access inconsistent with the user’s role, unusual downloads, password-reset activity, and enrollment of new MFA devices. This is how a stealer log becomes an early-warning sensor for identity compromise.
Treat stealer logs as an identity problem
Once a high-risk exposure is confirmed, speed matters. Defenders should invalidate compromised sessions, reset affected credentials, and increase monitoring around the identity.
Beyond individual incidents, organizations should track recurring exposures, affected applications, and whether stolen credentials lead to attempted access.
Ultimately, infostealer monitoring has become an essential layer of identity security, enabling organizations to identify exposed credentials and sessions, understand the access they provide, determine whether they remain exploitable, and disrupt potential account takeover before it develops into a broader compromise.
Learn more by signing up for our free trial.
Sponsored and written by Flare.
