USB Forensics

✨ Welcome to the land of USB forensics! ✨

Last time I wrote about the USB basics, documenting my quest to understand and study how USB devices and their hosts communicate. This time let’s dive into USB forensics on Linux and macOS – I want to find out what kind of information can be dug up about the machine’s USB connections.

Linux

On Linux, the /var/log directory seems to be the place to start. It is full of files of interest such as messages, syslog, kern.log. Each file is explained in more detail here; we will focus on the ones which are known to give us details about USB.

messages

This file consists of global system messages. Let’s see what information it can give away that has something to do with USB.

Just a quick look reveals that whenever a new USB device is registered, the following message gets logged: New USB device found. We’re going to use this phrase and sprinkle some Linux magic on it to narrow down our results and make them more readable.

actual footage of me sprinkling some Linux magic, whatever that means

root@kali:/var/log# cat messages | grep -i -E "Apr 29 .* new usb device found" -A 4
...
Apr 29 20:23:00 kali kernel: [ 7374.461566] usb 1-1: New USB device found, idVendor=0930, idProduct=6545, bcdDevice= 1.10
Apr 29 20:23:00 kali kernel: [ 7374.461567] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 29 20:23:00 kali kernel: [ 7374.461568] usb 1-1: Product: DataTraveler 2.0
Apr 29 20:23:00 kali kernel: [ 7374.461569] usb 1-1: Manufacturer: Kingston
Apr 29 20:23:00 kali kernel: [ 7374.461570] usb 1-1: SerialNumber: 50E549C20268B0C14972C88E
--
Apr 29 20:23:01 kali kernel: [ 7374.763690] usb 2-2.2: New USB device found, idVendor=2109, idProduct=0103, bcdDevice=14.24
Apr 29 20:23:01 kali kernel: [ 7374.763694] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 29 20:23:01 kali kernel: [ 7374.763697] usb 2-2.2: Product: USB 2.0 BILLBOARD
Apr 29 20:23:01 kali kernel: [ 7374.763699] usb 2-2.2: Manufacturer: VLI Inc.
Apr 29 20:23:01 kali kernel: [ 7374.763701] usb 2-2.2: SerialNumber: 0000000000000001

This command might be a bit much if you’re not familiar with Linux command line, so feel free to refer to the explanation below if you find it confusing.

I redacted some of the output with ... as the same devices have been connected multiple times therefore producing identical logging messages at different times, there were also devices like the USB hub registering that I took out, so that we you can focus on the entries regarding the USB memory stick. I am mentioning this just so that you don’t expect the output of that command to be 10 or 20 lines – if you use your VM often it will be much much larger, and it’s how it’s supposed to be.

syslog and kern.log

The syslog file keeps track of everything that happens on a machine apart from authentication related events. kern.log logs kernel events. Both of these files show the same messages about the USB device connections as messages and can be analysed using the commands as above. But this is getting tiring, isn’t it? So many files to be checked in the exact same way. So, let’s…

Yes, I am very clearly a sucker for vintage memes. It’s classy, okay?

usbrip

Usbrip is a tool which automates the above search for you.  The full instructions on how to set it up can be found in the project repo, although I found them a bit convoluted; the easiest way I got it to work is by running pip3 install usbrip. The tool will enumerate key files for you and show you data in a a more readable format – example below.

usbrip output, no meme this time

MacOS

log command

One of the ways to review USB connections on macOS is to use the log command. Sarah Edwards of the mac4n6 blog proposes the following syntax for displaying system messages regarding USB mass storage devices. She goes into great detail of tuning and formatting the output to fit your needs – make sure to give her post a read if you’re curious.

log show --predicate "eventMessage contains 'USBMSC'"

A predicate includes a pattern clause (eventMessage), an operator (contains), and the search term itself (USBMSC). These are not the only options, of course; you can play about trying to find different things.

Centralised thumbnail caches

Woohoo! I knew I would be able to stick in my dissertation knowledge in here somewhere. My dissertation was on centralised thumbnail caches in macOS and I promise I will try and not summarise the whole of it here (but you gotta get through a bit). While this method will not give you hardware information such as serial numbers or unique IDs of USB devices, you can gain some circumstantial knowledge of the customisable USB storage device names, and a rough (not definite) idea of the movement of files. It’s worth noting that modern operating systems create thumbnails for most file types – including text files, code, PDFs, videos – and sometimes the thumbnail of a file might even hint at its content. Example being a PDF file whose thumbnail reveal the document’s first page’s layout.

an example of a PDF file’s first page (right) and its extracted thumbnail (left)

The centralised thumbnail cache is a place where all thumbnails and corresponding metadata are stored. You can find it here:

​​​​​~/var/folders/<random 2 letter string>/<random n letter string> /C/com.apple.QuickLook.thumbnailcache

Bear in mind, to be able to to access this directory you will need to turn of the System Integrity Protection (instructions and associated risks are explained here.).

Inside the com.apple.QuickLook.thumbnailcache folder you will find some files, out of which we are especially interested in index.sqlite (the database containing metadata about files for whose thumbnails were cached) and thumbnails.data (the data blob actually containing the thumbnail images). Note that thumbnail pictures in thumbnails.data are stripped of magic numbers, making it impossible (or at least very difficult) to identify and carve. This is (one of the reasons) why we need index.sqlite which provides offsets for each thumbnail picture.

The process of extraction thumbnails from thumbnail.data based on the offsets listed in index.sqlite has fortunately already been automated by Mari DeGrazia in the QuickLook Parser project – so please don’t try and do it by hand!

I won’t go in too much detail – this isn’t really the topic of this blogpost – but one interesting table in the index.sqlite database in the files table.

This gives you the file names and paths of the files for which thumbnails were created, as well as IDs of the volume and of the file within the volume. Note that in the folder column you can see the name of the USB storage device (the name of mine is literally ​​USB_STORAGE) which can help direct your further investigation. (Row #4 is what happens if you try and delete a file off your USB stick, and then proceed to the Trash in the UI to empty it. You actually leave double the footprint). Linking entries referencing the same file name can also help you detect how the file was moved throughout the file system – above we can see what a move from USB_STORAGE to Trash looks like – but as I said before, this is purely FYI. It could not really be treated as definitive evidence, because theoretically you could have two different files with the same name on different volumes and this method would not allow you to differentiate between them. This is not to say that centralised thumbnail caches as evidence have no admissibility at all, either. I talked a bit more about how they were historically used in court in the second half of my Le Tour Du Hack talk, so feel free to check it out.

🔮🔮🔮

I hope this has been useful and provided you with an introduction to USB forensics on Linux and macOS. It was great to be able to throw in some bits of my dissertation into this as well. Thanks for reading and see you in the next one!

 

Sources

• • https://www.plesk.com/blog/featured/linux-logs-explained/
  • http://forensic-proof.com/wp-content/uploads/2012/06/USB-Device-Tracking-Artifacts-on-Linux.pdf
  • https://eclecticlight.co/2016/10/17/log-a-primer-on-predicates/
  • https://www.macworld.co.uk/how-to/mac/how-turn-off-mac-os-x-system-integrity-protection-rootless-3638975/

Advertisement