Command Line Kung Fu: Episode #77: USB History

Ed Embarks:

Believe it or not, one of the things that we strive for in this blog is to be, not to put too fine a point on it, actually useful. We keep our musings here away from the theoretical and focused on the practical, in the hopes of helping people do their jobs better with a little bit of command-line fun. Almost* nothing gives Hal that special warm glow like e-mail from readers telling us that a recent article saved them tons of work, or allowed them to accomplish something they thought impossible. And, once Tim taught his mom to spoof e-mail addresses, the amount of such e-mail we receive has gone up a full 33% since we brought Tim on board.

Regular readers know that most of the techniques we cover here are focused on system administration and security work (such as audit, penetration testing, or, occasionally, forensics). For this episode, I'd like to address a technique that I find quite useful in my forensics work. As is our way, I'll talk about it in good ol' cmd.exe. But, I'm especially interested in seeing what magickal incantations Tim can add with PowerShell, and then I really want to see how Hal can tease this kind of information from Linux.

Sometimes, when working on a forensics case, we need to determine whether a given USB device was plugged into a given computer. Perhaps we are wondering if a user brought in an unauthorized USB token and attached it, infecting their system with malware which then spread. Or, maybe we want to get an idea if an intruder with physical access to a machine plugged in a USB hard drive so he or she could have copied large numbers of files. Sometimes, for a huge number of reasons, we need historical information about USB activities on the box for some extra proof of a perpetrators actions.

Windows stores information in the registry about every USB device plugged into the box. We can view this information with the following command:

c:\> reg query hklm\system\currentcontrolset\enum\usbstor /s

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0
  DeviceDesc    REG_SZ    @disk.inf,%disk_devdesc%;Disk drive
  Capabilities    REG_DWORD    0x10
  HardwareID    REG_MULTI_SZ    USBSTOR\DiskSanDisk_Enterprise______6.52\0USBS
TOR\DiskSanDisk_Enterprise______\0USBSTOR\DiskSanDisk_\0USBSTOR\SanDisk_Enterprise______6\0SanDisk_Enterprise______6\0USBSTOR\GenDisk\0GenDisk
  CompatibleIDs    REG_MULTI_SZ    USBSTOR\Disk\0USBSTOR\RAW
  ClassGUID    REG_SZ    {4d36e967-e325-11ce-bfc1-08002be10318}
  Driver    REG_SZ    {4d36e967-e325-11ce-bfc1-08002be10318}\0001
  Class    REG_SZ    DiskDrive
  Mfg    REG_SZ    @disk.inf,%genmanufacturer%;(Standard disk drives)
  Service    REG_SZ    disk
  ConfigFlags    REG_DWORD    0x0
  FriendlyName    REG_SZ    SanDisk Enterprise USB Device

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters\MediaChangeNotification

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters\Partmgr
  Attributes    REG_DWORD    0x0

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\LogConf

HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Properties
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Control

The /s indicates that I want the reg command to recurse the Registry, showing all settings under this area. In my output, I first see an indication of the vendor and product information, which is prefaced with "Disk&Ven". I can just pull that information by piping the output through the find command in a case-insensitive (/i) fashion:

c:\> reg query hklm\system\currentcontrolset\enum\usbstor /s | find /i "Disk&Ven"

Here, you'll see stuff like SanDisk (for a lot of thumb drive memory tokens), Lexar, WD, SAMSUNG, and much more. You'll also typically see a "Prod" indication on this same line, showing the product name or number the vendor associates with the device. A quick Google search on the vendor and product data will often show you more details about the product.

After that, we get a registry entry with a unique id number associated with the device (0B919380B2629895&0 in the example above). This value is derived from a serial number from the device. With this number, I can track the usage of a single USB device across multiple machines.

Also, keep in mind that the reg key can be used remotely, so I can pull this data from target systems where I have admin credentials and SMB access, by simply prefixing the hklm above with \\MachineName\. Oh, and one more nifty bonus: The reg key is case insensitive, so I don't have to memorize the annoying CamelCase nonsense of registry keys when using reg. No, unfortunately, the cmd.exe reg command doesn't have tab autocomplete with registry paths, something that I'm sure Tim is going to extol in his PowerShell write-up.

*Don't ask. You really don't wanna know.

Tim finds his way in:

So we are digging to the registry huh? Well, that's easy. Especially with tab completion! (Insert angel AAAAAAAAHHHHH sound here) Tab completion in the registry is such a hand feature, expecially when you can't remember if the CurrentVersion key has a space in the middle (it doesn't).

PS C:\> gci -r HKLM:\SYSTEM\curr<Press tab>

PS C:\> gci -r HKLM:\SYSTEM\CurrentControSet

See how easy that was? That saved a dozen key strokes, keystrokes that can be shipped to the keystroke challenged and help them with their crops and...uh...let's get back to what we are supposed to be working on.

So we are using Get-ChildItem, the same command we use to browse the file system. However, when we use Get-ChildItem with the registry it doesn't display the values. Why? Well, you don't see the contents of files with you do a directory listing do you? Ok, that is a bit weak, but it does make sense if you think about it just right.

Another thing that might take you by surprise is that you can "change directory" into the registry. Technically "cd" is an alias for Set-Location, but it still works the same as the "cd" you know and love from the other shells.

PS C:\> cd HKLM:
PS HKLM:\> cd software
PS HKLM:\SOFTWARE> ls

    Hive: HKEY_LOCAL_MACHINE\SOFTWARE

SKC  VC Name                           Property
---  -- ----                           --------
  1   0 ActiveTouch                    {}
  4   0 Adobe                          {}
  1   0 AGNS                           {}
  2   0 Alps                           {}
...

Now that you have seen some of the mind-bending features of PowerShell let try to recreate what Ed did.

PS C:\> gci -r HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR | select name
Name
----
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters\MediaChangeNotification
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Device Parameters\Partmgr
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\LogConf
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Properties
HKEY_LOCAL_MACHINE\system\currentcontrolset\enum\usbstor\Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52\0B919380B2629895&0\Control
...

We use -r, which is short for Recurse, in order to show all the keys below our current location. Now let's find all of the devices that have been plugged in.

PS C:\> gci -recurse HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR |
  ? { $_.PSPath -match ".*Disk&Ven[^\\]*$" }  | select PSChildName
Disk&Ven_SanDisk&Prod_Enterprise&Rev_6.52
Disk&Ven_&Prod_USB_Flash_Memory&Rev_PMAP
Disk&Ven_Generic&Prod_&Rev_6000
Disk&Ven_IronKey&Prod_Secure_Drive&Rev_1.00
...

First, we get the results of Get-ChildItem. Next, we filter the results based on a regular expression. The regular expression looks for Disk&Ven followed by any characters that are NOT a backslash. Finally, we select the name of the node using the PSChildName property. The PSChildName is the name of the node in question. The property name leaves a little to be desired, but it works.

We got the Vender &: Product info, and we can use a similar command to get all the unique ids.

PS C:\> gci -recurse HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR |
  ? { $_.PSParentPath -match ".*Disk&Ven[^\\]*$" }  | select PSChildName
0B919380B2629895
...

The difference between the commands is subtle. In the second command we use our regular expression on the parent item, not the current item. This takes us one step deeper and gets us the unique id.

PowerShell allows us to use the .NET framework, which gives us access to a lot of cool tools. While I wasn't able to finish it for this episode, we can use the Windows API in order to get the last write time of the registry keys. It isn't pretty, but it works. Much like some friends of mine.

Hal is happy to come along

I was really happy when Ed proposed this idea because the Linux side was something I'd been meaning to research for quite some time now. But now Ed just let me in on where all of those fan emails are coming from and I'm all depressed. Ah well, nothing to do but get really geeky in order to take my mind of things.

So your first question might be, how exactly does one research something like this? I went for the "brute force and massive ignorance" approach, using a technique similar to the find trick I discussed back in Episode #29. I simply used touch to update the timestamp on an empty file, plugged in the USB device, and then did a "find ... -newer ..." to locate any files that had changed as a result of the device being inserted. So the command line looked like:

# touch /root/timestamp
[... plug in USB device ...]
# find / -newer /root/timestamp

The results were actually quite interesting and fairly consistent across the two Linux distros I tested against: CentOS 5.4 (a Red Hat derivative running kernel v2.6.18) and Ubuntu 9.10 aka "Karmic Koala" (a Debian derivative running kernel v2.6.31). Here's what I found:

When the device is plugged in, it inherits the next available "sd" device name. So on my laptop, for example, the internal drive is "sda", so the first USB device gets "sdb", the second "sdc", and so on. Also a number of symlinks are created under /dev pointing to the sd device for the USB drive that was just inserted. Here's some of the pathnames to show you what I'm taking about:

/dev/disk/by-uuid
/dev/disk/by-uuid/80a5317f-8e4c-4c83-88ea-b5192b442f97
/dev/disk/by-path
/dev/disk/by-path/pci-0000:02:02.0-usb-0:1:1.0-scsi-0:0:0:0-part1
/dev/disk/by-path/pci-0000:02:02.0-usb-0:1:1.0-scsi-0:0:0:0
/dev/disk/by-id
/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_8990000000000000000000B0-part1
/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_8990000000000000000000B0
/dev/.udev/links
/dev/.udev/links/disk\x2fby-uuid\x2f80a5317f-8e4c-4c83-88ea-b5192b442f97
/dev/.udev/links/disk\x2fby-uuid\x2f80a5317f-8e4c-4c83-88ea-b5192b442f97/b8:17
/dev/.udev/links/disk\x2fby-path\x2fpci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0-part1
/dev/.udev/links/disk\x2fby-path\x2fpci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0-part1/b8:17
/dev/.udev/links/disk\x2fby-id\x2fusb-Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0-part1
/dev/.udev/links/disk\x2fby-id\x2fusb-Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0-part1/b8:17
/dev/.udev/links/disk\x2fby-path\x2fpci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0
/dev/.udev/links/disk\x2fby-path\x2fpci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0/b8:16
/dev/.udev/links/disk\x2fby-id\x2fusb-Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0
/dev/.udev/links/disk\x2fby-id\x2fusb-Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0/b8:16

You can see the manufacturer name for the device ("Kingston DataTraveler 2.0"), the serial number of the device ("8990000000000000000000B0"), and the UUID associated with the file system on the device ("80a5317f-8e4c-4c83-88ea-b5192b442f97") in the path names above. And if you look closely, you'll see that there's a single partition on the device (in addition to the links that point to the device as a whole). If you wanted to, you could also run the mount command (see Episode #59) to get more information about this file system.

The only problem with all of this information is that it's completely ephemeral. As soon as the drive is removed, all of this information goes away. So from an "after the fact" sort of forensic perspective, it's not really all that useful.

In addition to the device files and links under /dev, the OS also creates some information files under /dev/.udev/db. CentOS calls these files names like "/dev/.udev/db/block@sdb" and "/dev/.udev/db/block@sdb@sdb1", while the newer kernel on my Ubuntu box uses names like "/dev/.udev/db/block:sdb" and "/dev/.udev/db/block:sdb1", but the basic information in the files is pretty much the same. Here's the data in the "/dev/.udev/db/block:sdb1" file from my Ubuntu system:
```
N:sdb1
S:block/8:17
S:disk/by-id/usb-Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0-part1
S:disk/by-path/pci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0-part1
S:disk/by-uuid/80a5317f-8e4c-4c83-88ea-b5192b442f97
W:51
E:ID_VENDOR=Kingston
E:ID_VENDOR_ENC=Kingston
E:ID_VENDOR_ID=0951
E:ID_MODEL=DataTraveler_2.0
E:ID_MODEL_ENC=DataTraveler\x202.0
E:ID_MODEL_ID=1603
E:ID_REVISION=1.00
E:ID_SERIAL=Kingston_DataTraveler_2.0_8990000000000000000000B0-0:0
E:ID_SERIAL_SHORT=8990000000000000000000B0
E:ID_TYPE=disk
E:ID_INSTANCE=0:0
E:ID_BUS=usb
E:ID_USB_INTERFACES=:080650:
E:ID_USB_INTERFACE_NUM=00
E:ID_USB_DRIVER=usb-storage
E:ID_PATH=pci-0000:02:03.0-usb-0:1:1.0-scsi-0:0:0:0
E:ID_FS_UUID=80a5317f-8e4c-4c83-88ea-b5192b442f97
E:ID_FS_UUID_ENC=80a5317f-8e4c-4c83-88ea-b5192b442f97
E:ID_FS_SEC_TYPE=ext2
E:ID_FS_VERSION=1.0
E:ID_FS_TYPE=ext3
E:ID_FS_USAGE=filesystem
E:DKD_PARTITION=1
E:DKD_PARTITION_SCHEME=mbr
E:DKD_PARTITION_NUMBER=1
E:DKD_PARTITION_TYPE=0x83
E:DKD_PARTITION_SIZE=4018885632
E:DKD_PRESENTATION_NOPOLICY=0
```
There isn't a whole lot here we couldn't have pulled out of the link names shown above, but this format is definitely a lot more readable. Unfortunately, this file is also ephemeral and gets cleaned up as soon as the drive is disconnected from the system.

At this point you're probably asking yourself if there's any forensic technique we could use to recover the deleted. The bad news is that both the links and the db files created by the device insertion are created in a memory-based file system:
```
$ df /dev/.udev
Filesystem           1K-blocks      Used Available Use% Mounted on
udev                   1992768       276   1992492   1% /dev
$ df /dev/disk
Filesystem           1K-blocks      Used Available Use% Mounted on
udev                   1992768       276   1992492   1% /dev
```
Assuming the system hasn't been rebooted since the device was inserted, I suppose it's possible that you might find some strings still floating around in the memory image of the system (or possibly in the disk-based swap area). But frankly, I don't hold out much hope for you. At least the db file has a nice regular structure to assist in searching.

There are, however, some more permanent records of the device having been connected to the system. Any of you who've been using Linux for a while know that when you hook up a removable device to the system, the Nautilus agent in the standard Gnome desktop will position an icon on the desktop that represents the device. You may have noticed that if you disconnect and later reconnect the same device, the icon will always re-appear in the same spot on the desktop. Nautilus keeps track of this in a file in your home directory.

On CentOS, the file is called "~/.nautilus/metafiles/x-nautilus-desktop\:%2F%2F%2F.xml" and looks like this:
```
<?xml version="1.0"?>
<directory><file name="trash" timestamp="1200596020" icon_position="64,182"/>
<file name="home" timestamp="1200596020" icon_position="64,102"/>
<file name="computer" timestamp="1200596020" icon_position="64,22"/>
<file name="CD-ROM%20Drive.volume" timestamp="1206558600" icon_position="64,282"/>
<file name="CD-RW%2FDVD%C2%B1RW%20Drive.volume" timestamp="1212709603" icon_position="64,282"/>
<file name="465.8%20GB%20Volume.volume" timestamp="1263069239" icon_position="64,282"/>
<file name="USB%20DISK%202.0.volume" timestamp="1263070714" icon_position="64,282"/>
<file name="Kingston%20DataTraveler%202.0.volume" timestamp="1263073745" icon_position="64,582"/></directory>
```
What's interesting to me about this file is the time stamp value. The time stamp is in the Unix "seconds since Jan 1, 1970" format, but this can easily be converted to something human readable, if my co-authors will permit me to use a little bit of Perl:
```
$ perl -e 'print scalar(localtime(1263073745)), "\n";'
Sat Jan  9 13:49:05 2010
```
Loyal reader Adrian Shaw wrote in to point out that the GNU date command will actually allow us to do this conversion without resorting to Perl:

$ date -d @1263073745
Sat Jan 9 13:49:05 PST 2010

So this is an awesome trick for Linux users, but don't expect it to work on other Unix-like operating systems unless you install the standard GNU tools.

The only problem is that this time stamp value gets updated if the user moves the icon for the device around on their desktop. But since users don't tend to do this very often, it usually reflects the time the device was first connected to the system.

On my Ubuntu box running a newer version of Gnome, the Nautilus agent actually creates a separate file for each new device. For example, the information for the "4.0 GB Filesystem" on my Kingston device ends up in a file called "~/.gconf/apps/nautilus/desktop-metadata/4@46@0@32@GB@32@Filesystem@46@volume/%gconf.xml", which looks like this:
```
<?xml version="1.0"?>
<gconf>
        <entry name="nautilus-icon-position-timestamp" mtime="1263074552" type="string">
                <stringvalue>1263074552</stringvalue>
        </entry>
        <entry name="icon-scale" mtime="1263074552" type="string">
                <stringvalue>1</stringvalue>
        </entry>
        <entry name="nautilus-icon-position" mtime="1263074552" type="string">
                <stringvalue>64,10</stringvalue>
        </entry>
</gconf>
```
What's nice about the newer file format is that there are multiple time stamps in the file. The "icon-scale" time stamp does not get updated if the user repositions the icon on their desktop, and therefore may give you a truer reading on when the device was first connected to the system.

The only problem with data in a user's home directory, is that an astute user may clean up after themselves if they're doing something nefarious. And they may use a secure deletion tool (see Episode #32) to prevent recovery of the data.

The last place to find information about the device is in the system logs. Both the kernel and the file system drivers log information about the device being inserted.

Here's the log from my CentOS system when the device is inserted:

Jan  9 13:51:22 localhost kernel: usb 1-1: new high speed USB device using ehci_hcd and address 8
Jan  9 13:51:22 localhost kernel: usb 1-1: configuration #1 chosen from 1 choice
Jan  9 13:51:22 localhost kernel: scsi7 : SCSI emulation for USB Mass Storage devices
Jan  9 13:51:28 localhost kernel:   Vendor: Kingston  Model: DataTraveler 2.0  Rev: 1.00
Jan  9 13:51:28 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jan  9 13:51:28 localhost kernel: SCSI device sdb: 7856128 512-byte hdwr sectors (4022 MB)
Jan  9 13:51:28 localhost kernel: sdb: Write Protect is off
Jan  9 13:51:28 localhost kernel: sdb: assuming drive cache: write through
Jan  9 13:51:28 localhost kernel: SCSI device sdb: 7856128 512-byte hdwr sectors (4022 MB)
Jan  9 13:51:28 localhost kernel: sdb: Write Protect is off
Jan  9 13:51:28 localhost kernel: sdb: assuming drive cache: write through
Jan  9 13:51:28 localhost kernel:  sdb: sdb1
Jan  9 13:51:28 localhost kernel: sd 7:0:0:0: Attached scsi removable disk sdb
Jan  9 13:51:28 localhost kernel: sd 7:0:0:0: Attached scsi generic sg1 type 0
Jan  9 13:51:29 localhost kernel: kjournald starting.  Commit interval 5 seconds
Jan  9 13:51:29 localhost kernel: EXT3 FS on sdb1, internal journal mode.
Jan  9 13:51:29 localhost hald: mounted /dev/sdb1 on behalf of uid 500

And here's what happens when the device is removed:

Jan  9 14:00:43 localhost hald: unmounted /dev/sdb1 from '/media/disk' on behalf of uid 500
Jan  9 14:00:47 localhost kernel: usb 1-1: USB disconnect, address 8

You'll notice that the system logs the UID of the user on the console of the system, as well as giving you information about the device name (no serial number though), and the size and type of file system found on the device.

The information logged on my Ubuntu box with a newer kernel version is slightly different:

Jan  9 14:02:26 ubuntu kernel: [ 2350.984617] usb 1-1: new high speed USB device using ehci_hcd and address 5
Jan  9 14:02:26 ubuntu kernel: [ 2351.365130] usb 1-1: configuration #1 chosen from 1 choice
Jan  9 14:02:26 ubuntu kernel: [ 2351.377732] scsi6 : SCSI emulation for USB Mass Storage devices
Jan  9 14:02:26 ubuntu kernel: [ 2351.378321] usb-storage: device found at 5
Jan  9 14:02:26 ubuntu kernel: [ 2351.378330] usb-storage: waiting for device to settle before scanning
Jan  9 14:02:31 ubuntu kernel: [ 2356.399268] usb-storage: device scan complete
Jan  9 14:02:31 ubuntu kernel: [ 2356.404119] scsi 6:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
Jan  9 14:02:31 ubuntu kernel: [ 2356.406027] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jan  9 14:02:31 ubuntu kernel: [ 2356.438414] sd 6:0:0:0: [sdb] 7856128 512-byte logical blocks: (4.02 GB/3.74 GiB)
Jan  9 14:02:31 ubuntu kernel: [ 2356.441587] sd 6:0:0:0: [sdb] Write Protect is off
Jan  9 14:02:31 ubuntu kernel: [ 2356.441594] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
Jan  9 14:02:31 ubuntu kernel: [ 2356.441599] sd 6:0:0:0: [sdb] Assuming drive cache: write through
Jan  9 14:02:31 ubuntu kernel: [ 2356.463161] sd 6:0:0:0: [sdb] Assuming drive cache: write through
Jan  9 14:02:31 ubuntu kernel: [ 2356.463231]  sdb: sdb1
Jan  9 14:02:31 ubuntu kernel: [ 2356.495857] sd 6:0:0:0: [sdb] Assuming drive cache: write through
Jan  9 14:02:31 ubuntu kernel: [ 2356.495900] sd 6:0:0:0: [sdb] Attached SCSI removable disk
Jan  9 14:02:32 ubuntu kernel: [ 2356.945441] kjournald starting.  Commit interval 5 seconds
Jan  9 14:02:32 ubuntu kernel: [ 2356.957462] EXT3 FS on sdb1, internal journal
Jan  9 14:02:32 ubuntu kernel: [ 2356.957535] EXT3-fs: mounted filesystem with writeback data mode.
[... device is removed ...]
Jan  9 14:12:17 ubuntu kernel: [ 2942.693376] usb 1-1: USB disconnect, address 5

You'll notice that the Ubuntu system isn't logging the UID of the user on the console at the time the drive is connected. But you could always get this information by running "last" to get the last login history of the system. The other problem, however, is that the newer kernel logs use a slightly different format for reporting the device manufacturer info, so there isn't a simple grep expression that will work when parsing logs from multiple different kernel versions.

Phew! That's a whole lot of information! The short summary, though, is that the only data that may exist long after the drive has been removed is the limited data in the system logs plus possibly some data in user home directories. I have to say that Windows leaves a much more detailed forensic trail. Whether you consider this a "feature" or not is up to you. I suppose it depends on whether you're representing the prosecution or the defense.

Command Line Kung Fu

Pages

Tuesday, January 12, 2010

Episode #77: USB History