Tuesday, February 28, 2012

The best feature you never knew existed

Bonjour Reader!,
I know I have large gaps in my blog posts, its not for a lack of ideas but it is for a lack of time. With the economic recovery in full swing in the legal world we are very busy.

However, I still need to finish my new book and start getting back to blogging more regularly so please feel free to harass me on twitter @hecfblog if I don't write a post once a week.

In this short post I am going to point out a feature in FTK that has existed since 3.3 atleast that I never knew existed. The feature is called 'export lnk contents' in ftk 3.3 and 'export LNK metdata' in ftk 4.0 and it may be the one feature that I wish existed in FTK for the last 8 years of using it. When I've mentioned what this feature is and what it does to fellow examiners each of them has said the same two things:

1. "Woh! This going to save me so much time!"
2. "Why didn't they tell everyone this was here?!"

So in relation to point number 2, let me do that for them.

HEY EVERYONE, FTK will now export out all of the metadata of a lnk file and the contents of the parsed lnks to a file (from atleast 3.2-4.0)!

It can do this with one, some or all LNK files just highlight them, right click a lnk and the context menu will show the option! Suddenly all the manual copy and pasting into a spreadsheet or running other tools (like tzworks lslnk) are no longer necessary. This is especially great when it comes to carved LNK files that may not actually be valid and break many third party tools when they try to parse them.

What all does it export you say?
Keep reading!

Surely there is no way they snuck in a feature everyone wanted and didn't tell anyone?
I sure didn't see it!

It must be missing something right?
Not that I can see! It exports out into a tab seperated file:
* Shortcut File - Name of the LNK file
* Local Path - The path to the file the LNK file is pointing to
* Volume Type - The type of volume (Fixed, Removable, CDROM) of the volume being accessed
* Volume Label - The volume label for the volume being accessed
* Volume Serial Number - The VSN of the volume being accessed
* Network Path - If this was done over the network, the full UNC path to the file
* Short Name - The 8.3 name of the file
* File Size - Size of the file in bytes
* Creation time (UTC) - When the file the LNK file is pointing to was created
* Last write time (UTC) - When the file the LNK file is pointing to was modified
* Last access time (UTC) - When the file the LNK file is pointing to was accessed
* Directory - If file the LNK file is ponting to is a directory
* Compressed - If file the LNK file is ponting to is compressed
* Encrypted - If file the LNK file is ponting to is encrypted
* Read-only - If file the LNK file is ponting to is marked read only
* Hidden - If file the LNK file is ponting to is marked hidden
* system - If file the LNK file is ponting to is marked as a system file
* Archive - If file the LNK file is ponting to is marked as to be archived
* Sparse - If file the LNK file is ponting to is 'sparse'
* Offline - If file the LNK file is ponting to is offline
* Temporary - If file the LNK file is ponting to is a ntfs temporary file
* Reparse point - If file the LNK file is ponting to is extended directory information
* Relative Path - The relative path to the LNK file
* Program arguments - Any arguements stored for the execution of the program
* Working directory - Where the executable will default for reads/writes without a path
* Icon - What icon is associated with the executable if any
* Comment - This is an outlook feature, not sure why its included
* NetBIOS name - The network names of the system the LNK file was accessing
* MAC address - The MAC of the system the LNK file was accessing

So the next time you are working a case in FTK and you want to know what was being accessed from external drives (and you are checking shell bags and other artifacts seperately of course) then make a filter for all file with the extension 'LNK' and right click on one and export all of them to TSV. Import that TSV into excel, sort by Local Path and your done! This may be one the biggest time savers I've found in FTK in years and I now use it on every case.

Have you found a feature you love that everyone seems to miss? Leave it in the comments below.

Saturday, December 3, 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.

Thursday, December 1, 2011

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 into speak at CEIC again and I'm looking for other conferences. Let me know if yours is looking for one!

Wednesday, May 18, 2011

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.

Tuesday, February 22, 2011

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

Friday, February 18, 2011

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.

Friday, February 11, 2011

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!