Don't Steal Music!: Catching an iPod Thief Using Forensic Evidence
by frameloss
Music is important, especially in a noisy office.
There is a girl that sits a few feet away from me in her cubicle and talks to herself all day. As if it wasn't bad enough to be stuffed into a cubicle, her constant chatter is maddening. Without my headphones, there are honestly days when I could quite possibly lose it. Because of this, I am usually very careful to protect my iPod.
However, given that my workplace is relatively safe, I wasn't too concerned when, on my way home after work, I realized that I had left my iPod sitting on my desk plugged into my Mac. Of course, you can already guess what happened next. The following morning when I arrived at work, I was half way through my first cup of coffee before I realized that my music player was gone! Of course, since I always misplace things, I spent the next half hour tearing my cube apart looking for my iPod. Nothing. Damn.
I work in IT security, so my first reaction was to start putting together an incident timeline. When did I leave the office? Who was still working as I was leaving? Maybe it was just a prank. There were a few guys that might have found it funny to alarm me (and probably owed me for messing with them in the past). I asked around, but everyone I spoke to denied taking my iPod.
Then it struck me that I had a critical piece of information sitting in my lap that just might get the iPod back in my hands.
My iPod was plugged into a Mac, and UNIX creates log entries when a hard disk is unplugged! Sure enough, the /var/log/system.log had a bunch of the following messages:
So I called up the physical security folks and let them know that there was a theft.
Since I knew what time it happened and since it was at night, I assumed that it would be pretty easy to figure out who did it. The cleaning staff came through at 6 p.m. and was usually done by 8 p.m. So there should have been no one in the office around the time my iPod grew legs. If anyone was there then they would have looked awfully suspicious. Security said that they would get back to me, but since I knew their manager, I gave her a call to ensure that the key card access logs got reviewed and that the security camera recordings were preserved. About half an hour later they called to tell me that they know who did it and would handle them later that day when they were scheduled to work. Sweet. Key card logs and corporate video surveillance may have been useful for the first time known to man.
The next morning, the manager of the physical security group stopped by and returned my iPod unharmed. She explained that it was a member of the cleaning staff that had come back after his shift to steal electronics. He was given the opportunity to return the stolen property or face charges. He immediately returned the iPod but, of course, he lost his job. The moral of the story is that stealing music is wrong. ;-)
It wasn't the first time an iPod had been stolen at my office, and it wasn't the last either.
The things are like little stacks of cash laying around waiting to be taken. For this reason, I decided to do a bit more research and find out what it would take to get the same forensic results from a Windows machine. UNIX users have it easy; significant happenings with block devices, such as hard drives, are logged by default. For most UNIX-like systems you can find these in /var/log/dmesg (or by running the dmesg command). But, alas, Windows is the dominant OS and is likely to remain that way for a while.
The logging on Windows isn't that great. Sure, it is configurable, but it somehow never seems to have the right settings to make this type of work easy. However, I found a way to get the same results on Windows XP, given the right circumstances. Here is what I found that works under XP Pro SP2. It also seems to work on SP3, but does not work on Vista, where you can only get the last time an iPod was synced, not removed.
In XP Pro, the time at which an iPod was last plugged in and the time at which it was unplugged can be determined in the following cases:
- User was logged in, and the iPod was removed. The system was not shut down.
- User was logged in, logged out, and the iPod was subsequently removed.
- User was logged in, logged out, logged back in, and the iPod was subsequently removed.
The time at which an iPod was unplugged cannot be determined if the user was logged in, the iPod was removed, and the system was subsequently rebooted because the:
registry tree appears to be dynamically rebuilt at boot time.
So, as long as the system was not shut down, you can tell when a device was removed.
This is done using the Log Parser tool from Microsoft. If you plan on doing the procedure remotely (which will result in less overall changes to the system when compared to logging in as a user interactively), you will need to perform the following command from a CMD.EXE shell on another host before beginning:
Substitute appropriate values for the <hostname> of your machine and the <administrator> account name.
Next you can perform the log query:
You should, once again, substitute an appropriate value for <hostname> listed above.
Also any line breaks should be removed when running the actual command.
Command Options Explained
- -i:reg instructs Log Parser to use the system registry as the source.
- -o:csv specifies that the output should in Comma-Separated Values (CSV) format. This allows for easier analysis with a spreadsheet program.
- "select * from \\<hostname>\HKLM\SYSTEM\CurrentControlSet\ where path like '%iPod%' order by lastwritetime desc" is the actual query. It looks at all values in the registry, where the pathname (not actual key values) has the text iPod. It then returns it sorted in a list with the most recent entries first.
- HKLM is shorthand for HKeyLocalMachine.
- To see what other fields can be queried you can run: logparser -i:reg -h
- There are three subkeys below CurrentConrolSet that contain relevant information (Control, ENUM, and Services) which is why the query is performed at such a high-level within the registry.
- The string '%iPod%' can be changed to represent another device, such as a USB thumb drive. You can view the HKeyLocalMachine\SYSTEM\CurrentControlSet\Enum\USBSTOR\ area of the registry to see what other removable USB devices (or substitute USBSTOR, with SCSISTOR for SCSI) have been connected and experiment with the name assigned by the device manufacturer to find the evidence you need. Be sure to encapsulate whatever string you need with single-quotes and percent signs as shown in the above example, surrounding the string "iPod".
- -e:1000 instructs Log Parser to quit after 1000 errors (a number intentionally higher than is likely to happen in such a restricted query). If Log Parser is not given this instruction, then errors will not appear in the output, and it is important to see the errors in case you are not seeing all of the necessary data.
- > outfile.csv specifies the file name where information will be stored.
Opening the CSV file in your choice of spreadsheet program will allow you to sort the data by access time.
Sort by descending timestamp, and you should be able to see when the registry key was last written.
This is when the device was unplugged.
I hope you are as lucky as I was and get your iPod back, too!