Forensic Blogs

An aggregator for digital forensics blogs

April 30, 2020 by LCDI

Data Recovery Blog 3

Imaging Hard Drives

The data recovery team has been busy making disk images for the last couple of weeks and working with a variety of unique tools. The objective of our team is to test and determine the effective means of securely deleting data. Our investigation requires a set of samples to test our techniques and programs. The creation of disk images allows us to safely do this and inspect the data without risk. How clean can a hard drive be and what do these standards look like? 

What is a Disk Image?

In a world where 95% of people own a smartphone and 85% have a computer, disk images are the norm for digital forensics and criminal justice as a whole. A disk image is a collection of the data that’s stored on a device. Programs can load these files, to display the contains of the original source material. Some of these programs include GetDataBack and Wizard Partition Recovery. Sleuth Kits like FTK Imager can often produce disk images as well.

(From left to right) GetDataBack and Wizard Partition Recovery

Why Use Disk Images?

The most important piece of a case is the evidence that will solve it. The rise of technology has made computers the easiest way to store and send data. Thus, the evidence is mostly localized to a drive and its safety becomes of the utmost importance. Data recovered from a crime scene is volatile and extremely sensitive. Investigators cannot go into the device haphazardly or they run the risk of altering critical data. Altered data is unusable in court, thus data integrity and movement are heavily documented and preserved. However, in conjunction with other investigative devices, disk images allow users to access the data without risk of invalidating the evidence. They also allow an investigator to look through the data without the physical components, allowing easy access and transportation. Not only can disk images come from computers and hard drives, but also from phones and tablets.

The downside to disk images is that files are often quite large, but this depends on the size of the storage device they were made from. Compression usually mitigates this problem, but frequently, the disk images will keep the exact same size as the device being copied. This presents more problems, such as the amount of time it takes to create the file. The means of transportation also pose a problem unless there is another hard drive or cloud storage that is the same size or larger.

Benefits of File Hashing

Every detail of digital evidence is unique and valuable to digital forensic analysts and the law. Even an edit as small as changing a character then changing it back could make the data unusable in court. This is due to the creation of hash files and how they ensure validity. File hashing is the process of creating a code for a file that’s linked to the file itself. If any changes happen, including the opening, copying, pasting, or moving of a file, the hash value will change. This ensures the integrity of the evidence, even if there is no way someone could tell that a change had been made. This code is one way generated, meaning nothing can glean data from the code. Standalone programs found on the internet can generate this code. Integrating file hashing it into programs can generate this code while also completing some other function.

(From left to right) The program File Hasher in standby and File Hasher in progress

The program above is an example of a file hasher, aptly called “file hasher”. It takes the file from the user then generates a code based on the size and order of the characters in the file. This is how it ensures that there have been absolutely no changes to the order of the code. These changes can occur even when moving or copying the image.

The method of creating this code is not universal, and there are many types and methods of hash algorithms. The most popular are MD5 and SHA1, which generate a 40 digit long code. Other types of hash algorithms include RIPEMD, Whirlpool, and Blake, which all vary in the length of the code as well as the structure of the output. Though SHA1 is no longer considered safe for government use, it is still a very effective and safe method to ensure the safety of noncritical data.       

Write Blockers

As previously mentioned, the hash code changes for all interactions with it. That of course raises the question: How do you copy the data from the device without changing the hash code? The answer is a device called a write blocker, which allows the user to move or copy evidence from a hard drive onto a computer without changing the data. It does this by blocking commands from the computer that attempt to change the data on the device. This preserves integrity for the investigators and allows them to create the hard drive image. This only lets the user read and move the files. Write blockers do not prevent changes in computer data, though. This means data intentionally or unintentionally changed on the computer is still not viable.

Data recovery is the future of criminal justice and the better understanding we have of the technology used, the easier it is to understand what does and does not work. Data recovery programs allow easy access to data and allow the performance of digital investigations without a hitch. Write blockers may not always be a professional tool with limited public access. We believe the future will be more accustomed to these practices, making data easier and safer to store. To stay updated with the conclusion of our project, check out our Twitter, Instagram, and Facebook!

The post Data Recovery Blog 3 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

Read the original at: The Leahy Center for Digital Forensics & CybersecurityFiled Under: Digital Forensics, Uncategorized Tagged With: Blog Post, Data Recovery

April 30, 2020 by LCDI

Data Recovery Blog 2

Data on a screen, various numbers highlighted green, with a red open lock Data Is Not As “Deleted” As You Think

Here at The Leahy Center for Digital Forensics and Cybersecurity, the Data Recovery team has been hard at work searching through hard drives. These drives have been wiped using different methods in order to find any Personally Identifiable Information, or PII, that can be tied back to an individual.

At this point, ten out of the twenty eight drives purchased have been fully analyzed for the purposes of recovering data. Three drives, numbered 7, 9, and 10, all contained PII data. Drive 7 used the wiping method of DBAN, which stands for Darik’s Boot and Nuke, and is a free Linux utility. Drives 9 and 10 use the Xerase method, put forth by EPS. Both of these utilities claim to offer “secure absolute destruction”, yet how secure can they be if a team of analysts is able to recover data using tools that are freely available to the public?

The Recovery Process

For this project, we are using four “freeware” tools to recover data. These tools are SluethKit’s Autopsy, FTK Imager, Bulk Extractor, and Eric Zimmerman’s “bstrings” utility for Windows. Every drive that was purchased was run through all of these tools, not only to ensure visibility of data, but to determine if one tool has superior discovery abilities for deleted data. The tools are relatively simple to begin using, but require a bit of technical knowledge to become comfortable with. We have built a beginner-friendly user guide for how to start all four tools for acquisitions of data, which can be seen below.

Autopsy: Open Autopsy.  Fill out the stating form as needed.  Select “Add Data Source” –> “Unallocated Space Image File”.  Select the first piece of the drive. 

Wait for the image to finish scanning. This will take a while.

Bstrings: Open the command line in the folder in which you extracted bstrings. Type out the command to run it on a folder recursively to search an entire drive at once. Example:  bstrings.exe -d Disk Location > File Where Data Found Is Saved\bstrings.txt Adjust the conventions to match the image that you are working on. Bulk Extractor:  Point Bulk Extractor to the desired image Ex: HDD02.001, and a directory where you would like the output to go. Turn on all scanners by checking all of their boxes Press the ‘start bulk_extractor’ button to being the scan FTK Imager: Upload disk image from the F:\Drive into FTK Imager v3.4.0.5.  On the left hand side, click on the location i.e HD1, then select the file path (it will be the only option in the evidence tree).  Upon clicking, there will be a file list in the middle column, and a column full of text and UNICODE on the far right. This is where all of the data is.  Since there is no file system, the program pulls data haphazardly.  In FTK Imager, you can use “Ctrl + F” to search from strings, but be wary of what language you are searching in.  Select the “wrap” option as well, to ensure that if a string crosses more than one line, it will be recorded in the results. Analyze Which Data Recovery Tools Reign Supreme?

At the current point in the project, Autopsy is proving to be the most effective tool for data recovery. Autopsy has a very user friendly interface. This provides ease of access and lower frustrations when dealing with drives that have been wiped. Also, Autopsy is very thorough in the way that it searches, parsing through nearly every single file, and every bit of unallocated space. FTK Imager is a very good tool as well, yet does not have a very easy interface to work with. This is not what would be known as a “deal breaker”, but plays into our analysis as we spend a lot of time analyzing these drives, so ease of access is a crucial part. Bulk Extractor is a utility that runs off of command line, but has a GUI—or Graphical User Interface—to facilitate the process for those who are not comfortable with command line utilities. This tool runs the drive analysis as raw data, and finds everything that is on the drive, which is very helpful for data recovery. 

The last tool we have used is bstrings by Eric Zimmerman. Bstrings is a command line utility that only runs as such, making it a bit more difficult than the other tools to be comfortable with. It is ridiculously thorough, as it pulls anything and everything off of the drive that’s considered a string. However, due to CPU constraints, this tool does take the longest to fully finish, often over 24 hours. 

Image of a trophy with a 1 on it

Stay up to date with Twitter, Instagram, and Facebook by following @ChampForensics so you always know what we’re up to!

The post Data Recovery Blog 2 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

Read the original at: The Leahy Center for Digital Forensics & CybersecurityFiled Under: Digital Forensics, Uncategorized Tagged With: Data Recovery, Digital forensics, Exploration Forensics, Internship, Projects, Student Work, Students, Update

April 30, 2020 by LCDI

Application Analysis Blog 2

Application Analysis Continued

On the Application Analysis team, we have been busy recovering data from deleted programs. Please refer to this link for our previous blog post and more information about what we do!

Google Drive

Since our last update, the team has been busy digging through Google Drive. While we found a lot of information, we also learned about some unknown features of the application. When a user starts the installation for Google Drive, the application creates a new folder. Also added is a syncing program to download and upload the files locally. This is important to be aware of because once one deletes a program, this local folder and all the files within are still available.  This is a good feature for user interface, even if it is at the cost of security. If the user has files on their drive and still need them offline, it provides easy access. The problem arises if the user wanted all traces of their google drive gone from their computer in a single deletion.  

In our experiment, we created test profiles and tested all of the capabilities of the application. Then, we investigated what information we could access after deleting the application from the computer.  The separate folder had all of the information that was linked and downloaded to Google Drive and its local folder. The problem with drive storage versus cloud storage is that anything that you have downloaded lacks the need for a user login and password.  In addition, the folder created during installation is shown under “Quick Access” even after deletion, making it easily visible to unwanted users.  

Introducing Axiom

When the team started investigating the evidence in Magnet Axiom (a commercial digital forensics investigation tool), the beneficial applications of this method became apparent. The deletion of the application doesn’t retain the Google user’s information (password, email, name, etc), but the URL to the Google document is.

Picture of analysis tool results for Google Drive

The link to the Google Drive is to the right under Evidence Information

All of the files that were stored under the “Google Drive” folder locally were accessible from Axiom. In addition, all files contained a link back to the drive that can be opened in browser.  When you go to open the file online links from Axiom to the Google Drive, unless you possess the login information, the rest of the information is safe.  In a way this ensures future data security, as any future iterations of files are not accessible after the deletion of the app unless the user is accessing it.  It is a bit of both worlds for accessibility and security, as expected from such a large and well-developed company.

Dropbox

The team has also spent time sifting through Dropbox data from a similarly structured experiment. After we loaded the virtual machine file into Axiom, we saw that the system stores all Dropbox-based files, even after deleting the program from the computer. 

Screenshot showing the dropbox files visible in Axiom

Screenshot showing the dropbox files visible in Axiom

Axiom processes a variety of information: when the user logged into the program, when they downloaded the default Dropbox files, the files/folders Dropbox stores and creates, when they were created, and the direct file paths of the files. 

Screenshot showing specific information about one of the Dropbox files

Screenshot showing specific information about one of the Dropbox files

The system Google implemented is still very much present in Dropbox.  The program created a folder in the file system locally that remained after the deletion of the application.  However, the information in the image above does not include a link back to Dropbox. If there was not a folder for the information, there would be very little distinguishing information within the files showing that Dropbox downloaded them. Dropbox however unlike Google, does not have its own format(Google Documents, Google Presentation, etc) or online application for documents and files, a factor which likely influenced this approach.

Conclusion

Considering the type of user interaction these services provide, this outcome is surprising, but not entirely difficult to understand. It is important information to anyone who may be trying to compromise your data. In order to rid your system of all the above information, the user will need to do it manually. It is clear to see that one can’t delete all of the information by uninstalling the desktop version of the program. 

In the coming weeks we will be investigating Steam. As the largest video game platform worldwide, it would need to keep its users’ data safe.  

We will be sure to let everyone know the verdict on our next Application Analysis blog!

Stay up to date with Twitter @ChampForensics, Instagram @ChampForensics, and Facebook @ChamplainLCDI so you always know what we’re up to!

 

The post Application Analysis Blog 2 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

Read the original at: The Leahy Center for Digital Forensics & CybersecurityFiled Under: Digital Forensics, Uncategorized Tagged With: application, Application Analysis, Data Recovery, Exploration Forensics, Internship, Magnet, Magnet Forensics, Projects, Senator Leahy Center for Digital Investigation, Student Work, Students, Update

  • 1
  • 2
  • 3
  • Next Page »

About

This site aggregates posts from various digital forensics blogs. Feel free to take a look around, and make sure to visit the original sites.

  • Contact
  • Aggregated Sites

Suggest a Site

Know of a site we should add? Enter it below

Sending

Jump to Category

All content is copyright the respective author(s)