Hello Reader,
Yesterday we went through detecting system clock changes on Windows 7, today we are going to talk about timestamp changing using two different utilities, timestomp and setmace. Why two timestamp changing tools? They have two different approaches, timestomp and its variants use a Win32 API call to change timestamps that allow them to adjust STDINFO attribute timestamps but not FILENAME attribute timestamps within the MFT. setmace on the other hand can change both and its use is currently not detectable by comparing the STDINFO and FILENAME timestamps. Let's get into it. None of the information in this post is new but I hope to frame it in such a way that it is easy to understand and approach if you don't have a low level understanding of MFT operations.
Initially I was going to cover both tools in this post, but there are enough details and new gotchas between the two to justify taking the time to split this between two posts. Today we will cover timestomp running through meterpeter on a compromised xp host.
Timestomp
Timestomp and other timestamp modification programs that work like it make use of the win32 api to reset timestamps located in the STDINFO MFT attribute for a file. STDINFO contains the timestamps shown to you within explorer and most non forensic file utilities. This method of timestamp modification has a simple detection mechanism that has been a staple for IR and forensic investigators to detect.
Step 1. Grab the MFT from the file system
Step 2. Parse the MFT (I used our ANJP tool)
Step 3. Compare the STDINFO creation/modification and access times to the FILENAME creation/modification and access times.
If the times in step 3 do not equal you have a file with a possibly altered timestamp.
Step 4. Validate your assumptions and make sure the file wasn't distributed by a vendor with a bad timestamp.
Here is an example, we created a file called 'test.txt'. We then used timestomp to reset the timestamp of that file to 0 which in timestomp terms is 1601-01-01 and the STDINFO creation dates look as follows:
When you look at the FILENAME attribute of the same file you will find the original timestamps:
So the comparison here is pretty obvious, not only because without the possibility of time travel there is no computer file being created in 1601 (Oh man, Time travel forensics!) but also because this file named:
is user created and not part of a system package or other vendor delivered weirdness that you can find. In my testing I found a lot of 0 date FILENAME attribute files within the system32 directory which surprised me.
Let's not stop here though, let's talk about why these things exist. When a file is created in NTFS the first thing that is created is a File record. This file record maintains the basic header needed for NTFS to be able to reference and find the file. The second thing created is the STDINFO or standard information attribute which contains metadata about the file, MAC timestamps, etc..., but not the name of the file itself. Instead the name of the file and an additional set of timestamps is kept in a separate attribute called FILENAME.
The first FILENAME attribute will contain the 8.3 version of the files name (so called because it allows 8 characters in the name and 3 in the extension). If the file name is longer than 8 characters in the name or 3 in the extension then a second FILENAME attribute will be created that will store it and another set of timestamps. There can be even more FILENAME attributes but I haven't found any documentation yet that states all the possible mechanisms that generate additional ones. If you have please leave a comment and let me know.
Tomorrow we will show how setmace works and how using journal forensics we can overcome what is a very effective methods with some limitations on newer platforms.
Yesterday we went through detecting system clock changes on Windows 7, today we are going to talk about timestamp changing using two different utilities, timestomp and setmace. Why two timestamp changing tools? They have two different approaches, timestomp and its variants use a Win32 API call to change timestamps that allow them to adjust STDINFO attribute timestamps but not FILENAME attribute timestamps within the MFT. setmace on the other hand can change both and its use is currently not detectable by comparing the STDINFO and FILENAME timestamps. Let's get into it. None of the information in this post is new but I hope to frame it in such a way that it is easy to understand and approach if you don't have a low level understanding of MFT operations.
Initially I was going to cover both tools in this post, but there are enough details and new gotchas between the two to justify taking the time to split this between two posts. Today we will cover timestomp running through meterpeter on a compromised xp host.
Timestomp
Timestomp and other timestamp modification programs that work like it make use of the win32 api to reset timestamps located in the STDINFO MFT attribute for a file. STDINFO contains the timestamps shown to you within explorer and most non forensic file utilities. This method of timestamp modification has a simple detection mechanism that has been a staple for IR and forensic investigators to detect.
Step 1. Grab the MFT from the file system
Step 2. Parse the MFT (I used our ANJP tool)
Step 3. Compare the STDINFO creation/modification and access times to the FILENAME creation/modification and access times.
If the times in step 3 do not equal you have a file with a possibly altered timestamp.
Step 4. Validate your assumptions and make sure the file wasn't distributed by a vendor with a bad timestamp.
Here is an example, we created a file called 'test.txt'. We then used timestomp to reset the timestamp of that file to 0 which in timestomp terms is 1601-01-01 and the STDINFO creation dates look as follows:
When you look at the FILENAME attribute of the same file you will find the original timestamps:
So the comparison here is pretty obvious, not only because without the possibility of time travel there is no computer file being created in 1601 (Oh man, Time travel forensics!) but also because this file named:
is user created and not part of a system package or other vendor delivered weirdness that you can find. In my testing I found a lot of 0 date FILENAME attribute files within the system32 directory which surprised me.
Let's not stop here though, let's talk about why these things exist. When a file is created in NTFS the first thing that is created is a File record. This file record maintains the basic header needed for NTFS to be able to reference and find the file. The second thing created is the STDINFO or standard information attribute which contains metadata about the file, MAC timestamps, etc..., but not the name of the file itself. Instead the name of the file and an additional set of timestamps is kept in a separate attribute called FILENAME.
The first FILENAME attribute will contain the 8.3 version of the files name (so called because it allows 8 characters in the name and 3 in the extension). If the file name is longer than 8 characters in the name or 3 in the extension then a second FILENAME attribute will be created that will store it and another set of timestamps. There can be even more FILENAME attributes but I haven't found any documentation yet that states all the possible mechanisms that generate additional ones. If you have please leave a comment and let me know.
Tomorrow we will show how setmace works and how using journal forensics we can overcome what is a very effective methods with some limitations on newer platforms.
