Malware

Pivot on Google Code C2 Reveals Additional Malware

Clock Icon 4 min read
Related Products

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

Filename p
Size 154112 Bytes
File Type (.DLL) Win32 Dynamic Link Library
MD5 499ec45d12e236dc73a8358da7265aaf
SHA1 6671fceda11006b752771a3591eb009234332302
SHA256 3556b79c12eacf956f2114a529a22a05804bf594eaa4deb1000046f9b6c7a5a8
SSDEEP 1536:Nnb7fpVBhwoKv4E3qsnLPdtr9Y0Wc2KWnXyOSbIFxni:NnBVIoKV3qkLFlMDhFx

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

Filename kernel32.dll
Size 78848 Bytes
File Type (.DLL) Win32 Dynamic Link Library
MD5 a137c15705afac2600152e7e8359c91f
SHA1 366679e9f74f7f6583c38bdd5000dcd4512353ce
SHA256 d91af8f24916d4e4d98459726161429652c7c0e7f6c86a6b080fface3616bc07
SSDEEP 768:Thr7tMlJ/z4JL6BDMHh2LGnTEDPCvyHzp5twJe2rYlGJ:9vtiJ/0JcgBL8Hz/tD2rVJ

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.

evil 1

Table 3

Filename pluginWinPswLogger.dll
Size 7668 Bytes
File Type (.EXE) UPX compressed Win32 Executable
MD5 c0324adf195c780b33d93746aa3310fa
SHA1 7d9d5763f107ae51ae721dad5e21e24a8e2d9454
SHA256 acfe002cb5ff0ed779e9aa413e35f3743eea6492cee94bf7ac6382f07a201847
SSDEEP 96:ooVbogW6eTm49snCADR1mkgz8mN60Ju7CfB7Axl5ipWQOylCCahJ+Ie6uW2PLe4:vPW6emVnj91mQ0Ju2fhw5LLZuz6p2X

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.

evil 2

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.

evil 3
 

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.

Enlarged Image