First identified in 2012, PlugX is a Remote Access Trojan (RAT) known to be used against high profile government institutions and other organizations. PlugX has evolved and has also been seen as Korplug, SOGU and DestroyRAT. The primary functionality of the malware is to:
- Provide persistence access for adversaries.
- Perform surveillance of the infected machines.
- Reach out to a command and control server.
- Hijack legitimate executables and inject malicious code.
Since PlugX was first identified in 2012, it has mutated in complexity and exploitation techniques. With capabilities to impersonate authentic processes and perform extensive recon on infected machines, it’s no surprise that PlugX is common to be used in advanced targeted attacked. However, the core functionality has remained the same through the malware’s evolution. TLDR: This blog post reviews a high-level analysis of a recently discovered PlugX malware sample.
Diagnosing a PlugX Infection – Analysis Environment
The malware being analyzed in this blog posted was discovered while responding to an incident involving a compromised web server from an academic institution. The attackers used a folder named /temp/ located at the root directory of the compromised machines to store the PlugX malware. The primary Windows executables that we analyzed were named p.exe and karksy.exe. They are both executable files that were extracted from the infected host. Karsky.exe’s name and process image closely resemble Kaspersky, a commercial Russian Anti-Virus Suite. The executable’s description and meta data also are the same as Kaspersky. However, it was anticipated that p.exe manipulated the Karsky executable.
When reviewing the results of a VirusTotal analysis scan, the general consensus among most scanners was that p.exe was a trojan or a backdoor. A few scanners were more specific in recognizing p.exe as Korplug or PlugX malware. This malware acts as a backdoor able to take screenshots, record keystrokes, and exfiltrate data from the infected host.
The infected environment was recreated as best as possible. The compromised machine was running Windows Server 2008. We replicated the machines using VirtualBox with the following criteria below:
- Kali Linux (192.168.1.1)
- INetSim – Intercepted all traffic on the network for analysis
- Wireshark – Allowed packet capture for analysis
- Windows Server 2008 (192.168.1.10; Kali Linux was set as gateway)
- Windows Sysinternals Suite (Process Monitor, Process Explorer)
- Memory Capture Tools
Strings and FLOSS – Initial Static Analysis
Static analysis is the process of analyzing malware without actually running it. Similarly to an autopsy, static analysis can provide insight on the previous events and how damaging they were.
Analyzing the strings of an executable can be a simple way to gain insight about the functionality of a program. FLOSS is a tool that uses advanced static analysis techniques to automatically remove any attempts to obfuscate strings from malware binaries. The Floss analysis of p.exe revealed strings relating to both file and registry manipulation.
One area of interest are the decoded strings from Floss’ output. “GETPASSWORD1” appears to be a variable the programmer wrote, as it is not in the traditional naming structure as seen in functions parsed from Dynamic Linked Libraries (dlls). “REPLACE” & “RENAMEDLG” are also decoded strings that may be used when the malware is executed. More interactions with WinRAR were also seen. SFX is a self-extraction tool which hints that the malware unpacked or extracting more files once it is in-place on the network.
Finally, several dlls are seen in the strings hinting that they may be called or used by the malware. Their functionality includes interaction with users, files, and connections to the network. This list includes:
- Riched20 & 32.dll
After research of the individual strings as well as the possible interaction of the strings among each other, it supports the hypothesized theory that the malware is a member of the PlugX / Korplug family of malware. Common strings between the p.exe and the PlugX malware include the GETPASSWORD1 and the usage of WinRAR SFX commands. Common DLLS were also seen such as Ole32.dll and riched20.dll and riched32.dll.
Understanding the Functionality – Reverse Engineering the Disassembly
Without access to the source code, disassembling binaries is necessary to learn more about a program’s purpose. Disassembly code can provide a glimpse into a hostile program and help determine what it is doing, at least on a surface level.
The general processes used was to investigate interesting strings and functions found previously and to gather more information by investigating the context in which they were used. GETPASSWORD1 is a common string found in this family of malware and does not match any functions imported by the various dlls seen in the disassembly. This function appears to be called after checking for a visible window and then pulling the dialog parameters from the open dialog box seen in the image below. GETPASSWORD1 pulls the DlgItemTextW storing whatever variable is entered into the referenced dialog control box.
Shortly after GETPASSWORD1 is called, another interesting and common string among the malware “AskNextVol1” is called. Similar to GETPASSWORD1, the command is loaded into memory and then executed to pull strings from the Dialog Item Text. Again, this may be used to steal user credentials or to get information about running processes that have fields a user is interacting with. This can be seen in the image below and looks similar to the GETPASSWORD1 function.
The program can then be seen using InitCommonControlsEx and SHGetMalloc to retrieve access to Malloc interfaces. InitCommonControlsEx ensures comctl32.dll is loaded and then calls SHGetMalloc, which enables the usage of IMalloc; a command generally used for allocation and management of process memory. Whenever investigating malware, allocation of memory is generally regarded as a red flag due to the program’s ability to launch and hide malicious processes.
Another interesting function is the usage of Ole32.dll to utilize SFX to unpack karsky.exe using the WinRar SFX tools. In the below function, it can be seen that the dll is initialized, calls a command line argument, and moves SetEnviornmentVariableW to memory before ultimately creating a file “winrarsfxmappingfile.tmp”.
After the temporary file is created, the file continues to utilize several functions that are believed to be building karsky.exe. Functions “GetModuleFileName”, “GetModuleHandleW”, “LoadIcon” and “LoadBitmapW” all called before calling sub_41280F, as seen below (renamed to LoadRiched).
The usage of the riched32.dll and riched20.dll are common and used by the malware when Sub_41280F is called. These dlls are normally used by Rich Text Edit and allows for the editing of the registry. Its usage can be seen below as it is called into memory within the named subroutine “LoadRiched32”. The two dlls are loaded into memory and then used to access the InitCommonControlsEx. This allows access to ppMalloc and SHGetMalloc to be called which can be utilized to allocate space for a new program in memory.
Once the process has allocated space in memory thanks to ppMalloc, several other smaller sub-routines are called in order to ensure the proper files are located for installation. The function “STARTDLG” is called and its execution results in execution of the WinRAR SFX, just with karsky instead of Kaspersky. These functions can be seen in part 2 of the process creation function below.
After this execution completes, Ole32.dll is uninitialized and the process is exited.
An analysis of decompiled code confirms the malware is attempting to blend in as Kaspersky by creating and calling modified .dll files that are seen in the legitimate Kaspersky program. As mentioned above, there are several dlls and functions called that mimic Kaspersky’s legitimate calls. One of the first subroutines found calls the dll files unpacked by the malware, ushata.dll. Ushata.dll is significant as it is used by Kasperky for installation and ensuring the legitimate program has the files required.
Traversing further down this subroutine, another dll used by Kaspersky is seen being used maliciously. Avpinit.dll is referenced and has a similar process of pushing it into memory after capturing metadata using sub_401510. This is repeated again with multiple other dlls relating to Kaspersky.
Finally, as seen below, the malware gets a process address. It then runs “Initialize”, and gets the process’s address. Then, the program makes a call to “Inithooks” and calls the process address again. This appears to be where the malware is hooking the dll files.
In summary, the malware appears to be modifying the dll files and then replacing the legitimate versions. This allows the malware to gain persistence, access to the user’s environment, as well as networking functionality.
An example of network activity used by the malware can be see when following the “FilterConnectionCommunicationPort” and “FilterSendMessage” functions. This “creates a communication server port on which a minifilter driver can receive connection requests from user-mode applications” as per Microsoft. The functions in action can be seen below:
Ushata.dll is a dll file found normally within the installation folder of Kaspersky Anti-Virus. When opening the dll in IDA Pro, it was found that the dll may have been modified to be used by the malware to install karsky as well as create and read from a file karsky.kvp. Overall, the dll is a smaller file.
Once copied, the dll creates a file and allocates space within the heap. Once the file is in place, the file is read from. The dll then sleeps and returns again to the beginning of the function. It is likely this dll is ensuring that the file is there and may be used as a form of persistence.
Executing the Malware – Dynamic Analysis
Running the malware in the test environment confirmed the hypothesis of the malware being a backdoor trojan that belonged in the PlugX malware family. Upon running the p.exe file with administrator privileges, several things happened. Overall, the malware performed several actions including:
- Making changes to the Registry
- Achieving persistency
- Reached out to networking addresses assumed to be a C2 server
- Created, Compared, and parsed from user files and System32 files
Like other strains of the PlugX family, it made changes to the registry and attempted to install several files and persistence methods. It did so utilizing several .dll files seen earlier within the static analysis. Their calls for the first time can be seen below
The p.exe file also attempted to install and run karsky.exe. Karsky is not a legitimate program and has a process icon similar to Kaspersky Anti-Virus. This is likely the program attempting to blend in among the processes. Karsky.exe created with the RasTls directory and read from them as seen below:
With files in place, karsky.exe also created a directory to be used later. The file path and actions that took place can be seen below:
Contacting Home – Stuck in a Loop
Generally malware will reach out to a command and control server (C2) to either receive more commands or exfiltrate data. Capturing the network packets while malware runs enables analysts to inspect the traffic coming and going from the infected machines.
When the malware executed on the Windows 2008 server, the Kali linux machine captured the network traffic using Wireshark and provided spoofed website responses to the malware. Analyzing the Wireshark packet capture file revealed that the malware was looping through its actions as seen in Process Monitor. It is likely that because it could not access the C2 server, it was repeating the process until it could. The malware was repeatedly sending ICMP request and QUIC TCP traffic.
The malware continuously changed registry keys and would attempt to contact the C2. It is hypothesized the C2 server would allow for commands to be sent to any of the executables loaded during the execution of p.exe and that the malware had established a back door onto the infected host.
Due to this malware still actively infecting machines in the wild, the connection to the C2 was not allowed to connect to the true host. In turn, this crippled PlugX actions and the dynamic analysis ended at this point.
Process Hollowing – Hijacking Svchost.exe
Malware leverages code injection to force a legitimate process to perform actions on its behalf. Hollow process injection is a code injection technique that occurs when malware starts a new instance of a legitimate process with malicious code that replaces some or all of the legitimate executable section of code. When p.exe was executed, a new instance of the Service Host process (svchost.exe) with injected code is launched. Hollow process injection can be located by analyzing the Random Access Memory (RAM) of the infected computer.
When reviewing the processes that were running in memory, an instance of svchost.exe with the process ID (PID) of 2444 had a child process of msiexec.exe. Msiexec is used for installing programs and was not expected to be running in this environment. The Volatility Framework plugin Malfind indicated that the Svchost instance with the PID of 2444 may have been victim to process hollowing.
To determine if this was indeed process hollowing, the Virtual Address Descriptors at the process memory address 0x57000 were compared for all the Svchost process on the machine. The legitimate Svchost processes had the file object loc2008.nls loaded into memory with the protection “Page Read Only”. However, for the Svchost process with the PID of 2444, this file objected was wiped from memory. This area was given the protection rights of “Page Execute Read Write”, meaning that code here could be executed and written to.
Using the Volatility Malfind plugin, this suspected malicious segment of memory was dumped for further analysis. As anticipated, binwalk determined that this segment of process memory contained a Windows executable.
Strings analysis of this segment revealed more PlugX configuration (such as the command and control server address) as well as some of the the malwares comprehensive functionality.
It’s apparent that PlugX is using Windows APIs to monitor the infected machine, manipulate processes and to communicate with its command and control server. Some of the more noticeable strings such as “ImpersonateLoggedOnUser”, “mouse_event”, “keybd_event” and “GetUserNameW” confirms that the PlugX malware is performing heavy surveillance on the infected host machine.
Ensuring Persistent Access
Malware becomes stealthier by achieving persistence on exploited machines. Persistent access ensures that malware will continue to act as intended even after restarts, reboots and log-offs. Modifying registry keys to manipulate the Windows operating system is a common technical malware uses to ensure its access on the system.
This malware achieved persistence by creating and editing registry keys that allowed it start itself upon the restart of the host as well as if the process was killed. This ensured that the malware would continue to communicate with its C2 server and and that it could continue operating. Viewing the registry key “ControlSet001\Services\RasTls” showed the primary registry key PlugX created.
Although the PlugX malware has a vast variety of functionality, due diligence security and threat modeling can limit the potential damages from this malware. If your organization suspects they are victims of a compromise, contact us and we would be more than happy to help.