Threat Spotlight: Group 72, Opening the ZxShell

Recently, there was a blog post on the takedown of a botnet used by threat actor group known as Group 72 and their involvement in Operation SMN. This group is sophisticated, well funded, and exclusively targets high profile organizations with high value intellectual property in the manufacturing, industrial, aerospace, defense, and media sector. The primary attack vectors are watering-hole, spear phishing, and other web-based attacks.

Frequently, a remote administration tool (RAT) is used to maintain persistence within a victim’s organization. These tools are used to further compromise the organization by attacking other hosts inside the targets network.

ZxShell (aka Sensocode) is a Remote Administration Tool (RAT) used by Group 72 to conduct cyber-espionage operations. Once the RAT is installed on the host it will be used to administer the client, exfiltrate data, or leverage the client as a pivot to attack an organization’s internal infrastructure. Here is a short list of the types of tools included with ZxShell:

Keylogger (used to capture passwords and other interesting data)

Command line shell for remote administration

Remote desktop

Various network attack tools used to fingerprint and compromise other hosts on the network

Local user account creation tools

For a complete list of tools please see the MainConnectionIo section.

The following paper is a technical analysis on the functionality of ZxShell. The analysts involved were able to identify command and control (C2) servers, dropper and installation methods, means of persistence, and identify the attack tools that are core to the RAT’s purpose. In addition, the researchers used their analysis to provide detection coverage for Snort, Fireamp, and ClamAV.

Background

ZxShell has been around since 2004. There are a lot of versions available in the underground market. We have analyzed the most common version of ZxShell, version 3.10. There are newer versions, up to version 3.39 as of October 2014.

Distribution and Delivery

An individual who goes by the name LZX in some online forums is believed to be the original author of ZxShell. Since ZxShell has been around since at least 2004, numerous people have purchased or obtained the tools necessary to set up ZxShell command and control servers (C&C) and generate the malware that is placed on the victim’s network. ZxShell has been observed to be distributed through phishing attacks, dropped by exploits that leverage vulnerabilities such as CVE-2011-2462, CVE-2013-3163, and CVE-2014-0322.

Analysis of the Main ZxShell Module

To illustrate the functionality of main ZxShell module, Let’s take a look at the following sample:

It exports the following functions, which are examined in greater detail below:

DllMain

Install

UnInstall

ServiceMain

ShellMain

ShellMainThread

zxFunction001

zxFunction002

DllMain

DllMain performs the initialization of ZxShell. It allocates a buffer of 0x2800 bytes and copies the code for the ZxGetLibAndProcAddr function. To copy memory, the memcpy function is invoked. It is not directly used from msvcrt.dll but is instead copied to another memory chunk before being called. Finally, the trojan Import Address Table (IAT) is resolved and the file path of the process that hosts the dll is resolved and saved in a global variable.

Install

ZxShell.dll is injected in a shared SVCHOST process. The Svchost group registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost is opened and the netsvc group value data is queried to generate a name for the service.

Before the malware can be installed a unique name must to be generated for the service. The malware accomplishes this through querying the netsvc group value data located in the svchost group registry key which is HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost.

At startup, Svchost.exe checks the services part of the registry and constructs a list of services to load. Each Svchost session can contain multiple shared services that are organized in groups. Therefore, separate services can run, depending on how and where Svchost.exe is started.

Image 1. Svchost Groups registry key

Svchost.exe groups are identified in the above registry key. Each value under this key represents a separate Svchost group and appears as a separate instance when you are viewing active processes. Each value is a REG_MULTI_SZ value and contains the services that run under that Svchost group. Each Svchost group can contain one or more service names that are extracted from the following registry key, whose Parameters key contains a ServiceDLL value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Service

On a Windows machine, the netsvc group contains names of both existing and non-existing services. ZxShell exploits this fact by cycling between each of the names, verifying the existence of the real service. The service’s existence is verified with the ServiceExists function, which attempts to open the relative registry sub-key in HKLM\SYSTEM\CurrentControlSet\Services. The first service name that is not installed on the system becomes the ZxShell service name.

A new service is then created using the service parser function ProcessScCommand. ZxShell implemented its own version of the Windows SC command. There are minor differences between the ZxShell implementation of this command and the original Windows one, but they are irrelevant for the purpose of the analysis The command used to install the service is:

The installed service registry key is opened and the 2 values under its Parameter subkey are created. These 2 values, ServiceDll and ServiceDllUnloadOnStop are needed for services that run in a shared process.

Before the service is started ChangeServiceConfig is called to modify the service type to shared and interactive. If the service fails to start then a random service name formatted as netsvc_xxxxxxxx, where xxxxxxxx represent an 8-digit random hex value, is added to the netsvc group and the entire function is repeated.

ServiceMain

This function is the entry point of the service. It registers the service using the RegisterServiceCtrlHandler Windows API function. The ZxShell service handler routine is only a stub: it responds to each service request code, doing nothing, and finally exits. It sets the service status to RUNNING and finally calls the ShellMain function of ZxShell.

ShellMain

The ShellMain function is a stub that relocates the DLL to another buffer and spawns a thread that starts from ShellMainThreadInt at offset +0xC0CD. The ShellMainThreadInt function gets the HeapDestroy Windows API address and replaces the first 3 bytes with the RET 4 opcode. Subsequently, it calls the FreeLibrary function to free its own DLL buffer located at its original address. Because of this, the allocated heaps will not be freed. It re-copies the DLL from the new buffer to the original one using the memcpy function. Finally, it spawns the main thread that starts at the original location of ShellMainThread procedure, and terminates. At this point, the ZxShell library is no longer linked in the module list of the host process. This is important because if any system tool tries to open the host process it will never display the ZxShell DLL.

ShellMainThread

This thread implements the main code, responsible for the entire botnet DLL.
First, it checks if the DLL is executed as a service. If so, it spawns the service watchdog thread. The watchdog thread checks the registry path of the ZxShell service every 2 seconds, to verify that it hasn’t been modified. If a user or an application modifies the ZxShell service registry key, the code restores the original infected service key and values.

Image 3. The watchdog thread of ZxShell service

The buffer containing the ZxShell Dll in the new location is freed using the VirtualFree API function. A handle to the DLL file is taken in order to make its deletion more difficult. The ZxShell mutex is created named @_ZXSHELL_@.

ZxShell plugins are parsed and loaded with the AnalyseAndLoadPlugins function. The plugin registry key HKLM\SYSTEM\CurrentControlSet\Control\zxplug is opened and each value is queried. The registry value contains the plugin file name. The target file is loaded using the LoadLibrary API function, and the address of the exported function zxMain is obtained with GetProcAddress.

If the target filename is incorrect or invalid the plugin file is deleted and the registry value is erased. That is performed by the function DeleteAndLogPlugin. Otherwise, the plugin is added to an internal list. Here is the data structure used to keep track of the plugins:

The thread KeyloggerThread is spawned and is responsible for doing keylogging on the target workstation. We will take a look at the keylogger later on. Finally the main network communication function GetIpListAndConnect is called.

GetIpListAndConnect

This function is at the core of the RAT’s network communication. It starts by initializing a random number generator and reading 100 bytes inside the ZxShell Dll at a hardcoded location. These bytes are XOR encrypted with the byte-key 0x85 and contains a list of remote hosts where to connect. The data is decrypted, the remote host list is parsed and verified using the BuildTargetIpListStruct function. There are 3 types of lists recognized by ZxShell: plain ip addresses, HTTP and FTP addresses.
If the list does not contain any item, or if the verification has failed, the ZxShell sample tries to connect to a hardcoded host with the goal of retrieving a new updated list.

Otherwise, ZxShell tries to connect to the first item of the list. If ZxShell successfully connects to the remote host, the function DoHandshake is called. This function implements the initial handshake which consists of exchanging 16 bytes, 0x00001985 and 0x00000425, with the server. The function GetLocalPcDescrStr is used to compose a large string that contains system information of the target workstation. That information is the following:

local hostname

organization

owner

operating system details

CPU speed

total physical memory

The string is sent to the remote host and the response is checked to see if the first byte of the response is 0xF4, an arbitrary byte. If it is, the botnet connection I/O procedure is called through the MainConnectionIo function.

Image 4. The GetLocalPcDescrStr and DoHandshake functions called beforestarting the command processing

Otherwise, the ZxShell code closes the socket used and sleeps for 30 seconds. It will then retry the connection with the next remote host, if there is one.

It is noteworthy that this function includes the code to set the ZxShell node as a server: if one of the hardcoded boolean value is set to 1, a listening socket is created. The code waits for an incoming connection. When the connection is established a new thread is spawned that starts with the MainConnectionIo function.

MainConnectionIo

The MainConnectionIo function checks if the Windows Firewall is enabled, sets the Tcp Keep Alive value and Non-blocking mode connection options and receives data from the remote host through the ReceiveCommandData function. If the communication fails, ZxShell disables the firewall by modifying the registry key:

Then the connection is retried. The received command is then processed by the ZxShell function with the ProcessCommand function.

The command processing function starts by substituting the main module name and path in the hosting process PEB, with the one of the default internet browser. The path of the main browser of the workstation is obtained by reading the registry value:

This trick renders identification by firewall more cumbersome. A host firewall will recognize the outgoing connection as originated by the browser instead of the ZxShell service host process. The browser process always performs outgoing connections and the firewall shouldn’t block them.

The command processing is straightforward. Here is the list of common commands:

COMMAND

MEANING

Help / ?

Get help

Exit / Quit

Exit and shut down the botnet client

SysInfo

Get target System information

SYNFlood

Perform a SYN attack on a host

Ps

Process service Unix command implementation

CleanEvent

Clear System Event log

FindPass

Find login account password

FileTime

Get time information about a file

FindDialPass

List all the dial-up accounts and passwords

User

Account Management System

TransFile

Transfer file in or from remote host

Execute

Run a program in the remote host

SC

Service control command, implemented as the Windows one

CA

Clone user account

RunAs

Create new process as another User or Process context.

TermSvc

Terminal service configuration (working on Win Xp/2003)

GetCMD

Remote Shell

Shutdown

Logout, shutdown or restart the target system

ZXARPS

Spoofing, redirection, packet capture

ZXNC

Run ZXNC v1.1 – a simple telnet client

ZXHttpProxy

Run a HTTP proxy server on the workstation

ZXSockProxy

Run a Sock 4 & 5 Proxy server

ZXHttpServer

Run a custom HTTP server

PortScan

Run TCP Port MultiScanner v1.0

KeyLog

Capture or record the remote computer’s keystrokes. The implementation is a userland keylogger that polls the keymap with each keystroke.

LoadDll

Load a DLL into the specified process

End

Terminate ZxShell DLL

Uninstall

Uninstall and terminate ZxShell bot DLL

ShareShell

Share a shell to other

CloseFW

Switch off Windows Firewall

FileMG

File Manager

winvnc

Remote Desktop

rPortMap

Port Forwarding

capsrv

Video Device Spying

zxplug

Add and load a ZxShell custom plugin

This set of functionality allows the operator complete control of a system. Being able to transfer and execute files on the infected system means the attacker can run any code they please. Further, the keylogging and remote desktop functionality allows the operator to spy on the infected machine, observing all keystrokes and viewing all user actions.

Uninstall

Unloads ZxShell and deletes all of the active components. This simply deletes the ZxShell service key from the Windows registry (using SHDeleteKey Api) and all of the subkeys. Finally, it marks ZxShell main Dll for deletion with the MoveFileEx Windows API.

ZxFunction001

This function is the supporting functionality for WinVNC. To allow the VNC session to connect, the current network socket WSAProtcol_Info structure is written to a named pipe prior to calling zxFunction001. Once the named pipe has been created, CreateProcessAsUserA is called with the following as the CommandLine parameter :

The functionality (connect or bind) depends on the data contained within the named pipe. Unlike zxFunction001, this is not used by any of the RAT commands in the zxshell.dll.

Kernel Device Driver LoveUSD

Apart from user-mode ZxShell droppers mentioned earlier, there is a file (SHA256: 1e200d0d3de360d9c32e30d4c98f07e100f6260a86a817943a8fb06995c15335) that installs a kernel device driver called loveusd.sys. The architecture of this dropper is different from the others: it starts extracting the main driver from itself. It adds the SeLoadDriver privilege to its access token and proceeds to install the driver as a fake disk filter driver. ZxShell opens the registry key that describes the disk class drivers:

It then adds the “Loveusd.sys” extracted driver name to the upper filter list. In our analysed sample the “Loveusd.sys” driver is installed with the name “USBHPMS”. Finally the driver is started using the ZwLoadDriver native API.

The ZxShell driver starts by acquiring some kernel information and then hooking “ObReferenceObjectByHandle” API. Finally it spawns 2 system threads.

The first thread is the “communication” thread. ZxShell employs a strange method for communication: it hooks the NtWriteFile API and recognizes 5 different special handle values as commands:

0x88888888 – Set a special value called “type” in Windows registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverMain

The second Loveusd system thread does a lot of things. Its principal duties are to create the ZxShell main DLL in “c:\Windows\System32\commhlp32.dll” and to install the Kernel “Load Image Notify routine”. The code then tries to kill each process and service that belongs to the following list of AV products:

The installation procedure continues in the user-mode dropper. The ZxShell service is installed as usual, and the in-execution dropper is deleted permanently using the special handle value 0x22222222 for the WriteFile API call. This handle value is invalid: all the windows kernel handle values are by design a multiple of 4. The ZxShell hook code knows that and intercept it.

ObReferenceObjectByHandle is a Kernel routine designed to validate a target object and return the pointer to its object body (and even its handle information), starting from the object handle (even the user-mode one). The hook installed by ZxShell implements one of its filtering routine. It filters each attempt to open the ZxShell protected driver or the main DLL, returning a reference to the “netstat.exe” file. The protection is enabled to all processes except for ones in the following list: Svchost.exe, Lsass.exe, Winlogon.exe, Services.exe, Csrss.exe, ctfmon.exe, Rundll32.exe, mpnotify.exe, update.exe.

If the type of the object that the system is trying to validate is a process, the hook code rewrites again the configuration data of the ZxShell service in the windows registry.

The last type of Kernel modification that ZxShell rootkit performs is the system call dispatcher (KiFastCallEntry) hook. In this manner, ZxShell is able to completely hide itself, intercepting the following Kernel API calls: ZwAllocateVirtualMemory, ZwOpenEvent, ZwQueryDirectoryFile, ZwWriteFile, ZwEnumerateKey, and ZwDeviceIoControlFile.

Command and Control Server

Sample (SHA256: 1eda7e556181e46ba6e36f1a6bfe18ff5566f9d5e51c53b41d08f9459342e26c) is configured to act as a server. The symbol “g_bCreateListenSck” is set to 1. This means that, as seen above, the ZxShell Dll is started in listening mode. It connects to the first remote C&C that tries to contact it and succeeds in the handshake. The encrypted IP address is “127.0.0.2” (used as loopback) and no connection is made on that IP address (due to the listening variable set to 1).

Malware Package

We used the ZxShell package for version 3.10 (SHA256: 1622460afbc8a255141256cb77af61c670ec21291df8fe0989c37852b59422b4).The convenient thing about this is that the CNC panel worked with any version, 3.10 and above. The buttons are all in Chinese, with the help of Google Translate and keen detective skills (read: button clicking), we’ve deciphered the functionality.

When you start the controller, you need to set the port you want to listen on and if you’ve set a password, add it here.

Once an infected machine connects, you see its information displayed in a selection box at the top. There are some built in functions on the side for the more common features. These include remote desktop, webcam spying, remote shell, and file management. You can also select a host and type help for a full list of commands.

I have the same machine infected with two different version of ZxShell. Sending the help command for each, you can see the extra features added between version 3.1 and 3.2.

Keylogging, ZXARPS (IP and URL spoofing), and SYNFlood are some of the interesting features added to version 3.2.

Version Information

We wrote a script to extract version info from the binaries we have.

3.100 : 914

3.200 : 152

3.210 : 118

3.220 : 14

3.390 : 3

In versions 3.1 – 3.21, the configuration info is xor encoded with 0x85. This configuration info can be changed with a tool included in the ZxShell package.

In versions 3.22 and 3.39 the routine changes. The new xor encoding byte is 0x5B. The data is stored in the last 0x100 bytes of the file. The first 8 bytes of data are static. Then there is the dll install name, the domain, and the port.

Extracted URL Analysis

Knowing the obfuscation routines for this data we wrote a script to extract the URLs / IPs and ports stored.

The most common ports used are, 80, 1985, 1986, and 443. 1985 is the default port for the malware, 1986 is the lazy variation of that port. Port 80 and 443 are the default ports for HTTP and HTTPS traffic. The next most common is port 53. This is used in some of the newer 3.22 and 3.39 samples. After that, the count for each port starts declining sharply. The choices are interesting though, many correspond to what looks like the birth year of the controller (ie. years in the late 1980s and early 1990s), and others seem to match what year the malware was launched in (ie. in the 2000s, relatively close to the current year).

Since this malware dates back to around 2004, there are many samples containing CNC URLs from the 3322.org page. This page used to offer no-ip type hosting and was widely used by malware authors. So much so that Microsoft did a takedown in 2012. A similar service, vicp.net, is also seen in many of the domains.

In the malware, if a domain is configured, it will retrieve domain.tld/myip.txt. This file contains a list of IP addresses for the infected machine to connect back to. Otherwise, if an IP address is configured, it will connect directly to that IP address.

Cloning the ZxShell Server

We have written a simple C++ ZxShell Server that implements the communication and the handshake for the version 3.10 and 3.20 of the ZxShell DLL. The implementation is quite simple: After the handshake, 2 threads that deal with data transfer are spawned. Here we have some screenshots that show the Server and the ZxShell Keylogger in action:

Our server has accepted a connection from a remote host

The ZxShell keylogger has captured 2 user passwords(gmail.com and amazon.com)

The last image shows a very interesting feature of the ZxShell keylogger: once installed and activated, the keylogger is able to catch each password that the user inserts in the login box of each website (like Google, Amazon and so on…). This makes the keylogger a perfect weapons for the attackers. They will be able to steal and resell in the underground market the sensitive data of each victim.

Conclusion

Advanced persistent threats will remain a problem for companies and organizations of all sizes, especially those with high financial or intellectual property value. Group 72’s involvement in Operation SMN is another example of what sort of damage that can be done if organizations are not diligent in their efforts to secure their networks. ZxShell is one sample amongst several tools that Group 72 used within their campaign.

ZxShell is a sophisticated tool employed by Group 72 that contains all kinds of functionality. Its detection and removal can be difficult due to the various techniques used to conceal its presence, such as disabling the host anti-virus, masking its installation on a system with a valid service name, and by masking outbound traffic as originating from a web browser. While other techniques are also utilized to conceal and inhibit its removal, ZxShell’s primary functionality is to act as a Remote Administration Tool (RAT), allowing the threat actor to have continuous backdoor access on to the compromised machine.

As our analysis demonstrates, ZxShell is an effective tool that can be ultimately used to steal user credentials and other highly valuable information. The threat posed by ZxShell to organizations is one that cannot be ignored. Organizations with high financial or intellectual property value should take the time to ensure their security requirements are met and that employee’s are educated about the security threats their organizations face.

The rules are on the first 8 bytes of the first two packets. They are hard coded in the binaries. The rest of the bytes are variable (for example, 66664640 is a floating point version number of ZxShell).

Snort rules:

sid:32180

sid:32181

These rules have been released in our community ruleset and can be downloaded and used directly, or via pulledpork from Snort.org

Appendix B: ClamAV Signatures

Win.Trojan.ZxShell-11

Win.Trojan.ZxShell-12

Win.Trojan.ZxShell-13

Win.Trojan.ZxShell-14

Win.Trojan.ZxShell-15

Win.Trojan.ZxShell-16

Win.Trojan.ZxShell-17

Win.Trojan.ZxShell-18

Win.Trojan.ZxShell-19

Win.Trojan.ZxShell-20

Win.Trojan.ZxShell-21

Win.Trojan.ZxShell-22

Win.Trojan.ZxShell-23

Win.Trojan.ZxShell-24

Win.Trojan.ZxShell-25

Win.Trojan.ZxShell-26

These signatures are available within the ClamAV database. Please run freshclam to ensure you stay updated with the latest coverage.

Appendix C: List of Memory Offsets for Some ZxShell Functions

Here’s a list for some ZxShell functions for sample SHA256: 1eda7e556181e46ba6e36f1a6bfe18ff5566f9d5e51c53b41d08f9459342e26c:

FUNCTION NAME

BRIEF DESCRIPTION

OFFSET

ZxGetLibAndProcAddr

ZxShell GetProcAddress implementation

0x12CDA

CopyMemoryFromNewMsvcrt

ZxShell memory copy routine

0x12C4C

ServiceExists

Get if a service is installed in the system or not

0x0A7C7

ProcessScCommand

ZxShell “SC” command implementation

0x0E3EF

AnalyseAndLoadPlugins

Parse the installed plugin list and load each one of them

0x0127B7

DeleteAndLogPlugin

Delete a corrupted plugin and log the problem

0x012597

KeyloggerThread

ZxShell keylogger implementation

0x0D591

GetIpListAndConnect

Analyse the IP list inside the ZxShell PE and tries to connect

0x011496

BuildTargetIpListStruct

Build remote server Ip list structure

0x11419

DoHandshake

Perform initial connection handshake

0xB8E8

GetLocalPcDescrStr

Build a string containing the target workstation data

0x0B627

MainConnectionIo

ZxShell main connection I/O routine

0x1126C

ReceiveCommandData

Receive each byte from the socket until a newline char

0x016DF

ProcessCommand

Main ZxShell command processing routine

0x10C2B

Appendix D: Other Collateral

Here is a non-exhaustive list of ZxShell samples that were analyzed for this report.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.