28 01 2012

Hey all, I decided to go ahead and do a written blog post for this one. This is the first time I have looked into Malware analysis, but I figured why not. It was too cold here in Korea to do anything else. I also wanted to use Volatility and perform some memory forensics.

I went out to; http://www[dot]malwaredomainlist[dot]com/mdl[dot]php and got infected by one of the random pieces of malware. Make sure you do this in an environment that is “safe(er)”. I used an isolated vmware machine.

I figured I would just get started an infect the machine, but before I did I executed regshot prior to executing the malware so I could see what kind of artifacts it showed.

Infection:

According to the report from Regshot after comparing the first and second reg shots there were 12 keys added, 29 values added and 12 values modified for a total of 53 changes. The 12 keys there were added are:
Keys added:12
———————————-
HKU\[Removed_SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\hiv
HKU\[Removed_SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.hiv
HKU\[Removed_SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.hiv\OpenWithList
HKU\[Removed_SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.hiv
HKU\[Removed_SID]\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\13\ComDlg
HKU\[Removed_SID]\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg
HKU\[Removed_SID]\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg\{}
HKU\[Removed_SID]\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg\{}\{}
HKU\[Removed_SID]_Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\13\ComDlg
HKU\[Removed_SID]_Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg
HKU\[Removed_SID]_Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg\{}
HKU\[Removed_SID]_Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\ComDlg\{}\{}

You can look at everything here: Regshot compare list

After taking the regshot I proceeded to pause my VMWare machine and go into where I have my VM and pull the .vmem out, which is basically an image of the current state of your memory. It’s the same as if you used dumpit.exe, FTk, or some other memory acquisition tool. It’s just much faster within a VM environment. I also limit my host VM machine to no more than 2GB of memory to make things a bit faster. I’m just running malware on them so it’s not a big deal.

Ok, now that I have a copy of memory I went ahead and ran my live/volatile data script to acquire the volatile data on my system.

After collecting memory and live data I went ahead and booted up my SIFT Workstation and proceeded to download the latest version of Volatility via svn checkout. You can do the same if you want by going to your command line terminal within SIFT Workstation and typing the following:

SIFT-Workstation:~$ svn checkout http://volatility.googlecode.com/svn/trunk/ [destination_folder]

After that was downloaded I copied the memory image over to the /cases directory on SIFT. Once the memory image was transfered over I fired up volatility and proceeded to take a look at the image. The first command I ran was the imageinfo command and I got the following back;

sansforensics@SIFT-Workstation:~/vol$ python vol.py -f /cases/win7.vmem imageinfo
Volatile Systems Volatility Framework 2.1_alpha
Determining profile based on KDBG search…
          Suggested Profile(s) : Win7SP1x64, Win7SP0x64
          AS Layer1 : AMD64PagedMemory (Kernel AS)
          AS Layer2 : FileAddressSpace (/cases/win7.vmem)
          PAE type : PAE
          DTB : 0×187000
          KDBG : 0xf80002c590a0L
          KPCR : 0xffdff000L
          Number of Processors : 1
          Image Type : Service Pack 1

Now that we know it’s a Windows 7 SP1 x64 image we can set the profile when running the command line arguments. You will see the profile specification in the upcoming commands.

After the image info command I decided to run the userassist registry command to see if I can find anything odd that might have been executed on the system.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 userassist -f /cases/win7.vmem
[snip]
REG_BINARY    C:\Users\Patrick Olsen\Desktop\Up4Ir2-def.exe : 
Count:          1
Focus Count:    0
Time Focused:   0:00:00.500000
Last updated:   2012-01-27 12:09:41 
0×00000000  00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00   …………….
0×00000010  00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf   …………….
0×00000020  00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf   …………….
0×00000030  00 00 80 bf 00 00 80 bf ff ff ff ff d0 8f 80 8c   …………….
0×00000040  ec dc cc 01 00 00 00 00                           ……..
[snip]

Interesting….that seems like an odd file name that was executed…

Let’s see if anything has made any connections.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 netscan -f /cases/win7.vmem
Volatile Systems Volatility Framework 2.1_alpha
[snip]
0x7d681570 TCPv4    0.0.0.0:0                      56.[snip]:0        CLOSED           920      svchost.exe    -
0x7dc33b30 TCPv4    0.0.0.0:0                      56.[snip]:0        CLOSED           920      svchost.exe    -
0x7f670810 TCPv4    0.0.0.0:0                      56.[snip]:0      0x2cc00002       2808     Up4Ir2-def.exe -
0x805c6cf0 TCPv4    0.0.0.0:0                      56.[snip]:0        CLOSED           920      svchost.exe    -
[snip]

I thought these connections seemed a bit odd even though a few of them are closed. Let’s take a closer look at these process ids.

Next I decided to see what processes were running at the time of this “suspected” compromise. I ran the pslist command.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 pslist -f /cases/win7.vmem
Volatile Systems Volatility Framework 2.1_alpha
 Offset(V)  Name                 PID    PPID   Thds   Hnds   Time 
———- ——————– —— —— —— —— ——————- 
[snip]
0xfffffa801b342060 svchost.exe            1052    508     14    356 2012-01-27 11:50:30       
0xfffffa801b63b250 spoolsv.exe            1144    508     14    336 2012-01-27 11:50:31       
0xfffffa801b686b30 svchost.exe            1188    508     18    312 2012-01-27 11:50:31       
0xfffffa801b784890 vmtoolsd.exe           1400    508      8    298 2012-01-27 11:50:31       
0xfffffa801b7ffb30 TPAutoConnSvc.         1552    508      9    131 2012-01-27 11:50:31       
0xfffffa801af19b30 svchost.exe            1680    508      6     93 2012-01-27 11:50:31       
0xfffffa801b8a9890 dllhost.exe            1868    508     13    189 2012-01-27 11:50:31       
0xfffffa801bca4060 msdtc.exe              2028    508     12    144 2012-01-27 11:50:34       
0xfffffa801b3f05e0 svchost.exe            1208    508     10    137 2012-01-27 11:52:31
0xfffffa801b2b4b30 svchost.exe             920    508     30    955 2012-01-27 11:50:30       
0xfffffa801b599a70 svchost.exe            1728    508     13    335 2012-01-27 11:52:32       
0xfffffa8018f32890 SearchIndexer.         1892    508     13    730 2012-01-27 11:52:32       
0xfffffa801914e7a0 taskhost.exe           2444    508      7    188 2012-01-27 11:53:56       
0xfffffa80191ac8a0 dwm.exe                2512    868      3     79 2012-01-27 11:53:56       
0xfffffa801918d920 explorer.exe           2524   2500     21    773 2012-01-27 11:53:56       
0xfffffa8019258b30 VMwareTray.exe         2644   2524      4     68 2012-01-27 11:53:56       
0xfffffa801912c3a0 vmtoolsd.exe           2652   2524      6    288 2012-01-27 11:53:56       
0xfffffa801a609ae0 TPAutoConnect.         2840   1552      5    143 2012-01-27 11:53:58       
0xfffffa801a60f5a0 conhost.exe            2848    416      1     34 2012-01-27 11:53:58       
0xfffffa8019cd7b30 Up4Ir2-def.exe         2808    500      1     47 2012-01-27 12:09:43
0xfffffa801942fb30 cmd.exe                2932   1400      0 —— 2012-01-27 12:31:19
0xfffffa8019c7db30 conhost.exe            3044    360      0     30 2012-01-27 12:31:19

From running the pslist command these are the two processes (and possibly the last conhost.exe) that stick out to me. One, because Up4Ir2-def.exe at process id (PID) 2808 just simply doesn’t match anything “normal” and secondly the cmd.exe process was running when I didn’t actually start it up myself during the “compromise”.

Note: The one downside to pslist is that it does not detect hidden or unlinked processes (same with pstree). Kernel mode rootkits fool this simple “task list”/pslist command. Let’s run a quick psscan, which will show us previously terminated and processes that have been hidden or unlinked by malware. [1] Psscan will look through memory trying to find EPROCESS data structures, which is how a process is represented within memory.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 psscan -f /cases/win7.vmem
Volatile Systems Volatility Framework 2.1_alpha
 Offset(P)  Name             PID    PPID   PDB        Time created             Time exited             
———- —————- —— —— ———- ———————— ———————— 
 [snip]             
0x7ef94060 svchost.exe         752    508 0×71243000 2012-01-27 11:50:29                              
0x7f1acb30 svchost.exe         576    508 0×09371000 2012-01-27 11:50:30                              
0x7f67db30 conhost.exe        3044    360 0x0126e000 2012-01-27 12:31:19      2012-01-27 12:31:20    
0x7f6d2060 svchost.exe         700    508 0x0fc33000 2012-01-27 11:50:29                              
0x7f6d7b30 Up4Ir2-def.exe     2808    500 0x410ed000 2012-01-27 12:09:43                              
0x7f7a27f0 smss.exe            264      4 0x2eb27000 2012-01-27 11:50:22                              
0x7f9cbb30 ipconfig.exe       1476   2932 0x7a7d9000 2012-01-27 12:31:19      2012-01-27 12:31:20     
0x7fe2fb30 cmd.exe            2932   1400 0×03389000 2012-01-27 12:31:19      2012-01-27 12:31:20   
0x80058b30 VMwareTray.exe     2644   2524 0x36e8e000 2012-01-27 11:53:56  
0x7e0b4b30 svchost.exe         920    508 0x6b619000 2012-01-27 11:50:30                            
0x8032c3a0 vmtoolsd.exe       2652   2524 0x37c13000 2012-01-27 11:53:56                              
0x8034e7a0 taskhost.exe       2444    508 0x4ffbf000 2012-01-27 11:53:56                              
0×80353920 SearchFilterHo     2408   1892 0x10b8a000 2012-01-27 11:55:41      2012-01-27 11:58:35    
0x8038d920 explorer.exe       2524   2500 0x4f434000 2012-01-27 11:53:56                              
0x803ac8a0 dwm.exe            2512    868 0x39a12000 2012-01-27 11:53:56                              
0×80528040 System                4      0 0×00187000 2012-01-27 11:50:22                              
0×80532890 SearchIndexer.     1892    508 0x4e051000 2012-01-27 11:52:32

Interesting….there are a few more that didn’t show up under the pslist command. Are they trying to hide from us? Maybe…. Let’s take a closer look at some of these by using the dlllist command. The -o command option is used to specify the offset, which we got from running pslist and psscan commands. I’ve highlighted the numbers to make it easier to find in the above commands.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 dlllist -o 0x7f6d7b30 -f /cases/win7.vmem
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
Up4Ir2-def.exe pid:   2808
Command line : “C:\Users\Patrick Olsen\Desktop\Up4Ir2-def.exe”
Base         Size         Path
0×00400000   0x0b6000     C:\Users\Patrick Olsen\Desktop\Up4Ir2-def.exe
0x773b0000   0x1a9000     C:\Windows\SYSTEM32\ntdll.dll
0x73ba0000   0x03f000     C:\Windows\SYSTEM32\wow64.dll
0x6fcb0000   0x05c000     C:\Windows\SYSTEM32\wow64win.dll
0x73c10000   0×008000     C:\Windows\SYSTEM32\wow64cpu.dll

From reading about these wow dll’s they appear to allow 32bit applications to run on a 64 bit system. The wow64cpu.dll for example gets the processor “ready” and switches it from 64bit to 32bit and vice versa. [2] We can also see that ntdll.dll is there, which contains NT kernel functions. Maybe we have a kernel level rootkit on our hands here, which would possibly explain why some of those processes were hidden from us.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 dlllist -o 0x7e0b4b30 -f /cases/win7.vmem
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
svchost.exe pid:    920
Command line : C:\Windows\system32\svchost.exe -k netsvcs
Service Pack 1
Base         Size         Path
0xffbc0000   0x00b000     C:\Windows\system32\svchost.exe
0x773b0000   0x1a9000     C:\Windows\SYSTEM32\ntdll.dll
0×77190000   0x11f000     C:\Windows\system32\kernel32.dll
0x7fefd600000   0x06c000     C:\Windows\system32\KERNELBASE.dll
[snip - Lots more]

After this I decided to just execute the procexedump command, more so because I don’t know much about memory forensics and i’m learning as I go along here…but it basically dumps a processes .exe in to the specified out directory by using the -D option.

sansforensics@SIFT-Workstation:~/vol$ python vol.py –profile=Win7SP1x64 procexedump -f /cases/win7.vmem -D /cases/
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
Dumping Up4Ir2-def.exe, pid:   2808 output: executable.2808.exe

Once I have the exe out I wanted to run some strings against it.

sansforensics@SIFT-Workstation:~/vol$ strings /cases/executable.2808.exe | egrep -i ‘http|update|ftp|https|IRC|room|join|\.exe|chat|System32|Windows|ip|%d.|User-Agent|image’ > strings.txt

sansforensics@SIFT-Workstation:~/vol$ cat strings.txt |more

Here is some of the output that I received:
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform\
SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform\
Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\
ERUNT.exe
ERDNT.exe
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ERUNT_is1
update%s.%s.com
GET %s?%s HTTP/1.1
User-Agent: %s
POST %s HTTP/1.1
wv=%s&uid=%d&lng=%s&mid=%s&res=%s&v=%08X
v=spf1 a mx ip4:%d.%d.%d.%d/%d ?all
SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HTTP/1.1
Host: update1.randomstring.com
HTTP/1.1
/?abbr=RTK&setupType=update&uid=%d&ttl=%s&controller=microinstaller&pid=3
Host: update1.randomstring.com
/update_c1eec.exe
%appdata%\ScanDisc.exe
Drive%dModelNumber
Drive%dSerialNumber
Drive%dControllerRevisionNumber
Drive%dControllerBufferSize
Drive%dType
C:\Windows\system32\drivers\etc\hosts
http://findgala.com/?&uid=%d&q={searchTerms}
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
http://findgala.com/?
 
http://findgala.com/?&uid=%d&q={searchTerms}
C:\file.exe
ntoskrnl.exe

SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce – I was reading Windows Registry Forensics by Harlan Carvey the other day (good book) and he talks a little bit about the RunOnce key and how it can make an excellent persistence mechanism [3] and [4]. It can be used instead of the Run key to make it harder for an investigator to catch it. Unlike the Run key the RunOnce key does just that. It runs once and then it’s deleted. But a process could be set to constantly write to the RunOnce key keeping its persistence. If the system is then rebooted the persistence mechanism would activate, and the key would be deleted “without a trace”…hence “RunOnce”. This would be a continuous cycle until it was mitigated. The RunOnce key can even be prefixed with an asterisk to force the associated program to run even in Safe Mode. You can even used a ! to defer deleting of the value until after the command runs, but I’m going to assume most malware would use the default and that means the RunOnce value is deleted before the command runs.

C:\Windows\system32\drivers\etc\hosts – This is pretty self explanatory, but malware will sometimes edit the \etc\host file in an attempt to prevent users from going to anti-virus websites, redirect users to infected anti-virus websites, etc. It’s a persistence mechanism in a way. I didn’t see that the hosts file on my system was edited, but I also didn’t let it run for that long after I infected it. It very well could have been changed an hour or so after it was infected, but I only let it run for about 20 mins or so.

Host: update1.randomstring.com
/?abbr=RTK&setupType=update&uid=%d&ttl=%s&controller=microinstaller&pid=3
/update_c1eec.exe – There are multiple references to the word “update”. I don’t know what any of these specifically mean, but im going to hypothesize and say they are going to be used at some point to issue update commands for the malware? Without further analysis I really can’t say for sure. I’m simply guessing at this point.

ntoskrnl.exe – While reading Malware Analyst’s Cookbook I came across the following statement, “If a process in user mode loads ntoskrnl.exe (the kernel executive module), it’s most likely gathering information to install a kernel-level rootkit.” [5] That could also explain why we see all of the “Drive%d” commands. Maybe it’s enumerating system information for its takeover plan. Not sure. That also jives with the above when we ran our pslist command and we had a few that were hidden from us until we ran psscan.

After running strings I decided to run a tool that comes with The Sleuth Kit called srch_strings.

sansforensics@SIFT-Workstation:~/vol$ srch_strings -t d -e l /cases/win7.vmem |grep -A2 -B2 “Up4Ir2-def.exe”

The -A2 and -B2 just says to give me two lines before and two lines after when you see “Up4Ir2-def.exe”

When running this I noticed another interesting web link named; http://n[cut]t[dot]org/update/Up4Ir2-def.exe so I decided to run another strings search for that website and grep it.

sansforensics@SIFT-Workstation:~/vol$ srch_strings -t d -e l /cases/win7.vmem |grep -A2 -B2 “n[snip]t.org”
1022668940 update
1022669012 Up4Ir2-def.exe
1022669296 novosoft.org
1022669424 update
1022669488 Up4Ir2-def.exe
–
1129131552 ncpa.cpl.manifest
1129131800 webfile
1129131828 C:\Users\Patrick Olsen\Desktop\Up4Ir2-def.exe|http://n[snip]t[dot]org/update/Up4Ir2-def.exe
1129144300 PROGRESS
1129185344 http://schemas.microsoft.com/windows/2004/02/mit/task

I decided to go out and download the actual .exe file and run an md5hash against it since the only other md5 hash I had was from extracting the original process id (PID) 2808 executable. Upon downloading and running md5sum against it.

Then I proceeded to google for that md5 hash and I got a hit, but it didn’t really give me anything other than saying it was “bad”. So i’ll continue to look at it.

Now I think i’ve gotten pretty much everything that I can from memory at this point. There were a few other things I wanted to do like using the rip.pl/volatility combo and some others, but my machine was acting up so I will have to do some fixes. Until then I am going to switch over to my Windows machine and see if I can’t analyze the .exe file I was able to download from finding the website when I ran srch_strings.

UPDATE: I did the Volatility commands the long way. I saw this little shortcut here:

export VOLATILITY_LOCATION=file:///media/Fv/Malware_Second/Windows\ 7\ x64-86bbfb9a.vmem


export VOLATILITY_PROFILE=Win7SP1x64

Once you run those two commands it’s MUCH quicker to run your commands.

sansforensics@SIFT-Workstation:~/vol$ python vol.py pslist
Volatile Systems Volatility Framework 2.1_alpha
 Offset(V)  Name                 PID    PPID   Thds   Hnds   Time 
———- ——————– —— —— —— —— ——————- 
0xfffffa8018f28040 System                    4      0     87    518 2012-01-28 13:43:23       
0xfffffa8019e4b950 smss.exe                264      4      2     29 2012-01-28 13:43:23       
0xfffffa801a616630 csrss.exe               360    352      8    513 2012-01-28 13:43:26       
0xfffffa801a999620 wininit.exe             404    352      3     75 2012-01-28 13:43:28       
0xfffffa801a9af060 csrss.exe               416    396      9    220 2012-01-28 13:43:28       
0xfffffa801aa63b30 winlogon.exe            464    396      6    130 2012-01-28 13:43:29       
0xfffffa801a98db30 services.exe            508    404     11    219 2012-01-28 13:43:29       
0xfffffa801b4077c0 lsass.exe               516    404      7    510 2012-01-28 13:43:29

Windows

I decided to run PEiD against the malware sample that I had downloaded. PEiD, which is no longer being updated as of April 2011 is used to detect most common packers, cryptors and compilers for PE files.

Tweet


References:
[1] - http://code.google.com/p/volatility/wiki/CommandReference#psscan
[2] - http://en.wikipedia.org/wiki/WoW64
[3] – Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry
[4] - http://support.microsoft.com/kb/314866
[5] - Malware Analyst’s Cookbook
[6] - http://msdn.microsoft.com/en-us/library/cc232761(v=prot.10).aspx

Digital Forensics, Forensic Artifacts, Malware Analysis, pslist, psscan, Registry, Regshot, RunOnce, SANS, sans investigative forensic toolkit, SIFT Kit, Volatility, Windows 7

SIFT Workstation: Video 4 – Extracting $MFT using mmls, icat, and log2timeline SIFT Workstation: Video 5 Gmail Passwords inside Memory Dumps