We will be returning in the near future!

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. 

Peeling Apart TDL4 and Other Seeds of Evil Part I

This is the first 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.

Emerging Threats signature-based alert

The first indicator of any issue was the firing of an Emerging Threats signature ET 2010823 on an EXtrusion Detection System (figuratively named because the main focus is detection of compromised internal systems via outbound traffic patterns).

#matt jonkman, re 3fac60b31a7cda96e217c86405fcc48c
#
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Torpig Related Fake User-Agent (Apache (compatible...))"; flow:established,to_server; content:"User-Agent|3a| Apache (compatible|3b| MSIE 6.0|3b| Windows NT 5.1|3b| SV1)"; http_header; classtype:trojan-activity; reference:url,doc.emergingthreats.net/2010823; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Torpig; sid:2010823; rev:4;)

Having previously torn apart aspects of Mebroot and Torpig, I figured this would be a fast process, however no Torpig infection could be found, based on the typical indicators as discussed elsewhere and in previous blog entries. Perhaps the signature referred to a "Torpig Related" scenario - meaning not Torpig itself, but a different type of malware that perhaps came down from a Neosploit kit that has often been known to drop Mebroot & Torpig, or another malware that had some other Torpig association.

I first made a dd diskimage and took a memdump for further analysis with the Volatility Framework. For unknown reasons, my memdump tool of choice Moonsols win32dd did *not* work on this box - but Mandiants memorydd.bat worked properly. The error messages seen below are not a concern, they are just indicators that not all areas of memory can be safely read. AFAIK this is not a tactic to hide malware from a memory dumping function, but surely anti-dumping techniques are being researched and implemented as these techniques become more common.

Team CYMRU's WinMHR in action

Next, I took this engagement as an opportunity to play with the relatively new WinMHR (Malware Hash Repository) tool released by the helpful "behind the scenes" Team CYMRU (https://www.team-cymru.org/Services/MHR/WinMHR/)that compares MD5 hashes from files/directories or processes with an extensive hash collection accessible on a server maintained by Team CYRMR.  As expected, WinMHR found multiple indicators of malware on the system that were not found by the currently installed anti-malware apps on the box (McAfee Enterprise, Spybot Search & Destroy, Malware Bytes Anti-Malware) when scanning from within the infected system itself and from a mounted drive.

Obviously, binaries/PDF's/etc that are dynamically obfuscated are going to be harder to find by static hash matching, but there were enough static components found to provide insight. A curious element from scanning the infected system itself was that WinMHR detected malware inside of Windows\System32\userinit.exe yet the disk copy perfectly hash-matched a clean copy. However, as I would learn later the in-memory version of userinit.exe was indeed infected. A little digging and I soon determined that TDL3 was known to infect userinit.exe in a similar manner, which set my sights on detecting TDL as the next meaningful step. (Further results from the use of WinMHR will be discussed in later parts of this series, as long as I stay motivated and don't get too lazy)

Finding TDL

TDL is a rootkit like malware distribution system that takes control of the system at boot time with a default behavior involving click fraud and has been well documented by various researchers from F-Secure, ESET, Kaspersky, the KernelMode.info forum and others. I will not duplicate the results of their research here.

TDL was easy to find - multiple tools confirmed it's presence.

mbr.exe from gmer.net:

detected hooks:
\Driver\atapi DriverStartIo -> 0x82133999
user != kernel MBR !!!
sectors 80293246 (+255): user != kernel
Warning: possible TDL4 rootkit infection !
TDL4 rootkit infection detected ! Use: "mbr.exe -f" to fix.  

I do not know for certain, but I had read that replacing atapi.sys was one quick method to neuter a TDL infection. TDL is known to create it's own encrypted filesystem at the end of the disk (similar to where Mebroot stashes it's malicious driver) and according to some forum message I read, the atapi.sys replacement method leaves the TDL filesystem intact but it's no longer operational in that it's various DLL's are no longer injected into the running system at boot time.

GMER also finds it easily:

---- Disk sectors - GMER 1.0.15 ----

Disk            \Device\Harddisk0\DR0  sector 00 (MBR): rootkit-like behavior; TDL4  <-- ROOTKIT !!!
Disk            \Device\Harddisk0\DR0  sector 10: rootkit-like behavior; 
Disk            \Device\Harddisk0\DR0  sector 63: rootkit-like behavior; 
Disk            \Device\Harddisk0\DR0  sectors 80292992 (+255): rootkit-like behavior; 

I did not yet want to "clean" TDL4 from the system but after a variety of reading, I learned that apparently most "cleaning" tools could not handle TDL4 yet. Some "cleaning" attempts were resulting in crashes boxen and fsked up file systems. Supposedly, HitMan Pro could do it, but I did not try it. Kaspersky offers a TDSSKiller tool, which readily detected TDL4 but was reportedly only able to "clean" a TDL3 infection on Nov 10. Since then, Kaspersky has updated TDSSKiller and it does indeed work with the TDL4 infection that I dealt with.

TDSSKiller log shows:

2010/11/10 15:33:03.0640 \HardDisk0 - detected Rootkit.Win32.TDSS.tdl4 (0) 

Obtaining access to the TDL4 file system and configuration
 

A tweet and article (TDL3: The Rootkit of All Evil?) by Aleksandr Matrosov from ESET informed me that he had written a dumper tool that pulled the typically known files from the TDL3 file system, allowing further inspection. Unfortunately, this tool did not work on the TDL4 infection.

I offer my gratitude to Michael Hale Ligh, one of the authors of the excellent Malware Analysts Cookbook, who wrote a YARA plugin to work with the Volatility Framework that would allow one to dump the special path to the TDL File System from a memdump. The path is designated from the globalroot object.  I had to load up the newest development version of Volatility (1.4) in order to utilize the YARA rule, which was a little confusing as the structure has changed from 1.3, but this particular technique worked like a charm to reveal the path. I learned there are many other ways of finding that path data, but Michael pointed the way. His work is shared with permission.

Michael's YARA rule is as follows:

rule tdl3
{
   meta:
   null_string = 1

   strings:
   $ = "\\\\?\\globalroot\\"
   $ = ".ini"   

   condition:
   all of them     
}

And a portion of an example output:

$ python volatility.py malfind -Y tdl3.rules -f memory.dmp -D outdir

svchost.exe  1048 0x01F50000 0x01F65FFF VadS
Dumped to: outdir/svchost.exe.164bc28.01f50000-01f65fff.dmp

YARA rule: tdl3
Hit: \\?\globalroot\device\00000f9f\4038b10d
Hit: \\?\globalroot\device\00000f9f\4038b10d\cfg.ini

The last two elements of the TDL filesystem directory structure (before the filename) change at each reboot. Once the path is known, the files can be dumped. I used a tool Michael wrote called tdlcopy.exe that he was kind enough to share.

TDL4 is well known to be an emergent 64-bit infecting malware (infects 32 bit too, of course). The 32 and 64 bit elements can be easily seen in the files dumped above. I was interested in the configuration file, having seen examples from research papers mentioned earlier, because sitenames and other data could open the door for further queries for detection and containment as well as research.

The format of the config file is explained elsewhere, but TDL4 seems to have slightly modified the wording from a TDL3 config. In this particular infection, we can see that the affiliate ID is 30002 (someone out there is using this affiliate, perhaps through the Dogma Millions group) and that cmd.dll is going to be injected, as this was a 32 bit box. The various domain names for the different aspects of this particular infection are listed below. Many of these are already well-known. Warning: links are probably still live - don't mess around and please treat very carefully (I've added some spaces to avoid accidental use). While many probably already have this information and more, these domains are included for response and detection purposes.

cfg.ini:

[main]
version=0.02
aid=30002
sid=0
builddate=4096
rnd=1035525444
knt=1288036792
[inject]
*=cmd.dll
[cmd]
srv=https://ruk keianno.com/;https://86b  6b96b.com/;https://kango jjm1.com/;https://lkatu rl71.com/
wsrv=http://skolew cho.com/;http://jikdo oyt0.com/;http://swltc ho81.com/;http://switcho 81.com/;http://rammyju ke.com/
psrv=http://crj71ki8 13ck.com/
version=0.15
bsh=51dd2a5137201c031dcc783efb440e975d6807a3
delay=7200
csrv=http://lkckclckl i1i.com/
[tasks]

Quick enumeration with Process Hacker

Poking around with Process Hacker into various aspects of the running infected system also revealed the TDL4 path a little easier than using the YARA rule and a memdump, although one could also just grep the globalroot path from a memdump file without even having to use Volatility. Since TDL invades the system, it leaves traces everywhere. In this particular example, I took note of a RWX memory section inside the ISUSPM.exe process:

Analyzing this Private section further, we find the TDL cmd.dll loaded:

The system was rebooted several times during analysis, which accounts for the changing TDL file system paths.

The next series of blog entries shall cover TDL4 network traffic observed, a SOCKS proxy service installed on the host and it's control traffic, an FTP password stealer application & Symantec antivirus disabler, and other interesting artifacts from the infection clusterfsck. 

A Shot in the Dark - Analysis of a Failed Malware Attack

Rather than let this entry stagnate on the hard drive, I've elected to share it while it may still be of potential research interest. 

This is a brief (and incomplete) analysis of a semi-targeted malware attack attempt from June 23, 2010. The attack failed, but not before enough artifacts were obtained to take a peek at the motives at play. I call this semi-targeted because the mail message was apparently not received by a large number of people and the hosted binaries vanished very quickly. These factors may not be enough for this to truly be a semi-targeted attack, but in the absence of other information this designation will have to do.

Detection statistics reflect the date & time of initial analysis (late June 2010), not the time of the creation of this entry (August 2010, slacker)

June 23, 2010 an email was received:  

The fake careerbuilder.com link actually pointed to http://www.zewiundbebe-jou.ch/resume.pdf which was a PE file that had yet to be specifically encountered by VirusTotal although it did trigger various generic signatures.

File size: 83968 bytes
MD5   : 1717b7fff97d37a1e1a0029d83492de1
SHA1  : c79a326f8411e9488bdc3779753e1e3489aaedea

Static antivirus via VirusTotal indicated detection by 20/41 (48.78%)

http://www.virustotal.com/analisis/ec44c6ab3090bb91ec04e37a5fe31c313c92e8455c9f6d579cdc7ce29 6d723be-1277318724

Antivirus	Version	Last Update	Result
a-squared	5.0.0.30	2010.06.23	Win32.SuspectCrc!IK
AhnLab-V3	2010.06.23.01	2010.06.23	-
AntiVir	8.2.4.2	2010.06.23	TR/Dldr.Delphi.Gen
Antiy-AVL	2.0.3.7	2010.06.23	-
Authentium	5.2.0.5	2010.06.23	W32/Delfloader.B.gen!Eldorado
Avast	4.8.1351.0	2010.06.23	-
Avast5	5.0.332.0	2010.06.23	-
AVG	9.0.0.836	2010.06.23	-
BitDefender	7.2	2010.06.23	Gen:Trojan.FirewallBypass.fKW@aqsq81n
CAT-QuickHeal	10.00	2010.06.23	-
ClamAV	0.96.0.3-git	2010.06.23	-
Comodo	5195	2010.06.23	Heur.Packed.Unknown
DrWeb	5.0.2.03300	2010.06.23	-
eSafe	7.0.17.0	2010.06.23	-
eTrust-Vet	36.1.7661	2010.06.23	-
F-Prot	4.6.1.107	2010.06.23	W32/Delfloader.B.gen!Eldorado
F-Secure	9.0.15370.0	2010.06.23	Gen:Trojan.FirewallBypass.fKW@aqsq81n
Fortinet	4.1.133.0	2010.06.23	-
GData	21	2010.06.23	Gen:Trojan.FirewallBypass.fKW@aqsq81n
Ikarus	T3.1.1.84.0	2010.06.23	Win32.SuspectCrc
Jiangmin	13.0.900	2010.06.15	-
Kaspersky	7.0.0.125	2010.06.23	Heur.Trojan.Generic
McAfee	5.400.0.1158	2010.06.23	Suspect-06!1717B7FFF97D
McAfee-GW-Edition	2010.1	2010.06.23	Heuristic.BehavesLike.Win32.Keylogger.J
Microsoft	1.5902	2010.06.23	TrojanDownloader:Win32/Small.gen!AO
NOD32	5223	2010.06.23	probably a variant of Win32/TrojanDownloader.Banload.BJY
Norman	6.05.10	2010.06.23	W32/Downloader
nProtect	2010-06-23.02	2010.06.23	Gen:Trojan.FirewallBypass.fKW@aqsq81n
Panda	10.0.2.7	2010.06.23	Trj/CI.A
PCTools	7.0.3.5	2010.06.23	-
Prevx	3.0	2010.06.23	-
Rising	22.53.02.04	2010.06.23	Trojan.DL.Win32.Downloader.GEN
Sophos	4.54.0	2010.06.23	Sus/Delf-J
Sunbelt	6494	2010.06.23	-
Symantec	20101.1.0.89	2010.06.23	-
TheHacker	6.5.2.0.303	2010.06.23	-
TrendMicro	9.120.0.1004	2010.06.23	-
TrendMicro-HouseCall	9.120.0.1004	2010.06.23	-
VBA32	3.12.12.5	2010.06.23	suspected of Win32.Trojan.Downloader (http://...)
ViRobot	2010.6.21.3896	2010.06.23	-
VirusBuster	5.0.27.0	2010.06.23	-

ThreatExpert is a huge time-saver, except in the case that it cannot analyze something because it's been built in such a manner to bypass Threat Expert specifically or generically (TDSS comes to mind, along with some VM-packer based  binaries that I've tried to run through the sandbox)

The interesting portions of the ThreatExpert report from the successful scan of the first binary
(http://www.threatexpert.com/report.aspx?md5=1717b7fff97d37a1e1a0029d83492de1) are as follows:

Alias:
New Malware.ai  [McAfee]
TrojanDownloader:Win32/Small.gen!AO  [Microsoft]

Running the binary in ThreatExpert results in the following (real or faked?) Adobe message one sees when trying to open content made in a newer version. I'm not certain which version of Adobe Reader is installed inside ThreatExpert, but various HTTP transactions to Adobe took place around the same time as the display of this message which makes me think that it's a legitimate message and not a fake.

Files created:

C:\resume.pdf     31,268 bytes  MD5: 0xAB48D6582C0DE8936EBD891D246AD359
%Windir%\inf\alg.exe   660,992 bytes MD5: 0x100C62729E997E6FCC1997E7BDDED0D7

Alg.exe is configured to run as a service named “WSALG2” with display name “Application Layer
Gateway Service2”. Initially the service is stopped. The following Registry Keys were created:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\WSALG2
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\WSALG2\Security
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSALG2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSALG2\Security

The newly created Registry Values are:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\WSALG2\Security]
Security = 01 00 14 80 90 00 00 00 9C 00 00 00 14 00 00 00 30 00 00 00
02 00 1C 00 01 00 00 00 02 80 14 00 FF 01 0F 00 01 01 00 00 00 00 00
01 00 00 00 00 02 00 60 00 04 00 00 00 00 00 14 00 FD 01 02 00 01 01
00 00 00 00 00 05 12 00 00 00 00 00 18 00 FF 01 0F 0

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\WSALG2]
  Type = 0x00000110
  Start = 0x00000002
  ErrorControl = 0x00000001
  ImagePath = "%Windir%\inf\alg.exe"
  DisplayName = "Application Layer Gateway Service2"
  ObjectName = "LocalSystem"
  Description = "Provides support for 3rd party protocol plug-ins for
Internet Connection Sharing and the Windows Firewall."

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSALG2\Security]
Security = 01 00 14 80 90 00 00 00 9C 00 00 00 14 00 00 00 30 00 00 00
02 00 1C 00 01 00 00 00 02 80 14 00 FF 01 0F 00 01 01 00 00 00 00 00
01 00 00 00 00 02 00 60 00 04 00 00 00 00 00 14 00 FD 01 02 00 01 01
00 00 00 00 00 05 12 00 00 00 00 00 18 00 FF 01 0F 0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSALG2]
  Type = 0x00000110
  Start = 0x00000002
  ErrorControl = 0x00000001
  ImagePath = "%Windir%\inf\alg.exe"
  DisplayName = "Application Layer Gateway Service2"
  ObjectName = "LocalSystem"
  Description = "Provides support for 3rd party protocol plug-ins for
Internet Connection Sharing and the Windows Firewall."

ThreatExpert says the file may come from Belize. The binary was built with Delphi.

A variety of outbound HTTP connections were made to 194.150.249.52 (resolves as
ns84.tophost.ch but was queried as zewiundbebe-jou.ch in this case) and 208.50.81.170 (no
DNS name, hosted by Global Crossing, likely a load balanced adobe update site)

The data identified by the following URLs was then requested from the remote web
server:

  http://www.zewiundbebe-jou.ch/resume.jpg  <- we care about this one
  http://update.adobe.com/pub/adobe/acrobat/js/6.x/rdr/win/enu/DataScript.js
  http://update.adobe.com/pub/adobe/acrobat/js/6.x/rdr/win/enu/CodeScript.js
  http://update.adobe.com/pub/adobe/acrobat/js/6.x/rdr/win/enu/UIScript.js
  http://update.adobe.com/pub/adobe/acrobat/js/6.x/rdr/win/enu/ResourceScript.js
  http://update.adobe.com/pub/adobe/acrobat/js/6.x/rdr/win/enu/MasterScript.js

Similar malware incidents are documented in the next two links:

http://threatexpert.com/report.aspx?md5=eb3140416c06fa8cb7851076dd100dfb 

The common elements are that the malware drops c:\resume.pdf, uses the \inf folder, creates a service
named WSALG2 with display name “Application Layer Gateway Service2”, creates identical registry
entries for the service, appears to be from Belize.

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

 Another description of an incident -

http://greatis.com/blog/how-to-remove-malware/svchost-exe-csrss-exe.htm 

shows similar characteristics with references to the Win32.Genome malware family and references to
Banload.

resume.jpg is clearly a file of interest in this case. It’s another Delphi binary file.

File size: 660992 bytes
MD5   : 100c62729e997e6fcc1997e7bdded0d7

As this is the secondary payload and likely to be considered of higher value to the attacker, I suspect it was engineered to evade more antivirus tools. VirusTotal detection is lower, 8/41, about 20%.

http://www.virustotal.com/analisis/7ece2a68bf14afe658edbbb83c6f8f3a8b1bd989cc55f5daf844411bf9 545018-1277328611

Antivirus	Version	Last Update	Result
a-squared	5.0.0.30	2010.06.22	-
AhnLab-V3	2010.06.22.00	2010.06.22	-
AntiVir	8.2.2.6	2010.06.21	TR/ATRAPS.Gen
Antiy-AVL	2.0.3.7	2010.06.22	-
Authentium	5.2.0.5	2010.06.22	W32/SysVenFak.A.gen!Eldorado
Avast	4.8.1351.0	2010.06.21	-
Avast5	5.0.332.0	2010.06.21	-
AVG	9.0.0.787	2010.06.21	-
BitDefender	7.2	2010.06.22	Gen:Trojan.Heur.OK0@trs3QZoiC
CAT-QuickHeal	10.00	2010.06.22	-
ClamAV	0.96.0.3-git	2010.06.22	-
Comodo	5180	2010.06.22	TrojWare.Win32.Spy.Banker.Gen
DrWeb	5.0.2.03300	2010.06.22	-
eSafe	7.0.17.0	2010.06.20	-
eTrust-Vet	36.1.7657	2010.06.22	-
F-Prot	4.6.1.107	2010.06.21	W32/SysVenFak.A.gen!Eldorado
F-Secure	9.0.15370.0	2010.06.22	Gen:Trojan.Heur.OK0@trs3QZoiC
Fortinet	4.1.133.0	2010.06.21	-
GData	21	2010.06.22	Gen:Trojan.Heur.OK0@trs3QZoiC
Ikarus	T3.1.1.84.0	2010.06.22	-
Jiangmin	13.0.900	2010.06.15	-
Kaspersky	7.0.0.125	2010.06.22	-
McAfee	5.400.0.1158	2010.06.22	-
McAfee-GW-Edition	2010.1	2010.06.22	-
Microsoft	1.5902	2010.06.22	-
NOD32	5216	2010.06.21	-
Norman	6.05.06	2010.06.21	-
nProtect	2010-06-21.01	2010.06.21	-
Panda	10.0.2.7	2010.06.21	-
PCTools	7.0.3.5	2010.06.22	-
Prevx	3.0	2010.06.23	Medium Risk Malware
Rising	22.53.01.04	2010.06.22	-
Sophos	4.54.0	2010.06.22	-
Sunbelt	6483	2010.06.21	-
Symantec	20101.1.0.89	2010.06.22	-
TheHacker	6.5.2.0.302	2010.06.22	-
TrendMicro	9.120.0.1004	2010.06.22	-
TrendMicro-HouseCall	9.120.0.1004	2010.06.22	-
VBA32	3.12.12.5	2010.06.22	-
ViRobot	2010.6.21.3896	2010.06.22	-
VirusBuster	5.0.27.0	2010.06.21	-
Additional information
File size: 660992 bytes
MD5: 100c62729e997e6fcc1997e7bdded0d7

This time, ThreatExpert generates almost no output with resume.jpg except to tell us that it’s probably from Belize. Not too useful.

Anubis is able to deliver a partial analysis of the file -

http://anubis.iseclab.org/?action=result&task_id=14746a621c57c8164e100e15a56aadc5c&format=html 

Interesting items from the Anubis analysis:

- Registry Values Read:

Key	Name	Value	Times
HKLM\​SOFTWARE\​Microsoft\​CTF\​SystemShared\​	CUAS	0	1
HKLM\​SOFTWARE\​Microsoft\​Windows NT\​CurrentVersion\​FontSubstitutes	MS Shell Dlg 2	Tahoma	4
HKLM\​SYSTEM\​CurrentControlSet\​Control\​Session Manager	CriticalSectionTimeout	2592000	1
HKLM\​Software\​Policies\​Microsoft\​Windows\​Safer\​CodeIdentifiers	TransparentEnabled	1	1
HKLM\​System\​CurrentControlSet\​Control\​ComputerName\​ActiveComputerName	ComputerName	PC	3
HKLM\​System\​CurrentControlSet\​Control\​ServiceCurrent		8	1
HKLM\​System\​CurrentControlSet\​Control\​Terminal Server	TSUserEnabled	0	1
HKU\​S-1-5-21-842925246-1425521274-308236825-500\​Keyboard Layout\​Toggle	Language Hotkey	1	2
HKU\​S-1-5-21-842925246-1425521274-308236825-500\​Keyboard Layout\​Toggle	Layout Hotkey	2	2

“Cicero Unaware Application Support (CUAS). CUAS is a feature of the Microsoft Windows XP operating
system that provides support for Advanced Text Services. Examples of these services include
handwriting recognition, speech recognition, and East Asian keyboard input services.”
http://support.microsoft.com/kb/822656 

Hmm, East Asian keyboard input services. Anyone who has studied any sort of malware knows that this could be significant, suggesting that the malware either does, or does not want to target a particular population.

Query of \Safer\CodeIdentifiers\TransparentEnabled Checks if Windows Software Restriction Policies
are enabled. In this case, they are (value of 1).

TSUserEnabled checks to see if terminal server users have slightly higher permissions due to their
placement in the TERMINAL SERVER USER group.

Language Hotkey is perhaps being queried to determine the language in use on the infected system.

Next,  the EventLog RPC service named pipe PIPE\Eventlog  is read and modified, and a control code is
involved in three interactions. The control code is 0x0011C017 which is FSCTL_PIPE_TRANSCEIVE,
involved in the sending and receiving of data from an open pipe.  There are two elements, a  request
and a response.  If data is in the buffer when the request is called, it’s written to the pipe in a binary
blob. The response gives a status message on how the blob was handled.  I’m not sure this is relevant for
the analysis, but Anubis doesn’t go into enough detail to determine.

http://msdn.microsoft.com/en-us/library/dd240221%28v=PROT.13%29.aspx 

Some interaction with Ksecdd.sys takes place, but I am unable to determine relevance.

Several mutexes are created:

CTF.Asm.MutexDefaultS-1-5-21-842925246- 1425521274-308236825-500
CTF.Compart.MutexDefaultS- 1-5-21-842925246-1425521274-308236825-500
CTF.LBES.MutexDefaultS-1- 5-21-842925246-1425521274-308236825-500
CTF.Layouts.MutexDefaultS- 1-5-21-842925246-1425521274-308236825-500
CTF.TMD.MutexDefaultS-1- 5-21-842925246-1425521274-308236825-500
CTF.TimListCache.FMPDefaultS- 1-5-21-842925246-1425521274-308236825-500MUTEX.DefaultS-1-5-21-842925246-1425521274-308236825-500

The relevance of these is unknown and is either left as an exercise to the reader or is something I might look into at a later time.

A Structured Exception Handling (SEH) exception takes place one time:

Exception 0x406d1388 at 0x7c812aeb

Apparently calling RaiseException with this code gets the attention of a debugger and may be used to
name threads  (http://www.highprogrammer.com/alan/windev/visualstudio.html). This URL refers to
Visual Studio, however this binary is written in Delphi. RaiseException may not care.

In this case, I suspect (but have not verified) that it may be used to interfere with execution in a
debugging/emulated environment.  It was mentioned that 0x406d1388 messes up WINE in the following
message: http://www.winehq.org/pipermail/wine-devel/2001-April/000540.html


Analyzing strings from the binary in IDA points us to other conclusions not possible in the sandboxed
environments.

The binary spoofs a typical browser user-agent (labeled “Browser_Spoof” here)

.text:00484DC0 Browser_Spoof   db 'Mozilla/4.0 (compatible; MSIE 6.1; Windows XP; .NET CLR 1.1.4322;' 
.text:00484DC0                 ; DATA XREF: sub_484C00+55o 
.text:00484DC0                 db ' .NET CLR 2.0.50727)',0 

Binary contains a variety of obvious commands to an HTTP-based command and control server, such as the
checkupdate command  (labeled ‘CheckUpdate” here). Such command structures make for useful IDS signatures.

.text:00484E20 CheckUpdate     db '?action=checkupdate&v=',0 ; DATA XREF: sub_484C00+6Fo 

An update command:

.text:00484E84 Update          db '?action=update&v=',0 ; DATA XREF: sub_484C00+EFo 

A chkcmd command:

.text:00484F2D                 push    offset a?actionChkcmdV ; "?action=chkcmd&v=" 


Offers some type of WebDAV functionality (TRACE, OPTIONS, DELETE)

Contains cookie handling code (Comment URL, DISCARD, Port)

Is proxy aware (or maybe runs it’s own proxy?)
.text:0047F398 aProxyAuthoriza db 'Proxy-Authorization',0 ; DATA XREF: sub_47F2C8+3Ao

.text:0047F398                                         ; sub_47F2C8+98o

.text:0047F3AC                 dd 0FFFFFFFFh, 8

.text:0047F3B4 aUsername_0     db 'Username',0         ; DATA XREF: sub_47F2C8+62o

.text:0047F3BD                 align 10h

.text:0047F3C0                 dd 0FFFFFFFFh, 8

.text:0047F3C8 aPassword_0     db 'Password',0         ; DATA XREF: sub_47F2C8+72o

Options to install, uninstall, and silent:

.text:0045DB64                 mov     eax, offset aInstall ; "INSTALL"

.text:0045DDA0 aSilent         db 'SILENT',0           ; DATA XREF: sub_45DB38+3Ao

.text:0045DDB0 aUninstall      db 'UNINSTALL',0        ; DATA XREF: sub_45DB38:loc_45DB8Do

 A reference to an Eastern European character set:

.data:00487D74                 dd offset aEasteurope_cha ; "EASTEUROPE_CHARSET"

Other malware has looked for a certain character set and then taken actions based on that. For instance,
Russian users could be excluded from an attack.

The binaries stashed on the attack website were removed from the site in less than 24 hours. Can't imagine that anyone would need them at this stage, but if you do drop me a line or tweet.

I've just learned that the same MD5 for the second binary is still floating about, according to a ThreatExpert report from August 9, 2010:

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

TE is able to identity keylogger and trojan downloader capabilities, but nothing further.

If any researcher has any additional info about this malware, the HTTP command structure or other info I would appreciate any feedback or commentary.

As time allows I may try to analyze this further but at this rate it will be a while. Until then, may your shields be strong.