Ch6 - Operating System Forensics

Chapter-6
Operating System Forensics
Session Objectives:
At the end of this Session, you will be able to understand Where evidence resides in a Windows System? Conducting Windows Examination. Event Viewer. How to find events in Logs? How to Manage Log Contents? Few Ways to recover Deleted Data. Windows Registry Basics. Forensics of Linux System. Linux system Analysis.
All Rights Reserved. www.sedulitygroups.com
Inroduction__________________________________________
When your initial response indicates that further investigation is warranted, you have two options: You could perform the investigative steps on the evidence media itself, or you could perform forensic duplication of the evidence media, and then perform the investigative steps on a restored image. If you choose to investigate the evidence media itself without creating a forensic duplication, you will be changing the actual evidence, and you will not have a baseline for comparison after your intrusive investigative steps have altered the system. For example, simply viewing a file or directory entry on the evidence system causes information on the system to be changed. But this information could be the key element in establishing the acts of a suspect. On the other hand, if you have created a forensic duplicate of the evidence media, you will always have the original forensic image to restore should your investigative steps accidentally delete or destroy evidence. Therefore, we recommend using a forensic duplication for your investigations. This chapter explores the different ways to investigate Windows systems (NT, 2000, and XP) in an effort to confirm unlawful, unacceptable, or unauthorized behavior. We assume that you have performed the following tasks: 1. Conducted an initial response and confirmed that further investigation is necessary. 2. Consulted with legal counsel. 3. Performed a forensic duplication of the evidence drive, using Safeback, EnCase, or another imaging tool. You will need a formal approach to investigating the system, because a disorganized approach will lead to mistakes and overlooked evidence. This chapter outlines many of the steps you will need to take to unearth the evidence for proving or disproving allegations.
6.1 WHERE EVIDENCE RESIDES ON WINDOWS SYSTEMS___

Before you dive into forensic analysis, it is important to know where you plan to look for the evidence. The location will depend on the specific case, but in general, evidence can be found in the following areas: Volatile data in kernel structures Slack space, where you can obtain information from previously deleted files that are unrecoverable Free or unallocated space, where you can obtain previously deleted files, including damaged or inaccessible clusters The logical file system The event logs The Registry, which you should think of as an enormous log file Application logs not managed by the Windows Event Log Service The swap files, which harbor information that was recently located in system RAM (named pagefile.sys on the active partition) Special application-level files, such as Internet Explorers Internet history files (index.dat), Netscapes fat.db, the history.hst file, and the browser cache. Temporary files created by many applications 2
The Recycle Bin (a hidden, logical file structure where recently deleted items can be found) The printer spool Sent or received email, such as the .pst files for Outlook mail
6.2 CONDUCTING A WINDOWS INVESTIGATION___________

Once youve set up your forensic workstation with the proper tools and recorded the low-level partition data from the target image, you are ready to conduct your investigation. The following basic investigative steps are required for a formal examination of a target system: Review all pertinent logs. Perform keyword searches. Review relevant files. Identify unauthorized user accounts or groups. Identify rogue processes and services. Look for unusual or hidden files/directories. Check for unauthorized access points. Examine jobs run by the Scheduler service. Analyze trust relationships. Review security identifiers. These steps are not ordered chronologically or in order of importance. You may need to perform each of these steps or just a few of them. Your approach depends on your response plan and the circumstances of the incident.
6.3 Reviewing All Pertinent Logs________________________

The Windows NT, 2000, and XP operating systems maintain three separate log files: the System log, Application log, and Security log. By reviewing these logs, you may be able to obtain the following information: Determine which users have been accessing specific files Determine who has been successfully logging on to a system Determine who has been trying unsuccessfully to log on to a system Track usage of specific applications Track alterations to the audit policy Track changes to user permissions (such as increased access) System processes and device driver activities are recorded in the System log. System events audited by Windows include device drivers that fail to start properly; hardware failures; duplicate IP addresses; and the starting, pausing, and stopping of services. Activities related to user programs and commercial off-the-shelf applications populate the Application log. Application events that are audited by Windows include any errors or information that an application wants to report. The Application log can include the number of failed logons, amount of disk usage, and other important metrics. System auditing and the security processes used by Windows are found in the Security log. Security events that are audited by Windows include changes in user privileges, changes in the audit policy, file and directory access, printer activity, and system logons and logoffs.
Any user can view the Application and System logs, but only administrators can read the Security log. The Security log is usually the most useful log during incident response. An investigator must be comfortable with viewing and filtering the output to these logs to recognize the evidence that they contain.
6.4 Event Viewer______________________________________

In Windows XP, an event is any significant occurrence in the system or in a program that requires users to be notified, or an entry added to a log. The Event Log Service records application, security, and system events in Event Viewer. With the event logs in Event Viewer, you can obtain information about your hardware, software, and system components, and monitor security events on a local or remote computer. Event logs can help you identify and diagnose the source of current system problems, or help you predict potential system problems.
Investigators are most interested in the event IDs in the Event column. Each event ID represents a specific type of system event. Experienced system administrators are familiar with the event IDs that are listed in Table given below. ID 516 517 528 529 531 538 576 578 595 608 610 612 624 626 630 636 642 643 Description Some audit event records discarded Audit log cleared Successful logon Failed logon Failed logon, locked Successful logoff Assignment and use of rights Privileged service use Indirect access to object Rights policy change New trusted domain Audit policy change New account added User account enabled User account deleted Account group change User account change Domain policy change
6.4.1 Event Log Types

A Windows XP-based computer records events in the following three logs: Application log The application log contains events logged by programs. For example, a database program may record a file error in the application log. Events that are written to the application log are determined by the developers of the software program. Security log The security log records events such as valid and invalid logon attempts, as well as events related to resource use, such as the creating, opening, or deleting of files. For example, when logon auditing is enabled, an event is recorded in the security log each time a user attempts to log on to the computer. You must be logged on as Administrator or as a member of the Administrators group in order to turn on, use, and specify which events are recorded in the security log. System log The system log contains events logged by Windows XP system components. For example, if a driver fails to load during startup, an event is recorded in the system log. Windows XP predetermines the events that are logged by system components.
6.4.2 How to View Event Logs

To open Event Viewer, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, click Event Viewer. The Application, Security, and System logs are displayed in the Event Viewer window.
6.4.3 How to View Event Details

To view the details of an event, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, expand Event Viewer, and then click the log that contains the event that you want to view. 3. In the details pane, double-click the event that you want to view. 4. The Event Properties dialog box containing header information and a description of the event is displayed. 5. To copy the details of the event, click the Copy button, then open a new document in the program in which you want to paste the event (for example, Microsoft Word), and then click Paste on the Edit menu. 6. To view the description of the previous or next event, click the UP ARROW or DOWN ARROW.
6.4.4 How to Interpret an Event

Each log entry is classified by type, and contains header information, and a description of the event. 6.4.4.1Event Header The event header contains the following information about the event: Date The date the event occurred. Time The time the event occurred. User The user name of the user that was logged on when the event occurred. Computer The name of the computer where the event occurred. Event ID An event number that identifies the event type. The Event ID can be used by product support representatives to help understand what occurred in the system. Source The source of the event. This can be the name of a program, a system component, or an individual component of a large program. 6
Type The type of event. This can be one of the following five types: Error, Warning, Information, Success Audit, or Failure Audit. Category A classification of the event by the event source. This is primarily used in the security log. 6.4.4.2 Event Types The description of each event that is logged depends on the type of event. Each event in a log can be classified into one of the following types: Information An event that describes the successful operation of a task, such as an application, driver, or service. For example, an Information event is logged when a network driver loads successfully. Warning An event that is not necessarily significant, however, may indicate the possible occurrence of a future problem. For example, a Warning message is logged when disk space starts to run low. Error An event that describes a significant problem, such as the failure of a critical task. Error events may involve data loss or loss of functionality. For example, an Error event is logged if a service fails to load during startup. Success Audit (Security log) An event that describes the successful completion of an audited security event. For example, a Success Audit event is logged when a user logs on to the computer. Failure Audit (Security log) An event that describes an audited security event that did not complete successfully. For example, a Failure Audit may be logged when a user cannot access a network drive.
6.4.5 How to Find Events in a Log

The default view of event logs is to list all its entries. If you want to find a specific event, or view a subset of events, you can either search the log, or you can apply a filter to the log data. 6.4.5.1 How to Search for a Specific Log Event To search for a specific log event, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, expand Event Viewer, and then click the log that contains the event that you want to view. 3. On the View menu, click Find. 4. Specify the options for the event that you want to view in the Find dialog box, and then click Find Next.
The event that matches your search criteria is highlighted in the details pane. Click Find Next to locate the next occurrence of an event as defined by your search criteria. 6.4.5.2 How to Filter Log Events To filter log events, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, expand Event Viewer, and then click the log that contains the event that you want to view. 3. On the View menu, click Filter. 4. Click the Filter tab (if it is not already selected). 5. Specify the filter options that you want, and then click OK. Only events that match your filter criteria are displayed in the details pane. To return the view to display all log entries, click Filter on the View menu, and then click Restore Defaults.
6.4.6 How to Manage Log Contents

By default, the initial maximum of size of a log is set to 512 KB, and when this size is reached, new events overwrite older events as needed. Depending on your requirements, you can change these settings, or clear a log of its contents. 6.4.6.1 How to Set Log Size and Overwrite Options To specify log size and overwrite options, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, expand Event Viewer, and then right-click the log in which you want to set size and overwrite options. 3. Under Log size, type the size that you want in the Maximum log size box. 4. Under When maximum log size is reached, click the overwrite option that you want. 5. If you want to clear the log contents, click Clear Log. 6. Click OK. 6.4.6.2 How to Archive a Log If you want to save your log data, you can archive event logs in any of the following formats:

Log-file format (.evt) Text-file format (.txt) Comma-delimited text-file format (.csv)
To archive a log, follow these steps: 1. Click Start, and then click Control Panel. Click Performance and Maintenance, then click Administrative Tools, and then double-click Computer Management. Or, open the MMC containing the Event Viewer snap-in. 2. In the console tree, expand Event Viewer, and then right-click the log in which you want to archive, and then click Save Log File As. 3. Specify a file name and location where you want to save the file. In the Save as type box, click the format that you want, and then click Save. The log file is saved in the format that you specified.
6.5 Event Log Drawbacks_______________________________

The default Security event log settings for Windows are to log nothing at all. This means that, by default, Windows systems do not log successful logons, files accesses, shutdowns, and many other important events. This can make investigating Windows systems a challenge. One of the difficulties with Windows logging is that Event Viewer allows you to view only a single record at a time. This often makes reviewing Windows system logs rather time-consuming and difficult. Another more perplexing and serious drawback is that these logs only record the source NetBIOS name, rather than the IP address of the remote system. This makes conclusive identification of remote connections to Windows systems impossible using only event logs! The default settings for Windows event logs restrict each log file to a maximum size of 512KB and a time length of seven days. When the fixed size is reached, the log file is closed, and it must be cleared before you are able to begin logging to that log file again. You can change these options in the Log Settings menu, but remember that the size and time length of each log (Security, Application, and System) need to be set individually. One of the drawbacks of reviewing system logs offline is that the logs populate the Description field by using values from various dynamically linked library (DLL) files. This should not affect offline review of the Security log, since its messages are standard, but the Application log may contain entries that do not have the proper description text messages that correspond to the event ID an application generated. Unless the forensic workstation you use has the exact applications installed as the evidence system, you will be missing much of the explanatory data in the Application log, as shown Below.
Using PsLogList and importing the event logs into Excel or some other spreadsheet application, as described in the previous section, makes it easier to review the logs and create reports.
6.6 What Can Happen__________________________________

You are performing offline review of a systems Application log, and you see an entry made from the systems anti-virus software. The problem is that your forensic workstation is unable to populate the Description field on the entry to determine what message the virus scanner was communicating.
6.7 Where to Look for Evidence_________________________

During your review of the Application log from the restored image, keep track of the applications that logged events that require the descriptive messages from the Registry. To translate the seemingly useless numbers into the proper descriptive messages, you will need to get a copy of the System Registry hive file from the restored image. This files default location is in the \%systemroot%\System32\Config directory. Import the System hive by using Regedt32. Make sure to name the imported hive appropriately so you do not confuse it with the local Registry of the forensic workstation. Locate the EventMessageFile key for the application for which you need a description. This key is usually found in the CurrentControlSet\Services\EventLog\Application subkey of the imported hive. You can either identify the entries and descriptions you are looking for or import all of these keys into the forensic workstations Registry. (But remember that its easier to simply boot the forensic duplicate into its native operating system to review the logs or to use the forensic image.) 10
6.8 IIS Logs__________________________________________

If you are investigating a Windows server that runs Internet Information Services (IIS), you will need to review the log files for each IIS service, especially the web server. These logs are ordinarily located in the \%systemroot%\System32\LogFiles directory, in the corresponding subdirectories of each service. For IIS, the default log filename is based on the current date, in the format exyymmdd.log. A new log file is generated each day. The default format for IIS logs is the W3C (World Wide Web Consortium) Extended Log File Format, a standard format that many third-party utilities interpret and parse. Other available formats include IIS logging, which provides a fixed ASCII format, and ODBC (Open Database Connectivity) logging on Windows 2000 systems, which sends a fixed format to a specified database. Here, we will look at the W3C logging, which is in a format that allows logs to be written hourly, daily, weekly, or monthly. You can activate and configure IIS logging through the Web Site Properties settings of the IIS Manager. The default log file stores the time, client IP address, method (GET, POST, and so on), URI stem (the requested resource, or page), and HTTP status (a numerical status code). IIS logging is enabled by default (unlike Security event logging), so these log files probably will be present. Most of the log fields are self-explanatory, but the HTTP Status field requires some explanation. In general, any code in the 200 to 299 range indicates success. The common 200 code indicates that the client request was fulfilled. Codes in the 300 to 399 range indicate actions that need to be taken by the client to fulfill a request. This usually means an automatic redirection, such as when a web sites content moves to another location. Codes in the 400 to 499 and 500 to 599 ranges indicate client and server errors, respectively. Among the two most common 400 series codes are the 404 code, indicating that the requested resource is not found on the server, and the 403 code, indicating that retrieving the requested resource is forbidden.
6.9 Reviewing Relevant Files____________________________

Determining the files that harbor evidence of an attack or misuse on Windows systems can be a cumbersome, exciting, and daunting task. There is usually trace evidence somewhere on the system that helps to confirm or dispel your suspicions. The hard part may be finding it. Windows systems write input and output to so many files at a time that almost all actions taken on the system leave some trace of their occurrence. Windows has tempfiles, cache files, a Registry that keeps track of recently used files, a Recycle Bin that maintains deleted files, and countless other locations where runtime data is stored. It is important to recognize files by their extensions as well as by their true file headers (if possible). At a minimum, you need to know what .doc, .tmp, .log, .txt, .wpd, .gif, .exe, and .jpg files are. Although EnCase provides viewing capability for many file types, it doesnt cover everything. So, even if youre using this forensic utility, you may also need a comprehensive file viewer, such as Quickview Plus (by JASC Software). Quickview and similar file viewers ignore the file extensions, thus the name of a file does not trick the application.
11
Popular third-party software can augment the monitoring and record keeping a Windows system performs. You hit a jackpot every time your incidents occur on a system running a host-based firewall. Third-party firewall software provides fantastic audit trails for investigators to piece together incoming and outgoing network activity on a system. Most personal firewall applications record every web site a system visits, trap viruses, and provide an audit trail for every known attack on the system. This certainly makes reconstructing events easier.
6.10 Incident Time and Time/Date Stamps_________________

The goal for an investigator is to know which files might be relevant to the current incident. The most common manner in which this is accomplished is by determining the time-frame in which the incident occurred, and then scrutinizing those files created, modified, or accessed during this timeframe. The files touched during the relevant timeframe provide the information required to determine which files were stolen, executed, removed (if placed in the Recycle Bin), or uploaded to a system. As basic as reviewing time stamp information is, it almost always becomes a critical piece of any adequate response. You will need to scour network-based logs or use oral testimony (remember the totality of the circumstances!) to identify a range of time when an incident must have occurred. If these two methods do not enlighten you, then review of the target system often reveals action daysdays when relevant activities took place. Once you identify these active, relevant timeframes, it is always a good idea to review the time/date stamps encapsulated within those timeframes. (Realize that you arbitrarily determine the timeframe you want to review.) The files that were modified, created, or changed during the time that the suspicious event took place can be considered relevant files. As explained in Chapter 5, you can use the dir command to get a directory listing that includes file access, modification, and creation times. Review of the files created, modified, and accessed during an incident usually leads to reconstruction of the incident. If you perform this task from a controlled boot floppy, you can use NTIs file-listing tool (FileList), which can checksum all the files on a system for you. The FileList tool lists all directories and files, along with their last access time, modified time, and creation time. When reviewing the Application log of a victim system called HOMER, you encounter the following line: 3/4/03 3:38:43 PM 1 0 257 AlertManager N/A HOMER NetShield NT: The file C:\Inetpub\scripts\04.D on HOMER is infected with the virus BackGate. Unable to clean file. Cleaner unavailable or unable to access the file. You realize that this entry is probably the result of a web server hack, because the BackGate virus (really a backdoor that allows remote access) was introduced into the system in the C:\Inetpub\scripts directory. This is the default directory for web server scripts on IIS 4 and IIS 5 web servers.
12
6.11 Where to Look for Evidence________________________

You know the exact time of the attack, in system time. Thus, you can search for all files modified, accessed, or deleted during this timeframe to reconstruct the incident. To confirm that the HOMER system was a victim of a web server attack, you peruse the web Investigating Windows Systems 305 server logs in the %systemroot%\System32\LogFiles\W3SVC1 directory. Remember that these IIS logs are recorded in Universal Time (similar to Greenwich Mean Time, or GMT). A quick review of the ex030304.log file reveals the telltale sign of the IIS Unicode attack. 20:37:44 44.153.22.11 GET /scripts/../../winnt/system32/attrib.exe 502 20:37:54 44.153.22.11 GET /scripts/../../winnt/system32/cmd.exe 502 20:38:07 44.153.22.11 GET /scripts/../../winnt/system32/tftp.exe 502 20:38:20 44.153.22.11 GET /scripts/E.asp 200 20:38:32 44.153.22.11 GET /scripts/../../winnt/system32/attrib.exe 502 20:38:47 44.153.22.11 GET /scripts/../../winnt/system32/cmd.exe 502 Notice that the time is approximately seven hours later than the system time. Now that you have confirmed that the web server was indeed a victim of an attack, you can use find to identify all the files accessed at approximately 3:43:00 to perhaps 04:43:00. A search on the victim server reconstructs the following events that took place on the system after the attacker initiated the web server attack (all times translated to GMT for standardization). Date 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 3/4/2003 Time (GMT) 20:37:30 20:37:44 20:37:54 20:38:07 20:38:20 20:38:20 20:38:22 20:38:22 20:38:23 20:38:23 20:38:24 20:38:27 20:38:28 20:38:28 20:38:29 20:38:30 20:38:30 20:38:31 Action cmd.exe run using Unicode Exploit (return 200) attrib.exe run using Unicode Exploit (return 502) cmd.exe run using Unicode Exploit (return 502) Tftp.exe run using Unicode Exploit (return 502) E.asp run using Unicode Exploit (return 200) dl.bat created 00.D created (install.bat) 01.D created (dir.txt) 02.D created (firedaemon.exe) 03.D created (login.txt) 04.D created (MMtask.exe) (BackGate-anti-virus detected?) 05.D created (newgina.dll) 06.D created (reggina.exe) 07.D created (regit.exe) 08.D created (restrict.exe) 09.D created (restsec.exe) 10.D created (settings.reg) 11.D created (SUD.exe)
As this table shows, you can determine the actions taken by an attacker by reviewing the time/date stamps.
13
6.12 Proprietary Email Files_____________________________

Email is often the correspondence of choice for suspects you are investigating. The most common email clientsOutlook, Netscape Messenger, and AOLeach has its own roprietary format. When reviewing the email sent or received by a suspect, you must use the appropriate client software to view the suspects email. In other words, you must copy the proprietary files from the restored media that correspond to the sent and received email, and then view them with the appropriate client software. Otherwise, you will be reviewing the email with a text editor, which is not going to yield a complete and accurate conclusion.
6.13 Netscape Messenger Mail:__________________________

Netscape maintains mail messages in a plain text file. You will find these files in the mail directory of the appropriate profile directory. If Netscape is installed in the default location and the profiles are stored in the default location, you will find the Netscape Messenger files in \Program Files\Netscape\Users\<User Account>\Mail. Each Netscape mailbox has two files to support it: an index file (with an extension of .snm) and a message-text file (with no extension). Thus, each mail folder in Netscape is stored as a single file. The inbox is stored as a file named Inbox, and sent messages are stored as a file named Sent. To view the contents of these files, open the files in WordPad or any other text editor. Review of the index files (.snm) is rarely necessary.
6.14 Microsoft Outlook Mail:____________________________

Microsoft Outlook maintains mail messages in a proprietary format. Typically, Outlook files on Windows 2000 systems are stored in the Documents and Settings\<User Account>\Local Settings\Application Data\Microsoft\Outlook directories. You are looking for the *.pst filesthe Personal Folders files. These files are locally stored archives of the Outlook data for the specific user account. The .pst files can archive all folders within Outlookthe Calendar, Deleted Items, Drafts, Inbox, Journal, Notes, Outbox, Sent Items, and Tasksexcept the Contacts folder. Since the user can configure the archived *.pst files to be located anywhere on the drive, you may need to search around a bit. To view another systems .pst files, copy them to your forensic workstation and then open the files using the Outlook Client. Select File | Open | Personal Folders File (.pst) and browse your forensic workstation to load the target Outlook archive file (the suspect .pst file).
6.15 Deleted Files and Data_____________________________

There are numerous occasions when incident response requires the recovery of lost files that might have been deleted by malicious users to cause damage or simply erased by those who wish to cover up their misdeeds. In this section, we examine the different ways to obtain files that, for all intents and purposes, suspects would believe no longer exist. These deleted files are often the ones that make or break your investigation, so your techniques of data recovery must be exceptional! 14
6.15.1 In general, there are four ways to recover deleted data:

Using undelete tools. Restoring files located in the Recycle Bin. Recovering .tmp files Using low-level tools to repair the file system. Undelete Tools As you probably know, deleted files are not truly deleted; they are merely marked for deletion. These files will remain intact until new data has overwritten the physical area where these deleted files are located on the hard drive. This means that the sooner you attempt to undelete a file, the better your chances of success. Most commercial undelete utilities require the use of the native operating system, and they will restore the files in place. This is a bad practice. As the number of files recovered in place increases, the likelihood of recovering a damaged file or file fragment diminishes, because you are overwriting currently unallocated space that may contain valuable information. One tool that performs undeletion on the NTFS file system is File Scavenger. File Scavenger can undelete files as long as the space they occupy on the hard drive has not been used by more recent I/O storage. File Scavenger may work even after the disk has been reformatted. Realize that some utilities can be set to prevent the deletion of files. For example, Norton Utilities Protect is an undelete utility that acts as a replacement for the Recycle Bin. Protect can be configured to protect all deleted files, including files deleted under a command prompt, and to automatically delete them after a specified number of days. When a suspect system is booted into its native operating system, you may detect that a suspect has protected her deleted files from undeletion using Norton Utilities Protect or a similar utility.
6.16 Temporary Files__________________________________

Many applications such as web browsers, email clients, and other types of end-user programs create temporary files to function properly. You would think with a name like tmp, the file would be deleted or removed from a system when the application that created the file terminated. However, that is not the case. For example, if you have recently received email messages with large attachments, it is possible that nearly all the attached files are stored as temporary files. A review of all files with a .tmp filename extension may reveal year-old documents that were deleted, old PowerPoint presentations, and files that were received as attachments.
6.17 Backup File Recovery______________________________

Probably the most cumbersome yet most reliable way to recover lost data is to find the most current backupof the system and then attempt to locate the relevant files. The evidence that is missing from the system you are investigating can often be found on one of the backup tapes. Windows systems ship with powerful backup tools. For example, Windows NTs NTBACKUP.EXE is a GUI tool that creates a log file recording the date of the backup, how many files were backed up, how many files were skipped during the backup process, how many errors were recorded, and how long the backuptook to finish. To determine whether a backupwas recently made of the restored image, search for BACKUP.LOG, or simply *.log, and determine whether it was created by NTBACKUP. Also, never hesitate to ask a client about the existence of any system backups.
15
6.18 The Swap File____________________________________

The swap file is a hidden system file that is used for virtual memory. When the system becomes too busy for the amount of memory in a system, the swapfile is used to function temporarily as RAM. The operating system will swap out the lesser-used portions of RAM to free space for more active applications. The swap file is usually about twice the amount of RAM on a system. The pieces of memory swapped to the hard drives swap file are called pages (as in page swapping). The swapfile may contain fragments of text from documents, passwords, and other tidbits of information that a user recently viewed or typed on his system. The key is that the user may not realize that the data is there. The swap files on Windows systems are named pagefile.sys. (The permanent swap file in Windows 9x is called win386.swp.) Figure 12-8 shows a file monitoring tool capturing a system writing megabytes of data to the swap file. Since the swapfile is a hidden system file, you must first allow your system to display hidden files. You can use dir /ah at the command line, or you can set Windows Explorer to view hidden files by choosing Tools | Folder Options and selecting the Show Hidden Files and Folders option. This will allow you to view inactive swap files. Viewing a live swapfile is a difficult task, and we do not know of any publicly available software that provides this ability. Therefore, if you want to view the swap file offline, it is important to make sure that pagefile.sys is not cleared if the system needs to be gracefully powered down (something that may happen with Oracle or SQL Server machines; you do not want to just yank the power cord on these, because that can corrupt the database records). Since pagefile harbors cached information that power users may not want you to be able to review, they can configure their Registry to have the pagefile cleared before the system gracefully shuts down. Review the following key to determine whether the pagefile will be cleared on shutting down the system: HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\ClearP ageFileAtShutdown A zero means the swapfile is not overwritten at shutdown, which is the default setting. A one signifies that all inactive pages are overwritten with zeros during shutdown. This still leaves some swapfile left for forensic examination, but consider yourself lucky if you find anything useful. On Windows 2000, a user can enable a local policy called Clear Virtual Memory Page File When System Shuts Down, accessed through Local Security Settings | Local Policies | Security Options. This setting works the same as the ClearPageFileAtShutdown key in the Registry. Looking for leads in the swapfile by viewing it with hex editors or some other viewer is extremely time-consuming. Most of the contents are in binary format and may not be very helpful to you. It is probably sufficient to perform a string search on the swap file to obtain evidence.
6.19 Broken Links_____________________________________

Another important step is to check for broken links on the system. We already discussed using the Registry to determine the software installed on a system and perhaps find trace evidence of applications that were removed improperly. Checking links can also help you determine what software had been on a system? 16
Links are used to associate a desktop shortcut or a Start menu item with an application or a document. Manually removing applications or documents does not remove the links that were created for them. Users may delete files but forget to delete the desktop icon on the system. The NTRK tool chklnks.exe is excellent for unearthing files that were once installed but now are nowhere to be found. As shown below, chklnks finds dead (broken) links.
Links are also important when considering network connections and shortcuts. Average users have desktopshortcuts for their ISP dialupconnections and other network connections. Check out the users \%systemroot%\Profiles\<user>\Desktopdirectory and review all the links (*.lnk) for that users desktop applications.
6.20 Web Browser Files________________________________

Employees need access to the Internet at work, but many companies do not want their employees spending the majority of their work hours shopping, surfing, trading stocks, chatting, or downloading pornography on company systems. These activities require the use of web browsers. Web browsers such as Netscape and Internet Explorer maintain log files. Both browsers record browsing history and track sites that were recently visited. They also maintain a cache that contains a certain amount of the actual files and web pages recently viewed. Netscape and Internet Explorer History Files. The Netscape history file, netscape.hst, is normally located in the \Program Files\Netscape\Users\<username> directory. Netscapes fat.db file maintains an even longer history of browsing activity, and it is usually located aware of Netscapes history file, and individuals who wish to hide their cyber-shenanigans (using their browser to visit inappropriate sites) often erase this file or clear it via the Netscape Preferences settings. However, the fat.db file is often overlooked and is an excellent source for tracing browser use. All Rights Reserved. www.sedulitygroups.com 17
For the initial response, you can simply use the about:cache URL to review the contents of the fat.db. Internet Explorer maintains its temporary Internet files in the \Documents and Settings\<UserId>\Local Settings\Temporary Internet Files directory. The index.dat file holds the viewer history. The actual HTML and files are stored in the Internet Explorer cache files, usually found in the \WINNT\Temporary Internet Files directory on Windows NT systems. Windows 2000 maintains the web browser cache in \Documents and Settings\<User Account>\Local Settings\Temporary Internet Files. The index.dat file in Windows 2000 that maps cached HTML pages to actual dates, times, and specific URLs is located in the \Documents and Settings\<User Account>\Application Data\Microsoft\ Internet Explorer\UserData directory. Netscapes fat.db and netscape.hst files and Internet Explorers index.dat file are binary files. Therefore, you must use a special utility to view them. The Internet Explorer History Viewer tool allows you to view most of the binary files maintained by both Netscape (fat.db and netscape.hst) and Internet Explorer (index.dat). Pasco, a free forensic utility written by Keith Jones of Foundstone, allows the examination of Internet Explorer cache files. (Keith Jones also wrote several other free forensic utilities to view the contents of cookie files and the INFO2 file.)
6.21 Looking for Unusual or Hidden Files_________________

All bad guys want to hide something, and computer criminals are no different. Once an attacker gains unlawful access to a Windows system, she needs to hide her files for later use. Once an insider chooses to perform unauthorized or unacceptable deeds on his system, he may choose to make a few files invisible. Both of these attackers can take advantage of NTFS file streams to hide data behind legitimate files. Unfortunately, how to stream files is common knowledge to the computer-savvy bad guy (or gal). NTFS has a feature, originally developed on the Macintosh Hierarchical File System (HFS), to store multiple instances of file data under one file entry. These multiple data streams may be used to hide data, because Windows Explorer does not indicate the presence of the additional streams. Figure 12-12 shows how our trusty friend netcat (nc.exe) can be hidden in a secondary data stream of a file called logo.jpg by using the following command: cp nc.exe logo.jpg:nc.exe Notice in the figure how the presence of the nc.exe within the logo.jpg file entry is not reflected by the file size, but the time/date stampis altered. It is critical to run the SFind or Streams utility on the restored file system. In Figure shown below, you can see that SFind identified a streamed file. The usage for the SFind utility is as follows: Programming by JD Glaser - All Rights Reserved Usage - sfind [path] /ns [dirpath] Directory to search - none equals current -ns Skip sub-directories - or / Either switch statement can be used -? Help COMMAND PROMPT MUST HAVE A MINIMUM WIDTH OF 80 CHARACTERS
18
Other commonly used methods to hide files within the logical file system include changing the file extension or creatively naming the files to match those of important system files. Neither of these methods should throw off an experienced examiner, but they can fool some popular automated forensic tools.
6.22 Remote Control and Remote Access Services_________

Some of the most common remote-access points into a Windows system are dial-in utilities such as PC Anywhere, Windows native Remote Access Service (RAS), and similar utilities that allow dial-in or network-based command-level access. We divide remote access of Windows systems into two classes: those that allow remote control and those that allow remote access. The difference between the two is mainly the amount of network traffic and performance speeds. Applications such as PC Anywhere, AT&Ts Virtual Network Computing (VNC), and Reach Out allow remote control. With these applications, the remote user takes absolute control over the system, including the keyboard, screen, and mouse. When the screen changes on the remote system, you actually see the screen change on the local system that is being controlled. To detect remote-control software on the system, use netstat, Fport, and PsList to find the open ports. You can also peruse the file system to determine whether the remote-control software has been installed.
19
Remote-control applications allow only a single remote user to control the system at a time. Thus, attackers prefer to connect to a service that allows remote access, rather than remote control. Windows RAS enables remote access, where multiple remote users can simultaneously connect to the system via a modem connection. RAS is a favorite access point for the ex-employee who wants to maintain access to his prior employers network. This is because RAS is the only remote-command-level access that comes standard with Windows NT Server systems. Windows NT Server is capable of handling 256 incoming RAS connections right out of the box. Use the tool rasusers to list all the user accounts that have the privilege to log in to the RAS server. We issue the net start command without any arguments to view all the running services: Net start If a system is offering RAS, you will see this service being offered when you issue the net start command.
6.23 Administrative Shares_____________________________

Windows uses the term share to refer to any file or folder that is accessible over a network through Windows networking. A user can share a directory with any other user who has the authority to connect to that users system. Choosing to share a folder with remote systems is simple: just select a directory you wish to share, right-click it, and choose Sharing from the pop-up menu. If you see an icon of a hand underneath a folder that means that the directory is shared with remote users who have the proper credentials to log on to that share. It would seem a user who decides not to share a folder is not creating an access point for attackers. However, this is not the case. Windows systems have administrative shares, which are shares that are automatically offered to remote users after each boot process. These administrative shares are considered hidden shares, and they all have the $ character appended to their names. The idea that they are hidden provides a false sense of security; realistically, attackers know what the hidden shares are. The most exploited share seems to be IPC$, but each logical drive also becomes an administrative share. To remove these administrative shares permanently, a user would need to do Registry surgery, which the vast majority of users are unarmed and unprepared to do. Thus, many attackers will scan for port 139 on a system and then attempt to connect to administrative shares on that system. Remember that if a remote user can authenticate and access any of the administrative shares, she will be able to access all the files on that logical drive. Unless the user has installed the NTFS file system and selected to audit File and Object Access events for the particular share, Windows will not log when files are accessed by a remote user.
6.24 Reviewing Searches and Files Used__________________

One of the first steps to take when an employee is leaving the company is to see what the last few searches on her system were.Asimple way to do this is to look at the scroll box in the Find dialog box. 20
It is also a good idea to immediately review the files in the Recycle Bin to determine whether the employee deleted anything that was critical to the company or obfuscating the fact that she had files that she should not have been able to access. Use AFind (a tool from Foundstone) to determine all the files accessed in the last few days prior to departure. Or, use dir output to search on time/date stamps. Finally, perform a quick review of the most recently used files by using the GUI interface or viewing the Registry.
6.25 AccessData Registry Viewer________________________

AccessData Registry Viewer allows you to view the contents of Windows operating system registries. Unlike the Windows Registry Editor, which displays only the current systems registry, Registry Viewer lets you view registry files from any system. Registry Viewer also provides access to a registrys protected storage, which contains passwords, usernames, and other information not accessible in Windows Registry Editor.
6.26 Registry Viewer Overview__________________________

Registry Viewer provides several tools for obtaining and reporting important registry information. The Full Registry view shows all the contents of a registry file, while the Common Areas view displays only those sections of the registry most likely to contain significant data. From either view, you can select keys and subkeys to add to a report. The Report view displays these selected keys, allowing you to print only relevant information. All views also contain two detail panes: a Key Properties viewer and a hex viewer. The Key Properties viewer displays any property values associated with a selected key, while the hex viewer displays a selected value in hexadecimal format. Dongle Restrictions Registry Viewer requires a dongle to access all of the program features. If a valid dongle is not installed when you start Registry Viewer, the program runs in Demo mode.
In Demo mode, the following program features are disabled:
Common Areas view Report view Generate Report function Decryption and interpretation of protected storage areas
21
Note: The dongle is checked only at program startup; putting in or taking out a dongle during a session does not switch from Demo mode to Full mode. You must restart Registry Viewer in order to switch between Demo and Full program modes.
6.27 Windows Registry Basics__________________________

The Windows registry is a set of data files that allows the Windows operating system to control hardware, software, user information, and the overall functionality of the Windows interface. For forensic work, registry files are particularly useful because they can contain the following important information: Usernames and passwords for programs, e-mail, and Internet sites A history of Internet sites visited, including the date and time for each A record of Internet queries (i.e., searches performed on Internet search engines like Google, Yahoo, etc.) Lists of recently accessed files (e.g., documents, images, etc.) A list of all programs installed on the system The files that make up the registry differ depending on the version of Windows. The tables below list the registry files for each version of Windows, along with their locations and the information they contain. Version 98/ME File Name Location system.dat \Windows Contents Protected storage for all users on the system All installed programs, their settings, and any usernames and passwords associated with them System settings Most recently used (MRU) files
user.dat 2000/XP ntuser.dat Default SAM Security Software
System
\Windows \Windows\profiles\useraccount \Documents and Settings\user Protected storage for the user account Most recently used (MRU) files User preference settings \Winnt\system32\config System settings \Winnt\system32\config User account management and security settings \Winnt\system32\config Security settings \Winnt\system32\config All installed programs, their settings, and any usernames and passwords associated with them \Winnt\system32\config System settings
When you open one of these files in Registry Viewer, a registry tree appears in the left pane of the Full Registry view. The tree is organized in a hierarchical structure, similar in appearance to the folder and file structure of the Windows file system. Each registry entry, denoted by a folder icon, is called a key. Some keys contain subkeys, which may in turn contain other subkeys. 22
When you select a key, the top-right pane displays the keys values or the information associated with that key. Each value has a name and data type, followed by a representation of the values data. The data type tells you what kind of data the value contains as well as how it is represented. For example, values of the REG_BINARY type contain raw binary data and are displayed in hexadecimal format. The following table lists the possible data types: Data Type REG_BINARY Description Raw binary data displayed in hexadecimal format. Most hardware component information is stored as binary data. REG_DWORD Data represented by a number that is four bytes long (a 32-bit integer). Many parameters for device drivers and services are this type, and are displayed in binary, hexadecimal, or decimal format. Related values are: DWORD_LITTLE_ENDIAN (the least significant byte is at the lowest address) REG_DWORD_BIG_ENDIAN (the least significant byte is at the highest address) REG_EXPAND_SZ A variable-length data string. This data type includes variables that are resolved when a program or service uses the data. REG_MULTI_SZ A multiple string. Entries are separated by spaces, commas, or other marks. Values that contain lists or multiple values in a format that people can read are usually this type. REG_SZ A fixed-length text string. REG_NONE Data with no particular type. This data is written to the registry by the system or application, and is displayed in hexadecimal format. REG_LINK A Unicode string naming a symbolic link. REG_QWORD Data represented by 64-bit integer. REG_RESOURCE_LIST A series of nested arrays designed to store a resource list used by a hardware device driver or one of the physical devices it controls. This data is detected by the system and is displayed in hexadecimal format as a binary value. REG_RESOURCE_REQUIREMENTS_LIST A series of nested arrays designed to store a device drivers list of possible hardware recourses it, or one of the physical devices it controls, can use. This data is detected by the system and is displayed in hexadecimal format as a binary value. All Rights Reserved. www.sedulitygroups.com 23
REG_FULL_RESOURCE_DESCRIPTOR
A series of nested arrays designed to store a resource list used by a physical hardware device. This data is displayed in hexadecimal format as a binary value.
6.28 Opening and Closing Registry Files__________________

You can have only one registry file open at a time in Registry Viewer. If you want to open another file, you must first close the current file or open another instance of Registry Viewer. To open a registry file: 1 Select File, and then Open from the menu. 2 In the Open dialog, locate and select the registry file you want, and click Open. You can also drag-and-drop a registry file into Registry Viewer to open it, or open a recently used file by selecting File, and then the filename from the menu. To close a registry file, select File, and then Close from the menu. Opening Files from a Hard Drive Image Computer forensics often involves work with exact, bit-by-bit copies of the contents of a device, or image files. To view registry files of a device without affecting the original contents, you create an image, export it from the device, and analyze it on a separate system. If you integrate Registry Viewer with AccessData Forensic Toolkit (FTK), you can extract and open image registry files at the same time. FTK automatically identifies the registry files available within the image for selection to view. Upon selection, FTK automatically creates a temporary registry file that you can then view in Registry Viewer; when youre finished, FTK deletes the temporary file. For more information, see Integrating the Forensic Toolkit or see the Forensic Toolkit documentation. Searching The Find option allows you to quickly search keys, values, and data for the next occurrence of a specified text string. Registry Viewer provides three ways to perform live searches for specific information in a registry file: a quick search, an advanced search, and a search by last written date. Using the Find Option Find searches only in the currently open view. If you want to search the entire registry file, you must search from the Full Registry view. Likewise, if you want to search only in common areas, you must search from the Common Areas view, and so forth.
24
To use the Find option: 1 From the menu, select Edit, and then Find. The Find dialog appears. 2 In the Find What field, enter the text string for which you want to search. 3 Select the registry file areas you want to search. Mark the Keys checkbox to search for the specified string in all key names. Mark the Values checkbox to search for the specified string in all value names. Mark the Data checkbox to search for the specified string in all value data. Mark the Match Whole String Only checkbox to find only data that matches the entire specified string.
4 Click Find Next to search for the specified string. When Registry Viewer finds a match
to the specified string, it expands the registry tree and highlights the key that contains the matching data. To search for the next instance of the specified string, select Edit, and then Find Next from the menu, or press F3. Using the Advanced Search Option The Advanced Find option lets you search for and view all instances of a specific text string. You can also add the search results to the Report view.
25
To use the Advanced Find Option: 1. From the menu, select Edit, and then Advanced Find. The Advanced Find dialog opens. 2. In the Find What field, enter the text string for which you want to search. 3. In the drop-down box, select the registry area you want to search: Full Registry, Report Items, or Common Areas. 4. Mark the registry file items you want to search: Mark the Keys checkbox to search for the specified string in all key names. Mark the Values checkbox to search for the specified string in all value names. Mark the Data checkbox to search for the specified string in all value data. 5. Check Match Whole String Only to find only data that matches the entire specified string. 6. Click Search to look for all instances of the specified string. Registry Viewer displays all keys that contain matching data in the results list. The total number of found keys is displayed at the upper-right corner of the list. To add keys in the Results list to the Report view: Mark the checkbox next to the keys you want to add. To checkmark all listed keys, click the checkmark button. To uncheck all marked keys, click the empty button. Click Add to Report. The marked keys are added to the Report view at the root level. Click Clear Results to clear all found keys from the Results list. When finished, click Done. Using the Search by Date Option The Search by Date option lets you search for keys based on the date they were last written to the registry file. You can add found keys to the Report view. To use Search by Date to search for keys: 1. From the menu, select Edit, and then Search by Date. The Search by Last Written Date dialog appears. 2. Select the date range you want to search. Select during a Date Range to search for keys last written between two specified dates. Select During and After a Given Date to search for keys last written on or after a specified date. Select During and Before a Given Date to search for keys last written on or before a specified date. 3. In the Search In drop-down box, select the registry area you want to search: Full Registry, Report Items, or Common Areas. 4. In the date fields, enter a date, or click the drop-down arrow to select a date from the popup calendar. 5. Click Search to look for all keys last written in the specified date range. Registry Viewer displays all matching keys in the Results list. The total number of found 26
keys is displayed at the upper-right corner of the list. To add keys in the Results list to the Report view: Mark the checkbox next to the keys you want to add. To checkmark all listed keys, click the checkmark button. To uncheck all marked keys, click the empty button. Click Add to Report. The marked keys are added to the Report view at the root level. Click Clear Results to clear all found keys from the Results list. When finished, click Done. Using the Full Registry View The Full Registry view displays all the contents of the open registry file. A Windows registry is made up of multiple files. Because Registry Viewer opens one file at a time, it does not display the whole registry but only the information contained in the currently open file. The Full Registry view is the default view when opening a file.
Using the Common Areas View The Common Areas view helps you quickly access those areas of a registry file most likely to contain information important to you. Unlike the Full Registry view, which displays all the contents of a registry file, the Common Areas view shows only those keys, such as usernames, passwords, browser history, which you have marked in other registry files as forensically interesting. Note: Registry viewer provides some customizable common areas by default. Of course, the various files that make up a registry contain different information, so the keys and subkeys that appear in your Common Areas view depend upon whether they exist in the newer registry file as well.
27
To view the Common Areas, select View, and then Common Areas from the menu.
Adding Keys to the Common Areas View Registry Viewer keeps track of each key you add, remembering them between registry files and sessions. Keys that have been added to the Common Areas view are identified by a folder icon overlaid by a green key To add a key to the Common Areas view: 1. Select View, and then the Full Registry from the menu. 2. In the registry tree, locate and select the key you want to add. 3. Select Edit from the menu, and then Add to Common Areas. Removing Keys from the Common Areas View Registry Viewer keeps track of each key you remove. The folder icon no longer appears next to the key. To remove a key from the Common Areas view: 1. In the Common Areas view, locate and select the key you want to remove. 2. From the menu, select Edit, and then Remove from Common Areas. Using the Reports View The Report view lists the keys you add to a report in the order you add them. You can reorder keys in the tree by dragging them up or down. You can also remove keys from the Report view. When you are finished, you can generate a report file containing all the selected keys and their associated information. To view the Report view, select View, and then Report Items from the menu.
28
Adding Keys to the Report View Keys added to the Report view are not saved between sessions or registry files. To save a record of this information, you must generate a report file or a summary report before closing the registry file or exiting Registry Viewer. Keys that have been added to the Report view are identified by special folder icons in the registry tree: Keys added individually are denoted by. Keys added with children are denoted by. Keys added as children of a parent key are denoted by.
To add a key to the Report view:
1. Open the view that contains the keys you want to add. To open the Full Registry, select View, and then Full Registry from the menu. To open the Common Areas, select View, and then Common Areas from the menu. 2. In the registry tree, locate and select the key you want to add. 3. Add the key to the Report view by doing one of the following: From the menu, select Report, and then Add to Report. From the menu, select Report, and then Add to Report with Children. Note: In the Common Areas view, if you select the Common Areas root item in the tree, this option becomes Add Children to Report. Each child key (with its subkeys) under the Common Areas root item is added individually to the Report view. Because each key is added at the main level of the Report tree, you can also remove individual keys. For more information on removing keys, see the following section Removing Keys from the Report View.
The selected key is added to the Report view at the root of the Report tree.
29
Removing Keys from the Report View You can remove keys from the Report view. You can remove only keys at the main level of the Report tree. You cannot remove individual subkeys. To remove a key from the Report view: 1. In the Report view, Full Registry view, or Common Areas view, locate and select the key you want to remove. 2. From the menu, select Report, and then Remove from Report. To remove all keys from the Report view, select Report, and then Clear All Report Entries from the menu. Generating a Report After you have finished adding keys to the Report view, you can generate a printable, HTML report file containing all the selected keys and their associated information. To generate a report file: 1. From the menu, select Report, and then Generate Report. The Create Report dialog appears. 2. In the Report Title field, enter a title for the report. 3. In the Report Location field, enter the location where you want to save the report file or click Browse to navigate to the directory location. The default location for report files is \AccessData\AccessData Registry Viewer\Report. 4. In the Report Filename field, enter a filename for the report file. The name of the current registry file is entered by default. 5. Mark the Reduce Excess Data Output checkbox to limit the data displayed for a value or string to the first 17 bytes. In the generated report, you can view the additional data for a value or string by moving your cursor over the Data field. A popup displays the complete data. 6. Mark the Also Show DWORD Values as Timestamps checkbox to display timestamp equivalents for all DWORD values. Timestamps are displayed in both UTC and local time formats. 7. Mark the Show Key Properties Only checkbox to include the items displayed in the Key Properties pane. 8. Mark the View Report when Created checkbox to automatically open the newly created report file (Index.htm) in your Internet browser. 9. Click OK to generate the report file. If you integrate Registry Viewer with AccessData Forensic Toolkit (FTK), Registry Viewer uses the case report location defined in FTK as the default location for the generated report. For more information, see Integrating the Forensic Toolkit or see the Forensic Toolkit manual. Generating a File-types Report Registry Viewer lets you create a report that identifies all the file-type information stored in the currently open registry file. A files type indicates what kind of information is stored in the file. Each file type is associated with one or more filename extensions (e.g., .txt, .doc, and .htm) and with the programs that can open those files. To generate a file types report:
30
1. From the menu, select Report, and then Generate File Types Report. The Create File Types Report dialog appears. 2. In the Report Title field, enter a title for the report. 3. In the Report Location field, enter the location where you want to save the report file, or click Browse to navigate to the directory location. The default location for report files is \AccessData\AccessData Registry Viewer\Report. 4. In the Report Filename field, enter a filename for the report file. The name <current registry file>-filetypes is entered by default. 5. Mark the View Report when Created checkbox to automatically open the newly created report file (*.htm) in your Internet browser. 6. Click OK to generate the report file. Defining a Summary Report In addition to creating reports by adding keys to the Report view, Registry Viewer gives you the option to define summary reports. Summary reports differ from those created in the Report view in three important ways: You add individual key values to a summary report definition. Unlike the Report view in which adding a key automatically adds all the values contained in that key, a summary report definition allows you to select and add individual key values from any key in the registry file. Summary report definitions allow you to create reports that contain only those key values of forensic interest. You can also create multiple summary report definitions for the same registry file, each targeted to a different area of an investigation. You can group the added key values into user-defined sections. In a summary report definition, key values can be grouped in up to ten different sections. When the summary report is generated, grouped key values appear together under a specified section heading. You can use sections to combine information from different areas of a registry file. For example, you can group together all the key values containing information about a specific user (e.g., username, visited Internet Websites, and MRU lists). Summary report definitions are saved between registry files and sessions. Registry Viewer automatically saves the summary report definitions that you create. You can use these saved definitions again and again to generate summary reports from different registry files. The resulting reports contain the same key values, grouped in the same sections, but the actual information associated with those values is, of course, specific to each registry file.
31
To define a summary report: 1. Open the view that contains the key values you want to add. 2. In the registry tree, locate and select the key that contains the values you want to add. 3. Select Report from the menu, and then Define Summary Report. You can also right-click the key and select Define Summary Report from the quick menu. The Define Summary Report dialog opens. 4. In the Summary Report Title field, enter a name for the summary report definition. The name of the selected key is entered by default. The Summary Report Title appears in the Summary Reports dialog and is also the filename for all reports generated with this definition. Be sure to choose a descriptive, easily identifiable name. 5. Define wildcard keys, if needed. A wildcard key allows you to add key values to the summary report definition for keys that may exist in the current registry file. There are two types of wildcard keys: a wildcard that finds the specified key values in any of the direct subkeys of a selected parent key, and a wildcard that finds the specified key values in the selected key and any of its descendants. For more information, see Adding Wildcard Keys to a Summary Report. 6. In the Summary Key registry tree, locate and select a key that contains key values you want to add. The keys values are displayed in the Available Items list. 7. If you want to group added key values into sections: Select the appropriate section number (110) from the drop-down list. You must define sections sequentially (i.e., define section 1 first, then section 2, and so forth). 7b In the Section Title field, enter a name for the section. This is the name that appears as the section heading in a generated report, so be sure to choose a descriptive name.
32
8. Add specific key values to the summary report definition by doing any of the following: Select a key value in the Available Items list and click Add Value. Press the Ctrl button and click to select multiple key values. Click Add Value to add all the selected values to the report definition. To add all the key values in the Available Items list, click Select All, and then Add Value. The key values appear in the Included Items list. 9. Select Match any item, then click Add Value to add a key-value wildcard to the summary report definition. A key-value wildcard reports all values for the selected key, even if those values change in name or number between registry files. For example, you can use a key-value wildcard to return all the values in the MUICache key, even though the number and names of those key values (program paths, links, etc.) are unique to each registry file. 10. Click Add Unlisted Value to specify a value for the selected key that is not available in the current registry file. In the Add an Unlisted Value dialog, type the name of the key value, then click OK to add it to the summary report definition. For example, if you know that a software key often contains a Version value, but that value is not present in the current registry file, you can still add it to the summary report definition using the Add Unlisted Value option. If you then use the summary definition to create reports from other registry files, the Version value is reported whenever it is present. 11. To remove key values from the Included Items list, do one of the following: Select a key value and click Remove Value. Click Remove All to remove all key values in the list. 12. Click Preview Report to generate and view a printable HTML report file from the summary report definition. Preview reports are temporary: they are deleted from memory when you close the browser window. To generate a saved report, you must save the summary report definition and then generate the report from the Managing Summary Reports dialog. 13. When finished, click Save and Close to save the summary report definition, and to exit the dialog. After you have created a summary report definition, you can use the Manage Summary Reports feature to generate and view additional summary report files. Adding Wildcard Keys to a Summary Report When you define a summary report, you add values from specific keys. Because each key has a set name and registry. path, Registry Viewer can locate those keys in any registry file, and include their values in the generated report. Some keys, however, have names that change among registry files. For example, registry files often include username keys, where the name of each key is the name of a user with an account on that system. Because a username key is unique to a specific file, Registry Viewer cannot use its name and registry path to locate similar keys in other registry files. A wildcard key allows you to select and include key values from the subkeys under a selected parent key, even though the number and names of those subkeys change from registry file to registry file. Using a wildcard key allows you to include username key values in a summary report definition. When you add a wildcard key, you select a parent key that contains the subkeys you want to include in the report. You can then add specific key values from these subkeys (or children) to the summary report definition. Each value needs to be added only once for all the subkeys.
33
When you generate the summary report, Registry Viewer uses the parent keys name and registry path to locate all of its subkeys, and display the selected key value information for each one. For example, you may want to a summary report to include password and login key values for each username key in a registry file. In the current file, there are two username keys, peter1 and paul2. Both are children of Users key. To set the wildcard key, you select the Users key as the parent key. You then select the peter1 subkey and add its password and login key values to the definition. When you generate the summary report, Registry Viewer first lists the password and login key value information for peter1, then the password and login information for paul2. Suppose you then use the summary report definition to create a report from a different registry file. In this file, the Users key contains three children: mary1, mary2 and mary3. The generated report lists the password and login information for mary1, followed by the password and login information for mary2, then mary3. If mary3 doesnt have a defined password, This summary report item does not exist in the current registry file displays for that value. To add a wildcard key to a summary report definition: 1. 1 In the Summary Key registry tree, locate and select the parent key of the subkeys you want to include in the report. 2. In the Wildcard Key definition box, select the type of wildcard key you want to add: Match All Immediate Children finds the specified key values in the direct subkeys of only the selected parent key. Match the Entire Subtree finds the specified key values in the selected parent key and any of its descendants. 3. Click Use Currently Selected Key. The full registry path of the parent key appears in the Wildcard Key field. Managing Summary Reports After you have created a summary report definition, you can use the Manage Summary Reports feature to preview and generate a printable HTML report file containing the summary reports selected key values and associated information. You can also edit or delete existing summary report definitions. To manage summary report definitions, select Report, and then Manage Summary Reports from the menu. The Summary Reports dialog lists the available summary report definitions. Previewing a Summary Report When you preview a summary report, Registry Viewer generates a temporary report using the information in the currently open registry file and then displays it in Internet Explorer. Preview reports are not saved; they are deleted from memory when you close the browser window. To preview a summary report: 1 In the Available Summary Reports list, select the report definition. 2 Mark the Reduce Excess Data Output checkbox to limit the data displayed for a value or string to the first 17 bytes. In the generated report, you can view the additional data for a value or string by moving your cursor over the Data field. A popup displays the complete data. 34
1. Mark the Also Show DWORD Values as Timestamps checkbox to display timestamp equivalents for all DWORD values. Timestamps are displayed in both UTC and local time formats. 2. Click Preview. Registry Viewer asks if you wish to include Empty Values in this report. Click Yes to include all defined key values, even if they contain no data. Click No to include only those key values that contain data. 3. Registry Viewer opens the summary report file in Internet Explorer. Generating a Summary Report When you generate a summary report, Registry Viewer uses the selected report definition to extract the specified key values from the currently open registry file. The resulting report is then saved. To generate a summary report: 1. In the Available Summary Reports list, select the report definition. 2. Mark the Reduce Excess Data Output checkbox to limit the data displayed for a value or string to the first 17 bytes. In the generated report, you can view the additional data for a value or string by moving your cursor over the Data field. A popup displays the complete data. 3. Mark the Also Show DWORD Values as Timestamps checkbox to display timestamp equivalents for all DWORD values. Timestamps are displayed in both UTC and local time formats. 4. Click Generate to make the HTML report file. Registry Viewer asks if you wish to include Empty Values in this report. Click Yes to include all defined key values, even if they contain no data. Click No to include only those key values that contain data. The generated file is automatically saved in the \AccessData\AccessData Registry Viewer\Reports folder. A time and date stamp is added to the filename for easy identification. 5 After the report generates successfully, click OK. To view a generated report, select Report, and then View Existing Reports from the menu. Editing a Summary Report Definition Registry Viewer allows you to edit previously created summary report definitions. To edit a summary report definition: 1. In the Available Summary Reports list, select the report definition. 2. Click Edit. The Define Summary Report dialog opens. 3. Edit the summary report definition as needed. 4. Click Save and Close to save your changes. Changes made to a summary report definition are permanent and affect all subsequent reports generated from that definition. Deleting a Summary Report Definition Registry Viewer lets you delete previously created summary report definitions. Deleting a report definition does not delete any summary report files generated from that definition. To delete a summary report definition: 1. In the Available Summary Reports list, select the report definition. 2. Click Delete Registry Viewer asks if you want to permanently delete the summary report definition. 3. Click Yes to delete the definition.
35
Integrating Registry Viewer with Other AccessData Tools AccessData forensic tools generate lists of words from the drive images taken. These word lists are then used to attack passwords and open locked files and systems. Much of the functionality of these tools overlaps, and understanding how the programs work together will help you apply them to your cases. The AccessData Forensic Toolkit (FTK) indexes drive image files from which you can create your wordlists. This index includes all non-encrypted data in registry files such as the System Software and the unencrypted portions of the ntuser.dat file. By itself, FTK cant index encrypted portions of registry files such as the Protected Storage area of the registry files desired. FTK utilizes Registry Viewer to decrypt and obtain word lists from these files. Registry Viewer can also create an individual word list from a single registry file. Use FTK to create your initial indexes and word lists. Use Registry Viewer to access the encrypted areas of ntuser.dat, then add Registry Viewers word list to the larger FTK word lists. One large, comprehensive word list will be easier to manage, and more efficient to apply to your case. Integrating Registry Viewer with the Forensic Toolkit (FTK) Integrating Registry Viewer with FTK allows you to seamlessly view registry files and create registry reports from within FTK. Any created reports are saved by default in the current FTK case report location. Integration also allows you to extract and open registry files on the fly from hard drive images. FTK automatically creates a temporary registry file from the image and opens it in Registry Viewer; after youre finished, FTK deletes the temporary file. To run Registry Viewer from FTK: 1. In FTK, open an existing case by selecting File, and then Open Case. 2. If you have chosen to always display the FTK Startup screen, select Open an Existing Case and then click OK. 3. Select the case you want to open. 4. Select File, and then Registry Viewer. 5. Select the registry file you want to view, and then click View File. 6. If you have located registry files in the case in FTK, you can right-click on a file and then select iew in Registry Viewer. Registry Viewer automatically launches. Updating Index.htm Registry Viewer generates a list of the reports named Index.htm used for reference by the Forensic Toolkit. This list is updated every time you create new report, but must be manually updated when you remove reports from the Report folder. To manually regenerate the Index.htm: 1. Activate the Report menu by opening a file in Registry Viewer. 2. From the main menu, select Report, and then Regenerate Index.htm to update the list of reports currently in your Report folder. Exporting a Word List If you are using PRTK, you can export the case index to use as a dictionary in the password recovery process. To export the word list: 36
1. Select Tools, and then Export Word List. 2. Select the file and location to which you want to write the word list. The default filename is case_name.txt. 3. To add registry files, click Add Files and then select the registry files to add to the word list. 4. Click Save. For more information, see the AccessData Forensic Toolkit Users Guide. Integrating Registry Viewer with the Password Recovery Toolkit (PRTK) Registry Viewer lets you create and export a word list containing all the strings in a registry file. The word list can then be used in AccessData Password Recovery Toolkit (PRTK) as a dictionary for decoding passwords and pass-phrases. Exporting a Word List When you export a word list, Registry Viewer searches the registry file for key values that are stored as strings. Each string it finds is exported into a text file as a separate line. The resulting file contains a list of every string value in the registry. If you save or copy the word list file into the PRTK Dictionary folder (i.e., \AccessData\PRTK6\Dictionaries), PRTK can access the file as a user-defined dictionary. PRTK uses each line in the file as a possible password or pass-phrase in a password recovery operation. To export a word list: 1. From the menu, select Report, and then Export Word List. The Generate Word List dialog appears. 2. Navigate to the directory location where you want to save the word list file. The default path for word list files is \AccessData\AccessData Registry Viewer. 3. In the Filename field, enter a name for the word list file. The file (*.txt) is saved in plain-text format. 4. Click Save to export the word list.
6.28 Forensic Analysis of a Live Linux System, Pt. 1 Mariusz Burdach 2004-03-22
During the incident response process we often come across a situation where a compromised system wasn't powered off by a user or administrator. This is a great opportunity to acquire much valuable information, which is irretrievably lost after powering off. I'm referring to things such as: running processes, open TCP/UDP ports, program images which are deleted but still running in main memory, the contents of buffers, queues of connection requests, established connections and modules loaded into part of the virtual memory that is reserved for the Linux kernel. All of this data can help the investigator in offline examination to find forensic evidence. Moreover, when an incident is still relatively new we can recover almost all data used by and activities performed by an intruder. Sometimes the live procedure described here is the only way to acquire incident data because certain types of malicious code, such as LKM based rootkits, are loaded only to memory and don't modify any file or directory. A similar situation exists in Windows operating systems -- the Code Red worm is a good example of this, where the malicious code was not saved as a file, but was inserted into and then run directory from memory.
37
On the other hand, methods presented below also have serious limitations and violate the primary requirement of the collection procedure for digital investigation -- a requirement which can not be easily fulfilled. That is: every user and kernel space tool used to collect data by nature changes the state of the target system. By running any tools on a live system we load them into memory and create at least one process which can overwrite possible evidence. By creating a new process, the memory management system of the operating system allocates data in main memory and then can overwrite other unallocated data in main memory or in the swap file system. Other problems arise when we plan to take legal actions and need to comply with local laws. The signs of intrusions found in images of main memory can be untrusted, because they could be created by our acquisition tools. So before taking any action we must decide whether to acquire some data from a live compromised system or not. It is very often worth it to collect such information. In the main memory image we can find passwords or decrypted files. Using /proc pseudo file system we can also recover programs that have been deleted but are still allocated in memory. In an ideal world, I could imagine a kind of hardware based solution for Intel-based computers, which would allow us to dump the whole memory to an external storage device without assistance of operating system. Such a solution exits on Sparc machines, whereby we can dump the whole physical memory by using the OpenBoot firmware. Unfortunately, no similar solution exists for Intel- or AMD-based computers. Despite the above problem, software based methods also have advantages for forensic purposes, and I'll try to show them in this paper. The main goal of this article is a presentation of methods used during an evidence collection procedure. All collected data can be used later to perform offline forensic analysis. Some of presented tasks can be also be performed in the preparation and identification phases of the incident response cycle -- these are two of the six phases defined in a guide called "Incident Handling Step by step", published by the SANS Institute.
6.29 Forensic Analysis_________________________________

This article is divided into four related sections: Fitting to the environment Preparing the forensic toolkit media Data collecting from a live system - step by step procedure Initial data analysis and keyword searching
6.29.1 Fitting to the environment

Before gathering data from a live system we have to fit ourselves into the environment. First of all we have to run a network sniffer and it must "see" communication flows to and from a compromised system. This condition is mandatory. We can detect some types of malicious activities just by recording and analyzing, in real time, this communication. The utility tcpdump is excellent tool for this purpose. My advice is to record packets in a raw format because of performance issues that may result otherwise. Before taking any activities on the compromised system we have to create a paper copy of our data collection procedure. An example procedure can be found in chapter three of this article. This procedure helps us to avoid any mistakes during the forensics of an incident. All Rights Reserved. www.sedulitygroups.com 38
We must make additional notes after every finished step as well as if something goes wrong. Documentation is important, and is something to keep in mind if we plan to take our forensic case to court. Our next step is to record the results of commands run during our phase of data gathering. From there, we connect a destination host to the same local area network on which we will be sending information from the compromised host. Remember, we are not allowed to write any results on the compromised system. Recording data locally on the compromised host can delete signs of an intrusion. To make less of an impact on a compromised system we have to send all our digital data to a remote, or destination, host. This is one of the most important rules in the forensic analysis process. And once again, as described earlier this is a requirement that is not always easily to fulfill. If we don't have a forensic toolkit available for install on removable media, now is a good time to prepare it for our compromised system. Using tools from this toolkit we will collect all important data, beginning from the volatile to the less volatile. The following methods describe a method how to prepare our media into a forensic toolkit.
6.29.2 Preparing the forensic toolkit media

It is important to remember that during a data collection process we have to fulfill following criteria: Try not to run programs on a compromised system. Why? An intruder could modify system commands (such as a netstat) or system libraries (such as a libproc), rendering the results unreliable. To fulfill this criteria we have to prepare versions of the tools which are compiled statically. Try not to run programs which can modify the meta-data of files and directories. All results from the investigation must be written to a remote location. To fulfill this criteria we will use the remote host as our destination location. The netcat tool will be used to transfer digital data. You have to use tools to calculate the hash values of the digital data. This is a kind of assurance that the digital data has not been altered. A best practice is to make sure that data is not altered and is properly saved on the destination host, so we also will compare hash values calculated on both the source and the destination. Sometimes it's impossible to calculate a hash value on the compromised host -- a good example of this is with main memory. When we try to use md5sum on the /dev/mem device twice in a row, every time the hash value will be different. This happens because every time we load that program into memory (and thus create a new process which needs memory to operate) we change the state of the memory. In our procedure we calculate hash values of digital data immediately after collection is completed, as well as (when possible) on both the source and destination host. To maintain the integrity of all results we will use md5sum tool. The required criteria about preventing our tools from writing data to the memory and even the swap space of the compromised system cannot be fulfilled for some steps. This will be discussed in greater detail in section 2.3. For now, let's ensure we have a proper forensic toolkit on removable media, as showin in Table 1.
39
Table 1: Requirements for a forensic toolkit on removable media. program 1 2 nc dd source & method of creation http://www.atstake.com/research/tools/network_utilities/nc110.tgz How to build: $tar zxvf nc110.tgz; make linux How to verify: file nc or ldd nc http://www.gnu.org/software/fileutils/fileutils.html (added to core utilities) http://www.gnu.org/software/coreutils/ How to build: $ tar zxvf coreutils-5.0.tar.gz; configure CC="gcc -static", make How to verify: file date cat or ldd date cat http://www.porcupine.org/forensics/tct How to build: $tar zxvf tct-1.14.tgz; make CC="gcc -static" How to verify: file pcat or ldd pcat
datecat
pcat
http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt To make the module more "independent" we have to delete the following lines from the source code: #ifdef CONFIG_MODVERSIONS #define MODVERSIONS Hunter.o #include <linux/modversions.h> #endif We can load this module to other kernels by removing the MODVERSIONS. How to build: $ gcc -c hunter.c -I/usr/src/linux/include/ insmod http://www.kernel.org/pub/linux/utils/kernel/modutils/for kernel 2.4 How to build: $./configure-enable-insmod_static; make How to verify: file insmod.static or ldd insmod.static
http://freshmeat.net/projects/net-tools/ NetstatAr How to build: $bzip2 -d net-tools-1.60.tar.bz2; tar xvf net-toolsproute 1.60.tar.bz2; make config; make CC="gcc -static" How to verify: file netstat arp route or ldd netstat arp route dmesg http://ftp.cwi.nl/aeb/util-linux/util-linux-2.12.tar.gz How to build: $./configure; make CC="gcc -static" How to verify: file dmesg or ldd dmesg
When we build all above tools successfully, we can copy all of them to our removable media (such as a CD-RW disc).
6.29.3 Data collecting from a live system - a step by step procedure

The next requirement, and a very important one, is that we have to start collecting data in proper order, from the most volatile to the least volatile data. We have to remember about this during data gathering. 40
Step 1: Take a photograph of a compromised system's screen

This is a kind of screenshot, and of course we have to use a digital camera to do this task. This is a simple step. Before moving on to step two, mounting our media, let's first think about the impact this next step will have on a compromised system. What will be an effect of our activity? For the moment let's ignore the impact it will have on the compromised system's memory. It is clear that we have to mount external media into the compromised system. We must use the untrusted mount command to perform this task. This will be probably the sole situation when an untrusted system command is used. If everything will go according to the plan, we will run the rest of the command from the mounted media using tools that we trust. We also have to check to see what the impact of the mount command will have on the system. I have done some research on a computer, and Table 2 lists the relevant files and directories that are modified.
# strace /bin/mount /mnt/cdrom
Table 2: Files accessed by the mount command. File /etc/ld.so.cache /lib/tls/libc.so.6 /etc/fstab /etc/mtab* /dev/cdrom Modified Meta-data by the mount command atime atime atime atime, mtime, ctime atime
/usr/lib/locale/locale-archive atime
/bin/mount atime *We can avoid access to this file by using a "-n" switch. We can imagine a situation when an intruder modifies the mount command. When someone tries to run this command perhaps a special process, which removes all evidence from the compromised system, is initiated instead of allowing the media to be mounted. Such a process is called a "deadman switch". But let's assume this is not the case, and now go back to the process of data collection. I suggest that one verify every command that is going to be put on the forensic toolkit media, which later will be used on the compromised system to collect evidence. We also have to stop and think about potential problems met during the mounting process: After putting the media into a drive, the Volume Manager process will mount the media automatically. Which files and directories will be modified? Are these files listed in the table 1? Suppose an unknown media is currently mounted on a compromised system. Then the first task is to unmount that media. How should we safely unmount it? I can suggest two solutions. We can use the untrusted unmount command or we can put the trusted unmount command (statically linked) on a floppy disc. Next, we use the untrusted mount command to mount the floppy and then run the All Rights Reserved. www.sedulitygroups.com 41
trusted unmount command. It is a little bit complicated but effective. We still use only one untrusted command. An administrator is logged off or even worse an administrator password is changed by an intruder. When the administrator is logged off we have to login into the system. What files will be accessed or modified during the login process? How many additional processes will be created? If the administrator password was changed what are the other accounts on the system? What volatile data can be collected without access to a shell? Open TCP/UDP ports, current connections, what else? Are there other unpredictable problems?
Step 2: Media mounting

Let's go ahead and mount our media, in this case a CD-ROM with our toolkit.
# mount -n /mnt/cdrom
If the mounting process is successful we can start with the most important phase of data collection. Remember, all results generated by trusted commands have to be sent to the remote host. I use the netcat tool and the pipe method to do this. To better differentiate which tasks are performed on which host, all commands run on the compromised host will be prefixed with a (compromised) word in brackets. Commands run on the remote host will be prefixed with a (remote) word in brackets. Consider the following example. To send information about an actual date of the compromised system into the remote location (the IP address of remote host in this case is 192.168.1.100) we have to open TCP port on the remote host as it follows: (Remote host)# nc -l -p 8888 > date_compromised Next, on the compromised host we do the following: (Compromised host)# /mnt/cdrom/date | /mnt/cdrom/nc 192.168.1.100 8888 -w 3 To maintain the integrity of digital evidence we calculate the hash value of the collected file and clearly document every step on our paper copy, to document this procedure. (remote host)# md5sum date_compromised > date_compromised.md5 Sometimes we can generate checksums on the compromised system and send the result to the remote host. A bit more about some of the problems this can cause has been discussed elsewhere in this article.
(compromised host)# /mnt/cdrom/md5sum /etc/fstab | /mnt/cdrom/nc 192.168.1.100 8888 -w 3
Step 3: Current date

The result is presented in the UTC format (Coordinated Universal Time)
(remote)# nc -l -p port > date_compromised (compromised)# /mnt/cdrom/date -u | /mnt/cdrom/nc (remote) port (remote)# md5sum date_compromised > date_compromised.md5
Step 4: Cache tables

First, we have to collect information from cache tables because the lifetime of this data, placed in the tables, is very short. I will collect data from the arp and routing tables. 42
Mac address cache table: (remote)# nc -l -p port > arp_compromised (compromised)# /mnt/cdrom/arp -an | /mnt/cdrom/nc (remote) port (remote)# md5sum arp_compromised > arp_compromised.md5 Kernel route cache table: (remote)# nc -l -p port > route_compromised (compromised) # /mnt/cdrom/route -Cn | /mnt/cdrom/nc (remote) port (remote)#md5sum route_compromised > route_compromised.md5
Step 5: Current, pending connections and open TCP/UDP ports.

Now, we start collecting information about current connections and open TCP/UDP ports. Information about all active raw sockets will be gathered in step eight.
(remote)#nc -l -p port > connections_compromised (compromised)# /mnt/cdrom/netstat -an | /mnt/cdrom/nc (remote) port (remote)#md5sum connections_compromised > connections_compromised.md5
We can use the cat command instead of the netstat one in this case. Information about open ports is kept in the /proc pseudo file system (/proc/net/tcp and /proc/net/udp files). Information about current connections is placed in the /proc/net/netstat file. All data in those files are represented in the hex format. For example: 0100007F:0401 in decimal is 127.0.0.1:1025. As mentioned before, current connections can be detected by analyzing of the recorded traffic. It is important to note: an easy method of detecting a rootkit, loaded into kernel memory, is when one of its tasks is hiding an open port. We have to scan the compromised host remotely and compare the detected open ports with our result from the netstat command. But this causes a lot of harm and we once again change the state of the compromised system, in step seven I will present an alternate method of detecting hidden LKM based rootkits.
6.30 Concluding part one_______________________________

Now that we have the date and the network status logged, we're ready to take some additional steps on the compromised machine before we power it off. Next month, in part two of this article series, we will focus on the search for malicious code by collecting more data to be sent to our remote host. We'll also discuss some of the searching that can be done with the data once we're able to go through it in a safe environment.
6.30.1 Introduction :
FCCU GNU/Linux Forensic Bootable CD is a bootable CD based on KNOPPIX that contains a lot of tools suitable for computer forensic investigatins, including bash scripts.
43
FCCU GNU/Linux Forensic Boot CD's main purpose is to create images of devices prior to analysis, and it is used by the Belgian Federal Computer Crime Unit. Here are some key features of "FCCU GNU/Linux Forensic Boot CD": This CD is based on KNOPPIX by Klauss Knopper. It is a remaster that I made to use at my work as a computer forensic investigator. Its main purpose is to create images copies of devices before analyse. It does not use a lot of CPU cycles for unnecessary programs, which is why it drops you to a shell right after the boot. It recognizes lots of hardware (Thanks to Klauss Knopper). It leaves the target devices unaltered (It does not use the swap partitions found on the devices). It contains a lot of tools with forensic purpose. What's New in This Release? The ability to start in non-graphical mode by passing "live 3" as a boot parameter. An updated version of Guymager (0.3.1). Two Windows tools to copy Win32 memory (including Vista): win32dd and mantech mdd. The memory analysis tool Volatility was added. The registry analysis tool regripper was added. aeskeyfinder and rsakeyfinder were added. A better starting Web page and a better description of the tools on the CD. An updated version (0.40) of the Perl library Parse-win32Registry. Version 3.3.4 of afflib. Many other updates. Forensic acquisition: dd : tool to make bit to bit copies and backups dd_rescue : more or less the same as dd but handles disk errors dd_rhelp : a script to facilitate the use of dd_rescue dcfldd : tool to make bit to bit copies AFFLIB : Advanced Forensic Format tools sdd : a dd clone specialized in tapes AIR : A graphical frontend for dd and dcfldd
6.31 Forensic analysis :________________________________

Sleuthkit/Autopsy : tool to find deleted files (and many more features) Galetta : a ms-windows cookies analyzer Pasco : a ms-windows IExplorer cache analyzer Rifiuti : a ms-windows trashcan analyzer mork.pl : perl script to read firefox history.dat cookie_cruncher.pl : a tool to parse cookies dumpster_dive.pl : a tool to read m$ recycle bin files 44
browser-history-viewer : as the name says
6.32 Undelete :________________________________________

Sleuthkit/Autopsy : tool to find deleted files (and many more features) testdisk : tool to recover damaged partitions (WIP version) NTFS Tools : tools to find deleted files on NTFS partitions Scrounge-NTFS : a tool to rescue data from NTFS partitions recoverjpeg : a tool to recover jpeg images fatback : a tool to undelete files on a fat filesytsem foremost : a tool to find files on a raw disk based on their headers magicrescue : another one e2undel : recover deleted files on ext2 recover : like e2undel e2retrieve : a tool to recover deleted files on ext2 filesystems myrescue : a tool to recover data on damaged hard disk drives recoverdm : another tool to recover data on damaged hard disk drives scalpel : another foremost/magicrescue like tool gzrecover : a tool to recover data from damaged gz files safecopy : a tool to recover data from damaged devices
6.33 Hardware utilities_________________________________

discover : a tool to discover hardware lshw : a very useful tool to list hardware scsitools : some useful scsi tools scsiadd : a script to rescan scsi chain blktool : a tool to display or change block devices settings
6.34 Disk/partition utilities______________________________

setmax : A tool to change Host Protected Area settings (no support of large disks) testdisk : tool to recover damaged partitions (WIP version) disktype : a tool to list disk partitions and other useful informations ms-sys : a tool to create ms boot sectors (fdisk /mbr) safecopy : a tool to recover data from damaged devices
6.35 Archive tools :____________________________________

zoo : the zoo compression algorythm support p7zip : the 7zip compression tools orange : cab file reader spantape : a tool to span data on multiple tapes unshield : a reader for self extraction shield files unrar : a tool to uncompress rar files unace : a tool to uncompress ace files gzrecover : a tool to recover data from damaged gz files
45
6.36 Pictures tools :___________________________________

FBI : tool to view images in console mode exiftags : a tool to extract exif informations in jpeg files exif : another one metacam : a third one jhead : a fourth one dcraw : a tool to read raw photo images from digital cameras jpeginfo : a tool view jpeg files informations recoverPhotos : another image recovery tool exifprobe : another exif extractor
6.37 Video tools :_____________________________________

MPlayer : tool to view movies in console mode
6.38 Password cracker :________________________________

cmospwd : a tool to recover cmos passwords pwl : a tool to crack win 9x pwl files John the ripper : a password cracker for unixes, and win nt,2k and xp passwords lcrack : lepton cracker chntpw : a tool to help cracking NT passwords crack : a password cracker samdump : a tool to extract password hashes from MS Windows registry files bkhive : a tool to extract Syskey bootkey from MS Windows system hive file pgpcrack : a pgp brute force attacker nasty : a tool to try to recover PGP or GPG passphrases fcrackzip : a zip file password cracker medussa : a distributed password cracker
6.39 Crypto/Stegano tools :_____________________________

cryptcat : a encrypted version of netcat outguess : a stegano tool stegdetect : a tool to detect stegano bcrypt : crypto utility ccrypt : an encryption decryption tool
6.40 Anti-virus :_______________________________________

clamav : command line antivirus rkhunter : a rootkit hunter
6.41 MS files tools:____________________________________

Galetta : a ms-windows cookies analyzer Pasco : a ms-windows IExplorer cache analyzer Rifiuti : a ms-windows trashcan analyzer readpst : a tools to read ms-Outlook pst files antiword : a tool to read ms-Word files mdbtools : playing with MS mdb access databases 46
ripole : A tool to rip attachements from MS files tnef : A tool to decode MS encapsulation format fccu-docprop : a tool to read MS OLE files (mainly doc, xls) properties fccu.evtreader : a tool to parse MS evt log files reglookup : MS windows registry viewer grokevt : An MS win event log viewer with dll message import eindeutig : read and convert dbx files clit : convert MS e-books cookie_cruncher.pl : a tool to parse cookies dumpster_dive.pl : a tool to read m$ recycle bin files mscompress : Decompress files compressed with compress.exe
6.42 Network:_________________________________________
RIP and PXE boot : A complete system for large network keyword search sbd : a netcat like utility with encryption supprot smbc : samba commander p0f : A passive OS fingerprinting tool arping : a ping utility ngrep : grep utility for network packets netwox : a toolbox with more than 200 network tools sshfs : a filesystem client based on ssh lft : a traceroute tool socat : a netcat like tool netdiscover : a tool to discover networks mimms : download mms streams weplab : a wep security analyzer netsed : network srteam altering tool
6.43 Network scanner:_________________________________

knocker : TCP security port scanner nikto : web server security scanner nbtscan : a smb network scanner
6.44 Network capture :_________________________________

tcpick : textmode sniffer tcptrack : another one tcpflow : a tool to capture tcp packets tcpreplay : a tool to replay TCP dumps (replay a tap) tcpextract : a tool to extract files from network traffic based on file headersw netdude : a tool to analyze captured tcp packets dsniff : a tool to sniff packets on a network hunt : packet sniffer sniffit : another one ettercap : a packet sniffer driftnet : sniff images (jpegs ...) on the network karpski : another sniffer nast : another one scapy : packet manipulation tool
47
hydra : a network services password guessing tool chatsniff : an instant messenger sniffer msn-capture : a tool to capture msn traffic from the network imsniff : an instant messaging sniffer darkstat : another packet sniffer netwox : a toolbox with more than 200 network tools prismstumbler : a wireless sniffer
6.45 Malware collection :_______________________________

nepenthes : A tool to collect malware mwcollect : A tool to collect malware
6.46 VNC utils :_______________________________________

xvncviewer : a VNC client (runs under X) direct-vnc : a VNC client in console mode
6.47 Common tools :__________________________________

pipebench : a pipe progress viewer pv : another pipe progress viewer cpipe : another pipe progress viewer pipemeter : another pipe progress viewer biew : an HEX editor bfr : a buffer optimizer biabam : Bash Attachement mailer aish : convert too and from uuencode or base 64 mimedecode : like the name says ftimes : a tool to gather informations about files md5deep : a tool to recursively calculate md5 hashes glark : a sort of colorized grep curl : a tool to play with http like mirroring a website star : a tar archiver sgrep : a grep for structures
6.48 Other, unsorted :__________________________________

slocate : a file location database wdutch,wfrench : french and dutch dictionaries gpsd : a gps deamon sg3-utils : some scsi utilities dds2tar : dds tapes utilities nomarch : A tool to extract arc archives mpack : A tool to unpack mime format pdftk : A tool to work with pdf files upx : A tool to uncompress UPX executables nxclient : A client for NX servers fccu-checker.sh : A script to check for all those useful utilities heme : Another Hex editor multitail : like tail for multiple files vlc : a media client with framebuffer support 48
dmidecode : a tool to display hardware informations shed : an text based hexa editor hexcat : like cat but with hexadecimal output mbuffer : another pipe measurement tool w3m : a tool to get web pages like curl or wget
49

Ch6 - Operating System Forensics

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch6 - Operating System Forensics

Uploaded by

Copyright:

Available Formats

Chapter-6

Operating System Forensics

All Rights Reserved. www.sedulitygroups.com

6.1 WHERE EVIDENCE RESIDES ON WINDOWS SYSTEMS___

6.2 CONDUCTING A WINDOWS INVESTIGATION___________

6.3 Reviewing All Pertinent Logs________________________

6.4 Event Viewer______________________________________

All Rights Reserved. www.sedulitygroups.com

6.4.1 Event Log Types

All Rights Reserved. www.sedulitygroups.com

6.4.2 How to View Event Logs

6.4.3 How to View Event Details

6.4.4 How to Interpret an Event

6.4.5 How to Find Events in a Log

6.4.6 How to Manage Log Contents

6.5 Event Log Drawbacks_______________________________

All Rights Reserved. www.sedulitygroups.com

6.6 What Can Happen__________________________________

6.7 Where to Look for Evidence_________________________

6.8 IIS Logs__________________________________________

6.9 Reviewing Relevant Files____________________________

6.10 Incident Time and Time/Date Stamps_________________

All Rights Reserved. www.sedulitygroups.com

6.11 Where to Look for Evidence________________________

6.12 Proprietary Email Files_____________________________

6.13 Netscape Messenger Mail:__________________________

6.14 Microsoft Outlook Mail:____________________________

6.15 Deleted Files and Data_____________________________

6.15.1 In general, there are four ways to recover deleted data:

6.16 Temporary Files__________________________________

6.17 Backup File Recovery______________________________

6.18 The Swap File____________________________________

6.19 Broken Links_____________________________________

6.20 Web Browser Files________________________________

6.21 Looking for Unusual or Hidden Files_________________

All Rights Reserved. www.sedulitygroups.com

6.22 Remote Control and Remote Access Services_________

All Rights Reserved. www.sedulitygroups.com

6.23 Administrative Shares_____________________________

6.24 Reviewing Searches and Files Used__________________

6.25 AccessData Registry Viewer________________________

6.26 Registry Viewer Overview__________________________

6.27 Windows Registry Basics__________________________

user.dat 2000/XP ntuser.dat Default SAM Security Software

6.28 Opening and Closing Registry Files__________________

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

All Rights Reserved. www.sedulitygroups.com

6.29 Forensic Analysis_________________________________

6.29.1 Fitting to the environment

6.29.2 Preparing the forensic toolkit media

All Rights Reserved. www.sedulitygroups.com

6.29.3 Data collecting from a live system - a step by step procedure

Step 1: Take a photograph of a compromised system's screen

Step 2: Media mounting

Step 3: Current date

Step 4: Cache tables

Step 5: Current, pending connections and open TCP/UDP ports.

6.30 Concluding part one_______________________________