An Analysis of PlugX

There are a number of articles recently written about a Remote Access Trojan called PlugX  or Korplug (with older variants known as Sogu, Thoper, TVT, or Destory RAT ) which has recently seen increasing use in targeted attacks. These articles

• suggest an identity of the author of the trojan
• suggest that this project has seen continued development
• and describe some capabilities of this malware

This article is our contribution to the publicly available knowledge about:

• development of this RAT
• the design  and function  of the malware itself,
• and the C&C protocols  and infrastructure  which have been used to control infected hosts.

INSIGHTS ON PLUGX DEVELOPMENT

Other blogs have offered some insight into the development  of this project , and we would like to extend their findings.

THE DEMO MESSAGE

The malware has a special demo message inside:

This message could be shown in two procedures:

1. An installation procedure - when the malware copies its files and registers them in the registry (for autorun or as a service)
2. A procedure for creating a new pipe - it creates a named pipe to communicate with other instances of the malware that work in the same system. The malware uses this functionality to start the processes of its instances as different users.

By default (in a default constructor) a variable ‘is_demo_version’ is set as 1, but it could easily be changed by loading new settings (from a file or from the Internet).

Probably, the author intended to use this option to protect the malware from theft during demonstrations. Also, it is obvious that after unpacking the malware, it is very easy to change this option. One can infer that the people for whom this malware was demonstrated probably weren’t malware developers, as this appears to be a very simple protection.

THE LOGGING

This malicious program is a rather complex software project. We analyzed several samples, and some of them (probably older ones) have a logging function:

plugx_log(source_name, line_number, message_id)

We analyzed the parameters of this function and determined that the source code of this malware project consists of at least 35 different cpp files, most seeming to have more than 200 lines of code.

Format: file_name estimated_number_of_lines

XBuffer.cpp 252

XPlgLoader.cpp 1087

XPlugService.cpp 505

XPlug.cpp 391

XPlugShell.cpp 603

XHide.cpp 416

XPlugTelnet.cpp 623

XPlugRegedit.cpp 719

XSetting.cpp 645

XPlugDisk.cpp 966

XPlugOption.cpp 229

XPlugPortMap.cpp 237

XJoin.cpp 820

XInstallUAC.cpp 181

XSo.cpp 174

XSoUdp.cpp 206

XDList.cpp 101

XException.cpp 39

XInstall.cpp 451

XSessionImpersonate.cpp 432

dllmain.cpp 56

XOnline.cpp 1184

XThreadManager.cpp 122

XBase64.cpp 36

XPlugSQL.cpp 480

XPlugKeyLogger.cpp 702

XPlugScreen.cpp 1376

XBoot.cpp 733

XRTL.cpp 1444

XSoTcpHttp.cpp 1061

XPlugNetstat.cpp 492

XPacket.cpp 333

XSoPipe.cpp 240

XPlugNethood.cpp 213

XSoTcp.cpp 502

XPlugProcess.cpp 546

The estimated total number of code lines is ~19,000

Impressive.

DESIGN OF PLUGX

This is a very well-designed, well-written software project; it has modular plugins which, rather than having their own routines for tasks such as external communication, use functionality provided by PlugX internal APIs. This design choice allows plugins or APIs to be updated independently and in a backward-compatible way, without interrupting the execution of the malware or requiring it to be reinstalled. It can also be run in thread-safe and non-thread-safe environments. Care was taken to protect this malware from being easily identified by antivirus software or forensic analysts; at no time is any malicious code on disk in decrypted and decompressed form.

In summary, the project appears to have been developed by a skilled programmer or team of programmers, in an iterative fashion, starting with a clear set of features, which have been expanded and updated over time.

THE PLUGX PLUGINS

This malware comes with 13 default plugins. One of the parameters of plugin initialization appears to be a date. It could be creation date of the plugin, or the date of last modification. These dates range from 2012/01/17 to 2012/03/25, with some dates being the same.

Plugin	Date-like parameter	Functionality supplied
Disk	20120325	create, read, delete files, change env strings, create/write new files from C&C to disk, run .exe/tools
Process	20120204	create, kill, enum processes
Service	20120117	create, change, enum, start, delete services
RegEdit	20120315	create, change, enum, delete registry keys
Netstat	20120215	collect some network usage statistics
Nethood	20120213	enumerate computers and shared resources in the local network
Option	20120128	reboot, logoff, shutdown the system
PortMap	20120325	(the analysis of this component is still in progress)
Screen	20120220	take screenshots
Shell	20120305	create a new cmd.exe process; communicate with it via named pipes; relay input from/output to the C&C connection
Telnet	20120225	create new cmd.exe process with /Q option, turning off echo; communicate with process via sockets; relay input from/output to the C&C connection
SQL	20120323	connect and make queries to a SQL databases
Keylog	20120324	keylogger (writes to file NvSmart.hlp)

PROCESS OF INFECTION

We observe an infection process very similar to  that   described  in other posts:

1. The rarsfx archive
   • drops three files into the temp directory:
     • hkcmd.exe - a benign file with a valid digital signature.
     • hccutils.dll - an auxiliary dll, which has fake exports which are required by hkcmd.exe.
     • hccutils.dll.res - not a PE file, but a base-independent code, which consists of a decryptor and an encrypted malicious image. It also contains encrypted settings.
   • then starts hkcmd.exe

2. During the hkcmd.exe loading process, the Windows loader looks for “hccutils.dll” in the current directory, finds it, and loads the DLL which was dropped by the rarsfx archive. This is sometimes known as a dll-load-order-hijack, where a local DLL supplants a system-supplied library.  

3. hkcmd.exe imports three functions from hccutils.dll:
   • FindResources
   • LoadSTRING
   • LoadSTRINGFromHKCU

4. hccutils.dll (in the dllmain procedure) patches the entry point of the hkcmd.exe image in memory (it hasn’t executed yet). Also, the dllmain has a date check. If the current date is before 2012/01/01, the malware just terminates, as seen in the reconstructed code below:

5. After this code is executed, instead of the original entry point, hkcmd.exe would jump to loadShellCode() function, which loads base-independent code from file hccutils.dll.res:

6. hccutils.dll.res contains an encrypted, compressed image containing the core PlugX payload and its further encrypted settings. In some samples, this image may be wrapped in an additional encryption layer (possibly as AV evasion). After unpacking this extra layer, or if the decryptor doesn’t have an additional layer, it decrypts the image, and decompresses it.

7. It then copies this image, section by section, to new memory and erases the PE header, replacing it with its own header format. (Probably to evade AV software which might attempt to find unknown PEs in memory)

8. Next, it begins to establish persistence:
   • it reads the encrypted settings
   • copies all files in a temporary directory to “%ALLUSERSPROFILE%\<dir_name>” where dir_name is a path specified in the settings.
   • restarts itself with parameters that cause it to install itself in one of several ways, depending on the environment in which it is running.

OPERATION

After the malware has established persistence on a system (copied files and creates itself as service, or added an autorun entry in registry), it tries to establish a network connection with the C&C.

It can communicate with a server using TCP, UDP, or HTTP protocols. It sends broadcast UDP packets to devices on the same subnet as the victim, and listens for a broadcast response, in an attempt to establish connections with other bots in the same local network.

As soon as the connection is established, the C&C is able to:

1. Get machine info - obtain information about a processor and a system
2. Start plugin manager - depending on the request’s option, ask the bot to initialize plugins, send information about plugins, or create a remote shell.
3. Uninstall - delete all bot’s files and registry entries
4. Get plugins info - obtain information about all plugins
5. Send settings - send new settings to the bot
6. Get settings - get current settings from the bot

If the plugin manager (OlProcManager) is started, the C&C is then able to communicate with the chosen plugins.

Below is a generic example of how the C&C interacts with plugins:

UPDATING

The authors took many steps to protect against antivirus software and forensic analysts; at no time during the updating process is any malicious code ever on disk in decrypted and decompressed form. Whenever PlugX attempts to update itself, create another instance of itself, or inject code into a process, it does so by first injecting a block of location-independent code that is used to decrypt and unpack the payload, which is then injected and used to create the new instance, or update an existing plugin.

New plugins are added in 2 stages:

1. deliver the plugin files to an infected host

2. attempt to open the files with name “$x.plg” where $x is number from 0 to 127; if a file successfully opens, then it is loaded to memory, decrypted, decompressed, and initialized as a new plugin

The malware also has download-and-execute functionality through the Disk plugin, allowing it to simply run a new copy of itself, or download and run any tools an operator desires.

ENCRYPTION OF hccutils.dll.res

When it is first dropped, the base-independent code is encrypted and compressed. There may also be an additional encryption layer which wraps the decryptor.

If so, it looks like:

After it unpacks itself (or if the decryptor doesn’t have an additional layer), it looks like:

It then decrypts the image using this algorithm:

It then uses RtlDecompressBuffer to decompress the image.

This scheme: {compress + encrypt / decrypt + decompress} is also used for:

1. sending/receiving data to/from C&C (through the network)
2. sending/receiving data to/from other bots (through named pipes)
3. extracting compressed and encrypted dlls from within the image
4. extracting other compressed and encrypted files from disk

INTERESTING MECHANISMS IN PLUGX - UAC EVASION

The PlugX malware has a UAC (User Account Control)  evasion mechanism. It checks if UAC is enabled, and restarts itself through specific steps:

1. It has a compressed and encrypted dll inside:

2. It unpacks the dll and writes it to a temporary file. The compression and encryption mechanisms are discussed in theencryption section  above.

3. It creates a new process in a suspended state:

“C:\Windows\System32\msiexec.exe UAC”

4. Then it allocates memory in the process and injects the base-independent code there:

This code strongly resembles the code found here:

http://sinowal.com/UAC.cpp

INTERESTING MECHANISMS IN PLUGX - CREATE NEW PROCESS

Besides the usual mechanisms of creating new processes like:

1. CreateProcess
2. CreateService
3. Injecting memory to another process

PlugX also has an interesting method for creating a process though COM interfaces:

When the above code is executed:

service.exe creates a process (if it does not already exist)

"C:\WINDOWS\System32\svchost.exe -k DcomLaunch"

svchost.exe creates a process (if it does not already exist)

“C:\WINDOWS\system32\wbem\wmiprvse.exe -Embedding"

wmiprvse.exe creates a process with a command line specified in a call:

pcreate_copy->Put(L“CommandLine”, 0, &cmd, 0);

C&C INFRASTRUCTURE + ATTACK TIMELINE

Other blogs have done a great job of documenting the C&C of several attackers using older variants of PlugX.

However, there does not appear to be any infrastructure intersection with the attacks we witnessed. The attackers using this C&C infrastructure also focus their efforts in Southeast Asia, primarily targeting technology manufacturers, developers, or organizations that deal with them.

Let’s look at a few of the domains these attackers used in recent campaigns:

ns4.msftncsl.com

ns5.msftncsl.com

ns1.attoo1s.com

msftncsl.com similar to  msftncsi.com

attoo1s.com similar to at-tools.com

These attackers appear to use subdomains which strongly resemble legitimate domains for C&C. Using some passive DNS data, we examined this infrastructure.

1. the second level domains often have only a CNAME record, pointing to the legitimate domain they resemble

msftncsl.com CNAME msftncsi.com

2. or resolve to localhost.

attoo1s.com A 127.0.0.1 

After discovery, the attackers respond by also changing the A record used in the attack to point to 127.0.0.1, or 224.0.0.225. This pattern is also visible in other domains and subdomains used by the same attackers in other attacks.

Using passive DNS data, we can see that ns4.msftncsl.com resolved to 211.48.96.142 by 2012-11-21. It was also  seen resolving to210.116.103.68 shortly thereafter. After 2012-12-21, it was seen resolving to 244.0.0.225, most likely a typo of the224.0.0.225 (the upper end of IP space reserved for multicast traffic) which this infrastructure typically changes A records to point at after discovery. In this time, we observed this domain and IP being used for C&C traffic for two RATs frequently used in targeted attacks (9002 RAT, PlugX).

In the following, we establish a timeline with infrastructure information combined with information extracted from the binaries discussed above.

2009-02-20: hkcmd.exe compiled (0D58E5F4E82539DE38BA7F9B4A8DDA12)

2010-11-22: domain msftncsl.com registered with ENOM, INC:

Contact: msftncsl@hotmail.com
        
Domain name: msftncsl.com

Registrant Contact:
  
  xu wenqiang ()
  
  Fax: 
  anyuan road no 170,putuoqu, shanghai,China
  shanghai, CN 200085
  CN

Administrative Contact:
  
  xu wenqiang (6g8wkx@gmail.com)
  +86.013965128080
  Fax: +86.02167326460
  anyuan road no 170,putuoqu, shanghai,China
  shanghai, CN 200085
  CN

Technical Contact:
  
  xu wenqiang (6g8wkx@gmail.com)
  +86.013965128080
  Fax: +86.02167326460
  anyuan road no 170,putuoqu, shanghai,China
  shanghai, CN 200085
  CN

2010-11-24: first observed lookup for msftncsl.com (CNAME msftncsi.com)

2011-07-01: first observed lookup for update.msftncsl.com A 127.0.0.1

2012-06-09: rarsfx.exe compiled (D5F69A21BCC84E34B0DF9D36EA5891D5)

2012-09-13: hkcmd.exe added to rarsfx archive

2012-09-28: hccutils.dll compiled (55C15EFA6369957C69E7C6643BC86EF2)

2012-11-17: unpacked hccutils.dll.res compiled (93B86D6DFD36CAE603A5EFBE95FA9289)

2012-11-21: hccutils.dll.res added to rarsfx archive

2012-11-22: ns4.msftncsl.com first points to 211.48.96.142

2012-11-24: sample found in the wild

2012-11-30: ns4.msftncsl.com then points to 210.116.103.68

2012-12-04: ns4.msftncsl.com then points to 211.48.96.142

2012-12-21: ns4.msftncsl.com then points to 244.0.0.225

So what can this timeline tell us about the attacker?

It is clear that this is a pattern of behavior, not just a unique attack.

First, consider the fact that the rarsfx archive is created 5-6 months before this attack; next examine the insertion times of the different artifacts within it; each is different, and not just by a few minutes, but by days. This attacker likely used the same rarsfx archive with other payloads before this attack.

It appears that the planning, building, testing, and finally, deployment of these attacks was iterative, planned, and practiced. This attacker has likely engaged in other attacks which follow the same (or at least a similar) pattern. It is clear that different payloads have been swapped in and out of the rarsfx. For example, consider:

https://www.virustotal.com/file/d5f69a21bcc84e34b0df9d36ea5891d5/analysis/

https://www.virustotal.com/file/c48cdf2ce519307358ead3512e31f264/analysis/         

Note that the compile times for the archives, hkcmd.exe, and hccutils.dll (you can verify on the additional information tab of the VT analyses) are the same. Note that the insertion time of hkcmd.exe is the same, and that the others differ.

The two hccutils.dll files were both built at the same time, but are replaced for new attacks. In one sample, hccutils.dll was inserted shortly after building, and in the other, it was swapped just in time for use. One can imagine an attacker building a number of these hccutils.dll files at the same time, for different attacks, and swapping a new one in for each to enhance AV evasion. It seems to work, given the VT reports for each sample.

Also note that the hccutils.dll.res is swapped in shortly before use as well; given the model of PlugX, this makes sense. An attacker who uses this same dll-hijacking mechanism in multiple attacks would likely use the same hijacking dll with several different PlugX-payload resources before changing out the dll for a new one with a slightly different packing.

rarsfx.exe (Sat Jun 09 17:19:49 2012) d5f69a21bcc84e34b0df9d36ea5891d5

1. hkcmd.exe (Fri Feb 20 23:31:55 2009) 0d58e5f4e82539de38ba7f9b4a8dda12
2. hccutils.dll (Fri Sep 28 07:13:51 2012) 55c15efa6369957c69e7c6643bc86ef2
3. hccutils.dll.res 3aa819b9089cd906d6434e446bea75ba
4. hccutils.dll.res.unp (Wed Oct 17 12:34:30 2012) 93b86d6dfd36cae603a5efbe95fa9289

rarsfx.exe (Sat Jun 09 17:19:49 2012) c48cdf2ce519307358ead3512e31f264

1. hkcmd.exe (Fri Feb 20 23:31:55 2009) 0d58e5f4e82539de38ba7f9b4a8dda12
2. hccutils.dll (Fri Sep 28 07:13:51 2012) 58c11dd3a9f257869bc362c7a5bc85f1
3. hccutils.dll.res 824ee49166f2cfb45c573434fb588dde

DECODING THE C&C COMMUNICATION OF PLUGX

The communication done by PlugX is encrypted in two stages: to perform the first stage, the malware uses this routine:

# Python implementation:

def decrypt(key, src, size):
    key0 = key
    key1 = key
    key2 = key
    key3 = key
    dst = b''
    i = 0
    if size > 0:
        while i < size:
            key0 = (key0 + (((key0 >> 3)&0xFFFFFFFF) - 0x11111111)&0xFFFFFFFF)&0xFFFFFFFF
            key1 = (key1 + (((key1 >> 5)&0xFFFFFFFF) - 0x22222222)&0xFFFFFFFF)&0xFFFFFFFF
            key2 = (key2 + (0x44444444 - ((key2 << 9)&0xFFFFFFFF))&0xFFFFFFFF)&0xFFFFFFFF
            key3 = (key3 + (0x33333333 - ((key3 << 7)&0xFFFFFFFF))&0xFFFFFFFF)&0xFFFFFFFF
            new_key = (((key2&0xFF) + (key3&0xFF) + (key1&0xFF) + (key0&0xFF))&0xFF)
            res = unpack("<B", src[i:i+1])[0] ^ new_key
            dst += pack("<B", res)
            i = i + 1
    return dst

using the first four bytes from a given TCP data as the key:

After the first round of decryption (see below), there is a header which includes:

1. a flag to indicate which plugin the traffic is for
2. the size of the compressed data to follow
3. the size of the decompressed data
4. the status of the operation

Then you may decrypt the body, using the same key as for the header:

And finally, you decompress the body, using the parameters from the header:

Since the keys are in every packet, and we have managed to decrypt and decompress the payload, all that is left is to identify the flags for routing communication to each component of the malware. We have already identified several flags:

    GET_MACHINE_INFO_FLAG = 0x1 #returns machine name and identifier

    START_PLUGIN_MGR_FLAG = 0x3 #select and enable plugins

    INSTALL_NEW_COPY_FLAG = 0x5 #install itself again

    SEND_NEW_SETTINGS_FLAG = 0x6 #send bot new settings

    SAVE_SETTINGS_TO_FILE_FLAG = 0x7 #save current settings to file

    SEND_PLUGINS_INFO_FLAG = 0x8 #send C&C info about plugins

For the time being, the tool to do completely decode C&C traffic is still in development, but we have prepared a sample script  to decrypt and decompress payloads, and identify some flags.