Tuesday, June 4, 2013

Banking Blockade (Cridex) Trojan Analysis

Hello internets! I recently encountered a new variant of what I know as the "blockade banking" trojan, so I figured I'd do a writeup on it. This is probably more commonly known as the Cridex trojan. I think it's fairly interesting in that the primary method of distribution is via the Neutrino Exploit Kit (which I'm not really going to discuss beyond the URL pattern) [Note: it's also distributed via the Phoenix exploit kit, as I found out later]. I haven't done any research into Phoenix Exploit Kit, but I did look a tiny bit into Neutrino. Neutrino Exploit Kit is fairly old as far as the infosec world is concerned -- it dates back to 2011. You can see the url pattern for Neutrino Exploit Kit here: http://urlquery.net/report.php?id=2679468

Regex/PCRE pattern for Neutrino (from the traffic I've seen) looks like this, in case you want to use it in a Snort rule:


And now, onto the part you've clearly been dying to learn about: the blockade banking trojan. This trojan is designed to steal credentials that a victim uses to access their online banking services. Presumably this would be used as part of an identity theft.

So, how does the victim end up with this trojan? Similar to Darkleech, Neutrino often affects legitimate websites. When the user visits an affected website, Neutrino traffic looks similar to this:

The first part of the stream contains a bunch of obfuscated javascript. I'm not going to reverse engineer the JS in this example, since we covered how to do that in the previous post about Darkleech landing pages.

Following the obfuscated JS, a POST request happens that contains what looks like shell code, seen here:

As we keep looking through the traffic in Wireshark, eventually we get a GET request that contains the payload: a .jar file and an obfuscated EXE. We can see the jar file here:

We'll take a look at some of the class files inside the .jar file later. Here's an obfuscated file from later in the same TCP stream. Given that we know that the mime type is "application/octet-stream", we can pretty well conclude that this is an exe file:

First things first, let's take a look at the .jar file and the .class files inside it. As expected, there are a whole bunch of .class files in here. For now, I'm only going to decompile one of them. In this case, we're looking at mm.class. Using JAD, I decompiled the mm.class file and got the following code:

import java.awt.image.*;

abstract class mm extends BufferedImage


    private static String d2(String s)
        String s1 = s.replaceAll("[0-9]", "");
        String s2 = (new StringBuilder(s1)).reverse().toString();
        return new String(s2);

    private int tt(String s)
        if(s.length() < 0)
            return 1;
            return s.length();

    public mm(int i, int j, int k, int l, ColorModel colormodel, SampleModel samplemodel)
        super(i, j, k);
        str1 = "(98071949708552672673878308~snip~;
        str2 = "(038673574676929482034231>960~snip~";
        _ft = l;
        _fcm = colormodel;
        _fsm = samplemodel;

    public int getType()
        String s = Thread.currentThread().getStackTrace()[2].toString();
                return _ft;
        catch(Exception exception) { }
        Object obj = null;
        return ((Integer)obj).intValue();

    int _ft;
    ColorModel _fcm;
    SampleModel _fsm;
    String str1;
    String str2;

Deobfuscating the big variables using the methods discussed previously tells us only one piece of information, but remember that there are 10 or so .class files in this payload.

"Str1" from mm.class deobfuscates to: "ICC_Transform.getImageLayout". 

"Str2" doesn't actually deobfuscate in this class file, but it is used in other class files (and ultimately, in the final payload). This is just a quick example of how class files are used to create an exploit. :)

So, let's move on to the obfuscated exe file mentioned earlier... 

Thankfully this thing is only XOR'ed with a simple key. XORsearch wasn't doing it for me, so a little trial and error allowed me to find the XOR key: 79 6C 74 6F 67 76 73

So, here's a snapshot of the un-XORed MZ file header:

A quick sigcheck of the file gives us a hash:

Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com

        Verified:       Unsigned
        Link date:      8:43 PM 1/9/2001
        Publisher:      Texfztm
        Description:    VwwnvzeWwzsnajsz
        Product:        Kdsybzc Drpkiifmeqo
        Version:        n/a
        File version:
        MD5:    813F17A401571A20664E882DE29E5DDC
        SHA1:   E66AF5281427B411877F04A4F6A4D010F9472310
        PESHA1: 56BBDEA472F4CE6D6BFB37D4CF9450466DE4ADE2
        SHA256: ABB566B5938027F10F9E877257F5C9970C5851B1D96524B7708B5238FFD5FFF4

Thankfully it's got a fairly high detection rate these days. Okay, so what does this thing do? Well, we're about to find out.

First, let's verify a few things about the exe just to make sure I didn't accidentally fuck up with my XOR key. Running exiftool on the exe gives us the following output:

ExifTool Version Number         : 9.30
File Name                       : unknown.exe.malware
Directory                       : C:/Users/admin/Desktop
File Size                       : 62 kB
File Modification Date/Time     : 2013:06:04 02:49:01-06:00
File Access Date/Time           : 2013:06:04 02:59:22-06:00
File Creation Date/Time         : 2013:06:04 02:59:22-06:00
File Permissions                : rw-rw-rw-
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2001:01:09 19:43:07-07:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 2048
Initialized Data Size           : 1536
Uninitialized Data Size         : 115200
Entry Point                     : 0x13cb
OS Version                      : 4.0
Image Version                   : 5.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
File Version Number             : 0.9331.0.21
Product Version Number          : 0.9331.0.21
File Flags Mask                 : 0x003f
File Flags                      : (none)
File OS                         : Windows NT 32-bit
Object File Type                : Executable application
File Subtype                    : 0
Language Code                   : English (U.S.)
Character Set                   : Unicode
Company Name                    : Texfztm
File Description                : VwwnvzeWwzsnajsz
File Version                    :
Internal Name                   : Vwwnvze
Legal Copyright                 : ┬⌐ Texfztm
Original Filename               : Vwwnvze.exe
Product Name                    : Kdsybzc Drpkiifmeqo
Product Version                 :

Notice the timestamp on it? Pretty old... considering Cridex wasn't around in 2001. It's a fairly safe bet that the compile time timestamp was modified by the malware writer. 

TrID confirms that it is indeed an exe. TrID output:

TrID/32 - File Identifier v2.10 - (C) 2003-11 By M.Pontello
Definitions found:  5062

Collecting data from file: C:\Users\admin\Desktop\unknown.exe.malware
 34.2% (.DLL) Win32 Dynamic Link Library (generic) (6581/28/2)
 33.9% (.EXE) Win32 Executable (generic) (6514/8/2)
 10.7% (.EXE) Win16/32 Executable Delphi generic (2072/23)
 10.4% (.EXE) Generic Win/DOS Executable (2002/3)
 10.4% (.EXE) DOS Executable Generic (2000/1)

Now, onto the exe itself... The exe does several things of note

  •  Creates file %USERPROFILE%\appdata\roaming\kb00596853.exe
    •  MD5 hash: 813f17a401571a20664e882de29e5ddc
    •  Note: This is the same hash as the original file\
  •  Creates file (empty)C:\Users\admin\AppData\Local\Temp\POS280.tmp
    • Note: This filename is randomized with each execution
  •  Creates a mutex "Local\QM0000049C"
  •  Creates a mutex "Local\QI0000049C"
  •  Creates a mutex "Local\QM0000051C"
  •  Creates a mutex "Local\QI0000051C"
  •  Creates a mutex "Local\QRD46134FE"
  •  Creates a mutex "Local\!IETld!Mutex".
    • Note: The mutex names above appear to be randomized slighlty
  •  Queries DNS vseforyou.ru
  •  Queries DNS commorgan.ru
  •  KB00596853.exe Connects to "" on port 80
  •  Creates process "(null),"C:\Windows\system32\cmd.exe" /c "C:\Users\admin\AppData\Local\Temp\POS2119.tmp.BAT",(null)"
    • The .BAT file is responsible for deleting the original file
Sets some persistence by creating the following registry value (Note: Newer/older variants use different filenames, but the persistence location is always the same):: 
  • \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kb00596853.exe
The network traffic created by the malware is pretty interesting. The first POST request header can be seen here (This is the first part that steals banking credentials for a bunch of pre-set banking websites):

Later on in the same TCP stream we encounter another MZ file header. Extracting that file and running through sigchek gives us the following info:

Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com

        Verified:       Unsigned
        Link date:      8:20 PM 1/9/2001
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Version:        n/a
        File version:   n/a
        MD5:    97720BBBA4DD08221402FCE851A8B718
        SHA1:   A97DA0B22C78ADB85F55F6A58BBAD2C8A609EFB4
        PESHA1: 28912AD78B57EAB2F7D4BC9E8FBA77316BF4ADED
        SHA256: 6EC20F0164A46607E11116770B43A964D539FB92D179A449CB0D8899FED6BF4C

Fun times. Further analysis of this file shows that it's actually the same file as the original, but with a different hash. This could indicate that it's either polymorphic, or that there's a set of files living on the C2 server that this malware grabs at random. 

This worm not only steals banking credentials, it also gathers intel from the victim's host. This is likely used in future exploitation. We can see the worm enumerating the running processes on the victim's host here and sending it back to the CnC server (Note: This does not happen right away... the worm sleeps for a while before sending this out):

In the end, this new Cridex variant is quite nasty. Here's some info about the traffic:

Known CnC IP addresses:,
Original Infection Vector IP:
CnC domains: myplanethome.ru, west.modest-summer-trip.info
Compromised referrer domain: thairath.co.th
Other suspected malicious domains: vseforyou.ru, commorgan.ru

That's all for this evening. More to come soon; I hope you enjoyed the read!


No comments:

Post a Comment