#### WHITE PAPER # ANALYZING THE RACCOON STEALER **[www.cyberark.com](http://www.cyberark.com)** ----- ## Table of Contents ###### Introduction.....................................................................................................................................................................4 How Raccoon Works......................................................................................................................................................4 Commonwealth of Independent States (CIS) Countries...................................................................................5 Raccoon’s Hidden C&C............................................................................................................................................ 6 Stealer’s Config.........................................................................................................................................................7 Working Folder & Downloading Files...................................................................................................................7 Stealing Methods..........................................................................................................................................................10 Chromium-based Browsers.................................................................................................................................10 Data Extraction.................................................................................................................................................................................13 Credentials – Login Data DB..........................................................................................................................................................13 AutoFill Information – Login Data DB......................................................................................................................................... 15 Credit Card information – Web Data DB ................................................................................................................................... 15 Cookies – Cookies DB .....................................................................................................................................................................16 History – History DB ......................................................................................................................................................................16 Internet Explorer.................................................................................................................................................... 17 Internet Explorer Autocomplete Password.................................................................................................................................17 ieExfiltrateURL function................................................................................................................................................................. 18 HTTP Basic Authentication ..........................................................................................................................................................19 Mozilla-Based Applications..................................................................................................................................23 Credentials - logins.json/signons.sqlite.......................................................................................................................................25 logins.json..............................................................................................................................................................................25 signons.sqlite........................................................................................................................................................................ 26 Cookies - cookies.sqlite...................................................................................................................................................................27 History- places.sqlite......................................................................................................................................................................27 Outlook.....................................................................................................................................................................27 lvl1_regEnum....................................................................................................................................................................................28 lvl2_regEnum...................................................................................................................................................................................28 getOutlookAccount function.........................................................................................................................................................28 ----- ###### Foxmail.................................................................................................................................................................... 30 Cryptocurrency Wallets........................................................................................................................................ 31 Electrum.............................................................................................................................................................................................31 Ethereum...........................................................................................................................................................................................32 Exodus................................................................................................................................................................................................32 Jaxx.....................................................................................................................................................................................................32 Monero...............................................................................................................................................................................................32 Bither.................................................................................................................................................................................................32 Wallet Grabber.................................................................................................................................................................................33 Gather information about the compromised machine..................................................................................33 Final Steps......................................................................................................................................................................37 Sending It All Back to C&C....................................................................................................................................37 Deleting Its Traces................................................................................................................................................40 Summary.......................................................................................................................................................................40 IoCs...........................................................................................................................................................................40 YARA Rule................................................................................................................................................................41 ----- ### Introduction ###### In this whitepaper, we describe a few select technical ##### For a higher level version of this ###### details regarding an infostealer named ‘Raccoon,’ including in-depth analysis of Raccoon’s methods and techniques. research, please take a look at this blog ##### post: Raccoon; The Story of a Typical An infostealer is a type of malware that is focused on gathering sensitive and conditional information from the [Infostealer.](https://www.cyberark.com/threat-research-blog/raccoon-the-story-of-a-typical-infostealer/) compromised system. While this information is often related to the user’s credentials, they have also been known to seek out financial data and personal information. The research performed by CyberArk Labs focused on the methods and techniques that a typical infostealer leverages for stealing sensitive user data and information. Additionally, we wanted to better understand what clients (a.k.a. cybercriminals) are able to retrieve with a low price infostealer such as Raccoon. ### How Raccoon Works Raccoon stealer is not the most sophisticated malware that’s available to cyber attackers, but it proves to be quite effective. This reaffirms that attackers do not require anything overly advanced when these less-sophisticated techniques are still very much effective in carrying out an attack. The first step in our analysis was investigating the malware strings to gain leads derived from these samples. We were able to determine the browser’s names, application paths, DLL name (which is used for Mozilla applications,) some unusual strings – like encryptedUsername and encryptedPassword – and more. _Figure 1: Part of Raccoon’s strings_ ----- Before Raccoon moves forward in stealing sensitive data from a system, it first performs various checks on the compromised system. It starts by looking for the mutex: rc/%username% and, if it isn’t already present, it automatically proceeds to create it. Secondly, it looks to see if the computer is part of the Commonwealth of Independent States (CIS) countries. #### Commonwealth of Independent States (CIS) Countries Raccoon gets the locale of the machine by calling to GetUserDefaultLCID and GetLocaleInfoA and then compares the system language to CIS languages (Russian, Ukrainian, Belarusian, Kazakh, Kyrgyz, Armenian, Tajik, Uzbek). _Figure 2: Check for CIS countries_ The strings of the CIS languages are encrypted, so the malware decrypts the strings and compares them to the system’s locale. Since part of Raccoon’s strings are encrypted, Raccoon creates a bytes array with the XOR key as the most significant byte and the rest of the array is XORed and NOTed with the byte-key, for example, 379ABDBBBBA1A9A6→ Russian. To remain stealthy, most of the strings that Raccoon uses are encrypted, therefore it decrypts them in runtime. Once those system checks are completed, Raccoon does the following: ###### • [Gets its C&C (Command and Control) – by decrypting some hardcoded values and using Google Drive as a middle stage.] • [Gets its configuration – by querying the C&C server with its hardcoded configuration ID, Racoon receives a JSON that contains ] the configuration for the sample. ----- #### Raccoon’s Hidden C&C The stealer binary contains 3 hardcoded values: ###### • [A base64 string: ] Mypo7lAqDGp6xNdb/CUHGKD0x9cCPC4XYTUYxcMwDD/ tWbPQlmUzGwH+R8cN9kncB7OZsuFsvcdiB1xtd7BAC0yoPZteuoB1hV5KWIQ0+cA=. ###### • [A first ][encrypted][ key for the Google Drive URL decryption routine.] • [A second key ][26b948359b43d02743bd1fad775a15ca][ for the C&C server URL decryption routine.] The process of getting the server address is as follows: **1.** Raccoon decrypts the first key, which will be the Google Drive decryption key 1@zFg08*@45. Part of Raccoon’s strings are encrypted like the first key. Raccoon creates a byte array with the XOR key as the most significant byte and the rest of the array is XORed and NOTed with the byte-key, for example: 34FA8BB18DACFBF3E18BFFFE→ 1@zFg08*@45. **2.** The stealer uses a decryption routine (some naive XOR cipher) in order to decrypt the first hardcoded base64; the decryption function gets the first key and the decoded base64. The decryption function will return a string for Google Drive URL (https://drive[.]google[.]com/ uc?export=download&id=1QQXAXArU8BU4kJZ6IBsSCCyLtmLftiOV), which will be the middle stage for getting the C&C domain. **3.** It will then create a GET request to this Google Drive using HTTPS. The response from Google Drive is seen in Figure 3. _Figure 3: Google Drive response_ **4.** Raccoon filters the response in order to get the file name from the Content-Disposition response header. _“attachment (indicating it should be downloaded; most browsers presenting a ‘Save as’ dialog, prefilled with the value of the_ _filename parameters if present), MDN.”_ The filter function gets the response as a string and two other strings (attachment;filename=”, .txt”;filename*=UTF-8 ) and returns the string between the latter two strings → /nR09mYYxgcjyzYzfq24EGsrNabUWO3ZUN7At+/iX2rFDA== which is the encrypted C&C server URL. **5.** Finally, Raccoon decrypts the filtered base64 string using its naive decryption routine and passes the decoded base64 from the response (from step four) and the second hardcoded private key. The decryption routine will return Raccoon’s **C&C** http://35[.]189[.]105[.]242/gate/log.php. ----- #### Stealer’s Config Like most of the credential stealers, the client (i.e. the attacker) can customize its own configuration for the stealer functionality, which can be saved in the binary built by the malware or in the C&C server and sent back to the malware when executed. In Raccoon, after the client chooses the configuration, the malware builder generates a configuration ID for the client’s configuration and writes this ID to the compiled malware. In this case, the config ID is encrypted and Raccoon has another hardcoded base-64 encoded string in the binary. To decrypt the config ID it uses the first key (1@zFg08*@45) and, after the decryption routine, gets the config ID (which, in this case, is: 4ede41fe0ea963034a3d65f0dd442de4671c214f). To get the full configuration (enabled capabilities) the stealer has to query the C&C. **1.** The malware generates an ID for the machine from MachineGuid, which is a common ID (query this registry key HKLM\SOFTWARE\Microsoft\Cryptography for the value MachineGuid) and from the current username (calling to GetUserNameA). **2.** It creates the next machine profile bot_id=%machineGUID%_%username%&config_id=%configID%&data=null and encodes the string as base64. **3.** The remaining piece is to send the machine profile to the C&C. It concatenates the encoded base64 string to params= and sends a POST request with params=%base64MachineProfile% as the content of the request. _Figure 4: POST request to C&C_ The C&C server returns JSON that contains the configuration the stealer needed for its functionality. _Figure 5: The stealer configuration JSON_ #### Working Folder & Downloading Files The malware working directory is the Temp folder. During runtime, it downloads all the files it needs (DLLs, zip file, and dropped malware) to this folder and writes all the stolen data to text files in this directory. Raccoon uses getTempPath function many times. ----- _Figure 6: getTempPath function_ In order to download files, the malware uses a function that we named downloadFile. The function gets a location to download the file from and a download URL (the function gets the parameters using the registers - ecx/edx). To stay stealthy, the malware dynamically loads urlmon.dll, so we can’t find it within the import table of the PE. ----- _Figure 7: DownloadFile function_ After loading the DLL (urlmon.dll), it calls dynamically to URLDownloadToFileA by using GetProcAddress. _Figure 8: Calling to URLDownloadToFileA dynamically_ ----- ### Stealing Methods #### Chromium-based Browsers The first applications that Raccoon targets are chromium-based browsers. The sensitive data for these applications is saved within SQLite databases. In order to extract the data from the DB, Raccoon has to query it using the exported functions of sqlite3.dll. The first step Raccoon takes is to download this DLL, therefore, it uses the downloadFile function and passes the attachemrnt_url value from the config JSON (the value contains a download URL for sqlite3.dll). _Figure 9: The stack frame for URLDownloadToFileA (downloadFile function)_ After downloading the sqlite3.dll from the C&C server, it loads it to memory. The malware has a plain text list for the chromium-based browsers containing: ###### • [Application name] • [A path for the application folder that contains the sensitive DBs] • [DB names] _Figure 10: Part of the plain text list for Chromium-based browsers_ ----- In the list, there are 29 applications with all the path names and relevant DB names (note: the DB names are the same for all the browsers, so it is useless to repeat this process further times). Raccoon loops over all 29 applications by using the same functions and techniques it used to steal the data from the DBs, the only difference is in the User Data folder location. This methodology makes the malware authors’ work easier because they develop one functionality that can work for all the Chromium-based browsers, enabling them to cover more applications without developing more capabilities. The location for application User data can be in different locations within AppData (CSIDL_APPDATA/CSIDL_LOCAL_APPDATA) _Figure 11: Getting the application directory_ The next step for Raccoon is to create the full path for the User Data directory, so it concatenates the app data path (Local/ Roaming) with the plain text application path, for example, C:\Users\user\AppData\Local\Google\Chrome\User Data. The malware is focused on extracting sensitive data from: ###### • [Login Data DB – usernames and passwords, autofill data] • [Web Data DB – credit card information] • [Cookies DB] • [History DB (if enabled by the configuration JSON)] The stealer uses one generic function, which we named findDB_RunFunc, this function searches for the DB file inside the User Data folder and calls to the relevant function to correctly extract the data from the DB (each DB has a specific function to handle it: extractCreds,extractCookie and etc.). ----- _Figure 12: Getting the application directory and passing the relevant extraction function_ findDB_RunFunc function gets four parameters: ###### • [by stack: the handle to Sqlit3.dll ] • [the pointer to browser name (string)] • [the pointer to the function that handles the DB] • [by registers: the path for the user data directory] The function searches (recursively) by name in the user data folder for the DB file. When it finds the DB, the function calls to the passed function to handle it (i.e. extract the data.) ----- _Figure 13: Call to relevant subroutine to handle the DB_ Note: There is some non-traditional logic in the findDB_RunFunc function. The function keeps searching for the DB file in the directory even after it finds the file and calls to the relevant function to handle it. Now, that we’ve discussed how Raccoon gets the confidential DBs files, we will focus on how it extracts and decrypts the data. ###### Data Extraction All the extraction functions have the same scheme: **1.** The malware saves the addresses of the functions from sqlite3.dll (by using GetProcAddress): ###### ˚ [sqlite3_open_v2] ˚ [ sqlite3_prepare_v2] ˚ [ sqlite3_step] ˚ [ sqlite3_column_bytes] ˚ [ sqlite3_column_blob] ˚ [ sqlite3_column_text] ˚ [ sqlite3_column_finalize] ˚ [ sqlite3_column_close] **2.** It generates a random string (length of 10 characters) and copies the DB file to a temp folder named like the random string – all the extractions methods will be on the copied DB. In order to extract the data from the DB, the malware has to create the SQL query and query the DB using sqlite3.dll functions. ###### Credentials – Login Data DB **1.** The malware opens the DB by using sqlite3_open_v2 and passes the DB path. **2.** It decrypts the SQL query for the “Login Data” DB: SELECT origin_url, username_value, password_value FROM logins **3.** It calls to sqlite3_prepare_v2, the function gets a handle to DB and the SQL query and returns a statement handle. **4.** By using sqlite3_column_bytes/sqlite3_column_blob/sqlite3_column_text, the malware can get the results from the queries; those functions get the statement (query) handle and index for the column. ----- The passwords in the DB are encrypted by DPAPI and, therefore, the malware uses the function CryptUnprotectData to decrypt the user’s passwords. _Figure 14: Decryption of the user’s password_ sqlite3_column_bytes will return the size of the encrypted password and sqlite3_column_blob the bytes for the encrypted password. Using memmove, it copies the encrypted password to CRYPT_INTEGER_BLOB structure and the CryptUnprotectData function gets this structure The malware puts the extracted data in a form and iterates all the passwords in DB. After getting all the passwords, it creates a text file named passwords.txt and writes the extracted data to it. ----- _Figure 15: Extracted information from chrome login data DB_ ###### AutoFill Information – Login Data DB The same extraction logic, but different SQL queries. Note: Within every extraction function, Raccoon repeats getting the address for the sqlite3.dll functions. The malware gets the passwords dynamically and then overrides the variables with the same addresses, which doesn’t make any sense. The query for the autofill information is SELECT name, value FROM autofill. The malware iterates all the values in the autofill table and writes them to a text file named chrome_autofill.txt. ###### Credit Card information – Web Data DB The same extraction logic, but different SQL DBs and queries. The query for the credit card information is SELECT name_on_card, card_number_encrypted, expiration_month, expiration_year FROM credit_cards. The malware iterates all the values in the credit_cards table and writes them to a text file named CC.txt. The encrypted value card_number_encrypted is decrypted by using the CryptUnprotectData function. ----- _Figure 16: The CC info from the Chrome Web data DB_ ###### Cookies – Cookies DB The same extraction logic, but different SQL DBs and queries. The query for the cookies information is SELECT host_key, path, is_secure, expires_utc, name, value, encrypted_value FROM cookies. The malware iterates all the values in the cookies table and writes them to a text file named chrome_cookie.txt. The encrypted value cookie is decrypted, just like before, by using the CryptUnprotectData function. ###### History – History DB This feature is enabled only by the configuration JSON; by default this feature is disabled. The same extraction logic, but different SQL DBs and queries. The query for the history information is SELECT url, visit_count, datetime(last_visit_time / 1000000 + (strftime(‘%s’, ‘1601-01-01’)), ‘unixepoch’) FROM urls. The malware iterates all the values in the URLs table and writes them to a text file named chrome_urls.txt. ----- #### Internet Explorer ###### Internet Explorer Autocomplete Password ##### “The IUrlHistory interfaces provide Internet Explorer Autocomplete passwords for websites are saved under the registry key HKEY_CURRENT_USER\Software\ functionality to manage Windows Microsoft\Internet Explorer\IntelliForms\Storage2, but they are Internet Explorer history information” saved in a stealthy way – every value represents a login for a [-Microsoft Docs](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms774939(v=vs.85)) website (URL), but the value is a hash of the URL website and the data for the value is the encrypted credentials. In order to match the password to the hash, the malware has to find the hash of the URL. [In this part of the analysis, we used this IDA python to analyze the COM objects: fboldewin/COM-Code-Helper.](https://github.com/fboldewin/COM-Code-Helper) _Figure 17: Received interface pointer to IUrlHistoryStg2_ Raccoon calls to IUrlHistoryStg2Vtbl.EnumUrls, which returns an interface to an enumerator of visited links in the Windows Internet Explorer history. The malware passes every URL in the Internet Explorer history to a function we named ieExfiltrateURL. ----- ###### ieExfiltrateURL function At first, the function creates a hash of SHA1 for the given argument, which is the URL. _Figure 18: Raccoon creates SHA1 from the URL_ ----- After that, Raccoon passes the hash to a function that we named searchGetKeyRegValue. This function gets a registry key and value and returns the data for a matched value or null (if not found). By this method, Raccoon matches the hash of the URL to the URL. The value for the hash is the encrypted password. Raccoon uses CryptUnprotectData to decrypt the value. The stealer has few more methods to extract data from IE. It uses a function we named exfiltrateDecDPAPI, which handles the decrypted data from the various extraction methods. The exfiltrateDecDPAPI function gets, as an argument, a number (some flag) and uses it to determine how to handle the decrypted data and writes it. The flag indicates which IE extraction method the data came from. In this part of writing the decrypted data to ie_autofill.txt, we noticed that Raccoon doesn’t handle the decrypted data correctly; therefore, the user passwords will never be written to the text file, only the usernames. _Figure 19: Null Terminator in the Decrypted Data_ ###### HTTP Basic Authentication The HTTP basic authentication passwords are stored in the credentials store. The credentials are encrypted by using DPAPI after they are salted with a fixed value generated from the next GUID abe2869f-9b47-4cd9-a358-c22904dba7f7. Raccoon enumerates the credentials of the user and adds the relevant filter Microsoft_WinInet_* to get only the HTTP basic authentication credentials. ----- _Figure 20: Calling to CredEnumrateW_ In order to get the plain text password, the malware uses CryptUnprotectData with the relevant OptinalEntropy. ----- _Figure 21: Calling to CryptUnprotectData_ After getting the decrypted credentials, the malware uses the exfiltrateDecDPAPI function again, but with another flag, so that it will process the decrypted data in a different way. The exfiltrateDecDPAPI function gets the decrypted data and the URL from the credentials store. The user name and password are in this format: : and the URL is in this format: Microsoft_WinInet_. At first, it cuts the Microsoft_WinInet_ from the string and gets only the URL part. Raccoon checks if the URL starts with the string ftp://, filtering only the FTP servers from the HTTP basic authentication. ----- _Figure 22: Selecting the FTP servers_ All the stolen FTP credentials are written to a text file named ie_ftp_data.txt. _Figure 23: FTP stolen credentials_ ----- #### Mozilla-Based Applications Raccoon gets the value of the libraries key from the configuration and downloads a ZIP file from the C&C server. The zip file contains multiple different dlls in order to complete its malicious activity. _Figure 24: Downloads the Compressed Zip to Temp\ADLibs\ff-functions.zip_ After downloading the file, it extracts all the files from the ff-funcs.zip to ADLibs, deletes the zip and adds ADLibs to PATH env variables. To extract and decrypt the user sensitive data from the Mozilla application, Raccoon must use nss3.dll, so it loads the nss3.dll from ADLibs and all the relevant exported functions: ###### • [NSS_Init] • [ NSS_Shutdown] • [ PK11_GetInternalKeySlot] • [ PK11_FreeSlot] • [ PK11_Authenticate] • [ PK11SDR_Decrypt] • [ sqlite3_open] • [ nss3.sqlite3_prepare_v2] • [ nss3.sqlite3_step] • [ nss3.sqlite3_column_text] • [ nss3.sqlite3_finalize] Raccoon relies again on the same technique to steal sensitive data from the Mozilla-based applications as the Chromium-based browsers. It has extraction functions that work for all the applications, because they have the same code base, which allows Raccoon to cover more applications easily. ----- _Figure 25: Main Mozilla-based functionality_ This feature targets (120/24=5) Mozilla based applications, which includes popular browsers like Firefox and Email client like Thunderbird. The extraction and decryption functions get the application name and some directory path like Firefox,\Mozilla\Firefox\. Raccoon creates a full path to the Profile folder of the application where all the sensitive files are located. It does that by getting the RoamingAppData path, concats the hardcoded “Profiles” string to the application directory path (which passed to the func), for example, C:\Users\user\AppData\Roaming\Mozilla\Firefox\Profiles. ----- The Profiles folder contains the user profile for the application, it can be more than one folder, which may indicate multiple users; therefore, it saves all those profiles paths. In order to validate those profile directories within the “Profiles” folder, Raccon calls to NSS_Init (resolved function from nss3.dll) with the Profile path, the function returns SECSuccess on success or SECFailure on failure. The profile folder is expected to contain the certificate, key and module databases. ###### Credentials - logins.json/signons.sqlite The login credentials can be saved in two formats, in a JSON file or SQLite DB, depedning on the application version. It is more common for most of the stealers to extract data only from the logins.json file. ###### logins.json The malware decrypts the string logins.json and concats it to the profile path (C:\Users\user\AppData\Roaming\Mozilla\Firefox\ Profiles\a11b22cc.default-release\logins.json) and validates if the file exists and gets a handle to this file by calling to _fopen. _Figure 26: Logins.json content_ Every item in the logins list (second key in the JSON) is a saved login credential for a resource. Raccoon iterates this list and performs the next actions for every login. **1.** Checks if there is value for the next keys: For thunderbird application: hostname, encryptedUsername, encryptedPassword For other applications: formSubmitURL, encryptedUsername, encryptedPassword **2.** Extracts the values from those keys. In order to decrypt the confidential values, the encrypted data is passed to a function that we named getDecryptedPK11. ----- getDecryptedPK11 function gets the encrypted data, which is encoded as base64, and retrieves the decrypted data. It uses CryptStringToBinaryA with the flag (CRYPT_STRING_BASE64) to convert the formatted string into bytes. The decryption routine uses the resolved crypto functions from nss3.dll. **1.** PK11_GetInternalKeySlot **2.** PK11_Authenticate **3.** PK11SDR_Decrypt **4.** PK11_FreeSlot The function returns the decrypted data or “err” string for any error during the decryption process. **3.** After decrypting the data, the stealer calls to a function that we named buildBrowsersForm, which creates forms from all the values in order to write them on the disk. The form looks like: HOST: %URL%\n USER: %username%\n PASS: %password%\n\n The buildBrowsersForm function returns the form as a string. **4.** Create a text file (or get a handle to an existing one) named passwords.txt/thinderbird.txt and write the form. ###### signons.sqlite This method is less common because it is supported only by older Mozilla based applications, like Firefox versions < 32. The process for extracting the data from SQLite DB is very similar to chrome based browsers: **1.** Decrypts the string “signons.sqlite” and create a full path to the DB and copies the DB to temp directory. **2.** Creates this SQL query SELECT encryptedUsername, encryptedPassword, formSubmitURL FROM moz_logins. **3.** Gets the extracted data and passes it to getDecryptedPK11 function and after that to buildBrowsersForm. _Figure 27: The stolen credentials_ ----- ###### Cookies - cookies.sqlite The Mozilla based applications store the cookies in an SQLite database named cookies.sqlite and it’s default location is under the user’s profile folder (Profile\%profile%). This function starts similarly to the credentials extraction function since they both get the application name and path (it builds a full path to the Profiles software directory) and saved all the profiles (directories) in the Profile folder. For every directory in Profiles, which means every profile: **1.** The malware first decrypts the string \cookies.sqlite, creating the full path for the DB (C:\Users\user\AppData\Roaming\ Mozilla\Firefox\Profiles\%profile%\cookies.sqlite), and copies the DB to Temp directory. **2.** Handling the SQLite DB: The malware calls to NSS3sqlite3_open(pTempDB, hSqliteDB) in order to get a handle to this DB. Then, it decrypts the SQL query: SELECT host, path, isSecure, expiry, name, value FROM moz_cookies, prepares the statement (query) by Nss3Sqlite3_prepare_v2 and passes it to Nss3sqlite3_step. **3.** Finally, it extracts the data from the DB by using Nss3sqlite3_column_text. **4.** The malware concats all the values from the DB together (the delimiter is between the values is TAB -> \t and \n for every cookie, so every line represents a cookie). **5.** It then creates a text file named firefox_cookie.txt and writes the stolen cookies. ###### History- places.sqlite The malware extracts user history from places.sqlite DB. The algorithm of this function is very similar to the previous function. The DB name and the SQL query is the only difference between those functions. The SQL query is SELECT url, visit_count, last_visit_ date FROM moz_places WHERE last_visit_date<> 0 AND visit_count <> 0. Using this query, Raccoon extracts the website URL, the duration of the visit and the last visit time. It writes the data to firefox_urls.txt. #### Outlook Raccoon also targets the popular email client Microsoft Outlook. It uses multiple techniques to extract the user data and also supports older versions of Outlook software. The stealer has a function that implements all the stealing techniques and returns the stolen data as a string. The returned data is written to a text file named outlook.txt. Raccoon extracts the email client information from a few registries key in different methods: ###### • [HKCU\Software\Microsoft\Internet Account Manager\Accounts] • [ HKLM\Software\Microsoft\Office\Outlook\OMI ] • [ HKCU\Software\Microsoft\Office\Outlook\OMI Account Manage] • [ HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Microsoft Outlook Internet Settings] • [ HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook] • [ HKCU\Software\Microsoft\Office\19.0\Outlook\Profiles\Outlook] Raccoon tries to extract information from this registry seven times with different version numbers from 19.0 to 13.0. ----- Raccoon uses two functions to enumerate all the values under a received registry path: lvl1_regEnum and lvl2_regEnum. Moreover, it has a “core” function that extracts the account information from a received registry key. This function is named getOutlookAccount. lvl1_regEnum calls to Identities and lvl2_regEnum calls to getOutlookAccount, so it looks like this: lvl1_regEnum→ lvl2_regEnum→ getOutlookAccount ###### lvl1_regEnum The function gets two parameters – two strings for a registry key or one string for a registry key and null. The function builds a registry key string and passes it to lvl2_regEnum. **1.** It opens the first registry key (the first argument) within HKEY_CURRENT_USER and enumerates all the subkeys under this registry path. **2.** Creates a new string that represents a registry key that combines the first argument, the enumerated key and the second argument (if there is one). For example, Software\Microsoft\Internet Account Manager\Accounts\%enumrated_key%\ Identities **3.** The malware calls to lvl2_regEnum and passes the newly built string. ###### lvl2_regEnum The function gets one parameter – a string that represents a registry key. **1.** Raccoon opens the registry key (the argument) within HKEY_CURRENT_USER and enumerates all the subkeys under this argument. **2.** It creates a new string that represents a registry key that combines the first argument and the enumerated key _(arg_0+EnumratedKey)._ **3.** It calls to getOutlookAccount and passes the newly created registry key. ###### getOutlookAccount function The function gets the final enumerated registry key and checks all the values in the registry key in order to find AN outlook account values. The values that Raccoon searches are: SMTP Email Address, SMTP Server, POP3 Server, POP3 User Name, SMTP User Name, NNTP Email Address, NNTP User Name, NNTP Server, IMAP Server, IMAP User Name, Email, HTTP User, HTTP Server URL, POP3 User, MAP User, HTTPMail User Name, HTTPMail Server, SMTP User, POP3 Password2, IMAP Password2, NNTP Password2, HTTPMail Password2, SMTP Password2, POP3 Password, IMAP Password, NNTP Password, HTTP Password, SMTP Password, POP3 Port, SMTP Port, IMAP Port ----- _Figure 28: Raccoon targeting Outlook’s values_ To do so: **1.** Raccoon enumerates all the values within the registry path. **2.** It searches those targeted values. **3.** It saves the extracted data in the next form: %value%:%data%\n. - For encrypted values like passwords, it decrypts the password using CryptUnprotectData and then it saves the data. After extracting all those values for multiple accounts Raccoon writes it back to a file named outlook.txt. _Figure 29: Stolen data from Outlook_ ----- The calling order to lvl1_regEnum and lvl2_regEnum is: **1.** Calling to lvl2_regEnum(&L”Software\Microsoft\Internet Account Manager\Accounts”) **2.** Calling to lvl1_regEnum (&L”Identities”, &L”Software\Microsoft\Internet Account Manager\Accounts”) **3.** Search and get the data for the Outlook value in this reg key: HKLM\Software\Microsoft\Office\Outlook\OMI Account Manager. The data is also a reg key. After that, it calls to lvl2_regEnum(%OutlookRegResult%). **4.** Calling to lvl2_regEnum(&L”\Software\Microsoft\Office\Outlook\OMI Account Manager”). **5.** Calling to lvl1_regEnum (&L”Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ Microsoft Outlook Internet Settings”, 0) **6.** Calling to lvl1_regEnum (&L”Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ Outlook”, 0) **7.** Calling to lvl1_regEnum 7 times with different version numbers (19.0 - 13.0). For example: lvl1_regEnum(&L”Software\ Microsoft\Office\19.0\Outlook\Profiles\Outlook”, 0) Application Name Version Number Outlook 97 0 Outlook 98 5 Outlook 2000 0 Outlook XP/2002 10.0 Outlook 2003 11.0 Outlook 2007 12.0 Outlook 2010 14.0 Outlook 2013 15.0 Outlook 2016 16.0 Outlook 2019 16.0 #### Foxmail Foxmail is an Email client that is popular in China. Raccoon decrypts some strings for the application default location: ###### • [D:\Program Files\Foxmail 7.2\Storage] • [D:\Program Files (x86)\Foxmail 7.2\Storage] • [D:\Program Files (x86)\Foxmail 7.2\Storage] • [C:\Program Files\Foxmail 7.2\Storage] • [C:\Program Files (x86)\Foxmail 7.2\Storage] • [C:\Foxmail 7.2\Storage] For every location, Raccoon tries to find the file that contains the confidential data. The storage directory contains directories and each directory is a user account. The sensitive file is Account.rec0, which is within the Accounts directory, for example, C:\Foxmail 7.2\Storage\%user_account%\Accounts\Account.rec0. |Application Name|Version Number| |---|---| |Outlook 97|0| |Outlook 98|5| |Outlook 2000|0| |Outlook XP/2002|10.0| |Outlook 2003|11.0| |Outlook 2007|12.0| |Outlook 2010|14.0| |Outlook 2013|15.0| |Outlook 2016|16.0| |Outlook 2019|16.0| ----- The Account.rec0 doesn’t have a known format, but it contains some encoded UTF-8 strings. First, the malware creates a file with a random name and copies the Account.rec0 file from the account directory, encoding the new file as UTF-8. It look for a string between the “password” string and the “!PeriodicCheckTime” string in the file. The result is the encrypted password by DPAPI, so it decrypts the string (hex characters). Second, it copies the Account.rec0 file from the account directory again and creates a file with a random name. Again, it encodes the copied file as UTF-8 and looks for the next strings “outgoingssl” “OutgoingServer” “InComingSSL” “IncomingServer” – the result from the first pair is the SMTP server name and the result from the second pair is the IMAP server name. It writes the stolen data to a file named foxmail.temp. _Figure 30: Stolen Foxmail credentials_ #### Cryptocurrency Wallets Raccoon is not solely focused on user credentials. It also has financial goals, so it grabs wallet files from the machine. Most, if not all the Cryptocurrency Wallets are encrypted by Master Password. Therefore, the attacker has to use brute force to decrypt those wallets and extract the sensitive data. Raccoon leverages the fact that most users installed the wallet applications at the default location. ###### Electrum **1.** Raccoon decrypts the string \Electrum, gets the AppData path by calling to _getenv and creates the path to Electrum folder (C:\Users\%user%\AppData\Roaming\Electrum\). **2.** Scans the folder in order to find a file named “default_wallet” (the default wallet name for Electrom wallet). **3.** It creates a Wallets directory in temp (if there is no such directory), creates a subfolder named Electrum and copies the wallet to this folder. **4.** After scanning the Electrum folder, Raccoon tries to find wallets in this hardcoded path: C:\Users\%user%\AppData\ Roaming\Electrum\wallets. ----- ###### Ethereum **1.** Raccoon decrypts the string \Ethereum Wallet, gets the AppData path by calling to _getenv and creates the path to Ethereum folder (C:\Users\%user%\AppData\Roaming\Ethereum Wallet). **2.** It scans the folder in order to find a file whose name contains “UTC_”. **3.** It creates a Wallets directory in temp (if there is no such directory), creates a subfolder named Ethereum and copies the wallet to this folder. **4.** After scanning the Electrum folder, Raccoon tries to find wallets in this hardcoded path: C:\Users\%user%\AppData\ Roaming\Ethereum but only if the file name contains “UTC_”. ###### Exodus **1.** Raccoon decrypts the string \Exodus\exodus.wallet. **2.** It creates Wallets in temp (if there is no such directory), creatse a subfolder named Exodus and creates the exodus.wallet folder inside that folder. **3.** It copies all the files from exodus.wallet directory to the created folder (C:\Users\%user%\AppData\Local\Temp\Wallets\ Exodus\exodus.wallet). **4.** After it copies all the files, Raccoon tryes to find wallets in this hardcoded path: C:\Users\%user%\AppData\Roaming\ Exodus, looking for JSON files and copied them to C:\Users\%user%\AppData\Local\Temp\Wallets\Exodus. ###### Jaxx **1.** Raccoon decrypts the string \Jaxx\Local Storage, gets the AppData path by calling to _getenv and creates the path to Jaxx folder (C:\Users\%user%\AppData\Roaming\Jaxx\Local Storage). **2.** Creates Wallets in temp (if there is no such directory) and creates a subfolder named Jaxx. **3.** It copies all the files from this folder to C:\Users\%user%\AppData\Local\Temp\Wallets\ ###### Monero **1.** Raccoon decrypts the string \Documents\Monero\wallets. **2.** The Monero default installation directory is within the user directory; therefore, Raccon gets the user directory by calling to getenve and passing USERPROFILE. This user profile is concatenated with the decrypted string, so it looks like C:\Users\%user%\Documents\Monero\wallets. **3.** It enumerates all the wallets in this folder (each folder is a wallet). **4.** It scans each folder for a file that contains .keys extension. **5.** It copies only the keys file to a Monero temp folder. ###### Bither The execution time for stealing a Bither wallet file is a little bit non-traditional. Raccoon’s normal behavior is to steal all of the data of a particular type before it goes on to steal data of another type (i.e. stealing from all the crypto wallets and then moving to stealing from another data type). However, when Raccoon steals data from crypto wallets, it doesn’t include the Bither wallet. The Bither wallet is only included when the malware gathers all of the stolen data to zip file. It then adds the Bither wallet file directly to the zip. **1.** Raccoon decrypts \AppData\Roaming\Bither\address.db. ----- **2.** It gets the current user directory and creates this path C:\Users\%user%\AppData\Roaming\Bither\address.db. **3.** It adds the wallet file to the zip file. ###### Wallet Grabber Raccoon scans all the files/folders in AppData (C:\Users\user\AppData\Roaming). **1.** It checks for a file named wallet.dat in AppData. **2.** For every wallet.dat, it creates a new name according to the parent directory name (which is probably the crypto wallet application name). **3.** It copies the wallet.dat file to the wallets directory. _Figure 31: Grabbed wallet_ #### Gather information about the compromised machine Raccoon gathers information about the system it has infiltrated and adds this information to the stolen data. At first, Raccoon gets the public IP address of the machine from the configuration JSON that it retrieved from the C&C. There is a key in the JSON named ip, which contains the IP address. **1.** After the hardcoded date – which for this sample is probably the build date (Fri Aug 23 14:42:12 2019) – it decrypts the string Build compiled on. ----- _Figure 32: The hardcoded value & the decryption routine_ **2.** The malware decrypts Raccoon Version “[Raccoon Stealer] - v1.2 Kushage Release,” which we see is build version 1.2. **3.** It gets the current time (when the stealer lunched). **4.** It creates again the Machine ID - %machineGUID%_%username%, as described within the blog post. **5.** It gets the system default locale by calling to GetUserDefaultLCID,GetLocaleInfoA. **6.** It gets the OS version and name by calling to GetVersionExA and querying the next registry value, ProductName, within the next key, SOFTWARE\Microsoft\Windows NT\CurrentVersion. **7.** It checks the system architecture by calling to a function that should retrieve a folder used by 64-bit architecture. This directory is not present on 32-bit Windows. ----- _Figure 33: 64bit Function_ **8.** [Raccoon gets information about the CPU by using CPUID instruction Processor brand string technique. The processor](http://insightforfuture.blogspot.com/2010/11/how-to-find-your-processor-brand-string.html) brand string returns EAX, EBX, ECX, and EDX to the registers. Moreover, it calls to GetSystemInfo to get the number of processors. **9.** It calls to GlobalMemoryStatusEx in order to retrieve information about the current state of the physical memory. **10. It gathers information about the system’s screen resolution by calling to GetSystemMetrics two times, once with the SM_** CYSCREEN flag to get the height of the window and then with the SM_CXSCREEN flag to get the width of the screen. In addition, it gets the display name by calling EnumDisplayDevicesA. **11. Installed applications, Raccoon is using known methods to get this information.** It opens this reg path HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall and gets the DipslayName value for every key under this path. Raccoon filters the applications by checking every value to see if it contains the string Microsoft or Visual or Windows. After filtering the applications, it tries to get the DisplayVersion value. **Raccoon doesn’tt take into consideration when the DisplayVersion registry value doesn’t exist, so when it creates the form for the installed applications section it doesn’t separate the application by \n like it does when there is a DisplayVersion registry value. All the data about the system is written to a text file named machineinfo.txt (when it adds this file to the zip, the file name changes to System Info.txt) ----- _Figure 34: Stolen information from a machine_ Furthermore, after gathering the information about the system, Raccoon can (based on the configuration build) take a screenshot [from the machine using GDI. You can read more about this method here: https://www.codeproject.com/Articles/5051/Various-](https://www.codeproject.com/Articles/5051/Various-methods-for-capturing-the-screen) **[methods-for-capturing-the-screen](https://www.codeproject.com/Articles/5051/Various-methods-for-capturing-the-screen)** _Figure 35: Capturing a Screenshot Using GDI_ ----- ### Final Steps Raccoon creates a zip file named Log.zip, which contains all the stolen information from the machine, including text files, wallets files and PNG files. The data in the zip file is organized by category (browsers, mail, wallets, etc.) _Figure 36: Example of what the Log.zip can contain_ #### Sending It All Back to C&C So, Raccoon gathered all the stolen information to one zip file and now it just has to send that file to the C&C. Raccoon’s configuration contains the C&C handle to the stolen file. To send the file back to C&C, it creates a POST request that contains the zip file. **1.** Like most of the strings in Raccoon’s binary, the strings for sending the file back to the C&C are encrypted. So, Raccoon decrypts them (some HTTP headers). ###### ˚ [Content-type: multipart/form-data, boundary=Jfbvjwj3489078yuyetu] ----- ###### ˚ [\r\n--Jfbvjwj3489078yuyetu\r\ncontent-disposition: form-data; name=”file”; filename=”data.zip”\r\nContent-Type: application/] octet-stream\r\n\r\n ###### ˚ [\r\n--Jfbvjwj3489078yuyetu--] **2.** Raccoon gets a handle to Log.zip and the file size. **3.** It allocates a new block of memory in the heap as the size of the Log. zip file + 0x800 bytes. **4.** It copies the pointer from Log.zip to the newly allocated memory. **5.** It Copies the second decrypted string next to the file pointer. _Figure 37: Copy the values to the memory block_ **6.** Copy the Log.zip data (binary) to the allocated memory next to the second decrypted string _Figure 38: Copy the log.zip Binary to the Memory Block_ ----- **7.** It copies the third decrypted string next to log.zip data. This string is used to identify the end of the file. _Figure 39: The allocated memory block_ Raccoon uses functions from Winhttp.dll for the network session. When it uses WinHttpSendRequest, the optional data (lpOptional) receives a pointer to the newly created memory block and the additional headers (=pszHeaders) receive the first decrypted string – Content-type: multipart/form-data, boundary=Jfbvjwj3489078yuyetu. In doing that, Raccoon creates a POST request to the C&C that contains the Log.zip data. The string Jfbvjwj3489078yuyetu represents the boundary of the Log.zip data in the POST request. _Figure 40: The POST to the C&C_ ----- #### Deleting Its Traces In order to delete its trace from the machine, Raccoon creates a cmd.exe process that creates a ping.exe process and runs a delete command for the stealer file. It gets the stealer file path (current process) by using GetModuleFileNameA and decrypts the next strings: cmd.exe /C ping 1.1.1.1 -n 1 -w 3000 > Nul & Del /f /q “%s”. The cmd process runs the next command ping 1.1.1.1 -n 1 -w 3000 > Nul & Del /f /q “%stealer_path”. ### Summary In this research, we cover in great technical detail Raccoon’s techniques for communicating with the C&C server and stealing sensitive data from compromised systems. It is clear that Raccoon’s methods are not overly sophisticated, however this technique still provides nefarious characters with success in carrying out their attacks. This Malware-as-a-Service is available at a very low price and proves to be an effective and powerful stealer, making it extremely popular among cybercriminals. Raccoon steals data from a variety of applications, like browsers, email clients, cryptocurrency wallets, etc. As users of many of these targets, we wish to mitigate the risk of an attack to those sensitive assets from threats like Raccoon and raise awareness to the danger of opening suspicious attachments or clicking unknown URLs. The CyberArk Endpoint Privilege Manager solution can also aid in defending against credential-stealing malware. For more information on how to secure your organization from [cyberattacks, please visit www.cyberark.com.](http://www.cyberark.com) #### IoCs ###### • [SHA256] ˚ [a57e1f3217b993476c594570095d28b6c287731a005325e5f64a332a86cb7878] • [Malicious Activity] ˚ [Mutex - rc/][%username%] ˚ [cmd.exe /C ping 1.1.1.1 -n 1 -w 3000 > Nul & Del /f /q ][%malware_path%] • [ Network Communication] ˚ [https://drive[.]google[.]com/uc?export=download&id=1QQXAXArU8BU4kJZ6IBsSCCyLtmLftiOV] ˚ [http://35[.]189[.]105[.]242/gate] ˚ [http://35[.]189[.]105[.]242/gate/sqlite3.dll] ˚ [http://35[.]189[.]105[.]242/gate/libs.zip] ----- #### YARA Rule rule raccoon_stealer_rule { meta: author = “Ben Cohen, CyberArk” date = “16-01-2020” strings: $stealer_typo = “g:\stealer\stealler\json.hpp” wide $path1 = “\Google\Chrome SxS\User Data” wide $path2 = “\Chromium\User Data” wide $path3 = “\Xpom\User Data” wide $path4 = “\Comodo\Dragon\User Data” wide $path5 = “\Amigo\User Data” wide $path6 = “\Orbitum\User Data” wide $path7 = “\Bromium\User Data” wide $path8 = “\Nichrome\User Data” wide $path9 = “\RockMeIt\User Data” wide $path10 = “\360Browser\Browser\User Data” wide $db1 = “Login Data” wide $db2 = “Cookies” wide $db3 = “Web Data” wide condition: $stealer_typo or (4 of $path* and 2 of $db*) } This whitepaper is based on research done by CyberArk Labs Researcher Ben Cohen. ###### About CyberArk Labs CyberArk Labs is a team of cyber security experts who conduct research focused on targeted attacks against organizational networks – the methods, tools and techniques employed by targeted attackers, as well as methods and techniques to detect and mitigate such attacks. ###### About CyberArk CyberArk is the global leader in privileged access management, a critical layer of IT security to protect data, infrastructure and assets across the enterprise, in the cloud and throughout the DevOps pipeline. CyberArk delivers the industry’s most complete solution to reduce risk created by privileged credentials and secrets. The company is trusted by the world’s leading organizations, including more than 50 percent of the Fortune 100, to protect against external attackers and malicious insiders. A global company, CyberArk is headquartered in Petach Tikva, Israel, with U.S. headquarters located in Newton, Mass. The company also has offices throughout the Americas, EMEA, Asia Pacific and Japan. -----