On March 29^th a file was uploaded to VirusTotal containing a fake Microsoft Update Authenticode certificate. Soon thereafter, RSA Research investigated the sample based on certain artifacts that matched those present on Shell_Crew malware RSA Research previously reported on. This Windows DLL file was compiled on October 28^th, 2014 at 06:35:47 GMT (Table 1).

Table 1 Dropper Details

The file is surprisingly large as it appears to have OpenSSL 0.9.8y 5 Feb 2013 statically linked at compile time. When the file is executed with rundll32.exe and the DllRegisterServer named export, it entrenches on the target system. The malware (Table 2) extracts a DLL to C:WindowsSystem32winms2[xxxx].dat, where x is a random digit (e.g., winms22353.dat). To maintain persistence, the malware adds an entry to the Windows registry as a service. The malware also finds the timestamp of Kernel32.dll and timestomps its $SI Create attribute (Figure 1).

Table 2 Service DLL Details

Figure 1 Service DLL Timestomping

When executed, the malcode begins in DllMain with a call to Kernel32!CreateThread() to an offset in the portable executable (PE) that starts a decoding function (Figure 2).

Figure 2 Decoding Function

These two decoders carve out two small DLLs (Tables 3 and 4) from the .data section of the PE.

Table 3 Keylogger #1 Details

Table 4 Keylogger #2 Details

Both DLLs export a named export labeled “Func” and are nearly identical with the only real difference in functionality being the keylogger text output (Figure 3).

Figure 3 Keylogger BinDiff Results

Figure 4 Malware Communications over Named Pipe

The striking detail is in how the malware communicates with these two DLLs. Notice the named pipe calls in the assembly in Figure 4. The malware and the keylogger DLLs communicate via this named pipe. The malware does not load these DLLs in the service DLL address space. Instead, it injects the DLLs directly into explorer.exe after finding its Process ID, then creates a remote thread at the offset of the “Func” named export. This is detected in RSA NetWitness® Endpoint via several methods.

Floating code attributed to the two keyloggers injected into explorer.exe is suspicious as it uses the target application as a host and lives within its memory space. RSA NetWitness Endpoint alerts and shows the injected code (Figure 5).

Figure 5 Floating Code in explore.exe

Also suspicious is a service DLL with a .dat extension, with a forged Authenticode certificate. Service DLL’s always have the .dll extension and you will find legitimate DLL’s with expired or self-signed certificates but rarely with an invalid certificate signature (Figure 6).

Figure 6 Malicious Service

We observed the malware opening a handle to explorer.exe and creating a remote thread (Figure 7). RSA NetWitness Endpoint filters the API call OpenProcess() based on arguments passed to the function via the stack in the case of 32-bit code, or registers in the case of 64-bit code.

Figure 7 Malware Entrenchment and Code Injections

The named pipe appears in the svchost.exe process as a handle (Figure 8).

Figure 8 Named Pipe Communications

The output from the keyloggers can be seen in memory strings in the address space allocated within explorer.exe (Figures 9 and 10).

Figure 9 Injected Code Segment

Figure 10 Keylogger Output Visible in Memory

The malware also writes this information to disk in C:WindowsTemp directory with a filename DMIF[xxx].tmp, where x is a random digit. These are specified by the malware using an encoded Registry entry in SOFTWAREMicrosoftRPCLevel01 (Figure 11).

Figure 11 Malware Registry Configuration

The Registry entries are single byte XOR’d with 0xA0, but the malware takes an interesting approach to calculate this. Instead of XOR’ing with 0xA0, the malware XORs with 0x5F (Figure 12) and then NOTs the result to get 0xA0, as decoded in Figure 13.

Figure 12 Registry XOR Routine

 

Figure 13 Registry Entry Decoded

In addition to the keylogger files, there are seven distinct 64 byte null-terminated blocks of information. These blocks are encoded and decoded at runtime with the 4 byte rotating XOR function, below. The config is 784 bytes long and the shift right rotates through the DWORD, in orange (Figure 14). The command and control (C2) functionality reads from the second block looking for the string http:// or https:// to match a URL. This malware fails to decode a valid URL with its own algorithm, but, nonetheless, continues collecting keylogger data and capturing RDP logins.

Figure 14 Configuration Decoder

During execution the malware creates three threads. The first decodes the keyloggers and then creates the remaining two threads. The second created thread is on a ten second timer to call the Malware_Main function that controls malware’s interaction with the C2. The final thread is on a five second timer and connects to the named pipe created by the keylogger. The malware seemingly operates without a valid C2 URL or email address for the SMTP data exfiltration capability. This may indicate intentional configuration on the target system by the actor who would, presumably, return at a later date to manually retrieve the files.

Figure 15 Main Malware Functions

The file was originally submitted to VirusTotal from Malaysia, which could indicate the location of the entity targeted. With only 11 detections, none from the larger antivirus (AV) vendors, this suggests it may be an effective tool to surveil human interaction on a targeted machine. The installation by a DLL with a named export of DllRegisterServer also indicates it is a second-stage tool used for reconnaissance once the actor has a foothold in the targeted network.

Using the YARA signature (below), RSA NetWitness Endpoint can be configured to find this automatically. An analyst may also combine the scan data indicating floating code and follow along in Tracking Data to manually discover this type of behavior. The verbosity and level of detail available in Tracking Data cannot be understated. Malware is regularly tweaked to avoid signature-based technology, as well as heuristics-based detection engines. What can’t be hidden are the end results, injected code and an unknown, suspicious service DLL running in the environment. The level of detail provided by RSA NetWitness Endpoint gives an analyst many options for finding malware in their environment.