[Studying] Analyzing Poison Ivy
Last Update:
Word Count:
Read Time:
Introduction
This article is part of my series: Inside Different Generations of RATs. If you are interested in the full series, please refer to the linked article above.
Poison Ivy is a legacy RAT widely used in targeted attacks during the Windows XP era.
This article analyzes version 2.3.2, including its payload generation mechanism, network communication, and staged loader design.
Key findings include:
- The stage-1 payload is a small loader (~7 KB)
- The loader retrieves other components (multi-stage) from the C2 server
- Communication is encrypted using RC4
- Payload modules appear to be dynamically injected assembly fragments
PoisonIvy
PoisonIvy is a remote access trojan that enables key logging, screen capturing, video capturing, file transfer, system administration, password theft, and traffic relaying. It was created around 2005 by a Chinese hacker and has been used in several prominent hacks, including a breach of the RSA SecurID authentication tool and the Nitro attacks on chemical companies, both in 2011. The malware is also known as Backdoor.Darkmoon 1.
Different versions can be found on the internet.
In this article, I conduct reverse engineering to version 2.3.2.
Experimental Environment Setup
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 |
| PEiD | File analysis tool used to detect packers and compiler signatures in PE executables |
| Wireshark | Network protocol analyzer used to capture and inspect live or recorded traffic |
| 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
Usage
Launch Poison Ivy 2.3.2.exe
Poison Ivy adopts a multiple-window style for the graphical user interface, similar to OllyDbg:
However, the early version adopted a single-window interface:
To build a payload executable, we need to configure several options. Poison Ivy allows users to save multiple profiles for building payloads:
In addition, the payload executable can connect to multiple C2 servers:
Here, the term “server” might be confusing from a modern perspective. Compared to the previous articles, this GUI application acts as the server in the network architecture, while the payload is the client. However, in that era, the term server often referred to the service provider—the payload—which provides the remote manipulation features.
Poison Ivy allows users to build the payload as either a PE executable or shellcode:
I will analyze the shellcode while conducting reverse engineering.
Next, configure the TCP listener:
Then, we can deploy the payload on the target machine. Once the target machine is compromised, we can see the online machine in the GUI application:
To access a compromised machine, double-click the available item:
Note that Poison Ivy has some features and design that modern RATs have:
Protocol Analysis
The communication channel is protected using RC4 encryption.
Reverse Engineering
First, multiple tools confirmed that the payload is not packed:
Second, the payload executable is only 7 KB in size. I then realized that it is a staged loader since Poison Ivy provides shellcode payload as mentioned. it downloads additional staged payload components from the C2 server and executes them directly in memory, similar to Meterpreter.
Therefore, I shifted to analyze the shellcode and tried to obtain the stage-2 payload, but before that, let’s analyze the stage-1 payload.
The payload dynamically loads different libraries:
We can also analyze the payload executable with Immunity Debugger, OllyDbg or x32dbg. However, while analyzing, the debuggers crashed frequently, regardless of whether I used “open” or “attach”. Therefore, I tried another method to obtain the stage-2 payload: dump the process from memory to the disk.
To dump the process from memory, we can use procdump.exe:1
> procdump -ma PID dump.dmp
Open dump.dmp using Ghidra:
Initially, I believed that Poison Ivy loaded a specific PE file from the C2 server. I then realized that the mechanism of Poison Ivy is much more complicated. It loads different payloads—most likely, assembly code (or shellcode)—from the C2 server and inserts them as different fragments. This explains why there are many API names in string format (in truth, the source code of Poison Ivy confirms my inference):
The initial 7 KB payload acts as a staged loader. Instead of retrieving a single stage-2 executable, the loader downloads multiple payload fragments from the C2 server and dynamically integrates them into the running process. These fragments appear to contain assembly routines implementing different functionalities, which explains the large number of API names stored as strings in memory.
Conclusion
Poison Ivy was released and spread during the era of Windows XP. As a legacy RAT, it adopted shellcode and loader techniques.
Based on the memory dump, Poison Ivy does not appear to load a single monolithic stage-2 payload. Instead, it likely implements a modular architecture where different functionality modules are downloaded from the C2 server and injected into the running process.
This design allows the operator to dynamically extend the capabilities of the infected host without redeploying the entire payload.
Although the development process might be difficult since a part of the payloads were written in assembly language, this significantly enhances the difficulty of reverse engineering.
It makes me recall one of my side projects Eden-RAT, and its mechanism is similar to that of Poison Ivy.
References
1. https://en.wikipedia.org/wiki/PoisonIvy_(trojan) ↩
THANKS FOR READING
