Understanding Stealer Logs and Its Role in Security Testing — Part 1
A Thorough Exploration of Stealer Logs: What, How, and Case Study
بسم الله الرحمن الرحيم
This write-up is a part of HakTrak Cybersecurity Squad’s research activity.
Abstract
Stealer logs, which contain sensitive information such as credentials and cookies, are something we cannot overlook in security testing. These logs often provide attackers with an initial foothold, allowing for deeper access to a target or offering a more thorough understanding of the target under examination.
In this article, we will explore the fundamental concepts of stealer logs, the types of data they capture, and how they can be used to analyze the initial IoC in some cases. Additionally, we will present a case study to illustrate how testers can effectively leverage stealer logs in security testing.
I. A Brief Overview of Stealer Logs
In one of our published write-ups, we emphasized that in security testing, having access to credentials can be a key factor that differentiates between surface-level assessments and truly comprehensive testing. For instance, we managed to gain super admin access after obtaining credentials from a user, revealing vulnerabilities that previously “appeared” to be hidden.
It’s undeniable that some applications may seem secure from the outside, but the reality can be vastly different once access with various privileges is obtained. With the use of credentials, testers can explore deeper into the system, uncover hidden features, and reveal vulnerabilities that might otherwise remain unnoticed.
So, what do testers typically do to gain access? As a recap from one of our articles, here are several common methods that can be used to achieve this:
- Crawling through files and directories within the application.
- Looking for login credentials within collaboration platforms such as GitHub or Atlassian products.
- Trying to determine if default credentials (like, username and password) are being used.
- Conducting general tests, such as observing responses during random login attempts, executing basic injections, and similar techniques.
- Attempting to register an account (if applicable) to gain deeper insights into the target’s features, which may help in identifying potential vulnerabilities.
However, a question might arise, what if these methods don’t yield results? Is there another approach that might assist testers in gaining access? The answer is yes, there is. One additional step that can provide a significant advantage is reading stealer logs. Now, some of you might now be wondering, what exactly are stealer logs?
1.1. What is it?
Simply put, stealer logs are detailed records containing sensitive data such as credentials, passwords, credit card numbers, and other personal information. This data is stolen from devices infected by malicious software known as “stealer malware” or “stealer,” which are specifically designed for the purpose of theft.
In recent years, stealer logs have become increasingly common and traded online, making it easier for individuals with minimal technical skills to engage in cybercrime. These logs are often sold on dark web marketplaces and underground forums, providing easy access for criminals to exploit the stolen data.
Given this context, understanding stealer logs becomes essential for anyone involved in cybersecurity. These logs represent a significant threat vector and provide valuable insights that can aid in identifying vulnerabilities, enhancing defenses, and improving overall security posture.
1.2. How the Stealer Malware Infects Users?
Before stealer logs can be generated, the stealer malware must first find its way onto a user’s device. This infection often occurs due to risky online behaviors, such as downloading cracked software, using cheats in games, visiting gambling sites, or accessing explicit content. These activities can lead users to click on links or download files that seem harmless but are actually embedded with malware. In these scenarios, the stealer malware is often bundled with the desired software or disguised as something legitimate, tricking the user into installing it.
Infection can also start with social engineering tactics like phishing, where attackers send emails containing malicious attachments or links that, when clicked, download and execute the stealer malware. And another common infection method involves users unknowingly downloading and installing malware by visiting compromised websites. Once the stealer is on the system, it often disguises itself as legitimate software, allowing it to operate undetected while quietly gathering data.
Outside of exploiting online behaviors, attackers can also manually deploy stealer onto a target system by compromising vulnerable systems using various techniques. Once inside, they can install the malware directly, avoiding the need for user interaction and gaining more control over its deployment.
1.3. What Information Is Stolen by Stealers?
Stealer malware is designed to capture a broad spectrum of sensitive information from infected devices. Most data commonly targeted includes information stored in web browsers, such as:
- URL History — this includes records of websites the user has visited.
- Cookies — small pieces of data used to maintain user sessions and track browsing activity.
- Usernames and Passwords — stored login credentials for various accounts.
- Autofill Data — this encompasses information that the browser automatically fills in, such as addresses and payment details.
In addition to browser data, many stealer programs are also capable of collecting other types of information from the device, including:
- Desktop Screenshots — images of the user’s desktop.
- Process Lists — information about currently running processes on the device.
- Generic Device/User Information — details such as the desktop or server name, hardware or machine ID, operating system used, installed antivirus software, IP address, and geographical location (country and city).
In general, the following shows the sample structure of information typically found in stealer logs:
While this structure is typical, it’s important to recognize that some stealer malware variants may gather even more extensive data, such as:
- Session data or key configurations from VPN applications.
- Credentials, configuration files, and other significant data from password managers, email clients, and FTP clients.
- Wallet files from various cryptocurrency wallet applications.
As seen, the data covered in stealer logs is quite extensive, and it’s undeniable that such data opens significant opportunities for attackers to use it as a vector for breaching a system. This must be one of the critical considerations for testers, as this vector should not be overlooked.
By utilizing information such as login credentials, session cookies, and other data collected in these stealer logs, testers can gain an in-depth view, potentially uncovering security flaws that might otherwise be missed by traditional testing methods.
In the next chapter, we will explore how the logs generated by stealers can be strategically used in security testing and how the right approach can enhance the effectiveness of such testing.
II. Getting Start with Stealer Logs in Security Testing
As discussed previously, the extensive range of data captured by stealer malware highlights its potential as a significant vector for attackers. Therefore, utilizing this data is essential for conducting effective security testing.
2.1. The First Step in Leveraging Stealer Logs
Let’s say we have a log in .txt format related to the target being tested, so one of the initial steps that testers should take is to transfer the data from .txt files to a more readable format. A basic tool that can assist with this process is the “Get Data (Power Query)” feature available in Microsoft Excel.
So, what will be imported through this feature? The simple thing to be imported is a file containing credentials (usually named password.txt, all passwords.txt, and so on).
Specifically, these files will have 4 different parameters such as:
For example, here is a sample from one of the stealer logs that contains all four of those parameters:
In this stage, the next step we need to take is to use a semicolon (;) to separate one parameter from another, and then to separate one URL from another by placing each on a new line.
Here is an illustration of the parameters and URLs that have been separated from one another:
But, why use a semicolon? Essentially, there is no strict guideline for choosing a “delimiter” (as it’s called in Microsoft Excel), since we can create our own according to our preferences. In this case, we used a semicolon because, at first glance, it appears that the URLs in this stealer log rarely use semicolons.
Please note, avoid using the following characters as delimiters:
- Colon: This is used both as a separator in the part following “http/https” and to denote parameter values in the stealer logs.
- Comma: Some people may use this symbol as part of their password. To avoid confusion after separation, it’s better to avoid using a comma as a delimiter.
- Equals sign: This is commonly used to set parameter values in a URL.
So, after setting it up, be sure to select the “Based on entire data set” option under “Data type detection”. If the default option is selected, Microsoft Excel will only take the first 200 rows, while in many cases, the adjusted stealer log can contain more than 500, or even thousands of rows.
When all these parameters have been properly separated into four columns, the next step is simply to “load” the data so that everything is transferred into the spreadsheet:
By importing the data using this feature, at least, testers will have greater flexibility to analyze the information contained within.
2.2. Analyzing the Imported Data and Common Pitfalls
Once the data has been imported, testers can proceed with the following basic steps:
- Filter the data based on domains related to the target.
This is intended to simplify the validation process for each credential found related to the target we are testing. The reason is that it’s important to focus on the most relevant data first, ensuring we don’t overlook any immediate opportunities or obvious entry points in the analysis. - Attempt to log in using the discovered credentials.
After filtering the data, testers should attempt to log in to the relevant systems using the credentials found in the stealer logs. However, if this step does not succeed, we can explore alternative approaches. - Calculate the frequency of password usage.
Analyzing the frequency of password usage across different accounts can reveal patterns in user behavior, such as the reuse of passwords across multiple platforms.
The three steps mentioned above are the most fundamental aspects that testers need to consider. Often, by leveraging these steps, testers can gain direct access to the targeted system, regardless of the level of privilege obtained.
However, it’s important to remember that several factors can cause the testing results to fall short of expectations, such as:
- Outdated Information. Sometimes, stealer logs from a certain month or year might reappear, giving the impression that the log is still up-to-date. In reality, these logs may have been recollected by a threat actor and re-released to make them seem more valuable by artificially increasing their size or for other reasons related to data collection tactics.
If this is the case, testers might find that the credentials no longer work during validation, possibly due to internal policies like credential rotation every 90 days.
- Early Detection by Companies. There is also the possibility that a company has detected the credential leak earlier and taken prompt action to secure the affected users.
2.3. Utilizing Additional Data from Stealer Logs
In addition to credentials, stealer logs can provide valuable insights through other types of data, such as cookies and URL history.
2.3.1. Cookie Logs
Can someone log in using cookies and gain authorization from an application? The answer is yes, it is indeed possible.
Basically, cookies are small data files stored by browsers that contain information about user sessions and preferences. Since these cookies often contain session tokens or authentication details, they can be used to gain unauthorized access to an application if specific conditions are met. For instance, the session associated with the cookie must still be active (not expired), or the application must not have mechanisms that frequently invalidate or regenerate cookies.
2.3.2. URL History
Are there other aspects in stealer logs that can be used for login? Yes, there are indeed other aspects.
In addition to credentials and cookies, the URL history found in the logs can also be analyzed. Because basically, URL history may contain hardcoded tokens embedded in the URLs by the target applications. If these tokens are also still valid or have not been frequently invalidated or regenerated (similar to the conditions discussed for cookies), we may obtain access to the target application without needing additional credentials.
In other situations, URL history can be leveraged to exploit a broken access control issue by utilizing parameter values in the URL that are difficult to guess, such as UUIDs — an approach that we will explore in this discussion.
III. Identifying IoCs from Stealer Logs
After reviewing the entire discussion from previous chapters, we might wonder, “can we identify the location of the malware that has infected the user’s device?” The simple answer is that while not all stealer logs explicitly provide clear clues that serve as indicators of compromise (IoCs), there are instances where a stealer provides information that can help the team to conduct a deeper investigation.
Some common clues found in stealer logs that can serve as indicators include:
- Name of the malware along with its location that triggered the data exfiltration to the C2 server.
- The list of processes or applications running at a specific time that could be identified as part of the malware or malicious tools.
- The URL history that could lead to malicious sites or domains known to be C2 servers.
- The unusual file paths or paths related to malware files.
3.1. Sample Clues
Suppose we discover a user infected by a stealer. It’s important to note that one basic piece of information that can help us obtain clues is from the “UserInformation.txt” file or similarly named files (as the file name can sometimes vary). Below is an example of the content of such a file:
From these kind of file, we indirectly obtain information about a path and file name that appear quite unusual. One of the easiest ways to determine whether this file is related to malware is to search for it on search engines or on malware analysis sites such as Any.run or VirusTotal.
In this example, the file name is `MSIUpdaterV131.exe`, and it has a path named `MSIUpdaterV131_494d7bdd0cd2abc364b692ce8d81347c`.
Upon investigation, we find that this path name is closely associated with a type of stealer malware, as indicated by information from Any.run.
During the analysis process, we can further investigate by looking into other common names used by related malware, examining the executed processes, connections made, and the hash values of the malware itself.
Additionally, as another reference, we can use this hash value in VirusTotal to obtain further information.
And, of course, many more details can be obtained from the activities of the related stealer.
Basically, these details, in addition to confirming the presence of malware on a device, can also assist system owners in integrating with automated analysis tools (such as TI feeds) to accelerate and refine the identification process, as well as enhancing security perimeters for prevention of similar incidents in the future.
3.2. Challenges in Identifying IoC from Stealer Logs
Although stealer logs can provide opportunities to obtain indicators of compromise (IoC), there are several challenges to be aware of:
- Assumptive Nature. Unlike digital forensic activities, which generally have clear supporting evidence (such as log hosts, log perimeters, policies, rules, roles, etc.), analysis based on stealer logs often relies on assumptions. Therefore, the information obtained from stealer logs is only an initial step intended to assist the team in further analysis.
- Accuracy Limitations. Data in stealer logs may be outdated or not relevant. This requires in-depth verification to ensure that the data used is still accurate and reliable.
IV. Case Studies
Having covered the fundamental steps for processing and analyzing stealer logs, along with the potential challenges, let’s explore how these logs are applied in real-world situations. Below are several case studies that illustrate how stealer logs can be used in security testing and reveal significant vulnerabilities.
Given that some of the case studies we are presenting have fairly lengthy narratives, we have decided to separate the more complex cases into an upcoming article. For this instance, we will focus on the simpler case study.
4.1. Case Study 1: Exploiting UUID-Based Broken Access Control Using URL History from Stealer Logs
At one point, we discovered a broken access control issue in a private program that was quite intriguing, because the vulnerable parameter (using the GET method) employed a UUID as its value.
This is interesting because UUIDs are specifically designed to make it difficult for anyone to guess values related to user IDs, transaction details, or similar sensitive information.
Thus, a reasonable question may come to mind: “Can the broken access control issue in a parameter using UUIDs be dismissed simply because the value is hard for an attacker to guess?”
Well, in practice, this issue cannot be ignored, given the possibility that other vectors might expose the UUID value. In this brief case study, we will show that one such vector not only relates directly to the application but can also be accessed through users affected by a stealer.
4.1.1. The Reporting Process
Returning to the story, did this reporting situation go smoothly? Initially, it didn’t. As is often the case, the program owner assumed that using a UUID alone would sufficiently complicate an attacker’s efforts to guess the value.
At that time, they asked how we could exploit the broken access control issue for other users, given that we were using our own UUID (this question indirectly granted us permission to access other users’ data). We then demonstrated that we could easily obtain the UUID value by examining the URL history of customers infected by stealer malware.
After demonstrating how we obtained the UUID values, the program owner initially further responded by stating that if a user’s device is compromised by a stealer, the broken access control issue related to UUIDs “might seem” irrelevant, as the account could be fully taken over anyway.
This reasoning, however, overlooked several critical points, because:
- First, just because a user’s device is infected with a stealer doesn’t mean they will never change their credentials. They may receive alerts — like those from browsers warning of compromised passwords — prompting them to update their credentials. Additionally, not all stealer malware has persistent access to a device. This means that, over time, credentials could become invalid, especially if session tokens are periodically regenerated.
- Second, the application offered more than one login method, namely using a username (email/phone number) and password, or a password-less approach (where the customer provides a phone number and receives an OTP for login). If the customer opts for the passwordless method, the assumption that an account compromised by a stealer would automatically be fully taken over is not valid.
To sum up, the report was validated, and we were awarded a bonus for identifying this issue.
4.1.2. Lesson Learned from this Case Study
Reflecting on this case, we can draw several lessons:
- Utilizing UUIDs in the app does not inherently make a feature immune to attacks, even if the UUIDs are challenging to obtain. It is crucial to implement robust access controls to ensure security, regardless of the complexity of the ID values.
- In one of the discussions on Bug Bounty Report Explained, it was pointed out that another potential attack vector could be exploitation by a former employee who no longer works for the company.
- A comprehensive understanding of the target being tested is important for effectively identifying potential attack vectors.
V. Preliminary Key Takeaways
While we’re not yet at the conclusion of this article series — since we will be discussing several case studies in future posts — it’s worth taking a moment to reflect on some key takeaways from what we’ve covered so far.
5.1. For System Owners:
- Gaining a thorough understanding of their system and being aware of potential risks is essential. This insight helps identify possible security vulnerabilities before they become a problem. As the saying goes, “while defenders must protect everything, an attacker only needs to find one weak spot”.
For instance, some companies implement VPN technology to grant employees access to intranet assets. Unfortunately, many of them overlook the fact that a VPN can become a new entry point for attackers, leading them to skip the implementation of additional security measures, such as whitelist access, multi-factor authentication, or other perimeter defenses that monitor activity. Some of them may not realize that while attackers once had to bypass various physical barriers to access intranet assets, today they can exploit vulnerabilities remotely, often by taking advantage of an employee’s mistakes — such as leaving credentials exposed or if an employee falls victim to stealer malware.
What we want to emphasize is that, while the convenience of new technologies is a positive aspect, it’s important to recognize that implementing any new technology also requires careful attention to security. This means that, alongside the benefits, appropriate security measures must be put in place to address potential risks.
- Having a clear distinction between assets accessible via the internet and those restricted to the intranet is important to minimize exposure to the public. Additionally, separating assets into critical and non-critical zones can be a prudent step for enhancing security. This approach is considered to be relatively cost-effective, because it prioritizes critical assets, which are often primary targets for attackers, and ensures they receive the most robust protection.
- It is advisable for companies to consistently monitor for credential breaches, as this is crucial for defending against threats like stealer malware. Regular monitoring helps identify and address potential security risks before they escalate.
5.2. For End-Users:
- Be cautious of downloading applications, games, or media from untrusted sources, and avoid interacting with unclear or dubious advertisements. Offers for cracked software, pirated movies, or suspicious ads can often be gateways for malware. Stick to reputable sources and avoid engaging with suspicious offers or links.
- Basic security practices should be followed when using computers or accessing company systems. This includes using strong and unique passwords, and being cautious when clicking on links or opening email attachments. Even though end-users may not manage the company’s IT systems directly, their actions can still impact overall security.
- Passwords should be regularly updated, and it is important to avoid using the same password across multiple accounts. Any suspicion of compromised credentials should be reported to the IT department immediately. Proactive attention to personal security helps protect both individual information and company data.
Well, we’ve reached the final part of this section. In the next article, InshaAllah we’ll explore more case studies we’ve encountered.
REFERENCES
- SOCRadar, “Stealer Malware 101: Understanding the Different Variants and Families,” 25 January 2024. [Online]. Available: https://socradar.io/stealer-malware-101-understanding-the-different-variants-and-families/.
- A. Mukherjee, “How Stealer Malware Puts Your Credentials at Risk,” 3 July 2023. [Online]. Available: https://www.threatintelligence.com/blog/stealer-malware.
- Packetlabs, “What is InfoStealer Malware and How Does It Work?,” 15 May 2024. [Online]. Available: https://www.packetlabs.net/posts/what-is-infostealer-malware-and-how-does-it-work/.
- S. Sharma and A. Kumar, “Statc Stealer: Decoding the Elusive Malware Threat,” 8 August 2023. [Online]. Available: https://www.zscaler.com/blogs/security-research/statc-stealer-decoding-elusive-malware-threat.
- CYFIRMA, “Kematian-Stealer : A Deep Dive into a New Information Stealer,” 06 July 2024. [Online]. Available: https://www.cyfirma.com/research/kematian-stealer-a-deep-dive-into-a-new-information-stealer/.
- A. Tomi and W. A. Prabowo, “XSS to Account Takeover — Bypassing CSRF Header Protection and HTTPOnly Cookie” 28 October 2019. [Online]. Available: https://mastomi.id/articles/2019-10/xss-to-account-takeover
- G. Niedziela and D. Day, “Are UUID-based IDORs valid bugs?” 23 August 2024. [Online]. Available: https://www.youtube.com/shorts/ONiXQRQHCEk.
- https://virustotal.com/
- https://any.run/
