Book Update
I've received the counter-signed contract from Syngress for Windows Forensic Analysis 3/e, and I'm finishing up a couple of the chapters to get in for review. This book is NOT the same as 2/e, in that I did not start with the manuscript from that edition (the way I did when I started 2/e). Instead, 3/e is a companion edition...if you already have 2/e, you will want to have 3/e, as well. This is because the information in 2/e is still valid, and in many instances (in particular information such as the PE file format, etc.) hasn't changed. Also, 2/e focused primarily on XP, and those systems are still around...there hasn't been a huge corporate shift to Windows 7 yet. As such, 3/e will shift focus to Windows 7...it will also focus more on solving problems, rather than simply depositing technical information in your lap and leaving you to figure out what to do with it.
Another new aspect of WFA 3/e is that rather than providing an accompanying DVD, the tools (as with WRF) will be provided online. Providing the tools in this manner is just so much easier for everyone, particularly when someone purchases the ebook/Kindle version of the book, or leaves their DVD at home. As with my previous books, I will do my best to provide functioning, tested code along with book, and provide links to other tools mentioned, described, or discussed in the book.
Accessing VSCs
I've posted before on accessing Volume Shadow Copies, but thanks to a recent blog post from Corey Harrell, I thought that it might be a good idea to revive the topic. In his post, A Little Help with Volume Shadow Copies, Corey walks through a means for automating access to several VSCs, as well as automating the collection of information from each. Corey does this through the use of a batch file.
Accessing VSCs in this manner is nothing new...it's been around for a while. This post appeared on the Forensics from the sausage factory blog over a year ago. In this post, copying of specific files via robocopy is demonstrated, showing how to use batch files to mount VSCs, copy files and then unmount the VSCs. Corey's script takes a different approach, in that rather than copying files, he rips Registry hives using RegRipper (more accurately, rip.exe). Corey was kind enough to provide a commented copy of one iteration of his batch file for inclusion in the materials associated with WFA 3/e (see above).
More than anything else, this is just the beginning. Corey's had a need and used already-available information as a stepping stone to meeting his needs. Whether you use the VHD method for mounting images, or the VMWare method (described by Rob Lee and Jimmy Weg), or some other method, the fact is that once you mount the VSC, it's simply a matter of getting the job done. You can either copy out the Registry hives, or do as Corey's done, and run RegRipper (you'll still have the image and VSCs to access if you need the original data) on the hives. You can copy or query for other files, as well, or use other tools (some I'll mention later). In fact, with the right tools and a little bit of thought, you can do pretty much anything...compare files by hash, look for specific files, etc. You may need to build some tools (or reach to someone for assistance), or download some tools, but you can piece some pretty decent automated (and self-documenting) functionality together and achieve a great deal.
Open Source Tools Book
Speaking of books, the book that Cory Altheide wrote (I was a minor co-author), Digital Forensics with Open Source Tools (aka, "DFwOST"), has been published and should be available to those who pre-ordered it soon. Also, a really good idea is to follow @syngress on Twitter...I've been asked a couple of times if I will be providing a discount; I didn't provide the discount, Syngress did via Twitter. I simply "RT'd" it. You should really check this book out. Cory's goal was to provide a means for folks with a basic understanding of digital forensics (and limited means) with an understanding of some of the open source tools available to them, and how to get them installed and configured. And he did a great job of it!
My books have focused on the analysis of Windows systems, and have discussed/described free and open source tools that can assist an analyst. Cory's book focuses on the open source tools, and covers several that you can use to analyze Linux, MacOSX and Windows systems.
SANS Forensic Summit
I don't know if you've seen it, but Rob's posted the agenda for this year's SANS Forensic Summit, to be held on 7 and 8 June, in Austin, TX. Check it out...there are a number of great speakers, and several panels, which have proven to be an excellent format for conferences, as opposed to just having speaker after speaker.
It looks like Chris is gonna kick right off with his "Sniper Forensics" presentation, which has been getting him a LOT of mileage. Richard Bejtlich is also presenting, in addition to being on a panel on the second day. All in all, it looks like this will be another great opportunity to hear some good presentations, as well as to mingle with some of the folks in the business who are right there in the trenches.
OSDFC
I wanted to give another plug for Brian Carrier's OSDFC, the open source conference coming up on 14 June in McLean, VA. Cory Altheide and I will both be presenting; I'm presenting in the morning, and Cory's got clean-up in the afternoon; that's Brian's tactic to get everyone to stay, by saving the best for last! ;-) I hope that this will be another great opportunity to mingle with others in the community...I had several interesting conversations with attendees at last year's conference. Also, don't forget...DFwOST is out! Bring your copy and get both of us to sign it...although you may have to wait for the cocktail reception at the end for that!
Scalpel
There's an announcement over at the DFS Forensics blog that scalpel 2.0 is available. There are some interesting enhancements, and the download contains pre-compiled Windows binaries and the source code.
USBStor
I received another question today that I see time and again, via email and in the lists/forums, having to do with LastWrite times on the USBStor subkeys and how they apply to the time that a USB device was last connected to the system.
In this particular case, the person who emailed me had confiscated and secured the thumb drive, and then found that the LastWrite time (apparently, the system itself was still active) for the USBStor subkey had been updated recently.
Folks, I really don't understand how this can be written and talked about so much, published in books (WFA 2/e, WRF, etc.) and STILL be so misunderstood. Rob Lee's even made PDFs available that describe very clearly how to perform USB device analysis (XP, Vista/Win7).
If you want to know more about what may have caused the USBStor subkey LastWrite time to be updated when the device hadn't been connected, or more about why all of the USBStor subkeys have the same LastWrite time, put together a timeline. Seriously. I've seen both of these questions (some even include, "...I need to explain this in court..."), and a great way to answer it is to create a timeline of activity on the system and see what occurred around that time.
Showing posts sorted by relevance for query usbstor. Sort by date Show all posts
Showing posts sorted by relevance for query usbstor. Sort by date Show all posts
Friday, April 22, 2011
Saturday, August 30, 2008
RegRipper News and Mentions
I'm never really sure who's using RegRipper and how they're using it, or how they'd like to use it. However, getting input or feedback from the folks using it inevitably leads to making RegRipper a better tool.
James E. Martin mentioned RegRipper in his Detection of Data Hiding in Computer Forensics presentation. In the presentation, Mr. Martin demonstrated the use of RegRipper to extract USB device information from a System hive file.
I was recently discussing the issue of presenting USB data from multiple systems in an easy-to-view and -manage manner using RegRipper with another examiner. RR is a GUI tool that parses one file at a time...however, rip.exe comes along with it (another user recently contacted me and informed me that he made a couple of minor modifications and now runs rip.pl on Linux) and is a command line interface (CLI) tool that is easy to automate via a batch file. In order to provide something useful to the examiner, I opened up the usbstor.pl plugin, and within minutes made some minor modifications so that the output was .csv format. I then added the code from the mountdev.pl plugin to map USB removeable storage devices to a drive letter, if the information is available. Finally, I added the code from the compname.pl plugin to extract the name of the system from the System hive file...if you're running this across multiple hive files, you will need a way to differentiate the various systems in your output.
So, the resulting plugin, which took all of maybe 30 minutes to create, tweak and test can be run via rip.exe like so:
C:\Perl\forensics\rr>rip -r d:\cases\system -p usbstor2
The output for this System hive file looks like:
PETER,Disk&Ven_&Prod_USB_DISK&Rev_1.13,0738015025AC&0,
1127776426,USB DISK USB Device,
7&2713a8a1&0,\DosDevices\E:
So, the output is:
- System name
- Device class ID
- Serial Number
- LastWrite time from the unique ID key, 'normalized' to Unix time
- The "FriendlyName" value from the unique ID key
- The ParentIdPrefix value, if available
- The DosDevice listed in the MountedDevices key, if the ParentIdPrefix value exists
So, to run this against multiple System hive files, simply create a batch file that contains lines that look like this:
C:\Perl\forensics\rr>rip -r System -p usbstor2 >> usbstor.csv
Once you run this, the usbstor.csv file can be opened in Excel and you can quickly and easily determine devices that were connected to multiple systems, etc.
This just shows you how easy-to-use and flexible this tool set is. To see even more, don't miss the SANS Forensic Summit, where I'll be discussing Registry analysis and demonstrating these tools, as well as something else very special!
James E. Martin mentioned RegRipper in his Detection of Data Hiding in Computer Forensics presentation. In the presentation, Mr. Martin demonstrated the use of RegRipper to extract USB device information from a System hive file.
I was recently discussing the issue of presenting USB data from multiple systems in an easy-to-view and -manage manner using RegRipper with another examiner. RR is a GUI tool that parses one file at a time...however, rip.exe comes along with it (another user recently contacted me and informed me that he made a couple of minor modifications and now runs rip.pl on Linux) and is a command line interface (CLI) tool that is easy to automate via a batch file. In order to provide something useful to the examiner, I opened up the usbstor.pl plugin, and within minutes made some minor modifications so that the output was .csv format. I then added the code from the mountdev.pl plugin to map USB removeable storage devices to a drive letter, if the information is available. Finally, I added the code from the compname.pl plugin to extract the name of the system from the System hive file...if you're running this across multiple hive files, you will need a way to differentiate the various systems in your output.
So, the resulting plugin, which took all of maybe 30 minutes to create, tweak and test can be run via rip.exe like so:
C:\Perl\forensics\rr>rip -r d:\cases\system -p usbstor2
The output for this System hive file looks like:
PETER,Disk&Ven_&Prod_USB_DISK&Rev_1.13,0738015025AC&0,
1127776426,USB DISK USB Device,
7&2713a8a1&0,\DosDevices\E:
So, the output is:
- System name
- Device class ID
- Serial Number
- LastWrite time from the unique ID key, 'normalized' to Unix time
- The "FriendlyName" value from the unique ID key
- The ParentIdPrefix value, if available
- The DosDevice listed in the MountedDevices key, if the ParentIdPrefix value exists
So, to run this against multiple System hive files, simply create a batch file that contains lines that look like this:
C:\Perl\forensics\rr>rip -r System
Once you run this, the usbstor.csv file can be opened in Excel and you can quickly and easily determine devices that were connected to multiple systems, etc.
This just shows you how easy-to-use and flexible this tool set is. To see even more, don't miss the SANS Forensic Summit, where I'll be discussing Registry analysis and demonstrating these tools, as well as something else very special!
Monday, September 19, 2011
Links and Updates
iTunes Forensic Analysis
I ran across a very interesting read regarding the forensic analysis of an iTunes installation via DFINews. One of the things I see consistently within the community is that folks really want to see how someone else has done something, how they've gone about conducting an exam or investigation, and this is a good example of that.
Volatility Updates
Keep your eye on the Volatility site for updates that include support for Windows 8, thanks to the efforts of @iMHLv2, @gleeda, @moyix, and @attrc.
Speaking of Volatility, the folks at p4r4ni0d take a look at Morto. Great work, using a great tool set. If you want to see how others using Volatility, take a look at the blog post.
NetworkMiner
A new version of NetworkMiner has been released. If your work involves pcap capture and analysis, this is one tool that I'd definitely recommend that you have in your kit.
Registry
Andrew Case (@attrc) put together a very good paper (blog post here) on how he went about recovering and analyzing deleted Registry hives. Now, this is not recovering deleted keys from within hive files...Andrew recovered entire hive files from unallocated space after (per his paper) the system had been formatted and the operating system reinstalled. Take a look at the process he went through to this...this may be something that you'd want to incorporate into your tool kit.
If you're read Windows Registry Forensics, you'll understand Andrew's approach; Registry hive files (including those from Windows 8) start with 'regf' at the first 4 bytes of the file. The hive files are broken into 4k (4096 bytes) pages, with the first one beginning with 'regf'; the subsequent pages start with 'hbin'.
I've done something similar with respect to Windows XP Event Logs, carving specifically for individual records rather than entire Event Log (.evt) files. In much the same way, Andrew looked that goals of his examination, and then used the tools he had available to accomplish those goals. Notice that in the paper, he didn't discuss re-assembling every possible hive file, but instead only those that might contain the data/information of interest to his examination. Nor did he attempt to carve every possible file type using scalpel; he only went after the types of files that he thought were necessary.
When I wrote my event record carving tool, I had the benefit of knowing that each record contains the record size as part of its metadata; Andrew opted to grab 25MB of contiguous data from the identified offset, and from his paper, he appears to have been successful.
Also, page 4 includes a statement that is extremely important; "This is necessary as USBSTOR keys timestamps are not always reliable." As you're reading through the paper, you'll notice that Andrew focused on the USBStor keys in order to identify the devices he was looking for, but as you'll note from other sources (WRF, as well as Rob Lee's documentation), the time stamps on the USBStor keys are NOT a reliable indicator of when a USB device was last connected to (or inserted into) a system. This is extremely important, and I believe very often confused.
More importantly, I think that Andrew deserves a great big "thanks" for posting his process so clearly and concisely. This isn't something that we see in the DFIR community very often...I can only think of a few folks who do this work who've stepped up to share this sort of information. Clearly, this is a huge benefit to the community, as I would think that there will be folks reading his paper who will think to themselves, "wow, I could've used that on that examination!", just as others will likely be using it before 2011 closes out. Notice that there's nothing in the write-up that specifically identifies a customer or really gives away any case-specific data.
Andrew's paper is an excellent contribution to the community, and provides an excellent look at a thorough process for approaching and solving a problem using what you, as an examiner, have available to you. Something else to consider would be to look for remnants of the (for Windows XP) setupapi.log file, which would provide an indication of devices that had been connected (plugged in, attached, inserted into) to the system. I've done something similar with both the pagefile and unallocated space...knowing what I was looking for, I used Perl to locate indications of the specific artifacts, and then grab X number of bytes on either side of that artifact. As an example, you could use the following entry from a setupapi.log file:
Now, search for all instances of the above string, and then grab 200 or more bytes on either side of that offset and write it to a file. This could provide some very useful information, as well.
Timelines
Corey has an excellent post up regarding the thought processes behind putting a timeline together. I'd posted recently on how to go about creating mini-timelines from a subset of data; in his post, Corey discusses the thought process that he goes through when creating timelines, in general...he also provides an example. If you look at the "Things to consider" section of his post, you'll notice some similarity to stuff I've written, as well as to Chris Pogue's Sniper Forensics presentations; in particular, the focus on the goals of the examination.
In his post, Corey mentions two approaches to timelines; the "kitchen sink" (including everything you can, and then performing analysis) and the "minimalist" approach. From my perspective, the minimalist approach is very similar to what Corey describes in his post; you can add data sources to a timeline via a "layering" approach, in that you can start with specific data sets (file system metadata, Event Logs, Prefetch file metadata, Registry metadata, Jump Lists, etc.), and then as you begin to develop a more solid picture, add successive layers, or even just specific items, to your timeline. The modular approach to the tools I use and have made available makes this approach (as well as creating mini-timelines) extremely easy. For example, during an examination involving a SQL injection attack, I put together a timeline using just file system metadata and pertinent web server log entries. For an incident involving user activity on a system, I would create a timeline using file system metadata, Registry key LastWrite times (as well as specific entries, such as UserAssist data), Event Log entries, Prefetch file metadata, and if the involved system were Windows 7, Jump List metadata (including parsing the DestList stream and sorting the entries in MFU/MRU order). In a malware detection case, I may not initially be interested in the contents of any user's web surfing activity, with the exception of the LocalService or "Default User" user accounts.
This is not to say that one way is better or more correct than another; rather, the approach used really depends upon the needs of the examination, skill set of the analyst, etc. I've simply found, through my own experience, that adding everything available to a timeline and then sorting things out doesn't provide me with the level of data reduction I'm looking for, whereas a more targeted approach allows me to keep focused on the goals of the examination.
I ran across a very interesting read regarding the forensic analysis of an iTunes installation via DFINews. One of the things I see consistently within the community is that folks really want to see how someone else has done something, how they've gone about conducting an exam or investigation, and this is a good example of that.
Volatility Updates
Keep your eye on the Volatility site for updates that include support for Windows 8, thanks to the efforts of @iMHLv2, @gleeda, @moyix, and @attrc.
Speaking of Volatility, the folks at p4r4ni0d take a look at Morto. Great work, using a great tool set. If you want to see how others using Volatility, take a look at the blog post.
NetworkMiner
A new version of NetworkMiner has been released. If your work involves pcap capture and analysis, this is one tool that I'd definitely recommend that you have in your kit.
Registry
Andrew Case (@attrc) put together a very good paper (blog post here) on how he went about recovering and analyzing deleted Registry hives. Now, this is not recovering deleted keys from within hive files...Andrew recovered entire hive files from unallocated space after (per his paper) the system had been formatted and the operating system reinstalled. Take a look at the process he went through to this...this may be something that you'd want to incorporate into your tool kit.
If you're read Windows Registry Forensics, you'll understand Andrew's approach; Registry hive files (including those from Windows 8) start with 'regf' at the first 4 bytes of the file. The hive files are broken into 4k (4096 bytes) pages, with the first one beginning with 'regf'; the subsequent pages start with 'hbin'.
I've done something similar with respect to Windows XP Event Logs, carving specifically for individual records rather than entire Event Log (.evt) files. In much the same way, Andrew looked that goals of his examination, and then used the tools he had available to accomplish those goals. Notice that in the paper, he didn't discuss re-assembling every possible hive file, but instead only those that might contain the data/information of interest to his examination. Nor did he attempt to carve every possible file type using scalpel; he only went after the types of files that he thought were necessary.
When I wrote my event record carving tool, I had the benefit of knowing that each record contains the record size as part of its metadata; Andrew opted to grab 25MB of contiguous data from the identified offset, and from his paper, he appears to have been successful.
Also, page 4 includes a statement that is extremely important; "This is necessary as USBSTOR keys timestamps are not always reliable." As you're reading through the paper, you'll notice that Andrew focused on the USBStor keys in order to identify the devices he was looking for, but as you'll note from other sources (WRF, as well as Rob Lee's documentation), the time stamps on the USBStor keys are NOT a reliable indicator of when a USB device was last connected to (or inserted into) a system. This is extremely important, and I believe very often confused.
More importantly, I think that Andrew deserves a great big "thanks" for posting his process so clearly and concisely. This isn't something that we see in the DFIR community very often...I can only think of a few folks who do this work who've stepped up to share this sort of information. Clearly, this is a huge benefit to the community, as I would think that there will be folks reading his paper who will think to themselves, "wow, I could've used that on that examination!", just as others will likely be using it before 2011 closes out. Notice that there's nothing in the write-up that specifically identifies a customer or really gives away any case-specific data.
Andrew's paper is an excellent contribution to the community, and provides an excellent look at a thorough process for approaching and solving a problem using what you, as an examiner, have available to you. Something else to consider would be to look for remnants of the (for Windows XP) setupapi.log file, which would provide an indication of devices that had been connected (plugged in, attached, inserted into) to the system. I've done something similar with both the pagefile and unallocated space...knowing what I was looking for, I used Perl to locate indications of the specific artifacts, and then grab X number of bytes on either side of that artifact. As an example, you could use the following entry from a setupapi.log file:
#I121 Device install of
Now, search for all instances of the above string, and then grab 200 or more bytes on either side of that offset and write it to a file. This could provide some very useful information, as well.
Timelines
Corey has an excellent post up regarding the thought processes behind putting a timeline together. I'd posted recently on how to go about creating mini-timelines from a subset of data; in his post, Corey discusses the thought process that he goes through when creating timelines, in general...he also provides an example. If you look at the "Things to consider" section of his post, you'll notice some similarity to stuff I've written, as well as to Chris Pogue's Sniper Forensics presentations; in particular, the focus on the goals of the examination.
In his post, Corey mentions two approaches to timelines; the "kitchen sink" (including everything you can, and then performing analysis) and the "minimalist" approach. From my perspective, the minimalist approach is very similar to what Corey describes in his post; you can add data sources to a timeline via a "layering" approach, in that you can start with specific data sets (file system metadata, Event Logs, Prefetch file metadata, Registry metadata, Jump Lists, etc.), and then as you begin to develop a more solid picture, add successive layers, or even just specific items, to your timeline. The modular approach to the tools I use and have made available makes this approach (as well as creating mini-timelines) extremely easy. For example, during an examination involving a SQL injection attack, I put together a timeline using just file system metadata and pertinent web server log entries. For an incident involving user activity on a system, I would create a timeline using file system metadata, Registry key LastWrite times (as well as specific entries, such as UserAssist data), Event Log entries, Prefetch file metadata, and if the involved system were Windows 7, Jump List metadata (including parsing the DestList stream and sorting the entries in MFU/MRU order). In a malware detection case, I may not initially be interested in the contents of any user's web surfing activity, with the exception of the LocalService or "Default User" user accounts.
This is not to say that one way is better or more correct than another; rather, the approach used really depends upon the needs of the examination, skill set of the analyst, etc. I've simply found, through my own experience, that adding everything available to a timeline and then sorting things out doesn't provide me with the level of data reduction I'm looking for, whereas a more targeted approach allows me to keep focused on the goals of the examination.
Monday, April 09, 2007
From the Lab: Mapping USB devices via LNK files
My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?
Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.
Remember: the ParentIdPrefix value is NOT the device serial number!!
But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...
Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.
The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.
Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:
F:\,Removable,,1B360101,FAT,,961.875 MB
Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.
Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.
I verified the volume serial number using "chkdsk f:", and got:
Volume Serial Number is 1B36-0101
It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.
The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.
Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:
Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101
Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.
So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.
If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.
Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95
Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.
Remember: the ParentIdPrefix value is NOT the device serial number!!
But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...
Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.
The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.
Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:
F:\,Removable,,1B360101,FAT,,961.875 MB
Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.
Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.
I verified the volume serial number using "chkdsk f:", and got:
Volume Serial Number is 1B36-0101
It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.
The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.
Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:
Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101
Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.
So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.
If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.
Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95
Tuesday, September 26, 2006
Something old, something new...with USB
It really amazes me sometimes how a journalist "covering the security scene" will wake up one day and come to the relevation that something is "new". The thing is that most kids in junior high school today know enough about how to use Google to find out that these things really aren't all that "new". Ugh. Maybe now that we've redefined "is", we have to work our way through the dictionary and redefine "new", as well.
Case in point...this ComputerWorld article. Take a look at this excerpt from the first paragraph:
Now, the emergence of USB flash drives that can store and automatically run applications straight off the device could soon make the drives even more of a security headache.
Yeah, okay, this is essentially a true statement...and there's more to it. It's that extra bit of informaiton that needs to be understood to effectively address this threat.
The ComputerWorld article makes repeated references to Hak.5, a video podcast version of MAKE. It's not a podcast I've seen before, but it does look pretty interesting. Anyway, the article refers to something called "Switchblade", described in the episode Wiki as "a custom USB key that will retrieve vital information from a target computer, necessary for auditing password strength".
Okay, so what's really going on here? Well, the issue is the use of the U3-enabled thumb drives. In a nutshell, the U3 utilities create a small CDFS partition at the beginning of the thumb drive, with the intention of providing the user with mobility...anyone owning a U3-enabled thumb drive can take their desktop (well, a limited desktop) anywhere with them, and plug the thumb drive into any workstation and use their applications. Nice, convenient...and a security nightmare.
Like I said, the core issue is the CDFS partition and how Windows systems treat these partitions. Windows has an autorun feature that allows for the "load=" and "run=" lines from autorun.inf files located in the root of the partition to be parsed and executed, but only for certain types of media. Removable (ie, USB) drives don't allow this by default, but CDs and DVDs do. The default value for the NoDriveTypeAutoRun key is 0x95, which means that CD-Rom drives allow the functionality by default.
For more information, MS KB article Q155217 describes how to disable this functionality for CD-Rom drives. Additional information about the Cdrom\AutoRun key is here, and there's an explanation of the AutoRunAlwaysDisable key here. Also, from MS's USB FAQ:
Q: What must I do to trigger Autorun on my USB storage device?
The Autorun capabilities are restricted to CD-ROM drives and fixed disk drives. If you need to make a USB storage device perform Autorun, the device must not be marked as a removable media device and the device must contain an Autorun.inf file and a startup application.
The U3 utility essentially marks a portion of the device as a CDFS partition (...must not be marked as a removable media device...). Please note...regardless of what one thinks it should be, "removable media" != "CD-Rom")
For myself, I purchased a Geek Squad 1GB USB thumb drive when I saw them on sale at Best Buy a while ago. I was shocked when I plugged the device in...not only did I not get 1GB of removable storage, but I also got a bunch of applications...this isn't what I wanted! Digging around the Registry in the USBStor key, I found two entries:
CdRom&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
and
Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
Hhhmmm...two almost identical entries for the same device, both under the Enum\USBStor key. Beneath both entries, the serial number for the USB device was the same. So we've now got a way of detecting the use of such devices within the infrastructure. For information on tracking USB removable storage devices across Windows systems, check out my GMU2006 presentation slides.
You can go here to download a utility to remove that pesky U3 partition, or just go to U3's Launchpad Removal site.
Okay, so why isn't this 'new'? Back in June, DarkReading had an interesting article on the same subject, from a social engineering perspective. Also, there's a Hacking U3 site that discusses creating your own custom ISO to replace the utilities loaded (scroll down to "The Sting" section).
Finally (as if that weren't enough), there's a nasty little utility called USBDumper that is installed on a PC and silently dumps all files from any USB removable storage device that's plugged into the system. Wow! Copying files is one thing...how about automatically imaging the device and recovering deleted files?!
A brief word on Windows Event Logs: it seems that Windows 2000 will report when USB removable storage devices are plugged into and removed from a system. Event ID 134 would be generated (source = Removable Storage) as the arrival notice and Event ID 160 as the removal notice. However, this seems to have been removed as of XP SP2, according to this KB article:
After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices.
Additional Resources/Reading:
Schneier On Security
WikiPedia entry for AutoRun
SecuriTeam Blog entry by Gadi
USBSnoop (2002)
USBSnoop (2001)
USBSnoopy (2001)
USB Monitor
Case in point...this ComputerWorld article. Take a look at this excerpt from the first paragraph:
Now, the emergence of USB flash drives that can store and automatically run applications straight off the device could soon make the drives even more of a security headache.
Yeah, okay, this is essentially a true statement...and there's more to it. It's that extra bit of informaiton that needs to be understood to effectively address this threat.
The ComputerWorld article makes repeated references to Hak.5, a video podcast version of MAKE. It's not a podcast I've seen before, but it does look pretty interesting. Anyway, the article refers to something called "Switchblade", described in the episode Wiki as "a custom USB key that will retrieve vital information from a target computer, necessary for auditing password strength".
Okay, so what's really going on here? Well, the issue is the use of the U3-enabled thumb drives. In a nutshell, the U3 utilities create a small CDFS partition at the beginning of the thumb drive, with the intention of providing the user with mobility...anyone owning a U3-enabled thumb drive can take their desktop (well, a limited desktop) anywhere with them, and plug the thumb drive into any workstation and use their applications. Nice, convenient...and a security nightmare.
Like I said, the core issue is the CDFS partition and how Windows systems treat these partitions. Windows has an autorun feature that allows for the "load=" and "run=" lines from autorun.inf files located in the root of the partition to be parsed and executed, but only for certain types of media. Removable (ie, USB) drives don't allow this by default, but CDs and DVDs do. The default value for the NoDriveTypeAutoRun key is 0x95, which means that CD-Rom drives allow the functionality by default.
For more information, MS KB article Q155217 describes how to disable this functionality for CD-Rom drives. Additional information about the Cdrom\AutoRun key is here, and there's an explanation of the AutoRunAlwaysDisable key here. Also, from MS's USB FAQ:
Q: What must I do to trigger Autorun on my USB storage device?
The Autorun capabilities are restricted to CD-ROM drives and fixed disk drives. If you need to make a USB storage device perform Autorun, the device must not be marked as a removable media device and the device must contain an Autorun.inf file and a startup application.
The U3 utility essentially marks a portion of the device as a CDFS partition (...must not be marked as a removable media device...). Please note...regardless of what one thinks it should be, "removable media" != "CD-Rom")
For myself, I purchased a Geek Squad 1GB USB thumb drive when I saw them on sale at Best Buy a while ago. I was shocked when I plugged the device in...not only did I not get 1GB of removable storage, but I also got a bunch of applications...this isn't what I wanted! Digging around the Registry in the USBStor key, I found two entries:
CdRom&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
and
Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
Hhhmmm...two almost identical entries for the same device, both under the Enum\USBStor key. Beneath both entries, the serial number for the USB device was the same. So we've now got a way of detecting the use of such devices within the infrastructure. For information on tracking USB removable storage devices across Windows systems, check out my GMU2006 presentation slides.
You can go here to download a utility to remove that pesky U3 partition, or just go to U3's Launchpad Removal site.
Okay, so why isn't this 'new'? Back in June, DarkReading had an interesting article on the same subject, from a social engineering perspective. Also, there's a Hacking U3 site that discusses creating your own custom ISO to replace the utilities loaded (scroll down to "The Sting" section).
Finally (as if that weren't enough), there's a nasty little utility called USBDumper that is installed on a PC and silently dumps all files from any USB removable storage device that's plugged into the system. Wow! Copying files is one thing...how about automatically imaging the device and recovering deleted files?!
A brief word on Windows Event Logs: it seems that Windows 2000 will report when USB removable storage devices are plugged into and removed from a system. Event ID 134 would be generated (source = Removable Storage) as the arrival notice and Event ID 160 as the removal notice. However, this seems to have been removed as of XP SP2, according to this KB article:
After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices.
Additional Resources/Reading:
Schneier On Security
WikiPedia entry for AutoRun
SecuriTeam Blog entry by Gadi
USBSnoop (2002)
USBSnoop (2001)
USBSnoopy (2001)
USB Monitor
Sunday, August 14, 2011
Updates and Links
ECSAP
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique. My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.
One take-away for me from the conference speaking is that people like to get free stuff. In this case, I had one DiskLabs Find Evidence keyboard key left, and as I tend to do with conferences where I speak, I also gave away copies of my books...I gave away one copy of DFwOST and one of WRF (both of which were signed). I hope that the continuing promises of free stuff kept folks coming back into the room from breaks...
Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback. Did what they say make sense? Was the presentation material something that you feel you can use? A simple "yes" doesn't really constitute feedback. Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus. But again..."cool" isn't really "feedback".
I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement. If what I talked about simply isn't useful, please...let me know. If it's too easy or too hard to understand...let me know. I think that most folks who present would welcome some honest feedback on what they covered.
Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis. Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis. I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received. From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").
Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end. We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer. Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.
Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently. I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot). One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.
One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts. Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.
Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19. The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.
Tools
Need to find Facebook artifacts? Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available. You never know when you're going to need something like this...
Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced. Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...". I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.
Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.
The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that. There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam. You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.
A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares
Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.
DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST. Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique. My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.
Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback. Did what they say make sense? Was the presentation material something that you feel you can use? A simple "yes" doesn't really constitute feedback. Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus. But again..."cool" isn't really "feedback".
I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement. If what I talked about simply isn't useful, please...let me know. If it's too easy or too hard to understand...let me know. I think that most folks who present would welcome some honest feedback on what they covered.
Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis. Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis. I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received. From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").
Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end. We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer. Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.
Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently. I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot). One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.
One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts. Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.
Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19. The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.
Tools
Need to find Facebook artifacts? Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available. You never know when you're going to need something like this...
Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced. Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...". I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.
Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.
The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that. There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam. You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.
A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares
Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.
DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST. Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.
Thursday, July 21, 2011
Evading Investigators and Analysts
I recently had an opportunity to spend two days with some great folks in the Pacific Northwest, talking about timeline creation and analysis. During this time, we talked about a couple of ancillary topics, such as critical thinking, questioning assumptions, looking at what might be unusual on a system, and we even touched briefly on anti-forensics. If you've read my blog for any considerable length of time, you know that my thoughts on anti-forensics are that most tactics are meant to target the analyst, or the analyst's training.
Along the lines of anti-forensics, a good deal of reading can be found online. For example, in 2005, the Grugq gave a presentation at BlackHat that addresses anti-forensics. James Foster and Vincent Lui gave a presentation on a similar subject. Also, I recently ran across a very interesting article regarding evading the forensic investigator. One of the most important statements in the article is:
"Here it is important to note that the software makes it possible to store..."
Why is this statement important? Well, if you consider the statement critically for a moment, you'll see that it points out that this technique for hiding data from an analyst requires additional software to be added to the system. That's right...this isn't something that can be done using just tools native to the system...something must be added to the system for this technique to be used. What this means is that while the analyst may not necessarily be able to immediately determine that data may have been hidden using these techniques, they would likely be able to determine the existence of this additional software. After all, what would be the purpose of hiding data with no way for the person hiding it to access it? If you wanted to deny the owner access to the data, why not simply wipe it to a level at which it is prohibitively expensive to retrieve?
What are some ways that an analyst might go about finding the additional software? Well, because many times I deal solely with acquired images, I use a malware detection checklist for those times where my analysis calls for it, and one of the things I check is the MUICache keys for the users, which can provide me with an indication of software that may have been executed, but perhaps not via the shell. This is just one item on the checklist, however...there are others, and because the checklist is a living document (I can add to it, and note when some things work better than others), there may be additional items added in the future.
Another way to address this is through incident preparation. For example, if the audit capability for the Windows system includes Process Tracking (and the Event Logs are of sufficient size), then you may find an indication of the software being executing there (using evtrpt.pl against Windows XP and 2003 .evt files works like a champ!). Another possible proactive approach is to use something like Carbon Black from Kyrus Technology; installing something like this before an incident occurs will provide you with (as well as your responders) with considerable, definitive data. To see how effective a proactive approach involving Carbon Black can be, take a look at this video.
Beyond this, however, its critical that analysts have the training and knowledge to do their jobs in a quick, efficient, and accurate manner, even in the face of dedicated attempts to obfuscate or hinder that analysis. One of the things we talked a great deal about in the class is the use of multiple data sources to add context to the data, as well as increase the relative level of confidence in that data. Chris Pogue talks about this a bit in one of his recent blog posts. Rather than looking at a single data point and wondering (or as is done in many cases, speculating) "...what could have caused this?", it's better to surround that data point with additional data from other sources in order to not only see the context in which the event took place, but we also have to keep in mind that some data is more mutable (easily changed) than others.
When I teach a class like this, I learn a lot, not just in putting the course materials together, but also from engaging with the attendees. At one point, I was asked on about how many cases do I create a timeline...my response was, "all of them", and that's fairly accurate. Now, timeline analysis may not be my primary analysis technique...sometimes, I may have something available (an Event Log record, a file name, etc.) to get me started and the goals of my analysis simply dictate that a timeline be created. Looking back over my recent examinations, I've created a timeline in just about every instance...either to have a starting point for my analysis, or to provide context or validation to my findings, or even to look for secondary or tertiary artifacts to support my findings. However, the important thing to keep in mind here is that I'm not letting the technique or tool drive my analysis...quite the opposite, in fact. I'm using the technique for a specific purpose and because it makes sense.
Another thing I have learned through engaging with other analysts over the years is that a lot of this stuff that some of us talk about (timeline or Registry analysis) is great, but in some cases, someone will go to training and then not use what they learned for 6 - 9 (or even more) months. By then, what they learned has become a fog. These techniques are clearly perishable skill sets that need to be exercised and developed, or they will just fade away.
An example of this that I've seen a great deal of recently in online forums has to do with tracking USB devices on Windows systems. In the spring of 2005, Cory Altheide and I published some research that we'd conducted regarding USB device artifacts on Windows systems. Since then, more has been written about this subject, and Rob Lee has posted (and provided worksheets) to the SANS Forensics blog, not only covering thumb drives, but also drive enclosures. USB artifacts have been discussed in books such as Windows Forensic Analysis (1/e, 2/e), and Windows Registry Forensics, and I'm including yet another discussion in the upcoming third edition of WFA. I think that this is important, because with all of the information available (including this page on the Forensics Wiki), there continues to be a misunderstanding of the artifacts and analysis process regarding these devices. For example, variations on the same question have appeared in multiple forums recently, specifically asking why all (in one case, 20 or more) device keys listed beneath the USBStor subkey have the same LastWrite time, and how could the user have plugged all of the devices into the system at the same time. The problem with this line of analysis is that the LastWrite times for the subkeys beneath the USBStor key are NOT used to determine when the devices were last connected to the system! What I normally suggest is that analysts engage with the various resources available, and if they want to know what could be responsible for the keys all having the same LastWrite times, generate a timeline. Seriously. Timelines aren't just for analysis anymore...they're a great testing tool, as well.
As a side note, RegRipper has all of the necessary plugins to make USB device analysis pretty straightforward and simple. I've been working on a chapter on Registry Analysis for my upcoming Windows Forensic Analysis 3/e, and I haven't had to produce any new plugins. So, even if you're using Rob's SANS checklists, you can get the data itself using RegRipper.
Resources
IronGeek: Malicious USB Devices
Matthieu recently released DumpIt, which is a fusion of the 32- and 64-bit Windows memory dumping utilities that will create a memory dump in the current working directory (which makes this a great utility to run from a thumb or wallet drive).
Along the lines of anti-forensics, a good deal of reading can be found online. For example, in 2005, the Grugq gave a presentation at BlackHat that addresses anti-forensics. James Foster and Vincent Lui gave a presentation on a similar subject. Also, I recently ran across a very interesting article regarding evading the forensic investigator. One of the most important statements in the article is:
"Here it is important to note that the software makes it possible to store..."
Why is this statement important? Well, if you consider the statement critically for a moment, you'll see that it points out that this technique for hiding data from an analyst requires additional software to be added to the system. That's right...this isn't something that can be done using just tools native to the system...something must be added to the system for this technique to be used. What this means is that while the analyst may not necessarily be able to immediately determine that data may have been hidden using these techniques, they would likely be able to determine the existence of this additional software. After all, what would be the purpose of hiding data with no way for the person hiding it to access it? If you wanted to deny the owner access to the data, why not simply wipe it to a level at which it is prohibitively expensive to retrieve?
What are some ways that an analyst might go about finding the additional software? Well, because many times I deal solely with acquired images, I use a malware detection checklist for those times where my analysis calls for it, and one of the things I check is the MUICache keys for the users, which can provide me with an indication of software that may have been executed, but perhaps not via the shell. This is just one item on the checklist, however...there are others, and because the checklist is a living document (I can add to it, and note when some things work better than others), there may be additional items added in the future.
Another way to address this is through incident preparation. For example, if the audit capability for the Windows system includes Process Tracking (and the Event Logs are of sufficient size), then you may find an indication of the software being executing there (using evtrpt.pl against Windows XP and 2003 .evt files works like a champ!). Another possible proactive approach is to use something like Carbon Black from Kyrus Technology; installing something like this before an incident occurs will provide you with (as well as your responders) with considerable, definitive data. To see how effective a proactive approach involving Carbon Black can be, take a look at this video.
When I teach a class like this, I learn a lot, not just in putting the course materials together, but also from engaging with the attendees. At one point, I was asked on about how many cases do I create a timeline...my response was, "all of them", and that's fairly accurate. Now, timeline analysis may not be my primary analysis technique...sometimes, I may have something available (an Event Log record, a file name, etc.) to get me started and the goals of my analysis simply dictate that a timeline be created. Looking back over my recent examinations, I've created a timeline in just about every instance...either to have a starting point for my analysis, or to provide context or validation to my findings, or even to look for secondary or tertiary artifacts to support my findings. However, the important thing to keep in mind here is that I'm not letting the technique or tool drive my analysis...quite the opposite, in fact. I'm using the technique for a specific purpose and because it makes sense.
Another analyst told me not long ago, "...I've been doing timelines for years." I'm sure that this is the case, as the concepts behind timeline analysis have been around for some time and used in other areas of analysis, as well. However, I'm willing to bet that most of the analysts that have created timelines have done so by manually entering events that they discover into a spreadsheet, and that the events that they've added are based on limited knowledge of the available data sources. Also, it has been clear for some time that the value of timelines as an analysis tool isn't completely recognized or understood, in part by looking at questions asked in online forums; many of these questions could be answered by creating a timeline. So, while many are talking about timeline analysis, I think that its imperative that more of us do it. |
Another thing I have learned through engaging with other analysts over the years is that a lot of this stuff that some of us talk about (timeline or Registry analysis) is great, but in some cases, someone will go to training and then not use what they learned for 6 - 9 (or even more) months. By then, what they learned has become a fog. These techniques are clearly perishable skill sets that need to be exercised and developed, or they will just fade away.
An example of this that I've seen a great deal of recently in online forums has to do with tracking USB devices on Windows systems. In the spring of 2005, Cory Altheide and I published some research that we'd conducted regarding USB device artifacts on Windows systems. Since then, more has been written about this subject, and Rob Lee has posted (and provided worksheets) to the SANS Forensics blog, not only covering thumb drives, but also drive enclosures. USB artifacts have been discussed in books such as Windows Forensic Analysis (1/e, 2/e), and Windows Registry Forensics, and I'm including yet another discussion in the upcoming third edition of WFA. I think that this is important, because with all of the information available (including this page on the Forensics Wiki), there continues to be a misunderstanding of the artifacts and analysis process regarding these devices. For example, variations on the same question have appeared in multiple forums recently, specifically asking why all (in one case, 20 or more) device keys listed beneath the USBStor subkey have the same LastWrite time, and how could the user have plugged all of the devices into the system at the same time. The problem with this line of analysis is that the LastWrite times for the subkeys beneath the USBStor key are NOT used to determine when the devices were last connected to the system! What I normally suggest is that analysts engage with the various resources available, and if they want to know what could be responsible for the keys all having the same LastWrite times, generate a timeline. Seriously. Timelines aren't just for analysis anymore...they're a great testing tool, as well.
As a side note, RegRipper has all of the necessary plugins to make USB device analysis pretty straightforward and simple. I've been working on a chapter on Registry Analysis for my upcoming Windows Forensic Analysis 3/e, and I haven't had to produce any new plugins. So, even if you're using Rob's SANS checklists, you can get the data itself using RegRipper.
Resources
IronGeek: Malicious USB Devices
Matthieu recently released DumpIt, which is a fusion of the 32- and 64-bit Windows memory dumping utilities that will create a memory dump in the current working directory (which makes this a great utility to run from a thumb or wallet drive).
Thursday, May 26, 2022
USB Device Redux, with Timelines
If you ask DFIR analysts, "What is best in life?", the answer you should hear is, "...creating timelines!" After all, industry luminaries such as Andrew said, "Time is the most important thing in life, and timelines are one of the most useful tools for investigation and analysis.", and Chris said, "The timeline is the central concept of all investigative work."
My previous blog post addressed USB-connected devices, but only from the perspective of Windows Event Logs. In this blog post, I wanted to include data from the Registry, incorporated in a timeline so that the various data sources could be viewed through a common lens, in a single pane of glass.
I stated by using wevtutil.exe to export current copies of the five Windows Event Logs to a central location. I then used reg.exe to do the same thing for the System hive. I then used my timeline process (outlined in several of my books) to create the events file from the six data sources; I used wevtx.bat to parse the Windows Event Logs, and three newly created RegRipper Pro plugins to parse the relevant data from the System hive. The specific keys, values and data parsed from the hive were based largely on Yogesh's blog post, and this academic paper posted at the ResearchGate site. I created the initial plugins, and then modified them to display TLN-format output, for inclusion in timelines.
For this research, there where three specific devices I was interested in...my iPod, my iPhone, and a SanDisk Cruzer USB thumb drive. After creating the overall events file, I used the "type" and "find" commands to look for events associated specifically with those devices, isolated each into their own individual "overlay" events file, and then created timelines from each of those events files. This approach makes it easy to "see" what's going on and create artifact constellations, as I don't have to filter out "noise" associated with other events, and I still have the overall events file that I refer to.
What I'm sharing below are partial timelines of events, just enough to demonstrate events based on intentionally limited data sources, so that initial artifact constellations can be developed. From this point, the constellations can be built out; for example, accessing files the SanDisk Cruzer will produce Windows shortcut files pointing to files on the "E:\" volume. Again, these timeline overlays are not complete, but are intended to demonstrate Registry artifacts associated with USB-connected devices alongside Windows Event Log artifacts.
iPod
A while back, I inserted my iPod into my computer in order to retrieve music files, via iTunes, so that I could transfer them to my iPhone. I didn't think much about it at the time, but the connection was clearly "remembered" by Windows 10, specifically via the Registry.
Here are the events around the insertion:
Sun Jan 2 19:41:21 2022 Z
REG - First Inserted - Apple iPod [6&3091e96e&0&0000]
REG - First Install - Apple iPod [6&3091e96e&0&0000]
EVTX Stewie - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPod,4.3.5,40
REG - Last Inserted - Apple iPod [6&3091e96e&0&0000]
Sun Jan 2 19:41:15 2022 Z
EVTX Stewie - Microsoft-Windows-DeviceSetupManager/112;iPod,{fc916355-34ea-555c-9e24-3c59f6125097},2,42,11
And here are the events around the removal of the device from the computer, a little more than 14 minutes later:
Sun Jan 2 19:55:46 2022 Z
REG - Last Removal - Apple iPod [6&3091e96e&0&0000]
The completed message string for the "Microsoft-Windows-DeviceSetupManager/112" event above is:
Device 'Apple iPod' ({fc916355-34ea-555c-9e24-3c59f6125097}) has been serviced, processed 6 tasks, wrote 34 properties, active worktime was 11748 milliseconds.
I state this specifically because following the "Last Removal" event on 2 Jan 2022, the timeline contains an additional 9 events from 6 Jan to 22 May, all for the same "Microsoft-Windows-DeviceSetupManager/112" event records for the iPod, but the last three string entries are different. In every case, only 1 task is run, and the active worktime runs from 0 to 31 milliseconds. I know that the iPod was not plugged in during these times, and as such, this seems to be an artifact the installation process.
iPhone
I have connected my iPhone to this Windows 10 system via a USB cable, to transfer pictures from it, and to transfer music files to it, via iTunes. Here was see one such connection on 7 May 2022:
Sat May 7 14:16:35 2022 Z
REG - Last Removal - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]
REG - Last Removal - Apple iPhone [6&139bb8e1&1&0000]
Sat May 7 14:14:57 2022 Z
EVTX Stewie - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40
EVTX Stewie - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,296
Sat May 7 14:14:56 2022 Z
REG - Last Inserted - Apple iPhone [6&139bb8e1&1&0000]
REG - Last Inserted - @oem119.inf,iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device [00008030000E6C6C11DA802E]
There's information later in the timeline regarding another connection to the system, this time to copy pictures off of the iPhone. The "Last Inserted" and "Last Removal" events are from a different Registry key as seen above, as noted by the serial number in brackets at the end of the "event".
Fri Apr 15 16:23:13 2022 Z
REG - Last Removal - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]
...
Fri Apr 15 16:19:02 2022 Z
EVTX Stewie - Microsoft-Windows-WPD-MTPClassDriver/1005;Apple Inc.,Apple iPhone,15.4.1,40
Fri Apr 15 16:18:57 2022 Z
EVTX Stewie - Microsoft-Windows-DeviceSetupManager/112;Apple iPhone,{7e8068a1-2d62-53fb-8285-a12072dfa871},4,34,140
REG - Last Inserted - @oem119.inf,iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device [6&139bb8e1&1&0001]
Cruzer
The artifact constellation for the SanDisk Cruzer thumb drive is a bit different from that of the iPhone and the iPod. In this case, the events around the last time the device was inserted and then removed from the computer is less than a minute...
Mon May 16 22:07:08 2022 Z
EVTX Stewie - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...
REG - Last Removal - SanDisk Cruzer USB Device
REG - Last Removal - Cruzer [E:\]
Mon May 16 22:06:26 2022 Z
EVTX Stewie - Microsoft-Windows-Ntfs/145;3,{1e09345e-d3d4-11e8-92fd-1c4d704c6039},2,E:,false,0,{fab772f6-83e6-5d5f-1086-740d39e45bff},8,SanDisk ,16,Cruzer ...
EVTX Stewie - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,512,8036285952,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,Integrated : ...
Mon May 16 22:06:24 2022 Z
EVTX Stewie - Microsoft-Windows-Partition/1006;1,8208,262401,false,0,0,0,0,0,7,SanDisk,Cruzer,8.02,2443931D6C0226E3,...
EVTX Stewie - Microsoft-Windows-DeviceSetupManager/112;Cruzer,{81fa6fcf-bfc9-5887-bdbc-2cffb6be0b29},4,34,281
REG - Last Inserted - Cruzer [E:\]
REG - Last Inserted - SanDisk Cruzer USB Device
Note that several of the events, particularly those from the Partition/Diagnostic Event Log, are shortened here for readability.
Registry
Each of the above three devices appears in the Registry, specifically in the System hive, sometimes in multiple locations. For example, the SanDisk Cruzer thumb drive appears in both the USBStor and WPDBUSENUM subkeys.
From the USBStor key:
From the USBStor key:
Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02
2443931D6C0226E3&0
DeviceDesc : @disk.inf,%disk_devdesc%;Disk drive
Mfg : @disk.inf,%genmanufacturer%;(Standard disk drives)
Service : disk
FriendlyName : SanDisk Cruzer USB Device
First Install : 2021-09-09 17:37:15Z
First Inserted : 2021-09-09 17:37:15Z
Last Inserted : 2022-05-16 22:06:24Z
Last Removal : 2022-05-16 22:07:08Z
From the WPDBUSENUM key:
_??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer&Rev_8.02#2443931D6C0226E3&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
DeviceDesc : Cruzer
FriendlyName : E:\
First Install : 2021-09-09 17:37:17Z
First Inserted : 2021-09-09 17:37:17Z
Last Inserted : 2022-05-16 22:06:24Z
Last Removal : 2022-05-16 22:07:08Z
The Apple devices appear beneath the USB key, based on the vendor ID:
VID_05AC&PID_129E
b9e69c2c948d76fd3f959be89193f30a500a0d50
DeviceDesc : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device
Mfg : @oem119.inf,%aapl%;Apple, Inc.
Service : usbccgp
FriendlyName : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device
First Install : 2022-01-02 19:41:16Z
First Inserted : 2022-01-02 19:41:15Z
Last Inserted : 2022-01-02 19:41:15Z
Last Removal : 2022-01-02 19:55:46Z
VID_05AC&PID_129E&MI_00
6&3091e96e&0&0000
DeviceDesc : Apple iPod
Mfg : Apple Inc.
Service : WUDFWpdMtp
FriendlyName : Apple iPod
First Install : 2022-01-02 19:41:21Z
First Inserted : 2022-01-02 19:41:21Z
Last Inserted : 2022-01-02 19:41:21Z
Last Removal : 2022-01-02 19:55:46Z
VID_05AC&PID_129E&MI_01
6&3091e96e&0&0001
DeviceDesc : @oem119.inf,%iphone.appleusbmux.devicedesc%;Apple Mobile Device USB Device
Mfg : @oem119.inf,%aapl%;Apple, Inc.
Service : WINUSB
FriendlyName : @oem119.inf,%iPhone.AppleUsbMux.DeviceDesc%;Apple Mobile Device USB Device
First Install : 2022-01-02 19:41:16Z
First Inserted : 2022-01-02 19:41:16Z
Last Inserted : 2022-01-02 19:41:16Z
Last Removal : 2022-01-02 19:55:46Z
VID_05AC&PID_12A8
00008030000E6C6C11DA802E
DeviceDesc : @oem119.inf,%iphone.appleusb.devicedesc%;Apple Mobile Device USB Composite Device
Mfg : @oem119.inf,%aapl%;Apple, Inc.
Service : usbccgp
FriendlyName : @oem119.inf,%iPhone.AppleUSB.DeviceDesc%;Apple Mobile Device USB Composite Device
First Install : 2022-01-02 19:56:40Z
First Inserted : 2022-01-02 19:56:40Z
Last Inserted : 2022-05-07 14:14:56Z
Last Removal : 2022-05-07 14:16:35Z
VID_05AC&PID_12A8&MI_00
6&139bb8e1&1&0000
DeviceDesc : Apple iPhone
Mfg : Apple Inc.
Service : WUDFWpdMtp
FriendlyName : Apple iPhone
First Install : 2022-01-02 19:56:46Z
First Inserted : 2022-01-02 19:56:46Z
Last Inserted : 2022-05-07 14:14:56Z
Last Removal : 2022-05-07 14:16:35Z
Additional Resources
Note that per Yogesh's blog post, the "Microsoft-Windows-Kernel-PnP/Device Configuration" Event Log may also contain information about the connected devices.
One More Thing
While I was doing some research for this blog post, I ran across this entry for event ID 112, albeit from the Microsoft-Window-TaskScheduler/Operational" Event Log. Once again, please stop referring to event records solely by their ID, and start including the event source, as well.
Saturday, December 15, 2012
There are FOUR lights!
Okay, you're probably wondering what Picard and one particular episode of Star Trek TNG has to do with forensicating. Well, to put it quite simply...everything!I recently posted the question in a forum regarding Shellbag analysis, and asked who was actually performing it as part of their exams. One answer I got was, "...I need to start." When I asked this same question at the PFIC 2012 conference of a roomful of forensicators, two raised their hands...and one admitted that they hadn't done so since SANS training.
I've seen during exams where the shellbags contain artifacts of user activity that are not found anywhere else on the system. For example, I've seen the use Windows Explorer to perform FTP transfers (my publisher used to have me do this to transfer files), where artifacts of that activity were not found anywhere else on the system. When this information was added to a timeline, a significant portion of the exam sort of snapped into place, and became crystal clear.
Something I've seen with respect to USB devices that were connected to Windows systems is that our traditional methodologies for parsing this information out of a system are perhaps...incomplete. I have seen systems where some devices are not so much identified as USB storage devices by Windows systems (rather, they're identified as portable devices...iPods, digital cameras, etc.), and as such, starting by examining the USBStor subkeys means that we may miss some of these devices that could be used in intellectual property theft, as well as the creation and trafficking of illicit images. Yet, I have seen clear indications of a user's access to these devices within the shellbags artifacts, in part because of my familiarity with the actual data structures themselves.
The creation and use of these artifacts by the Windows operating system goes well beyond just the shellbags, as these artifacts are comprised of data structures known as "shell items", which can themselves be chained together into "shell item ID lists". Rather than providing a path that consists of several ASCII strings that identify resources such as files and directories, a shell item ID list builds a path to a resource using these data structures, which some in the community have worked very hard to decipher. What this work has demonstrated is that there is a great deal more information available than most analysts are aware.
So why is understanding shell items and shell item ID lists important? Most of the available tools for parsing shellbags, for example, simply show the analyst the path to the resource, but never identify the data structure in question...they simply provide the ASCII representation to the analyst. These structures are used in the ComDlg32 subkey values in the NTUSER.DAT hive on Windows Vista and above systems, as well as in the IE Start Menu and Favorites artifacts within the Registry. An interesting quote from the post:
Of importance to the forensic investigator is the fact that, in many cases, these subkeys and their respective Order values retain references to Start Menu and Favorites items after the related applications or favorites have been uninstalled or deleted.
I added the emphasis to the second half of the quote, because it's important. Much like other artifacts that are available, references to files, folders, network resources and even applications are retained long after they've been uninstalled or deleted. So understanding shell items are foundational to understanding larger artifacts.
But doesn't stop with the Registry...shell item ID lists are part of Windows shortcut (LNK) files, which means that they're also part of the Jump Lists found on Windows 7 and 8.
Okay, but so what, right? Well, the SpiderLabs folks posted a very interesting use of LNK files to gather credentials during a pen test; have any forensic analysts out there seen the use of this technique before? Perhaps more importantly, have you looked for it? Would you know how to look for this during an exam?
Here's a really good post that goes into some detail regarding how LNK files can be manipulated with malicious intent, demonstrating how important it is to parse the shell item ID lists.
So, the point of the graphic, as well as of the post overall, is this...if you're NOT parsing shellbags as part of your exam, and if you're NOT parsing through shortcut files as part of your root cause analysis (RCA), then you're only seeing three lights.
There are, in fact, four lights.
Resources
DOSDate Time Stamps in Shell Items
ShellBag Analysis, Revisited...Some Testing
Monday, October 21, 2019
Registry Analysis
Something I've observed over the years is that analysis of the Windows Registry is still a largely misunderstood, misinterpreted, and under-appreciated aspect of analysis of Windows systems.
What is "Registry analysis"? Registry analysis is the observation and interpretation of data or metadata from the Windows Registry, in the context of other data/metadata, also from the Registry or other sources. The correct interpretation of this data can add an unprecedented level of granularity to the context surrounding various events observed during, for example, timeline analysis.
"Registry analysis" is not the parsing and display of individual artifacts from within the Registry; that's "parsing and display". It's also not keyword searching of the Registry; that's "keyword searching". Keyword searches or searches for indicators do not constitute "analysis". I do understand, however, that not all cases require Registry analysis. There are more than a few types of cases out there where keyword searching is all that is necessary, and I get it. Through engaging with other analysts and following up on conversations, I've seen where keyword searches have more than sufficed for a number of types of cases. But that's not the "analysis" we're talking about here.
That is not to say that keyword or indicator searches cannot be used as pivot points into more fully-fledged analysis. Very often, these searches can be an excellent entry point into analysis, allowing the investigator to winnow through vast amounts of data to determine what is initially important.
Analysis techniques where I have been able to incorporate data and metadata from the Windows Registry into an overall analysis process, have allowed me to get a better understanding of inherent activity derived or extracted from a system. This has occurred to the point, in some cases, of changing the direction of my investigation. Further, I'll be the first to admit that I haven't seen everything there is to see; in fact, within just the past weeks, I've observed activity that I had never seen before, and was able to develop an understanding of what activity led to the observed artifacts. This is not something for which keyword searching would have sufficed, and was only achieved by bringing together multiple data sources in a manner that allowed me to discern context.
Why is this important? Well, for one, Windows keeps changing. Yes, yes, I know, we've heard this before...Windows Vista was a big leap forward (with respect to DFIR artifacts) over XP/2003, and Windows 7 a similar "leap". There were some pretty interesting changes in the short-lived Windows 8/8.1 world, but we've arguably seen a (dare I say, "significant"?) spike in changes just between versions of Windows 10 since that version has been out. The point is that you can't often go for a week or two before something new with respect to the Windows operating system (and specifically the Registry) is discovered or observed. An analysis process accounts for these changes occurring. For example, one of the approaches I use to winnow down data is to create mini-timelines and overlays; in short, using very specific data sources to create a mini-timeline in order to get a view of the data without all the inherent "noise" of the operating system. I'll create a timeline from a user's Registry hives, incorporating not just time-based data extracted from the hives (i.e., shellbags, UserAssist data, etc.), but also the overall metadata from those hives. This way, I can 'see' a user's activities over time, without having to wade through massive amounts of "noise", such as Windows Updates. And, I'll not only be able to develop context, but I'll also see new things, as well.
Speaking of which, let's take a look at the great work Jason Hale has done, as an example. Some of the things we've (I use the universal "we") seen over the years have been Registry key LastWrite times associated with USB devices being universally 'stomped' by updates, as well as Registry hive "backups" no longer being written (by default) to the RegBack folder.
Jason recently pointed out that key LastWrite times associated with MRUs within the shellbags artifacts have been 'stomped' by an update, similar to what was observed with USBStor keys. What impact would this have had on your analysis had this happened 6 months, or 2 years ago? How would this have impacted your findings in a case?
Why is understanding the use and function of the Registry important when it comes to analyzing Windows systems?
Two important aspects of the Windows Registry that I've discussed during many of my speaking engagements have been:
The Windows Registry contains a great deal of configuration information about the system that, if correctly understood and correctly interpreted, can have a significant impact on your analysis.
The Registry contains a lot of configuration settings for the operating system, many set by default, right "out of the box". There are others that can be changed along the way that have an impact on what users of the systems can see and do, as well as what attackers can do. For example, there's a setting that tells the Windows operating system to store credentials in memory, in plain text. Attackers can set this value to "1", wait a week, and come back and dump the credentials from memory, and not have to spend time cracking the passwords. There are settings that tell the Windows shell to not show all user accounts on the Welcome screen, as well as settings that control the functionality of Terminal Services, etc. There are even settings within the Registry that control what users can and cannot access, and how their account functions (i.e., deleted files bypass the Recycle Bin, etc.). Understanding these settings, as well as knowing how to determine when (or if) they changed, can have a significant impact on an investigation.
There are also a number of "autostart" locations within the Registry, keys or values that tell the operating system to start applications with no other interaction from the user beyond booting the system, or logging in. Consider this Threat Research blog post regarding newly-discovered malware, for example. Not only does it include what is reportedly a new persistence mechanism, but it also includes a figure illustrating how code used by the malware is encoded and placed in the Registry for later use. Knowing this, encountering an infected system and incorporating this into our analysis will allow us to discover new information about how the malware operated or was used.
As a side-note, does anyone have an NTUSER.DAT file from a user profile infected with the malware identified in the Juniper Threat Research blog post? I'm curious if the binaryImage32_* values are detected by the RegRipper sizes.pl plugin. Thanks in advance to anyone who can check, or share such a hive file.
The Windows Registry records and maintains a great deal of user activity that, if correctly understood and interpreted, can illustrate "humanness"; that is, provide strong indications of specific, purposeful human activity, as opposed to the automatic effects of the operating system, or of malware.
There are a number of user actions...opening or saving files, launching applications, etc...that are recorded within the Windows Registry, as part of tracking user activity in order to improve the "user experience". The idea is to make Windows more "user friendly", in part by making the more frequently used functionality more easily accessible to the user. The key here is that actions specifically taken by the user can be interpreted as "humanness", as the data recorded is the direct result of a person interacting with the Windows shell, applications, etc. This can provide information to inform an investigation, particularly when knowing when someone was sitting at the keyboard is important, or when discerning whether a user or some automated function accessed data is a critical aspect of an investigation.
Thankz/Shout-Outz
Thankz and shout-outz are due to a number of folks within the #DFIR community who've contributed to the topic through research, creating tools, etc. In no specific order:
Mari DeGrazia
Maxim Suhanov
Jason Hale
Eric Zimmerman
farmerK
I apologize profusely for any names I may have missed, as it was not intentional.
What is "Registry analysis"? Registry analysis is the observation and interpretation of data or metadata from the Windows Registry, in the context of other data/metadata, also from the Registry or other sources. The correct interpretation of this data can add an unprecedented level of granularity to the context surrounding various events observed during, for example, timeline analysis.
"Registry analysis" is not the parsing and display of individual artifacts from within the Registry; that's "parsing and display". It's also not keyword searching of the Registry; that's "keyword searching". Keyword searches or searches for indicators do not constitute "analysis". I do understand, however, that not all cases require Registry analysis. There are more than a few types of cases out there where keyword searching is all that is necessary, and I get it. Through engaging with other analysts and following up on conversations, I've seen where keyword searches have more than sufficed for a number of types of cases. But that's not the "analysis" we're talking about here.
That is not to say that keyword or indicator searches cannot be used as pivot points into more fully-fledged analysis. Very often, these searches can be an excellent entry point into analysis, allowing the investigator to winnow through vast amounts of data to determine what is initially important.
Analysis techniques where I have been able to incorporate data and metadata from the Windows Registry into an overall analysis process, have allowed me to get a better understanding of inherent activity derived or extracted from a system. This has occurred to the point, in some cases, of changing the direction of my investigation. Further, I'll be the first to admit that I haven't seen everything there is to see; in fact, within just the past weeks, I've observed activity that I had never seen before, and was able to develop an understanding of what activity led to the observed artifacts. This is not something for which keyword searching would have sufficed, and was only achieved by bringing together multiple data sources in a manner that allowed me to discern context.
Why is this important? Well, for one, Windows keeps changing. Yes, yes, I know, we've heard this before...Windows Vista was a big leap forward (with respect to DFIR artifacts) over XP/2003, and Windows 7 a similar "leap". There were some pretty interesting changes in the short-lived Windows 8/8.1 world, but we've arguably seen a (dare I say, "significant"?) spike in changes just between versions of Windows 10 since that version has been out. The point is that you can't often go for a week or two before something new with respect to the Windows operating system (and specifically the Registry) is discovered or observed. An analysis process accounts for these changes occurring. For example, one of the approaches I use to winnow down data is to create mini-timelines and overlays; in short, using very specific data sources to create a mini-timeline in order to get a view of the data without all the inherent "noise" of the operating system. I'll create a timeline from a user's Registry hives, incorporating not just time-based data extracted from the hives (i.e., shellbags, UserAssist data, etc.), but also the overall metadata from those hives. This way, I can 'see' a user's activities over time, without having to wade through massive amounts of "noise", such as Windows Updates. And, I'll not only be able to develop context, but I'll also see new things, as well.
Speaking of which, let's take a look at the great work Jason Hale has done, as an example. Some of the things we've (I use the universal "we") seen over the years have been Registry key LastWrite times associated with USB devices being universally 'stomped' by updates, as well as Registry hive "backups" no longer being written (by default) to the RegBack folder.
Jason recently pointed out that key LastWrite times associated with MRUs within the shellbags artifacts have been 'stomped' by an update, similar to what was observed with USBStor keys. What impact would this have had on your analysis had this happened 6 months, or 2 years ago? How would this have impacted your findings in a case?
Why is understanding the use and function of the Registry important when it comes to analyzing Windows systems?
Two important aspects of the Windows Registry that I've discussed during many of my speaking engagements have been:
The Windows Registry contains a great deal of configuration information about the system that, if correctly understood and correctly interpreted, can have a significant impact on your analysis.
The Registry contains a lot of configuration settings for the operating system, many set by default, right "out of the box". There are others that can be changed along the way that have an impact on what users of the systems can see and do, as well as what attackers can do. For example, there's a setting that tells the Windows operating system to store credentials in memory, in plain text. Attackers can set this value to "1", wait a week, and come back and dump the credentials from memory, and not have to spend time cracking the passwords. There are settings that tell the Windows shell to not show all user accounts on the Welcome screen, as well as settings that control the functionality of Terminal Services, etc. There are even settings within the Registry that control what users can and cannot access, and how their account functions (i.e., deleted files bypass the Recycle Bin, etc.). Understanding these settings, as well as knowing how to determine when (or if) they changed, can have a significant impact on an investigation.
There are also a number of "autostart" locations within the Registry, keys or values that tell the operating system to start applications with no other interaction from the user beyond booting the system, or logging in. Consider this Threat Research blog post regarding newly-discovered malware, for example. Not only does it include what is reportedly a new persistence mechanism, but it also includes a figure illustrating how code used by the malware is encoded and placed in the Registry for later use. Knowing this, encountering an infected system and incorporating this into our analysis will allow us to discover new information about how the malware operated or was used.
As a side-note, does anyone have an NTUSER.DAT file from a user profile infected with the malware identified in the Juniper Threat Research blog post? I'm curious if the binaryImage32_* values are detected by the RegRipper sizes.pl plugin. Thanks in advance to anyone who can check, or share such a hive file.
The Windows Registry records and maintains a great deal of user activity that, if correctly understood and interpreted, can illustrate "humanness"; that is, provide strong indications of specific, purposeful human activity, as opposed to the automatic effects of the operating system, or of malware.
There are a number of user actions...opening or saving files, launching applications, etc...that are recorded within the Windows Registry, as part of tracking user activity in order to improve the "user experience". The idea is to make Windows more "user friendly", in part by making the more frequently used functionality more easily accessible to the user. The key here is that actions specifically taken by the user can be interpreted as "humanness", as the data recorded is the direct result of a person interacting with the Windows shell, applications, etc. This can provide information to inform an investigation, particularly when knowing when someone was sitting at the keyboard is important, or when discerning whether a user or some automated function accessed data is a critical aspect of an investigation.
Thankz/Shout-Outz
Thankz and shout-outz are due to a number of folks within the #DFIR community who've contributed to the topic through research, creating tools, etc. In no specific order:
Mari DeGrazia
Maxim Suhanov
Jason Hale
Eric Zimmerman
farmerK
I apologize profusely for any names I may have missed, as it was not intentional.
Monday, February 02, 2026
Devices
As such, it's not only important to keep up with what's available from the default installation of an endpoint, and what sources can be used to validate your findings, but also note what's available depending upon the applications installed.
However, what's most important are your analysis goals. For example, it's easy to say, "I want to see all USB devices connected to the endpoint", and not provide a timeframe. However, to what are these devices pursuant? IP theft? Violation of acceptable use policies? What about CSAM production? After all, smartphones and digital cameras can be connected to a computer via a USB cable, but use different protocols, and information about the devices being connected can be found in other locations than those that we traditionally look to as a result of training we may receive.
When it comes to devices connected to a Windows system, things have definitely changed over time. Cory and I published a peer-reviewed paper in 2005, covering USB artifacts on Windows XP systems. Since then, there's been quite a few changes to Windows, and as one would expect, how devices connected to an endpoint are tracked. Nicole mentioned some time ago (2014) that different protocols used by different devices (in this case, smartphones) have an impact on investigations; unfortunately, as time has gone on, I've had a hard time linking back to Nicole's published research or even her presentations, but one of her presentations can be found here.
This WindowsIR blog post describes the fact that some of the Windows Event Log files we might look to in order to investigate USB devices connected to an endpoint have been seen to be disabled, and recommended some alternative data sources. Similarly, this NirSoft page for the USBDeView application similarly recommends data sources.
Speaking of the WindowsIR blog, here's a whole series of blog posts about just "USB devices".
Now, as to why I'm writing this blog post, in the first place...
I recently ran across this LinkedIn post from Garrett Moreau, which I thought was interesting. He's right, in that information about devices connected to/removed from the endpoint is stored in the Registry, and not just in the USBStor key. RegRipper, for example, includes multiple plugins within the "devices" category. What's really eye-opening is to read through the comments to the post; one comment, for example, states the following:
Quick note for defenders, default logging settings don’t provide much depth.
USB events are recorded under the Applications and Services Logs > Microsoft > Windows > DriverFrameworks-UserMode > Operational path, but this log must be activated manually.
Previous versions of Windows required activation of these events using PowerShell.
While the statement is true, this goes back to what I said earlier about traditional training, and the need to not only keep playbooks up to date, but to also pursue other alternative data sources. A data source we're familiar with, the Microsoft-Windows-DriverFrameworks-UserMode Event Log, is now disabled by default, and as stated, doesn't provide "much depth". However, if understanding the USB devices connected to an endpoint are part of your investigative goals, then keeping playbooks updated is key.
Some of the comments go one to suggest other data sources that might be used to add granularity or context to your investigations, such as shellbags (for directory transversal), etc. In the past, I've found the Application Event Log, and in particular, MsiInstaller events to be useful in illustrating attempts to install applications from a USB device.
My recommendation is this...first and foremost, understand your analysis goals; what are you attempting to show, to prove or disprove? From there, maintain playbooks associated with these goals, and if you're in a role where you're dealing with different implementations and applications, keep documentation on any new findings that apply to specific edge cases, as you never know when you will see such things again. An excellent example of this is when Don Weber worked a case where the LANDesk Software Monitoring application was installed on an endpoint, and found that the application provided valuable information regarding program execution.
Addendum, 2 Mar: Just yesterday, I became aware of this USB Devices article from ElComSoft, which addresses different types of USB-connected devices, and resources for investigating them.
Subscribe to:
Posts (Atom)