USBPcap is an open-source USB sniffer for Windows.

USB Packet capture for Windows Tour

System Requirements

• This utility works on any version of Windows, starting from Windows 2000 and up to Windows 7. Both 32-bit and 64-bit systems are supported. Be aware that at this moment USBLogView doesn't work on Windows 8. 

• Operating system identification
• Installed application identification
• Vendor-specific driver enumeration
• Endpoint Protection System assessment

Based on commentary I've seen in a couple of online forums, I thought I'd resurrect the "HowTo" label from some previous blog posts, and share (for commentary, feedback and improvement) some of the analysis processes that I've used while examining images of Windows systems.  There is a good deal of information available regarding various Windows artifacts, and one of perhaps the most difficult aspects of analysis is to tie various disparate bits of information together, correlating the artifacts, and building a complete picture so that your analysis can be used to answer questions and provide solutions.

This particular topic was previously discussed in this blog (and here's another, much older post), but sometimes processes like this need to be revisited.  Before we start, however, it's important to point out that this process will work only on Windows Vista systems and above, due to the information that is required for the process to work properly.

LNK Files
A Windows shortcut/LNK file can contain volume serial number, or VSNs.  This is intended to be a unique 4-byte (DWORD) value that identifies the volume, and is changed when the volume is reformatted.  Many tools that parse LNK files will display the VSN in their output, if one exists.

Note: Prefetch files include a volume information block which also contains a VSN.  If this information is different from the local system...that is, if a user launched an application from an external storage device...you can also use this process to correlate the VSN to the particular device.  You can view the VSN for a volume on a live system by navigating to the volume via the command prompt and typing the 'vol' command.

Registry
The EMDMgmt key (within the Software hive) contains information about USB external devices connected to the system.  This information is generated and used by the ReadyBoost service, at least in part to determine the suitability of the device for use as external RAM.

The path to the key in question is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key will contain subkeys that pertain to and describe external storage media.  The subkeys that we're interested in are those that begin with "_??_USBSTOR#".  These subkey names are very similar to artifacts found in the System hive, particularly in the USBStor subkeys.  These subkey names include device serial number, as well a volume name (if one exists) and a VSN in decimal format.

An example of such a subkey name, with the VSN in bold, appears as follows:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}TEST_1677970716

For those subkeys that pertain to USB thumb drives, the emdmgmt.pl RegRipper plugin will parse the subkey name, and display the VSN formatted in a usable, understandable manner.  That is to say that the plugin will translate the decimal value for the VSN into a hexidecimal format, and display it in the same manner as the VSN seen in LNK and Prefetch files, as well as what is displayed by the vol command on live systems.
Again, it is important to note the EMDMgmt key exists on Vista systems and above, but not on XP systems. As such, this technique will not work for XP/2003 systems.

Now that we have these two pieces of information, we can correlate LNK files (or Prefetch files, if necessary) to a particular device, based on the VSNs.  I've used this technique a number of times, most recently in an attempt to determine a user's access to a particular device (remember, LNK files are most often associated with a user, as they are often located within the user's profile).  If you know what it is that you're attempting to determine or demonstrate...that is, the goals of your analysis...then the tools and artifacts tend to fall right into place.  When I've had to perform this type of correlation of artifacts, because of the tools I have available, this analysis is complete in just a few minutes.

As a final note, do not forget the value of historical information on the system, particularly for the Registry.  The RegBack folder should contain a backed-up copy of the Software hive, and there is additional information available in VSCs.  Corey Harrell has a number of excellent posts on his blog that demonstrate how to use simple tools and processes...batch files...to exploit the information available in VSCs.

Resources
MS-SHLLINK file format specification
Description of EMDMgmt RegRipper plugin

There's been a good deal of discussion and documentation regarding discovering USB devices that had been connected to a Windows system, as this seems to be very important to a number of examiners.  In 2005, Cory Altheide and I published some initial information, and over the years since then, that information has been expanded, simply because it continues to grow.  For example, Rob Lee has published valuable checklists via the SANS Forensics Blog, and Jacky Fox recently published her dissertation, which includes some interesting and valuable information regarding interpreting some of the information that is available regarding user access to USB devices via the Registry.  Ms. Fox determined that when a USB device is connected to a system and mounted as a volume, that volume GUID is added to the MountPoints2 key for all logged in users, not just the user logged in at the console.

Further, Mark Woan recently updated information collected by his USBDeviceForensics tool, to include querying some additional keys/values.

Regarding the additional keys/values that Mark's tool is querying, Windows 7 and 8 systems have additional values beneath the device keys in the System hive, specifically a "Property" key with a number of GUID subkeys.  This blog post provides some very good information that facilitates further searches, which leads use to information regarding a time stamp value that pertains to the InstallDate, as well as one that pertains to the FirstInstallDate.

So what?  Well, let's take a look at the MS definition for the FirstInstallDate:

Windows sets the value of DEVPKEY_Device_FirstInstallDate with the time stamp that specifies when the device instance was first installed in the system.

Pretty cool, eh?  This is what MS says about the InstallDate time stamp:

This time stamp value changes for each successive update of the device driver. For example, this time stamp reports the date and time when the device driver was last updated through Windows Update.

Ah, interesting. So it would appear that, based on the MS definitions for these values, we now have the information about when the device was first connected to the system available right there in the Registry.  I'm not saying that we don't have to go anywhere else...rather, I'm suggesting that we have corroborating data that we can use to provide an increased relative confidence (a phrase that you usually see in my posts regarding timelines) in the data that we're analyzing.

Something that hasn't been addressed is that most of the publicly-available processes that are currently being used are not as complete as they could be.  Wait...what?  Well, this is where specificity of language within the DFIR community comes into play...it turns out that the processes are actually really very good, as long as all we're interested in is specifically USB thumb drives or external drives.  However, there are devices that can be connected to Windows systems via USB and accessed as storage devices (digital cameras, iStuff, smartphone handsets), that do not necessarily become apparent to analysts using the commonly-accepted tools, processes and checklists.  We can find these devices by looking beneath other Registry keys, as well as in other locations beyond the Registry, and by correlating information between them.  This is particularly useful when counter-forensics techniques have been used (however unintentional...), as not everything may be completely gone, and we may be able to find some remnant (LNK file, shellbags, deleted Registry keys/values, Windows Event Log, etc.) that will point us to the use of such devices.

One of the pitfalls of interpretation of Registry data, as Ms. Fox pointed out in her dissertation, is that we often don't have current, up-to-date databases of all devices that could be connected to a Windows system, so we might see vendor ID (VID) and product ID (PID) values within key names beneath the Enum\USB key, but not know what they translate to...I've found Motorola devices, for instance, that required a good deal of searching in order to determine which smartphone handset was pointed to by the PID value.  As such, no process is going to be 100%, push-a-button complete, but the point is that we will know that the data is there, we know to get it, and we know how to use it.

Full analysis of USB-accessible storage media can be extremely important to a number of exams, such as illicit image and IP theft cases.  Many examiners used to think that sneaking a thumb drive into an infrastructure was a threat...and it still is; these devices get smaller and smaller every day, while their capacity increases.  But we need to start thinking about other USB-accessible storage, such as smartphones and iDevices, not because they're easily hidden, but because they're so ubiquitous that we tend to not focus on them...we take them for granted.

A Mapping Technique
The EMDMgmt subkey (within the Software Registry hive) names include the serial number for the mounted volume (VSN), which is also included in the MS-SHLLLINK structure, which itself is found in Windows shortcut/LNK files, as well as Windows 7 and 8 Jump Lists.  By correlating the VSNs from multiple sources, I was able to illustrate access to external storage devices in a manner that overcomes the shortcoming identified by Ms. Fox.  What I've done is used code to parse through the LNK structures (LNK files in the Recent folder, for example, and the LNK streams within the Jump Lists) to list the VSNs, looking for the one (or two, or however many...) that point to the device identified in the EMDMgmt subkey name.

Now and again, I get some interesting questions from folks, usually posing a previously-addressed question with a slightly different twist on it.  I received one of these types of questions recently and wanted to post a HowTo for others to review, and provide something to which they can add comments.

The question involved a thumb drive, and mapping the use of the thumb drive to a Windows shortcut/LNK file.  The items that we have are the device serial number (pulled from the device descriptor of the thumb drive...remember, this is NOT located in the memory area) and the volume serial number (VSN) from the formatted volume on the device.  These definitions should help you understand what we're referring to.

By now, most of us are familiar with how to go about doing USB device analysis on Windows systems.  This has been covered extensively by Rob Lee of SANS (see the Resources section below), as well as in Windows Registry Forensics and Windows Forensic Analysis 3/e. 

The key to answering the question of mapping volume serial numbers (VSNs) to specific devices on Vista and Windows 7 can be found in the EMDMgmt key.  This key is associated with ReadyBoost, and lists some details of the device that was connected to the system, including the unique device descriptor, the volume name, and the VSN.  Remember that the VSN can be changed simply by reformatting the device; however, this key should provide valuable information for mapping devices and VSNs (pulled from LNK files).

The EMDMgmt key and it's usefulness is discussed in detail in chapter 5 of Windows Forensic Analysis 3/e.

Often times, the Windows Portable Devices key (mentioned on pg 115 of Windows Registry Forensics; the data can be extracted from the Software hive using the port_dev.pl RegRipper plugin) will contain some very useful information, such as historical drive mappings.  Beneath this key is the Devices key, and beneath that key are subkeys that refer to devices that have been connected to the system.  The "FriendlyName" value will often contain the drive letter to which the device was mounted; in one instance, I have a device that was connected and has the volume name ("TEST") in that particular value data, rather than the drive letter.  The subkey name will usually contain the unique device identifier (very often, the device serial number) within the name...simply parse the key name apart, using "#" as your separator, and you'll see it at or near the end.

Addendum
I came up with a graphic to illustrate the relationship between various Registry hives and keys (and some values) with respect to this analysis:


Resources
Blog Post: Windows Portable Devices (Vista)
SANS Forensic Guide for profiling thumb drives on Windows systems
WindowsIR: Mapping USB devices via LNK (2007)

CyberSpeak, 8 Nov
Be sure to check out the CyberSpeak 8 Nov podcast, with an interview of Kristinn, creator of Log2Timeline. There's some Lubie, some iPhone stuff, and lots of Ovie! Good stuff, Ovie, thanks for putting these podcasts together and entertaining us all.

Windows 7 & USB Devices
A member of the Win4n6 group recently posted that there seems to be yet another place that Windows 7 tracks USB removable storage devices. The key path is:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key appears to have to do with ReadyBoost, and applies to Vista, as well as Windows 7, systems. The key names for each of the devices listed contains information similar to what's in the DeviceClasses key, including the serial number (bold in the below example) for the device, as illustrated below:

\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}GEEKSQUAD_1414378827

The values beneath each key include things such as the physical size of the device, as well the date that it was last tested (presumably by ReadyBoost for use as a RAM cache). I have a Windows 7 system for testing, as well as set of hive files from a Vista system, and I see entries for devices that include thumb drives and even an iPod, but not for a digital camera that had been connected to the system.

This might be a very good resource, as I've seen where some folks have asked for the physical size information of a USB device. It would be interesting to see if external HDD enclosures appear in this key, as well, and under what conditions the key LastWrite time is updated.

Resources
CodeProject

F-Response
There's a new post over on the NewInForensics blog that talks about using F-Response, in this case when analyzing Windows Event Logs (.evtx) files. I have to say that I'm glad to see others using this tool, and running tests like this, as it tells me two things. One is that folks are deciding to pick up tools and run their own tests.

The other is that folks in the community and industry are beginning to really realize and acknowledge how useful and truly powerful a tool F-Response really is, and they're using it as such.

When it comes to Windows Event Logs (.evtx) from Vista and above systems, I like to use LogParser from MS to parse the logs into some text-based format, and then use Perl to put the entries in a TLN format for inclusion into a timeline, or for generating mini-timelines. Sometimes I get questions that are best answered by creating mini-timelines (sort of the opposite of super timelines) from just RDP login events, W32Time events, etc.

OpenSource Tools
Brian mentioned recently that there's a new site available called OpenSourceForensics. From Brian:

One of the take aways from the Sleuth Kit and Open Source Digital Forensics Conference last year was that the community needed a site where examiners could go to find tools and learn about which ones were better than others.

This is a great resource, as one of the issues I hear from folks is that tools are out there, but they're OUT there...there's no single resource or location where an examiner can go to search for or find a tool, or get input from other analysts on the usefulness of the tool. Hopefully, with input from examiners and analysts, this can become an exemplary resource...but remember, folks, it takes effort from everyone!

Add to that a big thanks and shout-out to Brian for this, as well as for the Open Source Conference last June...Brian also mentioned that there will be another one next June!

Note
I presented at the PFIC2010 conference recently, and while I was there, someone came up and told me that they had all of my books. I was going to say something witty, and ask which one they liked best or opened the most, only to have them start off by saying, "...File System Forensic Analysis..."...uh...that's Brian, not me. Brian has hair, and is much smarter than I.

SecTor.ca
Speaking of conferences, SecTor videos are available. I watched Greg Hoglund's keynote presentation, and correlated to what I heard there about the APT and focused attacks to what I saw in Dave Nardoni's presentation at PFIC2010.

During the keynote, Greg pimped Windows Forensic Analysis 2/e during his presentation...very cool, Greg, thanks!

Greg went on to say that the perimeter is disappearing through the use of mobile devices, and that host systems are becoming more important than ever. Early in his keynote, he talked about threat intelligence achieved through host-based analysis, and how many folks have a simple, flash-and-go response policy...wipe the drive of a potentially infected system, re-install, and move on. I think that one of the scariest things...well, should be one of the scariest things...is that Greg pointed out that there's an economy behind gaining access to host systems. That's right...people are paying money to gain access to your systems!

Finally, during his presentation, Greg mentioned a couple of times how MD5 hashes are just short of useless for analysis of well-thought-out intrusions. I know someone who'd be upset about that, if they bothered to watch videos like this.

I posted to the Win4n6 Yahoo Group on USB removable storage devices and tracking connections, and got some really good confirmation from Rob Lee, so I thought I'd share it here, as well.

So, when I was writing WFA 2/e, I did some testing and found that when connecting a USB removable storage device to a system, beneath the unique instance ID key (under the DeviceClasses key), a Control subkey was created, and when the device was disconnected, the Control subkey was deleted. The creation/deletion of this subkey constitutes a modification to the unique instance ID key, updating the key's LastWrite time and allowing us to track the usage of the device.

However, there appear to have been changes to this functionality since then, and Rob's more expansive testing has confirmed my own. Essentially, if you sit down to a running system (XP SP2 or 3, Vista, Windows 7), and plug in a USB removable storage device (even one that's been previously connected to that system), you'll see the Control subkey created...but when you disconnect the device, the Control subkey will remain until the system is rebooted. Rob has confirmed that this LastWrite time survives logins, as well.

So, now the LastWrite time on the unique instance key refers to the time that the device was last connected to the system, which is an important distinction to make when performing analysis of the usage of these devices. This requires further testing for more complete confirmation, but this is how things appear at this time. Shout outs to Rob Lee for the testing on this!

Every now and then I get emails from folks who've found my blog or one of my books useful, whether it has to do with work, school, or a hobby. For the most part, these emails are positive...I haven't really received any negative comments, per se...but I also try to see if there's a way to have these comments made publicly available in some manner. Recently, one of the folks who emailed me consented to allowing me to post the body of their email to my blog...so, here it is...

I'll try to make this short. I have your first book and on more than one occasion, I've referenced it for information. A fellow examiner asked me about it one time and even read through it to some extent. He later commented that it was a pretty good book but the author wasn't even a certified examiner. I let it go because everyone has their opinion. About a week or so ago, he was preparing to testify in a case and the subject of external drives and USB flash drives came up. I showed him your chapters concerning the registry and USB storage. Long story way too long, his newly gained knowledge of the registry and USB helped out enormously during the trial to the point that the other side didn't even have their expert take the stand. He is now a converted HC follower and has plans to purchase your upcoming WFA 2/e as I will be doing the same. Anyhow, I thought you would find this pretty amusing....I did.

Pretty amusing, definitely. Cory Altheide and I conducted the first publicly available research into USB removable storage device artifacts on Windows systems many, many moons ago, and since then, I'd have to say that it's probably the most popular and most asked-about set of artifacts...and maybe even one of the most misunderstood.

I've been party to or heard a good number of discussions lately regarding USB removable storage devices, and one of the topics that invariably comes up is, how can you determine which files were copied from the system to a thumb drive, or vice versa.

In most instances, folks are working only with the image of a system, and do not have access to the thumb drive itself. They can easily find the information that tells them when a thumb drive was first connected, and when it was last connected...and then the next question is, what files were or may have been copied to the thumb drive (or from the thumb drive to the system)?

The fact is that Windows systems do not maintain a record of file copies or moves...there is simply no way for a forensic analyst to look at the image of a system and say which files were copied off of the system onto a thumb drive. In order to determine this, you'd need to have the thumb drive (or other media) itself, and be able to see that you had two files of the same or similar size (you can also compare the files with md5deep or ssdeep), one of which is on each piece of media. From there, you could then check the file MAC times and possibly make some conclusions regarding the direction of transfer.

Many times in a conversation on this topic, someone will bring up Windows shortcuts or LNK files. To be honest, I'm not really sure why this comes up, it just seems to be the case. Shortcuts can be created manually, of course, but with regards to files, they are created when a user double-clicks a file, such as a Word document, to open it. Repeated testing on my part (including testing done by others) has yet to turn a method by which normal (as in "normal user activity") dragging-and-dropping a file or using the "copy" command will result in a Windows shortcut file being created.

Does anyone out there have any thoughts or input on tracking this kind of activity, having nothing more than a single system image to analyze? If so, I'd appreciate hearing from you.

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

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