[Studying] Analyzing Gh0st RAT Beta 2.5-3.6
Last Update:
Word Count:
Read Time:
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:
- How to Setup Your Experimental Environment for Malware Analysis
- Installing VMware Tools on Windows XP and Windows 95 with VMware WorkStation 17
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.
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.
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:
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:
After deploying the payload on a remote machine, the compromised host will appear in the controller interface once a connection is established.
File Manager:
This design allows files to be uploaded or downloaded using a drag-and-drop interface, similar to VMware.
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++.
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.
I opened this DLL file in Ghidra and observed several imported libraries, including ws2_32.dll.
I also found the keyword Gh0st within the DLL.
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.
Based on this analysis, the Gh0st deployment mechanism can be summarized as follows:
- The executable drops a DLL file (stage-2 payload) into
C:\Windows\System32\and sets its file attributes to hidden. - It modifies the registry at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\<Service_of_Gh0st>\Parametersand adds aServiceDllentry pointing to the dropped DLL. - The DLL payload is executed through
svchost.exe -k netsvcs. - Finally,
payload.exewill be deleted.
Next, analyze the payload DLL:
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.
Additionally, the Gh0st payload uses a DLL injection technique.
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 | |
The code block LAB_10005ca0 performs the following operations:
PUSH 0x2/CALL [ESI]: callOpenSCManagerA().ESIindicateslpBaseAddress.CALL [ESI + 0x4]: callOpenServiceA().param_2is the name of payload service name.CALL [ESI + 0xc]: callControlService, stop the service if it is still running.call [esi + 0X14]: callDeleteService(), remove the service data from the Windows service database.CALL [ESI + 0x1c]: callSHDeleteKeyA, 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