作業系統鑑識

1. 作業系統鑑識 Windows 蔡一郎 2010/11/23

2. 大綱 • Vista, Windows 2008 (R2), Windows 7 • MBR and VBR • NTFS Reparse Points • Change Journal • Transactional NTFS • Last Access Dates • ExFAT • Windows Event Logs • Directory Structure Changes • Public Folders • File Virtualization • Registry Virtualization • Registry Changes and Additions • Recycle Bin. • Superfetch • Volume Shadow Copy • BitLocker. • Appendix – Lots more. Disk Partitions Volume BitLocker Fvevol.sys File Systems NTFS, FAT32, EXFAT OS Artifacts

3. VBR & NTFS Both VBR & NTFS partition is now located at sector 2048, not sector 63. Common location for VBR using a hard drive with 63SPT. (PS63) New location of VBR (PS2048)

4. NTFS - Reparse Points • Volume mount points - similar to Unix mount points, where the root of another file system is attached to a directory. This allows additional file systems to be mounted without requiring a separate drive letter (like C: or D:) for each. • Directory Junctions - similar to Volume Mount Points, however directory junctions reference other directories in the file system instead of other volumes. • Hard Link - Allows a user to create multiple links to the same data. • Symbolic Link – is different than a hard link because it can point to files & folders and objects on other volumes or network shares. • A symbolic links is resolved differently than a directory junction. • Windows processes symbolic links on the local system, even when they reference a location on a remote file server. • Windows processes directory junctions that reference a remote file server on the server itself. • Symbolic links on a server can therefore refer to locations that are only accessible from a client, like other client volumes, whereas directory junctions cannot.

5. Change Journal - $USNJRNL • The USN Journal is a NTFS logging mechanism that logs various transactions that occur on the file system. • This feature is available in Windows 2000, Windows XP and Windows Server 2003, but it is disabled by default. • In Vista, Server 2008 (R2), Windows 7 this feature in enabled by default, thus causing a verbose log to be created of various file system changes. • These changes are written to an internal NTFS metadata file named “$USNJRNL” and specifically into an alternate data stream of that file. • Various artifacts such as filenames, date stamps an MFT record numbers can be located in this journal and it should be inspected and or searched in Unicode when looking for specific filenames.

6. Transactional NTFS - $TxF • $TxF works on top of NTFS to provides transaction logging. • “Transactional NTFS (TxF) allows file operations on an NTFS file system volume to be performed in a transaction. TxF transactions increase application reliability by protecting data integrity across failures and simplify application development by greatly reducing the amount of error handling code.” • Allows a related series of file system changes to be treated and logged as a “transaction.” • NTFS can then commit if the changes are completed successfully, or abort and roll back if they are not.

7. Last Access Dates • The last access dates are no longer updated when a file is accessed. • Microsoft explains that with all the new file system transactional journaling, it was somewhat of a performance hit, so they have disabled them by default. • This feature can be turned off via a registry key. • This default setting obviously has a severe impact on how some types of cases are analyzed and examiners should take great care when using these date stamps as part of their analysis. • HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem\ • Default NOT tracking • Change to tracking ON

8. ExFAT ***New Windows 7 & 2008 R2 *** • Extended FAT file system • “a new file system that is better adapted to the growing needs of mobile personal storage. The EXFAT file system not only handles large files, such as those used for media storage, it enables seamless interoperability between desktop PCs and devices such as portable media devices so that files can easily be copied between desktop and device.” • http://msdn.microsoft.com/en-us/library/aa914353.aspx • The volume header of an EXFAT volume.

9. Windows Event Logs • No more .EVT files now they are .EVTX • Event logs are not stored in • \Windows\System32\config • Old View • Event log files Event logs are stored in • \Windows\System32\winevt\Logs. • New View

10. Windows Event Logs

11. Windows Event Logs Vista, Server 2008 (R2), Windows 7 Windows Server 2003 Application and System log event id DID NOT change. Security Log event id DID change.

12. Directory Structure Changes • Vista, Server 2008 (R2) and Window 7 have new directory structures. • In Windows 2000, XP & 2003 • C:\Documents and Settings folder is where each users profile is stored along with all their personal documents. • In Vista, Windows Server 2008 (R2), Windows 7 • C:\Users is where each users profile is stored. • In the figure to the left you can see several Junctions are now used to redirect information to a different location, such as Documents and Settings folder and the Default User folder. • C:\Documents & Settings ----------------> C:\Users (Junction) • C:\Users\All Users -------------------> C:\ProgramData (Symbolic Link) • C:\Users\Default Users --------------------> C:\Users\Default (Junction)

13. Public Folders • In Windows Server 2003 Server, a folder named All Users was located under the Documents & Settings folder which served as a structure that was accessible by all users. • Changed and is called ”Public”. Any files or folders located under the “public” folder are accessible by everyone. Note that the structure in a live machine is different that what is seen from a forensic view.

14. File Virtualization • File virtualization is an application compatibility technology that redirects file writes from protected storage to per-user locations. This redirection is transparent to applications reading from or writing to the per-user location. • Part of User Access Control—Standard user cannot write to certain protected folders. • C:\Windows • C:\Program Files • C:\Program Data • To allow standard user to function, any writes to protected folders are “virtualized” and written to: • C:\Users\[user]\AppData\Local\VirtualStore

15. File Virtualization • When Files Do and Do Not get Virtualized • 32-bit apps using administrative privileges do Not get virtualized. • 32-bit applications written following new Windows application guidelines do not need to be virtualized. • 64-bit applications must be written and signed following new Windows application guidelines and do not need to be virtualized • Otherwise and attempt to write a file in C:\Program Files, it is silently redirected to a Virtual Store directory for the located inside the current user's account. • To the application, things proceed as normal • Application does not need knowledge of the redirection occurring. • Multi-user systems, each user will have isolated, local copies of redirected files.

16. Registry Virtualization • Registry virtualization is an application compatibility technology that enables registry write operations that have global impact to be redirected to per-user locations. This redirection is transparent to applications reading from or writing to the registry. • HKEY_LOCAL_MACHINE\SOFTWARE - Non-administrator writes are redirect to: HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\ • Location of the registry hive file for the VirtualStore • Is NOT the user’s NTUSER.DAT • It is stored in the user’s UsrClass.dat \Users\[user]\AppData\Local\Microsoft\Windows\UsrClass.dat • Investigation requires the investigator to examine at least two account specific registry hive files for each user account. • NTUSER.DAT • UsrClass.dat

17. Registry Virtualization • Disabled for the following: • 64-bit process. • Non interactive process, such as services • Process that impersonate a user • Kernel Mode process such as drivers • Keys excluded from virtualization • HKEY_LOCAL_MACHINE\Software\Classes • HKEY_LOCAL_MACHINE \Software\Microsoft\Windows • HKEY_LOCAL_MACHINE \Software\Microsoft\Windows NT

18. Registry Changes and Additions • New Registry Hive files: • BCD in \Boot. • Components in \Windows\System32\config. • Transaction support for the registry (TxR). • Registry Transaction Logs allows applications to perform registry operations in a transactional manner. • Stored in the TxR subfolder in \Windows\System32\config with the system registry hives. • Typical scenario: software installation. • Files copied to file system and information to the registry as a single operation. • In the event of failure, registry modification rolled back or discarded.

19. Recycle Bin • [Volume]:\$Recycle.Bin • $Recycle.Bin is visible in Explorer (view hidden files). • Per user store in a subfolder named with account SID. • No more Info2 files. • When a file is deleted—moved to the Recycle Bin—it generates two files in the Recycle Bin. • $I and $R files. • $I or $R followed by several random characters, then original extension. The random characters are the same for each $I/$R pair. • $I file maintains the original name and path, as well as the deleted date. • $R file retains the original file data stream and other attributes. The name attribute is changed to $R******.ext.

20. Recycle Bin

21. Recycle Bin • Holding down shift key while pressing Delete will by pass Recycling Bin. • Can still be configured to be bypassed: • HKEY_USER\”USER SID”\SOFTWARE\Microsoft\Windows\Current Version\Explorer\BitBucket\volume\GUID\NukeOnDelete\o1h

22. Superfetch • The existence of a prefetch file indicates that the application named by the prefetch file was run. • The creation date of a prefetch file can indicate when the named application was first run. • The modification date of a prefetch file can indicate when the named application was last run.

23. Superfetch \Windows\Prefetch

24. Volume Shadow Copy • Volume shadow copies are bit level differential backups of a volume. • 16 KB blocks. • Copy on write. • Volume Shadow copy files are “difference” files. • The shadow copy service is enabled by default on Vista and Windows 7, but not on Windows 2008 or 2008 R2. • Shadow copies reside in the System Volume Information folder.

25. Volume Shadow Copy • Shadow copies are the source data for Restore Points and the Restore Previous Versions features. Also used in can backup operations. • Shadow copies do not contain a complete image of everything that was on the volume at the time the shadow copy was made. • Shadow copies provide a “snapshot” of a volume at a particular time. • Shadow copies can show how files have been altered. • Shadow copies can retain data that has later been deleted, wiped, or encrypted. • vssadmin list shadows /for=[volume]:

26. Volume Shadow Copy \System Volume Information\Syscache.hve

27. Volume Shadow Copy The Volume Shadow Copy difference files are maintained in “\System Volume Information” along with other VSS data files, including a new registry hive.

28. Volume Shadow Copy

29. Volume Shadow Copy

30. BitLocker • System Volume NOT encrypted: • Boot Sector • Boot Manager (bootmgr) • Boot Configuration Data (BCD) • MUI Files • Font Files • Boot Utilities • OS Volume Contains: • Encrypted OS • Encrypted Page File • Encrypted Temp Files • Encrypted Data • Encrypted Hibernation File • Encrypted Crash Dump Files • During installation, Windows 7 creates a “system reserved” volume, which allow you to setup BitLocker. In Vista you had to create a separate 1.5 GB system volume.

31. BitLocker • During installation, Windows 7 creates a “system reserved” volume, which allow you to setup BitLocker. In Vista you had to create a separate 1.5 GB system volume before enabling BitLocker • Vista & Windows 2008 cannot unlock BitLocker volumes created with Windows 7 or 2008 R2. • Must use Windows 7 or 2008 R2 to open (and image) BitLocker volumes from Windows 7 or 2008 R2.

32. BitLocker • Physical level view of the header of the boot sector of the second partition, the BitLocker protected volume: • ëR-FVE-FS (EB 52 90 4E 54 46 53)- Vista & Windows 2008 • ëX-FVE-FS- (EB 58 90 2D 46 56 45 2D 46 53 2D) Windows 7 • Logical level view of the header of the boot sector of the BitLocker protected volume (same physical sector): • Approached at a PHYSICAL level, the BitLocker protected volume will be ENCRYPTED. • While on-line and approached at the LOGICAL level, the BitLocker protected volume will unlocked—that is, appear DECRYPTED

33. BitLocker Viewed or imaged as part of a physical disk, BitLocker volumes appear encrypted.

34. BitLocker To view a BitLocker volume as it appears in its unlocked state, address it as a logical volume.

35. BitLocker

36. BitLocker Image the logical volume to obtain an image of the unlocked volume.

37. BitLocker To Go

38. BitLocker To Go

39. BitLocker To Go Selecting the “I forgot my password” will bring up a window to enter the recovery key.

40. BitLocker To Go

41. BitLocker To Go As with the BitLocker unlock window, selecting “More information” will display the BitLocker recovery key identification.

42. BitLocker To Go

43. BitLocker To Go

44. BitLocker To Go

45. BitLocker To Go The BitLocker To Go device is unlocked and ready for review or imaging.

46. NTFS Internals Information • In NTFS, all file data—file name, creation date, access permissions, and contents—are stored as metadata. • This abstract approach allowed easy addition of file system features during Windows NT's development — an interesting example is the addition of fields for indexing used by the Active Directory software. • NTFS allows any sequence of 16-bit values for name encoding (file names, stream names, index names, etc.). • This means UTF-16 codepoints are supported, but the file system does not check whether a sequence is valid UTF-16 (it allows any sequence of short values, not restricted to those in the Unicode standard). • Internally, NTFS uses B+ trees to index file system data. Although complex to implement, this allows faster file look up times in most cases. • A file system journal is used to guarantee the integrity of the file system—but not individual files' content. Systems using NTFS are known to have improved reliability compared to FAT file systems. • The Master File Table (MFT) contains metadata about every file, directory, and metafile on an NTFS volume. • It includes filenames, locations, size, and permissions. Its structure supports algorithms which minimize disk fragmentation. • A directory entry consists of a filename and a "file ID" which is the record number representing the file in the Master File Table. • The file ID also contains a reuse count to detect stale references. • While this strongly resembles the W_FID of Files-11, other NTFS structures radically differ.

47. NTFS Metafiles Information • NTFS contains several files which define and organize the file system. These metafiles define files, back up critical file system data, buffer file system changes, manage free space allocation, satisfy BIOS expectations, track bad allocation units, and store security and disk space usage information.

48. NTFS Resident vs. non-resident files • To optimize storage for the common case of small data files, NTFS prefers to place file data within the master file table—if it fits, instead of using MFT space to list clusters containing the data. • The former is called "resident data" by computer forensics workers. • The amount of data which fits is highly dependent on the file's characteristics, but 700 to 800 bytes is common in single-stream files with non-lengthy filenames and no ACLs. • Encrypted-by-NTFS, sparse, or compressed files cannot be resident. • Since resident files do not directly occupy clusters ("allocation units"), it is possible for an NTFS volume to contain more files on a volume than there are clusters. • For example, an 80 GB (74.5 GiB) partition NTFS formats with 19,543,064 clusters of 4 KiB. Subtracting system files (64 MiB log file, a 2,442,888-byte $Bitmap file, and about 25 clusters of fixed overhead) leaves 19,526,158 clusters free for files and indices. • Since there are four MFT records per cluster, this volume theoretically could hold almost 4 × 19,526,158 = 78,104,632 resident files.

49. Volume Shadow Copy vssadmin list shadows /for=[volume]:

50. Volume Shadow Copy