{
	"id": "f1ed8f4d-3a73-4e6f-acb7-a7177bf6a69c",
	"created_at": "2026-04-06T00:21:39.880051Z",
	"updated_at": "2026-04-10T03:21:29.417441Z",
	"deleted_at": null,
	"sha1_hash": "4ae52dfd4d0c0fa607005c9792fb24b3dd73858c",
	"title": "Deep Analysis of New Poison Ivy/PlugX Variant - Part II",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3551928,
	"plain_text": "Deep Analysis of New Poison Ivy/PlugX Variant - Part II\r\nBy Xiaopeng Zhang\r\nPublished: 2017-09-15 · Archived: 2026-04-05 18:51:33 UTC\r\nBackground\r\nThis is the second part of the FortiGuard Labs analysis of the new Poison Ivy variant, or PlugX, which was an\r\nintegrated part of Poison Ivy’s code. In the first part of this analysis we introduced how this malware was installed\r\nonto victim’s systems, the techniques it used to perform anti-analysis, how it obtained the C\u0026C server’s IP\u0026Port\r\nfrom the PasteBin website, and how it communicated with its C\u0026C server.\r\nWhat we didn’t talk much about in that first blog was the control-commands that are used by this malware, partly\r\nbecause only a few of those commands were used during our analysis. However, as you may know, RAT malware\r\nusually has many control-commands so that attackers can effectively remotely control a victim’s machine.\r\nSo, after our initial analysis, we monitored the C\u0026C servers and captured their packets. Fortunately, we were able\r\nto successfully collect enough attacks and packets so that we could obverse and document its behavior. In this\r\nanalysis, I’m going to focus on the control-commands used by the C\u0026C server as it attempts to penetrate the\r\nvictim’s network by exploiting vulnerabilities.\r\nAlthough the C\u0026C servers have now been shut down, we found a way to decrypt the communication data from\r\nthe captured packets in order to analyze its behavior.\r\nAs per my analysis, this variant of Poison Ivy eventually launches the MS17-010 (Eternal Blue) attack against the\r\nmachines located inside the victim’s LAN. Let’s now take a look at how it performs this exploit.\r\nManage multiple modules\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 1 of 11\n\nBefore going on, however, we have to talk about how the decrypted modules are managed. From Part I we know\r\nthat there are six modules in the svchost.exe program, which are connected by a doubly linked list. There is a\r\nmodule node in each of modules, as well as in svchost.exe. The module node is added into the doubly linked list\r\nwhen its module code is initialized. The header of the doubly linked list is in a global variable located in\r\nsvchost.exe’s memory space (qword_2345D0 with base address 0x220000 in my case).  Below is a module node’s\r\nstructure, along with some corrections to the one shown in the Part I of this analysis.\r\nThe first module (which was injected into svchost.exe when svchost.exe started) is executed in svchost.exe, and\r\nwas the first one added into the doubly linked list. I call it the host module.\r\nI named these module1, module2, etc. according to the order in which they are added into the doubly linked list,\r\n The six modules are decrypted by the host module.\r\nFigure 1 shows a view of the module node of the host (svchost.exe) in memory.\r\nFigure 1. View of the host module node in memory\r\nThe host module node’s address is 0x334A20. The previous node’s address is 0x165068, and the next one is\r\n0x51F280. The host module’s index is 0, and its module base address is 0x220000. Finally, the function table’s\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 2 of 11\n\naddress is 0x334A60. Module index is important because it is also a part of the Control-Commands. We will talk\r\nmore about this later.\r\nSeveral functions in the host module are used to manage this doubly linked list. To manage the doubly linked list\r\nbetween these different modules, the author of the malware designed a named sharing memory (by calling API\r\nCreateFilemappingA) where the addresses of the manager functions are saved. So whenever it wants to manage\r\nthe doubly linked list, it only needs to access all these functions from the sharing memory. BTW, the name of this\r\nsharing memory is created by calculating two current process IDs (by calling API GetCurrentProcessID, i.e.\r\nsvchost.exe PID).\r\nIn Figure 2, you can see how the named sharing memory is created, and where the manager functions are saved in\r\nthe sharing memory. The functions in [rax+8] and [rax+18] are called frequently during handling C\u0026C\r\ncommands. [rax+18] is the function that gets the module node from the doubly linked list using the module index,\r\nand sets module flag. [rax+8] is used to restore the module flag.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 3 of 11\n\nFigure 2. Code snippet of adding management functions into the named sharing memory\r\nHere is the modules’ information in my test environment:\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 4 of 11\n\nControl-Command Packet Structure\r\nIn order to easily understand the C\u0026C packets, I will explain the packet structure here. As I explained in the first\r\nblog, the packet payload is encrypted. Through analyzing its decryption function, I was able to write a python\r\nfunction to decrypt the data. This is the same function that the host module used to decrypt those six modules, as\r\nwell as the C\u0026C server IP\u0026Port from the PasteBin website, but different decryption keys are used.\r\nPython decryption function:\r\nThe decrypted packet consists of two parts. The first 14H bytes are the header, and the data starts at offset 14H.\r\nThe packet structure looks like this:\r\nIn the first blog I introduced commands “030001” and “030003”. Please refer here for more details. By the way,\r\nthe malware uses big-endian byte order to save its data. The control command is a Dword value, whose high 16\r\nbits are the module index, and the low 16 bits is a kind of code branch switch. Once the malware gets the\r\ncommand it retrieves the module node from the doubly linked list by matching the module index. It then calls the\r\nfunctions of that module to handle this command data.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 5 of 11\n\nFigure 3. All packets from C\u0026C server are dispatched from here\r\nFigure 3 shows the code snippet used for dispatching the C\u0026C packets to the correct module for processing. After\r\n“call sub_193370” we got the decrypted C\u0026C server packet in [rbp+arg_8]. “call sub_191C44” is used to get the\r\nmanagement functions in rax from the named sharing memory. “call qword ptr [rax+18h]” is used to call one\r\nmanagement function to get the module node from the doubly linked list using the module index in rcx i.e. high\r\n16 bits of command. “call qword ptr [r8]” calls the first function of the function table to process the received\r\npacket.\r\nFrom the above analysis you should now be able to clearly see the entire process of how the malware processes\r\nthe C\u0026C server’s packets.\r\nInstalling the “00000025” module\r\nIn my captured traffic, I was able to see many control commands. They include “00030001”, “00030002”,\r\n“00030003”, “00030004”, “00000003”, “00000001”, “00250000”, etc.\r\nSo let’s now take a look at what the “00000003” command is used for. Figure 4 shows the original received packet\r\nand the decrypted data.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 6 of 11\n\nFigure 4. “00000003” command data\r\nFrom the command “00000003” details we know that this packet is going to be passed to the host module (its\r\nindex is 0), and then be processed by the first function in the function table and the “0003” branch.\r\nIt gets the sub-command (“00000025”) as the module index to look for in that doubly linked list. So far, no\r\nmodule’s index is 0x25. It then replies to the C\u0026C server with sub-command “00000040”. If the 0x25 module\r\nnode exists, the sub-command is “00000000”.\r\nThe C\u0026C server then sends back command “00000001” with a new module attached. Below is part data of this\r\npacket after decryption, where you can see that the sub-command is “00000025”. In code branch “0001” it\r\ndecompresses the received module, then gets its code initialized, and finally adds it into the doubly linked list.\r\nThis module’s index is 0x25, so I call it Module25.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 7 of 11\n\nIt later sends command “00000001” with sub-command “00000000” to the C\u0026C server to let it know that the\r\n0x25 module was installed successfully. This module will be used to penetrate the victim’s network.\r\nBTW, this module’s information in my test machine is:\r\nPenetrating the victim’s LAN using EternalBlue\r\nI’m sure that the C\u0026C server sent commands to get the victim’s network configuration (my local IP, Gateway,\r\nDNS server), though I did not catch them.\r\nFigure 5 is the screenshot of the network configuration of my test machine.\r\nFigure 5. Network information\r\nThe C\u0026C server controls the malware to scan the victim’s network segment, including local IP, Gateway, and\r\nDNS server.  For example, because my DNS server is 172.30.1.105 it’s going to scan the 172.30.1.105/24 network\r\nsegment.\r\nThe C\u0026C server sends the “00000025” command with the destination IP and Port for further attack. By\r\ndecrypting “00000025” packets we are able to see its data, shown below.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 8 of 11\n\nFrom this data it is easy to see that there are IP addresses from three local machines. The sub-command\r\n“000001BD” refers to port 445.\r\nModule25 processes this packet, pulls the IP and port information from the packet, and then makes a connection to\r\nit. If any error occurs, it sends the status to the C\u0026C server.\r\nOnce successfully connected to the destination machine, the malware then serves as a middleman that keeps\r\ntransferring the two sockets’ data between the C\u0026C server and the destination machine (like man-in-the-middle\r\ndoes). In module3 we also see its debug output strings “SoTransfer(%p\u003c=\u003e%p)...\\r\\n” and\r\n“SoTransfer(%p\u003c=\u003e%p) quit!\\r\\n”. Figure 6 and 7 show the attack view in Wireshark.\r\nFigure 6. EternalBlue attack packets\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 9 of 11\n\nFigure 7. EternalBlue attack packet payload\r\nModule25 makes the connection to the destination IP and then calls module3’s function to perform the transfer\r\nwork by calling the recv() and send() functions. In module3 function sub_1935A8  it creates two threads to do\r\nthat. One thread receives data from the C\u0026C socket and sends it to the destination machine, and another one\r\nreceives data from the destination machine and forwards it to the C\u0026C server.  Figure 8 shows the code snippet\r\nfor what I explained about the two threads.\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 10 of 11\n\nFigure 8. Two threads to transfer packets\r\nConclusion\r\nBased on our analysis, this new Poison Ivy variant takes advantage of the EternalBlue exploit to spread. Once one\r\nsystem is infected by this variant, other systems on the same network are likely to be infected by the compromised\r\nsystem.\r\nSolution\r\nUsers should apply Microsoft’s patch for MS17-010.\r\nFortinet IPS signature MS.SMB.Server.SMB1.Trans2.Secondary.Handling.Code.Execution was released in March\r\n2017 to protect our customers against the EternalBlue attack.\r\nSign up for weekly Fortinet FortiGuard Labs Threat Intelligence Briefs and stay on top of the newest emerging\r\nthreats.\r\nSource: https://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nhttps://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii\r\nPage 11 of 11\n\nFigure 1. View The host module of the host node’s address module node in is 0x334A20. memory The previous node’s address is 0x165068, and the next one is\n0x51F280. The host module’s index is 0, and its module base address is 0x220000. Finally, the function table’s\n   Page 2 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.fortinet.com/2017/09/15/deep-analysis-of-new-poison-ivy-plugx-variant-part-ii"
	],
	"report_names": [
		"deep-analysis-of-new-poison-ivy-plugx-variant-part-ii"
	],
	"threat_actors": [],
	"ts_created_at": 1775434899,
	"ts_updated_at": 1775791289,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4ae52dfd4d0c0fa607005c9792fb24b3dd73858c.pdf",
		"text": "https://archive.orkl.eu/4ae52dfd4d0c0fa607005c9792fb24b3dd73858c.txt",
		"img": "https://archive.orkl.eu/4ae52dfd4d0c0fa607005c9792fb24b3dd73858c.jpg"
	}
}