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 http://www.malwaredomainlist.com 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. http://www.malwaredomainlist.com/mdl.php?search=inter-solutions.cn shows a site (live as of 1/1/10) hosting the following:
The auth page's form action looks like this:
A bit of googling reveals little information, except the MDL information, and a page at malwareview.com - http://malwareview.com/index.php?topic=397.0 which reveals that x0r.su 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 malwarereview.com site. While this may not have any relationship with JustExploit, one instance of JustExploit was covered in my blog recently:
http://perpetualhorizon.blogspot.com/2009/12/poking-at-justexploit-kit-part-1.html
http://perpetualhorizon.blogspot.com/2009/12/poking-at-justexploit-kit-part-2.html
(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:
http://dxp2532.blogspot.com/2009/05/tornado-exploit-pack.html
http://lists.emergingthreats.net/pipermail/emerging-sigs/2009-May/002692.html
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:// inter-solutions.cn /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:
http://www.pinlady.net/PluginDetect/
http://www.pinlady.net/PluginDetect/JavaDetect.htm
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:// inter-solutions.cn /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
http://wepawet.cs.ucsb.edu/domain.php?hash=3f57e3b83e4362dd129bae8e8fd862f3&type=js
for the entire domain
http://wepawet.cs.ucsb.edu/view.php?hash=10591142d602d9e850d33f92e915289b&t=1262348578&type=js
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 | CVE-2008-2992 |
http://wepawet.cs.ucsb.edu/view.php?hash=10591142d602d9e850d33f92e915289b&t=1262348578&type=js
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
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:
http://www.virustotal.com/analisis/888cce0a9ec478865d0a2bc9f70e9dcb8c60b07a4890891a3a67f2f1cff3cce2-1262422521
| a-squared | 4.5.0.43 | 2010.01.02 | PWS.Win32!IK |
| Comodo | 3445 | 2010.01.02 | TrojWare.Win32.TrojanSpy.Zbot.Gen |
| DrWeb | 5.0.1.12222 | 2010.01.02 | Trojan.Packed.18626 |
| Ikarus | T3.1.1.79.0 | 2009.12.31 | PWS.Win32 |
| Kaspersky | 7.0.0.125 | 2010.01.02 | Trojan-Spy.Win32.Zbot.adog |
| McAfee+Artemis | 5848 | 2009.12.31 | Artemis!403E486715B0 |
| Microsoft | 1.5302 | 2010.01.02 | PWS:Win32/Zbot.gen!R |
| NOD32 | 4736 | 2010.01.01 | a variant of Win32/Kryptik.BLS |
| Panda | 10.0.2.2 | 2010.01.01 | Trj/CI.A |
| Rising | 22.28.03.04 | 2009.12.31 | Packer.Win32.Agent.GEN |
| Sophos | 4.49.0 | 2010.01.02 | Mal/TibsPk-D |
| VBA32 | 3.12.12.1 | 2010.01.01 | Malware-Cryptor.Win32.Palka |
Download via google chrome saves the Zeus loader as klnc.exe.
Anubis analysis of the binary:
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: 403e486715b0a7d568fa67995c737a
* SHA1 hash: 1ede9dd940fe28349a3b741ad58618
[ 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: 403e486715b0a7d568fa67995c737a
* SHA1 hash: 1ede9dd940fe28349a3b741ad58618
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:
- http://print-design.cn/shark/config.bin
- http://www.whatismyip.com/automation/n09230945.asp
print-design.cn is a well-known Zeus domain, having been published to the Zeus blacklist on 12/5/09:
https://zeustracker.abuse.ch/monitor.php?host=print-design.cn
Nothing apparently new here, despite the presence of the Java detection script. Perhaps further digging when I have more time will discover more details.
Posts
