Elsevier

Digital Investigation

Volume 3, Issue 4, December 2006, Pages 211-226
Digital Investigation

Data hiding in the NTFS file system

https://doi.org/10.1016/j.diin.2006.10.005Get rights and content

Abstract

In this paper we examine the methods of hiding data in the NTFS file system. Further we discuss the analysis techniques which can be applied to detect and recover data hidden using each of these methods. We focus on sophisticated data hiding where the goal is to prevent detection by forensic analysis. Obvious data hiding techniques, for example setting the hidden attribute of a file, will not be included. Hidden data can be further obfuscated by file system independent approaches like data encryption and steganography. This paper is only concerned with the methods which are made possible by the structure of the NTFS file system, and with the recovery of hidden data, not its interpretation.

Introduction

This paper discusses the file system dependent methods that can be used to hide data in the NTFS file system, and the analysis techniques that can be applied to detect and recover this hidden data. Target readers for this paper are computer forensic analysts and examiners, but the content may also be useful for system administrators and managers.

We restrict the discussion to those methods of data hiding techniques in NTFS file system which meet the criteria of security and capacity as specified in Provos and Honeyman:

  • Standard file system check with a utility such as chkdsk should not return any errors.

  • Hidden data will not be overwritten or the possibility of data being overwritten is low.

  • Hidden data will not be revealed when using standard GUI file system interface.

  • A reasonable amount of hidden data can be stored.

A method which fails to meet any one of the above criteria is not effective in the long term. If data can be easily detected with standard utilities by a normal user then it is not hidden properly. And if the data can be overwritten by unrelated file system activities, it can never be retrieved by the hiding party or the forensic examiner.

To order our discussion, we classify the effective hiding methods into two main categories:

  • Specific methods based on unique NTFS data structures.

  • Generic slack space based methods in relation to NTFS.

We further explore how NTFS specific methods can exploit the metadata structures and user data and directories in NTFS. For the sake of completeness we will also briefly discuss some methods which we would not under general circumstances consider effective according to the definition given above.

Section snippets

Methodology and tools

We used a number of software tools to first hide data using each of the discussed methods, and then recover these data and restore its original format. Runtime's DiskExplorer for NTFS v2.31 (DiskExplorer) was used to manually create the hidden data for testing purposes for all but one of the methods. The only exception was hidden data for alternate data streams (ADS) which was created by a standard DOS command. The test data were created on a system with Windows XP version 5.1.2600. Throughout

NTFS background

In the NTFS file system, every object is a file, and as such it inherits all the characteristics of a file. This includes file system metadata which defines the structure of the file system itself. NTFS organizes structures on a disk volume in four logical blocks (How NTFS Works) as shown in Fig. 1.

The most important feature of NTFS is the Master File Table (MFT), which is implemented as an array of records (Russinovich and Solomon, 2005). Every file and every directory has at least one entry

NTFS specific data hiding methods

As stated before any object in NTFS is a file, and as such can have any file attribute. Some attributes, for example $DATA, $INDEX_ROOT or $INDEX_ALLOCATION may legitimately appear multiple times in a single file, and in such case they are given unique names. Naturally depending on the file type, certain attributes are required and expected, but it appears that NTFS is not sensitive to a file including attributes which are unnecessary. This feature can be exploited for hiding data in such way

Slack space based hiding methods in NTFS

Slack space relates to all the areas on disk surface which cannot be utilised by the file system because of discrete nature of space allocation. Existence of slack space is characteristic of all file systems, not just NTFS. The discussion of data hiding methods in NTFS would not be complete without discussing slack space, and we will highlight those aspects of the methods which are specific to NTFS.

Ineffective data hiding methods

As stated in the introduction, effective data hiding techniques in a file system should meet the goals of security and capacity (Provos and Honeyman). Below we list some uncommon and ineffective techniques possible with NTFS which do not satisfy all of these goals.

  • Set the allocation bit of certain unallocated clusters to 1 and hide data in these clusters: a simple chkdsk validation would detect this.

  • Hide data in unallocated clusters: there is a high possibility of the hidden data being erased

NTFS integrity

A check of general integrity should be performed on NTFS before any analysis starts. The chkdsk command should be run, and if it returns any error, this is an indication that the file system could have been manipulated and left in an unstable state. Next the standard Windows utility Fsutil or the Sleuth Kit command fsstat should be run to obtain general information about NTFS system under investigation.

The cluster size of the system should be checked against the default size matching the file

Conclusion

In general, the analysis of hidden data in NTFS file system is divided into three phases. The first phase is to determine whether any data is hidden. This process can either systematically check for all hiding methods discussed in this paper, or search the system for anomalies. For example, it is abnormal for an operating system to detect bad sectors before a hard disk does, so the very presence of any bad clusters is suspicious and worth further analysis. Similarly, if the integrity of the

References (28)

  • D. Bem et al.

    Alternate data streams in forensic investigations of file systems backups

    (2006)
  • B. Carrier

    File system forensic analysis

    (2005)
  • Carrier B. The Sleuth Kit. Available from:...
  • H. Carvey

    Data hiding on a live system

    (2004)
  • H. Carvey

    Windows forensics and incident recovery

    (2004)
  • A. Chuvakin

    LinuxSecurity.com

  • K. Eckstein et al.

    Data hiding in journaling file systems

  • D. Farmer et al.

    Forensic discovery

    (2005)
  • Foremost,...
  • How NTFS Works, Windows Server 2003 Technical Reference. Available from:...
  • Incident handling/forensics FAQs....
  • W.G. Kruse et al.

    Computer forensics: incident response essentials

    (2002)
  • K. Li

    A guide to programming Intel IA32 PC architecture

  • J.R. Mallery

    Secure file deletion, fact or fiction?

  • Cited by (46)

    • Characteristics and detectability of Windows auto-start extensibility points in memory forensics

      2019, Digital Investigation
      Citation Excerpt :

      Hence, the tool analyzes the string and marks as suspicious those paths that contain any reference to the folders %APPDATA% (i.e., C:∖Users∖[username]∖AppData∖Roaming), %TMP% or %TEMP% (i.e., C:∖Users∖[username]∖AppData∖Local∖Temp), or the common parent folder AppData. Additionally, the tool also marks as suspicious any string command that contains operations regarding NTFS Alternate Data Streams (ADS) (Huebner et al., 2006) or well-known shell commands that indirectly launch programs (Mosuela, 2016; Reichel, 2017). For instance, the command rundll32.exe shell32.dll,ShellExecute_RunDLL [filename] will load the system library shell32.dll and will execute the function ShellExecute_RunDLL with the parameter filename.

    • Forensic Readiness: A Case Study on Digital CCTV Systems Antiforensics

      2017, Contemporary Digital Forensic Investigations of Cloud and Mobile Applications
    • Forensic Readiness: A Case Study on Digital CCTV Systems Antiforensics

      2016, Contemporary Digital Forensic Investigations of Cloud and Mobile Applications
    • Data loss recovery for power failure in flash memory storage systems

      2015, Journal of Systems Architecture
      Citation Excerpt :

      By reading this entry during the boot-up time, the host system identifies whether or not the storage was normally dismounted. In case of Ext4 [49] or NTFS [50], the host system stores boot-up status to a system registry file at start up and clears this registry file at normal termination. Therefore, the host is aware of the unusual termination state by examining the system registry file at system start up, and then starts a system recovery process, making a distinction between clean dismounts and dirty dismounts.

    • Forensics Analysis of NTFS File Systems

      2023, Advances in Cyberology and the Advent of the Next-Gen Information Revolution
    View all citing articles on Scopus
    View full text