SANS Digital Forensics and Incident Response Blog

Benefits of using multiple timestamps during timeline analysis in digital forensics

Timeline analysis is a highly valuable tool. However, like everything else in computer forensics, it requires a skilled investigator to examine all the data available in order to find the evidence and provide an accurate account of the events. When analyzing Windows systems, it is common to use key timestamps in forensics such as Creation Date, Last Modified Date, Last Accessed Date, and the Last Modified Date for the file's Master File Table (MFT) entry. A key factor in using these timestamps is to not rely solely on a single timestamp, but use the combination of these timestamps in digital forensics. The combination of these timestamps can prove to be far more powerful and revealing than any single timestamp on its own. I will use an example to illustrate.

A forensic investigator was reviewing volatile evidence collected during an investigation into suspicious system activity. In reviewing active file handles, the investigator found winlogon.exe accessing files named sdra64.exe, local.ds, and user.ds. These are solid indicators of compromise for a Zeus infection. The investigator began file system analysis to determine when and how this Trojan had compromised the system. By looking at a registry startup modification timestamp for the sdra64.exe, the investigator had a solid starting timestamp for when Zeus initially ran and a full path to the binary.

The investigator examined the Zeus binary, but what they found was not what they expected. The file's creation timestamp was from August 2008 and the file's last modified date was February 2009. The investigator knew the system had not been compromised since 2008 so why would the malicious actor choose these specific timestamps? Windows file creation and last modified timestamps can be confusing as they can be modified a number of ways. One example is a file copy vs a file move. Another example is file actions within a local system/volume vs across systems/volumes. Despite these timestamp subtleties, the timestamps observed seemed odd and out of place. Each timestamp on its own did not immediately reveal anything of significant value. However, combining these two odd timestamps demonstrated why they had been selected. These two timestamps exactly matched the timestamps of another file on the system, a key Windows system file, ntdll.dll. In this case the malicious actor was attempting to hide this Zeus binary alongside other well known and valid operating system files. Had the forensic investigator lacked the ability to directly spot signs of Zeus and just used the single creation or last modified timestamp by itself, it is possible that this compromise would have gone completely undetected. The malicious actor was counting on the investigator only reviewing recent file timestamps for signs of compromise.

On a side note, this isn't the only way malicious actors alter timestamp information. Malicious actors have also completely removed file creation or other timestamps. Again relying on a single timestamp or even a couple can lead to missing key evidence in investigations. A check for any file with a blank or missing timestamp can be a quick way to spot obvious attempts to hide files.

The information for malicious actors on the tools and methods to modify timestamps is out there already and has been for some time. It is key for forensic investigators to know these methods exist and have techniques in their toolkit to spot these attempts.

Chris Silveira manages the CSIRT and Paul Yacovetta is a forensic engineer at a financial institution.

3 Comments

Posted August 19, 2010 at 4:01 AM | Permalink | Reply

DSabourin

Timely posting. I'm currently investigating several cases ''" many of which involve Zeus and these exact characteristics. Great point about timestamps. One notable characteristic ''" there were several copies of many of the files you noted. Hash values are a great way to isolate multiple copies ''" several of which were in Restore Points. Thanks!

Posted August 19, 2010 at 10:41 AM | Permalink | Reply

H. Carvey

By looking at a registry startup modification timestamp for the sdra64.exe, the investigator had a solid starting timestamp for when Zeus initially ran''"
I'd be somewhat careful about that statement''the Winlogon key (Zeus adds its entry to the UserInit value) is not an MRU-style key, and contains a number of additional values. As such, the system becoming infected will modify the Registry key LastWrite time, but so will a policy rolled out a week later that, for example, adds/deletes/modifies another value.
The purpose of using multiple timestamps''file system metadata, Registry data, metadata from Prefetch files, Event Log record metadata''is to add context to the timeline data, as well as to increase your overall level of confidence (''truthiness") in the data. Knowing that $SIA time stamps are easily modified, but that others aren't, is very important.

Posted August 19, 2010 at 3:40 PM | Permalink | Reply

Rob Lee

Harlan, Id be careful about saying $SIA timestamps are easily modifiable. Unless you are using powershell, native timestamp manipulation tools do not exist on Windows. For example, if I wanted to set my Created, Modified, and Access times of a specific file to a SPECIFIC time, that is difficult to achieve without first downloading or writing a program. Both of which can be traced. $SIA times can be modified easier than other timestamps as a WIN32 API exists to help out. But it is not necessarily "easily modified" without a 2nd tool.
"Easily modified" should be "easier to modify" compared to other timestamps.