Redline Stealer Malware Static Analysis

Aaron Stratton
InfoSec Write-ups
Published in
8 min readAug 20, 2022

--

Introduction

This blog post will be a summary of findings from static analysis I recently performed on a sample of Redline stealer malware. This is not an exhaustive analysis of all of Redline’s capabilities, rather, it is an overview of some of the capabilities and methods which I found interesting.

According to Malpedia, “Redline Stealer is a malware available on underground forums for sale apparently as standalone ($100/$150 depending on the version) or also on a subscription basis ($100/month). This malware harvests information from browsers such as saved credentials, autocomplete data, and credit card information. A system inventory is also taken when running on a target machine, to include details such as the username, location data, hardware configuration, and information regarding installed security software. More recent versions of RedLine added the ability to steal cryptocurrency. FTP and IM clients are also apparently targeted by this family, and this malware has the ability to upload and download files, execute commands, and periodically send back information about the infected computer.” [1]

Technical Analysis

Link to sample: https://bazaar.abuse.ch/sample/12aec3ae5c5828745e45a86fedbb1ff4c0631855f8e76d63f0ac7fb554d5afc3/.

Starting off, the file command reveals that the binary is a .NET assembly. According to the Microsoft .NET documentation, “Assemblies form the fundamental units of deployment, version control, reuse, activation scoping, and security permissions for .NET-based applications. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. Assemblies take the form of executable (.exe) or dynamic link library (.dll) files, and are the building blocks of .NET applications. They provide the common language runtime with the information it needs to be aware of type implementations.” [2]

Figure 1. Output of file command.

.NET assemblies are essentially just the end result of coding and compiling a C# program. Luckily for malware analysts, C# binaries can be easily decompiled using a tool like dnSpy, meaning that they can directly view the source code, or at the very least, something very close to the source code. Before decompiling, though, I wanted to see what the pestudio tool could find in this binary. Right off the bat, I have an IP address, presumably for a C2 (Command & Control) server. Also of note, pestudio reveals that the binary’s name at time of compilation was “Implosions.exe”.

Figure 2. Possible C2 server IP address extracted from the binary as a plaintext string.

I took this IP address and searched for it on virustotal, and the communicating files section identifies the Implosions.exe filename. Thankfully, this particular sample already has a pretty high detection rate, meaning that in its current configuration, the malware will be caught by most antivirus products.

Figure 3. Communicating files section identifying the Implosions.exe file.

On the other hand, it is trivially easy to change a hash just by changing one bit, renaming a variable, adding a junk comment, etc. I renamed one method in the binary and recompiled it with the renamed method, and the SHA256 hash was completely different, and previously unseen by virustotal. This illustrates the importance of not over-relying on tools like virustotal.

Establishing C2 & Early Execution

Once I decompiled the binary in dnSpy, I went to the binary’s entry point, a class named “Program”, and I began my analysis. At the very top, I noticed another class named EntryPoint being passed as an argument to the Execute method, so I take note of that. The next thing I noticed is that the binary is executing decryption on four strings specified in the EntryPoint class: “Message”, “Key”, “IP”, and “ID”. The binary also decrypts the C2 IP address, and then attempts to establish a connection. Once the connection is established, Redline sleeps for 5 seconds before getting the ScanningArgs from the C2 server, probably in an attempt to evade behavior based detection.

Figure 4. Note the StringDecrypt.Decrypt method being used on the four strings from the EntryPoint class. Also note the Program.SeenBefore method.

Even though Redline uses the StringDecrypt.Decrypt method, it turns out that the strings stored within the EntryPoint class of this particular sample are not even encrypted at all. This was probably due to the threat actor(s) using this particular sample not being particulary concerned about OPSEC.

Figure 5. Plaintext C2 IP, ID, Message, and Key strings stored within the EntryPoint class.

Going back to the Program class, there is also a SeenBefore method (Noted in Figure 4). This method searches for a \AppData\Local\Yandex\YaAddon folder. If the folder exists, a false value is returned to the SeenBefore method, and if the folder doesn’t exist, it is created using the CreateDirectory method. The return value (true or false) is stored within the ScanResult data structure, and then returned to the threat actor at the C2 server, informing them of whether or not the infected machine has been infected with Redline stealer malware before. This would probably be of interest to cybercriminals for two main reasons. If the machine has been infected before, and information was stolen, then they won’t be able to sell that information in underground forums for a profit as easily. The second reason is that if a cybercriminal already stole credentials to multiple accounts, they may have changed credentials for some of these accounts, securing their continued access. Now a different cybercriminal comes along and steals what they think are valid credentials, but they’re actually invalid because they’ve been changed by the first cybercriminal.

Figure 6. SeenBefore method.

Information Stealing Functionality

Now that Redline has established a connection to the C2 server and performed some initial system enumeration, it needs to begin taking commands from the operator to implement its functionality. Referring back to the Program class (the binary’s entrypoint), Redline gathers the scanning arguments specified by the operator. These arguments are all derived classes from the ScanningArgs class, and they specify what actions the binary is supposed to take. For example, the threat actor could specify “ScanDiscord”, and Redline would then execute methods within the DiscordRule class.

Figure 7. Gathering scanning arguments.

Let’s continue with the Discord example. So the threat actor has supplied the ScanDiscord argument, and now Redline will execute the methods contained within the DiscordRule class.

Figure 8. GetScanArgs method within the DiscordRule class. Note the string specifying that the directory to be searched is %appdata%\discord\Local\Storage\level1db.

The GetScanArgs method specifies the folder that will be searched, being C:\Users\<USER>\AppData\Roaming\discord\Local\Storage\level1db. The GetTokens method then uses a regular expression (regex) to perform a pattern search. The developer of the malware added in some light obfuscation by adding “String” into the regular expression used to search for the discord tokens. I have highlighted the presence of this obfuscation in the figure below. When this is removed later in the execution, the regular expression is: [A-Za-z\d]{24}\.[\w-]{6}\.[\w-]{27}. This regular expression fits the exact naming pattern which discord tokens follow.

Figure 9. GetTokens method using regex to pattern search for discord tokens. Note the obfuscation attempt by adding “String” in random intervals between the regex characters.

The tokens are then stored in a file named “Tokens.txt”, and the file is read by the CopyFile method within the FileCopier class. Then the file data is copied into a shadow copy. These discord tokens are used for authentication to discord servers. A threat actor in possession of these tokens could attempt to authenticate to a discord server as if they were the victim user.

Figure 10. ScannedFile class, where the results from the FileCopier method are stored.

The FileCopier contains several different methods which all implement similar yet slightly different functionality relating to enumerating, copying, and reading files. These methods are used extensively throughout other classes and methods in Redline.

Figure 11. Methods within FileCopier class.

Another interesting, albeit not surprising, aspect of Redline’s functionality is its targeting of cryptocurrency wallet credentials. Redline searches for cryptocurrency wallet credentials and cookies to steal using a child class of the FileScannerRule named BrowserExtensionsRule.

Figure 12. Dictionary of cryptocurrency wallets targeted by the BrowserExtensionsRule. Note that this does not include all of the target crypto wallets. There are several more which did not fit in this screenshot.
Figure 13. GetScanArgs method specifying the Login Data, Web Data, and Cookies directories.

The AllWalletsRule class, a child class of the FileScannerRule class, uses the GetScanArgs method to specify that Redline will search for C:\Users\<USER>\AppData\Roaming\wallets\wallet.data to steal data from.

Figure 14. GetScanArgs method being used within AllWalletsRule class to specify what file to scan for, wallet.data. Note the light obfuscation by placing the string “asf” in random places throughout the strings actually being used, then removing it.

Redline also targets data from the Telegram desktop application. It does this using the DesktopMessangerRule class, also a child of the FileScannerRule class. Redline will search the C:\Users\<USER>\AppData\Telegram Desktop\tdata folder for files with any extension, indicated by the asterisk in the Pattern variable below. The \Telegram Desktop\tdata folder contains messages, images, and files from Telegram sessions.

Figure 15. Redline searches for Telegram desktop files stored in the tdata folder.

Redline is also capable of stealing information like passwords, cookies, autofill data, and credit cards from the Google Chrome browser. The C_h_r_o_m_e class contains methods such as ScanFills (autofills), ScanCC (credit cards), and ScanCook (cookies). The image below shows the ScanCC method. Redline reads the SQLite table named “credit_cards”, which Chrome uses to store credit card data that the user has decided to save for quick and easy online checkout. Once the credit_cards table has been read, Redline decrypts the data and parses it.

Figure 16. Redline reads the credit_cards SQLite database table and decrypts the data.

Redline is also capable of gathering a large amount of data about the infected system using the SystemInfoHelper class. The GetFirewalls method uses calls to ManagementObjectSearcher [3] to gather information about anti-virus, anti-spyware, and firewall products, as well as Windows OS security settings. Again, there is an attempt at light obfuscation by adding random strings in the middle of the actual strings that will be used.

Figure 17. Redline using ManagementObjectSearcher calls to gather information about various security products and settings on the system.

Indicators of Compromise (IOC’s)

SHA256: 12aec3ae5c5828745e45a86fedbb1ff4c0631855f8e76d63f0ac7fb554d5afc3

C2 IP: 188.34.194.107:44644

Conclusion

In conclusion, Redline stealer is a very capable, modular, info stealing malware used by cybercriminals in a large number of attacks. The malware can be delivered via multiple methods, and can compromise financial and personal data with little effort by the threat actor. It is just one piece of a growing trend in the cybercriminal underground known as “Malware-as-a-Service” (MaaS).

I hope you enjoyed this post, and that you’ll come back again! A follow and share would be super appreciated. Feedback is certainly welcome as well. I am by no means an expert malware analyst, so if there’s something I missed, got wrong, a technique I could use, etc., feel free to let me know. Thanks!

References

  1. (Malpedia, https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer)
  2. (Microsoft technical documentation, https://docs.microsoft.com/en-us/dotnet/standard/assembly/)
  3. (Microsoft technical documentation, https://docs.microsoft.com/en-us/dotnet/api/system.management.managementobjectsearcher?view=dotnet-plat-ext-6.0)

From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE!

--

--