Hacking Exposed

by Aaron Philipp

  Recovering Complete Files in EnCase Using EnCase, you can either use EnScript or choose portions of unallocated space manually to export out of the image and back on to your local hard drive.

  When using EnScript, you can either choose to write your own script or go to Guidance Software’s Web site and choose an EnScript script from the EnScript library. Here’s how to run an EnScript to recover complete files:

  1. Load your image into EnCase.

  2. Depending on the EnCase version, do one of the following:

  • In version 3, click the EnScript button.

  • In version 4, click View Scripts.

  • In version 6, under Tools, click Case Processor, create a bookmark, and click Next.

  3. Select the appropriate EnScript script you want to run; we recommend File Finder.

  4. Click Run / Finish.

  Recovering files manually is covered in the sections “Recovering File Fragments in EnCase” and “Recovering File Fragments in SMART” a bit later in the chapter.

  Recovering Complete Files in SMART In SMART, you’ll find it easier to use the extended features of the searching interface to write out any complete files it finds automatically. Here’s how:

  1. Load the image in SMART.

  2. Right-click the image and choose Search.

  3. Right-click the empty space where search terms are stored, and do one of the following:

  • Choose one of the file types from the Term Library to have SMART automatically fill in the header and footer of the document you are seeking.

  • Choose Add New Term and define your own header and footer.

  4. Click Auto-Export.

  5. Choose where you want to save files by typing in a prefix and extension, as shown in Figure 6-10.

  6. Click Search, and as the search runs, the files will be recovered and stored in the location you defined in step 5.

  Searching for Relevant Data in the Unallocated Space

  You will need to search the entire disk to locate all relevant documents, logs, e-mails, and more in most of your cases. At times, though, you may want to find relevant data only in the unallocated space. To do so, you would search the unallocated space for keywords.

  Figure 6-10 Saving complete files in SMART to the hard disk

  This part of the process can be difficult because it’s a manual process; no automated method can be used to tell the tool the context or file type of the relevant data that you seek. You will have to locate what appears to be relevant data and then export it out of the tool of your choice to begin reconstructing it for review.

  Recovering File Fragments in EnCase To recover file fragments manually in EnCase, do the following:

  1. Create a new keyword, which will be the unique part of the header you are seeking.

  2. Search for that keyword across the physical disk.

  3. Review the hits and highlight the complete portions of the document that you would like to export out of EnCase.

  4. Right-click the highlighted text and choose Export, as shown in Figure 6-11.

  Figure 6-11 Exporting text from EnCase

  5. In the Export View dialog box, choose the name of the file and the directory to which you want to write it, and then click OK, as shown in Figure 6-12.

  The fragment now exists in the directory you chose.

  Recovering File Fragments in SMART To recover files manually in SMART, do the following:

  1. Load your image in SMART.

  2. Right-click Search.

  3. Right-click the empty area in the Search box and choose Add New Term.

  4. Enter the header of the type of document you are seeking.

  5. Search the image.

  6. Right-click a hit from the search and choose View Hit.

  7. Highlight and then right-click the text you want to view.

  8. Choose Selected Data | Export Data, as shown in Figure 6-13.

  9. Click Save Data To and indicate where you want to save the data.

  10. Click Export.

  The data now exists in the directory you chose in step 9.

  Figure 6-12 Selecting where to export text

  Figure 6-13 Choosing data to export

  Parsing the Unallocated Space

  Tools such as AccessData’s Forensic Tool Kit (FTK) allow an investigator to take an entire image and try to identify all of the documents in the file system, including the unallocated space. If you want to search the entire disk many times over, tools such as FTK can help you build a full-text index. Full-text indexing allows you to build a binary tree-based dictionary of all the words that exist in an image, and you can search the entire image for those words in seconds. For more information on full-text indexing and more tools that can accomplish this task, refer to Chapter 10.

  Limitations

  Although data recovery methods mean that recovery is possible, recovering deleted data has its limitations. Not every system will produce results. This can be caused by a number of reasons:

  • The system is newer and the user’s data was copied to it, leaving the forensic remnants you are looking for on the older disk. When a file system is restored to another disk using a utility such as ghost, it does not by default bring the deleted files or unallocated space with it.

  • A new hard drive could have been purchased and the data was copied to it.

  • The system could have been reinstalled, meaning that the FATs would have been overwritten and only the unallocated space would contain the deleted data you are seeking. This prevents you from recovering all of the deleted documents.

  • The user could have constantly run defragmentation tools. This would cause the earliest deleted data to be overwritten more quickly. This prevents you from recovering all the deleted documents.

  Drive-Wiping

  Another scenario, drive-wiping, involves overwriting every bit of the disk. Some tools in the market, such as PGP Wipe and BCWipe, allow a user to wipe out only the deleted, file slack, and unallocated portions of the disk. This type of wiping will eliminate most of the deleted and forensic data you are trying to recover. For a detailed review of wiping and all of the types of wiping you will encounter, refer to Chapter 9.

  Detecting Wiping

  Detecting when a disk has been wiped can be a manual task. You must check the image to determine the date back to which the deleted files extend and examine the unallocated space to see what data lies within it. Most wiping tools allow the user to choose the pattern that is used to write to the disk. Some tools will turn the entire unallocated space into 0’s or the alphabet. Most modern wipers will employ a more randomized scheme, usually following the US Department of Defense (DOD) specifications for secure wiping. If actual recoverable text cannot be viewed in the unallocated space, and if the sectors tend to look exactly the same, you can be pretty sure that wiping has occurred.

  In such a case, you should search the disk for wiping tools and review the user’s Internet history for accesses to Web sites that discuss or provide wiping tools as well as the program files directory and the registry. Many partial wiping tools are available today that are advertised as “system cleaners” or “Internet evidence eliminators.” These tools follow the same methodologies but are often not as thorough as a full disk wipe, as they are designed to target only certain files or locations and generally leave some evidence behind. Many evidence eliminator packages exist, and more are released every day; most of them share the same trait of any application in that they do not totally remove themselves upon being uninstalled. Finding them should be a matter of reviewing the programs installed on the system and reviewing the recently deleted files if your image was created soon after the program was uninstalled. Because the existence of a wiper is against policy at many companies today, you should check the relevant company’s policies if you locate a wiper.

  WINDOWS ARTIFACTS

  In the process of using Windows, many files are created, deleted, modified, and accessed. Some of these patterns or specifi
c types of changes are unique enough to allow us to say without doubt that a certain action has taken place. If you fail to determine whether or not these artifacts exist, you can wind up making incorrect conclusions or not being able to support your case argument. Windows artifacts can become key points in your investigations and often lead to the identification of key evidence. What we present here is not a comprehensive list of artifacts that can be covered in a Windows system, so make sure that you research other artifacts as you perform your own investigations.

  Emptying the Recycle Bin

  Most users empty the Recycle Bin often. Sometimes the files will wind up in the unallocated space, including much of the useful data you are hoping to find, such as the filename or where on the disk the file was stored.

  Recovering INFO Records

  Upon entering the Recycle Bin, a, INFO record (INFO2 for Windows 95 and later) is created for each file. The INFO record contains the path, the full filename, and the time when the file was deleted. Even after the Recycle Bin has been emptied, you can search for these INFO records to find all of the files that have been put in the bin. This is useful in cases in which certain named documents are alleged to have been misappropriated.

  Recovering INFO Records in EnCase

  Use the Info Record Finder EnScript that comes by default with EnCase to recover records.

  Here’s how to run an EnScript to recover INFO records:

  1. Load your image into EnCase.

  2. Depending on the EnCase version, do one of the following:

  • In version 3, click the EnScript button.

  • In version 4, click View Scripts.

  • In versions 5 and 6, click View and then EnScript.

  3. Select the Info Record Finder script. In versions 5 and 6, choose the Case Processor and choose the appropriate options.

  4. Click Run.

  The results will be stored in your bookmarks.

  Recovering INFO Records in SMART

  In SMART, you must create a custom search term in the term library. You would do so by adding this hex string:

  05 00 00 00 00 00 00 00 00 00 00 00 20 03

  The hex string will match the header of any INFO2 record, which will contain one entry for every file placed in the Recycle Bin.

  Recovering Data from the Pagefile

  The data that is created from processes that are active in memory do not exist in a structured file. Examples of data that is created by a running program includes the data created from copying a file from a floppy disk or a CD-ROM, or data created from loading a document from a removable hard drive. Instead of creating a structured file to store the data, it resides in memory.

  Understanding What Lies in the Page File

  The page file, pagefile.sys, is a single file used by the system as additional memory. Within this single file is a free-form block of data much like the unallocated space, except that it holds data that was written to it as a form of secondary memory called virtual memory. You can think of virtual memory as a block of specialized, unallocated space that has no structure. Not only is the data unstructured, but much of it is actually raw data that we typically cannot reconstruct. With experience and effective keywords, you can begin to determine what possibly could have created the data you see within it and begin to identify things such as chat sessions, e-mails, and web pages.

  Understanding the purpose of the page file is important, as many of the searches you perform in your investigation may show hits in it. Being able to view these hits and understand how they might have been created will help you determine whether a hit is something that came from a file access or whether it is a file that is being loaded into memory.

  Here’s an example of reconstruction of a page file that recovered the properties of an SSL certificate from a Web site that was visited:

  “ldap:///CN=cert.io.fiosinc.com, CN=cert, CN=CDP, CN=Public%20Key%20Services, CN=Services, CN=Configuration, DC=fiosinc, DC=com?certificateRevocationList? base?objectclass=cRLDistributionPoint0@ >

  Here’s an example of the recovery of the name of a document opened in Microsoft Word:

  SourceURL:file:///C:Documents%20and%20SettingsdcowenMy%20Documents personalbookforensics%20exposedContentchapter6chapter6.doc”

  Printer Spools

  Printing involves a spooling process that delays the data being sent to a printer. Print spooling is accomplished by creating temporary files that contain data to be printed and sufficient information to complete the print job. The two formats used to spool printing are RAW and EMF. Many times, documents that were deleted or accessed on external media will still exist in a printer spool file.

  Recovering Printed Documents

  The spool files that Windows creates are stored in a file in the Windows system folder, which varies on the version of Windows you are using: system32spoolprinters. The files that end with the extension .SPL are the image files—normally EMF, a Windows graphics file format. In Windows 95/98, you will find a .SPL file and a matching .SHD file that gives the name of the printer used, the name of the document, and the location of the temporary file that contains the image. If you find a printer spool, you can view its contents by loading it into an application that supports EMF.

  In Windows 2000, you must search the disk for a file that has this header, in hexadecimal notation:

  x01x00x00x00x18x17x00

  or

  x01x00x00x00xC4x36x00

  In Windows XP, you must search the disk for a file that has this header, in hexadecimal notation:

  x01x00x00x00x5Cx01x00

  If you are looking for printer spools on an NTFS file system, you may be out of luck. NTFS can create temporary files that are never committed to the disk and will not exist for later recovery.

  LNK Files

  For most documents and programs opened on Windows 95 and later systems, a LNK, or link file, will be created. This file contains the path of the file and the type of storage on which it existed, such as hard drives, network drives, or floppy drives. It also contains the file’s MAC times as well as the MAC times of its own that show when the LNK file was created. When you’re trying to re-create a suspect’s dealings with a document, as you would do when a suspect is accused of stealing a document, not reviewing LNK files can mean that you miss valuable evidence. For example, if a suspect accesses documents that were stored on external USB drives or on a CD-ROM, the only evidence left that shows where these files existed and how they were accessed is in the LNK file.

  Recovering LNK Files

  You will find LNK files in the active file system with the extension .LNK. Recovering all deleted LNK files in the unallocated space can be accomplished by searching the physical disk for the occurrence of the hex value 4C 00 00 00; this may turn up a large amount of false positive hits, however. Instead, it’s better to search for the name of the file that is in question. Remember that the LNK files contain the filename in either ASCII or Unicode, depending on the version of Windows, so make sure you are searching for both encodings. In addition, most forensic tools today provide libraries and scripts to find LNK files in the unallocated space for you; try these utilities first.

  ASCII is an 8-bit computer representation of a character that almost all computing systems can easily represent and write. Unicode is an extended character set that can use 16 bits to represent a single character. Windows now uses Unicode at the system level, so some Windows files created by the operating system may exist in Unicode instead of ASCII.

  For a thorough review of LNK file information, check out “The Windows Shortcut File Format” at www.i2s-lab.com/Papers/The_Windows_Shortcut_File_Format.pdf.

  Removable USB Storage Devices

  Identifying USB removable storage devices that were attached to a user’s system is often necessary for many investigations, especially those dealing with theft of intellectual property. You can determine the date/time when a device was last attached to the system and obtain the device’s vendor infor
mation such as make and model and other important values. These bits of evidence will be quite useful in aiding an investigation and in the device’s recovery, if necessary.

  How to Identify a USB Storage Device

  Whenever a USB storage device such as a CD ROM or ThumbDrive is attached to a Windows 2000 and later system, registry entries are created in the USBSTOR key located in the system registry. The first entry is the vendor key that contains the make, model, and revision information. The second entry is for the individual device itself; this keyname is located beneath the vendor key. Identical devices will appear under the same vendor key but will be identified by a different keyname. The keyname is generated by the Windows system and is unique. This unique name will stay the same between different windows systems.

  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Kingston&Prod_DataTraveler_2.0&Rev_1.00e

  If the registry viewer you are using does not provide the Last Write Time for the device, you should be able to right-click and export the registry key out as a text file instead of a registry file to obtain it. Remember that you will need the Last Write Time for the device, not the one for the vendor key.