Hacking Exposed

by Aaron Philipp

  RegistryKey.txt

  Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTOR

  Disk&Ven_Kingston&Prod_DataTraveler_2.0&Rev_1.00e01000000000000000000297&0

  Device ParametersMediaChangeNotification

  Class Name:

  Last Write Time: 12/18/2008 - 7:33 AM

  Identifying the Windows Version

  In many investigations, you may find it necessary to learn which version of Windows is running on a suspect’s system, because many version-specific features and forensic remnants exist in Windows that can be properly viewed only when the version is known. Making conclusions on Windows artifacts without knowing the version of Windows can lead to mistakes.

  How to Identify the Windows Version

  Identifying the Windows version involves examining the structure of the Windows directory and looking for the system’s registry.

  You can gather information about which Windows version you have by viewing the CurrentVersion registry key with a registry viewer. Values such as the CurrentBuild, ProductName, and even the InstallDate are available here. Several free registry viewer tools are available on the Internet, as well as tools that convert the decimal value of the InstallDate to a date/time format if needed. Remember to take time-zone differences into account.

  Registry Path:

  HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersion

  System Times

  Discovering the last time a suspect shut down a system can be important in some cases. Specifically, if a suspect alleges not to have used the system during a specific period, or, in some cases, if a suspect is alleging that a system was in fact in active use, this information can help make a case. Checking system times can also help identify whether anyone else logged into the system after the suspect shut it down, or if an administrator or someone else tampered with the evidence. Trusting a suspect’s word implicitly is not as reliable as checking out the system yourself.

  Determining the Last Time a System Was Shut Down

  In Windows 2000 and later, you can determine the last time the system was shut down by viewing the last written time of the registry hive key $$$PROTO.HIV.

  You can also determine when the system was last shut down by examining the SysEvent log file in an event viewer. Sort the log by date/time and look for the last entry with the Event ID: 6006, which is an ID for shutdown.

  Event Log Locations:

  Windows 2000 and XP WindowsSystem32Config

  Windows Vista WindowsSystem32ConfigWindowsSystem32winevtLogs

  The system registry also contains a Shutdown Time. The value is located within the following key: HKLMSYSTEMCurrentControlSetControlWindows. The binary value will need to be converted to a usable date/time format. Another method is to navigate to this same registry key, right-click it, and export it as a text file instead of a registry file. This way you can obtain the key’s Last Write Time.

  RegistryKey.txt

  Key Name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlWindows

  Class Name:

  Last Write Time: 12/17/2008 - 9:18 AM

  For Windows 98 and earlier versions, you must rely on your own ability to determine whether the last dates of files being written to on the disk are feasible. This is a reliability issue, however, as file dates can be changed.

  Determining the First Time a User Logged In

  You can determine the first time a user logged into a system by viewing the creation date of the user’s directory.

  Determining the Last Time a User Logged Out

  In Windows NT 4.0 and later, you can determine the last time a user logged out by viewing the modification date of the ntuser.dat file in the user’s documents and settings directory. With Windows Vista, you would look in the Users directory instead of documents and settings directory.

  Office Document Metadata

  While Office is not part of Windows, it is the most common document creation application in use. Whenever an Office document is created, certain attributes and hidden data fields are placed in the document automatically. Many times, a suspect will delete a stolen Office document, and your ability to prove certain arguments, such as when or by whom it was created, can only be proven by data stored within the document itself.

  Discovering the Properties of Deleted Office Documents

  If you are able to recover an entire Office 97 or later document from the unallocated space, you can load the document into the Office application and view its properties. Or, if your forensic application supports it, such as EnCase, you can view the metadata within your forensic environment. Otherwise, if you can recover only a fragment of the original document, you will need to have access to utilities such as the OLE/COM Object Viewer from Microsoft to view the properties of the COM objects that the Office document contained. You will not always be able to recover the metadata from a fragment, but many times you will.

  OleViewer.exe is included as part of Visual Studio and is located in the ..toolsbin directory, or you can obtain a copy by downloading a Windows Resource Kit. Do an Internet search for “Windows Server 2003 Resource Kit Tools” or visit the following link: www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-bl8c479Ocffd.

  Discovering the MAC Address of the System that Wrote a Word Document

  Loading a Word document for any version of Office 97 and later (up to, but not including, Office XP) into a text editor that is not Word will show you the raw binary data in the document. Search that document for the keyword PID_GUID, and after some other data appears, you will see a bracket-enclosed piece of Unicode text:

  { 1 0 4 A 8 A 2 2 - 6 2 3 B - 1 1 D 4 - 8 8 D D - 0 0 D 0 B 7 1 B 0 4 C 4 }

  The string 0 0 D 0 B 7 1 B 0 4 C 4 is the MAC (Media Access Control) or the hardware address MAC assigned to an Ethernet card. The Ethernet MAC is important to us because it allows us to tie the creation of a document to a particular user’s system. This is powerful evidence in showing that a user was involved or directly responsible for some activity.

  Dr. Watson: Problems Reports and Solutions

  Whenever a program crashes in Windows NT, 2000, or XP, the error handler called Dr. Watson creates a memory dump of the current system. If your case has at issue events that would have existed only in memory while the user experienced a crash, finding these files could provide valuable evidence.

  In Windows Vista, Dr. Watson was replaced with the Problems Reports and Solutions Feature. See the following link for more information: http://technet.microsoft.com/en-us/library/cc709644.aspx.

  Recovering a Memory Dump

  A file called user.dmp, if it exists, contains a dump of the physical memory on the system. In Windows Vista you would look for the dump file at %SystemRoot%MEMORY.DMP. Before you can work with the file, it must be converted, since it has null characters in between each character in the file. Once these null characters are removed, you can search the file to find any of the data you would hope to find in memory, such as Internet history, viewed file contents, opened files, and accessed processes.

  Determining Programs a User Has Run (Windows 2000 and Later)

  When a user executes a program or accesses certain types of files in Windows 2000 and later, a built-in Windows function records his or her actions. Often, when tools such as wipers, encryption programs, and other so-called anti-forensic tools are used, you will want to identify those tools. You should always check UserAssist keys to identify user actions and programs executed when they are of relevance to a case.

  UserAssist

  UserAssist is a feature of Windows 2000 and later that is not well documented or well understood by the public. It tracks the use of applications, shortcuts, and other items by frequency of use and time last used. It works like built-in spyware, because it captures the actions of a user until someone or something removes the entries from the registry or disables logging as with the Privacy feature in Windows Vista. UserAssist entries
are encrypted, but lucky for us investigators, they are encrypted with ROT13! The following shows an example of what a UserAssist entry looks like encoded:

  HRZR_EHACNGU:P:CEBTEN~1ZVPEBF~2Bssvpr10BHGYBBX.RKR

  And here’s a decoded UserAssist key:

  UEME_RUNPATH:C:PROGRA~1MICROS~2Office10OUTLOOK.EXE

  UserAssist keys can be found in the registry under HKEY_CURRENT_USER SoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist.

  In this registry key, you will find two subkeys, and within these are programs and web pages that the user has executed or visited. To recover UserAssist entries from the unallocated space, search for HRZR_, which is a static entry in all UserAssist entries.

  For more information about UserAssist, read “Understanding the UserAssist Registry Key” at www.accessdata.com/downloads/media/UserAssist%20Registry%20Key%209-8-08.pdf. Many free ROT13 converters are available on the Internet. To take a look at the UserAssist utility available for download, visit http://blog.didierstevens.com/programs/userassist. In addition, many forensic tools can view or search for ROT13 within their environments.

  CHAPTER 7

  LINUX ANALYSIS

  In recent years, Linux has become the third most popular operating system, behind the Microsoft Windows platform and Apple’s OS X. Linux users love its stability and the “close to the metal” feel they get from using it. The majority of scripted hacks and vulnerabilities are written to run under Linux, which means as an investigator you may spend a lot of time unwinding attacks that script kiddies and sophisticated hackers alike were trying to launch. Luckily, Linux is copiously documented, and you can easily find references on common attacks and procedures hackers use as well as how they try to cover their tracks. The other edge of the sword, however, is that a criminal can easily modify the OS to hide data, implement trap doors, and launch other kernel-space operations that are very difficult to unwind. Add to this the hundreds of arcane commands that exist, just waiting to be trojaned, and you can see why an investigation of a Linux system can be a daunting task.

  THE LINUX FILE SYSTEM (EXT2 AND EXT3)

  Much like Windows uses NTFS and FAT, Linux has its own file system structure. For older versions of Linux, data is stored on an ext2 format partition. Newer versions use ext3 or ext4, which is functionally identical to ext2 with the addition of journaling. (More on that later in the section “ext3/ext4 Structure.”) As a practical matter, an ext file system also exists, but it’s so old that it was deprecated about the time that Minux became Linux and is rare to find in use today. You may also run across other, more exotic, file systems, such as the encrypted file system (EFS), and those will be covered in more detail in Chapter 9. For now, we will focus on the ext2, ext3, and the Linux swap formats.

  ext2 Structure

  The layout of ext2 is heavily based upon UNIX file system concepts. The disk is divided into partitions that are subsections of the disk. These partitions are then further divided into groups, which are nothing more than partitions of the partition, and they help to break up the clustering. Each group contains a superblock, a group descriptor, a block bitmap, an inode bitmap, an inode table, and finally data blocks, in that order.

  Superblock

  The superblock stores all the metadata about the file system. Each group has its own superblock, and a master superblock stores the data about the entire file system. This block is vital to system operation since it is read when the file system is mounted. If this block becomes corrupted, the file system will no longer mount. If you think a system’s superblock has been knocked out, you can re-create it, since Ext2fs utility stores a copy of the superblock in each group. When you run Ext2fschk, it checks for superblock consistency and repairs it if necessary.

  Some versions of Linux, such as those that run on 68K platforms, use a byte-swapped file system to compensate for little-endian versus big-endian formats. Make sure you are aware of the type of platform you are working with.

  Group Descriptors

  The group descriptor, as its name suggests, contains information about the group. Within the group descriptor is the table of inodes and the allocation bitmaps for inodes and data blocks. This allocation bitmap is of huge importance to the investigator, since it tells the file system which blocks are used and which aren’t. When a file is deleted, the allocation bitmap changes the state of the blocks used by the file to unallocated. This does not mean that the data in the blocks has been deleted. You can use the blocks along with the inode table to reconstruct a file that has supposedly been removed from the disk.

  Inodes and File Structure

  Files are represented by inodes, and directories are simple files that contain a list of entries and pointers to the files that can be found in said directory. To understand the inode structure, you can think of it as a sort of hierarchical chart. Each inode points to a set of data blocks that contain the data in the file. Fifteen pointers to data blocks are inside each inode. If you do the math, you will see that this is not a sufficient number of blocks for any reasonably sized file. Thus, only 13 blocks are used to hold data. If the file is bigger than 13 blocks, the 14th block is used to hold a pointer to a new “indirect block” that gives 13 more slots. If that still isn’t enough, the 15th block is used to point to a “doubly indirect block” that stores pointers to other blocks that themselves have 15 slots. You can see how this gets confusing fast. Figure 7-1 may help to clarify the picture and shows you how the inodes link together in ext2.

  If you do any substantive work with file recovery under Linux, understanding this inode structure inside and out is a must. Later in this chapter, when we talk about recovering data, we will look at how to use inodes to recover previously deleted files. As an aside, the linked structure of this system has some significant performance increases as well. Since the smaller files are so close to the inode root in the hierarchy, they are accessed more quickly than the larger files. As the following table shows, the majority of files on a disk are small enough to fit into this category.

  As you may have guessed, the ext2 file system has inodes flying around all over the place. To consolidate all of this into one logical data structure, the inode table was created.

  Figure 7-1 The inode structure of ext2

  Directories

  Using a system that requires the end user to refer to files by their inode numbers would be nearly impossible for the user. (Think about your daughter trying to access her school paper named 15332. Good luck remembering that.) As such, we need a way to tie a filename to an inode number. Enter the directory. As stated earlier, directories are nothing more than files that store pointers to the files contained in the directory. To clarify, take a look at Figure 7-2.

  A special directory on the ext2 is /, the root directory, located at the top of the hierarchy. So that the hierarchy can be found when the system is rebooted and the file system remounted, the root directory node is stored in a constant location, namely the second inode. From this directory entry, the entire file system can be re-created. A subdirectory is nothing more than a link to the file that contains the directory entry for said subdirectory. Two special entries exist in each directory:. (a dot) and .. (two dots). These are the identity and previous pointers, respectively, and they are created when the directory is created and cannot be deleted.

  Figure 7-2 Directories linking to file inodes

  ext3/ext4 Structure

  The ext3/ext4 is commonly referred to as “ext2 + journaling.” Journaling is a concept used to protect the structure of the files by changing the read/write process on the disk into an atomic transaction. This means that either all the data gets written to disk or none of it does. The majority of file system failures occur when a disk crashes midwrite and loses half of the information that it was writing to disk. To prevent this, a journaling OS uses an atomic write and has the file system first write to a buffer, or journal. Once in the journal, a transaction flag is set, which says the disk is in midwrite. After all the data has bee
n successfully written to the disk, the transaction flag is cleared and the data is wiped from the journal. If something should happen midwrite, the next time the file system mounts, the system will see the transaction flag and recommit all the data in the journal, assuming that something happened in the process. This is important from a forensics standpoint: You should always check the journal to see whether something that was supposed to be written wasn’t written. Conversely, by mounting one of these journaled file systems, you will change the disk, and any hashes you made of the disk will no longer be valid.

  Linux Swap

  Linux supports swaps in two forms: as a swap file or as a swap partition. If the swap is stored as a partition, the kernel uses the disk blocks to act as additional memory blocks for program usage (a memory paging system, to be semantically correct). This format is nothing more than an array of blocks. While this was never meant to be human-readable, it can be accessed with raw search tools that can search for keywords and binary sequences in the blocks themselves. This can be useful in memory and file-reconstruction.