I read a blog post by Boe Prox while sitting on the beach in Cebu, Philippines 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 is 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.
Test Case I went ahead and created the WriteFileTest1.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. Props to Boe. If you're in Nebraska, buy him a beer.