Hacking Exposed Computer Forensics Blog

Back to Basics, CD and DVD basic forensics

2011-12-03T23:11:00.001-06:00

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!

2011-12-01T21:50:00.000-06:00

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!

CEIC 2011

2011-05-18T14:41:00.001-05:00

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

2011-02-22T15:49:00.000-06:00

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!

2011-02-18T10:07:00.000-06:00

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!

2011-02-11T18:22:00.003-06:00

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!

Read more »

What are you missing? AIX

2011-02-03T17:14:00.003-06:00

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

2011-01-19T18:31:00.008-06:00

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

2011-01-16T23:39:00.002-06:00

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?

2011-01-11T16:45:00.005-06:00

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

2011-01-05T15:17:00.003-06:00

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.

New Year New Post

2010-02-22T10:51:00.002-06:00

Hello everyone,
I'm still alive, sorry for the lapse in content for the last 6 months. The second edition of the book is out, we will be at the RSA conference doing a book signing next week so make sure to stop by and say hi.

I'll be finishing the current series today and then moving on to new topics.

I love ftk 2.2.1

2009-08-14T10:14:00.003-05:00

I am going to interrupt the series to just write a small love note to accessdata.

Dear FTK,
I know we've had some tough times together in the past. Me cussing at a crashed indexed, you not responding to my mouse clicks. There were times I thought we wouldn't last and that I would find someone else who would fulfill my needs. Then I saw the new you (FTK 2.2.1) and when I actually exported the emails from a indexed search into a recreated recursive directory path from the PST folder structure that it came from I held my breath. When I then saw that actual MSG files were contained in the right folders my heart skipped a beat. Then when I saw that the attachment was actually in place in the MSG ... I knew everything would work out.

Love,
G-C Partners, LLC

Seriously though, for those who didn't immediately get this joke alot of the forensic tools available to the market for the last 10 years have had some real gaps of functionality that made our lives torture. One of these most basic features missing was the ability to export an email found when reviewing an image in a forensic tool back to a msg or pst instead of just a text export or html export that wasn't even compliant to the rfc specifications needed for most tools to convert it. If we didn't have it in msg or pst most lawfirms and ediscovery firms could not process it.

FTK 2.2.1 has fixed that issue and for this my office will gain many, many hours of producivity back instead of running my very long process to reassemble the data from other tool outputs.

Back to the series in the next post, thanks for reading.

What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?

2009-08-08T23:10:00.004-05:00

Howdy Reader,

It's been quite some time since my last blog post, I apologize. Things have been pretty busy, apparently the recession/depression has really spurred civil crimes and I had a very nice vacation. In our last time together we discussed more detectable methods of how suspects remove data from their systems. I've left off the most common and lengthy portion of the post so I could give it the detail and supporting documentation it deserves. In this post we will finish the concept exploring method 3 in this post and 4-5 in the next. This series does focus on Microsoft windows systems as they are the most popular business system in use, I will write another linux or mac specific series at another time.

Method 3 – Copying data to an external drive

How did they take data from the system

The first step you should take in a windows system is examining the contents of the registry keys that track storage devices plugged into the system. Inside these registry keys located under the system registry file under the system control sets are at least three keys keeping track of three types of external storage devices:
1. USB Devices
USB storage devices have their information store under the USBSTOR key found under:
system\currentcontrolset\enum\usbstor
1. Firewire Devices
Firewire devices that are also storage devices can be found in the system registry under the system control set as well at:

System\currentcontrolset\enum\sbp2
1. eSATA Devices
eSATA devices that are plugged into the system can be found in the system registry under the system control as well at:

system\currentcontrolset\enum\ide

It's important to know that the type of eSATA enclosure (for instance I was testing with a Simpletech Prodive) will not appear in the IDE registry key. The type and serial number of the drive will appear in the registry but you will have no way to identify what enclosure the drive was in from the registry. Of course you can compare the drives in enclosure to find the right drive but if drafting a subpoena you will not be able to specify what enclosure the drive is in.
1. Responsive to all types of devices:
There are additional versions under the system key some of which are duplicates of currentcontrolset so make sure to check each one. Each controlset that is numbered such as controlset001 is a configuration state of the system that booted successfully at one time. The currentcontrolset points to the numbered controlset that was last booted from successfully.

An easy way to parse out these registry entries is with RegRipper which creates a nice text file with all the most useful parts of the registry for the forensic examiner but in its latest version does not include the sbp2 key but I'm sure it will be added soon.

There is one registry entry under these keys for each storage device that has been attached to the computer since it was first installed if these keys do not exist or are empty then someone has run a system cleaner as the key will only get created on the first attachment of a storage device except for IDE which will exist if their is an IDE drive in the system. Remember these entries are in the system registry so it applies to every user who has used the system. This means that if you have a multi user system you still will have to verify who plugged it in during the times and dates we find. These entries will contain digital cameras, thumb drives, external hard drives, ipods, cell phones, anything that provides some type of storage and will be accessed as a drive letter. Each entry will contain the parent id, the vendor id and what is marked as the serial number of the device. The serial number reported to windows is not always the serial number printed on the physical device and this varies by manufacturer so when requesting these devices in a subpoena or other form make sure to specify it 'as reported to Microsoft Windows'.

The last written date of the registry key for each device entry tells you the last time the device was plugged into the system. We can determine the first time the device was plugged into the system by searching for the device name we found in the USBSTOR/SBP2/IDE keys and searching for it in the setupapi.log file found in the 'windows' directory in windows xp and in the setupapi.dev.log located under 'windows\inf' in Vista.

To find out each additional time the device was plugged into the system we can look at the backed up copies of the system registry located in the restore points. For Windows XP this is located under the 'system volume information folder\rp'. There is a new version of regripper for restore point registry examination called ripxp that will run the ripper not only against the current registry file but also all the previous copies of it in the restore points.

Windows Vista restore points are renamed to "system restore" points and utilize the shadow copy service to make a separate volume where previous versions of files and system files are kept depending on the configuration and version of windows vista. You can use programs such as Shadow Explorer to access these volumes on a live system (or an image running in a vm) where you can browse the point in time back up of each partition on the system for the same registries. I have not found a forensic tool to date that can mount these shadow volumes in the way that shadow explorer can.
What did they take

If our suspect did not wipe the system clean of the information we now know all of the external devices they could have copied information to. Determining the extent of what they have copied on to these devices is not as well recorded by the system. There are several ways that a suspect may attempt to copy data to the external drive.
1. Backup programs
  There are a variety of backup programs a suspect can use. Some of them will come bundled with the external media and others are built into the operating system. We can determine what backup program the suspect ran from the techniques discussed in part 2. Once you've identified the software used a quick google should reveal what if any logging the software left behind. For instance in Carreker Corporation v. Cannon et al (4:06-cv-00175-RAS-DDB) we found the use of Dantz Retrospect which creates a log file for each of the backups performed logging the configuration, directories backed up, files backed up and total data copied for each backup done with the software.
2. Copy programs
  Some suspects will choose to use utilities such as robocopy or xxcopy to copy the data to external media. In those cases the techniques discussed in part 2 will help you identify what program they used and when they copied the data.
3. Standard copy and paste
  If our suspect copied the data to some external media with just a copy and paste or drag and drop there will be no record that I have found to date to reflect it.
  The next thing we have to determine is what they copied on to the external drive. There are two reliable methods generated by Windows automatically that can tell us what files and/or directories they accessed from the external media.
  1. LNK Files
  Windows shortcut or 'LNK' (pronounced link) files have been a standard feature of windows since windows 95. LNK files as most forensic examiners refer to them are created for a variety of reasons. What is most important to us for this method is that for files and directories opened in windows explorer a LNK file will be created in the users recent directory ('\documents and settings\user name\recent' in windows xp, '\users\user name\recent' in windows vista) and if a program such as Microsoft office is associated with the file then a second lnk file will be located in the program's own recent directory located in the application data directory. The LNK file in its normal usage allows a user to quickly access the file that it points to. We can examine the LNK files and see which of them show that the file or directory it points to existed on an external disk. For more information on LNK files read this or this. For a free utility that will parse these files and other try Windows File Analyzer (most forensic tools have this capability already either built in or through some provided script).
  
  The LNK file tells us many important facts about a file that it points to.
  1. The time the file was first accessed on this computer
    The created date of the LNK file will tell you the first time the file was accessed through windows explorer, this captures the first access to the file. If the modification date varies from the creation date then you have the last time the file was opened as well.
  2. The time the file was first created on the media it resides on
    The LNK file captures the creation, modification, access dates as well as the size of the file that it points to within the LNK file structure. This allows us to know the creation time of the file which reflects the first time the file was copied onto the media. We can then determine when the data our suspect has taken was first copied on to the media. We will only know this if the suspect accesses the files or directories after copying them to the disk.
  3. The name, type and volume serial number of the media the file resided on.
    Using this we can determine which files accessed came from external media and match it up to those devices we identified in this section.
  1. MRU
    Most Recently Used entries in the registry exist for multiple types of applications and windows components. They keep track of the last files opened by the user for that application but they only track the file opened and the date on which the file was opened. The only way to determine if the path where the file was opened was on external media is to check if the drive letter shown was not local to the system. You can easily pull out most MRUs with regripper.

At this point we can now determine what external devices were in use and what files we can determine were placed there. The last two methods to discuss are copying data to network locations and uploading data to file hosting websites.

Back in the US

2009-07-23T11:03:00.002-05:00

Hello everyone,
Sorry for the lack of new posts. I've been out of the country for work and vacation the last couple months but I'm back and ready to finish the series. In good news while onsite for two months I did run across a number of new OWA log format that I wrote some new parsers for that I will be posting soon.

What did they take when they left? Part 3 - Where did it go and what did they take?

2009-03-31T23:58:00.002-05:00

Howdy Reader,

In the prior posts in this series we've talked about how to determine if our suspect burned a CD and then what programs he ran before he left. In this post we will discuss ways our suspect could have taken out of the system and how we can find out what they took. There are several options available to someone who wants to take data depending on the environment they are in. They could burn a cd (which we talked about before), send out an email via their companies servers, send out an email via a webmail service, copy the data to a external drive, copy data to another network location or upload data to a web based file hosting service are the most common. Any combination of these methods can be used so we have two challenges:

We need to determine what method or methods they used to take data from the system
We need to determine what files they took using these methods

Method 1 – Email via corporate servers

How did they take data from the system

How we are able to recreate activities will depend on the email system they have in place. Typically a suspect using this method will be emailing files and forwarding messages to their personal account. The sophistication of the suspect is pretty low in this method but occasionally even these suspects will delete these messages. Every email system has its own particular quirks for the recovery and analysis of messages, enough so that we will have separate posts to deal with each one at a later date. In most cases if a user has deleted the email messages we have three sources of recovery:

Recovery of deleted messages from the local system

When an email is sent from a suspect's system it is typically saved in the local and possible the server side 'sent' box. How we recover the message depends on how much time has passed since the user deleted the message, what other activity has occurred on the system since that time and whether or not the user purposefully attempted to push the email out of the local email archive.

i. Messages recovered from the application database structure

Most email systems have an accompanying client side application (groupwise, outlook, notes) that store the emails they receive into a database like structure. Typically when these emails are deleted they remain within the database like structure until they are flushed out (such as using the outlook compact and repair function). Until that occurs then most of the major commercially available forensic tools (Paraben's email examiner, Encase Forensic, Forensic Toolkit) can recover these deleted messages if they support the file format. If you are looking for a free option you might try the steps outlined here but that could become quite burdensome if you have a large number of messages to recover.
ii. Messages recovered from the unallocated space
Depending on the email client used the data will either be in plain text in the unallocated space for easy carving or it may be stored in some binary format such as the case with deleted messages from most outlook pst's. Outlook pst's support a data encoding format known as outlook compressible encryption. When this data is pushed out of the pst structure either over time or through the operation of a compact and repair the message will then exist in the unallocated space but be encoded in OCE. The only tool I know of currently that can search for OCE data in the unallocated space is encase. However the temporary files made by Microsoft Word, which has been the default editor for emails inside of Outlook since at least 2003, are recoverable as plain or Unicode text in the unallocated space.
Recovery of deleted messages from the live server

Most email servers don't flush out emails from their database when the user deletes them. If you or your IT contact has administrative access to the email server you can ask them to recover recently deleted messages from the live server. In exchange there is what has been called a 'dumpster' functionality that will retain emails for a definable set of days (default of 14 I believe). In groupwise you can recover deleted messages using tools like network email examiner or the salvage utility. In lotus notes you could either check to see if the 'soft delete' option was set and for how long it will retain messages or again use commercial tools. There are not many (any?) open source or free tools for dealing with enterprise email server solutions.

If the email server has flushed out the message recovering the message from the unallocated space becomes more difficult since I don't know the encoding of the message. If you are dealing with a sendmail/imail server like Iplanet you can recover the messages in the unallocated space through regex searches for headers.
Recovery of deleted messages from backup

When all else fails you can go to backup, usually tape. Restore the email database for the relevant time intervals to hopefully capture the email it was not purged the same day it was deleted, not very typical. You can restore the tape with either the native software (netbackup, backupexec, arcserve, etc…) or with software that supports your tape format (Ontrack Powercontrols, Quest Recovery Manger for Exchange). Then you will need to access the email database either with the native email server in a recovery environment or with a tool that supports reading the database directly (network email examiner, Ontrack Powercontrols, Quest Recovery Manger for Exchange). Once you've done this you can see if the emails you are looking for exist. This is a very detailed topic on the variances of backup software for the forensic examiner and data available, I plan to make separate posts about each of the major backup formats and tape examination techniques.
What did they take

Now that we have the email messages we can see what was forwarded and attached to those messages to make a list of those files, email addresses and subject matters. In my job I have no knowledge of internal matters so I have to hand over this data to counsel so they can determine what that was sent to themselves contained relevant data.

Method 2 – Email via webmail

How did they take data from the system

The first step I would perform is examining the internet history of the user. If they did not clear out their internet history then you can look through it for webmail websites they have been visiting. The majority of webmail services are either free or in the case of a hosted website they own will be using a free webmail package (like squirrel mail). We can use these sites to get unique keywords they display in either the html source of the page or in the rendered page itself to identify specific pages of interest.

The nature of how we send and receive data to websites dictates what is and is not recoverable. We can recover pages they have viewed, such as the contents of a mailbox/folder . We can see messages received the form to write an email but not the email they wrote. So we can look for the most recent views of their inbox for emails they have sent to themselves with files attached. Many people have said that gmail no longer leaves cached emails for us to recover. This is not in fact true, the move to the ajax model means we no longer have a separate cached page for every email viewed, instead we have to look at the virtual memory (pagefile.sys in windows, the swap partition in unix based systems) to find these email remnants.
What did they take

Most webmail sites will separately make a pop up or page for attaching files and giving notification of successfully attached files. This is good for us as we can recover each notification page and make a list of what files they sent themselves. In addition some suspects are nice enough to open each email they forwarded to themselves to just make sure they got their files.

There are three more methods to detail, but I don't want to wait another day to get this up. To be continued in part 4.

What did they take when they left? Part 2 – Finding out what they ran before they left

2009-03-25T20:06:00.002-05:00

Hello Reader,

In Part 1 we discussed how to determine if a CD was burned. Knowing what application it was burned with and what other tools they ran before they left is also important.

User Assist

One way to determine this is with the user assist registry keys. Over the years since the user assist registry keys were first discovered (they were included in our windows analysis chapter in 2005) many people have realized the impact it can have on their case. The User Assistance functionality has existed since Windows 2000 and is a registry key divided into two parts that keeps track of recently used programs and files for the start menu.

The user assist registry key exists in each user's ntuser.dat under the key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

Of which there are multiple keys depending on the version of windows you are examining, two for windows 2000, xp, 2003 and three for windows vista, server 2008, under which you will find a count key that contains the actual data we are looking for. Entries are encoded in rot13 and if you are not using one the tools listed in this blog you will need to decode them yourself to read the entries.

There are multiple tools that support the user assist registry keys for analysis (Accessdata's registry viewer and Didier Stevens tool for instance) that will quickly allow you to see:

What program or file was accessed
How many times the program or file has been accessed through windows explorer
The last time the program or file was accessed through windows explorer

As a simple example, I use Microsoft Office a lot. In fact I write my blog posts in it as it can directly post them to blogger (hopefully catching all my typos). So a decoded user assist entry for Office in my registry looks like this:

"{75048700-EF1F-11D0-9888-006097DEACF9}","20","UEME_RUNPATH:C:\Program Files\Microsoft Office\Office12\WINWORD.EXE","","54","37","3/22/2009 9:25:59 PM"

This entry was found in:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}\Count

Decoding the entry section by section we see:

{75048700-EF1F-11D0-9888-006097DEACF9} - the registry key under user assist that this belongs to, data appears to be grouped into categories based on these id's.
20 – The index number this number increments as entries are added to this key. In this case this is the 20^th entry logged. If you have a program executed multiple times, such as my Word 2007 program, sorting by the index number will give you an idea of when it was first executed.
UEME_RUNPATH:C:\Program Files\Microsoft Office\Office12\WINWORD.EXE – This is two pieces of info combined into one:
1. UEME_RUNPATH – This is the prefix for all entries that will give you a full path to the program or file being accessed
2. C:\Program Files\Microsoft Office\Office12\WINWORD.EXE – this is the full path to the program or file executed
54 – This is the session, its use is still unknown
37 – This is the number of times the program has been executed
3/22/2009 9:25:59 PM – This is the last time the key was updated and should be the last time it was executed

Going through the user assist then allows us to find out what programs where being executed around the time that for instance a CD was burned. Sorting the entries for that time we can see what was being executed around that time. If there is no corresponding entry you may want to look at the restore points for backups of the ntuser.dat close to time of the burn to find the program executed.

If the user assist keys is missing two things could have occurred

The user disabled them, there will be a registry key created showing this if true.
The user has deleted them, this can be an indication of some type of 'cleaning' tool being run such as Crap Cleaner.

Now the user assist registry keys are not the only place to look for what programs have been executed. We don't want to rely solely on access times as they change so easily and don't prove that a program was actually executed. We want to focus on artifacts created because of an execution of which there are two other well documented sets of artifacts that show the actual execution of a program.

Shortcut/Lnk Files

Stored in several locations depending on its function LNK files so named because of the extension '.LNK' that is given to them. We will discuss LNK files in more detail in the next post as they are an extreme wealth of information but for the purposes of this post it can suffice to say that we can use LNK files to determine if a program was executed through it.

The start menu for each user stored from windows 2000 and on is under the user's profile directory (\documents and settings\<user>\start menu in xp and \users\<user>\start menu in vista and 2008) contains a LNK file for each of the files listed in the user's start menu when the click the start button. So each time a user loads a program through it the modified date of the LNK file will change to reflect it. This also applies to any other instance of the lnk file such as in the quick launch bar or on the desktop.

So for instance my Office 2007 LNK file in the start menu shows a created time of 11/24/2008 which is when I installed office 2007 on this computer. The modification date is 3/22/09 9:25pm which is the last time I used the LNK file to load up office 2007. You can see that the prefetch reference below says 9:26pm, it takes a couple second between the time I clicked the LNK and when the prefetch file gets created.

Prefetch Files

Stored in the \Windows\Prefetch directory there is one .pf file for each of a max of 128 programs and the last modified time is updated each time the program is executed. The Forensic Wiki has a nice write up on prefetch files. There are several tools out there for parsing prefect files, one that is free is part of the Windows File Analyzer program. If I were to analyze the prefetch file for Office 2007 I would see the following:

File name: WINWORD.EXE-6AC9169C.pf

Last loaded: 3/22/09 and 9:26PM

This is when I started writing this blog post, it's been a couple days of research catching up on old topics to see what people have figured out.

So the prefetch file is a third correlation point we can use to determine if and when a program has been executed.

Conclusion

So we now have three separate sources on a typical Windows system that we can use to determine what programs had been executed (the first and last times), when and how many times they have been executed. These are not the only places we can look for this information but they are three of the most reliable due to the nature of their creation and use. If you find that all of this data is missing then it becomes almost certain that either

The system is being reimaged each time it reboots/logs in (some public access terminals do this)
A cleaning/wiping tool has been run

I plan to make a post on how to determine what a user has wiped after this series but if a cleaning tool has not been run one or all of these sources will allow you to state for a fact what program was executed to:

Run a backup program (such as the ones that are packaged with some external hard drives like retrospect)
Burn a CD
Run an ftp program
Access some kind of archiving or copy tool

Which will then lead to the next question and our next post in the series : Part 3 - Where did it go and what did they take?

What did they take when they left? Part 1 - Detecting CD Burning

2009-03-19T23:41:00.005-05:00

Dear Reader,

We've been discussing server level analysis for the last couple posts but there is plenty to talk about on the desktop. This will be a multi part series discussing different artifacts that we can recover that give us provable facts regarding a user's activity. It is easy to speculate on actions based on speculative data such as access data or related files or dll's accessed on a system but it is always better to rely on a repeatable process that creates a specific artifact each time to explain a user's action.

We only do cases that either lead to civil litigation or are in the process of civil litigation (no criminal work). One of our most common requests is the question, before this employee left did they take any documents with them. There are several places on a system we check to determine if a user has taken a document from the system in some fashion (CD, USB Drive, Emailed out, printed, etc…) and in this post we will discuss how to determine if a user has burned a CD. If you are examining a Windows XP or Windows Server 2003 (I have not been able to test this on Vista or server 2008 yet) image then the system event log will contain eventids 7036 and 7035 as it was generated by the Service Control Manager and will contain in the description a string starting with The IMAPI CD-Burning Service. There will be one such set of entries showing the service starting and stopping on each reboot but any entry not close to a reboot will indicate that a CD is being burned from this system.

An example of a burning entry, yes my machine is named HOSS:

12/11/2008		3:04:13 PM	Service Control Manager	Information	None	7036	N/A
12/11/2008		3:04:13 PM	Service Control Manager	Information	None	7035	NT AUTHORITY\SYSTEM
12/11/2008		3:04:22 PM	Service Control Manager	Information	None	7036	N/A
HOSS	The IMAPI CD-Burning COM Service service entered the running state.
HOSS	The IMAPI CD-Burning COM Service service was successfully sent a start control.
HOSS	The IMAPI CD-Burning COM Service service entered the stopped state.

Sorry for the bad editing here, the full row will not fit in this blog template. The line starts with the date and then continues in the block below. There is one date for each of the IMAPI entries.

If those three entries are not part of a reboot/startup sequence then you have found a user burning a CD. These entries do not have to be in uninterrupted sequence as you see here, but there should be a start and a stop to show a successful burn. This is not just for CDs burned by Windows directly, third party applications will also call this service when burning a CD. You can estimate the size of the data burned to the disk by determining the number of minutes spent burning (the time between the start and stop of the service) multiplied by the write speed of the CDROM. This also applies to DVDs.

I will not discuss how to determine if a CD was accessed in this post as that is material for Part 2 – What was accessed from external drives.

Update: As per the comments below, more activities than just booting and burning will cause these event log entries to show up. I will be doing some more testing to find a better answer.

Blackberry Server Log Analysis

2009-03-13T23:38:00.002-05:00

Hello Reader,

To the end user the blackberry server is what their blackberries get their email from. But there are multiple methods of communication a blackberry is capable of relaying, logging and recovering by an informed investigator.

Email
SMS
Blackberry Messenger
PIN Messaging
Phone Call Log

The blackberry server will create the following type of logs in total:

ALRT - BES Alert
BBIM - BlackBerry Instant Messenger (4.1)
BBUA - BlackBerry User Administration Service (BRK)
CBCK - Backup Connector
CEXC - Exchange PIM Connector
CMNG - Management Connector
CTRL - BlackBerry Controller
DISP - BlackBerry Dispatcher
MAGT - BlackBerry Mailbox Agent (aka BlackBerry Messaging Agent)
MDAT - Mobile Data Services
MDSS - MDS Services (4.1)
MDSS-DISCOVERY - MDS Services (4.1)
POLC - Policy Service
ROUT - Router
SYNC - BlackBerry SyncServer
PhoneCallLog (4.1)
PINLog (4.1)
SMSLog (4.1)

(Thanks Wikipedia http://en.wikipedia.org/wiki/BlackBerry_Enterprise_Server)

Email – The blackberry server logs will store when a device connects to the server to pull email and delivers mail and other messages. When you are dealing with a time sensitive issue of did a message get received/sent/deleted from a blackberry these logs may be your best source of evidence if a enough time has passed to let the message be deleted from the blackberry device itself before imaging. Regarding imaging blackberry devices I personally use Paraben's device seizure (found here http://www.paraben-forensics.com/catalog/product_info.php?products_id=405) to do the device acquisition.
The MAGT log with a name like "<Blackberry server name>_MAGT_01_20090108_0001.txt" will be a listing of every action taking place regarding the delivery of messages/calendar items/etc.. to every blackberry communicating with the server. You will find them in multiple segments per day. This is the place to look if the timing of the delivery/deletion/forwarding of a message from a blackberry is at issue.
SMS – When configured to do so the blackberry server will log into a csv file the following fields:
"Name.ID,"Email Address","Type of Message","To","From","Callback Phone Number","Body","Send/Received Date","Server Log Date","Overall Message Status","Command","UID"
With a file name such as "SMSLog_20070927.csv" with one log being created per day.
The file is written out in utf16 so be aware of that if you to parse it out.

Blackberry Messenger – This is a blackberry IM program that according to my current research will not be logged on the server without creating an account to relay all the messages to. Without prior configuration the only way to recover these messages is from the device itself.

PIN Messaging – This is the PIN messaging log. PIN Messages are those messages sent between blackberries directly through the blackberry server directed to the PIN assigned to the blackberry by the server. By default the blackberry server will log into a csv the following fields:
"Name.ID,"PIN","Email Address","Type of Message","To","Cc","Bcc","From","Subject","Body","Send/Received Date","Server Log Date","Overall Message Status","Command","UID"
With a file name such as "PINLog_20070927.csv" with one log being created per day.
The file is written out in utf16 so be aware of that if you to parse it out. I'm writing a parser now to dump them all into a mysql database that I will post when I correct a weird multiline message that I've found. Special bonus it's a perl script that correctly handles utf16.

Phone Call Log – This is a log of all of the calls being made out of the blackberry devices, note this only applies to calls made on blackberries connected to this blackberry server. This includes missed calls, outgoing calls and incoming calls that I've seen to date. By default the blackberry server will log into a csv the following fields:
"Name.ID","Type of Call","Name","Phone Number","Start Date","Server Log Date","Elapsed Time","Memo","Command","UID"
With a file name such as "PhoneCallLog_20070927.csv" with one log being created per day.
The file is written out in utf16 so be aware of that if you to parse it out.

All of the CSV files will load into excel directly if you import them, otherwise if there is a large number of dates in question I would recommend parsing them into some kind of database so you can pull records by the user's name or PIN.

Depending in the current configuration of the blackberry server after the date in question or the changes you make to a server now in preparation (if you are internal) a large amount of responsive data that the user may not believe exists will be available to you. Don't expect your blackberry admin to be aware of this data existing but make sure to ask for a copy of the log director regardless.

When is powerpoint file not a powerpoint file?

2009-03-11T23:17:00.004-05:00

Dear Reader,

Today we will not discuss OWA again. Rather we will discuss a peculiar case of a temporary file that lead into a journey of discovery into Microsoft internals.

I was working a case Lockheed Martin v L-3, et al (6:05-cv-1580-Orl-31KRS), which has since settled, which involved amongst other things several files that were contained on a CDROM and accessed on a laptop. On this CDROM were lots of files and one of the issues in the case revolved around which if any of those files had been accessed on the laptop showing which information may have been exposed and/or transferred to the rest of the company.

So like a good computer forensic investigator I reviewed all of the recently used registry entries, the lnk files and the user assist records regarding any of the files known to have come from that CD. One of the files in particular had an extension of 'shs'. 'shs' files are scrap files made when a user is copy and pasting items such as powerpoint slides, in this case it was a powerpoint slide. So I found the entries referencing that this specific shs file, which when loaded into powerpoint is a single slide, was accessed on three occasions. At times corresponding to these accesses I found a temporary file on the desktop that contained keywords relevant to the case and appeared by content to be a powerpoint document but no matter what tool I used it would not open it. All of my file signature tools regarded the file as 'data' with no specific file type.

The opposing investigator had the system this CD was burned form and thus had one significant advantage over me, he knew that the temporary file was related to the scrap file contained on the CD. Sure enough when I renamed this temporary file that no tool regarded as anything to an extension of 'shs' it opened up right away in powerpoint revealing the same slide as contained in the shs file on the CDROM. This left the question, how did this file get created on desktop?

So I keep reiterating the CDROM for a reason, normally when temporary files are created in office documents they are created in the same directory as the file you are working with. When you are working on a file in a read only directory, like a CDROM, it will instead create the temporary file on the desktop. So mystery of why the file exists solved! We already knew the scrap file was accessed and now we have corresponding temporary files to show that on the desktop.

The opposing expert was not deterred so easily, he pointed out that the temporary file sh60.tmp had the numeric 60 in it meaning in his opinion that it had in fact been accessed many more times than 2 since the 60 is actual hex for 96 so he claimed it was accessed approximately 95 times. This would a very large amount of accesses for a single powerpoint slide no matter what the contents so I was skeptical. We did some research to determine what creates the temporary file and found out it was a shared Microsoft library that many, many applications use including the application of hotfixes and service packs. Each time a temporary file is created by anything that uses this shared temporary file library the counter is incremented thus explaining how we had such huge jumps between our temporary files left on the desktop and the discrepancy of the offset to the number of times the rest of the forensic artifacts showed the file being accessed.

So the morale of the story is, sometimes a temporary file isn't just a temporary file so be careful out there and always test your assumptions. In this case both myself for assuming the temporary file was just a temporary file and the opposing expert for assuming that nothing else would change the counter on the temporary file got to learn an important lesson.

Using OWA logs to make your civil case

2009-03-10T21:47:00.004-05:00

Hello Readers,

I will not be talking about OWA every time.

In our prior time together we discussed parsing OWA logs to determine who has been accessing someone else's account. For criminal prosecution (unauthorized access) or internal investigations this might be enough, but for investigations involving the civil court system you need to show that the information accessed and the time they accessed it corresponds to some claim such as tortuous interference.

The same OWA logs we looked at last time will allow you to do this, with some caveats. When you see a single entry to access an item such as:

" /exchange/USA/Attach/read.asp?obj=000000007C6A5AC4439BD948B2EDEC2B4701083907007DC649E6901ED711982E0002B3A2389C000000C0411400007DC649E6901ED711982E0002B3A2389C0000013340B20000&att=ATT-0-C9D9D5C63632DD439C1AF3C6A4B4AF8A-TOD9D1%7E1.PPT"

This is a request to open up an email attachment, the obj show here in the query is a unique identifier for the item within the exchange database. This means that if you replay that url while, and this is important, logged in as that user you will be able to bring up the exact same message that was viewed at that time (If it was not deleted). If you attempt to access this object while logged in as any other user it will deny you, even if you login as the administrator. If you want to make sure the messages exist (meaning not deleted) restore the exchange server from a backup tape referring to the time period the message we viewed and replay it to the restored server.

These are the following asp pages that can be called by an OWA user according to about two years worth of logs from one case I worked:

/exchange/USA/LogonFrm.asp

/exchange/USA/root.asp

/exchange/USA/Navbar/nbInbox.asp

/exchange/USA/inbox/main_fr.asp

/exchange/USA/inbox/peerfldr.asp

/exchange/USA/inbox/title.asp

/exchange/USA/inbox/messages.asp

/exchange/USA/inbox/commands.asp

/exchange/USA/forms/IPM/NOTE/frmRoot.asp

/exchange/USA/forms/IPM/NOTE/read.asp

/exchange/USA/logoff.asp

/exchange/USA/Attach/read.asp

/exchange/USA/logon.asp

/exchange/USA/forms/IPM/NOTE/commands.asp

/exchange/USA/forms/IPM/NOTE/cmpTitle.asp

/exchange/USA/forms/IPM/NOTE/cmpMsg.asp

/exchange/USA/errinbox.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/RESP/frmRoot.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/RESP/read.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/RESP/commands.asp

/exchange/USA/options/set.asp

/exchange/USA/calendar/main_fr.asp

/exchange/USA/calendar/title.asp

/exchange/USA/calendar/events.asp

/exchange/USA/calendar/appts.asp

/exchange/USA/calendar/pick.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/REQUEST/frmRoot.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/REQUEST/mrread.asp

/exchange/USA/forms/IPM/SCHEDULE/MEETING/REQUEST/commands.asp

/exchange/USA/contacts/main_fr.asp

/exchange/USA/contacts/title.asp

/exchange/USA/contacts/peerfldr.asp

/exchange/USA/contacts/messages.asp

/exchange/USA/contacts/commands.asp

/exchange/USA/finduser/root.asp

/exchange/USA/finduser/fumid.asp

/exchange/USA/finduser/fumsgdef.asp

/exchange/USA/finduser/fumsg.asp

/exchange/USA/finduser/details.asp

/exchange/USA/forms/REPORT/DR/frmRoot.asp

/exchange/USA/tshoot.asp

Of these we care about the following:

This is a user logging in - /exchange/USA/LogonFrm.asp

This is a user requesting to read a specific message - /exchange/USA/forms/IPM/NOTE/read.asp

This is a user opening an attachment - /exchange/USA/Attach/read.asp

This is a user composing a new message - /exchange/USA/forms/IPM/NOTE/cmpMsg.asp

This is a user reading a message request - /exchange/USA/forms/IPM/SCHEDULE/MEETING/REQUEST/mrread.asp

If you parsed our just these commands identified by the logged in user you could see what specific emails, meetings, and attachments a webmail user had viewed, created, sent using OWA and the time on which they did. Using these times and matching the ip address to the suspect you can then combine the information accessed, to the time it was accessed, to the benefit they received by having that information at that time.

As an example, in the case Exel Transporation Services Inc v. Total Transportation Services LLC et al (3:06-cv-00593) I used this to uncover a large industrial espionage case. First I used the program in the prior post to find which accounts were being used to access other email accounts in the system. Then I looked up the IP Addresses and found out one of them was actually registered to one of the ex-executives of exel directly on ARIN. We then broke out just the accesses used by those accounts (I mean really why else would the blackberry server administrative account or the voicemail server be logging into a website .. something we had to explain to counsel) into a database divided up by type of item accessed (email, attachment, calendar).

The next part was more difficult, we had to replicate their exchange network, AD controller, etc.. to restore their exchange server backups and replay those months to find out what our suspects were viewing. This included almost every decision maker within exel and according to the filings I read about $120 million dollars in lost business as they were able to read the contracts sent to customers during a bidding process and always beat them. We fed the urls into a GUI automation tool that would interact with the web browser and save the emails and attachments into MHT (full website archive) files for the lawyers review. I couldn't within the time frame get a pure perl program to work the way I needed it to.

For more information read this news article:

http://www.bizjournals.com/memphis/stories/2006/08/21/daily30.html

The case was settled out of court with a public apology written by TTS. The final stone in my understanding that led to settlement was when we matched the TTS OWA logs to the Exel OWA logs and showed the suspects logged into the TTS server with their real user name, with the same ip and at the same date/time, as they were logged into the Exel OWA server with their administrative accounts.

I hope this was useful, I can post parsers I wrote if you think it would help you in the future.

Outlook Web Access Log Analysis

2008-12-23T11:56:00.012-06:00

Hello Reader,
In this entry I’d like to discuss log analysis on Outlook Web Access servers. I’ve successfully used OWA log analysis in the past to quickly determine who has been reading mailboxes other than their own. Two pieces of information in the logs that exist by default in the OWA creation process allow this to occur. The first is that OWA uses NTLM authentication for web mail users who log in and the domain and username authenticated is stored in the logs in the cs-username field with format “domain\username”, remember this field will only be populated if the user successfully authenticated otherwise it will be filled with “-“. The second is that the mailbox accessed is stored in the cs-uri-query field in the logs and will look something like “isnewwindow=0&mailbox=username”. By comparing the authenticated NTLM username to the username of the mailbox requested we can write some pretty easy code to determine who has been accessing the mailboxes of other users, or attempting to.

First things first, we need the OWA logs themselves. They should be located in the “%systemroot%\system32\logfiles” directory usually in W3SVC1 if it’s the first default web created. Once we have them we need to either copy or export the log files in that directory from the image. Our first bit of code reads the content of the directory:

opendir(IMD, $dirtoget) die("Cannot open directory");
@thefiles=
readdir(IMD);
closedir(IMD);

foreach $file
(@thefiles)
{

print "my file: $file\n";
open(FILE, "$file");
}

Next we need to do something with these files. We want to parse each line looking for people accessing mailboxes:

while(FILEHANDLE)
{

if ($_ =~ m/^([0-9\-]+
[0-9:]+) ([0-9.]+) ([^ ]+) [^ ]+ [^ ]+ [0-9.]+
[0-9]+ (GETPOST) ([^ ]+)
isnewwindow=0&mailbox=([^ ]+) ([1-3][0-9][0-9]) [0-9] [0-9]+ [0-9]+
[0-
9]+ HTTP.+ [^ ]+ ([^ ]+) ([^ ]+) (.+)$/i)

{
my ($access, $ip, $username, $method, $url, $query,
$status,
$useragent, $cookie, $referer) = ($1, $2, $3, $4, $5, $6, $7, $8,
$9,
$10);
}

Next we want to see if the username they have authenticated with matches the username of the mailbox they have requested. If it does, move on and print a . to the screen so we can see some activity. If it does not print a ! to the screen and write the resulting access to a separate file.

if ($username !~ m/$query/i )

{

print OUTFILE "$access, $ip, $username, $query,
$status\n";

print "!";

}

else

{



print
".";

}

We can also store a unique list of these users in a hash so we can get a list of offenders to review. Additionally you could store all of this in a database table in larger cases so you can begin to run queries in time periods, users affected and start breaking out what messages, attachments, tasks and calendar items have been accessed.

I have posted the raw perl code and the windows compiled executable for this. For the windows executable I made it just search the same directory the executable is in, so just copy it into the directory with the logs and run it. Load up the report.csv file and find out who your suspects are.

Raw Code

Windows Executable

YACFB - Yet another computer forensics blog

2008-12-22T23:49:00.000-06:00

Hello readers,
after recently searching for new tools and techniques I found Harlan Carvey's blog and this blog. I had no idea outside of the Encase support forums, smart support forums, and local HTCIA groups that there was a discussion of new findings. I am one of the co-authors of Hacking Exposed: Computer Forensics (second edition is being written as we speak) and a partner at G-C Partners, LLC where I perform computer forensics services in civil litigation. I've been doing computer forensics for civil litigation since 1999 and I have built a repository of information and tools over the years that I hope will help others in the community to solve and document their own investigations.

I am a Dallas, Texas based Perl programmer, I have your books Harlan, a computer forensics examiner and a testifying expert of many years. I plan to fill this blog with tools, information, and case studies on closed litigation (I've been told discussing active litigation is frowned upon). I hope you find something useful and feel free to comment if you have questions.

My first real investigation in 1999 started when I was still primarily doing network security at Enstar Networking (now closed), and it involved a rogue ex-CTO who decided to install key loggers across the other executives systems to make sure his agenda got pushed forward. The investigation was not difficult as he did not expect anyone to seize his system and being well organized had folders made not only for the decrypted key logs that were being emailed to him but also for the receipts that included the key logger he purchased. What was interesting was the key logging itself was not a terminable offense, rather the letter to his parole officer in new york state was. Why? because he never disclosed that he had a class b felony to his employer nor did he disclose that he believed he overpaid his restitution as he wrote to his parole officer.

From this investigation I was introduced and asked to speak at our local high tech crime investigation association chapter and got introduced to the computer forensics community I didn't know existed.