[Studying] Analyzing Gh0st RAT Beta 2.5-3.6

First Post:

Last Update:

Word Count:
1.9k

Read Time:
11 min

Introduction

This article is part of my series: Inside Different Generations of RATs. It is also part of the Gh0st Family

If you are interested in the full series, please refer to the linked articles above.

Key findings include:

  • Self-destroy feature

Important: Since the Gh0st family contains numerous variants, it is difficult to analyze all of them within a single article. Future posts in this series will examine additional Gh0st variants and provide supplementary analysis.

Gh0st

The Ghost (Gh0st) malware is a widely used remote administration tool (RAT) that originated in China in the early 2000s. It has been the subject of many analysis reports, including those describing targeted espionage campaigns like Operation Night Dragon and the GhostNet attacks on Tibet.

Gh0st is an open-source application. There are enormous verious can be found on the internet (more than 30 verios, not including those with different names), which are released by different developers.

It is important to note that there is no official naming convention for Gh0st variants. Many versions were released by anonymous developers in underground communities, which can make identification confusing when analyzing samples.

One of the most well-known branches of the Gh0st family is DHL, which stands for Dà Huī Láng — the transliteration of “大灰狼” in Chinese. Both Gh0st and DHL were widely circulated during that period, and many people are often confused about the relationship between them. In short, DHL is a branch of Gh0st. In face, DHL frequently contain keywords such as GHOST and Gh0st 2.

Another well-known variant is Gh0stCringe, which is a more modern implementation reportedly used by several APT groups.

Overall, the original Gh0st project serves as the foundation for many later variants.

Since numerous verions of Gh0st are available online, I decided to analyze them in separate articles. In a future post, I will summarize the evolution of Gh0st variants and present them as a timeline.

This article is the first in the series and focuses on a reverse engineering analysis of an early version.

Gh0st Beta 3.6 is one of the most well-known open-source versions of Gh0st, and many later variants were developed based on it. However, this article uses Gh0st Beta 2.5 for demonstration because it proved to be more stable during experimentation.

Experimental Environment

To safely conduct malware analysis, the environment should be isolated using virtual machines. Under no circumstances should malware be executed on a personal or production system.

Tool Description
ExeInfo PE Executable analysis tool used to detect packers, compilers, and basic file properties
Detect It Easy (DIE) File identification tool used to detect packers, protectors, and compiler signatures
Immunity Debugger Windows debugger commonly used for reverse engineering, malware analysis, and exploit development
Wireshark Network protocol analyzer used for packet capture and traffic analysis
Ghidra Open-source software reverse engineering framework developed by the NSA

Device IP Address Description
Windows XP x86 (VM) 192.168.85.2 Victim machine used for executing both the controller and payload
Windows 10 x64 (VM) 192.168.85.3 Analysis machine used for reverse engineering

The two virtual machines were configured within an isolated internal network to prevent unintended external communication. If you want to know how to set up your experimental environment, please view:


Simplified Chinese Environment

Compared to the previous articles in this series, Gh0st was primarily designed for Simplified Chinese users. The graphical user interface is written in Simplified Chinese, which means the UI text may appear corrupted if the program is executed on systems using other language settings.

The UI is filled with "???"

In this situation, one option is to switch the operating system to a Simplified Chinese environment.

However, there is a simpler solution: Locale Emulator. This tool allows applications to be launched using a specified system locale.

Locale Emulator Installer

Installing the Simplified Chinese locale

Launching the controller application using Simplified Chinese locale

The UI can now correctly display Simplified Chiense text


Usage

For readability, the first few secreenshots are taken from Gh0st Beta 3.6, since that version provides an English interface.

Gh0st beta 2.5-3.6 provides the following graphical user interface:

Gh0st RAT Beta 2.5-3.6

Again, as I mentioned in my previous article, some authors used the term “server” for a payload that acts as a client from an internet architecture perspective. This is because “server” can refer to the role that provides services to a user (client). This is similar to how the terms “upload” and “download” are used.

To avoid confusion, this article uses the following terms:

  • Controller: attacker-side application
  • Payload: executable deployed on the victim machines

Configure and build the payload:

Listening configuration

Payload configuration

After deploying the payload on a remote machine, the compromised host will appear in the controller interface once a connection is established.

Online machine(s)


File Manager:

The upper panel displays the controller's local file system, while the lower panel shows the file system of the compromised machine.

This design allows files to be uploaded or downloaded using a drag-and-drop interface, similar to VMware.


Monitor:

Monitor


Terminal:


Protocol Analysis

All C2 command requests have prefix Gh0st:

In addition, Gh0st Beta 2.5~3.6 use multiple ports for different features:

The communication channel is protected.

Reverse Engineering

Both ExeInfo and DIE (Detect It Easy) confirmed that neither the payload nor the controller is packed, and both were compiled using Visual C++.

Payload

Controller application

After opening the payload in Ghidra, I noticed that no networking libraries were imported. This is unusual for a remote access tool.

Based on this observation, I initially suspected that Gh0st dynamically loads networking libraries at runtime.

However, I later noticed an interesting behavior. After the payload is executed, the executable file can be deleted while the process is still running. Therefore, I decided to analyze the sample using Immunity Debugger (although OllyDbg could also be used on Windows XP system).

Further investigation revealed that the payload drops a DLL file into the %TEMP% directory.

CreateFileA()

LoadLibraryA()

DeleteFileA()

dll.tmp

ExeInfo comfirmed this is a DLL file.

I opened this DLL file in Ghidra and observed several imported libraries, including ws2_32.dll.

WS2_32.DLL

I also found the keyword Gh0st within the DLL.

Keyword Gh0st

However, further analysis revealed that this DLL is NOT the main payload responsible for C2 communication.

Returning to the main executable (payload.exe) in Ghidra, we can observe several persistence-related operations.

Modifying registry

CreateService

OpenSCManagerA(), CreateServiceA()

Based on this analysis, the Gh0st deployment mechanism can be summarized as follows:

  1. The executable drops a DLL file (stage-2 payload) into C:\Windows\System32\ and sets its file attributes to hidden.
  2. It modifies the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\<Service_of_Gh0st>\Parameters and adds a ServiceDll entry pointing to the dropped DLL.
  3. The DLL payload is executed through svchost.exe -k netsvcs.
  4. Finally, payload.exe will be deleted.

Hidden DLL file (this is the payload DLL of Gh0st responsible for C2 communication)

Modifying the registry

VirusTotal

Next, analyze the payload DLL:

Message handler of registry

Outter message handler

These analysis confirmed that this is the DLL file responsible for C2 communication.

This raises another question: what is the purpose of dll.tmp (the initial DLL file)?

After further investigation, it appears that this component allows the compromised host to connect a specified proxy server.

Outter message handler


Additionally, the Gh0st payload uses a DLL injection technique.

WriteProcessMemory()

At first glance, this may appear to be a simple evasion technique. However, further analysis shows that this mechanism actually implements a self-destruction routine!

The payload allocates memory in the winlogon.exe process using VirtualAllocEx().

It then writes the base addresses of several APIs into the remote process:

The content of LAB_10005ca0 is shown as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
10005caa 6a 02           PUSH       0x2

10005cac 6a 00 PUSH 0x0

10005cae 6a 00 PUSH 0x0

10005cb0 ff 16 CALL dword ptr [ESI]

10005cb4 8d 46 2c LEA EAX,[ESI + 0x2c]

10005cb7 68 ff 01 PUSH 0xf01ff

0f 00

10005cbe ff 56 04 CALL dword ptr [ESI + 0x4]

10005cc1 85 db TEST EBX,EBX

10005cc7 85 ff TEST EDI,EDI

10005cc9 75 0c JNZ LAB_10005cd7

10005ccd 83 c8 ff OR EAX,0xffffffff

10005cd4 c2 04 00 RET 0x4

LAB_10005cd7 XREF[2]: 10005cc5(j), 10005cc9(j)

10005cd7 8d 4c 24 0c LEA ECX,[ESP + 0xc]

10005cdd ff 56 08 CALL dword ptr [ESI + 0x8]

10005ce0 85 c0 TEST EAX,EAX

10005ce2 75 0c JNZ LAB_10005cf0

10005ce6 83 c8 ff OR EAX,0xffffffff

10005ced c2 04 00 RET 0x4

LAB_10005cf0 XREF[1]: 10005ce2(j)

10005cf0 83 7c 24 CMP dword ptr [ESP + 0x10],0x1

10 01

10005cf5 74 23 JZ LAB_10005d1a

10005cf7 8d 54 24 0c LEA EDX,[ESP + 0xc]

10005cff ff 56 0c CALL dword ptr [ESI + 0xc]

10005d02 85 c0 TEST EAX,EAX

10005d04 75 0c JNZ LAB_10005d12

10005d08 83 c8 ff OR EAX,0xffffffff

10005d0f c2 04 00 RET 0x4

10005d17 ff 56 24 CALL dword ptr [ESI + 0x24]

10005d1b ff 56 14 CALL dword ptr [ESI + 0x14]

10005d1e 8d 86 90 LEA EAX,[ESI + 0x90]

00 00 00

10005d2a ff 56 1c CALL dword ptr [ESI + 0x1c]

10005d2d 85 ff TEST EDI,EDI

10005d2f 74 04 JZ LAB_10005d35

10005d32 ff 56 18 CALL dword ptr [ESI + 0x18]

LAB_10005d35 XREF[1]: 10005d2f(j)

10005d35 85 db TEST EBX,EBX

10005d37 74 04 JZ LAB_10005d3d

10005d3a ff 56 18 CALL dword ptr [ESI + 0x18]

10005d3f 33 c0 XOR EAX,EAX

10005d45 c2 04 00 RET 0x4

The code block LAB_10005ca0 performs the following operations:

  1. PUSH 0x2/CALL [ESI]: call OpenSCManagerA(). ESI indicates lpBaseAddress.
  2. CALL [ESI + 0x4]: call OpenServiceA(). param_2 is the name of payload service name.
  3. CALL [ESI + 0xc]: call ControlService, stop the service if it is still running.
  4. call [esi + 0X14]: call DeleteService(), remove the service data from the Windows service database.
  5. CALL [ESI + 0x1c]: call SHDeleteKeyA, delete the associated registry keys.

Why so sophisticated? The reason for this approach is that a running PE file cannot directly delete itself. By executing the cleanup routine inside winlogon.exe, the malware can remove its own service and registry artifacts, effectively implementing a self-destruction mechanism.

Conclusion

This article introduced the first variant in the Gh0st family and conducted reverse engineering. Gh0st RAT Beta 3.6 represents one of the earliest open-source implementations in the Gh0st ecosystem and serves as the foundation for many later variants.

One important lesson from this analysis is how Gh0st implemented a self-destruction mechanism at such an early stage. Although this technique may not function correctly on modern operating systems such as Windows 10 or Windows 11, it demonstrates how early threat actors attemped to remove forensic traces of their tools.

Again, since the Gh0st family contains numerous variants, it is difficult to analyze all of them within a single article. Future posts in this series will examine additional Gh0st variants and provide supplementary analysis.

If you have any comments or suggestions, please feel free to leave them below!

References

1. http://researchcenter.paloaltonetworks.com/2015/09/musical-chairs-multi-year-campaign-involving-new-variant-of-gh0st-malware/
2. https://github.com/0xCuSO4/DHLYK

THANKS FOR READING