{"id":9327,"date":"2017-09-16T08:58:06","date_gmt":"2017-09-16T16:58:06","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/09\/16\/news-3100\/"},"modified":"2017-09-16T08:58:06","modified_gmt":"2017-09-16T16:58:06","slug":"news-3100","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/09\/16\/news-3100\/","title":{"rendered":"Deep Analysis of New Poison Ivy\/PlugX Variant – Part II"},"content":{"rendered":"

Credit to Author: Xiaopeng Zhang| Date: Fri, 15 Sep 2017 12:50:00 +0000<\/strong><\/p>\n

\n

Background<\/h3>\n

This is the second part of the FortiGuard Labs<\/a> analysis of the new Poison Ivy variant, or PlugX, which was an integrated part of Poison Ivy\u2019s code. In the first part<\/a> of this analysis we introduced how this malware was installed onto victim\u2019s systems, the techniques it used to perform anti-analysis, how it obtained the C&C server\u2019s IP&Port from the PasteBin website, and how it communicated with its C&C server.<\/p>\n

What we didn\u2019t talk much about in that first blog\u00a0was the control-commands that are used by this malware, partly because only a few of those commands were used during our analysis. However, as you may know, RAT malware usually has many control-commands so that attackers can effectively remotely control a victim\u2019s machine.<\/p>\n

So, after our initial analysis, we monitored the C&C servers\u00a0and captured their packets. Fortunately, we were able to successfully collect enough attacks and packets so that we could obverse and document its behavior. In this analysis, I\u2019m going to focus on the control-commands used by the C&C server as it attempts to penetrate the victim\u2019s network by exploiting vulnerabilities.<\/p>\n

\"\"<\/p>\n

Although the C&C servers have now been shut down, we found a way to decrypt the communication data from the captured packets in order to analyze its behavior.<\/p>\n

As per my analysis, this variant of Poison Ivy eventually launches the MS17-010<\/a> (Eternal Blue) attack against the machines located inside the victim\u2019s LAN. Let\u2019s now take a look at how it performs this exploit.<\/p>\n

Manage multiple modules<\/h3>\n

Before going on, however, we have to talk about how the decrypted modules are managed. From Part I we know that there are six modules in the svchost.exe program, which are connected by a doubly linked list. There is a module node in each of modules, as well as in svchost.exe. The module node is added into the doubly linked list when its module code is initialized. The header of the doubly linked list is in a global variable located in svchost.exe\u2019s memory space (qword_2345D0 with base address 0x220000 in my case).\u00a0 Below is a module node\u2019s structure, along with some corrections to the one shown in the Part I of this analysis.<\/p>\n

\"\"<\/p>\n

The first module (which was injected into svchost.exe when svchost.exe started) is executed in svchost.exe, and was the first one added into the doubly linked list. I call it the host module.<\/p>\n

I named these module1, module2, etc. according to the order in which they are added into the doubly linked list, \u00a0The six modules are decrypted by the host module.<\/p>\n

Figure 1 shows a view of the module node of the host (svchost.exe) in memory.<\/p>\n

\"\" <\/em><\/p>\n

Figure 1. View of the host module node in memory<\/em><\/p>\n

The host module node\u2019s address is 0x334A20. The previous node\u2019s address is 0x165068, and the next one is 0x51F280. The host module\u2019s index is 0, and its module base address is 0x220000. Finally, the function table\u2019s address is 0x334A60. Module index is important because it is also a part of the Control-Commands. We will talk more about this later.<\/p>\n

Several functions in the host module are used to manage this doubly linked list. To manage the doubly linked list between these different modules, the author of the malware designed a named sharing memory (by calling API CreateFilemappingA<\/em>) where the addresses of the manager functions are saved. So whenever it wants to manage the doubly linked list, it only needs to access all these functions from the sharing memory. BTW, the name of this sharing memory is created by calculating two current process IDs (by calling API GetCurrentProcessID<\/em>, i.e. svchost.exe PID).<\/p>\n

In Figure 2, you can see how the named sharing memory is created, and where the manager functions are saved in the sharing memory. The functions in [rax+8] and [rax+18] are called frequently during handling C&C commands. [rax+18] is the function that gets the module node from the doubly linked list using the module index, and sets module flag. [rax+8] is used to restore the module flag.<\/p>\n

\"\" <\/em><\/p>\n

Figure 2. Code snippet of adding management functions into the named sharing memory<\/em><\/p>\n

Here is the modules\u2019 information in my test environment:<\/p>\n

\"\"<\/p>\n

Control-Command Packet Structure<\/h3>\n

In order to easily understand the C&C packets, I will explain the packet structure here. As I explained in the first blog, the packet payload is encrypted. Through analyzing its decryption function, I was able to write a python function to decrypt the data. This is the same function that the host module used to decrypt those six modules, as well as the C&C server IP&Port from the PasteBin website, but different decryption keys are used.<\/p>\n

Python decryption function:<\/p>\n

\"\"<\/p>\n

The decrypted packet consists of two parts. The first 14H bytes are the header, and the data starts at offset 14H. The packet structure looks like this:<\/p>\n

\"\"<\/p>\n

In the first blog I introduced commands \u201c030001\u201d and \u201c030003\u201d. Please refer here<\/a> for more details. By the way, the malware uses big-endian byte order to save its data. The control command is a Dword value, whose high 16 bits are the module index, and the low 16 bits is a kind of code branch switch. Once the malware gets the command it retrieves the module node from the doubly linked list by matching the module index. It then calls the functions of that module to handle this command data.<\/p>\n

\"\"<\/p>\n

Figure 3. All packets from C&C server are dispatched from here<\/em><\/p>\n

Figure 3 shows the code snippet used for dispatching the C&C packets to the correct module for processing. After \u201ccall sub_193370\u201d we got the decrypted C&C server packet in [rbp+arg_8]. \u201ccall sub_191C44\u201d is used to get the management functions in rax from the named sharing memory. \u201ccall qword ptr [rax+18h]\u201d is used to call one management function to get the module node from the doubly linked list using the module index in rcx i.e. high 16 bits of command. \u201ccall qword ptr [r8]\u201d calls the first function of the function table to process the received packet.<\/p>\n

From the above analysis you should now be able to clearly see the entire process of how the malware processes the C&C server\u2019s packets.<\/p>\n

Installing the \u201c00000025\u201d module<\/h3>\n

In my captured traffic, I was able to see many control commands. They include \u201c00030001\u201d, \u201c00030002\u201d, \u201c00030003\u201d, \u201c00030004\u201d, \u201c00000003\u201d, \u201c00000001\u201d, \u201c00250000\u201d, etc.<\/p>\n

So let\u2019s now take a look at what the \u201c00000003\u201d command is used for. Figure 4 shows the original received packet and the decrypted data.<\/p>\n

\"\"<\/p>\n

Figure 4. \u201c00000003\u201d command data<\/em><\/p>\n

From the command \u201c00000003\u201d details we know that this packet is going to be passed to the host module (its index is 0), and then be processed by the first function in the function table and the \u201c0003\u201d branch.<\/p>\n

It gets the sub-command (\u201c00000025\u201d) as the module index to look for in that doubly linked list. So far, no module\u2019s index is 0x25. It then replies to the C&C server with sub-command \u201c00000040\u201d. If the 0x25 module node exists, the sub-command is \u201c00000000\u201d.<\/p>\n

The C&C server then sends back command \u201c00000001\u201d with a new module attached. Below is part data of this packet after decryption, where you can see that the sub-command is \u201c00000025\u201d. In code branch \u201c0001\u201d it decompresses the received module, then gets its code initialized, and finally adds it into the doubly linked list. This module\u2019s index is 0x25, so I call it Module25.<\/p>\n

\"\"<\/p>\n

It later sends command \u201c00000001\u201d with sub-command \u201c00000000\u201d to the C&C server to let it know that the 0x25 module was installed successfully. This module will be used to penetrate the victim\u2019s network.<\/p>\n

BTW, this module\u2019s information in my test machine is:<\/p>\n

\"\"<\/p>\n

Penetrating the victim\u2019s LAN using EternalBlue<\/h3>\n

I\u2019m sure that the C&C server sent commands to get the victim\u2019s network configuration (my local IP, Gateway, DNS server), though I did not catch them.<\/p>\n

Figure 5 is the screenshot of the network configuration of my test machine.<\/p>\n

\"\"<\/p>\n

Figure 5. Network information<\/em><\/p>\n

The C&C server controls the malware to scan the victim\u2019s network segment, including local IP, Gateway, and DNS server. \u00a0For example, because my DNS server is 172.30.1.105 it\u2019s going to scan the 172.30.1.105\/24 network segment.<\/p>\n

The C&C server sends the \u201c00000025\u201d command with the destination IP and Port for further attack. By decrypting \u201c00000025\u201d packets we are able to see its data, shown below.<\/p>\n

\"\"<\/p>\n

From this data it is easy to see that there are IP addresses from three local machines. The sub-command \u201c000001BD\u201d refers to port 445.<\/p>\n

Module25 processes this packet, pulls the IP and port information from the packet, and then makes a connection to it. If any error occurs, it sends the status to the C&C server.<\/p>\n

Once successfully connected to the destination machine, the malware then serves as a middleman that keeps transferring the two sockets\u2019 data between the C&C server and the destination machine (like man-in-the-middle does). In module3 we also see its debug output strings \u201cSoTransfer(%p<=>%p)…rn<\/em>\u201d and \u201cSoTransfer(%p<=>%p) quit!rn<\/em>\u201d. Figure 6 and 7 show the attack view in Wireshark.<\/p>\n

\"\"<\/h2>\n

Figure 6. EternalBlue attack packets<\/em><\/p>\n

\"\"<\/p>\n

Figure 7. EternalBlue attack packet payload<\/em><\/p>\n

Module25 makes the connection to the destination IP and then calls module3\u2019s function to perform the transfer work by calling the recv() and send() functions. In module3 function sub_1935A8 <\/em>\u00a0it creates two threads to do that. One thread receives data from the C&C socket and sends it to the destination machine, and another one receives data from the destination machine and forwards it to the C&C server. \u00a0Figure 8 shows the code snippet for what I explained about the two threads.<\/p>\n

\"\"<\/p>\n

Figure 8. Two threads to transfer packets<\/em><\/p>\n

Conclusion<\/h3>\n

Based on our analysis, this new Poison Ivy variant takes advantage of the EternalBlue exploit to spread. Once one system is infected by this variant, other systems on the same network are likely to be infected by the compromised system.<\/p>\n

Solution<\/h3>\n

Users should apply Microsoft\u2019s patch for MS17-010<\/a>.<\/p>\n

Fortinet IPS signature MS.SMB.Server.SMB1.Trans2.Secondary.Handling.Code.Execution was released in March 2017 to protect our customers against the EternalBlue attack.<\/p>\n

Sign up<\/i><\/a>\u00a0for weekly Fortinet FortiGuard Labs Threat Intelligence Briefs and stay on top of the newest emerging threats.<\/i><\/p>\n<\/div
https:\/\/blog.fortinet.com\/feed<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

<\/p>\n

Credit to Author: Xiaopeng Zhang| Date: Fri, 15 Sep 2017 12:50:00 +0000<\/strong><\/p>\n

This is the second part of the FortiGuard Labs analysis of the new Poison Ivy variant, or PlugX, which was an integrated part of Poison Ivy\u2019s code. In the first part of this analysis we introduced how this malware was installed onto victim\u2019s systems, the techniques it used to perform anti-analysis, how it obtained the C&C server\u2019s IP&Port from the PasteBin website, and how it communicated with its C&C server.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10424,10378],"tags":[],"class_list":["post-9327","post","type-post","status-publish","format-standard","hentry","category-fortinet","category-security"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/9327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=9327"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/9327\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=9327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=9327"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=9327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}