{
	"id": "7199eee4-d9ca-4a37-8c93-6de3d7d80731",
	"created_at": "2026-04-06T00:16:06.233828Z",
	"updated_at": "2026-04-10T13:11:39.530871Z",
	"deleted_at": null,
	"sha1_hash": "12ace14e9dfca1adafff6eda46eb2b0d449f6114",
	"title": "THREAT ANALYSIS REPORT: PlugX RAT Loader Evolution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2231047,
	"plain_text": "THREAT ANALYSIS REPORT: PlugX RAT Loader Evolution\r\nBy Cybereason Global SOC Team\r\nArchived: 2026-04-05 17:11:00 UTC\r\nThe Cybereason Global Security Operations Center (GSOC) Team issues Threat Analysis Reports to inform on impacting\r\nthreats. The Threat Analysis Reports investigate these threats and provide practical recommendations for protecting against\r\nthem.\r\nIn this Threat Analysis report, the Cybereason GSOC investigates the PlugX malware family, a modular Remote Access\r\nTool/Trojan (RAT) often utilized by Asia-based APT groups such as APT27. The malware has backdoor capabilities to take\r\nfull control of the environment with its many malicious “plugins.”\r\nThis report provides an overview of the PlugX loader as well as modifications across multiple samples (six in total) starting\r\nfrom the year 2012 to 2022. \r\nKey Points\r\nThe Rule of Three: The malware may be delivered differently depending on the campaigns such as whether the\r\ninitial delivering format is self de-archiving or not. However, the PlugX loader always consists of three main\r\ncomponents: a legitimate executable, a malicious module, and a malicious payload. The malware has been around for\r\nover a decade, but the format of the malware has not changed.\r\nSecurity Evasion-Focused Techniques: PlugX loader is known for utilizing DLL-Sideloading techniques for\r\nevasion purposes. However, the malware is packing additional evasion techniques. This increases the chance of\r\ndeploying the main PlugX payload successfully.\r\nDetected and Prevented: The Cybereason Defense Platform effectively detects and prevents the PlugX malware. \r\nIntroduction\r\nPlugX is a post-exploitation modular RAT (Remote Access Trojan), which, among other things, is known for its multiple\r\nfunctionalities such as data exfiltration, keystroke grabbing, and backdoor functionality. The malware’s first publications and\r\nresearch papers date back to 2012. \r\nHowever, according to Trend Micro, the malware has actually been around since 2008. PlugX was already making a name\r\nfor itself back in 2012 due to high activity within Asia. \r\nThis may have been due to the fact that the PlugX malware authors were tied to China and the operators of this malware at\r\nthe time were located within Asian countries. Since then, the malware has been active and utilized by many threat actors for\r\nover the past decade. The malware had many updates over the years and it does not appear to be going away anytime soon.\r\nFrom its original version, the PlugX malware has been primarily used against public-sector organizations such as\r\ngovernments and various political organizations. In addition, advanced threat actors utilize the malware heavily to target\r\nhigh profile private organizations. \r\nFor example, in June 2016, Japan’s leading tourism agency announced the leak of privacy data of 7.93 million users, which\r\nwas later identified by Trellix as an attack utilizing PlugX. The malware was also seen utilized outside of Asian countries\r\nwhen it targeted military and aerospace interests in Belarus and Russia. \r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 1 of 18\n\nThis may be the indicator that the malware operators for PlugX were expanding their markets and targets. Most recently, the\r\nmalware was utilized to target European government agencies which aided Ukrainian refugees from the recent Russia-Ukraine War. \r\nPlugX loader is commonly delivered via phishing emails and it is also seen delivered by exploiting a vulnerability such as\r\nProxyLogon according to Unit 42 from Palo Alto Networks. The malware is often delivered as an archived formatted file\r\nsuch as .zip, .rar or self-extracting RAR (SFX) archive. \r\nWithin this archived file format, the malware contains three main files: \r\nlegitimate executable\r\nmalicious module\r\nmalicious payload\r\nThe malware utilizes DLL Side-Loading as a main method to load a malicious DLL from a legitimate executable, like\r\nAcrobat Reader or a legacy Microsoft binary, for instance. The benefits of using DLL Side-Loading is that the malware can\r\nhijack and masquerade the legitimate executable by loading malicious modules. DLL Side-loading not only allows for\r\nevasion of security tools, but also allows malware developers to have a variety of options into which legitimate executable to\r\nside-load the PlugX payload:\r\nPlugX infection flow. View Loading PlugX Process FlowChart\r\nDLL Side-Loading is one of many evasive aspects that this malware has in its arsenal, and which this analysis describes in\r\ndepth:\r\nTechnical Analysis\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 2 of 18\n\nThe technical analysis focuses on the PlugX loader’s deployment method and specifically PlugX Loader Analysis focuses on\r\nthree files with the following sample Secure Hash Algorithm (SHA)-256. These files were introduced in this article from\r\n2012:\r\nFilename SHA-256\r\nNv.exe (legitimate) 523D28DF917F9D265CD2C0D38DF26277BC56A535145100ED82E6F5FDEAAE7256\r\nNvSmartMax.dll EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3\r\nNv.mp3 3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB\r\nThe malware utilizes DLL Side-Loading technique by leveraging the legitimate executable (Nv.exe) to load a malicious\r\nmodule (NvSmartMax.dll), which loads an additional malicious payload (Nv.mp3) to prepare for an actual PlugX payload. \r\nThe Comparative Analysis compares different PlugX loader samples to provide the modifications of deployment methods.\r\nPlugX Loader Analysis\r\nThis section describes the deployment of the PlugX loader in the specific case of the use of Nv.exe as the DLL side-loader.\r\nThe chapter ends with the PlugX payload loaded in memory:\r\nPlugX Loader Summary\r\nOS Datetime Check\r\nWhen the legitimate executable Nv.exe first executes and side-loads the PlugX loader module NvSmartMax.dll, the module\r\nfirst checks the OS date and time with the GetSystemTime method, which then calculates the output with the following\r\nformula.\r\nResult = ( (OS_Year * 100) + OS_Month ) * 100 + OS_Date\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 3 of 18\n\nThe result of the equation is expected to be a hex value, which is then compared with the value 0x1330225, which is\r\nequivalent to the date 2012-01-01. The execution of this method enables the NvSmartMax.dll to check if the OS date and\r\ntime is later than 2012-01-01. \r\nIf the date and time is later than 2012-01-01, the DLL execution exits. This checking mechanism is assumed to be for\r\nmalware’s release purpose and prohibits its usage before its official release:\r\nOS datetime check\r\nControl Flow Manipulation\r\nAfter the OS date and time is confirmed to be later than 2012-01-01, the NvSmartMax.dll fetches the address of Nv.exe’s\r\nEntryPoint and proceeds to update the page protection of the EntryPoint by calling the VirtualProtect function.\r\nNvSmartMax.dll updates the Nv.exe’s EntryPoint’s page protection to PAGE_EXECUTE_READWRITE to prepare a\r\nmodification on the EntryPoint:\r\nPAGE_EXECUTE_READWRITE\r\nThe NvSmartMax.dll module proceeds to patch the EntryPoint to jump into a function at offset 0x1020 in NvSmartMax.dll.\r\nThe malware appears to be utilizing control flow manipulation as an obfuscation method against static analysis:\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 4 of 18\n\nNv.exe’s entry point patched\r\nOnce the control flow enters the EntryPoint of the Nv.exe, execution jumps to the patched address in NvSmartMax.dll. In the\r\ntarget function, the malware prepares to load the Nv.mp3 by attempting the following steps:\r\nCheck the OS date and time again - however, during this check, the verification checks for the year 2012\r\nPrepare the malware file\r\nAllocate memory\r\nRead Nv.mp3 into allocated memory\r\nUpdate page protection to PAGE_EXECUTE_READ\r\nExecute code located at Nv.mp3\r\nPrepare payload file name\r\nAllocate and enter the payload\r\nInInitialization Order Module List\r\nOnce the control flow accesses the Nv.mp3 memory region, it dynamically fetches the loaded module kernel32.dll’s base\r\naddress from the InInitializationOrderModuleList within the Process Environment Block (PEB).\r\nPEB is a data structure, which contains process information which is utilized internally by the operating system (OS). PEB\r\nis often utilized for anti-analysis techniques such as NtGlobalFlag check, but it can also be used to fetch necessary module\r\ninformation. \r\nAt offset 0x0C within PEB, PEB_LDR_DATA structure is located which stores loaded module information. This structure\r\nhas three members: InLoadOrderModuleList, InMemoryOrderModuleList, and InInitializationOrderModuleList:\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 5 of 18\n\nFetching loaded modules from PEB_LDR_DATA\r\nThe code located in Nv.mp3 fetches InInitializationOrderModuleList, which includes all the loaded modules in order of\r\ninitialization. This list does not include the executable itself, and it only lists the modules:\r\nInitializationOrderModuleList diagram\r\nThe Nv.mp3 searches through each element’s BaseDllName, until it finds kernel32.dll and retrieves the BaseAddress of the\r\nmodule. \r\nOnce the base address of kernel32.dll is retrieved, Nv.mp3 fetches the function GetProcAddress address in order to load the\r\nfunctions LoadLibraryA, VirtualAlloc, VirtualFree, and ExitThread, which appears to be loaded via StackString method:\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 6 of 18\n\nStackString libraries\r\nOnce all the function addresses are loaded from kernel32.dll, Nv.mp3 loads the module ntdll.dll by using the LoadLibraryA\r\nfunction which was retrieved earlier by the GetProcAddress function. From ntdll.dll, Nv.mp3 loads functions\r\nRtlDecompressBuffer and memcpy.\r\nPlugx Payload Decompression\r\nThe code located at Nv.mp3 level proceeds to decrypt the RC4-encrypted strings which are stored within the payload at\r\noffset 0x1529 with size 117KB. The decrypted strings are a compressed version of a PE file, which performs the\r\nRtlDecompressBuffer function with LZ decompression format:\r\nNT_RTL_COMPRESS_API NTSTATUS RtlDecompressBuffer(\r\n [in] USHORT CompressionFormat,\r\n [out] PUCHAR UncompressedBuffer,\r\n [in] ULONG UncompressedBufferSize,\r\n [in] PUCHAR CompressedBuffer,\r\n [in] ULONG CompressedBufferSize,\r\n [out] PULONG FinalUncompressedSize\r\n);\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 7 of 18\n\nFigure 11: RtlDecompressBuffer Function Parameters\r\nDecompressed Buffer\r\nThe decompressed PE file is an actual PlugX itself. However, the control flow does not immediately enter the decompressed\r\npayload. Nv.mp3 places the “GULP” signature, which is the backward for “PLUG” in newly allocated memory by\r\nVirtualAlloc with PAGE_EXECUTE_READWRITE protection. It proceeds to allocate each section’s .text, .rdata, .data, and\r\n.reloc by using the memcpy function into allocated memory.\r\nLastly, it loads necessary libraries and functions dynamically by using LoadLibraryA and GetProcAddress from the import\r\ntable listed in the decompressed PE file. Once this preparation is done, it proceeds to enter the PlugX payload:\r\nPlugX\r\npayload header\r\nPlugX Loader Flowchart\r\nThe following flowchart summarizes the flow of the PlugX loader:\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 8 of 18\n\nFigure 14: PlugX loader flowchart\r\nComparative Analysis\r\nThis comparative analysis analyzes the following six samples listed in the table below. The samples are observed in the past\r\nfrom various analyses from different reports. As a reference, the samples (executable, module, payload) are identified with\r\ncodename with prefix px_ followed by the relevant year that the samples were observed according to the external sources:\r\nCodename Filename SHA-256\r\npx_2012\r\nNv.exe 523D28DF917F9D265CD2C0D38DF26277BC56A535145100ED82E6F5FDEAAE7256\r\nNvSmartMax.dll EAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3\r\nNv.mp3 3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB\r\npx_2014 Gadget.exe 5C859CA16583D660449FB044677C128A9CDEDD603D9598D4670235C52E359BF9\r\nSidebar.dll 4B23F8683E184757E8119C8C68063F547F194E1ABD758DCBD4DACF70E3908FC1\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 9 of 18\n\nSidebar.dll.doc B2B93C7C4AC82623F74B14FE73F2C3F8E58E3306CC903C5AE71BC355CB5BD069\r\npx_2015\r\nfsguidll.exe 5C5E3201D6343E0536B86CB4AB0831C482A304C62CD09C01AC8BDEEE5755F635\r\nfslapi.dll 96876D24284FF4E4155A78C043C8802421136AFBC202033BF5E80D1053E3833F\r\nfslapi.dll.gui ACDC4987B74FDF7A32DFF87D56C43DF08CCE071B493858E3CE32FCF8D6372837\r\npx_2019\r\nmcinsupd.exe 507D49186748DD83D808281743A17FCA4B226883C410EC76EB305360CBC8C091\r\nmytilus3.dll 9FB33E460CA1654FCC555A6F040288617D9E2EFE626F611B77522606C724B59B\r\nmytilus3.dump 6914E9DE21F5CCE3F5C1457127122C13494ED82E6E2D95A8200A46BDB4CD7075\r\npx_2021\r\naro.exe 18A98C2D905A1DA1D9D855E86866921E543F4BF8621FAEA05EB14D8E5B23B60C\r\naross.dll 9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47\r\naro.dat 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F\r\npx_2022\r\nRasTls.exe F9EBF6AEB3F0FB0C29BD8F3D652476CD1FE8BD9A0C11CB15C43DE33BBCE0BF68\r\nRasTls.dll 6CD5079A69D9A68029E37F2680F44B7BA71C2B1EECF4894C2A8B293D5F768F10\r\nRasTls.dll.res 37B3FB9AA12277F355BBB334C82B41E4155836CF3A1B83E543CE53DA9D429E2F\r\nEach sample is compared based on the configuration and implementation of the PlugX loader:\r\nMalware’s release date control with OS datetime check\r\nManipulation of control flow by patching the instructions within the executable for anti-analysis\r\nDynamically retrieving module kernel32.dll’s base address within payload by utilizing the PEB_LDR_DATA\r\nstructure\r\nCode obfuscation within the payload for anti-analysis\r\nDecompression preparation of PlugX payload and the format of the payload\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 10 of 18\n\nOS Datetime\r\nAs explained in the previous section, PlugX loader does check that the date is later than a specific value. This behavior has\r\nbeen observed on three samples, from this list of six samples:\r\nSample Check count Datetime\r\npx_2012 2 2012-01-01, 2012\r\npx_2014 2 2012-01-01, 2012\r\npx_2015 0 N/A\r\npx_2019 1 2018\r\npx_2021 0 N/A\r\npx_2022 0 N/A\r\nThe date and time check happens twice in samples px_2012 and px_2014: \r\nChecks the date before executing the instruction patching function\r\nChecks the year before allocating the PlugX loader payload file\r\nHowever, in sample px_2019, it only conducts the date and time check for the year 2018. The versioning of this malware\r\nalso seems to exist, which is evident from the date and time check of the date of px_2019 being 2018. \r\nManipulate Control Flow\r\nSample Patch Instruction Patched Instruction\r\npx_2012 Yes JMP\r\npx_2014 No N/A\r\npx_2015 Yes JMP\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 11 of 18\n\npx_2019 Yes PUSH/RET\r\npx_2021 No N/A\r\npx_2022 Yes PUSH/RET\r\nManipulation of the control flow by patching the instructions with JMP is utilized with the samples, however the samples\r\npx_2019 and px_2022 are patched with PUSH and RET instructions. The PUSH instruction “pushes” the relevant function\r\naddress onto the stack and the RET instruction moves the control flow into the pushed address. \r\nSamples px_2014 and px_2021 did not patch instructions to manipulate the control flow. It utilized legitimate exported\r\nfunction names of the legitimate DLL which gets called by the legitimate executable.\r\nPEB_LDR_DATA\r\nSample PEB_LDR_DATA\r\npx_2012 InInitializationOrderModuleList \r\npx_2014 InInitializationOrderModuleList \r\npx_2015 InInitializationOrderModuleList \r\npx_2019 InInitializationOrderModuleList \r\npx_2021 InMemoryOrderModuleList \r\npx_2022 InInitializationOrderModuleList \r\nAside from InitializationOrderModuleList, sample px_2021 utilized InMemoryOrderModuleList.\r\nInMemoryOrderModuleList lists loaded modules according to the memory placement. The difference from\r\nInInitializationOrderModuleList is that InMemoryOrderModuleList includes the executable within the list. \r\nPayload Obfuscation\r\nSample Usage of StackString Usage of Code Obfuscation\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 12 of 18\n\npx_2012 Yes N/A\r\npx_2014 Yes Yes\r\npx_2015 Yes Yes\r\npx_2019 Yes; Places one characters at a time N/A\r\npx_2021 Yes; Places one characters at a time N/A\r\npx_2022 Yes; Some, one character at a time, some in bulk. N/A\r\nThe usage of StackString on the functions which need to be loaded dynamically appears to be consistent throughout the\r\nsamples. However, a slight update is placed in px_2019, px_2021 and px_2022, which is placing one character at a time onto\r\na Stack:\r\nFetching VirtualProtect\r\nSamples px_2014 and px_2015 also have additional code obfuscation, which is an encryption on the function that prepares\r\nthe PlugX payload. This function is the main component of this deployment payload and this is an additional layer of anti-analysis:\r\nCode deobfuscation in px_2015\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 13 of 18\n\nDecompression and Payload Deployment\r\nSample\r\nDecompression\r\nFormat\r\nDecryption of compressed\r\ndata\r\nDecompressed Data Format\r\nPayload\r\nHeader\r\npx_2012 LZ Yes PE File with PE signatures GULP\r\npx_2014 LZ Yes PE File with PE signatures GULP\r\npx_2015 LZ Yes\r\nPE File without PE\r\nsignatures\r\nXV\r\npx_2019 LZ Yes PE File with PE signatures GULP\r\npx_2021 LZ Yes\r\nPE File without PE\r\nsignatures \r\nROHT\r\npx_2022 LZ Yes PE File with PE signatures .PE\r\nDecompression of PlugX payload is consistent across the samples, which decrypts the LZ compressed data. However, the\r\ndecompressed payload for the samples px_2015 and px_2021 was not in complete PE file format. It was missing traditional\r\nPE signatures such as “MZ…This program cannot be run in DOS mode”. The relevant section information was still intact,\r\nwhich was needed for the PlugX loader to allocate necessary sections to the new memory region. \r\nThis update only removed portions of the PE header. However, it contained necessary information for the code to function.\r\nThis update prevents analysts from simply dumping the decompressed payload and conducting further analysis, since it is\r\nnot in proper PE format. \r\nSample px_2015, px_2021 and px_2022 also had different headers once the decompressed payload was allocated into\r\nPAGE_EXECUTE_READWRITE memory region: \r\npx_2015: XV - Roman numeral for 15.\r\npx_2021: ROHT - Backward for “THOR”\r\npx_2022: .PE - Portable Executable\r\nThe differences in the header may be evidence of the versioning of PlugX as well.\r\nCore Deployment Methods Are Consistent Across Samples\r\nThere are several slight detail differences while comparing samples, however there appears to be no major updates in the\r\npast decade regarding the deployment method of this malware. \r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 14 of 18\n\nAlthough there were no major updates, the malware loader appears to have version management. This is evident from OS\r\ndate and time check as well as the differences in payload headers while deploying the actual PlugX.\r\nThe lack of a major deployment method is also believed to be due to the use of the DLL Side-Loading technique. The DLL\r\nSide-Loading technique itself gives the threat actors various options on which legitimate executables to side-load the PlugX\r\nwith. This evasion technique already creates various combinations and an update on deployment methods deemed\r\nunnecessary\r\nDetection and Prevention\r\nCybereason Defense Platform\r\nThe Cybereason Defense Platform is able to detect and prevent infections with the PlugX loader using multi-layer protection\r\nthat detects and blocks malware with threat intelligence, machine learning, anti-ransomware and Next-Gen Antivirus\r\n(NGAV) capabilities:\r\nMalOp generation based from threat intelligence as seen in the Cybereason Defense Platform\r\nCybereason GSOC MDR\r\nThe Cybereason GSOC recommends the following:\r\nEnable both the Signature and Artificial Intelligence modes on the Cybereason NGAV, and enable the Detect and\r\nPrevent modes of this feature.\r\nHandle files originating from external sources (email, web browsing) with caution.\r\nTo hunt proactively, use the Investigation screen in the Cybereason Defense Platform and the queries in the Hunting\r\nQueries section to search for machines that are potentially infected with PlugX. Based on the search results, take\r\nfurther remediation actions, such as isolating the infected machines and deleting the payload file.\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 15 of 18\n\nCybereason is dedicated to teaming with defenders to end cyber attacks from endpoints to the enterprise to everywhere.\r\nSchedule a demo today to learn how your organization can benefit from an operation-centric approach to security.\r\nMITRE ATT\u0026CK MAPPING\r\nExecution Persistence Defense Evasion Discovery Collection\r\nCommand\r\nand Control \r\nCommand and\r\nScripting\r\nInterpreter\r\nBoot or logon\r\nAutostart\r\nExecution\r\nDeobfuscate/Decode Files\r\nor Information\r\nFile and\r\nDirectory\r\nDiscovery\r\nInput\r\nCapture\r\nApplication\r\nLayer Control\r\nNative API\r\nCreate or\r\nModify System\r\nProcess\r\nHide Artifacts\r\nNetwork Share\r\nDiscovery\r\nScreen\r\nCapture\r\nEncrypted\r\nChannel\r\n    Hijack Execution Flow\r\nProcess\r\nDiscovery\r\n \r\nIngress Tool\r\nTransfer\r\n    Masquerading Query Registry  \r\nNon-Application\r\nLayer Protocol\r\n    Modify Registry\r\nSystem Network\r\nConnections\r\nDiscovery\r\n  Web Service\r\n   \r\nObfuscated Files or\r\nInformation\r\n     \r\n   \r\nTrusted Developer\r\nUtilities Proxy Execution\r\n     \r\n   \r\nVirtualization/Sandbox\r\nEvasion\r\n     \r\nIndicators Of Compromise For PlugX Malware\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 16 of 18\n\nExecutables\r\nSHA-256 hash:\r\nEAAA7899B37A3B04DCD02AD6D51E83E035BE535F129773621EF0F399A2A98EE3\r\nSHA-256 hash:\r\n3D64E638F961B922398E2EFAF75504DA007E41EA979F213F8EB4F83E00EFEEBB\r\nSHA-256 hash:\r\n4B23F8683E184757E8119C8C68063F547F194E1ABD758DCBD4DACF70E3908FC1\r\nSHA-256 hash:\r\nB2B93C7C4AC82623F74B14FE73F2C3F8E58E3306CC903C5AE71BC355CB5BD069\r\nSHA-256 hash:\r\n96876D24284FF4E4155A78C043C8802421136AFBC202033BF5E80D1053E3833F\r\nSHA-256 hash:\r\nACDC4987B74FDF7A32DFF87D56C43DF08CCE071B493858E3CE32FCF8D6372837\r\nSHA-256 hash:\r\n9FB33E460CA1654FCC555A6F040288617D9E2EFE626F611B77522606C724B59B\r\nSHA-256 hash:\r\n6914E9DE21F5CCE3F5C1457127122C13494ED82E6E2D95A8200A46BDB4CD7075\r\nSHA-256 hash:\r\n9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47\r\nSHA-256 hash:\r\n59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F\r\nSHA-256 hash:\r\n6CD5079A69D9A68029E37F2680F44B7BA71C2B1EECF4894C2A8B293D5F768F10\r\nSHA-256 hash:\r\n37B3FB9AA12277F355BBB334C82B41E4155836CF3A1B83E543CE53DA9D429E2F\r\nAbout The Researchers \r\nKotaro Ogino, Senior Security Analyst, Cybereason Global SOC\r\nKotaro Ogino is a Senior Security Analyst with the Cybereason Global SOC team. He is involved in threat hunting,\r\nadministration of Security Orchestration, Automation, and Response (SOAR) systems, and Extended Detection and\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 17 of 18\n\nResponse (XDR). Kotaro has a bachelor of science degree in information and computer science.\r\nYuki Shibuya, Senior Security Analyst, Cybereason Global SOC\r\nYuki Shibuya is a Senior Security Analyst with the Cybereason Global SOC team. He is tasked with triaging critical\r\nincidents, threat hunting and malware research. He has a master degree of information systems security and is interested in\r\nmalware research and penetration testing.\r\nBig thanks to Aleksandar Milenkoski for advising the research!\r\nSource: https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nhttps://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cybereason.com/blog/threat-analysis-report-plugx-rat-loader-evolution"
	],
	"report_names": [
		"threat-analysis-report-plugx-rat-loader-evolution"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-10T02:00:05.259593Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "e3492534-85a6-4c87-a754-5ae4a56d7c8c",
			"created_at": "2022-10-25T15:50:23.819113Z",
			"updated_at": "2026-04-10T02:00:05.354598Z",
			"deleted_at": null,
			"main_name": "Threat Group-3390",
			"aliases": [
				"Threat Group-3390",
				"Earth Smilodon",
				"TG-3390",
				"Emissary Panda",
				"BRONZE UNION",
				"APT27",
				"Iron Tiger",
				"LuckyMouse",
				"Linen Typhoon"
			],
			"source_name": "MITRE:Threat Group-3390",
			"tools": [
				"Systeminfo",
				"gsecdump",
				"PlugX",
				"ASPXSpy",
				"Cobalt Strike",
				"Mimikatz",
				"Impacket",
				"gh0st RAT",
				"certutil",
				"China Chopper",
				"HTTPBrowser",
				"Tasklist",
				"netstat",
				"SysUpdate",
				"HyperBro",
				"ZxShell",
				"RCSession",
				"ipconfig",
				"Clambling",
				"pwdump",
				"NBTscan",
				"Pandora",
				"Windows Credential Editor"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "c63ab035-f9f2-4723-959b-97a7b98b5942",
			"created_at": "2023-01-06T13:46:38.298354Z",
			"updated_at": "2026-04-10T02:00:02.917311Z",
			"deleted_at": null,
			"main_name": "APT27",
			"aliases": [
				"BRONZE UNION",
				"Circle Typhoon",
				"Linen Typhoon",
				"TEMP.Hippo",
				"Budworm",
				"Lucky Mouse",
				"G0027",
				"GreedyTaotie",
				"Red Phoenix",
				"Iron Tiger",
				"Iron Taurus",
				"Earth Smilodon",
				"TG-3390",
				"EMISSARY PANDA",
				"Group 35",
				"ZipToken"
			],
			"source_name": "MISPGALAXY:APT27",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "b399b5f1-42d3-4b53-8c73-d448fce6ab43",
			"created_at": "2025-08-07T02:03:24.68371Z",
			"updated_at": "2026-04-10T02:00:03.64323Z",
			"deleted_at": null,
			"main_name": "BRONZE UNION",
			"aliases": [
				"APT27 ",
				"Bowser",
				"Budworm ",
				"Circle Typhoon ",
				"Emissary Panda ",
				"Group35",
				"Iron Tiger ",
				"Linen Typhoon ",
				"Lucky Mouse ",
				"TG-3390 ",
				"Temp.Hippo "
			],
			"source_name": "Secureworks:BRONZE UNION",
			"tools": [
				"AbcShell",
				"China Chopper",
				"EAGERBEE",
				"Gh0st RAT",
				"OwaAuth",
				"PhantomNet",
				"PoisonIvy",
				"Sysupdate",
				"Wonknu",
				"Wrapikatz",
				"ZxShell",
				"reGeorg"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434566,
	"ts_updated_at": 1775826699,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/12ace14e9dfca1adafff6eda46eb2b0d449f6114.pdf",
		"text": "https://archive.orkl.eu/12ace14e9dfca1adafff6eda46eb2b0d449f6114.txt",
		"img": "https://archive.orkl.eu/12ace14e9dfca1adafff6eda46eb2b0d449f6114.jpg"
	}
}