|
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.
Table 1 Sample Details The sample is a DLL with four named exports. DllRegisterServer entrenches the malware on the target system.
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:\Windows\System32\ 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:\Windows\Temp\ 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:\Windows\System32\.
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:\Windows\System32\ directory.
Figure 3 MFT Timestomping Evidence These 3 drivers are legitimately signed Novell Client drivers, version 3.1.11.0. 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 3.1.11.0 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.
Table 2 Unsigned Driver Details
Table 3 Exploit Executable Another interesting aspect is that this driver is registered as a service, copied to C:\Windows\System32\Drivers\, 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.
Figure 4 Floating Driver
Figure 5 Kernel Hooks Diagram
Figure 6 IP Tracking Information The malware also selectively deploys these tools based on the targeted machine’s operating system version.
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.
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 alias.host and the IP address registers in alias.ip. The actual alert for this shows up in the ioc, Indicators of Compromise meta key.
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.
Figure 11 SuperCMD Receive Mutex
Figure 12 SuperCMD Send Mutex The received data is XOR’d by another simple XOR loop.
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.
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 192.168.58.0/24 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.
The post SuperCMD RAT appeared first on Speaking of Security - The RSA Blog. |
