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
Comments
Post a Comment