A Different Take on Keystroke Logging
- April 15, 2017
On March 29th 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 28th, 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.