In this Malware Analysis Spotlight, we will assume the role of a threat researcher tasked with analyzing, categorizing, and classifying an unknown malicious sample. We will analyze the unknown sample in a malware sandbox to jumpstart the process.
Our unknown sample in this Spotlight is the information stealer, Raccoon (also known as RaccoonStealer). Active since 2019, Raccoon targets multiple applications including browsers, email clients, and cryptocurrency wallets. Victims of Raccoon are often infected through phishing campaigns or exploit kits. This sample was first observed in-the-wild in February 2021.
Follow along with us on our journey to classify this sample by viewing the VMRay Analyzer Report.
Malware Classification Case Study
Before analyzing the behavior of the sample in detail, let’s have a look at the triggered VMRay Threat Identifiers (VTIs) to get an instant overview of the observed behavior. In Figure 1, we can see multiple VTI matches for ‘Data Collection’ and ‘Discovery’ have been triggered, which provides the classification “Spyware”. This is an indicator that the sample might be some kind of information stealer or at a minimum have data exfiltration functionality.
This assumption is supported by two other triggered VTIs. To steal data from targeted applications, it needs to search and access sensitive files of these applications. Furthermore, information stealers usually extend the gathered data with information about the system. Both behaviors can be seen as a discovery of the infected system.
After all the data has been gathered it needs to be transmitted to the operator which usually involves a network connection. Interestingly, the overview of VTIs reveals that the sample drops at least one PE file. Because the samples can execute or load these PE files, the next step is to look at the monitored processes.
Scrolling down to the process graph, we can see three processes relevant to the analysis are observed. The sample creates a new process of cmd.exe which in turn starts a new process of timeout.exe (Figure 2). Because the sample does not modify the process of cmd.exe directly (e.g. by process injection) the behavior is controlled either by a script written on the filesystem or by its command-line arguments.
To get more information about the cmd.exe process, we can navigate to the “Behavior” Tab. We can see in Figure 3, the sample invokes cmd.exe with command-line arguments. It uses the application timeout to delay its execution, which is the reason the third process is spawned and deletes the sample file afterward. This is a common technique for self-deletion and is typically used to delete traces of infection.
Now that we’ve identified cmd.exe is used for self-deletion, we can focus on the first process. Because the sample creates at least one PE file but does not execute it, let’s have a look at the “Files” tab to inspect the sample’s activity on the filesystem. Here it is noticeable that the sample drops multiple clean DLL files (Figure 4) and a malicious zip archive named “aR8pJ3hC8rG2sT.zip”.
The filenames of the DLLs indicate that they provide additional abilities to access sensitive data of applications. For example, the file sqlite3.dll could provide the functionality to read sqlite3 databases and mozglue.dll to read data of Mozilla products such as Mozilla Firefox.
The usage of third-party libraries indicates that the sample is not equipped with these capabilities on its own but relies on the use of DLLs to fulfill its data exfiltration purpose. Because it is not guaranteed that these libraries are present on the infected system, they have to be either embedded in the sample or downloaded from an external server.
In addition to the above-mentioned dropped clean DLLs, a zip archive is created that contains multiple files. Given the filenames, it seems that those files contain the data that is exfiltrated (Figure 5).
Furthermore, the sample does not process these files individually (e.g. send them file by file) but is compressed to a zip archive named “v8iylu0Ytni.zip”. We can see the relationship between the zip archive and its embedded files in the “Files” tab by looking at the category (“Embedded File”) and the parent file entry.”. This is a common technique as various malware families stage the collected data before exfiltration. It is covered by MITRE-T1074.001 and we mentioned this technique in for example our Ursnif analysis as well.
Let’s summarize our findings so far. We can suspect that the sample requires third-party libraries to reach its goal. Those libraries have to be either embedded in the sample itself or the sample needs to download them from an external server.
Given the findings regarding the filesystem activity, it seems the sample stores gathered information in a zip archive named “v8iylu0Ytni.zip”. We have seen multiple VTIs indicating that the sample does data exfiltration but at the moment we do not know how it transmits the data.
So before we take a closer look at the content of the zip archive, let’s inspect the observed network activity. The sample performs five HTTP requests in total, one to telete[.]in and the four to yearofthepig[.]top (Figure 6).
By inspecting the data of the two GET requests, we can see that it downloads the required libraries from yearofthepig[.]top. The dropped file sqlite3.dll is downloaded by the first GET request (Figure 7 left) and additional libraries are downloaded in form of an archive (“aR8pJ3hC8rG2sT.zip”).
After both have been downloaded, the sample extracts then the zip archive to “%AppData%” (Figure 7 right, Figure 4). Because these libraries are PE files, this behavior triggers the VTI regarding dropped PE files and excessive file creation.
The data of the last POST request shows that the sample sends a zip archive, indicated by the extension in the filename and the characters “PK” (Figure 8 right). We can now easily verify that the send zip archive is the archive that contains the gathered information by comparing the data.
After we have found out that the sample performs data exfiltration, including previous staging, and the destination of the data transmission, we can take a closer look at the collected data. This allows us to get a brief impression of the data exfiltration ability of the sample similar to the triggered VTIs.
The archive contains four files that indicate the collected data includes information about Outlook emails, Mozilla Firefox URLs, and cookies (Figure 9 left). Another interesting file seems to be the file “System Info.txt” as the content of this file could reveal further targeted applications or collected information about the system. By looking at its content, we can spot immediately the malware family which seems to be Raccoon in version 1.7.2 (Figure 9 right). Additionally, the file contains statistics about the gathered information and data related to the network communication like the generated Bot_ID.
From here on, we can use our newly gained-findings to review external material published by other researchers. This improves our background of the family and we can interpret the observed behavior better to verify the classification and take countermeasures.
Conclusion
Analyzing a malware sample is a continuous process in which assumptions are made based on previous partial results and confirmed or rejected by further research. A good trait of a threat researcher is to remain curious during the analysis and to satisfy this curiosity during the analysis.
Equipped with the right set of tools, analyzing malware can be an educational yet enjoyable journey.
IOCs
Sample
f10cbc7f10b3978cbc4f00b7d065c705e79763c4cd43626f51dac380b0c6e1df
Packed third-party Dependencies
4cfada7eb51a6c0cb26283f9c86784b2b2587c59c46a5d3dc0f06cad2c55ee97
C&Cs
yearofthepig[.]top
Telete[.]in
References & Additional Resources
https://malpedia.caad.fkie.fraunhofer.de/details/win.raccoon
https://lp.cyberark.com/rs/316-CZP-275/images/CyberArk-Labs-Racoon-Malware-wp.pdf
