Hey everyone, Tarah Melton here, and today I’m going to show you a new artifact that you can enable in AXIOM 4.4 when processing a Windows evidence item, called NTFS Timestamp Mismatch.
This artifact is looking for a couple of things that could be potential indicators of malicious activity, like timestomping, which I will detail here. So let’s take a look.
I am in the Artifacts Explorer in AXIOM Examine, under the Operating System Artifact category. I’m going to go ahead and click on that new artifact, and you’ll see there’s a few files listed here.
So after some investigation, we may have a file that’s believed to be malicious, and I’ve bookmarked a couple here. And like I said, there’s a couple of things that this artifact is looking for, and the reason for that hit is going to be stated over here, in the Details pane.
First, the artifact is going to be checking to see if the millisecond values in the timestamp are exactly zero, which can sometimes be an indicator that timestomping activity may have occurred on an infected system.
And second, this artifact will compare the timestamps within the MFT records of the files in the file system from two sections: the $Standard_Information section, and the $File_Name section. The Standard_Information timestamp is what Windows will display to the end user, as well as what most forensic tools will display as far as date and time stamps.
When the Standard_Information timestamp is earlier than the File_Name timestamp, this artifact will flag it as a mismatch.
Now, there are legitimate reasons that this could happen in a normal environment. Sometimes normal system behaviour will cause this to happen. But this artifact can definitely help provide you with a starting point if you believe that timestomping activity occurred on your system.
Under normal circumstances, if we identified this file and we were to timeline the activity of this device, but we’re only pulling the date and time stamps from the Standard_Information section of the MFT, it might not appear to fall into the scope of the timeframe that we’re looking at, because those timestamps were maliciously manipulated. However, the file name timestamps and the MFT record are only modified by the Windows kernel, and will generally go untouched by anti-forensic timestomping activity.
So I’m going to build connections off of this file really quick. And when examining the associated artifacts, most of the activity surrounding this file is in September 2019, from $logfile, usnjrnl, there’s an autorun item.
And you can see – when I focus in on the NTFS timestamp mismatch artifact – we can see how valuable those file name values are. The standard information times fall way out of scope, but the file name times make way more sense and this potentially malicious file does in fact fall into the timeframe that the malicious activity occurred.
So this will help make identifying that malicious activity easier when timestamp manipulation has occurred, especially when comparing it to IDS alerts, network logs, or looking at it in Timeline view which I’m going to go ahead and do right now from the file name timestamp.
And in Timeline view, as I’m scrolling through, you can see how useful it is to be able to pull those file name timestamps from the MFT. It does fall within the time frame that we are looking at.
Finally, I’m going to go ahead and switch over to AXIOM Process, and I’m looking at the artifacts here under ‘Computer.’ And I just want to point out that this artifact is turned off by default, so if it’s something that you’re interested in your case that you’re working, be sure to remember to check the box that’s next to it, so that it runs against your evidence.
So hopefully you’ll find this artifact useful, and for more details of specifics of this artifact at work, please feel free to take a look at the corresponding blog on the Magnet Forensics Resource Center. There are visuals of the MFT records and where these timestamps are being pulled from. And please let us know if you have any questions or comments. Thanks for watching.
