Unveiling USB Artifacts: A Comparative Analysis

Introduction

Understanding USB artifacts is key for tracking user activities on files located in the USB. This blog delves into the artifacts generated in the USB device when files are accessed or modified, examining whether different operating systems, file systems, and applications used influence these artifacts.

Key discoveries in the blog

• USB formatted with NTFS, FAT32, and ExFAT often create temporary files, particularly during file modifications.
• USB formatted with NTFS on Windows provided more information on file system changes from the $Logfile due to its journaling capabilities.
• USB formatted with HFS+ stores versions of files that have been edited using applications with GUI in a versioning database “db.sqlite”, providing information on file_last_seen times.
• USB formatted with FAT32/ExFAT on MacOS generates “. _filename” files to ensure file system compatibility for storing of extended attributes. The creation and modification times of these files can indicate file tampering.

Who may find this blog interesting:

• Cybersecurity analysts and corporate security teams
• Cyber investigators
• Computer Emergency Response Teams (CERT)

Methodology

To comprehensively analyze USB artifacts, a series of tests were conducted across multiple environments, as described below.

Test Setup

A SanDisk 32GB USB flash drive (commonly known as a thumb drive) was used for this research and the test was conducted across three different operating systems – Linux (Kali Linux v6.6.9, 2024.1), Windows 11, macOS (Sonoma v14.2.1).

Note that given the variety of Linux distributions, this research focused on Kali Linux. Other distributions may yield different results than those discussed in this blog.

For each operating system, the USB was formatted with different file systems and populated with files of various types.

Files types include, but are not limited to: .pptx, .csv, .xlsx, .key, .numbers, .txt, .py, .java, .html,  .docx, .odt, etc.

Test Cases

Two scenarios were tested for each operating system and USB file system combinations:

• Test case 1 (TC1): Open and close a file without making modifications.
• Test case 2 (TC2): Open, modify (write to), and close a file.

Below is a list of common applications selected from each operating system used to conduct the research:

Table 1 – Applications used for the test for each operating system

Analysis

Following each test, logical drive images (E01) of the USB drive were captured using FTK Imager (v 4.5.0.3) and analyzed with both Axiom v7.5.0 and Autopsy v4.21.0 forensic tools to examine and understand the artifacts left behind. Note that the mention of tools is solely for transparency in our methodology and is not intended as an advertisement or endorsement.

Key Findings

Main Artifacts Observed – Temporary files

Based on the research results from various tests, the creation of temporary files was commonly observed when the files were opened or edited. These temporary files often have distinct naming conventions, such as ~$filename, .~lock.filename, filename.<ext>.swp, and others. Typically, these files are automatically deleted once the file is closed, requiring data recovery tools to carve them out and examine their contents.

Figure 1 – Temporary files carved from the USB logical image

Every time a file is opened and closed, a new temporary file is created. This behavior is as illustrated in Figure 2 and 3.

Figure 2 – Opening of the same file multiple times with LibreOffice Draw creates multiple temporary files

Figure 3 – Modifying the file multiple times with Nano creates multiple temporary files

Application-Specific Behavior

Since different applications handle file operations in varied ways, it was observed to have a significant influence over how artifacts were created. Here are three key observations:

1. Most applications tested do not create temporary files.
2. Some applications create a copy of the original file, with modifications written to this copy. When saved, the copy is renamed as the original file. This behavior was reflected in the NTFS $Logfile transactional records:
   

   Figure 4- NTFS $Logfile transactional records

3. Temporary file creation varies by applications. Some examples include:
   • Notepad++, Sublime, VSCode: Do not create temporary files even when tested with various file types (.txt, .log, .html, .css, etc.).
   • MS Word, Photos (Windows Default Image Viewer): Generates temporary files only when files are modified.
   • MS Excel, MS PowerPoint, LibreOffice: Creates temporary files when files are opened or modified.
4. Information found in temporary files created by different applications were observed to be different.

Temporary files generated by different applications contain varying information. For example, ~$filename created by Microsoft Excel and PowerPoint contained only the username of the person who opened the file. In contrast, opening the same file using LibreOffice creates .~lock.filename, which contains information such as hostname, username, and date timestamp of when the temporary file was created.

Figure 5 – Username recorded “~$test_excel.xlsx” carved file

Figure 6 – Hostname, username, and temporary file creation date timestamp recorded in .~lock.filename

Files opened using Nano and Vim in the Kali Linux operating system also recorded application version, hostname, username, and file name in .filename.swp, as shown in Figure 7. 

Figure 7 – Application version, username, hostname, and filename recorded in .filename.swp

Some temporary files lack identifying information about the user who opened or edited the file. In such cases, only the access time (derived from the creation or modification date of temporary files) can be used to estimate when the file was accessed.

File System and Available Artifacts

The information that can also be useful for analysis was observed to differ between the various file systems of the USB.

Windows

• FAT32 and ExFAT: Temporary files were commonly created (subjected to the applications used) when  files were accessed or modified.
• NTFS: As it has additional features and capabilities including journaling which is not present in FAT32 and ExFAT, $Logfile provides information such as file creation, modification, deletion, or file rename, especially if temporary files are unrecoverable or not created.

Figure 8 – File modifications recorded in $Logfile

Kali Linux:

• FAT32 and ExFAT: Temporary files were commonly created for files opened with GUI/CLI (subjected to the applications used) when files were accessed or modified.
• NTFS: The creation of temporary files was also dependent on the application used to read or write the file. However, it was observed that using an NTFS-formatted USB on Kali Linux does not update transactional records in $Logfile, unlike in Windows.
  

  Figure 9 – File events not recorded in $Logfile for NTFS on Kali Linux

MacOS

• HFS+: Temporary files were not created when files were opened. However, entries for modified files and their last-seen timestamps were added to the versioning database (“db.sqlite”) located in the “.DocumentRevisions-V100” → “db-V1” folder. The “.DocumentRevisions-V100” folder is hidden and used to store previous versions of documents, allowing users to revert to earlier versions. According to the list of applications (with reference to Table 1) used for this research, it was observed that files edited with GUI tools were recorded, whereas modifications made through the CLI using Vim and Nano were not.
  

  Figure 10 – Modified file entries in “db.sqlite” versioning database

• FAT32 and ExFAT: Temporary files were created, but their patterns might differ from those in Windows or Kali Linux environments. Since macOS adds “extended attributes” (EAs) to files and FAT32 and ExFAT do not support EAs, Finder (the macOS file explorer) stores these attributes in temporary files with the same name as the original file, prefixed by “._”. These files were also created when files were copied into these file systems from a macOS machine. While they were observed not to be deleted upon file closure, their modification times were updated when the files were reopened. If “._” file was not previously present, a new “._filename”  would be created.
  

  Figure 11 – Example of “._” files in a FAT32-Formatted USB

Change in Timestamps

When temporary files, version databases, or NTFS journals were absent, access times could suggest when a file was opened, while modified times might indicate potential file tampering. However, access times could be affected by programs such as antivirus scans, which may alter these timestamps. Additionally, it’s important to note that FAT32 does not store access timestamps. Although modified timestamps are generally reliable, they can be subject to timestomping (where the timestamp is deliberately altered). Therefore, these timestamps should be considered alongside other forensic evidence to draw reliable conclusions.

SUMMARY

Table 2 – Temporary USB artifacts created using scenarios TC1 (Open and close a file without making modifications), and TC2 (Open, modify, and close a file). Please note that the presence of Temporary files are subjected to the application used.

Conclusion

As part of Digital Forensics and Incident Response, the investigation into USB drive artifacts across different operating systems and file systems revealed that temporary files are a significant but not universal indicator of file access/tampering. Factors such as the type of operation (opening vs. modifying), the application used, and the file system type can influence the presence and nature of these artifacts. It is also important to note that these temporary files, when deleted, might be overwritten quickly and there can be chances where such files cannot be recovered. Understanding the behavior and existence of temporary files helps investigators better identify file tampering activities.