GIAC Certified Haiku Master

One of the many reasons why I like the SANS Institute is that the collective SANS community is made up of some pretty sharp and creative people. One of the creative things that SANS did in promoting their upcoming SANS Boston conference was to have a Twitter Haiku contest that was judged by Craig Duerr with the words provided by Stephen Northcutt.

I've always had an interest in Haiku so even though I won't be able to make the conference this year, I decided to take a shot at the competition. It turns out that Dan Crowley also has a thing for Haiku and he decided to participate also. The battle was joined and Dan and I entered what we affectionately began to call the SANS Haiku Thunderdome (Two poets enter, one leaves).

Dan won the first round and I somehow managed to win the next two rounds and emerge the winner. I'll be the first to admit that Dan is a better Haiku poet than I am, but sometimes a blind squirrel finds a nut and that just happened to be me this time around.

The spoils of victory were a certificate proclaiming me a GIAC Certified Haiku Master and I also was awarded a Iron Kung Fu fan as my trophy. Very cool. We'll call this competition reason #214 why I love SANS.

The Ballad of Grayson Lenik

Grayson Lenik is a relatively new member of our community who has made the decision to move from a systems administration focus to a digital forensics focus. You can follow his journey at his blog "An Eye on Forensics".

Grayson is clearly a sharp fellow. From what I can tell, he passed the SANS GCFA exam via the challenge process rather than taking any of the SANS course content. That's impressive considering the scope and difficultly of that exam. Grayson has been encouraged to contribute to the recently started Into The Boxes digital forensic online magazine and, to his credit, he's accepting the challenge and looking for a topic to research.

His comments on the research issue made me think of my decision making process regarding engaging digital forensics research. I've been doing digital forensics for a relatively long time now, but it was only last year when I decided that I'd start to contribute to the community in a meaningful manner in this area.

The reasons why I hadn't done so were largely due to intimidation. I look up to people such as Harlan, Rob, Jesse and Eoghan (otherwise known as the people who don't need last names to know who they are) and the work that they have done advancing the field with their research, training and tool development efforts. Who was I to even think that I could play on the same field as them? I also fell into a common trap that I see with IT security people which is that because I didn't know everything, I thought that I didn't know anything.

Last year I stumbled across Adobe Flash Cookies while doing an examination and started to dig into them. I began to learn that some of these cookies can provide a treasure trove of information for a digital forensic examination and started to parse them out as well as I could. I made a couple phone calls to some very experienced examiners and asked them if they had heard of them before and was told that they had not. One of those examiners was actually able to take what I told them over the phone and put it to use in a criminal investigation they were using so I knew I had something that would be beneficial to the community.

So I decided to just plow ahead and start writing something up with the goal having something to present at a conference like CEIC. I started to create an early overview paper. I was lucky enough to have people like Cindy Murphy, Gary Kessler, Jimmy Weg and Mark Johnson review that paper and make suggestions on how to improve it. Cindy even managed to carve out some time from her busy schedule to do some additional research in regards to a particular kind of cookies that really helped fill out my knowledge. I briefly distributed the paper through some of the email lists like IACIS and HTCC hoping that it might get the word out and generate some additional research leads.

I sent it out to the community and heard....nothing much. I later learned this is a pretty common occurrence in our community even for Those-Who-Only-Need-A-First-Name. A digital forensics researcher will put a lot of work and effort into a project, release it out for free and ask for feedback...and will rarely get any back. I would get people thanking me for providing them the paper after I sent it to them, but then no response back to my requests for feedback on whether it was useful, whether they found any errors, how I could improve the final product, etc.

One of the notable exceptions to this which was Jesse Kornblum. Some time after I had released the paper, I checked my email to see a request from Jesse for the paper. It was a classic good news\bad news situation. The good news was that Jesse Kornblum wanted to see the paper. The bad news was that Jesse Kornblum wanted to see the paper. I'll admit a certain amount of dread when I hit the send button. The short version of the story is that Jesse liked what I had done. He offered encouragement and suggestions on how to proceed. Very cool!!!

So bolstered with my new found confidence, I pressed forwards with the research project and hit a major sticking point when I encountered some very odd metadata behavior that I absolutely could not figure out. I was saved by Eoghan Casey who helped me determine that the odd behavior I was seeing was due to File System Tunneling (which I will explain at my CEIC presentation next month). Yet another of my forensic idols riding to the rescue!

Around January or so, however, I was starting to realize that I was over my head. I able to parse out the header information for these artifacts, but I didn't have the knowledge to completely parse everything out. My hex-fu was okay, but it wasn't good enough to completely finish the project the way I wanted to complete it. The way I saw it was that I could either crawl back into my hole and admit defeat or just publish what I learned so far and hope that someone else could run with the research at a later date. I decided to do the second option with an eye on getting what I had completed published in some form.

Then on Feb 17th, 2010, I got lucky. Kristinn Gudjonsson posted some of his Adobe Flash Cookie research on the SANS Forensic blog. My initial reaction was that I had been too slow, too unknowledgeable and had been just wasted months of my research life because what he had done was so fantastic that it was better than I could have ever done. I even found that I had made at least one major error in my original header research. Woe is me, right? However, when I started to look closer, I realized that we had approached the research from different standpoints. Kristinn is an amazingly sharp incident responder and forensic examiner with an engineering background. That means he spent a lot of time looking at the hex level view of these cookies and did an exceptional job parsing them out. I approached the research from a more traditional investigative digital forensics perspective which means I concentrated on the metadata (which is why I discovered and overcame the file tunneling issue) and a lot of the higher level aspects of the research such as how and when Flash cookies tended to appear on a machine. I became excited about the prospect of merging the research, but would someone like Kristinn be willing to talk to little old me? (There's that self doubt again...)

As you know from my previous blog entries, yes, he was more than willing to talk and after a flurry of emails comparing our various notes on the project, we decided it made good sense to team up and create a final research project.

The moral of the story?

1. Be like Grayson Lenik, not Eric Huber. Grayson has been a member of our community literally only for a matter of months and he's already sharing what he's learning through his educational process and he's going to do a research project for ITB. It took me years before I decided to do what Grayson is doing now.

2. Research what you know and if you get stuck, get help and continue on. There is a vast amount of research opportunities in digital forensics for all skill levels. Harlan wrote a particularly pithy bit of advice for Grayson when he said "...start writing about what you know...we'll work with you." That's essentially what I have been doing. I plow through the best I can within the range of my abilities and if I get stuck, I go ask for help. Grayson will do great because he's a sharp fellow who has the desire to do the work and he'll have people like Harlan and Don Weber to help him when he needs it. What I've found is that the gurus like Harlan and Don are very helpful if you approach them in the right way.

3. If you don't have time to complete a project, even partial research is helpful and someone else might take what you have done and run with it. I did that with my Kindle forensic research. I knew I wasn't going to have the time and probably the knowledge to completely parse every aspect of what one can find on a Kindle so I posted what I learned on this blog.

4. Provide feedback. If you don't have the time or desire to do digital forensic research, no worries. However, one thing that you can do to help those who are doing it is to provide feedback when you have found something useful that helped you in your job. Did you like a particular digital forensics book? A nice thing to do would be to post review at a site like Amazon. Even negative feedback is welcome as long as it's constructive. If I made a mistake, I want to know about it. If what I wrote didn't make any sense, it doesn't help me develop as a writer or a researcher if I don't know what I'm doing wrong.

Forensic 4cast and Me

The most recent Forensic 4cast podcast is up with a brand new format. Lee has decided to test out a panel format where he brings together people from the digital forensic community to discuss the topics of the day.

This episode included a panel that consisted of Lee, Tom Yarrish, Joe Garcia and myself. Give it a listen and let Lee know what you think about the new format. I'm grateful to Lee for the opportunity and I hope I did a good job for him. I have to admit that I was a bit vexed when I heard the podcast after the fact because the sound quality from my phone wasn't remotely as good as the other panelists. I already have a proper Skype certified phone on order from Newegg so that I can use it with Skype next time and not sound like the panelist who is calling from the outer reaches of Absurdistan.

Lee has also released the much anticipated presentation on Volume Shadow Copies that he was due to give at the SANS EU Forensic Summit. That summit was delayed because of, as Chad Tilbury puts it, the Krakatoa eruption in Iceland. Chad made the Krakatoa reference on Twitter this week and I've been laughing about it ever since. It's yet another reason why I like socializing with my fellow digital forensic examiners on Twitter. Chad is a very sharp fellow and one of the primary SANS digital forensics instructors.

As Lee was nice enough to mention at the end of the podcast, I will be presenting on the topic of Adobe Flash Cookies at this year's CEIC conference. Kristinn Gudjonsson and I have been working on an article to submit to an academic journal and I have crafted an overview of the research for the presentation. The presentation won't cover much of the content in the article because there just won't be enough time to do that, but it will provide examiners with enough of an understanding of these artifacts to start using them in their digital examinations. I'm looking forward to CEIC this year as there are a lot of amazing presentations such as Rob Lee's Super Timeline Analysis Lab. I also think it's a moral imperative that I have an Bacon N' Eggs burger at LBS Burger.

I started this research project independently late last year and it turns out Kristinn had also been working on parsing these artifacts as part of his larger log2timeline research. He posted about them on the SANS Forensic blog earlier this year and that's when we discovered that we had been working on the same subject. We essentially had a "you got chocolate in my peanut butter" moment and decided to work together on putting together a paper that we hope will be useful to the community. Kristinn is certainly the brains behind the operation given his very robust technical background. I never would have been able to fully parse these artifacts on my own because I don't have the deep technical knowledge that Kristinn has so I'm lucky he posted on the SANS Forensic blog when he did and that he's generous with his time and knowledge.

One of the reasons I mentioned Chad earlier in this post is that he also did some research on Adobe Flash Cookies and posted about it on the SANS Forensic blog.

Additional Thoughts on Kindle Forensics

We're in an exciting time in digital forensics. It seems like each week we have a sharp digital forensic researcher discovering some new method or creating a new tool for us. We have seen incredible advances in traditional hard drive forensics and we have the wonderful and relatively new world of mobile device forensics to explore.

I've been doing digital forensics many years now and one of the things I've noticed about digital forensics people is that we sometimes tend to engage in catastrophic thinking when it comes to advances in technology and the future of digital forensics. We've all seen the various predictions that hard drive sizes, thin clients, encryption and other advances would spell the end for digital forensics. In fact, these advances show that our skills will become more in demand. However, we will have to constantly keep our edge sharp or we will fall behind. There will always be some sort of digital technology that will require a digital forensics practitioner to examine. Digital forensics will no more fade way than will technology or law, but it will be a constantly changing field.

The Kindle is a great example of how technological advances will provide examiners new opportunities for their examinations, but why examiners need to invest a considerable amount of time keeping their technological edge. The Kindle isn't a computer and it's not a cell phone, but it has qualities of both.

I recently received an Amazon gift certificate from a friend of mine. Amazon can distribute their gift certificates through email. In this case, the gift certificate was sent to my email address and included a code that I could enter into my Amazon profile to credit my account for the proper amount. Of course, I used that amount to purchase several books for my Kindle.

The Kindle book store can be accessed by the Kindle itself through the device's 3G network connection. There isn't any need to connect the device to a computer to download purchased content like you would for something like iTunes. You merely access the Kindle store via your Kindle device and you can purchase your books using your Amazon account. Another option is that you can log onto the Kindle bookstore on a computer using the Amazon website. You can then shop for Kindle books, purchase them through the website and have the content delivered to your Kindle via the wireless network. This is what I did with my gift certificate and after I had made my purchase, I picked up my Kindle and the books were on my device.

Great stuff for the consumer, but something that a forensic examiner would need to be very aware of when dealing with the Kindle as evidence. The last thing you want is to have a Kindle sitting in your evidence room waiting to be examined and to have additional content land on the machine and potentially overwrite existing evidence.

My advice is to treat the Kindle like you would any other mobile device examination up to and including using a shielded environment where the device can't phone home. A good research project for someone would be to determine whether or not it's safe to keep the device outside of a shielded environment if the 3G network is disabled by the examiner.

A Cursory Look at Kindle Forensics

I recently purchased a Kindle which I have come to adore. It's one of those devices make it hard imagine what life was like before you purchased it. However, being the hopeless forensic geek that I am, I had to figure out what sort of forensics could be performed on the device. (No, I have no idea how I got someone to marry me. I really don't.)

I purchased the current generation Kindle with the 6" screen. This model provides the user the ability to plug the device into a computer via a USB port to interact with the device. Amazon accomplishes this ability by creating a 1.5GB portion of the device that is visible and accessible to the user as if it were a standard USB storage device.

From the research that I have conducted so far, it appears that you can treat the Kindle as you would any other USB storage device for imaging purposes. The best way to do it is to use the USB cable that Amazon provides for connecting the Kindle to a computer. You can then write block a Kindle like you would any USB device. For my research, I used a Tableau T8 USB Forensic Bridge and was able to make the image using EnCase without any problems.

I haven't spent much time on the analysis portion of this research. However, I can report that a Kindle USB Drive shows up as an mkdosfs\FAT32 situation. This makes sense given that the Kindle runs some sort of Linux OS that we can't see via this USB capture process.

There are some interesting artifacts of the low hanging fruit variety. For example, "userannotlog" file located in the system folder. It lists the last book that I read, what my position was in the book and it also includes clear text time stamp information that correlates with when I know I was reading the book in question. Very cool.

The "documents" folder, as you might expect, contains the actual content that I have on my Kindle. I don't have much on it right now, but each book has an .azw file which is the actual content of the book in a proprietary format and a .mdp file that...well, I don't know what it does at this point.

There is a "search indexes" folder in the system\search indexes folder path that, one assumes, keeps track of searching done on the device. I bought a wine book that I did a search for the word "Pinotage" (Sigh. Yes, add "wine geek" to my list of vices...) and I used that as a keyword for a search...and came up with nothing eventful. There were about 20 hits on the word, but all of them in the context of other words in that alphabetical range so nothing that would show that I searched for that word.

You'll find a lot of indexed words in the system\search indexes\Index.db What I'm seeing already is that there are three bytes before each word that are clearly meaningful. For example, the word "pinewood" is preceded by 0x740008. So what we have is the word "pinetorch" and then 0x740008 and then the word "Pinewood". I don't know what the 0x74 means or if it's associated with the word "pinetorch" or "pinewood", but the 0x08 is the length of the pinewood entry. It's probable that this length indicator actually uses two bytes which would make 0x0008 the bytes that indicate length. I'm seeing this behavior consistently in this index file where a word is preceded by byte(s) whose hex value correlates with the length of the word that comes after the byte(s). Interestingly, I'll see a block of words pretty close together and then one word will end with 0x7A instead of 0x74 and then there won't be anymore words until a new block starts again about 900 or so bytes later. Towards the end of this file, there is a listing of the books on the Kindle and the paths to their associated files.

There is also a reader preferences file in the system\com.amazon.ebook.booklet.reader\reader.pref location. It has a clear text time stamp that appears to correlate with the last time I used the Kindle. It also declares what preferences I'm using for a dictionary, the type of justification I'm using and the last book I read.

There's a white paper in here for someone somewhere.