Persistant Ways of PlugX RAT

 

 PlugX a Remote Access Trojan (RAT) was first identified in 2012. PlugX is known to be used against high profile government institutions and other organizations and has evolved since then. PlugX has also been seen as Korplug, SOGU and DestroyRAT. The primary functionality of this malware is to:

•      Provide persistence access for adversaries.
•    Perform surveillance of the infected machines.
•      Reach out to a command and control server.
•      Hijack legitimate executable and inject malicious code.

Since the identification of PlugX in 2012, it has mutated in complexity and exploitation techniques. PlugX is commonly seen to be used in advanced targeted attacks, with capabilities to impersonate authentic processes and perform extensive recon on infected machines.

The malware sample analyzed in this blog, has been downloaded from the internet.

Basic Static Analysis

The malware sample analyzed in this blog is a 32-bit Executable, having a compiler timestamp of Feb 10, 2010.

Basic Information

Apart from this, PE header analysis tells us that the executable has 5 sections and it’s a GUI application.

PE Header Analysis

Checking the entropy for each section we can see that the .text section is packed. The .text section contains executable instructions.

Entropy Analysis

Further we can see that the sample is packed using WinRAR SFX.

Packer used

As the malware sample is packed using WinRAR SFX, we can easily unpack it by opening it in WinRAR and extracting the files. Upon unpacking the malware sample, we get 3 new files.

Evt.exe | Mc.cp | McUtil.dll

 

WinRAR

Let’s now perform basic string analysis on the unpacked files.

Strings

Analysing strings of a sample is an easy way of gaining an insight about the functionality of the program. Here, we can see that the packed sample is using WinRAR SFX to unpack itself. Further it creates a directory to store the three files that we get after unpacking.

One interesting thing that can be seen is, “evt.exe” is making “IsDebuggerPresent” API call. With this knowledge, we can assume that the malware is implementing an anti-debugger behaviour. Also “evt.exe” is a McAfee OEM binary signed by McAfee.

Disassembling the Executable

Analysing the packed executable

Based on static analysis we could conclude that the .text section is packed using the WinRAR SFX. Here, in the disassembled code we can see that WinRAR SFX is used to unpack the executable and further it is executed as a child process using “runas”.

Unpacking routine

Analysing evt.exe

Once again in the static analysis we could conclude that evt.exe is actually a McAfee OEM executable and is signed by McAfee. The malware is using DLL search order attack to load a malicious dll by the name “McUtil.dll”.

Inside function sub_403350, a call to InitializeCriticalSection is made to load the dll “McUtil.dll” in memory. In the unpacking process, the malware creates a directory in temp folder and writes evt.exe and McUtil.dll inside it. When evt.exe tries to load McUtil.dll in memory, firstly it checks inside the same folder, if any dll by the same name exists. As in this case, a malicious dll is been named as “McUtil.dll”, the process loads it into its memory.

Loading McUtil.dll

Executing the Malware

Now to test our hypothesis, lets run the malware in protected environment. As we had seen in the disassembled code, the malware unpacks itself with in a folder inside the temp directory.

Create File

Along with the three files unpacked in the temp directory, the malware also creates several dll files inside SysWOW64 folder.

Create File – DLL

Further the malware starts a separate thread to create a process for evt.exe. Once a separate process is created for evt.exe, the thread is exited.

Load Image

This is how the process tree of our malware sample looks like. Here, interestingly, evt.exe has a child process svchost.exe.

Process Tree

Analysing Registry changes

Analysing the registry values that were added post execution of the malware sample, we could see an Autorun entry added to run evt.exe at start up.

Registry Value Added

Further, there is a shell bag entry with hex code value. Converting the hex code to ascii, we could see the “PlugX” string.

PlugX

Connecting back to home

Analysing the traffic, we could see that the malware sample makes a DNS query for sec[.]asmlbigip[.]com. Since the malware is executed in a simulated environment, the dns query is resolved with a local IP. Further the malware sample sends ICMP packets (pings) to check if the resolved IP is reachable on port 80. In the lab environment, “Destination unreachable (Port unreachable)” response was sent back due to which the malware couldn’t exhibit its full behaviour.

Network Activity

IOCs

322d2c12e2593d317df5491f43d708541d651616ee0758b15bf15801a6b66555

3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe

9242badc81a14205b713180e223eba631477ae963e516bce895809b3122e757

ebcd0a0d92f5efef88196a9ca6e1936cf331d9789f4d8cca6506131fcf921cbf

bb14728459929940d4a7c6fd636177faacc0a23e4f75e526f12259e78a3853e7

sec[.]asmlbigip[.]com

 

Mapping it to MITRE ATT&CK

T1204.002 - User Execution: Malicious File

T1055.001 - Process Injection: Dynamic-link Library Injection

T1543.003 - Create or Modify System Process: Windows Service

T1036.003 - Masquerading: Rename System Utilities

T1036.005 - Masquerading: Match Legitimate Name or Location

T1112 - Modify Registry

T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder

T1071.004 - Application Layer Protocol: DNS

T1071.001 - Application Layer Protocol: Web Protocols