USB Storage Timesta...
 
Notifications
Clear all

USB Storage Timestamp Registry Anomaly  

Page 1 / 2
  RSS
honor_the_data
(@honor_the_data)
New Member

I'm working on a case at my new job in which I've been asked to determine if there is evidence that an employee took corporate data before resigning to work a competitor.

I'm practically done with the analysis but do not understand what I'm seeing in the USB device timestamps. According to the registry, only one USB mass storage device was ever connected. The last times the keys for that device were written was 9/30/2016 83401 UTC. This doesn't make sence though because the laptop had been collected by my colleague the previous day and it did not have anything connected to at the time of collection.

9/30/2016 83401 UTC- Evidence1\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Seagate&Prod_USB_3.0_Cable&Rev_SA11
9/30/2016 83401 UTC- Evidence1\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Seagate&Prod_USB_3.0_Cable&Rev_SA11\2HC015kj&0
4/18/2016 211858 UTC- Evidence1\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Seagate&Prod_USB_3.0_Cable&Rev_SA11\2HC015kj&0\Device Parameters\Partmgr

I took a look at my registry on my work laptop to see how its timestamps look, since I've connected multiple USB storage devices to it.

10/13/2016 141937 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Apricorn&Prod_&Rev_0133
10/13/2016 183006 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Plugable&Prod_USB3-SATA-UASP1&Rev_0
10/13/2016 141937 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_Seagate&Prod_FreeAgent_GoFlex&Rev__210
10/13/2016 141937 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_TOSHIBA&Prod_External_USB_3.0&Rev_0
10/13/2016 141937 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_WD&Prod_My_Passport_0839&Rev_1072
10/13/2016 141937 UTC- my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\Other&Ven_WD&Prod_SES_Device&Rev_1072

5/6 of the timestamps above are identical, but I surely did not connected those devices at the same time and did not event connect them at all yesterday. The once device with a different timesamp was connected at the specified time. Additionally, the subkeys for each of those have identical timestamps, rather than showing the timestamp of when the device was first connected.

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.

Quote
Posted : 17/10/2016 6:29 pm
jaclaz
(@jaclaz)
Community Legend

Which OS is that?
How (with which tool/program) are you finding those timestamps?
How do they compare with other artifacts (like - say - setupapi.log or similar)?
How do they compare with related other keys (like mountpoints and mountpoints2)?
How do they compare with the full system timeline?

Check these (if applicable)
http//www.swiftforensics.com/2013/11/windows-8-new-registry-artifacts-part-1.html
http//windowsir.blogspot.it/2013/01/there-are-four-lights-usb-accessible.html

jaclaz

ReplyQuote
Posted : 17/10/2016 7:10 pm
honor_the_data
(@honor_the_data)
New Member

OS of Evidence1 Windows 7 Enterprise (Service Pack 1)
OS of my_laptop Windows 7 Enterprise (Service Pack 1)

Tools used to find timestamps Encase 7, Registry Viewer 1.8.0.5 (AccessData), RegistryViewer 1.3 (Gaijin), USBDeview (Nirsoft), log2timeline 0.66
All of the aforementioned tools produced identical registry timestamps.

The setupapi.dev.log shows the date & time when the drive was first connected, but not the last time it was connected, which is what I am really interested in. The initial connection timestamp was consistent with the times found with the aforementioned tools.

Other artifacts on the system make it seem as though Windows was started up at 9/29/2016 at 192903, which is the same time my colleague picked up the system, according to the chain of custody form. There are no shutdown events after this.

Nothing was attached to it though and the most recent attachment time, according to the registry timestamps, was 13 hours after the last start and was during the middle of the night for us.

ReplyQuote
Posted : 17/10/2016 9:46 pm
jaclaz
(@jaclaz)
Community Legend

The setupapi.dev.log shows the date & time when the drive was first connected, but not the last time it was connected, which is what I am really interested in. The initial connection timestamp was consistent with the times found with the aforementioned tools.

Other artifacts on the system make it seem as though Windows was started up at 9/29/2016 at 192903, which is the same time my colleague picked up the system, according to the chain of custody form. There are no shutdown events after this.

Nothing was attached to it though and the most recent attachment time, according to the registry timestamps, was 13 hours after the last start and was during the middle of the night for us.

I don' tknow, IF the setupapi.dev.log indicates as first install a date/time before the 9/29/2016 at 192903 AND the other keys/artifacts indicate a date/time after that for the SAME device, since it is impossible (if you are not in possession of THAT device) that - even by mistake - it was re-connected after seizure, those Registry time stamps must be *somehow* fake/fabricated or the like. ?

jaclaz

ReplyQuote
Posted : 17/10/2016 11:10 pm
honor_the_data
(@honor_the_data)
New Member

The first install date, as indicated by the setupapi.dev.log and the registry was 4/18/2016, which is well before the scope of the investigation.

The last connected timestamps definitely do seem like they are fake/erroneous but the really unusual part is that my own laptop had similar behavior in that registry keys for USB devices had been updated as a batch even when I know that those devices were not connected at those times. For example, my laptop currently shows six devices under my_laptop\HKLM\SYSTEM\ControlSet001\Enum\USBSTOR\. The timestamps for all six are 10/14/2016 181134 UTC, but I know that I had only 1 of those devices connected at that time.

Weird huh?

ReplyQuote
Posted : 17/10/2016 11:36 pm
passcodeunlock
(@passcodeunlock)
Senior Member

I think that one of your installed USB drivers is malfunctioning somehow, mixing up the USB addressing and writing unreliable data to the logs.

On your test laptop remove all your USB entries with USBDeview, then refresh the hardware components in your Device Manager. After that, test a bit with connecting and disconnecting different USB devices, see if the dates/times for logs work as they are supposed to work.

ReplyQuote
Posted : 18/10/2016 1:09 am
honor_the_data
(@honor_the_data)
New Member

I think that one of your installed USB drivers is malfunctioning somehow, mixing up the USB addressing and writing unreliable data to the logs.

On your test laptop remove all your USB entries with USBDeview, then refresh the hardware components in your Device Manager. After that, test a bit with connecting and disconnecting different USB devices, see if the dates/times for logs work as they are supposed to work.

I'll give that a shot. Thanks for the tip.

ReplyQuote
Posted : 18/10/2016 1:13 am
BarryC
(@barryc)
New Member

What Windows version is it?
Depending on the version, you can find some timestamps in the Security Auditing event log.

ReplyQuote
Posted : 19/10/2016 5:31 am
jaclaz
(@jaclaz)
Community Legend

What Windows version is it?
Depending on the version, you can find some timestamps in the Security Auditing event log.

OS of Evidence1 Windows 7 Enterprise (Service Pack 1)
OS of my_laptop Windows 7 Enterprise (Service Pack 1)

roll

jaclaz

ReplyQuote
Posted : 19/10/2016 1:59 pm
keydet89
(@keydet89)
Community Legend

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.

ReplyQuote
Posted : 03/12/2016 4:34 pm
jaredpquinn
(@jaredpquinn)
New Member

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?

ReplyQuote
Posted : 14/08/2019 4:50 am
jaredpquinn
(@jaredpquinn)
New Member

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/

ReplyQuote
Posted : 14/08/2019 7:37 am
keydet89
(@keydet89)
Community Legend

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//windowsir.blogspot.com/2019/08/chasing-dfir-cure.html).

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.

ReplyQuote
Posted : 14/08/2019 1:30 pm
gpwinkler
(@gpwinkler)
New Member

@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).

ReplyQuote
Posted : 30/08/2019 7:48 pm
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 30/08/2019 8:17 pm
Page 1 / 2
Share: