Crumbled Security: Unmasking the Cookie-Stealing Malware Threat

Over the past few years, we’ve seen a huge increase in the adoption of identity security  solutions. Since these types of solutions help protect against a whole range of password-guessing and stealing techniques, such as brute force password guessing and, in some cases, keylogging.

Despite the added value provided by these solutions, any security researcher will tell you this isn’t enough. There’s a relatively simple and extremely common technique that can allow threat actors unauthorized access without even needing to know the credentials or initiating an MFA challenge. That technique is web session hijacking through cookie theft.

This blog post will provide a general overview of malware that steals cookies (infostealer) and the prominent infostealer malware families. We’ll cover common infection techniques and impacts as well as take a look at some examples.

Initial Access and Impact

Infostealers have many different techniques for targeting their victims. The most common techniques we see aren’t usually meant to target any specific individual but rather target as broad an audience as they can reach. The three main infection methods are phishing, malvertising (i.e. spreading via malicious ads on popular sites like Google and Facebook) and impersonating illegal software such as cracked programs and game cheats.

Once a user opens the phishing attachment or executes whatever program was downloaded, the malware begins to run. The stealers generally target various types of login and session data for various applications, some of which we’ll elaborate on later. It’s important to note that most application data doesn’t require elevated privileges to access, which allows malware to steal things like cookies without running as an admin. Once all the data is collected, it’s sent to a command and control server for the threat actors to look at and use as they see fit. Usually, the stolen data is then exported from the server to be sold on various forums either on the dark web or sometimes on hacking forums on the clearnet.

The impacts of an infostealer can vary greatly. For organizations, the more concerning aspect of infostealers is that attackers will often buy credentials stolen by infostealers to create more targeted and robust attacks. Arguably, the worst are the cases where threat actors gain access to the company’s codebase or customer support and then leverage the access to create supply chain attacks, which will ripple into many other organizations.

In addition to supply chain attacks, stolen cookies can serve as initial access points for ransomware operators, which these days means organizations will have some stolen data leaked on the dark web along with more data being encrypted in their network, leading operations to a halt.

We see many other impacts as well. A few notable examples are theft, which occurs when threat actors gain access to various payment systems or crypto applications. It’s also common to see threat actors leverage access to reputable social media accounts to push crypto scams.

Figure 1: Infostealer Infection Flow

Infostealer Telemetry

Unlike ransomware groups, who often employ leak sites that can be used to gain accurate (though not perfect) measurements of how many victims each ransomware group has, infostealers don’t generally advertise who/how many victims they have. The closest thing to a ransomware leak site is stolen logs for sale on various forums. But these come with a whole host of problems. For example, many logs don’t include information about which infostealer was used to steal those logs. And, of course, there’s the whole legal issue regarding access to stolen logs, even when meant for research. Because of these issues, most people use detection telemetry to attempt to assess which infostealers are most successful. These, unfortunately, come with their own issues. Since identifying the process as an infostealer is much easier than determining which specific stealer was used, we often see detection engines identify the malware as a “generic stealer” or try to guess the malware but occasionally get it wrong.

You might think the most successful malware will have no detections at all. However, in practice, there tends to be a cat-and-mouse game where high detections for malware result in malware developers modifying the malware to avoid detection. Security vendors who notice they’re missing a particular malware update their detection logic. This means the number of vendors that detect a certain malware varies over time, but the average across different malware families is fairly consistent. So, finding more detections for a specific malware probably means it’s showing up more worldwide, implying it’s more successful.

Considering that, we decided to look at multiple telemetry sources online to see how consistent the results were. Looking at the top five infostealers by number of uploads to VirusTotal,

Any.Run and malware bazaar during the month of February 2024, we get the following:

As we can see, the results are only consistent for the first three. The top are RisePro, RedLine and then StealC. LummaC2 and Vidar both appear in fourth and fifth places but also have a column where they don’t make it into the top five at all (in both cases, they’re sixth but relatively far behind). Raccoon ranks fourth on VirusTotal but doesn’t appear in the other top five sets. In MalwareBazaar, there were a mere two uploads of Raccoon in the entire month. Finally, PureLogs also only appears once in fifth place in the MalwareBazaar set.

Infostealer Techniques

In addition to cookie theft, infostealer malware often steals several other important browser files worth mentioning.

A “Local State” file might be the most important of these. Since cookies and other browsing data are considered sensitive information, the browser encrypts much of their content. There’s a problem, though, since the browser also needs to store the decryption key to access that data. That key is stored in the Local State file, so malware steals it too. The Local State file is protected via a Windows mechanism known as DPAPI. Still, unfortunately, this also has proven to be barely more than a speed bump when it comes to stopping malware from accessing the data in that file.

Another important file is the “Login Data” file. This file is pretty much what the name implies: the login data the browser stored. This will generally include things like usernames and passwords, meaning that threat actors can gain access even without a cookie anywhere MFA is disabled.

Like the Login Data file, another targeted file is called the “Web Data” file. This file contains saved form data used by the browser. While not explicitly meant for passwords, the file can contain them in some situations since passwords are generally entered as part of a form. Other sensitive data, such as credit card information, might also be saved in this file, which could be valuable to an attacker.

In addition to browser data, infostealer malware often targets a handful of desktop applications such as Telegram, Discord and Steam. And finally, certain stealers can also be configured to target any folder on the victim machines so they can end up stealing other sensitive documents as well.

Infostealer Examples

Now that we’ve seen how stealers work, let’s look at some examples. RedLine, in particular, is a relatively old stealer and fairly well-covered, so we will instead focus on RisePro, StealC and LummaC2.

RisePro

As we can see from the telemetry, RisePro is consistently the most prolific infostealer. It also appears to be over twice as common as all the other infostealers except RedLine. As such, we’ll hold it to a higher standard than the other stealers and focus on places where they seemed to mess up.

It’s common practice for malware to clean up after themselves. We often see malware delete various files they created, making it more difficult for researchers and incident responders to figure out what malware they’re dealing with. This holds for RisePro as well. We can see from the Procmon logs (Figure 2) how the malware extracts some data from the browser and copies it to a new file only to later delete the same file when cleaning up shortly after. However, RisePro does not treat all files the same way – some are missed. In particular, a file called “passwords.txt” that the malware saves in a subfolder of the temp folder isn’t deleted after the malware runs.

Figure 2: RisePro Copying Login Data from Chrome to Temp Folder Followed by Deletion

Aside from having bad manners and not cleaning up after yourself, this file is a serious problem for the malware to leave behind. Opening it up (Figure 3), we clearly see we’re dealing with RisePro Stealer. Putting up a huge banner in one of the files they leave behind makes it obvious to any researcher and incident responder that they’re dealing with RisePro. Worse still, even if they cleaned up, just writing their file like that can be easily detected by many EDR-type solutions to identify RisePro infections.

Figure 3: RisePro Banner in dropped passwords.txt file

StealC

StealC is another successful infostealer and has relatively good coverage. We’ll primarily focus on one feature of theirs which we found interesting. Many researchers develop and maintain configuration extractors for various malware. This is a pretty good way to identify malware and extract useful information, such as the C2 server used. In the case of infostealers, we can also see what browsers and other software the stealers were configured to target.

Because of the commonality of configuration extractors, some threat actors have begun to make efforts to prevent researchers from extracting configurations in various ways. In the world of ransomware, for instance, we’ve seen some malware, such as Egregor and ALPHV, which require a specific command line argument to extract their configurations. That way, even if a researcher has the sample, it’ll be of limited use without knowing the command line argument.

Infostealers, however, often need to run automatically and can’t rely on a threat actor to manually put in the required argument to run. StealC uses a partial solution to the configuration extractors in infostealers, which seems unique. While much of the configuration is in the malware itself, the targeted application list is stored on the server side. The malware then sends a request to get that part of the configuration (Figures 4 and 5). This, of course, can only ever be a partial solution since it requires the C2 address itself to be stored in the malware for the malware to be able to send the request to get the rest of the configuration.

Figure 4: Base64 encoded response from StealC C2 Server

Figure 5: Decoding of configuration downloaded by StealC malware

It’s unclear if the reasoning behind this feature is to avoid config extractors or if the purpose was to allow for more flexibility when modifying targets for the malware. For instance, if a new browser comes out, other stealers will need to compile a new executable and distribute it to new victims. At the same time, StealC might be able to modify the config on the server and immediately affect all victims that have been recently infected with their malware.

LummaC2

LummaC2 isn’t quite as common as the other stealers we’ve looked at. They didn’t even end up in the top five on VirusTotal. However, they’re definitely worth looking at, as the group seems to be relatively innovative and flexible with their approach to malware. We’ve seen three recent examples of this in the past six months. The first was the use of trigonometry as an anti-sandbox measure. Then, when the MultiLogin issue in Google Chrome was discovered, Lumma was the first group to adopt this technique to “recover” stolen cookies. Finally, the creative distribution method which showed up on Reddit when they infected a computer via “chargeable adult tools.”

The group is somewhat reminiscent of an early LockBit ransomware syndicate, which was smaller but more innovative and flexible than its competitors in the early days. But, four years later, not only were they in first place with respect to the number of victims on their leak site, but they also had almost five times the number of victims in second place. Seeing the similarity, we believe it’s worth keeping an eye on this group as they may end up following a similar path and become the most successful (by far) infostealer group around as well.

Mitigations

As we’ve seen earlier, most infostealer malware spreads via some mode of user interaction. Because of this, it’s crucial to raise user awareness on the matter. Many organizations regularly run phishing simulations to keep employees alert when reading emails, and this is a good start. But it’s also advised to raise awareness of the risks of downloading software from ads, pirated software and game cheats. It would also be a good idea to have a policy preventing employees from using their personal email on company machines, as this could allow attackers with access to personal accounts to sync access to company services, as we saw in the recent Okta breach. EDRs and EPM-type solutions should also be deployed to prevent malware from being able to run and access the cookies in the first place.

Finally, the CyberArk Secure Browser can be configured to operate in two states where the cookie is never saved on disk and only used in real-time, in memory, to reduce the risk of any malware present on the endpoint to compromise. In addition, the cookies/session tokens can be saved within the CyberArk cloud infrastructure, adding another layer of security and protection. As hinted earlier with StealC, we can assume that stealers won’t target something like CSB for a while simply because the browser is new. But, even once they start to target cookies from that browser, with these configurations, malware still won’t be able to steal the cookies from the endpoint.

Summary

Even today, with so much focus on protecting digital identities, malware still has a common and relatively easy way to bypass most types of protection. With the cybercrime market flooded with everything from phishing kits to infostealing malware to logs stolen by infostealers, it’s incredibly easy for a threat actor to simply buy any step in the process and cause tremendous damage to an organization. As such, staying vigilant and maintaining the best security practices to protect against credential and cookie theft is essential.

Ari Novick is a malware analyst at CyberArk Labs.