Peeling Apart TDL4 and Other Seeds of Evil Part II

(please excuse the lousy formatting, blogger doesn't handle these posts too well)

This is the second in an intended series discussing analysis on a compromised XP SP3 machine. Multiple malware components were found on the system and I shall try to describe the analysis processes I used in an attempt to provide something of interest. In some cases, this information consists simply of notes taken during the observation process and further research may be required to gain full insight.

This entry shall focus on the properties and observed behavior uncovered during dynamic analysis of the infected system with regards to the TDL4 components. This entry is not necessarily complete or fully accurate and some of this information may have been published elsewhere. Any constructive corrections or comments welcomed. Flames to /dev/loopback for instant karma.

Network Traffic with a TDL4 clickserver

As documented by others, the TDL clickserver is involved in the click fraud process. The TDL4 configuration file containing the clickserver, (csrv=http://lkckclckl i1i.com/ - space added) was obtained as discussed in Part I and a pcap shows interaction with the TDL4 click server as follows, interspersed with comments:

1 0.000000   62.122.75.136 TCP 1335 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460

GET /IAt4NbWd6K3MCno0Y2xrPTIuMSZiaWQ9NTFkZDJhNTEzNzIwMWMwMzFkY2M3ODNlZmI0NDBlOTc1ZDY4MDdhMyZhaWQ9MzAwMDImc2lkPTAmcmQ9MA==25c HTTP/1.1

Accept-Language: en-us

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2)

Host: lkckclckli1i.com

Cache-Control: no-cache

The GET parameter is obviously base64 and a quick decode indicates the following data sent to the clickserver:

  x5����

z4clk=2.1&bid=51dd2a5137201c031dcc783efb440e975d6807a3&aid=30002&sid=0&rd=0

I do not know what all the fields mean - here is a guess:

x5           ? 

z4           ?

clk=2.1    the version of the clickserver code inside one of the TDL4 DLL's

bid=        bot ID, a unique identifier corresponding to each unique infection

aid=        Affiliate ID, found in the main config file (the ID matches)

sid=        ?

rd=         ?

There are a few non-printable bytes included at the start of the string. We can see the affiliate ID (aid=) being passed upstream. If one might be able to sniff a TDSS clickserver or other upstream element, it might be interesting to get a sense of how the affiliate traffic and payment was being handled, as well as being able to map which affiliates have which compromised resources. I'm not aware of any public maps of the various affiliate goals and methods, but I'll guess that they are probably typical crap - making money through whatever means (fake av, spam, clickfraud, perhaps banking trojans, etc)

These parameters and the version variable are a function of TDL's cmd.dll as found at cmd.dll (after UPX layer unpacked) loc_1000205D:

We can see in the following pcaps the use of the common nginx webserver and the use of keywords functionality. In this case, "ford explorer keyless entry" seems to be the hot item. The clickserver returns URL's to links containing the phrase.

HTTP/1.1 200 OK

Server: nginx/0.8.48

Date: Tue, 14 Dec 2010 22:16:02 GMT

Content-Type: text/html

Connection: close

X-Powered-By: PHP/5.2.10-2ubuntu6.5

Vary: Accept-Encoding

Content-Length: 1377

http://c3.lkckclckl1i1i.com/kZH1xjjL8y4MDjU2ecb09fdc5a3678d9836beadbacfea8ec05x|http://austin-apartment-net.com/result.php?Keywords=ford+explorer+keyless+entry&r=e31c7caa0131f5b3e026bd97c7f9fc06d9fe5a4f1fc6a85976f8a1661934dbe753703436f17f9a233337f1eb70166810&Submit=Go|5|331

As of this writing, the austin-apartment-net.com isn't active, returning a blank page and "" in the HTML source, indicating a possible takedown or an attempt to hide. 

http://c3.lkckclckl1i1i.com/Vv34kmOe6j4JKys331f8e2a2297518b172db5069b90e36dc26Z|http://airplane-rental.com/result.php?Keywords=ford+explorer+keyless+entry&r=e31c7caa0131f5b3e026bd97c7f9fc06d9fe5a4f1fc6a85976f8a1661934dbe753703436f17f9a233337f1eb70166810&Submit=Go|1|1800

http://c3.lkckclckl1i1i.com/9Aw1T13P5A4JVPo2b3dc1edd422aaab342982924c4ccd9bb35g|http://clock.com/search.php|6|297

An attempt to access the first portion of this URL prior to the first pipe results in an interesting re-direction to a localhost resource as a result of an HTTP 301 "Moved Permanently" from the server to http://127.0.0.1. Perhaps this has been done because the link used is stale and it's obviously so to the server which then does the re-direct. 

http://c3.lkckclckl1i1i.com/9Aw1T13P5A4JVPo2b3dc1edd422aaab342982924c4ccd9bb35g

HTTP/1.1 301 Moved Permanently

Server: nginx/0.8.48

Date: Mon, 10 Jan 2011 05:55:35 GMT

Content-Type: text/html

Connection: close

X-Powered-By: PHP/5.2.10-2ubuntu6.5

Cache-Control: no-cache, must-revalidate

Expires: Sat, 26 Jul 1997 05:00:00 GMT

Location: http://127.0.0.1/

Vary: Accept-Encoding

Content-Encoding: gzip

Content-Length: 20

I didn't specifically trace this, but it seems that the re-direct to the localhost resource triggers an interaction between NoScript's Application Boundary Enforcer (ABE) and Firefox's chrome://browser/content/browser.xul element.

An attempt to access chrome://browser/content/browser.xul was detected. Since I'm not the browser hacker like people such as .mario and kuza55, I wasn't sure what this did. Accessing this resource embeds another browser window within the browser as such:

I haven't traced the behavior but I suspect that this is just a Firefox-specific trick to open a browser window to the sites that the clickserver wants the infected machine to access, or it's a technique to attempt to leverage a plugin, perhaps one that was dropped by TDL itself that's not present on this particular analysis machine at this time. Or it could be just part of NoScript. 

*MORE INVESTIGATION NEEDED HERE*

More network-based activity:

http://c3.lkckclckl1i1i.com/bKC34McD7E7JC0O3bc38ce92494413c274bab6a58cae244b15c|http://airstreamcamper.com/result.php?Keywords=ford+explorer+keyless+entry&r=e31c7caa0131f5b3e026bd97c7f9fc06d9fe5a4f1fc6a85976f8a1661934dbe753703436f17f9a233337f1eb70166810&Submit=Go|3|300

http://c3.lkckclckl1i1i.com/bKN3zi7l8w4yOjO8f73956a4f9ce1ba7a878bffae372ee9216x|http://djkrush.com/search.php|3|300

http://c3.lkckclckl1i1i.com/EAZ4ob7p8O3xqfc3240634f8b6e2a5c49d4e26758a3bb3a218x|http://cerigua.com/search.php|3|150

http://c3.lkckclckl1i1i.com/jZG4yUYp535J8qu9885347614e80822a61dcee8438d7930a16Z|http://charitywalk.org/search.php|3|300

http://c3.lkckclckl1i1i.com/VaG2MwCd5X3j8tS7c3062e7ff8152dac465433c4c31112cd28c||3|300

I am not aware of the purpose of the encrypted/encoded blob or of the parameters passed within the pipe characters but the pattern makes for easy sniffing. I haven't checked the newest versions of TDL to see if the pattern is the same, so this information may be outdated. 

Poking about inside CMD.DLL

There are several DLL's included in the TDL4 file system and once they are dumped, I found that cmd.dll (my first analysis target) was trivially packed with UPX. This is of course easily determined through a variety of means (PEid for instance) but in this case I discovered it through IDA:

Poking about inside the CMD.DLL reveals a variety of useful tidbits, including the following user-agent string, easily fingerprintable, in the .rdata section:


.rdata:1000863C aMozilla4_0Comp db 'Mozilla/4.0 (compatible; MSIE 1.0; Windows NT; CMD3)',0


Emerging Threats published a signature for this recently, on 2/21/2011:


http://lists.emergingthreats.net/pipermail/emerging-sigs/2011-February/012049.html


This data was known for some time, as discussed on the kernelmode.info forum, and surely people have made private signatures for this trivially detected indicator, but I am surprised that it took so long for a public signature to be written. This goes to show that there is always more to learn, even if this particular DLL has been analyzed by many.


A mutex, used at least since TDL3, is easily found:


.rdata:100085E0 aGlobal3006345f db 'Global\3006345f-6baf-4669-a7e1-aaa310564be9',0


This data could be placed into a YARA rule for use with Volatility, or an Indicator of Compromise for use with Memoryze.


Since I have read some of the analysis papers on TDL by Kaspersky and other anti-malware organizations, I recall that while TDL can load anything the default functionality is for click fraud. I'm guessing here that the default click-fraud component of TDL seems to have many targets, as seen in the useful .rdata section:

CMD.DLL implements an HTTP/302 found shortly thereafter, suggesting a redirection associated with these sites to itself in order to inject clickable items. 


RFC2616 describes 302 Found as such:

The requested resource resides temporarily under a different URI. 

The configuration file, cfg.ini, is built by functions in cmd.dll through calls to WritePrivateProfileStringA. Many values that populate the config file are stored within cmd.dll. Here we can see a few of the various values:

And the locations that store some of the URL's:

Some of these URL's, such as https://61.61.20. 132 and https://34jh7alm94. asia, (spaces added) are not in the config file, but other values are. The .asia domain appeared around March 2010 in TDL3 config files as a srv= value, but is not in this file, obtained from a TDL4 infection in late 2010. The config file (spaces added to prevent accidental click and/or blacklisting of the blog):

[main]
version=0.02
aid=30002
sid=0
builddate=4096
rnd=1035525444
knt=1288036792
[inject]
*=cmd.dll
[cmd]
srv=https://rukkeianno .com/;https://86b6b96b .com/;https://kangojjm1 .com/;https://lkaturl71 .com/
wsrv=http://skolewcho .com/;http://jikdooyt0 .com/;http://swltcho81 .com/;http://switcho81 .com/;http://rammyjuke .com/
psrv=http://crj71ki813ck. com/
version=0.15
bsh=51dd2a5137201c031dcc783efb440e975d6807a3
delay=7200
csrv=http://lkckclckli1i .com/
[tasks]

Some javascript hackery is injected into the browser - we can see the forced click on a GET method form being performed:

Within the same overall function we next see a javascript history.back function, then a (faked) HTTP/200 OK status code sent to the browser from within the DLL:

Here we see the associated .rdata sections expand the values pushed onto the stack:

TDL4's cmd.dll has support for a variety of browsers (the usual IE and Firefox plus Chrome, Opera, Safari, Netscape, Avant, "*browser*", Mozilla), and the windows update function (wuauclt). Amazing that there is enough return on investment for the TDL authors to consider long-dead browsers such as Netscape; perhaps this function was easy to code or ripped from somewhere else, or perhaps it's the same code from older versions that still found some of these browsers in use more frequently.

There are many other interesting elements inside CMD.DLL, but I will save them, as well as analysis of other components of TDL for another entry.