Home Archives for 2011

Back to Basics, CD and DVD basic forensics

Well hello there reader,
At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office). Often times we will go over case studies of recently solved cases but other times we get back to basics because you can't assume everyone knows everything you do. One class we recently did was on CD/DVD forensics and since it was received well I thought I should do a similar thing here on the blog. I admit I was watching the barefoot contessa's 'back to basics' show before i wrote this so the title is most likely influenced by delicious food.

I think a lot of people have forgotten about DVDs and CDs as important forensic evidence with the widespread use of cheap reusable USB storage (commercially introduced in December 2000 (Thanks wikipedia!)), but back when I got started (1999) it was very much 'a thing'. There are four important things we can determine forensically from a CD/DVD.

1. The volume name of the CD (always)
2. When it was burned (always)
3. What software made the CD (sometimes)
4. The previous burns (always)
and some easter eggs.

1. The volume name of the CD
All of the CDs I reviewed start with a ISO9660 session on the disk which began at an offset of 8000. You can see in the screenshot below that standard identifier has been set as 'CD001' which is the default for most burners when a ISO9660 session is selected. However what we care about is right after that the name of the CD is ' Oct 28 11 09:33'.

You may think, why do I care about this, this is the volume name that I can see in any tool? Well if you have a multi session disk the volume name will be set to the current session, this may be the only way you have to determine the labels of the prior sessions. We will talk more about sessions in 4.

2. When it was burned
Near the end of the ISO9660 session block are four time stamps, I've always seen them set to the same time. This is the time the CD/DVD was created.

Let's break the timestamp down to a more readable form:

2011102808333500è
2011102808333500è
2011102808333500è
2011102808333500è

As you can see each of them terminates with ascii character è which is hex E8. Breaking down an individual entry we can see that the time is:
2011 10 28 08 33 3500
So October 28, 2011 at 8:33:35am is when the CD was burned, notice this is one hour off of the CD label time. Note that this time is only as accurate as the system clock that burned the CD/DVD.

3. What burned it
Depending on what software burned the CD/DVD many of them will also place the name and version of the software in the reserved space of the ISO9660 session start. In our example we can see that the name of the software that burned it is 'PRASSI2.1.374'.

Doing some quick searches for 'Prassi cd burning software' reveals that this is Primo Prassi version 2.1.374 a now defunct company whose software was bundled with some CD/DVD burners.
Why do we care? If you are trying to prove that a CD/DVD was burned on a particular system matching the software name and version to what was installed on the system can be one indicator that you can use.

4. The previous burns
If you are inspecting a rewritable CD/DVD and it has had more than one write burned to it, then each of the writes are still available. There are multiple layers of burnable media within a rewritable disk and when inserted into a CD/DVD ROM your computer will only show the most recent session. When you image the CD/DVD using a tool like FTK Imager all the prior sessions will be viewable. This is why determining the name of the session may be important as we detailed in 1.

5. Easter Eggs
Sometimes you'll find something unexpected. The ISO9660 specification does not state what can't exist within the reserved space of the session start and systems don't parse for unused areas. For instance within MSDN DVDs you'll be Microsoft's name, address and phone number. What is contained within the session start beyond what we've described here will also depend on what the burning software programmer decided to place within it.

That's it, I hope this shined some light on a possibly forgotten set of facts. Let me know what you think, your comments help to motivate me to keep posting in between baby bottles.

Oh look, I still have a blog!

Hello Readers!,
I know its been awhile but thanks for not sending any threats or rotten fruit. Things have been very busy around G-C with work flooding back in and the new book, which is very behind. This no reason not to try to keep up with all of you and our new research.

I'll follow up with a new blog post tomorrow, a simple short one about what many forgot about basic CD/DVD forensics. Until then, did you know I'm google+ and twitter?

http://twitter.com/#!/HECFBlog
https://plus.google.com/u/0/?tab=wX#104808728995007755708/posts

Feel free to add me/follow me/circle me while I attempt to get back into the swing of things, so many new things for us to talk about in this one way conversation.

Speaking of two way conversations, I've put in to speak at CEIC again and I'm looking for other conferences. Let me know if yours is looking for one!

CEIC 2011

Hello Readers,
Thanks to everyone who came to my session at CEIC 2011, I hope you enjoyed it. Here are my slides: link that I used in my presentation. I'll have the code up soon for everyone to download. I'll be making one post per exchange version so I can explain the procedures.

NCCDC is coming - My favorite time of year

Once a year the fine folks at the National Collegiate Cyber Defense Competition invite a team of people to participate in their event as red or white team members. I'm happy to announce that I've been asked to return as captain of the red team this year again on April 8-10 in San Antonio, Texas. I got my start as a professional in network security and though I speak about computer forensics publicly we at G-C still do network security for select clients.

For those not familiar with CCDC it is a national competition that pits teams of college contestants who have to defend their network while continuing to deploy new business services against a team of people who are looking to ruin their day.While there is always a team who wins the national title I've always felt that it's the red team who always wins since we have the most fun.

Getting involved with CCDC is something I've always enjoyed doing and would recommend others do as well, if you are looking to volunteer as either a good guy or a bad guy you should go here http://www.nationalccdc.org/index.php?option=com_content&view=article&id=58&Itemid=70 to get involved at either the national or local levels.

If you are company looking to recruit the best talent emerging out of today's universities you could also benefit by sponsoring, as we have, the event and get access to these students before they can write their own ticket. To sponsor go here: http://www.nationalccdc.org/index.php?option=com_content&view=article&id=59&Itemid=37

New year, New book!

Hello Readers,
I thought I'd take this weeks post to announce that I just signed the contract with McGraw Hill to write a new book. It will be called 'Computer Forensics, A Beginner's Guide'. It's meant for those of you already in the IT field who are looking for a jump start into your first computer forensics investigations. I'll post more details as I finish the manuscript but we are currently set to have in stores in early November.

Oh no, it's GroupWise!

Hi there Reader,

For many years when I talked to a client about their network environment, these would be my words 'Oh no, it's GroupWise!' but not anymore!

What are you missing? AIX

Happy February Readers,

I didn't want to miss last week's posting, but I also didn't have the time to make a quality post before leaving on a trip. So quality over quantity will hopefully gain favor with you. I'm taking a break in the What was wiped series to give myself some more time to gather what I need and instead I am continuing the What are you missing series in this post.

Doing forensics on specialized servers, which I will define as anything non wintel and whose file systems have no parsers supported in forensic tools, is an interesting challenge. You have to:

1. Research where the system log files exist

2. Determine what format the logs are in

3. Capture the metadata of the file system

4. Determine if the file system can be parsed by anything but the running OS

5. Determine if it's feasible to image the server via DD

6. Determine if here is any hardware specific evidence that exists

A good example of this would be an older AIX system as detailed below

What was wiped? Part 1

Hello again Reader,

I've actually put an appointment on my calendar now to remind me to blog, let's see if reminders will ensure regular posts.This is a short beginning for part 1 to insure I meet these weekly updates.

Many times when you are working an investigation the question of spoliation will come up. In the most obvious scenarios of spoliation a suspect will use a tool that will to some extent wipe out his tracks. These tools come in three flavors:

1. Whole disk wipers: It's fairly obvious when this happens, though some suspects may tell you it's just encrypted. If they say that ask them what program they used to encrypt it and to please hand over the key.

2. File/directory wipers: If someone were to run a program such as bcwipe or eraser to delete files or directories the first thing these programs do is rename the file to prevent you from recovering what file was deleted. So if your suspect wiped 1,000 files you would find 1,000 randomly named files all seeming modified within seconds of each other on the disk from a different date. After renaming the file, it sets the time and after overwriting the contents of the file it sets the size to 0.

Here is a ftk imager view of a directory named temp with some random new files made:

Here is the same directory in ftk imager a second after wiping:

"How long these file stick around seems to vary by the file system. In older cases I found them months after the fact but on my Windows 7 system that I'm running ftk imager doing a view of my local physical drive some random files disappear in a couple seconds, which accounts for why we don't see 7 random files. " *This isn't exactly true, please see the update below* This wipe was done using bcwipe, the behavior of what wipers leave behind and how it runs on each OS and file system sounds like a good post for me to work on.

In part 2 we will go into system cleaners like CCleaner and some research into what they leave behind.

Update:

Looks like my disappearing wiped files are not a product of a different version of windows or the file system, it was the windows write cache. I made a couple of new files before and just wiped them immediately after, looks like they didn't actually get committed to the disk before I wiped them and thus would not be around afterwords.

To test this I downloaded a random set of source code from sourceforge, extracted it to a directory and then rebooted to make sure everything was flushed.

After rebooting I wiped seven files from a directory in the source tree and got seven wiped entries as expected:

As you can see, seven randomly named files all again with the date of 4/30/1986 and the time 11:43am. I guess this goes back to my last post, if something seems wrong double check your assumptions.

When I wipe the entire directory tree it then appears as an orphaned directory with all of the directory names and file names changed again to random letters with the same date as we saw before, except for the directories which remain the correct date (these times are in UTC so the date appears as 1/20/11):

New blog design

Happy Sunday,
hope you enjoy the new blog design as much as I do. I've added some facebook/twitter buttons as well to make things easier for those of you already sharing, thanks btw. Looking for the next blog to be up Tuesday.

What are you missing?

Hola Readers,
Every image is a special snowflake in regards to what software you find installed. There are times though when an investigator, myself included, gets comfortable as to what to expect and what they believe their tools are already doing for them. I had such an occasion last month when I found an image where the user was using Google Chrome as their browser. The case this was for is now settled and there was no public disclosure of my involvement in any form of declaration/affidavit/report so I will not be identifying the parties.

I was the second person to review the image at the time and we were looking to recover communications between our suspect and other parties around the time of his departure from his then current employer. What was suspiciously absent in our first round of reviews was a lack of web activity being reported from our standard tools. When this happens three things come to my mind for sanity checking:

1. When did the user profile I am looking at get created?
If this is a new system and I got handed it a couple days after the suspect started using it maybe what I'm seeing is correct. In this case, no the system had been in use for at least a year.

2. Is there any indications of popular 'cleaning' or wiping software being used?
Running through the user assist records, lnk files to no longer existent sources or other artifact sources that no longer show data after a consistent date are all signs of this. I will write another blog post about detecting what/when something was cleaned. In this case everything else was in place as it should be.

3. What other programs are installed? Am I missing something?
A quick look through the program files folder and user assist should be done at this point, is there something being used here that you hadn't dealt with previously. The user in this case had IE and firefox installed on his system so I didn't think to check for yet another web browser.

So I took a look through the keyword hits coming from his personal email address and noticed for the first time that they were contained within Chrome SQL Lite databases. Prior to this point I had not extracted the history files for a Chrome user and began a round of google searches to determine how to proceed.

While Google Chrome does make use of SQL Lite databases, basically flat files that contain a database structure that can be used like a relational database without the overhead, I didn't want to manual string together queries. I found two pages that helped me reach the evidence I needed.

The first located on the SANS blog provided me the information I needed regarding the structure of where the files should exist and what files I was most interested in. If I was looking to use log2timeline I could have stopped there, but I already have a license of NetAnalysis so I went to their site next.

Luckily for me in version 1.52 was announced in my inbox on 12/11/10 and now included Google Chrome support. So utilizing the information from the SANS blog I exported it to NetAnalysis for parsing and came up with all of the webmail usage I was expecting.

So the next time you don't find what you are expecting try my three steps and see if there is something you are missing.

If you know of a tool that supports Google Chrome histories besides log2timeline and NetAnalysis please comment or email with it.

Happy New Year and new Federal Civil Procedure Rules Year

Hello Readers,
Since I last so optimistically posted that I would resume blogging in 2010 I had no idea what the first year of a child's life meant for a new parent. I am making a commitment in 2011 to begin regularly posting again and I hope you will believe me and choose to follow along.

In 2010 news I did speak at HTCIA 2010 in Atlanta this year on forensic cases studies from some of G-C's greatest civil cases.

In 2011 news I will be speaking at CEIC 2011 http://www.ceicconference.com on outlook web access forensic analysis. I've been asked to make it a lab so if you are going to CEIC I hope you sign up and learn about what I've learned about OWA analysis in 2010 as it relates to Exchange 2003/2007/2010.

I plan to try to speak more often in 2011 so if your conference is looking for a speaker let me know.

In civil expert witness news I am very happy to join the chorus of other legal commentators to praise the change in the federal rules of civil procedure for expert disclosures. The rule took effect December 1, 2010.

You can read more about it here and here but the jist of it is that emails and drafts of documents exchanged between lawyers and experts is no longer discoverable unless it contains information regarding compensation or information that leads to an opinion. This will make mine my life considerably easier and I hope yours as well.

Subscribe to: Posts ( Atom )

Top Posts/Right Now