Saturday, January 2, 2010

Unmasking the Dreaming Shaman - the Shamans Dream exploit kit

Jan-4-2010: UPDATE: I've learned that I missed some important aspects of this exploit kit during my analysis and likely published this too soon, so look for a part two if I'm able to continue analysis (which will depend upon finding a live sample to work with)

Note: there is nothing very novel or unique about this particular malware kit that I was able to determine. As a result of this, I will be more selective in the future about what malware gets analyzed and posted. However, there may be something in here that is of value or interest to other researchers.

I appreciate the Malware Domain List (MDL), found at because it posts and briefly categorizes new malware, and is open to the public. I take note of exploit kits for obvious reasons and was interesting in learning more about one listed as Shamans Dream. I have never heard of this kit before, and figured it may be new. shows a site (live as of 1/1/10) hosting the following:

The auth page's form action looks like this:

Notice that the Zeus/wsnpoem trojan (nasty banking/infostealing trojan) being served from the same site and the same gibberish directory (mNYbH63). It's not too hard to deduce that installation of Zeus is likely the goal of this particular malware kit.

A bit of googling reveals little information, except the MDL information, and a page at  - which reveals that knew of a Shamans Dream kit on December 10, 2009. Posters to the the thread speculate that it's part of the JustExploit kit, or a modified Tornado exploit pack. An example of obfuscated Javascript, very typical to modern malware delivery via client-side exploits, is included on the site. While this may not have any relationship with JustExploit, one instance of JustExploit was covered in my blog recently:

(other links from there point to other reference sources)

And the Tornado exploit kit has been covered on other sites, for instance in May 2009, dxp2532 created a blog entry and an Emerging Threats IDS signature (detecting the compromised, or soon to be compromised box sending a fingerprintable HTTP GET to the server hosting the malware) were also created:

The Emerging Threats signature dxp2532 created:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET
        MALWARE Tornado Pack Binary Request";
        flow:established,to_server; content:"GET "; depth:4;
        uricontent:"?o="; uricontent:"&t="; uricontent:"&i=";
        uricontent:"&e="; classtype:trojan-activity; sid:XXXX; rev:1;

does not appear to have any relationship with the HTTP traffic seen later in the chain of this particular sample, so I believe that the alleged relationship with Tornado Pack may be minimal or non-existent. However, I do not have the actual kit source code to compare.

In this case, opening up the entry page, http:// /ImNYbH63/ reveals typically obfuscated Javascript as such:

Notice the first few lines load a plugin file, PluginDetect.js which appears to be used in this case to detect the version of Java in use. For more info about how that script works, see the work by Eric Gerds on PluginDetect and the Java detection in particular here: 
In this example the script looks like it's configured to detect the version and config of Java "On the Fly" OTF which involves using faster techniques first (MIME type checking) before trying to actually load an applet. A variety of functions are documented, however the ones apparently of interest to the exploit kit are as follows: 
/* PluginDetect v0.6.3 [ onWindowLoaded isMinVersion getVersion Java(OTF)

My quick read of this indicates that the attackers care most about the version and minimum version of java and want to detect it quickly (OTF). Better not have the browser hang for too long waiting on applets, although many victim computer users still won't have any clue. For further details, see the full JavaScript pasted at the end of this entry.

Attempts to automatically deobfuscate the Javascript have failed for unknown reasons, however I've learned enough to see that the important action appears to be simply to load an IFRAME pointing to the page which then loads Zeus. That IFRAME is http:// /ImNYbH63/pdf.php?exp=pdf_all (spaces added to break link). This was determined by just using wget to obtain the file on a unix box. The wget'ed file contains a smaller amount of obfuscation than the file obtained via the browser (pasted in screenshot above) and the wget'ed file does not contain the obvious reference to the PluginDetect script.

Downloading via Windows web browser results in a file named price.pdf which is blank (except for the exploit code). Sloppy, I'd think that the malware authors would at least embed some text in the PDF file to make it less obvious. But most victims of drive-by exploits aren't necessarily known for being well-informed about exploitation defenses, are they now? That's a problem of human behavior, priorities and economics out of scope for this entry.

The attack page (or perhaps some other issue) seems to limit the number of views of specific pages from IP addresses to one, at least in my initial tests when I received a 404 on later attempts. This is of course easily circumvented with the use of Tor or proxies or other techniques.

The Wepawet report for the domain shows a variety of activities, but appears to not detect anything about Java being used as an exploit vector. Instead, we see references to CVE-2008-2992, Adobe's util.printf exploit being used on http:/ /inter-solutions .cn /ImNYbH63/pdf.php
for the entire domain
for the actual exploit page 

Adobe util.printf overflow
Stack-based buffer overflow in Adobe Acrobat and Reader via crafted format string argument in util.printf

While Wepawet finds util.printf, visual analysis also reveals the use of CVE-2007-5659 Collab.collectEmailInfo with a long unescaped %u0c0c%u0c0c to accomplish a heap spray technique:

var nbbpY8JUZaFmNsRs = unescape("%u0c0c%u0c0c");
while (nbbpY8JUZaFmNsRs.length < 44952)nbbpY8JUZaFmNsRs += nbbpY8JUZaFmNsRs;
  this .collabStore = Collab.collectEmailInfo({
    subj : "", msg : nbbpY8JUZaFmNsRs

The PDF file itself, when downloaded with wget, is dynamically generated and modified each download, as indicated by the following md5sum run:

d5cd342f86718e0c4da8f7dd97a85879  pdf.php
e9a7d033e03941cec2e3204893cd5e31  pdf.php.1
f1dcefa18ce504c42b97f210352340ed  pdf.php.10
70cb614609fbe10b3c7ada5c45a1a37a  pdf.php.11
8f7cb033f72a776bd2680cb952333632  pdf.php.2
8086d55947bbfde39d277dfa28d5b640  pdf.php.3
26d6f2db431f6e0bb6fe26171ccfdf17  pdf.php.4
8c4f80120297351365f6e5236923581b  pdf.php.5
80f2fae80d4ca281fc5d0f2f6322dbae  pdf.php.6
e4d0b79bce7ff2c879bc54c53f604ed9  pdf.php.7
d6d4396518deabad3e2fcfafcfec1c0e  pdf.php.8
3e343fd3b115ddf778951d7a9ddee95d  pdf.php.9

A sad truth - attackers continue to get results from older Adobe bugs. Rather pathetic really. According to Wepawet, the payload from pdf.php is exe.php?exp=pdf which is already documented as Zeus. In this case, the binary payload is not changing with each load, at least based on the static MD5 that I'm seeing when downloading with wget 8 times:

403e486715b0a7d568fa67995c737af7  exe.php?exp=pdf
403e486715b0a7d568fa67995c737af7  exe.php?exp=pdf.1
403e486715b0a7d568fa67995c737af7  exe.php?exp=pdf.8

Sandbox and online analysis results

The Zeus binary has 12/40 (30% detection) with static scanners on VirusTotal:



a variant of Win32/Kryptik.BLS

Download via google chrome saves the Zeus loader as klnc.exe.

Anubis analysis of the binary:

The Norman Sandbox is unable to detect the malware:

klnc.exe : Not detected by Sandbox (Signature: NO_VIRUS)

 [ DetectionInfo ]
   * Filename: C:\analyzer\scan\klnc.exe.
   * Sandbox name: NO_MALWARE
   * Signature name: NO_VIRUS.
   * Compressed: NO.
   * TLS hooks: NO.
   * Executable type: Application.
   * Executable file structure: OK.
   * Filetype: PE_I386.

 [ General information ]
   * File length:        93184 bytes.
   * MD5 hash: 403e486715b0a7d568fa67995c737af7.
   * SHA1 hash: 1ede9dd940fe28349a3b741ad586187c3a192c0d.

Attempting to analyze the Zeus binary loader with JoeBox (selecting XP SP3, Vista and Windows 7) provided no results. However, analyzing the binary with JoeBox with the default (XP SP3) discovered quite a bit about the process. The basics indicate that C:\​​WINDOWS\​​system32\​​sdra64.​​exe was dropped. There is no online version of the JoeBox results; I will try to incorporate them into this blog at a later time. Kudos to the JoeBox developers for allowing analysis with Windows 7 and Vista!

ThreatExpert offers a nice analysis:

Some highlights:

  • The data identified by the following URLs was then requested from the remote web server:
In this case, the Zeus config is obtained from the config.bin download. ThreatExpert does a nice job displaying the institutions being attacked in it's report, which saves the time that it would take to decode the config.bin file. is a well-known Zeus domain, having been published to the Zeus blacklist on 12/5/09:

Nothing apparently new here, despite the presence of the Java detection script. Perhaps further digging when I have more time will discover more details.