What the rise of infostealers says about identity attacks

Infostealer malware seems to be grabbing the headlines right now. It’s easy to see why, too, after laying claim to one of the biggest breaches in history. The recent attacks on Snowflake customers saw ~165 businesses compromised using stolen credentials, resulting in millions of breached customer records, with the full impact still emerging. 

Notably, 80% of the credentials used to access Snowflake customer accounts had found their way online after being stolen in infostealer infections – dating back as early as 2020. 

The Snowflake situation is a reminder of how lucrative stolen credentials can be for attackers – and how the cybercrime ecosystem has tilted as a result. As the saying goes nowadays, hackers don’t hack in, they log in. Stolen credentials are the lowest hanging fruit available to attackers, and their appetite (and the ecosystem needed to feed it) is insatiable. As an attacker, the prospect of picking up access to a major enterprise for just $10 or less (or even for free) is hard to resist – why wouldn’t you buy a ticket and take the gamble?  

Infostealers are a huge part of the shift toward identity attacks. Along with phishing, infostealers are the primary mechanism for attackers to harvest credentials. Unlike phishing, infostealers can collect a large number of credentials (and other helpful data saved in the browser) in one fell swoop. But, they do have limitations. For example, you would expect any credible EDR to detect and block these attacks. And yet, the success of the attacks on Snowflake customers show us that gaps are being found and exploited.  

In this article, we’ll look at the history of infostealers, how they work, and what the trends show us about how the cybercrime ecosystem is leaning into the opportunity they present.    

The state of infostealers today

Infostealers, and the mass credential harvesting they enable, are a big part of the rise in identity attacks. The stats support this, as:

• One million new stealer logs are distributed every month, with an estimated 3-5% containing credentials and session cookies to corporate IT environments (Flare).

• Infostealer activity increased by 266% in 2023, while the number of attacks featuring valid credentials saw a 71% increase year-over-year (IBM).

• 147,000 token replay attacks were detected by Microsoft in 2023, an 111% increase year-over-year (Microsoft). 

• Over 1000 credentials are posted online per day, per marketplace with an average sale price of $10, and 65% posted less than one day after being collected (Verizon).

• Nearly half of the malware detected last year by Sophos targeted victims’ data specifically, and the majority of that malware was classified as infostealers (Sophos).

• Attacks on session cookies happen at the same order of magnitude as password-based attacks (Google).

How did we get here?

Let’s go back to the beginning. When they first emerged, infostealers were designed to steal online banking and credit card information. The most notable early example comes from as far back as 2006 with the ZeuS trojan. After the ZeuS source code was leaked in March 2011, the creation of multiple variants boosted the popularity of this type of malware and inspired the development of infostealers with increasingly sophisticated capabilities.

Modern infostealers rose to prominence in around 2018 with the emergence of Arkei, which quickly spawned the more popular Vidar stealer. Today, some of the most popular families are RisePro, RedLine, StealC, Raccoon, and Lumma, with new variants and families appearing all the time. 

Infostealers are used by all manner of threat actors of varying levels of sophistication. For larger groups with sufficient resources, the creation of new, custom stealers and malware packages is a common tactic to attempt to evade detection. 

But despite all the variants, infostealers do have common capabilities and characteristics, such as:

• Extracting information from the browsers of a compromised device, such as passwords, cookies, autofill information, downloaded file information.

• Snapshotting the desktop and system inventory, with details such as the username, location data, hardware configuration, and information regarding installed security software.

• Sending stolen data back to a C2 server.

• Facilitating the deployment of additional tools and malware as part of a package. 

• Often (but not always) self-terminating once complete, leaving little trace on the victim machine and no ongoing behavior that might be detected. 

Infostealers are distributed in similar ways to other types of malware, such as:

• Delivery of malicious executable files via phishing emails or by having a victim download content from a malicious website. 

• ‘Drive-by’ style attacks where the victim has only to visit an infected website.

They’re typically spread via malvertising, P2P downloads, and deceptive software download sites. Gaming forums, Facebook ads, and YouTube video descriptions are popular locations for malicious links, but recent examples also include complex malware distribution networks on GitHub – such as the recent campaign from ‘Stargazer Goblin’ with more than 3,000 fake accounts creating and promoting hundreds of fake repositories to increase their apparent legitimacy and make them more likely to appear on GitHub's trending section.

Infostealers are key to the cybercrime ecosystem

After being stolen, infostealer data inevitably finds its way onto hacker forums and marketplaces, both on the clearweb and darkweb. Popular infostealers have their own dedicated Telegram channels to advertise and sell stolen data. Private channels also exist, with the channel owner distributing tens of thousands of logs per week to a limited number of threat actors who pay $200-$400 for access to the channel. This allows them to get ‘first pick’ of stolen logs, which are later shared through public Telegram channels. 

Public data eventually makes its way onto services such as Have I Been Pwned (HIBP), which gives individuals and security teams some visibility of which credentials have been compromised. For example, in June, Troy Hunt (creator of HIBP) wrote about the impact of channels like Telegram and the sale of combolists (username, password, login portal URL), after being sent 122GB of data scraped out of thousands of Telegram channels, containing 361M unique email addresses (of which 151M had never been seen in HIBP before). 

The cybercrime ecosystem is complex, with a developed supply chain and organizations fulfilling different roles as a result: from malware-as-a-service developers, to initial access brokers, to the operators that actually conduct the attacks (be they ransomware, data theft, etc.) – and many, many other roles in between. Sometimes, a single group and/or its affiliates will conduct the full chain, but this is far less common today. 

Infostealers are often sold by malware developers to other attackers as a monthly subscription service. The price can range from $50 to over $1,000 USD per month for access to a stealer command and control (C2) server operated by the developer. The service often features a range of support functions, including multiple ways to view, download, and share stolen data. Self-hosted stealer C2 servers are also available and are usually sold for a flat fee. 

There’s also evidence that there is an element of target coordination – with one marketplace, Russian Market, allowing users to ‘preorder’ credentials for a $1,000 USD deposit from 2022. 

So what? Well, there's evidently an abundance of breached data already online, and attackers have the tools readily available to have this pile grow exponentially bigger and more useful. It’s also probably more coordinated than we like to admit – a particularly intimidating prospect in the wake of Snowflake, which will no doubt have many criminals smelling blood in the water. 

How can stolen data be abused by attackers? 

It’s pretty obvious that attackers getting access to all of your passwords and session cookies is bad, but there is a clear value hierarchy from a corporate security perspective. So, from highest to lowest risk:

• Stolen session cookies simply need to be imported into an attacker’s browser to resume an active session on an app. That means access can be gained without needing to enter a username and password, or pass any MFA checks. 

• Stolen usernames, passwords, and login page URLs can be used to access any accounts that lack MFA. 

• Stolen autofill data can be used to gather other valuable information that could be useful for impersonating the victim when speaking to social engineering IT support staff, for example to reset or remove MFA.

Naturally, stolen session cookies are the most valuable prize, but they are often valid for only a limited time before the user must re-authenticate, and active sessions can often be terminated by security admins. Unfortunately, it’s not that uncommon for sessions to last for up to a month, or even sometimes indefinitely.

Stolen usernames and passwords are a different story. As the Snowflake breaches demonstrate, passwords can remain valid for years after a breach, particularly in the world of SaaS apps where mandatory password rotation is not as common as for a user’s primary domain account.

There’s also the problem of ghost logins – where a local login with a username and password (and probably lacking MFA) can exist alongside other, more secure login methods such as SSO. Given the fact that many apps are self-adopted by users, these accounts continue to exist even when an app is subsequently added to SSO via the chosen IdP, meaning they can fly under the radar of security teams. 

Should you be concerned about infostealers?

It’s commonly thought that infostealers are primarily a concern for unmanaged devices that lack security controls common to corporate IT, such as EDR. But there’s a couple of reasons why corporate users are also at risk:

EDR can be bypassed

EDR is seen as the go-to solution for defending against infostealer malware. However, attackers are always looking for ways to get around security controls by obfuscating malicious behavior and evading signature-based checks. For example, a flaw in Microsoft Defender SmartScreen was recently exploited to deliver infostealer malware.

Getting total coverage across your endpoint estate is notoriously difficult, if not totally unrealistic. Unless the malware is stopped on execution, then data will inevitably be stolen, and will continue to be taken until stopped (or it self-terminates). And once an attacker has stolen employee credentials or sessions, the credential stuffing and session hijacking attacks that come next won’t touch the endpoint. For those reasons, you can’t rely on EDR as a single line of defense against infostealers.

Unmanaged devices such as BYOD or third-parties are vulnerable

Companies that support BYOD often have less secure configurations than those with fully managed devices. The same applies to third-party contractors, who often use their own devices to access company systems on a temporary basis. 

This issue was acutely felt in the Snowflake attacks: There is some suggestion that targeting key third-party suppliers – such as EPAM Systems, a software engineering firm and Snowflake ‘Elite Tier Partner’ – yielded some of the access needed. It’s unclear what came first, but it’s possible (likely, even) that EPAM was identified as a target specifically because of its lucrative customer base – third-parties are a known weak point for red teamers, so it would be foolish to assume that attackers don’t also think this way. It’s possible too that EPAM were specifically targeted because of their Snowflake chops – adding another indicator that Snowflake was potentially a premeditated attack inspired by the availability of Snowflake credentials online. 

Browser profiles can be synced across devices, increasing the blast radius

It’s not uncommon for employees to access their personal email accounts from company devices. When accessing any browser, you are typically prompted to sign in with your account credentials (e.g. your Google account). If a user signs into a browser on a company device with a personal account, you’re usually prompted to sync your account across devices. This usually means that any saved passwords, search history, and settings are shared across devices. 

Naturally, this means that if a personal device is compromised where you’re also logged into the browser profile, then an infostealer will be able to harvest information saved into that profile across devices.

Even when using separate browser profiles for work and personal, it’s easy for the two to converge, or to slip into using the wrong profile. Accessing personal accounts (or at least synchronizing data across accounts) is usually a workplace policy violation, but it’s unfortunately all too common. 

Previous vulnerabilities have exacerbated this problem, such as an exploit affecting Google MultiLogin to maintain access to synced accounts even after a password reset. 

Are infostealers a bigger problem than credential phishing? 

The short answer is: No. The longer answer is: They are both part of the bigger problem of identity attacks, and attackers can wield both approaches simultaneously. 

While they are delivered to victims in similar ways to phishing links, most organizations are arguably better protected against infostealers than modern phishing attacks because endpoint security controls provide another layer of protection, in theory – whereas modern phishing attacks don’t necessarily involve the delivery of malware that executes on the device. 

Infostealers arguably provide more bang for the attacker’s buck, grabbing a stack of credentials and useful data in one go. In contrast, phishing is usually much more targeted, and involves the compromise of a narrower set of credentials – typically focusing on a particular site or app. 

It’s worth focusing on the TTP, not the particular tool being used: The attacker technique here is session cookie theft, and subsequently session hijacking by importing the cookie into the attacker’s browser. Both infostealers and modern phishing attacks involve the theft of session tokens, and so are valid means to achieve this end. In fact, there’s nothing to stop threat groups from employing both simultaneously.

What can organizations do about the infostealer threat? 

Security teams should have two main concerns:

• Data that is already out there from historical data dumps, but is still valid. 

• Data in private channels that attackers could use in the future, that you are blind to. 

As always, the root-cause of the problem is a lack of meaningful visibility of what apps your employees are using (including those outside your IdP) and whether the associated identities are configured securely. 

A layered, defense-in-depth approach is required to resolve the issue, by:

• Deploying MFA across all your identities and apps, including any local logins that can’t be put behind SSO. 

• Configuring time-limited session lifetimes for all apps to ensure that any stolen session tokens can only be used temporarily. 

• Ensuring that employees don’t access or synchronize personal accounts on their work devices, as well as limiting non-work activities on their work device as much as possible.

• Implementing a robust EDR/MDR solution to detect and respond to malware compromises on user devices. 

Organizations also have the option of investing in a commercial TI feed to detect and report data breaches affecting employees. But in our experience, these feeds contain a lot of false positives – so unless you have password visibility for employee accounts across apps, it’s going to waste a chunk of valuable time for you and your employees.

It would be remiss of us not to mention our recently released session token theft detection feature that identifies session token theft by adding telemetry to the user agent string – using the power of our browser agent to create a new high-fidelity signal for security teams. It can also be applied more generally to detect any session taking place in an unmanaged browser – so you can use it to spot unauthorized access to company apps in general, too.  

What’s next for infostealers?

All the signs point to the fact that infostealers will continue being a useful tool in the attacker’s arsenal. The Snowflake attacks in particular are both a warning for defenders and encouragement for attackers. It's also a good reminder that while infostealers were once used to harvest things like VPN creds to pivot to the internal network, they're now largely used to target third-party services over the internet.

To evade EDR, it’s likely that we’ll see a growing number of families and variants used by individual groups, or better ‘enterprise’ capabilities from malware-as-a-service vendors. 

One notable quirk is that, to date, infostealers have not really branched out from targeting browsers. Take the example of password manager apps – you would think this would be an obvious target, right? But, they’re not usually targeted (with some exceptions). And when they do, they work by eavesdropping on the password manager’s browser extension in action – meaning they are intercepted one-at-a-time as the user uses them, rather than targeting the password manager directly and exporting the saved passwords all at once. It will be interesting to see whether these capabilities are added in the future. 

On the other hand, there are defensive security developments that could reduce the ability of attackers to leverage things like stolen session tokens, such as Microsoft’s token binding feature in Entra, or Google’s device bound session cookies. Google also released an app-bound encryption feature, which adds additional protection against infostealers attempting to steal browser data in Chrome if the underlying Windows device is compromised.

That said, mature versions of these controls are still years away, and while session cookie theft is a key risk of infostealers, it’s not the only risk – so alternative controls and mitigations remain valuable to security teams in the present.