Windows File Systems

Microsoft Windows comprises two main file systems of interest to the forensic examiner: FAT and NTFS. The original Windows files system was based on the FAT 16 file system. Later versions of Windows, starting with NT 3.1, were built on the enhanced file system, NTFS. Both file systems have characteristics that make them valuable for an examiner , and this section examines both the strengths and weaknesses of the file systems and how they are used. Future versions of Windows might use WinFS, a database-driven file system currently under development and slated for release after the Vista version of Windows. Table 4-2 provides an overview of the file system compatibility of different Windows versions.

Table 4-2: File System Compatibility

VERSION	NTFS	FAT16	FAT32
Windows 95	—	ˆ	—
Windows 95 OSR2	—	ˆ	ˆ
Windows 98	—	ˆ	ˆ
Windows ME	—	ˆ	ˆ
Windows NT 4	ˆ	ˆ	—
Windows 2000	ˆ	ˆ	ˆ
Windows XP	ˆ	ˆ	ˆ
Windows 2003	ˆ	ˆ	ˆ

File systems are created by formatting a specific partition on a hard disk. Formatting writes the partition boot record (also called the partition boot sector, or boot sector) for the file system chosen to the starting sector of that partition, in addition to updating the partition table to reflect the new partition type. Microsoft provides both visual and command line formatting tools.

When reformatting an existing drive, Microsoft leaves the existing data in place. The partition boot sector is replaced as is the file system type in the MBR, if necessary. The actual contents of the files present prior to formatting are still there and can be searched and recovered using the tools mentioned in Chapter 10. Quick formatting and standard formatting perform similarly in Windows. The difference is that the standard format performs a disk integrity check sector-by-sector to identify any areas with read errors.

Windows allows for the addressing of individual partitions, which have been formatted using drive letters . A drive letter designates the logical name (for example, C:) assigned to a partition. By convention, the A: and B: drives are reserved for floppy disks, the C: drive is assigned to the operating system drive, and the D: through Z: drives are assigned to other partitions, network drives , and removable media.

FAT

The File Allocation Table (FAT) file system traces its history back to the days of Microsoft DOS (MS-DOS) with FAT12. The "12" in FAT12 refers to the number of clusters that the operating system could handle.

Note 

It actually goes back to a predecessor operating system of DOS, CP/M. The first version of QDOS, which became MS-DOS, in 1980 supported FAT12.

The original FAT file system was capable of addressing 2 ¹² clusters of a 512- byte fixed size . This allowed the file system to address 2,220,032 bytes of memory (512 — 2 ¹² ) or approximately 2MB of file space. This was adequate addressing for the available 360KB floppy drives available at the time but quickly grew dated as floppy drive capacity increased and hard drives were introduced in the PC marketplace . FAT12 is still used as the file system of choice for many floppy disks (including standard 1.44MB floppies).

Note 

A cluster is the smallest area a file system can directly address.

As hard disks became available in the mid-1980s, the need for a larger file system was addressed with the introduction of FAT16. Capable of addressing up to 2 ¹⁶ clusters, the FAT16 file system additionally allowed cluster sizes of 2K to 32K bytes. This permitted the addressing of drives up to 2,147,483,648, or 2GB in size (2 ¹⁶ — 32,768). FAT16 was the original file system in Windows 95 and is still used for defining smaller partitions (for example, BIOS tool partitions) in current drives.

In the mid-1990s, drive capacity grew beyond 2GB and the need to address drives larger than that permitted by FAT16 led to the development of FAT32 with Windows 95 OSR2 and later Windows 98. FAT32 supports up to 2 ³² clusters, with cluster sizes ranging from 4K to 32K. FAT32 theoretically supports larger cluster sizes and up to 2TB of total addressable storage, but realistically , the upper limit is 64GB per partition for performance reasons.

SECURE DATA WIPING

Recent media stories and journal articles have highlighted problems with standard format commands not deleting data. Indeed, the Microsoft format command itself does not actually alter any drive data, just the metadata on the drive. From a forensic perspective, this is a good thing when recovering files but a bad thing when protecting data from one's own investigations.

Both before and after any investigation, the destination analysis disk should be wiped clean using secure wipe utilities before partitioning and formatting. Wiping involves the writing over of every byte in every sector of the disk with a pattern. Although there are proponents for multi-pass wiping, with the latest hard disks, the recovery possibilities using STM technologies are minimal for anything but top secret-level information. A search of the media shows no commercial endeavors ever having their data recovered maliciously after a single-pass wipe.

For forensic drives, a zero pattern tends to be well received because a disklevel analysis quickly shows that the drive has been adequately wiped. Likewise, any data written to the disk will write over the zero pattern, preventing the possibility of slack data previously existing on the drive being read as part of the investigation. To zero-out a drive, there are several good utilities available. Darik's Boot and Nuke, a floppy-disk and/or CD-based solution, is free and readily available online. Likewise, for those who have Cygwin installed or a Linux box available, using dd if=/dev/zero of=/dev/hda accomplishes the same thing from the Linux command line. Finally, those who use EnCase have a built-in disk wiping utility available. This is great for USB and FireWire drives that cannot be directly accessed without special drivers from a bootable floppy disk.

When disposing of disks permanently, the preceding utilities work as well and are recommended for any disks being retired or repurposed. Degaussing of hard disks does not work effectively. The logic circuits would fail if a field strength great enough to completely wipe the platters without residuals were present. Because the voltage requirement for a degausser strong enough to wipe hard disks is fairly high, the secure wipe is a cheaper and safer option.

For those ultra - paranoid about their data being recovered, the best mechanism available is still physical destruction of the disk platters. Shredding and then incinerating appears to be the Department of Defense method of choice. It is difficult to recover data from a solid hunk of metal.

For a definitive look at sanitization, see Garfinkel and Shelat, "A Remembrance of Data Passed: A Study of Disk Sanitization Practices," IEEE Security and Privacy, 2003.

 

The original versions of FAT permitted the use of file names of up to 11 characters. (Hence the 8.3 DOS legacy naming convention still in use: eight characters for the file name and three for the extension.) To allow for larger file names (up to 255 characters ), Windows introduced VFAT. VFAT is not a new version of FAT, but an extension to FAT16 and FAT32 to allow for long file names to be stored.

FAT clusters have a fixed number of physically addressable sectors per cluster, defined in the boot record. A cluster is the smallest area of space logically addressable by the file system. The file system does not directly reference sector-level information. This leads to an anomaly in disk storage: slack space. This is perhaps best illustrated with an example:

• A FAT16 disk with a cluster size of 32KB needs to store a file containing 1KB of data.

• Because the file system can access only an individual cluster (and not a sector), it must use a full 32KB entry to store the 1KB of data.

• When the 1KB of data is stored, the file system only overwrites the first 1KB of the 32KB cluster, leaving 31KB of old data in place and untouchable until the cluster is reclaimed. This is called slack space.

When conducting a forensic investigation, the slack space noted previously is useful when searching for content from removed files. The searching of slack space in an investigation is detailed in Chapter 5.

The FAT file system retains its name from the File Allocation Table, which identifies the status of individual clusters within a partition. On a FAT partition, the file allocation table is present immediately after the partition boot record. The overall layout of a FAT partition is shown in Figure 4-2.

Figure 4-2: FAT partition layout

The boot sector contains the specific information on the layout of the partition and is referenced by the MBR detailed in Chapter 3. The Boot Sector itself contains the meta-information on the structure of the hard disk and is useful to the forensic analyst in determining the starting locations of both the file allocation tables and the data itself. The boot sector on a FAT32 volume is composed of the key entries useful in forensic analysis shown in Table 4-3. (For the full layout, refer to Appendix D.)

Table 4-3: FAT32 Boot Sector

OFFSET # LOCATION	OF BYTES	IDENTIFIER	NOTES
03h	8	OEM name	The name of the OS that formatted the partition. Can be used to determine legacy OS presence in the case of reformatted drives.
0Dh	2	# of reserved sectors	The number of sectors sectors reserved for the boot record. This number indicates the beginning of the actual file allocation table.
15h	1	Media type	F0 for a floppy drive, F8 for a hard drive. If the media type is changed, the device might not be recognized properly (although it may still contain valid data).
28h	2	Flags	Reserved for determining FAT mirroring status. Allows for the use of the backup FAT as the primary on FAT32 systems. If the backup FAT is being used, this may be of importance and indicate data hiding.
40h	1	Drive Id	00 for a Floppy Disk, 80 for a Hard Disk
43h	4	Volume serial number	A unique number assigned to a partition at format time. Both Quick and Full formats reassign a serial number. This can be used to uniquely identify a partition on a given drive.
47h	11	Volume/partition name	An 11 character name assigned to the volume by the person formatting the drive.

Immediately following the boot sector is a copy of the file allocation table itself. The file allocation table indicates the status of individual clusters on the partition and consists of the header and the cluster map.

The header for the file allocation table includes two entries (each two bytes) immediately following the boot sector: media type and partition state. The media type should match the media type identified at offset 15h. If it does not, this is an indication of potential drive corruption (accidental or intentional.) The partition state is used by Windows to indicate whether a proper shutdown has occurred. When Windows starts, this value is set to FF F7, indicating that the partition is actively in use. When Windows shuts down and when the partition is initially formatted, the state is set to FF FF. If Windows detects the partition state as FF F7, it knows that the operating system was not shut down properly and runs scandisk to verify file system integrity. If a system was shut down by pulling the plug, a hex editor should show the partition state as FF F7. This can provide independent verification of shut-down procedures.

Following the FAT header is the cluster map itself. The cluster map contains an entry for every cluster on the drive. For FAT12 and FAT16 file systems, each cluster is represented by two bytes. For FAT32, each cluster is represented by four bytes. The FAT entry contains one of a number of data entries:

• 0F FF FF F7 indicates a cluster is bad and should not be used by the operating system. Forensic tools such as hex editors will still allow the viewing of these clusters, which may contain intentionally hidden data (if the cluster is marked as bad by the user ) or unintentionally hidden data (data left over in the cluster if the disk reports a single bad sector within it).

• 00 00 00 00 indicates that a cluster is available for storage of data. When a file is deleted, this cluster map is updated to indicate all clusters associated with that file are available. When this happens, the cluster map will contain 00 00 for any files previously in that cluster. Until another file is written to the disk and needs those clusters, the data in them is still present and may be recovered.

• 0F FF FF F80F FF FF FF indicates the cluster is the end of a file entry.

• 00 00 00 020F FF FF F6 indicate user data is stored in that cluster. The information contains the ordinal number of the cluster in a particular file. If the file is fragmented , that is if the clusters of a file are not contiguous, the cluster map will indicate the position on the drive of the next cluster in the file.

Fragmentation is normal on a disk drive and occurs with usage. Consider the cluster map scenario shown in Figure 4-3:

• A drive contains four files (File 1, File 2, File 3, and File 4), each three clusters in length.

• File 1 and File 3 are deleted. Their clusters are marked as available.

• File 5, which requires five clusters of space, is written to the disk. Because there are no contiguous groups of available clusters large enough, it is split between two groups of clusters. This is called fragmentation.

Figure 4-3: Drive fragmentation

Defragmentation is the process of consolidating the data so that the majority of clusters for a given file are contiguous. This optimizes drive speeds and simplifies the cluster map. Defragmentation can be both a boon and a bane to the forensic analyst. Any clusters at the beginning of a drive are likely to be wiped mostly clean and the information from other clusters stored there. An advantage to the analyst, however, is the fact that those clusters in the upper sectors of the disk now contain copies of information that may not be overwritten for a long time, even if the original files are securely wiped from their new locations.

Following the file allocation table and its backup is the root directory entry for the drive. Entries in FAT32 directories are 32 bits (four bytes) long, and contain the name and information on files that is used by the operating system. The root directory is the first directory on the drive, of which all other directories are subdirectories.

Within the root directory entry are the items shown in Table 4-4.

Table 4-4: Root Directory Entry

OFFSET LOCATION	# OF BYTES	IDENTIFIER	NOTES
00h	8	File name	The eight character short file name.
08h	3	File extension	The three-letter extension used to map the file to an executable.
0Bh	1	File attributes	Set to 1 if a given attribute is true. Attribute bits are as follows : 0 = Read Only 1 = Hidden 2 = System 3 = Volume Label 4 = Directory 5 = Archive 6,7 = Reserved
0Ch	1	Reserved	Reserved for future NT use.
0Dh	1	Reserved	Reserved for future NT use.
0Eh	2	File creation time	Time the file was last created.
10h	2	File creation date	Date the file was last created.
12h	2	Last accessed date	Date the file was last accessed.
14h	2	High half of start cluster	The high word of the starting cluster of the entry referred to.
16h	2	Time of last write	Time the file was last written to.
18h	2	Date of last write	Date the file was last written to.
1Ah	2	Low half of start cluster	The low word of the starting cluster of the entry referred to.
1Ch	4	File size	The size of the file. This is all zeros, if this is a subdirectory and not a file.

Tip 

For general Windows date and time decoding during forensics, try the Decode tool available for free at http://www.digital-detective.co.uk/freetools/decode.asp.

Each and every file has an entry as shown in Table 4-4. Subdirectories have entries similar to files, and each subdirectory has two additional entries:

1. . (pronounced dot)refers to the directory itself.

2. .. (pronounced dot-dot)refers back to the parent directory.

When conducting a forensic analysis, the times and dates of file creation, access, and write are important. Although they can be intentionally altered through the use of a program or by changing the system time, they are still critical to an investigation. The creation time indicates the time at which an entry was first written into the directory for the file. The last accessed time indicates the last time an application referenced that particular file. Note that all applications do not necessarily update this date properly. A backup program, for example, reads these files without updating the access time.

Table 4-5 shows the date format used in FAT entries.

Table 4-5: FAT Date Format

NAME #	OF BITS	VALUE
Year (elapsed since 1980)	7	0128
Month	4	112
Day	5	131
Hour (24- hour )	5	023
Minute	6	059
Seconds	5	029

Note 

As a result of space limitations, FAT permits the storing of even seconds only, so the seconds value is actually multiplied by 2 for display.

VFAT

Virtual FAT (VFAT) was introduced with Windows 95 to enable the use of long file names (up to 255 characters). In order to remain backward-compatible with existing operating systems (for example, DOS), the long file name (LFN) extensions are added as new directory entries, the same as existing directory entries. For older programs to ignore the entries (which, if they are designed to accept 8.3 filenames they cannot process), the directory entries containing the LFN have the Volume Label attribute set (the Read Only, System, and Hidden attributes are also set). Older programs will see these entries as being Volume Labels and not files and will ignore them.

The VFAT LFN entries are placed in the directory entry immediately preceding the existing FAT32 entry for a file, in reverse order, so the entries would be as follows:

• LFN n

• LFN n-1

• LFN n-2

• LFN 1

• Legacy FAT entry

In addition to supporting up to 255 characters, VFAT supports the use of Unicode to enable support for multiple languages with more characters than ASCII can handle (for example, Mandarin Chinese and other double byte languages). As a result, every character in a LFN entry takes two bytes instead of one (as required for ASCII entries). For characters not requiring the use of Unicode, the first byte is the ASCII character value and the second byte set to 00. Each directory entry can store up to 13 LFN characters (13 — 2 = 26 bytes; the other six bytes are for sequence number, checksum, and legacy support).

The format of the LFN entry is shown in Table 4-6.

Table 4-6: LFN Entry Format

OFFSET LOCATION	# OF BYTES	IDENTIFIER	NOTES
00h	1	Sequence number	Refers to which LFN entry this is. The last entry always has bit 6 set.
01h	10	File name(1)	First five Unicode characters of file name.
0Bh	1	File attributes	Set to 0F for LFN entries.
0Ch	1	Reserved	Reserved for future NT use.
0Dh	1	Checksum	Value to validate LFN entry, calculated as follows: Checksum is calculated on the short file name (not the long file name) as follows: Start with the value of the first character. Bitwise rotate right (ROR) the sum. Add the value of the next character to the sum. Repeat steps 2 and 3 for all 11 characters.
0Eh	12	File name(2)	Second six Unicode characters of file name.
1Ah	2	Start of cluster	This is in place to support legacy applications looking for a standard FAT entry. Set to 00 00 for LFN entries.
1Ch	4	File name (3)	Third two Unicode characters

The short name is stored as an abbreviated version of the long name. The short name takes the format NNNNNN~#.XXX, where NNNNNN are the first six characters of the LFN with spaces removed (and translated to uppercase), # is an ordinal number defined by Windows (in case there are multiple entries with matching NNNNNN values), and XXX is the file extension. A LFN of "Long File Name.doc" would be stored as "LONGFI~1.DOC." These can be viewed from the command prompt by typing dir /x on Windows systems.

Note 

If there are more than four files with the first six characters the same, VFAT short entries take the form NN####~1.XXX, where #### is a unique four digit number.

NTFS

To address the limitations of the FAT32 file system and add POSIX compliance, Microsoft began work on a new operating system in the early 1990s. At the time, Microsoft had a partnership with IBM to develop the next generation operating system: OS/2. As part of this development effort, Microsoft and IBM jointly developed the High Performance File System (HPFS).

Note 

POSIX stands for Portable Operating System Interface and is a standard that allows interoperability between different operating systems.

Partway through the OS/2 project, the relationship between Microsoft and IBM dissolved, and they parted ways. Microsoft began development of its own operating system, Windows NT. The NT File System (NTFS) used many of the features present in the HPFS system used by OS/2 and greatly improved on the existing FAT16 file system. FAT32 was not yet available.

NTFS version 4.0 (also called NTFS 1.1) was used in earlier version of Windows NT up through NT 4.0. Starting with Windows 2000, an enhanced version of NTFS known as NTFS 5.0 was released and is the currently available version. Many features introduced in NTFS 5.0 were present in the structures used for earlier versions but not yet supported by the operating system. Enhancements such as file permissions and change logs offer additional features of use to the forensic examiner. Features such as compression and encryption also present new challenges during a forensic examination and require special handling. The forensic use of these will be detailed in this and the following chapter.

ALTERNATE DATA STREAMS

The NTFS file definitions support multiple $DATA attributes, each of which is referred to as an alternate data stream (ADS). The use of an ADS allows Windows programs to store additional information in the form of a separate stream, all within a single file. Secondary streams are not visible to most Windows applications, making them a great way to hide information in files.

Windows uses a colon to reference an ADS within a file. Each ADS is named, with the name be prefixed by the actual file name. Thus, an ADS called financials within a file innocuous.txt would be referenced as " innocuous .txt:financials." The data contained in the alternate stream would not be displayed by non-ADS aware applications. Likewise, the directory listing would only show the primary file name, not the financials stream. Even file size is not an indication. The file size displayed in Windows Explorer is only the size for the primary stream, allowing a multi-megabyte ADS to exist under a file showing a size of 1K.

Consider the following interaction, where the secret ADS is added to the file innocuous.txt:

 C:\Test>echo This is a Test File > innocuous.txt C:\Test>type innocuous.txt This is a Test File C:\Test>dir  Volume in drive C has no label.  Volume Serial Number is 00A8-1CDC  Directory of C:\Test 09/20/2004  12:39 PM    <DIR>           . 09/20/2004  12:39 PM    <DIR>           .. 09/20/2004  12:39 PM                 22 innocuous.txt                1 File(s)             22 bytes                2 Dir(s)   3,003,953,152 bytes free C:\Test>echo Here is a second file > innocuous.txt:secret C:\Test>dir   Volume in drive C has no label.   Volume Serial Number is 00A8-1CDC   Directory of C:\Test 09/20/2004  12:39 PM    <DIR>           . 09/20/2004  12:39 PM    <DIR>           .. 09/20/2004  12:39 PM                 22 innocuous.txt                1 File(s)             22 bytes               2 Dir(s)   3,003,953,152 bytes free C:\Test>type innocuous.txt This is a Test File C:\Test>type innocuous.txt:secret The filename, directory name, or volume label syntax is incorrect. C:\Test>more < innocuous.txt:secret Here is a second file 

In the preceding example, the directory listing does not show the ADS in name or reflect the additional size of the data in either the bytes free or the total bytes listed. Likewise, the ADS cannot be accessed using the type command, as that command does not include ADS support. The more command, which is ADS-enabled, shows the data is present and accounted for, however. Likewise, DiskExplorer indicates the second $DATA attribute as being present as shown in the following figure.

ADS data

Although not viewable by general tools, ADSs will still be searched when a sector-level copy of the disk is examined for a given string. Likewise, ADSs can be identified by searching for other $DATA entries in a file, as done by the streams program available from Sysinternals. Using streams below shows the above-created stream in the innocuous.txt file.

 C:\Test>streams * Streams v1.5 - Enumerate alternate NTFS data streams Copyright (C) 1999-2003 Mark Russinovich Sysinternals - www.sysinternals.com C:\Test\innocuous.txt:           :secret:$DATA 24 

Because streams allow recursive searching, an entire drive can be searched using the -s switch for any ADSs present on a given drive, for example, streams-s c:\*.* .

Streams are copied when a logical file is copied from one NTFS partition to a second NTFS partition. When a file is copied to a non-NTFS drive, however, any ADSs present are lost and only the primary $DATA stream retained. For the forensic examiner, a logical copyusing the copy command to duplicate files to a floppy, for exampleshould always include a preliminary check for the presence of ADSs.

 

Taking a cue from Unix systems, almost everything within an NTFS partition is a file, including files that contain meta-data about the partition itself. The exception to this is the partition boot sector which is referenced by the MBR and contains the basics of the partition and bootstrap code.

Note 

Technically, the partition boot sector is a file, $BOOT, as listed by the $MFT, but unlike other files cannot be relocated .

Table 4-7 shows the key features of the boot sector on an NTFS system which are of use in a forensic examination. (The full layout is included in Appendix E.)

Table 4-7: NTFS Boot Sector

OFFSET LOCATION	# OF BYTES	IDENTIFIER	NOTES
03h	8	OEM name	The name of the OS that formatted the partition. Can be used to determine legacy OS presence in the case of reformatted drives.
0Dh	2	Number of reserved sectors	The number of sectors reserved for the boot record. This number indicates the beginning of the actual NTFS file system.
15h	1	Media type	Should always be F8 for a hard drive. If the media type is changed, the device might not be recognized properly (although it may still contain valid data).
30h	8	Logical cluster number for the file $MFT	Starting cluster of the $MFT file (see below).
38h	8	Logical cluster number for the file $MFTMirr	Starting cluster of the $MFTMirr file (see below).
48h	4	Volume serial number	A unique number assigned to a partition at format time. Both Quick and Full formats reassign a serial number. This can be used to uniquely identify a partition on a given drive.

The boot sector on an NTFS partition is mirrored on the last sector(s) of the disk as well, though it is not referenced as such.

Immediately following the boot sector is one of two mirrored copies of the main file used by NTFS, the master file table ($MFT). The master file table contains the information used to define the partition's file system and its contents, including metadata files. To accommodate all of this information, Microsoft reserves a significant portion (12.5 percent initially) of a disk to store this file. The space can be used, when necessary, by other applications but is initially set aside upon formatting.

Each entry within the $MFT is referred to as an inode. Each inode is made up of attributes, defined in the $AttrDef metafile (a list of all Metafiles in NTFS is included as an appendix). The key inode attributes are as follows:

• $Standard_Information . The basic file attribute information (similar to FAT file information) is stored here. The information in the Standard Information includes the times and dates used by Windows for tracking file system additions, updates, and changes.

• $Attribute_List . A listing of all file attributes that are non-resident.

• $File_Name . The long and short names of the file.

• $Object_ID . A unique identifier assigned to each object.

• $Security_Descriptor . The attribute containing the file owner and access control list (ACL) information.

• $Data . The actual content of the file, or pointers to the content of the file (for most files, this will be a pointer to content. Only very small files store the data resident). NTFS supports multiple data streams per file, with one $DATA attribute per stream (see "Alternate Data Streams" later in this chapter).

The $Standard_Information attribute has the fields shown in Table 4-8.

Table 4-8: $Standard_Information Attribute Fields

OFFSET LOCATION	# OF BYTES	IDENTIFIER	NOTES
00h	8	File creation	The date and time the MFT record for the file was initially created.
08h	8	File modified	The date and time the file was last changed.
10h	8	MFT modified	The date and time the file's MFT entry was last altered.
18h	8	File accessed	The date and time the file was last read.
20h	4	DOS attributes	The DOS attribute settings for the file.
24h	4	Maximum versions	The maximum number of versions permitted for a file (0 if versioning is disabled for the file).
28h	4	Current version	The current, latest version number.
2Ch	4	Class ID	Used to point back to the class identifiers.
30h	4	Owner ID	The Owner ID contains a pointer to the $Quota metafile referencing the owner of the file for quota purposes.
34h	4	Security ID	The Security ID contains a pointer to an entry in the $Secure metadata file.
38h	8	Quota charge	The number of quota bytes chargedincludes the sum of all data streams in the file. Because only the primary stream size is shown by most applications, the quota charge may be different than the displayed file size values.
40h	8	USN	The update sequence number (USN) contains a pointer into the NTFS journal metadata used for file system transactional integrity.

The individual DOS file permissions expand on the basic file permissions assigned to files in the FAT file system. The permissions are shown in Table 4-9.

Table 4-9: NTFS DOS File Permissions

GROUP /BIT	IDENTIFIER	NOTES
1/1	Read-Only	The file system won't allow writing to the file.
1/2	Hidden	The file won't be displayed in standard directory listings.
1/3	System	Bit set for system (OS) files.
1/4	Directory	File is a directory.
2/2	Archive	Used for backups ; set to indicate the file needs archiving.
2/3	Device	Special attribute to indicate the file is a device that mimics a file for operations.
2/4	Normal	File is a standard file.
3/1	Temporary	File is a temporary file that can be cleaned on system cleanup tasks .
3/2	Sparse file	File is a sparse file (a special type of file that is large in size but has small amounts of initial data).
3/3	Reparse point	is a reparse point indicating another file system is mounted at this location.
3/4	Compressed	File is compressed by Windows.
4/1	Offline	File is not available (online) on the current media.
4/2	Encrypted	The file is encrypted by Windows.

Like the $Standard_Information attribute, the $File_Name attribute also contains information that may be of interest to the examiner. The $File_Name attribute is defined as shown in Table 4-10.

Table 4-10: $File_Name Attribute Definition

OFFSET LOCATION	# OF BYTES	IDENTIFIER	NOTES
00h	8	..	The pointer to the parent directory of the file.
08h	8	File creation	The date and time the MFT record for the file was initially created.
10h	8	File modified	The date and time the file was last changed.
18h	8	MFT modified	The date and time the file's MFT entry was last altered.
20h	8	File accessed	The date and time the file was last read.
28h	8	Allocated size	Allocated size of the file.
30h	8	Real size	Real size of the file
38h	4	DOS attributes	The DOS attribute settings for the file.
3Ch	4	EA size	The size of extended attributes buffer.
40h	1	File name length	The number of characters used by the file name.
41h	1	File name namespace	The namespace defining which characters are valid for the file.

The attributes in the $File_Name tag are not updated unless that attribute itself changes. The attributes in $Standard_Information are updated whenever the file or MFT entry changes and are therefore the accurate items to use in most investigations. If it is suspected that the user changed the name of the file intentionally to hide it, that attribute will then have a date different from the initial creation date.

The easiest way to view MFT entry information directly is through the use of a third-party tool. DiskExplorer from Runtime Software has a great interface for doing this. A view of the $Standard_Information attribute for the pagefile.sys file is shown in Figure 4-4.

Figure 4-4: MFT standard information for pagefile.sys

NTFS has three additional special types of files of interest from a forensic standpoint:

• Directories. NTFS treats directories as files as well. A file defined as a directory contains three additional attributes, $Index_Root , $Index_Allocation , and $Bitmap . These three attributes contain entry information allowing for the linking to the $MFT file entries or subdirectory entries.

• Sparse files. Sparse files were designed to allow for very large files to reserve space with minimal amounts of actual storage allocated. A multi-gigabyte file with large runs of zeros may only take up a few megabytes if defined as a sparse file on NTFS. Be aware when conducting an examination using a native NTFS file system that copying a sparse file to another file system (for example, FAT) will result in the full-size file being generated and copied, requiring significantly more storage space or an NTFS drive to be used.

• Reparse points. Reparse points permit the redirection of access to a file using set criteria. Individual applications can define their own reparse point information but NTFS used reparse points for a few key items of interest to the investigator . Symbolic links provide Unix-like redirects from one file (or directory, in the case of junction points) to another. The other items of interest are volume mount points. These permit an entry to point to another system or partition and appear to be part of the same logical directory structure. The Windows Mountvol command will show all volume mount points present.

The NTFS file system supports two key features not found in FAT-based file systems: compression and encryption. Both present challenges for the investigator for searching, accessing, and copying files.

BYPASSING NTFS PERMISSIONS

NTFS allows for an individual user to claim ownership of a file or directory. That individual, designated as the owner, has the ability to assign access rights to Windows users and groups to that file or directory. These rights are stored along with the entity and can include any number of file permissions including reading, changing, and deleting a given file.

When accessed through a Windows environment, the NTFS driver checks the security permissions on a given file before permitting access to that file. If the individual currently logged on does not have rights to that file to perform the requested operation, access is denied . If the user has administrative rights over the system on which the NTFS partition resides, that user can take ownership of the entity and grant themselves rights to access it. If they do not have administrative rights, they must request that an administrator or the owner of the entity grant them the requested permissions.

Even though there are access control lists (ACLs) present on NTFS files, Windows relies on the individual NTFS driver to enforce those controls. Therefore, using a non-Microsoft NTFS drive such as the ones available for Linux or the read-only NTFSDOS driver that does not support ACL enforcement allows an individual to read any file on a drive regardless of permissions. Likewise, any utility that performs a raw, sector-by-sector copy of a drive (such as EnCase or SafeBack) will likewise ignore file permissions as it is operating at a level below that of file system when copying.

To access files on a machine for which the investigator does not have an account or the necessary permissions:

• Create a Windows 98 boot disk. Insert a blank disk into a Windows 98 machine and from the command prompt type format a: /s . This will create a bootable DOS disk with the Windows 98 file on it.

  • If a boot CD is needed (for example, if there is no floppy drive on the system in question), Linux may be the best choice. Both Helix (available at http://www.e-fense.com/ helix /) and F.I.R.E. (available at http://www. biatchux .dmzs.com) are forensic-specific bootable CDs, which include NTFS support.

• Download the NTFSDOS Professional driver from SysInternals at http://www.sysinternals.com/files/NTFSProR.exe to a Windows NT, 2000, or XP machine. Run the executable to install the disk creator.

• Run the installed NTFS Professional Boot Disk Wizard to copy the necessary system files to the newly created boot disk.

  • To save time, create an ISO image of the NTFSDOS bootable floppy with the NTFSDOS executable called from the autoexec.bat file. These new images can be copied directly to a boot disk without needing to go through the first three steps.

• Boot the suspect's machine with the new floppy. Insert the new disk into the floppy drive of the target machine and ensure that the floppy drive is the first boot choice from the setup menu.

• Start NTFSDOS and browse the hard disk. Run NTFSDOS from the directory where the files are placed with the wizard. Browse the target NTFS file system in read-only mode and use other floppy disks or create a boot disk with network or null modem cable drivers to copy target files to a non-NTFS partition, bypassing any permissions.

 

Compression

NTFS permits the compression of files, directories, and volumes to save space. The compression used is lossless compression. There is no data lost in shrinking the file size. The specific algorithm used is an older Lempel-Zip (LZ) algorithm which searches for repeating strings of variable lengths and replaces them with smaller, fixed-length placeholder codes. While not optimal in terms of storage reduction (the algorithms used by programs such as PKZip and WinRAR do a much better job of compressing information to smaller sizes), the algorithm is fairly fast, allowing for a minimal time difference when accessing compressed files.

Note 

Algorithms such as JPEG and MPEG-2 are examples of lossy compression. Information is lost when these algorithms are used.

When a program accesses a file that is compressed using NTFS compression, the operating system compresses and decompresses the file on the fly. This is accomplished automatically when programs access NTFS-compressed files (Windows filters out system calls to files with compressed data and performs the decompression first then passed the decompressed data to the calling program.)

Note 

Windows XP also supports ZIP files. This is a separate function from NTFS compression, but the compression and decompression are still handled by the operating system, just a different set of library functions.

Because the act of compression changes the data stored on the disk, compressed files cannot be searched accurately within a sector-by-sector image. These files need special treatment to be accurately searched, as do all compressed files. They need to be decompressed and searched at a logical file system level instead of a sector level. Additionally, searches for file headers (for example, tools that search for deleted files with no MFT record), will likely be unsuccessful on compressed data.

Figure 4-5 shows the actual data stored in the compressed (bottom) and uncompressed (top) versions of a text file containing the words to the United States Constitution. The lower, compressed image is not likely to find keywords or strings when a basic search is performed.

Figure 4-5: Compressed and uncompressed file comparison

The Microsoft command line tool compact allows the investigator to search a logical volume for, and uncompress, NTFS- compacted files that are present. The compact /S command can be used to recursively search all folders for compressed files. Any files with a "C" in front of the file name are compressed. The compact command also allows the investigator to both compress and decompress files and view the compression ratios. The compact /C command allows for a file to be compressed, and the compact /U command allows for decompression.

The commands that follow compact the file http://www.report.htm, which is highly compressible due to extensive whitespace and repeating text being present. In fact, it compacts at a 2.6:1 ratio, allowing for it to be stored in less than half of the original space used. Note, however, the file size has not changed in the directory listing although the space used on disk has. This is of interest when copying files to a non-NTFS partition. Any files that were compressed will be decompressed when copying to a floppy or tape if a logical copy operation is used. This may require more storage space than was originally used on the source drive based on the compression ratios.

Note 

Windows also supports .cab compression. These files are usually distributed with software, and the format is not commonly used for end-user compression (and therefore less likely to contain evidence in a forensic investigation). To extract the files from a compressed .cab archive, the expand -F:* command can be used.

 C:\Test>dir   Volume in drive C has no label.   Volume Serial Number is 00C9-1BDC   Directory of C:\Test 09/21/2004  10:03 AM    <DIR>           . 09/21/2004  10:03 AM    <DIR>           .. 06/01/2004  09:38 AM             43,279 report.htm                1 File(s)         43,279 bytes                2 Dir(s)    2,492,268,544 bytes free C:\Test>compact /C report.htm   Compressing files in C:\Test\ report.htm              43279 :     16384 = 2.6 to 1 [OK] 1 files within 1 directories were compressed. 43,279 total bytes of data are stored in 16,384 bytes. The compression ratio is 2.6 to 1. C:\Test>dir   Volume in drive C has no label.   Volume Serial Number is 00C9-1BDC   Directory of C:\Test 09/21/2004  10:03 AM    <DIR>           . 09/21/2004  10:03 AM    <DIR>           .. 06/01/2004  09:38 AM             43,279 report.htm                1 File(s)         43,279 bytes                2 Dir(s)    2,492,100,608 bytes free 

Encryption

NTFS version 5, introduced with Windows 2000, brought the concept of encrypting the data within a file, directory, or volume as a native service provided by Windows. This encryption is supported in Windows 2000, XP Professional, and 2003 under the name Encrypting File System (EFS).

EFS permits an individual user to encrypt any files for which they are the owner. The act of encryption is fairly complex and uses both symmetric and public-key encryption. When encrypting a file, the file owner specifies who has access. By default, only the individual performing the encryption and any designated data recovery agents (DRAs) are permitted access, but other users can be added by the individual.

Note 

Data recovery agents are defined by policy as accounts that can be used to decrypt a file if the original account's encryption keys are lost or damaged or the original account holder is unavailable. Most organizations designate their security group as one of the DRAs.

To encrypt a file, the following steps take place:

1. Windows generates a random 128-bit key called the file encryption key (FEK) specifically for that file.

2. The current user's public key is accessed through the registry.

3. If this is the first time the user encrypts a file, Windows generates a public and private key for the user. The private key is stored in an encrypted form (encrypted with a master key generated by Windows from user-specific credentials) with the individual user's profile.

4. A data decryption field (DDF), containing the user's information and a copy of the FEK encrypted with the user's public key is generated and added to the file header.

5. Additional DDFs for each additional user granted access likewise contain FEKs encrypted with that user's public key and placed in the file header.

6. Any DRA fields are generated the same way as the DDFs and stored in the header.

7. The original data is symmetrically encrypted using DESX (an RSA enhancement to the data encryption standard algorithm) or TripleDES (another enhancement, available as an option with XP Professional and 2003) and copied to the $DATA attribute of the newly created header.

8. The original data file is removed.

SYMMETRIC AND PUBLIC KEY ENCRYPTION

Symmetric encryption relies on a single key that can be used to both encrypt and decrypt a file. An example is XOR'ing a file against a given set of binary digits and storing the result. A second XOR operation against the encrypted result with the same key will return the original data.

Public key encryption relies on two keys: a public and a private key. Public key algorithms use one-way functions, which are based on computationally hard problems (for example, factoring of large numbers ) where a different key is used to encrypt (public) than to decrypt (private). With public key encryption, the encryption cannot be reversed with knowledge the public key in a reasonable timeframe, allowing that key to be published widely.

 

When a forensic investigator encounters an EFS-encrypted file, directory, or volume, he will not be able to read its contents using standard disk viewing tools at either a logical or physical level. The contents can actually be read, but they will be unintelligible as they are encrypted. To recover the information from an EFS-encrypted file, the investigator has a few primary options:

Obtain the user's credentials and log in as the user. This will potentially alter forensic evidence (for example, login times and profile information) and should only be performed after a full forensic duplicate of all information has been made. If EFS or other encryption is suspected and the user is logged in when the computer is found, a live system analysis should be performed in lieu of powering off the machine. The users' credentials can be obtained through social engineering, password guessing (of that or other passwords), or any other technique used to obtain user passwords.

• Use a designated DRA account to access the files. If the security group is registered as a DRA or has access to a DRA account, this account can be used to decrypt the files in question. The DRAs can be identified using a tool such as EFSDump as shown below:

 C:\Test\report.htm: DDF Entry:     SECURITY\Chad M.S. Steel:         Chad M.S. Steel(Chad M.S. Steel@SECURITY) DRF Entry:     SECURITY\Administrator       Administrator(Administrator@SECURITY) 

• After a DRA on a file has been identified, that account, if available, can be used to decrypt the contents.

• Obtain a certificate file for either the DRF or DDF entries as listed above. Certificate files with the private key included can be exported from Windows with a default extension of .PFX. These files can then be imported into the certificate store on the system used for analysis to permit access to files encrypted by those users. Some users will export .PFX files to either have a backup copy of their certificate or to use the same certificate on multiple systems. Searching the suspect's drives for .PFX files may yield the needed certificate. The Certificate Manager of the Microsoft Management Console can be used to view and import certificates. A sample Certificate Store is shown below in Figure 4-6. To import a new certificate, right-click the existing store and select All Tasks Import. The wizard will then walk the user through importing a certificate. (In most Windows builds, double-clicking a .PFX file will automatically import it.)

Figure 4-6: Microsoft Certificates storage location

Note 

The Certificate Management option may be available directly from the Control Panel. If it is not, open the Management Console by typing mmc; then select Add/Remove Snap-In from the File menu and select the Certificates snap-in to add.

• Search for the unencrypted data at a physical level. Even though a file may be encrypted, remnants of the file or the whole file may exist on the drive. When an encrypted file is created, the original data is duplicated into an encrypted form. The original data may still be present from this process. Likewise, the file itself may be recoverable from the paging file, from temp files or from other unallocated sectors where fragments or old versions may reside.

Tip 

When an encrypted file is opened by an application, unencrypted temp copies may be generated by that application.

Identifying encrypted files can be down with the Windows cipher command. This command also allows for the command line encryption and decryption of files. The cipher command can be used to encrypt, list, and then decrypt a file as follows:

 C:\Test>cipher   Listing C:\Test\   New files added to this directory will not be encrypted. U report.htm C:\Test>cipher /E /A   Encrypting files in C:\Test\ report.htm          [OK] 1 file(s) [or directorie(s)] within 1 directorie(s) were encrypted. 

Converting files from plaintext to ciphertext may leave sections of old plaintext on the disk volume(s). It is best to use the command cipher /W:directory to clean up the disk after all converting is done.

 C:\Test>cipher   Listing C:\Test\   New files added to this directory will not be encrypted. E report.htm C:\Test>cipher /A /D   Decrypting files in C:\Test\ report.htm [OK] 1 file(s) [or directorie(s)] within 1 directorie(s) were decrypted. 

In the preceding example, the "E" next to the file name indicates an encrypted file. To find all encrypted files on a drive, the command cipher /S:C: /N can be used. The /S:C: switch denotes a recursive search of the C: drive. The /N switch denotes a "no touch" searchDDF and DRFs will not be updated with the search.

As with compression, encryption is an NTFS-specific feature. When the encrypted file or directory is moved to a non-NTFS partition by a user with the appropriate access rights, the encryption will be turned off.

CASE STUDY: FTP HACKER

While running a web development organization, one of my team's tasks was to build and install development and staging servers for client projects. The servers were generally built by systems engineers , but occasionally a developer would build a box when resources were tight. One of the developers built a Windows NT 4.0 box with IIS for development then imaged that same build and deployed it on our external gateway for staging (we utilized our staging environment for customer acceptance testing as well as internal testing).

One of the common criticisms of Windows and security is its poor installation choices out-of-the-box. This was a conscious choice by Microsoft. (Microsoft Windows 2003 represents a shift in strategy; this operating system defaults to having everything off and requires the user to explicitly install needed functionality.) Users did not want to install functionality piecemeal; they wanted it all installed and would theoretically turn off functionality they did not need when they hardened the system, although in reality this rarely happened . Because of this, unused and exploitable functionality was frequently present on systems built by the less security conscious. The default installation of IIS is no exception to this rule. FTP, installed with the web server, allows anonymous access to the machine. Anonymous access and an Internetaccessible server was a recipe for disaster.

Our system engineers responded to developer complaints of disk space issues on the client staging server. As part of our build procedures, we would create a separate partition that only contained the wwwroot and ftproot directories, the locations where web and FTP traffic were located. A complaint of space being in short supply generally meant that one of the developers had started using the partition to share their MP3s. A routine cleansing of the offending directories would generally do the trick.

When the system engineer arrived at the machine, there were only two directories present on the partition and free space was at 10KB out of 20GB available. The developers did not generally use that much space. A quick check of directories in Windows Explorer showed the wwwroot directory was using 12MB and the ftproot directory had the remainder of that space used. Looking into the ftproot directory there was a single subdirectory present titled PRN. A check revealed a directory size of zero, with zero files present (the number of files and folders was not even visible) similar to that shown in the following figure. This was very unusual since the parent directory had hundreds of files and almost 20GB of used space.

Looking under the PRN subdirectory revealed an entire subdirectory after subdirectory, all with names like "COM1;PRN", "+TAGGED BY PYRO+", and "(((1 M 3LEET)))." Following the chain revealed directories containing DIVX version of several recent movies, cracked version of popular software, and some pornographic images. Fearing the machine had been hacked, the security team was called in.

PRN directory size

When we arrived, we first took a look at the upstream router and noted several current FTP connections. We took the machine off the network to prevent further damage and began our analysis. A quick look at the FTP logs revealed several independent IP addresses had attempted anonymous connections, succeeded in connecting, then copied and deleted a filed labeled 1ktest . A day after the first of these connections, the same IP address reconnected and created the directory structure present then proceeded to upload several pieces of the offending content. Over the next several days, another individual had found and uploaded content as well. This was followed by a massive downloading by hundreds of different IP addresses.

A check on the development box (which was never Internet accessible) showed that anonymous FTP was enabled. Since the staging server was built from the development image, this was likely how it had been configured as well. A hash comparison of the system partition to the development box to the system partition on the staging server showed no unusual discrepancies. The machine itself was not compromised, only its FTP partition.

The IP addresses which were primarily responsible for uploading returned addresses in several foreign countries with somewhat lax intellectual property and computer intrusion laws. Given the low likelihood of finding the offenders, the embarrassment at disclosing the intrusion, and the lack of permanent damage, the company made the decision to delete the offending content, lock down the configuration, and bring the servers back online.

Initial attempts to delete the offending PRN directory hierarchy using Windows Explorer were unsuccessful, returning the infamous message displayed in the following figure.

Error when deleting the PRN subdirectory

Similarly, attempts to delete the folder using the command prompt also failed:

 C:\ftproot>dir   Volume in drive C has no label.   Volume Serial Number is 8C9D-6FEA   Directory of C:\ftproot 03/01/2005  05:36 PM    <DIR>          . 03/01/2005  05:36 PM    <DIR>          .. 03/01/2005  05:16 PM    <DIR>          PRN               0 File(s)              0 bytes               3 Dir(s)       12,832 bytes free C:\ftproot>rmdir PRN The directory name is invalid. 

A quick refresher on Windows file naming conventions revealed the directories that violated those conventions. The ftp interface used the full UNC paths when creating them, bypassing the Windows checks for domain names. By doing so, PRN (a reserved name for the printer device) and COM1 (a reserved name for the first serial port) were able to be used as names for the directories. To delete them, the respective UNC names had to be used from the command prompt:

 C:\ftproot>rmdir \.\C:\ftproot\PRN 

After the folders had been removed, the machine was brought back online and new build requirements, including a security signoff by a systems engineer, were put in place.