At approximately 22:50 CDT on 20101029 I responded to an event involving a user who had received an email from a friend with a link to some kid's games. The user said he tried to play the games, but that nothing happened. A few minutes later, the user saw a strange pop up message asking to send an error report about regwin.exe to Microsoft.

I opened a command prompt on the system, ran netstat and saw an established connection to a host on a different network on port 443. The process id belonged to a process named kids_games.exe.

Audit Viewer gave the kids_games.exe process a very high Malware Rating Index (see Figure 1), so I decided there was probably more at play here than kids games. I took the suspect system offline and began gathering time line evidence.

Figure 1: Audit Viewer -- kids_games.exe

Within 20 minutes of taking the system offline, I was staring at the following timeline data (see Figure 2):

Figure 2: Timeline

Line one of the timeline data was disconcerting. I suspected regwin.exe hadn't been created on 20080414 because this system wasn't that old. The file could have been moved onto this volume from another NTFS volume, causing the modification and born time stamps to be inherited from the original volume (see Figure 4 for time stamp update rules). Or it could have inherited these time stamps from the installation media. However, behavioral analysis of the binary showed that it was malicious, so that likely ruled out time stamp inheritance from the installation media archives.

Further, look at the Prefetch entry for regwin.exe (second entry from the bottom in Figure 2). If regwin.exe had been on this system since the date of installation, was it possible that it hadn't been run until today? It's very possible. I've also investigated systems before where binaries had been run previously, but were removed from the Prefetch. Remember there's only room for 128 entries, perhaps regwin.exe had been FIFO'd.

Given that this was an NTFS file system, I knew I could pull the time stamps from the $FILE_NAME attribute and compare them to the ones I was looking at from NTFS' $STANDARD_INFORMATION attribute. Unfortunately, getting $FILE_NAME time stamps is not as straightforward as getting $STANDARD_INFO's. However, there are tools available that can acquire them. One is David Kovar'sanalyzeMFT.py, Harlan Carvey has a Perl script he shared with Chris Pogue that will pull them out as well.

Those who follow my babbling on Twitter know I've been looking for a solution that would pull $FILE_NAME time stamps and put them into bodyfile format so they can be added to the overall time line for analysis. Given enough time, I could have coded up my own tool, fortunately for me, Mark McKinnon and Kovar both spent time working on a solution. Kovar got very close and given time, I'm sure he'll have a working solution in analyzeMFT if he decides it's worth pursuing.

McKinnon has a proof of concept tool called mft_parser that comes in both a GUI and a CLI version, the latter is convenient for scripting. As of this writing, mft_parser is run against the MFT from the suspect system, the syntax looks like this:

mft_parser_cl <MFT> <db> <bodyfile> <mount_point>

The "db" argument is the name of a sqlite database that the tool creates, "bodyfile" is similar to the bodyfile that fls from Brian Carrier's The Sleuth Kit produces, except that it will also include time stamps from NTFS' $FILE_NAME attribute. The "mount_point" argument is prefixed to the paths in the bodyfile, so if you're running this tool against a drive image that was drive C, you can provide "C" as an argument.

I have highlighted the new information in Figure 3. Notice that McKinnon's tool labels the $FILE_NAME time stamps with FN at the beginning of the path. What do the $FILE_NAME time stamps tell us that the $STANDARD_INFO time stamps don't?

Carrier's File System Forensic Analysis book says, "Windows does not typically update this set of temporal values like it does with those in the $STANDARD_INFORMATION attribute, and they frequently correspond to when the file was created, moved, or renamed," (page 318).

Rob Lee has done some research on time stamp modification for different types of activity performed via the GUI for both the $STANDARD_INFORMATION and $FILE_NAME attributes. I have simplified his charts in Figure 4:

Figure 4: Time stamp change rules (GUI)

Rows in the charts represent the four different types of NTFS time stamps and the columns represent different activities performed on a file via the Windows GUI. Cells containing the letter X indicate that the given time stamp will be updated for the given action. (Note that for Vista and later Access time stamps are disabled by default.)

Given these rules and the information in Figure 3, it appears that this incident has the hallmarks of time stamp manipulation. This accounts for the differences in regwin.exe's modification, born, access and metadata change times in its $STANDARD_INFORMATION and $FILE_NAME attributes. Where did the time stamps in regwin.exe's $STANDARD_INFORMATION attribute come from? A little careful filtering and I was able to match them up with a number of possibilities, but I suspect the attacker set them to match regedit.exe's time stamps, see Figure 5:

Figure 5: regwin.exe and regedit.exe have matching $STANDARD_INFO time stamps

This seems plausible given that Vinnie Liu'stimestomp, one of the anti-forensics tools built into Metasploit, provides a function to modify time stamps of one file to match those of another.

Given the available timeline evidence and the user's account of what happened, it seems likely that the kids_games executable opened a connection to an attacker's remote system. The attacker uploaded regwin.exe and executed it in an attempt to rootkit the system, the attacker then modified the time stamps for regwin.exe to match those of regedit.exe in an attempt to throw off the investigation.

The incident demonstrates the benefit of including $FILE_NAME time stamps in the overall timeline. Until recently, the process of gathering $FILE_NAME time stamps has been cumbersome. Tools like Kovar's analyzeMFT.py and now McKinnon's mft_parser are making this process easier. I still think ideally, fls should provide a flag for pulling $FILE_NAME time stamps into the bodyfile. I submitted a request to Carrier a few weeks ago asking for this option and didn't get a response.

Lee said he spoke to Carrier about it and that Carrier had reservations about it because fls is a tool made to work with multiple file systems and not all file systems have alternative time samps like NTFS. My feeling is that for non-NTFS file systems, fls should warn the user if they attempt to use the flag to collect $FILE_NAME attributes. I'd love to be able to do something like the following using fls:

fls -r -m C: /dev/sda1 > std_bodyfile

to collect the $STANDARD_INFO time stamps, then:

fls -r -m C: -f FN /dev/sda1 > fn_bodyfile

to collect the $FILE_NAME time stamps. For now, if you want to collect $FILE_NAME time stamps, you'll need another tool.

The traditional file system time stamp collection is done using fls as follows:

fls -r -m C: /dev/sda1 > fs_bodyfile

To acquire last modification times from Windows Registry keys, we use Carvey's regtime.pl against the Registry hives. The syntax is as follows:

regtime.pl -m <hive_name> -r <hive_file> > reg_bodyfile

Next we use Kristinn Gudjonsson'slog2timeline to collect time stamp artifacts from a variety of sources. At a minimum, I like to collect time stamps from the Windows Prefetch, lnk files and UserAssist keys. The syntax is:

To collect the $FILE_NAME time stamps, you'll first need to collect the MFT for the system you're investigating. There are a variety of ways to do this, one is using icat from the Sleuth Kit as follows:

icat /dev/sda1 0 > MFT

Once you've got the MFT, you can use McKinnon's mft_parser, which he should be releasing more widely very soon. I'll update this post with that information once it is available. The syntax for mft_parser was explained above, but here it is:

mft_parser_cl <MFT> <db> <mft_parser_bodyfile> <mount_point>

Following that, I use grep to single out the $FILE_NAME time stamps as follows:

grep "C:FN/" mft_parser_bodyfile > fn_bodyfile

Why do I separate the $FILE_NAME time stamps in mft_parser's output? Because while mft_parser does pull all time stamps, fls provides the MFT entry number, the MFT type and the MFT type id in this format (######-###-##), see column four in figures 2, 3 and 5. I prefer having this information in the time line as it can alert the analyst to the presence of alternate data streams. As of this writing, mft_parser only provides the MFT entry number in its output.

You may have noticed that in the steps above, I've stored each time stamp artifact in its own bodyfile, but we need to combine them for the next step in the process. To do this, I use something like:

Once I've gathered all this data into a master_bodyfile, I use mactime to turn the bodyfile into something human readable. Here's the syntax I typically use:

mactime -b master_bodyfile -d -y -m -z <time_zone> > timeline.csv

Obviously the -b flag tells mactime that the argument that follows is the input file, -d tells mactime to produce csv output, -y says start each line with a four digit year value, -m says to use numeric values for months rather than names and -z is obviously to supply time zone information. Getting csv output means I can pull this data into Excel, having the dates in yyyy mm dd format, means that I can easily sort and filter using dates. Excel's filtering capabilities can make analysis of a large data set relatively painless.

You can supply mactime with a date range value, but doing so may prevent you from seeing artifacts that have had their time stamps manipulated. Again, I prefer to gather more data than I need and then filter it during analysis.

Dave Hull is an incident responder and forensics practitioner in a Fortune 10000 corporation. Lately his focus has been on incident detection and malware analysis. He'll be TAing for Lenny Zeltser'sReverse Engineering Malware Course at SANS CDI in December.

14 Comments

Rob Lee

While complex, we have now reached a point where correlating time information is possible. It is like running up a hill with a full backpack, but it can be done. Wait till more people have Volume Shadow Copies to add timelines not just from one static snapshot but over time. You can see how the system changes and the key areas of the system that consistently change. Then you might be able to filter those out as "noise" and then look for the anomalies. It is great the amount of work now being done in this area.

Jose R. Vela

Interesting casecase. Thanks for sharing. I have some questions. Was this a real case or ficticious? Last year I looked at Memryze for live response and lost interest since it had some sw dependencies. I can't remember what it was, maybe. Net? It might also required to be installed on the target. At that time I was considering tools that could run off external media or a network share without dependencies. Is that still the case? Or is there a new version that can be put quickly into action as you describe in your case?

Dave Hull

Jose ''" Let me answer your second question first. My experience with Memoryze is that though it comes packaged up with an msi and "installs" on a system, you can copy just the exe and the xml config file or the bat file that has the configuration you want to use to victim system, as long as those two systems are very similar in terms of architecture and OS. In other words, I've got Memoryze installed on an analysis system that matches the standard configuration for the rest of the systems in my enterprise. When a system is compromised, I use Audit Viewer on my analysis system to configure Memoryze to do what I want it to do, then I copy the Memoryze binary and the config file to the victim machine and run it using "memoryze.exe -o -script ."As to your first question about whether or not this was a real case, this was a recreation of a real case, using the binaries from in the real case. In the real case, the system was compromised via social engineering. In the recreation, I put kids_games.exe on the system after figuring out that it was Metasploit's Meterpreter and configuring the lab environment to catch all the traffic from the victim system, regwin.exe was uploaded to the system using Meterpreter's upload functionality and timestomp was used to manipulate regwin.exe's time stamps.The only significant differences between the real case and the recreation are the dates and times and the actual user was in the admin group, but was not Administrator.

Dave Hull

Jose ''" WordPress commenting cut out the arguments to -o and -script. Check the userguide.pdf for Memoryze for details. I'm not sure if this will make it through the comment filter, but here goes,the right syntax is:memoryze.exe -o -script

Jose R. Vela

Lindsey

Hello,In regards to Figure 4, I have tried to replicate the information in the table but I have come across some anomolies! For instance, According to your table, viewing an image file in mspaint is going to update the ''last accessed time' on a NTFS volume in Windows 7? Which is not the case. I think? Im really confused.As windows 7 does not use the last accessed by default, what other caveats are on the table for other operating systems?Ill probably do my own testing but I just thought i would ask (politely of course) since I idolise the work you guys do.ThanksLindsey

smokiesanndy

John McCash

Dave ''" I've been referencing this presentation for my forensics class for a while, but just noticed what looks like an issue with Figure 4. You've got a modification of the file data updating the Modification time, but not the Change time'' This seems odd, as an update of the Modification time MFT data is by definition an update of the MFT, which should result in an update of the Change time as well. Are you saying it really doesn't, or am I misinterpreting?ThanksJohn

Francis Caratti

Thx Dave, great post. I will re-use your Figure 4.I have a case with a file with ''''b' date in 2008 and ''mac.' dates showing 2005, found in a $I30 file that should reflect MFT $FN info.OS level $SI ''mac?' dates are all in 2005. Your post help me a lot !

Dave

John, Nice catch. The chart in Figure 4, is taken from work Rob Lee did. It's possible I missed a box when transposing it for this post, or that it was wrong in the source material from whence it came. Either way, a modification to a file, should be reflected in the file's modification time and that should affect the file's standard information attribute change time. The chart should be updated to reflect that, alas, I no longer manage, edit, or contribute to the blog. /me sheds tear. Glad people are still finding it useful.

"Rob has insight that few others have and that alone is worth the cost of the the course."- Chris Spurrier, Xerox Corp

"For my line of work, basic &amp;amp; extensive understanding of the file system is extremely important. The literature and books on file systems for me are very critical &amp;amp; thanks you for them, great reference material"- Vince Ramirez, Las Vegas Metro P.D.

"I had taken several other forensic courses prior to this one, but none of them or their instructors made understanding forensic methodologies and techniques as clear and understandable as Rob Lee and this course has."- Nathon Heck, Purdue