A Deep Dive Into DarkME Rat Malware

DarkMe RAT steals information from victims' machines and responds to various commands received from its Command and Control (C&C) server. A spike in distributing DarkMe RAT was observed in February 2024, exploiting the zero-day (CVE-2024-21412) by the hacking group Water Hydra. The SonicWall threat research team recently analyzed a variant of the DarkMe RAT malware. Execution of DarkMe RAT starts from a Windows Shortcut File (LNK) which uses a Microsoft Installer File and COM DLL registration to evade detection from security software.

Windows Shortcut File

The Windows Shortcut File (LNK) displays an image related to a stock trading graph to distract the user while a malicious batch script from a URL is executed in the background. The batch script is responsible for downloading and executing the malicious Microsoft Installer File (MSI). MSI files are not commonly used by malware authors and thus arouse less suspicion from security software.

[Link]

Figure 1: Content of Windows Shortcut File

[Link]

Figure 2: Image displayed to the user

A URL-hosted batch script downloads the MSI file into the %temp% folder and starts its execution.

[Link]

Figure 3: Content of batch script

The LNK file, along with the MSI file, is hosted on a WebDAV share by the threat actor.

[Link]

Figure 4: Content of attacker-hosted server

Microsoft Installer File

Windows Installer (msiexec.exe) extracts files from "oxc.msi" and starts executing the DLL file "AFWIKFNMUI9430.ocx" using rundll32 by calling the exported function "RunDllEntryPointW." The malware involves the execution of multiple executable files to load and execute the encrypted DarkMe RAT binary "Video01.mp4."

[Link]

Figure 5: Files extracted from MSI file

First Executable (AFWIKFNMUI9430.ocx)

The malware copies extracted files from the directory "%temp%" to "%appdata%\ WMProjectFiles" and imports registry entries from "info.txt" using the Registry Console Tool (reg.exe). The "info.txt" file contains registry entries to register the COM DLL "soundtrack.ocx" with CLSID "AAE802DB-FB67-4407-A175-61223EFF30D4." The registered COM DLL is executed by "rundll32" with the CLSID in a Single-Threaded Apartment (STA) using the below command line: "rundll32.exe" /sta {AAE802DB-FB67-4407-A175-61223EFF30D4}

[Link]

Figure 6: Content of registry file

Second Executable (soundtrack.ocx)

The malware copies a legitimate executable file from "%appdata%\WMProjectFiles\Sound.mp3" to "%appdata%\ProductConfigurations\WINDBVERS.EXE," which is a targeted file for process hollowing to execute the DarkMe RAT binary. The malware decrypts the binary file "%appdata%\WMProjectFiles\WMFile01.tmp" into a DLL file "C:\Users\Public\Libraries\WMFile01.dll." The file can be decrypted using a single byte XOR operation except for the initial few bytes of the MZ header. The malware invokes the decrypted DLL with the exported function "VBDLLDEMO."

Third Executable (WMFile01.dll)

The DLL file decrypts the final payload (Video01.mp4) using the same logic used to decrypt the file (WMFile01.dll). The malware creates a suspended process for a legitimate file "%appdata%\ProductConfigurations\WINDBVERS.EXE" and resumes its execution after loading the DarkMe RAT malware code using process hollowing.

DarkME RAT

The Visual Basic compiled DarkMe RAT executable is highly obfuscated to make analysis of the file more difficult. While debugging, the malware makes the analyst go through the obfuscation code inside each module or function call.

Obfuscation

The malware code is obfuscated with a large amount of garbage code preceded by an always-followed jump instruction to the next executable code. The address followed by the jump may be a malware instruction or further obfuscated code.

[Link]

Figure 7: Obfuscated code

An IDA Python script can be used to simplify the obfuscated code, making it easier to debug. The Python script searches for obfuscated code and replaces it with a single jump instruction to the actual malware code.

[Link]

Figure 8: IDA Python script to remove obfuscation

String Encoding

The malware keeps the strings encoded, decoding them before use. Strings are encoded by their hex values, sometimes through a single iteration or sometimes through a double iteration.

[Link]

Figure 9: Strings decryption

Single Instance Execution

The malware checks for the window name "MS-Office network" using the API FindWindowA and terminates its execution if the window name is found. If the malware instance is not already running, the malware creates a window named "MS-Office network" and continues executing the malicious code.

Data Exfiltration

The malware collects various information from the victim's machine, including the country name, information about the installed antivirus product, computer name, username, and active window name. To retrieve the country information, the malware uses the API GetLocalInfoA with arguments "LOCALE_SISO3166CTRYNAME" and "LOCALE_SENGLISHCOUNTRYNAME," which gets values "US" and "United States" respectively.

[Link]

Figure 10: English name of the country

[Link]

Figure 11: ISO-based name of the country

The malware retrieves the computer name and username information from the environment variables.

[Link]

Figure 12: Gets computer name and username

The malware gets the installed antivirus information using Windows Management Instrumentation (WMI) queries. All the strings related to WMI queries are kept encrypted and are decrypted by adding 0x0A to each byte of the encrypted string.

[Link]

Figure 13: Decryption logic for WMI-related queries

The malware executes the query "SELECT * FROM AntivirusProduct" to retrieve the installed antivirus details.

[Link]

Figure 14: Code to retrieve AV information

The malware gets the active window name using the APIs GetForegroundWindow and GetWindowTextA. The information can be used by threat actors at the C&C server to identify the debugging environment. For example, if the malware is being debugged using the IDA debugger, threat actors will receive the active window name as "IDA" and can avoid further communication with the targeted machine.

Network Communication

The RC4 encrypted C2 address (AA1EC8EE260AEB1B34081CA091FD29F6240C4F) is decrypted using the RC4 key "noway123!$$#@35@!" to get the C2 address "unfawjelesst322.com." The malware gets the IP address for the decrypted C2 host using the API gethostbyname and uses socket APIs for communicating with the C2 server.

[Link]

Figure 15: C2 information

The malware collects and sends system information to the C2 server using the send API from DLL ws2_32.dll. The stolen information is separated using the delimiter "0xA9."

[Link]

Figure 16: Stolen Information

Asynchronous Commands from C2

The malware creates a window using the API CreateWindowExA for the "STATIC" class with the window name "SOCKET_WINDOW" and registers a callback function with the API SetWindowLongA. The callback function is responsible for receiving data from the C2 server using the recv API from DLL "wsock32.dll." The malware registers the window "SOCKET_WINDOW" to receive network events for the socket connected to the C2 server using message number "401."

[Link]

Figure 17: Register window to get socket event

When the callback function for the window "SOCKET_WINDOW" receives message number "401," it receives a command from the C2 server using the API recv from wsock32.dll.

[Link]

Figure 18: Window callback function to receive commands from C2

The malware supports the following commands from the C2 server:

• STRFLS
• STRFL2
• 300100
• SHLEXE
• RNMFIL
• DELDEL
• DIRMAP
• DELMAP
• SEITUS
• SEITUD
• ZIPALO
• FRIKAT
• COPALO
• PASALO

Persistence Entry

The malware registers the COM DLL "%appdata%\ \WMProjectFiles\soundtrack.ocx" and creates a persistence entry by adding a registry entry into "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" for executing the COM DLL.

[Link]

Figure 19: Registers COM DLL

[Link]

Figure 20: Makes persistence entry

Only a few security providers are detecting the LNK file at the time of analysis in popular threat intelligence sharing portals like VirusTotal and ReversingLabs, indicating its uniqueness and evasiveness:

[Link]

Figure 21: LNK Detections on VirusTotal

Evidence of detection by the RTDMI(tm) engine can be seen below in the Capture ATP report for this file.

[Link]

Figure 22: Capture report