{
	"id": "8b9ad92a-d651-4c02-9a09-88e68be150a7",
	"created_at": "2026-04-06T00:12:30.414419Z",
	"updated_at": "2026-04-10T13:12:31.228219Z",
	"deleted_at": null,
	"sha1_hash": "d5ce1ff47f61c71602dee36184b45cb9542de9a5",
	"title": "Raccoon Stealer 2.0 Malware analysis - ANY.RUN's Cybersecurity Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1124137,
	"plain_text": "Raccoon Stealer 2.0 Malware analysis - ANY.RUN's Cybersecurity Blog\r\nBy hardee\r\nPublished: 2022-08-30 · Archived: 2026-04-05 15:18:31 UTC\r\nRaccoon Stealer was one of the most mentioned malware in 2019. Cybercriminals sold this simple but versatile info stealer\r\nas a MaaS just for $75 per week and $200 per month. And it successfully attacked numerous systems. But in March 2022,\r\nthreat authors shut down their operations. \r\nIn July 2022, a new variant of this malware was released. And now Raccoon Stealer 2.0 has gone viral and got a new name\r\nin the wild – RecordBreaker. In this article, we will analyze several samples of the info stealer to find out its techniques and\r\nwhat data it collects.\r\nWhat is Raccoon Stealer?\r\nRaccoon Stealer is a kind of malware that steals various data from an infected computer. It’s quite a basic malware, but\r\nhackers who provide excellent service and simple navigation have made Raccoon popular. \r\nThe malware’s owners are interested in the following data:\r\nLogin/password pairs from various services saved in browsers\r\nCookies from different browsers\r\nBank data\r\nCryptocurrency wallets\r\nCredit card information\r\nArbitrary files, which can be of interest to intruders\r\nRaccoon – a sample overview\r\nIn the process of malware analysis, we worked with the following samples:\r\nsha-256\r\n9ee50e94a731872a74f47780317850ae2b9fae9d6c53a957ed7187173feb4f42\r\n0142baf3e69fe93e0151a1b5719c90df8e2adca4301c3aa255dd19e778d84edf\r\n022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03\r\n048c0113233ddc1250c269c74c9c9b8e9ad3e4dae3533ff0412d02b06bdf4059\r\n263c18c86071d085c69f2096460c6b418ae414d3ea92c0c2e75ef7cb47bbe693\r\n27e02b973771d43531c97eb5d3fb662f9247e85c4135fe4c030587a8dea72577\r\n494ab44bb96537fc8a3e832e3cf032b0599501f96a682205bc46d9b7744d52ab\r\nf26f5331588cb62a97d44ce55303eb81ef21cf563e2c604fe06b06d97760f544\r\nfcdc29b4d9cb808c178954d08c53c0519970fe585b850204655e44c1a901c4de\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 1 of 19\n\nRaccoon malware overview in DiE\r\nMITRE ATT\u0026CK Matrix produced by ANY.RUN Sandbox:\r\nChallenges during the malware analysis of Raccoon stealer v2\r\nRaccoon stealer v.2 got extremely famous, and, of course, we decided to look into it closely. And here, we have faced\r\nseveral challenges:\r\nWhen we first started our malware analysis, we immediately got a sample\r\n9ee50e94a731872a74f4778037850ae2b9fae9d6c53a957ed7187173feb4f4, which we were unable to run in our sandbox.\r\nThis example was packed and immediately finished execution when we tried to run it in a virtual environment. So, our team\r\ndecided to investigate the sandbox evasion mechanisms.\r\nDuring the sample’s reverse-engineering, we encountered another issue: the packer detects the presence of Anti-Anti-Debugger and terminates before checking the execution’s environment. In our case, we used TitanHide. \r\nWhen running the program under a debugger, the NtQueryInformationProcess call causes the ProcessInformation variable to\r\nbe overwritten. The packer compares the random value written to this variable earlier with the value after the call. If they are\r\ndifferent, it stops execution. \r\nThe challenge was solved with the following script for x64dbg:\r\nbphc\r\nrun\r\nfindallmem 0, #e91727f5ff#\r\nbph ref.addr(0)+5\r\nrun\r\n $p = [esp+0x10]\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 2 of 19\n\n$val = [p]\r\nlog \"secret:{0}\",$val\r\nbphc\r\nsti\r\nsti\r\nmov [$p], $val\r\nret\r\nIt turned out that the bug was known but had not been fixed at the moment of our research. After the report, it was fixed.\r\nTherefore, this Anti-debugger detection method no longer works.\r\nBut this script didn’t solve the problem of running in the virtual environment without a debugger. So we continued our\r\nmalware analysis and came across an interesting piece of code:\r\nAs it turned out, this piece of code is executed differently in virtual and real environments. An exception occurs after the IF\r\nflag is set in the flag register with the popfd command. If we run in a virtual environment, the exception handler pre-installed by the malware considers that the exception occurred on the “call” instruction. \r\nHowever, when running on a real machine, the exception occurs on the “nop” instruction. Thus, by comparing the addresses\r\nof the exceptions that occurred, the malware determines the presence of a virtual environment. \r\nBypassing this check is enough to decrease the EIP register value by one when entering the exception handler. After that, the\r\nmalware is successfully launched. \r\nAfter making the necessary corrections on our end, this detection method no longer works in ANY.RUN sandbox.\r\nExecution process of RecordBreaker malware \r\nLoading WinAPI libraries, getting addresses of used functions\r\nFirst, Raccoon dynamically loads WinAPI libraries using kernel32.dll!LoadLibraryW and gets addresses of WinAPI\r\nfunctions using kernel32.dll!GetProcAddress\r\nRaccoon is dynamically loading needed libraries and getting WinAPI imports addresses\r\nDecryption of strings \r\nDepending on the sample, the algorithm for encrypting strings can be: \r\nencrypted with RC4 algorithm, then encoded into the Base64 format\r\nXOR encrypted with a random key, e.g.:\r\nRaccoon Stealer is using XOR strings encryption\r\nencryption may not be applied at all\r\nExamples of decrypted strings:\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 3 of 19\n\nlogins.json\r\n\\autofill.txt\r\n\\cookies.txt\r\n\\passwords.txt\r\nformhistory.sqlite\r\n…\r\nC2 servers decryption\r\nThe next malware step is to decrypt C\u0026C servers. There can be several up to five ones. As in the case of strings, the\r\nencryption algorithm of C\u0026C servers may vary depending on a sample.\r\nFrom all the samples we have reviewed, at least two methods have been identified:\r\nEncryption using the RC4 algorithm with further recoding to Base64:\r\nRaccoonstealer is using RC4 -\u003e Base64 encryption chain for C2s\r\nRaccoonstealer is using RC4 -\u003e Base64 encryption chain for C2s\r\nEncryption with XOR:\r\nRaccoon malware is using XOR C2s encryption\r\nRaccoon termination triggers\r\nAt this stage the malware has not executed any malicious code yet. There are certain triggers that may cause the program to\r\nterminate without executing any other actions.\r\nThe user’s locale is checked (in some samples, certain locales corresponding to the locales of CIS countries cause Raccoon\r\nto terminate)\r\nRaccoon is checking for specific user locale\r\nA check is made to see if the malware has been rerun, in parallel with another sample running on this machine.\r\nRecordBreaker tries to open a particular mutex (the value of the mutex varies in different samples). If it succeeds, it\r\nterminates immediately. If not, it creates the mutex itself.\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 4 of 19\n\nRaccoon v2 is checking for a specific mutex\r\nWe can see the result in ANY.RUN: the mutex was created.\r\nMutex operations are captured by ANY.RUN interactive sandbox\r\nPrivilege Level Check\r\nAfter creating a mutex, the malware performs a System/LocalSystem level privilege check using\r\nAdvapi32.dll!GetTokenInformation and Advapi32.dll!ConvertSidToStringSidW comparing StringSid with L “S-1-5-18”:\r\nRaccoonstealer 2.0 is checking for System/LocalSystem privileges\r\nProcess enumeration\r\nIf the check shows that RecordBreaker has the privilege level it needs, it starts enumerating processes using the TlHelp32\r\nAPI (kernel32.dll!CreateToolhelp32Snapshot to capture processes and kernel32.dll!Process32First /\r\nkernel32.dll!Process32Next). In our samples this information isn’t collected or processed in any way. \r\nRaccoon malware is enumerating currently running processes\r\nConnecting to C2 servers\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 5 of 19\n\nThe next important step is to attempt to connect to one of the C\u0026C servers. To do this, Raccoon stealer generates a string\r\nlike:\r\nmachineId={machineguid}|{username}\u0026configId={c2_key}\r\nThen the program tries to send a POST request with the string to every possible server.\r\nRaccoon Stealer is trying to connect to C2s\r\nAn example of a connection request that was intercepted by the HTTP MITM proxy feature in ANY.RUN sandbox:\r\nRaccoon info stealer C2 connection request\r\nRaccoon info stealer C2 connection request \r\nIt is important to note that if there are multiple C\u0026C servers, the malware will only accept commands from the one it was\r\nable to connect to first. In response to the above request, the server will send the malware a configuration. If RecordBreaker\r\nfails to connect to any of the C\u0026C servers, it will stop its work.\r\nDescription of the malware configuration structure\r\nConfiguration lines are divided into prefixes, each tells the malware how to interpret a particular line. Here is a table\r\ndescribing these prefixes and what they do:\r\nPrefix Example\r\nlibs_\r\nlibs_nss3:http://{HOSTADDR}/{RANDOM_STRING}/nss3.dlllibs_msvcp140:http://{HOSTADDR}/{RANDOM_STRING}/msvcp140\r\nlibs_vcruntime140:http://{HOSTADDR}/{RANDOM_STRING}/vcruntime140.dll\r\ngrbr_\r\ngrbr_dekstop:%USERPROFILE%\\Desktop\\|*.txt, *.doc, *pdf*|-|5|1|0|files grbr_documents:%USERPROFILE%\\Documents\\|*.txt, *.doc\r\n*pdf*|-|5|1|0|files grbr_downloads:%USERPROFILE%\\Downloads\\|*.txt, *.doc, *pdf*|-|5|1|0|files\r\nwlts_\r\nwlts_exodus:Exodus;26;exodus;*;*partitio*,*cache*,*dictionar* wlts_atomic:Atomic;26;atomic;*;*cache*,*IndexedDB*\r\nwlts_jaxxl:JaxxLiberty;26;com.liberty.jaxx;*;*cache* \r\news_ ews_meta_e:ejbalbakoplchlghecdalmeeeajnimhm;MetaMask;Local Extension Settings\r\news_tronl:ibnejdfjmmkpcnlpebklmnkoeoihofec;TronLink;Local Extension\r\nSettingsews_bsc:fhbohimaelbohpjbbldcngcnapndodjp;BinanceChain;Local Extension Settings\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 6 of 19\n\nPrefix Example\r\nldr_ [missing in the configuration of the sample]\r\ntlgrm_ tlgrm_Telegram:Telegram Desktop\\tdata|*|*emoji*,*user_data*,*tdummy*,*dumps*\r\nscrnsht_ scrnsht_Screenshot.jpeg:1\r\ntoken 101f4cb19fcd8b9713dcbf6a5816dc74\r\nsstmnfo_ sstmnfo_System Info.txt:System Information: |Installed applications: |\r\nOnce the info stealer receives information concerning what kind of data to collect from C2, it proceeds to do so.\r\nSystem data collection\r\nThe stealer collects various information about the infected system, including the OS bitness, information about RAM, CPU,\r\nand user data like the applications installed in the system.\r\nRaccoon’s mechanisms for data collection:\r\n gets the size of the main monitor using user32.dll!GetSystemMetrics\r\nRaccoon malware v2 is getting the user’s display resolution\r\nRaccoon malware v2 is getting the user’s display resolution\r\n finds a list of GPU devices, using user32.dll!EnumDisplayDevicesW\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 7 of 19\n\nRaccoon Stealer is iterating through display devices\r\n determines the architecture (bitness) of the system by calling the x64-specific function\r\nkernel32.dll!GetSystemWow64DirectoryW and comparing the last error code with\r\nERROR_CALL_NOT_IMPLEMENTED\r\nRaccoon malware v2 is getting the user’s display resolution\r\nRaccoon malware v2 is getting the user’s display resolution\r\n  collects RAM information via kernel32.dll!GlobalMemoryStatusEx\r\nRaccoon malware ver.2 is checking the user’s system RAM information\r\nRaccoon malware ver.2 is checking the user’s system RAM information\r\n gets information about the user’s timezone by kernel32!GetTimeZoneInformation:\r\nRaccoon malware is collecting the user’s system timezone data\r\nRaccoon malware is collecting the user’s system timezone data\r\n grabs the OS version from the registry, using advapi32.dll!RegOpenKeyExW and advapi32.dll!RegQueryValueExW\r\nto read the value of the key  HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\r\nNT\\CurrentVersion\\ProductName\r\nRaccoonstealer gets the user’s OS version\r\n obtains Information about the vendor of the CPU using asm-instruction __cpuid:\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 8 of 19\n\nRaccoonstealer 2.0 is getting CPU vendor info\r\n gets CPU cores number with kernel32.dll!GetSystemInfo\r\nRaccoon malware is getting CPU cores count\r\nRaccoon malware is getting CPU cores count\r\n collects the user’s default locale info requesting kernel32.dll!GetUserDefaultLCID and\r\nkernel32.dll!GetLocaleInfoW\r\nRaccoon info stealer is getting the user’s default locale info\r\n grabs data about installed apps from the registry using advapi32.dll!RegOpenKeyExW,\r\nadvapi32.dll!RegEnumKeyExW, and advapi32.dll!RegQueryValueExW.\r\nThe “DisplayName” and “DisplayVersion” values of all \r\n\\HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall key sub-keys:\r\nRaccoon malware 2.0 is traversing through the user’s installed applications list\r\nRaccoon malware 2.0 is traversing through the user’s installed applications list\r\nAfter obtaining the system information, RecordBreaker gets ready to steal user data. The malware loads the previously\r\ndownloaded legitimate libraries to reach this goal.\r\nRaccoon Stealer is loading previously downloaded legitimate third-party libs\r\nRaccoon Stealer is loading previously downloaded legitimate third-party libs\r\nThis way, the program has the functions needed for operations:\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 9 of 19\n\nRaccoonstealer gets functions addresses from the newly loaded modules\r\nOnce the libraries have been loaded, Raccoon starts to collect user data.\r\nUser data collection\r\nCookies\r\nFirst of all, the stealer collects cookies. It creates a copy of the cookies file and tries to open it. If it fails to do so, the current\r\nsubroutine is terminated.\r\nRaccoon malware v2 is copying the cookies database and trying to open it\r\nIf the sample manages to open the database, it retrieves cookies from it by executing the SQL query \r\nSELECT host, path, isSecure, expiry, name, value FROM moz_cookies\r\n.\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 10 of 19\n\nRaccoon stealer v2 is executing a SQL request to retrieve data from the cookies database\r\nAutofill data\r\nThe next step in Raccoon’s “plan” is to retrieve the autofill data. The program tries to open the database logins.json:\r\nRaccoon Stealer 2.0 is trying to open the logins.json database\r\nThen the stealer tries to decrypt the data from that database, using the Зnss3.dll!PK11SDR_Decrypt method.\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 11 of 19\n\nRaccoon malware 2.0 decrypts encrypted logins.json database\r\nAfter that, the malware formats collected data like so: \r\n“URL:%s\\nUSR:%s\\nPASS:%s”\r\nUsing encrypted data, Raccoon malware formats it to a more readable state\r\nUsing encrypted data, Raccoon malware formats it to a more readable state\r\nAutofill form data\r\nAfter these manipulations, the stealer collects the autofill form data. It attempts to open the formhistory.sqlite database:\r\nRaccoon info stealer tries to open another database\r\nIf the connection to the database is successful, the program retrieves form data values from it with an SQL query like:\r\nSELECT name, value FROM autofill\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 12 of 19\n\nRaccoonstealer is executing another SQL request to retrieve data\r\nRecordBreaker concatenates all data together and sends POST requests to C2. ANY.RUN sandbox’s HTTP MITM proxy\r\nfeature intercepts all the data that the malware has managed to collect.\r\n SystemInfo POST request\r\nSystem info request made by Raccoon aka RecordBreaker \r\nUserInfo POST request\r\nUser info request made by Raccoon malware \r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 13 of 19\n\nWhen the C2 server gets each chunk of data, it responds “received”:\r\nC2 server responds\r\nCrypto-wallets, Custom, and Telegram file data collection\r\nCrypto-wallets data\r\nRecordBreaker is looking for users’ crypto-wallets data using filters and templates retrieved from the configuration.\r\nRecordBreaker is looking for the user’s crypto-wallets data\r\nCustom files\r\nThen, the wallet.dat file is searched (it contains local information about the bitcoin wallet). After that, the stealer looks for\r\narbitrary files from custom directories specified in the configuration.\r\nRaccoonstealer is looking for any custom files\r\nTelegram messenger files \r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 14 of 19\n\nThe sample is looking for files related to Telegram messenger using data from the configuration.\r\nRecordBreaker is looking for files related to Telegram messenger\r\nAfter the malware has sent all the files, it takes a screenshot(s). \r\nRaccoon malware v2 is making screenshots of the user’s environment\r\nAn example of a screenshot captured by ANY.RUN:\r\nThe screenshot made by the 2d version of Raccoon malware\r\nIf any additional commands are provided in configuration, the sample will execute them before finishing its work. For\r\nexample, Raccoon executes other commands with the help of WinAPI (shell32.dll!ShellExecuteW) if C2 has sent them in\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 15 of 19\n\nthe prefix ldr_:\r\nRaccoonstealer executes extra commands \r\nThen, the malware releases the remaining allocated resources, unloads the libraries, and finishes its work.\r\nRaccoon configuration extraction\r\nYou can use our Python script to extract C2 servers from the unpacked Raccoon sample, or get malware configuration right\r\nin our service, which will unpack the sample from memory dumps and extract C2s for you:\r\nRaccoon malware configuration\r\nimport os, sys, re, string\r\nfrom enum import IntEnum\r\nfrom base64 import b64decode, b64encode\r\nfrom malduck import xor, rc4, base64\r\n# c2 buffer len \u0026 invalid c2 placeholder\r\nRACCOON_C2_PLACEHOLDER = b\" \" * 64\r\nRACCOON_C2_BUFF_LEN = len(RACCOON_C2_PLACEHOLDER)\r\n# c2s array size \u0026 key size\r\nRACCOON_C2S_LEN = 5\r\nRACCOON_KEY_LEN = 32\r\nclass ERaccoonBuild(IntEnum):\r\n UNKNOWN_BUILD = -1,\r\n OLD_BUILD = 0,\r\n NEW_BUILD = 1\r\n# extracts ascii and unicode strings from binary file\r\nclass RaccoonStringExtractor:\r\n ASCII_BYTE = string.printable.encode()\r\n c2_list = []\r\n rc4_key = str()\r\n xor_key = str()\r\n raccoon_build = ERaccoonBuild.UNKNOWN_BUILD\r\n \r\n def __init__(self, binary_path) -\u003e None:\r\n with open(binary_path, 'rb') as bin:\r\n self.buffer = bin.read()\r\n self.__process_strings()\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 16 of 19\n\ndef __is_base64_encoded(self, data) -\u003e bool:\r\n try:\r\n data = data.rstrip()\r\n return b64encode(b64decode(data)) == data\r\n except Exception:\r\n return False\r\n def __is_valid_key(self, key) -\u003e bool:\r\n key_re = re.compile(rb\"^[a-z0-9]{%d,}\" % RACCOON_KEY_LEN)\r\n return re.match(key_re, key)\r\n def __process_strings(self) -\u003e None:\r\n ascii_re = re.compile(rb\"([%s]{%d,})\" % (self.ASCII_BYTE, 4))\r\n self.c2_list = []\r\n ascii_strings = []\r\n for i, match in enumerate(ascii_re.finditer(self.buffer)):\r\n a_string = match[0]\r\n offset = match.start()\r\n string_entry = (a_string, offset)\r\n ascii_strings.append(string_entry)\r\n if len(a_string) == RACCOON_C2_BUFF_LEN and \\\r\n a_string != RACCOON_C2_PLACEHOLDER and \\\r\n self.__is_base64_encoded(a_string) == True:\r\n self.raccoon_build = ERaccoonBuild.OLD_BUILD\r\n print(f\"[+] found possible encrypted c2 {a_string.rstrip()} at {hex(offset)}\")\r\n self.c2_list.append(string_entry)\r\n if len(self.c2_list) == 1: # first c2 found\r\n rc4_key, offset = ascii_strings[i-1]\r\n # rc4 key should be 32-bytes long and contain only a-z 0-9 chars\r\n if self.__is_valid_key(rc4_key):\r\n self.rc4_key = rc4_key\r\n print(f\"[+] found possible rc4 key {self.rc4_key} at {hex(offset)}\")\r\n else:\r\n continue\r\n \r\n # have we found any c2s yet?\r\n if len(self.c2_list) == 0:\r\n for a_string, offset in ascii_strings:\r\n if len(a_string) == RACCOON_KEY_LEN and self.__is_valid_key(a_string):\r\n self.raccoon_build = ERaccoonBuild.NEW_BUILD\r\n self.xor_key = a_string\r\n print(f\"[+] found possible xor key {self.xor_key} at {hex(offset)}\")\r\n \r\n # extract c2s for new builds\r\n curr_offset = offset + 36\r\n for _ in range(0, RACCOON_C2S_LEN):\r\n enc_c2 = self.buffer[curr_offset : curr_offset + RACCOON_C2_BUFF_LEN]\r\n \r\n if enc_c2.find(0x20) != 0 and enc_c2 != RACCOON_C2_PLACEHOLDER: # check if c2 is empty\r\n print(f\"[+] found possible encrypted c2 {enc_c2.rstrip()} at {hex(curr_offset)}\")\r\n self.c2_list.append((enc_c2, curr_offset))\r\n curr_offset += RACCOON_C2_BUFF_LEN + 8 # each c2 is padded by 8 bytes\r\n return # don't process strings any further\r\n else:\r\n return\r\n print(f\"[!] C2Cs not found, could be a new build of raccoon sample\")\r\nclass RaccoonC2Decryptor:\r\n def __init__(self, sample_path: str) -\u003e None:\r\n self.extractor = RaccoonStringExtractor(sample_path)\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 17 of 19\n\ndef __is_valid_c2(self, c2):\r\n return re.match(\r\n rb\"((https?):((//)|(\\\\\\\\))+([\\w\\d:#@%/;$()~_?\\+-=\\\\\\.\u0026](#!)?)*)\", c2\r\n )\r\n def decrypt(self) -\u003e bool:\r\n raccoon_build = self.extractor.raccoon_build\r\n if raccoon_build == ERaccoonBuild.OLD_BUILD:\r\n return self.decrypt_method_1()\r\n elif raccoon_build == ERaccoonBuild.NEW_BUILD:\r\n return self.decrypt_method_2()\r\n else:\r\n return False # unknown raccoon build\r\n def decrypt_method_1(self) -\u003e None:\r\n for enc_c2, _ in self.extractor.c2_list:\r\n decrypted_c2 = rc4(\r\n self.extractor.rc4_key,\r\n base64(enc_c2.rstrip())\r\n )\r\n if self.__is_valid_c2:\r\n print(f\"[\u003e] decrypted c2: {decrypted_c2}\")\r\n else:\r\n print(f\"[!] invalid c2: {decrypted_c2}\")\r\n def decrypt_method_2(self) -\u003e None:\r\n for enc_c2, _ in self.extractor.c2_list:\r\n decrypted_c2 = xor(\r\n self.extractor.xor_key,\r\n enc_c2.rstrip()\r\n )\r\n \r\n if self.__is_valid_c2:\r\n print(f\"[\u003e] decrypted c2: {decrypted_c2}\")\r\n else:\r\n print(f\"[!] invalid c2: {decrypted_c2}\")\r\ndef main():\r\n # parse arguments\r\n if len(sys.argv) == 2:\r\n sample_path = os.path.abspath(sys.argv[1])\r\n else:\r\n print(f\"[!] usage: {os.path.basename(__file__)} \u003csample path\u003e\")\r\n return False\r\n try:\r\n RaccoonC2Decryptor(sample_path).decrypt()\r\n except Exception as ex:\r\n print(f\"[!] exception: {ex}\")\r\nif __name__ == '__main__':\r\n main()\r\nIOCs\r\nFilename SHA-256\r\n\\AppData\\LocalLow\\nss3.dll c65b7afb05ee2b2687e6280594019068c3d3829182dfe8604ce4adf2116cc46e\r\n\\AppData\\LocalLow\\msvcp140.dll 2db7fd3c9c3c4b67f2d50a5a50e8c69154dc859780dd487c28a4e6ed1af90d01\r\n\\AppData\\LocalLow\\vcruntime140.dll 9d02e952396bdff3abfe5654e07b7a713c84268a225e11ed9a3bf338ed1e424c\r\n\\AppData\\LocalLow\\mozglue.dll 4191faf7e5eb105a0f4c5c6ed3e9e9c71014e8aa39bbee313bc92d1411e9e862\r\n\\AppData\\LocalLow\\freebl3.dll b2ae93d30c8beb0b26f03d4a8325ac89b92a299e8f853e5caa51bb32575b06c6\r\n\\AppData\\LocalLow\\softokn3.dll 44be3153c15c2d18f49674a092c135d3482fb89b77a1b2063d01d02985555fe0\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 18 of 19\n\nFilename SHA-256\r\n\\AppData\\LocalLow\\sqlite3.dll 1b4640e3d5c872f4b8d199f3cff2970319345c766e697a37de65d10a1cffa102\r\nHTTP/HTTPS Requests:\r\nhttp://[C2 address]/\r\nhttp://[C2 address] /aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/nss3.dll\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/msvcp140.dll\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/vcruntime140.dll\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/mozglue.dll\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/freebl3.dll\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/sqlite3.dll\r\nhttp://[C2 address]/[config token]\r\nhttp://[C2 address]/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/softokn3.dll\r\nConclusion\r\nWe have done malware analysis of the Raccoon stealer 2.0 performance using a v2 sample in ANY.RUN sandbox. The\r\nexamined sample has used various techniques to evade detection: legitimate libraries for data collection, dynamic library\r\nloading, string encryption, and C\u0026C server encryption. Some examples are additionally protected by packers or being a part\r\nof other malware.\r\nCopy the script of Raccoon stealer and try to extract C2 servers by yourselves and let us know about your results.\r\nAnd write in the comments below what other malware analysis you are interested in. We will be glad to add it to the series!\r\nA few words about ANY.RUN \r\nANY.RUN is a cloud malware sandbox that handles the heavy lifting of malware analysis for SOC and DFIR teams. Every\r\nday, 300,000 professionals use our platform to investigate incidents and streamline threat analysis.  \r\nRequest a demo today and enjoy 14 days of free access to our Enterprise plan. \r\nRequest demo → \r\nReverse Engineer. Malware Analyst at ANY.RUN\r\nhardee\r\nReverse Engineer, Malware Analyst at ANY.RUN at ANY.RUN | + posts\r\nI contribute to open source from time to time and I am always up for a challenge.\r\nI contribute to open source from time to time and I am always up for a challenge.\r\nSource: https://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nhttps://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/\r\nPage 19 of 19\n\n https://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/   \nRaccoon stealer v2 is executing a SQL request to retrieve data from the cookies database\nAutofill data    \nThe next step in Raccoon’s “plan” is to retrieve the autofill data. The program tries to open the database logins.json:\nRaccoon Stealer 2.0 is trying to open the logins.json database  \nThen the stealer tries to decrypt the data from that database, using the Зnss3.dll!PK11SDR_Decrypt method.\n  Page 11 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://any.run/cybersecurity-blog/raccoon-stealer-v2-malware-analysis/"
	],
	"report_names": [
		"raccoon-stealer-v2-malware-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434350,
	"ts_updated_at": 1775826751,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d5ce1ff47f61c71602dee36184b45cb9542de9a5.pdf",
		"text": "https://archive.orkl.eu/d5ce1ff47f61c71602dee36184b45cb9542de9a5.txt",
		"img": "https://archive.orkl.eu/d5ce1ff47f61c71602dee36184b45cb9542de9a5.jpg"
	}
}