What We Do
How We Do
Resources
Company
Partners
Get Started
Blog

Introducing Gh0stGambit: A Dropper for Deploying Gh0st RAT

BY eSentire Threat Response Unit (TRU)

July 24, 2024 | 13 MINS READ

Attacks/Breaches

Threat Intelligence

Threat Response Unit

TRU Positive/Bulletin

Want to learn more on how to achieve Cyber Resilience?

TALK TO AN EXPERT

Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes.

We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware.

Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team.

In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward.

Here’s the latest from our TRU Team…

What did we find?

In early June, eSentire’s Threat Response Unit (TRU) identified multiple Gh0st RAT infections stemming from malicious installer packages masquerading as Chrome browser. In these cases, the Gh0st RAT variant was initiated by what we are dubbing Gh0stGambit, an evasive dropper used to retrieve and execute encrypted payloads.

Gh0st RAT is a longstanding remote access trojan with various data collection and remote-control capabilities. The widespread availability of its source code has led to its extensive use and customization by various cybercriminals and hacking groups. The RAT gained widespread attention in 2009 thanks to its use in GhostNet, a large-scale cyber espionage operation.

The command-and-control infrastructure of GhostNet was primarily based in the People's Republic of China. The operation compromised various high-value targets, including embassies, foreign ministries, other government offices, and the Dalai Lama's Tibetan exile centers in India, London, and New York City. Since then, Gh0st RAT variants have been employed by threat groups including but not limited to Lazarus Group, Earth Berberoka, GALLIUM, and many others.

The Gh0st RAT variant described here has been modified with open-source projects to enhance its capabilities. Additionally, we assess with high confidence that this campaign is primarily targeted at Chinese-speaking users. This assessment is based on the use of Chinese-language web lures and Chinese applications targeted for data theft and defense evasion by the malware.

In the infection cases we observed, the initial payload arrived via drive-by download when the user searched for Chrome on the internet and attempted to download a Chrome installer named ChromeSetup.msi (MD5: af2debe45edd4a10a07b2afeec81bf87) from chrome-web[.]com (Figure 1).

Figure 1: Malicious page serving fake Google Installer

The MSI installer contains two files, one is a legitimate Chrome installer, and the second one is a malicious installer (WindowsProgram.msi, MD5: 4bf494f15fcc172b98abeb5a02ecffed).

Figure 2: Contents of ChromeSetup.msi

WindowsProgram.msi (MD5: 4bf494f15fcc172b98abeb5a02ecffed) contains the following files:

The files are dropped under the “C:\Program Files\Windows Defenderr” path. Both files 1 and 2 have hidden file attributes to conceal their presence on the system. The “1” file that is later renamed to “Phone.exe” is responsible for loading and running the shellcode in the memory of a running process.

The main part of the shellcode starts at approximately 231175 bytes. The shellcode contains an encrypted payload that is decrypted through a multi-step process (Figure 3) outlined below:

  1. The counter state is initialized and then XORed with a hardcoded key. Both the initial counter state and the key are hardcoded, establishing the initial modified counter state for the encryption or decryption process.
  2. The encrypted data is processed block by block. For each block, the current counter state is first XORed with the key to prepare it for the transformation rounds.
  3. The XORed counter state undergoes 16 rounds of transformations involving bitwise rotations and additions.
  4. After completing the 16 rounds, the transformed state is XORed again with the key to produce the final keystream for the current block.
  5. Each byte of the encrypted block is then XORed with the corresponding byte from the final keystream to produce the decrypted data for that block.
  6. The counter is incremented after processing each block. This ensures that each block is encrypted (or decrypted) with a unique keystream, as the counter change affects the initial state for each block, leading to a different keystream generation even if two blocks of data are identical.
  7. The next stage payload (Gh0stGambit) is then decompressed with aPLib.

While analyzing the decryption algorithm , we determined that the shellcode appears to be generated using the open source Donut loader. We wrote a decryption script, which you can access here.

Figure 3: Snippet of the decryption hosg

Gh0stGambit Dropper

We dubbed the next stage payload Gh0stGambit Dropper (MD5: dcadba35680a03e44d91191d0d9a4d47). Gh0stGambit creates a .cmd file with a batch script (Figure 5, insert) and uses the CoCreateGuid API to create a unique GUID which is used as a filename for the script. It’s also worth noting that the shellcode file and Gh0stGambit dropper are dropped under “C:\ProgramData\{ unique_GUID_1}\{unique_GUID_2}\” (Figure 4).

Figure 4: The payloads being placed under C:\ProgramData\{ unique_GUID_1}\{unique_GUID_2}\

The batch script checks if the PID of the dropper is running and if not, it starts the dropper twice with a 5-second delay in between. Immediately after deleting itself, the script jumps to the end of the file, which exits the script, however, the script fails to delete itself because the attribute of the script file is set to hidden. If the script finds that the loader process is running, it waits for 20 seconds (ping -n 20 127.0.0.1 > null) and then repeats the check (goto loop).

Figure 5: The code responsible for creating the script file (on the left) and the script file (on the right)

Gh0stGambit checks if the 360 Safe Guard process is running (ZhuDongFangYu.exe); if it is, the dropper associates the path “C:\ProgramData\Microsoft\Windows\Start Menu\Programs” with logical drive L:\ under “HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\DOS Devices”. This registry path is used to manage DOS device names and their mappings to physical or logical filesystem paths.

An empty file “One Drive.vt” is created under “L:\” and is moved to “L:\Startup” after a system reboot (Figure 6). It’s likely that the association with the logical drive is used for evasion purposes. The unusual drive mapping can help avoid detection from both users and antivirus programs that might not expect executable files or suspicious activity in what appears to be a drive like any other.

Gh0stGambit sets up a new registry entry under “HKEY_CLASSES_ROOT\.VT” that defines .VT as a recognized file type. The default value is set to "NNLPS", which serves as an identifier linking the extension. Another key under “HKEY_CLASSES_ROOT\NNLPS\shell\open\command” is then configured to specify what action should be taken when a .VT file is opened. The command associated here is to execute "Phone.exe" under “C:\ProgramData\{unique_GUID_1}\{unique_GUID_2}\”.

Figure 6: The code responsible for logical drive and file extension associations

The dropper then checks if the Windows Defender service “WinDefend” is running, if it is then it adds “C:\Program Files\Windows Defenderr” to the exclusions of Windows Defender.

Figure 7: Adding "C:\Program Files\Windows Defenderr" to the Windows Defender exclusion

If the Windows Defender service is not present, it creates a text file under “C:\ProgramData\{unique_GUID_1}\{unique_GUID_3}\” with the following content:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]
"Startup"="C:\\ProgramData\\{unique_GUID_1}\\{unique_GUID_4}"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"Phone"=" C:\\ProgramData\\{unique_GUID_1}\\{unique_GUID_2}"\\Phone.exe"

We will come back to the contents of the text file later.

Next, it connects to the C2, in our example, at hxxp://pplilv.bond/d4/107.148.73[.]225/reg32 and retrieves an encrypted file that appears to be Registry Workshop, a registry editor tool (MD5: d96a742899aeab9eaba691861908e316).

The tool is placed under “C:\ProgramData\{unique_GUID_1}\{unique_GUID_5}.exe. The dropper then creates a shortcut file under a newly created directory at “C:\ProgramData\{unique_GUID_1}\{unique_GUID_6}\{unique_GUID_7}.lnk”.

The shortcut file is responsible for running the registry editor tool via the command “C:\ProgramData\{unique_GUID_1}\{unique_GUID_5}.exe /s " C:\ProgramData\{unique_GUID_1}\{unique_GUID_3}”.

Recall this is the previously mentioned text file containing registry data. Thus, running the file would create two persistence mechanisms via registry keys. Each registry key instructs the system to automatically execute the shortcut file named “One Drive.lnk” (MD5: 1577ad0ef0cc41b6e830c2c60821daa0) under “C:\\ProgramData\\{unique_GUID_1}\\{unique_GUID_4}" and Phone.exe when a user logs into their computer.

After running the text file, Gh0stGambit removes the directory containing the shortcut file at “C:\ProgramData\{unique_GUID_1}\{unique_GUID_6}\{unique_GUID_7}.lnk”, the registry editor tool as well as the text file to eliminate any traces.

To avoid multiple instances of the dropper running, it creates a named pipe “\\\\.\\pipe\\WF3ss22NHFsnBgfsHDF6”.

File Decryption

Gh0stGambit retrieves two encrypted files via its C2 using “/code32” and “/reg32” as a part of the URL to mark the files, for example:

The retrieved files are decrypted via XOR; the 20-byte XOR key is hardcoded into the file and resets at index 0x2C. After XOR decryption, the decrypted data undergoes aPLib decompression, which takes place in the loaded shellcode to obtain the final file. The shellcode includes API function names that are hashed using the BKDR hashing algorithm.

Below is a Python implementation of this hashing process:

def BKDRHash(api_name):
    hash_result = 0
    hash_seed = 131 
    for character in api_name:
        hash_result = (hash_result * hash_seed + ord(character)) & 0xFFFFFFFF 
    hash_result = hash_result & 0x7FFFFFFF 
    return hash_result

# Testing the function
resulting_hash = BKDRHash("VirtualAlloc")
print(f"Hash: {hex(resulting_hash)}")

This is a part of the implementation of DLLToShellCode, an open-source tool designed to convert Windows DLLs (Dynamic Link Libraries) into executable shellcode. The tool facilitates binary code manipulation, particularly when execution directly from memory is required without loading the DLL file itself.

The allocation of executable memory and the injection of shellcode into this memory are carried out using native APIs like NtAllocateVirtualMemory and NtWriteVirtualMemory, which are dynamically loaded (Figure 8).

Figure 8: Shellcode execution at allocated_memory_func_ptr

During our research, we uncovered additional domains related to Gh0stGambit that are included here.

Gh0st RAT Variant

Gh0st RAT is written in C++ and has many features, including terminating processes, removing files, capturing audio and screenshots, remote command execution, keylogging, data exfiltration, hiding registry, files, and directories via the rootkit capabilities, and many more. AhnLab provided technical analysis on a similar sample.

The RAT creates a driver.sys file in the C:\ProgramData\Microsoft Drive directory, which contains the encrypted data of the user's inputs as part of its keylogging capabilities (Figure 9). The data is decrypted using a simple XOR.

Figure 9: Snippet of the decrypted data (driver.sys)

The RAT contains a list of commands, some of which are listed below:

Command

Description

0x27

Run the process with elevated privileges

0x28

Terminate explorer.exe process

0x29

Delete Internet Explorer history via /;cmd.exe /c RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255” command

0x2A

Remove files and directories under \AppData\Local\Google\Chrome\User Data\Default

0x2B

Remove data under AppData\Roaming\Microsoft\Skype for Desktop

0x2C

Remove database files for Mozilla Firefox via “del /s /f %appdata%\Mozilla\Firefox\Profiles\*.db” command

0x2D

Remove data for 360 Secure Browser under \AppData\Roaming\360se6\User Data\Default

0x2E

Remove data for QQ Browser under \AppData\Local\Tencent\QQBrowser\User Data\Default

0x2F

Remove data for Sogou Explorer under \AppData\Roaming\SogouExplorer

0x45

Audio capture

0x48

Retrieve the QQ number, an account number for Tencent QQ, an instant messaging software platform in China

0x5A

Display the message box

0x5B

Crate MarkTime registry value under HKEY_CURRENT_USER\UUByte\Setup with date of the initial execution of the malware

0x5C

Execute remote commands via cmd.exe

0x5D

System shutdown

0x5E

Process termination

0x5F

Remove Uninstall registry key under HKEY_CURRENT_USER\UUByte\ if present

0x60

Clear event logs (Application, Security and System logs)

0x64

Open CD tray, force system reboot

0x72

File execution

0x75

Change screen resolution (attempts to set the screen resolution to 1600x900 with a color depth of 32 bits per pixel. If applying these settings fails, it reverts to the default settings)

0x7F

Gather system information such as OS, CPU, system uptime, memory, information related to Terminal Services (Remote Desktop Services)

0x9F

Extract Chrome passwords

0x83

Add guest account and elevate the guest account to the administrator level via “net user guest /active:yes && net user guest 123456 && net localgroup administrators guest /add” command

0x85

Enable RDP and change the port number

0x87

Disable RDP

0x8D

Delete a user account from the network and the local system using the NetUserDel API, and remove associated records within the SAM database in the registry, respectively.

0x8F

Check the state of a Remote Desktop Service session

0x90

Log off the RDP session

0x91

Disconnect from RDP session

Gh0st RAT includes an embedded rootkit (MD5: 1e7dccdacced54c5d3515c2d6f5b9f00) that conceals registry keys, processes, files, and directories. This component of the code was adapted from an open-source project available on GitHub (Figure 10).

Figure 10: A snippet of the function that queries and allocates registry data related to the rootkit functionality

The RAT attempts to read a specific registry value under “HKEY_CURRENT_USER\UUByte\Setup\Uninstall”, which is expected to contain the domain information for establishing a connection. If it successfully retrieves this data and confirms that it contains a domain in a valid format, the RAT will parse and use this domain for connectivity.

If the registry does not provide the expected information, the function defaults to using “hacker.heikeniubi[.]buzz” or “87df223265[.]cyou” as fallback command and control (C2) domains.

Gh0st RAT can drop Mimikatz (GetMP.exe) under the system folder, as shown in Figure 11.

Figure 11: The snippet with the command to display credentials for logged-on users

Additionally, the RAT also gathers the group members and friend list information from the QQ application, which suggests that the RAT was developed to primarily target Chinese-speaking users.

Lastly, it’s also worth noting that Gh0st RAT uses a separate DLL called “CHROMEUSERINFO.dll” (MD5: 82408e48f97f6c41b825b97a2e026831) to access two export functions named “fnGetChromeUserInfo” and “fnDeleteChromeUserInfo”. fnGetChromeUserInfo function is responsible for accessing Chrome's local state and login data, which includes credentials, installed extensions, and browser configuration data.

What did we do?

What can you learn from this TRU Positive?

Recommendations from our Threat Response Unit (TRU):

Indicators of Compromise

You can access the Indicators of Compromise here.

Detection rules

You can access the Yara rules here and here.

References

eSentire Unit
eSentire Threat Response Unit (TRU)

The eSentire Threat Response Unit (TRU) is an industry-leading threat research team committed to helping your organization become more resilient. TRU is an elite team of threat hunters and researchers that supports our 24/7 Security Operations Centers (SOCs), builds threat detection models across the eSentire XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. By providing complete visibility across your attack surface and performing global threat sweeps and proactive hypothesis-driven threat hunts augmented by original threat research, we are laser-focused on defending your organization against known and unknown threats.

Read the Latest from eSentire