Securing the Digital World


May 03, 2017 | by RSA Research |

On April 8th, an interesting DLL was uploaded from Canada to VirusTotal. What makes it interesting is that the detections on VirusTotal are mostly heuristics and do not settle on a single family. The malware is also configured to beacon to an RFC1918 internal IP address, however, the name 816db8a1916201309d2a24b4a745305b.virus indicates it was picked up by some sort of scanner. RSA has observed this relaying technique in environments that do not allow some segments of the network direct Internet access.

File Details
File Name: 816db8a1916201309d2a24b4a745305b.virus
File Size: 458240 bytes
MD5: 816db8a1916201309d2a24b4a745305b
SHA1: 25af2dca548ebbd1bbb467826acb7537dea13488
PE Time: 0x58DA281B [Tue Mar 28 09:08:43 2017 UTC]
Sections (5):
Name Entropy MD5
.text 6.64 bf3d0d8cb747ba341a90fde3a4e4d82e
.rdata 5.45 d158a025435f8afb68c09eae5eb79300
.data 7.16 1f7d73b60062ef6139dcce36162ae4e0
.rsrc 2.95 e775779e36cdfc889fab370e93e26fd5
.reloc 4.58 4508ecd274db4fd6f44cc31f30b7a5b7

Table 1 Sample Details

The sample is a DLL with four named exports. DllRegisterServer entrenches the malware on the target system.

Entrenchment tracking data

Figure 1 Malware Entrenchment

Several things stand out in this sequence of events. First, the service is created as the malware copies itself into C:WindowsSystem32 and starts itself up. (This is not shown in the figure above as this screenshot was taken after the system was rebooted.) The executable update001.tmp is created in the C:WindowsTemp directory and executed with a single argument "on". Three drivers are dropped and installed as services. Then another driver is written to disk, a service created for it and then run. Next, we see update001.tmp executed with the "off" argument. What is going on?

First is the file entrenchment, the module timestomps the service executable upon copying it to C:WindowsSystem32.

Entrenchment and Timestomping

Figure 2 Entrenchment and Timestomping Code

RSA NetWitness® Endpoint's excellent MFT parser points out this timestomping and shows us several more drivers being copied to the C:WindowsSystem32 directory.

Time stomped dll

Figure 3 MFT Timestomping Evidence

These 3 drivers are legitimately signed Novell Client drivers, version Windows versions Vista and above required drivers to be signed before install, so it would be impossible for that small 6KB unsigned driver to be loaded into the Windows Kernel, right? No. The Novell Client drivers contain a privilege escalation vulnerability, CVE-2013-3956, that allow direct access to the Windows Kernel. This update001.tmp packed with VM Protect, drops these driver files, loads them, and then exploits them to get the {CFAA3D51-1C5A-4291-2A51-1A2FFF126CCA}.sys to load without Windows normal signing requirement checks. As discussed in this blog, the same method was used for delivering the Derusbi Kernel driver, which is also unsigned. The file is then run again with the "off" argument since that code is no longer needed.

File Details
File Name: {CFAA3D51-1C5A-4291-2A51-1A2FFF126CCA}.sys
File Size: 6144 bytes
MD5: 86684a8e28a3c3bf0e26f82f18a8cebb
SHA1: 842c780081c149727417162aee9119acd9a76f72
PE Time: 0x5846F64A [Tue Dec 06 17:32:58 2016 UTC]
Sections (5):
Name Entropy MD5
.text 5.64 70d5814da1e96dfdd4a0c8cdacfd9589
.rdata 1.29 87321c5c49b41e9ea6536ba1ad089f33
.data 0.24 312651a6f76490d97aff95c683a68247
INIT 5.28 1ace52afdc5b2542611070f978124113
.reloc 2.03 ac056868e49d3f54e9f6124d71747964

Table 2 Unsigned Driver Details

File Details
File Name: update001.tmp
File Size: 253952 bytes
MD5: 89b457071f43d2fc20e1ab277f641217
SHA1: 2485c13d6b642762f9d97807cb72e402e353f735
PE Time: 0x5846B44B [Tue Dec 06 12:51:23 2016 UTC]
Sections (9):
Name Entropy MD5
.text 6.32 82fa38510d15f2cf5413321b68153ca6
.rdata 5.22 c9f4d887db5baab81876f7d3043ad493
.data 7.78 c764e4e966a29ca189db386eea008dde
.pdata 4.79 22e71d5019c10a679b8e2c23d9632021
.vmp0 6.92 53d624ba16958f9494a413cfac4f973d
.tls 0.0 bf619eac0cdf3f68d496ea9344137e8b
.vmp1 7.29 afd72b46ca785e7f2bb8accb8ec66b31
.reloc 4.24 8b29c8035b7767be600752ff72835cda
.rsrc 4.45 de54285f39044a53a0689f9941368d03

Table 3 Exploit Executable

Another interesting aspect is that this driver is registered as a service, copied to C:WindowsSystem32Drivers, executed, then deleting the registry keys and the driver file every time the malware loads. The driver is a simple rootkit filtering out any TCP/IP connection information from the host system. LibPCAP can still see the traffic, but the connection will not show up with traditional process monitoring tools, such as netstat or Process Hacker. RSA NetWitness Endpoint sees all of the above.

Small driver ecat

Figure 4 Floating Driver

Hooked driver diagram

Figure 5 Kernel Hooks Diagram

Ecat Sees IP

Figure 6 IP Tracking Information

The malware also selectively deploys these tools based on the targeted machine's operating system version.

System profile

Figure 7 Selectively Deploying Malcode Based on System Version

After that the malware starts several threads to handle Command and Control. The main thread begins by decoding the configuration stored in another section of the PE.

Config decoder

Figure 8 Configuration Decoder

This is a simple single byte XOR loop and the configuration is 426 bytes long. The configured IP address is displayed in the memory output panel once the routine has run. The malware then begins the 25-second beaconing loop to the configured command and control (C2) IP. It creates the TCP socket with the C2 and then profiles the system for information included in the beacon. The beacon is not encoded and contains the magic "windows update", the host MAC address, machine hostname, OS version and the configured IP address padded by blocks of 0x00. There are 3 blocks of 64 bytes and one with 32 bytes. The beacon pattern is structured enough that a Lua parser available in RSA Live is capable of parsing and registering the victim machine's data for easy tracking. The mac address registers in the alias.mac meta key, the hostname registers in the and the IP address registers in alias.ip. The actual alert for this shows up in the ioc, Indicators of Compromise meta key.

Initial beacon

Figure 9 SuperCMD Trojan Beacon


Figure 10 SuperCMD Parser Output

The malware uses threads to deal with communication and mutexes to control the I/O functionality so that the two threads aren't writing to, or reading from, the same address space in memory. These mutexes also give the malware its name SuperCMD.

SuperCMD ready

Figure 11 SuperCMD Receive Mutex

SuperCMD Send

Figure 12 SuperCMD Send Mutex

The received data is XOR'd by another simple XOR loop.

recv data decode

Figure 13 C2 Response Decoder

After that it's parsed by another function and can create an interactive shell, upload and download files, create directories, rename files - basically, anything you can do from the command line. It also contains code to take screenshots of the desktop, sending the data back as an encoded JPEG using the algorithm below.

Encode jpeg

Figure 14 Encode JPG Screenshot of Desktop

The key, 0xF0 is an interesting choice since it flips the most significant nibble of each byte and leaves the least significant nibble alone.

The unorthodox method of loading a Kernel driver rootkit coupled with the RFC1918 C2 IP, as well as the compile date being March 28th at 9:08:43 AM UTC, which is 5:08:43 AM EST and then being uploaded to VirusTotal on April 8th is interesting. This may signify an ongoing breach where the malware authors are actively battling the network owners' attempt to remediate the intrusion. Oftentimes, malware is entrenched in network segments that do not have direct Internet or proxy access and authors will install redirectors on segments that can reach the Internet as well as be reached by the segment they require access to. The destination IP being in the CIDR address space also coincides with the default Virtual Box NAT address space, so it could be a development test for detection rates. The .virus extension is from an F-Secure detection, but the VirusTotal version of F-Secure failed to detect it when submitted on April 8th. As of April 14th, the file is now detected by F-Secure.

YARA Signatures
rule SuperCMD
author = "RSAIR 10APR2017"
$mz = "MZ"
$supercmd1 = "supercmd_ready"
$supercmd2 = "supercmd_recv_ok"
$supercmd3 = "supercmd_send_ok"
$config_decoder = { 30 88 ?? ?? ?? ?? 40 3D ?? ?? ?? ?? 72 F2 }
$mz at 0 and all of ($supercmd*) and $config_decoder
rule SuperCMD_rootkit
author = "RSAIR 10APR2017"
$mz = "MZ"
$decoder = { 8B 44 24 30 8B 58 08 8B 4C 24 2C 33 19 8B 70 0C 83 FE FE 74 3B }
$hooker = { 44 00 72 00 69 00 76 00 65 00 72 00 5C 00 6E 00 73 00 69 00 70 00 72 00 6F 00 78 00 79 00 00 00 5C 00 44 00 65 00 76 00 69 00 63 00 65 00 5C 00 54 00 63 00 70}
$mz at 0 and $decoder and $hooker