"Okay, gotcha…although I still don't get the reference to my tools."
The MFT alone makes not an investigation. And this guy made some good points about incorporating reg records in to analysis with the MFT records
With some references to the $STANDARD_INFORMATION and $FILE_NAME )
And what I think what I was getting at from the SANS post
The benefits of identifying when specific keys are last updated and comparing that to what is occurring on the filesystem is a very telling investigative technique. You can use this to easily identify when files are saved, USB keys are inserted, and programs are executed
I have just been successful in investigations when hitting hard, fast and first at the reg hives and MFT records. Hand in hand that right after an acquisition, an examiner can really get a good course of action for other portions of the investigation. Lot's of mileage from WFA chapters 4-5 and Carrier chapters 11-13.
"yeah, once you reorder the columns properly…"
MFT Ripper column adjustments are still easier that the short name abbreviations for the months that FTK Imager users for CMA outputs - VERY annoying to sort! I put in a feature request, fingers crossed to make it to v3
The MFT alone makes not an investigation.
No, it doesn't…but the OP wasn't asking about an investigation…he was just asking about the entries in the MFT.
And what I think what I was getting at from the SANS post
The benefits of identifying when specific keys are last updated and comparing that to what is occurring on the filesystem is a very telling investigative technique. You can use this to easily identify when files are saved, USB keys are inserted, and programs are executed
I have just been successful in investigations when hitting hard, fast and first at the reg hives and MFT records. Hand in hand that right after an acquisition, an examiner can really get a good course of action for other portions of the investigation. Lot's of mileage from WFA chapters 4-5 and Carrier chapters 11-13.
I agree with what you've said, in the larger sense…but the OP simply said
During an analysis, i realised that the timestamps in $STANDARD_INFORMATION are not consistent with $FILE_NAME.
I'm sorry, but I'm still not following how that, and the two questions that followed, lead to the larger scope of investigations, incorporating Registry keys, etc. I guess I'm just not smart enough to see the connection.
Dude, think you are plenty smart enough. Maybe I am assuming to much in my own interpretation…..
I was looking at the OP and trying to gain context of what his analysis (maybe I wrongly inferred investigation) was trying to achieve.
Qn 1 Should i based my analysis based on $FILE_NAME or $STANDARD_INFORMATION?
Because of the general nature of those entries to have "my analysis based on" those records might be helpful to understand system artifacts as a relation to a larger picture. That is why I tried to maybe influence the poster to a more granular understanding. Because as Sean and you had pointed out, that it is not uncommon to see "$STANDARD_INFORMATION are not consistent with $FILE_NAME" and that a simple comparison might not be what is needed.
…and that a simple comparison might not be what is needed.
Perhaps, but that's all that the OP asked about…
I guess if the OP had asked how these bit of information might fit into an overall investigation, I could see that. But the OP's questions were pretty specific.
I guess I see too many junior analysts making assumptions every day, and I sit and wonder, "how did you get to *that* point, based on the customer's request?" In this case, the OP was just asking about SIA vs FNA, so I didn't see how Registry keys came into play, in the context of the question.
Like I said, I just must be a complete idiot.