In one of my previous blogs I was talking about what happens when a file is deleted on a Windows system. Today I want to talk about another very interesting topic, time stomping and how to detect it. I heard this as a question a few times in interviews, although in practice I didn’t see time stomping very often.
In my experience, the bad guys (even the most advanced) prefer to hide in plain sight by blending in the environment with deceiving names of executable and/or usage of (stolen) certificates to sign executable files.
This post does assume a certain level of familiarity with the digital forensic field (and in particular with the timestamps used in NTFS), if anything is unclear please check the references section of my previous blog (on file deletion) or just leave a comment below.
[Technical Assumptions]
Since the most discussed scenario is one that involves Windows (7 and beyond) with NTFS (version 3.1) I will cover only this.
Before we dive into the technical details let’s discuss why a threat actor would try to change the timestamps of the files used to perpetrate the attack.
Main reason is to delay the detection as much as possible by using a timestamp from the past (before the time frame of the attack). If an investigator simply uses a filter to select all events within a time-wrinkle around the moment of the initial alert or attack notification/s the timestomped file/s will not show up.
Another reason could be to stay “under the radar” of a Threat Hunt swipe of the environment where the time stamp is part of the detection logic.
[Deep Dive]
But enough rambling about simple things, let’s dive into the technicalities of detecting timestomping. To keep things simple, I will not discuss NTFS tunneling, but I would recommend anyone into digital forensics to have a look and understand the concept.
For the sake of structure and ease of reading I will use a numbered list to enumerate all the ways to detect time stomping. So here we go:
-
[MFT ID vs timestamps]The logic here is that the MFT ID will grow linearly with the FILE_NAME ($FN) birth timestamp. What this means is that the MFT ID of a file created in the past (e.g. when the OS was installed) is lower than the MFT ID of a file created now.
The anomaly would be a situation when a file has a birth/creation timestamp from the past (e.g. from 3 years ago) but the MFT ID value is very high and closer to the MFT IDs of files created much later.
NOTE: NTFS (especially for SSD) will reuse the MFT IDs of the files that have been deleted, so this technique is relatively prone to false positive hits. [$SI vs $FN]The expected values of the timestamps should be $FN birth/creation timestamp should be older than STANDARD_INFORMATION ($SI) birth/creation timestamp.
An anomaly at this level would be a situation where the $SI birth timestamp is older than the $FN birth timestamp.
NOTE: the general opinion is that $FN timestamps are harder to modify but testing shows that rename operations can copy over timestamps from the $SI (which are relatively easy to modify) to $FN, thus making this technique to detect time stomping useless.[Timestamp format – ending in zeros]This logic relies on the limitation of tools that are used to modify the timestamp; the resolution of the timestamp stops at second level and everything else (all the way to the last 100ns) is set to zero.
NOTE: be aware that different archive format (which should preserve the original timestamps) can truncate the timestamp resolution to have zeros for milliseconds and beyond. This can happen if the bytes allocated for the timestamps of the file/s archived (or zipped) are lower than 8 bytes.[UsnJrnl]You probably remember the alternate data stream $J from the previous blog (about file deletion) as valuable sources of forensic evidence; in this context the entries we might find in the UsnJrnl associated with the target file (with altered timestamps) will have the following codes BASIC_INFO_CHANGE+CLOSE.[Log files]This could be something as simple as Sysmon (which records an event with ID 2 for file timestamp modification) or the Windows Security log if file creation/modification is audited; but there might be other tools out there which are capable of recording such events.
NOTE: the Windows file system audit needs to be enabled globally at OS level, and then configured at folder level for different security accounts/groups or special identities; the events are 4656 (showing access request) and 4663 (showing what action was performed against the file).[IOCs]Very subjective, but should be on the table as an option, the IOCs can provide solid evidence of when a file was dropped (and maybe executed) on a system. Such IOCs can be:
– network IOCs (if this is a script/executable that calls back right after being dropped on the system).
– registry keys (or values) creation and/or modification; at this stage the keys show suspicious activity that is related to the main investigation.
– disk level artifacts (files) that could be produced as a result of something like the initial exploit that led to the system’s infection, etc.
NOTE: also in this category we can have all IOCs produced by the tool used to change the timestamps.
[Conclusion]
Time stomping although (in the author’s experience) not very popular in the wild, remains an anti-forensic technique any investigator should be familiar with. And if not very useful in real-life investigations, you can still impress your family and friends at the Christmas dinner if anyone is challenging the coolness factor of your job.
Joking aside, a lot of times one will need a few of the techniques describe above to show positive results before reaching a solid conclusion. The context of the investigation and experience of the investigator will play a big role when dealing with anti-forensic techniques (such as timestomping).
Never forget that we should always have a scientific approach to test our theories. A good investigator will not try to find only the evidence that supports his favorite hypothesis/theory, but instead will explore *all* conditions that would invalidate his theory and if it still stands that can be something that is worth being added in the final report.