THREAT ANALYSIS REPORT: PlugX RAT Loader Evolution
By Cybereason Global SOC Team
Archived: 2026-04-05 17:11:00 UTC
The Cybereason Global Security Operations Center (GSOC) Team issues Threat Analysis Reports to inform on impacting
threats. The Threat Analysis Reports investigate these threats and provide practical recommendations for protecting against
them.
In this Threat Analysis report, the Cybereason GSOC investigates the PlugX malware family, a modular Remote Access
Tool/Trojan (RAT) often utilized by Asia-based APT groups such as APT27. The malware has backdoor capabilities to take
full control of the environment with its many malicious “plugins.”
This report provides an overview of the PlugX loader as well as modifications across multiple samples (six in total) starting
from the year 2012 to 2022. 
Key Points
The Rule of Three: The malware may be delivered differently depending on the campaigns such as whether the
initial delivering format is self de-archiving or not. However, the PlugX loader always consists of three main
components: a legitimate executable, a malicious module, and a malicious payload. The malware has been around for
over a decade, but the format of the malware has not changed.
Security Evasion-Focused Techniques: PlugX loader is known for utilizing DLL-Sideloading techniques for
evasion purposes. However, the malware is packing additional evasion techniques. This increases the chance of
deploying the main PlugX payload successfully.
Detected and Prevented: The Cybereason Defense Platform effectively detects and prevents the PlugX malware. 
Introduction
PlugX is a post-exploitation modular RAT (Remote Access Trojan), which, among other things, is known for its multiple
functionalities such as data exfiltration, keystroke grabbing, and backdoor functionality. The malware’s first publications and
research papers date back to 2012. 
However, according to Trend Micro, the malware has actually been around since 2008. PlugX was already making a name
for itself back in 2012 due to high activity within Asia. 
This may have been due to the fact that the PlugX malware authors were tied to China and the operators of this malware at
the time were located within Asian countries. Since then, the malware has been active and utilized by many threat actors for
over the past decade. The malware had many updates over the years and it does not appear to be going away anytime soon.
From its original version, the PlugX malware has been primarily used against public-sector organizations such as
governments and various political organizations. In addition, advanced threat actors utilize the malware heavily to target
high profile private organizations. 
For example, in June 2016, Japan’s leading tourism agency announced the leak of privacy data of 7.93 million users, which
was later identified by Trellix as an attack utilizing PlugX. The malware was also seen utilized outside of Asian countries
when it targeted military and aerospace interests in Belarus and Russia. 
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 1 of 18

This may be the indicator that the malware operators for PlugX were expanding their markets and targets. Most recently, the
malware was utilized to target European government agencies which aided Ukrainian refugees from the recent Russia-Ukraine War. 
PlugX loader is commonly delivered via phishing emails and it is also seen delivered by exploiting a vulnerability such as
ProxyLogon according to Unit 42 from Palo Alto Networks. The malware is often delivered as an archived formatted file
such as .zip, .rar or self-extracting RAR (SFX) archive. 
Within this archived file format, the malware contains three main files: 
legitimate executable
malicious module
malicious payload
The malware utilizes DLL Side-Loading as a main method to load a malicious DLL from a legitimate executable, like
Acrobat Reader or a legacy Microsoft binary, for instance. The benefits of using DLL Side-Loading is that the malware can
hijack and masquerade the legitimate executable by loading malicious modules. DLL Side-loading not only allows for
evasion of security tools, but also allows malware developers to have a variety of options into which legitimate executable to
side-load the PlugX payload:
PlugX infection flow. View Loading PlugX Process FlowChart
DLL Side-Loading is one of many evasive aspects that this malware has in its arsenal, and which this analysis describes in
depth:
Technical Analysis
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 2 of 18

The technical analysis focuses on the PlugX loader’s deployment method and specifically PlugX Loader Analysis focuses on
three files with the following sample Secure Hash Algorithm (SHA)-256. These files were introduced in this article from
2012:
Filename SHA-256
Nv.exe (legitimate) 523D28DF917F9D265CD2C0D38DF26277BC56A535145100ED82E6F5FDEAAE7256
NvSmartMax.dll EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3
Nv.mp3 3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB
The malware utilizes DLL Side-Loading technique by leveraging the legitimate executable (Nv.exe) to load a malicious
module (NvSmartMax.dll), which loads an additional malicious payload (Nv.mp3) to prepare for an actual PlugX payload. 
The Comparative Analysis compares different PlugX loader samples to provide the modifications of deployment methods.
PlugX Loader Analysis
This section describes the deployment of the PlugX loader in the specific case of the use of Nv.exe as the DLL side-loader.
The chapter ends with the PlugX payload loaded in memory:
PlugX Loader Summary
OS Datetime Check
When the legitimate executable Nv.exe first executes and side-loads the PlugX loader module NvSmartMax.dll, the module
first checks the OS date and time with the GetSystemTime method, which then calculates the output with the following
formula.
Result = ( (OS_Year * 100) + OS_Month ) * 100 + OS_Date
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 3 of 18

The result of the equation is expected to be a hex value, which is then compared with the value 0x1330225, which is
equivalent to the date 2012-01-01. The execution of this method enables the NvSmartMax.dll to check if the OS date and
time is later than 2012-01-01. 
If the date and time is later than 2012-01-01, the DLL execution exits. This checking mechanism is assumed to be for
malware’s release purpose and prohibits its usage before its official release:
OS datetime check
Control Flow Manipulation
After the OS date and time is confirmed to be later than 2012-01-01, the NvSmartMax.dll fetches the address of Nv.exe’s
EntryPoint and proceeds to update the page protection of the EntryPoint by calling the VirtualProtect function.
NvSmartMax.dll updates the Nv.exe’s EntryPoint’s page protection to PAGE_EXECUTE_READWRITE to prepare a
modification on the EntryPoint:
PAGE_EXECUTE_READWRITE
The NvSmartMax.dll module proceeds to patch the EntryPoint to jump into a function at offset 0x1020 in NvSmartMax.dll.
The malware appears to be utilizing control flow manipulation as an obfuscation method against static analysis:
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 4 of 18

Nv.exe’s entry point patched
Once the control flow enters the EntryPoint of the Nv.exe, execution jumps to the patched address in NvSmartMax.dll. In the
target function, the malware prepares to load the Nv.mp3 by attempting the following steps:
Check the OS date and time again - however, during this check, the verification checks for the year 2012
Prepare the malware file
Allocate memory
Read Nv.mp3 into allocated memory
Update page protection to PAGE_EXECUTE_READ
Execute code located at Nv.mp3
Prepare payload file name
Allocate and enter the payload
InInitialization Order Module List
Once the control flow accesses the Nv.mp3 memory region, it dynamically fetches the loaded module kernel32.dll’s base
address from the InInitializationOrderModuleList within the Process Environment Block (PEB).
PEB is a data structure, which contains process information which is utilized internally by the operating system (OS). PEB
is often utilized for anti-analysis techniques such as NtGlobalFlag check, but it can also be used to fetch necessary module
information. 
At offset 0x0C within PEB, PEB_LDR_DATA structure is located which stores loaded module information. This structure
has three members: InLoadOrderModuleList, InMemoryOrderModuleList, and InInitializationOrderModuleList:
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 5 of 18

Fetching loaded modules from PEB_LDR_DATA
The code located in Nv.mp3 fetches InInitializationOrderModuleList, which includes all the loaded modules in order of
initialization. This list does not include the executable itself, and it only lists the modules:
InitializationOrderModuleList diagram
The Nv.mp3 searches through each element’s BaseDllName, until it finds kernel32.dll and retrieves the BaseAddress of the
module. 
Once the base address of kernel32.dll is retrieved, Nv.mp3 fetches the function GetProcAddress address in order to load the
functions LoadLibraryA, VirtualAlloc, VirtualFree, and ExitThread, which appears to be loaded via StackString method:
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 6 of 18

StackString libraries
Once all the function addresses are loaded from kernel32.dll, Nv.mp3 loads the module ntdll.dll by using the LoadLibraryA
function which was retrieved earlier by the GetProcAddress function. From ntdll.dll, Nv.mp3 loads functions
RtlDecompressBuffer and memcpy.
Plugx Payload Decompression
The code located at Nv.mp3 level proceeds to decrypt the RC4-encrypted strings which are stored within the payload at
offset 0x1529 with size 117KB. The decrypted strings are a compressed version of a PE file, which performs the
RtlDecompressBuffer function with LZ decompression format:
NT_RTL_COMPRESS_API NTSTATUS RtlDecompressBuffer(
 [in] USHORT CompressionFormat,
 [out] PUCHAR UncompressedBuffer,
 [in] ULONG UncompressedBufferSize,
 [in] PUCHAR CompressedBuffer,
 [in] ULONG CompressedBufferSize,
 [out] PULONG FinalUncompressedSize
);
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 7 of 18

Figure 11: RtlDecompressBuffer Function Parameters
Decompressed Buffer
The decompressed PE file is an actual PlugX itself. However, the control flow does not immediately enter the decompressed
payload. Nv.mp3 places the “GULP” signature, which is the backward for “PLUG” in newly allocated memory by
VirtualAlloc with PAGE_EXECUTE_READWRITE protection. It proceeds to allocate each section’s .text, .rdata, .data, and
.reloc by using the memcpy function into allocated memory.
Lastly, it loads necessary libraries and functions dynamically by using LoadLibraryA and GetProcAddress from the import
table listed in the decompressed PE file. Once this preparation is done, it proceeds to enter the PlugX payload:
PlugX
payload header
PlugX Loader Flowchart
The following flowchart summarizes the flow of the PlugX loader:
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 8 of 18

Figure 14: PlugX loader flowchart
Comparative Analysis
This comparative analysis analyzes the following six samples listed in the table below. The samples are observed in the past
from various analyses from different reports. As a reference, the samples (executable, module, payload) are identified with
codename with prefix px_ followed by the relevant year that the samples were observed according to the external sources:
Codename Filename SHA-256
px_2012
Nv.exe 523D28DF917F9D265CD2C0D38DF26277BC56A535145100ED82E6F5FDEAAE7256
NvSmartMax.dll EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3
Nv.mp3 3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB
px_2014 Gadget.exe 5C859CA16583D660449FB044677C128A9CDEDD603D9598D4670235C52E359BF9
Sidebar.dll 4B23F8683E184757E8119C8C68063F547F194E1ABD758DCBD4DACF70E3908FC1
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 9 of 18

Sidebar.dll.doc B2B93C7C4AC82623F74B14FE73F2C3F8E58E3306CC903C5AE71BC355CB5BD069
px_2015
fsguidll.exe 5C5E3201D6343E0536B86CB4AB0831C482A304C62CD09C01AC8BDEEE5755F635
fslapi.dll 96876D24284FF4E4155A78C043C8802421136AFBC202033BF5E80D1053E3833F
fslapi.dll.gui ACDC4987B74FDF7A32DFF87D56C43DF08CCE071B493858E3CE32FCF8D6372837
px_2019
mcinsupd.exe 507D49186748DD83D808281743A17FCA4B226883C410EC76EB305360CBC8C091
mytilus3.dll 9FB33E460CA1654FCC555A6F040288617D9E2EFE626F611B77522606C724B59B
mytilus3.dump 6914E9DE21F5CCE3F5C1457127122C13494ED82E6E2D95A8200A46BDB4CD7075
px_2021
aro.exe 18A98C2D905A1DA1D9D855E86866921E543F4BF8621FAEA05EB14D8E5B23B60C
aross.dll 9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47
aro.dat 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F
px_2022
RasTls.exe F9EBF6AEB3F0FB0C29BD8F3D652476CD1FE8BD9A0C11CB15C43DE33BBCE0BF68
RasTls.dll 6CD5079A69D9A68029E37F2680F44B7BA71C2B1EECF4894C2A8B293D5F768F10
RasTls.dll.res 37B3FB9AA12277F355BBB334C82B41E4155836CF3A1B83E543CE53DA9D429E2F
Each sample is compared based on the configuration and implementation of the PlugX loader:
Malware’s release date control with OS datetime check
Manipulation of control flow by patching the instructions within the executable for anti-analysis
Dynamically retrieving module kernel32.dll’s base address within payload by utilizing the PEB_LDR_DATA
structure
Code obfuscation within the payload for anti-analysis
Decompression preparation of PlugX payload and the format of the payload
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 10 of 18

OS Datetime
As explained in the previous section, PlugX loader does check that the date is later than a specific value. This behavior has
been observed on three samples, from this list of six samples:
Sample Check count Datetime
px_2012 2 2012-01-01, 2012
px_2014 2 2012-01-01, 2012
px_2015 0 N/A
px_2019 1 2018
px_2021 0 N/A
px_2022 0 N/A
The date and time check happens twice in samples px_2012 and px_2014: 
Checks the date before executing the instruction patching function
Checks the year before allocating the PlugX loader payload file
However, in sample px_2019, it only conducts the date and time check for the year 2018. The versioning of this malware
also seems to exist, which is evident from the date and time check of the date of px_2019 being 2018. 
Manipulate Control Flow
Sample Patch Instruction Patched Instruction
px_2012 Yes JMP
px_2014 No N/A
px_2015 Yes JMP
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 11 of 18

px_2019 Yes PUSH/RET
px_2021 No N/A
px_2022 Yes PUSH/RET
Manipulation of the control flow by patching the instructions with JMP is utilized with the samples, however the samples
px_2019 and px_2022 are patched with PUSH and RET instructions. The PUSH instruction “pushes” the relevant function
address onto the stack and the RET instruction moves the control flow into the pushed address. 
Samples px_2014 and px_2021 did not patch instructions to manipulate the control flow. It utilized legitimate exported
function names of the legitimate DLL which gets called by the legitimate executable.
PEB_LDR_DATA
Sample PEB_LDR_DATA
px_2012 InInitializationOrderModuleList 
px_2014 InInitializationOrderModuleList 
px_2015 InInitializationOrderModuleList 
px_2019 InInitializationOrderModuleList 
px_2021 InMemoryOrderModuleList 
px_2022 InInitializationOrderModuleList 
Aside from InitializationOrderModuleList, sample px_2021 utilized InMemoryOrderModuleList.
InMemoryOrderModuleList lists loaded modules according to the memory placement. The difference from
InInitializationOrderModuleList is that InMemoryOrderModuleList includes the executable within the list. 
Payload Obfuscation
Sample Usage of StackString Usage of Code Obfuscation
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 12 of 18

px_2012 Yes N/A
px_2014 Yes Yes
px_2015 Yes Yes
px_2019 Yes; Places one characters at a time N/A
px_2021 Yes; Places one characters at a time N/A
px_2022 Yes; Some, one character at a time, some in bulk. N/A
The usage of StackString on the functions which need to be loaded dynamically appears to be consistent throughout the
samples. However, a slight update is placed in px_2019, px_2021 and px_2022, which is placing one character at a time onto
a Stack:
Fetching VirtualProtect
Samples px_2014 and px_2015 also have additional code obfuscation, which is an encryption on the function that prepares
the PlugX payload. This function is the main component of this deployment payload and this is an additional layer of anti-analysis:
Code deobfuscation in px_2015
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 13 of 18

Decompression and Payload Deployment
Sample
Decompression
Format
Decryption of compressed
data
Decompressed Data Format
Payload
Header
px_2012 LZ Yes PE File with PE signatures GULP
px_2014 LZ Yes PE File with PE signatures GULP
px_2015 LZ Yes
PE File without PE
signatures
XV
px_2019 LZ Yes PE File with PE signatures GULP
px_2021 LZ Yes
PE File without PE
signatures 
ROHT
px_2022 LZ Yes PE File with PE signatures .PE
Decompression of PlugX payload is consistent across the samples, which decrypts the LZ compressed data. However, the
decompressed payload for the samples px_2015 and px_2021 was not in complete PE file format. It was missing traditional
PE signatures such as “MZ…This program cannot be run in DOS mode”. The relevant section information was still intact,
which was needed for the PlugX loader to allocate necessary sections to the new memory region. 
This update only removed portions of the PE header. However, it contained necessary information for the code to function.
This update prevents analysts from simply dumping the decompressed payload and conducting further analysis, since it is
not in proper PE format. 
Sample px_2015, px_2021 and px_2022 also had different headers once the decompressed payload was allocated into
PAGE_EXECUTE_READWRITE memory region: 
px_2015: XV - Roman numeral for 15.
px_2021: ROHT - Backward for “THOR”
px_2022: .PE - Portable Executable
The differences in the header may be evidence of the versioning of PlugX as well.
Core Deployment Methods Are Consistent Across Samples
There are several slight detail differences while comparing samples, however there appears to be no major updates in the
past decade regarding the deployment method of this malware. 
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 14 of 18

Although there were no major updates, the malware loader appears to have version management. This is evident from OS
date and time check as well as the differences in payload headers while deploying the actual PlugX.
The lack of a major deployment method is also believed to be due to the use of the DLL Side-Loading technique. The DLL
Side-Loading technique itself gives the threat actors various options on which legitimate executables to side-load the PlugX
with. This evasion technique already creates various combinations and an update on deployment methods deemed
unnecessary
Detection and Prevention
Cybereason Defense Platform
The Cybereason Defense Platform is able to detect and prevent infections with the PlugX loader using multi-layer protection
that detects and blocks malware with threat intelligence, machine learning, anti-ransomware and Next-Gen Antivirus
(NGAV) capabilities:
MalOp generation based from threat intelligence as seen in the Cybereason Defense Platform
Cybereason GSOC MDR
The Cybereason GSOC recommends the following:
Enable both the Signature and Artificial Intelligence modes on the Cybereason NGAV, and enable the Detect and
Prevent modes of this feature.
Handle files originating from external sources (email, web browsing) with caution.
To hunt proactively, use the Investigation screen in the Cybereason Defense Platform and the queries in the Hunting
Queries section to search for machines that are potentially infected with PlugX. Based on the search results, take
further remediation actions, such as isolating the infected machines and deleting the payload file.
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 15 of 18

Cybereason is dedicated to teaming with defenders to end cyber attacks from endpoints to the enterprise to everywhere.
Schedule a demo today to learn how your organization can benefit from an operation-centric approach to security.
MITRE ATT&CK MAPPING
Execution Persistence Defense Evasion Discovery Collection
Command
and Control 
Command and
Scripting
Interpreter
Boot or logon
Autostart
Execution
Deobfuscate/Decode Files
or Information
File and
Directory
Discovery
Input
Capture
Application
Layer Control
Native API
Create or
Modify System
Process
Hide Artifacts
Network Share
Discovery
Screen
Capture
Encrypted
Channel
    Hijack Execution Flow
Process
Discovery
 
Ingress Tool
Transfer
    Masquerading Query Registry  
Non-Application
Layer Protocol
    Modify Registry
System Network
Connections
Discovery
  Web Service
   
Obfuscated Files or
Information
     
   
Trusted Developer
Utilities Proxy Execution
     
   
Virtualization/Sandbox
Evasion
     
Indicators Of Compromise For PlugX Malware
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 16 of 18

Executables
SHA-256 hash:
EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3
SHA-256 hash:
3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB
SHA-256 hash:
4B23F8683E184757E8119C8C68063F547F194E1ABD758DCBD4DACF70E3908FC1
SHA-256 hash:
B2B93C7C4AC82623F74B14FE73F2C3F8E58E3306CC903C5AE71BC355CB5BD069
SHA-256 hash:
96876D24284FF4E4155A78C043C8802421136AFBC202033BF5E80D1053E3833F
SHA-256 hash:
ACDC4987B74FDF7A32DFF87D56C43DF08CCE071B493858E3CE32FCF8D6372837
SHA-256 hash:
9FB33E460CA1654FCC555A6F040288617D9E2EFE626F611B77522606C724B59B
SHA-256 hash:
6914E9DE21F5CCE3F5C1457127122C13494ED82E6E2D95A8200A46BDB4CD7075
SHA-256 hash:
9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47
SHA-256 hash:
59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F
SHA-256 hash:
6CD5079A69D9A68029E37F2680F44B7BA71C2B1EECF4894C2A8B293D5F768F10
SHA-256 hash:
37B3FB9AA12277F355BBB334C82B41E4155836CF3A1B83E543CE53DA9D429E2F
About The Researchers 
Kotaro Ogino, Senior Security Analyst, Cybereason Global SOC
Kotaro Ogino is a Senior Security Analyst with the Cybereason Global SOC team. He is involved in threat hunting,
administration of Security Orchestration, Automation, and Response (SOAR) systems, and Extended Detection and
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 17 of 18

Response (XDR). Kotaro has a bachelor of science degree in information and computer science.
Yuki Shibuya, Senior Security Analyst, Cybereason Global SOC
Yuki Shibuya is a Senior Security Analyst with the Cybereason Global SOC team. He is tasked with triaging critical
incidents, threat hunting and malware research. He has a master degree of information systems security and is interested in
malware research and penetration testing.
Big thanks to Aleksandar Milenkoski for advising the research!
Source: https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution
Page 18 of 18