Join Us!

Way to tell what pr...
 
Notifications
Clear all

Way to tell what program or process accessed a file?  

  RSS
vrocco
(@vrocco)
Junior Member

Is there any way in Windows to determine what program or process last accessed a file?

If I have a file that I can see was accessed during the time a machine was compromised, can I tell if it was accessed by (for example) a virus scanner or an ftp program?

Thanks in advance.

Quote
Posted : 24/05/2013 11:58 pm
twjolson
(@twjolson)
Active Member

Short answer No.

Long answer Nope.

You could create a super timeline (log2timeline, 4n6time) and see what executables were run (prefetch) at or near the time in question. But even if you see an executable being run and the timestamp being updated right after, you could never say definitively that it was the executable that did so.

You might get lucky with some log files. If, for instance, the virus scanner logged that it scanned a file at 1157am, and the last accessed time is 1157am, there is good odds those two are related.

I reserve the right to change my answer depending on the file in question, and the program in question.

This also assumes that Last Access time updating is on. If it is not, the file could have been accessed a hundred times before, during, and after the last access timestamp, and you'd never know.

ReplyQuote
Posted : 25/05/2013 12:48 am
keydet89
(@keydet89)
Community Legend

While I agree with twjolson, there MAY be ways to tell which program may have accessed the file. However, there are some major caveats…depending upon which version of Windows you're working with, which file you're referring to, etc.

Prefetch analysis may reveal something useful
http//windowsir.blogspot.com/2012/03/prefetch-analysis-revisited.html

Create a timeline of system activity, including data from the user's Registry hives. If Windows 7, consider including the USN Change Journal in your timeline. Look at the activity 'near' the last accessed time of the file in question to see what may have occurred around the same time.

Do a search across the entire system for the file name. You're sure to get a hit in the $MFT, but check for hits in the user shellbags, as well.

None of these are definitive, only possibilities.

ReplyQuote
Posted : 25/05/2013 4:46 am
twjolson
(@twjolson)
Active Member

If Windows 7, consider including the USN Change Journal in your timeline. Look at the activity 'near' the last accessed time of the file in question to see what may have occurred around the same time.

I have not dug too deep into the $UsnJrnl, so please correct me if I am wrong.

That logs changes. But the original question asked about last access times. If a file was accessed, but not changed, why would it be in the $UsnJrnl file?

To clarify my post a little. Computers are so 'busy', as you well know. Even if the poster found an executable what was launched at the same time, or near, the file in question, I would be hesitant to ever say that one caused the other. Windows has many, many processes going on, and you could never say that any particular one (with some caveats) accessed a particular file.

You could theorize, of course, but coming up with theories is easy (and kind of pointless in our profession).

ReplyQuote
Posted : 25/05/2013 10:15 am
keydet89
(@keydet89)
Community Legend

That logs changes. But the original question asked about last access times. If a file was accessed, but not changed, why would it be in the $UsnJrnl file?

I didn't say that it would be…remember, I said these are possibilities. Given the nature of the original question, I was offering up a possibility, in case there was more than just an access to the file.

To clarify my post a little. Computers are so 'busy', as you well know. Even if the poster found an executable what was launched at the same time, or near, the file in question, I would be hesitant to ever say that one caused the other. Windows has many, many processes going on, and you could never say that any particular one (with some caveats) accessed a particular file.

Agreed. Like I said, "possibilities".

You could theorize, of course, but coming up with theories is easy (and kind of pointless in our profession).

Of course…if that is all that is done. However, there is considerable value in proving or disproving those theories in order to further your examination.

ReplyQuote
Posted : 25/05/2013 4:49 pm
armresl
(@armresl)
Community Legend

When I first started testifying I learned to stay away from words like absolutely, never, not possible. I would go and watch trials and see people get shredded when they painted themselves into a corner and tried to leave a small route out by saying "with some caveats"

Never means never, you can't apply caveats to never. If you don't believe me, try it the next time you testify where there is an expert on the other side.

To clarify my post a little. Computers are so 'busy', as you well know. Even if the poster found an executable what was launched at the same time, or near, the file in question, I would be hesitant to ever say that one caused the other. Windows has many, many processes going on, and you could never say that any particular one (with some caveats) accessed a particular file.

If Windows 7, consider including the USN Change Journal in your timeline. Look at the activity 'near' the last accessed time of the file in question to see what may have occurred around the same time.

You could theorize, of course, but coming up with theories is easy (and kind of pointless in our profession).

ReplyQuote
Posted : 27/05/2013 4:04 am
Share: