Poking at the Justexploit kit part 2

Again, some of this analysis has probably already been posted somewhere but in the interests of continuing my process, I will pick up where I left off with yesterdays blog post. Yesterday I went over basically what the Justexploit's MDAC exploit attempted to do, and followed the malware trail for a while.

The second batch of bugs exploited by Justexploit are common Adobe Acrobat Reader issues, all patched. These have been documented to a large degree and are apparently well understood so I won't go into the mechanics. The bugs, which have been hammered by other exploit kits are:

Adobe Collab overflow - CVE-2007-5659
Adobe util.printf overflow - CVE-2008-2992
Adobe getIcon - CVE-2009-0927

Numerous PoC's and weaponized exploits exist for these issues.

The PDF exploitation associated with the sdfnucleartqg dot info site is hosted at /pdf.php and was already submitted by an unknown party to the excellent wepawet sandbox on 12-4-09:

http://wepawet.cs.ucsb.edu/view.php?type=js&hash=ac781b52bb2541aa214e3ee804ebfedc&t=1259920135

A portion of this blog entry expounds a bit on the wepawet analysis, but is not as pretty. If you want the full details, shellcode bytes and all of the de-obfuscated javascript (heap spray, etc) then please see the wepawet link above. Kudus to the developers of wepawet for it's time-saving properties.

Wepawet does a good job extracting the shellcode from the PDF, as we see in the "Shellcode and Malware" section. The actual payload starts off with a 0x90 based NOP sled, followed by shellcode that points to the downloading and executing of yet another URL from the same site-


.j...http://sdfn
ucleartqg.info/f
eedback.php?page
=3

The URL is obvious here and points towards the same windows binary pushed by the MDAC exploit. This binary was detected by VirusTotal on 12/2/09 by 10 out of 41 anti-malware engines (24.39%). See the VirusTotal report for full details, however the relevant results are pasted here:

http://www.virustotal.com/analisis/5a4dd63616bda4bef5b37b8ab6eeec0525f5c8aebc2f8c747a338d81dc9ed0cd-1259735138

a-squared 4.5.0.43 2009.12.02 Trojan.Win32.Oficla!IK
CAT-QuickHeal 10.00 2009.12.02 (Suspicious) - DNAScan
Ikarus T3.1.1.74.0 2009.12.02 Trojan.Win32.Oficla
Kaspersky 7.0.0.125 2009.12.02 Trojan.Win32.Sasfis.wox
McAfee+Artemis 5819 2009.12.01 Artemis!8D0F4EC4C458
Microsoft 1.5302 2009.12.01 Trojan:Win32/Oficla.E
Prevx 3.0 2009.12.02 Medium Risk Malware
Rising 22.24.02.03 2009.12.02 Trojan.Win32.Generic.51F273B2
Sophos 4.48.0 2009.12.02 Sus/UnkPack-C
Sunbelt 3.2.1858.2 2009.12.02 Trojan.Win32.Sasfis.a (v)

See the previous blog entry for a basic analysis of the payload. See the Anubis analysis of this binary for further details:

http://anubis.iseclab.org/?action=result&task_id=19ff7bcb29a1f7e54d929cfd9dc2a6969

I have found that Anubis doesn't always give me the level of detail that I need. I personally prefer ThreatExpert's sandbox analysis. Anubis does enumerate network activity, which shows the same target binary that was included with the MDAC exploit.

3.c) svchost.exe - Network Activity
DNS Queries:
Name Query Type Query Result Successful Protocol
h0stels.cn DNS_TYPE_A 210.51.166.250 1

HTTP Conversations:
From ANUBIS:1038 to 210.51.166.250:80 - [h0stels.cn]
Request: GET /SHasg2/bb.php?id=590043150&v=200&tm=8&b=justspl
Response: 200 "OK"

It is fair to assume that the Java exploit has the same end result. The exploit code is found in the following JAR (as previously documented elsewhere) - http://sdfnucleartqg dot info/files/sdfg.jar

98d499308df04932ed1b58a78417d6fb sdfg.jar

unzip sdfg.jar
Archive: sdfg.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
inflating: myf/y/AppletX.class
inflating: myf/y/LoaderX.class
inflating: myf/y/PayloadX.class

Avira catches the Jar as JAVA/OpenStream.AD Java Virus

Since java is trivial to reverse, it's easy to see what's going on. If this hasn't already been done ( I think it has ) I'll do it in part 3. Guessing it's based off of public exploit code for the Java bug released a while back. Why should the malware authors expend energy when they can just leech from security researchers? One of the downsides of people publishing exploits (I digress, this is a distinct topic)

The opening page where the initial Javascript starts the process of infection is dynamically generated with different encoding every time with a new id as such:

ID's generated in this sampling:

wtIsTqv
GhttiIm
Rv0jW1E
ujVvVrK
VZYaFVm
WztzroN
Xuq11AX
gvcGPqU
DOsZOc0
Ii8Qqbe
ERS6apw
srah6hg

Since Wepawet had no problem decoding, I didn't bother running the code through Malzilla or other local decoding tool.

In other news, a URL from the malware chain yesterday has changed it's payload. The page contains what appears to be command & control information for the infection.

http: //h0stels . cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1

The new contents of the .cn page points to a new binary:

http: //poezd-v-ad . eu/free1/mqh5.exe

VirusTotal gives what looks mostly like generic detections

9d99e88dfefc6528f4ba912d9d9b1f19 mqh5.exe

AntiVir 7.9.1.102 2009.12.08 TR/Dropper.Gen
DrWeb 5.0.0.12182 2009.12.08 BackDoor.Tdss.based.3
McAfee+Artemis 5825 2009.12.07 Artemis!9D99E88DFEFC
McAfee-GW-Edition 6.8.5 2009.12.08 Trojan.Dropper.Gen
Panda 10.0.2.2 2009.12.08 Suspicious file
Sophos 4.48.0 2009.12.08 Mal/TDSSPack-U
TrendMicro 9.100.0.1001 2009.12.08 BKDR_TDSS.SMA

Sure looks like the TDSS rootkit, based on signature scans.

ThreatExpert isn't able to get much from this binary:

http://www.threatexpert.com/report.aspx?md5=9d99e88dfefc6528f4ba912d9d9b1f19

# Submitted sample:

* File MD5: 0x9D99E88DFEFC6528F4BA912D9D9B1F19
* File SHA-1: 0x1BEFD04012D725FA38C5F58E50DDDFD29C7A8CAD
* Filesize: 62,464 bytes
* Alias: Mal/TDSSPack-U [Sophos]

I recall TDSS being analyzed previously, however I would like to see what this particular variant is doing. This will be covered in part three, if it's actions are unique.

•