CEIC 2014

A little over a week ago I had the opportunity to attend Guidance Software's Computer and Enterprise Investigations Conference (CEIC). I attended a number of sessions including Field Triage and RAM Analysis, Defrag Forensics, Vehicle System Forensics, Examining Volume Shadow Copies, APT Attacks Exposed, and Advanced Decryption, but the two that stuck with me the most were Analysis & Correlation of Mac Logs and SSD Forensics.

I would definitely consider myself a Windows person with little experience with Mac. Sarah Edwards gave a great presentation on Analysis & Correlation of Mac Logs. The presentation touched upon where you could find basic logs, system logs, audit logs, volume information, network information, location data, user activity, backup data, software data, system information, printing data, temporal changes, and Bluetooth information. I now have a list of places to start when examining a Mac computer because of this presentation.

This year was my second time going to the SSD Forensics session. The presentation, presented by Jeff Hedlesky from Guidance Software, Chris Bross from DriveSavers, and David Sun and Leo Costello from S34A, explained some problems that arise with SSD. Problem 1 is that hashing is made more difficult with SSDs. When LBA is used to image a HDD it includes unallocated space, but with SSDs, the data that is in the LBA can change under certain situations. Below is a slide from the presentation that explains Problem 1. 

 Problem 1 Explanation

Problem 2 is that data is now in areas that have not previously existed such as the Overprovisioning area which is data moved outside of the LBA. Below is a slide from the presentation that explains Problem 2.

Problem 2 Explanation

This got me thinking about ReFS on a SSD. It has the possibility of being much more efficient with a SSD than a HDD and could have even been designed with SSDs in mind. I am saying this because of the way it deals with its file table. When changes are made to the drive, the file table is copied and the changes are added to it, and the old copy of the file table is pushed into unallocated space. In the case of SSD, TRIM would run and take care of the extra copies, but on a HDD they just stay there waiting to be overwritten. This of course would need to be tested with a SSD to confirm that ReFS runs properly on it and that it does in fact dispose of the extra file table copies.

Thank you Champlain College and Guidance Software for giving me the opportunity to attend CEIC.

Sources:
Analysis and Correlation of Mac Logs, by Sarah Edwards
CEIC 2014 Advancements in SSD Forensics, by Jeff Hedlesky, David Sun, Chris Bross, Leo Costello

Nearing the End of the ReFS Adventure

I am nearing the end of my semester and finishing up my Capstone project. I have made quite a bit of progress in discovering ReFS's structure and how it compares to NTFS. Below are my findings, including updates to the findings talked about in my post, File Tables in ReFS.

Findings:

• There is a file table like structure in ReFS that could be compared to NTFS. My last post, ReFS/NTFS Comparison, shows a comparison breakdown between the two file systems.

• The beginning of each table has MACE times associated with them. The created time for each of the tables is the same, which could indicated that the file was copied and then modified by the system to reflect new files being created or other changes.

• According to Microsoft, ADS is not supported in ReFS. While an alternate steam cannot be found on the system, if an ADS consists of text, the text can be found in the file table. If the text is too long for the file table, it will be pushed into unallocated space. An ADS consisting of a file or executable is not possible. When the command is run to make this type of ADS, the response is "The requested operation could not be completed due to a file system limitation."

•  ReFS is not bootable. This is an important fact because not being bootable means that it cannot be the only volume on a system. As of right now, ReFS drives are mainly going to be data storage devices such as drives found in servers. This is due to their resiliency and ability to house extremely large files.

•  Compared to NTFS there is the possibility for a significantly more slack space with ReFS. This is due to the file system defaulting to large cluster sizes. This allows for users to hide data in slack space, the space at the end of a file before the next cluster begins, and forensic examination tools do not always pick up on this.

 These findings will allow investigators to be aware of where data can be hidden on a ReFS drive and  allow them to manually parse the file system to find any necessary metadata. Future work such as analyzing RAM dumps, decoding metadata files, and continuing to parse the file table will be important in order to fully understand how ReFS works.

ReFS/NTFS Comparison

In my last post I talked about the ReFS file table. Here's a visual comparing ReFS to NTFS:

File Tables in ReFS

I recently discovered what could be considered a file table in ReFS. When searching for the file table I found a number of instances of the file table that looked very similar, but had minor differences and some of which were missing a few files in them. I was able to see in EnCase 7 that only one of these tables was actually in allocated space, the rest being in unallocated space. At first I wasn't sure why there would be multiple file tables that essentially showed the same files. After additional analysis I was able to see that the most recent file table, the one in allocated space, was the file table that had all the current files listed with the most up-to-date metadata. It seems that the beginning of each table has MACE times associated with them. The created time for each of the tables is the same which could indicated that the file was copied and then modified by the system to reflect new files being created or other changes. So far I have been able to determine that the file table includes the file name, MACE times, size of the file in bytes, and a pointer to the physical cluster location of the file.

The images below show an example of the MACE times from an entry in the unallocated space and updated table in allocated space. Both show the created time as being 1/30/14 4:28:44 UTC, but the unallocated space modified and accessed times show 1/30/14 4:46:19 UTC, while the allocated space times show 1/30/14 5:12:06 UTC. The changes to the file table could be used in a forensic investigation to show data that was once on the drive.

MACE times in unallocated space file table

MACE times in allocated space file table

The image below shows an example of a file table entry. The orange highlights the name of the file, Paragraph.txt. The blue highlights the MACE times for the file which are in Windows 64-bit Little Endian. The red highlights the file size in bytes. In this case the hex 80 04, stored in Little Endian, converts to 1,152 bytes. The green highlights the hex, also in Little Endian, that points to the starting cluster of the file. In this case 70 03 converts to cluster 880.

File Table Entry Example

The ReFS Forensics Adventure Continues

Over the past few months I have been attempting to understand ReFS. This post will outline what I have done with the project so far and what discoveries I have made.

Methods:

In order to investigate how ReFS works, I had to be able to work with the file system.  I did this by creating a Windows Server 2012 R2 Datacenter virtual machine and made multiple virtual hard drives 10GB and 1GB in size.  I attached these virtual drives to my virtual machine, and formatted them ReFS and NTFS.  Two of the drives, one ReFS and one NTFS, were used for comparisons. This means that the data generated was the same on each of them. Additional drives were used to get a more in depth look at ReFS. Data was created on these drives by creating files of various sizes and types, creating folders, creating links, deleting folders and files, and creating alternate data steams (ADS). After generating the data, I captured the RAM from the virtual machine and made images of the drives. These images were then used for analysis.

Sample ReFS Virtual Drive

Initial Findings:

• ReFS is not bootable. This was an expected result based on prior research and information posted on MSDN.
• According to Microsoft, Alternate Data Steams (ADS) are not supported in ReFS. I have found that this is not necessarily true. An ADS consisting of text can be found in the hex.

ADS in ReFS

• Files only appear as deleted from a hex level when they have been emptied from the recycle bin, otherwise they can still be found in tact at the previous offset. Further research needs to be done to find out what makes these files not appear in Windows Explorer prior to the trash being emptied.
• ReFS has a 64k default allocation unit size (cluster size). When formatting the drive this cannot be changed like in other file systems such as NTFS or FAT.
• Timestamps are in same format as NTFS (Windows 64 bit Little Endian). 

An Introduction to the ReFS Forensics Adventure

This is my first post in a series of posts for my Digital Forensics Capstone. At Champlain College, each senior has the ability to chose one project and conduct cutting-edge research on it; I have chosen to do my project on Resilient File System (ReFS).

ReFS is a new file system, currently available in Windows Server 2012. The features of ReFS are said to include integrity, availability, scalability, compatibility, and proactive error identifications. The resiliency comes from its ability to survive even the most severe corruption.

I will be using a clean Windows Server 2012 virtual machine (VM) for this project. Inside this VM will be two virtual drives, one formatted as ReFS and one formatted as New Technology File System (NTFS). Additionally, I will use an external hard drive formatted as ReFS. I will image each drive using Forensic Toolkit (FTK) Imager Lite before making any changes to the drive. Once I have these baseline images I will add identical data to each of the drives and image them again.  This process will be repeated multiple times. I can then analyze these images to attempt to answer the research questions below.

Windows Server 2012: Main operating system being used for this project

The questions I would like to answer through my research include:

• What does the structure of ReFS look like?
• Are there any logs or file tables specific to ReFS?
• What actions cause the metadata of a file to change in ReFS?
• How does the metadata of a file on a ReFS volume compare to the metadata of a file on an NTFS volume?
• How does a file's metadata change when it is moved from NTFS to ReFS or ReFS to NTFS?

Sources:
MSDN: Resilient File System
Building the Next Generation File System for Windows: ReFS