Are any of you aware of any Windows operations/Laptop operations that do batch updates USB registry keys? I'm wondering if there is something going on with the computers at this organization that is causing this, because my forensics machine, which is not joined to the domain, does not have similar issues going on in the registry.
Yes, it's been known for some time that there are times when a Windows update will occur, and for some reason, all of these time stamps are set to the same time.
This is why on Windows 7 (Vista and above, actually), you have to use more than the USBStor key LastWrite times to determine when the devices were connected.
First and while I continue to search this forum and Google for answers to the following questions, does anyone here have a response off-hand?
Second, is there a blog someone can link me to or an official notice from Windows that explains this 'known for some time fact' regarding OS updates that stomp the LastWrite times of the USBStor key?
Third and in reference to the 'you have to use more than the USBStor key to determine when a device was connected' comment - can someone provide a definitive list of locations that show the 'last connected' time of USB devices on a Windows 7 system?
Fourth, if a Windows OS update can timestomp the USBStor dates - can we ever have any faith in this value, outside of the efforts cited in my eighth question?
Fifth, if I have to go somewhere else for a reliable timestamp - why would I ever look to the USBStor key for this information when there's always the risk of it having been stomped? Of course, if this is the only info. you have and/or are just looking to help build a general idea of system activity - I understand. In relation to a specific investigation that hinges on when a device was connected to a system however, it doesn't appear as though this can be reliably cited as a definitive source - less the efforts cited in my eighth question.
Sixth, could the same update that timestomped the USBStor value also have timestomped whatever other locations are cited in response to my third question?
Seventh, are there any other processes that are known to timestomp this or any other 'last connected' date associated with USB devices?
Eighth and in reference to the possibility of an OS update, or any other process, having timestomped the USBStor dates - can someone explain how I might verify this? Outside of looking for discrepancies by comparing 'last connected' times found elsewhere - I assume I could determine each date the system was updated on and if any of those timestamps match the LastWrite key of the inserted USB device, then perhaps I have uncovered the culprit? Any thoughts here? How might I determine the timestamp for each OS update?
https://www.forensicfocus.com/Forums/viewtopic/t=11709/postdays=0/postorder=asc/start=7/
https://www.forensicfocus.com/Forums/viewtopic/t=5772/
I found the posts above but they too appear to have ended without a resolution.
Currently going through the following post but it doesn’t appear to have come to any clear conclusions
https://www.forensicfocus.com/Forums/viewtopic/t=16665/postdays=0/postorder=asc/start=14/
First and while I continue to search this forum and Google for answers to the following questions, does anyone here have a response off-hand?
I'll give it a shot.
Second, is there a blog someone can link me to or an official notice from Windows that explains this 'known for some time fact' regarding OS updates that stomp the LastWrite times of the USBStor key?
Microsoft does not have a profound interest in digital forensics, per se, so it's highly unlikely that you'll find something like that. I'm sure you've already checked, and found this to be true.
Third and in reference to the 'you have to use more than the USBStor key to determine when a device was connected' comment - can someone provide a definitive list of locations that show the 'last connected' time of USB devices on a Windows 7 system?
These have been provided, through open sources such as SANS, etc.
Fourth, if a Windows OS update can timestomp the USBStor dates - can we ever have any faith in this value, outside of the efforts cited in my eighth question?
As has been stated for some time, no. If an analyst is relying solely on the LastWrite times from the Registry keys in question (posted by the OP) for the last time that the device was connected, then that simply makes my point for me (i.e., http//
I'm not trying to blast anyone or call anyone out. These topics are, in fact, complex, in the sense that there is a good bit of information involved, and glossing over or misinterpreting the data from any of the steps will cause the overall findings to be "off".
On a bit of a side note, something that came to mind…more than a few folks in the DFIR industry have mentioned "basic cyber hygiene" over the last couple of months, as it applies to a number of issues. I would suggest that where were are, in this thread, right now, is a result of the DFIR community falling short in basic skills, as well…specifically, documentation.
Fifth, if I have to go somewhere else for a reliable timestamp - why would I ever look to the USBStor key for this information when there's always the risk of it having been stomped? Of course, if this is the only info. you have and/or are just looking to help build a general idea of system activity - I understand. In relation to a specific investigation that hinges on when a device was connected to a system however, it doesn't appear as though this can be reliably cited as a definitive source - less the efforts cited in my eighth question.
Yes, this is similar to a previous question.
Sixth, could the same update that timestomped the USBStor value also have timestomped whatever other locations are cited in response to my third question?
Maybe.
Seventh, are there any other processes that are known to timestomp this or any other 'last connected' date associated with USB devices?
That's a good question.
Eighth and in reference to the possibility of an OS update, or any other process, having timestomped the USBStor dates - can someone explain how I might verify this? Outside of looking for discrepancies by comparing 'last connected' times found elsewhere - I assume I could determine each date the system was updated on and if any of those timestamps match the LastWrite key of the inserted USB device, then perhaps I have uncovered the culprit? Any thoughts here? How might I determine the timestamp for each OS update?
The OP mentioned the use of log2timeline…and therein lies the answer. Unfortunately, it seems that those who have been vocal online about asking questions similar to this one don't understand what they have available when they're looking at a timeline.
Notice I didn't say "timeline analysis". I avoided this phrase specifically because running a tool such as log2timeline, and then asking, "…why are all the USB devices connected at once, based on this time stamp…" clearly illustrates that there is no "timeline analysis" being done. Asking what events could have caused this state (i.e., all USB device time stamps relatively close together) and not bothering to see what happened just prior to that time in the timeline is indicative of a search, but no analysis being done.
The simple fact is that if you have a timeline that includes the necessary data sources, at a minimum, then you have the answers you need right there. I'd be more than happy to assist with the analysis, if you were willing to share the timeline. Beyond that, all anyone can say is that you have the answers.
@op I too have run into these same issues and questions. I also get asked to perform similar investigations. I've never been able to find a great answer either. And I have been to the SANS courses that present the topic (but admit it has been awhile so I don't know if they've improved them or not) and used Harlan's books for guides.
I find the setupapi log file information to be reliable. In a few cases I've found a certain device installed for the very first time on, or very nearly on, an employee's last day of work. That always raises suspicions.
Might suggest you look elsewhere for corroborating information. Link files, jump lists, shellbags with references to drives other than C (or whatever is physically present).
I'm always very careful to present and disclose that these corroborating items, even when they may exist, and appear to "line up" with a hypothesis, are not definitive proof of suspected activities. Also point out that if they DONT exist, does not mean a suspected activity DID NOT take place.
I'm still waiting for the day they actually hand me a USB device that was retrieved from an off premise location (like that's ever gonna happen).
I'm always very careful to present and disclose that these corroborating items, even when they may exist, and appear to "line up" with a hypothesis, are not definitive proof of suspected activities. Also point out that if they DONT exist, does not mean a suspected activity DID NOT take place.
Hmmm.
A very equilibrated opinion. )
I wonder how prosecution (or defense, or however either parties) leverage on your conclusions in these reports. ?
jaclaz
Hmmm.
A very equilibrated opinion. )
I wonder how prosecution (or defense, or however either parties) leverage on your conclusions in these reports. ?
jaclaz
Is that bad/wrong? If I don't see a smoking gun, I'm not going to leave an impression that there was a smoking gun. If someone has a suspicion that something happened I'm of the opinion they like to latch onto anything that corroborates it, no matter how miniscule. I don't want to encourage that. I would rather err on the side of caution, especially in circumstance where there can be doubt (like here where odd results exist).
Also, I've noticed that lawyers are impossible to pin on anything. They speak and answer in ways which leaves quite the latitude for interpretation - why not give it right back to them? )
As to how my conclusions are leveraged, well that is up to the parties to debate.