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
}
{
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.
Posts
