System Forensics

All your artifacts are belong to us.

LastWriteTime and LastAccessTimes via Powershell

I read a blog post by Boe Prox while sitting on the beach in Cebu this past weekend, which oddly enough is the same guy I used to work with about 6+ years ago when I was working for BAE Systems back in Nebraska. Small world, eh?
In either case here is the post: Write to an Existing File without updating LastWriteTime or LastAccessTimestamps using Powershell

As you can tell after reading his post, this script has the capability to make our DFIR lives a bit harder when it’s used to perform “bad things”.

Or does it? On the surface yes, I do believe it can and will be used to fool people, but can it hold up to rock star timeline analysis and fool all of the good old MFT timestamps we are provided? Highly unlikely, but let’s take a look at an example anyway.

I might also note that Boe doesn’t claim that his script will/can fool detailed MFT/timeline analysis. He claims that it doesn’t modify LastWriteTime and LastAccessTime, which is correct as you will see below (and from his blog).

TEST CASE:

I went ahead and created the WriteFile_Test_1.txt file at 11:17am.

Here we are simply gathering some information about our drive so we can narrow down information and feed it to fls. Specifically the starting sector of our NTFS partition so we can pass it off as the offset to fls and istat.

Next we will run fls so we can figure out where the file is located. You can see that it’s located at inode 121105-128-1 – Now we can use istat and pull out our timestamp information.

Here we can run istat. You see the Standard Information Attribute (SIA) that provides us with some of our timestamp artifacts (in addition to others). There are also timestamps located within the File Name attribute as well, but we won’t be looking them today. We are going to be looking at SIA.

As you can see our times pretty much all line up at this point. We haven’t modified or done anything to the file since we created it. All is normal at this point. Let’s move forward and write to the file with the write-file powershell script that Boe created.

Here we are going to add one line to the file. You can see in this image that we added the line, “It is 11:49ish now and this is our first test”.

Note the modified date hasn’t changed. It’s the same time as above when we first created the file.

Let’s see what it looks like using istat again. You can see here that the only time change was MFT Modified, which is the time when the MFT record was last modified.

Let’s look at what happens if you modify the file with something like the windows echo command.

You notice here that when we used a simple echo command to append a file it updated all of the timestamps except the creation date.

So the script does what it’s suppose to do, but it can’t account for the MFT change time. It can’t fool the last time the MFT record was last modified, which can be an indicator when doing analysis.

On the flip side doing that level of analysis is time consuming, and you’re more than likely not going to be doing that kind of analysis if you haven’t already been tipped off or suspect something was wrong to begin with.

If you suspect something is wrong then dig a bit deeper and see what you come up with. Don’t assume everything is what it says it is. It might just be smoke and mirrors.

I would like to see Boe continue refining the script and see what else he can come up with. Maybe a true timestomping script? Props to Boe. If you’re in Nebraska, buy him a beer.

Tweet

Enjoy!

, , , , ,

Comments are currently closed.

One thought on “LastWriteTime and LastAccessTimes via Powershell

  • Keydet89 says:

    Interesting post…both this one and the original one, as well. I appreciate the time and effort that you both took to document all of this…it’s clearly repeatable, which is not something that you see in the DFIR community very often.

    That being said, I do think that using this technique…essentially, a use of a publicly available API with ‘special’ parameters…would indeed fool most normal IT admins and junior DF analysts. Most folks conversant with timeline analysis, for example, know that there’s much more to timeline analysis than what’s in the timeline…it’s not the end of analysis, it’s just the beginning.

    I think that what you need to look at is how something like this would be employed. It likely would not be a one-time thing…if the attacker was able to get malware on the system, something that created and appended to a file, then they’d want to have the capability present to keep the time stamps static throughout the life of the file, wouldn’t they?

    My point is that this is something that will work against casual observers, and perhaps even some knowledgeable analysts, but it’s a single data point in an environment where multiple data points are employed in analysis.

    Again, thanks for your efforts…