The Most/Recent Articles

Showing posts with label timestamps. Show all posts
Showing posts with label timestamps. Show all posts

Daily Blog #814: Sunday Funday 4/20/25

 


Hello Reader, 

It's an Eng world and we are just living in it, unless of course you take the time to put in an entry this week and win! This week we are changing courses to an old file system problem with some utilities.

The Prize:

$100 Amazon Giftcard


 
The Rules:

  1. You must post your answer before Friday 4/25/25 7PM CST (GMT -6)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtful
  6. Anonymous entries are allowed, please email them to dlcowen@gmail.com. Please state in your email if you would like to be anonymous or not if you win.
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post
  8. AI assistance is welcomed but if a post is deemed to be entirely AI written it will not qualify for a prize. 


The Challenge:

FAT32 does not store a time stamp for access dates, it only records the date. However many tools have or have in the past actually treated the zero time entry as a real time entry and adjusted it for time zones. Test your favorite tools such as , ftk imager, xways, axiom, encase, autopsy your choice but you must submit at least two and show if they are correctly handling FAT32 timestamps.

 

Daily Blog #269: Cool! When did FTK start doing that? #1 Create/mod dates of Carved PDFs from PDF metadata

Create/mod dates of Carved PDFs from PDF metadata

Hello Reader,
          Occasionally in our work we stumble across new features from our tools that suddenly makes our lives easier. A long time ago I blogged about when FTK made the 'export lnk metadata' option available which made our lives so much easier. Today I want to talk about something else they just kinda put in and don't know when.

FTK is now correctly parsing out the creation and modification dates (if they exist) from carved pdf files and placing them in the correct fields within the interface. This may sound simple and apparent but for a very long time any carved file within FTK would have no time entries as well, they had no file timestamps... they were carved. What we saw this week was for those files that have timestamps within their metadata FTK is starting to pull this out in the processing of the carved file and sticking them into their relevant timestamp location.

Does this sound simple? It is, but it can be a huge time saver! Here is an example. I have a pdf file that I'm looking for an image that has been deleted and is no longer recoverable from all the usual locations (recycle bin, mft deleted file record, shadow copy, etc..) so I have to carve to find it. I know the date the file was created on the system as I still have a shellbag from the desktop access of the file, but I believe that it is a scanned image stored in a pdf. This presents a problem as I can't just do a keyword search for what I think the file contains as its an image.

You could try to OCR all of the carved pdf's and then search for keywords, but calling the OCRing of carved data (which may be incomplete and curropted) failure prone is being kind. So instead I was able to filter my file list for carved pdf's and then sort by create date. Boom there was one carved pdf created on the same day as the shellbag entry pointing to it. A quick preview of the file within Adobe Reader and I had what I was looking for.

So the next time you are what appears to be a huge lake of carved data trying to find a file interest, check to see if the tool you are using is exposing the dates stored within the document metadata it could be your ticket to a quick resolution.

Also Read: Daily Blog #268

Daily Blog #130: Detecting Fraud Sunday Funday 10/27/13 Part 3 - SetMace

Detecting Fraud SetMace by David Cowen - HECF Blog

Hello Reader,
            Yesterday we reviewed the timestomp tool and showed how simple MFT analysis can defeat it. Today we are going to go into the newest version of setmace v1006 which not only can modify the STDINFO timestamps but the FILENAME timestamps as well. 

I'm not sure how widely known setmace is but I will tell you that its very good at what it does as we'll see in the screenshots below. Prior versions of setmace did some tricks with file moving to reset the FILENAME timestamps but in version v1006 it actually modifies the physical disk itself leaving very few traces of its actions. Setmace will work on NTFS and FAT file systems.

Things to understand

What it does


Setmace will access the underlying physical disk and modify the $MFT directly changing the timestamps you specify (STDINFO or FILENAME or both) or cloning them from another file. Since this is direct physical disk access there are no $logfile or USN entries that show these changes.

What it does not do


It does not change the MFT record number, sequence number or find other artifacts pointing to it. That does not mean that future versions couldn't be modified to further obfuscate the original timestamps.

Capabilities by OS


Windows XP


On a Windows XP system setmace can reset timestamps on a file on any volume as XP's security model did not restrict access to the physical disk. Further since Windows XP does not have a USN Journal by default the only way to prove the original timestamps of a file will either be through the $Logfile or shell items pointing to the file.

Windows Vista/7/8


On a Windows Vista/7/8 system setmace cannot access the physical disk of any system volume, but it can access the physical disk of non system volumes. In my virtual environment I created two additional partitions one which i ran setmace from and the other where i stored the files whose timestamps i reset.

What does it look like?

After setmace runs this is what the STDINFO timestamps look like:

Detecting Fraud SetMace by David Cowen - HECF Blog

This is what the FILENAME timestamps look like for both the 8.3 and Unicode filenames:

Detecting Fraud SetMace by David Cowen - HECF Blog

I've used 1-1-1970 here to make it easy to spot that this is a fake timestamp but notice something here, the milliseconds here are set. This is another standard forensic analysis technique to detect timestamp modification, finding files where the milliseconds are set to 0. In this instance our suspect could set the full timestamp value to any date/time desired or clone a valid file. Scary stuff

The USN Journal contains no entries as the timestamp alteration occured outside the filesystem driver, we do have an entry from the usage of the file prior to its timestamp alteration that we can gather a last true usage time from:

Detecting Fraud SetMace by David Cowen - HECF Blog

The $Logfile contains the original timestamps of these files from its creation:

Detecting Fraud SetMace by David Cowen - HECF Blog

However there is no entry in any of the filesystem journal logs we normally rely on that would detail the fact that a timestamp change occured, it would be up to the analyst to look for indicators.

What indicators are left?

Don't lose hope, this isn't a blank check just yet for undetectable timestamp alteration. We still have several analysis points left that can reveal past true timestamps of this file:

  • Shell Items contain timestamps, compare them to the MFT to determine if MFT creation date is different. Examples of Shell item containers include
    • LNK Files
    • Shell bags
    • Jumplists
    • Other registry keys being identified but that I don't have in front of me :) Sounds like a good post for next week.
  • MFT entry and sequence numbers, is the file outside the range that it should be in to be created at that time? 
  • Registry MRUs
  • System restore points
    • Vista/7/8 - Shadow copies - Compare MFTs
    • XP - Restore Points  - Parse LNK files for shell items
  • Any activity taken place through the filesystem driver prior to the timestamps change will still be in the $logfile and USN
  • Prefetch of the setmace execution
Now having said this, not every analyst will think of these things. This will require an additional  steps in your process to look for these kinds of indicators and likely won't be the first thing you check for. Setmace will modify timestamps but it doesn't eliminate any of the IOCs/Artifacts you are already looking for.

I am going to be looking deeper into setmace to see what other artifacts of execution exist, I'll follow up on this on a later blogpost. Until then get some rest, these anti-forensic tools will only get better and you will have to do get better as well to keep up.

This is a 3-part series and here are all links to the entire series:

Daily Blog #129: Detecting Fraud Sunday Funday 10/27/13 Part 2 - Timestamp changes

Detecting Fraud Part 2 - Timestamp Changes

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:

Detecting Fraud Part 2 - Timestamp Changes


When you look at the FILENAME attribute of the same file you will find the original timestamps:

Detecting Fraud Part 2 - Timestamp Changes

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:

Detecting Fraud Part 2 - Timestamp Changes

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.

This is a 3-part series and here are all links to the entire series:

Daily Blog #128: Detecting Fraud Sunday Funday 10/27/13 Part 1 - Time Changes

Detecting Fraud - Time Changes - HECF Blog

Hello Reader,
           Let's talk about system clock changes which is one of the areas not covered by this weeks Sunday Funday winning answer. Often times when creating fraudulent documents a suspect will change the date of the system in order to make the document appear to be generated at an earlier time. If you've done these cases on Windows XP you've probably read Steve Bunting's old blog regarding this, http://www.stevebunting.org/udpd4n6/forensics/timechange.htm. However the event ids and sources have changed since XP and since this challenge focuses on Windows 7 I thought it would be useful to show what clock changes now look like.

Windows 7 has a lot more logging turned on by default, as such clock time change events are logged. The entry will be found in the 'Security' event log and the source will be 'Microsoft Windows security auditing'. The task category is 'Security State Change' and the Event ID is 4616. Here is an example:

Detecting Fraud - Time Changes - HECF Blog

You can see that the event records the previous and new times, in this case my clock was 9 minutes behind and I set it forward. If the clock were to be changed back you would see the new time be earlier than the previous time.

If you wanted to quickly determine if a user had changed the system clock recently this is the best place to quick filter for Event ID 4616. The security log for a workstation on my system goes back two months and there would be additional copies of it in the shadow copies and possible freesspace if you can recover event log entries from freespace.

So that is a pretty simple way to detect when the system clock for the entire system is changed, pretty easy huh? Tomorrow we will going into individual files timestamps being altered.