Beginning Analysis

 So I ran all the commands I discussed previously on 30 October. Lets go thru some of them...

CPORTS: Shows Open TCP/UDP Ports
I open up the CSV in excel and do some fiddling so it looks pretty. Something immediately sticks out at me.

That looks like A LOT of svchost.exe (the same one I may add-- PID 760) going out to 192.168.0.5 (lets say its my proxy server). I decide to sort on the 'ProcessCreatedOn' column...

So they started at 0917 GMT (local time). How do I know it was local time? I ran unixdate when I started my analysis remember? This also give you an idea how long this has been running for. In our case, not long. I count 72 instances of some sort of connection attempt to 192.168.0.5 from PID 760, all at 0917GMT . Two of them are established, which means potentially there is still data going out.

P.S. A lot of times students say 'Hey! I see multiple svchosts.... that's bad right?' No, it doesn't not automatically mean badness. Check out this How-To Geek Article about it. Basically it is a container used to run services executed on the system. However, if we scroll ALL the way over in cport output to look at Process Service for our suspicious PID, we don't see any... but heck let's just check.

Services
I am hoping to see SOMETHING here. Luckily since my system administrator is amazing (*blush*) they have a list of  services installed on the standard image from this organization. This bring me to a big helpful piece of advice: KNOW YOUR NETWORK. If you know what is normal, then you will have a faster/easier time picking out things which do not belong.

Anyways, I check my services output with the list from my admin. I see the 'rpcapd' service which is a bit unnerving as it is used to capture packets off the wire for the machine. Something to bring up to the administrator (ie WHY do all the machines have this?! Why do they need it? It could be used for malicious purposes....) Nothing here though from the malware.. maintaining persistence elsewhere!

MFT
OK, so we have a timeframe (potentially). Let's see if we can use the good ol Master File Table and focus on that time frame (October 30, ~0917 GMT). Remember if we are dealing with NTFS then a file should have at least one entry in the MFT (even if it is deleted-- potentially). Time for MFTDump by Mike Spohn now that we have the $MFT.

So the command I entered was as follows:

mftdump.exe --hostname=VICTIM_PC F:\Output\MFT_victim.txt

 This created a file called 'mftdump_VICTIM_PC'. I throw this into Excel (every analyst's first love) and after making it pretty sort by created time. Lo and behold I hit some goodness...

Well THAT doesn't look normal! What are those weird looking executables? log files? Let me copy those to another worksheet and then lets also sort by accessed time as well...maybe something was created earlier but then was run again around that time? So now I have a new spreadsheet with created time around the suspicious time and accessed around the suspicious time. (I have linked here the excel spreadsheet if people want to follow along...)

I also want to point out the two different attributes for time here, the $Standard_Information(si) attribute and the $File_Name(fn) attribute. If you look you notice that they do not always match.  Why is that? Well its because of the way different attributes are updated based on actions. Lets quickly recap the definitions of each action (from whereismydata):

• File Created: This is the date the file was “created” on the volume. This does not change when working normally with a file, e.g. opening, closing, saving, or modifying the file.

• File Accessed: This is the date the file was last accessed. An access can be a move, an open, or any other simple access. It can also be tripped by Anti-virus scanners, or Windows system processes. Therefore caution has to be used when stating a “file was last accessed by user XXX” if there is only the “File Access” date in NTFS to work from.

• File Modified: This date as shown by Windows there has been a change to the file itself. E.g a notepad document is has more date added to it, would trip the date it was modified.

• MFT Entry Modified: A basic understanding of NTFS and the MFT is required for this section. This is date not shown by Windows Explorer or the average windows interface, but requires forensic tools , e.g EnCase, FTK, iLook, WinHex, etc.  This date shows when the MFT entry, which points to the file of concern, was changed. This means that if the record that points to the file  is changed, then this date would trip. As all the dates, file name, file sizes are stored in the MFT, if any of those are changed then the date will change. For example, if the file size changes then the MFT Entry modified date is changed. If the file name is changed, than the MFT entry modified is changed.

Dusting off the File System Forensic Analysis Book by Brian Carrier, Windows does not generally update the values in $FILE_NAME, therefore the $STANDARD_INFORMATION timestamps are more 'up-to-date' (these are the ones you normally see in a Windows GUI). However certain things like 'accessed times' need to be treated carefully, as 'accessed' do not always mean 'executed'.  Oh and don't forget timestomping.... Oh and now they can alter the $FILE_NAME attribute too... Sad panda :(

SIDE NOTE: You can also grab some interesting timestamp by parsing the $I30 (Index Attribute File). See the SANS blog post talking about it. You can download the INDXparser tool for free here. I have even used this before in a case, but completely forgot until now.

So right now my timeline is looking something like this (I have things I think are malicious bold in red, suspicious in yellow):

October 30 @ 0853 

• windows.exe is created in Temp directory for Administrator (I always find things created in Temp directory interesting, and it fits within the scope of the timeline)

October 30 @ 0904

•  Google Crashed (maybe related? not sure)

October 30 @ 0916

• RunDLL32 is accessed (seen by prefetch)
• Looks like a USB is connected (seen via the wav file and USBSTOR.SYS)

October 30 @ 0917

• rundll32 executed again (seen by rundll32.exe and prefetch)
• bin folder accesses from \MinGW directory
• Application Data folder accessed for Administrator
• windows.exe is accessed and run from Temp directory (see the prefetch?)
• ijjfkkxw.exe is created and accessed from  StartMenu\Programs\StartUp
• keqkhgks.log is created and accessed from Application Data
• ijjfkkxw.exe is created and accessed from Application Data\agrsahog
• desktop.ini is accessed
• areapmadsdctysii.exe is created, accessed, and run from Temp directory
• tourstart.exe accessed from system32
• migwiz.exe accessed from system32\usmt\
• xpsp1res.dll accessed from system32
• sti_ci.dll accessed from system32
• ...

October 30 @ 0922

• Folder agrsahog is accessed 

October 30 @ 0923

• IR First Response starts with UNIXDATE and FASTDUMP observed...

See how useful the MFT is?! Amazing! We have a good timeline and additional places to look for badness! Man how happy am I that I saved off the temp folder! Judging from size alone it looks like potentially areapmadsdctysii.exe, ijjfkkxw.exe, and windows.exe are the same files, just in various locations. Did you see that places itself in StartUp? Hooray we found one persistence mechanism!

In theory since we have the offending executable we could throw that bad boy into our lab for dynamic analysis... but whats the fun in that? Let's keep moving!! 
 
Also want to post these two additional links about $FILE_NAME and $STANDARD_INFORMATION attributes.  I hope I explained it properly... I was actually going back thru Brian's book in sheer amazement about the complexity of NTFS. It's a jungle out there!