Hello Reader,
No time to finish my Gmail code review so I'm going to continue the understanding the artifacts posts to keep things going. I got some good responses yesterday from the prolific Joachim Metz regarding what he's seen in User Assist keys which I updated the post to include. The more we share our knowledge with each other the better picture we have of whats true and whats possible, so if you see something you feel is missing please let me know and I'll incorporate it!
USBStor
Most of us doing forensics are familiar with the USBStor key, we look to it to identify USB devices plugged into a system and identify the make, model (unless its generic) and serial number (as windows reports it) of the device. USBstor also has at least two sister keys IDE (for physical disks) and SBP2stor (for firewire) all of which serve the same purpose. This is one of the first registry artifacts many examiners are made away of as what USB external storage devices have been attached is so important to most investigations. Many times I'm asked as I've stated in the prior post, 'Is the computer logging this to track us? Did the NSA request this feature?'. The answer is, as far as I know, no.
Instead the USBStor and its sister keys are all related to a convenience mechanism to the user that is greatly appreciated. It associates a known device to its loaded driver! Without these keys every time you inserted an external device (USB, eSATA, Firewire in this example), the system would have to look up the driver to load it, check to see if it has the driver and load it. Instead thanks to the caching of known device to driver pairs the device quickly comes up each subsequent plugin.
You might ask, well why does it not stop keeping knowledge of devices after so many days. The answer that its more inefficient to check and expire registry keys and then just recreate them again in the future if the device is plugged in rather than just store it since hard drive space is no longer a premium.
This understanding can help you to explain odd scenarios. For instance lets say a generic USB device was plugged in (many white labeled devices do not identify a specific manufacturer) and from its name you cannot determine what kind of device it was, storage or connectivity of some kind (CDROM, Phone, MP3 player that does not expose its file system). You can look at the driver loaded to determine what functionality Windows made available to the custodian and how the custodian could have made use of it on this system.
It's this kind of deeper understanding that will lead to better explanations, testimony and fact finding. I hope you look to understand deeper and let me know if you think there is functionality that i'm missing in the comments below!
No time to finish my Gmail code review so I'm going to continue the understanding the artifacts posts to keep things going. I got some good responses yesterday from the prolific Joachim Metz regarding what he's seen in User Assist keys which I updated the post to include. The more we share our knowledge with each other the better picture we have of whats true and whats possible, so if you see something you feel is missing please let me know and I'll incorporate it!
USBStor
Most of us doing forensics are familiar with the USBStor key, we look to it to identify USB devices plugged into a system and identify the make, model (unless its generic) and serial number (as windows reports it) of the device. USBstor also has at least two sister keys IDE (for physical disks) and SBP2stor (for firewire) all of which serve the same purpose. This is one of the first registry artifacts many examiners are made away of as what USB external storage devices have been attached is so important to most investigations. Many times I'm asked as I've stated in the prior post, 'Is the computer logging this to track us? Did the NSA request this feature?'. The answer is, as far as I know, no.
Instead the USBStor and its sister keys are all related to a convenience mechanism to the user that is greatly appreciated. It associates a known device to its loaded driver! Without these keys every time you inserted an external device (USB, eSATA, Firewire in this example), the system would have to look up the driver to load it, check to see if it has the driver and load it. Instead thanks to the caching of known device to driver pairs the device quickly comes up each subsequent plugin.
You might ask, well why does it not stop keeping knowledge of devices after so many days. The answer that its more inefficient to check and expire registry keys and then just recreate them again in the future if the device is plugged in rather than just store it since hard drive space is no longer a premium.
This understanding can help you to explain odd scenarios. For instance lets say a generic USB device was plugged in (many white labeled devices do not identify a specific manufacturer) and from its name you cannot determine what kind of device it was, storage or connectivity of some kind (CDROM, Phone, MP3 player that does not expose its file system). You can look at the driver loaded to determine what functionality Windows made available to the custodian and how the custodian could have made use of it on this system.
It's this kind of deeper understanding that will lead to better explanations, testimony and fact finding. I hope you look to understand deeper and let me know if you think there is functionality that i'm missing in the comments below!
No comments:
Post a Comment