Wednesday, August 15, 2012

EnCase EnScript to verify LEF collection

I recently received an email from an old colleague Brian Olson. He wanted to share a recent EnScript he wrote and provide a detailed description in case others find it useful:

----------------------------------------------------------

One of the alternative methods of preserving digital evidence with EnCase is through an EnCase Logical Evidence File (LEF). Logical Evidence Files allow the examiner to preserve only the selected files from digital evidence, reducing the amount of data copied from a system while continuing to maintain the metadata and defensibility of the specific files preserved. 

LEFs are great alternatives in cases where a full disk image is not a viable option or it is not necessary to preserve the entire source device. Other EnCase products, such as eDiscovery and CyberSecurity rely on the LEF format to preserve digital evidence. Products like Symantec's Clearwell eDiscovery platform can process EnCase LEFs which helps maintain the file system metadata of the digital evidence from collection through processing and culling. An Examiner can also choose to use LEFs in situation where they are have large volume of data, such as a large file share, but only need to preserve a small portion of allocated data as evidence, like a specific user's home folder. Also, I find LEFs useful for extracting and transporting Malware, as AV will not try to clean a compressed LEF file. 

So what is a LEF and how does it work? LEFs differ from an EnCase Evidence File (E01) in that the LEF format only preserves the specific items identified by ether an Examiner or EnScript. When digital evidence is preserved into a LEF, each individual item can be MD5 HASHed and recorded. To further confuse the audience, LEFs can not only preserve files, but can also preserve data from other EnCase sources such as Records and Snapshots. For example, EnCase eDiscovery will preserve E-Mail from an e-mail source (i.e. Exchange) into a "Records LEF." 

However, there are some important things an examiner must understand about EnCase LEFs and their limitations. When EnCase preserves files into a LEF, only the allocated space of the selected files is preserved. This means the slack space or initialized space of the target files will be excluded from LEFs (possible with an EnScript?).

When EnCase verifies a LEF, it is validating the recorded MD5 HASH of each individual item with the items current HASH value, along with the CRC for each block in the LEF. There is no real HASH for the entire LEF, as we are used to seeing with full disk images. EnCase will report discrepancies through a dialog for CRC errors or by placing an astrik (*) next to the HASH in the entries pane for each item has a mismatched HASH.

Unfortunately, there is no report that an Examiner can export which explicitly says the items in a LEF passed verification and are valid. To assist with documenting the validity of of items preserved into LEFs, I've written an EnScript for verifying data collected in LEFs. The EnScript simply compares the MD5 hash of each individual file and records the results into a Date Stamped CSV file.

During the verification process, results are output to the console. A Final Report is including in the console upon completion of the job which details the specific LEFs that Passed / Failed verification.  Some known limitations of this EnScript is that it cannot verify EnCase Evidence Files (E01) or LEFs where the contents of files were excluded (Zero-Byte LEFs). 

Please send bug reports to dbrianolson (at) gmail.com

Download here (EnCase 6.18+)

1 comments:

johnmccash Tuesday, 21 August, 2012  

One irritating thing about LEFs is that unless you manually include the MFT or some portion thereof, you don't get most of the filesystem metadata for the file you're collecting.
John

Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles