{
	"id": "97e1f5cd-a392-488e-b85b-edd70ca2ee44",
	"created_at": "2026-04-06T00:11:24.826677Z",
	"updated_at": "2026-04-10T03:32:20.792051Z",
	"deleted_at": null,
	"sha1_hash": "ca1583533d1d3f1e95986c97bf401f17e3e236fd",
	"title": "Malware Analysis – PlugX – Part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1193274,
	"plain_text": "Malware Analysis – PlugX – Part 2\r\nBy By Luis Rocha\r\nPublished: 2018-05-09 · Archived: 2026-04-05 14:39:57 UTC\r\nFollowing my previous article on PlugX, I would like to\r\ncontinue the analysis but now use the PlugX controller to mimic some of the steps that might be executed by an\r\nattacker. As you know the traditional steps of an attack lifecycle follow, normally, a predictable sequence of events\r\ni.e., Reconnaissance, initial compromise, establish foothold, escalate privileges, internal reconnaissance, move\r\nlaterally, maintain persistence, complete mission. For sake of brevity I will skip most of the steps and will focus\r\non the lateral movement.I will use the PlugX controller and C2 functionality to simulate an attacker that\r\nestablished a foothold inside an environment and obtained admin access to a workstation. Following that, the\r\nattacker moved laterally to a Windows Domain Controller. I will use the PlugX controller to accomplish this\r\nscenario and observe how an attacker would operate within a compromised environment.\r\nAs we saw previously, the PlugX controller interface allows an operator to build payloads, set campaigns and\r\ndefine the preferred method for the compromised hosts to check-in and communicate with the controller. In the\r\nPlugX controller, English version from Q3 2013, an operator can build the payload using two techniques. One is\r\nusing the “DNS Online” technique which allows the operator to define the C2 address e.g, an URL or IP address,\r\nthat will be used by the payload to speak with the C2. The other method, is the “Web Online”, which allows the\r\noperator to tell the payload from where it should fetch the C2 address. This method allows the operator to have\r\nmore control over the campaign. The following diagram illustrates how the “Web Online” technique works.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 1 of 13\n\nWhy do I say this technique would allow an attacker to have more control? Consider the case that an organization\r\nwas compromised by a threat actor that use this PlugX technique. In case the C2 is discovered, the impacted\r\norganization could block the IP or URL on the existing boundary security controls as a normal reaction to the\r\nconcerns of having an attacker inside the network. However, the attacker could just change the C2 string and point\r\nit to a different system. In case the organization was not able to scope the incident and understand the TTP’s\r\n(Tools, Tactics and Procedures) then the attacker would still maintain persistence in the environment. This is an\r\nexample that when conducting incident response, among other things, you need to have visibility into the tools\r\nand techniques the attacker is using so you could properly scope the incident and perform effective and efficient\r\ncontainment and eradication steps. As an example of this technique, below is a print screen from a GitHub page\r\nthat has been used by an unknown threat actor to leverage this method.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 2 of 13\n\nSo, how to leverage this technique on the PlugX builder? The picture below shows how the operator could create a\r\npayload that uses the “Web Online” technique. The C2 address would be fetched from a specified site e.g. a\r\nPastebin address, which on its turn would redirect the payload to the real C2 address. The string\r\n“DZKSAFAAHHHHHHOCCGFHJGMGEGFGCHOCDGPGNGDZJS” in this case is used to decode to the real\r\nC2 address which is “www.builder.com”. On the “PlugX: some uncovered points” article, Fabien Perigaud writes\r\nabout how to decode this string. Palo Alto Unit42 gives another example of this technique on the “Paranoid\r\nPlugX” article. The article “Winnti Abuses GitHub for C\u0026C Communications” from Cedric Pernet ilustrates an\r\nAPT group leveraging this technique using GitHub.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 3 of 13\n\nFor sake of simplicity, in this article, I’m going to use the DNS Online technique using “www.builder.com” as C2\r\naddress. Next, on the “First” tab I specify the campaing ID and the password used by the payload to connect to the\r\nC2.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 4 of 13\n\nNext, on the Install tab I specify the persistence settings, in this case I’m telling the payload to install a service and\r\nI can specify different settings including where to deploy the binaries, the service name and service description. In\r\naddition, I can specify that if the Service persistence mechanism fails due to some reason the payload should\r\ninstall the persistence mechanism using the Registry and I can specify which HIVE should be used.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 5 of 13\n\nThen, In the inject tab I specify which process will be injected with the malicious payload. In this case I choose\r\n“svchost.exe”. This will make PlugX start a new instance of “svchost.exe” and then inject the malicious code into\r\nsvchost.exe process address space using process hollowing technique.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 6 of 13\n\nOther than that, the operator could define a schedule and determine which time of the week the payload should\r\ncommunicate with the C2. Also the operator could define the Screen Recording capability that will take\r\nscreenshots at a specific frequency and will save them encrypted in a specific folder.\r\nLast settings on the “option” tab allow the operator to enable the keylogger functionality and specify if the\r\npayload should hide it self and also delete itself after execution.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 7 of 13\n\nFinally, after all the settings defined, the operator can create/download the payload in different formats. An\r\nexecutable, binary form (Shellcode), or an array in C that can then be plugged in another delivery mechanism e.g,\r\nPowerShell or MsBuild. After deploying and installing the payload on a system, that system will check-in into the\r\nPlugX controller and an operator can call the “Manager” to perform the different actions. In this example I show\r\nhow an attacker, after having compromised a system, uses the C2 interface to:\r\nBrowse the network\r\nAccess remote systems via UNC path\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 8 of 13\n\nUpload and execute a file e.g., upload PlugX binary\r\nInvoke a command shell and perform remote commands e.g., execute PlugX binary on a remote system\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 9 of 13\n\nPrevious pictures illustrate actions that the attacker could perform to move laterally and, for example, at some\r\npoint in time, access a domain controller via UNC path, upload the PlugX payload to a directory of its choice and\r\nexecute it. In this case the pictures show that the PlugX payload was dropped into c:\\PerfLogs\\Admin folder and\r\nthen was executed using WMI. Below example shows the view from the attacker with two C2 sessions. One for\r\none workstation and another for a domain controller.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 10 of 13\n\nHaving access to a domain controller is likely one of the goals of the attacker so he can obtain all the information\r\nhe needs about an organization from the Active Directory database.\r\nTo access the Active Directory database, the attacker could, for example, run the “ntdsutil.exe” command to create\r\na copy of the “NTDS.dit” file using Volume Shadow Copy technique. Then, the attacker can access the database\r\nand download it to a system under his control using the PlugX controller interface. The picture below illustrates an\r\nattacker obtained the relevant data that was produced using the “ntdsutil.exe” command.\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 11 of 13\n\nFinally, the attacker might delete the artifacts that were left behind on the file system as consequence of running\r\n“ntdsutil.exe”.\r\nSo, in summary, we briefly looked at the different techniques a PlugX payload could be configured to speak with a\r\nCommand and Controller. We built, deploy and install a payload. Compromised a system and obtain a perspective\r\nfrom PlugX operator. We move laterally to a domain controller and installed the PlugX payload and then used a\r\ncommand shell to obtain the Active Directory database. Of course, as you noted, the scenario was accomplished\r\nwith an old version of the PlugX controller. Newer versions likely have many new features and capabilities. For\r\nexample, the print screen below is from a PlugX builder from 2014 (MD5: 534d28ad55831c04f4a7a8ace6dd76c3)\r\nwhich can create different payloads that perform DLL Search order hijacking using Lenovo’s RGB LCD Display\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 12 of 13\n\nUtility for ThinkPad (tplcdclr.exe) or Steve Gibson’s Domain Name System Benchmarking Utility (sep_NE.exe).\r\nThe article from Kaspersky “PlugX malware: A good hacker is an apologetic hacker” outlines a summary about it.\r\nThat’s it! With this article we set the table for the next article focusing on artifacts that might helps us uncover the\r\nhidden traits that were left behind by the attacker actions performed during this scenario. Stay tuned and have fun!\r\nSource: https://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nhttps://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/\r\nPage 13 of 13\n\n https://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/     \nFor sake of simplicity, in this article, I’m going to use the DNS Online technique using “www.builder.com” as C2\naddress. Next, on the “First” tab I specify the campaing ID and the password used by the payload to connect to the\nC2.      \n   Page 4 of 13   \n\n  https://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/    \nUtility for ThinkPad (tplcdclr.exe) or Steve Gibson’s Domain Name System Benchmarking Utility (sep_NE.exe). \nThe article from Kaspersky “PlugX malware: A good hacker is an apologetic hacker” outlines a summary about it.\nThat’s it! With this article we set the table for the next article focusing on artifacts that might helps us uncover the\nhidden traits that were left behind by the attacker actions performed during this scenario. Stay tuned and have fun!\nSource: https://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/      \n   Page 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://countuponsecurity.com/2018/05/09/malware-analysis-plugx-part-2/"
	],
	"report_names": [
		"malware-analysis-plugx-part-2"
	],
	"threat_actors": [
		{
			"id": "4d5f939b-aea9-4a0e-8bff-003079a261ea",
			"created_at": "2023-01-06T13:46:39.04841Z",
			"updated_at": "2026-04-10T02:00:03.196806Z",
			"deleted_at": null,
			"main_name": "APT41",
			"aliases": [
				"WICKED PANDA",
				"BRONZE EXPORT",
				"Brass Typhoon",
				"TG-2633",
				"Leopard Typhoon",
				"G0096",
				"Grayfly",
				"BARIUM",
				"BRONZE ATLAS",
				"Red Kelpie",
				"G0044",
				"Earth Baku",
				"TA415",
				"WICKED SPIDER",
				"HOODOO",
				"Winnti",
				"Double Dragon"
			],
			"source_name": "MISPGALAXY:APT41",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2a24d664-6a72-4b4c-9f54-1553b64c453c",
			"created_at": "2025-08-07T02:03:24.553048Z",
			"updated_at": "2026-04-10T02:00:03.787296Z",
			"deleted_at": null,
			"main_name": "BRONZE ATLAS",
			"aliases": [
				"APT41 ",
				"BARIUM ",
				"Blackfly ",
				"Brass Typhoon",
				"CTG-2633",
				"Earth Baku ",
				"GREF",
				"Group 72 ",
				"Red Kelpie ",
				"TA415 ",
				"TG-2633 ",
				"Wicked Panda ",
				"Winnti"
			],
			"source_name": "Secureworks:BRONZE ATLAS",
			"tools": [
				"Acehash",
				"CCleaner v5.33 backdoor",
				"ChinaChopper",
				"Cobalt Strike",
				"DUSTPAN",
				"Dicey MSDN",
				"Dodgebox",
				"ForkPlayground",
				"HUC Proxy Malware (Htran)"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434284,
	"ts_updated_at": 1775791940,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ca1583533d1d3f1e95986c97bf401f17e3e236fd.pdf",
		"text": "https://archive.orkl.eu/ca1583533d1d3f1e95986c97bf401f17e3e236fd.txt",
		"img": "https://archive.orkl.eu/ca1583533d1d3f1e95986c97bf401f17e3e236fd.jpg"
	}
}