2600 Article: Don’t steal music (or how to catch an iPod thief using forensics)

I said I would post this once it was published, and a few days ago I picked up the latest copy.  This article is a bit longer than what 2600 put out, because they were space limited (yes, I tend to be verbose.) So here it is.

Music is important, especially in a noisy office.  There is a girl that sits a few feet away in a cubicle, and she talks to herself all day.  As if it wasn’t bad enough to be stuffed into a cubicle but the constant chatter is maddening.  Honestly there are days that if I didn’t have my headphones on I could quite possibly lose it.  Because of this I am usually very careful to protect my iPod like it is made of gold–and if you look at the RIAA’s assessment (cost estimate of imaginary property? Huh?) of the value of the songs on it, it is worth more than gold!  But that is a different article.

It is a good place to work, they pay people well, and treat employees better than most.  I wasn’t too concerned when on my way home after work when I had realized that I left my iPod plugged into my Apple at work.  Of course, you being an astute reader, already know what happened.  The next morning arriving at work sleepy and slow, I was half way through the first cup of coffee before realizing that my music player was gone!  (Cue dramatic music.)  Of course I am always misplacing things, so I spent the next half hour tearing my cube apart looking for my iPod.  Nothing.  Crap.  Now I am angry.

I work in IT security, so my first reaction is to start putting together a incident timeline.  When did I leave the office, who was still there working as I was leaving.  It didn’t make sense, there was only a couple of folks left when I went home, and I KNOW that they wouldn’t steal from me.  So, maybe it was just a prank–there are a few folks that might find it funny to alarm me (and probably owe me for messing with them in the past.)  Without tact I ask them if they know anything about my iPod and let them know that if it was a prank that it was cool, but I would like my iPod back.  No luck; I believe them when they say they didn’t take it, but would add it to their list of ways to annoy me later.

Then it strikes me, I have a critical peice of information sitting in my lap and it just might get my iPod back in my hands.  It was plugged into a Mac, not my windows box, woohoo–Unix creates log entries when a hard disk is unplugged!  Sure enough, the /var/log/system.log has a bunch of the following:

Sep 10 22:31:23 computer kernel[0]: disk2s1: media is not present.

So I call up the physical security folks and let them know that there was a theft.  But, that I know what time it happened and because it was at night it should be pretty easy to figure out who did it.  The cleaning crew comes through at 6pm (quite annoying actually) and are usually done by 8pm.  So there should have been no-one in the office around the time my iPod grew legs, if anyone was there: they would look awfully suspicious.  They say they will get back to me, but since I know their manager I give her a call–to ensure that key card access logs get reviewed and that the security camera recordings are preserved.  About half an hour later I get a call saying they know who did it and will handle them later that day when they are scheduled to work.  Sweet.

The next morning the manager of the physical security group stops by and returns my iPod unharmed.  And she explains that it was a member of the cleaning crew that had come back after his shift to steal electronics.  I still feel justified in not having the standard knee-jerk reaction and would give them the benefit of the doubt in the future too!  He was given the opportunity to return the stolen property or we would press charges.  He immediately returned the iPod during the interview.  Of course the guy lost his job.  The moral of the story is that stealing music is wrong ;-)

This wasn’t the first time an iPod had been stolen at the office, and it wasn’t the last either–the things are like little stacks of cash laying around, and to someone desperate for money the temptation is just too much.  Because of that I decided to do a bit more research and look at what it would take to get the same results but from a Windows box.  Unix users have it easy–significant happenings with block devices, such as a hard drive, at the kernel level are logged by default.  For most Unix-like systems you can find these in /var/log/dmesg (or by running the dmesg command.)

But how about Windows?

But, alas Windows is the dominant OS out there 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 settings in place beforehand that make this type of work easy.  I found a way to get the same results on Windows XP, under the right circumstances.  Here is what I found under XP Pro SP2, it still seems to work on SP3, but does not work on Vista–sorry, as soon as the iPod is synced the disk is disconnected and you can only get a timestamp of when it was synced, not removed.

A list of forensic evidence retained pertaining to disk removal events in XP Pro, (or catching an iPod thief.)

User was logged in, and the iPod was removed. The system _has_not_ been shut down:

• When iPod was unplugged

• When iPod was last plugged-in

net use \\<hostname>\ipc$ /u:<administrator>

Substitute appropriate values for the <hostname>, and <administrator> account name.
Next you can perform the query:

logparser -i:reg -o:csv “select * from \\<hostname>\HKLM\SYSTEM\CurrentControlSet\ where path like ‘%iPod%’ order by lastwritetime desc” -e:1000 > outfile.csv

You should, once again, substitute an appropriate value for the <hostname> listed above. Also any line breaks should be removed when running the actual command.

Command options explained:

• “-i:reg” instructs “LogParser” to use the system registry as a source.
• “-o:csv” specifies that the output should be comma separated values. This allows for easier analysis within a spreadsheet program.
• “select * from \\<hostname>\HKLM\SYSTEM\CurrentControlSet where path like ‘%iPod%’ order by lastwritetime desc” Is the actual SQL query. It looks at all values in the registry, where the path name (not actual key values) has the text iPod. It then returns it sorted in a list with the most recent entries first.
• The 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 CurrentControlSet 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 a single-quote and percent signs as shown in the above example, surrounding the string “iPod”.
• “-e:1000” instructs “LogParser” to quit after 1000 errors (a number intentionally higher than likely to ever happen in such a restricted query.) If “LogParser” is not given this instruction, 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 spreadsheat 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!