Fundamentals in Computer Investigations - General Digital Forensics
Fundamentals in Computer Investigations - General Digital Forensics
The four investigation phases and accompanying processes in the figure should be
applied when working with digital evidence. The phases can be summarized as follows:
2 Fundamental Computer Investigation Guide For Windows
Assess the situation. Analyze the scope of the investigation and the action to be
taken.
Acquire the data. Gather, protect, and preserve the original evidence.
Analyze the data. Examine and correlate digital evidence with events of interest that
will help you make a case.
Report the investigation. Gather and organize collected information and write the
final report.
Detailed information about each of the phases is provided in the chapters of this guide.
You should determine whether or not to involve law enforcement with the assistance of
legal advisors. If you determine that law enforcement is needed, then you need to
continue the internal investigation unless law enforcement officials advise you otherwise.
Law enforcement might not be available to assist in the investigation of the incident, so
you must continue to manage the incident and investigation for later submission to law
enforcement.
Depending on the type of incident being investigated, the primary concern should be to
prevent further damage to the organization by those person(s) who caused the incident.
The investigation is important, but is secondary to protecting the organization unless
there are national security issues.
If law enforcement is not involved, your organization may have existing standard
operating procedures and policies that guide the investigation process. Refer to the
"Reporting Computer-Related Crimes" section in Appendix: Resources in this guide for
types of crimes that need to be reported to law enforcement.
Overview 3
Chapter Summary
This guide is comprised of five chapters and an appendix, which are briefly described in
the following list. The first four chapters provide information about the four phases of the
internal investigation process:
Chapter 1: Assess the Situation explains how to conduct a thorough assessment of
the situation and prepare for the internal investigation.
Chapter 2: Acquire the Data provides guidance about how to gather digital evidence.
Chapter 3: Analyze the Data examines the standard techniques of evidence analysis.
Chapter 4: Report the Investigation explains how to write the investigation outcome
report.
Chapter 5: Applied Scenario Example describes a fictional scenario that depicts
unauthorized access to confidential information.
Appendix: Resources includes information about how to prepare for a computer
investigation, contact information for reporting computer-related crimes and obtaining
computer investigation training, worksheets that can be used in computer
investigations, and lists of certain computer investigation tools.
Audience
This guide is intended for IT professionals in the United States who need a general
understanding of computer investigations, including many of the procedures that can be
used in such investigations and protocols for reporting incidents.
Style Conventions
This guidance uses the style conventions that are described in the following table.
Element Meaning
Depending on the scope of the incident and absent any national security issues or
life safety issues, the first priority is to protect the organization from further harm.
After the organization is secure, restoration of services (if needed) and the
investigation of the incident are the next priorities.
Decisions you make may be questioned as much as the evidence. Because computer
evidence is complex, different investigations (such as those conducted by an opposing
party) may make different decisions and reach different conclusions.
Use tools to examine the state of software applications and operating systems on
computers that are likely affected. Useful tools for this task include the Windows
application logs, system logs, and Windows Sysinternals PsTools.
Examine affected file and application servers. Use Windows Sysinternals tools such
as PsTools, PsFile, ShareEnum and internal Windows security logs to examine and
document activity on these servers.
Important Some of the information gathered during this assessment (such as running
processes and data in memory) is captured by your tools in real time. You must ensure that any
records or logs generated are securely stored to prevent losing this volatile data.
Chapter 1: Assess the Situation 9
In addition, the following best practices can help you obtain a complete understanding of
the situation.
Build a timeline and map everything to it. A timeline is especially important for global
incidents. Document any discrepancies between the date and time of hosts, such as
desktop computers, and the system date and time, such as the Windows Time
service in Windows Server 2003.
Identify and interview anyone who might be involved in the incident, such as system
administrators and users. In some situations, such people might be external to the
organization. Interviewing users and affected personnel often provides good results
and insights into the situation. Interviews should be conducted by experienced
interviewers.
Document all interview outcomes. You will need to use them later to fully understand
the situation.
Retrieve information (logs) from internal and external facing network devices, such as
firewalls and routers, which might be used in the possible attack path.
Some information, such as IP address and domain name ownership, is often public
by its nature. For example, you can use the Windows Sysinternals Whois tool or the
American Registry for Internet Numbers to identify an owner of an IP address.
Important When using tools to collect data, it is important to first determine whether or not a
rootkit has been installed. Rootkits are software components that take complete control of a
computer and conceal their existence from standard diagnostic tools. Because rootkits operate at
a very low hardware level, they can intercept and modify system calls. You cannot find a rootkit
by searching for its executable, because the rootkit removes itself from the list of returned search
results. Port scans do not reveal that the ports the rootkit uses are open, because the rootkit
prevents the scanner from detecting the open port. Therefore, it is difficult to ensure that no
rootkits exist. One available tool you can use is the Microsoft® Windows® Sysinternals
RootkitRevealer.
When acquiring data over a network, you need to consider the type of data to be
collected and the amount of effort to use. Consider what data you need to obtain that
would support the prosecution of the offending parties. For example, it might be
necessary to acquire data from several computers through different network connections,
or it might be sufficient to copy a logical volume from just one computer.
The recommended data acquisition process is as follows:
1. Create accurate documentation that will later allow you to identify and authenticate
the evidence you collect. Ensure that you note any items of potential interest and log
any activities that might be of importance later in the investigation. Key to a
successful investigation is proper documentation, including information such as the
following:
Who performed the action and why they did it. What were they attempting to
accomplish?
How they performed the action, including the tools they used and the procedures
they followed.
When they performed the action (date and time) and the results.
2. Determine which investigation methods to use. Typically, a combination of offline and
online investigations is used.
In offline investigations, additional analysis is performed on a bit-wise copy of the
original evidence. (A bit-wise copy is a complete copy of all the data from the
targeted source, including information such as the boot sector, partition, and
unallocated disk space.) You should use the offline investigation method
whenever possible because it mitigates the risk of damaging the original
evidence. However, this method is only suitable for situations in which an image
can be created, so it cannot be used to gather some volatile data.
In an online investigation, analysis is performed on the original live evidence. You
should be especially careful when performing online analysis of data because of
the risk of altering evidence that might be required to prove a case.
3. Identify and document potential sources of data, including the following:
Servers. Server information includes server role, logs (such as event logs), files,
and applications.
Logs from internal and external facing network devices, such as firewalls,
routers, proxy servers, network access servers (NAS), and intrusion detection
systems (IDS) that may be used in the possible attack path.
Internal hardware components, such as network adapters (which include media
access control (MAC) address information) and PCMCIA cards. Also note
external port types, such as Firewire, USB, and PCMCIA.
Chapter 2: Acquire the Data 13
Storage devices that need to be acquired (internal and external), including hard
disks, network storage devices, and removable media. Don’t forget portable
mobile devices such as PocketPC, Smartphone devices, and MP3 players such
as Zune™.
4. When you must capture volatile data, carefully consider the order in which you collect
the data. Volatile evidence can be easily destroyed. Information such as running
processes, data loaded into memory, routing tables, and temporary files can be lost
forever when the computer is shut down. Information about tools and commands that
can help gather this information is available in the "Tools" section of Appendix:
Resources in this guide.
5. Use the following methods to collect data from storage media and record storage
media configuration information:
If you need to remove any internal storage devices, turn off the computer first.
However, before you turn off the computer you should verify that all volatile data
has been captured whenever possible.
Determine whether to remove the storage device from the suspect computer and
use your own system to acquire the data. It may not be possible to remove the
storage device because of hardware considerations and incompatibilities.
Typically, you would not disconnect storage devices such as RAID devices,
storage devices with a hardware dependency (for example, legacy equipment),
or devices in network storage systems such as storage area networks (SANs).
Create a bit-wise copy of the evidence in a backup destination, ensuring that the
original data is write-protected. Subsequent data analysis should be performed
on this copy and not on the original evidence. Step-by-step guidance for imaging
is beyond the scope of this guide but is an integral part of evidence collection.
Important Use industry accepted tools when acquiring a bit-wise copy. For example,
EnCase by Guidance Software or FTK by AccessData.
Document internal storage devices and ensure that you include information about
their configurations. For example, note the manufacturer and model, jumper
settings, and the size of the device. In addition, note the type of interface and the
condition of the drive.
6. Verify the data you collect. Create checksums and digital signatures when possible to
help establish that the copied data is identical to the original. In certain circumstances
(for example, when a bad sector exists on the storage media) it may be impossible to
create a perfect copy. Ensure that you have obtained the best copy possible with the
available tools and resources. You can use the Microsoft File Checksum Integrity
Verifier (FCIV) tool to compute an MD5 or SHA1 cryptographic hash of the content of
a file.
Ensure that no unauthorized personnel has access to the evidence, over the network
or otherwise. Document who has physical and network access to the information.
Protect storage equipment from magnetic fields. Use static control storage solutions
to protect storage equipment from static electricity.
Make at least two copies of the evidence you collected, and store one copy in a
secure offsite location.
Ensure that the evidence is physically secured (for example, by placing the evidence
in a safe) as well as digitally secured (for example, by assigning a password to the
storage media).
Clearly document the chain of custody of the evidence. Create a check-in / check-out
list that includes information such as the name of the person examining the evidence,
the exact date and time they check out the evidence, and the exact date and time
they return it. A sample Worksheet - Chain of Custody Log Documentation
document is included with the worksheets referenced in Appendix: Resources in this
guide.
Chapter 3: Analyze the Data
This chapter discusses different approaches and well-accepted industry best practices for
analyzing the evidence that is gathered during the Acquire the Data phase of an internal
investigation. Use the three-step process shown in the following figure.
Important Online analysis of data, which examines a computer directly while it is running, is
often necessary. Online analysis is typically performed because of time constraints on an
investigation or to capture volatile data. You should be especially careful when performing online
analysis to ensure that you minimize the risk to other evidence.
the connection and whether a suspected party established a session with a specific
server.
information about EFS see "The Encrypting File System" on Microsoft TechNet.
External EFS recovery tools are also available, such as Advanced EFS Data
Recovery by Elcomsoft.
3. If necessary, uncompress any compressed files and archives. Although most forensic
software can read compressed files from a disk image, you might need to
uncompress archive files to examine all files on the media you are analyzing.
4. Create a diagram of the directory structure. It might be useful to graphically represent
the structure of the directories and files on the storage media to effectively analyze
the files.
5. Identify files of interest. If you know which files were affected by the security incident,
you can focus the investigation on these files first. The hash sets created by the
National Software Reference Library can be used to compare well-known files (such
as operating system and application files) to the originals. Those files that match can
normally be eliminated from the investigation. You can also use informational sites
such as filespecs.com, Wotsit's Format, ProcessLibrary.com, and Microsoft DLL Help
to help you categorize and collect information about existing file formats as well as to
identify files.
6. Examine the registry, the database that contains Windows configuration information,
for information about the computer boot process, installed applications (including
those loaded during startup), and login information such as username and logon
domain. For registry background information and detailed descriptions of registry
content, see the Windows Server 2003 Resource Kit Registry Reference. Various
tools are available for analyzing the registry, including RegEdit, which ships with the
Windows operating system, Windows Sysinternals RegMon for Windows, and
Registry Viewer by AccessData.
7. Search the contents of all gathered files to help identify files that may be of interest.
Various intelligent searches can be performed using tools described in the "Tools"
section in Appendix: Resources of this guide. For example, you can use the Windows
Sysinternals Streams tool to reveal whether there are any NTFS alternate data
streams used on files or folders. NTFS alternate data streams can hide information
within a file by causing it to appear to contain zero bytes of data when viewed
through Windows Explorer although the file actually contains hidden data.
8. Study the metadata of files of interest, using tools such as Encase by Guidance
Software, The Forensic Toolkit (FTK) by AccessData, or ProDiscover by Technology
Pathways. File attributes such as timestamps can show the creation, last access, and
last written times, which can often be helpful when investigating an incident.
9. Use file viewers to view the content of the identified files, which allow you to scan and
preview certain files without the original application that created them. This approach
protects files from accidental damage, and is often more cost effective than using the
native application. Note that file viewers are specific to each type of file; if a viewer is
not available, use the native application to examine the file.
After you analyze all of the available information, you may be able to reach a conclusion.
However, it is important to be very cautious at this stage and ensure that you do not
blame the wrong party for any damages. However, if you are certain of your findings, you
will be ready to begin the Report the Investigation phase.
Chapter 4: Report the Investigation
This chapter discusses how to organize the information that you gather and the
documentation that you create throughout a computer investigation, as well as how to
write a final report. Use the two-step process shown in the following figure.
operational and security-related procedures. You should review your existing operational and
incident response documentation and incorporate the knowledge you gain during an
investigation. If you do not have such documentation or wish to adopt an industry standard
format, you can use the Microsoft® Operations Framework (MOF) documentation templates and
guidance. For more information about MOF visit the Microsoft Operations Framework home page.
Chapter 5: Applied Scenario Example
This scenario depicts unauthorized access to internal confidential information within a
national financial institution—Woodgrove Bank. The scenario is fictional, as are the
people and the organizations mentioned in the scenario.
The scenario was designed to provide an overview of tools and technologies used for
data collection and examination. In a real security breach situation, you should consult
with appropriate management, legal, and law enforcement groups for advice about the
appropriate investigative techniques to use. Also, although the authors recognize that
imaging a suspect drive is important in investigative work, it is beyond the scope of this
guide and only briefly mentioned during the data acquisition phase of the scenario.
Scenario
It has been brought to the attention of Ray Chow, the Enterprise Systems Administrator
of Woodgrove National Bank, that someone was bragging about knowing the salary of
many different bank employees. Ray learned the name of the employee who claimed to
know this information—Mike Danseglio. Mike works in the loan department and should
not have access to any Human Resources (HR) files.
Woodgrove National Bank has a policy that relates to the proper use of bank computers.
This policy states that there is no expectation of privacy when using company computers
for any purpose, including e-mail services and access to Web sites. The policy also
states that no programs will be loaded on any computers without the written permission
of the IT Director, and that any attempts to circumvent passwords or obtain unauthorized
access to bank files will be grounds for termination or legal prosecution. The policy also
allows the IT staff to install any network monitoring devices, including sniffers or other
packet capture devices, to maintain network security or to investigate possible abuses.
Ray wants to ensure that he uses accepted computer investigation procedures to
investigate this issue and report his findings. Ray believes that information might have
been originally obtained from the HR file server and plans to follow the four-phase
computer investigation model shown in the following figure:
Important See the "Applied Scenario Lab Configuration" section at the end of this chapter for
information about how to emulate this scenario and follow along using the tools.
Ray then considers different options for proceeding with the investigation. Because some
of the information he needs to acquire is volatile data, Ray decides to begin the internal
computer investigation by analyzing live data. He will then make an image of Mike
Danseglio’s drive and examine the static evidence.
Ray creates a USB drive that includes the appropriate investigative tools for a live
investigation. (The "Tools" section in Appendix: Resources in this guide describes the
tools that are referenced in this chapter.)
Ray's next task is to duplicate the suspected party's hard disk in a way that protects and
preserves the evidence if he locates information that requires him to report the case to
law enforcement.
Chapter 5: Applied Scenario Example 25
Ray notes items of potential interest, documents what is needed to be able to identify and
authenticate the collected evidence later in the investigation, and creates an audit log of
actions performed during the investigation.
Figure 5.3. Security event log entries that indicate user account mdanseglio
accessed the 090806PR-A139.xls file in the HR\Internal\Payroll folder
First, Ray creates new \evidence and \tools folders on the USB drive. To ensure the
integrity of the evidence files he creates, Ray will perform an MD-5 cryptographic hash on
any files he copies from Mike’s computer to the evidence folder.
MD-5 cryptographic hashes are created by running an algorithm on a file to create a
unique 128-bit “fingerprint” of the contents of the file. If someone questions the integrity of
the data collected by Ray (for example, to imply the file may have been edited at a later
time), Ray can provide the original MD-5 checksum value for comparison and validation.
Ray exports the log set to a USB drive that is labeled HR01. He will use this same USB
drive for all his evidence collection.
Note Connecting a USB drive to a Windows–based computer adds an entry to the Setupapi.log
file and alters the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\Storage\RemovableMedia
Ray decides to determine what permissions are assigned to the HR\Internal folder by
running the Windows Sysinternals AccessChk tool on the server. This tool shows what
permissions the specified user or group has to files, registry keys, or Windows services.
Ray runs the tool from his USB drive, which appears as drive F:, by typing the following
at a command prompt:
f:\tools>accesschk mdanseglio c:\hr\internal
Chapter 5: Applied Scenario Example 27
Note The Sysinternals AccessChk tool requires an installation process and will leave a footprint
on the local drive in the following registry key:
HKEY_CURRENT_USER\Software\Sysinternals\AccessChk
Ray notes that the mdanseglio user account has read and write permissions to the
\Benefits, \Payroll, and \Reviews subfolders under \HR\Internal as shown in the following
screen shot:
Figure 5.4. AccessChk results that indicate user account mdanseglio has read and
write permissions to the HR\Internal subfolders
Ray suspects that errors in the configuration of the HR server permissions allowed Mike
Danseglio to access the HR\Internal folder. Ray spends a few minutes investigating Mike
Danseglio’s user rights and notices that he is a member of a group called branch01mgrs.
This group has read and write permissions to the HR\Internal folders.
Ray wants to know whether Mike Danseglio is currently logged on to any servers on the
network. Ray uses PsLoggedOn, a tool that displays locally logged on users as well as
users who are logged on through resources to either the local computer or a remote one.
Ray inserts his USB stick into his computer and types the following at the command
prompt:
f:\tools>psloggedon mdanseglio
The results, shown in the following screen shot, indicate that Mike Danseglio is logged
onto WNB-HQ-FS1 at this time.
Figure 5.5. Psloggedon results indicating that user account mdanseglio is logged
on to WNB-HQ-FS1
Ray removes Mike Danseglio from the branch01mgrs group and rechecks his user rights
to the HR\Internal folder.
After further review of the Security event logs and the results of AccessChk to look for
other possible incorrect permission configurations to the HR\Internal folder, Ray begins
investigating the contents of Mike Danseglio’s computer using remote investigative
techniques.
28 Fundamental Computer Investigation Guide For Windows
Note PsExec gathers information remotely by using services that are already on the target
computer, such as Cmd and Ipconfig. PsExec can also be used to load services across the
network to run on the target computer. Ray does not want to install any applications on
Mike’s computer—he only runs services that are supported by the Windows XP operating
system on Mike's computer.
4. Run remote tools that use local application programming interfaces (APIs).
Ray now runs several tools to determine whether other computers have files open on
Mike’s computer, the processes that are running on the computer, and to obtain the
System and Security event logs from the computer.
psfile \\hqloan164 >> j:\evidence\mdevidence.txt
pslist -t \\hqloan164 >> j:\evidence\mdevidence.txt
psloglist -s \\hqloan164 >> j:\evidence\mdevidence.txt
psloglist -s sec \\hqloan164 >> j:\evidence\mdevidence.txt
PsFile shows files opened remotely. This tool uses remote Windows APIs and
does not need to be loaded on the target computer.
PsList shows information about running processes and threads on a computer.
This tool uses remote Windows APIs and does not need to be loaded on the
target computer.
PsLogList dumps the contents of the computer's Event log by default—no
additional parameter is needed. Ray runs this command with the sec parameter
to obtain the Security event log.
5. Create a record of all tasks.
Windows automatically tracks all the commands that are executed at a command
prompt. Ray uses the Doskey command to capture this record and pipes the history
information into a file called mdevidence-doskey.txt.
doskey /h > j:\evidence\mdevidence-doskey.txt
Notes Display limitations might cause the preceding command to display on more than one
line. It should be entered as a single line at the command prompt.
The FCIV tool computes and verifies cryptographic hash values. This tool is available through
Microsoft Knowledge Base article 841290, "Availability and description of the File Checksum
Integrity Verifier utility."
30 Fundamental Computer Investigation Guide For Windows
Ray wants to remotely review the folders on Mike Danseglio’s computer. To do so, he
uses PsExec to open a command prompt on Mike's computer. At the command prompt,
Ray enters the following commands:
psexec \\hqloan164 cmd
cd c:\documents and settings\mdanseglio\my documents
dir /s
Although all users are required to keep documents on the network server, Ray notices
that Mike Danseglio has a Personal folder on his computer. This folder includes a
spreadsheet and a \xxxpixset subfolder.
After remotely reviewing the folders on Mike's computer, Ray is ready to report his
findings and move to Mike’s computer to investigate locally.
Jill Shrader, the HR Department Manager, calls Ray on his cell phone and asks about the
status of Ray’s investigation. Ray explains that he has collected the following information:
Mike Danseglio's user account had read and write permissions to the HR\Internal
folder because he was mistakenly added to the branch01mgrs group, which has
permissions to that folder and its subfolders.
Mike's computer has a Personal folder on its hard disk that contains at least one
spreadsheet.
Mike's computer contains two unauthorized programs that enable him to monitor
network traffic and scan the network for services and computers.
Mike's computer has a large collection of image files on its hard disk that Ray
suspects are pornographic images.
Ray uses the Xcopy command with the /s parameter to copy subfolders, the /e
parameter to copy subfolders even if they are empty, the /k parameter to retain the
read-only attribute on destination files if present on the source files, and the /v
parameter to verify each file as it is written to the destination file to make sure that the
destination files are identical to the source files.
f:
md evidence_files
c:
cd \documents and settings\mdanseglio\my documents\personal
xcopy *.* f:\evidence_files /s /e /k /v
Note Display limitations might cause the preceding command to display on more than one
line. It should be entered as a single line at the command prompt.
Chapter 5: Applied Scenario Example 35
4. Ray first copies 090806PR-A139.xls to the \evidence_files folder and then uses the
Strings tool to list ASCII and Unicode strings contained in the spreadsheet file.
strings j:\evidence_files\090806PR-A139.xls
The results (shown in the following screen shot) indicate that the spreadsheet file
contains payroll information. Ray runs the Strings tool again and pipes the results into
his mdevidence-review.txt file.
strings j:\evidence_files\090806PR-A139.XLS >>
j:\evidence\mdevidence-review.txt
Note Display limitations might cause the preceding command to display on more than one
line. It should be entered as a single line at the command prompt.
36 Fundamental Computer Investigation Guide For Windows
Figure 5.10. Results of running the Strings utility on the spreadsheet file
Ray feels confident that he has located an unauthorized copy of an HR payroll file on
Mike Danseglio’s computer.
Analysis. This section includes the results of the local and remote investigations,
which prove that sexually explicit images were downloaded, permissions were
incorrectly configured, and a confidential file that contains payroll information was
accessed.
Conclusion. This section summarizes the outcome of the investigation and includes
recommendations to avoid similar incidents in the future.
Supporting documents. This section includes network diagrams and a list of the
computer investigation procedures and technologies used in the investigation.
After submitting his report, Ray waits for the authorization to perform additional
investigatory steps or whatever other actions management might want him to perform.
Note Every investigation may be different. You should use tools that are appropriate for the
required task and that help you obtain the information you seek, but it is always a good idea to
gather more evidence than you might need.
After you install the operating system on each computer, run Dcpromo on WNB-HQ-DC
to install Active Directory and DNS.
Table 5.2. Groups and Users Referenced in the Applied Scenario Lab
Groups Users
Enterprise System Administrator Ray Chow
Domain Admins Ray Chow
HR MGRS Jenny Gottfried, Roland Winkler, Jill Shrader
Branch01Mgrs Mike Danseglio, Nuria Gonzalez
On the file server WNB-HQ-FS1, the Domain Admins group is added as a member of the
local Administrators group.
Configure Auditing
On the domain controller WNB-HQ-DC, the Audit object access policy is configured to
audit both Success and Failure. This configuration is set through the Domain Security
Policy MMC and the Domain Controller Security Policy MMC.
On the file server WNB-HQ-FS1, auditing is configured for the Domain Users group on
the \HR\Internal folder. To achieve this configuration, right-click the folder and select
Properties, Security, Advanced, and then Auditing. Then enter the Domain Users
group.
Appendix: Resources
This appendix provides information about various resources that you can use to conduct
a computer investigation.
Data acquisition tools are shown to be accurate. Proving accuracy is generally easier
if you use well-known computer forensics software.
The tools do not modify the access time of files.
The examiner's storage device is forensically sterile, which means the disk drive
does not contain any data, before it is used. You can determine whether a storage
device is forensically sterile by running a checksum on the device. If the checksum
returns all zeros, it does not contain any data.
The examiner's hardware and tools are used only for the computer investigation
process and not other tasks.
You should first consult with your legal advisors to determine whether it is necessary to
report specific computer-related crimes to appropriate authorities at the local, state,
federal, or international level, depending on the scope of the crime. Most likely, your local
or state authorities would be the first ones to contact. If it is a computer-related federal
crime, then you might need to report the crime to local offices of federal law enforcement.
As noted earlier, this guidance is only intended for use in the United States.
Appendix: Resources 43
United States law enforcement agencies that investigate Internet-related crime include
the following:
Federal Bureau of Investigation (FBI)
United States Secret Service (USSS)
U.S. Immigration and Customs Enforcement (ICE)
U.S. Postal Inspection Service
Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF)
U.S. Drug Enforcement Administration (DEA)
These agencies have offices throughout the United States, and contact information is
available in local telephone directories or through Internet searches. Generally, federal
crimes can be reported by telephoning the local office of an appropriate law enforcement
agency and requesting the Duty Complaint Agent. If the organization has joined the
Electronic Crimes Task Force (ECTF), InfraGard, or the International High Technology
Crime Investigation Association (HTCIA), then the appropriate contact person may
already be known. Contacting someone who is known and knows your organization
simplifies the reporting process.
Many agencies have trained agents who specialize in computer hacker cases.
Training
Have at least some incident response team members attend formal computer
investigation training. Without relevant training, it is unlikely that the team will be effective
in the investigation. In fact, unskilled examiners could negatively affect the investigation
by accidentally destroying volatile evidence.
For a list of nonprofit agencies, organizations, Federal law enforcement agencies, and
academic institutions that provide computer forensic training, see "Appendix G. Training
Resources List" in Forensic Examination of Digital Evidence: A Guide for Law
Enforcement by the National Institute of Justice, an agency of the U.S. Department of
Justice.
Tools
Every investigation will likely be different. The tools you use should be appropriate for
obtaining the information you seek, but it is always a good idea to gather more evidence
than you might need.
46 Fundamental Computer Investigation Guide For Windows
This section provides information about the Windows Sysinternals tools and other
Windows tools that can help you conduct an internal computer investigation. Tool types
are represented by icons in the first column of the following table:
Table A.3. Tool Types
Icon Description
This icon represents a command-line tool.
This icon represents a tool with a GUI interface that requires installation and
alters the target drive.
The following tables provide information about numerous tools that you can use in
computer investigations.
Diskmon Capture all hard disk activity. Acts like a software disk
activity light in your system tray.
Handle v3.2 Display open files and the process that opened those files.
ListDLLs v2.25 Display all the DLLs that are currently loaded, including
where they are loaded and their version numbers (prints the
full path names of loaded modules).
PendMoves v1.1 Display file rename and delete commands that will be
executed the next time the computer is started.
Portmon v3.02 Display serial and parallel port activity (will also show a
portion of the data being sent and received).
Process Explorer Display files, registry keys, and other objects that processes
v10.2 have open, which DLLs they have loaded, owners of
processes, etc.
ShareEnum v1.6 Scan file shares on a network and view their security
settings to eliminate improperly applied settings.
Strings v2.3 Search for ANSI and UNICODE strings in binary images.
TCPView v2.4 Display all open TCP and UDP endpoints and the name of
the process that owns each endpoint.
Appendix: Resources 49
Windows Tools
Table A.5. Windows Tools Information
Tool Name Description
type
Vol Display the disk volume label and serial number, if they exist.
Hostname Display the host name portion of the full computer name of the
computer.
Reg Use to view, modify, export, save or delete, registry keys, values,
and hives.
Ftype View or modify file types used in file name extension associations.
Charles Denny, Karl Grunwald, John Howie, Christopher Johnsen, Lesley Kipling,
Troy Larson, Mark Miller, Bob McCoy, Craig Nelson, Sanjay Pandit,
Alexandre Hollanda Silva, Mike Smith-Lonergan
Product Managers
Alain Meeus
Jim Stuart
Program Manager
Vlad Pigin
Release Manager
Karina Larson
Testers
Gaurav Singh Bora
Thammarai Selvi Rajendran - Infosys Technologies Ltd.
Vijayanand Senniappan - Infosys Technologies Ltd.
Index
-A- -F-
AccessData, 13, 17, 41 File Checksum Integrity Verifier (FCIV), 13, 28, 29,
38, 41, 50
AccessEnum, 46
Filemon, 47
Acquire the data, 2, 3, 5, 9, 11, 15, 16, 19, 25, 30,
31 Find, 34, 50
Analyze the data, 2, 3, 8, 15, 16, 19, 33 Firewall, 20, 28, 30
Arp, 28, 30, 41, 49
Assess the situation, 2, 3, 5, 7, 9, 19, 24
Autoruns, 41, 46
-G-
Autorunsc, 46 Guidance Software, 13, 17, 41
-B- -H-
Handle, 47
BIOS, 28
Hostname, 50
-C-
Cryptographic hash, 13, 28, 29, 50
-I-
Intrusion detection system (IDS), 12, 15
Ipconfig, 25, 28, 29, 30, 41, 49
-D-
Date, 31, 49
Dir, 31, 49
-L-
Documentation, 14, 42 ListDLLs, 41, 47
-N-
-E- Net, 49
Netstat, 25, 28, 30, 41, 49
EFS (Encrypting File System), 16
Encase, 17, 41
Encryption, 16 -O-
Online analysis, 15
Openfiles, 50
56 Fundamental Computer Investigation Guide For Windows
-P- Sysinternals, 8, 16, 17, 25, 27, 28, 29, 30, 31, 32,
33, 35, 36, 41, 46, 47, 48, 49
Portmon, 47
ProcessExplorer, 16, 41
-T-
PsExec, 28, 29, 30, 47
TCPVcon, 48
PsFile, 8, 25, 28, 29, 30, 47
TCPView, 48
PsInfo, 41, 47
TDIMon, 8, 49
PsList, 28, 29, 30, 33, 48
The Forensic Toolkit, 17, 41
PsLoggedOn, 25, 27, 48
Time, 9, 31, 49
PsLogList, 28, 29, 30, 41, 48
Tokenmon, 49
PsService, 48
Tools, 8, 11, 12, 13, 16, 17, 24, 25, 27, 28, 38, 39,
PsTools, 8 41, 45, 46, 49
Training, 45, 53
-R-
Regmon, 48 -V-
Report the investigation, 2 Vol, 50
-S- -W-
Schtasks, 28, 30, 50 Windows Command Line Tools, 9, 25, 28, 29, 30,
ShareEnum, 8, 48 31, 34, 41, 49, 50