- Researcher: Anandeshwar Unnikrishnan
- Editors: Suchita Katira & Hansika Saxena
An info stealer is malicious software (malware) that seeks to steal private data from a compromised device, including passwords, cookies, autofill information from browsers, and cryptocurrency wallet information.
Since the beginning of 2019, the Raccoon malware has been offered as malware-as-a-service on various cybercrime forums. The Raccoon Stealer group, however, was disbanded in March 2022 as a result of the death of one of its senior developers in the Ukraine-Russia war.
In June 2022, a new version of the Raccoon stealer was identified in the wild by the researchers at Sekoia. Initially, the malware was named “Recordbreaker” but was later identified as a revived version of Raccoon stealer. The developer of the Raccoon stealer (MaaS) is very active on underground forums, regularly updating the malware, and posting about the new feature builds on the forum.
The Malware
Raccoon samples have been spotted in the wild on numerous occasions. While some of these were protected by commercial code protectors like VmProtect and Themida, others were seen packed in popular community packers like Armadillo.
CloudSEK’s telemetry was able to pick up a very interesting Raccoon sample that employed very effective anti-analysis and anti-debugging techniques to foil analysis attempts. The sample covered in this report is unique in terms of the deployment of the malware.
The Malware Deployment
The packer used to obfuscate the stealer is specifically designed to perform the two main tasks:
- Identify sandbox and debugging
- Perform hooking in order to control transfer to the stealer
The Process of Anti Analysis & Anti Debugging
- For detecting sandboxed environments, especially virtual environments, the packer makes use of Read Time Stamp Counter (RDTSC), a very well known CPU instruction used to detect VM by calculating the time difference (delta) between two calls to RDTSC. RDTSC has also been observed, querying system information like the firmware information table to identify VMs.
- To prevent anti-debugging, the malware includes process-level debug checks and sets the main thread hidden from the debugger.
Malicious Hooks
The malware’s API trace provided a greater understanding of the internals of the packer, without having to spend much time in a debugger. A very interesting behavior found in the trace log is shown below.
- The threads in the current process are enumerated by using the following APIs:
- kernel32!CreateToolhelp32Snapshot
- kernel32!Thread32Next
- The threads are then opened and suspended.
- Once the threads are suspended, some memory is allocated and data is added to it.
- Finally, the memory protections are changed from RWX to RX.
The above sequence of operations is performed twice, and then the packer resumes the suspended threads.
The data written by the malware was retrieved by CloudSEK’s researchers with the help of instrumentation.
- As shown in the image below, a call was made to kernel32!WriteProcessMemory was intercepted to see the passed data. It is interesting to note that the lpAddress parameter in both calls points to ntdll.dll in the memory of the malware. A total of five bytes of data was written in the memory region of the loaded ntdll.
- The written data is a JMP (jump) instruction, followed by a specific address that points to one of the segments in the packer.
Hooking plays a major role in the stealer loading phase and the packer is hooking the following two APIs:
- ntdll!DbgUiRemoteBreakin – The hooked DbgUiRemoteBreakin will take the control flow to exit. This is another anti-debugging technique in which, the targeted API is used mainly by Windows debuggers to do a software break. Hence, the packer redirects the flow, which leads to the termination of the malware.
- ntdll!ZwProtectVirtualMemory – If the above doesn’t happen, the packer makes a call to ntdll!ZwProtectVirtualMemory and deploys the Raccoon Stealer v2 on the target system.
Experimenting with the return values of the kernel32!WriteProcessMemory call during analysis helped to confirm the hooking of ntdll!ZwProtectVirtualMemory, which is a crucial step in the infection process. Failure to hook ntdll!ZwProtectVirtualMemory causes the malware to terminate and the following warning to appear.
This behavior is not observed when the malware fails to hook ntdll!DbgUiRemoteBreakin, as the program doesn’t get terminated.
The Malware Execution
Dynamic API Loading
Once Raccoon Stealer is executed, APIs are dynamically loaded into the memory. These APIs are later used by the malware to perform malicious activities on the compromised machine.
String Decoding
After successfully loading the libraries, the stealer decodes all the strings in memory. The previous versions of the stealer used RC4 decryption to encrypt the strings.
However, the recent version uses a custom XOR-based encoding to encrypt the strings.
Russian Language Detection
The stealer calls the kernel32!GetDefaulLocaleName to retrieve the system language (locale name), and then checks it against the string “RU”. In case of a positive match, no logic is implemented for execution, which shows that the malware is still under development. In the future, we can expect the stealer to terminate itself after a match is found.
Mutex
After the locale name check, the stealer looks for any active malware samples, by calling kernel32.OpenMutexW. If an active malware process is found, the current malware execution is terminated, else a new mutex is created on the system.
Admin Check
Once the Mutex is created, Raccoon checks the privileges of the user process by following the steps below:
- Advapi32.OpenProcess is called to obtain a handle to the process token.
- Advapi32.GetTokenInformation is called on the acquired process token handle by passing TOKEN_USER as the value for TokenInformationClass parameter, which returns a user SID structure.
- The SID structure is converted to a string by calling Advapi32!ConvertSidToStringSidW.
- The SID string is compared with the value “S-1-5-18”, the SID value for Local/SYSTEM or members in the Local Admin group.
- If the user process is elevated, the value 0 is returned.
Process Enumeration
If the process is elevated, the processes running on the system are enumerated as shown below:
- Kernel32!CreateToolhelp32Snapshot is called by passing the flag TH32CS_SNAPPROCESS to include all processes running on the system in the snapshot.
- The Kernel32!Process32First and Kernel32!Process32Next APIs are used to walk through the snapshot which contains the information of processes running on the system.
It is interesting to note that the result returned (1/0) is not used anywhere by Raccoon. The main reason behind this may be the strong likelihood that the malware is still being actively developed, and some changes to the code of future Raccoon samples should be anticipated.
Also to Read Raccoon Stealer Malware Threat Intel Advisory
C2 Network
Attackers employ a set of tools and procedures known as command and control infrastructure, usually abbreviated as C2 or C&C, to keep in touch with compromised devices after the initial access has been gained. The Raccoon stealer calls home for the first time by sending a unique string to the C2. The string, for the communication, is crafted with the following information:
- Machine GUID retrieved from the following location in the registry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
- The username, fetched via the Advapi32!GetUserNameW API.
- The configuration ID, which is decoded using the RC4 key in some samples and a unique alphanumeric string in others.
C2 Configuration
The Raccoon stealer uses the following C2 identifier tags to control the behavior of the stealer.
| Identifier | Description |
|---|---|
| libs_ | Library PE/DLL to download |
| ews_ | Browser Extensions |
| wlts_ | Crypto Wallets Stealing |
| sstmnfo_ | Collects SystemInformation and list of Installed Applications |
| scrnsht_ | Takes Screenshot |
| tlgrm_ | Steals data from Telegram Desktop |
| grbr_ | Password Grabber |
| dscrd_ | Discord Stealer |
| ldr_ | Launches additional payloads like RATs |
| token | Unique identifier for tracing campaign |
Fetching Library
Once the stealer obtains the C2 configuration from the C2, it starts to parse the configuration, searching for the libs_ identifier to download the legitimate library files such as:
- ns33.dll
- msvcp140.dll
- vcruntime140.dll
- mozglue.dll
- freeble.dll
- softok3.dll
- sqlite3.dll
These are downloaded into the User\AppData\LocalLow directory and are not loaded into memory.
The malware loads the necessary DLLs into memory, during the information-stealing process, and dynamically resolves various functions. The images below depict the dynamic API loading from sqlite.dll and ns33.dll respectively.
Sysinfo Enumeration
Post fetching the libraries, a profile of the host is created and sent to the C2 as a “System Info.txt” file.
The stealer performs the host profiling only if sstmnfo_ identifier is present in the C2 configuration. Following information is enumerated in the host profile:
- Locale information, fetched from the system via the Kernel32!GetLocaleInfoW.
- Time zone information, fetched from the system via Kernel32!GetTimeZoneInformation.
- Product Name (OS), fetched from the registry.
- Architecture of the victim, identified by checking the presence of SysWOW64 directory.
- CPU vendor and model information, fetched by the CPUID assembly instruction.
- System information retrieved from the Kernel32!GetSystemInfo API.
- Memory information, fetched from the system via Kernel32!GlobalMemoryStatusEx.
- Display resolution, fetched from the system via User32!GetSystemMetrics
- Display adapters and monitors connected to the system.
- Installed applications via SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall.
Information Stealing
Browser Data
The malware steals information saved by web browsers in the local user’s AppData directory. The primary directories targeted are “User Data” and Profile .
The stealer is interested in the following browser data:
- Cookies
- AutoFills
- Stored passwords
- Stored credit card information
Like any stealer, Raccoon performs the following operations to steal the browser data:
- It retrieves the target SQL database file stored by the browser. A few of Chrome’s critical databases, targeted by the stealer, are listed below.
| Stolen Data | Location of the Stolen Data |
|---|---|
| Passwords | C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Login Data |
| AutoFills | C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Web Data |
| Credit Cards | C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Web Data |
| Cookies | C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies |
- The malware steals the decryption key, stored in the “Local State” file of the browser, which is used to protect data stored in databases in the User Data directory, mentioned above.
- The malware then proceeds to open the database and decrypts the data.
- The stolen data is then sent back to C2.
Commands to Steal the Browser Data
The previously downloaded sqlite.dll is loaded into memory to resolve the addresses of the functions required for querying data from the browser database. Following images contain the various SQL queries employed by the malware to steal the Chrome browser data.
The previously downloaded ns33.dll is loaded into memory to retrieve the data stored by Mozilla Firefox. The stealer then proceeds to steal the browser’s cookie, login, and form history data. The “ffcookies.txt” filename is used for sending stolen Firefox data to the C2 server.
Wallets & Browser Extensions
The table below contains the list of wallets and web extensions targeted by the Raccoon malware.
| Wallets | |||
|---|---|---|---|
| Exodus | Atomic | Jaxx Liberty | Electron Cash |
| Binance | Coinomi | Electrum | Ledger |
| Guarda | Monero | Ronin | Daedalus |
| Blockstream Green | Meta | Wasabi | |
| Web Extensions | |||
| metax | xdefi | waveskeeper | solflare |
| rabby | cyano | coinbase | auromina |
| khc | tezbox | coin98 | temple |
| iconex | sollet | clover | polymesh |
| neoline | keplr | terraStation | liquality |
| SaturnWallet | GuildWallet | phantom | tronlink |
| brave | MetaMask | ronin | mewcx |
| ton | goby | bitkeep | Cosmostation |
| GameStop | stargazer | Enkrypt | jaxxliberty |
| CloverWallet | |||
File Grabbing
The malware uses the grbr_ identifier to enable the grabber functionality and starts searching the system for files such as password files, wallet seeds, etc.
Telegram & Discord Data
Raccoon steals Telegram data from the “Telegram Desktop”\tdata directory. It is particularly interested in the directories containing user_data, emoji, tdummy, and dumps.
The stealer is also capable of stealing Discord data, such as tokens, but this feature is not enabled by default. The malware operator needs to explicitly provide a “dscrd_” identifier in the configuration to enable this option.
ScreenShot Capture
Apart from stealing information, Raccoon can also take screenshots of the compromised system by using the “scrnsht_” identifier in the C2 configuration. The details of the screenshot capturing process are explained below.
- Raccoon utilizes two libraries namely gdi32.dll and gdiplus.dll to capture the screen of the victim. These libraries are dynamically loaded and the API addresses are resolved.
| List of APIs Resolved | ||
|---|---|---|
| Gdiplus!GdiplusStartup | Gdiplus!GdipDisposeImage | Gdiplus!GdipGetImageEncoders |
| Gdiplus!GetImageEncodersSize | Gdiplus!GdipCreateBitmapFromHBitmap | Gdiplus!GdipSaveImageToFile |
| gdi32!BitBlt | gdi32!CreateCompatibleBitmap | gdi32!CreateCompatibleDC |
| gdi32!DeleteObject | gdi32!GetObjectW | gdi32!SelectObject |
| gdi32!SetStretchBltMode | gdi32!StretchBlt | |
- The process undertaken for screen grabbing using the above libraries is not straightforward. It requires extensive image processing techniques, which is beyond the scope of this report. In a nutshell, the captured image is saved onto the disk in a jpeg format. Initially, the name assigned to the file is random, however, when it is sent to the C2, the image is transferred as “–screenshot.jpg”. The below image shows the Raccoon’s conversation with C2.
Additional Payload Execution
The Raccoon stealer, like any other malware in its class, has the ability to execute user-provided additional malware (such as RATs) on the compromised system. As per CloudSEK’s analysis of multiple samples, this feature is not present by default. Thus, when the stealer fetches the configuration, the operator will have to explicitly enable this feature by providing the ldr_ identifier with a URL to fetch the additional payload executable along with the directory information, to install/drop it on the system for further execution.
The image below depicts the module responsible for this feature. Initially, the module checks for the identifier ldr_ in the C2 configuration. If no Idr_ is present, the flow returns to its main function.
If the C2 contains an ldr_ identifier, the following code is used to execute the fetched executable. The shell32!ShellExecuteW API is called by passing the file and the ‘open’ operation as parameters.
Cleaning Up
Before exiting the system, the stealer deletes the DLL files that were loaded in the memory during the operation and terminates its execution.
Indicators of Compromise (IoCs)
| Binary | |
|---|---|
| 494ab44bb96537fc8a3e832e3cf032b0599501f96a682205bc46d9b7744d52ab | |
| dd2db9bfa45002375af028ac00ca1b5e0c1db30a116c21cac2b4c75cb4ff9aec | |
| IPv4 | |
| 193.56.146.177 |