# Recordbreaker: The Resurgence of Raccoon **cloudsek.com/recordbreaker-the-resurgence-of-raccoon** Anandeshwar Unnikrishnan September 16, 2022 **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,](https://blog.sekoia.io/raccoon-stealer-v2-part-1-the-return-of-the-dead/) 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. ----- Post describing the technical details of recent samples and modifications made in the Raccoon Stealer ## 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-](https://cloudsek.com/) 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. API trace present in the malware The above sequence of operations is performed twice, and then the packer resumes the suspended threads. Image of the packer resuming 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. Hooking the NT API Calls ----- The written data is a JMP (jump) instruction, followed by a specific address that points to one of the segments in the packer. Updated function entry after hooking 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._ Warning popup triggered upon failure of hooking 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. ----- Code responsible for runtime dynamic linking of DLLs ### 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. RC4 decryption routine used in the old malware samples However, the recent version uses a custom XOR-based encoding to encrypt the strings. Custom XOR encoding used in new malware samples ----- ### 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. Code responsible for mutex creation [Also Read Technical Analysis of Bumblebee Malware Loader](https://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/) ## 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. Administrator check performed by the stealer ----- ### 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. Process enumeration done by the malware 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](https://cloudsek.com/threatintelligence/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. Format of the victim profile sent to the C2 ----- The HTTP POST request and the victim identification data sent by Raccoon Stealer to the C2 ### 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_** ----- C2 configuration fetched by the malware ### 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. ----- Legitimate DLLs downloaded by the malware 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. Runtime dynamic loading of sqlite.dll Runtime dynamic loading of ns33.dll ### Sysinfo Enumeration Post fetching the libraries, a profile of the host is created and sent to the C2 as a “System Info.txt” file. ----- System information sent to C2 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. SQL queries used by Raccoon to steal cookie data from Chrome browser’s cookie store SQL queries used by Raccoon to steal credit card information saved on the browser SQL queries used by Raccoon to steal autofill data stored in the browser 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. ----- Mozilla Firefox cookies targeted by Raccoon SQL query issued by Raccoon on the cookie.sqlite file, to steal cookie data from Firefox SQL query used by Raccoon to steal form history from Firefox ### 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. File grabbing C2 configuration in Raccoon ### 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. Malware taking screen capture using gdi32.dll and gdiplus.dll **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. Screenshot being sent to the C2 endpoint ## 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. Checking the C2 configuration for additional payload execution option 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._** Code responsible for additional payload execution via the ShellExecuteW API ## 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** ----- **Binary494ab44bb96537fc8a3e832e3cf032b0599501f96a682205bc46d9b7744d52ab** **dd2db9bfa45002375af028ac00ca1b5e0c1db30a116c21cac2b4c75cb4ff9aec** **494ab44bb96537fc8a3e832e3cf032b0599501f96a682205bc46d9b7744d52ab** **IPv4** **dd2db9bfa45002375af028ac00ca1b5e0c1db30a116c21cac2b4c75cb4ff9aec** **193.56.146.177** **IPv4** ## References [Raccoon Stealer v2 – Part 1: The return of the dead (sekoia.io)](https://blog.sekoia.io/raccoon-stealer-v2-part-1-the-return-of-the-dead/) Author Details [Anandeshwar Unnikrishnan](https://cloudsek.com/author/anadeshwar-unnikrishnan/) Threat Intelligence Researcher, [CloudSEK](https://cloudsek.com/) Anandeshwar is a Threat Intelligence Researcher at CloudSEK. He is a strong advocate of offensive cybersecurity. He is fuelled by his passion for cyber threats in a global context. He dedicates much of his time on Try Hack Me/ Hack The Box/ Offensive Security Playground. He believes that “a strong mind starts with a strong body.” When he is not gymming, he finds time to nurture his passion for teaching. He also likes to travel and experience new cultures. [Hansika Saxena](https://cloudsek.com/author/hansika-saxena/) Total Posts: 2 Hansika joined CloudSEK’s Editorial team as a Technical Writer and is a B.Sc (Hons) student at the University of Delhi. She was previously associated with Youth India Foundation for a year. ----- [Suchita Satyaprem Katira](https://cloudsek.com/author/suchita-katira/) Total Posts: 0 Sorry! The Author has not filled his profile. × [Anandeshwar Unnikrishnan](https://cloudsek.com/author/anadeshwar-unnikrishnan/) Threat Intelligence Researcher, [CloudSEK](https://cloudsek.com/) Anandeshwar is a Threat Intelligence Researcher at CloudSEK. He is a strong advocate of offensive cybersecurity. He is fuelled by his passion for cyber threats in a global context. He dedicates much of his time on Try Hack Me/ Hack The Box/ Offensive Security Playground. He believes that “a strong mind starts with a strong body.” When he is not gymming, he finds time to nurture his passion for teaching. He also likes to travel and experience new cultures. Latest Posts ----- -----