Vestige Views

Not a week goes by that I am not talking with a client about some computer forensic matter when the conversation drifts into discussions of how data is deleted.  A few minutes later and the client says "well, I guess deleted isn't deleted".

Most of the public is familiar with that phrase.  They understand through newspaper articles, talking with the local IT expert, working with companies such as us and even watching TV that data can be recovered by those of us with the skills and know-how.

This article, however, illustrates how any of your data, no matter who keeps it and where they keep it, may not be deleted when you think it is.  In order for companies like Facebook, MySpace and others to recover from disasters they need to have backups or mirrors of your data.  Disasters can range from data loss, server crash or power outage to buildings destroyed by flood or other natural disasters.  The point is that your data is in multiple locations.

The data may not be kept just for backup purposes.  It also may be kept because the provider has regulatory requirements that necessitate the need to keep the data.  Maybe they are performing analytics on the data for future use.  These steps may be made known to you or they may not be.  Whatever the reason for keeping of the data, the fact remains is that it happens, quite often when one knowing.

When you request your data be deleted, you are relying that the provider is deleting any and all copies whether they be for analytic studies, backup or regulatory purposes.  Needless to say from the article referrenced, that doesn't always happen.  Maybe it is purposely kept.  Maybe it is accidentally kept because the provider isn't aware of all the places it keeps your data.

Logic would hold that this issue isn't just a Facebook problem.  Think about all of your cloud providers.  Whether you keep just your email, financial data or large sums of data in the cloud, chances are there are multiple copies of it up there.  Depending on who you talk to in customer service or tech support, they may not even be aware of it.  I recall working on a client matter wherein I wanted access to certain logs.  I asked multiple times for these specific logs and was told by the provider that they did not keep these logs.  A few weeks later I brought the subject up again, only this time I found out that they did keep these logs (side note: unfortunately they didn't keep the logs for a long period of time so they claimed that they didn't have them from the time period I was looking for.  I bet if I inquired further, I may have found that story to be inaccurate).

So what can you do? 

1. Start with checking your contract with your provider.  This may be a written formal contract or it may be as simple as their terms of service.
2. Inquire at multiple levels.  Start with customer service, go to your sales contact, ask to speak to a support engineer.  Not only may you be surprised, you may surprise your provider with what you discover.

You may find out at the end of the day that you have more discoverable information in a case then you realized.  Quite often it may be helpful in proving your case but at the very least knowing this information will help you ward off spoliation claims.

All operating systems and file systems are not equal!  This especially is true when you compare a Mac system to a Windows system.  [Insert Apple commercial here]  I commonly come across examiners who try to apply Windows forensics facts when examining a Mac computer.  They get in trouble pretty fast! 

We oftentimes use the old Library card catalog system with our clients to explain how the deletion of files works on both Macintosh and Windows based computers.  The card catalog in a typical library system contains the book name, author, publisher and most importantly the location of the book in the library.  The Master File Table, or “MFT”, is the card catalog equivalent in the Windows computer world.  The “MFT” contains the location of a file, when it was created, modified, accessed, etc.  The “book” in the card catalog system is a file.  When a file is deleted within a Windows computer, a special designation is made in the “MFT” keeping track of the deletion.  No, the “librarian” does not take the “book” off the shelf and throw it away, burn it or even rip out pages.  Once you hit the delete key, the file is still fully recoverable until a new file is put in the space where the old file existed.  There is no way to predict when this will occur.  If that special designation is removed from the file, the file is fully recoverable! 

In the Mac World, the card catalog is the “iNode”.  (Commonly known as “Index Node” or “Identification Node”)  Here is one instance where misinterpretation of artifacts commonly occurs.  Once the delete key is hit on a Mac system, a permanent separation occurs between the “iNode” entry and the file itself.  There is no longer any association between the metadata of a file and the file itself!  Many tools claim to be able to recover this information fully, but this is irresponsible and incorrect!  To make matters worse, the “iNode” entries are quickly compressed therefore permanently removing the “card catalogs” from the Mac Operating system!  Now you may ask, what happened to the book then when the card in the card catalog is gone?   The entire book is still available, but you have to search the library to find it!  A process called “carving” is utilized to find the file in the “sea of books” on the hard drive.  The “iNode” information is no longer available.

One of the most common misinterpretations of Mac artifacts occurs in the interpretation of dates within a Mac computer system. The first order of business as computer forensic examiners is to decide what type of file systems are we dealing with on the computers we are examining and to understand their differences.  For example, within the Windows world the NTFS file system “create” date of a file is when the file came into existence on a volume.  Why did I say it that way?  Well, let’s say that you received an email from your significant other today and it contained a picture of the family pet that was taken when you first adopted them.  It has been a number of years since you adopted the pet, but you wanted the daily reminder of how cute they used to be so you download it to your Windows computer.  The picture was taken a number of years ago, but the create date on the NTFS volume is recorded as the date and time you downloaded the picture which was today.

Let’ say that your significant other, who uses a Mac computer, is worried that the picture they took a year ago would be lost forever so they decided to make a backup of the picture that is located on their Mac which has an HFS+ partition.  They buy a hard drive that is formatted HFS+, which is one of the common file systems supported by a Mac operating system.   They copy the pictures to this backup hard drive.  The “create” date of the picture on the backup would not be the date and time this most recent copied occurred, but when the picture was originally transferred to the Mac from the digital camera years ago!

The analysis of various file systems can get pretty tricky, but with an understanding of how different file systems work and thorough testing you can avoid a lot of headaches!

At one of our recent Tech Meetings (some background, we have bi-weekly 30-60 minute Tech Meetings at Vestige where we have some training on a topic, it is part of our continuing education program) I presented on LogParser (http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx). It is a free tool from Microsoft and is very handy for parsing event logs, web server logs and traversing file systems to get directory listings.

It is a command line driven application that uses SQL syntax for pulling various fields out of different objects and then outputting the data to another format. CSV is my favorite output format because then I can bring it into my database of choice. Sure, I can write a DTS in SQL Server for a specific input file type, but why reinvent the wheel?

For those of you that are dismayed over the fact that GSI removed the reporting of the record number from their Event Log Parser script, LogParser will pull that information from the event logs. If you get the standard "event log is corrupt" message, I recommend FixEvt (http://murphey.org/fixevt.html).

For those of you that have to parse through gigs and gigs of IIS log files, you can use LogParser to just pull out just those records you are interested in. Maybe you just want the 400s or 500s or maybe you are just looking for records from certain IP addresses. You can also create charts as an output which is great for presentations or to look analytically at say the most viewed webpages on the site in question.

What I really like using LogParser for is traversing file systems. You can recurse or not through a specific folder structure and you can grab data such as filenames, full path, MAC dates, attributes and even some of the internal metadata that is displayed when you right click on a file in Explorer and click on "Properties". You can also calculate MD5 hashes for each file. Neat, huh?

In testing, I found that even when you are calculating the MD5 hash on a file, the last access date is not modified. However, when traversing folders for information, the last access date of a folder is modified. Ah, but that is where someone got smart and provided a "preserveLastAccTime" parameter for LogParser. Set it to "On" and none of that data is altered. There is also another parameter that allows you to capture the MAC dates in UTC time. So here is another good option for collecting files from a computer if you cannot image it (such as in the case of a server that the owner does not want shut down).

There is an install package for the application, but all that does is copy files to a folder on your computer. You can copy that folder structure to a CD/DVD or USB drive and then plug it into the computer you are collecting from and not have to run any installation routine. There is also a DLL that you can access from VB, C++, C# or the programming tool of your choice. Some people have already done that and there are GUI wrappers available on the internet.

The help file is great, just enough information but not too much (like some Microsoft help files are known to do in my opinion). Did I say that this application is free?

A look at common business practices that result in less than ideal conditions for performing digital forensic examinations -- and a struggle to understand why organizations never have the resources to proactively protect their data, but remarkably find the resources to react to a breach of their system -- even when the reactive approach can easily be 10 to 20 times more expensive.