From infostealer to full RAT: dissecting the PureRAT attack chain

By James Northey and Anna Pham (Contributor) of Huntress Labs

An investigation into what initially seemed to be a routine Python-based infostealer campaign took an unexpected twist with the revelation that it culminated in the deployment of PureRAT, a sophisticated and commercially available remote access trojan (RAT). This analysis delves into the threat actor’s strategic blend of custom-developed tools and readily accessible malware.

The campaign illustrates a methodical escalation, beginning with a standard phishing lure and advancing through multiple layers of in-memory loaders, evasion tactics, and credential theft. The final payload, PureRAT, epitomizes this effort: a modular, professionally crafted backdoor that grants the attacker comprehensive control over an infiltrated host.

We will dissect the entire attack sequence, from the initial sideloaded DLL to the encrypted command-and-control (C2) channel, equipping you with the context and indicators necessary for fortifying your networks.

Note: Since the commencement of this analysis, SentinelLABS and Beazley Security have released a commendable report detailing Stages 1 and 2. While their findings provide valuable context, the material pertaining to Stage 3 (PureRAT) remains exclusive to this write-up, so stay tuned for that.

In-depth threat analysis

This intrusion serves as a prime example of layered obfuscation and tactical evolution. The threat actor meticulously chained together ten distinct payloads/stages, progressively increasing in complexity to obscure their ultimate objective.

Stage 1: The initial lure and Python Loaders.

The attack commences with a conventional phishing email containing a ZIP archive masquerading as a copyright infringement notice. Inside this archive lies a legitimate, signed PDF reader executable alongside a malicious version.dll.

This represents a classic DLL sideloading technique, compelling a trusted executable to unwittingly load the malicious DLL from the same directory.

The malicious DLL employs a series of Windows binaries and files within a concealed folder named “_” to execute the subsequent payload. It utilizes certutil.exe to decode a Base64-encoded blob hidden within a file titled Document.pdf, resulting in a ZIP archive. A bundled, renamed copy of WinRAR (images.png) is then employed to extract the contents.

From this secondary archive, files are extracted to C:Userspublicwindows, including a renamed Python interpreter (svchost.exe) and an obfuscated Python script (images.png), which are subsequently executed.

This phase of the attack is captured by Sysmon event:

Type: Process Create
Image: C:WindowsSysWOW64cmd.exe
ParentImage: C:UsersMalwareDesktopsampleDetailedreportdocumentonactionsinvolvingcopyrighted_material.exe
CommandLine: cmd /c cd  && start Document.pdf && certutil -decode Document.pdf Invoice.pdf && images.png x -ibck -y Invoice.pdf C:UsersPublic && start C:UsersPublicWindowssvchost.exe C:UsersPublicWindowsLibimages.png ADNUZJomrp3vPMujoH4bot

Payload 2

The Python script images.png (distinct from images.png, the WinRAR binary) acts as a loader containing a substantial, Base85-encoded string. The payload executes entirely in memory using exec() after being decoded and decompressed, triggering payload 3.

Payload 3

Analyzing payload 3 with dis, a built-in module for converting bytecode to human-readable format, reveals it to be another loader, this time employing a custom cryptographic method. It utilizes a hybrid encryption scheme involving RSA, AES, RC4, and XOR to decrypt the next payload.

Payload 4

Reconstructing this functionality in our own Python script allows us to run this payload through dis again.

For an in-memory attack of this nature, the threat actor must ensure their malware can withstand a system reboot. The payload 4 script employs Python’s built-in winreg library to modify system registry keys, adding a run key designed to mimic a legitimate Windows component: Windows Update Service.

The data stored in this value is a command that re-executes the initial stage of the malware, ensuring the entire infection chain is re-initiated each time the compromised user logs in.

cmd /c start C:UsersPublicWindowssvchost.exe C:UsersPublicWindowsLibimages.png 

Payload 4 continues the loader pattern, utilizing Telegram bot descriptions and URL shorteners (is[.]gd) to dynamically fetch and execute the next payload, providing the threat actor with a flexible mechanism for updating their attack chain.

It is noteworthy that sys.argv[1] in this case refers to the argument ADN_UZJomrp3vPMujoH4bot from when stage 1 extracted payload 2 and executed the first Python script.

As hacker tradecraft evolves daily, we break it down on Tradecraft Tuesday!

Join Huntress Labs monthly for an in-depth exploration of attacker tradecraft—free from sales or product discussions. Sign up for the series today or catch up on previous episodes. No tricks, just tradecraft.

Stage 2: The first weaponized payload—A Python Info-Stealer

Retrieving the next stage from is[.]gd, we encounter the first weaponized payload: a Python-based information stealer. Analyzing the decrypted bytecode reveals its capability to harvest a wide array of sensitive data, including credentials, cookies, credit card information, and autofill data from Chrome and Firefox browsers.

All stolen data is archived into a ZIP file and exfiltrated via the Telegram Bot API. The metadata of the ZIP file provides a clue regarding the potential perpetrator, featuring a contact field linked to the Telegram handle @LoneNone.

The Telegram API is subsequently employed to dispatch the resulting ZIP file and message to various Telegram chats, following a specific logic:

Telegram Chat	Used for	When Used	Data Sent
CHATIDNEW (-1002460490833)	Main data	If Count == 1	Zip archive, message
CHATIDRESET (-1002469917533)	Fallback or reinfection?	If Count != 1	Zip archive, message
CHATIDNEW_NOTIFY (-4530785480)	Notification channel	If Count == 1	Message-only notification

Table 1: Telegram Message Logic

Stage 3: The Pivot to .NET

Just as the campaign’s objectives seem clear, the threat actor makes a pivotal shift. Stage 3 signifies a notable transition from interpreted Python scripts to compiled .NET executables.

This new stage is retrieved from 0x0[.]st, a “no-nonsense file hosting and URL shortening service.” This stage is significantly larger than the previous Python script (40KB -> ~3 MB), as it encompasses two additional embedded payloads.

The first binary is a .NET assembly that is decrypted using base64 and an RC4 hardcoded key. The threat actor then employs process hollowing by launching a legitimate .NET utility, RegAsm.exe, in a suspended state.

This process unmaps the original executable code from the process’s memory, allocates a new memory region, and writes the malicious .NET payload into it (payload 7). The main thread’s context is then updated to point to the new entry point, and the thread is resumed, executing the malicious code under the guise of a legitimate Microsoft binary.

The second is a shellcode loader, which will not be discussed here due to the complexity of the analysis.

Payload 7

This marks our first PE payload, and it appears debugging strings were left by the author, confirming that it employs two key defense evasion techniques:

1. AMSI Patching: It modifies the AmsiScanBuffer function in amsi.dll to prevent the Antimalware Scan Interface from inspecting dynamically loaded code.
2. ETW Unhooking: It alters EtwEventWrite in ntdll.dll to blind Event Tracing for Windows, a common telemetry source for EDR products.

This assembly contains yet another embedded payload (payload 8), which it decodes using a straightforward Base64 and XOR combination.

Once decrypted, the payload is passed to the built-in .NET method Assembly.Load, which loads the executable directly into memory, continuing through getEntryPoint to retrieve the entry point of the loaded assembly, and finally invoking the method via reflection.

Extracting this payload using CyberChef (Base64 → XOR with key),

Payload 8

This payload employs AES-256 and GZip decompression to unpack the ninth and final stage: a DLL named Mhgljosy.dll. Instead of relying on traditional exports, the loader utilizes .NET reflection (Assembly.Load(), GetType(), GetMethod()) to load the DLL entirely in memory and invoke a specific, obfuscated method to initiate its execution.

With a breakpoint on GetMethod() and some debugging, we discover that this method is Mhgljosy.Formatting.TransferableFormatter.SelectFormatter().

Payload 9: The Final Part—PureRAT

After traversing eight payloads/stages of loaders, stealers, and obfuscation, we finally arrive at the last payload, Mhgljosy.dll. However, the DLL is protected with .NET Reactor, a commercial obfuscator designed to hinder reverse engineering.

Static analysis proves unfruitful, prompting us to turn to deobfuscation. Utilizing an open-source tool called NETReactorSlayer (thanks to Anna Pham for the suggestion), we successfully stripped away enough control flow redirection and string encryption to yield a more comprehensible assembly.

With a clearer binary, we can analyze the entry point identified in the previous payload:

Following the deobfuscated control flow, we first encounter ReceiveAttachedSubscriber. Just above this method, we observe a Base64 blob.

The decoding logic is as follows:

1. Base64 Decode: The initial string is decoded.
2. GZip Decompress: The base64 decoded output reveals a GZip header.
3. Protobuf Deserialize: The decompressed data is deserialized using a Protocol Buffers (protobuf) schema.

This process unveils the malware’s configuration.

The final deserialized configuration contains the C2 infrastructure: an IP address (157.66.26[.]209), a list of ports (56001, 56002, 56003), and another base64 blob that decodes to an X.509 certificate. This certificate is utilized for TLS pinning, ensuring that C2 communications remain encrypted and resilient against man-in-the-middle inspection.

Notably, this C2 server is located in Vietnam, further substantiating the connection to the PXA group, suggesting that the individuals behind this operation are likely Vietnamese.

Upon establishing a connection to the C2, the RAT sends an initial “hello” packet back to the operator. This packet comprises logic that is somewhat obscured due to the obfuscation of method names.

Once manually deobfuscated, we find that this consists of an exhaustive fingerprinting of the host machine, gathering a wealth of information before relaying it back to the C2 server.

The following breakdown outlines all the functions utilized in this fingerprinting routine:

Unique Host ID: As illustrated in Figure 23, this is generated by an MD5 hash based on the processor ID, disk drive serial number, physical memory serial number, and the user’s domain name, creating a stable, unique identifier for the victim machine.

Cryptocurrency Wallets: This function searches for numerous browser-based and desktop cryptocurrency wallets by checking for Chrome extension IDs, file system paths (%APPDATA%), and registry keys.

Note: This function does not collect any data; it merely returns a string of what is present on the system.

Once the initial host fingerprinting is complete and the handshake with the C2 is established, the RAT transitions into its primary function: a persistent tasking loop designed to receive and execute commands.

The task loop is relatively straightforward once unpacked:

1. (Red) Read the first 4 bytes to determine the payload length.
2. (Blue) Read that many bytes into a buffer — this is the actual payload.
3. (Green) Deserialize the buffer using the protobuf routine we observed earlier.
4. (Green) Spawn a new thread and invoke DecideFlexibleController() on the message to execute the task.

This architecture effectively transforms this RAT into a dynamic loader. The implant remains dormant, awaiting the operator to push down modules on demand, dynamically extending its capabilities far beyond the initial reconnaissance. These plugins could enable functionalities ranging from microphone/webcam access to real-time keylogging and hidden desktop access.

Fortunately for the victim, the Huntress SOC was able to isolate and remediate the infected host before the threat actor could deploy any of these additional weaponized plugins, thwarting the attack before it could reach its final objectives. Unfortunately, this means we lack further modules for investigation.

One final clue reveals Pure RAT

The .NET namespaces provide another clue with references to PureHVNC, strongly indicating that this sample is linked to Pure Hidden VNC, a piece of commodity malware previously marketed by an individual using the alias PureCoder.

While PureHVNC has largely become obsolete, many of its modules persist in PureCoder’s newer malware families, each crafted for specific purposes:

• PureCrypter: A crypter designed to inject malware into legitimate processes, evade detection, and complicate analysis with anti-VM and anti-debug checks.
• BlueLoader: A loader that deploys additional payloads on infected systems, providing attackers with a streamlined method for staging and updating malware campaigns.
• PureMiner: A silent cryptojacker that commandeers the victim’s CPU and GPU resources to mine cryptocurrency for the attacker without consent.
• PureLogs Stealer: An information stealer that exfiltrates browser data, saved credentials, and session tokens, often delivering them directly to the attacker’s Telegram.
• PureRAT: A modular backdoor that establishes an encrypted C2 channel and allows operators to load additional modules.
• PureClipper: Monitors the system clipboard for cryptocurrency addresses and replaces them with attacker-controlled addresses during copy-paste operations, redirecting crypto transactions to steal funds.

This architecture and feature set align seamlessly with PureRAT, which the developer openly advertised as a custom-coded .NET remote “administration tool,” featuring a lightweight, TLS/SSL-encrypted client and multilingual GUI, offering extensive surveillance and control capabilities such as hidden desktop access (HVNC/HRDP), webcam and microphone spying, real-time and offline keylogging, remote CMD, and application monitoring (e.g., browsers, Outlook, Telegram, Steam).

It also includes management tools for file, process, registry, network, and startup management, along with capabilities for DDoS attacks, reverse proxying, .NET code injection, and execution of files in memory or on disk.

Notably, it explicitly “excludes password/cookie recovery” (Stealer Functionality) as that is sold separately.

Maintain Situational Awareness—Register for Tradecraft Tuesday

Tradecraft Tuesday offers cybersecurity professionals an in-depth analysis of the latest threat actors, attack vectors, and mitigation strategies.

Each weekly session features technical walkthroughs of recent incidents, comprehensive breakdowns of malware trends, and up-to-date indicators of compromise (IOCs).

Participants gain:

• Detailed briefings on emerging threat campaigns and ransomware variants
• Evidence-driven defense methodologies and remediation techniques
• Direct interaction with Huntress analysts for incident response insights
• Access to actionable threat intelligence and detection guidance

Advance your defensive posture with real-time intelligence and technical education specifically designed for those responsible for safeguarding their organization’s environment.

Register for Tradecraft Tuesday →

MITRE ATT&CK Mapping

Tactic	Technique	Technique Name	Description of Observed Behavior
Initial Access	T1566.001	Spearphishing Attachment	The campaign begins with a phishing email containing a malicious ZIP archive.
Execution	T1204.002	User Execution: Malicious File	The user is tricked into executing an .exe file disguised as a document.
Execution	T1059.006	Python	Stages 1 and 2 are executed via a renamed Python interpreter.
Persistence	T1547.001	Registry Run Keys / Startup Folder	Payload 4 establishes persistence by creating a “Windows Update Service” Run key.
Defense Evasion	T1574.001	DLL Side-Loading	A legitimate PDF reader executable is used to load a malicious version.dll.
Defense Evasion	T1027	Obfuscated Files or Information	Multiple stages use Base85, Base64, RC4, AES, and XOR to hide payloads.
Defense Evasion	T1055.012	Process Hollowing	The payload 7 .NET loader is injected into a suspended RegAsm.exe process.
Defense Evasion	T1562.001	Impair Defenses: Disable or Modify Tools	The payload 7 loader patches AMSI to bypass runtime scanning.
Defense Evasion	T1562.006	Impair Defenses: Indicator Blocking	The payload 7 loader unhooks ETW to block EDR telemetry.
Discovery	T1082	System Information Discovery	PureRAT fingerprints the OS version, architecture, and user privileges.
Discovery	T1518.001	Security Software Discovery	The malware uses WMI to enumerate installed antivirus products.
Collection	T1560.001	Archive Collected Data: Archive via Utility	Stolen data is compressed into a ZIP archive before exfiltration.
Command and Control	T1071.001	Web Protocols	The stage 2 stealer exfiltrates data via HTTP POST requests to the Telegram API.
Command and Control	T1573.002	Encrypted Channel: Asymmetric Cryptography	PureRAT uses TLS with a pinned X.509 certificate for C2 communications.

Indicators of Compromise

Disk and Memory Artifacts

Value	Description
Mhgljosy.dll SHA256: e0e724c40dd350c67f9840d29fdb54282f1b24471c5d6abb1dca3584d8bacaa	Payload 9 (PureRAT)
maegkffm.exe SHA256: 06fc70aa08756a752546198ceb9770068a2776c5b898e5ff24af9ed4a823fd9d	Payload 8 (PureRAT Loader)
wwctn_crypted.exe SHA256: f5e9e24886ec4c60f45690a0e34bae71d8a38d1c35eb04d02148cdb650dd2601	Payload 7 (NetLoader)
File Path: C:UsersPublicWindowssvchost.exe	Renamed Python interpreter used in early stages.
File Path: C:UsersPublicWindowsLibimages.png SHA256: f6ed084aaa8ecf1b1e20dfa859e8f34c4c18b7ad7ac14dc189bc1fc4be1bd709	Obfuscated Python script (payload 2).
Registry Key: HKCUSOFTWAREMicrosoftWindowsCurrentVersionRunWindows Update Service	Persistence registry key created in payload 4.

Network/Infrastructure

Type	Value	Description
IP Address	157.66.26[.]209	PureRAT C2 Server
Port	56001	PureRAT C2 Port (Default)
Port	56002	PureRAT C2 Port
Port	56003	PureRAT C2 Port
URL	https://0x0[.]st/8WBr.py	Stage 3 payload hosting URL.
URL	https://is[.]gd/s5xknuj2 https://paste[.]rs/fVmzS	Stage 2 payload hosting URL.
Telegram Handle	@LoneNone	Threat actor handle associated with stage 2 (PXA Stealer).

Acknowledgments

I would like to thank Anna Pham for her assistance in dumping and deobfuscating the final stage.

Sponsored and written by Huntress Labs.