{
	"id": "8e084060-140d-4847-a232-ce09e394464e",
	"created_at": "2026-04-06T00:08:30.469568Z",
	"updated_at": "2026-04-10T03:32:39.027052Z",
	"deleted_at": null,
	"sha1_hash": "713132cb020bd00fba7e6a97fdec10757fce7e50",
	"title": "Malware Analysis – PlugX",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2528147,
	"plain_text": "Malware Analysis – PlugX\r\nBy By Luis Rocha\r\nPublished: 2018-02-04 · Archived: 2026-04-02 11:31:31 UTC\r\n[The PlugX malware family has always intrigued me. I was curious to look at one variant. Going over the Internet\r\nand the research articles and blogs about it I came across the research made by Fabien Perigaud. From here I got\r\nan old PlugX builder. Then I set a lab that allowed me to get insight about how an attacker would operate a PlugX\r\ncampaign. In this post, l will cover a brief overview about the PlugX builder, analyze and debug the malware\r\ninstallation and do a quick look at the C2 traffic. ~LR]\r\nPlugX is commonly used by different threat groups on targeted attacks. PlugX is also refered as KORPLUG,\r\nSOGU, DestroyRAT and is a modular backdoor that is designed to rely on the execution of signed and legitimated\r\nexecutables to load malicious code. PlugX, normally has three main components, a DLL, an encrypted binary file\r\nand a legitimate and signed executable that is used to load the malware using a technique known as DLL search\r\norder hijacking. But let’s start with a quick overview about the builder.\r\nThe patched builder, MD5 6aad032a084de893b0e8184c17f0376a, is an English version, from Q3 2013,  of the\r\nfeatured-rich and modular command \u0026 control interface for PlugX that allows an operator to:\r\nBuild payloads, set campaigns and define the preferred method for the compromised hosts to check-in and\r\ncommunicate with the controller.\r\nProxy connections and build a tiered C2 communication model.\r\nDefine persistence mechanisms and its attributes.\r\nSet the process(s) to be injected with the payload.\r\nDefine a schedule for the C2 call backs.\r\nEnable keylogging and screen capture.\r\nManage compromises systems per campaign.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 1 of 13\n\nThen for each compromised system, the operator has extensive capabilities to interact with the systems over the\r\ncontroller that includes the following modules:\r\nDisk module allows the operator to write, read, upload, download and execute files.\r\nNetworking browser module allows the operator to browse network connections and connect to another\r\nsystem via SMB.\r\nProcess module to enumerate, kill and list loaded modules per process.\r\nServices module allows the operator to enumerate, start, stop and changing booting properties\r\nRegistry module allows the operator to browse the registry and create, delete or modify keys.\r\nNetstat module allows the operator to enumerate TCP and UDP network connections and the associated\r\nprocesses\r\nCapture module allows the operator to perform screen captures\r\nControl plugin allows the operator to view or remote control the compromised system in a similar way like\r\nVNC.\r\nShell module allows the operator to get a command line shell on the compromised system.\r\nPortMap module allows the operator to establish port forwarding rules.\r\nSQL module allows the operator to connect to SQL servers and execute SQL statements.\r\nOption module allows the operator to shut down, reboot, lock, log-off or send message boxes.\r\nKeylogger module captures keystrokes per process including window titles.\r\nThe picture below shows the Plug-X C2 interface.\r\nSo, with this we used the builder functionality to define the different settings specifying C2 comms password,\r\ncampaign, mutex, IP addresses, installation properties, injected binaries, schedule for call-back, etc. Then we build\r\nour payload. The PlugX binary produced by this version of the builder (LZ 2013-8-18) is a self-extracting RAR\r\narchive that contains three files. This is sometimes referred in the literature as the PlugX trinity payload.\r\nExecuting the self-extracting RAR archive will drop the three files to the directory chosen during the process. In\r\nthis case “%AUTO%/RasTls”. The files are: A legitimate signed executable from Kaspersky AV solution named\r\n“avp.exe”, MD5 e26d04cecd6c7c71cfbb3f335875bc31, which is susceptible to DLL search order hijacking . The\r\nfile “avp.exe” when executed will load the second file: “ushata.dll”, MD5 728fe666b673c781f5a018490a7a412a,\r\nwhich in this case is a DLL crafted by the PlugX builder which on is turn will load the third file. The third file:\r\n“ushata.DLL.818”, MD5 “21078990300b4cdb6149dbd95dff146f” contains obfuscated and packed shellcode.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 2 of 13\n\nSo, let’s look at the mechanics of what happens when the self-extracting archive is executed. The three files are\r\nextracted to a temporary directory and “avp.exe” is executed. The “avp.exe” when executed will load “ushata.dll”\r\nfrom the running directory due to the DLL search order hijacking using Kernel32.LoadLibrary API.\r\nThen “ushata.dll” DLL entry point is executed. The DLL entry point contains code that verifies if the system date\r\nis equal or higher than 20130808. If yes it will get a handle to “ushata.DLL.818”, reads its contents into memory\r\nand changes the memory address segment permissions to RWX using Kernel32.VirtualProtect API. Finally,\r\nreturns to the first instruction of the loaded file (shellcode). The file “ushata.DLL.818” contains obfuscated\r\nshellcode. The picture below shows the beginning of the obfuscated shellcode.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 3 of 13\n\nThe shellcode unpacks itself using a custom algorithm. This shellcode contains position independent code. Figure\r\nbelow shows the unpacked shellcode.\r\nThe shellcode starts by locating the kernel32.dll address by accessing the Thread Information Block (TIB) that\r\ncontains a pointer to the Process Environment Block (PEB) structure. Figure below shows a snippet of the\r\nshellcode that contains the different sequence of assembly instructions for the code to find the Kernel32.dll.\r\nIt then reads kernel32.dll export table to locate the desired Windows API’s by comparing them with stacked\r\nstrings. Then, the shellcode decompresses a DLL (offset 0x784) MD5 333e2767c8e575fbbb1c47147b9f9643, into\r\nmemory using the LZNT1 algorithm by leveraging ntdll.dll.RtlDecompressBuffer API. The DLL contains the PE\r\nheader replaced with the “XV” value. Restoring the PE header signature allows us to recover the malicious DLL.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 4 of 13\n\nNext, the payload will start performing different actions to achieve persistence. On Windows 7 and beyond, PlugX\r\ncreates a folder “%ProgramData%\\RasTl” where “RasTl” matches the installation settings defined in the builder.\r\nThen, it changes the folder attributes to “SYSTEM|HIDDEN” using the SetFileAttributesW API. Next, copies its\r\nthree components into the folder and sets all files with the “SYSTEM|HIDDEN” attribute.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 5 of 13\n\nThe payload also modifies the timestamps of the created directory and files with the timestamps obtained from\r\nntdll.dll using the SetFileTime API.\r\nThen it creates the service “RasTl” where the ImagePath points to “%ProgramData%\\RasTl\\avp.exe”\r\nIf the malware fails to start the just installed service, it will delete it and then it will create a persistence\r\nmechanism in the registry by setting the registry value “C:\\ProgramData\\RasTls\\avp.exe” to the key\r\n“HKLM\\SOFTWARE\\Classes\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\RasTls” using\r\nthe RegSetValueExW API.\r\nIf the builder options had the Keylogger functionality enabled, then it may create a file with a random name such\r\nas “%ProgramData%\\RasTl\\rjowfhxnzmdknsixtx” that stores the key strokes. If the payload has been built with\r\nScreen capture functionality, it may create the folder “%ProgramData%\\RasTl \\RasTl\\Screen” to store JPG images\r\nin the format \u003cdatetime\u003e.jpg that are taken at the frequency specified during the build process. The payload may\r\nalso create the file “%ProgramData%\\DEBUG.LOG” that contains debugging information about its execution\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 6 of 13\n\n(also interesting that during execution the malware outputs debug messages about what is happening using the\r\nOutputDebugString API. This messages could be viewed with DebugView from SysInternals). The malicious code\r\ncompletes its mission by starting a new instance of “svchost.exe” and then injects the malicious code into\r\nsvchost.exe process address space using process hollowing technique. The pictures below shows the first step of\r\nthe process hollowing technique where the payload creates a new “svchost.exe” instance in SUSPENDED state.\r\nand then uses WriteProcessMemory API to inject the malicious payload\r\nThen the main thread, which is still in suspended state, is changed in order to point to the entry point of the new\r\nimage base using the SetThreadContext API. Finally, the ResumeThread API is invoked and the malicious code\r\nstarts executing. The malware also has the capabilities to bypass User Account Control (UAC) if needed. From\r\nthis moment onward, the control is passed over “svchost.exe” and Plug-X starts doing its thing. In this case we\r\nhave the builder so we know the settings which were defined during building process. However, we would like to\r\nunderstand how could we extract the configuration settings. During Black Hat 2014, Takahiro Haruyama and\r\nHiroshi Suzuki gave a presentation titled “I know You Want Me – Unplugging PlugX” where the authors go to\r\ngreat length analyzing a variety of PlugX samples, its evolution and categorizing them into threat groups. But\r\nbetter is that the Takahiro released a set of PlugX parsers for the different types of PlugX samples i.e, Type I, Type\r\nII and Type III. How can we use this parser? The one we are dealing in this article is considered a PlugX type II.\r\nTo dump the configuration, we need to use Immunity Debugger and use the Python API. We need to place the\r\n“plugx_dumper.py” file into the “PyCommands” folder inside Immunity Debugger installation path. Then\r\nattached the debugger to the infected process e.g, “svchost.exe” and run the plugin. The plugin will dump the\r\nconfiguration settings and will also extract the decompressed DLL\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 7 of 13\n\nWe can see that this parser is able to find the injected shellcode, decode its configuration and all the settings an\r\nattacker would set on the builder and also dump the injected DLL which contains the core functionality of the\r\nmalware.\r\nIn terms of networking, as observed in the PlugX controller, the malware can be configured to speak with a\r\ncontroller using several network protocols. In this case we configured it to speak using HTTP on port 80. The\r\nnetwork traffic contains a 16-byte header followed by a payload. The header is encoded with a custom routine and\r\nthe payload is encoded and compressed with LZNT1. Far from a comprehensive analysis we launched a Shell\r\nprompt from the controller, typed command “ipconfig” and observed the network traffic. In parallel, we attached a\r\ndebugger to “svchost.exe” and set breakpoints: on Ws2_32.dll!WSASend and Ws2_32.dll!WSARecv to capture\r\nthe packets ; on ntdll.dll!RtlCompressBuffer and ntdll.dll!RtlDecompressBuffer to view the data before and after\r\ncompression. ; On custom encoding routine to view the data before and after. The figure below shows a\r\ndisassemble listing of the custom encoding routine.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 8 of 13\n\nSo, from a debugger view, with the right breakpoints we could start to observe what is happening. In the picture\r\nbelow, on the left-hand side it shows the packet before encoding and compression. It contains a 16-byte header,\r\nwhere the first 4-bytes are the key for the custom encoding routine. The next 4-bytes are the flags which contain\r\nthe commands/plugins being used. Then the next 4-bytes is the size. After the header there is the payload which in\r\nthis case contains is output of the ipconfig.exe command. On the right-hand side, we have the packet after\r\nencoding and compressing. It contains the 16-byte header encoded following by the payload encoded and\r\ncompressed.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 9 of 13\n\nThen, the malware uses WSASend API to send the traffic.\r\nCapturing the traffic, we can observe the same data.\r\nOn the controller side, when the packet arrives, the header will be decoded and then the payload will be decoded\r\nand decompressed. Finally, the output is showed to the operator.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 10 of 13\n\nNow that we started to understand how C2 traffic is handled, we can capture it and decode it.  Kyle Creyts has\r\ncreated a PlugX decoder that supports PCAP’s. The decoder supports decryption of PlugX Type I.But Fabien\r\nPerigaud reversed the Type II algorithm and implemented it in python. If we combine Kyle’s work with the work\r\nfrom Takahiro Haruyama and Fabien Perigaud we could create a PCAP parser to extract PlugX Type II and Type\r\nIII. Below illustrates a proof-of-concept for this exercise against 1 packet. We captured the traffic and then used a\r\nsmall python script to decrypt a packet. No dependencies on Windows because it uses the herrcore’s standalone\r\nLZNT1 implementation that is based on the one from the ChopShop protocol analysis and decoder framework by\r\nMITRE.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 11 of 13\n\nThat’s it for today! We build a lab with a PlugX controller, got a view on its capabilities. Then we looked at the\r\nmalware installation and debugged it in order to find and interpret some of its mechanics such as DLL search\r\norder hijacking, obfuscated shellcode, persistence mechanism and process hollowing. Then, we used a readily\r\navailable parser to dump its configuration from memory. Finally, we briefly looked the way the malware\r\ncommunicates with the C2 and created a small script to decode the traffic. Now, with such environment ready, in a\r\ncontrolled and isolated lab, we can further simulate different tools and techniques and observe how an attacker\r\nwould operate compromised systems. Then we can learn, practice at our own pace and look behind the scenes to\r\nbetter understand attack methods and ideally find and implement countermeasures.\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 12 of 13\n\nReferences:\r\nAnalysis of a PlugX malware variant used for targeted attacks by CRCL.lu\r\nOperation Cloud Hopper by PWC\r\nPlugX Payload Extraction by Kevin O’Reilly\r\nOther than the authors and articles cited troughout the article, a fantastic compilation about PlugX articles and\r\npapers since 2011 is available here.\r\nCredits: Thanks to Michael Bailey who showed me new techniques on how to deal with shellcode which I will\r\nlikely cover on a post soon.\r\nSource: https://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nhttps://countuponsecurity.com/2018/02/04/malware-analysis-plugx/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://countuponsecurity.com/2018/02/04/malware-analysis-plugx/"
	],
	"report_names": [
		"malware-analysis-plugx"
	],
	"threat_actors": [
		{
			"id": "ec14074c-8517-40e1-b4d7-3897f1254487",
			"created_at": "2023-01-06T13:46:38.300905Z",
			"updated_at": "2026-04-10T02:00:02.918468Z",
			"deleted_at": null,
			"main_name": "APT10",
			"aliases": [
				"Red Apollo",
				"HOGFISH",
				"BRONZE RIVERSIDE",
				"G0045",
				"TA429",
				"Purple Typhoon",
				"STONE PANDA",
				"Menupass Team",
				"happyyongzi",
				"CVNX",
				"Cloud Hopper",
				"ATK41",
				"Granite Taurus",
				"POTASSIUM"
			],
			"source_name": "MISPGALAXY:APT10",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "04b07437-41bb-4126-bcbb-def16f19d7c6",
			"created_at": "2022-10-25T16:07:24.232628Z",
			"updated_at": "2026-04-10T02:00:04.906097Z",
			"deleted_at": null,
			"main_name": "Stone Panda",
			"aliases": [
				"APT 10",
				"ATK 41",
				"Bronze Riverside",
				"CTG-5938",
				"CVNX",
				"Cuckoo Spear",
				"Earth Kasha",
				"G0045",
				"G0093",
				"Granite Taurus",
				"Happyyongzi",
				"Hogfish",
				"ITG01",
				"Operation A41APT",
				"Operation Cache Panda",
				"Operation ChessMaster",
				"Operation Cloud Hopper",
				"Operation Cuckoo Spear",
				"Operation New Battle",
				"Operation Soft Cell",
				"Operation TradeSecret",
				"Potassium",
				"Purple Typhoon",
				"Red Apollo",
				"Stone Panda",
				"TA429",
				"menuPass",
				"menuPass Team"
			],
			"source_name": "ETDA:Stone Panda",
			"tools": [
				"Agent.dhwf",
				"Agentemis",
				"Anel",
				"AngryRebel",
				"BKDR_EVILOGE",
				"BKDR_HGDER",
				"BKDR_NVICM",
				"BUGJUICE",
				"CHINACHOPPER",
				"ChChes",
				"China Chopper",
				"Chymine",
				"CinaRAT",
				"Cobalt Strike",
				"CobaltStrike",
				"DARKTOWN",
				"DESLoader",
				"DILLJUICE",
				"DILLWEED",
				"Darkmoon",
				"DelfsCake",
				"Derusbi",
				"Destroy RAT",
				"DestroyRAT",
				"Ecipekac",
				"Emdivi",
				"EvilGrab",
				"EvilGrab RAT",
				"FYAnti",
				"Farfli",
				"Gen:Trojan.Heur.PT",
				"Gh0st RAT",
				"Ghost RAT",
				"GreetCake",
				"HAYMAKER",
				"HEAVYHAND",
				"HEAVYPOT",
				"HTran",
				"HUC Packet Transmit Tool",
				"Ham Backdoor",
				"HiddenFace",
				"Impacket",
				"Invoke the Hash",
				"KABOB",
				"Kaba",
				"Korplug",
				"LODEINFO",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"MiS-Type",
				"Mimikatz",
				"Moudour",
				"Mydoor",
				"NBTscan",
				"NOOPDOOR",
				"Newsripper",
				"P8RAT",
				"PCRat",
				"PlugX",
				"Poison Ivy",
				"Poldat",
				"PowerSploit",
				"PowerView",
				"PsExec",
				"PsList",
				"Quarks PwDump",
				"Quasar RAT",
				"QuasarRAT",
				"RedDelta",
				"RedLeaves",
				"Rubeus",
				"SNUGRIDE",
				"SPIVY",
				"SharpSploit",
				"SigLoader",
				"SinoChopper",
				"SodaMaster",
				"Sogu",
				"TIGERPLUG",
				"TVT",
				"Thoper",
				"Trochilus RAT",
				"UpperCut",
				"Vidgrab",
				"WinRAR",
				"WmiExec",
				"Wmonder",
				"Xamtrav",
				"Yggdrasil",
				"Zlib",
				"certutil",
				"certutil.exe",
				"cobeacon",
				"dfls",
				"lena",
				"nbtscan",
				"pivy",
				"poisonivy",
				"pwdump"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434110,
	"ts_updated_at": 1775791959,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/713132cb020bd00fba7e6a97fdec10757fce7e50.pdf",
		"text": "https://archive.orkl.eu/713132cb020bd00fba7e6a97fdec10757fce7e50.txt",
		"img": "https://archive.orkl.eu/713132cb020bd00fba7e6a97fdec10757fce7e50.jpg"
	}
}