Special Publication 800-86

Guide to Integrating Forensic 

Techniques into Incident 

Response 

Recommendations of the National Institute 

of Standards and Technology

Karen Kent 

Suzanne Chevalier

Tim Grance 

Hung Dang 

Guide to Integrating Forensic Techniques 

into Incident Response

Recommendations of the National

Institute of Standards and Technology 

Karen Kent, Suzanne Chevalier, 

Tim Grance, Hung Dang 

NIST Special Publication 800-86 

C O M P U T E R S E C U R I T Y

Computer Security Division

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899-8930 

August 2006 

U.S. Department of Commerce 

Carlos M. Gutierrez, Secretary

Technology Administration

Robert C. Cresanti, Under Secretary of

Commerce for Technology

National Institute of Standards and Technology

William A. Jeffrey, Director
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

 

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nationís 

measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of

concept implementations, and technical analysis to advance the development and productive use of

information technology. ITLís responsibilities include the development of technical, physical,

administrative, and management standards and guidelines for the cost-effective security and privacy of

sensitive unclassified information in Federal computer systems. This Special Publication 800-series

reports on ITLís research, guidance, and outreach efforts in computer security and its collaborative

activities with industry, government, and academic organizations.

 

 

 

 

 

 

 

 

 

 

 

 

 

Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately. 

Such identification is not intended to imply recommendation or endorsement by the

National Institute of Standards and Technology, nor is it intended to imply that the

entities, materials, or equipment are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 800-86 

Natl. Inst. Stand. Technol. Spec. Publ. 800-86, 121 pages (August 2006) 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ii
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Acknowledgments

The authors, Karen Kent and Tim Grance of the National Institute of Standards and Technology, and

Suzanne Chevalier and Hung Dang of Booz Allen Hamilton, wish to thank their colleagues who reviewed

drafts of this document and contributed to its technical content. The authors would particularly like to

acknowledge Rick Ayers, Wayne Jansen, Peter Mell, and Murugiah Souppaya of NIST, and Adam

Feldman, Mike Noblett, and Joseph Nusbaum of Booz Allen Hamilton, for their keen and insightful

assistance throughout the development of the document. The authors would also like to express their

thanks to security experts Susan Ballou (Office of Law Enforcement Standards), Brian Carrier (Purdue

University), Eoghan Casey (Stroz Friedberg, LLC), Duane Crider (Microsoft), Kurt Dillard (Microsoft),

Dean Farrington (Wells Fargo Bank), Jessica Reust (Stroz Friedberg, LLC), Marc Rogers (Purdue

University), and Miles Tracy (U.S. Federal Reserve System), as well as representatives from the

Department of State, for their particularly valuable comments and suggestions.

Trademarks

All product names are registered trademarks or trademarks of their respective companies.

iii
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Table of Contents

Executive Summary............................................................................................................ES-1

1. Introduction ................................................................................................................... 1-1

1.1 Authority................................................................................................................ 1-1

1.2 Purpose and Scope............................................................................................... 1-1

1.3 Audience ............................................................................................................... 1-1

1.4 Publication Structure ............................................................................................. 1-2

2. Establishing and Organizing a Forensics Capability.................................................. 2-1

2.1 The Need for Forensics......................................................................................... 2-1

2.2 Forensic Staffing ................................................................................................... 2-3

2.3 Interactions with Other Teams............................................................................... 2-4

2.4 Policies.................................................................................................................. 2-5

2.4.1 Defining Roles and Responsibilities ........................................................... 2-5

2.4.2 Providing Guidance for Forensic Tool Use ................................................. 2-6

2.4.3 Supporting Forensics in the Information System Life Cycle........................ 2-6

2.5 Guidelines and Procedures ................................................................................... 2-7

2.6 Recommendations ................................................................................................ 2-8

3. Performing the Forensic Process ................................................................................ 3-1

3.1 Data Collection...................................................................................................... 3-2

3.1.1 Identifying Possible Sources of Data.......................................................... 3-2

3.1.2 Acquiring the Data...................................................................................... 3-3

3.1.3 Incident Response Considerations............................................................. 3-5

3.2 Examination .......................................................................................................... 3-6

3.3 Analysis................................................................................................................. 3-6

3.4 Reporting............................................................................................................... 3-6

3.5 Recommendations ................................................................................................ 3-7

4. Using Data from Data Files........................................................................................... 4-1

4.1 File Basics............................................................................................................. 4-1

4.1.1 File Storage Media..................................................................................... 4-1

4.1.2 Filesystems................................................................................................ 4-3

4.1.3 Other Data on Media.................................................................................. 4-4

4.2 Collecting Files...................................................................................................... 4-5

4.2.1 Copying Files from Media........................................................................... 4-6

4.2.2 Data File Integrity....................................................................................... 4-7

4.2.3 File Modification, Access, and Creation Times ........................................... 4-9

4.2.4 Technical Issues ........................................................................................ 4-9

4.3 Examining Data Files........................................................................................... 4-10

4.3.1 Locating the Files..................................................................................... 4-11

4.3.2 Extracting the Data................................................................................... 4-11

4.3.3 Using a Forensic Toolkit........................................................................... 4-13

4.4 Analysis............................................................................................................... 4-14

4.5 Recommendations .............................................................................................. 4-15

5. Using Data from Operating Systems ........................................................................... 5-1

5.1 OS Basics ............................................................................................................. 5-1

iv
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

5.1.1 Non-Volatile Data....................................................................................... 5-1

5.1.2 Volatile Data............................................................................................... 5-3

5.2 Collecting OS Data................................................................................................ 5-4

5.2.1 Collecting Volatile OS Data ........................................................................ 5-5

5.2.2 Collecting Non-Volatile OS Data ................................................................ 5-8

5.2.3 Technical Issues with Collecting Data ...................................................... 5-10

5.3 Examining and Analyzing OS Data...................................................................... 5-11

5.4 Recommendations .............................................................................................. 5-12

6. Using Data From Network Traffic................................................................................. 6-1

6.1 TCP/IP Basics ....................................................................................................... 6-1

6.1.1 Application Layer........................................................................................ 6-2

6.1.2 Transport Layer.......................................................................................... 6-2

6.1.3 IP Layer ..................................................................................................... 6-3

6.1.4 Hardware Layer.......................................................................................... 6-4

6.1.5 Layersí Significance in Network Forensics ................................................. 6-4

6.2 Network Traffic Data Sources................................................................................ 6-5

6.2.1 Firewalls and Routers................................................................................. 6-5

6.2.2 Packet Sniffers and Protocol Analyzers...................................................... 6-5

6.2.3 Intrusion Detection Systems....................................................................... 6-6

6.2.4 Remote Access.......................................................................................... 6-7

6.2.5 Security Event Management Software ....................................................... 6-7

6.2.6 Network Forensic Analysis Tools ............................................................... 6-8

6.2.7 Other Sources............................................................................................ 6-8

6.3 Collecting Network Traffic Data ............................................................................. 6-9

6.3.1 Legal Considerations ................................................................................. 6-9

6.3.2 Technical Issues ...................................................................................... 6-10

6.4 Examining and Analyzing Network Traffic Data ................................................... 6-11

6.4.1 Identify an Event of Interest...................................................................... 6-12

6.4.2 Examine Data Sources............................................................................. 6-12

6.4.3 Draw Conclusions .................................................................................... 6-16

6.4.4 Attacker Identification............................................................................... 6-17

6.5 Recommendations .............................................................................................. 6-18

7. Using Data from Applications ...................................................................................... 7-1

7.1 Application Components........................................................................................ 7-1

7.1.1 Configuration Settings................................................................................ 7-1

7.1.2 Authentication ............................................................................................ 7-2

7.1.3 Logs........................................................................................................... 7-2

7.1.4 Data ........................................................................................................... 7-3

7.1.5 Supporting Files ......................................................................................... 7-3

7.1.6 Application Architecture.............................................................................. 7-4

7.2 Types of Applications ............................................................................................ 7-5

7.2.1 E-mail......................................................................................................... 7-5

7.2.2 Web Usage ................................................................................................ 7-6

7.2.3 Interactive Communications ....................................................................... 7-7

7.2.4 File Sharing................................................................................................ 7-7

7.2.5 Document Usage ....................................................................................... 7-8

7.2.6 Security Applications.................................................................................. 7-8

7.2.7 Data Concealment Tools............................................................................ 7-8

7.3 Collecting Application Data.................................................................................... 7-9

v
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

7.4 Examining and Analyzing Application Data............................................................ 7-9

7.5 Recommendations .............................................................................................. 7-10

8. Using Data from Multiple Sources ............................................................................... 8-1

8.1 Suspected Network Service Worm Infection.......................................................... 8-1

8.2 Threatening E-mail................................................................................................ 8-3

8.3 Recommendations ................................................................................................ 8-5

List of Appendices

Appendix Aó Recommendations........................................................................................A-1

A.1 Organizing a Forensics Capability .........................................................................A-1

A.1.1 Forensic Participants..................................................................................A-1

A.1.2 Forensic Policies, Guidelines, and Procedures...........................................A-1

A.1.3 Technical Preparation ................................................................................A-2

A.2 Performing the Forensics Process.........................................................................A-2

A.2.1 Data Collection...........................................................................................A-3

A.2.2 Examination and Analysis ..........................................................................A-4

A.2.3 Reporting ...................................................................................................A-4

Appendix Bó Scenarios.......................................................................................................B-1

B.1 Scenario Questions ...............................................................................................B-1

B.2 Scenarios ..............................................................................................................B-1

Appendix Có Glossary ........................................................................................................C-1

Appendix Dó Acronyms ......................................................................................................D-1

Appendix Eó Print Resources.............................................................................................E-1

Appendix Fó Online Tools and Resources ........................................................................ F-1

Appendix Gó Index..............................................................................................................G-1

List of Figures

Figure 3-1. Forensic Process ................................................................................................. 3-1

Figure 4-1. File Header Information...................................................................................... 4-12

Figure 6-1. TCP/IP Layers...................................................................................................... 6-1

Figure 6-2. TCP/IP Encapsulation.......................................................................................... 6-2

List of Tables

Table 4-1. Commonly Used Media Types .............................................................................. 4-2

vi
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Executive Summary

Forensic science is generally defined as the application of science to the law. Digital forensics, also

known as computer and network forensics, has many definitions. Generally, it is considered the

application of science to the identification, collection, examination, and analysis of data while preserving

the integrity of the information and maintaining a strict chain of custody for the data. Data refers to

distinct pieces of digital information that have been formatted in a specific way. Organizations have an

ever-increasing amount of data from many sources. For example, data can be stored or transferred by

standard computer systems, networking equipment, computing peripherals, personal digital assistants 

(PDA), consumer electronic devices, and various types of media, among other sources. 

Because of the variety of data sources, digital forensic techniques can be used for many purposes, such as

investigating crimes and internal policy violations, reconstructing computer security incidents,

troubleshooting operational problems, and recovering from accidental system damage. Practically every 

organization needs to have the capability to perform digital forensics (referred to as forensics throughout 

the rest of the guide). Without such a capability, an organization will have difficulty determining what

events have occurred within its systems and networks, such as exposures of protected, sensitive data. 

This guide provides detailed information on establishing a forensic capability, including the development

of policies and procedures. Its focus is primarily on using forensic techniques to assist with computer

security incident response, but much of the material is also applicable to other situations.

Because different organizations are subject to different laws and regulations, this publication

should not be used as a guide to executing a digital forensic investigation, construed as legal advice,

or used as the basis for investigations of criminal activity.

1

 Instead, organizations should use this

guide as a starting point for developing a forensic capability in conjunction with extensive guidance 

provided by legal advisors, law enforcement officials, and management.

The process for performing digital forensics comprises the following basic phases:

! Collection: identifying, labeling, recording, and acquiring data from the possible sources of

relevant data, while following procedures that preserve the integrity of the data.

! Examination: forensically processing collected data using a combination of automated and

manual methods, and assessing and extracting data of particular interest, while preserving the

integrity of the data.

! Analysis: analyzing the results of the examination, using legally justifiable methods and

techniques, to derive useful information that addresses the questions that were the impetus for

performing the collection and examination.

! Reporting: reporting the results of the analysis, which may include describing the actions used,

explaining how tools and procedures were selected, determining what other actions need to be

performed (e.g., forensic examination of additional data sources, securing identified

vulnerabilities, improving existing security controls), and providing recommendations for

improvement to policies, procedures, tools, and other aspects of the forensic process.

This guide provides general recommendations for performing the forensic process. It also provides

detailed information about using the analysis process with four major categories of data sources: files,

 1 For further information regarding computer and network forensic requirements for law enforcement, see Electronic Crime

Scene Investigation: A Guide for First Responders and Forensic Examination of Digital Evidence: A Guide for Law

Enforcement, which are both available at http://www.ncjrs.gov/ by searching on each documentís title.

ES-1 
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

operating systems, network traffic, and applications. The guide focuses on explaining the basic

components and characteristics of data sources within each category, as well as techniques for the

collection, examination, and analysis of data from each category. The guide also provides

recommendations for how multiple data sources can be used together to gain a better understanding of an

event.

Implementing the following recommendations should facilitate efficient and effective digital forensic

activities for Federal departments and agencies.

Organizations should ensure that their policies contain clear statements addressing all major 

forensic considerations, such as contacting law enforcement, performing monitoring, and 

conducting regular reviews of forensic policies and procedures.

At a high level, policies should allow authorized personnel to monitor systems and networks and perform

investigations for legitimate reasons under appropriate circumstances. Organizations may also have a

separate forensic policy for incident handlers and others with forensic roles; this policy would provide

more detailed rules concerning appropriate behavior. Forensic policy should clearly define the roles and 

responsibilities of all people and external organizations performing or assisting with the organizationís

forensic activities. The policy should clearly indicate who should contact which internal teams and 

external organizations under different circumstances.

Organizations should create and maintain procedures and guidelines for performing forensic tasks,

based on the organizationís policies and all applicable laws and regulations. 

Guidelines should focus on general methodologies for investigating incidents using forensic techniques,

since it is not feasible to develop comprehensive procedures tailored to every possible situation. 

However, organizations should consider developing step-by-step procedures for performing routine tasks. 

The guidelines and procedures should facilitate consistent, effective, and accurate actions, which is

particularly important for incidents that may lead to prosecution or internal disciplinary actions; handling

evidence in a forensically sound manner puts decision makers in a position where they can confidently

take the necessary actions. The guidelines and procedures should support the admissibility of evidence

into legal proceedings, including information on gathering and handling evidence properly, preserving the

integrity of tools and equipment, maintaining the chain of custody, and storing evidence appropriately. 

Because electronic logs and other records can be altered or otherwise manipulated, organizations should

be prepared, through their policies, guidelines, and procedures, to demonstrate the integrity of such

records. The guidelines and procedures should be reviewed periodically, as well as when significant

changes are made to the teamís policies and procedures. 

Organizations should ensure that their policies and procedures support the reasonable and 

appropriate use of forensic tools.

Organizationsí policies and procedures should clearly explain what forensic actions should and should not

be performed under various circumstances, as well as describing the necessary safeguards for sensitive

information that might be recorded by forensic tools, such as passwords, personal data (e.g., Social

Security numbers), and the contents of e-mails. Legal advisors should carefully review all forensic policy 

and high-level procedures.

Organizations should ensure that their IT professionals are prepared to participate in forensic

activities.

ES-2 
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

IT professionals throughout an organization, especially incident handlers and other first responders to

incidents, should understand their roles and responsibilities for forensics, receive training and education

on forensicñrelated policies and procedures, and be prepared to cooperate with and assist others when the

technologies that they are responsible for are part of an incident or other event. IT professionals should

also consult closely with legal counsel both in general preparation for forensics activities, such as

determining which actions IT professionals should and should not perform, and also on an as-needed

basis to discuss specific forensics situations. In addition, management should be responsible for

supporting forensic capabilities, reviewing and approving forensic policy, and approving certain forensic

actions, such as taking mission-critical systems off-line.

ES-3 
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

ES-4 
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

1. Introduction

1.1 Authority 

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its

statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,

Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for

providing adequate information security for all agency operations and assets; but such standards and 

guidelines shall not apply to national security systems. This guideline is consistent with the requirements 

of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), ìSecuring Agency

Information Systems,î as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental

information is provided in A-130, Appendix III. 

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental

organizations on a voluntary basis and is not subject to copyright, though attribution is desired. 

Nothing in this document should be taken to contradict standards and guidelines made mandatory and 

binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these

guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,

Director of the OMB, or any other Federal official.

This guideline should not be held as binding to law enforcement personnel relative to the

investigation of criminal activity.

1.2 Purpose and Scope

This publication is intended to help organizations in investigating computer security incidents and

troubleshooting some information technology (IT) operational problems by providing practical guidance

on performing computer and network forensics. The guide presents forensics from an IT view, not a

law enforcement view.2

 Specifically, the publication describes the processes for performing effective

forensics activities and provides advice regarding different data sources, including files, operating

systems (OS), network traffic, and applications. 

The publication is not to be used as an all-inclusive step-by-step guide for executing a digital forensic

investigation or construed as legal advice. Its purpose is to inform readers of various technologies and 

potential ways of using them in performing incident response or troubleshooting activities. Readers are

advised to apply the recommended practices only after consulting with management and legal counsel for

compliance concerning laws and regulations (i.e., local, state, Federal, and international) that pertain to

their situation.

 

1.3 Audience 

This publication has been created for incident response teams; forensic analysts; system, network, and 

security administrators; and computer security program managers who are responsible for performing

forensics for investigative, incident response, or troubleshooting purposes. The practices recommended 

2 For further information regarding computer and network forensic requirements for law enforcement, see Electronic Crime

Scene Investigation: A Guide for First Responders and Forensic Examination of Digital Evidence: A Guide for Law

Enforcement, which are both available at http://www.ncjrs.gov/ by searching on each documentís title.

1-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

in this guide are designed to highlight key principles associated with the handling and examination of

electronic evidence. Because of the constantly changing nature of electronic devices and software, and

forensic procedures and tools, readers are expected to refer to other resources, including those listed in 

this guide, for more current and detailed information than that presented in this guide.

1.4 Publication Structure 

The remainder of this publication is divided into seven major sections: 

! Section 2 discusses the need for computer and network forensics and provides guidance on 

establishing and organizing a forensics capability for an organization. 

! Section 3 explains the basic steps involved in performing computer and network forensics: data

collection, examination, analysis, and reporting. 

! Sections 4 through 7 provide details on collecting, examining, and analyzing data from various

data sources, based on the framework described in Section 3. The data source categories

discussed in Sections 4 through 7 are data files, OSs, network traffic, and applications,

respectively.

! Section 8 presents case studies that illustrate how analysis can correlate events among several 

data sources.

The publication also contains several appendices with supporting material: 

! Appendix A presents the major recommendations made in the publication. 

! Appendix B presents scenarios in which forensics techniques might be useful and asks the reader

a series of questions regarding each scenario. 

! Appendices C and D contain a glossary and acronym list, respectively. 

! Appendix E lists print resources, and Appendix F identifies online tools and resources, that may

be useful for establishing a forensics capability or understanding forensics tools and techniques.

! Appendix G contains an index for the publication.

1-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

2. Establishing and Organizing a Forensics Capability

The term data refers to distinct pieces of digital information that have been formatted in a specific way. 

The expansion of computers

3

 for professional and personal use and the pervasiveness of networking have

fueled the need for tools that can record and analyze an ever-increasing amount of data from many

sources. For example, data can be stored or transferred by standard computer systems (e.g., desktops,

laptops, servers), networking equipment (e.g., firewalls, routers), computing peripherals (i.e., printers),

personal digital assistants (PDA), CDs, DVDs, removable hard drives, backup tapes, flash memory,

thumb drives, and jump drives. Many consumer electronic devices (e.g., cell phones, video game

consoles, digital audio players, digital video recorders) can also be used to store data. This increasing

variety of data sources has helped spur the development and refinement of forensics tools and techniques. 

This has also been caused by the realization that such tools and techniques can be used for many

purposes, such as investigating crimes, reconstructing computer security incidents, troubleshooting

operational problems, and recovering from accidental system damage.

This section discusses several aspects of organizing a forensics capability for an organization. It begins

by showing the wide variety of potential uses for forensics, and then presents a high-level overview of the

forensics process. The next part of the section discusses how forensics services are typically provided

and provides guidance on building and maintaining the necessary skills to perform forensics tasks. The

section also explains the need to include various teams from throughout the organization, such as legal

advisors and physical security staff, in some forensic activities. The section ends by discussing how

policies, guidelines, and procedures should address forensics (e.g., defining roles and responsibilities,

providing guidance on the proper usage of tools and techniques, incorporating forensics into the

information system life cycle).

The techniques and processes presented in this guide are based on principles of digital forensics. 

Forensic science is generally defined as the application of science to the law. Digital forensics, also

known as computer and network forensics, has many definitions. Generally, it is considered the

application of science to the identification, collection, examination, and analysis of data while preserving

the integrity of the information and maintaining a strict chain of custody for the data. Because different 

organizations are subject to different laws and regulations, this publication should not be used as a 

guide for executing a digital forensic investigation, construed as legal advice, or used as the basis

for investigations of criminal activity. Instead, organizations should use this guide as a starting

point for developing a forensic capability in conjunction with extensive guidance provided by legal 

advisors, law enforcement officials, and management. 

2.1 The Need for Forensics

Over the last decade, the number of crimes that involve computers has grown, spurring an increase in 

companies and products that aim to assist law enforcement in using computer-based evidence to

determine the who, what, where, when, and how for crimes. As a result, computer and network forensics

has evolved to assure proper presentation of computer crime evidentiary data into court. Forensic tools

and techniques are most often thought of in the context of criminal investigations and computer security

incident handlingóused to respond to an event by investigating suspect systems, gathering and

preserving evidence, reconstructing events, and assessing the current state of an event. However, forensic

tools and techniques are also useful for many other types of tasks, such as the following: 

! Operational Troubleshooting. Many forensic tools and techniques can be applied to

troubleshooting operational issues, such as finding the virtual and physical location of a host with

 3 In this publication, the term computer is used to refer to all computing, storage, and peripheral devices.

2-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

an incorrect network configuration, resolving a functional problem with an application, and 

recording and reviewing the current OS and application configuration settings for a host.

! Log Monitoring. Various tools and techniques can assist in log monitoring, such as analyzing 

log entries and correlating log entries across multiple systems. This can assist in incident

handling, identifying policy violations, auditing, and other efforts.

! Data Recovery. There are dozens of tools that can recover lost data from systems, including data

that has been accidentally or purposely deleted or otherwise modified. The amount of data that

can be recovered varies on a case-by-case basis.

! Data Acquisition. Some organizations use forensics tools to acquire data from hosts that are

being redeployed or retired. For example, when a user leaves an organization, the data from the

userís workstation can be acquired and stored in case it is needed in the future. The workstationís

media can then be sanitized to remove all of the original userís data.

! Due Diligence/Regulatory Compliance. Existing and emerging regulations require many

organizations to protect sensitive information and maintain certain records for audit purposes. 

Also, when protected information is exposed to other parties, organizations may be required to

notify other agencies or impacted individuals. Forensics can help organizations exercise due

diligence and comply with such requirements.

Regardless of the situation, the forensic process comprises the following basic phases:

4

! Collection. The first phase in the process is to identify, label, record, and acquire data from the

possible sources of relevant data, while following guidelines and procedures that preserve the

integrity of the data. Collection is typically performed in a timely manner because of the

likelihood of losing dynamic data such as current network connections, as well as losing data

from battery-powered devices (e.g., cell phones, PDAs).

! Examination. Examinations involve forensically processing large amounts of collected data

using a combination of automated and manual methods to assess and extract data of particular

interest, while preserving the integrity of the data.

! Analysis. The next phase of the process is to analyze the results of the examination, using legally

justifiable methods and techniques, to derive useful information that addresses the questions that

were the impetus for performing the collection and examination.

! Reporting. The final phase is reporting the results of the analysis, which may include describing

the actions used, explaining how tools and procedures were selected, determining what other

actions need to be performed (e.g., forensic examination of additional data sources, securing

identified vulnerabilities, improving existing security controls), and providing recommendations

for improvement to policies, guidelines, procedures, tools, and other aspects of the forensic

process. The formality of the reporting step varies greatly depending on the situation.

A more in-depth discussion of the forensic process is presented in Section 3. Sections 4 through 7 

provide additional information on collecting, examining, and analyzing different types of forensic data.

 4 There are many models for the forensic process. Although the exact phases of the models vary somewhat, the models reflect

the same basic principles and the same overall methodology. Models differ primarily in how granular each phase of the 

process is and in the terms used for specific phases. The model presented in this guide offers a simple way of looking at the

phases. Organizations should choose the specific forensic model that is most appropriate for their needs.

2-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

2.2 Forensic Staffing

Practically every organization needs to have some capability to perform computer and network forensics. 

Without such a capability, an organization will have difficulty determining what events have occurred 

within its systems and networks, such as exposures of protected, sensitive data. Although the extent of

this need varies, the primary users of forensic tools and techniques within an organization usually can be

divided into the following three groups:5

! Investigators. Investigators within an organization are most often from the Office of Inspector

General (OIG), and they are responsible for investigating allegations of misconduct. For some

organizations, the OIG immediately takes over the investigation of any event that is suspected to

involve criminal activity. The OIG typically uses many forensic techniques and tools. Other

investigators within an organization might include legal advisors and members of the human 

resources department. Law enforcement officials and others outside the organization that might

perform criminal investigations are not considered part of an organizationís internal group of

investigators.

! IT Professionals. This group includes technical support staff and system, network, and security

administrators. They use a small number of forensic techniques and tools specific to their area of

expertise during their routine work (e.g., monitoring, troubleshooting, data recovery).

! Incident Handlers. This group responds to a variety of computer security incidents, such as

unauthorized data access, inappropriate system usage, malicious code infections, and denial of

service attacks. Incident handlers typically use a wide variety of forensic techniques and tools

during their investigations. 

Many organizations rely on a combination of their own staff and external parties to perform forensic

tasks. For example, some organizations perform standard tasks themselves and use outside parties only 

when specialized assistance is needed. Even organizations that want to perform all forensic tasks 

themselves usually outsource the most demanding ones, such as sending physically damaged media to a

data recovery firm for reconstruction, or having specially trained law enforcement personnel or

consultants collect data from an unusual source (e.g., cell phone). Such tasks typically require the use of

specialized software, equipment, facilities, and technical expertise that most organizations cannot justify

the high expense of acquiring and maintaining. As described in Section 3.1.2, organizations should

determine in advance which actions should be performed by law enforcement officials. Also, when

expert testimony is needed for legal proceedings, organizations might seek external assistance.

When deciding which internal or external parties should handle each aspect of forensics, organizations

should keep the following factors in mind:

! Cost. There are many potential costs. Software, hardware, and equipment used to collect and

examine data may carry significant costs (e.g., purchase price, software updates and upgrades,

maintenance), and may also require additional physical security measures to safeguard them from

tampering. Other significant expenses involve staff training and labor costs, which are

particularly significant for dedicated forensic specialists. In general, forensic actions that are

needed rarely might be more cost-effectively performed by an external party, whereas actions that

are needed frequently might be more cost-effectively performed internally.

 5 An individual performing forensic activities needs to understand forensic principles and practices, and follow the correct

procedures for each activity, regardless of which group he or she is a member.

2-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Response Time. Personnel located on-site might be able to initiate computer forensic activity

more quickly than could off-site personnel. For organizations with geographically dispersed

physical locations, off-site outsourcers located near distant facilities might be able to respond

more quickly than personnel located at the organizationís headquarters.

! Data Sensitivity. Because of data sensitivity and privacy concerns, some organizations might be

reluctant to allow external parties to image hard drives and perform other actions that provide

access to data. For example, a system that contains traces of an incident might also contain health

care information, financial records, or other sensitive data; an organization might prefer to keep

that system under its own control to safeguard the privacy of the data. On the other hand, if there

is a privacy concern within the teamófor example, if an incident is suspected to involve a

member of the incident handling teamóuse of an independent third party to perform forensic

actions would be preferable.

Incident handlers performing forensic tasks need to have a reasonably comprehensive knowledge of

forensic principles, guidelines, procedures, tools, and techniques, as well as anti-forensic tools and 

techniques that could conceal or destroy data. It is also beneficial for incident handlers to have expertise

in information security and specific technical subjects, such as the most commonly used OSs, filesystems,

applications, and network protocols within the organization. Having this type of knowledge facilitates

faster and more effective responses to incidents. Incident handlers also need a general, broad

understanding of systems and networks so that they can determine quickly which teams and individuals 

are well-suited to providing technical expertise for particular forensic efforts, such as examining and

analyzing data for an uncommon application.

Individuals performing forensics might need to perform other types of tasks as well. For example, if the

results of an investigation are used in a court of law, incident handlers may be called upon to provide

testimony and corroborate their findings. Incident handlers might provide training courses in forensics to

technical support staff, system and network administrators, and other IT professionals. Possible training

topics include an overview of forensics tools and techniques, advice on using a particular tool, and the

signs of a new type of attack. Incident handlers might also want to have interactive sessions with groups

of IT professionals to hear their thoughts on forensics tools and identify potential shortcomings in existing

forensics capabilities. 

On an incident handling team, more than one team member should be able to perform each typical

forensic activity so that the absence of any single team member will not severely impact the teamís

abilities. Incident handlers can train each other in the use of forensic tools and other technical and 

procedural topics. Hands-on exercises and external IT and forensic training courses can also be helpful in 

building and maintaining skills. In addition, it might be beneficial to have team members see

demonstrations of new tools and technologies or try out forensic and anti-forensic tools in a lab. This can

be particularly useful in familiarizing incident handlers with the collection, examination, and analysis of

data from devices such as cell phones and PDAs. Incident handlers need to stay current with new

forensic technologies, techniques, and procedures.

2.3 Interactions with Other Teams

It is not feasible for any one person to be well-versed in every technology (including all software) used

within an organization; therefore, individuals performing forensic actions should be able to reach out to

other teams and individuals within their organization as needed for additional assistance. For example, an

incident involving a particular database server might be handled more efficiently if the database

administrator were available to provide background information, answer technical questions, and provide

database documentation and other reference material. Organizations should ensure that IT professionals

throughout the organization, especially incident handlers and other first responders to incidents,

2-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

understand their roles and responsibilities for forensics, receive ongoing training and education on

forensicñrelated policies, guidelines, and procedures, and are prepared to cooperate with and assist others

when the technologies that they are responsible for are part of an incident or other event.

In addition to IT professionals and incident handlers, others within an organization may also need to

participate in forensic activities in a less technical capacity. Examples include management, legal

advisors, human resources personnel, auditors, and physical security staff. Management is responsible for

supporting forensic capabilities, reviewing and approving forensic policy, and approving certain forensic

actions (e.g., taking a mission-critical system off-line for 6 hours to collect data from its hard drives). 

Legal advisors should carefully review all forensic policy and high-level guidelines and procedures, and 

they can provide additional guidance when needed to ensure that forensic actions are performed lawfully. 

The human resources department can provide assistance in dealing with employee relations and the

handling of internal incidents. Auditors can help determine the economic impact of an incident, including

the cost of forensic activity. Physical security staff can assist in gaining access to and physically securing

evidence. Although these teams often do not play a prominent role in the forensic process, the services

that these teams provide can be beneficial.

To facilitate inter-team communications, each team should designate one or more points of contact.

These individuals are responsible for knowing the expertise of each team member and directing inquiries

for assistance to the appropriate person. Organizations should maintain a list of contacts that the

appropriate teams can reference as needed. The list should include both standard (e.g., office phone) and

emergency (e.g., cell phone) contact methods.

2.4 Policies 

Organizations should ensure that their policies contain clear statements that address all major forensic

considerations, such as contacting law enforcement, performing monitoring, and conducting regular

reviews of forensic policies, guidelines, and procedures. At a high level, policies should allow authorized

personnel to monitor systems and networks and perform investigations for legitimate reasons under

appropriate circumstances. Organizations may also have a separate policy for incident handlers and 

others with forensic roles; this policy would provide more detailed rules for appropriate behavior. Such

personnel should be familiar with and understand the policy. Policies may need to be updated frequently,

particularly for organizations that span many jurisdictions, because of changes to laws and regulations, as

well as new court rulings. In addition, the organizationís forensic policy should be consistent with the

organizationís other policies, including policies related to reasonable expectations of privacy. Sections

2.4.1 through 2.4.3 discuss policy-related topics in more detail.

2.4.1 Defining Roles and Responsibilities

Forensic policy should clearly define the roles and responsibilities of all people performing or assisting 

with the organizationís forensic activities. This should include actions performed during both incident

handling and routine work activities (e.g., system administration, network troubleshooting). The policy

should include all internal teams that may participate in forensic efforts, such as those listed in Section

2.3, and external organizations such as law enforcement agencies, outsourcers, and incident response

organizations. The policy should clearly indicate who should contact which internal teams and external

organizations under different circumstances. The policy should also discuss jurisdictional conflictsóa

crime that involves multiple jurisdictions, which could be investigated by multiple law enforcement 

agenciesóand explain how to resolve them. As mentioned in Section 2.2, some organizations have an

Office of Inspector General (OIG) that is responsible for investigating allegations of misconduct; the OIG

may also be well-suited to resolving jurisdictional conflicts. In some organizations, if a crime may have

been committed, the OIG immediately takes over the investigation.

2-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

2.4.2

2.4.3

Providing Guidance for Forensic Tool Use 

Incident handlers; IT professionals, such as system and network administrators; and others within an

organization use forensic tools and techniques for a variety of reasons. Although the technologies have

many benefits, they can also be misused accidentally or intentionally to provide unauthorized access to

information, or to alter or destroy information, including evidence of an incident. In addition, the use of

certain forensic tools may not be warranted in some situations (for example, a minor incident probably

does not merit hundreds of hours of data collection and examination efforts).

To ensure that tools are used reasonably and appropriately, the organizationís policies, guidelines, and

procedures should clearly explain what forensic actions should and should not be performed under

various circumstances. For example, a network administrator should be able to monitor network 

communications on a regular basis to solve operational problems, but should not read usersí e-mail unless 

specifically authorized to do so. A help desk agent might be permitted to monitor network

communications for a particular userís workstation to troubleshoot an application problem but not be

permitted to perform any other network monitoring. Individual users might be forbidden from

performing any network monitoring under any circumstances. Policies, guidelines, and procedures

should clearly define the specific actions that are permitted and forbidden for each applicable role under

normal circumstances (e.g., typical duties) and special circumstances (e.g., incident handling). 

Policies, guidelines, and procedures should also address the use of anti-forensic tools and techniques. 

Described in Sections 4 through 7, anti-forensic software is designed to conceal or destroy data so that

others cannot access it. There are many positive uses for anti-forensic software, such as removing data

from computers that are to be donated to charity and removing data cached by Web browsers to preserve

a userís privacy. However, like forensic tools, anti-forensic tools can also be used for malicious reasons. 

Therefore, organizations should specify who is permitted to use such tools and under what circumstances.

Because forensic tools may record sensitive information, policies, guidelines, and procedures should also

describe the necessary safeguards for the information. There should also be requirements for handling

inadvertent exposures of sensitive information, such as an incident handler seeing passwords or patient

medical information.

Supporting Forensics in the Information System Life Cycle

Many incidents can be handled more efficiently and effectively if forensic considerations have been

incorporated into the information system life cycle. Examples of such considerations are as follows:

! Performing regular backups of systems and maintaining previous backups for a specific period of

time

! Enabling auditing on workstations, servers, and network devices

! Forwarding audit records to secure centralized log servers

! Configuring mission-critical applications to perform auditing, including recording all

authentication attempts 

! Maintaining a database of file hashes for the files of common OS and application deployments,

and using file integrity checking software on particularly important assets 

! Maintaining records (e.g., baselines) of network and system configurations

2-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Establishing data retention policies that support performing historical reviews of system and

network activity, complying with requests or requirements to preserve data relating to ongoing

litigation and investigations, and destroying data that is no longer needed.

Most of these considerations are extensions of existing provisions in the organizationís policies and 

procedures, so they are typically specified within the relevant individual documents instead of a

centralized forensics policy.

2.5 Guidelines and Procedures

As mentioned in Section 2.4, an organization should create and maintain guidelines and procedures for

performing forensic tasks, based on the organizationís policies, incident response staffing models, and 

other teams identified as participants in forensic activities. Even if the activities are performed by

external parties, the organizationís internal staff will still interact with them and participate to some extent

in the activities, such as notifying the external party of a need for assistance, granting physical or logical

access to systems, and securing an incident scene until an investigator arrives. The internal staff should

work closely with the external parties to ensure that the organizationís policies, guidelines, and

procedures are understood and followed.

An organizationís forensic guidelines should include general methodologies for investigating an incident

using forensic techniques, since it is not feasible to develop comprehensive procedures tailored to every

possible situation. However, organizations also should consider developing step-by-step procedures for

performing routine tasks, such as imaging a hard disk, capturing and recording volatile information from

systems, or securing physical evidence (e.g., removable media). The goal for the guidelines and

procedures is to facilitate consistent, effective, and accurate forensic actions, which is particularly

important for incidents that may lead to prosecution or internal disciplinary actions. Because electronic

logs and other records can be altered or otherwise manipulated, organizations should be prepared, through

their policies, guidelines, and procedures, to demonstrate the integrity of such records.6

Information is rapidly migrating to a form in which all the information assets exist in electronic form. In

both the public and private sectors, it is increasingly important to demonstrate conclusively the

authenticity, credibility, and reliability of electronic records, such as the performance of a specific action

or decision, or the existence of a certain item of information. Business records have normally been

treated as equivalent to originals. Increasingly, some in the legal and forensic communities are concerned

with the ease with which electronic records can be created, altered, or otherwise manipulated. In addition,

various compliance initiatives in the public and private sectors are making it increasingly important to

demonstrate the integrity of electronic records. With the explicit caveat that such issues are matters for

discussion with legal counsel and senior IT officials and well beyond the scope of this publication, the use

of sound, documented, and reasonably explicable forensic techniques coupled with other methods (such

as log retention and analysis) is an important resource for decision makers as well as for incident

handlers.

Forensic guidelines and procedures should be consistent with the organizationís policies and all 

applicable laws. Organizations should include technical experts and legal advisors in the development of

guidelines and procedures as a quality assurance measure. Management should also be involved in

guideline and procedure development, particularly in ensuring that all major decision-making points are

documented and that the proper course of action is defined so that decisions are made consistently.

 6 For more information on preserving the integrity of computer security logs, see NIST SP 800-92 (DRAFT), Guide to

Computer Security Log Management, which is available at http://csrc.nist.gov/publications/nistpubs/. 

2-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

The guidelines and procedures should support the admissibility of evidence into legal proceedings,

including information on gathering and handling evidence properly, preserving the integrity of tools and 

equipment, maintaining the chain of custody, and storing evidence securely.

7

 Although it may not be

feasible to record every event or action taken in response to an incident, having a record of the major

events and actions taken helps ensure that nothing has been overlooked, and helps explain to others how

the incident was handled. This documentation can be useful for case management, report writing, and 

testifying. Keeping a record of the dates and times that people worked on an incident, including the time

needed to recover systems, can also help calculate the costs of damages. Also, handling evidence in a

forensically sound manner puts decision makers in a position where they can confidently take the

necessary actions.

It is also important to maintain the guidelines and procedures once they are created so that they remain

accurate. Management should determine how frequently the guidelines and procedures should be

reviewed (generally, at least annually). Reviews should also be conducted whenever the teamís policies,

guidelines, and procedures undergo significant changes. When a guideline or procedure is updated, the

previous version should be archived for possible future use in legal proceedings. Guideline and procedure

reviews should include the same teams that participate in their creation. In addition to performing

reviews, organizations might choose to conduct exercises that help to validate the accuracy of certain

guidelines and procedures.

2.6 Recommendations

The key recommendations on establishing and organizing a forensic capability are as follows: 

! Organizations should have a capability to perform computer and network forensics. 

Forensics is needed for various tasks within an organization, including investigating crimes and

inappropriate behavior, reconstructing computer security incidents, troubleshooting operational

problems, supporting due diligence for audit record maintenance, and recovering from accidental

system damage. Without such a capability, an organization will have difficulty determining what

events have occurred within its systems and networks, such as exposures of protected, sensitive

data. Also, handling evidence in a forensically sound manner puts decision makers in a position 

where they can confidently take the necessary actions.

! Organizations should determine which parties should handle each aspect of forensics. Most 

organizations rely on a combination of their own staff and external parties to perform forensic

tasks. Organizations should decide which parties should take care of which tasks based on skills

and abilities, cost, response time, and data sensitivity.

! Incident handling teams should have robust forensic capabilities. More than one team

member should be able to perform each typical forensic activity. Hands-on exercises and IT and 

forensic training courses can be helpful in building and maintaining skills, as can demonstrations

of new tools and technologies.

! Many teams within an organization should participate in forensics. Individuals performing

forensic actions should be able to reach out to other teams and individuals within an organization,

as needed, for additional assistance. Examples of teams that may provide assistance in these

efforts include IT professionals, management, legal advisors, human resources personnel,

auditors, and physical security staff. Members of these teams should understand their roles and

 7 This document does not describe the computer and network forensic requirements placed on law enforcement. For further

information regarding computer and network forensic requirements for law enforcement, see Electronic Crime Scene 

Investigation: A Guide for First Responders and Forensic Examination of Digital Evidence: A Guide for Law Enforcement, 

which are both available at http://www.ncjrs.gov/app/topics/topic.aspx?topicid=158. 

2-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

responsibilities in forensics, receive training and education on forensicñrelated policies,

guidelines, and procedures, and be prepared to cooperate with and assist others on forensic

actions.

! Forensic considerations should be clearly addressed in policies. At a high level, policies 

should allow authorized personnel to monitor systems and networks and perform investigations

for legitimate reasons under appropriate circumstances. Organizations may also have a separate

forensic policy for incident handlers and others with forensic roles that provides more detailed 

rules for appropriate behavior. Everyone who may be called upon to assist with any forensic

efforts should be familiar with and understand the forensic policy. Additional policy

considerations are as follows:

ñ Forensic policy should clearly define the roles and responsibilities of all people performing or

assisting with the organizationís forensic activities. The policy should include all internal

and external parties that may be involved and should clearly indicate who should contact 

which parties under different circumstances.

ñ The organizationís policies, guidelines, and procedures should clearly explain what forensic

actions should and should not be performed under normal and special circumstances and

should address the use of anti-forensic tools and techniques. Policies, guidelines, and 

procedures should also address the handling of inadvertent exposures of sensitive

information.

ñ Incorporating forensic considerations into the information system life cycle can lead to more

efficient and effective handling of many incidents. Examples include performing auditing on

hosts and establishing data retention policies that support performing historical reviews of

system and network activity.

! Organizations should create and maintain guidelines and procedures for performing

forensic tasks. The guidelines should include general methodologies for investigating an

incident using forensic techniques, and step-by-step procedures should explain how to perform

routine tasks. The guidelines and procedures should support the admissibility of evidence into

legal proceedings. Because electronic logs and other records can be altered or otherwise

manipulated, organizations should be prepared, through their policies, guidelines, and procedures,

to demonstrate the reliability and integrity of such records. The guidelines and procedures should

also be reviewed regularly and maintained so that they are accurate.

2-9
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

2-10
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

3. Performing the Forensic Process 

The most common goal of performing forensics is to gain a better understanding of an event of interest by

finding and analyzing the facts related to that event. As described in Section 2.1, forensics may be

needed in many different situations, such as evidence collection for legal proceedings and internal

disciplinary actions, and handling of malware incidents and unusual operational problems. Regardless of

the need, forensics should be performed using the four-phase process shown in Figure 3-1. The exact 

details of these steps may vary based on the specific need for forensics; the organizationís policies,

guidelines, and procedures should indicate any variations from the standard procedure.

This section describes the basic phases of the forensic process: collection, examination, analysis, and 

reporting.

8

 During collection, data related to a specific event is identified, labeled, recorded, and

collected, and its integrity is preserved. In the second phase, examination, forensic tools and techniques

appropriate to the types of data that were collected are executed to identify and extract the relevant

information from the collected data while protecting its integrity. Examination may use a combination of

automated tools and manual processes. The next phase, analysis, involves analyzing the results of the

examination to derive useful information that addresses the questions that were the impetus for

performing the collection and examination. The final phase involves reporting the results of the analysis,

which may include describing the actions performed, determining what other actions need to be

performed, and recommending improvements to policies, guidelines, procedures, tools, and other aspects 

of the forensic process.

Figure 3-1. Forensic Process 

As shown at the bottom of Figure 3-1, the forensic process transforms media into evidence, whether

evidence is needed for law enforcement or for an organizationís internal usage.

9

 Specifically, the first 

transformation occurs when collected data is examined, which extracts data from media and transforms it

into a format that can be processed by forensic tools.10 Second, data is transformed into information

 8 As explained in Section 2.1, the forensic process model presented in this document offers a simple way of looking at the

phases of the forensic process. There are many other forensic process models that reflect the same basic principles and 

overall methodology. Forensic models differ primarily in how granular each phase of the process is and in the terms used

for specific phases. Organizations should choose the specific forensic model that is most appropriate for their needs. 9 From a legal perspective, the term evidence technically refers only to those items that are admitted into a court case by a

judge. However, the term evidence is widely used in a much broader sense, and this publication uses the less restrictive

definition of evidence. 10 In this context, the word media refers to both systems and networks. 

3-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

through analysis. Finally, the information transformation into evidence is analogous to transferring

knowledge into actionóusing the information produced by the analysis in one or more ways during the

reporting phase. For example, it could be used as evidence to help prosecute a specific individual,

actionable information to help stop or mitigate some activity, or knowledge in the generation of new leads 

for a case.

3.1 Data Collection

The first step in the forensic process is to identify potential sources of data and acquire data from them. 

Section 3.1.1 describes the variety of data sources available and discusses actions that organizations can 

take to support the ongoing collection of data for forensic purposes. Section 3.1.2 describes the

recommended steps for collecting data, including additional actions necessary to support legal or internal

disciplinary proceedings. Section 3.1.3 discusses incident response considerations, emphasizing the need

to weigh the value of collected data against the costs and impact to the organization of the collection

process.

3.1.1

 

Identifying Possible Sources of Data

The increasingly widespread use of digital technology for both professional and personal purposes has led

to an abundance of data sources. The most obvious and common sources of data are desktop computers,

servers, network storage devices, and laptops. These systems typically have internal drives that accept

media, such as CDs and DVDs, and also have several types of ports (e.g., Universal Serial Bus [USB],

Firewire, Personal Computer Memory Card International Association [PCMCIA]) to which external data

storage media and devices can be attached. Examples of external storage forms that might be sources of

data are thumb drives, memory and flash cards, optical discs, and magnetic disks. Standard computer

systems also contain volatile data that is available temporarily (i.e., until the system is shut down or

rebooted). In addition to computer-related devices, many types of portable digital devices (e.g., PDAs,

cell phones, digital cameras, digital recorders, audio players) may also contain data. Analysts should be

able to survey a physical area, such as an office, and recognize the possible sources of data.

11

Analysts should also think of possible data sources located in other places. For example, as described in

Sections 6 and 7, there are usually many sources of information within an organization regarding network 

activity and application usage. Information may also be recorded by other organizations, such as logs of

network activity for an Internet service provider (ISP). Analysts should be mindful of the owner of each

data source and the effect that this might have on collecting data. For example, getting copies of ISP 

records typically requires a court order. Analysts should also be aware of the organizationís policies, as

well as legal considerations, regarding externally owned property at the organizationís facilities (for

example, an employeeís personal laptop or a contractorís laptop). The situation can become even more

complicated if locations outside the organizationís control are involved, such as an incident involving a

computer at a telecommuterís home office. Sometimes it is simply not feasible to collect data from a

primary data source; therefore, analysts should be aware of alternate data sources that might contain some

or all of the same data, and should use those sources instead of the unattainable source.

Organizations can take ongoing proactive measures to collect data that may be useful for forensic

purposes. For example, as described in Section 5.1.1, most OSs can be configured to audit and record

certain types of events, such as authentication attempts and security policy changes, as part of normal

operations. Audit records can provide valuable information, including the time that an event occurred and 

11 Because forensic actions can be performed by people in various roles within an organization, this document typically uses

the word ìanalystî as a generic term for individuals performing forensic actions. 

3-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

the origin of the event.12 Another helpful action is to implement centralized logging, which means that

certain systems and applications forward copies of their logs to secure central log servers. Centralized

logging prevents unauthorized users from tampering with logs and employing anti-forensic techniques to

impede analysis.

13 Performing regular backups of systems allows analysts to view the contents of the

system as they were at a particular time. In addition, as described in Sections 6 and 7, security monitoring

controls such as intrusion detection software, antivirus software, and spyware detection and removal 

utilities can generate logs that show when and how an attack or intrusion took place.

Another proactive data collecting measure is the monitoring of user behavior, such as keystroke

monitoring, which records the keyboard usage of a particular system. Although this measure can provide

a valuable record of activity, it can also be a violation of privacy unless users are advised through 

organizational policy and login banners that such monitoring may be performed. Most organizations do

not employ techniques such as keystroke monitoring except when gathering additional information on a

suspected incident. Authority for performing such monitoring should be discussed with legal advisors

and documented clearly in the organizationís policy.

3.1.2

 

Acquiring the Data

After identifying potential data sources, the analyst needs to acquire the data from the sources. Data

acquisition should be performed using a three-step process: developing a plan to acquire the data,

acquiring the data, and verifying the integrity of the acquired data. Although the following items provide

an overview of these three steps, the specific details behind steps 2 and 3 vary based on the type of data

being acquired. Sections 4.2, 5.2, 6.3, and 7.3 provide more detailed explanations of acquiring and 

verifying the integrity of data files, OS data, network traffic data, and application data, respectively.

1. Develop a plan to acquire the data. Developing a plan is an important first step in most cases 

because there are multiple potential data sources. The analyst should create a plan that prioritizes

the sources, establishing the order in which the data should be acquired. Important factors for

prioritization include the following:

! Likely Value. Based on the analystís understanding of the situation and previous experience

in similar situations, the analyst should be able to estimate the relative likely value of each

potential data source.

! Volatility. Volatile data refers to data on a live system that is lost after a computer is

powered down or due to the passage of time. Volatile data may also be lost as a result of

other actions performed on the system. In many cases, acquiring volatile data should be

given priority over non-volatile data. However, non-volatile data may also be somewhat

dynamic in nature (e.g., log files that are overwritten as new events occur).

! Amount of Effort Required. The amount of effort required to acquire different data sources

may vary widely. The effort involves not only the time spent by analysts and others within

the organization (including legal advisors) but also the cost of equipment and services (e.g.,

outside experts). For example, acquiring data from a network router would probably require

much less effort than acquiring data from an ISP.

12 If auditing was not enabled on a system when an event occurred, incident handlers might enable auditing after the event is

discovered in an attempt to record evidence of ongoing activity. Because this could alter evidence of the incident and alert 

an attacker to the presence of the incident handlers, the impact of enabling auditing should be considered, and incident

handlers should document their actions. 13 For more information on centralized logging, see NIST SP 800-92 (DRAFT), Guide to Computer Security Log

Management, which is available at http://csrc.nist.gov/publications/nistpubs/. 

3-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

By considering these three factors for each potential data source, analysts can make informed

decisions regarding the prioritization of data source acquisition, as well as determining which 

data sources to acquire. In some cases, there are so many possible data sources that it is not

practical to acquire them all. Organizations should carefully consider the complexities of

prioritizing data source acquisition and develop written plans, guidelines, and procedures that can 

help analysts perform prioritization effectively.

2. Acquire the data. If the data has not already been acquired by security tools, analysis tools, or

other means, the general process for acquiring data involves using forensic tools to collect

volatile data, duplicating non-volatile data sources to collect their data, and securing the original

non-volatile data sources. Data acquisition can be performed either locally or over a network. 

Although it is generally preferable to acquire data locally because there is greater control over the

system and data, local data collection is not always feasible (e.g., system in locked room, system

in another location). When acquiring data over a network, decisions should be made regarding 

the type of data to be collected and the amount of effort to use. For instance, it might be

necessary to acquire data from several systems through different network connections, or it might

be sufficient to copy a logical volume from just one system.

3. Verify the integrity of the data. After the data has been acquired, its integrity should be

verified. It is particularly important for an analyst to prove that the data has not been tampered

with if it might be needed for legal reasons. Data integrity verification typically consists of using

tools to compute the message digest of the original and copied data, then comparing the digests to

make sure that they are the same.

Before the analyst begins to collect any data, a decision should be made by the analyst or

management (in accordance with the organizationís policies and legal advisors) on the need to

collect and preserve evidence in a way that supports its use in future legal or internal disciplinary

proceedings. In such situations, a clearly defined chain of custody should be followed to avoid

allegations of mishandling or tampering of evidence. This involves keeping a log of every person

who had physical custody of the evidence, documenting the actions that they performed on the

evidence and at what time, storing the evidence in a secure location when it is not being used, 

making a copy of the evidence and performing examination and analysis using only the copied

evidence, and verifying the integrity of the original and copied evidence. If it is unclear whether or

not evidence needs to be preserved, by default it generally should be preserved.

In addition, several other steps should be taken. Throughout the process, a detailed log should be kept of

every step that was taken to collect the data, including information about each tool used in the process. 

The documentation allows other analysts to repeat the process later if needed. Additionally, evidence

should be photographed to provide visual reminders of the computer setup and peripheral devices. In

addition, before actually touching a system, the analyst should make a note or photograph of any pictures,

documents, running programs, and other relevant information displayed on the monitor. If a screen saver

is active, that should be documented as well since it may be password-protected. If possible, one person

on the scene should be designated the evidence custodian, and given the sole responsibility to photograph,

document, and label every item that is collected, and record every action that was taken along with who

performed the action, where it was performed, and at what time. Since the evidence may not be needed

for legal proceedings for an extended time, proper documentation enables an analyst to remember exactly

what was done to collect data and can be used to refute claims of mishandling.

To assist the analyst with evidence collection, the necessary resources, such as forensic workstations, 

backup devices, blank media, and evidence handling supplies (e.g., hard-bound notebooks, chain of

custody forms, evidence storage bags and tags, evidence tape, digital cameras) should be prepared

3-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

beforehand. In some cases, it may be necessary to ensure that the scene is physically secured to prevent 

unauthorized access and alteration of the evidence. This may be as simple as having a physical security

staff member guard a room. There also may be situations where a law enforcement representative should

handle the data collection for legal reasons. This includes, but is not limited to, obtaining ISP records and

collecting data from external computer systems and unusual devices and media. Based on guidance from

legal advisors, organizations should determine in advance what types of data are best collected by law 

enforcement officials.

Analysts should take into account what will be done with the collected data and plan for the potential

ramifications. In some cases, the data may be turned over to a law enforcement agency or another

external party for examination and analysis. This could result in the collected hardware being unavailable

for an extended period of time. If the original media needs to be kept secured for legal proceedings, it

could be unavailable for years. Another concern is that sensitive information unrelated to the

investigation (e.g., medical records, financial information) might be inadvertently captured along with the

desired data.

3.1.3 Incident Response Considerations

When performing forensics during incident response, an important consideration is how and when the

incident should be contained. Isolating the pertinent systems from external influences may be necessary

to prevent further damage to the system and its data or to preserve evidence. In many cases, the analyst 

should work with the incident response team to make a containment decision (e.g., disconnecting network

cables, unplugging power, increasing physical security measures, gracefully shutting down a host). This

decision should be based on existing policies and procedures regarding incident containment, as well as

the teamís assessment of the risk posed by the incident, so that the chosen containment strategy or

combination of strategies sufficiently mitigates risk while maintaining the integrity of potential evidence

whenever possible.

The organization should also consider in advance the impact that various containment strategies may have

on the ability of the organization to operate effectively. For example, taking a critical system offline for

several hours to acquire disk images and other data might adversely affect the ability of the organization 

to perform its necessary operations. Significant downtime could result in substantial monetary losses to

the organization. Therefore, care should be taken to minimize disruptions to an organizationís operations.

One step often taken to contain an incident is to secure the perimeter around a computer and limit access

to authorized personnel during the collection process to ensure that the evidence is not altered. Also, a list 

of all users who have access to the computer should be documented, because these persons may be able to

provide passwords or information on where specific data is located. If the computer is connected to a

network, disconnecting network cables attached to the computer can prevent remote users from modifying

the computerís data. If the computer uses a wireless network connection, the external network adapter

may be unplugged from the computer or the internal network adapter may be disabled to sever the

network connection. If neither option is possible, then powering off the wireless network access point

that the computer is using should achieve the same result; however, doing so may prevent users outside

the scope of the investigation from performing their daily routines. In addition, there could be more than

one access point within range of the computer. Some wireless network adapters automatically attempt to

connect to other access points when the primary access point is unavailable, so that containing the

incident in this way could involve disconnecting several access points.

3-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

3.2 Examination

After data has been collected, the next phase is to examine the data, which involves assessing and

extracting the relevant pieces of information from the collected data. This phase may also involve

bypassing or mitigating OS or application features that obscure data and code, such as data compression,

encryption, and access control mechanisms. An acquired hard drive may contain hundreds of thousands

of data files; identifying the data files that contain information of interest, including information

concealed through file compression and access control, can be a daunting task. In addition, data files of

interest may contain extraneous information that should be filtered. For example, yesterdayís firewall log 

might hold millions of records, but only five of the records might be related to the event of interest.

Fortunately, various tools and techniques can be used to reduce the amount of data that has to be sifted

through. Text and pattern searches can be used to identify pertinent data, such as finding documents that

mention a particular subject or person, or identifying e-mail log entries for a particular e-mail address. 

Another helpful technique is to use a tool that can determine the type of contents of each data file, such as

text, graphics, music, or a compressed file archive. Knowledge of data file types can be used to identify

files that merit further study, as well as to exclude files that are of no interest to the examination. There

are also databases containing information about known files, which can also be used to include or exclude

files from further consideration. Specific information about examination tools and techniques is

presented in Sections 4.3, 5.3, 6.4, and 7.4.

3.3 Analysis

Once the relevant information has been extracted, the analyst should study and analyze the data to draw

conclusions from it.

14 The foundation of forensics is using a methodical approach to reach appropriate

conclusions based on the available data or determine that no conclusion can yet be drawn. The analysis

should include identifying people, places, items, and events, and determining how these elements are

related so that a conclusion can be reached. Often, this effort will include correlating data among

multiple sources. For instance, a network intrusion detection system (IDS) log may link an event to a

host, the host audit logs may link the event to a specific user account, and the host IDS log may indicate

what actions that user performed. Tools such as centralized logging and security event management

software can facilitate this process by automatically gathering and correlating the data. Comparing

system characteristics to known baselines can identify various types of changes made to the system. 

Section 8 describes this analysis process in more detail.

As described in Section 3.1.2, if evidence may be needed for legal or internal disciplinary actions,

analysts should carefully document the findings and all steps taken.

3.4 Reporting 

The final phase is reporting, which is the process of preparing and presenting the information resulting 

from the analysis phase. Many factors affect reporting, including the following:

! Alternative Explanations. When the information regarding an event is incomplete, it may not 

be possible to arrive at a definitive explanation of what happened. When an event has two or

more plausible explanations, each should be given due consideration in the reporting process. 

Analysts should use a methodical approach to attempt to prove or disprove each possible

explanation that is proposed.

 14 Some forensic process methodologies have a separate analysis phase after the examination phase. For the sake of simplicity,

this publication presents analysis as part of the examination phase. Typically, an analyst examines data and performs

analysis of that data, then conducts additional examination and analysis based on the results of the initial analysis. 

3-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Audience Consideration. Knowing the audience to which the data or information will be shown

is important. An incident requiring law enforcement involvement requires highly detailed reports 

of all information gathered, and may also require copies of all evidentiary data obtained. A 

system administrator might want to see network traffic and related statistics in great detail. 

Senior management might simply want a high-level overview of what happened, such as a

simplified visual representation of how the attack occurred, and what should be done to prevent 

similar incidents.

! Actionable Information. Reporting also includes identifying actionable information gained

from data that may allow an analyst to collect new sources of information. For example, a list of

contacts may be developed from the data that might lead to additional information about an

incident or crime. Also, information might be obtained that could prevent future events, such as a

backdoor on a system that could be used for future attacks, a crime that is being planned, a worm

scheduled to start spreading at a certain time, or a vulnerability that could be exploited.

As part of the reporting process, analysts should identify any problems that may need to be remedied,

such as policy shortcomings or procedural errors. Many forensic and incident response teams hold formal

reviews after each major event. Such reviews tend to include serious consideration of possible

improvements to guidelines and procedures, and typically at least some minor changes are approved and 

implemented after each review. For example, one common problem is that many organizations find it

resource-intensive to maintain current lists of personnel to contact regarding each different type of

incident that may occur. Other common issues are what to do with the gigabytes or terabytes of data

collected during an investigation, and how security controls (e.g., auditing, logging, intrusion detection)

can be altered to record additional data that would be helpful for future investigations. Formal reviews

can help identify ways to improve these processes. Once changes to guidelines and procedures are

implemented, all team members should be informed of the changes and frequently reminded of the proper

procedures to follow. Teams typically have formal mechanisms for tracking changes and identifying the

current versions of each process and procedure document. In addition, many teams have posters or other

highly visible documents mounted on walls or doors that remind teams of the key steps to take, so that

everyone is constantly reminded of how things are supposed to be done.

In addition to addressing identified problems, analysts should take other steps to maintain and grow their

skills. As a matter of maintaining their certification or accreditation, some forensic examiners must 

routinely refresh themselves with the latest tools and techniques that address the latest technologies 

pertaining to computer storage media, data types and formats, and other relevant issues. Whether

required or not, periodic refreshing of skills through coursework, on-the-job experience, and academic

sources helps ensure that people performing forensic actions keep pace with rapidly changing

technologies and job responsibilities. Some organizations require all members of their forensic teams to

pass annual proficiency examinations. Periodic review of policies, guidelines, and procedures also helps

ensure that the organization stays current with trends in technology and changes in law.

3.5 Recommendations

The key recommendations presented in this section for the forensic process are as follows:

! Organizations should perform forensics using a consistent process. This guide presents a

four-phase forensic process, with collection, examination, analysis, and reporting phases. The

exact details of each phase may vary based on the need for forensics.

! Analysts should be aware of the range of possible data sources. Analysts should be able to

survey a physical area and recognize possible sources of data. Analysts should also think of

possible data sources located elsewhere within an organization and outside the organization. 

3-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Analysts should be prepared to use alternate data sources if it is not feasible to collect data from a

primary source.

! Organizations should be proactive in collecting useful data. Configuring auditing on OSs,

implementing centralized logging, performing regular system backups, and using security

monitoring controls can all generate sources of data for future forensic efforts.

! Analysts should perform data collection using a standard process. The recommended steps 

in this process are identifying sources of data, developing a plan to acquire the data, acquiring the

data, and verifying the integrity of the data. The plan should prioritize the data sources,

establishing the order in which the data should be acquired based on the likely value of the data,

the volatility of the data, and the amount of effort required. Before data collection begins, a

decision should be made by the analyst or management regarding the need to collect and preserve

evidence in a manner that supports its use in future legal or internal disciplinary proceedings. In

such situations, a clearly defined chain of custody should be followed to avoid allegations of

mishandling or tampering of evidence. If it is unclear whether or not evidence needs to be

preserved, by default it generally should be preserved.

! Analysts should use a methodical approach to studying the data. The foundation of forensics

is using a methodical approach in analyzing the available data so that analysts can either draw

appropriate conclusions based on the available data or determine that no conclusion can yet be

drawn. If evidence might be needed for legal or internal disciplinary actions, analysts should

carefully document the findings and all steps taken.

! Analysts should review their processes and practices. Reviews of current and recent forensic

actions can help identify policy shortcomings, procedural errors, and other issues that might need

to be remedied, as well as ensuring that the organization stays current with trends in technology

and changes in law.

3-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

4. Using Data from Data Files

A data file (also called a file) is a collection of information logically grouped into a single entity and 

referenced by a unique name, such as a filename. A file can be of many data types, including a document,

an image, a video, or an application. Successful forensic processing of computer media depends on the

ability to collect, examine, and analyze the files that reside on the media. 

This section provides an overview of the most common media types and filesystemsómethods for

naming, storing, organizing, and accessing files. It then discusses how files should be collected and how

the integrity of the files should be preserved. The section also discusses various technical issues related to

file recovery, such as recovering data from deleted files. The last portion of the section describes the

examination and analysis of files, providing guidance on tools and techniques that can assist analysts.

15

4.1 File Basics

Before attempting to collect or examine files, analysts should have a reasonably comprehensive

understanding of files and filesystems. First, analysts should be aware of the variety of media that may

contain files; Section 4.1.1 provides several examples of the media used in personal computers and other

types of digital devices. Section 4.1.2 then explains how filesystems are used to organize files and

provides an overview of several common filesystems. Section 4.1.3 discusses how data from deleted files 

can still exist within filesystems.

4.1.1

 

File Storage Media 

The widespread use of computers and other digital devices has resulted in a significant increase in the

number of different media types that are used to store files. In addition to traditional media types such as

hard drives and floppy disks, files are often stored on consumer devices such as PDAs and cell phones, as

well as on newer media types, such as flash memory cards, which were made popular by digital cameras.

Table 4-1 lists media types that are commonly used on computers and digital devices. This list does not 

include every media type available; rather, it is intended to show the variety of media types that an analyst

might come across.

15 For additional information regarding examination and analysis, see Examination of Digital Evidence: A Guide for Law

Enforcement, which can be found at http://www.ncjrs.gov/pdffiles1/nij/199408.pdf. 

4-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Table 4-1. Commonly Used Media Types 

Media Type Reader Typical Capacity16 Comments

Primarily Used in Personal Computers

Floppy disk Floppy disk drive 1.44 megabytes 

(MB)

3.5-inch disks; decreasing in popularity

CD-ROM CD-ROM drive 650 MBñ800 MB Includes write-once (CD-R) and rewritable (CDRW) disks; most commonly used media 

DVD-ROM DVD-ROM drive 1.67 gigabytes

(GB)ñ15.9 GB

Includes write-once (DVD±R) and rewritable

(DVD±RW) single and dual layer disks 

Hard drive N/A 20 GBñ400 GB Higher capacity drives used in many file servers 

Zip disk Zip drive 100 MBñ750 MB Larger than a floppy disk 

Jaz disk Jaz drive 1 GBñ2 GB Similar to Zip disks; no longer manufactured

Backup tape Compatible tape

drive

80 MBñ320 GB Many resemble audio cassette tapes; fairly

susceptible to corruption from environmental

conditions 

Magneto

optical (MO)

disk 

Compatible MO drive 600 MBñ9.1 GB 5.25-inch disks; less susceptible to

environmental conditions than backup tapes 

Advanced

Technology

Attachment

(ATA) flash

card

PCMCIA slot 8 MBñ2 GB PCMCIA flash memory card; measures 85.6 x 54

x 5 mm 

Used by Many Types of Digital Devices

Flash/Jump

drive

USB interface 16 MBñ2 GB Also known as thumb drives because of their

size

CompactFlash

card

PCMCIA adapter or

memory card reader 

16 MBñ6 GB Type I cards measure 43 x 36 x 3.3 mm; Type II

cards measure 43 x 36 x 5 mm

Microdrive PCMCIA adapter or

memory card reader 

340 MBñ4 GB Same interface and form factor as CompactFlash

Type II cards

MultiMediaCard

(MMC)

PCMCIA adapter or

memory card reader 

16 MBñ512 MB Measures 24 x 32 x 1.4 mm

Secure Digital 

(SD) Card

PCMCIA adapter or

memory card reader 

32 MBñ1 GB Compliant with Secure Digital Music Initiative

(SDMI) requirements; provides built-in data

encryption of file contents; similar in form factor

to MMCs

Memory Stick PCMCIA adapter or

memory card reader 

16 MBñ2 GB Includes Memory Stick (50 x 21.5 x 2.8 mm),

Memory Stick Duo (31 x 20 x 1.6 mm), Memory

Stick PRO, Memory Stick PRO Duo; some are

compliant with SDMI requirements and provide

built-in encryption of file contents

SmartMedia

Card

PCMCIA adapter or

memory card reader 

8 MBñ128 MB Measures 37 x 45 x 0.76 mm

xD-Picture

Card

PCMCIA adapter or

xD-Picture card

reader 

16 MBñ512 MB Currently used only in Fujifilm and Olympus

digital cameras; measures 20 x 25 x 1.7 mm

 16 The maximum capacity of many media types increases over time because of advances in technology and reductions in cost.

4-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

4.1.2

 

Filesystems

Before media can be used to store files, the media must usually be partitioned and formatted into logical

volumes. Partitioning is the act of logically dividing a media into portions that function as physically

separate units. A logical volume is a partition or a collection of partitions acting as a single entity that has

been formatted with a filesystem. Some media types, such as floppy disks, can contain at most one

partition (and consequently, one logical volume). The format of the logical volumes is determined by the

selected filesystem.

A filesystem defines the way that files are named, stored, organized, and accessed on logical volumes. 

Many different filesystems exist, each providing unique features and data structures. However, all 

filesystems share some common traits. First, they use the concepts of directories and files to organize and

store data. Directories are organizational structures that are used to group files together. In addition to

files, directories may contain other directories called subdirectories. Second, filesystems use some data

structure to point to the location of files on media. In addition, they store each data file written to media

in one or more file allocation units. These are referred to as clusters by some filesystems (e.g., File

Allocation Table [FAT], NT File System [NTFS]) and as blocks by other filesystems (e.g., UNIX and

Linux). A file allocation unit is simply a group of sectors, which are the smallest units that can be

accessed on media.

Some commonly used filesystems are as follows:

! FAT12.

17 FAT12 is used only on floppy disks and FAT volumes smaller than 16 MB. FAT12

uses a 12-bit file allocation table entry to address an entry in the filesystem.

! FAT16. MS-DOS, Windows 95/98/NT/2000/XP, Windows Server 2003, and some UNIX OSs 

support FAT16 natively. FAT16 is also commonly used for multimedia devices such as digital

cameras and audio players. FAT16 uses a 16-bit file allocation table entry to address an entry in

the filesystem. FAT16 volumes are limited to a maximum size of 2 GB in MS-DOS and

Windows 95/98. Windows NT and newer OSs increase the maximum volume size for FAT16 to

4 GB.

! FAT32.

18 Windows 95 Original Equipment Manufacturer (OEM) Service Release 2 (OSR2),

Windows 98/2000/XP, and Windows Server 2003 support FAT32 natively, as do some

multimedia devices. FAT32 uses a 32-bit file allocation table entry to address an entry in the

filesystem. The maximum FAT32 volume size is 2 terabytes (TB).

! NTFS. Windows NT/2000/XP and Windows Server 2003 support NTFS natively. NTFS is a

recoverable filesystem, which means that it can automatically restore the consistency of the

filesystem when errors occur. In addition, NTFS supports data compression and encryption, and

allows user and group-level access permissions to be defined for data files and directories.19 The

maximum NTFS volume size is 2 TB.

! High-Performance File System (HPFS). HPFS is supported natively by OS/2 and can be read

by Windows NT 3.1, 3.5, and 3.51. HPFS builds on the directory organization of FAT by

providing automatic sorting of directories. In addition, HPFS reduces the amount of lost disk

space by utilizing smaller units of allocation. The maximum HPFS volume size is 64 GB. 

17 More information on FAT12 and FAT16 is available at

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx. 18 The FAT32 filesystem specification, which provides highly technical details on FAT32, is available for download from

http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx. 19 Additional NTFS features are described at http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx. 

4-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Second Extended Filesystem (ext2fs).

20 ext2fs is supported natively by Linux. It supports

standard UNIX file types and filesystem checks to ensure filesystem consistency. The maximum

ext2fs volume size is 4 TB.

! Third Extended Filesystem (ext3fs). ext3fs is supported natively by Linux. It is based on the

ext2fs filesystem and provides journaling capabilities that allow consistency checks of the

filesystem to be performed quickly on large amounts of data. The maximum ext3fs volume size

is 4 TB. 

! ReiserFS.

21 ReiserFS is supported by Linux and is the default filesystem for several common 

versions of Linux. It offers journaling capabilities and is significantly faster than the ext2fs and 

ext3fs filesystems. The maximum volume size is 16 TB.

! Hierarchical File System (HFS).

22 HFS is supported natively by Mac OS. HFS is mainly used

in older versions of Mac OS but is still supported in newer versions. The maximum HFS volume

size under Mac OS 6 and 7 is 2 GB. The maximum HFS volume size in Mac OS 7.5 is 4 GB. 

Mac OS 7.5.2 and newer Mac OSs increase the maximum HFS volume size to 2 TB.

! HFS Plus.

23 HFS Plus is supported natively by Mac OS 8.1 and later and is a journaling

filesystem under Mac OS X. It is the successor to HFS and provides numerous enhancements,

such as long filename support and Unicode filename support for international filenames. The

maximum HFS Plus volume size is 2 TB.

! UNIX File System (UFS).

24 UFS is supported natively by several types of UNIX OSs, including

Solaris, FreeBSD, OpenBSD, and Mac OS X. However, most OSs have added proprietary

features, so the details of UFS differ among implementations.

! Compact Disk File System (CDFS). As the name indicates, the CDFS filesystem is used for

CDs. 

! International Organization for Standardization (ISO) 9660 and Joliet. The ISO 9660 

filesystem is commonly used on CD-ROMs. Another popular CD-ROM filesystem, Joliet, is a

variant of ISO 9660. ISO 9660 supports filename lengths of up to 32 characters, whereas Joliet 

supports up to 64 characters. Joliet also supports Unicode characters within filenames.

! Universal Disk Format (UDF). UDF is the filesystem used for DVDs and is also used for some

CDs. 

4.1.3

 

Other Data on Media

As described in Section 4.1.2, filesystems are designed to store files on media. However, filesystems may

also hold data from deleted files or earlier versions of existing files. This data can provide important 

information. (Section 4.2 discusses techniques for collecting this type of data.) The following items 

describe how this data can still exist on various media:

! Deleted Files. When a file is deleted, it is typically not erased from the media; instead, the

information in the directoryís data structure that points to the location of the file is marked as

deleted. This means that the file is still stored on the media but is no longer enumerated by the

20 More information on ext2fs is available at http://e2fsprogs.sourceforge.net/ext2.html. 21 More information on ReiserFS and its successor, Reiser4, is available at http://www.namesys.com/. 22 An overview of HFS is available at http://developer.apple.com/documentation/mac/Files/Files-17.html. 23 An overview of HFS Plus and technical details on its implementation are available at

http://developer.apple.com/technotes/tn/tn1150.html. 24 An overview of UFS is available at http://en.wikipedia.org/wiki/Unix_File_System. 

4-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

OS. The operating system considers this to be free space and can overwrite any portion of or the

entire deleted file at any time.

! Slack Space. As noted previously, filesystems use file allocation units to store files. Even if a

file requires less space than the file allocation unit size, an entire file allocation unit is still

reserved for the file. For example, if the file allocation unit size is 32 kilobytes (KB) and a file is

only 7 KB, the entire 32 KB is still allocated to the file, but only 7 KB is used, resulting in 25 KB

of unused space. This unused space is referred to as file slack space, and it may hold residual

data such as portions of deleted files. 

! Free Space. Free space is the area on media that is not allocated to any partition; it includes

unallocated clusters or blocks. This often includes space on the media where files (and even

entire volumes) may have resided at one point but have since been deleted. The free space may 

still contain pieces of data. 

Another way in which data might be hidden is through Alternate Data Streams (ADS) within NTFS

volumes. NTFS has long supported multiple data streams for files and directories. Each file in an NTFS

volume consists of an unnamed stream that is used to store the file's primary data, and optionally one or

more named streams (i.e., file.txt:Stream1, file.txt:Stream2) that can be used to store auxiliary

information, such as file properties and picture thumbnail data.

25 For instance, if a user right-clicks on a 

file in Windows Explorer, views the fileís properties, and then modifies the information displayed in the

summary tab, the OS stores the summary information for the file in a named stream.

All data streams within a file share the fileís attributes (e.g., timestamps, security attributes). Although

named streams do affect the storage quota of a file, they are largely concealed from users because

standard Windows file utilities, such as Explorer, only report the size of a file's unnamed stream. As a 

result, a user cannot readily determine whether a file contains ADS using the standard Windows file

utilities. This allows hidden data to be contained within any NTFS filesystem. Moving files with ADS to

non-NTFS filesystems effectively strips ADS from the file, so the ADS can be lost if analysts are not 

aware of their presence. Software and processes are available to identify ADS.26 

4.2 Collecting Files

During data collection, the analyst should make multiple copies of the relevant files or filesystemsó

typically a master copy and a working copy.

27 The analyst can then use the working copy without 

affecting the original files or the master copy. Section 4.2.1 describes the primary techniques and tools 

for copying files and residual file data from media. Section 4.2.2 discusses the importance of maintaining

the integrity of the files and provides guidance on hardware and software that can assist in preserving and 

verifying file integrity. It is often important to collect not only the files, but also significant timestamps 

for the files, such as when the files were last modified or accessed. Section 4.2.3 describes the

timestamps and explains how they can be preserved. Other technical issues related to file collection, such

as finding hidden files and copying files from redundant array of inexpensive disks (RAID)

implementations, are addressed in Section 4.2.4.

 25 Directories do not have an unnamed stream but may contain named streams. 26 Additional information on ADS is available at

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx, 

http://www.infosecwriters.com/texts.php?op=display&id=53, and within http://www.heysoft.de/Frames/f_faq_ads_en.htm. 27 The purpose of the master copy is to generate additional working copies if the first working copy can no longer be used

because of alteration or other reasons.

4-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

4.2.1

 

Copying Files from Media

Files can be copied from media using two different techniques:

! Logical Backup. A logical backup copies the directories and files of a logical volume. It does

not capture other data that may be present on the media, such as deleted files or residual data

stored in slack space.

! Bit Stream Imaging. Also known as disk imaging, bit stream imaging generates a bit-for-bit 

copy of the original media, including free space and slack space. Bit stream images require more

storage space and take longer to perform than logical backups.

If evidence may be needed for prosecution or disciplinary actions, the analyst should get a bit stream

image of the original media, label the original media, and store it securely as evidence. All subsequent

analysis should be performed using the copied media to ensure that the original media is not modified and 

that a copy of the original media can always be recreated if necessary. All steps that were taken to create

the image copy should be documented. Doing so should allow any analyst to produce an exact duplicate

of the original media using the same procedures. In addition, proper documentation can be used to

demonstrate that evidence was not mishandled during the collection process. Besides the steps that were

taken to record the image, the analyst should document supplementary information such as the hard drive

model and serial number, media storage capacity, and information about the imaging software or

hardware that was used (e.g., name, version number, licensing information). All of these actions support

the maintenance of the chain of custody. 

When a bit stream image is executed, either a disk-to-disk or a disk-to-file copy can be performed. A

disk-to-disk copy, as its name suggests, copies the contents of the media directly to another media. A

disk-to-file copy copies the contents of the media to a single logical data file. A disk-to-disk copy is

useful since the copied media can be connected directly to a computer and its contents readily viewed. 

However, a disk-to-disk copy requires a second media similar to the original media.

28 A disk-to-file copy

allows the data file image to be moved and backed up easily. However, to view the logical contents of an

image file, the analyst has to restore the image to media or open or read it from an application capable of

displaying the logical contents of bit stream images. The details of this are OS and forensics tooldependent. Section 4.3 discusses this process in more detail.

Numerous hardware and software tools can perform bit stream imaging and logical backups. Hardware

tools are generally portable, provide bit-by-bit images, connect directly to the drive or computer to be

imaged, and have built-in hash functions.

29 Hardware tools can acquire data from drives that use common

types of controllers, such as Integrated Drive Electronics (IDE) and Small Computer System Interface

(SCSI). Software solutions generally consist of a startup diskette, CD, or installed programs that run on a

workstation to which the media to be imaged is attached.

30 Some software solutions create logical copies

28 The destination medium should be forensically clean before the copy occurs, so that any existing data on the medium is

eliminated. The destination medium should have a larger storage capacity than the data to be copied. 29 Examples of hardware-based disk imaging tools are Image MASSterís SOLO Forensics (http://www.ics-iq.com/) and

Logicubeís Solitaire (http://www.logicube.com/). Additional products are referenced in Web sites listed in Appendix F,

including The Ultimate Collection of Forensics Software (TUCOFS)

(http://www.tucofs.com/tucofs/tucofs.asp?mode=filelist&catid=10&oskey=12). The applications referenced throughout

this publication are by no means a complete list of applications to use for forensic purposes, nor does this publication 

imply any endorsement of certain products. 30 Examples of software-based disk imaging tools are Linux dd, SafeBack (http://www.forensics-intl.com/safeback.html),

EnCase (http://www.encase.com/), Norton Ghost 

(http://www.symantec.com/home_homeoffice/products/overview.jsp?pcid=br&pvid=ghost10), and ILook 

(http://www.ilook-forensics.org/). Additional products are referenced in Web sites listed in Appendix F.

4-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

of files or partitions and may ignore free or unallocated drive space, whereas others create a bit-by-bit

image copy of the media. 

In addition to their primary function, some disk imaging tools can also perform forensic recordkeeping,

such as automated audit trails and chain of custody. The use of such tools can support consistency in the

examination process and the accuracy and reproducibility of results. An increasing number of disk

imaging tools are becoming available. In response to this proliferation and the lack of a standard for 

testing them, NISTís Computer Forensics Tool Testing (CFTT) project has developed rigorous testing 

procedures for validating the toolsí results. Currently, only a few disk imaging tools have undergone

CFTT testing.

31 

Generally, tools that perform bit stream imaging should not be used to acquire bit-by-bit copies of an

entire physical device from a live systemóa system currently in useóbecause the files and memory on

such a system are changing constantly and therefore cannot be validated.32 However, a bit-by-bit copy of

the logical areas of a live system can be completed and validated. When logical backups are being

performed, it is still preferable not to copy files from a live system; changes might be made to files during

the backup, and files that are held open by a process might not be easy to copy. Accordingly, analysts 

should decide whether copying files from a live system is feasible based on which files need to be

obtained, how accurate and complete the copying needs to be, and how important the live system is.

33 For

example, it is not necessary to take down a critical server used by hundreds of people just to collect files 

from a single userís home directory. For logical backups of live systems, analysts can use standard

system backup software. However, performing a backup could affect the performance of the system and

consume significant amounts of network bandwidth, depending on whether the backup is performed

locally or remotely. 

Organizations should have policy, guidelines, and procedures that indicate the circumstances under which

bit stream images and logical backups (including those from live systems) may be performed for forensic

purposes and which personnel may perform them.

34 It is typically most effective to establish policy,

guidelines, and procedures based on categories of systems (i.e., low, moderate, or high impact) and the

nature of the event of interest; some organizations also choose to create separate policy statements,

guidelines, and procedures for particularly important systems. The policy, guidelines, or procedures

should identify the individuals or groups with authority to make decisions regarding backups and images;

these people should be capable of weighing the risks and making sound decisions. The policy, guidelines,

or procedures should also identify which individuals or groups have the authority to perform the backup

or imaging for each type of system. Access to some systems might be restricted because of the sensitivity

of the operations or data in the system.

4.2.2 

 

Data File Integrity 

During backups and imaging, the integrity of the original media should be maintained. To ensure that the

backup or imaging process does not alter data on the original media, analysts can use a write-blocker

while backing up or imaging the media. A write-blocker is a hardware or software-based tool that

prevents a computer from writing to computer storage media connected to it. Hardware write-blockers

are physically connected to the computer and the storage media being processed to prevent any writes to

31 The test results can be found at http://www.cftt.nist.gov/disk_imaging.htm. 32 For example, services or processes running on the system might be writing to a systemís hard drive, even if no person is

currently using the computer. 33 Analysts should also consider the possible need to collect volatile data from the system. If the system is live, its volatile 

data is likely to change more quickly and to be more challenging to preserve. 34 This recommendation is not intended to restrict users from performing backups of their own data and local workstations, but

to prevent people from collecting backups of othersí systems and data without appropriate cause for doing so.

4-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

that media.35 Software write-blockers are installed on the analystís forensic system and currently are

available only for MS-DOS and Windows systems. (Some OSs [e.g., Mac OS X, Linux] may not require

software write-blockers because they can be set to boot with secondary devices not mounted. However,

attaching a hardware write-blocking device will ensure that integrity is maintained.) MS-DOSñbased

software write-blockers work by trapping Interrupt 13 and extended Interrupt 13 disk writes. Windowsbased software write-blockers use filters to sort interrupts sent to devices to prevent any writes to storage

media.

36 

In general, when using a hardware write-blocker, the media or device used to read the media should be

connected directly to the write-blocker, and the write-blocker should be connected to the computer or

device used to perform the backup or imaging. When using a software write-blocker, the software should

be loaded onto a computer before the media or device used to read the media is connected to the

computer. Write-blockers may also allow write-blocking to be toggled on or off for a particular device. 

It is important when write-blocking is used, that it be toggled on for all connected devices.37 Writeblockers also should be tested routinely to ensure that they support newer devices. For example, a new

device might make use of reserved or previously unused functions or placeholders to implement devicespecific functions that might ultimately write to the device and alter its contents.

After a backup or imaging is performed, it is important to verify that the copied data is an exact duplicate

of the original data.

38 Computing the message digest of the copied data can be used to verify and ensure

data integrity.

39 A message digest is a hash that uniquely identifies data and has the property that

changing a single bit in the data will cause a completely different message digest to be generated. There

are many algorithms for computing the message digest of data, but the two most commonly used are

MD5 and Secure Hash Algorithm 1 (SHA-1). These algorithms take as input data of arbitrary length and

produce as output 128-bit message digests. Because SHA-1 is a Federal Information Processing

Standards (FIPS)ñapproved algorithm and MD5 is not, Federal agencies should use SHA-1 instead of

MD5 for message digests.40

When a bit stream image is performed, the message digest of the original media should be computed and

recorded before the image is performed. After the imaging, the message digest of the copied media

should be computed and compared with the original message digest to verify that data integrity has been

preserved. The message digest of the original media should then be computed again to verify that the

imaging process did not alter the original media, and all results should be documented. The process 

should be used for logical backups, except that message digests should be computed and compared for

 35 Examples of hardware write-blockers are FastBloc (http://www.guidancesoftware.com/lawenforcement/ef_index.asp),

NoWrite (http://www.mykeytech.com/nowrite.html), and SCSIBlock 

(http://www.digitalintelligence.com/products/scsiblock/). Additional tools are referenced in the Web sites listed in

Appendix F. 36 An example of a software write-blocker is PDBlock (http://www.digitalintelligence.com/software/disoftware/pdblock/). 

Additional tools are referenced in the Web sites listed in Appendix F. 37 These are only general guidelines for using write-blockers. Analysts should refer to the operating procedures for a specific

write-blocker product for instructions on proper usage. 38 If a backup is performed on a live system, it is likely that some files will change between the time the backup was initiated

and the time it is completed and verified. 39 Message digests should be used to ensure the integrity of all data that is acquired during forensic activity, including log files

and logical backups. 40 Federal agencies must use FIPS-approved encryption algorithms contained in validated cryptographic modules. The

Cryptographic Module Validation Program (CMVP) at NIST coordinates FIPS testing; the CMVP Web site is located at

http://csrc.nist.gov/cryptval/. FIPS 180-2, Secure Hash Standard, is available at

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf. NIST has announced that Federal agencies

should plan to transition from SHA-1 to stronger forms of SHA (e.g., SHA-224, SHA-256) by 2010. For more information,

see NIST comments from August 2004 posted at http://csrc.nist.gov/hash_standards_comments.pdf, as well as

http://www.nsrl.nist.gov/collision.html. 

4-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

each data file. For both bit stream images and logical backups, the message digests created to ensure data

integrity should be stored on read-only or write-once media or printed, and then secured in a proper

location.

4.2.3 

4.2.4

 

File Modification, Access, and Creation Times 

It is often important to know when a file was created, used, or manipulated, and most OSs keep track of

certain timestamps related to files. The most commonly used timestamps are the modification, access,

and creation (MAC) times, as follows:

! Modification Time. This is the last time a file was changed in any way, including when a file is

written to and when it is changed by another program.

! Access Time. This is the last time any access was performed on a file (e.g., viewed, opened, 

printed).

! Creation Time. This is generally the time and date the file was created; however, when a file is

copied to a system, the creation time will become the time the file was copied to the new system. 

The modification time will remain intact.

Different types of filesystem may store different types of times. For example, Windows systems retain

the last modified time, the last access time, and the creation time of files.41 UNIX systems retain the last 

modification, last inode42 change, and last access times; however, some UNIX systems (including

versions of BSD and SunOS) do not update the last access time of executable files when they are run. 

Some UNIX systems record the time when the metadata for a file was most recently altered. Metadata is

data about data; for filesystems, metadata is data that provides information about a fileís contents.

If an analyst needs to establish an accurate timeline of events, then the file times should be preserved. 

Accordingly, analysts should be aware that not all methods for collecting data files can preserve file

times. Bit stream images can preserve file times because a bit-for-bit copy is generated; performing a

logical backup using some tools may cause file creation times to be altered when the data file is copied. 

For this reason, whenever file times are essential, bit stream imaging should be used to collect data.

Analysts should also be aware that file times may not always be accurate. Among the reasons for such

inaccuracies are the following:

! The computerís clock does not have the correct time. For example, the clock may not have been

synchronized regularly with an authoritative time source.

! The time may not be recorded with the expected level of detail, such omitting the seconds or

minutes.

! An attacker may have altered the recorded file times.

Technical Issues

Several technical issues may arise in collecting data files. As noted in Section 4.2.1, the primary issue is

the collection of deleted files and remnants of files existing in free and slack space on media. Individuals 

can use a variety of techniques to hinder the collection of such data. For example, there are many utilities 

available that perform wipingóthe overwriting of media (or portions of media, such as particular files)

with random or constant values (e.g., all 0ís). Such utilities vary in services and reliability, but most are

41 Windows systems using the NTFS filesystem also record the entry modified time. 42 An inode is a set of data regarding certain characteristics of a file, such as the privileges set for the file and the fileís owner.

4-9
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

effective in preventing easy collection of files, especially if several wipes are performed. Individuals can

also use physical means to prevent data collection, such as demagnetizing a hard drive (also known as

degaussing) or physically damaging or destroying media. Both physical and software-based techniques

can make it very difficult, or even impossible, to recover all of the data using software. Recovery

attempts in these cases necessitate the use of highly specialized forensic experts with advanced facilities,

hardware, and techniques, but the cost and effort involved in making use of such means are prohibitive

for general use.

43 In some cases, the data is simply not recoverable. 

Another common issue is the collection of hidden data. Many OSs permit users to tag certain files,

directories, or even partitions as hidden, which means that by default they are not displayed in directory

listings.

44 Some applications and OSs hide configuration files to reduce the chance that users will

accidentally modify or delete them. Also, on some OSs, directories that have been deleted may be

marked as hidden. Hidden data may contain a wealth of information; for example, a hidden partition 

could contain a separate OS and many data files.

45 Users may create hidden partitions by altering the

partition table to disrupt disk management and prevent applications from seeing that the data area exists. 

Hidden data can also be found within ADSs on NTFS volumes, in the end-of-file slack space and free

space on a medium, and in the Host Protected Area (HPA) on some hard drives, which is a region of a 

drive intended to be used by vendors only. Many collection tools can recognize some or all of these

methods of hiding data and recover the associated data. 

Yet another issue that may arise is collection of data from RAID arrays that use striping (e.g., RAID-0, 

RAID-5).46 In this configuration, a striped volume consists of equal-sized partitions that reside on

separate disk drives. When data is written to the volume, it is evenly distributed across the partitions to

improve disk performance. This can cause problems because all partitions of a striped volume must be

present for the examination of its contents, but in this case the partitions reside on separate physical disk

drives. To examine a striped volume, each disk drive in the RAID array needs to be imaged and the

RAID configuration has to be recreated on the examination system.

47 The examination system needs to

be booted using a forensic boot disk that can recognize and use the RAID array and that prevents writes to

the array. Some imaging tools can acquire striped volumes and preserve unused data areas of the volume,

such as free space and slack space.

48

4.3 Examining Data Files 

After a logical backup or bit stream imaging has been performed, the backup or image may have to be

restored to another media before the data can be examined. This is dependent on the forensic tools that

will be used to perform the analysis. Some tools can analyze data directly from an image file, whereas

others require that the backup or image be restored to a medium first.

49 Regardless of whether an image

file or a restored image is used in the examination, the data should be accessed only as read-only to ensure

 43 Companies that specialize in such recovery efforts include Data Recovery Services, DriveSavers, and Ontrack Data

Recovery. 44 On UNIX systems, files or folders beginning with a ë.í are considered hidden and are not displayed when listing files unless

the ña flag is used. 45 An example of a freely available tool that can be used to locate hidden partitions is the FDISK utility built into DOS. 

Information about additional tools is available from the Web sites listed in Appendix F. 46 An overview of RAID is available at

http://www.adaptec.com/worldwide/product/markeditorial.html?prodkey=quick_explanation_of_raid. 47 Because RAID-5 stores parity information on one disk, it is possible to examine a RAID-5 volume by imaging all of the

disks but one. 48 For more information regarding RAIDs, visit http://www.anandtech.com/storage/showdoc.html?i=1491. 49 At one time, when tools had more limited capabilities, it was often recommended that data files be restored to a system

using the same OS or a related one. Current tools are more advanced and are designed to be used with many types of data

files, regardless of the underlying OS, so it is no longer necessary in most cases to restore data files to a particular OS. 

4-10
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

that the data being examined is not modified and that it will provide consistent results on successive runs. 

As noted in Section 4.2.2, write-blockers can be used during this process to prevent writes from occurring

to the restored image. After restoring the backup (if needed), the analyst begins to examine the collected

data and performs an assessment of the relevant files and data by locating all files, including deleted files,

remnants of files in slack and free space, and hidden files. Next, the analyst may need to extract the data

from some or all of the files, which may be complicated by such measures as encryption and password 

protection. This section describes the processes involved in examining files and data, as well as

techniques that can expedite examination.

4.3.1

4.3.2

 

Locating the Files

The first step in the examination is to locate the files. A disk image can capture many gigabytes of slack

space and free space, which could contain thousands of files and file fragments. Manually extracting data

from unused space can be a time-consuming and difficult process, because it requires knowledge of the

underlying filesystem format. Fortunately, several tools are available that can automate the process of

extracting data from unused space and saving it to data files, as well as recovering deleted files and files 

within a recycling bin. Analysts can also display the contents of slack space with hex editors or special 

slack recovery tools.

Extracting the Data

The rest of the examination process involves extracting data from some or all of the files. To make sense

of the contents of a file, an analyst needs to know what type of data the file contains. The intended

purpose of file extensions is to denote the nature of the fileís contents; for example, a jpg extension

indicates a graphic file, and an mp3 extension indicates a music file. However, users can assign any file

extension to any type of file, such as naming a text file mysong.mp3 or omitting a file extension. In

addition, some file extensions might be hidden or unsupported on other OSs. Therefore, analysts should

not assume that file extensions are accurate.

Analysts can more accurately identify the type of data stored in many files by looking at their file headers. 

A file header contains identifying information about a file and possibly metadata that provides

information about the fileís contents. As shown in Figure 4-1, the file header contains a file signature that

identifies the type of data that particular file contains.

50 The example in Figure 4-1 has a file header of FF

D8, which indicates that this is a JPEG file. A file header could be located in a file separate from the

actual file data. Another effective technique for identifying the type of data in a file is a simple histogram

showing the distribution of ASCII values as a percentage of total characters in a file. For example, a

spike in the ëspaceí, ëaí, and ëeí lines generally indicates a text file, while consistency across the

histogram indicates a compressed file. Other patterns are indicative of files that are encrypted or that

were modified through steganography.

50 File headers can also indicate whether a file is encrypted. Attackers can alter file headers using a hex editor to conceal the 

actual file type, and then alter the file header back to use the file. In some cases, a file can be used even when its header is

altered.

4-11
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Figure 4-1. File Header Information 

Encryption often presents challenges for analysts. Users might encrypt individual files, folders, volumes,

or partitions so that others cannot access their contents without a decryption key or passphrase.

51 The

encryption might be performed by the OS or a third-party program. Although it is relatively easy to

identify an encrypted file, it is usually not so easy to decrypt it. The analyst might be able to identify the

encryption method by examining the file header, identifying encryption programs installed on the system,

or finding encryption keys (which are often stored on other media). Once the encryption method is

known, the analyst can better determine the feasibility of decrypting the file. In many cases, it is not

possible to decrypt files because the encryption method is strong and the authentication (e.g., passphrase)

used to perform decryption is unavailable.

Although an analyst can detect the presence of encrypted data rather easily, the use of steganography is

more difficult to detect. Steganography, also known as steg, is the embedding of data within other data.

Digital watermarks and the hiding of words and information within images are examples of

steganography. Some techniques an analyst can use to locate stegged data include looking for multiple

versions of the same image, identifying the presence of grayscale images, searching metadata and

registries, using histograms, and using hash sets to search for known steganography software. Once

certain that stegged data exists, analysts might be able to extract the embedded data by determining what

software created the data and then finding the stego key, or by using brute force and cryptographic attacks 

to determine a password.

52 However, such efforts are often unsuccessful and can be extremely timeconsuming, particularly if the analyst does not find the presence of known steganography software on the

media being reviewed. In addition, some software programs can analyze files and estimate the

probability that the files were altered with steganography. 

Analysts may also need to access non-stegged files that are protected by passwords. Passwords are often 

stored on the same system as the files they protect, but in an encoded or encrypted format. Various

utilities are available that can crack passwords placed on individual files, as well as OS passwords.

53 

Most cracking utilities can attempt to guess passwords, as well as performing brute force attempts that try

every possible password. The time needed for a brute force attack on an encoded or encrypted password 

can vary greatly, depending on the type of encryption used and the sophistication of the password itself. 

Another approach is to bypass a password. For example, an analyst could boot a system and disable its

screensaver password, or bypass a Basic Input/Output System (BIOS) password by pulling the BIOS

 51 Although volumes and partitions can be encrypted on some operating systems, this is not common due to corruption and

other functional problems that may result in a complete loss of data if only a sector of data is corrupted. Encryption of

individual files and folders is far more common, and is supported by many newer operating systems. 52 Further discussion regarding steganography is outside the scope of this document. For more information, see the article An

Overview of Steganography for the Computer Forensics Examiner by Gary Kessler, available at

http://www.fbi.gov/hq/lab/fsc/backissu/july2004/research/2004_03_research01.htm. 53 An example of an open source password cracking utility is John the Ripper, which supports multiple OSs and file types.

Additional password cracking utilities are listed on several Web sites listed in Appendix F, including Computer Forensics

Tools (http://www.forensix.org/tools/) and The Ultimate Collection of Forensic Software (TUCOFS)

(http://www.tucofs.com/tucofs.htm). 

4-12
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

jumper from the systemís motherboard or using a manufacturerís backdoor password.54 Of course, 

bypassing a password might mean rebooting the system, which might be undesirable. Another possibility

is to attempt to capture the password through network or host-based controls (e.g., packet sniffer,

keystroke logger), with proper management and legal approval. If a boot-up password has been set on a

hard drive, it might be possible to guess it (i.e., a default password from a vendor) or to circumvent it with

specialized hardware and software.

4.3.3

 

Using a Forensic Toolkit

Analysts should have access to various tools that enable them to perform examinations and analysis of

data, as well as some collection activities. Many forensic products allow the analyst to perform a wide

range of processes to analyze files and applications, as well as collecting files, reading disk images, and

extracting data from files. Most analysis products also offer the ability to generate reports and to log all

errors that occurred during the analysis. Although these products are invaluable in performing analysis, it

is critical to understand which processes should be run to answer particular questions about the data. An 

analyst may need to provide a quick response or just answer a simple question about the collected data.

In these cases, a complete forensic evaluation may not be necessary or even feasible. The forensic toolkit 

should contain applications that can accomplish data examination and analysis in many ways and can be

run quickly and efficiently from floppy disks, CDs, or a forensic workstation. The following processes

are among those that an analyst should be able to perform with a variety of tools:

! Using File Viewers. Using viewers instead of the original source applications to display the

contents of certain types of files is an important technique for scanning or previewing data, and is

more efficient because the analyst does not need native applications for viewing each type of file. 

Various tools are available for viewing common types of files, and there are also specialized tools

solely for viewing graphics. If available file viewers do not support a particular file format, the

original source application should be used; if this is not available, then it may be necessary to

research the fileís format and manually extract the data from the file.

55

! Uncompressing Files. Compressed files may contain files with useful information, as well as

other compressed files. Therefore, it is important that the analyst locate and extract compressed

files. Uncompressing files should be performed early in the forensic process to ensure that the

contents of compressed files are included in searches and other actions. However, analysts

should keep in mind that compressed files might contain malicious content, such as compression

bombs, which are files that have been repeatedly compressed, typically dozens or hundreds of

times. Compression bombs can cause examination tools to fail or consume considerable

resources; they might also contain malware and other malicious payloads. Although there is no

definite way to detect compression bombs before uncompressing a file, there are ways to

minimize their impact. For instance, the examination system should use up-to-date antivirus 

software and should be standalone to limit the effects to just that system. In addition, an image of

the examination system should be created so that, if needed, the system can be restored.

! Graphically Displaying Directory Structures. This practice makes it easier and faster for

analysts to gather general information about the contents of media, such as the type of software

installed and the likely technical aptitude of the user(s) who created the data. Most products can

display Windows, Linux, and UNIX directory structures, whereas other products are specific to

Macintosh directory structures.

54 See the article How to Bypass BIOS Passwords (available at http://labmice.techtarget.com/articles/BIOS_hack.htm) for

more information and examples of known BIOS backdoor passwords. 55 Web sites such as Wotsitís Format (http://www.wotsit.org/) contain file format information for hundreds of file types. 

4-13
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Identifying Known Files. The benefit of finding files of interest is obvious, but it is also often

beneficial to eliminate unimportant files, such as known good OS and application files, from

consideration. Analysts should use validated hash sets, such as those created by NISTís National

Software Reference Library (NSRL) project

56 or personally created hash sets57 that have been

validated, as a basis for identifying known benign and malicious files. Hash sets typically use the

SHA-1 and MD5 algorithms to establish message digest values for each known file.

! Performing String Searches and Pattern Matches. String searches aid in perusing large

amounts of data to find key words or strings. Various searching tools are available that can use

Boolean, fuzzy logic, synonyms and concepts, stemming, and other search methods. Examples of

common searches include searching for multiple words in a single file and searching for

misspelled versions of certain words. Developing concise sets of search terms for common 

situations can help the analyst reduce the volume of information to review. Some considerations

or possible difficulties in performing string searches are as follows:

ñ Some proprietary file formats cannot be string searched without additional tools. In addition,

compressed, encrypted, and password-protected files require additional pre-processing before

a string search. 

ñ The use of multi-character data sets that include foreign or Unicode characters can cause

problems with string searches; some searching tools attempt to overcome this by providing

language translation functions. 

ñ Another possible issue is the inherent limitations of the search tool or algorithm. For

example, a match might not be found for a search string if part of the string resided in one

cluster and the rest of the string resided in a nonadjacent cluster. Similarly, some search tools 

might report a false match if part of a search string resided in one cluster and the remainder of

the string resided in another cluster that was not part of the same file that contained the first 

cluster.

! Accessing File Metadata. File metadata provides details about any given file. For example,

collecting the metadata on a graphic file might provide the graphicís creation date, copyright 

information, and description, and the creatorís identity.

58 Metadata for graphics generated by a

digital camera might include the make and model of the digital camera used to take the image, as

well as F-stop, flash, and aperture settings. For word processing files, metadata could specify the

author, the organization that licensed the software, when and by whom edits were last performed,

and user-defined comments. Special utilities can extract metadata from files.

4.4 Analysis

After the examination has been completed, the next step is to perform analysis of the extracted data. As

mentioned in Section 4.3.3, there are many tools available that can be helpful in analysis of different types 

of data. When using these tools or performing manual reviews of data, analysts should be aware of the

value of using system times and file times. Knowing when an incident occurred, a file was created or

modified, or an e-mail was sent can be critical to forensic analysis. For example, such information can be

used to reconstruct a timeline of activities. Although this may seem like a simple task, it is often

 56 The NSRL home page is located at http://www.nsrl.nist.gov/. 57 Analysts may also create hashes of system files periodically; these hash sets are then available when an event occurs so that

the analyst can quickly eliminate known benign files from examination. Analysts should rely on standard hash sets such as

those from the NSRL project whenever possible, and create custom hash sets primarily for organization-specific files. 58 Only certain types of graphics files include metadata; for example, JPEG-format graphics might have metadata, but bitmapformat graphics cannot.

4-14
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

complicated by unintentional or intentional discrepancies in time settings among systems. Knowing the

time, date, and time zone settings for a computer whose data will be analyzed can greatly assist an

analyst; Section 5 describes this in more detail. 

It is usually beneficial to analysts if an organization maintains its systems with accurate timestamping. 

The Network Time Protocol (NTP) synchronizes the time on a computer with an atomic clock run by

NIST or other organizations. Synchronization helps ensure that each system maintains a reasonably 

accurate measurement of time.

If multiple tools are used to complete an examination and analysis, the analyst should understand how

each tool extracts, modifies, and displays file modification, access, and creation (MAC) times. For

instance, some tools modify the last access time of a file or directory if the filesystem has been mounted

with write permissions by the OS. Write-blockers can be used to prevent these tools from modifying the

MAC times; however, although write-blockers can prevent these times from being modified on the media,

they cannot prevent the OS from caching the changes in memory (i.e., storing the changes in random

access memory [RAM]). The OS might then report the cached MAC times rather than the actual times,

thereby returning inaccurate results. The analyst should be aware that the last access time for data files 

and directories might change between queries, depending on the tool used to perform the query. Because

of these issues, analysts should take care in choosing a MAC viewing method and record the details of

that method.

Analysts can use special tools that can generate forensic timelines based on event data. Such tools 

typically give analysts a graphical interface for viewing and analyzing sequences of events. A common 

feature of these tools is to permit analysts to group related events into meta-events. This helps analysts to

get a ìbig pictureî view of events.

In many cases, forensic analysis involves not only data from files, but also data from other sources, such

as the OS state, network traffic, or applications. Section 8 provides examples of how data from files and 

data from other sources can be correlated through analysis.

4.5 Recommendations

The key recommendations presented in this section for using data from data files are as follows.

! Analysts should examine copies of files, not the original files. During the collection phase, the

analyst should make multiple copies of the desired files or filesystems, typically a master copy

and a working copy. The analyst can then work with the working copy of the files without 

affecting the original files or the master copy. A bit stream image should be performed if

evidence may be needed for prosecution or disciplinary actions, or if preserving file times is

important.

! Analysts should preserve and verify file integrity. Using a write-blocker during backups and

imaging prevents a computer from writing to its storage media. The integrity of copied data

should be verified by computing and comparing the message digests of files. Backups and 

images should be accessed as read-only whenever possible; write-blockers can also be used to

prevent writes to the backup or image file or restored backup or image.

! Analysts should rely on file headers, not file extensions, to identify file content types. 

Because users can assign any file extension to a file, analysts should not assume that file

extensions are accurate. Analysts can identify the type of data stored in many files by looking at

their file headers. Although people can alter file headers to conceal actual file types, this is much

less common than altering file extensions.

4-15
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Analysts should have a forensic toolkit for data examination and analysis. The toolkit should

contain various tools that provide the ability to perform quick reviews of data as well as in-depth

analysis. The toolkit should allow its applications to be run quickly and efficiently from

removable media (e.g., floppy disk, CD) or a forensic workstation.

4-16
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

5. Using Data from Operating Systems 

An operating system (OS) is a program that runs on a computer and provides a software platform on

which other programs can run. In addition, an OS is responsible for processing input commands from a

user, sending output to a display, interacting with storage devices to store and retrieve data, and 

controlling peripheral devices such as printers and modems. Some common OSs for workstations or

servers include various versions of Windows, Linux, UNIX, and Mac OS. Some network devices, such

as routers, have their own proprietary OSs (e.g., Cisco Internetwork Operating System [IOS]). PDAs

often run specialized OSs, including PalmOS and Windows CE.

59 Many embedded systems, such as

cellular phones, digital cameras, and audio players, also use OSs.

60 This section discusses the

components of an OS that might be relevant to forensics and provides guidance on collecting, examining,

and analyzing data from common workstation and server OSs.

61

5.1 OS Basics

OS data exists in both non-volatile and volatile states. Non-volatile data refers to data that persists even

after a computer is powered down, such as a filesystem stored on a hard drive. Volatile data refers to data

on a live system that is lost after a computer is powered down, such as the current network connections to

and from the system. Many types of non-volatile and volatile data may be of interest from a forensics 

perspective. This section discusses both of these types of OS data.

5.1.1

 

Non-Volatile Data

The primary source of non-volatile data within an OS is the filesystem.

62 The filesystem is also usually

the largest and richest source of data within the OS, containing most of the information recovered during

a typical forensic event. The filesystem provides storage for the OS on one or more media.

63 A

filesystem typically contains many types of files, each of which may be of value to analysts in different

situations. In addition, as noted in Section 4.1.2, important residual data can be recovered from unused

filesystem space. Several types of data that are commonly found within OS filesystems are as follows:

! Configuration Files. The OS may use configuration files to store OS and application settings.

64 

For example, configuration files could list the services to be started automatically after system

boot, and specify the location of log files and temporary files. Users might also have individual

OS and application configuration files that contain user-specific information and preferences,

such as hardware-related settings (e.g., screen resolution, printer settings) and file associations. 

Configuration files of particular interest are as follows:

59 For more information on PDA forensics, see NIST SP 800-72, Guidelines on PDA Forensics, available at

http://csrc.nist.gov/publications/nistpubs/index.html. 60 A discussion of the types of information that can be found on these types of devices and the methods for collecting,

examining, and analyzing the information is beyond the scope of this document. Because of the wide variety of devices and 

the knowledge and equipment needed in many cases to forensically process the data they contain, most organizations will

find it best to secure such a device and transfer it to an appropriate party that is experienced in collecting, examining, and 

analyzing data from such devices (e.g., a law enforcement agency). 61 Guidance specific to data from proprietary and specialized operating systems is beyond the scope of this document;

however, many of the concepts described in this section should also apply to them. 62 This may not be true for some devices, such as consumer electronics that do not use standard filesystems. 63 In some cases, the filesystem may be ìstoredî in dynamic memory. The term memory filesystems refers to filesystems that

reside only in a systemís memory. Such filesystems are considered volatile data. Filesystems, including an entire bootable

OS implementation, may also reside on removable media such as flash drives. 64 On Windows systems, many configuration settings reside in a set of special files known as the registry. For more

information on the registry, see Microsoft Knowledge Base article 256986, Description of the Microsoft Windows Registry, 

available at http://support.microsoft.com/?id=256986. 

5-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

ñ Users and Groups. The OS keeps a record of its user accounts and groups. Account

information may include group membership, account name and description, account

permissions, account status (e.g., active, disabled), and the path to the accountís home

directory.

ñ Password Files. The OS may store password hashes in data files. Various passwordcracking utilities may be used to convert a password hash to its clear text equivalent for

certain OSs.

ñ Scheduled Jobs. The OS maintains a list of scheduled tasks that are to be performed

automatically at a certain time (e.g., perform a virus scan every week). Information that can

be gleaned from this include the task name, the program used to perform the task, command

line switches and arguments, and the days and times when the task is to be performed.

! Logs. OS log files contain information about various OS events, and may also hold applicationspecific event information. Depending on the OS, logs may be stored in text files, proprietaryformat binary files, or databases. Some OSs write log entries to two or more separate files. The

types of information typically found in OS logs are as follows:

ñ System Events. System events are operational actions performed by OS components, such

as shutting down the system or starting a service. Typically, failed events and the most

significant successful events are logged, but many OSs permit system administrators to

specify which types of events will be logged. The details logged for each event also vary

widely. Each event is usually timestamped; other supporting information could include event 

codes, status codes, and username.

ñ Audit Records. Audit records contain security event information such as successful and

failed authentication attempts and security policy changes. OSs typically permit system

administrators to specify which types of events should be audited. Administrators also can

configure some OSs to log successful, failed, or all attempts to perform certain actions.

ñ Application Events. Application events are significant operational actions performed by

applications, such as application startup and shutdown, application failures, and major

application configuration changes. Section 7 contains more information on application event 

logging.

ñ Command History. Some OSs have separate log files (typically for each user) that contain a

history of the OS commands performed by each user.

ñ Recently Accessed Files. An OS might log the most recent file accesses or other usage,

creating a list of the most recently accessed files.

! Application Files. Applications can be composed of many types of files, including executables,

scripts, documentation, configuration files, log files, history files, graphics, sounds, and icons. 

Section 7 provides an in-depth discussion of application files.

! Data Files. Data files store information for applications. Examples of common data files are text 

files, word processing documents, spreadsheets, databases, audio files, and graphics files. In

addition, when data is printed, most OSs create one or more temporary print files that contain the

print-ready version of the data. Sections 4 and 7 discuss application data files in more depth.

! Swap Files. Most OSs use swap files in conjunction with RAM to provide temporary storage for

data often used by applications. Swap files essentially extend the amount of memory available to

5-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

a program by allowing pages (or segments) of data to be swapped in and out of RAM. Swap files 

may contain a broad range of OS and application information, such as usernames, password 

hashes, and contact information. Section 5.1.2 discusses the contents of memory in more detail.

! Dump Files. Some OSs have the ability to store the contents of memory automatically during an

error condition to assist in subsequent troubleshooting. The file that holds the stored memory

contents is known as a dump file.

! Hibernation Files. A hibernation file is created to preserve the current state of a system

(typically a laptop) by recording memory and open files before shutting off the system. When the

system is next turned on, the state of the system is restored.

! Temporary Files. During the installation of an OS, application, or OS or application updates and 

upgrades, temporary files are often created. Although such files are typically deleted at the end of

the installation process, this does not always occur. In addition, temporary files are created when

many applications are run; again, such files are usually deleted when the application is

terminated, but this does not always happen. Temporary files could contain copies of other files

on the system, application data, or other information.

Although filesystems are the primary source of non-volatile data, another source of interest is the BIOS. 

The BIOS contains many types of hardware-related information, such as the attached devices (e.g., CDROM drives, hard drives), the types of connections and interrupt request line (IRQ) assignments (e.g.,

serial, USB, network card), motherboard components (e.g., processor type and speed, cache size, memory

information), system security settings, and hot keys. The BIOS also communicates with RAID drivers 

and displays the information provided by the drivers. For example, the BIOS views a hardware RAID as

a single drive and a software RAID as multiple drives. The BIOS typically permits the user to set 

passwords, which restrict access to the BIOS settings and may prevent the system from booting if the

password is not supplied. The BIOS also holds the system date and time.

5.1.2 Volatile Data

OSs execute within the RAM of a system. While the OS is functioning, the contents of RAM are

constantly changing. At any given time, RAM might contain many types of data and information that

could be of interest. For example, RAM often contains frequently and recently accessed data, such as

data files, password hashes, and recent commands. In addition, like filesystems, RAM can contain 

residual data in slack and free space, as follows:

! Slack Space. Memory slack space is much less deterministic than file slack space. For example,

an OS generally manages memory in units known as pages or blocks, and allocates them to

requesting applications. Sometimes, although an application might not request an entire unit, it is

given one anyway. Residual data could therefore reside in the unit of memory allocated to an

application, although it might not be addressable by the application. For performance and 

efficiency, some OSs vary the size of the units they allocate, which tends to result in smaller

memory slack spaces.

! Free Space. Memory pages are allocated and deallocated much like file clusters. When they are

not allocated, memory pages are often collected into a common pool of available pagesóa

process often referred to as garbage collection. It is not uncommon for residual data to reside in

these reusable memory pages, which are analogous to unallocated file clusters.

Some other significant types of volatile data that might exist within an OS are as follows:

5-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Network Configuration. Although many elements of networking, such as network interface

card (NIC) drivers and configuration settings, are typically stored in the filesystem, networking is

dynamic in nature. For example, many hosts are assigned Internet Protocol (IP) addresses 

dynamically by another host, meaning that their IP addresses are not part of the stored

configuration. Many hosts also have multiple network interfaces defined, such as wired, wireless,

virtual private network (VPN), and modem; the current network configuration indicates which

interfaces are currently in use. Users also may be able to alter network interface configurations

from the defaults, such as manually changing IP addresses. Accordingly, analysts should use the

current network configuration, not the stored configuration, whenever possible.

! Network Connections. The OS facilitates connections between the system and other systems. 

Most OSs can provide a list of current incoming and outgoing network connections, and some

OSs can list recent connections as well. For incoming connections, the OS typically indicates 

which resources are being used, such as file shares and printers. Most OSs can also provide a list 

of the ports and IP addresses at which the system is listening for connections. Section 6 provides

an in-depth examination of the significance of network connections.

! Running Processes. Processes are the programs that are currently executing on a computer. 

Processes include services offered by the OS and applications run by administrators and users. 

Most OSs offer ways to view a list of the currently running processes. This list can be studied to

determine the services that are active on the system, such as a Web server, and the programs that

individual users are running (e.g., encryption utility, word processor, e-mail client). Process lists

may also indicate which command options were used, as described in Section 7. Identifying the

running processes is also helpful for identifying programs that should be running but have been

disabled or removed, such as antivirus software and firewalls.

! Open Files. OSs may maintain a list of open files, which typically includes the user or process 

that opened each file. 

! Login Sessions. OSs typically maintain information about currently logged-in users (and the

start time and duration of each session), previous successful and failed logons, privileged usage,

and impersonation.

65 However, login session information might be available only if the computer

has been configured to audit logon attempts. Logon records can help to determine a userís

computer usage habits and confirm whether a user account was active when a given event 

occurred.

! Operating System Time. The OS maintains the current time and stores daylight savings time

and time zone information. This information can be useful when building a timeline of events or

correlating events among different systems. Analysts should be aware that the time presented by

the OS might differ from that presented by the BIOS because of OS-specific settings, such as

time zone.

5.2 Collecting OS Data

As described in Section 5.1, OS data exists in both non-volatile and volatile states. Non-volatile OS data

such as filesystem data can be collected using the approaches discussed in Section 4 for performing

logical backups and bit stream imaging. Volatile OS data should be collected before the computer is

powered down. Sections 5.2.1 and 5.2.2 provide recommendations for collecting volatile and non-volatile

OS data, respectively. Section 5.2.3 discusses technical issues that can impede the collection of data.

 65 Impersonation can allow a regular system user to have higher system privileges to accomplish certain tasks. For example, a

particular program might require administrator access to run. Through impersonation, a regular user can be given those

permissions to run the application and then be reverted back to the usual privileges. 

5-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

5.2.1 Collecting Volatile OS Data

Volatile OS data involving an event can be collected only from a live system that has not been rebooted

or shut down since the event occurred. Every action performed on the system, whether initiated by a

person or by the OS itself, will almost certainly alter the volatile OS data in some way. Therefore,

analysts should decide as quickly as possible whether the volatile OS data should be preserved. Ideally,

the criteria for making this decision should have been documented in advance so that the analyst can

make the best decision immediately. The importance of this decision cannot be stressed enough, because

powering off the system or even disconnecting it from a network can eliminate the opportunity to collect

potentially important information. For example, if a user recently ran encryption tools to secure data, the

computerís RAM might contain password hashes, which could be used to determine the passwords. 

On the other hand, collecting volatile OS data from a running computer has inherent risks. For instance,

the possibility always exists that files on the computer might change and other volatile OS data might be

altered. In addition, a malicious party might have installed rootkits designed to return false information,

delete files, or perform other malicious acts. In deciding whether to collect volatile data, the risks 

associated with such collection should be weighed against the potential for recovering important 

information. As noted in Section 3.2, if evidence may be needed, the analyst should fully document what

is seen on the screen before touching the system. If a live system is in sleep mode or has visible password

protection, analysts should also decide whether to alter the state of the system by waking it from sleep

mode or attempting to crack or bypass the password protection so that analysts can attempt to collect

volatile data. If the effort needed to collect the volatile data is not merited, analysts might instead decide

to perform a shutdown, as described in Section 5.2.2.

Section 5.2.1.1 describes how forensic tools should be compiled in preparation for collecting volatile OS

data. Next, Section 5.2.1.2 discusses several types of data and mentions categories of tools or specific OS

tools that are effective in collecting each type of data. Finally, Section 5.2.1.3 explains the need to

identify the types of volatile OS data that are most likely to be valuable in a particular situation and then

to prioritize the collection of data based on importance and relative volatility.

5.2.1.1 Forensic Tool Preparation

When collecting volatile OS data, all forensic tools that might be needed should be placed on a floppy

disk, CD-ROM, or USB flash drive, from which the tools should be executed. Doing so enables analysts

to collect OS data with the least amount of disturbance to the system. In addition, only forensic tools 

should be used, since a user might have replaced system commands with malicious programs, such as one

to format a hard disk or return false information. However, use of forensic tools is no guarantee that the

data retrieved will be accurate. If a system has been fully compromised, it is possible that rootkits and 

other malicious utilities have been installed that alter the systemís functionality at the kernel level. This

can cause false data to be returned to user-level tools.

When creating a collection of forensic tools, statically linked binary files should be used. Such an

executable file contains all of the functions and library functions that it references, so separate dynamic

link libraries (DLL) and other supporting files are not needed. This eliminates the need to place the

appropriate versions of DLLs on the tool media and increases the reliability of the tools. The analyst

should know how each tool affects or alters the system before collecting the volatile data. The message

digest of each tool should be computed and stored safely to verify file integrity. Licensing and version 

information also should be documented for each forensic tool. In addition, the exact commands that were

used to run each forensic tool should be documented (i.e., command line arguments and switches). It may 

be helpful to place a script on the tool media that can be run to capture which commands were run, at

what time, and with what output. 

5-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

The media containing the tools should protect them from changes. Floppy disks should be writeprotected to ensure that no changes are made to the tools. CD-ROMs should be write-once CDs (i.e., CDR), not rewritable CDs, since the contents of a rewritable CD could be altered by CD-burning utilities on

the userís computer. After the tools have been burned to a write-once CD, the disc should be finalized to

ensure that no additional data can be written to it.

66 

Because the media containing the tools should be write-protected, the results produced by the tools cannot 

be placed onto the tool media. Analysts often direct tool output to a floppy disk, but the prevalence of

floppy disk drives on computing devices is decreasing. As a result, alternative methods of collecting

output have been developed. Specially prepared CDs and USB flash drives containing a Windows or

Linux-based environment can be used to gather output without changing the state of the system and 

typically direct the output to another USB flash drive, external hard drive, or other writable media, or to a

remote system.

5.2.1.2 Types of Volatile OS Data

The following list shows several types of volatile OS data and explains how forensic tools can be used in

collecting each type of data:

67

! Contents of Memory. There are several utilities that can copy the contents of RAM to a data file

and assist in subsequent analysis of the data. On most systems, it is not possible to avoid

alteration of RAM when running a utility that attempts to make a copy of RAM. Instead, the goal

is to perform the copying with as small a footprint as possible to minimize the disruption of

RAM. 

! Network Configuration. Most OSs include a utility that displays the current network 

configuration, such as ifconfig on UNIX systems and ipconfig on Windows systems. 

Information that can be provided through network configuration utilities includes the hostname,

the physical and logical network interfaces, and configuration information for each interface (e.g.,

IP address, Media Access Control [MAC] address, current status).

! Network Connections. OSs typically provide a method for displaying a list of the current

network connections. Both Windows and UNIX-based systems usually include the netstat

program, which lists network connections by source and destination IP addresses and ports, and

also lists which ports are open on each interface.

68 Third-party utilities are available that can 

display port assignments for each program. Most OSs also can display a list of remotely mounted

filesystems, which provides more detailed information than a network connection list. Section

6.2.7 provides additional information about gathering network connection information.

69

 66 Finalizing a CD is a typical feature of CD-burning utilities. Some CD-burning utilities also allow the current session to be

closed. However, closing a session simply indicates to the CD-burning utility that no additional data will be written to the

disc in the current session; it does not prevent additional data from being written to the disc in a different session (often

referred to as a multisession disc). Therefore, analysts should finalize the disc, not close the session, when creating a toolkit

CD. 67 Many resources are available that list the hundreds of tools available for analysts. Appendix F lists several Web sites that

contain more information on computer forensic tools. For tools that are included with OSs, analysts should use copies of the

tools that are on read-only media, not tools on the OS of a system of interest. 68 Another way of identifying the open ports is by running port scanning software from another system. Port scanning

software sends network traffic to various ports and analyzes the responses, as well as missing responses, to determine which 

ports are open. However, port scanning might produce inaccurate results due to security controls, such as host-based

firewalls that block the scans; also, the scans could change the state of the system. Accordingly, port scans are best suited

for informal data acquisition and for information collection when access to the OS is not available. 69 More information on fport is available at

http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/proddesc/fport.htm. 

5-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Running Processes. All UNIX-based systems offer the ps command for displaying currently

running processes. Although Windows offers a graphical user interface (GUI)ñbased process list 

utility, the Task Manager, it is usually preferable to have a text-based listing. Third-party utilities 

can be used to generate a text list of running processes for Windows systems.

! Open Files. All UNIX-based systems offer the lsof command for displaying a list of open files. 

Third-party utilities can be used to generate text lists of open files for Windows systems.

! Login Sessions. Some OSs have built-in commands for listing the currently logged on users,

such as the w command for UNIX systems, which also lists the source address of each user and

when the user logged onto the system. Third-party utilities are available that can list currently

connected users on Windows systems.

! Operating System Time. There are several utilities available for retrieving the current system

time, time zone information, and daylight savings time settings. On UNIX systems, the date

command can be used to retrieve this information. On Windows systems, the date, time, and 

nlsinfo commands can be used collectively to retrieve this information.

In addition to the tools in the preceding list, it is often useful to include some general-purpose tools in the

forensic toolkit, such as the following:

! OS Command Prompt. This utility provides an OS command prompt through which the other

tools in the toolkit can be executed, such as cmd on Windows systems.

! SHA-1 Checksum. A utility that can compute the SHA-1 message digest of data files is helpful

in file verification. It may also be useful to include in the toolkit a list of SHA-1 message digests 

for system data files associated with the target OS to assist in file verification. Utilities are

available for various OSs for this purpose.

70

! Directory List. A utility for listing the contents of directories should be included for navigating 

a filesystem and seeing its contents. Practically all OSs include such a utility; for example, the ls

command is used on UNIX systems, whereas on Windows systems, the dir command is used.

! String Search. A utility for performing a text string search can be useful in identifying data files

of interest. UNIX systems offer the grep command for performing text string searches, and a

third-party grep utility is also available on Windows systems.71

! Text Editor. A simple text editor can be useful for viewing text files or composing notes. 

Numerous text editors are available, such as Notepad on Windows systems and vi on UNIX

systems.

5.2.1.3 Prioritizing Data Collection

The types of volatile data that should be collected with the toolkit depend on the specific need. For

instance, if a network intrusion is suspected, it might be useful to collect network configuration

information, network connections, login sessions, and running processes to determine how someone

gained access to a system. If an investigation concerns identity theft, then the contents of RAM, the list 

of running processes, the list of open files, network configuration information, and network connections

might reveal social security and credit card numbers, programs used to obtain or encrypt data, password 

hashes, and methods that might have been used to obtain the information over a network. When in doubt,

it is usually a good idea to collect as much volatile data as possible because all opportunities to collect

 70 See http://lists.thedatalist.com/pages/Checksum_Tools.htm for more information on checksum utilities. 71 One Windows version of grep is available at http://unxutils.sourceforge.net/. 

5-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

such data will be lost once the computer is powered down. Later, a determination can be made as to

which collected volatile data should be examined. An automated script on a toolkit CD can be used for

consistency in collecting volatile data. The script can include ways to transfer the collected information

to local storage media, such as a thumb drive, and to networked drive locations.

Because volatile data has a propensity to change over time, the order and timeliness with which volatile

data is collected is important. In most cases, analysts should first collect information on network

connections and login sessions, because network connections may time out or be disconnected and the list

of users connected to a system at any single time may vary. Volatile data that is less likely to change,

such as network configuration information, should be collected later. The recommended order in which 

volatile data generally should be collected, from first to last, is as follows:

1. Network connections

2. Login sessions 

3. Contents of memory

4. Running processes

5. Open files 

6. Network configuration 

7. Operating system time.

5.2.2

 

Collecting Non-Volatile OS Data

After obtaining volatile OS data, analysts often should collect non-volatile OS data. To do so, the analyst 

first should decide whether the system should be shut down. Shutting down the system not only affects 

the ability to perform bit stream imaging and many logical backups, but can also change which OS data is

preserved. Most systems can be shut down through two methods:

! Perform a Graceful OS Shutdown. Nearly every OS offers a shutdown option.72 This causes

the OS to perform cleanup activities, such as closing open files, deleting temporary files, and

possibly clearing the swap file, before shutting down the system. A graceful shutdown can also

trigger removal of malicious material; for example, memory-resident rootkits may disappear, and 

Trojan horses may remove evidence of their malicious activity. The OS is typically shut down

from the account of the administrator or the current user of the system (if the current user has 

sufficient privileges).

! Remove Power from the System. Disconnecting the power cord from the back of the computer

(and removing the batteries on a laptop or other portable device) can preserve swap files,

temporary data files, and other information that might be altered or deleted during a graceful

shutdown.

73 Unfortunately, a sudden loss of power can cause some OSs to corrupt data, such as

72 For example, on Windows systems, analysts could use the Shut Down feature on the Start menu. 73 Disconnecting a power cord from the electrical wall outlet is not recommended because the computerís power cord may be 

plugged into an uninterruptible power supply (UPS) unit.

5-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

open files. In addition, for some consumer devices, such as PDAs and cell phones, removing

battery power can cause a loss of data.

74

Some tools are able to perform collection actions on running systems without any problems, while other

tools are best run on systems that have been shut down. In the latter case, analysts should be aware of the

characteristics of each OS and choose a shutdown method based on the typical behavior of the OS and the

types of data that need to be preserved.

75 For example, DOS and Windows 95/98 systems generally do

not corrupt data when power is removed suddenly, so removing power should preserve data. Other OSs

might corrupt data, such as open files or files that were being accessed at the time, if there is a loss of

power. In these cases, a graceful shutdown is generally best unless swap files or temporary data files are

of particular interest or the system might contain rootkits, Trojan horses, or other malicious programs that

might be triggered by a graceful shutdown. After performing a shutdown (if needed), the analyst should

acquire filesystem data from the systemís storage media using the methods discussed in Section 4.

After the computer has been powered off, all components, storage devices, media, and peripheral devices 

connected to the computer should be inventoried and labeled if they are needed as evidence. Whenever

possible, the inventory should include the model number, serial number, and description of the item. In

addition, information about how each item is connected to the outside or inside of the computer (e.g.,

cable connections, jumper settings) should be documented and photographed. This will help the analyst 

to recreate the userís computer setup. Assuming that the evidence can be legally seized, each item should

be handled using antistatic bracelets, guarded against electrostatic discharges that can damage the item,

sealed properly (i.e., a box that is taped shut), and packed securely for transport. Handlers should wear 

antistatic bracelets when handling sensitive media and protect media with antistatic bags and other special 

packing materials.

Once the filesystem data has been collected, tools can be used to acquire specific types of data from the

filesystem. Acquiring regular files, such as data, application, and configuration files, is relatively

straightforward and is described in more detail in Section 4. The following list describes several other

types of non-volatile OS data and explains how tools can be useful in acquiring each type from the

filesystem:

76

! Users and Groups. Operating systems maintain a list of users and groups that have access to the

system. On UNIX systems, users and groups are listed in /etc/passwd and /etc/groups, 

respectively. In addition, the groups and users commands can be used to identify users who

have logged onto the system and the groups to which they belong. On Windows systems, the net

user and net group commands can be used to enumerate the users and groups on a system.

! Passwords. Most OSs maintain password hashes for usersí passwords on disk. On Windows 

systems, third-party utilities can be used to dump password hashes from the Security Account

Manager (SAM) database. On UNIX systems, password hashes are usually in the /etc/passwd or

/etc/shadow file. As described in Section 4.3.2, password cracking programs can be used to

extract passwords from their hashes.

 74 Power for such devices often must be maintained on an ongoing basis. If a device does not have regular power, typically its

memory will be sustained by battery power only for the short term (weeks at most, minutes at worst), even if the device is

powered off. For long-term storage of consumer devices that contain important data, power should be maintained to

preserve the devicesí memory. 75 In most cases, analysts can determine which type of OS is in use by looking at the screen. For example, Windows systems

use taskbars and other graphic elements that do not appear on other OSs. 76 Some of the tools described in this section can also be used to collect data from a live system. 

5-9
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Network Shares. A system may enable local resources to be shared across a network. On

Windows systems, the SrvCheck utility can be used to list network shares.

77 Third-party utilities

can provide similar information for other OSs.

! Logs. Logs that are not stored in text files might necessitate use of log extraction utilities. For

example, specialized utilities can retrieve information about recent successful and failed logon

attempts on Windows systems, which are stored in binary format logs. Most log entries on Unix

systems are stored in text files by syslog or in the /var/log directory, so special utilities are not

needed to acquire information from the logs.

78 Searching for filenames ending in .log should

identify most log files.

Occasionally, analysts may need to collect data from the BIOS, such as system date and time or processor

type and speed.

79 Because the BIOS primarily contains information related to the systemís hardware

configuration, BIOS data collection is most likely to be needed when a system administrator is

troubleshooting operational issues. Typically, analysts who need BIOS data first collect any needed

volatile data and filesystems, then reboot the system and press the appropriate function key (generally

specified in the initial screen during boot) to display the BIOS settings. If the BIOS password is set, the

analyst might not be able to gain access to the BIOS settings easily and might have to attempt to guess 

default passwords or circumvent the password protection. A variety of methods can be used to bypass 

BIOS passwords, including finding the appropriate manufacturer backdoor password, using a password

cracker, moving the appropriate jumper on the motherboard, or removing the Complementary Metal

Oxide Semiconductor (CMOS) battery (if possible). Systems vary, so analysts should first research the

particular characteristics of the system they are analyzing, as described in motherboard documentation, to

avoid harming a system unnecessarily.

80

5.2.3

 

Technical Issues with Collecting Data

Technical issues might also impede collection of OS data. Section 4 describes several filesystem-related

issues; this section focuses on additional collection issues and provides guidance on what, if anything, can 

be done to mitigate them. The intent of this section is not to provide an exhaustive discussion of all

possible issues, but to provide some basic information on common ones.

! OS Access. Collecting volatile data can be difficult because the analyst might not be able to

readily gain access to the OS. For instance, a user might run a password-protected screen saver

or have the system locked. In these cases, the analyst will need to circumvent this protection or

find another way to gain access to volatile OS data.

81 If a password-protected screen saver is

active, restarting the system might allow the analyst to bypass the screen saver, but would also

cause all volatile OS data to be lost. If a host uses biometric-based authentication, such as a

fingerprint reader, or another add-on authentication service, this could cause similar issues in

accessing volatile OS data. There are third-party utilities for some OSs that claim to crack screen

77 SrvCheck is available from the Windows Server 2003 Resource Kit. 78 More information on the syslog protocol is available in RFC 3164, The BSD Syslog Protocol, available at

http://www.ietf.org/rfc/rfc3164.txt. 79 Hard drive information presented in the BIOS might be inaccurate for larger hard drives. Many drives now use Logical 

Block Addressing, which causes the BIOS to display incorrect drive geometry information. Analysts should be able to

acquire the correct information by examining the physical label on the hard drive itself. 80 More information about bypassing BIOS passwords is available at http://www.freelabs.com/~whitis/security/backdoor.html

and http://labmice.techtarget.com/articles/BIOS_hack.htm. 81 Several Web sites indicate ways to circumvent specific screen savers, such as taking advantage of known OS vulnerabilities.

However, the screen saver bypass methods are of little use if the OS is unknown or the user has eliminated the

vulnerabilities. General information regarding passwords is available from the Microsoft Knowledge Base article

ìInformation About Unlocking a Workstationî (http://support.microsoft.com/kb/q281250/) and the article titled ìPassword

Information in Windows XPî (http://www.kellys-korner-xp.com/win_xp_passwords.htm). 

5-10
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

saver passwords without rebooting the system. These utilities generally rely on the CD driveís

autorun feature; the utility automatically runs in the background, then locates the encrypted

password and attempts to decrypt it. 

! Log Modification. The user might try to reduce the usefulness of logs by disabling log features,

modifying log settings so that there is little storage available for logs, or writing many spurious 

events to the logs. One way of reducing the impact of logging changes is to configure systems to

archive their log entries on a centralized server.

! Hard Drives with Flash Memory. Occasionally, an analyst might come across a hard drive that

also contains flash memory. This flash memory could contain a password that is needed to access

the drive, even when the drive has been removed from the computer. Typically, the analyst must

then find, guess, or crack the password to gain access to the drive.

! Key Remapping. On some computers, individual keys or combinations of keystrokes can be

remapped to perform a different function from their initial purpose. For example, a person could

map the Ctrl, Alt, and Del keys so that they wipe the computerís hard drive instead of the 

expected action, rebooting the system. An analyst who uses the keyboard of a computer of

interest could enter keystrokes that cause unexpected actions to be performed. The best way to

avoid key remapping problems is by collecting data from the computer without using its

keyboard. For example, the analyst could attach a forensic workstation to a computer of interest

using a crossover network cable and run scripts from the forensic workstation.

5.3 Examining and Analyzing OS Data

Various tools and techniques can be used to support the examination process. Many of the tools and

techniques discussed in Section 4.3 for examining collected data files can also be used with collected OS

data. In addition, as described in Section 7, security applications, such as file integrity checkers and host

IDSs, can be very helpful in identifying malicious activity against OSs. For instance, file integrity

checkers can be used to compute the message digests of OS files and compare them against databases of

known message digests to determine whether any files have been compromised. If intrusion detection

software is installed on the computer, it might contain logs that indicate the actions performed against the

OS.

Another issue that analysts face is the examination of swap files and RAM dumps, which are large binary

data files containing unstructured data. Hex editors can be used to open these files and examine their

contents; however, on large files, manually trying to locate intelligible data using a hex editor can be a

time-consuming process. Filtering tools automate the process of examining swap and RAM dump files

by identifying text patterns and numerical values that might represent phone numbers, names of people, email addresses, Web addresses, and other types of critical information.

Analysts often want to gather additional information about a particular program running on a system, such

as the processís purpose and manufacturer. After obtaining a list of the processes currently running on a

system, analysts can look up the process name to obtain such additional information. However, users 

might change the names of programs to conceal their functions, such as naming a Trojan program

calculator.exe. Therefore, process name lookups should be performed only after verifying the identity of

the processís files by computing and comparing their message digests. Similar lookups can be performed

on library files, such as DLLs on Windows systems, to determine which libraries are loaded and what

their typical purposes are.

As described in Section 5.2, analysts may collect many different types of OS data, including multiple

filesystems. Trying to sift through each type of data to find relevant information can be a time-intensive

5-11
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

process. Analysts generally find it useful to identify a few data sources to review initially, then find other

likely sources of important information on the basis of that review. In addition, in many cases, analysis

can involve data from other types of sources, such as network traffic or applications. Section 8 provides

examples of how data from OSs and other sources can be correlated through analysis.

5.4 Recommendations

The key recommendations presented in this section for using data from OSs are as follows.

! Analysts should act appropriately to preserve volatile OS data. The criteria for determining

whether volatile OS data must be preserved should be documented in advance so that analysts can

make informed decisions as quickly as possible. To determine whether the effort required to

collect volatile OS data is warranted, the risks associated with such collection should be weighed

against the potential for recovering important information.

! Analysts should use a forensic toolkit for collecting volatile OS data. Use of a forensic toolkit 

enables accurate OS data to be collected while minimizing the disturbance to the system and

protecting the tools from changes. The analyst should know how each tool is likely to affect or

alter the system during collection of data.

! Analysts should choose the appropriate shutdown method for each system. Each method of

shutting down a particular OS can cause different types of data to be preserved or corrupted; 

analysts should be aware of the typical shutdown behavior of each OS.

5-12
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

6. Using Data From Network Traffic

Analysts can use data from network traffic to reconstruct and analyze network-based attacks and 

inappropriate network usage, as well as to troubleshoot various types of operational problems. The

content of communications carried over networks, such as e-mail messages or audio, might also be

collected in support of an investigation. The term network traffic refers to computer network

communications that are carried over wired or wireless networks between hosts.

82 This section provides

an introduction to network traffic, including descriptions of major sources of network traffic data (e.g.,

intrusion detection software, firewalls). In addition, it discusses techniques for collecting data from these

sources and points out the potential legal and technical issues in such data collection. The remainder of

the section focuses on the techniques and tools for examining and analyzing data from network traffic. 

The section begins with an overview of Transmission Control Protocol/Internet Protocol (TCP/IP)óa

basic knowledge of TCP/IP is necessary to understand the data, tools, and methodologies presented in this

section.

6.1 TCP/IP Basics

TCP/IP is widely used throughout the world to provide network communications. TCP/IP

communications are composed of four layers that work together. When a user wants to transfer data

across networks, the data is passed from the highest layer through intermediate layers to the lowest layer,

with each layer adding additional information. The lowest layer sends the accumulated data through the

physical network; the data is then passed up through the layers to its destination. Essentially, the data

produced by a layer is encapsulated in a larger container by the layer below it. The four TCP/IP layers,

from highest to lowest, are shown in Figure 6-1.

Application Layer. This layer sends and receives data for particular

applications, such as Domain Name System (DNS), Hypertext Transfer

Protocol (HTTP), and Simple Mail Transfer Protocol (SMTP).

Transport Layer. This layer provides connection-oriented or connectionless 

services for transporting application layer services between networks. The

transport layer can optionally ensure the reliability of communications.

Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are 

commonly used transport layer protocols.

Internet Protocol Layer (also known as Network Layer). This layer routes

packets across networks. IP is the fundamental network layer protocol for

TCP/IP. Other commonly used protocols at the network layer are Internet

Control Message Protocol (ICMP) and Internet Group Management Protocol

(IGMP). 

Hardware Layer (also known as Data Link Layer). This layer handles 

communications on the physical network components. The best known data

link layer protocol is Ethernet.

Figure 6-1. TCP/IP Layers

The four TCP/IP layers work together to transfer data between hosts. As shown in Figure 6-2, each layer

encapsulates the previous layers. Sections 6.1.1 through 6.1.4 describe these layers in greater detail and

 82 Because nearly all network traffic of interest to organizations uses the TCP/IP protocol suite, this section addresses only

TCP/IP-based communications. However, most of the principles discussed in this section can be applied to other types of

network traffic as well.

6-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

indicate the characteristics that are most pertinent to network forensics. Section 6.1.5 explains how the

layers relate to each other. 

Figure 6-2. TCP/IP Encapsulation 

6.1.1

6.1.2

 

Application Layer

The application layer enables applications to transfer data between an application server and client. An

example of an application layer protocol is Hypertext Transfer Protocol (HTTP), which transfers data

between a Web server and a Web browser. Other common application layer protocols include Domain

Name System (DNS), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Simple

Network Management Protocol (SNMP). There are hundreds of unique application layer protocols in

common use, and many more that are not so common.

83 Regardless of the protocol in use, application

data is generated and then passed to the transport layer for further processing. Section 7 focuses on

application-related data collection, examination, and analysis. 

Transport Layer

The transport layer is responsible for packaging data so that it can be transmitted between hosts. After the

transport layer has encapsulated application data, the resulting logical units are referred to as packets. (A

packet can also be created without application dataófor example, when a connection is first negotiated.) 

Each packet contains a header, which is composed of various fields that specify characteristics of the

transport protocol in use; optionally, packets may also contain a payload, which holds the application

data.

Most applications that communicate over networks rely on the transport layer to ensure reliable delivery

of data. Generally, this is accomplished by using the TCP transport layer protocol, which establishes a

connection between two hosts and then makes a best effort to ensure the reliable transfer of data over that

connection. Each TCP packet includes a source port and a destination port. One of the ports is associated

with a server application on one system; the other port is associated with a corresponding client

application on the other system. Client systems typically select any available port number for application

use, whereas server systems normally have a static port number dedicated to each application. Although

many server ports are usually used by particular applications (e.g., FTP servers at port 21, HTTP servers 

83 For this reason, a detailed discussion of individual application layer protocols is beyond the scope of this document.

6-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

at port 80), many server applications can be run from any port number, so it is unwise to assume that

network traffic contains data from a certain application solely on the basis of server port number.

When loss of some application data is not a concern (e.g., streaming audio, video), the User Datagram

Protocol (UDP) is typically used. UDP involves less overhead and latency than TCP because UDP is

connectionless; one host simply sends data to another host without any preliminary negotiations. UDP is

also used for applications that are willing to take responsibility for ensuring reliable delivery of data, such

as DNS, and applications that are intended for use only on local area networks, such as Dynamic Host

Configuration Protocol (DHCP) and SNMP. As is the case with TCP, each UDP packet contains a source

port and a destination port. Although UDP and TCP ports are very similar, they are distinct from each

other and are not interchangeable. Some applications (such as DNS) can use both TCP and UDP ports;

although such applications typically use the same number for the TCP port and the UDP port, this is not 

required. 

6.1.3

 

IP Layer

The IP layer can also be called the network layer, because it is responsible for handling the addressing

and routing of data that it receives from the transport layer. The IP header contains a field called IP

Version, which indicates which version of IP is in use. Typically this is set to 4 for IPv4; but the use of

IPv6 is increasing, so this field may be set to 6 instead.

84 Other significant IP header fields are as follows:

! Source and Destination IP Addresses. These are the ìfromî and ìtoî addresses that are 

intended to indicate the endpoints of the communication.

85 Examples of IP addresses are 

10.3.1.70 (IPv4) and 1000:0:0:2F:8A:400:0427:9BD1 (IPv6).

! IP Protocol Number. This indicates which transport layer protocol the IP payload contains.

86 

Commonly used IP numbers include 1 (Internet Control Message Protocol [ICMP]), 6 (TCP), 17 

(UDP), and 50 (Encapsulating Security Payload [ESP]).

The IP layer is also responsible for providing error and status information involving the addressing and

routing of data; it does this with ICMP. ICMP is a connectionless protocol that makes no attempt to

guarantee that its error and status messages are delivered. Because it is designed to transfer limited

information, not application data, ICMP does not have ports; instead, it has message types, which indicate

the purpose of each ICMP message.

87 Some message types also have message codes, which can be

thought of as subtypes. For example, the ICMP message type Destination Unreachable has several

possible message codes that indicate what is unreachable (e.g., network, host, protocol). Most ICMP

messages are not intended to elicit a response.

88

IP addresses are often used through a layer of indirection. When people need to access a resource on a

network, such as a Web server or e-mail server, they typically enter the serverís name, such as

www.nist.gov, rather than the serverís IP address. The name, also known as a domain name, is mapped

84 There are other possible IP version numbers as well, although none are commonly used. The official list of valid IP Version

field values is available at http://www.iana.org/assignments/version-numbers. This document assumes the use of IPv4, but

the techniques described can easily be adapted for use with IPv6 (assuming that comparable tools are available that support

IPv6). 85 IP addresses are often inaccurate or misleading for identifying the actual endpoints of communication. Section 6.3 discusses

this topic in more detail. 86 The official list of valid IP Protocol Number values is available at http://www.iana.org/assignments/protocol-numbers. 87 The current list of valid ICMP types is available at http://www.iana.org/assignments/icmp-parameters. 88 ICMP is designed to limit responses, particularly to error messages. If ICMP had not been designed in this way, message

loops could occur. For example, if Host A received an ICMP error message from Host B and responded with an error

message, and Host B responded to that error message with an error message, the two hosts could continue sending error

messages regarding the error messages. 

6-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

to the IP address through the DNS application layer protocol. The primary reason for entering a domain

name instead of an IP address is that the former is generally easier for people to remember. In addition,

where a domain name is likely to remain the same, a hostís IP address can change over time; by

referencing a host by domain name, which is then mapped to the hostís IP address, users can reach the

host no matter what IP address the host is currently using.

6.1.4

6.1.5

 

Hardware Layer

As the name implies, the hardware layer involves the physical components of the network, including

cables, routers, switches, and NIC. The hardware layer also includes various hardware layer protocols;

Ethernet is the most widely used of these protocols. Ethernet relies on the concept of a MAC address,

which is a unique 6-byte value (such as 00-02-B4-DA-92-2C) that is permanently assigned to a particular

NIC.

89 Each frame contains two MAC addresses, which indicate the MAC address of the NIC that just

routed the frame and the MAC address of the next NIC to which the frame is being sent. As a frame 

passes through networking equipment (such as routers and firewalls) on its way between the original

source host and the final destination host, the MAC addresses are updated to refer to the local source and

destination. Several separate hardware layer transmissions may be linked together within a single IP layer

transmission.

In addition to the MAC addresses, each frame also contains an EtherType value, which indicates the

protocol that the frameís payload contains (typically IP or Address Resolution Protocol [ARP]).

90 When

IP is used, each IP address maps to a particular MAC address. (Because multiple IP addresses can map to

a single MAC address, a MAC address does not necessarily uniquely identify an IP address.)

Layersí Significance in Network Forensics

Each of the four layers of the TCP/IP protocol suite contains important information. The hardware layer

provides information about physical components, while other layers describe logical aspects. For events

within a network, an analyst can map an IP address (logical identifier at the IP layer) to the MAC address 

of a particular NIC (physical identifier at the physical layer), thereby identifying a host of interest. The

combination of the IP protocol number (IP layer field) and port numbers (transport layer fields) can tell an

analyst which application was most likely being used or targeted. This can be verified by examining the

application layer data.

Network forensic analysis relies on all of the layers. When analysts begin to examine data, they typically

have limited informationómost likely an IP address of interest and perhaps protocol and port

information. Nevertheless, this is enough information to support searching common data sources for

more information. In most cases, the application layer contains the actual activity of interestómost 

attacks are against vulnerabilities in applications (including services), and nearly all misuse involves

misuse of applications. Analysts need IP addresses so that they can identify the hosts that may have been

involved in the activity. The hosts may also contain additional data that would be of use in analyzing the

activity. Although some events of interest may not have relevant application-level data (e.g., a distributed

denial of service attack designed to consume all network bandwidth), most do; network forensics provides

important support to the analysis of application-layer activities.

89 The first 3 bytes of each MAC address indicate the vendor of the NIC; a list of mappings is available at

http://standards.ieee.org/regauth/oui/oui.txt. However, various software utilities are publicly available that allow people to

configure systems to spoof other MAC addresses. There have also been cases in which manufacturers accidentally created

NICs with duplicate MAC addresses. 90 EtherType value 0x0800 is IP, while 0x0806 is ARP. See http://www.iana.org/assignments/ethernet-numbers for more

information on EtherType values.

6-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

6.2 Network Traffic Data Sources

Organizations typically have several types of information sources concerning network traffic that might 

be useful for network forensics. These sources collectively capture important data from all four TCP/IP

layers. The following subsections highlight the major categories of network traffic data sourcesó

firewalls and routers, packet sniffers and protocol analyzers, IDSs, remote access, security event

management software, and network forensic analysis toolsóas well as several other types of data sources. 

The subsections explain the purpose of each source described and the type of data that is typically

collected and can potentially be collected.

6.2.1

6.2.2

 

Firewalls and Routers

Network-based devices such as firewalls and routers, and host-based devices such as personal firewalls,

examine network traffic and permit or deny it based on a set of rules. Firewalls and routers are usually

configured to log basic information for most or all denied connection attempts and connectionless 

packets; some log every packet.

91 Information logged typically includes the date and time the packet was 

processed, the source and destination IP addresses, the transport layer protocol (e.g., TCP, UDP, ICMP),

and basic protocol information (e.g., TCP or UDP port numbers, ICMP type and code). The content of

packets is usually not recorded.

Network-based firewalls and routers that perform network address translation (NAT) may contain 

additional valuable data regarding network traffic. NAT is the process of mapping addresses on one

network to addresses on another network; this is most often accomplished by mapping private addresses

92

from an internal network to one or more public addresses on a network that is connected to the Internet. 

NAT differentiates multiple internal addresses that are mapped to a single external address by assigning a 

different source port number to the external address for each internal address. The NAT device typically

records each NAT address and port mapping.

Some firewalls also act as proxies. A proxy receives a request from a client, and then sends a request on

the clientís behalf to the desired destination. When a proxy is used, each successful connection attempt 

actually results in the creation of two separate connections: one between the client and the proxy server,

and another between the proxy server and the true destination. Proxy servers may log basic information 

about each connection. Many proxies are application-specific, and some actually perform some analysis

and validation of application protocols, such as HTTP. The proxy may reject client requests that appear

to be invalid and log information regarding these requests.93

In addition to providing NAT and proxying services, firewalls and routers may perform such other

functions as intrusion detection and VPN. The intrusion detection and VPN functions are discussed in

more detail in Sections 6.2.3 and 6.2.4, respectively.

Packet Sniffers and Protocol Analyzers

Packet sniffers are designed to monitor network traffic on wired or wireless networks and capture packets.

Normally, a NIC accepts only the incoming packets that are specifically intended for it. But when a NIC 

91 Although logging all packets records more information about recent network activity than does logging information for

connections and connection attempts, space limitations might permit packets to be kept for a short time only. In addition, 

the overhead required to record all packets might cause the systemís performance to degrade. 92 The proper name for private addresses is RFC 1918 addresses. RFC 1918, Address Allocation for Private Internets, is

available at http://www.ietf.org/rfc/rfc1918.txt. 93 Some organizations configure their networks and network security so that all network traffic passing through the network

perimeter for common applications is proxied, preventing individual users from bypassing the proxies. In such an

environment, the proxy server logs can be particularly valuable for network forensics.

6-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

is placed in promiscuous mode, it accepts all incoming packets that it sees, regardless of their intended 

destinations. Packet sniffers generally work by placing the NIC in promiscuous mode; the user then

configures the sniffer to capture all packets or only those with particular characteristics (e.g., certain TCP

ports, certain source or destination IP addresses). Packet sniffers are commonly used to capture a

particular type of traffic for troubleshooting or investigative purposes. For example, if IDS alerts indicate

unusual network activity between two hosts, a packet sniffer could record all of the packets traveling 

between the hosts, potentially providing additional information for analysts.

Most packet sniffers are also protocol analyzers, which means that they can reassemble streams from

individual packets and decode communications that use any of hundreds or thousands of different

protocols.

94 Protocol analyzers usually can process not only live network traffic but also packets that

have been recorded previously in capture files by packet sniffers. Protocol analyzers are extremely 

valuable in displaying raw packet data in an understandable format. Protocol analyzers are discussed in

more depth in Section 6.4 and Section 7.

6.2.3 

 

Intrusion Detection Systems 

Network IDSs perform packet sniffing and analyze network traffic to identify suspicious activity and

record relevant information.

95 Host IDSs monitor characteristics of a particular system and events

occurring within the system, which can include network traffic.

96 Unlike network IDS sensors, which can 

monitor all network traffic on a particular network segment, host IDS software is intended to monitor

network traffic only for the host on which it is installed.97 For each suspicious event, IDS software

typically records the same basic event characteristics that firewalls and routers record (e.g., date and time,

source and destination IP addresses, protocol, basic protocol characteristics), as well as applicationspecific information (e.g., username, filename, command, status code). IDS software also records

information that indicates the possible intent of the activity. Examples include the type of attack (e.g.,

buffer overflow), the targeted vulnerability, the apparent success or failure of the attack, and pointers to

more information about the attack.

98

Some IDSs can be configured to capture packets related to suspicious activity. This can range from

recording only the packet that triggered the IDS to label the activity suspicious, to recording the rest of

the session. Some IDSs even have the ability to store all sessions for a short period of time so that if

something suspicious is detected, the previous activity in the same session can be preserved. The packets 

94 Examples of open source packet sniffer and protocol analyzer software for wired networks include Ethereal

(http://www.ethereal.com/), TCPDump (http://www.tcpdump.org/), and WinDump (http://www.winpcap.org/windump/). 

Open source software is also available for wireless networks, including Ethereal and Kismet

(http://www.kismetwireless.net/). Additional packet sniffer and protocol analyzer software products are listed on various

Web sites, including the Talisker Security Wizardry Portal (http://www.networkintrusion.co.uk/protanalyzers.htm),

Softpedia (http://www.softpedia.com/get/Network-Tools/Protocol-Analyzers-Sniffers/), Packet Storm

(http://packetstormsecurity.org/defense/sniff/), and other Web sites listed in Appendix F. 95 Some network IDSs allow administrators to identify misuse as well as attacks. For example, an administrator (with proper

approval) could configure the IDS with character strings of interest, such as an acronym or phrase associated with a sensitive 

project. The IDS could then search network traffic for file transfers, e-mails, and other forms of communication that used 

one of those character strings. 96 Examples of open source network IDS products include Bro (http://www.bro-ids.org/) and Snort (http://www.snort.org/). 

For more information about network and host IDS products, see the Talisker Security Wizardry Portal

(http://www.networkintrusion.co.uk/ids.htm), Honeypots.net (http://www.honeypots.net/ids/products/), the Common

Vulnerabilities and Exposures Web site (http://www.cve.mitre.org/compatible/product.html), and other Web sites listed in

Appendix F. 97 See NIST SP 800-31, Intrusion Detection Systems, for more information on network and host IDS. It is available at

http://csrc.nist.gov/publications/nistpubs/index.html. 98 Many IDS vendors provide help files that contain detailed information about each type of activity. IDS vendors also

typically provide pointers to external sources of information, such as CERTÆ/CC advisories, Common Vulnerabilities and

Exposures (CVE) numbers, and software vendor vulnerability announcements.

6-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

are captured primarily so that intrusion detection analysts can review them when validating IDS alerts and 

investigating suspicious activity. Some IDSs also have intrusion prevention capabilities, which means 

that they actively attempt to stop attacks in progress. Any use of intrusion prevention features should be

indicated in the IDS logs.

6.2.4

6.2.5

 

Remote Access

Remote access servers are devices such as VPN gateways and modem servers that facilitate connections

between networks. This often involves external systems connecting to internal systems through the

remote access server but could also include internal systems connecting to external or internal systems. 

Remote access servers typically record the origin of each connection and might also indicate which user

account was authenticated for each session. If the remote access server assigns an IP address to the

remote user, this is also likely to be logged. Some remote access servers also provide packet filtering

functions, which typically perform logging similar to that provided by firewalls and routers, as described

in Section 6.2.1. Remote access servers typically work at a network level, supporting the use of many

different applications. Because the servers have no understanding of the applicationsí functions, they

usually do not record any application-specific data.

In addition to remote access servers, organizations typically use multiple applications that are specifically

designed to provide remote access to a particular hostís OS. Examples include secure shell (SSH), telnet,

terminal servers,99 and remote control software. Such applications can typically be configured to log

basic information for each connection, including source IP address and user account. Organizations also

typically use many applications that are accessed remotely, such as client/server applications. Some of

these applications also log basic information for connections.

Although most remote accessñrelated logging occurs on the remote access server or the application 

server, in some cases the client also logs information related to the connection.

Security Event Management Software 

Security event management (SEM)100 software is capable of importing security event information from

various network trafficñrelated security event data sources (e.g., IDS logs, firewall logs) and correlating 

events among the sources.101 It generally works by receiving copies of logs from various data sources

over secure channels, normalizing the logs into a standard format, then identifying related events by

matching IP addresses, timestamps, and other characteristics. SEM products usually do not generate

original event data; instead, they generate meta-events based on imported event data. Many SEM 

products not only can identify malicious activity, such as attacks and virus infections, but also can detect

misuse and inappropriate usage of systems and networks. SEM software can be helpful in making many

sources of network traffic information accessible through a single interface.

Because SEM products can handle nearly any security event data source, such as OS logs, antivirus

software alerts, and physical security device logs, SEM products may contain a wide variety of

information regarding events. However, it is typical for only some data fields to be brought over. For

example, if an IDS records packets, the packets may not be transferred to the SEM because of bandwidth

and storage limitations. In addition, because most data sources record information in different formats,

SEM products typically normalize the dataóconverting each data field to a standard format and labeling 

99 In this context, terminal server refers to products such as Microsoft Windows Terminal Services and Citrix Metaframe that

provide graphical remote access to operating systems and applications. 100 SEM software is listed on several Web sites listed in Appendix F, including the Common Vulnerabilities and Exposures

(CVE) Web site (http://www.cve.mitre.org/compatible/product.html). 101 Another common term for security event management is security information management (SIM). 

6-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

the data consistently. Although this is beneficial for analysis (as described in Section 6.4), the

normalization process occasionally introduces errors in the data or causes some data to be lost. 

Fortunately, SEM products typically do not alter the original data sources, so analysts should retain copies

of the original logs and use them to verify the accuracy of the data if needed.

6.2.6

6.2.7

 

Network Forensic Analysis Tools

Network forensic analysis tools (NFAT)

102 typically provide the same functionality as packet sniffers,

protocol analyzers, and SEM software in a single product. Whereas SEM software concentrates on

correlating events among existing data sources (which typically include multiple network trafficñrelated

sources), NFAT software focuses primarily on collecting, examining, and analyzing network traffic. 

NFAT software also offers additional features that further facilitate network forensics, such as the

following:

! Reconstructing events by replaying network traffic within the tool, ranging from an individual

session (e.g., instant messaging [IM] between two users) to all sessions during a particular time

period. The speed of the replaying can typically be adjusted as needed.

! Visualizing the traffic flows and the relationships among hosts. Some tools can even tie IP

addresses, domain names, or other data to physical locations and produce a geographic map of the

activity.

! Building profiles of typical activity and identifying significant deviations.

! Searching application content for keywords (e.g., ìconfidentialî, ìproprietaryî).

Other Sources

Most organizations have other sources of network traffic information that can be of use for forensics in

some capacity, including the following:

! Dynamic Host Configuration Protocol Servers. The DHCP service assigns IP addresses to

hosts on a network as needed. Some hosts might have static IP addresses, which means that they

always receive the same IP address assignment; however, most hosts typically receive dynamic

assignments. This means that the hosts are required to renew their IP address assignments 

regularly and that there is no guarantee that they will be assigned the same addresses. DHCP

servers may contain assignment logs that include the MAC address, the IP address assigned to

that MAC address, and the time the assignment occurred.

! Network Monitoring Software. Network monitoring software is designed to observe network 

traffic and gather statistics about it.

103 For example, it may record high-level information about

traffic flows for a particular network segment, such as the amount of bandwidth typically

consumed by various protocols. Network monitoring software may also collect more detailed 

information about network activity, such as the payload size and the source and destination IP

addresses and ports for each packet. Some managed switches and other network devices offer

basic network monitoring capabilities, such as collecting statistics concerning bandwidth usage.

102 Listings of NFAT software are available from Web sites listed in Appendix F, such as the Talisker Security Wizardry Portal

(http://www.networkintrusion.co.uk/fornettools.htm). 103 Open source network monitoring software includes EtherApe (http://etherape.sourceforge.net/) and IPaudit

(http://ipaudit.sourceforge.net/). Packet sniffers, protocol analyzers, and IDS software may also perform basic network 

monitoring functions. See the Web sites listed in Appendix F for additional product names.

6-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Internet Service Provider Records. ISPs may collect network traffic-related data as part of

their normal operations and when investigating unusual activity, such as extremely high volumes

of traffic or an apparent attack. Usual ISP records often might be kept only for days or hours. 

Section 6.3.1 discusses legal considerations involved in collecting network traffic data from ISPs

and other third parties.

! Client/Server Applications. Some client/server applications used over networks may record

information regarding successful and failed usage attempts, which could include connectionrelated data such as the clientís IP address and port. The data fields recorded (if any) vary widely

among applications.

! Hostsí Network Configurations and Connections. Sections 5.1.2 and 5.2.1 describe the types

of network information that can be collected from individual hosts, including the TCP and UDP

ports at which a host is listening. 

6.3 Collecting Network Traffic Data

As described in Section 6.2, organizations typically have network traffic data recorded in many places

during normal operations. Organizations also use the same data recording mechanisms to collect

additional data on an as-needed basis when investigating incidents or troubleshooting problems. For

example, a network administrator or incident handler might deploy a packet sniffer to examine unusual

packets sent by a host.

Network traffic data is usually recorded to a log or stored in a packet capture file. In most cases,

collecting the data is as simple as collecting the logs and packet capture files. Section 4 describes how to

collect files in an appropriate manner for evidentiary purposes. If data is not stored in a file (e.g., traffic

flow map displayed graphically, data displayed on the console screen only), screen captures or

photographs of the screen might be needed. Although collecting network traffic data is typically

straightforward, there are several important legal and technical issues that can make data collection more

complicated.

6.3.1 Legal Considerations

Collecting network traffic can pose legal issues. Among these issues is the capture (intentional or

incidental) of information with privacy or security implications, such as passwords or the contents of emails. This could expose the information to the staff members who are analyzing the collected data or

administering the recording systems (e.g., IDS sensors). Organizations should have policies in place

regarding the handling of inadvertent disclosures of sensitive information. Another problem with

capturing data such as e-mails and text documents is that long-term storage of such information might 

violate an organizationís data retention policy. It is also important to have policies regarding the

monitoring of networks and to have warning banners on systems that indicate that activity may be

monitored.

Although most network traffic data collection occurs as part of regular operations, it can also occur as part

of troubleshooting or incident handling. In the latter case, it is important to follow consistent processes 

and to document all actions performed. For example, recording all packets sent and received by a

particular user should be initiated only after the successful completion of a formal request and approval

process. Organizations should have policies that clearly explain what types of monitoring can and cannot

be performed without approval, and that describe or reference the procedures that detail the request and 

approval process.

6-9
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Another potential legal issue is the preservation of original logs. As described in Section 6.4, many

organizations send copies of network traffic logs to centralized devices, as well as use tools that interpret 

and analyze network traffic. In cases where logs may be needed as evidence, organizations may wish to

collect copies of the original log files, the centralized log files, and interpreted log data, in case there are

any questions regarding the fidelity of the copying and interpretation processes. Section 6.4 contains

more information on this.

As privacy has become a greater concern to organizations, many have become less willing to share

information with each other, including network forensic data. For example, most ISPs now require a

court order before providing any information related to suspicious network activity that might have

passed through their infrastructure. Although this preserves privacy and reduces the burden on and

liability of the ISPs, it also slows down the investigative process. This is particularly challenging when

an organization is attempting to trace an ongoing network-based attack to its source, especially if the

traffic passes through several ISPs.

6.3.2

 

Technical Issues

Several technical issues might impede the collection of data about network traffic. This section describes 

several of the major issues and provides guidance on what, if anything, can be done to mitigate each.

! Data Storage. When there is a large volume of network activity, particularly during adverse

events such as attacks, logs may record many events in a short time. If insufficient storage is

available, information about recent activity may be overwritten and lost. Organizations should 

estimate typical and peak log usage, determine how many hoursí or daysí worth of data should be

retained, and ensure that systems and applications have sufficient storage available to meet those

goals.104

! Encrypted Traffic. When protocols such as IP Security (IPsec), SSH, and Secure Sockets Layer

(SSL) are used to encrypt network traffic, devices monitoring network traffic along the encrypted 

path can see only the most basic characteristics of the traffic, such as source and destination IP

addresses. If VPNs or other tunneling techniques are being used, the IP addresses might be for

the tunnel itself and not the true source and destination of the activity. To collect data about the

decrypted traffic, a data source must be positioned where it can see the decrypted activity. For

example, placing an IDS sensor immediately behind a VPN gateway can be effective at

identifying anomalous activity in the decrypted communications. If communications are

encrypted all the way to the internal host (e.g., an SSL-encrypted Web session), then devices 

monitoring network traffic cannot see the decrypted packets. Organizations should consider

establishing policies that specify the appropriate use of traffic encryption technologies, so that

security controls such as IDS sensors can monitor the contents of traffic that does not need to be

or should not be encrypted.

! Services Running on Unexpected Ports. Applications such as IDSs and protocol analyzers 

often rely on port numbers to identify which service is in use for a given connection. 

Unfortunately, as described in Section 6.1.2, most services can be run on any port number. 

Because traffic involving services running on unexpected port numbers may not be captured,

monitored, or analyzed properly, use of unauthorized services (e.g., providing Web services on an

104 Organizations should also provide sufficient data storage to keep logs associated with computer security incidents for a 

substantially longer time than other logs, as needed. For example, General Records Schedule (GRS) 24, Information

Technology Operations and Management Records, specifies that ìcomputer security incident handling, reporting and 

follow-up recordsî should be destroyed ì3 years after all necessary follow-up actions have been completed.î GRS 24 is

available from the National Archives and Records Administration at http://www.archives.gov/records-mgmt/ardor/. 

6-10
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

atypical port) might not be detected. Another motivation for using unexpected port numbers is to

slip traffic through perimeter devices that filter based on port numbers. There are several ways to

attempt to identify unexpected port usage, including the following:

ñ Configuring IDS sensors to alert on connections involving unknown server ports

ñ Configuring application proxies or IDS sensors that perform protocol analysis to alert on

connections that use an unexpected protocol (e.g., FTP traffic using the standard HTTP port)

ñ Performing traffic flow monitoring and identifying new and unusual traffic flows

ñ Configuring a protocol analyzer to analyze a particular stream as something else.

! Alternate Access Points. Attackers often enter networks from alternate access points to avoid 

detection by security controls that are monitoring major access points, such as the organizationís 

Internet gateway. A classic example of an alternate access point is a modem in a userís

workstation. If an attacker can dial into the workstation and gain access, attacks can be launched

from that workstation against other hosts. In such cases, little or no information regarding the

network activity might be logged because the activity would not pass through firewalls, IDSmonitored network segments, and other common data collection points. Organizations typically

address this potential problem by limiting alternate access points, such as modems and wireless

access points, and ensuring that each is monitored and restricted through firewalls, IDS sensors,

and other controls.

! Monitoring Failures. Inevitably, systems and applications will occasionally experience failures

or outages for various reasons (e.g., system maintenance, software failures, attacks). In the case

of dedicated monitoring systems such as IDS sensors, use of redundant equipment (e.g., two 

sensors monitoring the same activity) can lessen the impact of monitoring failures.

105 Another 

strategy is to perform multiple levels of monitoring, such as configuring network-based and hostbased firewalls to log connections.

6.4 Examining and Analyzing Network Traffic Data

When an event of interest has been identified, analysts assess, extract, and analyze network traffic data

with the goal of determining what has happened and how the organizationís systems and networks have

been affected. This process might be as simple as reviewing a few log entries on a single data source and

determining that the event was a false alarm, or as complex as sequentially examining and analyzing

dozens of sources (most of which might contain no relevant data), manually correlating data among

several sources, then analyzing the collective data to determine the probable intent and significance of the

event. However, even the relatively simple case of validating a few log entries can be surprisingly

involved and time-consuming.

Although current tools (e.g., SEM software, NFAT software) can be helpful in gathering and presenting 

network traffic data, such tools have rather limited analysis abilities and can be used effectively only by

well-trained, experienced analysts. In addition to understanding the tools, analysts should also have

reasonably comprehensive knowledge of networking principles, common network and application

protocols, network and application security products, and network-based threats and attack methods.

106 It

is also very important that analysts have knowledge of the organizationís environment, such as the

network architecture and the IP addresses used by critical assets (e.g., firewalls, publicly accessible

 105 In most organizations, the cost of redundant monitoring makes it feasible only for the highest risk areas. 106 Helpful references for analysts include lists of commonly used protocols and their typical port numbers, and Request for

Comment (RFC) documents that explain the standards for various network and application protocols.

6-11
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

servers), as well as knowledge of the information supporting the applications and OSs used by the

organization. If analysts understand the organizationís normal computing baseline, such as typical

patterns of usage on systems and networks across the enterprise, they should be able to perform their

work easier and faster. Analysts should also have a firm understanding of each of the network traffic data

sources, as well as access to supporting materials, such as intrusion detection signature documentation. 

Analysts should understand the characteristics and relative value of each data source so that they can

locate the relevant data quickly.

Given the potential complexities of the analysis process and the extensive knowledge of networking and

information security required for analyzing network traffic data effectively, a full description of

techniques needed for analyzing data and drawing conclusions in complex situations is beyond the scope

of this document. Instead, the section focuses on the basic steps of the examination and analysis

processes and highlights some significant technical issues that analysts should consider.

6.4.1

6.4.2

Identify an Event of Interest

The first step in the examination process is the identification of an event of interest. Typically, this

identification is made through one of two methods: 

! Someone within the organization (e.g., help desk agent, system administrator, security

administrator) receives an indication, such as an automated alert or a user complaint, that there is

a security or operational-related issue. The analyst is asked to research the corresponding

activity.

! During a review of security event data (e.g., IDS monitoring, network monitoring, firewall log 

review), which is part of the analystís regular duties, the analyst identifies an event of interest and

determines that it should be researched further.

When an event of interest has been identified, the analyst needs to know some basic information about the

event as a basis for research. In most cases, the event will have been detected through a network traffic 

data source, such as an IDS sensor or a firewall, so the analyst can simply be pointed to that data source

for more information. However, in some cases, such as a user complaint, it might not be apparent which

data sources (if any) contain relevant information or which hosts or networks might be involved. 

Therefore, analysts might need to rely on more general informationófor example, reports that several

systems on the fourth floor have been rebooting themselves. Although data examination is easier if the

event information is specific (e.g., IP addresses of affected systems), even general information provides

the analyst with a starting point for finding the relevant data sources.

Examine Data Sources

As described in Section 6.2, organizations may have many sources of network traffic-related data. A 

single event of interest could be noted by many of these data sources, but it may be inefficient or

impractical to check each source individually. For initial event data examination, analysts typically rely

on a few primary data sources, such as an IDS console that displays alerts from all IDS sensors, or SEM 

or NFAT software that consolidates many other data sources and organizes the data. Not only is this an

efficient solution, but also in most cases the event of interest will be identified by an alert from one of

these primary data sources.

For each data source examined, analysts should consider its fidelity. In general, analysts should have

more confidence in original data sources than in data sources that receive normalized (modified) data

from other sources. In addition, analysts should validate data that is based on interpretation, such as IDS

and SEM alerts. No tool for identifying malicious activity is completely accurate; they produce both false

6-12
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

positives (incorrectly reporting benign activity as malicious) and false negatives (incorrectly classifying

malicious activity as benign).

107 Tools such as NFAT and IDS might also produce inaccurate alerts if

they do not process all packets within a connection.

108 Validation should be based on an analysis of

additional data (e.g., raw packets, supporting information captured by other sources), a review of

available information on alert validity (e.g., vendor comments on known false positives), and past 

experience with the tool in question. In many cases, an experienced analyst can quickly examine the 

supporting data and determine that an alert is a false positive and does not need further investigation.

Analysts may also need to examine secondary network traffic data sources, such as host-based firewall

logs and packet captures, and non-network traffic data sources, such as host OS audit logs and antivirus

software logs. The most common reasons for doing this are as follows:

! No Data on Primary Sources. In some cases, the typical primary network traffic data sources

do not contain evidence of the activity. For example, an attack might have occurred between two 

hosts on an internal network segment that is not monitored or controlled by network security

devices. In these cases, analysts should identify other likely data sources and examine them for

evidence.

! Insufficient or Unvalidated Data on Primary Sources. Analysts might need to examine

secondary data sources if primary data sources do not contain sufficient information or analysts

need to validate the data. After reviewing one or more primary data sources, analysts should

query the appropriate secondary data sources based on the pertinent data from the primary data

sources. For example, if IDS records indicate an attack against the system at IP address

10.20.30.40 with an apparent origin of IP address 10.3.0.1, querying other data sources using one

or both IP addresses might uncover additional data regarding the activity. Analysts also use

timestamps,109 protocols, port numbers, and other common data fields to narrow their search as

necessary.

! Best Source of Data Elsewhere. Occasionally, the best sources of network traffic data are

located on a particular host, such as host-based firewall and IDS logs on a system that was

attacked. Although such data sources can be very helpful, their data may be altered or destroyed

during a successful attack.

If additional data is needed but cannot be located and the suspicious activity is still occurring, analysts 

might need to perform more data collection activities. For example, an analyst could perform packet

captures at an appropriate point on the network to gather more information. Other ways to collect more

information include configuring firewalls or routers to log more information on certain activity, setting an

IDS signature to capture packets for the activity, and writing a custom IDS signature that alerts when a

specific activity occurs. See Section 6.2 for additional guidance on tools that can collect data. Collecting

additional data may be helpful if the activity is ongoing or intermittent; if the activity has ended, there is

no opportunity to collect additional data. 

 107 From an analystís perspective, the concept of false negatives is important because it means that security devices sometimes

fail to report attacks that they have observed. Analysts should not assume that an activity is benign if security devices have

not reported it as malicious. 108 There are several possible causes for not processing all packets, including security device failure (e.g., outage, software

bug), security device overload (e.g., unusually high volume of packets to process), and asynchronous routing. In

asynchronous routing, the incoming packets and outgoing packets for a connection take different routes. If only one of these 

routes is monitored by a device such as an IDS sensor, the device can see only part of the connection. 109 As mentioned in Section 4.3.3, organizations should use time synchronization to keep systemsí clocks consistent. 

Correlating an event among multiple network traffic sources is easier and more effective if the clocks are in synch. If event

data sources are on separate devices, timestamps can be helpful in confirming the path that the packets used. (When packets

traverse a network, it takes them some amount of time to get from one device to the next.)

6-13
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

6.4.2.1 Data Source Value

As described in Section 6.2, organizations typically have many different sources of network traffic data.

Because the information collected by these sources varies, the sources may have different value to the

analyst, both in general and for specific cases. The following items describe the typical value of the most

common data sources in network forensics:

! IDS Software. IDS data is often the starting point for examining suspicious activity. Not only

do IDSs typically attempt to identify malicious network traffic at all TCP/IP layers, but also they

log many data fields (and sometimes raw packets) that can be useful in validating events and

correlating them with other data sources. Nevertheless, as noted previously, IDS software does 

produce false positives, so IDS alerts should be validated. The extent to which this can be done

depends on the amount of data recorded related to the alert and the information available to the

analyst about the signature characteristics or anomaly detection method that triggered the alert.

! SEM Software. Ideally, SEM can be extremely useful for forensics because it can automatically

correlate events among several data sources, then extract the relevant information and present it

to the user. However, because SEM software functions by bringing in data from many other

sources, the value of SEM depends on which data sources are fed into it, how reliable each data

source is, and how well the software can normalize the data and correlate events.

! NFAT Software. NFAT software is designed specifically to aid in network traffic analysis, so it

is valuable if it has monitored an event of interest. NFAT software usually offers features that

support analysis, such as traffic reconstruction and visualization; Section 6.2.6 describes these in

more depth.

! Firewalls, Routers, Proxy Servers, and Remote Access Servers. By itself, data from these

sources is usually of little value. Analyzing the data over time can indicate overall trends, such as

an increase in blocked connection attempts. However, because these sources typically record

little information about each event, the data provides little insight into the nature of the events. 

Also, many events might be logged each day, so the sheer volume of data can be overwhelming. 

The primary value of the data is to correlate events recorded by other sources. For example, if a

host is compromised and a network IDS sensor detected the attack, querying the firewall logs for

events involving the apparent attacking IP address might confirm where the attack entered the

network and might indicate other hosts that the attacker attempted to compromise. In addition,

address mapping (e.g., NAT) performed by these devices is important for network forensics

because the apparent IP address of an attacker or a victim might actually have been used by

hundreds or thousands of hosts. Fortunately, analysts usually can review the logs to determine

which internal address was in use.

! DHCP Servers. DHCP servers typically can be configured to log each IP address assignment 

and the associated MAC address, along with a timestamp. This information can be helpful to

analysts in identifying which host performed an activity using a particular IP address. However,

analysts should be mindful of the possibility that attackers on an organizationís internal networks

falsified their MAC addresses or IP addresses, a practice known as spoofing. 

! Packet Sniffers. Of all the network traffic data sources, packet sniffers can collect the most

information on network activity. However, sniffers might capture huge volumes of benign data

as wellómillions or billions of packetsóand typically provide no indication as to which packets 

might contain malicious activity. In most cases, packet sniffers are best used to provide more

data on events that other devices or software has identified as possibly malicious. Some

organizations record most or all packets for some period of time so that when an incident occurs, 

6-14
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

the raw network data is available for examination and analysis.

110 Packet sniffer data is best

reviewed with a protocol analyzer, which interprets the data for the analyst based on knowledge

of protocol standards and common implementations.

! Network Monitoring. Network monitoring software is helpful in identifying significant 

deviations from normal traffic flows, such as those caused by DDoS attacks, during which,

hundreds or thousands of systems launch simultaneous attacks against particular hosts or

networks. Network monitoring software can document the impact of these attacks on network 

bandwidth and availability, as well as providing information about the apparent targets. Traffic

flow data can also be helpful in investigating suspicious activity identified by other sources. For

example, it might indicate whether a particular communications pattern has occurred in the

preceding days or weeks.

! ISP Records. Information from an ISP is primarily of value in tracing an attack back to its

source, particularly when the attack uses spoofed IP addresses. Section 6.4.4 discusses this

subject in more depth.

6.4.2.2 Examination and Analysis Tools

Because network forensics can be performed for many purposes with dozens of data source types,

analysts may use several different tools on a regular basis, each well-suited to certain situations. Analysts 

should be aware of the possible approaches to examining and analyzing network traffic data and should

select the best tools for each case, rather than applying the same tool to every situation. Analysts should

also be mindful of the shortcomings of tools; for example, a particular protocol analyzer might not be able

to translate a certain protocol or handle unexpected protocol data (e.g., illegal data field value). It can be

helpful to have an alternate tool available that might not have the same deficiency. 

Tools are often helpful in filtering data. For example, an analyst might need to search data without any 

concrete information that could narrow the search. This is most likely to occur when the analyst is

responsible for performing periodic or ongoing reviews of security event data logs and alerts. If the

volume of log entries and alerts is low, reviewing the data is relatively easyóbut in some cases, there

may be many thousands of events listed per day. When a manual data review is not possible or practical,

analysts should use an automated solution that filters the events and presents the analysts with only the

events that are most likely to be of interest. One effective review technique is to import the logs into a

database and run queries against them, either eliminating types of activity highly likely to be benign and

reviewing the rest, or focusing on the types of activity most likely to be malicious. For example, if the

initial suspicion is that the server was compromised through HTTP activity, then log filtering might start

by eliminating everything except HTTP activity from consideration. An analyst who is very familiar with

a particular data source can generally perform a blind search on it relatively quickly, but, on unfamiliar

data sources, blind searches can take an extremely long time, because there might be little or no basis for

eliminating certain types of activity from consideration.

Another analysis option is to use a visualization tool. These tools present security event data in a

graphical format. This is most often used to represent network traffic flows visually, which can be very

helpful in troubleshooting operational issues and identifying misuse. For example, attackers might use 

covert channelsóusing protocols in unintended ways to secretly communicate information (e.g., setting

certain values in network protocol headers or application payloads). The use of covert channels is

generally hard to detect, but one useful method is identifying deviations in expected network traffic flows.

 110 Many NFAT programs, as described in Section 6.2.6, provide this function, as well as additional capabilities.

6-15
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Visualization tools are often included in NFAT software, as described in Section 6.2.6. Some

visualization tools can perform traffic reconstructionóby using timestamp and sequential data fields, the

tools can determine the sequence of events and graphically display how the packets traversed the

organizationís networks. Some visualization tools can also be used to display other types of security

event data. For example, an analyst could import intrusion detection records into a visualization tool,

which would then display the data according to several different characteristics, such as source or

destination IP address or port. An analyst could then suppress the display of known good activity so that

only unknown events are shown.

Although visualization tools can be very effective for analyzing certain types of data, analysts typically

experience a steep learning curve with such tools. Importing data into the tool and displaying it is usually

relatively straightforward, but learning how to use the tool efficiently to reduce large datasets to a few

events of interest can take considerable effort. Traffic reconstruction can also be performed by protocol

analyzers. Although these tools generally lack visualization capabilities, they can turn individual packets

into data streams and provide sequential context for activities.

6.4.3 Draw Conclusions

One of the most challenging aspects of network forensics is that the available data is typically not 

comprehensive. In many cases, if not most, some network traffic data has not been recorded and 

consequently has been lost. Generally, analysts should think of the analysis process as a methodical

approach that develops conclusions based on the data that is available and assumptions regarding the

missing data (which should be based on technical knowledge and expertise). Although analysts should

strive to locate and examine all available data regarding an event, this is not practical in some cases,

particularly when there are many redundant data sources. The analyst should eventually locate, validate,

and analyze enough data to be able to reconstruct the event, understand its significance, and determine its 

impact. In many cases, additional data is available from sources other than network trafficñrelated

sources (e.g., data files or host OSs). Section 8 provides examples of how analysis can correlate this other

data with data from network traffic to get a more accurate and comprehensive view of what occurred.

Generally, analysts should focus on identifying the most important characteristics of the activity and

assessing the negative impact it has caused or may cause the organization. Other actions, such as

determining the identity of an external attacker, are typically time-intensive and difficult to accomplish,

and do not aid the organization in correcting the operational issues or security weaknesses. Determining 

the intent of an attacker is also very difficult; for example, an unusual connection attempt could be caused

by an attacker, malicious code, misconfigured software, or an incorrect keystroke, among other causes. 

Although understanding intent is important in some cases, the negative impact of the event should be the

primary concern. Establishing the identity of the attacker might be important to the organization,

particularly when criminal activity has occurred, but in other cases it should be weighed against other

important goals to put it into perspective. The focus of the investigation should be determined at the

onset by the appropriate parties, who should decide if learning the identity of the attacker is vital. It is

particularly important to seek the advice of legal counsel when developing policies and procedures related

to making such decisions, as well as when guidance is needed for a particular situation.

Organizations should be interested not only in analyzing real events, but also in understanding the causes

of false alarms. For example, analysts are often well-positioned to identify the root causes of IDS false

positives. As merited, analysts should recommend changes to security event data sources that improve

detection accuracy.

6-16
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

6.4.4

 

Attacker Identification

When analyzing most attacks, identifying the attacker is not an immediate, primary concern: ensuring that

the attack is stopped and recovering systems and data are the main interests. If an attack is ongoing, such

as an extended denial of service attack, organizations might want to identify the IP address used by the

attacker so that the attack can be stopped. Unfortunately, this is often not as simple as it sounds. The

following items explain potential issues involving the IP addresses apparently used to conduct an attack:

! Spoofed IP Addresses. Many attacks use spoofed IP addresses. Spoofing is far more difficult to

perform successfully for attacks that require connections to be established, so it is most 

commonly used in cases where connections are not needed.

111 When packets are spoofed, usually

the attacker has no interest in seeing the response. This is not always trueóattackers could spoof

an address from a subnet that they monitor, so that when the response goes to that system, they

can sniff it from the network. Sometimes spoofing occurs by accident, such as an attacker

misconfiguring a tool and accidentally using internal NAT addresses. Sometimes an attacker

spoofs a particular address on purposeófor example, the spoofed address might be the actual

intended target of the attack, and the organization seeing the activity might simply be a

middleman.

! Many Source IP Addresses. Some attacks appear to use hundreds or thousands of different 

source IP addresses. Sometimes this appearance reflects realityófor example, DDoS attacks

typically rely on large numbers of compromised machines performing a coordinated attack.

Sometimes this appearance is illusoryóan attack might not require the use of real source IP

addresses, so the attacker generates many different fake IP addresses to add confusion. 

Sometimes attackers will use one real IP address and many fake ones; in that case, it might be

possible to identify the real IP address by looking for other network activity occurring before or

after the attack that uses any of the same IP addresses. Finding a match does not confirm that it

was the attackerís address; the attacker could have inadvertently or purposely spoofed a

legitimate IP address that happened to be interacting with the organization.

! Validity of the IP Address. Because IP addresses are often assigned dynamically, the system

currently at a particular IP address might not be the same system that was there when the attack

occurred. In addition, many IP addresses do not belong to end-user systems, but instead to

network infrastructure components that substitute their IP address for the actual source address,

such as a firewall performing NAT. Some attackers use anonymizers, which are intermediate

servers that perform activity on a userís behalf to preserve the userís privacy.

Several ways of validating the identity of a suspicious host are as follows:

! Contact the IP Address Owner. The Regional Internet Registries, such as the American

Registry for Internet Numbers (ARIN),

112 provide WHOIS query mechanisms on their Web sites 

for identifying the organization or person that ownsóis responsible foróa particular IP address. 

This information can be helpful in analyzing some attacks, such as seeing that three different IP

addresses generating suspicious activity are all registered to the same owner. However, in most 

cases, analysts should not contact the owner directly; instead, they should provide information

about the owner to the management and legal advisors of the analystís organization, who can 

initiate contact with the organization or give the analyst approval to do so if needed. This caution 

111 Connectionless protocols such as ICMP and UDP are the most likely to be spoofed. 112 ARINís web site is at http://www.arin.net/. The other registries are the Asia Pacific Network Information Centre (APNIC), 

located at http://www.apnic.net/; Latin American and Caribbean IP Address Regional Registry (LACNIC), located at

http://lacnic.net/; and RÈseaux IP EuropÈens Network Coordination Centre (RIPE NCC), located at http://www.ripe.net/. 

6-17
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

is primarily related to concerns about sharing information with external organizations; also, the

owner of an IP address could be the person attacking the organization.

! Send Network Traffic to the IP Address. Organizations should not send network traffic to an

apparent attacking IP address to validate its identity. Any response that is generated cannot

conclusively confirm the identity of the attacking host. Moreover, if the IP address is for the 

attackerís system, the attacker might see the traffic and react by destroying evidence or attacking

the host sending the traffic. If the IP address is spoofed, sending unsolicited network traffic to the

system could be interpreted as unauthorized use or an attack. Under no circumstances should

individuals attempt to gain access to othersí systems without permission.

! Seek ISP Assistance. As mentioned in Section 6.3.1, ISPs generally require a court order before

providing any information to an organization about suspicious network activity. Accordingly,

ISP assistance is generally an option during only the most serious network-based attacks. This

assistance is particularly useful in relation to attacks that involve IP address spoofing. ISPs have

the ability to trace ongoing attacks back to their source, whether the IP addresses are spoofed or

not.

! Research the History of the IP Address. Analysts can look for previous suspicious activity

associated with the same IP address or IP address block. The organizationís own network traffic

data archives and incident tracking databases might show previous activity. Possible external

sources include Internet search engines and online incident databases that allow searches by IP

address.

113

! Look for Clues in Application Content. Application data packets related to an attack might 

contain clues to the attackerís identity. In addition to IP addresses, valuable information could

include an e-mail address or an Internet relay chat (IRC) nickname.

In most cases, organizations do not need to positively identify the IP address used for an attack.

6.5 Recommendations

Key recommendations presented in this section for using data from network traffic are as follows:

! Organizations should have policies regarding privacy and sensitive information. The use of

forensic tools and techniques might inadvertently disclose sensitive information to analysts and

others involved in forensic activities. Also, long-term storage of sensitive information

inadvertently captured by forensic tools might violate data retention policies. Policies should also

address the monitoring of networks, as well as requiring warning banners on systems that indicate

activity may be monitored.

! Organizations should provide adequate storage for network activityñrelated logs. 

Organizations should estimate typical and peak log usage, determine how many hoursí or daysí

worth of data should be retained based on the organizationís policies, and ensure that systems and 

applications have sufficient storage available. Logs related to computer security incidents might 

need to be kept for a substantially longer period of time than other logs.

! Organizations should configure data sources to improve the collection of information. Over

time, operational experience should be used to improve the organizationís forensic analysis

capabilities. Organizations should periodically review and adjust the configuration settings of

data sources to optimize capture of relevant information.

 113 One publicly available incident database is DShield, located at http://www.dshield.org/. 

6-18
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Analysts should have reasonably comprehensive technical knowledge. Because current tools

have rather limited analysis abilities, analysts should be well-trained, experienced, and 

knowledgeable in networking principles, common network and application protocols, network

and application security products, and network-based threats and attack methods.

! Analysts should consider the fidelity and value of each data source. Analysts should have

more confidence in original data sources than in data sources that receive normalized data from

other sources. The analysts should validate any unusual or unexpected data that is based on

interpretation of data, such as IDS and SEM alerts.

! Analysts should generally focus on the characteristics and impact of the event. Determining

the identity of an attacker and other similar actions are typically time-intensive and difficult to

accomplish, and do not aid the organization in correcting operational issues or security

weaknesses. Establishing the identity and intent of an attacker may be important, especially if a

criminal investigation will ensue, but should be weighed against other important goals, such as

stopping an attack and recovering systems and data.

6-19
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

6-20
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

7. Using Data from Applications

Applications such as e-mail, Web browsers, and word processors are what make computers valuable to

users. OSs, files, and networks are all needed to support applications: OSs to run the applications,

networks to send application data between systems, and files to store application data, configuration

settings, and logs. From a forensic perspective, applications bring together files, OSs, and networks. 

This section describes application architecturesóthe components that typically make up applicationsó

and provides insights into the types of applications that are most often the focus of forensics. The section

also provides guidance on collecting, examining, and analyzing application data.

7.1 Application Components

All applications contain code in the form of executable files (and related files, such as shared code

libraries) or scripts. In addition to code, many applications have one or more of the following

components: configuration settings, authentication, logs, data, and supporting files. Sections 7.1.1

through 7.1.5 describe these components in detail, and Section 7.1.6 discusses the major types of

application architectures, which relate to the intended distribution of the major components.

7.1.1

 

Configuration Settings

Most applications allow users or administrators to customize certain aspects of the applicationís behavior

by altering configuration settings. From a forensics perspective, many settings are trivial (e.g., specifying

background colors), but others might be very important, such as the host and directory where data files 

and logs are stored or the default username. Configuration settings may be temporaryóset dynamically

during a particular application sessionóor permanent. Many applications have some settings that apply 

to all users, and also support some user-specific settings. Configuration settings may be stored in several

ways, including the following:

! Configuration File. Applications may store settings in a text file or a file with a proprietary

binary format.

114 Some applications require the configuration file to be on the same host as the

application, whereas other applications allow configuration files to be located on other hosts. For

example, an application might be installed on a workstation, but the configuration file for a

particular user could be stored on the userís home directory on a file server.

! Runtime Options. Some applications permit certain configuration settings to be specified at

runtime through the use of command-line options. For example, the UNIX e-mail client mutt has

options for specifying the location of the mailbox to open and the location of the configuration

file. Identification of the options being used for an active session is OS- and application-specific; 

possible identification methods include reviewing the list of active OS processes, examining an

OS history file, and reviewing an application log. Runtime options can also be specified in icons,

startup files, batch files, and other ways.

! Added to Source Code. Some applications that make source code available (e.g., open source

applications, scripts) actually place user or administrator-specified configuration settings directly

into the source code. If the application is then compiled (e.g., converted from human-readable

code to a binary, machine-readable format), the configuration settings may actually be contained

within executable files, potentially making the settings far more difficult to access than if they

were specified in configuration files or as runtime options. In some cases, the settings can be

found by searching for text strings within the executable files.

114 For example, on Windows systems, many configuration settings are stored in the Windows registry, which is essentially a

set of large configuration files.

7-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

7.1.2

7.1.3

Authentication

Some applications verify the identity of each user attempting to run the application. Although this is

usually done to prevent unauthorized access to the application, it may also be done when access is not a

concern so that the application can be customized based on the userís identity. Common authentication

methods include the following:

! External Authentication. The application may use an external authentication service, such as a

directory server. Although the application may contain some records related to authentication,

the external authentication service is likely to contain more detailed authentication information.

! Proprietary Authentication. The application may have its own authentication mechanism, such

as user accounts and passwords that are part of the application, not the OS.

! Pass-Through Authentication. Pass-through authentication refers to passing OS credentials 

(typically, username and password) unencrypted from the OS to the application.

! Host/User Environment. Within a controlled environment (e.g., managed workstations and 

servers within an organization), some applications may be able to rely on previous authentication

performed by the OS. For example, if all hosts using an application are part of the same

Windows domain and each user has already been authenticated by the domain, then the

application can extract the OS-authenticated identity from each workstationís environment. The

application can then restrict access to the application by tracking which users are permitted to

have access and comparing the OS-authenticated identity to the authorized user list. This

technique is effective only if users cannot alter the user identity in the workstation environment.

Authentication implementations vary widely among environments and applications. The details of such

implementations are beyond the scope of this document. However, analysts should be aware that there

are many ways in which users can be authenticated and that, accordingly, the sources of user

authentication records might vary greatly among applications and application implementations. Analysts 

should also know that some applications use access control (typically enforced by the OS) to restrict

access to certain types of information or application functions. This knowledge can be helpful in

determining what a particular application user could have done. In addition, some applications record

information related to access control, such as failed attempts to perform sensitive actions or access 

restricted data. 

Logs

Although some applications (primarily very simple ones) do not record any information to logs, most

applications perform some type of logging. An application may record log entries to an OS-specific log

(e.g., syslog on UNIX systems, event logs on Windows systems), a text file, a database, or a proprietary

file format. Some applications record different types of events to different logs. Common types of log

entries are as follows:

! Event. Event log entries typically list actions that were performed, the date and time each action

occurred, and the result of each action. Examples of actions that might be recorded are

establishing a connection to another system and issuing administrator-level commands. Event log

entries might also include supporting information, such as what username was used to perform

each action and what status code was returned (which provides more information about the result

than a simple successful/failed status).

7-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Audit. Audit log entries, also known as security log entries, contain information pertaining to

audited activities, such as successful and failed logon attempts, security policy changes, file

access, and process execution.115 Applications may use audit capabilities built into the OS or may

provide their own auditing capabilities.

! Error. Some applications create error logs, which record information regarding application 

errors, typically with timestamps. Error logs are helpful in troubleshooting both operational

issues and attacks. Error messages can be helpful in determining when an event of interest 

occurred and in identifying some characteristics of the event.

! Installation. An application may create a separate installation log file that records information

pertinent to the initial installation and subsequent updates of that application. Information

recorded in an installation log varies widely but is likely to include the status of various phases of

the installation. The log may also indicate the source of the installation files, the locations where

the application components were placed, and options involving the applicationís configuration.

! Debugging. Some applications can be run in a debugging mode, which means that they log far

more information than usual regarding the operation of the application. Debugging records are

often very cryptic and may have meaning only to the softwareís creator, who can decipher error

codes and other facets of the records. If an application offers a debugging capability, typically it

is enabled only if administrators or developers need to resolve a specific operational problem.

7.1.4

7.1.5

 

Data

Nearly every application is specifically designed to handle data in one or more ways, such as creating,

displaying, transmitting, receiving, modifying, deleting, protecting, and storing data. For example, an email client allows a user to create an e-mail message and to send it to someone, as well as to receive,

view, and delete an e-mail message from someone else. Application data often resides temporarily in

memory, and temporarily or permanently in files. The format of a file containing application data may be

generic (e.g., text files, bitmap graphics) or proprietary. Data may also be stored in databases, which are

highly structured collections of files and data specifications. Some applications create temporary files 

during a session, which may contain application data. If an application fails to shut down gracefully, it

may leave temporary files on media. Most OSs have a directory designated for temporary files; however,

some applications have their own temporary directory, and other applications place temporary files in the

same directory where data is stored. Applications may also contain data file templates and sample data

files (e.g., databases, documents).

Supporting Files

Applications often include one or more types of supporting files, such as documentation and graphics. 

Supporting files tend to be static, but that does not mean that they are not of value for forensics. Types of

supporting files include the following:

! Documentation. This may include administrator and user manuals, help files, and licensing 

information. Documentation can be helpful to analysts in many ways, such as explaining what

the application does, how the application works, and what components the application has.

Documentation also typically contains contact information for the vendor of the application; the

vendor might be able to answer questions and provide other assistance in understanding the

application.

115 Some applications record logon attempts to a separate authentication log. Section 7.1.2 contains additional information 

about authentication.

7-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

! Links. Also known as shortcuts, links are simply pointers to something else, such as an

executable. Links are most frequently used on Windows systems; for example, the items listed

on the Start menu are really links to programs. By examining the properties of a link, an analyst 

can determine what program the link runs, where the program is, and what options (if any) are

set.

! Graphics. These files may include standalone graphics used by the application, as well as

graphics for icons. Although application graphics are typically of little interest to an analyst, icon

graphics may be of interest for identifying which executable was running.

7.1.6 Application Architecture

Every application has an architecture, which refers to the logical separation of its components and the

communication mechanisms used between components. Most applications are designed to follow one of

three major application architecture categories, as follows:

! Local. A local application is intended to be contained mainly within a single system. The code,

configuration settings, logs, and supporting files are located on the userís system. Local

applications are unlikely to perform authentication. Application data may be contained on the

userís system or another system (e.g., file server) and usually cannot be modified simultaneously

by multiple users. Examples of local applications are text editors, graphics editors, and office

productivity suites (e.g., word processor, spreadsheet).

! Client/Server. A client/server application is designed to be split among multiple systems. A

two-tiered client/server application stores its code, configuration settings, and supporting files on

each userís workstation, and its data on one or more central servers accessed by all users. Logs

are most likely stored on the workstations only. A three-tiered client/server application separates 

the user interface from the rest of the application, and also separates the data from the other

components. The classic three-tier model places the user interface code on the client workstation

(along with some supporting files), the rest of the application code on an application server, and

the data on a database server. Many Web-based applications use four-tier models: Web browser,

Web server, application server, and database server. Each tier interacts only with the adjacent

tiers, so in three and four-tier models, the client does not interact directly with the database

server. Examples of typical client/server applications are medical records systems, e-commerce

applications, and inventory systems.

! Peer-to-Peer. A peer-to-peer application is designed so that individual client hosts directly

communicate and share data with each other. Typically, the clients first communicate with a

centralized server that provides information about other clients; this information is then used to

establish direct connections that do not need to go through the centralized server. Examples of

peer-to-peer applications are certain file sharing, chat, and IM programs. However, some

programs of these types, while popularly referred to as peer-to-peer, are actually client/server,

because the clients communicate with a centralized server, instead of communicating directly

with each other. 

Most applications are quite flexible in terms of architecture. For example, many client/server applications

can have multiple tiers installed on a single system. Especially during application demonstrations or

testing, all tiers might be installed on one system. On the other hand, some local applications can be split 

among systems, with some components on local systems and some on remote systems. Applications

often make it easy to specify where different components should be installed and where data and 

configuration files should be stored. For many applications, there can be a great deal of variety among

deployments.

7-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Applications that are designed to split their code among multiple hosts typically use application protocols 

for communications between hosts.

116 Ubiquitous types of applications, such as e-mail and Web, use

well-known, standardized application protocols to facilitate interoperability among different components. 

For example, nearly every e-mail client program is compatible with nearly every e-mail server program

because they are based on the same application protocol standards. However, a program based on a

standard might add proprietary features or violate the standard in some way, especially if the standard is

not exhaustively detailed. If interoperability with other applications is not a concern (or not desirable)

and the same party is creating all application components, non-standard protocols are often used.

As described throughout Section 7.1, applications may have many different components that operate

together. In addition, an application may be dependent on one or more other applications. For example,

many e-commerce application clients run within Web browsers. Many applications also rely on OS

services, such as printing and DNS lookups (to find the IP addresses of application servers and other

devices). Applications vary widely in complexity, from a simple utility program such as a calculator to a

large e-commerce application that may involve many thousands of components and have millions of

users.

7.2 Types of Applications

Applications exist for nearly every purpose imaginable. Although forensic techniques can be applied to

any application, certain types of applications are more likely to be the focus of forensic analysis,

including e-mail, Web usage, interactive messaging, file sharing, document usage, security applications,

and data concealment tools. Nearly every computer has at least a few applications installed from these

categories. The following sections describe each of these types of applications in more detail.

7.2.1

 

E-mail

E-mail has become the predominant means for people to communicate electronically. Each e-mail

message consists of a header and a body. The body of the e-mail contains the actual content of the

message, such as a memorandum or a personal letter. The header of the e-mail includes various pieces of

information regarding the e-mail. By default, most e-mail client applications display only a few header

fields for each message: the senderís and recipientsí e-mail addresses, the date and time the message was

sent, and the subject of the message. However, the header typically includes several other fields,

including the following:117

! Message ID

! Type of e-mail client used to create the message

! Importance of the message, as indicated by the sender (e.g., low, normal, high)

! Routing informationówhich e-mail servers the message passed through in transit and when each

server received it

! Message content type, which indicates whether the e-mail content simply consists of a text body

or also has file attachments, embedded graphics, etc.

E-mail client applications are used to receive, store, read, compose, and send e-mails. Most e-mail clients 

also provide an address book that can hold contact information, such as e-mail addresses, names, and

116 Applications that are designed to keep all code on a single host typically do not need to use any application protocols. 117 Most e-mail clients have a configuration setting that specifies whether full or partial e-mail headers should be displayed.

7-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

phone numbers. Encryption programs are sometimes used in conjunction with e-mail clients to encrypt 

an e-mailís body and/or attachments.

When a user sends an e-mail, it is transferred from the e-mail client to the server using SMTP. If the

sender and recipient of the e-mail use different e-mail servers, the e-mail is then routed using SMTP

through additional e-mail servers until it reaches the recipientís server. Typically, the recipient uses an email client on a separate system to retrieve the e-mail using Post Office Protocol 3 (POP3) or Internet

Message Access Protocol (IMAP); in some cases, the e-mail client may be on the destination server (e.g.,

a multi-user UNIX system). The destination server often performs checks on the e-mails before making

them available for retrieval, such as blocking messages with inappropriate content (e.g., spam, virus).

From end to end, information regarding a single e-mail message may be recorded in several placesóthe

senderís system, each e-mail server that handles the message, and the recipientís system, as well as

antivirus, spam, and content filtering servers.

118

7.2.2

 

Web Usage

Through Web browsers, people access Web servers that contain nearly every type of data imaginable. 

Many applications also offer Web-based interfaces, which are also accessed through Web browsers. 

Because they can be used for so many purposes, Web browsers are one of the most commonly used

applications. The basic standard for Web communications is HTTP; however, HTTP can contain many

types of data in a variety of standard and proprietary formats. HTTP is essentially the mechanism for

transferring data between the Web browsers and the Web servers.119

Typically, the richest sources of information regarding Web usage are the hosts running the Web 

browsers. Information that may be retrieved from Web browsers include a list of favorite Web sites, a 

history (with timestamps) of Web sites visited, cached Web data files, and cookies (including their

creation and expiration dates). Another good source of Web usage information is Web servers, which

typically keep logs of the requests they receive. Data that is often logged by Web servers for each request 

includes a timestamp; the IP address, Web browser version, and OS of the host making the request; the

type of request (e.g., read data, write data); the resource requested; and the status code. The response to

each request includes a three-digit status code that indicates the success or failure of the request. For

successful requests, the status code explains what action was performed; for failures, the status code

explains why the request failed.

Several other types of devices and software, in addition to Web browsers and servers, might also log

related information. For example, Web proxy servers and application proxying firewalls might perform

detailed logging of HTTP activity, with a level of detail similar to that of Web server logs.

120 Routers,

non-proxying firewalls, and other network devices might log the basic aspects of HTTP network 

connections, such as source and destination IP addresses and ports. Organizations that use Web content

monitoring and filtering services might find useful data in the servicesí logs, particularly regarding denied

Web requests. 

118 For more information on e-mail services, see NIST SP 800-45, Guidelines on Electronic Mail Security, available for

download from http://csrc.nist.gov/publications/nistpubs/index.html. 119 For a detailed description of the current HTTP standard, see RFC 2616, Hypertext Transfer ProtocolóHTTP/1.1, available 

at http://www.ietf.org/rfc/rfc2616.txt. Also, see NIST SP 800-44, Guidelines on Securing Public Web Servers, for 

additional information on Web services; it is available for download from

http://csrc.nist.gov/publications/nistpubs/index.html. 120 Typically, proxies cannot log the details of SSL or TLS-protected HTTP requests, because the requests and the 

corresponding responses pass through the proxy encrypted, which conceals their contents.

7-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

7.2.3

7.2.4

 

Interactive Communications

Unlike e-mail messages, which typically take minutes to go from sender to recipient, interactive

communications services provide real-time (or near-real-time) communications. Types of applications

commonly used for interactive communications include the following:

! Group Chat. Group chat applications provide virtual meeting spaces where many users can

share messages at once. Group chat applications typically use a client/server architecture. The

most popular group chat protocol, Internet Relay Chat (IRC), is a standard protocol that uses

relatively simple text-based communications.

121 IRC also provides a mechanism for users to send

and receive files.

! Instant Messaging Applications. IM applications are either peer-to-peer, allowing users to send

text messages and files directly to each other, or client/server, passing messages and files through 

a centralized server. IM application configuration settings may contain user information, lists of

users that the user has communicated with, file transfer information, and archived messages or

chat sessions. There are several major Internet-based IM services, each of which uses its own

proprietary communications protocols. Several companies also offer enterprise IM products that

are run within an organization. Such products are often integrated to some extent with the

organizationís e-mail services and can be used only by authenticated e-mail users.

! Audio and Video. As the capacity of networks continues to increase, conducting real-time video

and audio communications across computer networks also becomes more common. Technologies

such as Voice over IP (VoIP) permit people to conduct telephone conversations over networks

such as the Internet.

122 Some audio implementations provide computer-based service from end to

end, whereas others are only partially computer-based, with an intermediate server converting the

communications between computer networks and standard phone networks. Many audio 

technologies are primarily peer-to-peer applications. Video technologies can be used to hold

teleconferences or to have ìvideo phoneî communications between two individuals. Commonly

used protocols for audio and video communications include H.323 and Session Initiation Protocol

(SIP).123

File Sharing

Users can share files through many different programs. As described previously in this section, e-mail,

group chat programs, and IM software all offer the ability to send and receive particular files. However,

these programs generally do not allow a recipient to browse through files and to choose the files to

transfer. Full-fledged file sharing programs and protocols are needed for this level of functionality. File

sharing programs can be grouped by architecture, as follows: 

! Client/Server. Traditional file sharing services use client/server architectures, with a central file

server containing a repository of files. Clients can use the server by initiating connections to it,

authenticating to it (if required), reviewing the list of available files (if needed), then transferring

files to or from the server. Some commonly used client/server file sharing services are FTP,

Network File Sharing (NFS), Apple Filing Protocol (AFP), and Server Message Block (SMB).

124 

121 The original standard for IRC is documented in RFC 1459, Internet Relay Chat Protocol, available at

http://www.ietf.org/rfc/rfc1459.txt. RFCs 2810 through 2813 contain additional information that supplements RFC 1459. 122 For more information on VoIP, see NIST SP 800-58, Security Considerations for Voice Over IP Systems, available at

http://csrc.nist.gov/publications/nistpubs/index.html. 123 The standard for SIP is available as RFC 3261, SIP: Session Initiation Protocol, located at

http://www.ietf.org/rfc/rfc3261.txt. 124 More information on SMB is available from http://samba.anu.edu.au/cifs/docs/what-is-smb.html. 

7-7
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

These are standardized protocols that do not protect the confidentiality of the data in transit,

including any supplied authentication credentials, such as passwords. Secure alternatives, such as

Secure FTP (SFTP) and Secure Copy (scp), encrypt their network communications. Most OSs

have built-in file sharing clients (e.g., FTP, SMB), but users can also install various third-party 

programs that provide similar functionality.

! Peer-to-Peer. Most peer-to-peer file sharing services are primarily used to trade music, graphics,

or software across the Internet. Unlike client/server file sharing, in which a single server holds

the file repository, peer-to-peer file sharing is distributed, with files located on many different

hosts. Peer-to-peer file sharing services typically have a central server that gives clients 

information on where other clients are located, but the server does not participate in the

transmission of files or file information. Peer-to-peer file sharing services typically require no

user authentication. All file browsing and transfers occur directly between the clients (peers). 

Users typically can choose from several client programs when using a particular service. 

Although most services allow each user to control which files are shared on their system, services

known as encrypted peer-to-peer work by storing othersí files on an encrypted portion of each

userís hard drive, and giving users no control over or knowledge of what is stored in that area of

their own systems. Anonymous peer-to-peer services send requested files through multiple

intermediate hosts instead of simply sending them from source to destination, with the goal of

making it very difficult to identify the true source or destination of any given file.

7.2.5

7.2.6

7.2.7

 

Document Usage

Many users spend much of their time working with documents, such as letters, reports, and charts. 

Documents may contain any type of data, so they are often of interest to analysts. The class of software

used for creating, viewing, and editing such documents is known as office productivity applications. This

includes word processor, spreadsheet, presentation, and personal database software. Documents often

have user or system information embedded in them, such as the name or username of the person who 

created or most recently edited the document, or the license number of the software or the MAC address

of the system used to create the document.

125

Security Applications

Hosts often run one or more security applications that attempt to protect the host from misuse and abuse

occurring through commonly used applications, such as e-mail clients and Web browsers. Some

commonly used security applications are antivirus software, spyware detection and removal utilities,

content filtering (e.g., anti-spam measures), and host-based intrusion detection software. The logs of

security applications may contain detailed records of suspicious activity and may also indicate whether a

security compromise occurred or was prevented. If the security application is part of an enterprise

deployment, such as centrally managed and controlled antivirus software, logs may be available both on

individual hosts and on a centralized application log.

Data Concealment Tools

Some people use tools that conceal data from others. This might be done for benign purposes, such as

protecting the confidentiality and integrity of data against access by unauthorized parties, or for malicious

purposes, such as concealing evidence of improper activities. Examples of data concealment tools 

include file encryption utilities, steganographic tools, and system cleanup tools. System cleanup tools are

125 One example of an office productivity application that might capture user or system information within a document is

Microsoft Office. More information on this topic is available from Microsoft Knowledge Base article 834427, located at

http://support.microsoft.com/default.aspx?scid=kb;en-us;834427. 

7-8
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

special-purpose software that removes data pertaining to particular applications, such as Web browsers, as

well as data in general locations, such as temporary directories. The use of most data concealment tools is

unlikely to be captured in logs. Analysts should be aware of the capabilities of these tools so that they

can identify such tools on a system and recognize the toolsí effects.

7.3 Collecting Application Data

As described in Section 7.1, application-related data may be located within filesystems, volatile OS data,

and network traffic. Sections 4.2, 5.2, and 6.3 contain specific information about collecting data from

these respective sources. The types of application data that these sources may contain are as follows:

! Filesystems. Filesystems may contain many types of files related to applications, including

executable files and scripts, configuration files, supporting files (e.g., documentation), logs, and

data files.

! Volatile OS Data. Volatile OS data may contain information about network connections used by

applications, the application processes running on a system and the command line arguments used

for each process, and the files held open by applications, as well as other types of supporting

information.

! Network Traffic. The most relevant network traffic data involves user connections to a remote

application and communications between application components on different systems. Other

network traffic records might also provide supporting information, such as network connections

for remote printing from an application, and DNS lookups by the application client or other

components to resolve application componentsí domain names to IP addresses.

Analysts often face a major challenge in determining which data should be collected. In many cases, the

analyst must first decide which application is of interest. For example, it is common to have multiple

Web browsers and e-mail clients installed on a single system. If analysts are asked to collect data

regarding an individualís use of the organizationís e-mail services, they need to be mindful of all the ways

in which the individual could have accessed those services. The userís computer could contain three

different e-mail clients, plus two Web browsers that could be used to access a Web-based e-mail client

provided by the organization. For the userís computer, analysts could simply collect all data from the

computer and then determine during the examination process which clients were actually used for e-mail. 

However, there are many potential data sources aside from the userís computer, and these sources might 

vary based on the client that was used. For example, use of the Web-based client might have been

recorded in Web server, firewall, IDS, and content monitoring software logs, as well as in Web browser 

history files, Web browser caches, cookies, and personal firewall logs. In some situations, collecting the

necessary data might involve identifying all components of the application, deciding which were most 

likely to be of interest (based on the details of the situation and the need), finding the location of each

component, and collecting data from those components. Section 8 contains examples that illustrate the

complexity of identifying components and prioritizing data collection for applications.

7.4 Examining and Analyzing Application Data

Examining and analyzing application data largely consists of looking at specific portions of application

dataófilesystems, volatile OS data, and network trafficóusing the tools and techniques described in

Sections 4.3 and 4.4, 5.3, and 6.4, respectively. Examination and analysis might be hindered if the

application were custom, such as a program written by the user; the analyst is unlikely to have any

knowledge of such an application. Another possible issue in examination involves use of applicationbased security controls, such as data encryption and passwords. Many applications use such security

controls to thwart unauthorized access to sensitive data by authorized users.

7-9
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

In some cases, analysts bring together pertinent application data from several varied application data

sources; this is largely a manual process. Detailed analysis of application-related events and event

reconstruction usually require a skilled and knowledgeable analyst who understands the information

presented by all the sources. The analyst can review the results of the examination and analysis of

individual application data sources and see how the information fits together. Tools that may be helpful

to analysts include security event management software (described in Section 6.2.5), which can correlate

some application-related events among multiple data sources, and log analysis software (including some

types of host-based intrusion detection software), which can be run against certain types of logs to

identify suspicious activity. Section 8 shows how data from multiple types of sources can be correlated

through analysis to reach a more accurate and comprehensive view of what occurred.

7.5 Recommendations

The key recommendations presented in this section for using data from applications are as follows:

! Analysts should consider all possible application data sources. Application events might be

recorded by many different data sources. In addition, applications might be used through

multiple mechanisms, such as multiple client programs installed on a system and Web-based 

client interfaces. In such situations, analysts should identify all application components, decide

which are most likely to be of interest, find the location of each component of interest, and collect

the data.

! Analysts should bring together application data from various sources. The analyst should

review the results of the examination and analysis of individual application data sources and 

determine how the information fits together, to perform a detailed analysis of application-related

events and event reconstruction.

7-10
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

8. Using Data from Multiple Sources 

Sections 4 through 6 describe the collection, examination, and analysis of data from three data source

categories: data files, OSs, and network traffic. The techniques and processes for collecting, examining,

and analyzing the data in these categories are fundamentally different. Section 7 describes the collection,

examination, and analysis of application data, which brings together the three data source categories. For

example, many applications use data files, alter the configuration of OSs, and generate network traffic. 

Many situations, such as computer security incidents, can be handled most effectively by analyzing 

multiple types of data sources and correlating events across sources.

This section of the guide presents two examples of the use of multiple data sources during digital

forensics. Each example describes a scenario, indicates a specific need for forensic analysis, and presents

an explanation of how the forensic process might be performed. The explanations also illustrate how

complex the process can be. The examples presented in this section are as follows:

! Determining which worm has infected a system and identifying the wormís characteristics 

! Reconstructing the sequence of cyber events involving a threatening e-mail.

8.1 Suspected Network Service Worm Infection

An organizationís help desk receives several calls in a short time from users complaining about a

particular server providing slow responses. The help desk sends a trouble ticket to the monitoring group. 

That groupís network IDSs have recently reported several unusual alerts involving the server, and the

analyst who reviewed the alerts believes that they may be accurate. The data in the alerts indicates that

some suspicious activity was directed at the server, and the server is now generating identical activity

directed at other systems. The intrusion detection analystís initial hypothesis is that a worm may have

attacked a vulnerable network service and infected the server, which is now attempting to infect other

systems. The monitoring group contacts the incident handler on duty to investigate the possible incident

on the server.

For the incident, this particular incident handlerís role is to determine the type of worm that has infected

the system and to identify the distinguishing characteristics of the worm. This information is critical to

the incident response teamís ability to effectively perform containment, eradication, and recovery

activities and to prevent other systems within the organization from becoming infected. If the incident

handlerís investigation shows that the incident was probably caused by something other than a worm, the

characteristics the handler identifies should be very helpful in determining what actually occurred.

Information regarding this incident may be recorded in several different places. The incident handler

should check the data sources that are most likely to have relevant information first, based on the

handlerís previous experience with the data sources and the initial information available regarding the

incident. For example, because network IDS sensors saw the suspicious activity, other network-based 

data sources monitoring the same network segment might also contain relevant information. If the

organization uses security event management or network forensic analysis tool software, which bring 

together data from many different sources, the incident handler may be able to gather all necessary

information just by running a few queries from the SEM or NFAT console. If a centralized source of data

is not available, the handler should check individual potential sources of attack characteristics, such as the

following:

! Network IDS. Because the initial reports of the incident were generated by network IDS sensors,

it is very likely that the network IDS data contains information on the basic characteristics of the

8-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

network activity. At a minimum, the data should indicate which server was attacked and on what

port number, which indicates which network service was targeted. Identifying the service is very

important to finding the exploited vulnerability and developing a mitigation strategy to prevent 

similar incidents from occurring on other systems. From an analysis standpoint, knowing the

targeted service and port number is also important because the information can be used to identify

other likely data sources and to query them for relevant information. Some network IDS

deployments may record additional useful information, such as application data (e.g., Web 

requests and responses, e-mail headers and file attachment names). The application data may 

contain words, phrases, or other character sequences that are associated with a particular worm. 

! Network-Based Firewall. Firewalls are typically configured to log blocked connection attempts,

including the intended destination IP address and port. Accordingly, firewalls might have records

of worm activity that they blocked. Some worms attempt to exploit multiple services or service

ports; firewall records might show that a worm has actually tried to establish connections to at

least four different port numbers, but that the firewall blocked connections using three of the

ports. This information could be useful in identifying the worm. If firewalls are configured to

record permitted connections, their logs may show which hosts within the organization have

received worm traffic or been infected and generated their own worm traffic. This is particularly

useful for situations in which network IDS sensors do not monitor all traffic that reaches the

firewall. Other perimeter devices that the worm traffic may have passed through, such as routers,

VPN gateways, and remote access servers, may record information similar to that logged by

network-based firewalls.

! Host IDS and Firewall. IDS and firewall products running on the infected system may contain 

more detailed information than network IDS and firewall products. For example, a host IDS can 

identify changes to files or configuration settings on the host that were performed by a worm. 

This information is helpful not only in planning containment, eradication, and recovery activities

by determining how the worm has affected the host, but also in identifying which worm infected

the system. However, because many worms disable host-based security controls and destroy log

entries, data from host IDS and firewall software may be limited or missing. If the software was 

configured to forward copies of its logs to centralized log servers, then queries to those servers 

may provide some information.

! Antivirus Software. Because the threat reached the server and successfully breached it, it is

unlikely that network or host-based antivirus software contains any record of the threat. If

antivirus software had detected the worm, it should have stopped it. However, it is possible that

the antivirus software saw the worm but somehow failed to stop it, or that the antivirus software

was updated since the infection with new signatures that can recognize the worm. The incident

handler can also scan the server for worms using a current version of antivirus software from a

forensic toolkit.

! Application Logs. If the worm used a common application protocol, such as HTTP or SMTP,

information regarding it might be recorded in several places, such as application server logs, 

proxy servers, and application-specific security controls. Less common application protocols

probably have information only in the application server logs. Application logs record extensive

details on the application-specific characteristics of the activity, and are particularly helpful at

identifying attack characteristics from less common applications.

The goal in the initial information gathering effort is to identify enough characteristics for positive

identification of the worm. This can be challenging, particularly for worms that have dozens of variants; 

these variants often have similar characteristics but have different effects on systems. Analysts can 

perform queries on antivirus vendorsí malware databases, searching for identified characteristics such as

8-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

product name, service name or port number, text strings within the malware, and files or settings modified

on the target.

126 Virtually any instance of malware, other than the latest threats (e.g., released in the past 

several hours), is likely to be included in major malware databases. Each database entry typically

contains extensive information on how the worm spreads, how it affects systems (e.g., what changes it

makes), and how it can be eradicated, including measures concerning prevention of infections on other

systems.

If a search of malware databases does not lead to identification of the worm, then the incident handler

may need to perform additional research and analysis to discover the information usually provided by

malware database entries. Although the organization can send a copy of the worm to the organizationís 

antivirus vendor for analysis and identification, the organization should perform its own analysis in the

meantime, since the time frame for the vendorís response is unknown. To gather more information, the

analyst can examine the infection through the following methods:

! Current State of the Host. The analyst can examine the host to look at several aspects of its 

current state. In this case, it is probably most effective to examine the network connections

listing to identify unusual connections (e.g., large number, unexpected port number usage,

unexpected hosts) and unexpected listening ports (e.g., backdoors created by the worm). Other

steps that may be useful include identifying unknown processes in the running processes list and

examining the hostís logs to reveal any unusual entries that may be related to the infection.

! Hostís Network Activity. The analyst can collect worm traffic being generated by the infected

server through a packet sniffer and protocol analyzer. This may provide enough additional 

information regarding the characteristics of the worm to enable the analyst to locate it in major

malware databases.

Worm incidents often necessitate as rapid a response as possible, because an infected system may be

attacking other systems inside and outside the organization. In addition, worms often install backdoors

and other tools on systems that permit attackers to gain remote access to infected systems, which can

create additional damage. Accordingly, organizations may choose to disconnect infected systems from

networks immediately, instead of performing data collection for the host first. This step may make it

considerably more difficult for analysts to identify a worm and to determine its effects on systemsófor

example, if systems are disconnected from the network, network activity and certain aspects of the host 

state will not be available. In such cases, the analyst may need to perform a more detailed forensic

analysis of the server, such as collecting its filesystems and examining them for signs of malicious 

activity (e.g., altered system executables) to determine exactly what happened to the server. The analyst 

can also examine non-volatile characteristics of the serverís OS, such as looking for administrative-level

user accounts and groups that may have been added by the worm. Ultimately, the analyst should gather

enough information to identify the wormís behavior in sufficient detail to enable the incident response

team to act effectively to contain, eradicate, and recover from the incident.

8.2 Threatening E-mail

An incident handler responds to a request for assistance with an internal investigation. An employee has

been accused of sending a threatening e-mail to another employee through the organizationís e-mail

system. The incident handler has been asked to help investigators find all data sources that may contain 

 126 Malware databases are maintained by several vendors, including Computer Associates

(http://www3.ca.com/securityadvisor/virusinfo/default.aspx), F-Secure (http://www.f-secure.com/virus-info/), Network 

Associates (http://vil.nai.com/vil/default.aspx), Sophos (http://www.sophos.com/virusinfo/analyses/), Symantec

(http://securityresponse.symantec.com/avcenter/vinfodb.html), and Trend Micro 

(http://www.trendmicro.com/vinfo/virusencyclo/). 

8-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

records of the e-mail. This information will be helpful to investigators in determining who sent the email. Because e-mail can be forged easily, it is important to use all available data sources to reconstruct 

the sequence of events for creating, sending, and receiving the e-mail. Also, the incident handler needs to

perform all work using forensically sound tools, techniques, and procedures, and to document all actions

performed. 

The threatening e-mail is key to the investigation, and its header contains the most important information

to the incident handler. It should contain the domain name and the IP address of the host that sent the email, the type of e-mail client used to send the e-mail, the e-mailís message ID, and the date and time the

e-mail was sent. The e-mail header should also list each e-mail server (domain name and IP address) that

the message passed through and the date and time each server processed the e-mail.

127 Because the e-mail

was supposedly sent using the organizationís e-mail system, the e-mail header should only list systems 

within the organization. Assuming that this is the case, the incident handler can check each system on the

list for correlating information. 

Because of the importance of the threatening e-mail, the incident handler should focus first on collecting a

copy of the e-mail, including its header. Depending on the type of e-mail client used by the recipient and

its configuration, the e-mail may have been downloaded to the recipientís workstation, or it may remain

on the e-mail server. It is also possible that the e-mail is still stored in both locations. The incident

handler should collect copies of the e-mail from multiple sources, if possible, to confirm that the content 

of the e-mail has been unchanged in transit or by the recipient.

After reviewing the header, the incident handler should next gather more information about the sending of

the e-mail. The header should list the IP address and the e-mail client used by the sender; the incident

handler should determine which host was using that IP address at the time the e-mail was sent. There are

three possibilities for the IP address:

! Local E-mail Client. In this case, the incident handler should be able to use network records,

such as DHCP logs, to identify the desktop, laptop, PDA, or other device used to send the e-mail. 

The incident handler can then create images of the identified device and examine an image copy

to look for malware and for records related to the e-mail. For example, the e-mail client might be

configured to keep a copy of each e-mail that it sends, or the user might have saved drafts of the

e-mail message. If the message cannot be found intact on the system, collecting data from the

deviceís memory and filesystems, including deleted and temporary files, might lead to the

identification of fragments of the e-mail. In addition, security controls on the device, such as

spam filtering and antivirus software, might have scanned the outgoing e-mail and logged a

record of it. It is also possible, but unlikely, that a copy of the e-mail is stored on an e-mail

server. In addition to looking for records of the e-mail on the local host, the incident handler

should analyze the authentication records on the host to determine which user account was in use

when the e-mail was sent.

! Server-Based E-mail Client. If the organization offers a server-based client, such as a Webbased e-mail interface, then the IP address may correspond to that server. Typically, the use of

such a server requires users to authenticate themselves, so there may be authentication records 

that indicate when the alleged sender logged on to the server and what IP address the userís

system was using. The incident handler can then determine which system was assigned that IP

address at the time, perform bit stream imaging for the identified system, and examine a copy of

 127 Within the e-mail header, these records are stored in reverse order, so the most recent record occurs first and the least recent

record occurs last. If an e-mail has been forged, the false records are the least recent, so they should appear last in the 

header. 

8-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

the image for the malware and the e-mail. For example, temporary files from the Web browser

may contain a copy of the e-mailís contents.

! Spoofed. If the IP address was fabricatedófor example, if it is not a valid address within the

organizationís networksóthe incident handler should rely on other data sources to identify the

host that actually sent the e-mail message.

The organizationís e-mail servers are another likely source of information. Each of the server IP

addresses listed in the e-mail header should contain some record of the e-mail, including the message ID

value, which should facilitate quick identification of pertinent records. As mentioned previously, the final 

e-mail server in the list may contain a copy of the e-mail. Backups of that server may contain a copy of

the e-mail, but only if it was held there for delivery for several hours or more. Other services associated

with e-mail, such as antivirus software and spam filters, may also contain basic records of e-mail activity,

but are unlikely to contain many details. Another possible source of information is authentication

records. Although few e-mail servers require users to authenticate to send e-mail, they typically do

require authentication to deliver e-mail to users. Because users often send and receive e-mail during a

single session, authentication logs may contain records for receiving e-mail that can be helpful in

determining who may have sent a particular e-mail.

Another possible source of information is a record of the network traffic generated by sending or

receiving the e-mail. Packet sniffers or network forensic analysis tools that were monitoring network 

activity might have captured the activity, including the actual IP addresses of the sending or receiving

hosts, the contents and header of the e-mail, and any associated authentication activity.

Ultimately, the incident handler should identify the hosts that were used to send and receive the e-mail, as

well as all intermediate hosts that transferred the e-mail from sender to receiver. The incident handler

should collect copies of the e-mail and supporting information from each relevant host and, using the

timestamps in records, should re-create the sequence of events from a cyber perspective. For example, a

possible sequence might be as follows: 

A user logged on to a particular desktop computer at 8:37 a.m. At 10:02 a.m., the

threatening e-mail was sent from that computer using its built-in e-mail client. The email passed through three of the organizationís e-mail servers and was stored on

Server 4 to await retrieval by the intended recipient. The recipient user logged onto a

particular laptop computer at 11:20 a.m. and downloaded e-mail, including the

threatening e-mail, at 11:23 a.m. The contents of the e-mail on the recipientís 

computer, as well as user-provided header fields (e.g., From, To, Subject), were

identical to a copy saved in the Sent folder on the first userís desktop computer.

This information can be used as a basis for further investigation; although it documents cyber activities, it

does not tell the whole story. For example, it cannot determine which person actually sent the e-mail

from the desktop computer, only which user account was in use at the time. The incident handler could

analyze the desktop computer in question to verify its integrity, such as comparing its security settings

and controls to the organizationís baseline settings, checking its clock settings, and checking the system

for signs of compromise and other breaches of security.

8.3 Recommendations

The key recommendations presented in this section for using data from multiple sources are as follows:

! Analysts can handle many situations most effectively by analyzing several individual data

sources and then correlating events among them. The techniques and processes for collecting,

8-5
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

examining, and analyzing different types of data sources are fundamentally different. Many 

applications have data captured in data files, OSs, and network traffic.

! Organizations should be aware of the technical and logistical complexity of analysis. A

single event can generate records on many different data sources and produce more information

than analysts can feasibly review. Tools such as SEM can assist analysts by bringing information

from many data sources together in a single place.

8-6
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix AóRecommendations

Appendix A restates the major recommendations presented in Sections 2 through 8 of this publication. 

The first group of recommendations applies to organizing a forensics capability. The remaining 

recommendations have been grouped by the phases of the forensics process: collection, examination,

analysis, and reporting.

A.1

A.1.1

A.1.2 

Organizing a Forensics Capability 

! Organizations should have a capability to perform computer and network forensics. 

Forensics is needed for various tasks within an organization, including investigating crimes and

inappropriate behavior, reconstructing computer security incidents, troubleshooting operational

problems, supporting due diligence for audit record maintenance, and recovering from accidental

system damage. Without such a capability, an organization will have difficulty determining what

events have occurred within its systems and networks, such as exposures of protected, sensitive

data. Also, handling evidence in a forensically sound manner puts decision makers in a position 

where they can confidently take the necessary actions.

Forensic Participants

! Organizations should determine which parties should handle each aspect of forensics. Most 

organizations rely on a combination of their own staff and external parties to perform forensic

tasks. Organizations should decide which parties should take care of which tasks based on skills

and abilities, cost, response time, and data sensitivity.

! Analysts should have reasonably comprehensive technical knowledge. Because current tools

have rather limited analysis abilities, analysts should be well-trained, experienced, and 

knowledgeable in networking principles, common network and application protocols, network

and application security products, and network-based threats and attack methods.

! Incident handling teams should have robust forensic capabilities. More than one team

member should be able to perform each typical forensic activity. Hands-on exercises and IT and 

forensic training courses can be helpful in building and maintaining skills, as can demonstrations

of new tools and technologies.

! Many teams within an organization should participate in forensics. Individuals performing

forensic actions should be able to reach out to other teams and individuals within an organization,

as needed, for additional assistance. Examples of teams that may provide assistance in these

efforts include IT professionals, management, legal advisors, human resources personnel,

auditors, and physical security staff. Members of these teams should understand their roles and

responsibilities in forensics, receive training and education on forensicñrelated policies,

guidelines, and procedures, and be prepared to cooperate with and assist others on forensic

actions.

Forensic Policies, Guidelines, and Procedures

! Forensic considerations should be clearly addressed in policies. At a high level, policies 

should allow authorized personnel to monitor systems and networks and perform investigations

for legitimate reasons under appropriate circumstances. Organizations may also have a separate

forensic policy for incident handlers and others with forensic roles that provides more detailed 

rules for appropriate behavior. Everyone who may be called upon to assist with any forensic

A-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

efforts should be familiar with and understand the forensic policy. Additional policy

considerations are as follows:

ñ Forensic policy should clearly define the roles and responsibilities of all people performing or

assisting with the organizationís forensic activities. The policy should include all internal

and external parties that may be involved and should clearly indicate who should contact 

which parties under different circumstances.

ñ The organizationís policies, guidelines, and procedures should clearly explain what forensic

actions should and should not be performed under normal and special circumstances and

should address the use of anti-forensic tools and techniques. Policies, guidelines, and 

procedures should also address the handling of inadvertent exposures of sensitive

information.

ñ Incorporating forensic considerations into the information system life cycle can lead to more

efficient and effective handling of many incidents.

ñ The organizationís policies should address inadvertent disclosures and long-term storage of

sensitive information captured by forensic tools, and should ensure that this does not violate

the organizationís privacy or data retention policies.

ñ The organizationís policies should also address the monitoring of networks, as well as

requiring warning banners on systems that indicate that activity might be monitored. The

policies should take into account reasonable expectations of user privacy.

! Organizations should create and maintain guidelines and procedures for performing

forensic tasks. The guidelines should include general methodologies for investigating an

incident using forensic techniques, and step-by-step procedures should explain how to perform

routine tasks. The guidelines and procedures should support the admissibility of evidence into

legal proceedings. Because electronic logs and other records can be altered or otherwise

manipulated, organizations should be prepared, through their policies, guidelines, and procedures,

to demonstrate the reliability and integrity of such records. The guidelines and procedures should

also be reviewed regularly and maintained so that they are accurate.

A.1.3

A.2

Technical Preparation

! Analysts should have a forensic toolkit for data collection, examination, and analysis. It

should contain various tools that provide the ability to collect and examine volatile and nonvolatile data and to perform quick reviews of data as well as in-depth analysis. The toolkit should

allow its applications to be run quickly and efficiently from removable media (e.g., floppy disk,

CD) or a forensic workstation.

! Organizations should provide adequate storage for network activityñrelated logs. 

Organizations should estimate typical and peak log usage, determine how many hours or daysí

worth of data should be retained based on the organizationís policies, and ensure that systems and 

applications have sufficient storage available. Logs related to computer security incidents might 

need to be kept for a substantially longer period of time than other logs.

Performing the Forensics Process

! Organizations should perform forensics using a consistent process. This guide presents a

four-phase forensics process, with collection, examination, analysis, and reporting phases. The

exact details of the phases may vary based on the need for forensics.

A-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

A.2.1 Data Collection

! Organizations should be proactive in collecting useful data. Configuring auditing on OSs,

implementing centralized logging, performing regular system backups, and using security

monitoring controls can all generate sources of data for future forensic efforts.

! Analysts should be aware of the range of possible data sources. Analysts should be able to

survey a physical area and recognize possible sources of data. Analysts should also think of

possible data sources located elsewhere within an organization and outside the organization. 

Analysts should be prepared to use alternate data sources if it is not feasible to collect data from a

primary source.

! Analysts should consider all possible application data sources. Application events might be

recorded by many different data sources. In addition, applications might be used through

multiple mechanisms, such as multiple client programs installed on a system and Web-based 

client interfaces. In such situations, analysts should identify all application components, decide

which are most likely to be of interest, find the location of each component of interest, and

acquire the data.

! Analysts should perform data collection using a standard process. The recommended steps 

are identifying sources of data, developing a plan to acquire the data, acquiring the data, and 

verifying the integrity of the data. The plan should prioritize the data sources, establishing the

order in which the data should be acquired, based on the likely value of the data, the volatility of

the data, and the amount of effort required. Before data collection begins, a decision should be

made by the analyst or management regarding the need to collect and preserve evidence in a

manner that supports its use in future legal or internal disciplinary proceedings. In such

situations, a clearly defined chain of custody should be followed to avoid allegations of

mishandling or tampering of evidence.

! Analysts should act appropriately to preserve volatile OS data. The criteria for determining

whether volatile OS data must be preserved should be documented in advance so that analysts can

make informed decisions as quickly as possible. To determine whether the effort required to

collect volatile OS data is warranted, the risks associated with such collection should be weighed

against the potential for recovering important information.

! Analysts should use a forensic toolkit for collecting volatile OS data. Use of a forensic toolkit 

enables accurate OS data to be collected while minimizing disturbance to the system and

protecting the tools from changes. The analyst should know how each tool is likely to affect or

alter the system during collection of data.

! Analysts should choose the appropriate shutdown method for each system. Each way of

shutting down a particular OS can cause different types of data to be preserved or corrupted; 

analysts should be aware of the typical shutdown behavior of each OS.

! Analysts should preserve and verify file integrity. Using a write-blocker during backups and

imaging prevents a computer from writing to its storage media. The integrity of copied data

should be verified by computing and comparing the message digests of files. Backups and 

images should be accessed as read-only whenever possible; write-blockers can also be used to

prevent writes to the backup or image file or restored backup or image.

A-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

A.2.2

A.2.3

Examination and Analysis

! Analysts should use a methodical approach to studying the data. The foundation of forensics

is using a methodical approach in analyzing the available data so that analysts can either draw

appropriate conclusions based on the available data, or determine that no conclusion can yet be

drawn. If evidence might be needed for legal or internal disciplinary actions, analysts should

carefully document the findings and the steps that were taken.

! Analysts should examine copies of files, not the original files. During the collection phase, the

analyst should make multiple copies of the desired files or filesystems, typically a master copy

and a working copy. The analyst can then work with the working copy of the files without 

affecting the original files or the master copy. A bit stream image should be performed if

evidence may be needed for prosecution or disciplinary actions, or if preserving file times is

important.

! Analysts should consider the fidelity and value of each data source. Analysts should have

more confidence in original data sources than in data sources that receive normalized data from

other sources. Analysts should validate any unusual or unexpected data that is based on

interpreting data, such as IDS and SEM alerts.

! Analysts should rely on file headers, not file extensions, to identify file content types. 

Because users can assign any file extension to a file, analysts should not assume that file

extensions are accurate. Analysts can identify the type of data stored in many files by examining

their file headers. Although people can alter file headers to conceal actual file types, this is much

less common than altering file extensions.

! Analysts should generally focus on the characteristics and impact of the event. Determining

the identity of an attacker and other similar actions are typically time-intensive and difficult to

accomplish, and do not aid the organization in correcting operational issues or security

weaknesses. Establishing the identity and intent of an attacker may be important, especially if a

criminal investigation will ensue, but it should be weighed against other important goals.

! Organizations should be aware of the technical and logistical complexity of analysis. A

single event can generate records on many different data sources and produce more information

than analysts can feasibly review. Tools such as SEM can assist analysts by bringing information

from many data sources together in a single place.

! Analysts should bring together data from various sources. The analyst should review the

results of the examination and analysis of individual data sources, such as data files, OSs, and 

network traffic, and determine how the information fits together, to perform a detailed analysis of

application-related events and event reconstruction.

Reporting

! Analysts should review their processes and practices. Reviews of current and recent forensic

actions can help identify policy shortcomings, procedural errors, and other issues that might need

to be remedied, as well as ensuring that the organization stays current with trends in technology

and changes in law.

A-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix BóScenarios

Tabletop exercises that focus on how forensic tools and techniques can be used in various scenarios

provide an inexpensive and effective way of building and maintaining skills and identifying problems

with guidelines, procedures, and policies. The exercise participants review a brief scenario and are then

asked several questions related to the scenario. The participants discuss each question and formulate an

answer based on what they would really do in the situation. The response is then compared with the

organizationís policies, procedures, and guidelines to identify any discrepancies or deficiencies. For

example, the answer to one question might indicate that forensic actions would be delayed because a

participant lacked a particular piece of software and a particular team within the organization did not 

provide off-hours support.

Section B.1 contains a list of general questions that could be applied to almost any scenario. Section B.2

contains several sample scenarios, some of which are followed by additional scenario-specific questions. 

Organizations are encouraged to adapt these questions and scenarios for use in their own exercises.

B.1

B.2

Scenario Questions

1. What are the potential sources of data?

2. Of the potential sources of data, which are the most likely to contain helpful information and 

why?

3. Which data source would be checked first and why?

4. Which forensic tools and techniques would most likely be used? Which other tools and 

techniques might also be used?

5. Which groups and individuals within the organization would probably be involved in the forensic

activities?

6. What communications with external parties might occur, if any?

7. From a forensic standpoint, what would be done differently if the scenario had occurred on a

different day or at a different time (regular hours versus off-hours)?

8. From a forensic standpoint, what would be done differently if the scenario had occurred at a

different physical location (onsite versus offsite)? 

Scenarios

Scenario 1: Possible DDoS Attack 

On a Saturday afternoon, external users start having problems accessing the organizationís public Web 

sites. Over the next hour, the problem worsens to the point where nearly every attempt to access any of

the organizationís public Web sites fails. Meanwhile, a member of the organizationís networking staff

responds to automatically generated alerts from an Internet border router and determines that much of the

organizationís Internet bandwidth is being consumed by an unusually large volume of User Datagram

Protocol (UDP) packets to and from both of the organizationís public Domain Name System (DNS)

servers. 

B-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

The following are additional questions for this scenario: 

1. How would the forensic activity change if the DDoS attack appeared to be coming from a

network in a different state? In a different country?

2. How would the forensic activity change if the DDoS attack appeared to be coming from a

business partnerís network?

Scenario 2: Online Payment Problems

Over the course of a week, the number of phone calls coming into the organizationís help line for online

bill presentment and payment increases by 400 percent. Most callers complain of having to resubmit

payment information multiple times, and many cannot complete their payment.

The following are additional questions for this scenario: 

1. The problems could have a non-technical cause, such as a lack of clear instructions for new users. 

How should the technical and non-technical aspects of the investigation be coordinated and 

balanced? 

2. How might privacy considerations affect the use of forensic tools and techniques?

3. How would forensic tools and techniques be used if application developers were confident that an

operational problem was causing the issues?

Scenario 3: Unknown Wireless Access Point

On a Monday morning, the organizationís help desk receives calls from five users on the same floor of a

building who state that they are having problems with their wireless access. A network administrator who

is asked to assist in resolving the problem brings a laptop with wireless capability to the usersí floor. As

he views his wireless networking configuration, he notices that there is a new wireless access point listed

as available. Based on the insecure configuration settings transmitted by the access point, the

administrator does not believe that his team deployed it.

The following are additional questions for this scenario: 

1. What types of forensic tools might be used to locate the access point overtly? Covertly?

2. How would the forensic activities change if it was determined that the access point was deployed

for a legitimate business purpose, such as temporary work at the office by a contractor?

3. How would the forensic activities change if it was determined that an unknown individual had

been seen deploying the access point?

Scenario 4: Reinfected Host

During the past 2 weeks, a user has needed to have the same virus removed from a laptop computer twice,

and the user is now reporting similar symptoms again. The technical support staff who handled the

previous infections confirmed that the antivirus software on the computer was enabled and up to date and

were unable to determine how the virus was reinfecting the computer.

The following are additional questions for this scenario: 

B-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

1. What other sources of data might be spotted by visually surveying the userís office?

2. What are the most likely possible data sources outside of the userís office?

3. What legal considerations should the analysts be aware of if they want to examine a data source

that the organization does not own?

Scenario 5: Mistaken Identity

Within the past 24 hours, two employees in the organization have reported fraudulent purchases charged

to their organization-issued credit cards. The organization frequently buys items from the companies that

sold the items in the questioned transactions. A follow-on assessment shows that charges to the

organizationís credit cards across the organization have increased by 30 percent in the past 3 days. 

The following are additional questions for this scenario: 

1. How could forensic tools and techniques help analysts determine what has happened (e.g., that

individual employees in the organization are victims of identity theft, that financial resources 

have been corrupted)? 

2. What privacy concerns should be considered in investigating employeesí financial transactions?

Scenario 6: Unwanted Screen Saver

The organizationís help desk has just received several calls from users who complain that a screen saver

depicting pastoral scenery is activating while they are working at their computers. The screen saver

requires each user to submit his or her password to unlock the screen saver and continue work. At the

same time, the organizationís network intrusion detection systems report several unusual alerts involving

a Web server. The data in the alerts indicates that some suspicious activity was directed at the server, and

the server is now generating similar activity directed at other systems. The intrusion detection analystís 

initial hypothesis is that a worm may have attacked a vulnerable network service on the Web server.

The following are additional questions for this scenario: 

1. Given the time-sensitive nature of this scenario, how should analysts prioritize their actions?

2. How would the use of forensic tools and techniques change if the worm disrupted network

communications?

3. How would the use of forensic tools and techniques change if the infected desktop systems were

used to process sensitive information that the organization is required to safeguard?

Scenario 7: Phishing Attempts

In the past 24 hours, several employees have called the help desk to question the validity of e-mails from

the organizationís official credit card provider. The e-mails cite a possible security breach in the financial

institutionís records and ask recipients to follow a link to the institutionís Web site and create a new

password, after identifying themselves by providing their existing passwords and account information. 

The following are additional questions for this scenario: 

1. Given the time-sensitive nature of this scenario, how should analysts prioritize their actions?

B-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

2. What other organization(s) should be contacted to mitigate potential cases of identity theft?

Scenario 8: Encrypted Files 

An employee leaves an organization unexpectedly, and the employeeís manager is granted access to the

former employeeís desktop computer to retrieve important project information that should be stored on it. 

The manager finds some filenames that appear to be related to the project, but the manager cannot access 

the contents of the files. A system administrator looks at the system and concludes that the former

employee probably encrypted the files.

The following are additional questions for this scenario: 

1. Who should determine how much effort should be put into attempting to recover the encrypted

data? How would this be determined?

2. What changes could be made to the organizationís policies, guidelines, and procedures to reduce

the impact of similar future incidents?

B-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix CóGlossary

Selected terms used in the Guide to Integrating Forensic Techniques into Incident Response are defined

below.

Analysis: The third phase of the computer and network forensic process, which involves using legally 

justifiable methods and techniques, to derive useful information that addresses the questions that were the

impetus for performing the collection and examination.

Anti-Forensic: A technique for concealing or destroying data so that others cannot access it.

Bit Stream Imaging: A bit-for-bit copy of the original media, including free space and slack space. 

Also known as disk imaging.

Cluster: A group of contiguous sectors. 

Collection: The first phase of the computer and network forensics process, which involves identifying,

labeling, recording, and acquiring data from the possible sources of relevant data, while following 

guidelines and procedures that preserve the integrity of the data.

Data: Distinct pieces of digital information that have been formatted in a specific way. 

Digital Forensics: The application of science to the identification, collection, examination, and analysis,

of data while preserving the integrity of the information and maintaining a strict chain of custody for the

data.

Directory: Organizational structures that are used to group files together.

Disk Imaging: Generating a bit-for-bit copy of the original media, including free space and slack space. 

Also known as a bit stream image.

Disk-to-Disk Copy: Copying the contents of media directly to another media.

Disk-to-File Copy: Copying the contents of media to a single logical data file.

Examination: The second phase of the computer and network forensics process, which involves 

forensically processing large amounts of collected data using a combination of automated and manual

methods to assess and extract data of particular interest, while preserving the integrity of the data.

False Negative: Incorrectly classifying malicious activity as benign.

False Positive: Incorrectly classifying benign activity as malicious.

File: A collection of information logically grouped into a single entity and referenced by a unique name,

such as a filename. 

File Allocation Unit: A group of contiguous sectors, also known as a cluster.

File Header: Data within a file that contains identifying information about the file and possibly metadata

with information about the file contents.

C-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Filename: A unique name used to reference a file.

Filesystem: A method for naming, storing, organizing, and accessing files on logical volumes.

Forensic Science: The application of science to the law. 

Forensically Clean: Digital media that is completely wiped of all data, including nonessential and

residual data, scanned for malware, and verified before use.

Free Space: An area on media or within memory that is not allocated.

Logical Backup: A copy of the directories and files of a logical volume.

Logical Volume: A partition or a collection of partitions acting as a single entity that has been formatted

with a filesystem.

Message Digest: A hash that uniquely identifies data. Changing a single bit in the data stream used to

generate the message digest will yield a completely different message digest. 

Metadata: Data about data. For filesystems, metadata is data that provides information about a fileís

contents.

Network Address Translation: The process of mapping addresses on one network to addresses on

another network.

Network Intrusion Detection System: Software that performs packet sniffing and network traffic

analysis to identify suspicious activity and record relevant information.

Network Traffic: Computer network communications that are carried over wired or wireless networks

between hosts.

Non-Volatile Data: Data that persists even after a computer is powered down. 

Normalize: The process by which differently formatted data is converted into a standardized format and 

labeled consistently.

Operating System: A program that runs on a computer and provides a software platform on which other

programs can run.

Packet: The logical unit of network communications produced by the transport layer.

Packet Sniffer: Software that monitors network traffic on wired or wireless networks and captures

packets. 

Partition: A logical portion of a media that functions as though it were physically separate from other

logical portions of the media.

Process: An executing program.

Protocol Analyzer: Software that can reassemble streams from individual packets and decode

communications that use various protocols.

C-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Proxy: Software that receives a request from a client, then sends a request on the clientís behalf to the

desired destination.

Remote Access Server: Devices, such as virtual private network gateways and modem servers, that

facilitate connections between networks. 

Reporting: The final phase of the computer and network forensic process, which involves reporting the

results of the analysis; this may include describing the actions used, explaining how tools and procedures

were selected, determining what other actions need to be performed (e.g., forensic examination of

additional data sources, securing identified vulnerabilities, improving existing security controls), and

providing recommendations for improvement to policies, guidelines, procedures, tools, and other aspects 

of the forensic process. The formality of the reporting step varies greatly depending on the situation.

Sector: The smallest unit that can be accessed on media.

Security Event Management Software: Software that imports security event information from multiple

data sources, normalizes the data, and correlates events among the data sources.

Slack Space: The unused space in a file allocation block or memory page that may hold residual data.

Steganography: Embedding data within other data to conceal it.

Subdirectory: A directory contained within another directory.

Volatile Data: Data on a live system that is lost after a computer is powered down.

Wiping: Overwriting media or portions of media with random or constant values to hinder the collection 

of data.

Write-Blocker: A tool that prevents all computer storage media connected to a computer from being

written to or modified.

C-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

C-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix DóAcronyms

Selected acronyms used in the Guide to Integrating Forensic Techniques into Incident Response are

defined below.

ADS Alternate Data Stream

ARIN American Registry for Internet Numbers

ARP Address Resolution Protocol

ASCII American Standard Code for Information Interchange

ATA Advanced Technology Attachment

BIOS Basic Input/Output System

CCIPS Computer Crime and Intellectual Property Section

CD Compact Disc

CD-R CD-Recordable

CD-ROM CD-Read Only Memory

CD-RW CD-Rewritable

CDFS CD File System

CFI Computer and Financial Investigations

CFRDC Computer Forensics Research and Development Center

CFTT Computer Forensics Tool Testing 

CMOS Complementary Metal Oxide Semiconductor

CVE Common Vulnerabilities and Exposures

DDoS Distributed Denial of Service

DHCP Dynamic Host Configuration Protocol 

DLL Dynamic Link Library

DNS Domain Name System

DoD Department of Defense

DVD Digital Video Disc or Digital Versatile Disc

DVD-R DVD-Recordable

DVD-ROM DVDñRead Only Memory

DVD-RW DVD-Rewritable

ESP Encapsulating Security Payload 

ext2fs Second Extended Filesystem

ext3fs Third Extended Filesystem

FACCI Florida Association of Computer Crime Investigators

FAT File Allocation Table

FBI Federal Bureau of Investigation

FIPS Federal Information Processing Standards

F.I.R.E. Forensic and Incident Response Environment 

FISMA Federal Information Security Management Act

FLETC Federal Law Enforcement Training Center

FTP File Transfer Protocol

GB Gigabyte

GUI Graphical User Interface

D-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

HFS Hierarchical File System

HPA Host Protected Area

HPFS High-Performance File System

HTCIA High Technology Crime Investigation Association

HTTP Hypertext Transfer Protocol

IACIS International Association of Computer Investigative Specialists

ICMP Internet Control Message Protocol

ID Identification

IDE Integrated Drive Electronics

IDS Intrusion Detection System

IGMP Internet Group Management Protocol 

IM Instant Messaging

IMAP Internet Message Access Protocol

IOS Internetwork Operating System

IP Internet Protocol 

IPsec Internet Protocol Security

IR Interagency Report

IRC Internet Relay Chat

IRQ Interrupt Request Line

ISO International Organization for Standardization 

ISP Internet Service Provider

IT Information Technology

ITL Information Technology Laboratory

JPEG Joint Photographic Experts Group

KB Kilobyte

LACNIC Latin American and Caribbean IP Address Regional Registry

MAC Media Access Control

MAC Modification, Access, and Creation

MB Megabyte

MD Message Digest 

MISTI MIS Training Institute

MMC Multimedia Card

MO Magneto Optical 

MS-DOS Microsoft Disk Operating System

NAT Network Address Translation 

NFAT Network Forensic Analysis Tool 

NFS Network File Sharing 

NIC Network Interface Card

NIJ National Institute of Justice

NIST National Institute of Standards and Technology

NLECTC-NE National Law Enforcement and Corrections Technology CenterñNorth East 

NSRL National Software Reference Library

NTFS Windows NT File System

NTI New Technologies Inc.

D-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

NTP Network Time Protocol 

NW3C National White Collar Crime Center

OEM Original Equipment Manufacturer

OMB Office of Management and Budget 

OS Operating System

OSR2 OEM Service Release 2

PCMCIA Personal Computer Memory Card International Association

PDA Personal Digital Assistant 

POP3 Post Office Protocol 3 

RAID Redundant Arrays of Inexpensive Disks

RAM Random Access Memory

RCFL Regional Computer Forensics Laboratory

RFC Request for Comment

RIPE NCC RÈseaux IP EuropÈens Network Coordination Centre

SAM Security Account Manager

SCSI Small Computer System Interface

SD Secure Digital

SDMI Secure Digital Music Initiative

SEM Security Event Management 

SFTP Secure FTP 

SHA-1 Secure Hash Algorithm 1

SIP Session Initiation Protocol 

SMB Server Message Block

SMTP Simple Mail Transfer Protocol 

SNMP Simple Network Management Protocol

SP Special Publication 

SSH Secure Shell

SSL Secure Sockets Layer

TB Terabytes

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol

TUCOFS The Ultimate Collection of Forensic Software

UDF Universal Disk Format

UDP User Datagram Protocol 

UFS UNIX File System

UPS Uninterruptible Power Supply

URL Uniform Resource Locator

USB Universal Serial Bus 

VoIP Voice Over IP

VPN Virtual Private Network 

D-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

D-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix EóPrint Resources

Bejtlich, Richard. The Tao of Network Security Monitoring: Beyond Intrusion Detection. 

Addison-Wesley, 2004.

Carrier, Brian. File System Forensic Analysis. Addison-Wesley, 2005.

Casey, Eoghan. Digital Evidence and Computer Crime. Academic Press, 2004.

Casey, Eoghan. Handbook of Computer Crime Investigation: Forensic Tools & Technology. 

Academic Press, 2001.

Davis, Chris, et al. Hacking Exposed: Computer Forensics Secrets & Solutions. McGraw-Hill

Osborne Media, 2004.

Farmer, Dan, and Wietse Venema. Forensic Discovery. Addison-Wesley, 2004.

Honeynet Project. Know Your Enemy: Learning about Security Threats, Second Edition. 

Addison-Wesley, 2004.

Jones, Keith J., et al. Real Digital Forensics: Computer Security and Incident Response. 

Addison-Wesley, 2005.

Kruse, Warren G., II, and Jay G. Heiser. Computer Forensics: Incident Response Essentials. 

Addison-Wesley, 2001.

Lucas, Julie, and Brian Moeller. The Effective Incident Response Team. Addison-Wesley, 2004.

Orebaugh, Angela. Ethereal Packet Sniffing. Syngress, 2004.

Oseles, Lisa. ìComputer Forensics: The Key to Solving the Crime.î October 2001.

http://faculty.ed.umuc.edu/~meinkej/inss690/oseles_2.pdf. 

Prosise, Chris, et al. Incident Response and Computer Forensics, Second Edition. McGraw-Hill 

Osborne Media, 2003.

Schiffman, Mike, et al. Hackerís Challenge 2: Test Your Network Security & Forensic Skills. 

McGraw-Hill Osborne Media, 2002.

Schweitzer, Douglas. Incident Response: Computer Forensics Toolkit. Wiley, 2003.

Zalewski, Michal. Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect

Attacks. No Starch, 2005.

E-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

E-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix FóOnline Tools and Resources

The following lists provide examples of online tools (particularly free/open source) and resources that

might be helpful in establishing a forensics capability or performing computer and network forensics.

Organizations Supporting Forensics

Organization URL

Computer Crime and Intellectual Property Section (CCIPS), U.S.

Department of Justice

http://www.cybercrime.gov/ 

Federal Bureau of Investigation (FBI) http://www.fbi.gov/ 

Florida Association of Computer Crime Investigators (FACCI) http://www.facci.org/ 

High Technology Crime Investigation Association (HTCIA) http://www.htcia.org/ 

International Association of Computer Investigative Specialists (IACIS) http://www.cops.org/ 

National Law Enforcement and Corrections Technology CenterñNorth

East (NLECTC-NE)

http://www.nlectc.org/nlectcne/ 

National White Collar Crime Center (NW3C) http://www.nw3c.org/ 

Regional Computer Forensics Laboratory (RCFL) http://www.rcfl.gov/ 

SEARCH: National Consortium for Justice Information and Statistics http://www.search.org/ 

Technical Resource Sites

Resource Name URL

Computer Crime Research Center http://www.crime-research.org/ 

Computer Forensics Links (compiled by Dave Dittrich) http://staff.washington.edu/dittrich/ 

Computer Forensics Links and Whitepapers http://www.forensics.nl/links/ 

Computer Forensics Tool Testing (CFTT) Project http://www.cftt.nist.gov/ 

Digital Mountain Technical and Legal Resources http://www.digitalmountain.com/technical_resources 

The Electronic Evidence Information Center http://www.e-evidence.info/ 

Forensic FocusñBillboard and Links http://www.forensicfocus.com/ 

National Institute of Justice (NIJ) Electronic Crime 

Program

http://www.ojp.usdoj.gov/nij/topics/ecrime/welcome.html 

National Software Reference Library (NSRL) http://www.nsrl.nist.gov/ 

Technology Pathways Resource Center http://www.techpathways.com/DesktopDefault.aspx?tabin

dex=8&tabid=14 

Wotsitís Format http://www.wotsit.org/ 

F-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Training Resources

Training Resource Name URL

CompuForensics http://www.compuforensics.com/training.htm 

Computer Forensic Services http://www.computer-forensic.com/training.html

Computer Forensics Training Center

Online

http://www.cftco.com/ 

Federal Law Enforcement Training 

Center (FLETC), Computer & Financial

Investigations (CFI) Division 

http://www.fletc.gov/cfi/index.htm 

Foundstone http://www.foundstone.com/

IACIS http://www.iacis.info/iacisv2/pages/training.php 

InfoSec Institute http://www.infosecinstitute.com/courses/computer_forensics_training.html 

MIS Training Institute (MISTI) http://www.misti.com/

New Technologies Inc. (NTI) http://www.forensics-intl.com/training.html 

NW3C http://www.nw3c.org/ocr/courses_desc.cfm 

SANS Institute http://www.sans.org/

Other Technical Resource Documents

Resource Name URL

Basic Steps in Forensic Analysis of Unix Systems, by

Dave Dittrich 

http://staff.washington.edu/dittrich/misc/forensics/ 

Computer Forensics: Introduction to Incident Response

and Investigation of Windows NT/2000, by Norman

Haase

http://www.sans.org/rr/whitepapers/incident/647.php 

Digital Investigation: The International Journal of Digital

Forensics & Incident Response 

http://www.compseconline.com/digitalinvestigation/ 

Electronic Crime Scene Investigation: A Guide for First

Responders

http://www.ncjrs.gov/

Evidence Seizure Methodology for Computer Forensics, 

by Thomas Rude

http://www.crazytrain.com/seizure.html 

Forensic Analysis of a Live Linux System, by Mariusz

Burdach 

http://www.securityfocus.com/infocus/1769 (part one),

http://www.securityfocus.com/infocus/1773 (part two)

How to Bypass BIOS Passwords http://labmice.techtarget.com/articles/BIOS_hack.htm 

International Journal of Digital Evidence http://www.utica.edu/academic/institutes/ecii/ijde/ 

NIST Interagency Report (IR) 7100, PDA Forensic Tools:

An Overview and Analysis

http://csrc.nist.gov/publications/nistir/index.html 

NIST IR 7250, Cell Phone Forensic Tools: An Overview

and Analysis 

http://csrc.nist.gov/publications/nistir/index.html 

NIST SP 800-31, Intrusion Detection Systems http://csrc.nist.gov/publications/nistpubs/index.html 

NIST SP 800-44, Guidelines on Securing Public Web

Servers

http://csrc.nist.gov/publications/nistpubs/index.html 

NIST SP 800-45, Guidelines on Electronic Mail Security http://csrc.nist.gov/publications/nistpubs/index.html 

NIST SP 800-61, Computer Security Incident Handling 

Guide 

http://csrc.nist.gov/publications/nistpubs/index.html 

NIST SP 800-72, Guidelines on PDA Forensics http://csrc.nist.gov/publications/nistpubs/index.html 

F-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Resource Name URL

NIST SP 800-83, Guide to Malware Incident Prevention 

and Handling 

http://csrc.nist.gov/publications/nistpubs/index.html 

An Overview of Steganography for the Computer

Forensic Examiner, by Gary Kessler

http://www.fbi.gov/hq/lab/fsc/backissu/july2004/research

/2004_03_research01.htm 

RFC 3164: The BSD Syslog Protocol http://www.ietf.org/rfc/rfc3164.txt 

RFC 3227: Guidelines for Evidence Collection and 

Archiving

http://www.ietf.org/rfc/rfc3227.txt

Web Sites with Forensic Software Listings128

Software Type Web Site Name URL

Intrusion detection and 

prevention systems

Honeypots.net http://www.honeypots.net/ids/products/

Network packet sniffers

and protocol analyzers 

Packet Storm http://packetstormsecurity.org/defense/sniff/ 

Network protocol

analyzers 

Softpedia http://www.softpedia.com/get/Network-Tools/ProtocolAnalyzers-Sniffers/

Forensic and Incident

Response Environment

(F.I.R.E.)

http://fire.dmzs.com/?section=tools 

Foundstone http://www.foundstone.com/index.htm?subnav=resources/

navigation.htm&subcontent=/resources/freetools.htm 

Freshmeat http://freshmeat.net/search/?q=forensic§ion=projects 

Helix http://www.e-fense.com/helix/ 

Open Source Digital

Forensics Analysis Tool

Categories 

http://www.opensourceforensics.org/tools/categories.html 

Penguin Sleuth Kit http://www.linux-forensics.com/forensics/pensleuth.html 

Talisker Security Wizardry

Portal

http://www.networkintrusion.co.uk/ 

The Sleuth Kit http://www.sleuthkit.org/sleuthkit/tools.php 

The Ultimate Collection of

Forensic Software

(TUCOFS) 

http://www.tucofs.com/tucofs.htm 

Top 75 Security Tools http://www.insecure.org/tools.html 

Various computer and

network tools 

Trinux http://trinux.sourceforge.net/ 

Checksum Tools http://lists.thedatalist.com/pages/Checksum_Tools.htm 

Computer Forensics Tools,

Software, Utilities

http://www.forensix.org/tools/

Various computer tools 

Funduc Software http://www.funduc.com/ 

Various network tools Common Vulnerabilities and

Exposures (CVE)

http://www.cve.mitre.org/compatible/product.html

 128 The applications referenced in this table are by no means a complete list of applications to use for forensic purposes, nor 

does this publication imply any endorsement of certain products.

F-3
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

This page has been left blank intentionally.

F-4
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Appendix GóIndex

Data storage, 6-10 

Degaussing, 4-10 A Directory, 4-3, 4-13, 5-7, C-1 

Access control, 3-6 Disk imaging, C-1

A Disk-to-disk copy, 4-6, C-1 lternate Data Streams, 4-5, 4-10 

Analys Disk-to-file copy, 4-6, C-1 is, 1, 2-2, 3-1, 3-6, 4-14, 6-11, 7-9, C-1 

An Documentation, 3-4, 4-6, 5-9 ti-forensic, 2-6, 3-3, C-1 

Appl Domain name, 6-3 ication, 7-1 

C Dynamic Host Configuration Protocol, 6-8, 6-14 lient/server, 7-4 

Document, 7-8 

Local, 7-4 E

Peer-to-peer, 7-4 

Security, 7-8 E-mail, 7-5 

Application architecture, 7-4 Header, 7-5 

Application configuration setting, 7-1 Encryption, 3-6, 4-11, 6-10, 7-8, 7-9 

Application data, 7-3 Evidence, 2, 2-8, 3-1, 3-4, 4-6, 5-5, 6-9, 6-10 

Application supporting files, 7-3 Custodian, 3-4

Attacker identification, 6-17 Handling supplies, 3-4 

Audio, 7-7 Examination, 1, 2-2, 3-1, 3-6, 4-10, 5-11, 6-11, 7-9, C-1 

Auditing, 2-6, 3-2, 4-7 Exercises, 2-4 

Auditors, 2-5 

Authentication, 5-10, 7-2 F

B False negative, 6-13, C-1 

False positive, 6-13, C-1 

Backups, 2-6 File, 4-1, C-1 

Basic Input/Output System, 5-3, 5-10 Application, 5-2 

Bit stream imaging, 4-6, 4-8, 4-9, 4-10, C-1 Capture, 6-6 

Block, 4-3 Configuration, 5-1 

Data, 5-2 

Deleted, 4-4, 4-11 C Dump, 5-3 

Chain Hibernation, 5-3 of custody, 2-8, 3-4, 4-7 

C Hidden, 4-11 luster, 4-3, C-1 

Code, Open, 5-4, 5-7, 5-8 7-1 

Co Swap, 5-2, 5-11 llection, 1, 2-2, 3-1, 3-2, 4-5, 5-4, 6-9, 7-9, C-1 

Comp Temporary, 5-3 ression, 3-6, 4-13 

Compu File allocation unit, 4-3, C-1 ter Forensics Tool Testing, 4-7

Co File extension, 4-11 st, 2-3 

Cove File hash, 2-6, 4-14 rt channel, 6-15 

File header, 4-11, C-1 

File integrity, 4-7 D Checker, 5-11 

File sharing, 7-7 Data, 1, 2-1, C-1 

File type, 3-6, 4-11 Concealment tool. See Tool, Data concealment

File viewer, 4-13 Hidden, 4-10 

Filename, 4-1, C-2 Non-volatile, 3-3, 5-1, 5-4, 5-8, C-2 

Filesystem, 4-1, 4-3, 5-1, 5-9, 7-9, C-2 Sensitive, 2-4, 3-5, 6-9 

Memory, 5-1 Volatile, 3-3, 5-3, 5-4, 5-8, 7-9, C-3 

Recoverable, 4-3 Data acquisition, 2-2

Firewall, 6-5, 6-14 Data fidelity, 6-12

Forensic process, 2-2, 3-1 Data integrity, 3-4

Forensic science, 2-1, C-2 Data recovery, 2-2 

Forensics, 1 Data retention, 3-7 

Digital, 1, 2-1, C-1 Data source, 2-1, 3-2, 6-12, 8-1 

Free space, 4-5, 4-9, 4-11, 5-3, C-2 Identification, 3-2

G-1
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

G N

Group chat, 7-7 National Software Reference Library, 4-14 

Guidelines, 2, 2-7, 3-7, 4-7 Network access, 3-5 

Network address translation, 6-5, C-2 

Network configuration, 5-4, 5-6, 5-8, 6-9 H Network connection, 5-4, 5-6, 5-8, 6-9 

Ha Network forensic analysis tool, 6-8, 6-11, 6-12, 6-14, 6-16 rd drive, 5-11 

Hex edi Network intrusion detection system, 6-6, C-2 tor, 5-11 

Ho Network monitoring, 6-8, 6-15 st intrusion detection system, 5-11, 6-6 

Ho Network share, 5-10 st Protected Area, 4-10

Human resources, 2-5 Network Time Protocol, 4-15

Network traffic, 6-1, 7-9, C-2 

Normalize, 6-7, C-2 I

Incident handling. See Incident response O

Incident response, 2-1, 2-3, 2-4, 3-5, 3-7 

Containmen Office of Inspector General, 2-3, 2-5 t, 3-5 

Exe Operating system, 5-1, C-2 rcises, B-1

Information system life cycle, 2-6 Outsourcing, 2-3

Instant messaging, 7-7

Internet Control Message Protocol, 6-3 P

Internet Protocol, 6-3

Internet service provider, 3-2, 6-9, 6-10, 6-15, 6-18 Packet, 6-2, C-2 

Intrusion detection system, 6-6, 6-11, 6-12, 6-14 Packet header, 6-2 

Investigation, 2-1, 2-3, 2-4 Packet sniffer, 6-5, 6-14, C-2 

IT professional, 2-3 Partition, 4-3, C-2 

Password, 5-9, 7-9 

Basic Input/Output System, 4-12, 5-10 J Hard drive, 4-13 

Ju Password cracking, 4-12 risdictional conflict, 2-5

Password files, 5-2

Password protection, 4-11, 4-12, 5-10 K Photography, 3-4, 5-9 

Physical security, 2-5, 3-5 Key remapping, 5-11 

Policy, 2, 2-5, 2-6, 3-3, 3-7, 4-7 

Data retention, 2-7, 6-9 

L Port number, 6-2, 6-10 

Portable digital devices, 3-2, 4-1, 5-1 Law enforcement, 2, 2-8, 3-5, 3-7 Preparation, 2, 3-4 Layer Prioritization, 3-4, 5-7 Application, 6-1 Privacy, 2-5, 6-9, 6-10 Data link, 6-1 Procedures, 2, 2-6, 2-7, 3-7, 4-7 Network, 6-1 Process, 5-4, 5-7, 5-8, 5-11, C-2 Transport, 6-1 Protocol analyzer, 6-6, 6-15, C-2 Legal advisors, 2-5, 3-5 Proxy, 6-5, 6-14, C-3 Log, 5-2, 5-10, 5-11, 6-7, 6-10, 6-15, 7-2 

Management, 3-3 

Monitoring, 2-2 R

Logical backup, 4-6, 4-8, 4-9, 4-10, C-2 

Redundant Array of Inexpensive Disks, 4-10 Login session, 5-4, 5-7, 5-8 

Remote access server, 6-7, 6-14, C-3 

Reporting, 1, 2-2, 3-1, 3-6, C-3 

M Roles and responsibilities, 2-5

Router, 6-5, 6-14 Management, 2-5 

Media, 3-1, 3-2, 4-1, 4-2, 4-7, 5-1 

Destruction, 4-10 S

Media Access Control, 6-4 

M Searching, 3-6, 6-8 emory, 5-3, 5-6, 5-8, 5-11 

M Pattern matching, 4-14 essage digest, 3-4, 4-8, 5-7, 5-11, C-2 

M String, 4-14, 5-7 etadata, 4-9, 4-14, C-2 

M Sector, 4-3, C-3 onitoring, 2, 2-5, 3-3, 6-9, 6-11 

G-2
GUIDE TO INTEGRATING FORENSIC TECHNIQUES INTO INCIDENT RESPONSE

Security event management software, 6-7, 6-11, 6-12, 6-14,

C-3

Service, 6-10 

Shutdown methods, 5-8 

Skills, B-1

Slack space, 4-5, 4-9, 4-11, 5-3, C-3 

Spoofing, 6-14, 6-17 

Staffing, 2-3 

Steganography, 4-11, 4-12, 7-8, C-3 

Subdirectory, 4-3, C-3 

T

Text editor, 5-7 

Time, 4-14 

Entry modified, 4-9 

Modification, access, and creation, 4-9, 4-15 

Operating system, 5-4, 5-7, 5-8 

Preservation, 4-9 

Synchronization, 4-15 

Tool, 2-6, 3-4, 5-5, 5-11 

Anti-forensic, 2-6 

Data concealment, 7-8 

Examination, 6-15 

Toolkit, 4-13, 5-6, 5-7 

Training, 2-3, 2-5, 3-7 

Transmission Control Protocol, 6-2

Transmission Control Protocol/Internet Protocol, 6-1

Troubleshooting, 2-1 

U

User Datagram Protocol, 6-3

V

Video, 7-7 

Virtual private network, 6-10 

Visualization tool, 6-15 

Voice over IP, 7-7 

Volume, 4-3 

Logical, 4-3, C-2 

W

Web, 7-6 

Wiping, 4-9, C-3 

Write-blocker, 4-7, 4-11, 4-15, C-3 

G-3