Pivot on Google Code C2 Reveals Additional Malware

Last week, we reported on attacks observed against East Asia that used Google Code for command and control (C2). As follow-on to that work, we pivoted on the C2 indicators of compromise (IoCs) within our WildFire platform, looking for additional malicious activity.

One sample in particular caught our attention, downloaded on June 18 from 211.233.89.182 via FTP. While all of the other near-proximity samples downloaded from this Korean IP were flagged as malware by VirusTotal, this one was not at that time. Deeper inspection revealed what this malware was and how it evaded detection by antivirus programs.

The FTP download in question was for a resource innocuously named “p”.

Table 1

While this file listed Microsoft themed product and filename metadata, it also betrayed itself with a telling program database (PDB) reference:

E:\logic\projects\evil-codes\bin\xVirusDll.pdb

Additionally, the file advertised “Chinese (Simplified)” as its language code.

A closer look at associated DLL code and data sizes revealed that this file had some “passengers” of interest. Inspection of that content highlighted the use of an eight-byte rolling XOR encoding. Single-byte XOR encoding is commonly used by malware authors as a quick and still somewhat effective method of hiding (or obfuscating) malicious code. Rolling XOR expands on this success by using multi-byte XOR keys. Use of Rolling XOR has trended upward, meaning it takes more time and effort to decode respective content.

In this case, the rolling XOR key was leaked through the content itself, due to its implementation. Accounting for multi-byte key alignment, decode and extraction yielded two files, the first of which would be dropped and in turn drop the second.

Table 2

Strings of interest for this binary contain further evidence of malicious activity:

EvilPluginInit

EvilPluginRun

E:\logic\projects\evil-codes\bin\EvilKernel.pdb

The “EvilPluginInit” and “EvilPluginRun” procedures are invoked to activate the second file, pluginWinPswLogger.dll, after it is written to disk.

Table 3

The UPX compression (packing) employed was standard, allowing for default decompression and subsequent binary analysis. This implant was a Windows credential stealer with variants available as far back as 2009. Capture of successful Windows logons (local and network) were written to a configurable-location (determined by a single furnished parameter) log file in the clear (i.e., no obfuscation), with the following format:

[<date in MM/DD/YYYY format> <time in HH:MM:SS format>]

LogonType: <logon type enum>, MessageType: <logon submit type enum>

Domain:   <domain or workgroup>

User:     <username>

Password: <username’s matching password>

A sample entry for a user unlocking Windows using a local account follows:

[08/19/2014 18:15:06]

LogonType: 2, MessageType: 2

Domain:   MORDOR

User:     Frodo

Password: Wh47 4 r0ugh d4y!

This implant requires administrative privileges to run, which can be achieved through a prior implant and/or susceptible Windows configurations. This particular sample is a second stage payload, deployed after an attacker has already infected a system and wants to gather more information. It contains no command and control capability and cannot exfiltrate data on its own.

Open source intelligence (OSI) on this progression also showed that the “evil” series of malware is directly derived from the Google Code repositories of Logic.Yan.

Specifically, the xVirusDll (p) related code can be found here and the EvilKernel.dll (kernel32.dll) related code can be found here. All associated code was uploaded on February 12, 2012, under the xvirus project.

These freely available repositories have already been applied to at least one actor’s objectives and we can expect to see additional variants of this same codebase in the future.

From a trending perspective, key techniques employed by this progression to evade detection include:

• Employment of multi-byte XOR encoding: Increased resource cost of decoding for analysis.
• Standard binary packing (UPX): Further obfuscation of malicious code.
• Minor changes within implant binaries: Potential impacts on signature-based detections.
• The use of FTP for n-stage malicious code download: Not all organizations have visibility into and the ability to scrutinize this channel for threats.

Combined, these techniques extend the viability of somewhat dated malicious code and increase its ability to bypass protections and fulfill attacker objectives. To detect this type of secondary payload, ensure you are monitoring all applications (including FTP) for executable downloads and sending them to a dynamic analysis system like Palo Alto Networks WildFire.