Raccoon is a malware family that has been sold as malware-as-a-service on underground forums since early 2019. In early July 2022, a new variant of this malware was released. The new variant, popularly known as Raccoon Stealer v2, is written in C unlike previous versions which were mainly written in C++.
The Raccoon Malware is a robust stealer that allows stealing of data such as passwords, cookies, and autofill data from browsers. Raccoon stealers also support theft from all cryptocurrency wallets.
In this blog, ThreatLabz will analyze Raccoon Stealer v2 in the exe format, and highlight key differences from its predecessors. The authors of the Raccoon Stealer malware have announced that other formats are available, including DLLs and embedded in other PE files.
Raccoon v2 is an information stealing malware that was first seen on 2022-07-03. The malware is written in C and assembly.
Though we noticed a few new features in the newer variant as mentioned below, the data stealing mechanism is still the same as is seen in its predecessor:
We have noticed a significant change in the way list of command and control servers is obtained. The Raccoon Malware v1 was seen abusing the Telegram network to fetch the list of command and control servers, whereas the newer variant has abandoned the use of Telegram. Instead, they use a hardcoded IP address of a threat-actor-controlled server to fetch the list of command and control servers from where the next stage payload (mostly DLLs) is downloaded.
The analyzed file has debug data intact. According to the Debug headers compilation date was Thursday, 26/05/2022 13:58:25 UTC as shown in Figure 1.
Figure 1: Raccoon v2 Debug Headers
We have also seen a change in how Raccoon Stealer v2 hides its intentions by using a mechanism where API names are dynamically resolved rather than being loaded statically. The stealer uses LoadLibraryW and GetProcAddress to resolve each of the necessary functions (shown in Figure 2). The names of the DLLs and WinAPI functions are stored in the binary as clear text.
Figure 2: Raccoon v2 dynamic resolution
List Of Loaded DLLs
Raccoon v1 did not employ dynamic resolution for used functions, therefore packed samples were often observed in the wild to evade detection mechanisms. Conversely, Raccoon v2 is often delivered unpacked. Figure 3 shows the imported DLLs for raccoon v1.
Figure 3: Raccoon Stealer v1 imports (unpacked)
Once resolution of functions is done, the stealer will run its string decryption routine. The routine is simple. RC4 encrypted strings are stored in the sample with base64 encoding. The sample first decodes the base64 encoding and then decrypts the encrypted string with the key ‘edinayarossiya’. This routine is followed for all the strings in function string_decryption(). The 'string_decryption' routine is shown in Figure 4.
Figure 4: Raccoon v2 String Decryption Routine
Previous versions of Raccoon Stealer did not encrypt string literals other than hard coded IP addresses. The Raccoon v2 variant overcomes this by encrypting all the plain text strings. Several of the plaintext strings of Raccoon v1 are shown in Figure 5.
Figure 5: Plaintext Strings In Raccoon v1
After manual decryption of the Raccoon v1 sample strings, the following (Figure 6 and Figure 7) strings were obtained in plaintext format.
Figure 6: Raccoon v2 Decrypted Strings
Figure 7: Raccoon v2 Decrypted Strings
The command and control IP addresses are saved in the malware and follow the same decryption routine but have a different key, 59c9737264c0b3209d9193b8ded6c127. The IP address contacted by the malware is ‘hxxp://51(.)195(.)166(.)184/’. The decryption routine is shown in Figure 8.
Figure 8: IP Address Decryption Raccoon v2
The encrypted command and control IP Address can be easily decrypted by using public tools such CyberChef as shown in Figure 9.
Figure 9: Raccoon v2 IP Address (via cyberchef utils)
This technique is common between both versions of the malware. Figure 10 shows the same routine employed in Raccoon v1.
Figure 10: Raccoon v1 setting up overhead before IP Address decryption
Once all the overhead of setting up the functions and decryption of the strings is done, the malware will perform some checks before contacting the command and control server to download malicious DLLs and exfiltrate information.
Before executing the core of the malware, certain checks are made to understand the execution environment. This includes making sure the malware isn't already running on the machine. Further the malware also checks if it's running as NT Authority/System.
The malware gets a handle on mutex and checks if it matches a particular value or not. If it matches, the malware continues execution.
This technique is used to make sure only one instance of malware is running at one time. Figure 11 depicts the Mutex check and creation for Raccoon v2, while Figure 12 depicts the similar procedure used in Raccoon v1.
Figure 11: Raccoon v2 Mutex Check
Figure 12: Raccoon v1 Mutex Check
By retrieving the Process token and matching the text "S-1-5-18," as shown in Figure 13, the malware determines if it is or is not operating as the SYSTEM user.
Figure 13: Raccoon v2 Enumerating Process Token
If running as a SYSTEM user, the enumeration of all the running processes is done with the help of fun_CreateToolhelp32Snapshot. Otherwise, the malware moves forward without the enumeration. Figure 14 shows the 'enumerate_processes()' function being called while Figure 15 shows the malware iterating over the Processes.
Figure 14: Raccoon v2 Enumerate Process
Figure 15: Raccoon v2 Iterating Process Struct
Once the malware is aware of the environment in which it's running, it starts to fingerprint the host. This malware uses functions such as:
Figure 16 depicts the malware retrieving the Machine ID from the registry key "SOFTWAREMicrosoftCryptography" via the RegQueryKeyExW and RegQueryValueExW functions. Figure 17 depicts malware using the GetUserNameW function to retrieve a username.
Figure 16: Raccoon v2 Fetching MachineID
Figure 17: Raccoon v2 Fetching Username
Figure 18: Raccoon v2: Username Buffer
After all this is done, the malware will enumerate information such as MACHINE ID and username and then send the data to the remote command and control server.
For this purpose, the malware creates a char string and starts appending these values to it. It starts by adding machine id and username. Figure 19 shows the built payload in buffer.
Figure 19: Raccoon v2: Fingerprinting Payload
Next, it generates and appends configId which is the rc4 encryption key.
Communication with command and control takes place over plain text http protocol. The previously decrypted IP address hxxp://51(.)195(.)166(.)184/ is used for command and control communication.
The malware contacts the list of previously decrypted command and control IP addresses (stored in local_3c). Since this malware only contains one command and control IP Address, the post request is only made to one as seen in Figure 20.
Figure 20: Raccoon v2: Command and Control communication
Command and Control URL
Figure 21: Raccoon v2 URL in buffer
Figure 22: Raccoon v2 Request Headers
Once the request has been made, the malware checks if the content body length is zero or not. If no content is received from command and control or the content body length is zero, the malware exits. This check is made because the exfiltration mechanism of the malware requires command and control to respond with a list IP Addresses to exfiltrate data to. In Figure 23, this condition can be seen along with the 'ExitProcess()' function call.
Figure 23: Raccoon v2 Verifying Response Content
The Raccoon v1 relied on the Telegram Bot API description page to fetch command and control IP addresses and establish connections. The recent malware variants (v2) from this family have started to hard-code IP addresses in the binary to achieve this task. Raccoon Malware v2 uses 5 hard coded IP addresses and iterates over them.
The malware relies on response from command and control server to down the required DLLs and decides on the next course of action.
As of the writing of this blog the command and control IP has died, thus analysis of traffic towards the host is not possible. ThreatLabz has previously observed that the command and control server provides information on where to download additional payloads from and which IP Address to use for further communications.
Figure 24: Raccoon v2 pinging extracted IP Address
Figure 25: Raccoon v2 DLLs that are downloaded
The malware uses a WINAPI call to SHGetFolderPathW to get a path to C:\Users\<User>\AppData and appends “Local” to it and uses it as the path to store stolen information before sending it to the command and control.
Figure 26: Raccoon v2 Storage Path In Buffer
IP contacted by the analyzed sample of Raccoon v2.
List Of Other IPs that act as an C2 for other samples can be found here.
Path Used By the Malware
Other samples observed in the wild of Raccoon v2.
Raccoon Stealer sold as Malware-as-a-Service has become popular over the past few years, and several incidents of this malware have been observed. The Authors of this malware are constantly adding new features to this family of malware. This is the second major release of the malware after the first release in 2019. This shows that the malware is likely to evolve and remain a constant threat to organizations.
We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox.
Figure 27: Zscaler Sandbox Detection
Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: