Graphics files stored on a computer can T be recovered after they are deleted

File Carving

In most investigations, the very first place a file system examination begins is with live files. Live files are those files that still have MFT entries. Link file, trash bin, Outlook Temporary (OLK) folders, recent items, ISO lists, Internet history, TIF, and thumb databases all constitute a discernible, unique pattern of user activity. As such, they hold particular interest. By exploring these files an examiner can make determinations about file origins, the usage of files, the distribution of files, and of course the current location of the files. But sometimes the subject has been very clever and removed all traces of activity. Or the suspect item may be a server, used merely as a repository for the files. Or maybe someone just wants to recover a file that they deleted a long, long time ago (see sidebar, “Oops, Did I Delete That?”).

When such need arises, the vast graveyard called the unallocated clusters could hold the last hope that the file can be recovered. By searching the unallocated clusters using a search tool designed for such things, and by using a known keyword in the file, one may locate the portion within the unallocated clusters where a file used to reside. Typically, search hits will be stored under a tab or in a particular area of the forensic toolset, and they may be browsed, one by one, along with a small excerpt from the surrounding bits. By clicking on the search hit, another pane of the software window may show a more expanded view of the hit location. If it is a document, with text, then that is great and you may see other words that were also known to have been in the target file. Now, in TV shows like CSI, of course the document is always there, and by running some reverse 128-bit decrytion sequencer to an inverted 12-bit decryption sequencer that reloops the hashing algorithm through a 256-bit decompiler by rethreading it into a multiplexing file marker, they can just right click and say “export this” and the file will print out, even if it’s not even on the computer that is being examined and never was. (Yes, I made all that up.)

In the real world, more often than not we find that our examinations are spurred and motivated and wholly created by someone’s abject paranoia. In these cases, no amount of digging will ever create the evidence that they want to see. That leaves only creative use of time stamps on documents to attempt to create an aroma of guilt about the subject piece. Sometimes we find that even after rooting through 300 GB of unallocated clusters, leaving no stone unturned, the file just isn’t there. But sometimes, all pessimism aside, we find little bits and pieces of interesting things all salted around throughout the unallocated clusters.

The first place to turn is the automated carvers. By familiarizing ourselves with the hexadecimal patterns of file signatures (and I’ve provided a nice table for you here), we may view the hex of the unallocated clusters in a hex editor or in the hex pane of the examination tool. Or possibly we already know the type of file. Let’s say that we know the type of file because our client told us that they only use Word as their document editor. We scroll to the beginning of the section of text, which might look like this:

Figure sample file signature

From the text pane view of EnCase:

ÐϷࡱ᷷·············>···þÿ·········

From the Hex view:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4F 6F 70 73

21 20 20 44 69 64

20 49 20 64 65 6C 65 74 65 20 74 68 61 74 3F 0D 42 79

20 53 63 6F 74 74 20

52 2E 20 45 6C 6C 69 73 0D 73 65 6C 6C 69 73 40 75 73

2E 72 67 6C 2E 63 6F

6D 0D 0D 54 68 65 20 66 69 6C 65 20 69 73 20 67 6F 6E

65 2E 20 20 49 74 92

73 20 6E 6F 74 20 69 6E 20 74 68 65 20 72 65 63 79 63

6C 65 20 62 69 6E 2E

20 59 6F 75 92 76 65 20 64 6F 6E 65 20 61 20 63 6F 6D

70 6C 65 74 65 20 73

Scrolling down in the text pane, we then find the following:

···············Oops! Did I delete that? By Scott R. Ellis The file is gone. It’s not in the recycle bin. You’ve .......

By simply visually scanning the unallocated clusters, we can pick up where the file begins and, if the file signature isn’t in the provided list of signatures or if for some reason the carving scripts in the forensic software are incorrectly pulling files, they may need to be manually set up. Truly, for Word files, that is all you need to know. You need to be able to determine the end and the beginning of a file. Some software will ignore data in the file before and after the beginning and end of file signatures. This is true for many, many file types; I can’t tell you which ones because I haven’t tried them all. There are some file types that need a valid end-of-file (EOF) marker, but most don’t. However, if you don’t capture the true EOF (sensible marker or no), the file may look like garbage or all the original formatting will be scrambled or it won’t open. Some JPEG viewers (such as Adobe Photoshop) will throw an error if the EOF is not found. Others, such as Internet Explorer, won’t even notice. Here’s the trick—and it is a trick, and don’t let anyone tell you differently; they might not teach this in your average university cyber forensics class: Starting with the file signature, highlight as many of the unallocated clusters after the file signature that you think would possibly be big enough to hold the entire file size. Now double that, and export it as raw data. Give it a .DOC extension and open it in Word. Voilá! The file has been reconstructed. Word will know where the document ends and it will show you that document. If you happen to catch a few extra documents at the end, or a JPG or whatever, Word will ignore them and show only the first document.

Unless some sort of drastic “wiping action” has taken place, as in the use of a third-party utility to delete data, I have almost always found that a great deal of deleted data is immediately available in EnCase (forensic software) within 20–25 minutes after a hard disk image is mounted, simply by running “recover folders” and sitting back and waiting while it runs. This is especially true when the drive has not been used at all since the time the data was deleted. Preferably, counsel will have taken steps to ensure that this is the case when a computer is the prime subject of an investigation. Often this is not the case, however. Many attorneys, IT, and HR directors “poke around” for information all on their own.

It is conceivable that up to 80% of deleted data on a computer may be readily available, without the necessity of carving, for up to two or three years, as long as the computer hasn’t seen extreme use (large amounts of files, or large amounts of copying and moving of very large files) that could conceivably overwrite the data.

Even so, searching unallocated clusters for file types typically does not require the creation of an index. Depending on the size of the drive, it may take four or five hours for the carving process to complete, and it may or may not be entirely successful, depending on the type of files that are being carved. For example, MPEG videos do not carve well at all, but there are ways around that. DOC and XLS files usually carve out quite nicely.

Indexing is something that is done strictly for the purpose of searching massive amounts of files for large numbers of keywords. We rarely use EnCase to search for keywords; we have found it better to use Relativity, our review environment, to allow the people who are interested in the keywords to do the keyword searching themselves as they perform their review. Relativity is built on an SQL platform on which indexing is a known and stable technology.

In other words (as in the bottom line), spending 15 to 25 minutes with a drive, an experienced examiner can provide a very succinct answer as to how long it would take to provide the files that they want. And, very likely, the answer could be, “Another 30 minutes and it will be yours.” Including time to set up, extract, and copy to disk, if everything is in perfect order, two hours is the upper limit. This is based on the foundation that the deleted data they are looking for was deleted in the last couple of weeks of the use of the computer. If they need to go back more than a couple of months, an examiner may end up carving into the unallocated clusters to find “lost” files—these are files for which part of or all of the master file table entry has been obliterated and portions of the files themselves may be overwritten.

Carving is considered one of the consummate forensic skills. Regardless of the few shortcuts that exist, carving requires a deep, disk-level knowledge of how files are stored, and it requires a certain intuition that cannot be “book taught.” Examiners gain this talent from years of looking at raw disk data. Regardless, even the most efficient and skilled of carvers will turn to their automated carving tools. Two things that the carving tools excel at is carving out images and print spool files (EMFs). What are they really bad at? The tools I use don’t even begin to work properly to carve out email files. General regular program (GREP) searching doesn’t provide for branching logic, so you can’t locate a qualified email header, every single time, and capture the end of it. The best you can do is create your own script to carve out the emails. GREP does not allow for any sort of true logic that would be useful or even efficient at capturing something as complex as the many variations of email headers that exist, but it does allow for many alterations of a single search term to be formulated with a single expression. For example, the words house, housing, houses, and housed could all be searched for with a single statement such as “hous[(e)|(es)|(ing)|(ed)]”. GREP can be useful, but it is not really a shortcut. Each option added to a GREP statement doubles the length of time the search will take to run. Searching for house(s) has the same run time as two separate keywords for house and houses. It also allows for efficient pattern matching. For example, if you wanted to find all the phone numbers on a computer for three particular area codes, you could formulate a GREP expression like this. Using a test file and running the search each time, an expression can be built that finds phone numbers in any of three area codes:

(708)|(312)|(847) Checks for the three area codes [\(]?(708)|(312)|(847)[\-\)\.]? Checks for parentheses and other formatting

[\(]?(708)|(312)|(847)[\-\)\.]?###[\-\.]?#### Checks for the rest of the number

This statement will find any 10-digit string that is formatted like a phone number, as well as any 10-digit string that contains one of the three area codes. This last option, to check for any 10-digit number string, if run against an entire OS, will likely return numerous results that aren’t phone numbers. The question marks render the search for phone number formatting optional.

The following are the characters that are used to formulate a GREP expression. Typically, the best use of GREP is its ability to formulate pattern-matching searches. In GREP, the following symbols are used to formulate an expression:

. The period is a wildcard and means a space must be occupied by any character.

* The asterisk is a wildcard that means any character or no character. It will match multiple repetitions of the character as well.

? The character preceding the question mark must repeat 0 or 1 times. It provides instructions as to how to search for the character or grouping that precedes it.

+ This is like the question mark, only it must exist at least one or more times.

# Matches a number.

[·] Matches a list of characters. [hH]i matches hi and Hi (but not hHi!).

∧ This is a “not” and will exclude a part from a string.

[-] A range of characters such as (a-z) will find any single letter, a through z.

\ This will escape the standard GREP search symbols so that it may be included as part of the search. For example, a search string that has the (symbol in it (such as a phone number) needs to have the parentheses escaped so that the string can be included as part of the search.

| This is an “or.” See previous sample search for area codes.

\x Searches for the indicated hex string.

By preceding a hex character with \x marks the next two characters as hexadecimal characters. Using this to locate a known hex string is more efficient than relying on it to be interpreted from Unicode or UTF.

Most forensic applications have stock scripts included that can carve for you. Many of the popular cyber forensics applications can carve for you. They have scripted modules that will run, and all you have to do is select the signature you want and voilá, it carves it right out of the unallocated clusters for you. Sounds pretty slick, and it is slick—when it works. The problem is that some files, such as MPEG video, don’t have a set signature at the beginning and end of each file. So how can we carve them? Running an MPEG carver will make a mess. It’s a far better thing to do a “carve” by locating MPEG data, highlighting it, exporting it to a file, and giving it an MPEG extension.

Database Reconstruction

A disk that hosts an active database is a busy place. Again and again throughout this chapter, a single recurring theme will emerge: Data that have been overwritten cannot, by any conventionally known means, be recovered. If they could be, Kroll Ontrack and every other giant in the forensics business would be shouting this service from the rooftops and charging a premium price for it. Experimentally, accurate statistics on the amount of data that will be overwritten by the seemingly random action of a write head may be available, but most likely it functions by rules that are different for every system based on the amount of use, the size of the files, and the size of the unallocated clusters. Anecdotally, the formula goes something like this: The rules change under any given circumstances, but this story goes a long way toward telling how much data will be available:

On a server purposed with storing surveillance video, there are three physical HDs. Drive C serves as the operating system (OS) disk and program files disk; Drives E and F, 350 gigabytes (GB) each, serve as storage disks. When the remote DVR units synchronize each evening, every other file writes to every other disk of the two storage drives. Thirty-day-old files automatically get deleted by the synchronization tool.

After 8 months of use, the entire unallocated clusters of each drive, 115 GB on one drive and 123 GB on the other, are completely filled with Moving Picture Experts Group format (MPG) data. An additional 45 GB of archived deleted files is available to be recovered from each drive.

In this case, the database data were MPG movie files. In many databases, the data, the records (as the database indexes and grows and shrinks, and is compacted and optimized), will grow to populate the unallocated clusters. Database records found in the unallocated clusters are not an indicator of deleted records. Database records that exist in the unallocated clusters that do not exist in the live database are a sign of deleted records.

Lesson learned: Do not believe everything you see. Check it out and be sure. Get second, third, and fourth opinions when you are uncertain.

Control—Base-VMs

Analysis of the control Base-VM hard drives confirmed there was no data originally present relating to the Enron sample test data and Dropbox files. References were found for the term “Dropbox” in “index.dat” files, “msjint40.dll.mui,” “pagefile.sys,” and unallocated clusters. This should be borne in mind, as this indicates the presence of the keyword term “dropbox” on a hard drive does not necessarily indicate that Dropbox has been used. As is usual for a digital forensic examination, the context of a search result needs to be analyzed to determine the reason for a keyword match, rather than drawing a conclusion at face value of the presence of data. The control VMs in this case have shown that data matches will occur, even when user activity in relation to Dropbox has not been undertaken.

Reconstructing Cleared Browser History

It is possible to come across cleared browser histories during an investigation. The user could have deliberately deleted the files to hide their web browsing activity or a malware could have removed its traces to avoid detection and analysis. Nevertheless, an investigator will look into various locations on the suspect system to locate the deleted browser history files. The possible locations are unallocated clusters; cluster slack, page files, system files, hibernation files, and system restore points. Using AccessData's FTK Imager on the suspect drive or drive image, an investigator could promptly locate the orphaned files and see if the browser files are present there. The next step would be to use the FTK Imager to look at the unallocated spaces, which should end up being a time-consuming analysis as seen in Fig. 41.7. If the drive has not been used too much, an investigator has a high chance of locating the files in the unallocated space.

Reconstructing Cleared Browser History

It is possible to come across cleared browser histories during an investigation. The user could have deliberately deleted the files to hide their Web browsing activity, or a malware could have removed its traces to avoid detection and analysis. Nevertheless, an investigator will look into various locations on the suspect system to locate the deleted browser history files. The possible locations are unallocated clusters, cluster slack, page files, system files, hibernation files, and systems restore points. Using AccessData’s FTK Imager on the suspect drive or drive image, an investigator can promptly locate the orphaned files and see if the browser files are present there. The next step would be to use the FTK Imager to look at the unallocated spaces, which should end up being a time-consuming analysis as seen in Figure 10.7. If the drive has not been used too much, an investigator has a high chance of locating the files in the unallocated space.

Identify and Use Built-in Security Features of the Operating System and Applications

Many organizations and systems administrators state that they cannot create a secure organization because they have limited resources and simply do not have the funds to purchase robust security tools. This is a ridiculous approach to security because all operating systems and many applications include security mechanisms that require no organizational resources other than time to identify and configure these tools. For Microsoft Windows operating systems, a terrific resource is the online Microsoft TechNet Library.34 Under the Solutions Accelerators link, you can find security resources for all recent Microsoft products. An example of the tools available is the Microsoft Security Compliance Manager. Fig. 2.3 shows the initial screen for this product.

TechNet is a great resource and can provide insight into managing numerous security issues, from Microsoft Office 2007 to security risk management. These documents can assist in implementing the built-in security features of Microsoft Windows products. Assistance is needed in identifying many of these capabilities because they are often hidden from view and are turned off by default.

One of the biggest current concerns in an organization is data leaks, which are ways in which confidential information can leave an organization despite robust perimeter security. As mentioned previously, USB flash drives are one cause of data leaks; another is the recovery of data found in the unallocated clusters of a computer's hard drive. Unallocated clusters, or free space, as it is commonly called, is the area of a hard drive where the operating system and applications dump their artifacts or residual data. Although these data are not viewable through the graphical user interface (GUI), the data can easily be identified (and sometimes recovered) using a hex editor such as WinHex35 or one of several commercially available computer forensics programs. Fig. 2.4 shows the contents of unallocated clusters being displayed by EnCase Forensic.

If a computer is stolen or donated, it is possible that someone could access the data located in unallocated clusters. For this reason, many people struggle to find an appropriate “disk-scrubbing” utility. Many such commercial utilities exist, but one is built into Microsoft Windows operating systems. The command-line program cipher.exe is designed to display or alter the encryption of directories (files) stored on new technology file system partitions. Few people know about this command; even fewer are familiar with the /w switch. Here is a description of the switch from the program's Help file:

Removes data from available unused disk space on the entire volume. If this option is chosen, all other options are ignored. The directory specified can be anywhere in a local volume. If it is a mount point or points to a directory in another volume, the data on that volume will be removed.

To use Cipher, click Start | and type cmd in the “Search Programs and Files” Bod. When the cmd.exe window opens, type cipher/w:folder, where folder is any folder in the volume that you want to clean, and then press Enter. Fig. 2.5 shows Cipher wiping a folder.

For more on secure file deletion issues, see the author's white paper in the SANS reading room, “Secure file deletion: Fact or fiction?”36

Another source of data leaks is the personal and editing information that can be associated with Microsoft Office files. In Microsoft Word 2003 you can configure the application to remove personal information on save and to warn you when you are about to print, share, or send a document containing tracked changes or comments.

To access this feature, within Word click Tools | Options and then click the Security tab. Toward the bottom of the security window you will notice the two options described previously. Simply select the options you want to use. Fig. 2.9 shows these options. Microsoft Office 2007 made this tool more robust and accessible. A separate tool called Document Inspector can be accessed by clicking the Microsoft Office button, pointing to Prepare Document, and then clicking Inspect Document. Then select the items you want to remove.

In Microsoft Office 2010, click on File, Info, and Check for Issues to open the “Document Inspector” Window.

Implementing a strong security posture often begins by making the login process more robust. This includes increasing the complexity of the login password. All passwords can be cracked given enough time and resources, but the more difficult you make cracking a password, the greater the possibility the asset the password protects will stay protected.

All operating systems have some mechanism to increase the complexity of passwords. In Microsoft Windows 7, the preceding can be accomplished thus:

Open Local Security Policy by clicking the Start button, typing secpol.msc into the Search box, and then clicking secpol. If you are prompted for an administrator password or confirmation, type the password or provide confirmation.

In the Navigation pane, double-click Account Policies, and then click Password Policy.

Double-click the item in the Policy list that you want to change.37

In the right-hand panel you can enable password complexity. Once this is enabled, passwords must contain at least three of the four following password groups35:

English uppercase characters (A through Z)

English lowercase characters (a through z)

Numerals (0–9)

Nonalphabetic characters (such as !, $, #, and %)

It is important to recognize that all operating systems have embedded tools to assist with security. They often require a little research to find, but the time spent in identifying them is less than the money spent on purchasing additional security products or recovering from a security breach.

Although not yet used by many corporations, Mac OS X has some robust security features, including FileVault, which provides the ability to create an encrypted disk, including external drives. Fig. 2.6 shows the security options for Mac OS X Lion.

How Magnetic Hard Drives Store Data

We need to understand how the computer stores your files. Computers store your data in defined spaces called sectors. Think of sectors as the smallest container a computer can use to store information. Each sector holds up to 512 bytes of data as illustrated in Figure 2.4. It can hold less, but it can't hold more.

While a sector is the smallest container of data, a computer's operating system only stores data as clusters. Clusters are comprised of multiple sectors. In this example our clusters contain four sectors. Each sector can hold up to 512 bytes of data, giving the clusters the storage capacity of 2048 bytes. See figure 2.5.

It's important to remember that computers write data to the drive in clusters. If the file is larger than a single cluster, the system assigns it an additional cluster even though a portion of that cluster may not be used. Let's work through a little hypothetical exercise to better illustrate this concept.

Suppose we save our master criminal plan to our hard drive. We'll call it “evidence1.doc”. It just so happens to be 2304 bytes in size. Since it's larger than our cluster size limit (2048 bytes) it's assigned to two separate, unallocated clusters (in this example, clusters 5245 and 5246). You'll also notice that our file only uses a portion of the first sector in the second cluster. Since the machine has to write 512 bytes at a time, it fills that leftover space with zeros. See figure 2.6.

What about the last three sectors in cluster 5246 that weren't used? The answer is nothing. As we'll see in just a bit, this system behavior can leave some evidence behind. See figure 2.7.)

After watching Abby and McGee work their magic on NCIS, we start to have second thoughts. We decide it's probably better not to have that file on our computer. So we hit the delete key, sending the “evidence1.doc” to the recycle bin. With a sly grin we empty the recycle bin, content in the belief that “evidence1.doc” is now residing in digital oblivion. But wait, not so fast. The problem for us as bad guys is that unbeknownst to us, our incriminating file is STILL on the drive. It will remain in those two clusters until it's been overwritten by another file. Given the size of today's dives, that could take a very, very long time. Using standard forensic tools, we can recover any part of the document that hasn't been overwritten. Figure 2.8 depicts our two clusters after the recycle bin has been emptied.

Now for some really cool forensic stuff. Even if the clusters containing our evidence are allocated to another file, all is not lost. It's still possible that we can extract a portion of the original file. Here's how it works. Two days later, we save another file to our drive. We'll call this one “evidence2.doc”. It's only 768 bytes in size so it only takes one cluster to hold it. The system sees that cluster 5245 is available and decides to put it there. Remember, evidence1.doc is still sitting in the cluster even though it's been “deleted”. The system writes “evidence2.doc” to the first sector and part of the second. It then does its normal thing and fills the remainder of that second sector with zeros. So what happens to the rest of evidence1.doc? When we first saved it, it took up all of cluster 5245. Our new file (evidence2.doc) has overwritten only PART of evidence1.doc. The remnants of evidence1.doc that sits in the last two sectors can be recovered! See figure 2.9.

To recap, the only the first 780 bytes of our original file have been overwritten. Some quick math tells us that there are still 244 bytes of our original file remaining. Those 244 remaining bytes comprise what's known as slack space. The slack space, depicted in figure 2.10, is the difference between the space that is assigned and the space that is actually used.

So, out of the slack space we can recover fragments of the previous file. It may not be useful. But then again, it just might. It could be part of an incriminating spreadsheet, email or picture. These fragments could contain just enough of an email to identify the sender or the senders IP address. A partial picture of the victim could link them to the suspect. Slack space can't be accessed by the user or the operating system. As such, this evidence exists unbeknownst to all but the most tech-savvy suspects.

Unfortunately, recovering evidence from slack space may very well become a thing of the past. We'll explore that bad news more in Chapter 11, “Looking Ahead: Challenges and Concerns.”