Several tools were mentioned in this lecture as well as in your textbook… Install one of these tools of your choice and experiment. Afterward, write a brief summary concerning this tool. Please, include why you chose the tool that you chose. Also, describe the tool and what functions it performs. Did you find it helpful? Was it easy to use? What is your opinion on the tool?
Note: Your initial post will be your answer to the Question and is to be 300 – 350 words with at least two references. Initial posts will be graded on length, content, grammar, and use of references.
Don't use plagiarized sources. Get Your Custom Essay on
Malin, Cameron, Casey, Eoghan, and Aquilina, James (2012). Malware Forensics Field Guide for Windows Systems: Digital Forensics Field Guides. Syngress.
Malware Forensics Field
Guide for Windows Systems
Digital Forensics Field Guides
Cameron H. Malin
Eoghan Casey
James M. Aquilina
Curtis W. Rose
Technical Editor
contributors, or editors, assume any liability for any injury and/or damage to
persons or property as a matter of products liability, negligence or otherwise, or
from any use or operation of any methods, products, instructions, or ideas
contained in the material herein.
Library of Congress Cataloging-in-Publication Data
Application submitted
British Library Cataloguing-in-Publication Data
A catalogue record for this book is available from the British Library.
ISBN: 978-1-59749-472-4
For information on all Syngress publications visit our website at
http://store.elsevier.com
Printed in the United States of America
12 13 14 15 16 10 9 8 7 6 5 4 3 2 1
Typeset by: diacriTech, Chennai, India
For our moms, who taught us determination, patience,
creativity, and to live passionately.
Acknowledgments
Cameron would like to thank a number of people for their
guidance, support, and ideas on this book—without them it
would not have happened. James and Eoghan I appreciate your
willingness to keep an open mind and embrace the format and
structure of this book; it was a rewarding challenge. I’m proud to
work with you both.
Thanks to the Syngress crew for your patience and
understanding of our vision: Steve Elliot, Angelina Ward, Laura
Colantoni, Matthew Cater, Paul Gottehrer, Chris
Katsaropoulos, and David Bevans.
Not to be forgotten are the some terrific researchers,
developers, and forensic practitioners who assisted and
supported this book: Mila Parkour
(contagiodump.blogspot.com), Ero Carera and Christian
Blichmann (Zynamics), Matthew Shannon (F-Response), Maria
Lucas (HBGary), Thorsten Holz (Assistant Professor at Ruhr-
University Bochum; http://honeyblog.org/), Tark (ccso.com), and
Danny Quist (offensivecomputing.net).
For your friendship, camaraderie, and day-to-day hi-jinks,
For your friendship, camaraderie, and day-to-day hi-jinks,
“Team Cyber” of the Los Angeles Cyber Division—you are a
fantastic crew and I miss you. Jason, Ramyar, and Bryan—my
friends and confidants—thank you for everything, we had a good
run.
My sister Alecia—your determination and focus are an
inspiration to me. “No lying on the couch!”
Finally, to my lovely wife Adrienne, I am so lucky to have
you in my life—thanks for being a “team” with me—I love you.
Bentley and Barkley—thanks for being Daddy’s little “writing
buddies.”
Special Thanks to the Technical
Editor
Malware Forensics Field Guide for Windows Systems was
reviewed by a digital forensic expert who is a fantastic author in
his own right. My sincerest thanks to Curtis W. Rose for your
tenacity and attention to detail—we’re lucky to work with you.
About the Authors
Cameron H. Malin is a Supervisory Special Agent with the
Federal Bureau of Investigation assigned to a Cyber Crime
squad in Los Angeles, California, where he is responsible for the
investigation of computer intrusion and malicious code matters.
In 2010, Mr. Malin was a recipient of the Attorney General’s
Award for Distinguished Service for his role as a Case Agent in
Operation Phish Phry.
Mr. Malin is the Chapter Lead for the Southern California
Chapter of the Honeynet Project, an international non-profit
organization dedicated to improving the security of the Internet
through research, analysis, and information regarding computer
and network security threats. Mr. Malin currently sits on the
Editorial Board of the International Journal of Digital
Evidence (IJDE) and is a Subject Matter Expert for the
Information Assurance Technology Analysis Center (IATAC)
and Weapon Systems Technology and Information Analysis
Center (WSTIAC).
Mr. Malin is a Certified Ethical Hacker (C|EH) and
Certified Network Defense Architect (C|NDA) as designated by
Certified Network Defense Architect (C|NDA) as designated by
the International Council of Electronic Commerce Consultants
(EC-Council) and a Certified Information Systems Security
Professional (CISSP), as designated by the International
Information Systems Security Certification Consortium
((ISC)2®).
Prior to working for the FBI, Mr. Malin was an Assistant
State Attorney (ASA) and Special Assistant United States
Attorney (SAUSA) in Miami, Florida, where he specialized in
computer crime prosecutions. During his tenure as an ASA, Mr.
Malin was also an Assistant Professorial Lecturer in the
Computer Fraud Investigations Masters Program at George
Washington University.
The techniques, tools, methods, views, and opinions
explained by Cameron Malin are personal to him, and do not
represent those of the United States Department of Justice, the
Federal Bureau of Investigation, or the government of the United
States of America. Neither the Federal government nor any
Federal agency endorses this book or its contents in any way.
Eoghan Casey is founding partner of cmdLabs, author of
the foundational book Digital Evidence and Computer Crime,
and coauthor of Malware Forensics: Investigating and
Analyzing Malicious Code. For over a decade he has
dedicated himself to advancing the practice of incident handling
and digital forensics. He helps client organizations handle security
breaches and analyzes digital evidence in a wide range of
investigations, including network intrusions with international
scope. He works at the Department of Defense Cyber Crime
scope. He works at the Department of Defense Cyber Crime
Center (DC3) on research and tool development. He has
testified in civil and criminal cases, and has submitted expert
reports and prepared trial exhibits for computer forensic and
cyber-crime cases.
As a Director of Digital Forensics and Investigations at
Stroz Friedberg, he maintained an active docket of cases and
co-managed the firm’s technical operations in the areas of
computer forensics, cyber-crime response, incident handling, and
electronic discovery. He also spearheaded Stroz Friedberg’s
external and in-house forensic training programs as Director of
Training. Mr. Casey has performed thousands of forensic
acquisitions and examinations, including Windows and UNIX
systems, Enterprise servers, smart phones, cell phones, network
logs, backup tapes, and database systems. He also has extensive
information security experience, as an Information Security
Officer at Yale University and in subsequent consulting work. He
has performed vulnerability assessments; deployed and
maintained intrusion detection systems, firewalls, and public key
infrastructures; and developed policies, procedures, and
educational programs for a variety of organizations.
Mr. Casey holds a B.S. in Mechanical Engineering from the
University of California at Berkeley, and an M.A. in Educational
Communication and Technology from New York University. He
conducts research and teaches graduate students at Johns
Hopkins University Information Security Institute, and is Editor-
in-Chief of Digital Investigation: The International Journal of
in-Chief of Digital Investigation: The International Journal of
Digital Forensics and Incident Response.
James M. Aquilina, Executive Managing Director and
Deputy General Counsel, contributes to the management of
Stroz Friedberg and the handling of its legal affairs, in addition to
having overall responsibility for the Los Angeles, San Francisco,
and Seattle offices. He supervises numerous digital forensic,
Internet investigative, and electronic discovery assignments for
government agencies, major law firms, and corporate
management and information systems departments in criminal,
civil, regulatory, and internal corporate matters, including matters
involving data breach, e-forgery, wiping, mass deletion and other
forms of spoliation, leaks of confidential information, computer-
enabled theft of trade secrets, and illegal electronic surveillance.
He has served as a neutral expert and has supervised the court-
appointed forensic examination of digital evidence. Mr. Aquilina
also has led the development of the firm’s online fraud and abuse
practice, regularly consulting on the technical and strategic
aspects of initiatives to protect computer networks from spyware
and other invasive software, malware and malicious code, online
fraud, and other forms of illicit Internet activity. His deep
knowledge of botnets, distributed denial of service attacks, and
other automated cyber-intrusions enables him to provide
companies with advice and solutions to tackle incidents of
computer fraud and abuse and bolster their infrastructure
protection.
Prior to joining Stroz Friedberg, Mr. Aquilina was an
Assistant U.S. Attorney (AUSA) in the Criminal Division of the
Assistant U.S. Attorney (AUSA) in the Criminal Division of the
U.S. Attorney’s Office for the Central District of California,
where he most recently served in the Cyber and Intellectual
Property Crimes Section. He also served as a member of the
Los Angeles Electronic Crimes Task Force, and as chair of the
Computer Intrusion Working Group, an inter-agency cyber-
crime response organization. As an AUSA, Mr. Aquilina
conducted and supervised investigations and prosecutions of
computer intrusions, extortionate denial of service attacks,
computer and Internet fraud, criminal copyright infringement,
theft of trade secrets, and other abuses involving the theft and
use of personal identity. Among his notable cyber cases, Mr.
Aquilina brought the first U.S. prosecution of malicious botnet
activity against a prolific member of the “botmaster underground”
who sold his armies of infected computers for the purpose of
launching attacks and spamming and used his botnets to generate
income from the surreptitious installation of adware; tried to jury
conviction the first criminal copyright infringement case involving
the use of digital camcording equipment; supervised the
government’s continuing prosecution of Operation Cyberslam,
an international intrusion investigation involving the use of hired
hackers to launch computer attacks against online business
competitors; and oversaw the collection and analysis of
electronic evidence relating to the prosecution of a local terrorist
cell operating in Los Angeles.
During his tenure at the U.S. Attorney’s Office, Mr.
Aquilina also served in the Major Frauds and
Terrorism/Organized Crime Sections, where he investigated and
Terrorism/Organized Crime Sections, where he investigated and
tried numerous complex cases, including a major corruption trial
against an IRS Revenue Officer and public accountants, a fraud
prosecution against the French bank Credit Lyonnais in
connection with the rehabilitation and liquidation of the now
defunct insurer Executive Life, and an extortion and kidnapping
trial against an Armenian organized crime ring. In the wake of the
September 11, 2001, attacks Mr. Aquilina helped establish and
run the Legal Section of the FBI’s Emergency Operations
Center.
Before public service, Mr. Aquilina was an associate at the
law firm Richards, Spears, Kibbe & Orbe in New York, where
he focused on white collar defense work in federal and state
criminal and regulatory matters.
He served as a law clerk to the Honorable Irma E.
Gonzalez, U.S. District Judge, Southern District of California. He
received his B.A. magna cum laude from Georgetown
University, and his J.D. from the University of California,
Berkeley School of Law, where he was a Richard Erskine
Academic Fellow and served as an Articles Editor and Executive
Committee Member of the California Law Review.
He currently serves as an Honorary Council Member on
cyber-law issues for the EC-Council, the organization that
provides the C|EH and CHFI (Certified Hacking Forensic
Investigator) certifications to leading security industry
professionals worldwide. Mr. Aquilina is a member of Working
Group 1 of the Sedona Conference, the International
Association of Privacy Professionals, the Southern California
Honeynet Project, the Los Angeles Criminal Justice Inn of
Court, and the Los Angeles County Bar Association. He also
serves on the Board of Directors of the Constitutional Rights
Foundation, a non-profit educational organization dedicated to
providing young people with access to and understanding of law
and the legal process.
Mr. Aquilina is co-author of Malware Forensics:
Investigating and Analyzing Malicious Code.
About the Technical Editor
Curtis W. Rose is the President and founder of Curtis W. Rose
& Associates LLC, a specialized services company in Columbia,
Maryland, which provides computer forensics, expert testimony,
litigation support, and computer intrusion response and training
to commercial and government clients. Mr. Rose is an industry-
recognized expert with over 20 years of experience in
investigations, computer forensics, and technical and information
security.
Mr. Rose was a co-author of Real Digital Forensics:
Computer Security and Incident Response, and was a
contributing author or technical editor for many popular
information security books including Handbook of Digital
Forensics and Investigation; Malware Forensics:
Investigating and Analyzing Malicious Code; SQL Server
Forensic Analysis; Anti-Hacker Toolkit, 1st Edition; Network
Security: The Complete Reference; and Incident Response
and Computer Forensics, 2nd Edition. He has also published
whitepapers on advanced forensic methods and techniques
including “Windows Live Response Volatile Data Collection:
including “Windows Live Response Volatile Data Collection:
Non-Disruptive User and System Memory Forensic Acquisition”
and “Forensic Data Acquisition and Processing Utilizing the
Linux Operating System.”
Introduction to Malware
Forensics
Since the publication of Malware Forensics: Investigating and
Analyzing Malicious Code in 2008,1 the number and
complexity of programs developed for malicious and illegal
purposes has grown substantially. The 2011 Symantec Internet
Security Threat Report announced that over 286 million new
threats emerged in the past year.2 Other anti-virus vendors,
including F-Secure, forecast an increase in attacks against mobile
devices and SCADA systems in 2011.3
In the past, malicious code has been categorized neatly
(e.g., viruses, worms, or Trojan horses) based upon functionality
and attack vector. Today, malware is often modular and
multifaceted, more of a “blended-threat,” with diverse
functionality and means of propagation. Much of this malware
has been developed to support increasingly organized,
professional computer criminals. Indeed, criminals are making
extensive use of malware to control computers and steal
personal, confidential, or otherwise proprietary information for
personal, confidential, or otherwise proprietary information for
profit. In Operation Trident Breach,4 hundreds of individuals
were arrested for their involvement in digital theft using malware
such as ZeuS. A thriving gray market ensures that today’s
malware is professionally developed to avoid detection by
current AntiVirus programs, thereby remaining valuable and
available to any cyber-savvy criminal group.
Of growing concern is the development of malware to
disrupt power plants and other critical infrastructure through
computers, referred to by some as Cyber Warfare. The StuxNet
malware that emerged in 2010 is a powerful demonstration of
the potential for such attacks.5 Stuxnet was a sophisticated
program that enabled the attackers to alter the operation of
industrial systems, like those in a nuclear reactor, by accessing
programmable logic controllers connected to the target
computers. This type of attack could shut down a power plant or
other components of a society’s critical infrastructure, potentially
causing significant harm to people in a targeted region.
Foreign governments are funding teams of highly skilled
hackers to develop customized malware to support industrial and
military espionage.6 The intrusion into Google’s systems
demonstrates the advanced and persistent capabilities of such
attackers.7 These types of well-organized attacks, known as the
“Advanced Persistent Threat (APT),” are designed to maintain
long-term access to an organization’s network in order to steal
information/gather intelligence and are most commonly
associated with espionage. The increasing use of malware to
associated with espionage. The increasing use of malware to
commit espionage and crimes and launch cyber attacks is
compelling more digital investigators to make use of malware
analysis techniques and tools that were previously the domain of
anti-virus vendors and security researchers.
This Field Guide was developed to provide practitioners
with the core knowledge, skills, and tools needed to combat this
growing onslaught against computer systems.
How to Use this Book
This book is intended to be used as a tactical reference
while in the field.
This Field Guide is designed to help digital investigators
identify malware on a computer system, examine malware to
uncover its functionality and purpose, and determine malware’s
impact on a subject system. To further advance malware analysis
as a forensic discipline, specific methodologies are provided and
legal considerations are discussed so that digital investigators can
perform this work in a reliable, repeatable, defensible, and
thoroughly documented manner.
Unlike Malware Forensics: Investigating and
Analyzing Malicious Code, which uses practical case scenarios
throughout the text to demonstrate techniques and associated
tools, this Field Guide strives to be both tactical and practical,
structured in a succinct outline format for use in the field, but with
cross-references signaled by distinct graphical icons to
supplemental components and online resources for the field and
lab alike.
Supplemental Components
The supplementary components used in this Field Guide
include:
• Field Interview Questions: An organized and detailed
interview question and answer form that can be used
while responding to a malicious code incident.
• Field Notes: A structured and detailed note-taking
solution, serving as both guidance and a reminder
checklist while responding in the field or in the lab.
• Pitfalls to Avoid: A succinct list of commonly
encountered mistakes and discussion of how to avoid
these mistakes.
• Tool Box : A resource for the digital investigator to learn
about additional tools that are relevant to the subject
matter discussed in the corresponding substantive
chapter section. The Tool Box icon ( —a wrench and
hammer) is used to notify the reader that additional tool
information is available in the Tool Box appendix at the
end of each chapter, and on the book’s companion Web
site, www.malwarefieldguide.com.
• Selected Readings: A list of relevant supplemental
reading materials relating to topics covered in the
chapter.
Investigative Approach
When malware is discovered on a system, the
importance of organized methodology, sound analysis,
steady documentation, and attention to evidence dynamics
all outweigh the severity of any time pressure to
investigate.
Organized Methodology
The Field Guide’s overall methodology for dealing with
malware incidents breaks the investigation into five phases:
Phase 1: Forensic preservation and examination of volatile
data (Chapter 1)
Phase 2: Examination of memory (Chapter 2)
Phase 3: Forensic analysis: examination of hard drives
(Chapter 3)
Phase 4: File profiling of an unknown file (Chapters 5)
Phase 5: Dynamic and static analysis of a malware
specimen (Chapter 6)
Within each of these phases, formalized methodologies
and goals are emphasized to help digital investigators reconstruct
a vivid picture of events surrounding a malware infection and gain
a detailed understanding of the malware itself. The
methodologies outlined in this book are not intended as a
checklist to be followed blindly; digital investigators always must
apply critical thinking to what they are observing and adjust
accordingly.
Whenever feasible, investigations involving malware
should extend beyond a single compromised computer, as
malicious code is often placed on the computer via the network,
and most modern malware has network-related functionality.
Discovering other sources of evidence, such as servers the
malware contacts to download components or instructions, can
provide useful information about how malware got on the
computer and what it did once installed.
In addition to systems containing artifacts of compromise,
other network and data sources may prove valuable to your
investigation. Comparing available backup tapes of the
compromised system to the current state of the system, for
example, may uncover additional behavioral attributes of the
malware, tools the attacker left behind, or recoverable files
containing exfiltrated data. Also consider checking centralized
logs from anti-virus agents, reports from system integrity
checking tools like Tripwire, and network level logs.
Network forensics can play a key role in malware
incidents, but this extensive topic is beyond the scope of our
incidents, but this extensive topic is beyond the scope of our
Field Guide. One of the author’s earlier works8 covers tools and
techniques for collecting and utilizing various sources of evidence
on a network that can be useful when investigating a malware
incident, including Intrusion Detection Systems, NetFlow logs,
and network traffic. These logs can show use of specific exploits,
malware connecting to external IP addresses, and the names of
files being stolen. Although potentially not available prior to
discovery of a problem, logs from network resources
implemented during the investigation may capture meaningful
evidence of ongoing activities.
Remember that well-interviewed network administrators,
system owners, and computer users often help develop the best
picture of what actually occurred.
Finally, as digital investigators are more frequently asked
to conduct malware analysis for investigative purposes that may
lead to the victim’s pursuit of a civil or criminal remedy, ensuring
the reliability and validity of findings means compliance with an
oft complicated legal and regulatory landscape. Chapter 4,
although no substitute for obtaining counsel and sound legal
advice, explores some of these concerns and discusses certain
legal requirements or limitations that may govern the
preservation, collection, movement and analysis of data and
digital artifacts uncovered during malware forensic investigations.
Forensic Soundness
The act of collecting data from a live system may cause
changes that a digital investigator will need to justify, given its
impact on other digital evidence.
• For instance, running tools like Helix3 Pro9 from a
removable media device will alter volatile data when
loaded into main memory and create or modify files and
Registry entries on the evidentiary system.
• Similarly, using remote forensic tools necessarily
establishes a network connection, executes instructions
in memory, and makes other alterations on the
evidentiary system.
Purists argue that forensic acquisitions should not alter
the original evidence source in any way. However, traditional
forensic disciplines like DNA analysis suggest that the measure
of forensic soundness does not require that an original be left
unaltered. When samples of biological material are collected, the
process generally scrapes or smears the original evidence.
Forensic analysis of the evidentiary sample further alters the
original evidence, as DNA tests are destructive. Despite changes
that occur during both preservation and processing, these
methods are nonetheless considered forensically sound and the
evidence is regularly admitted in legal proceedings.
Some courts consider volatile computer data
discoverable, thereby requiring digital investigators to preserve
discoverable, thereby requiring digital investigators to preserve
data on live systems. For example, in Columbia Pictures
Industries v. Bunnell,10 the court held that RAM on a Web
server could contain relevant log data and was therefore within
the scope of discoverable information in the case.
Documentation
One of the keys to forensic soundness is documentation.
• A solid case is built on supporting documentation that
reports on where the evidence originated and how it was
handled.
• From a forensic standpoint, the acquisition process should
change the original evidence as little as possible, and any
changes should be documented and assessed in the
context of the final analytical results.
• Provided both that the acquisition process preserves a
complete and accurate representation of the original
data, and the authenticity and integrity of that
representation can be validated, the acquisition is
generally considered forensically sound.
Documenting the steps taken during an investigation, as
well as the results, will enable others to evaluate or repeat the
analysis.
analysis.
• Keep in mind that contemporaneous notes are often
referred to years later to help digital investigators recall
what occurred, what work was conducted, and who
was interviewed, among other things.
• Common forms of documentation include screenshots,
captured network traffic, output from analysis tools, and
notes.
• When preserving volatile data, document the date and
time that data was preserved and which tools were used,
and calculate the MD5 of all output.
• Whenever dealing with computers, it is critical to note the
date and time of the computer, and compare it with a
reliable time source to assess the accuracy of date-time
stamp information associated with the acquired data.
Evidence Dynamics
Unfortunately, digital investigators rarely are presented with
the perfect digital crime scene. Many times the malware or
attacker purposefully has destroyed evidence by deleting logs,
overwriting files, or encrypting incriminating data. Often the
digital investigator is called to an incident only after the victim has
taken initial steps to remediate—and in the process, has either
destroyed critical evidence, or worse, compounded the damage
to the system by invoking additional hostile programs.
This phenomenon is not unique to digital forensics.
Violent crime investigators regularly find that offenders attempted
to destroy evidence or EMT first responders disturbed the crime
scene while attempting to resuscitate the victim. These types of
situations are sufficiently common to have earned a name
—evidence dynamics.
Evidence dynamics is any influence that changes,
relocates, obscures, or obliterates evidence—regardless of intent
—between the time evidence is transferred and the time the case
is adjudicated.11
• Evidence dynamics is a particular concern in malware
incidents because there is often critical evidence in
memory that will be lost if not preserved quickly and
properly.
• Digital investigators must live with the reality that they will
rarely have an opportunity to examine a digital crime
scene in its original state and should therefore expect
some anomalies.
• Evidence dynamics creates investigative and legal
challenges, making it more difficult to determine what
occurred, and making it more difficult to prove that the
evidence is authentic and reliable.
• Any conclusions the digital investigator reaches without
knowledge of how evidence was changed may be
knowledge of how evidence was changed may be
incorrect, open to criticism in court, or misdirect the
investigation.
• The methodologies and legal discussion provided in this
Field Guide are designed to minimize evidence dynamics
while collecting volatile data from a live system using
tools that can be differentiated from similar utilities
commonly used by intruders.
Forensic Analysis in Malware
Investigations
Malware investigation often involves the preservation
and examination of volatile data; the recovery of deleted
files; and other temporal, functional, and relational kinds
of computer forensic analysis.
Preservation and Examination of Volatile
Data
Investigations involving malicious code rely heavily on forensic
preservation of volatile data. Because operating a suspect
computer usually changes the system, care must be taken to
minimize the changes made to the system; collect the most
volatile data first (aka Order of Volatility, which is described in
detail in RFC 3227: Guidelines for Evidence Collection and
Archiving);12 and thoroughly document all actions taken.
Technically, some of the information collected from a live
system in response to a malware incident is non-volatile. The
following subcategories are provided to clarify the relative
importance of what is being collected from live systems.
• Tier 1 Volatile Data: Critical system details that provide
the investigator with insight as to how the system was
compromised and the nature of the compromise.
compromised and the nature of the compromise.
Examples include logged-in users, active network
connections, and the processes running on the system.
• Tier 2 Volatile Data : Ephemeral information, while
beneficial to the investigation and further illustrative of the
nature and purpose of the compromise and infection, is
not critical to identification of system status and details.
Examples of these data include scheduled tasks and
clipboard contents.
• Tier 1 Non-volatile Data: Reveals the status, settings,
and configuration of the target system, potentially
providing clues as to the method of the compromise and
infection of the system or network. Examples include
registry settings and audit policy.
• Tier 2 Non-volatile Data: Provides historical
information and context, but is not critical to system
status, settings, or configuration analysis. Examples of
these data include system event logs and Web browser
history.
The current best practices and associated tools for
preserving and examining volatile data on Windows systems are
covered in Chapter 1 (Malware Incident Response: Volatile
Data Collection and Examination on a Live Windows System)
and Chapter 2 (Memory Forensics: Analyzing Physical and
Process Memory Dumps for Malware Artifacts).
Recovering Deleted Files
Specialized forensic tools have been developed to recover
deleted files that are still referenced in the file system. It is also
possible to salvage deleted executables from unallocated space
possible to salvage deleted executables from unallocated space
that are no longer referenced in the file system. One of the most
effective tools for salvaging executables from unallocated space
is “foremost,” as shown in Figure I.1 using the “-t” option, which
uses internal carving logic rather than simply headers from the
configuration file.
Figure I.1 Using foremost to carve executable files from
unallocated disk space
One of the primary goals of forensic analysis is to reconstruct
the events surrounding a crime. Three common analysis
techniques that are used in crime reconstruction are temporal,
functional, and relational analysis.
The most common form of temporal analysis is the time
line, but there is such an abundance of temporal information on
computers that the different approaches to analyzing this
information are limited only by our imagination and current tools.
The goal of functional analysis is to understand what
actions were possible within the environment of the offense, and
how the malware actually behaves within the environment (as
opposed to what it was capable of doing).
• One effective approach with respect to conducting a
functional analysis to understand how a particular piece
of malware behaves on a compromised system is to load
the forensic duplicate into a virtual environment using a
tool like Live View.13Figure I.2 shows Live View being
used to prepare and load a forensic image into a
virtualized environment.
Figure I.2 Live View taking a forensic duplicate of a Windows
XP system and launching it in VMware
Relational analysis involves studying how components of
malware interact, and how various systems involved in a
malware incident relate to each other.
• For instance, one component of malware may be easily
identified as a downloader for other more critical
components, and may not require further in-depth
analysis.
• Similarly, one compromised system may be the primary
command and control point used by the intruder to
access other infected computers, and may contain the
most useful evidence of the intruder’s activities on the
network as well as information about other compromised
systems.
systems.
Specific applications of these forensic analysis techniques
are covered in Chapter 3, Post-Mortem Forensics: Discovering
and Extracting Malware and Associated Artifacts from Windows
Systems.
Applying Forensics to Malware
Forensic analysis of malware requires an
understanding of how an executable is complied, the
difference between static and dynamic linking, and how to
distinguish class from individuating characteristics of
malware.
How an Executable File is Compiled
Before delving into the tools and techniques used to dissect a
malicious executable program, it is important to understand how
source code is compiled, linked, and becomes executable code.
The steps an attacker takes during the course of compiling
malicious code are often items of evidentiary significance
uncovered during the examination of the code.
Think of the compilation of source code into an
executable file like the metamorphosis of caterpillar to butterfly:
the initial and final products manifest as two totally different
entities, even though they are really one in the same but in
different form.
As illustrated in Figure I.3, when a program is compiled,
As illustrated in Figure I.3, when a program is compiled,
the program’s source code is run through a compiler, a program
that translates the programming statements written in a high-level
language into another form. Once processed through the
compiler, the source code is converted into an object file or
machine code, as it contains a series of instructions not intended
for human readability, but rather for execution by a computer
processor.14
Figure I.3 Compiling source code into an object file
After the source code is compiled into an object file, a
linker assembles any required libraries and object code together
to produce an executable file that can be run on the host
operating system, as seen in Figure I.4.
Figure I.4 A linker creates an executable file by linking the
required libraries and code to an object file
Often, during compilation, bits of information are added
to the executable file that may be relevant to the overall
investigation. The amount of information present in the
executable is contingent upon how it was compiled by the
attacker. Chapter 5 (File Identification and Profiling: Initial
Analysis of a Suspect File on a Windows System) covers tools
and techniques for unearthing these useful clues during the course
of your analysis.
Static versus Dynamic Linking
In addition to the information added to the executable during
compilation, it is important to examine the suspect program to
determine whether it is a static or a dynamic executable, as this
will significantly impact the contents and size of the file, and in
turn, the evidence you may discover.
• A static executable is compiled with all of the necessary
libraries and code it needs to successfully execute,
making the program “self-contained.”
• Conversely, dynamically linked executables are
dependent upon shared libraries to successfully run. The
required libraries and code needed by the dynamically
linked executable are referred to as dependencies.
• In Windows programs, dependencies are most often
dynamic link libraries (DLLs; .dll extension) that are
imported from the host operating system during
execution.
• File dependencies in Windows executables are identified
in the Import Tables of the file structure. By calling on
the required libraries at runtime, rather than statically
linking them to the code, dynamically linked executables
are smaller and consume less system memory, among
other things.
We will discuss how to examine a suspect file to identify
dependencies, and delve into Important Table and file
dependency analysis in greater detail in Chapter 5 (File
Identification and Profiling: Initial Analysis of a Suspect File on a
Windows System) and Chapter 6 (Analysis of a Malware
Specimen).
Class versus Individuating
Characteristics
It is simply not possible to be familiar with every kind of
malware in all of its various forms.
• Best investigative effort will include a comparison of
unknown malware with known samples, as well as
conducting preliminary analysis designed not just to
identify the specimen, but how best to interpret it.
• Although libraries of malware samples currently exist in
the form of anti-virus programs and hash sets, these
resources are far from comprehensive.
• Individual investigators instead must find known samples
to compare with evidence samples and focus on the
characteristics of files found on the compromised
computer to determine what tools the intruder used.
Further, deeper examination of taxonomic and
phylogenetic relationships between malware specimens
may be relevant to classify a target specimen and
determine if it belongs to a particular malware “family.”
Once an exemplar is found that resembles a given piece
of digital evidence, it is possible to classify the sample. John
Thornton describes this process well in “The General
Assumptions and Rationale of Forensic Identification”:15
Assumptions and Rationale of Forensic Identification”:15
In the “identification” mode, the forensic scientist
examines an item of evidence for the presence or
absence of specific characteristics that have been
previously abstracted from authenticated items.
Identifications of this sort are legion, and are
conducted in forensic laboratories so frequently and in
connection with so many different evidence categories
that the forensic scientist is often unaware of the
specific steps that are taken in the process. It is not
necessary that those authenticated items be in hand,
but it is necessary that the forensic scientist have
access to the abstracted information. For example, an
obscure 19th Century Hungarian revolver may be
identified as an obscure 19th Century Hungarian
revolver, even though the forensic scientist has never
actually seen one before and is unlikely ever to see one
again. This is possible because the revolver has been
described adequately in the literature and the literature
is accessible to the scientist. Their validity rests on the
application of established tests which have been
previously determined to be accurate by exhaustive
testing of known standard materials.
In the “comparison” mode, the forensic scientist
compares a questioned evidence item with another
item. This second item is a “known item.” The known
item may be a standard reference item which is
maintained by the laboratory for this purpose (e.g. an
maintained by the laboratory for this purpose (e.g. an
authenticated sample of cocaine), or it may be an
exemplar sample which itself is a portion of the
evidence in a case (e.g., a sample of broken glass or
paint from a crime scene). This item must be in hand.
Both questioned and known items are compared,
characteristic by characteristic, until the examiner is
satisfied that the items are sufficiently alike to conclude
that they are related to one another in some manner.
In the comparison mode, the characteristics that
are taken into account may or may not have been
previously established. Whether they have been
previously established and evaluated is determined
primarily by (1) the experience of the examiner, and (2)
how often that type of evidence is encountered. The
forensic scientist must determine the characteristics to
be before a conclusion can be reached. This is more
easily said than achieved, and may require de novo
research in order to come to grips with the significance
of observed characteristics. For example, a forensic
scientist compares a shoe impression from a crime
scene with the shoes of a suspect. Slight irregularities in
the tread design are noted, but the examiner is
uncertain whether those features are truly individual
characteristics unique to this shoe, or a mold release
mark common to thousands of shoes produced by this
manufacturer. Problems of this type are common in the
forensic sciences, and are anything but trivial.
forensic sciences, and are anything but trivial.
The source of a piece of malware is itself a unique
characteristic that may differentiate one specimen from another.
• Being able to show that a given sample of digital evidence
originated on a suspect’s computer could be enough to
connect the suspect with the crime.
• The denial of service attack tools that were used to attack
Yahoo! and other large Internet sites, for example,
contained information useful in locating those sources of
attacks.
• As an example, IP addresses and other characteristics
extracted from a distributed denial of service attack tool
are shown in Figure I.5.
Figure I.5 Individuating characteristics in suspect malware
• The sanitized IP addresses at the end indicated where the
command and control servers used by the malware were
located on the Internet, and these command and control
systems may have useful digital evidence on them.
Class characteristics may also establish a link between
Class characteristics may also establish a link between
the intruder and the crime scene. For instance, the “t0rn”
installation file contained a username and port number selected
by the intruder shown in Figure I.6.
Figure I.6 Class characteristics in suspect malware
If the same characteristics are found on other
compromised hosts or on a suspect’s computer, these may be
correlated with other evidence to show that the same intruder
was responsible for all of the crimes and that the attacks were
launched from the suspect’s computer. For instance, examining
the computer with IP address 192.168.0.7 used to break into
192.168.0.3 revealed the following traces (Figure I.7) that help
establish a link.
Figure I.7 Examining multiple victim systems for similar artifacts
Be aware that malware developers continue to find new
ways to undermine forensic analysis. For instance, we have
encountered the following anti-forensic techniques (although this
list is by no means exhaustive and will certainly develop with
time):
• Multicomponent packing and encryption
• Detection of debuggers, disassemblers, and virtual
environments
• Malware that halts when the PEB Debugging Flag is set
• Malware that sets the “Trap Flag” on one of its operating
threads to hinder tracing analysis
• Malware that uses Structured Exception Handling (SEH)
protection to block or misdirect debuggers
• Malware that rewrites error handlers to force a floating
point error to control how the program behaves
A variety of tools and techniques are available to digital
investigators to overcome these anti-forensic measures, many of
which are detailed in this book. Note that advanced anti-forensic
which are detailed in this book. Note that advanced anti-forensic
techniques require knowledge and programming skills that are
beyond the scope of this book. More in-depth coverage of
reverse engineering is available in The IDA Pro Book: The
Unofficial Guide to the World’s Most Popular
Disassembler.16 A number of other texts provide details on
programming rootkits and other malware.17
From Malware Analysis to
Malware Forensics
The blended malware threat has arrived; the need for
in-depth, verifiable code analysis and formalized
documentation has arisen; a new forensic discipline has
emerged.
In the good old days, digital investigators could discover
and analyze malicious code on computer systems with relative
ease. Trojan horse programs like Back Orifice and SubSeven
and UNIX rootkits like t0rnkit did little to undermine forensic
analysis of the compromised system. Because the majority of
malware functionality was easily observable, there was little need
for a digital investigator to perform in-depth analysis of the code.
In many cases, someone in the information security community
would perform a basic functional analysis of a piece of malware
and publish it on the Web.
While the malware of yesteryear neatly fell into distinct
categories based upon functionality and attack vector (viruses,
worms, Trojan horses), today’s malware specimens are often
modular, multifaceted, and known as blended-threats because
of their diverse functionality and means of propagation.18 And,
as computer intruders become more cognizant of digital forensic
techniques, malicious code is increasingly designed to obstruct
meaningful analysis.
By employing techniques that thwart reverse engineering,
encode and conceal network traffic, and minimize the traces left
on file systems, malicious code developers are making both
discovery and forensic analysis more difficult. This trend started
with kernel loadable rootkits on UNIX and has evolved into
similar concealment methods on Windows systems.
Today, various forms of malware are proliferating,
automatically spreading (worm behavior), providing remote
control access (Trojan horse/backdoor behavior), and
sometimes concealing their activities on the compromised host
(rootkit behavior). Furthermore, malware has evolved to
undermine security measures, disabling AntiVirus tools and
bypassing firewalls by connecting from within the network to
external command and control servers.
external command and control servers.
One of the primary reasons that developers of malicious
code are taking such extraordinary measures to protect their
creations is that, once the functionality of malware has been
decoded, digital investigators know what traces and patterns to
look for on the compromised host and in network traffic. In fact,
the wealth of information that can be extracted from malware has
made it an integral and indispensable part of computer intrusion,
identity theft and counterintelligence cases. In many cases, little
evidence remains on the compromised host and the majority of
useful investigative information lies in the malware itself.
The growing importance of malware analysis in digital
investigations, and the increasing sophistication of malicious
code, has driven advances in tools and techniques for performing
surgery and autopsies on malware. As more investigations rely
on understanding and counteracting malware, the demand for
formalization and supporting documentation has grown. The
results of malware analysis must be accurate and verifiable, to
the point that they can be relied on as evidence in an investigation
or prosecution. As a result, malware analysis has become a
forensic discipline—welcome to the era of malware forensics.
1 http://www.syngress.com/digital-forensics/Malware-
Forensics/.
2
http://www.symantec.com/connect/2011_Internet_Security_Threat_Report_Identifies_Risks_For_SMBs
3 http://www.f-secure.com/en_EMEA-Labs/news-
info/threat-summaries/2011/2011_1.html.
4 http://krebsonsecurity.com/tag/operation-trident-breach/.
5 http://www.symantec.com/connect/blogs/stuxnet-
introduces-first-known-rootkit-scada-
devices;http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier
6 “The New E-spionage Threat,”
http://www.businessweek.com/magazine/content/08_16/b4080032218430.htm;
“China Accused of Hacking into Heart of Merkel
Administration,”
http://www.timesonline.co.uk/tol/news/world/europe/article2332130.ece.
7 http://googleblog.blogspot.com/2010/01/new-approach-
to-china.html.
8 Casey, E. (2011). Digital Evidence and Computer Crime,
3rd ed. London: Academic Press.
9 For more information about Helix3 Pro, go to
9 For more information about Helix3 Pro, go to
http://www.e-fense.com/helix3pro.php.
10 2007 U.S. Dist. LEXIS 46364 (C.D. Cal. June 19,
2007).
11 Chisum, W.J., and Turvey, B. (2000). Evidence
Dynamics: Locard’s Exchange Principle and Crime
Reconstruction, Journal of Behavioral Profiling, Vol. 1,
No. 1.
12 http://www.faqs.org/rfcs/rfc3227.html.
13 For more information about Live View, go to
http://liveview.sourceforge.net.
14 For good discussions of the file compilation process and
analysis of binary executable files, see, Jones, K.J.,
Bejtlich, R., and Rose, C.W. (2005). Real Digital
Forensics: Computer Security and Incident Response.
Reading, MA: Addison Wesley; Mandia, K., Prosise,
C., and Pepe, M. (2003). Incident Response and
Computer Forensics, 2nd ed. New York: McGraw-
Hill/Osborne; and Skoudis, E., and Zeltser, L. (2003).
Malware: Fighting Malicious Code. Upper Saddle
River, NJ: Prentice Hall.
15 Thornton, JI. (1997). The General Assumptions and
Rationale of Forensic Identification. In: Faigman, D.L.,
Kaye, D.H., Saks, M.J., and Sanders, J., eds., Modern
Scientific Evidence: The Law and Science of Expert
Testimony, Vol. 2. St. Paul, MN: West Publishing Co.
16 http://nostarch.com/idapro2.htm.
17 See, Hoglund, G., and Butler, J. (2005). Rootkits:
Subverting the Windows Kernel. Reading, MA:
Addison-Wesley; Bluden, B. (2009). The Rootkit
Arsenal: Escape and Evasion in the Dark Corners of the
System. Burlington, MA: Jones & Bartlett Publishers;
Metula, E. (2010). Managed Code Rootkits: Hooking
into Runtime Environments. Burlington, MA: Syngress.
18
http://www.virusbtn.com/resources/glossary/blended_threat.xml.
Table of Contents
Title
Copyright
Dedication
Acknowledgments
About the Authors
About the Technical Editor
Introduction
Chapter 1. Malware Incident Response
Solutions in this chapter:
Volatile Data Collection and Analysis Tools
Non-Volatile Data Collection and Analysis Tools
Selected Readings
Jurisprudence/RFCS/Technical Specifications
Jurisprudence/RFCS/Technical Specifications
Chapter 2. Memory Forensics
Solutions in this chapter:
Selected Readings
Chapter 3. Post-Mortem Forensics
Solutions in this chapter:
Selected Readings
Chapter 4. Legal Considerations
Solutions in this chapter:
Chapter 5. File Identification and Profiling
Solutions in this chapter:
Selected Readings
Chapter 6. Analysis of a Malware Specimen
Solutions in this chapter:
Introduction
Goals
Goals
Guidelines for Examining a Malicious File
Specimen
Establishing the Environment Baseline
Pre-Execution Preparation: System and Network
Monitoring
Execution Artifact Capture: Digital Impression
and Trace Evidence
Interacting with and Manipulating the Malware
Specimen: Exploring and Verifying Functionality and
Purpose
Purpose
Event Reconstruction and Artifact Review: Post-
Run Data Analysis
Digital Virology: Advanced Profiling Through
Malware Taxonomy and Phylogeny
Conclusion
Pitfalls to Avoid
Selected Readings
Index
Chapter 1
Malware Incident Response
Volatile Data Collection and Examination on a Live
Windows System
Solutions in this chapter:
• Volatile Data Collection Methodology
Local vs. Remote Collection
Preservation of Volatile Data
Physical Memory Acquisition
Collecting Subject System Details
Identifying Logged-in Users
Current and Recent Network Connections
• Collecting Process Information
• Correlate Open Ports with Running Processes and
Programs
Identifying Services and Drivers
Determining Open Files
Collecting Command History
Identifying Shares
Determining Scheduled Tasks
Collecting Clipboard Contents
• Non-Volatile Data Collection from a Live Windows
System
Forensic Duplication of Storage Media
Forensic Preservation of Select Data
Assessing Security Configuration
Assessing Trusted Host Relationships
Inspecting Prefetch Files
Inspect Auto-Starting Locations
Collecting Event Logs
Reviewing User Account and Group Policy Information
Examining the File System
Dumping and Parsing Registry Contents
• Examining Web Browsing Artifacts
• Examining Web Browsing Artifacts
• Malware Artifact Discovery and Extraction from a Live
Windows System
Tool Box Appendix and Web Site
The “ ” symbol references throughout this chapter demarcate
that additional utilities pertaining to the topic are discussed in the
Tool Box appendix, appearing at the end of this chapter. Further
tool information and updates for this chapter can be found on the
companion Malware Field Guides Web site, at
http://www.malwarefieldguide.com/Chapter1.html.
Introduction
This chapter demonstrates the value of preserving volatile and
select non-volatile data, and how to do so in a forensically sound
manner. The value of volatile data is not limited to process
memory associated with malware, but can include passwords,
Internet Protocol (IP) addresses, Security Event Log entries, and
other contextual details that together can provide a more
complete understanding of the malware and its use on a system.
When powered on, a subject system contains critical
ephemeral information that reveals the state of the system. This
volatile data is sometimes referred to as stateful information.
Incident response forensics, or live response, is the process of
acquiring the stateful information from the subject system while it
remains powered on. As we discussed in the introductory
chapter, the Order of Volatility should be considered when
collecting data from a live system to ensure that critical system
data is acquired before it is lost or the system is powered down.
Further, because the scope of this chapter pertains to live
response through the lens of a malicious code incident, the
preservation techniques outlined in this section are not intended
to be comprehensive or exhaustive; instead, they are intended to
provide a solid foundation relating to incident response involving
malware on a live system.
Often, malicious code live response is a dynamic process,
with the facts and context of each incident dictating the manner
and means in which the investigator will proceed with his
investigation. Unlike other contexts in which simply acquiring a
forensic duplicate of a subject system’s hard drive would be
sufficient, investigating a malicious code incident on a subject
system very often requires some degree of live response. This is
because much of the information the investigator needs to identify
the nature and scope of the malware infection resides in stateful
information that will be lost when the computer is powered
down.
This chapter provides an overall methodology for
preserving volatile data on a Windows system during a malware
incident, and presumes that the digital investigator already has
built his live response toolkit of trusted tools, or is using a tool
suite specifically designed to collect digital evidence in an
automated fashion from Windows systems during incident
response. There are a variety of live response tool suites
available to the digital investigator—many of which are discussed
in the Tool Box section at the end of this chapter. Although
automated collection of digital evidence is recommend as a
measure to avoid mistakes and inadvertent collection gaps, the
aim of this chapter and associated appendices is to provide the
digital investigator with a granular walk-through of the live
response process and the digital evidence that should be
collected.
Analysis Tip
Field Interviews
Prior to conducting live response, gather as much information as
possible about the malicious code incident and subject system(s)
from relevant witnesses. Refer to the Field Interview Questions
appendix at the end of this chapter for additional details.
Local versus Remote Collection
Choose the manner in which data will be collected
from the subject system.
• Collecting results locally means storage media will be
connected to the subject system and the results will be
saved onto the connected media.
• Remote collection means establishing a network
connection from the subject system, typically with a
netcat or cryptcat listener, and transferring the
acquired system data over the network to a collection
server. This method reduces system interaction, but
relies on the ability to traverse the subject network
through ports established by the netcat listener.
Investigative Considerations
• In some instances, the subject network will have rigid
firewall and/or proxy server configurations, making it
cumbersome or impractical to establish a remote
collection repository.
collection repository.
• Remotely acquiring certain data during live response—
like imaging a subject system’s physical memory—may
be time and resource consuming and require several
gigabytes of data to traverse the network, depending on
the amount of random access memory (RAM) in the
target system. The following pair of commands depicted
in Figure 1.1 sends the output of a live response utility
acquiring data from a subject system to a remote IP
address (172.16.131.32) and saves the output in a file
named “20101020host1.txt” on the
collection system.
Figure 1.1 Netcat commands to establish a network listener to
collect tool output remotely
• The netcat command must be executed on the collection
system first so that it is ready and waiting to receive data
from the subject system.
• Local collection efforts can be protracted in instances
where a victim system is older and contains obsolete
hardware, such as USB 1.1, which has a maximum
transfer rate of 12 megabits per second (mbps).
• Always ensure that the media you are using to acquire live
response data is pristine and do not contain unrelated
case data, malicious code specimens, or other artifacts
from previous investigations. Acquiring digital evidence
on “dirty” or compromised media can taint and
undermine the forensic soundness of the acquired data.
Volatile Data Collection Methodology
Data should be collected from a live system in the Order of
Volatility. The following guidelines give a clearer sense of the
types of volatile data that can be preserved to better understand
malware:
• On the compromised machine, run a trusted command
shell from an Incident Response toolkit
• Document system date and time, and compare them to a
reliable time source
• Acquire contents of physical memory
• Gather hostname, user, and operating system details
• Gather system status and environment details
• Identify users logged onto the system
• Inspect network connections and open ports
• Examine Domain Name Service (DNS) queries and
connected hostnames
• Examine running processes
• Correlate open ports to associated processes and
programs
• Examine services and drivers
• Inspect open files
• Examine command-line history
• Identify mapped drives and shares
• Check for unauthorized accounts, groups, shares, and
other system resources and configurations using
Windows “net” commands
• Determine scheduled tasks
• Collect clipboard contents
• Determine audit policy
Preservation of Volatile Data
After obtaining the system date/time, acquire physical
memory from the subject system prior to preserving
information using live response tools.
• Because each version of the Windows operating system
has different ways of structuring data in memory, existing
tools for examining full memory captures may not be able
to interpret memory structures properly in every case.
• Therefore, after capturing the full contents of memory, use
an Incident Response suite to preserve information from
the live system, such as lists of running processes, open
files, and network connections, among other volatile
data. A number of commonly used Incident Response
tool suites are discussed in the Tool Box section at the
end of this chapter.
• Some information in memory can be displayed by using
Command-line Interface (CLI) utilities on the system
under examination. This same information may not be
readily accessible or easily displayed from the memory
dump after it is loaded onto a forensic workstation for
examination.
Investigative Considerations
• It may be necessary in some cases to capture non-volatile
data from the live subject system, and perhaps even
create a forensic duplicate of the entire disk. For all
create a forensic duplicate of the entire disk. For all
preserved data, remember that the Message Digest 5
(MD5) and other attributes of the output from a live
examination must be documented independently by the
digital investigator.
• To avoid missteps and omissions, collection of volatile
data should be automated.
Physical Memory Acquisition on a Live Windows System
Before gathering volatile system data using the various
tools in a live response toolkit, first acquire a full memory
dump from the subject system.
• Running incident response tools on the subject system will
alter the contents of memory.
• To get the most digital evidence out of physical memory,
perform a full memory capture prior to running any other
incident response processes.
• There are a myriad of tools that can be used to acquire
physical memory, and many have similar functionality.
Often, choosing a tool comes down to familiarity and
preference. Given that every malware incident is unique,
the right tool for the job may be driven not just by the
incident type but by the victim system typology.
Investigative Considerations
• Remember that some tools are limited to certain operating
systems and capture only up to 4 gigabytes (GB) of
RAM; others can acquire memory from many different
RAM; others can acquire memory from many different
operating system versions, gather up to 64 GB of RAM,
and capture the Windows pagefile. If possible, determine
subject system details and select appropriate forensic
tools prior to beginning incident response. Having
numerous tool options available in your toolkit will avoid
on-scene frustration.
• In addition to assessing tool limitations based upon
operating system and memory capacity, also consider
whether to use a command-line utility or a graphical user
interface (GUI)-based tool.
• This section will explore some of the ways to acquire
physical memory contents, but consult the Tool Box
section at the end of this chapter for further tool
discussion and comparison.
Acquiring Physical Memory Locally
Physical memory dumps can be acquired locally from a
subject system using command-line or GUI utilities.
Command-line Utilities
A commonly used command-line tool for physical memory
acquisition is HBGary’s FastDump.1
• FastDump Community2 version is a free version of
FastDump that supports the acquisition of memory from
32-bit systems with up to 4 GB of RAM.
• FastDump Community version does not support Vista,
Windows 2003, Windows 2008, or 64-bit platforms.
Windows 2003, Windows 2008, or 64-bit platforms.
• Using FastDump Community version, the following
command captures the contents of memory from a
subject Windows system and saves it to a file on
removable media (Figure 1.2):
Figure 1.2 Acquiring physical memory with FastDump
• FastDump Pro3 is the commercially supported version of
FastDump, which supports all versions of Window
operating systems and service packs (2000, XP, 2003,
Vista, 2008 Server).
FastDump Pro can capture memory from both 32-bit
and 64-bit systems, including systems with more than 4
GB of RAM (up to 64 GB of RAM), and supports
acquisition of the Windows pagefile with the memory
dump.
• Using FastDump Pro, the following command captures
the contents of both memory and the pagefile from a
subject Windows system and saves it to a file on
removable media (Figure 1.3):
Figure 1.3 Acquiring physical memory with FastDump Pro
Other Tools to Consider
Additional command-line utilities to capture physical memory,
including Memoryze, Mantech DD and Moonsols Memory
Toolkit, are discussed in the Tool Box section at the end of this
chapter and on the companion Web site for the Malware
Forensic Field Guide,
http://www.malwarefieldguide.com/Chapter1.html.
GUI-based Memory Dumping Tools
Agile Risk Management’s Nigilant324 is a GUI-based incident
response tool.
• Nigilant32 provides an intuitive interface and simplistic
means of imaging a subject system’s physical memory
means of imaging a subject system’s physical memory
using a drop-down menu in the tool’s user console.
• To image memory from Nigilant32, select the “Image
Physical Memory” option from the “Tools” menu, as
shown in Figure 1.4.
Figure 1.4 Imaging physical memory with Nigilant32
• At the prompt, select the location where the memory
dump file will be saved; memory imaging will start
thereafter.
Remote Physical Memory Acquisition
Physical memory dumps can be remotely acquired from
a subject system using F-Response.
F-Response is an incident response framework that
implements the Microsoft iSCSI initiator service5 to provide
read-only access to the full physical disk(s) of a networked
computer, as well as to the physical memory of most Microsoft
Windows systems.6
• There are four versions of F-Response (Field Kit,
Consultant, Enterprise, and TACTICAL) that vary in
deployment method, but all provide access to a remote
subject system drive as a local mounted drive.
• F-Response is flexible and “vendor agnostic,” meaning
that any tool can be used to acquire an image of the
subject system’s hard drive and physical memory once
connected to it.
• F-Response Field Kit and TACTICAL are typically used
in the context of live response, particularly in scenarios
where the subject systems are at a third-party location
and F-Response Consultant Edition or Enterprise Edition
have not been deployed prior to the incident.
• F-Response Field Kit requires a single USB key FOB
dongle and the Field Kit executable (f-response-
fk.exe), both of which are initiated on subject system.
Conversely, the examiner system, which enables the
digital investigator to leverage the results of F-Response,
simply requires the installation and invocation of the
Microsoft iSCSI initiator service. F-Response
TACTICAL, which uses a distinguishable paired key
FOB deployment, is discussed in the Tool Box section at
the end of this chapter.
• To access the physical memory of the remote subject
system with an F-Response Field Kit, connect the USB
key FOB dongle to the subject system and execute F-
Response. Enter the proper subject system identifiers,
and enable “Physical Memory,” using the radio button,
as shown in Figure 1.5.
Figure 1.5 Using F-Response to connect to a subject system
• On your local examiner system, invoke the iSCSI initiator
service, select the “Discovery” tab, and add the subject
system as a target, as shown Figure 1.6.
Figure 1.6 Adding the subject system as a target through the
iSCSI initiator service
• Choose the “Advanced” option and provide the same
username and password credentials used in the F-
Response Remote Configuration (Figure 1.7).
Figure 1.7 Authenticating through the iSCSI initiator to acquire
the target system
• After authenticating, the subject system will appear as a
target. Select the subject system hard drive and physical
memory from the target list (requiring re-authentication)
and connect to the subject system; the connection status
will be displayed in the target list (Figure 1.8).
Figure 1.8 Connecting to the subject system
Figure 1.8 Connecting to the subject system
• Once connected to the subject system through F-
Response, the subject system’s hard drive can be
accessed locally on your examiner system, as shown in
Figure 1.9.
Figure 1.9 Viewing the remote subject system hard drive
through F-Response
• On your local examiner system, use the Disk
Management snap-in to verify that the physical memory
is also “mounted.”
• As physical memory does not have a file system or
partition table, the physical memory will not be
recognized as a drive, but rather as an unknown disk, as
shown in Figure 1.10.
Figure 1.10 Identifying physical memory from a remote subject
system
• I n Figure 1.11, Helix3 Pro7 was used to acquire the
• I n Figure 1.11, Helix3 Pro7 was used to acquire the
memory image from the remote subject system. The
Helix3 Pro Live CD was initiated on the examiner
system and identified the subject system’s physical
memory as a local drive (PhysicalDrive2); acquisition
was conducted by selecting PhysicalDrive2 as the item
to image.
Figure 1.11 Acquiring physical memory from a remote subject
system
Other Tools to Consider
Commercial remote forensics tools such as ProDiscoverIR and
OnlineDFS have been developed to capture full memory
contents from remote systems. These, and other remote
forensics tools, are discussed further in the Tool Box section at
the end of this chapter and on the companion Web site,
http://www.malwarefieldguide.com/Chapter1.html.
Collecting Subject System Details
System details are helpful for providing context to the
live response and post-mortem forensic process,
live response and post-mortem forensic process,
establishing an investigative time line, and identifying the
subject system in logs and other forensic artifacts.
Obtain the following subject system details:
• System date and time
• System identifiers
• Network configuration
• Enabled protocols
• System uptime
• System environment
System Date and Time
After acquiring an image of the physical memory from a
subject system, the first and last items that should be collected
during the course of conducting a live response examination are
the system date and time. This information will serve both as the
basis of your investigative time line—providing context to your
analysis of the system—as well as documentation of the
examination.
• The most common method to collect system date and
time is to issue the date /t and time /t commands from
a trusted command shell in your live response toolkit.
• After recording the date and time from the subject
system, compare them to a reliable time source to verify
the accuracy of the information.
• Identify and document any discrepancies for comparison
to the date and time stamps of other artifacts you
discover on the system.
System Identifiers
In addition to collecting the system date and time, collect as
much system identification and status information from the
subject host as possible prior to launching into live response
examination, including:
System Identifier Tool/Command
Host Name
Identify the name of the subject system
by using a trusted version of the
hostname utility, which is native to
Windows operating systems.
Current User Identify the current system user with the
whoami8 command
Operating
System/Environment
Collect system environment identifiers by
issuing the ver9 command.
IP address and
related network
identifiers
The ipconfig/all command is used to
display the IP address assigned to the
subject system, along with the system
hostname, network subnet mask, DNS
servers, and related details.
Network Configuration
When documenting the configuration of the subject system,
keep an eye open for unusual items.
• Look for a Virtual Private Network (VPN) adapter
configured on a system that does not legitimately use a
VPN.
• Determine whether a network card of the subject system
is in promiscuous mode, which generally indicates that a
sniffer is running.
• Several tools are available to query a network
configuration, including promiscdetect10 and
Microsoft’s promqry11 (which requires the .NET
framework).
Enabled Protocols
Document which protocols are enabled on the subject system
to help identify potential vectors of attack.
• Identify the protocols enabled on the subject system using
the URLProtocolView utility from NirSoft.12
System Uptime
Determine how long the subject system has been running, or
the system uptime.
• Knowing that the subject system has not been rebooted
since malware was installed can be important, motivating
digital investigators to look more closely for deleted
processes and other information in memory that
processes and other information in memory that
otherwise might have been destroyed.
• To determine system uptime, invoke the uptime13 utility
from your trusted toolkit, as shown in Figure 1.12.
Figure 1.12 Querying a system with the uptime command
System Environment
Documenting general details about the subject system,
including operating system version, patch level, and hardware, is
useful when conducting an investigation of a Windows system.
• System environment information may reveal that the
system is outdated and therefore susceptible to certain
attacks.
• Knowing the version of Windows can be helpful when
performing forensic examination of a memory dump.
• A granular snapshot of a subject system’s environment
and status can be obtained by querying the system with
psinfo,14 as shown in Figure 1.13 on the next page.
Figure 1.13 Collecting system information with psinfo
Identifying Users Logged into the System
After conducting initial reconnaissance of the subject
system details, identify the users logged onto the subject
system both locally and remotely.
Identifying logged on users serves a number of
investigative purposes, such as to:
• Help discover any potential intruders logged into the
compromised system.
• Identify additional compromised systems that report to
the subject system as a result of the malicious code
incident.
• Provide insight into a malicious insider malware incident.
• Provide additional investigative context by being
correlated with other artifacts discovered.
• Obtain the following information about identified users
• Obtain the following information about identified users
logged onto the subject system:
Username
Point of origin (remote or local)
Duration of the login session
Shares, files, or other resources accessed by the user
Processes associated with the user
Network activity attributable to the user
There are a number of utilities that can be deployed
during live response to identify users logged onto a subject
system, including PsLoggedOn,15quser,16netusers,17 and
loggonsessions.18
Psloggedon is a CLI utility that is included in the PsTools
suite that identifies users logged onto a subject system both
locally and remotely. In addition, PsLoggedOn reveals users that
have accessed a subject system from resource shares, such as
shared drives.
Inspect Network Connections and Activity
Network connections and activity on the subject system
can reveal vital information about an attacker’s
connection to the system, including the location of an
attacker’s remote data collection server and whether the
subject system is beaconing to a command and control
structure, among other things.
In surveying a potentially infected and compromised
system, try to obtain the following information about the network
activity on the subject system:
• Active network connections
• DNS queries made from the subject system
• NetBIOS name table cache
• ARP cache
• Internal routing table
Investigative Considerations
• In addition to network activity analysis, conduct an in-
depth inspection of open ports on the subject system,
including correlation of the ports to associated
processes. Port inspection analysis is discussed later in
this chapter.
Active Network Connections
An investigator should identify current and recent network
connections to determine (1) whether an attacker is currently
connected to the subject system, and (2) if malware on the
subject system is causing the system to call out, or “phone
home,” to the attacker, such as to join a botnet command and
control structure.
• Often, malicious code specimens such as bots, worms,
and Trojans have instructions embedded in them to call
out to a location on the Internet, whether a domain
name, Uniform Resource Locator (URL), or IP address,
or to connect to another Web resource to join a
collection of other compromised and “hijacked” systems
and await further commands from the attacker
responsible for the infection.
• To examine current network connections, a common
• To examine current network connections, a common
approach is to use a trusted version of the netstat19
utility on the subject system. Netstat is a utility native to
the various Windows operating systems that displays
information pertaining to established and “listening”
network socket connections on the subject system.
• For granularity of results, query with the netstat –ano
command (available on Microsoft Windows XP and
subsequent versions; see Figure 1.14), which along with
displaying the nature of the connections on the subject
system, reveals:
Whether the session is Transmission Control Protocol
(TCP) or UDP protocol
The status of the connection
The address of connected foreign system(s)
The process ID number of the process initiating the
network connection
Figure 1.14 Netstat –ano command
• Alternatively, the netstat –an command reveals the same
information but without the process ID associated with
the connection.
DNS Queries from the Host System
Many malware specimens have network connectivity
capabilities, whether to gather further exploits from a remote
location, join a command and control structure, or await further
commands from an attacker. Many times, the malware is hard
coded with connectivity instructions in the form of domain
names, which the program will attempt to query and resolve to
identify the location of the network-based resource to which it is
intended to connect.
• To collect the DNS queries made from a subject system,
issue the ipconfig/displaydns command from your
trusted toolkit.
NetBIOS Connections
When native Windows networking is involved, additional
details about active network connections may be available that
can be useful in an investigation. There may be volatile data
showing which computers were recently connected to the
subject system and what files were transferred.
• Windows networking uses the NetBIOS protocol, which
supports a variety of services, such as file and printer
sharing.
• Each computer that is configured with NetBIOS is
• Each computer that is configured with NetBIOS is
assigned a unique name used to communicate with
others.
• The NetBIOS name cache on a subject system is a
section in system memory that contains a mapping of
NetBIOS names and IP addresses of other computers
with which the subject system has had NetBIOS
communication.20
• The NetBIOS name cache is volatile and is preserved for
a limited period of time.
• Capture the NetBIOS name cache using a trusted version
of the native Windows utility, nbtstat with the –c option,
which displays a list of cached remote machine names
and their corresponding IP addresses.21
• Identify current NetBIOS sessions by using the nbtstat
–S option and the net sessions command.
• Identify if any files were recently transferred over
NetBIOS using the net file command.
ARP Cache
The Address Resolution Protocol (ARP) resolves Media
Access Control (MAC) addresses or Ethernet addresses
(residing at the Data Link Layer in the Open Systems
Interconnect (OSI) model) to IP addresses (residing at the
Network Layer of the OSI model).22
• The mapping of these addresses is stored in a table in
memory called the ARP cache or ARP table.
• Examination of a subject system’s ARP cache will identify
other systems that currently or recently have established
a connection to the subject system.
a connection to the subject system.
• To display the contents of the ARP cache, issue the arp –
a command23 from your trusted command shell, which
will reveal the IP address assigned to the subject system,
along with the IP addresses and MAC addresses
assigned to suspicious systems that are currently or have
recently had connections to the subject system.
Collecting Process Information
Collecting information relating to processes running
on a subject system is essential in malicious code live
response forensics. Once executed, malware specimens,
such as worms, viruses, bots, key loggers, and Trojans,
often manifest on the subject system as a process.
During live response, collect certain information
pertaining to each running process to gain process context, or a
full perspective about the process and how it relates to the
system state and to other artifacts collected from the system. To
gain the broadest perspective, a number of tools gather valuable
details relating to processes running on a subject system.
Although this chapter covers some of these tools, refer to the
Tool Box section at the end of this chapter and on the
companion Web site,
http://www.malwarefieldguide.com/Chapter1.html, for additional
tool options.
• Start by collecting basic process information, such as the
process name and Process Identification (PID), with
subsequent queries to obtain the following details:
Process name and PID
Process name and PID
Temporal context
Memory consumption
Process to executable program mapping
Process to user mapping
Child processes
Invoked libraries and dependencies
Command-line arguments used to invoke the process
Associated handles
Memory contents of the process
Relational context to system state and artifacts
Process Name and Process Identification
The first step in gaining process context is identifying the
running processes, typically by name and associated PID.
• To collect a simple list of running processes and assigned
PIDs from our subject system, use tlist,24 a
multifunctional process viewer utility for Windows
distributed with Debugging Tools for Windows.
Temporal Context
To gain historical context about the process, determine the
period of time the process has been running.
• Obtain process activity times by using pslist in the
PsTools suite.
• The pslist utility displays, among other details:
• The pslist utility displays, among other details:
The names of running processes
Associated PIDs
The amount of time each process has been running on a
system
Memory Usage
Examine the amount of system resources that processes are
consuming. Often, worms, bots, and other network-centric
malware specimens are “active” and can be noticeably resource-
consuming, particularly on a system with less than 2 GB of
RAM.
• To get output identifying running processes, associated
PIDs, and the respective memory usage of the
processes, use a trusted version of the tasklist utility
with no switches.25
Process to Executable Program Mapping: Full System
Path to Executable File
Determine where the executable images associated with the
respective processes reside on the system. This effort will
provide further contextual information, including whether an
unknown or suspicious program spawned the process, or if the
associated program is embedded in an anomalous location on
the system, necessitating a deeper investigation of the program.
• To get an overview of the running processes and
associated location of executable program locations, use
PRCView (pv.exe)26 with the -e switch, as shown in
Figure 1.15.
Figure 1.15 Using PRCView to reveal the location of
executables associated with running processes
Process to User Mapping
During the course of identifying the executable program that
initiated a process, determine the owner of the process to gain
user and security context relating to the process. Anomalous
system users or escalated user privileges associated with running
processes are often indicative of a rogue process.
• Using tasklist with the –V switch, identify the program
name, PID, memory usage, program status, and
associated username.
Child Processes
Often upon execution, malware spawns additional processes,
or child processes. Upon identifying a potentially hostile process
during live response, analyze the running processes in such a way
as to identify the hierarchy of potential parent and child
processes.
• Query the subject system with any of the following
commands to obtain a structured and hierarchical “tree”
view of processes.
While inspecting running processes on a system, determine the
While inspecting running processes on a system, determine the
command-line instructions, if any, that were issued to initiate the
running processes. Identifying command-line parameters is
particularly useful if a rogue process already has been identified,
or if further information about how the program operates is
sought.
• The command-line arguments associated with target
processes can be collected by querying a subject system
with any of the following commands.
Tool Command
Cmdline
Invoking cmdline with no switches displays the
process ID number, the full system path, and the
executable file associated with each process running
on the system. By issuing the –pid argument and
supplying the PID number of a specific process of
interest, cmdline will only display information relating
to that process.
Tlist tlist –c
PRCViewpv –l
File Handles
Another important aspect to examining running processes is to
identify handles opened by the respective processes. System
resources like files, threads, or graphic images are data
resources like files, threads, or graphic images are data
structures commonly referred to as objects. Often, programs
cannot directly access object data and must rely upon an object
handle to do so.
• Each handle has an entry in an internally maintained
handle table containing the addresses of the resources
and the means to identify the resource type.
• To get additional context about the nature of running
processes, obtain information about which handles and
associated resources the processes are accessing by
using the handle27 utility.
• The handle utility has a number of switches that can be
applied, but for the purpose of revealing all handles
related to the running processes, use the handle –a
command.
Dependencies Loaded by Running Processes
Dynamically linked executable programs are dependent upon
shared libraries to successfully run. In Windows programs, these
dependencies are most often Dynamic Link Libraries (DLLs)
that are imported from the host operating system during
execution. Identifying and understanding the DLLs invoked by a
suspicious process can potentially define the nature and purpose
of the process.
• Many malicious code specimens, particularly rootkits, use
a technique called “DLL injection,” wherein malware
“injects” code into the address space of a running
process by forcing it to load a dynamic link library.28
• A great utility for viewing the DLLs loaded by a running
process is listdlls,29 which identifies the modules
process is listdlls,29 which identifies the modules
invoked by a process and reveals the full path to the
respective modules. Other utilities to consider for this
task include Procinterrogate,30 PRCView,31 and
ListModules.32
Exported DLLs
To discover the DLLs exported by an executable program
that launched a process—that is, identifying the functions or
variables made usable by other executable programs—consider
querying a subject system with NirSoft’s DLLExportViewer.33
• DLLExport view provides the investigator with the
exported function name, address, relative address, file
name, and full path of the module.
Capturing the Memory Contents of a Process on a Live Windows
System
During the course of examining running processes on a subject
system, potentially rogue processes may be identified. In addition
to locating and documenting the potentially hostile executable
programs, capture the individual process memory contents of the
specific processes for later analysis, as described in Chapter 2.
Correlate Open Ports with Running
Processes and Programs
In addition to identifying the open ports and running
processes on a subject system, determine the executable
program that initiated a suspicious established connection
or listening port, and determine where that program
resides on the system.
Examining open ports apart from active network
connections is often inextricably intertwined with discoveries
made during inspection of running processes on a subject
system.
• When examining active ports on a subject system, gather
the following information, if available:
Local IP address and port
Remote IP address and port
Remote host name
Protocol
State of connection
Process name and PID
Executable program associated with process
Executable program path
User name associated with process/program
• Process-to-port correlation can be conducted by
querying a subject system with any of the following
commands. Further details regarding the tools referenced
in this table can be found in the Tool Box section at the
end of the chapter and on the companion Web site,
http://www.malwarefieldguide.com/Chapter1.html.
Tool Command Information Gathered
Netstat
netstat -ano
netstat –anb
[the “b” option
requires
escalation (i.e.
Run As
Administrator)]
Displays protocol, status of
connection, foreign address in
connection, PID of process initiating
connection.
When investigating Windows XP
(SP2) and newer Windows
operating systems, this command
correlates open ports with
associated processes and displays
the executable program and related
components sequentially involved in
creating each connection or listening
port, as shown in Figure 1.16,
below.
Openports -lines and –
path
Provides a clear structured
perspective of the active ports
associated process and executable
programs along with the system path
where the respective programs
reside.
Fport
/p
/a
/i
/ap
Sort by port
Sort by process
Sort by PID
Sort by process path
/ap Sort by process path
CurrPorts /stext
Provides a detailed snapshot of the
process name, PID, local and
remote port numbers and IP
addresses, port state, protocol,
executable program path, and other
detailed identifying information.
Figure 1.16 Results of the netstat –anb command on a subject
system
Identifying Services and Drivers
Many malware specimens will manifest on a subject
system as a service or surreptitiously install driver files.
Examining Running Services
Microsoft Windows services are long-running executable
applications that run in their own Windows sessions; they do not
require user initiation or interaction.34 Services can be configured
to automatically start when a computer is booted up, paused,
and restarted without showing up in any user interface. Malware
can manifest on a victim system as a service, silently running in
the background, unbeknownst to the user.
• As with the examination of running processes and ports,
explore running services by first gaining an overview and
then applying tools to extract information about the
services with more particularity.
• While investigating running services, gather the following
information:
Service name
Display name
Status
Startup configuration
Service description
Dependencies
Executable program associated with service
Process ID
Executable program path
User name associated with service
• Gain a good overview of the running services on a subject
system by using a trusted version of tasklist with the
/svc switch, which displays services in each process.
• The output from this command provides a concise listing
of the executable program name, PID, and description of
the service, if applicable.
• To gather greater detail about running services, refer to
the Tool Box section at the end of this chapter and on
the Tool Box section at the end of this chapter and on
the companion Web site,
http://www.malwarefieldguide.com/Chapter1.html.
Examining Installed Drivers
In addition to determining the running services on a subject
system, consider examining the installed drivers on the system,
including the nature and status of the drivers.35
• To explore installed system drivers, query the subject
system with a trusted version of List Loaded Driver
(drivers.exe)36 and DriverView.37
• The output provided by List Loaded Drivers
(drivers.exe) is verbose and granular. Compare a
thorough examination of any suspicious files acquired
from the subject system against the collected data to
identify artifacts of value.
Determining Open Files
Open files may identify the nature of the malicious
code that has infected a system by revealing the services or
resources that the specimen requires to effectively launch
or operate.
• Open files may reveal other correlating or identifying
information about suspicious processes identified during
the course of live response.
• If malware has given the attacker access into the
• If malware has given the attacker access into the
compromised system, the attacker, during the course of
intrusion, may have opened certain files.
• Identifying open files may explain the purpose of the
attack, whether probing financial databases, sensitive
corporate information, or other unique resources on the
system.
• Examine files opened locally and remotely.
Identifying Files Opened Locally
• To examine files opened locally, query the subject system
with OpenFilesView.38
• OpenedFilesView displays a list of all opened files on a
subject system and additional information about the
accessed files, such as:
The process that opened the file
The associated handle value
Read/write/delete access times; and
File location on the system
Identifying Files Opened Remotely
• A remote connection from an anomalous system or share
accessing files on the subject system are potentially
indicia of compromise, so endeavor to identify files that
are accessed remotely.
• Query the subject system with a trusted version of the
• Query the subject system with a trusted version of the
native net file command or the psfile utility.39
Collecting Command History
Keystrokes typed by an attacker (or nefarious insider)
into a Windows command prompt that remains open can
be retrieved during live response.
• Display all of the commands that are stored in memory by
issuing the doskey/history40 command from the
toolkit’s trusted command prompt.
• The doskey/history command can be configured to hold
a maximum of approximately 61,900 bytes of data.
• Command prompt history can provide valuable contextual
evidentiary information, such as:
The names of files and folders accessed
Commands issued
Programs launched
Unique string names
Network identifiers such as domain names, IP addresses,
shares, and resources
Identifying Shares
Although malicious code does not always exhibit the
ability to propagate through network shares, some
specimens identify and affect shares on an infected
specimens identify and affect shares on an infected
system.41
• To query a subject system to identify available shares, use
a trusted version of the native Windows utility, net, as
seen in Figure 1.17.
Figure 1.17 Identifying shares on a subject system
Determining Scheduled Tasks
Some malicious code variants are “event-driven,”
meaning that until a certain date or event triggers
execution, the malware remains dormant.
Event-driven malware is typically referred to as a logic
bomb. Typically, most logic bomb malware specimens are
planted and secreted by a malicious insider, particularly by those
users with administrative access to systems.42 However, some
external malicious code threats have displayed logic bomb
features.43 Thus, examine a subject system for scheduled tasks
to ensure that a malicious program is not hidden away waiting to
execute.
• Reveal discovered scheduled tasks on a subject machine
using a trusted version of the native Windows utility at.44
• Confirm your findings by querying with schtasks,45 which
is also native to Windows XP and subsequent versions.
Collecting Clipboard Contents
In the instance of a potentially compromised system
wherein the infection vector is unknown, the clipboard
contents can potentially provide substantial clues into the
nature of an attack, particularly if the attacker is an
insider “threat” and has copied bits of text to paste into
tools or attack strings.
• The clipboard contents may contain:
Domain names
IP addresses
E-mail addresses
Usernames and passwords
Hostnames
Instant messenger chat or e-mail content excerpts
Attack commands
Other valuable artifacts identifying the means or purpose
of the attack
• Examine the contents of a subject system’s clipboard with
pclip,46 which collects and displays the contents of the
clipboard, seen here in Figure 1.18.
Figure 1.18 Exploring the clipboard contents with pclip.exe
Non-Volatile Data Collection from a Live
Windows System
Traditionally, forensic examiners do not access files on the hard
drive of a live system because of the potential risk of altering
stored data. However, some situations require selective forensic
preservation and examination of data in files and within the
registry of live systems. In some cases, the quantity of non-
volatile data on a computer’s system is so large that its
preservation is not feasible.
Expending resources to create a forensic duplicate of a
server that contains terabytes of documents and other data
unrelated to the malware incident may not make sense. Instead,
acquiring only the information that is generally the most relevant
and useful may be the better approach. Similarly, in cases
involving a large number of computers, forensic duplication of
only critical systems coupled with information gathering from the
remaining machines may best support the victim’s needs or
ability to pursue legal or other remedies.
Analysis Tip
Handle with Care
Whether to collect non-volatile data from a live system must be
carefully considered. Operating a live system inevitably makes
changes, like updating last accessed dates of files. Whether such
changes will hinder the investigation or alternatively be deemed
an acceptable loss of information for the benefit of acquiring
usable digital evidence is a judgment call. In certain cases, the
only option may be to collect non-volatile data from a live
system. From a business interference standpoint, the system
owner may be unable to accept actions that would disrupt the
system (i.e., transaction server processing thousands of credit
card transactions a minute). In such cases, obtain written
confirmation of authorization to perform actions that could result
in a reboot, temporary loss of service, or other perceived
disruption. Once the decision is made to perform preservation
processes on a live system, take great care to minimize changes
and thoroughly document actions taken to both distinguish them
from the effects of malware and defend them in court, if
necessary.
Forensic Duplication of Storage Media on a Live Windows
System
When dealing with high availability servers and other
systems that cannot be shut down, create a forensic
duplicate of the entire system while the computer is still
running.
The same approaches to preserving physical memory on
a live system can be used to acquire a forensic duplicate of any
storage media connected to the system.
• The following command takes the contents of an internal
hard drive and saves it to a file on removable media
along with the MD5 hash (for integrity/validation
purposes) and an audit log that documents the collection
process (Figure 1.19).
Figure 1.19 Forensic duplication of a hard drive using dd
Investigative Considerations
• Saving a forensic duplicate of the hard drive in a live
system onto another computer on the local area network
is generally faster than saving to removable media,
depending on the throughput.
• Save the forensic duplicate on a remote computer either
via an SMB share on the remote system or using the
netcat command. Remote forensic tools such as
EnCase Enterprise, OnlineDFS, and ProDiscoverIR also
have the capability of acquiring a forensic duplicate of
the hard drive from a remote system.
Forensic Preservation of Select Data on a Live Windows
System
Certain areas of a live Windows computer commonly
contain information about the installation and operation
of malware.
Methodical approaches to extracting evidence from these
areas are presented in the following list. These approaches are
not intended to be comprehensive or exhaustive, but rather
provide a solid foundation for the discovery of evidence relating
to malware resident on a live Windows computer.
• When more extensive forensic analysis is required, such
as hash analysis and keyword searching, work should be
performed on a forensic image, as discussed in Chapter
3. Although the tools covered in this section are designed
to run on live Windows systems, some also are useful in
post-mortem analysis.
• The following non-volatile data analysis can aid in
understanding the malware:
Assess security configuration
Acquire host files
Examine prefetch
Review auto-start
Examine logs
Review user accounts
Examine file system
Examine registry
Assess Security Configuration
Determining whether a system was well secured can
Determining whether a system was well secured can
help assess the risk level of the host to misuse,
vulnerabilities, and possible vectors of attack.
• Collect patch level and version information for a
Windows system using the WinUpdatesList utility.47
• Logging level and access control lists can be extracted
using auditpol48 and dumpsec.49
• If security logging is not enabled, there will most likely be
no log entries in the Security Event Log.
• When a system is configured to record security events but
the Security Event Log is empty, ascertain whether the
logs are stored elsewhere or were intentionally cleared.
Assess Trusted Host Relationships
Preserve the files in “%windir%\system32\drivers\etc\”
that contain information about trusted hosts and
networks.
These files are used for localized name resolution,
without relying on DNS.
• The “hosts” file contains associations between IP
addresses and hostnames.
• The “networks” file contains associations between ranges
of IP addresses and network names, which are generally
assigned by network administrators.
• The “lmhosts” file contains associations between the IP
address and NetBIOS names.
As shown in Figure 1.20, the contents of these files can be
displayed without modification and saved into individual log files
displayed without modification and saved into individual log files
using a trusted version of the Windows type command.
Figure 1.20 Collecting hosts, networks, and lmhosts from a
subject system
Investigative Considerations
• Examine these logs for modifications. Some malware
alters the contents of these files to block access to major
anti-virus and Microsoft sites, thus preventing a
compromised host from receiving security patches and
anti-virus updates.
Inspect Prefetch Files
To improve efficiency when a program is executed, the
Windows operating system creates a “prefetch” file that
enables speedier subsequent access to the program.
Anomalous prefetch files are potential artifacts evidencing
compromise of the subject system.
• Prefetch files are located in “%systemroot%\Prefetch”
and, among other information, contain the name of the
and, among other information, contain the name of the
program when it was executed.
• The creation date of a particular prefetch file generally
shows when the associated program was first executed
on the system, and the last modified date indicates when
it was most recently executed.
• To document the creation and last modified dates of files
in the prefetch directory, use a trusted command shell
(cmd.exe) to invoke the following commands (see Figure
1.21):
Figure 1.21 Listing prefetch files from a trusted command shell
When a system is rebooted, the number of places where
Windows automatically starts programs serve as
persistence mechanisms for malware.
These auto-starting locations exist in particular folders,
registry keys, system files, and other areas of the operating
system.
• References to malware embed in these auto-starting
locations to increase the malware’s longevity on a
computer.
• One of the most effective tools for viewing auto-start
• One of the most effective tools for viewing auto-start
locations is AutoRuns,50 which has both GUI and
command-line versions (autorunsc).
• Query a subject system for all auto-starting entries using
the autorunsc –a command.
• AutoRuns has a feature to ignore legitimate, signed
Microsoft items, reducing the volume of output.
Investigative Considerations
• Be aware that there will generally be a large number of
legitimate third-party programs in auto-start locations.
Inspect most, or all, of these executables to best identify
the extent of the malware on the system (see Figure
1.22).
Figure 1.22 AutoRuns discovering a suspect program
Collect Event Logs
Many activities related to a malware incident can
generate entries in the Event Logs on a Windows system.
Look for failed logon attempts recorded in the Security
Event Log and anti-virus warning messages recorded in the
Application Event Log.
• These logs are stored in a proprietary Microsoft format;
extract them in American Standard Code for Information
Interchange (ASCII) text form for examination using log
analysis tools that do not support the native Event Log
format.
• Collecting these logs from the live system will extract the
native message strings from that system.
• These logs can be collected using eldump, a utility
specifically designed to process Event Logs from
Windows systems. The same utility also can be used to
read saved Event Log files.51
• As shown in Figure 1.23, to collect specific event logs
from a subject system with eldump use the –l switch and
the name of the log (security, system, or application).
Figure 1.23 Collecting Event View Logs with eldump.exe
Logon and Logoff Events
To obtain a list of logon and logoff events associated with
To obtain a list of logon and logoff events associated with
associated users, use the NTlast utility.52
• This information may be particularly pertinent when a
malicious insider is the suspected wrongdoer, as
opposed to an “outside” attacker.
Review User Account and Group Policy Information
A close inspection of user accounts local to the
compromised system, or domain accounts used to log in,
can reveal how malware was placed on the computer.
Look for the unauthorized creation of new accounts,
accounts with no passwords, or existing accounts added to
Administrator groups.
• Check for user accounts that are not supposed to be in
local or domain level administrator groups.
• The net user command can be used to list all accounts
on the local system.
Examine the File System
A quick review of certain types of files can reveal
relevant information and provide additional context to
collected volatile data.
Identify hidden files, alternate data streams, and files in
the Recycle Bin.
• The HFind and SFind53 utilities in the Forensic Toolkit
• The HFind and SFind53 utilities in the Forensic Toolkit
from Foundstone can be used to locate alternate data
streams and files that are hidden from the general user by
the operating system and can be listed using HFind.
• A list of files that have been placed in the Recycle Bin can
be obtained by reading the INFO file using a tool like
Foundstone’s rifiuti.54
Investigative Considerations
• Also consider acquiring file system metadata relating to
file time stamps for additional temporal context.
When the time frame of the malware incident is known,
metadata for all files created, modified, or accessed
during that period can be obtained using the
macmatch.exe55 utility.
For instance, the following command (Figure 1.24) lists
all files created between March 26 and 28 in 2010.
Figure 1.24 Using macmatch.exe
Dumping and Parsing Registry Contents
Although there are tools for examining Registry files
in their native format, extracting the contents in ASCII
text form can facilitate examination and searching.
There are several tools for extracting information from
the Registry on a live system, such as the native Windows utilities
reg.exe and, regdump.exe,56 and the Systemtools.com
dumpreg57 utility.
• In addition to dumping the entire Registry contents to a
text file, particular areas of interest can be processed
individually.
• Details about the Universal Serial Bus (USB) devices that
have been plugged into the system can be extracted from
the Registry with USBView.58 This information may be
particularly valuable in the instance of a malicious insider,
wherein the infection vector was from a physical access
to a system, such as a USB device. Alternately, a user
may have inadvertently used a USB device infected with
malware that exploits Windows autorun functionality.59
• Examination of the Registry is covered in more depth in
Chapter 3 in the context of a full post-mortem forensic
examination of a compromised system.
Remote Registry Analysis
Registry contents can be acquired from a live subject
system remotely with F-Response.
As a discussed earlier in this chapter, F-Response
provides read-only access to the full physical disk(s) of a
networked computer, as well as the physical memory of most
Microsoft Windows systems.
• To access the Registry of a remote subject system with an
F-Response Field Kit, initiate F-Response on the
system, as shown in Figure 1.25.
Figure 1.25 Using F-Response to connect to a subject system
• On your examiner system, invoke the iSCSI initiator
service and select the “Discovery” tab to add the subject
system as a target, as shown Figure 1.26.
Figure 1.26 Adding the subject system as a target through the
Figure 1.26 Adding the subject system as a target through the
iSCSI initiator service
• Choose the “Advanced” option and provide the same
username and password credentials used in the F-
Response Remote Configuration (Figure 1.27).
Figure 1.27 Authenticating through the iSCSI initiator to acquire
the target system
• After authenticating, the subject system will appear as a
target. Select the subject system from the target list
(requiring re-authentication) and connect to the subject
system; the connection status will be displayed in the
target list (Figure 1.28).
Figure 1.28 Connecting to the subject system
• Once connected to the subject system F-Response, the
subject system’s hard drive can be accessed locally on
your examiner system, as shown in Figure 1.29.
Figure 1.29 Remote subject system hard drive through F-
Response
• On your local analysis system, invoke RegRipper,60 a
Windows Registry data extraction and correlation tool
created and maintained by Harlan Carvey. As F-
Response has made the subject system drive accessible
locally, RegRipper can be pointed at the target
NTUSER.dat file of the subject system for data
extraction (Figure 1.30).
Figure 1.30 Selecting the target NTUSER.dat from the subject
system using RegRipper
• RegRipper is a Windows Registry data extraction and
correlation tool written in Perl. Unlike other Registry
analysis tools, RegRipper is modular and uses plug-ins to
access specific Registry hive files, and in turn, to access
and extract specific keys, values, and data. RegRipper
accomplishes this through bypassing the Win32API.
• RegRipper’s plug-in-based architecture allows users to
develop custom plug-ins, many of which are shared with
the digital forensic community on the RegRipper Web
site.61
• Examination of the Registry is covered in more depth in
Chapter 3, in the context of a full post-mortem forensic
examination of a compromised system.
Examine Web Browsing Activities
With the increasing number of vulnerabilities in Web
With the increasing number of vulnerabilities in Web
browsers and the potential for unsafe browsing practices,
an examination of Web browser artifacts may reveal how
malware was placed on a system.
Client-side exploits have become more and more
prevalent, particularly through “drive-by-downloads.”
• Drive-by-downloads often occur when a user with an
insecure or improperly configured Web browser
navigates to a compromised (or nefarious) Web site that
is surreptitiously hosting malware, allowing the malware
to silently be downloaded onto the victim system.
• As a result, it is always advisable to examine the subject
system Web history to gain insight into whether a Web-
based vector of attack caused the malicious code
incident.
• Internet Explorer history files (index.dat) can be parsed
with Pasco, a free multiplatform command-line utility
offered by Foundstone. The results processed by Pasco
are output into a field delimited text file, enabling the
digital investigator to import into as spreadsheet to
further analyze these data.
• In addition to Pasco, there are numerous utilities available
to parse Web history artifacts associated with specific
Web browsers, as described in detail in the Tool Box
section of this chapter.
Examine Cookie Files
Similar to the correlative clues that can be gained through
reviewing the Web browsing history on a subject system, cookie
files also can provide insight into how malware may have been
placed on a victim system.
placed on a victim system.
• Information from cookie files can be acquired using
Galleta62 for Internet Explorer and
MozillaCookiesView63 for Firefox.
Inspect Protected Storage
If user accounts accessed from the subject system (such as e-
mail accounts and password-protected Web site logins) were
discovered to be compromised after a malicious code incident, it
is possible that malware may have harvested the protected
storage (also referred to as “pstore”) from the subject system (or
a key logger was installed).
• Protected storage may contain passwords stored by
Internet Explorer and other programs, providing the
attacker with stored user credentials on the system.
• This information can be gathered with NirSoft’s GUI and
CLI utility Protected Storage PassView (pspv.exe).64
• Contents of the Firefox AutoComplete and Protected
Storage areas can be extracted using the
DumpAutocomplete65 utility.
Malware Artifact Discovery and Extraction from a Live
Windows System
After identifying suspicious files on a subject system,
extract them for further analysis in your malicious code
laboratory. Additionally, consider browsing the system in
laboratory. Additionally, consider browsing the system in
a forensically sound manner for additional artifacts of
compromise.
Extraction can be accomplished with a variety or tools,
including Nigilant32, F-Response, HBGary’s FGET,66 and
Helix3 Pro, among others.
Extracting Suspicious Files
As discussed previously in the Memory Acquisition section of
this chapter, Agile Risk Management’s Nigilant32 67 is a GUI-
based incident response tool useful for extracting and analyzing
suspicious files. Valuable information about these suspicious files
can be obtained using the Nigilant32 File System Review
functionality.
• To use this function, select the “Preview Disk” function
within Nigilant32, accessible from the user console.
• After selecting this option, select the partition of the
subject hard drive to explore, as displayed in Figure
1.31.
Figure 1.31 Previewing the hard drive of the subject system
with Nigilant32
• The Preview Disk function uses code68 from Brian
Carrier’s forensic analysis framework, the Sleuth Kit,69
to examine the active file system and minimize any
potential modifications caused by the native Windows
API.
• Use this feature on a subject computer to explore its file
system, locate hidden files or folders or recently deleted
content, or extract files for additional analysis.
• Double click on a folder of interest, double click on a file
of interest, and review the populated file contents display
panels located below the main display pane, as seen in
Figure 1.32.
Figure 1.32 Examining file contents with Nigilant32
• Each display panel provides different information
pertaining to the selected file.
The first panel displays the hexadecimal offset for each
line in the file.
The second panel shows the contents of the file in
hexadecimal format.
The third and final panel reveals the contents of the file in
ASCII format, similar to using a utility to display
embedded strings.
• After discovering files of interest, you can extract the files
to an external source, such as a USB ThumbDrive or
external hard drive, using the Nigitlant32 “Extract File”
function shown in Figure 1.33. Using this function, you
can select the location and name of the suspect file you
want to extract, and in turn, the location where you want
to save the extracted file specimen.
Figure 1.33 Extracting our suspect file using the Nigilant32
Extract File feature
Extracting Suspicious Files with F-Response
Recall from the Memory Acquisition and Remote Registry
Analysis sections of this chapter that, F-Response is an incident
response framework that implements the Microsoft iSCSI
initiator service to provide read-only access to the full physical
disk(s) of a networked computer.
• Leveraging this functionality, you can locate and extract
suspicious files and associated artifacts from a suspect
system drive that is mounted locally with F-Response.
• After initiating F-Response, the subject system drive can
be “seen” locally on your examination system, as shown
in Figure 1.34.
Figure 1.34 Extracting suspect files using F-Response
• You can navigate the suspect drive locally to locate and
extract files of interest, just as you would your local hard
drive.
Conclusions
• Live Windows systems contain a significant amount of
volatile data that will be lost when the system is shut
down. These volatile data can provide critical details
about malicious code on the subject system, such as data
that it has captured and network connections that it has
established. There are a wide variety of tools for
preserving such data, many of which were demonstrated
in this chapter.
• Independent of the tools used and the operating system
under examination, a preservation methodology must be
established to ensure that available volatile data are
captured in a manner that is as consistent and repeatable
as possible. For forensic purposes, and to maintain the
integrity of the data, keep detailed documentation of the
steps taken on the live system.
• The methodology in this chapter provides a general robust
foundation for the forensic preservation of volatile data
on a live Windows system. It may need to be altered for
on a live Windows system. It may need to be altered for
certain situations. The approach is designed to capture
volatile data as a source of evidence, enabling an
objective observer to evaluate the reliability and
accuracy of the preservation process and the acquired
data.
• Collecting volatile data is a delicate process and great
care must be taken to minimize the changes made to the
subject system during the preservation process.
Therefore, extensive examination and searching on a live
system is strongly discouraged. If the system is that
interesting, take the time to create a forensic duplicate of
the disk for examination, as covered in Chapter 3.
• Do not trust the operating system of the subject system,
because it may give incomplete or false information. To
mitigate this risk, seek corroborating sources of
evidence, such as port scans and network logs.
Pitfalls to Avoid
Lacking familiarity with tools, techniques, and protocols
prior to an incident
Do not wait until an actual malicious code incident to become
familiar with the forensic process, techniques, and tools you are
going to use to investigate a subject system.
Practice live response techniques by using your tools in
a test environment to become and remain proficient.
a test environment to become and remain proficient.
Attend relevant training when possible. Budget
constraints, time constraints, and other factors often
make it difficult to attend formal training. If you cannot
attend, improvise. Attend free webinars; watch Web-
based tutorials; self-study texts, whitepapers, and blogs;
and attend local information security group meetings.
Stay current with tools and techniques. Live response is
a burgeoning area of digital forensics; almost daily there
are new tools or tool updates released, new research,
and techniques discussed. Keeping tabs on what is
current will likely enhance the scope of your live
response knowledge base and skills.
Stay abreast of new threats. Similar to staying current
with tools and techniques, the converse is just as
important—staying current on malicious code trends,
vulnerabilities, and vectors of attack.
Utilize online resources such as social networks and
listservs. It is often difficult to find time to attend training,
read a book, or attend a local information security group
meeting. A great resource to stay abreast of live
response tools and techniques is with social network
media such as Twitter and Facebook. Joining specific
lists or groups on these media can provide real-time
updates on topics of interest.
Failing to test and validate your tools
Do not deploy tools on a subject system without first having a
clear understanding of what your tools’ functionalities, limitations,
and “footprint” on a system are.
and “footprint” on a system are.
Research tools that you intend to incorporate into your
live response toolkit. Are they generally accepted by the
forensic community? Are there known “bugs” or
limitations to be aware of? Have you read all
documentation for the tools?
Deploy the tools in a test environment to verify
functionality and gain a clear understanding of how each
tool works and how it impacts the target system it is
deployed on.
Document your findings—notes regarding your tools
are not only a valuable reference, but can come in handy
for report writing.
Using improperly licensed commercial tools
Do not use “cracked” or “bootlegged” tools.
Remember that your investigation may end up in a legal
proceeding, whether criminal, civil, or administrative.
Having to explain that you used tools during the course
of your investigation that were illegally or unethically
obtained can damage your credibility—and potentially
your investigation—despite how accurate and thorough
your analysis and work product is.
Not conducting interviews prior to conducting live
response
Failing to conduct interviews of relevant parties prior to
conducting live response may cause you to miss important
details.
Conducting interviews of relevant parties prior to
conducting live response provides you with information
about the subject system, including the circumstances
surrounding the incident, the context of the subject
system, and intricacies about the system or network that
are salient to your investigation.
Running non-trusted tools directly from the subject system
Do not run Live Response tools directly from the subject
system.
The subject system is an unknown and untrustworthy
environment in which the collection of volatile data can
be tainted as a result of the infected system. Running
tools directly from a subject system relies on the
system’s operating system, which may be compromised
by malware, making the acquired data unreliable.
Make sure to use a run trusted command shell/tools
from an Incident Response toolkit.
Not using forensically sound/clean acquisition media
Do not contaminate your data by acquiring them on “dirty”
Do not contaminate your data by acquiring them on “dirty”
media.
Always ensure that the media you are using to acquire
live response data are pristine and do not contain
unrelated case data, malicious code specimens, and
other artifacts from previous investigations.
Always inspect your toolkit and acquisition media prior
to deployment.
Be cognizant that USB devices are common malicious
code vectors—the malware you are investigating can
propagate and infect your live response media by virtue
of connecting to the system.
Not following the order of volatility
Losing critical evidence.
As discussed in the introduction to this book and
Chapter 1, while powered on, a subject system contains
critical ephemeral information that reveals the state of the
system.
The purpose of live response is to gather this volatile
information in a forensically sound manner so that it is not
lost. Failing to follow the Order of Volatility and
gathering less volatile information impacts the state of
volatile data on the system (e.g., memory contents) and
increases the risk of losing the data altogether. Network
connections, process states, and data caches can quickly
change if not acquired in timely manner.
Failing to document the system date and time
Forgetting to document the system date and time and
compare them to a reliable time source at the beginning of live
response can prove problematic for your investigation.
The system date and time are essential details about the
suspect system that will serve as the baseline for
temporal context in your investigation.
Make sure to document the system date and time in
your investigative notes in addition to acquiring the date
and time through your live response toolkit.
Not acquiring the contents of physical memory at the
beginning of the live response process
Contaminating/impacting the evidence by leaving a “deep
footprint” in it.
As demonstrated in this chapter, the contents of
physical memory are impacted by running live response
tools on a subject system.
Acquire physical memory before conducting other live
response processes in an effort to keep the memory
contents as pristine as possible when acquired.
Gathering incomplete system details
Gathering incomplete system details
Incomplete system details can potentially affect the context
surrounding your subject system.
Make sure to gather as many details about the subject
system as possible, giving you deep context about and
surrounding the system. For instance, vital details such as
system date/time and system uptime are foundational in
establishing a time line surrounding the malicious code
incident.
Gathering the subject system’s hostname, IP address,
and other network-based identifiers is critical in
examining the relational context with other systems on
the network.
Failing to determine if the attacker is still logged into the
subject system
Do not let the attacker know you are investigating them.
Conducting live response while an attacker is on the
subject system will most likely alert the attacker to your
investigation.
Alerting the attacker can potentially have devastating
consequences to your investigation and to the subject
system (and other systems on the network), such as
destruction of evidence, escalation of attacks, or
additional compromises to maintain inconspicuous,
undiscoverable, and continual access to the system.
undiscoverable, and continual access to the system.
Failing to conduct a holistic investigation
Failing to obtain complete context about the suspect system
and the malicious code event.
Conducting a “flat” or incomplete investigation into a
subject system will limit your understanding about the
malicious code incident, the impact on the subject
system, and the nature and purpose of the attack.
Conduct a complete and thorough investigation,
gathering multiple perspectives on the data so that a
complete analysis can be conducted. For example, in
collecting information about running processes from a
subject system, simply gathering a list of running
processes without more provides the digital investigator
with insufficient information about the processes and their
relational context to other evidence.
Incomplete or sloppy documentation
Do not jeopardize your investigation by poorly documenting
it.
As discussed in the introduction to this book, one of the
keys to forensic soundness is documentation.
A solid case is built on supporting documentation that
reports where the evidence originated and how it was
reports where the evidence originated and how it was
handled.
From a forensic standpoint, the acquisition process
should change the original evidence as little as possible,
and any changes should be documented and assessed in
the context of the final analytical results.
Malware Forensic Tool Box
Live Response Tools for Investigating Windows Systems
In this chapter we discussesd a myriad of tools that can be used
during the course of live response investigation. Throughout the
chapter, we deployed many tools to demonstrate their
functionality and output when used on an infected system;
however, there are a number of tool alternatives that you should
be aware of and familiar with. In this section, we explore these
tool alternatives. This section can also simply be used as a “tool
quick reference” or “cheat sheet,” as there will inevitably be
times during an investigation where having an additional tool that
is useful for a particular function would be beneficial, since you
may have little time to conduct research for or regarding the
tool(s) while responding in the field. As the digital forensic tool
landscape is constanly evolving, the companion Web site for this
Field Guide, www.malwarefieldguide.com, will strive to maintain
a comprehensive, dynamic, and up-to-date listing of tools. We
welcome tool suggestions via the Web site
http://www.malwarefieldguide.com/Contact_Us.html.
The tools in this section (and on the companion Web site)
are identified by overall “tool type”—deliniating the scope of
how the respective tools can be incorporated in your malware
forensic live response toolkit. Further, each tool description
includes a cross-reference to the page number in Chapter 1 in
which the relevant substantive discussion is provided, along with
details about the tool author/distributor, associated URL,
description of the tool, and helpful command switches, when
applicable.
Incident Response Tool Suites
In Chapter 1 we examined the incident response process step by
step, using certain tools to acquire different aspects of stateful
data from a subject system. There are a number of tool suites
specifically designed to collect digital evidence in an automated
fashion from Windows systems during incident response and
generate supporting documentation of the preservation process.
• Some of these local incident response tool suites execute
commands on the compromised computer and rely on
system libraries on the compromised system.
• Other programs, commonly known as “remote forensics
tools,” address some of the limitations of local incident
response suites and use a servlet that enables remote
evidence gathering while trying to rely on the
compromised operating system as little as possible (with
varying degrees of success).
• Using remote forensic tools, digital investigators can
access many machines from a central console, making
your expertise more effective.
• Furthermore, using a remote forensics tool is more subtle
than running various commands on the system, and it is
less likely to alert the subject of investigation.
• These tool options, including the strengths and weakness
of these tools, are covered in this section.
Remote Collection Tools
Recall that in some instances, to reduce system interaction, it is
preferable to deploy live response tools from your trusted toolkit
locally on a subject system but collect the acquired data
remotely. This process requires establishing a network
connection, typically with a netcat or cryptcat listener, and
transferring the acquired system data over the network to a
collection server. Remember, although this method reduces
system interaction, it relies on the ability to traverse the subject
network through the ports established by the netcat listener.
Volatile Data Collection and
Analysis Tools
Physical Memory Acquisition
Chapter 1 emphasized the importance of first acquiring a full
memory dump from the subject system prior to gathering data
using the various tools in your live response toolkit. This is
important, particularly due to the fact that running incident
response on the subject system will alter the contents of memory.
To get the most digital evidence out of physical memory, it is
advisable to perform a full memory capture prior to running any
other incident response processes. There are a variety of tools to
accomplish this task, as described next.
Collecting Subject System Details
System details are a fundamental aspect of understanding a
malicious code crime scene. In particular, system details
inevitably will be crucial in establishing an investigative time line
and identifying the subject system in logs and other forensic
artifacts. In addition to the tools mentioned earlier in the chapter,
others tools to consider include the following.
Identifying Users Logged into the System
Remember, identifying users logged into the subject system
serves a number of investigative purposes: (1) to help discover
any potential intruders logged into the compromised system; (2)
to identify additional compromised systems; and (3) to provide
insight into a malicious insider malware incident, and provide
additional investigative context by being correlated with other
artifacts. Some other tools to consider for this task include the
following.
Network Connections and Activity
Malware network connectivity is a critical factor for identifying a
document; connectivity from a subject system may be to
communicate with an attacker’s command and control structure,
to download additional malicious files, or to exfiltrate data from
the system, among other things. Trusted versions of netstat,
arp, and nbtstat are essential in the digital investigator’s toolkit
for probing internal and external network connections. In
addition to these tools and others mentioned in this chapter,
tcpvcoan, described next, is another to consider. Further, for
utilities specifically geared for providing insight into port-to-
process mapping, see the section of this chapter called Correlate
Open Ports with Running Processes and Programs appearing on
page 22.
Process Analysis
As many malware specimens (such as worms, viruses, bots, key
loggers, and Trojans) will often manifest on the subject system as
a process, collecting information relating to processes running on
a subject system is essential in malicious code live response
a subject system is essential in malicious code live response
forensics. Process analysis should be approached holistically—
examine all relevant aspects of a suspicious process, as outlined
in the chapter. Listed next are additional tools to consider for
your live response toolkit.
Handles
Loaded DLLs
Correlate Open Ports with Running
Processes and Programs
Command-line Arguments
Services
Malware can manifest on a victim system as a service, silently
running in the background, unbeknownst to the user. As with the
examination of running processes and open ports, explore
running services by first gaining an overview, and then apply
tools to extract information about the services with more
particularity. Some other service analysis tools include:
Drivers
In addition to determining the running services on a subject
system, consider examining the installed drivers on the system,
including the nature and status ofthe drivers. A reminder of the
importance of this step is the recent sophisticated malware
variant, Stuxnet, which installs drivers used to inject code into
system processes and to conceal the malware. In addition to the
tools discussed in Chapter 1, another tool to consider is
ListDrivers.
Opened Files
Open files on a subject system may provide clues about the
nature and purpose of the malware involved in an incident, as
well as correlative artifacts for your investigation. In Chapter 1
we examined the tool OpenFilesView; another tool to consider is
openfiles.
Determining Scheduled Tasks
Recall that some malicious code variants are “event-driven,”
meaning that until a certain date or event triggers execution, the
malware will remain dormant. In Chapter 1, we referenced the
Microsoft utility schtasks, which is described in further detail
below.
below.
Clipboard Contents
Remember that an attacker, whether remotely logged into a
system or a nefarious insider, may cut and paste information
while on a subject system. This information may provide valuable
investigative leads and correlate other artifacts found on the
system, in network traffic, or in the malicious code itself.
Non-Volatile Data Collection
and Analysis Tools
System Security Configuration
Prefetch File Analysis
Auto-Start Locations
As was discussed in this chapter, malware often has a
persistence mechanism to ensure longevity on a computer. A
frequent method used for this purpose is the creation of an auto-
start location (also referred to as an “autorun”) in the registry. In
addition to the Microsoft Autoruns tool, another option for
discovering and analyzing autorun locations is StartupRun.
Event Logs
On Windows systems, many activities related to a malware
incident can generate entries in the Event Logs. Some other
Event Log dumping tools to consider for your live response
toolkit include:
Group Policies
Remember to closely inspect user accounts that are local to the
subject system or domain accounts that were used to log in—
these can reveal how malware was placed on the computer.
Below are additional tools that assist in examining user and group
policy details.
File System: Hidden Files and Alternate
Data Streams
Malware and associated artifacts often manifest as hidden files.
Similarly, certain malware specimens abuse the NTFS Alternate
Data Stream feature—which allows you to hide data in an
existing file name with the use of a stream name—to hide the
malware or associated files. Consider adding tools to your live
response toolkit to discover these files.
Dumping and Parsing Registry Contents
Web History
Client-side exploits are becoming more and more prevalent,
particularly through “drive-by-downloads.” Drive-by-downloads
often occur when a user with an insecure or improperly
configured Web browser navigates to a compromised (or
nefarious) Web site that is surreptitiously hosting malware,
allowing the malware to silently be downloaded onto the victim
system. As a result, it is always advisable to examine the subject
system Web history to gain insight into whether a Web-based
vector of attack caused the malicious code incident.
vector of attack caused the malicious code incident.
Malware Extraction
As discussed in this chapter, once a suspicious file is identified
through live response, safely extracing and preserving the files for
further analysis is an essential aspect of malware forensics.
further analysis is an essential aspect of malware forensics.
Another tool to consider for this process is HBGary’s FGET.
Selected Readings
Books
1. Carvey H. Windows Forensic Analysis DVD Toolkit
Second edition. Burlington, MA: Syngress; 2009.
2. Jones, K., Bejtlich, R., and Rose, C.W. (2005). Real
Digital Forensics. Reading, MA: Addison-Wesley.
Prosise, C., Mandia, K., and Pepe, M. (2003).
Incident Response and Computer Forensics, Second
edition. New York: McGraw-Hill/Osborne.
Papers
1. Kent K, et al. Guide to Integrating Forensic Techniques
into Incident Response National Institute of Standards
and Technology, Special Publication 800–86 2006.
2. Mancini, S. (2006). RAPIER: A 1st Responders
Information Acquisition Framework. First
Conference 2006.
3. Pär Österberg Medina, S. (2008). Detecting
3. Pär Österberg Medina, S. (2008). Detecting
Intrusions: The Latest Forensics Tools and
Techniques to Identify Windows Malware Infections.
First Conference 2008.
4. Waits C, et al. Computer Forensics: Results of Live
Response Inquiry vs Memory Image Analysis Carnegie
Melon Software Engineering Institute 2008.
Jurisprudence/RFCS/Technical
Specifications
1. Columbia Pictures Indus. v. Bunnell, 2007 U.S. Dist.
LEXIS 46364 (C.D. Cal. June 19, 2007). RFC 3227
—Guidelines for Evidence Collection and Archiving.
1 For more information about FastDump, go to
https://www.hbgary.com/products-services/fastdump/.
2 For more information about FastDump Community
version, go to https://www.hbgary.com/community/free-
tools/#fastdump.
3 For more information about FastDumpPro, go to
http://www.hbgary.com/wp-
content/themes/blackhat/images/fastdumppro-faq .
4 For more information about Nigilant32, go to
http://www.agileriskmanagement.com/publications_4.html.
5 For more information about the iSCSI initiator, go to
http://www.microsoft.com/downloads/en/details.aspx?
familyid=12cb3c1a-15d6-4585-b385-
befd1319f825&displaylang=en.
6 For more information about F-Response, go to
http://www.f-response.com/.
7 Helix3 Pro is a digital forensic tool suite CD that offers
both a “live” and bootable forensic environment. For
more information about Helix3 Pro, go to http://www.e-
fense.com/helix3pro.php.
8 For more information about whoami, go to
http://www.microsoft.com/downloads/en/details.aspx?
familyid=3E89879D-6C0B-4F92-96C4-
1016C187D429&displaylang=en.
9 For more information about ver, go to
http://technet.microsoft.com/en-
us/library/bb491028.aspx.
10 For more information about promisdetect, go to
http://www.ntsecurity.nu/toolbox/promiscdetect/.
11 For more information about promqry, go to
http://www.microsoft.com/downloads/en/details.aspx?
http://www.microsoft.com/downloads/en/details.aspx?
familyid=4df8eb90-83be-45aa-bb7d-
1327d06fe6f5&displaylang=en.
12 For more information about URLProtocolView, go to
http://www.nirsoft.net/utils/url_protocol_view.html.
13 For more information about uptime.exe, go to
http://support.microsoft.com/kb/232243.
14 For more information about psinfo, go to
http://technet.microsoft.com/en-
us/sysinternals/bb897550.aspx.
15 For more information about PsLoggedOn, go to
http://technet.microsoft.com/en-
us/sysinternals/bb897545.aspx.
16 For more information about quser, go to
http://technet.microsoft.com/en-
us/library/cc754583%28WS.10%29.aspx.
17 For more information about netusers, go to
http://www.systemtools.com/cgi-bin/download.pl?
NetUsers.
18 For more information about loggonsessions, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896769.aspx.
19 For more information about netstat, go to
http://technet.microsoft.com/en-
us/library/cc940097.aspx.
20 For more information about NetBIOS names, go to
http://msdn.microsoft.com/en-
us/library/ms817948.aspx.
21 For more information about nbtstat, go to
http://technet.microsoft.com/en-
us/library/cc940106.aspx.
22 For more information about ARP, go to
http://technet.microsoft.com/en-
us/library/bb490864.aspx.
23 For more information about the arp command, go to
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/arp.mspx?mfr=true.
24 For more information about tlist.exe, go to
http://www.microsoft.com/downloads/en/details.aspx?
familyid=C055060B-9553-4593-B937-
C84881BCA6A5&displaylang=en.
25 For more information about tasklist, go to
http://technet.microsoft.com/en-
us/library/bb491010.aspx.
26 For more information about PRCView, go to
http://www.teamcti.com/pview/prcview.htm.
27 For more information about handle.exe, go to
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Handle.mspx.
28 An example of malware that implements this technique is
the Vanquish Rootkit, a DLL-injection-based rootkit
that hides files, folders, and registry entries and logs
passwords. For more information about Vanquish
Rootkit, go to
https://www.rootkit.com/vault/xshadow/ReadMe.txt.
29 For more information about listdlls.exe, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896656.aspx.
30 For more information about Procinterrogate, go to
http://sourceforge.net/project/shownotes.php?
release_id=122552&group_id=15870.
31 For more information about PRCView, go to
http://www.teamcti.com/pview/prcview.htm.
32 For more information about ListModules, go to
http://ntsecurity.nu/toolbox/listmodules/.
33 For more information about DLLExportViewer, go to
http://www.nirsoft.net/utils/dll_export_viewer.html.
34 For more information about Microsoft Windows
services, go to http://msdn.microsoft.com/en-
us/library/ms685141.aspx.
35 In 2006, a printer driver distributed by Hewlett Packard
was found to be infected with the Funlove virus.
Another piece of malicious code emerged in August
2007 named Trojan.Peacomm.C infects a Windows
device driver named “kbdclass.sys” to force the system
to load the virus each time the system is rebooted.
Unfortunately, this Trojan also employs rootkit
techniques to hide its presence on the infected system,
becoming invisible to the operating system. In such
cases, memory forensics can be employed to extract
more information about the malicious code. For more
information, go to
http://www.symantec.com/enterprise/security_response/weblog/2007/08/the_new_peacomm_infection_tech.html
36 For more information about List Loaded Drivers, go to
36 For more information about List Loaded Drivers, go to
http://support.microsoft.com/kb/927229 (available from
the Windows 2000 Resource Kit Tools) and
http://download.microsoft.com/download/win2000platform/drivers/1.0/NT5/EN-
US/drivers.exe.
37 For more information about DriverView, go to
http://www.nirsoft.net/utils/driverview.html.
38 For more information about OpenFilesView, go to
http://www.nirsoft.net/utils/opened_files_view.html.
39 For more information about psfile, go to
http://technet.microsoft.com/en-
us/sysinternals/bb897552.aspx.
40 For more information about doskey, go to
http://technet.microsoft.com/en-
us/library/bb490894.aspx?wt.slv=3D=.
41 For example, the polymorphic file infector named
W32/Bacalid,
http://vil.nai.com/vil/Content/v_140566.htm.
42 For example, in early 2008, a system administrator was
sentenced to 30 months in prison for embedding
malicious code designed to wipe out critical data stored
on more than 70 servers
(http://newark.fbi.gov/dojpressrel/2007/nk091907.htm).
43 An example of such a specimen is
WORM_SOHANAD.FM, which once downloaded by
an unsuspecting user from a malicious Web site, installs
three additional malicious code files, and uses the
Windows Task Scheduler to create a scheduled task to
execute the files at a later time. For more information
about WORM_SOHANAD.FM, go to
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?
VName=WORM%5FSOHANAD%2EFM&VSect=P.
44 For more information about the at command, go to
http://support.microsoft.com/kb/313565.
45 For more information about schtasks.exe, go to
http://technet2.microsoft.com/windowsserver/en/library/1d284efa-
9d11-46c2-a8ef-87b297c68d171033.mspx?mfr=true.
46 For more information about pclip.exe, go to
http://unxutils.sourceforge.net.
47 For information about WinUpdatesList, go to
http://www.nirsoft.net/utils/wul.html.
48 For more information about auditpol, go to
48 For more information about auditpol, go to
http://technet.microsoft.com/en-
us/library/cc731451%28WS.10%29.aspx.
49 For more information about dumpsec, go to
http://www.systemtools.com/download/dumpacl.zip.
50 For more information about AutoRuns, go to,
http://technet.microsoft.com/en-
us/sysinternals/bb963902.aspx.
51 For more information about eldump, go to
www.ibt.ku.dk/jesper/ELDump/default.htm.
52 For more information about NTlast, go to
http://www.foundstone.com/us/resources/proddesc/ntlast.htm.
53 For more information about SFind, go to
http://www.foundstone.com/us/resources/proddesc/forensictoolkit.htm.
54 For more information about rifiuti, go to
http://www.foundstone.com/us/resources/proddesc/rifiuti.htm.
55 For more information about macmatch.exe, go to
http://www.ntsecurity.nu/toolbox/macmatch/.
56 For more information about regdump, go to
http://social.msdn.microsoft.com/Forums/en-
US/windowscompatibility/thread/c14b5017-40ec-
4978-a82c-b3758f0808c1/.
57 For more information about dumpreg, go to
http://www.systemtools.com/download/dumpreg.zip.
58 For more information about USBView, go to
http://www.nirsoft.net/utils/usb_devices_view.html.
59 For instance, in 2008, some USB digital picture frames
were infected with various pieces of malware, and a
number of Maxtor Basics Personal Storage 3200 hard
drives produced by Seagate in late 2007 contained the
Win32.AutoRun.ah virus. A Windows system that was
configured to launch executables referenced in the
“autorun.ini” configuration file stored on the digital
picture frame would have installed the virus that stole
passwords and sent them to a server on the Internet.
60 For more information about RegRipper, go to
http://regripper.wordpress.com/.
61 For more information about RegRipper, go to
http://regripper.wordpress.com/.
62 For more information about Galleta, go to
http://www.foundstone.com/us/resources/proddesc/galleta.htm.
http://www.foundstone.com/us/resources/proddesc/galleta.htm.
63 For more information about MozillaCookiesView, go to
http://www.nirsoft.net/utils/mzcv.html.
64 For more information about Protected Storage
PassView, go to http://www.nirsoft.net/utils/pspv.html.
65 For more information about DumpAutoComplete, go to
http://www.foundstone.com/us/resources/proddesc/DumpAutoComplete.htm.
66 For more information about FGET, go to
http://www.hbgary.com/free-tools.
67 For more information about Nigilant32, go to
http://www.agileriskmanagement.com/publications_4.html.
68 For more information about the code from the Sleuth
Kit, go to http://www.sleuthkit.org/sleuthkit/docs/api-
docs/index.html.
69 For more information about the Sleuth Kit, go to
http://www.sleuthkit.org/index.php.
Chapter 2
Memory Forensics
Analyzing Physical and Process Memory Dumps for
Malware Artifacts
Solutions in this chapter:
• Memory Forensics Overview
• Old School Memory Analysis
• How Windows Memory Forensic Tools Work
• Windows Memory Forensic Tools
• Dumping Windows Process Memory
• Dissecting Windows Process Memory
Introduction
The importance of memory forensics in malware investigations
cannot be overstated. A complete capture of memory on a
compromised computer generally bypasses the methods that
malware uses to trick operating systems, providing digital
investigators with a more comprehensive view of the malware. In
some cases, malware leaves little trace elsewhere on the
compromised system and the only clear indications of
compromise are in memory. In short, memory forensics can be
used to recover information about malware that was not
otherwise obtainable.
Digital investigators often find useful information in memory
dumps simply by reviewing readable text and performing
keyword searches. However, as the size of physical memory in
modern computers continues to increase, it is inefficient and
ineffective to review an entire memory dump manually. In
addition, much more contextual information can be obtained
using specialized knowledge of data structures in memory and
associated tools. Specialized forensic tools are evolving to
extract and interpret a growing amount of structured data in
memory dumps, enabling digital investigators to recover
substantial evidence pertaining to malware incidents. Such digital
evidence includes recovery of deleted or hidden processes,
including the executables and associated data in memory and the
pagefile. More sophisticated analysis techniques are being
codified in memory forensic tools to help digital investigators find
malicious code in an automated manner.
Investigative Considerations
• There is still information available during the live response
that cannot be extracted from memory dumps, for
instance, network configuration and enabled protocols,
ARP cache, and NetBIOS sessions. Therefore, it is
important to implement the process described in Chapter
1 and not just acquire a physical memory dump.
With the increasing power and automation of memory
forensic tools, it is becoming more important for digital
investigators to understand how the tools work in order to
validate the results. Without this knowledge, digital investigators
will find themselves reaching incorrect conclusions based on
faulty tool output or missing important information entirely. In
addition, digital investigators need to know the strengths and
weaknesses of various memory forensic tools in order to know
when to use them and when their results may not be entirely
reliable.
Ultimately, digital investigators must have some knowledge
of how malware can manipulate memory and need to be familiar
with a variety of memory forensic tools and how they interpret
underlying data structures. This chapter provides a
underlying data structures. This chapter provides a
comprehensive approach for analyzing malicious code in memory
dumps from a Windows system and covers associated
techniques and tools. Details about the underlying data structures
are beyond the scope of this field guide and are discussed in the
t e xt Malware Forensics: Investigating and Analyzing
Malicious Code (hereinafter Malware Forensics).1
Memory Forensics Overview
After memory is preserved in a forensically sound
manner, employ a strategy and associated methods to
extract the maximum amount of information relating to
the malware incident.
A memory dump can contain a wide variety of data,
including malicious executables, associated system-related data
structures, and remnants of related user activities and malicious
events. Some of this information has associated date-time
stamps. The purpose of memory forensics in malware incidents is
to find and extract data directly relating to malware and
associated information that can provide context, such as when
certain events occurred and how malware came to be installed
on the system. Specifically, in the context of analyzing malicious
code, the main aspects of memory forensics include:
• Harvest available metadata including process details,
network connections, and other information associated
with potential malware for analysis and comparison with
volatile data preserved from the live system.
• Perform keyword searches for any specific known details
relating to a malware incident, and look through strings
for any suspicious items.
for any suspicious items.
• Look for common indicators of malicious code including
memory injection and hooking.
• For each process of interest, if feasible, recover the
executable code from memory for further analysis.
• For each process of interest, extract associated data from
memory, including related encryption keys and captured
data such as usernames and passwords.
• Extract contextual details such as Event Logs, URLs,
MFT entries, and Registry values pertaining to the
installation and activities associated with malicious code.
• Perform temporal and relational analysis of information
extracted from memory, including a time line of events
and a process tree diagram.
These processes are provided as a guideline and not as a
checklist for performing memory forensics. No single approach
can address all situations, and some of these goals may not apply
in certain cases. In addition, the specific implementation will
depend on the tools that are used and the type of malware
involved. Ultimately, the success of the investigation depends on
the abilities of the digital investigator to apply digital forensic
techniques and adapt them to new challenges.
Investigative Considerations
• The completeness and accuracy of the above steps
depend heavily on the tools used and your familiarity
with the data structures in memory. Some tools will only
provide limited information or may not work on memory
acquired from certain versions of Windows.
• In one case, digital investigators ran a tool on a memory
dump and extracted a limited list of IP addresses that
had communicated with the compromised system.
had communicated with the compromised system.
Another digital investigator looked at the same memory
dump and used his knowledge of memory structures to
recover hundreds of additional connections that were
relevant to the investigation.
• To avoid mistakes and missed opportunities, it is
necessary to compare the results of multiple tools and to
verify important findings manually.
Analysis Tip
Field Interviews
Most incidents have a defining moment when malicious activity
was recognized. The more information that digital investigators
have about that moment, the more they can focus their forensic
analysis and increase the chances of solving the case. Simply
knowing the rough time period of the incident and knowing what
evidence of malware was observed can help digital investigators
develop a strategy for scouring memory dumps for relevant
digital evidence. Without any such background information,
forensic analysis can be like trying to find a needle in the
haystack, which can result in wasted time and lost opportunities
(e.g., relevant network logs being overwritten). Therefore, prior
to performing forensic analysis of a memory dump, it is advisable
to gather as much information as possible about the malicious
code incident and subject system from relevant witnesses. The
Field Interview Questions in Chapter 1 provide a solid
foundation of context to support a strong forensic analysis of
malware in memory.
Old School Memory Analysis
In addition to using specialized memory forensic tools
In addition to using specialized memory forensic tools
to interpret specific data structures, look through the data
in raw, uninterpreted form for information that is not
extracted automatically.
Although the memory forensic tools covered in this
chapter have advanced considerably over the past few years,
there is still a substantial amount of useful information in memory
dumps that many specialized tools do not extract automatically.
Therefore, it is generally still productive to employ “old school”
memory analysis, which was essentially limited to a manual
review of the memory dump, keyword searching, file carving,
and use of text extraction utilities such as the strings command
(with Unicode support). These old school techniques can
uncover remnants of activities or data that may be related to
malicious code, including but not limited to the following:
• File fragments such as Web pages and Word documents
no longer present on disk
• Commands run at the Windows command line
• Prefetch file names
• E-mail addresses and message contents
• URLs, including search engine queries
• Filenames and even full MFT entries of deleted files
• IP packets, including payload
Unexpected information can be found in memory dumps
such as intruder’s commands and communications that are not
saved elsewhere on the computer, making a manual review
necessary in every case.
For instance, in a case involving the ZeuS Trojan
program, entire HTTP GETs and POSTs are visible along with
the entire encrypted data sections of the communications as
shown in Figure 2.1, a benefit particularly when network traffic
was not previously captured.2
was not previously captured.2
Figure 2.1 Encrypted packet contents associated with the ZeuS
Trojan communications captured in memory dump
Memory dumps can also capture command and
control activities such as instructions executed by the
attacker and portions of network communications
associated with an attack. Figure 2.2 shows an example of
an IP packet and payload captured in a target memory
dump.
Figure 2.2 IP packet in memory with source IP address
172.16.157.136 (ac 10 9d 88), destination IP 172.16.157.1
(“AC 10 9D 01”) starting at offset 0x0263B01A and payload
visible in ASCII
visible in ASCII
It is often desirable to extract certain files from a memory
dump for further analysis.
• One approach to extracting executables and other types
of files for further analysis is to employ file carving tools
such as Foremost and Scalpel to run on the full memory
dump or on extracted memory regions relating to a
specific process (Figure 2.3).
Figure 2.3 Carving memory with foremost
Figure 2.4 Volatility psscan option carving EPROCESS
structures out of a memory dump
structures out of a memory dump
• The results of file carving can be more comprehensive
than the more surgical file extraction methods used by
specialized memory forensic tools.
• However, current file carving tools only salvage
contiguous data, whereas the contents of physical
memory may be fragmented. Therefore, the executables
that are salvaged using this method may be incomplete.
Even when sophisticated memory forensic tools are
available, digital investigators benefit from spending some time
looking through readable text in a memory dump or process
memory dump.
• When clues such as IP addresses are available from other
aspects of a digital investigation, keyword searching is
another efficient approach to locating specific information
of interest.
• Given the widespread use of Unicode by the Windows
operating system, it is critical to use a tool that can
extract Unicode strings, such as the strings utility
available from Microsoft.
Investigative Considerations
• These old school approaches to extracting information
from memory dumps do not provide surrounding
context. For instance, the time associated with a URL or
IP packet will not be displayed automatically, and may
not be available at all. For this reason, it is important to
combine the results of old school analysis with those of
specialized memory forensic tools to obtain a more
specialized memory forensic tools to obtain a more
complete understanding of activities pertaining to a
malware incident.
• Although memory forensic tools provide a mechanism to
perform precise extraction of executables by
reconstructing memory structures, there can be a benefit
to using file carving tools such as Foremost and Scalpel.
File carving generally extracts a variety of file fragments
that might include graphics files, reviewed document
fragments showing an intruder’s collection interest, and
data that may have been stolen.
How Windows Memory Forensic Tools
Work
Understanding the underlying operations that memory forensic
tools perform can help you select the right tool for a specific task
and assess the accuracy and completeness of results.
• Some tools will only list active processes, whereas others
will scan for all executive process (EPROCESS)
structures.
• Some tools only extract certain areas of process memory,
whereas others can extract related information from the
pagefile as well as the executable associated with a
process.
• Some tools will detect memory injection and hooking
correctly, whereas others will identify such features
incorrectly (false positive) or not at all (false negative).
• Additional details about how memory forensic tools work
are provided in the Malware Forensics text.
Investigative Considerations
• Although many memory forensic tools can be used
without understanding the operations that the tool uses to
interpret data structures in memory, a lack of
understanding will limit your ability to analyze relevant
information and will make it more difficult to assess the
completeness and accuracy of the information.
Therefore, it is important for digital investigators to
become familiar with data structures in memory.
Windows Memory Forensic Tools
Choose the tool(s) that are most suitable for the type of
memory analysis you are going to perform. Whenever
feasible, use multiple tools and compare their results for
completeness and accuracy.
Different memory forensic tools have different features
and may only support specific versions of Windows. Therefore,
it is necessary to be familiar with the strengths and weaknesses
of multiple memory forensic tools. The types of information that
most memory forensic tools provide are summarized in the
following list.
• Processes and threads
• Modules and libraries
• Open files and sockets
• Various data structures
Some tools provide additional functionality such as
Some tools provide additional functionality such as
extracting executables and process memory, detecting memory
injection and hooking, recovering Registry values and MFT
entries, and extracting URLs and e-mail addresses. Commercial
forensic tools such as FTK and EnCase have adapted to include
memory analysis capabilities. These and other malware forensic
tools are discussed further in the Tool Box section at the end of
this chapter.
Investigative Considerations
• Memory forensic tools are in the early stages of
development and may contain bugs and other limitations
that can result in missed information. To increase the
chance that you will notice any errors introduced by an
analysis tool, whenever feasible, compare the output of a
memory forensic tool with that of another tool as well as
volatile data collected from the live system.
Processes and Threads
Obtain as much information as possible relating to
processes and associated threads, including hidden and
terminated processes, and analyze the details to determine
which processes relate to malware.
When a system is running malware, information (what,
where, when, how) about the processes and threads is generally
going to be significant in several ways.
• What processes are hidden or injected in memory may be
of interest, and where they are located in memory or on
of interest, and where they are located in memory or on
disk may be noteworthy.
• When they were executed can provide useful clues, and
how they are being executed may be relevant.
• Deleted processes may also be important in an
investigation. To begin with, a comparison of processes
visible through the operating system with all EPROCESS
structures that exist in memory can reveal deleted and
hidden processes.
Command-line Memory Analysis Utilities
• The Volatility psscan plug-in scans a memory dump for
the signature of an EPROCESS data structure to
provide a list of active, exited, and hidden processes.
The following output shows the psscan option being
used to carve EPROCESS structures out of a memory
dump from the FUTo rootkit scenario in Malware
Forensics (Figure 2.4).3
• Comparing the output of the psscan output with a list of
running processes (e.g., using Volatility pslist option)
can reveal discrepancies caused by malware, or may
reveal anomalies that relate to the behavior of malware.
• The psdiff Volatility plug-in automatically performs this
comparison. In this example, two processes, “skls.exe”
and “skl.exe,” that were not displayed in the pslist
output are visible in the psscan output (shown in bold in
Figure 2.4) with a process ID of zero that is generally
reserved for the Windows system Idle process.
• The setting of the process identifier (PID) to zero is an
artifact of the FUTo rootkit, making it difficult for digital
forensic tools to reference the hidden processes by PID.
To address this challenge, tools such as Volatility have
To address this challenge, tools such as Volatility have
added the ability to run analysis on a process by the
location (offset) of the EPROCESS structure in the
memory dump as shown here for the hidden “skls.exe”
process to list loaded DLLs associated with this hidden
process (Figure 2.5).
Figure 2.5 Using the Volatility dlllist option
• Another approach to finding hidden processes is to
extract process details from the Windows “csrss”
process as demonstrated by the csrpslist Volatility
plug-in (Figure 2.6).4
Figure 2.6 Results of parsing a memory dump with the
csrpslist plug-in
• The output of this plug-in is provided below for the FUTo
rootkit example, with a zero in the second column when
a process was not present in the pslist output (e.g.,
skl.exe). Unfortunately, this list does not show the
“skls.exe” process found using psscan.
• Another free command-line tool is Memoryze from
Mandiant. The command-line options for this tool are
summarized in the Tool Box section at the end of this
chapter. A sample command line is provided here that
extracts processes and associated ports from a memory
dump (Figure 2.7).
Figure 2.7 Processing a memory dump file with Memoryze
• The output from Memoryze is in XML format and can be
viewed in raw form or using any XML viewer or using
the AuditViewer program described next.5
The threads associated with a given process identified
can also be examined to provide additional information about a
malware incident.
• The thrdscan and thrdscan2 plug-ins in Volatility will
carve and display all of the ETHREAD structures it can
find in a memory dump.
• Looking for threads that have a PID that was not
displayed in the process list may uncover hidden
displayed in the process list may uncover hidden
processes. The orphanthreads Volatility plug-in
attempts to find such hidden processes in memory
dumps.
Additional command-line utilities such as PTFinder to
extract process and thread details from physical memory dumps
are discussed in the Tool Box section at the end of this chapter.
GUI-based Memory Analysis Tools
• A number of tools have been developed to facilitate
forensic analysis of Windows memory. These tools can
be particularly useful for detecting artifacts of malware in
memory such as memory injection. Although Memoryze
is a command-line utility, it can be configured and run,
and its output can be viewed using a GUI program
named AuditViewer. Figure 2.8 shows one of the
configuration screens in AuditViewer used to configure
Memoryze.
• Figure 2.9 shows processes and associated details
viewed using AuditViewer, focusing on the “skl.exe”
process mentioned previously that was hidden using the
FUTo rootkit.
• Tabs within AuditViewer provide easy access to the
information that Memoryze extracts associated with each
process and driver including files, Registry keys, and
open ports.
• In addition, certain features in a memory dump that
commonly relate to malware such as memory injection
will be highlighted in red in the Memoryze results as
detailed in the Dissecting Windows Process Memory
section toward the end of this chapter.
Another GUI tool for examining memory is HBGary
Responder,6 as shown in Figure 2.10, which lists processes and
associated details.
Figure 2.10 HBGary Responder used to list processes and
associated metadata
• This tool provides various details relating to processes
and drivers, and can be used to perform keyword
searches within a memory dump.
• For an additional cost, advanced features are available as
add-ons to this tool, such as integrated
debugging/disassembly and automated detection of
features commonly found in malware (called Digital
DNA or DDNA).7
DNA or DDNA).7
• This tool can also be used to associate ports with a
particular process as shown in Figure 2.11 with the same
“skl.exe” processes selected, revealing that it has port
1900 open.
Figure 2.11 HBGary used to list ports associated with a
particular process
Relational Reconstruction
When examining processes in Windows memory, it can also
When examining processes in Windows memory, it can also
be fruitful to perform a relational reconstruction, depicting the
parent and child relationships between processes as shown in the
following section.
• For instance, malware will sometimes exploit a system
vulnerability and cause a system process to launch a
command shell.
• The Metasploit penetration testing framework8 has an
option to launch a remote command shell after exploiting
vulnerability in the Windows Local Security Authority
Subsystem Service (LSASS).
• Figure 2.12 shows how this looks in memory using the
Hacker Defender scenario from the Malware Forensics
text,9 with the “lsass.exe” process launching Metasploit,
which in turn launched the program “UMGR32.exe” that
turns out to be Back Orifice.
Figure 2.12 Graphical depiction of relationship between
processes in the Hacker Defender rootkit scenario
Another anomaly to look for in this type of relational
reconstruction is a user process that is the parent of what
resembles a system process.
• Because malware attempts to blend in with the legitimate
processes on a system, digital investigators might see the
“cmd.exe” process spawning a process named
“lsass.exe” to resemble the legitimate Windows LSASS
process.
• Conversely, suspicious activities can be found by looking
for system processes spawning an unknown process or
executable that is usually only started by a user.
• For instance, the ZeuS Trojan program is commonly
injected into the “svchost.exe” process and, therefore,
any remotely executed commands appear to be
spawned by the “svchost.exe” process.10
Investigative Considerations
• Some legitimate processes such as AntiVirus and other
security tools can have characteristics that are commonly
associated with malware. Therefore, it is advisable to
determine which processes are authorized to run on the
subject system. However, intruders may assign their
malware the same name as these legitimate processes to
misdirect digital investigators. Therefore, do not dismiss
seemingly legitimate processes simply because they have
a familiar name. Take the time to examine the details of a
seemingly legitimate process before excluding it from
further analysis.
Analysis Tip
Temporal and Relational Analysis
Analysis techniques from other forensic disciplines can be
applied to malware forensics to provide insights into evidence
and associated actions. In memory analysis the most common
form of temporal analysis is a time line and the most common
form of relational analysis is a process tree diagram. A time line
and process tree diagram should be created in all cases to
determine whether any processes were started substantially later
than standard system processes, or whether there are unusual
relationships between processes as previously discussed. The full
path of an executable and any files that a process has open may
also provide clues that lead to malware. Digital investigators
should look for other creative ways to analyze date-time stamps
and relationships found in memory not just for processes but for
all data structures.
Modules and Libraries
Extract details associated with modules (aka drivers)
and libraries in memory, and analyze them to determine
and libraries in memory, and analyze them to determine
which relate to malware.
Malware may create drivers or load libraries to perform
core functions such as concealment and keylogging. Therefore, in
addition to processes and threads, it is important to examine
drivers and libraries that are loaded on a Windows system.
Memory Analysis Utilities
• The Volatility modules and modscan2 plug-ins provide a
list of modules running on a system, and the driverscan
plug-in searches memory for specific driver objects.
• For example, Figure 2.13 shows a list of loaded modules
extracted from memory using the Volatility modules
option, with the module named “msdirectx.sys”
associated with the FUTo rootkit highlighted in bold.
Figure 2.13 A portion of Volatility output when used to list
Figure 2.13 A portion of Volatility output when used to list
loaded modules (aka drivers)
• If there is a chance that a module is hidden or exited, the
modscan2 option may be more effective.
• Once a module of interest is identified, the executable
contents can be extracted to a file for further analysis
using the moddump Volatility plug-in.11
• The dlllist option of Volatility can be used to list the
dynamic link libraries (DLLs) for each process.
• In the FUTo scenario of the Malware Forensics text,
listing DLLs reveals that a component of KeyLogger
named “kls.dll” (shown in bold in Figure 2.14) is
attached to two running processes: “explorer.exe” and
“helix.exe.”12
Figure 2.14 A portion of Volatility output when used to list
dynamic link libraries
• The fact that KeyLogger was attached to the “helix.exe”
process demonstrates the potential of malware
undermining incident response tools and the potential
notification of the intruder if the keylog is sent that the
response has occurred. A specific DLL can be extracted
from a memory dump using the dlldump Volatility plug-
in.
• Memoryze has an option to list all libraries associated
with each process, and provides two batch scripts
named DriverSearch.bat and DriverWalkList.bat that
can be used to list drivers.
• The results of running the DriverSearch.bat on the FUTo
memory dump are in Figure 2.15, providing details for
the “msdirectx.sys” module used by the FUTo rootkit.
Figure 2.15 Mandiant’s AuditViewer used to list drivers
Figure 2.15 Mandiant’s AuditViewer used to list drivers
including a rootkit module
• Similarly, HBGary Responder lists drivers and loaded
libraries, enabling digital investigators to drill down into a
specific object to obtain more details as shown in Figure
2.16.
Figure 2.16 HBGary Responder used to list drivers and libraries
• Note that the example in Figure 2.16 does not have the
DDNA feature enabled and does not show the
automated severity checks for each object in memory.
Investigative Considerations:
• In some cases, it is necessary to understand the function
of a certain library to determine whether it is normal or
not. For example, knowing that “wsock32” provides
network connectivity (e.g., wsock32) functions should
raise a red flag when it is being called by a program that
does not require network access.
Open Files and Sockets
Review open files and sockets in an effort to find items
associated with malware such as configuration logs,
keystroke logs, and network connections.
The files and sockets that are being accessed by each
process can provide insight into their operation on an infected
system. A Trojan horse program or rootkit may have its
configuration file open, a keylogger may have a log file to store
captured keystrokes, and a piece of malware designed to search
a disk for Personally Identifiable Information (PII) or Protected
Health Information (PHI) may have various files open that
contain social security numbers, credit card numbers, and other
sensitive data.
Memory Analysis Utilities
• The files option in Volatility can be used to show the
files that are being accessed by each process. In Figure
2.17, the files that a particular process has open are
listed and include files with sensitive data that are
relevant to the investigation (shown in bold).
relevant to the investigation (shown in bold).
Figure 2.17 Parsing a target memory dump with the Volatility
files option
In many cases it is desirable to associate processes
running on a compromised system with activities observed on the
network.
• The most common approach to making this association is
to determine which port(s) each process is using and
look for those ports in the associated network activities.
• Information about open ports and the associated process
can be extracted from a memory dump using the
Volatility commands seen in Figure 2.18.
Figure 2.18 Volatility commands to open ports and associated
processes
• The sockets output lists active open ports whereas the
sockscan output lists all recoverable port information,
including for those that have been closed.
• If there are any network connections in memory that were
associated with a particular port of interest, these can be
extracted using the connections and connscan2
Volatility plug-ins.
• For instance, connections associated with the ZeuS
Trojan activities were recovered from a memory dump
as shown in Figure 2.19, even after the network
connections were closed and did not appear in the active
connections.
Figure 2.19 Using the connscan2 plug-in
Memoryze can also be used to list open files with the
handles option, as shown in Figure 2.20.
Figure 2.20 Parsing a target memory dump for open files with
Memoryze
• The resulting list of open files can be viewed using
• The resulting list of open files can be viewed using
AuditViewer as shown in Figure 2.21 with open files lists
on the right.
Figure 2.21 Open files associated with ZeuS malware extracted
using Memoryze viewed with AuditViewer
• This example shows the main ZeuS Trojan executable file
“sdra64.exe” within the winlogon.exe process, along
with associated configuration files (user.ds and local.ds)
and a reference to “AVIRA,” which is common for this
malware.
Various Data Structures
Interpret data structures in memory that have a known
Interpret data structures in memory that have a known
format such as Event logs, Registry entries, MFT entries,
command history, and other details that can provide
additional context relating to the installation and
activities associated with malicious code.
Malware can create impressions and leave trace
evidence on computers, as described in Chapter 6, which
provide digital investigators with important clues for
reconstructing associated malicious activities.
• Such impressions and trace evidence created on a
computer system by malicious code may be found in
memory even after the artifacts are concealed on or
removed from the computer.
• For instance, an Event log entry, file name, or Registry
entry relating to malware may remain in memory along
with associated metadata after the actual file is deleted or
when it is hidden from the operating system.
• Memory forensic tools are being developed to interpret
an increasing number of such data structures.
Any data structure that exists on a computer system may
be found in memory.
For instance, file system information is generally cached in
memory, potentially providing digital investigators with clues
relating to malware and associated activities.
Event Logs
It may be possible to recover Windows Event Log records in
a target memory dump that shows activities relating to malware,
even after they have been deleted from the log file.
• Rather than interpreting this type of data structure
• Rather than interpreting this type of data structure
manually, it is generally desirable to use an automated
approach to locate and interpret all such entries in a
memory dump. File carving techniques can be used for
this purpose Murphey. R. (2007). Automated Windows
event log forensics in DFRWS2007 proceedings
(Available online at
www.dfrws.org/2007/proceedings/p92-murphey ).
Master File Table
Figure 2.22 illustrates an MFT entry in a target memory dump
that shows all metadata associated with a file that relates to an
investigation into potentially unauthorized access to and theft of
sensitive data.
Figure 2.22 MFT Entry in memory dump viewed in X-Ways.13
• The NTFS FILE Record template within X-Ways (under
the View — Template Manager menu option) can be
applied to an MFT entry found in memory to interpret all
of the attributes, including the area on disk that contains
the file contents.
• Rather than interpreting this type of data structure
manually, it is generally desirable to use an automated
approach to locate and interpret all such entries in a
memory dump.
An EnScript was developed to enable EnCase to extract
MFT entries from memory dumps automatically.14
Services
Volatility can be used to extract a list of services from memory
using the svcscan plug-in, which can be useful when malware is
installed as a service. The following portion of svcscan output
from the FUTo rootkit example shows a keylogger program
installed as a services (Figure 2.23; shown in bold).
Figure 2.23 The Volatility svcscan plug-in
Registry Entries
Registry entries can provide context for malware running on a
computer, directing digital investigators to important information
such as encryption keys stored in the Registry and used by the
malware to obfuscate network traffic.
• The regobjkeys Volatility plug-in prints Registry keys that
are stored in memory.
are stored in memory.
• By default, this plug-in may not recover all Registry keys,
particularly when malware is involved and is manipulating
memory.
• For instance, the default regobjkeys output for the FUTo
example does not include Registry keys associated with
the hidden processes. These keys can be extracted using
the regobjkeys plug-in by specifying the offset of the
associated EPROCESS structure in memory as shown in
Figure 2.24 for the hidden skl.exe process.
Figure 2.24 The Volatility regobjkeys plug-in
• A more comprehensive view of Registry information in
memory can be extracted by looking for all Registry
hives in a memory dump using the hivelist and
hivescan Volatility plug-ins as shown in Figure 2.25.
Figure 2.25 Using the hivelist plug-in to parse Registry
artifacts from a memory dump
• A listing of the contents of a particular Registry hive with
associated last written date-time stamps can be
extracted using the hivedump Volatility plug-in.
• For instance, part of the output for a target User hive,
“kremember,” in the memory dump is displayed in Figure
2.26.
Figure 2.26 Extracting a target User hive with the hivedump
plug-in
• Information about a specific Registry can be extracted
using the printkey plug-in, but to extract the contents of
Registry values in memory using Volatility it is necessary
to use the RegRipper plug-in.15 The offset in memory of
each memory hive is shown in the hivelist output in
Figure 2.26 and is provided as input to RegRipper along
with the memory dump as shown in Figure 2.27.
Figure 2.27 Extracting a target User hive with the hivedump
plug-in
• HBGary Responder also extracts Registry-related
information from memory dumps as shown in Figure
2.28.
Figure 2.28 Registry entries associated with a specific process
displayed by HBGary Responder Pro
Investigative Considerations
• Data structures in memory may be incomplete and should
be verified using other sources of information. At the
same time, even if there is only a partial data structure, it
can contain leads that direct digital investigators to useful
information on the file system that might help support a
conclusion. For instance, if only a partial MFT entry is
recoverable from a memory dump, it may contain a
recoverable from a memory dump, it may contain a
partial file name and date-time stamps that help focus a
forensic examination.
• Not all data structures in memory can be interpreted by
memory forensic tools automatically. Old school
methods discussed at the beginning of this chapter may
reveal additional details that can provide context for
malware. In addition, through experimentation and
research it may be possible to determine the format of a
specific data structure located in a memory dump.
Analysis Tip
Exploring Data Structures
In addition to Windows operating system data structures such as
Registry and MFT entries, any application can have unique data
structures in memory. Therefore, the variety of data structures in
memory is limited only by the programs that have been used on
the system, including peer-to-peer programs and instant
messaging clients. Digital investigators need to keep this in mind
when dealing with applications and may need to conduct
research to interpret data structures that are relevant to their
specific case. The most effective approach to learning how to
interpret data structures is through application of the scientific
method, conducting controlled experiments as demonstrated in
Casey and Stevens (DFRWS, 2010).
Dumping Windows Process Memory
In many cases, when examining a specific process of interest, it
will be possible to extract the necessary information from a
memory dump acquired as detailed in Chapter 1. However, in
memory dump acquired as detailed in Chapter 1. However, in
certain situations it will be desirable to acquire memory related to
a specific process running on a live system. This section
addresses both needs.
Extract malicious executable files and associated
data in memory for further analysis.
When there is a specific process that you are interested
in analyzing, there are two areas of memory that are necessary to
acquire: the executable and the area of memory used by the
process to store data. Both of these areas of memory can be
extracted from a memory dump using memory forensic tools.
Recovering Executable Files
When a suspicious process has been identified on a subject
system, it is often desirable to extract the associated executable
code from a memory dump for further analysis. As
straightforward as this might seem, it can be difficult to recover a
complete executable file from a memory dump. To begin with, an
executable changes when it is running in memory, so it is
generally not possible to recover the executable file exactly as it
would exist on disk. Pages associated with an executable can
also be swapped to disk, in which case those pages will not be
present in the memory dump. Furthermore, malware attempts to
obfuscate itself, making it more difficult to obtain information
about its structure and contents. With these caveats in mind, the
most basic process of recovering an executable is as follows:
1 . Read process environment block (PEB) structure to
determine the address where the executable begins.
2 . Go to the start of the executable and read the PE
header.
3. Interpret the PE header to determine the location and
3. Interpret the PE header to determine the location and
size of the various sections of the executable.
4 . Extract the pages associated with each section
referenced in the PE header, and combine them into a
single file.
The Malware Forensics text describes this process in
detail.16 Fortunately, memory forensic tools such as Volatility,
Memoryze, and HBGary Responder automate this process and
can save the executable associated with a given process or
module to a file. For instance, the procexedump option of
Volatility saves the executable associated with a process while
the procmemdump extracts an executable as a memory sample.
Other memory forensic tools have a comparable capability.
Memoryze provides scripts named ProcessDD.bat and
DriverDD.bat to facilitate the extraction of executables and
memory regions associated with processes and drivers.
Analysis Tip
Running AntiVirus on Extracted Executables
Digital investigators can run multiple AntiVirus programs on
executables extracted from memory dumps to determine whether
they contain known malware. Although this can result in false
positives, it provides a quick focus for further analysis.
Recovering Process Memory
In addition to obtaining metadata and executable code
associated with a malicious process, it is generally desirable to
extract all data in memory associated with that process.
Conceptually, the process of extracting all memory pages
associated with a particular process is simple.
associated with a particular process is simple.
• Sequentially read the entries in the Page Directory and
associated Page Tables, and extract the data in each
4096-byte page.
• The memory of a particular process can be dumped using
the memdmp option in Volatility (formerly named usrdmp in
earlier versions).
• However, some tools rely on a unique PID to reference
processes and, therefore, cannot be used to dump the
memory associated with the “skl” and “skls” processes
shown earlier, which both have a PID of zero.
• Other memory forensic tools for dumping process
memory rely on the physical location of the EPROCESS
block, and can extract the necessary information about
the location of data in order to extract the memory
contents for a particular process. For instance, in
Volatility, version 1.3, all of the commands related to
processes can have the process object specified as a
physical offset.
Investigative Considerations
• Shared memory areas may contain data relating to other
processes. Therefore, it is advisable to seek
corroborating clues before concluding that certain data is
related to the malware being analyzed.
• Most memory forensic tools can include data stored in the
pagefile, which may provide additional information when
extracting memory associated with a given process.
• In addition to acquiring and parsing the full memory
contents of a running system to identify artifacts of
malicious code activity, it is also recommended that the
digital investigator capture the individual process memory
of specific processes that are running on the system for
later analysis. Although it may seem redundant to collect
information that is already preserved in a full memory
capture, having the process memory of a piece of
malware in a separate file will facilitate analysis,
particularly if memory forensic tools have difficulty
parsing the full memory capture. Moreover, using
multiple tools to extract and examine the same
information can give added assurance that the results are
accurate, or can reveal discrepancies that highlight
malware functionality and weaknesses in a particular
tool.
Extracting Process Memory on Live Systems
In some cases it may be desirable to acquire the memory of a
specific process on a live system. This can apply to a computer
that is the subject of an investigation, or to a test computer that is
being used to examine a piece of malicious code. In such cases,
there are various utilities that can be run on a live system to
capture process memory, including pmdump,17 RAPIER,18
Process Dumper, and the Microsoft User Mode Process
Dumper (userdump),19 as shown in Figure 2.29.
Figure 2.29 Dumping suspicious process “tywv” with userdump
Figure 2.29 Dumping suspicious process “tywv” with userdump
Dissecting Windows Process Memory
Delve into the specific arrangements of data in memory
to find malicious code and to recover specific details
pertaining to the configuration and operation of malware
on the subject system.
When there is a specific process that you are interested
in analyzing, there are various things you will want to look for,
including:
• Command-line arguments
• IP addresses
• Hostnames
• Passphrases and encryption keys associated with
malicious code
Some of this information can be found by extracting
strings or performing keyword searches. Volatility can be used
to extract strings from an entire memory dump or a specific
process for further analysis.
HBGary Responder can be used to perform keyword
searches for both ASCII and Unicode, presenting any search
hits in the context of which process or module they were found.
Figure 2.30 shows the results of a keyword search for “sploit”
on a target memory dump file, revealing 8 keyword hits in
several processes.
Figure 2.30 Keyword search results for sploit using HBGary
Responder
Some tools look for specific keywords in memory
automatically when initially processing a memory dump in an
effort to recover potentially useful information such as
passwords. For instance, Figure 2.31 shows the Keys and
Passwords recovery feature of HBGary Responder displaying
the password from the Hacker Defender rootkit.
Figure 2.31 Keys and Passwords function of HBGary
Figure 2.31 Keys and Passwords function of HBGary
Responder showing password associated with rootkit extracted
from memory dump
Some memory forensic tools can provide additional
insights into memory that are specifically designed for malware
forensics.
• As more malware uses concealment techniques such as
injection and hooking, memory forensic tools are being
developed to detect new concealment methods.
• Attempts to detect specific malware concealment
techniques have been codified in tools such as
Memoryze, HBGary Responder, and Volatility plug-ins.
Some Volatility plug-ins have been developed to look for
concealment techniques commonly used by malware.
• These plug-ins include apihooks, driverirp, ssdt_ex,
and malfind.20
• A portion of output from the malfind plug-in relating to
the ZeuS Trojan is provided in Figure 2.32, listing and
extracting portions of memory that may be related to
malware.
Figure 2.32 Parsing memory with the Volatility malfind plug-in
• The output of these Volatility plug-ins is not as focused or
intuitive as memory forensic tools such as Memoryze or
HBGary Responder.
• Furthermore, these plug-ins and others that attempt to
detect concealment techniques in memory often result in
many false positives.
Therefore, the output of these tools should be treated as a
starting point for digital investigators rather than a final answer
relating to malware. Other tools and techniques should be
employed to validate the results of the plug-ins.
Memoryze has several functions for detecting injected
code and hooks in memory dumps, all of which can be enabled
using the AuditViewer program.
• Figure 2.33 shows a suspicious memory section
highlighted by AuditViewer that is associated with the
Trojan horse program Back Orifice.
Figure 2.33 AuditViewer showing suspicious memory sections
associated with the Back Orifice Trojan horse program
highlighted
• Memoryze (using the AuditViewer front end) has strong
memory injection detection capabilities as shown in
Figure 2.34, identifying an injected memory section in the
“Excel.exe” process, highlighted.
Figure 2.34 Identifying memory injection with AuditViewer
• Although Memoryze is a powerful tool for detecting
potential concealment techniques in memory, the
supporting documentation is careful to point out that not
all concealment techniques will be detected using the
automated tool. This again demonstrates the importance
in malware forensics of utilizing multiple analysis tools
and performing a comprehensive reconstruction
(temporal, relational, and functional, as discussed earlier
in this chapter) to ensure that a more complete
understanding of the malware is obtained.
• Figure 2.35 shows HBGary Responder examining a
system infected with the ZeuS Trojan, which makes
extensive use of process injection. Potentially malicious
objects in memory are highlighted and given a severity
score in an effort to help digital investigators focus on
areas of greatest potential concern.
Figure 2.35 Processes with code injected by the ZeuS Trojan
viewed using HBGary Responder
• Figure 2.36 provides additional details about a specific
• Figure 2.36 provides additional details about a specific
module that HBGary Responder has rated as suspicious
because of its ability to inject code into other processes.
Figure 2.36 Portions of HBGary Responder report of
suspicious module injected into svchost.exe process
• Tools such as HBGary DDNA automatically extract
some characteristics of executable code that can be
useful for malware forensics.
• For instance, Figure 2.37 shows the traits extracted by
DDNA for a malicious process. However, this approach
can result in a false positive and generally requires
additional analysis by a skilled digital investigator.
Figure 2.37 Traits of a malicious process automatically
extracted using Digital DNA (DDNA) module
Analysis Tip
Finding the Hidden in Memory
Digital investigators should not be overly reliant on automated
methods for detecting hidden information and concealment
techniques in memory. Free and commercial tools alike cannot
detect every concealment method. As such, automated detection
methods are simply one aspect of the overall process of
examining volatile data in memory as described in Chapter 1, as
well as the comprehensive examination and reconstruction
methods discussed earlier in this chapter.
Conclusions
• As memory forensics evolves, an increasing amount of
information can be extracted from full memory dumps,
providing critical evidence and context related to
providing critical evidence and context related to
malware on a system.
• The information that can be extracted from memory
dumps includes hidden and terminated processes, traces
of memory injection, and hooking techniques used by
malware, metadata, and memory contents associated
with specific processes, executables, and network
connections.
• In addition, impressions and trace evidence such as those
discussed in Chapter 6 may be present in memory
dumps, waiting for digital investigators to find and
interpret them.
• However, because memory forensics is in the early stage
of development, it may not be able to recover the
desired information from a memory dump in all cases.
Therefore, it is important to take precautions to acquire
the memory contents of individual processes of interest
on the live system.
• Even when memory forensic tools can be employed in a
particular case, acquiring individual process memory
from the live system allows digital investigators to
compare the two methods to ensure they produce
consistent results.
• Furthermore, because malware can manipulate memory, it
is important to correlate critical findings with other
sources of data such as the file system, live response
data, and external sources such as logs from firewalls,
routers, and Web proxies.
Pitfalls to Avoid
Failing to Validate Your Findings
Do not rely on just one tool.
Learn the strengths and limitations of your tools through
testing and research.
Keep in mind that tools may report false positives when
attempting to detect suspicious code.
Use more than one tool and compare the results to
ensure that they are consistent.
Verify important findings manually by examining items
as they exist in memory, and review their surrounding
context for additional information that may have been
missed by the tools.
Failing to Understand Underlying Data Structures
Do not trust results of memory forensic tools without
verification.
Learn the data structures that are being extracted and
interpreted by memory forensic tools in order to validate
important findings.
When a tool fails to extract certain items of interest,
interpret the data yourself.
Find additional information in memory that memory
forensic tools are not currently programmed to recover.
Memory Forensics: Field Notes
Note: This document is not intended as a checklist, but rather as
a guide to increase consistency of forensic examination of
memory. When dealing with multiple memory dumps, it may be
necessary to tabulate the results of each individual examination
into a single document or spreadsheet.
Malware Forensic Tool Box
Memory Analysis Tools for Windows Systems
In this chapter we discussed approaches to interpreting data
structures in memory. There are a number of memory analysis
tools that you should be aware of and familiar with. In this
section, we explore these tool alternatives, often demonstrating
their functionality. This section can also simply be used as a “tool
quick reference” or “cheat sheet,” as there will inevitably be
times during an investigation where having an additional tool that
is useful for a particular function would be beneficial, since you
may have little time to conduct research for or regarding the
tool(s). It is important to perform your own testing and validation
of these tools to ensure that they work as expected in your
environment and for your specific needs.
Selected Readings
Books
1. Eagle C. The IDA Pro Book: The Unofficial Guide to
the World’s Most Popular Disassembler San Francisco,
CA: No Starch Press; 2008.
2. Ligh M, Adair S, Hartstein B, Richard M. Malware
Analysis Cookbook: Tools and Techniques for Fighting
Malicious Code New York: Wiley; 2010.
3. Malin C, Casey E, Aquilina J. Malware Forensics:
Investigating and Analyzing Malicious Code Burlington,
MA: Syngress; 2008.
4. Skoudis E, Zeltser L. Malware: Fighting Malicious Code
Upper Saddle River, NJ: Prentice Hall; 2003.
5. Szor P. The Art of Computer Virus Research and
Defense Mountain View, CA: Symantec Press; 2005.
Papers
1. Dolan-Gavitt B. The VAD Tree: A Process-Eye View
of Physical Memory. Digital Investigation. 2007;Vol.
4(Suppl. 1):62–64.
2. Dolan-Gavitt B. Forensic Analysis of the Windows
Registry in Memory. Digital Investigation. 2008;Vol.
5(Suppl. 1):S26–S32.
3. Hejazia SM, Talhia C, Debbabi M. Extraction of
Forensically Sensitive Information from Windows
Forensically Sensitive Information from Windows
Physical Memory. Digital Investigation. 2009;Vol.
6(Suppl. 1):S121–S131.
4. Kang, M., Poosankam, P., and Yin, H. (2007).
Renovo: A Hidden Code Extractor for Packed
Executables. WORM ’07, Proceedings of the 2007
ACM Workshop on Recurring Malcode. New York:
ACM.
5. Murphey R. Automated Windows event log forensics
in DFRWS2007 proceedings.
http://www.dfrws.org/2007/proceedings/p92-
murphey ; 2007; Available online at.
6. Petroni Jr NL, Walters A, Fraser T, Arbaugh WA.
FATKit: A Framework for the Extraction and Analysis
of Digital Forensic Data from Volatile System Memory.
Digital Investigation. 2006;Vol. 3(Issue 4):197–210.
7. Royal, P. (2006). PolyUnpack: Automating the
Hidden-Code Extraction of Unpack-Executing
Malware. Annual Computer Security Applications
Conference, Miami Beach, FL, December 11–15.
8. Saur K, Grizzard JB. Locating ×86 Paging Structures in
Memory Images. Digital Investigation. 2010;Vol.
7(Issues 1–2):28–37.
9. Stevens RM, Casey E. Extracting Windows Command
Line Details from Physical Memory. Digital
Investigation. 2010;Vol. 7(Suppl. 1):S57–S63.
10. Yegneswaran, V. et. al. (2008). Eureka: A
Framework for Enabling Static Analysis on
Malware. Technical Report Number SRI-CSL-08-01,
SRI Project 17382.
Jurisprudence/RFCs/Technical
Specifications
1. Columbia Pictures Indus. v. Bunnell, 2007 U.S. Dist.
LEXIS 46364 (C.D. Cal. June 19, 2007).
2. RFC 3227—Guidelines for Evidence Collection and
Archiving.
13 For more information about X-Ways, go to
http://www.x-ways.com/.
1 http://www.syngress.com/digital-forensics/Malware-
Forensics/.
2 Cheval and Oxley (2011), Masters Thesis, Johns
Hopkins University Information Security Institute.
3 Malin, C., Casey, E., and Aquilina, J. (2008). Malware
Forensics: Investigating and Analyzing Malicious
Code, Chap. 3, p. 147. Burlington, MA: Syngress.
4 http://code.google.com/p/volatility/wiki/Plugins.
5 For more information about AuditViewer, go to
http://www.mandiant.com/products/free_software/mandiant_audit_viewer/.
6 For more information about HBGary Responder, go to
http://www.hbgary.com/responder-field.
7 For more information about HBGary Responder Pro and
Digital DNA, go to http://www.hbgary.com/responder-
pro-2/; http://www.hbgary.com/digital-dna.
8 For more information about the Metasploit penetration
testing framework, go to http://www.metasploit.com/.
9 Malin, C., Casey, E., and Aquilina, J. (2008). Malware
Forensics: Investigating and Analyzing Malicious
Code, Chap. 3, pp. 130–131. Burlington, MA:
Syngress.
10 Cheval and Oxley (2011), Masters Thesis, Johns
Hopkins University Information Security Institute.
11
http://code.google.com/p/volatility/source/browse/branches/Volatility-
1.4_rc1/contrib/plugins/moddump.py?r=540.
12 Malin, C., Casey, E., and Aquilina, J. (2008). Malware
Forensics: Investigating and Analyzing Malicious
Code, Chap. 3, p. 143. Burlington, MA: Syngress.
14 For more information about X-Ways, go to
http://www.x-ways.com/.
http://www.forensickb.com/2007/11/extract-mft-
records-from-memory-dump.html.
15 http://code.google.com/p/volatility/wiki/Plugins.
16 Malin, C., Casey, E., and Aquilina, J. (2008). Malware
Forensics: Investigating and Analyzing Malicious
Code, Chap. 3, pp. 144–146. Burlington, MA:
Syngress.
17 For more information about pmdump, go to
http://www.ntsecurity.nu/toolbox/pmdump/.
18 For more information about RAPIER, go to
http://code.google.com/p/rapier/.
19 For more information about Microsoft User Mode
Process Dumper, go to
http://www.microsoft.com/downloads/en/details.aspx?
FamilyID=E089CA41-6A87-40C8-BF69-
28AC08570B7E&displaylang=en.
20 http://code.google.com/p/volatility/wiki/Plugins.
Chapter 3
Post-Mortem Forensics
Discovering and Extracting Malware and Associated
Artifacts from Windows Systems
Solutions in this chapter:
• Windows Forensic Analysis Overview
• Forensic Examination of Compromised Windows
Systems
• Malware Discovery and Extraction from Windows
Systems
• Examine Windows File System
• Examine Windows Registry
• Keyword Searching
• Forensic Reconstruction of Compromised Windows
Systems
• Advanced Malware Discovery and Extraction from a
Windows System
Introduction
If live system analysis can be considered surgery, forensic
examination of Windows systems can be considered an autopsy
of a computer impacted by malware. Trace evidence relating to
a particular piece of malware may be found in various places on
the hard drive of a compromised system, including files, Registry
entries, records in event logs, and associated date stamps. Such
trace evidence is an important part of analyzing malicious code
by providing context and additional information that help us
understand the functionality and origin of malware.
This chapter provides a repeatable approach to conducting
forensic examinations in malware incidents by increasing the
consistency across multiple computers and enabling others to
evaluate the process and results. Employing this approach, with a
measure of critical thinking on the part of a digital investigator,
can uncover information necessary to discover how malware
was placed on the system (aka the intrusion vector), to
determine malware functionality and its primary purpose (e.g.,
password theft, data theft, remote control) and to detect other
infected systems. This forensic examination process can be
applied to both a compromised host and a test system purposely
infected with malware in order to learn more about the behavior
of the malicious code.
Investigative Considerations
• In the past, it was relatively straightforward to uncover
traces of malware on the file system and in the Registry
of a compromised Windows computer. Recently,
attackers have been employing more anti-forensic
techniques to conceal their activities. Modern malware is
being designed to leave limited traces on the
compromised host and to misdirect forensic examiners.
A methodical approach to forensic examination, looking
carefully at the system from all perspectives, increases
the chances of uncovering footprints that the intruder
failed to hide.
Windows Forensic Analysis Overview
After a forensic duplicate of a compromised system has
been acquired, employ a consistent forensic examination
been acquired, employ a consistent forensic examination
approach to extract the maximum amount of information
relating to the malware incident.
The hard drive of a Windows computer can contain
traces of malware in various places and forms, including
malicious files, Registry entries, log files, Web browser history
and remnants of installation, and execution and manipulation such
as Prefetch files and date-time tampering. Some of this
information has associated date-time stamps that can be useful
for determining when the initial compromise occurred and what
happened subsequently. The following general approach is
designed to extract the maximum amount of information related
to a malware incident:
• Search for known malware
• Survey installed programs
• Examine prefetch
• Inspect executables
• Review auto-start
• Review scheduled jobs
• Examine logs (system logs, AntiVirus logs, Web browser
history, etc.)
• Review user accounts
• Examine file system
• Examine registry
• Restore points
• Perform keyword searches for any specific, known
details relating to a malware incident. Useful keywords
may come from other forms of analysis, including
memory forensics and analysis of the malware.
• Harvest available metadata including file system date-time
stamps, modification times of Registry entries, e-mails,
Prefetch file details and entries in Web browser history,
and Windows Event logs and other logs such those
created by AntiVirus programs. Use this information to
created by AntiVirus programs. Use this information to
determine when the malware incident occurred and what
else was done to the system around that time, ultimately
generating a time line of potentially malicious events.
• Look for common indicators of anti-forensics including
file system date-time stamp manipulation and log
deletion.
• Look for links to other systems that may be involved.
These goals are provided as a guideline and not as a
checklist for performing Windows forensic analysis. No single
approach can address all situations, and some of these goals may
not apply in certain cases. In addition, the specific
implementation will depend on the tools that are used and the
type of malware involved. Some malware may leave traces in
novel or unexpected places on a Windows computer, including
in the Master Boot Record (MBR) or within other files.
Ultimately, the success of the investigation depends on the
abilities of the digital investigator to apply digital forensic
techniques and adapt them to new challenges.
Analysis Tip
Correlating Key Findings
As noted in prior chapters, knowing the time period of the
incident and knowing what evidence of malware was observed
can help digital investigators develop a strategy for scouring
compromised computers for relevant digital evidence. Therefore,
prior to performing forensic analysis of a compromised
computer, it is advisable to review all information from the Field
Interview Questions in Chapter 1 to avoid wasted effort and
missed opportunities. Findings from other data sources such as
memory dumps and network logs can also help focus the
forensic analysis (i.e., the compromised computer was sending
packets to a Russian IP address, providing an IP address to
packets to a Russian IP address, providing an IP address to
search for in a given time frame). Similarly, the results of static
and dynamic analysis covered in later chapters can help guide
forensic analysis of a compromised computer. So, the analysis of
one malware specimen may lead to further forensic examination
of the compromised host that uncovers additional malware that
requires further analysis; this cyclical analysis ultimately leads to a
comprehensive reconstruction of the incident. In addition, as new
traces of malicious activity are uncovered through forensic
examination of a compromised system, it is important to
document them in a manner that facilitates forensic analysis. One
effective approach is to insert new findings into a time line of
events that gradually expands as the forensic analysis proceeds.
This is particularly useful when dealing with multiple
compromised computers. By generating a single time line for all
systems, forensic analysts are more likely to observe
relationships and gaps that need to be filled with further analysis.
Investigative Considerations
• It is generally unrealistic to perform a blind review on
certain structures that are too large or too complex to
analyze without some investigative leads. Therefore, it is
important to use all of the information available from
other sources to direct a forensic analysis of the
compromised system, including interview notes,
spearfishing e-mails, volatile data, memory dumps, and
logs from the system and network.
• Most file system forensic tools do not provide full
metadata from an NTFS. When dealing with malware
that likely manipulated date-time stamps, it may be
necessary to extract additional attributes such as the
FILETIME details for comparison with the standard
attributes. Tools for extracting attributes from MFT
attributes. Tools for extracting attributes from MFT
entries such as TSK and analyzeMFT are presented in
the Tool Box appendix.
• It is important to look in all areas of a Windows system
where traces of malware might be found, even if a quick
look in a few common places reveals obvious signs of
infection. There may be multiple types of malware on a
computer, with more obvious signs of infection
presenting a kind of smoke screen that may distract from
more subtle signs of infection. Being thorough reduces
the risk that more subtle items will be overlooked.
• No one approach or tool can serve all needs in a forensic
examination. To avoid mistakes and missed
opportunities, it is necessary to compare the results of
multiple tools, to employ different analysis techniques,
and to verify important findings manually.
In addition to employing forensic tools, mount the
forensic duplicate as a logical volume to support
additional analysis.
Although forensic tools can support sophisticated
analysis, they cannot solve every problem relating to a malware
incident. For instance, running AntiVirus software against files on
the compromised system is an important step in examining a
compromised host. Figure 3.1 shows MountImage Pro1 being
used to mount a forensic duplicate so that it is accessible as a
logical volume on the forensic examination system without
altering the original evidential data.
Figure 3.1 MountImage Pro used to mount a forensic duplicate
Additional utilities such as FTK Imager, EnCase modules,
and Daemon Tools (www.daemon-tools.cc) for mounting a
forensic duplicate are discussed in the Tool Box section at the
end of this chapter.
Malware Discovery and Extraction from
Windows Systems
Employing a methodical approach to examining areas of the
compromised system that are most likely to contain traces of
malware installation and use increases the chances that all traces
of a compromise will be uncovered, especially when performed
with feedback from the static and dynamic analysis covered in
Chapters 5 and 6.
Search for Known Malware
Use characteristics from known malware to scour the
file system for the same or similar items on the
compromised computer.
Many intruders will use easily recognizable programs
such as known rootkits, keystroke-monitoring programs,
sniffers, and components from the PSTools package (e.g.,
psexec for starting a service remotely). There are several
approaches to locating known malware on a forensic duplicate
of a compromised computer.
• Hashes: Searching a forensic duplicate of a
compromised system for hash values matching known
malware may identify other files with the same data but
different names. The hash value of the full file will only
reveal exact matches (see Figure 3.2), but an alternate
approach involves searching for hash values of smaller
parts of malware.
One tool that is specifically designed to detect known
malware is Gargoyle Forensic Pro (see Figure 3.3).2
This program contains a database of known malware
that is regularly updated and can be used to scan a
forensic duplicate.
Figure 3.2 AFX Rootkit found using MD5 Hash
Figure 3.3 Scanning a target drive image with Gargoyle
• Piecewise Hashes: A piecewise hashing tool such as
ssdeep3 may reveal malware files that are largely similar
with slight variations. Using the matching mode, with a
list of fuzzy hashes of known malware, may find
specimens that are not detected with an exact hash
match or by current anti-virus definitions (e.g., when
embedded IP addresses change).
• AntiVirus: Scanning files within a forensic duplicate of a
compromised system using updated AntiVirus programs
may identify known malware. To increase the chances of
detecting malware, multiple AntiVirus programs can be
used with any heuristic capabilities enabled. Such
scanning is commonly performed by mounting a forensic
duplicate on the examination system and configuring
AntiVirus software to scan the mounted volume as
shown in Figure 3.4 using Avira.4
Figure 3.4 Avira A/V software scanning a mounted forensic
duplicate
• In addition to scanning logical files, it can be worthwhile
to carve all executables out of unallocated space and
scan them using AntiVirus software as well, particularly
when malware has been deleted by the intruder (or by
AntiVirus software that was running on the compromised
system).
Analysis Tip
Existing AntiVirus Logs
Given the prevalence of AntiVirus software, it is advisable to
review any logs that were created by AntiVirus software that
was running on the compromised system for indications of
malware that was detected and deleted as discussed in the
“Examine Logs” section later in this chapter. Many AntiVirus
programs have Quarantine features that back up detected
malware in a specially formatted file. Some vendors provide
utilities for decoding these quarantine backup files to enable
recovery of the actual malware for analysis.
• Keywords: Searching for IRC commands and other traits
commonly seen in malware, and any characteristics that
have been uncovered during the digital investigation (e.g.,
IP addresses observed in network-level logs) may
uncover malicious files on the system.
Investigative Considerations
• Some malware is specifically designed to avoid detection
using hash values, AntiVirus signatures, or other similarity
characteristics. Therefore, the absence of evidence in an
AntiVirus scan or hash analysis should not be interpreted
as evidence that no known malware is on the system.
• Keyword searches for common characteristics in
malware can also trigger AntiVirus definition files,
resulting in false positives.
Survey Installed Programs
Review the programs that are installed on the
Review the programs that are installed on the
compromised system for potentially malicious
applications.
Surveying the names and installation dates of programs
that were installed on the compromised computer may reveal
ones that are suspicious, as well as legitimate programs that can
be used to gain remote access or to facilitate data theft.
• This process does not require in-depth analysis of each
program. Instead look for items that are unexpected,
questionable, or were installed around the time of the
incident.
• Folders under “Program Files” show only some of the
programs that are installed on a Windows system.
Subfolders under each user profile can reveal
applications installed under specific user accounts. There
are also locations in the Registry where digital
investigators look for traces of installed programs and
applications that were installed but have since been
removed from the computer, as discussed in the section
Examine Windows Registry later in this chapter.
• A malicious program may be apparent from a folder in the
file system (e.g., keyloggers, WinRAR) or from a
Registry entry. Figure 3.5 shows subfolders under
Program Files on a Windows system, which include a
keylogger program.
Figure 3.5 Program Files contains SpyKeyLogger
• Legitimate programs installed on a computer can also play
a role in malware incidents. For instance, WinRAR or
remote desktop programs (e.g., RDP, VNC) installed
on a system may be normal in certain environments, but
their availability may have enabled intruders to use them
for malicious purposes such as packaging sensitive
information before stealing it over the network.5
Coordination with the victim organization can help
determine if these are legitimate typical business use
applications. Even so, keep in mind that they could be
abused/utilized by the intruder and associated log review
may be fruitful.
Analysis Tip
Registry Remnants
The SOFTWARE Registry hive contains configuration
information for installed applications and has a key
“Microsoft\Windows\CurrentVersion\App Paths” that contains a
list of executable paths for installed applications. The Windows
Registry Database (WiReD) project being developed by NIST
Registry Database (WiReD) project being developed by NIST
NSRL is currently working on a library of Registry remnants left
by common programs to help digital investigators determine what
programs were installed on a computer.
Examine Prefetch Files
Inspect the creation date and other attributes of
Prefetch files on the compromised system to determine
whether they relate to execution of malware.
When malware, or any executable for that matter, is
launched on a Windows system it may generate a Prefetch file.
The creation date of a particular Prefetch file generally shows
when the associated program was first executed on the system,
and the last modified date indicates when it was most recently
executed. Tools for parsing Prefetch files include Prefetch
Parser6 and WinPrefetchView.7
• In addition to providing temporal information, Prefetch
files contain information about the location of the
associated executable on the file system as well as the
number of times that the executable was run as shown in
Figure 3.6.
Figure 3.6 Example of Prefetch related to Poison Ivy malware
viewed using WinPrefetch View
Investigative Considerations
• Examining the NTOSBOOT-BOODFAAD.pf file can
help identify what is being loaded at boot time on a
Windows system.
• A Prefetch file can remain on a compromised system long
after the originating executable is gone, and can be the
only remaining indication that a particular executable
existed on the system.
• Keep in mind that not all actions on a Windows computer
will result in a Prefetch file being created, and that
Prefetch files may be deleted. Therefore, the lack of a
Prefetch file does not mean that a particular program
was not executed (absence of evidence is not evidence
of absence).
Inspect Executables
Determine whether any executables on the
compromised system exhibit suspicious or unusual
characteristics that might be used to conceal their
characteristics that might be used to conceal their
presence.
Attackers commonly try to make malware more difficult
to find and detect, so often digital investigators can look for
common concealment techniques by carefully inspecting
executables. This inspection can involve looking for misleading
file extensions, packed executables, and alternate data streams.
• Extension renaming: One of the simplest approaches
used to conceal executables on a Windows system is to
change the extension to something else.
• Packing: Modern malware is often encoded (aka
packed) to thwart detection and forensic analysis.
• Alternate data streams: Look for executables in an
ADS of other files or folders.
Investigative Considerations
• Reviewing every potential executable on a computer is a
time-consuming process, and an important file may be
missed in the mass of information. Fortunately, in many
cases, there are known time periods of interest or other
clues that focus forensic analysis and reduce the number
of files that need to be reviewed for suspicious
characteristics.
• The increase in “spearfishing attacks” that employ social
engineering to trick users to click on e-mail attachments,
combined with malware embedded in Microsoft Office
documents and Adobe PDFs as discussed in Chapter 5,
means that digital investigators need to expand searches
for malware to include objects embedded in documents
and e-mail attachments.
Inspect Services, Drivers, Auto-starting Locations, and
Scheduled Jobs
Look for references to malware in the various startup
routines on the compromised system to determine how
malware managed to remain running on a Windows
system after reboots.
To remain running after reboots, malware is usually re-
launched using some of the various startup routines on a
Windows system, including services, drivers, scheduled tasks,
and other startup locations.
• Schedule Tasks : Some modern malware uses the Task
Scheduler to periodically execute and maintain
persistence on the system. Therefore, it is necessary to
examine scheduled jobs that are stored in the
“Windows\Tasks” folder in data files with the name of
the application and the file extension .job.
• Services: It is extremely common for malware to
entrench itself within a new, unauthorized service or by
inserting itself as the ImagePath or ServiceDll for an
existing service.
• Drivers: Drivers are commonly used as rootkit
components to malware packages, and may be started
via a variety of means.
• AutoRun locations: Locations that Windows uses to
automatically launch an executable as the system starts
up may contain traces of malware. The AutoRuns tool
can be used to examine auto-start items as shown in
Figure 3.7, directing it to analyze a mounted forensic
image via the File -> Analyze Offline System. Items
displayed by AutoRuns that are missing or are unsigned
and do not have a publisher description may be of
and do not have a publisher description may be of
interest in malware incident.
Figure 3.7 AutoRuns used to analyze an offline system
Investigative Considerations
• Be aware that not all methods used by malware to
entrench itself on a Windows computer will be detected
by AutoRuns or similar tools. For instance, the order in
which Windows searches for dependencies may be used
to execute malware. Therefore, even if nothing unusual is
found during this inspection of auto-start locations, there
may still be persistent malware on the system.
• It may not be a simple matter to distinguish between
legitimate system processes and malware in Windows
auto-start locations. Therefore, it may be necessary to
combine multiple tools and analysis techniques. For
example, inspecting all changes to the file system and
example, inspecting all changes to the file system and
Registry during the period of interest can lead digital
investigators to the pertinent file names and auto-start
entries used by malware. In addition, looking for
unsigned executables referenced in a startup routine may
reveal unauthorized code.
Examine Logs
Look in all available log files on the compromised
system for traces of malicious execution and associated
activities such as creation of a new service.
Log files can provide some of the most useful historical
detail relating to a malware incident, giving visibility into past
events, the sequence of activities related to an attack, and clues
about what the intruder did on the compromised system. The
logs that are available on a Windows system will depend on its
configuration and installed programs. Some of the more common
log files are summarized here with examples of their usefulness.
• Windows Event Logs: Logon events recorded in the
security event log, including logons via the network,
Remote Desktop, and Remote Authentication Services,
can reveal that malware or an intruder gained access to a
compromised system via a given account at a specific
time. Other events around the time of a malware
infection can be captured in Windows Event logs,
including the creation of a new service or new accounts
around the time of an incident. Windows Event logs can
be examined using tools such as Log Parser8 and Event
Log Explorer9 as shown in Figure 3.8 with the ability to
filter on specific types of events. Additional information
filter on specific types of events. Additional information
about Log Parser and its flexibility is available in
Microsoft Log Parser Toolkit from Syngress.10
Figure 3.8 Windows System Event log being examined using
Event Log Explorer, filtering on errors associated with services
(Event IDs 7026 and 7030)
• Web browser history: The records of Web browsing
history on a compromised computer can reveal access to
malicious Web sites and subsequent download of
malware. In addition, some malware leaves traces in the
Web browser history when it spreads to other machines
on the network.
• Desktop firewall logs: Windows firewall and other
desktop security programs may be configured to record
access attempts and other activities on the compromised
system.
• AntiVirus logs: When a Windows system is
compromised, AntiVirus software may detect and even
compromised, AntiVirus software may detect and even
block malicious activities. Such events will be recorded
in a proprietary log file with associated date-time stamps,
and any quarantined items may still be stored by the
AntiVirus software in a holding area.
• Dr. Watson : The Dr. Watson log, located in
“Drwtsn32.log,” can contain information about programs
that crashed and produced debug information. When Dr.
Watson traps a crashing program, it can create a file
named “User.dmp” containing memory contents from the
crash, which may provide additional information.
Investigative Considerations
• Log files can reveal connections from other systems that
provide links to other systems on the network that may
be compromised.
• It is common to extract Windows event logs from a
forensic duplicate for examination. However, message
details that were unique to the compromised system may
not be available when performing this type of analysis.
Therefore, it may be necessary to reconstruct the event
details or review specific log entries of interest on a
resuscitated clone of the compromised system as
discussed in the “Forensic Reconstruction of
Compromised Windows Systems” section later in this
chapter.
• Windows event logs may be deleted in a malware
incident, requiring a search of unallocated space for
important entries.
Analysis Tip
Domain Controller Security Event Logs
Domain Controller Security Event Logs
In some enterprise environments domain controllers are relied on
for security logging, so local security event logging is disabled on
the Windows computers that are part of the domain. In addition,
DNS logs from a domain controller can be extremely important
when tracking beacons to DNS host names. Given the volume of
event logs on domain controllers, there may be a retention period
of just a few days and digital investigators must preserve those
logs quickly or risk losing this information.
Review User Accounts and Logon Activities
Verify that all accounts used to access the system are
legitimate accounts and determine when these accounts
were used to log onto the compromised system.
Look for the unauthorized creation of new accounts on
the compromised system, accounts with no passwords, or
existing accounts added to Administrator groups.
• Unauthorized account creation: This is identified by
unusual names or accounts created in close proximity to
known unauthorized events.
• Administrator groups: It is advisable to check for user
accounts that are not supposed to be in local or domain
level administrator groups.
• Weak passwords: In some situations it may be
necessary to look for accounts with no passwords or
easily guessed passwords. A variety of tools are
designed for this purpose, including PRTK,11 John the
Ripper,12 and Cain & Abel.13 Rainbow tables are
created by precomputing the hash representation of
passwords and creating a lookup table to accelerate the
process of checking for weak passwords.
Investigative Considerations
• Failed logon attempts can be important when repeated
efforts were made to guess the passwords.
Analysis Tip
Correlation with Logons
Combine a review of user accounts with a review of Windows
Security Event Logs on the system to determine logon times,
dates of account creation, and other activities related to user
account activity on the compromised system. This can reveal
unauthorized access, including logons via Remote Desktop.
Examine Windows File System
Explore the file system for traces left by malware.
File system data structures can provide substantial
amounts of information related to a malware incident, including
the timing of events and the actual content of malware. However,
malware is increasingly being designed to thwart file system
analysis. Some malware alters date-time stamps on malicious
files to make it more difficult to find them with time line analysis.
Other malware is designed to download modular components
from the Internet and only store them in memory to minimize the
amount of data stored in the file system. To deal with such anti-
forensic techniques, it is necessary to pay careful attention to
forensic techniques, it is necessary to pay careful attention to
time line analysis of file system date-time stamps and to files
stored in common locations where malware might be found.14
• Search for file types that attackers commonly use to
aggregate and exfiltrate information. For example, if
RAR files are not commonly used in the victim
environment, searching for .RAR file extensions and
headers may reveal activities related to the intrusion.
• Time line analysis is one of the most powerful techniques
for organizing and analyzing file system information.
Combining date-time stamps of malware-related files
and system-related files such as link files and Prefetch
files can lead to an illuminating reconstruction of events
surrounding a malware incident, including the initial
vector of attack and subsequent entrenchment and data
theft.
• Review the contents of the “%systemroot%\system32”
folder for files with date-time stamps around the time of
the incident, or executables not associated with
Windows or any known application (hash analysis can
assist in this type of review to exclude known files).
• When one piece of malware is found in a particular folder
(e.g., C:\WINNT\Java, or a Temp folder), an inspection
of other files in that folder may reveal additional
malware.
• Shadow Volumes on Windows Vista and 7 can contain
copies of files that have since been deleted from the file
system.
Investigative Considerations
• Although it is becoming more common for Standard
Information Attribute (SIA) date-time stamps to be
Information Attribute (SIA) date-time stamps to be
modified by malware, the File Name Attribute (FNA) is
not typically updated. Therefore, discrepancies between
the SIA and FNA may indicate that date-time stamps
have been artificially manipulated.
• The NTFS journal ($LogFile) contains references to
MFT records that can be found by searching for the
record header strings FILE0 or FILE* (case sensitive).
Some forensic suites such as EnCase have the ability to
parse $LogFile entries.
• The increasing use of anti-forensic techniques in malware
is making it more difficult to find traces on the file system.
To mitigate this challenge, use all of the information
available from other sources to direct a forensic analysis
of the file system, including memory and logs.
• It is often possible to narrow down the time period when
that malicious activity occurred on a computer, in which
case digital investigators can create a time line of events
on the system to identify malware and related
components, such as keystroke capture logs.
Examine Windows Registry
Scour Registry hives for information related to
malware and associated activities.
Registry hives on a compromised system can contain
information directly related to the operation of malware (e.g.,
auto-start on boot, configuration parameters), and can contain
traces of activities related to malware.
• UserAssist: The UserAssist key contains a list of
programs run by user accounts on a compromised
system that can provide details about malicious activities
system that can provide details about malicious activities
along with a date-time stamp of most recent execution.
• Common locations: In addition to auto-start locations,
Registry hives on a compromised system can contain
configuration information and other trace evidence
created by malware. For instance, names of files that
were created or opened in relation to the malware may
be retained in most recently used (MRU) lists and
Windows Explorer shell bags in the Registry. RegRipper
has standard templates that can be applied to common
Registry hives to extract information that is generally
useful when investigating a malware incident as shown in
Figure 3.9.
Figure 3.9 RegRipper used to extract items from a System
Registry hive, noting errors in the process that should be
reviewed in the log file
• Temporal analysis : Search the Registry for items with
• Temporal analysis : Search the Registry for items with
LastWritten date-time stamps around the time of the
incident. The RegistryViewer from AccessData has a
feature for finding all alteration in a Registry hive within a
specific date range as shown in Figure 3.10.
Figure 3.10 Registry Viewer used to search for all items in the
Software Registry hive on a specific date
Restore Points
Some versions of Windows make routine backups of Registry
hives that can contain information that is no longer present in the
current Registry. In addition to looking in backup Registry hives
for the same information as in the current hives as summarized
earlier, there are unique types of analysis that the Restore Point
earlier, there are unique types of analysis that the Restore Point
backups can support.
• Look back: Information from past states of the system
that is captured in a Restore Point can be useful in an
intrusion and malware investigation.15
• Comparative analysis: Comparing the Registry from
prior states of a compromised system can uncover
important changes.16
• Temporal analysis : The LastWritten date-time stamps
within the backup Registry hives can help develop the
time line of malicious activities on a compromised
system.
Keyword Searching
Search for distinctive keywords each time such an item
is uncovered during forensic analysis.
Searching for keywords is effective when you know what
you are looking for but do not know where to find it on the
compromised system. There are certain features of a malware
incident that are sufficiently distinctive to warrant a broad search
of the system for related information. Such distinctive items
include:
• Command-line arguments: Looking for commands that
malware uses to execute processes on or obtain from
other systems on the network (e.g., psexec, net use) or
to exfiltrate data can reveal additional information related
to the intrusion.
• IP addresses: These may be stored in the human
readable dot decimal format (e.g., 172.16.157.136) in
readable dot decimal format (e.g., 172.16.157.136) in
both ASCII and Unicode formats, and may be
represented in hex (e.g., ac 10 9d 88) both in little and
big endian formats. Therefore, it may be necessary to
construct multiple keywords for a single IP address.
• Computer hostnames: Used to establish remote
connections with a compromised system, these may be
found in various locations, including Windows event logs.
• Passphrases and encryption keys: Searching for these
when associated with malicious code can uncover
additional information related to malware.
• File extensions and headers of file types: These are
commonly used to steal data (e.g., .RAR) and can find
evidence of data theft.
Analysis Tip
Search Smart
Significant time can be wasted searching for overly general or
incorrectly encoded keywords. Therefore, care must be taken to
construct an effective keyword list that considers how data will
be represented on the system.
Forensic Reconstruction of Compromised
Windows Systems
Performing a comprehensive forensic reconstruction
can provide digital investigators with a detailed
understanding of the malware incident.
Although it may seem counterintuitive to start creating a
time line before beginning a forensic examination, there is a
time line before beginning a forensic examination, there is a
strong rationale for this practice. Performing temporal analysis of
available information related to a malware incident should be
treated as an analytical tool, not just a by-product of a forensic
examination. Even the simple act of developing a time line of
events can reveal the method of infection and subsequent
malicious actions on the system. Therefore, as each trace of
malware is uncovered, any temporal information should be
inserted into a time line until the analyst has a comprehensive
reconstruction of what occurred.
Functional analysis of a compromised Windows system
involves creating a bootable clone of the system and examining it
in action. One approach to creating a bootable clone is using
LiveView,17 as shown in Figure 3.11. The snapshot feature in
VMWare gives digital investigators a great degree of latitude for
dynamic analysis on the actual victim clone image. In this
instance, malware was found in the “C:\I386\SYSTEM32”
folder and the digital investigator used a bootable clone of the
compromised system to observe the functionality of two
associated utilities. The interaction in Figure 3.11 shows vgalist
(renamed pslist) looking for a malicious process named skls, then
help for vgautils (rootkit named “fu”), and then using the rootkit
to hide the skls process and confirm it is hidden by checking
again with vgautils (pslist).
Figure 3.11 Forensic duplicate loaded into VMWare using
LiveView
• Another approach is to restore a forensic duplicate onto a
hard drive and insert the restored drive into a computer.
This is necessary when malware detects that it is running
in a virtualized environment and takes evasive action to
thwart forensic examination.
• In some situations, malware defense mechanisms may
utilize characteristics of the hardware on a compromised
computer such as MAC address, in which case it may
be necessary to use a clone hard drive in the exact
hardware of the compromised system that the forensic
duplicate was obtained from.
Advanced Malware Discovery and
Extraction from a Windows System
Since the Malware Forensics textbook was published in 2008,
more tools have been developed to address the increasing
problem of malware designed to circumvent information security
best practices and propagate within a network, enabling
criminals to steal data from corporations despite intrusion
detection systems and firewalls.
detection systems and firewalls.
Some tools, such as the Microsoft Malware Removal
Tool18 shown in Figure 3.12, can be used to check every
computer that is managed by an organization for certain malware
and report the scan results to a central location.
Figure 3.12 Microsoft Malware Removal Tool
Keep in mind that this approach is not targeted—it checks
for a variety of different malware rather than one specific
malware. In some situations, this broader net can be
advantageous by finding malware that was not the focus of the
investigation. Keep in mind also that this approach is designed to
remove malware from the system, which may not be desirable if
the goal is to perform further forensic analysis of the system.
Other COTS remote forensic tools such as FTK
Enterprise, EnCase Enterprise, and F-Response can be
configured to examine files, memory, and Registry entries on
remote systems for characteristics related to specific malware
(see Figure 3.13).
Figure 3.13 AccessData FTK Enterprise extracting information
from remote systems
In addition, some consulting companies that specialize in
intrusion investigation have developed proprietary tools to
examine remote systems for traces of malicious code.
Conclusions
If malware is present on a system, it can be found by applying
the forensic examination approach outlined in this chapter.
Following such a methodical, documented approach will uncover
the majority of trace evidence relating to malware incidents and
has the added benefit of being repeatable each time a forensic
examination is performed. By conducting each forensic
examination in a consistent manner, documenting each step along
the way, digital investigators will be in a better position when
their work is evaluated by others in court.
As more trace evidence is found on a compromised
system, it can be combined to create a temporal, functional, and
relational reconstruct of the malware incident. In addition,
relational reconstruct of the malware incident. In addition,
information recovered from compromised hosts can be
correlated with network-level logs and memory, as well as the
malicious code itself, to obtain a full picture of the malware
incident.
• Use characteristics extracted from one compromised host
to search other systems on the network for similar traces
of compromise.
Pitfalls to Avoid
Stepping in Evidence
Don’t perform the steps outlined in this chapter on the original
system.
Create a forensic duplicate of the hard drive from the
original system and perform all analysis on a working
copy of this data. In this way, no alterations are made to
the original evidence during the forensic examination.
Make working copies of the forensic duplicate to
ensure that any corruption or problems that arise during
a forensic examination do not ruin the only copy of the
forensic duplicate.
Missed or Forgotten Evidence
Do not skip a step in the forensic examination process for the
sake of expediency.
Make an investigative plan, and then follow it. This will
ensure that you include all necessary procedures.
Be methodical, reviewing each area of the system that
may contain trace evidence of malware.
Document what you find as you perform your work so
that it is not lost of forgotten later. Waiting to complete
documentation later generally leads to failure because
details are missed or forgotten in the fast pace of an
investigation.
Failure to Incorporate Relevant Information from Other
Sources
Do not assume that you have full information about the
incident or that a single person performed the initial incident
review and response.
Determine all of the people who performed field
interviews, volatile data preservation, and log analysis,
and obtain any information they gathered.
Review documentation such as the Field Interview
notes for information that can help focus and direct the
forensic examination. If a particular individual did not
maintain documentation of their work and findings, speak
with them to obtain details.
Windows System Examination: Field Notes
Note: This document is not intended as a checklist, but rather as
a guide to increase consistency of forensic examination of
compromised Windows systems. When dealing with multiple
compromised computer systems, it may be necessary to tabulate
the results of each individual examination into a single document
or spreadsheet.
Windows Analysis Tool Box
Forensic Analysis Tools for Windows Systems
In this chapter we discussed approaches to conducting a forensic
examination of Windows systems for malware and associated
artifacts. There are a number of forensic analysis tools that you
should be aware of and familiar with. In this section, we explore
these tool alternatives, often demonstrating their functionality.
This section can also simply be used as a “tool quick reference”
or “cheat sheet,” as there will inevitably be an instance during an
investigation where having an additional tool that is useful for a
particular function would be beneficial, but while responding in
the field you will have little time to conduct research for or
regarding the tool(s). It is important to perform your own testing
and validation of these tools to ensure that they work as
expected in your environment and for your specific needs.
Mounting Forensic Duplicates
Forensic Examination of Window Systems
Timeline Generation
Forensic Examination of Common Sources
of Information on Windows Systems
Selected Readings
Books
1. Altheide C, Carvey H. Digital Forensics with Open
Source Tools Burlington, MA: Syngress; 2011.
2. Carrier B. File System Forensic Analysis Reading, MA:
Addison-Wesley Professional; 2005.
3. Carvey H. Windows Registry Forensics: Advanced
Digital Forensic Analysis of the Windows Registry
Burlington, MA: Syngress; 2011.
4. Carvey H. Windows Forensic Analysis DVD Toolkit
Second Edition Burlington, MA: Syngress; 2009.
5. Casey E. Digital Evidence and Computer Crime, Third
Edition: Forensic Science, Computers, and the Internet
San Diego, CA: Academic Press; 2011.
6. Casey E. Handbook of Digital Forensics and
Investigation San Diego, CA: Academic Press; 2009.
7. Jones K, Bejtlich R, Rose C. Real Digital Forensics:
Computer Security and Incident Response Reading,
PA: Addison-Wesley Professional; 2005.
Papers
1. Bang J, Yoo B, Lee S. Analysis of Changes in File Time
Attributes with File Manipulation. Digital
Investigation. 2011;7(3–4):135–144.
2. Fellows G. NTFS Volume Mounts, Directory Junctions
and $Reparse. Digital Investigation. 2007;4(3–
4):116–118.
3. Fellows GH. The Joys of Complexity and the Deleted
File. Digital Investigation. 2005;2(2):89–93.
4. Harms K. Forensic Analysis of System Restore Points in
Microsoft Windows XP. Digital Investigation.
2006;3(3):151–158.
5. Huebner E, Bem D, Kai Wee C. Data Hiding in the
5. Huebner E, Bem D, Kai Wee C. Data Hiding in the
NTFS File System. Digital Investigation.
2006;3(4):211–226.
6. Kent K, et alNational Institute of Standards and
Technology. Guide to Integrating Forensic Techniques
into Incident Response. In:
http://csrc.nist.gov/publications/nistpubs/800-
86/SP800-86 ; 2006.
7. Mee V, Tryfonas T, Sutherland I. The Windows
Registry as a Forensic Artefact: Illustrating Evidence
Collection for Internet Usage. Digital Investigation.
2006;Vol. 3(no. 3):166–173.
8. National Institute of Justice (NIJ). Forensic Examination
of Digital Evidence: A Guide for Law Enforcement. In:
http://www.ncjrs.gov/pdffiles1/nij/199408 ;
2004.
9. Nolan R, et alCarnegie Mellon Software Engineering
InstituteComputer Emergency Response Team (CERT).
First Responders Guide to Computer Forensics. In:
www.cert.org/archive/pdf/FRGCF_v1.3 ; 2005.
10. Nolan RCarnegie Mellon Software Engineering
InstituteComputer Emergency Response Team (CERT).
First Responders Guide to Computer Forensics:
Advanced Topics. In:
www.cert.org/archive/pdf/05hb003 ; 2005.
11. Scientific Working Group on Digital Evidence
(SWGDE). SWGDE Technical Notes on Microsoft
Windows 7. In:
http://www.swgde.org/documents/current-
documents/SWGDE%20Technical%20Notes%20on%20Microsoft%20Windows%207
; 2010.
12. Scientific Working Group on Digital Evidence
(SWGDE). SWGDE Technical Notes on Microsoft
Vista v1.0. In:
http://www.swgde.org/documents/current-
documents/2008-02-
08%20SWGDE%20Technical%20Notes%20on%20Windows%20Vista%20v1.0
; 2008.
13. Zhu Y, Gladyshev P, James J. Using ShellBag
Information to Reconstruct User Activities
DFRWS2009. In:
http://www.dfrws.org/2009/proceedings/p69-zhu
; 2009.
; 2009.
14. Zhu Y, James J, Gladyshev P. A Comparative
Methodology for the Reconstruction of Digital Events
Using Windows Restore Points. Digital Investigation.
2009;Vol. 6(no. 1–2):8–15.
1 http://www.mountimage.com.
2 http://wetstonetech.com/cgi-bin/shop.cgi?view,2.
3 http://ssdeep.sourceforge.net.
4 http://www.avira.com/.
5 Fellows, G. (2010). WinRAR Temporary Folder
Artefacts, Digital Investigation, Vol. 7, no. 1–2, pp. 9–
13.
6
http://redwolfcomputerforensics.com/downloads/parse_prefetch_info_v1.4.zip.
7 http://www.nirsoft.net/utils/win_prefetch_view.html.
8 http://www.microsoft.com/downloads/en/details.aspx?
FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07.
9 http://www.eventlogxp.com/.
10 http://www.syngress.com/information-security-and-
system-administrators/Microsoft-Log-Parser-Toolkit/.
11 http://accessdata.com/products/computer-
forensics/decryption.
12 www.openwall.com/john/.
13 http://www.oxid.it/cain.html.
14 Pittman R., and Shaver D. (2009). Windows Forensic
Analysis in Handbook of Digital Forensics and
Investigation (Casey, E, ed.) Burlington, MA: Elsevier.
15 Harms, K. (2006). Forensic Analysis of System Restore
Points in Microsoft Windows XP, Journal of Digital
Investigation, Vol. 3, no. 3, pp. 107–184.
16 Zhu, Y., James, J., and Gladyshev, P. (2009). A
Comparative Methodology for the Reconstruction of
Digital Events Using Windows Restore Points, Digital
Investigation, Vol. 6, no. 1–2, pp. 8–15.
17 http://liveview.sourceforge.net/.
18 http://www.microsoft.com/security/pc-security/malware-
removal.aspx.
Chapter 4
Legal Considerations
Solutions in this chapter:
• Framing the Issues
• General Considerations
The Legal Landscape
• Sources of Investigative Authority
Jurisdictional Authority
Private Authority
Statutory/Public Authority
• Statutory Limits on Authority
Stored Data
Real-time Data
Protected Data
• Tools for Acquiring Data
Business Use
Investigative Use
Dual Use
• Acquiring Data Across Borders
Workplace Data in Private or Civil Inquiries
Workplace Data in Government or Criminal Inquiries
• Involving Law Enforcement
Victim Reluctance
Victim Misperception
The Law Enforcement Perspective
Walking the Line
• Improving Chances for Admissibility
Documentation
Preservation
Chain of Custody
Legal Considerations Appendix and Web Site
The symbol references throughout this chapter denote the
availability of additional related materials appearing in the Legal
Considerations appendix at the end of this chapter. Further
updates for this chapter can be found on the companion
Malware Field Guides Web site, at
http://www.malwarefieldguide.com/Chapter4.html.
http://www.malwarefieldguide.com/Chapter4.html.
Framing The Issues
This chapter endeavors to explore the legal and regulatory
landscape when conducting malware analysis for investigative
purposes, and to discuss some of the requirements or limitations
that may govern the access, preservation, collection, and
movement of data and digital artifacts uncovered during malware
forensic investigations.
This discussion, particularly as presented here in
abbreviated Field Guide format, does not constitute legal advice,
permission, or authority, nor does this chapter or any of the
book’s contents confer any right or remedy. The goal and
purpose instead is to offer assistance in critically thinking about
how best to gather malware forensic evidence in a way that is
reliable, repeatable, and ultimately admissible. Because the legal
and regulatory landscape surround-ing sound methodologies and
best practices is admittedly complicated, evolving, and often
unclear, do identify and consult with appropriate legal counsel
and obtain necessary legal advice before conducting any
malware forensic investigation.
General Considerations
Think early about the type of evidence you may
encounter.
• Seek to identify, preserve, and collect affirmative
evidence of responsibility or guilt that attributes
knowledge, motive, and intent to a suspect, whether an
unlikely insider or an external attacker from afar.
• Often as important is evidence that exculpates or
excludes from the realm of possible liability for the
actions or behavior of a given subject or target.
• The lack of digital artifacts suggesting that an incident
stemmed from a malfunction, misconfiguration, or other
non-human initiated systematic or automated process is
often as important to identify, preserve, and collect as
often as important to identify, preserve, and collect as
affirmative evidence.
Be dynamic in your investigative approach.
• Frame and re-frame investigative objectives and goals
early and often.
• Design a methodology ensuring that investigative steps will
not alter, delete, or create evidence, tip off a suspect, or
otherwise compromise the investigation.
• Create and maintain at all times meticulous step-by-step
analytical and chain of custody documentation.
• Never lose control over the evidence.
The Legal Landscape
Navigate the legal landscape by understanding legal
permissions or restrictions as they relate to the
investigator, the victim, the digital evidence, the
investigatory tools, and the investigatory findings.
The Investigator
• The jurisdiction where investigation occurs may require
special certification or licensing to conduct digital
forensic analysis.
• Authority to investigate must exist, and that authority is
not without limit.
• The scope of the authorized investigation will likely be
defined and must be well understood.
The Victim
• Intruding on the privacy rights of relevant victim data
custodians must be avoided.
• Other concerns raised by the victim might limit access to
digital evidence stored on stand-alone devices.
• With respect to network devices, collection, preservation,
and analysis of user-generated content (as compared to
file or system metadata analysis) are typically handled
pursuant to a methodology defined or approved by the
victim.
• It is important to work with the victim to best understand
• It is important to work with the victim to best understand
the circumstances under which live network traffic or
electronic communications can be monitored.
The Data
• Encountered data, such as personal, payment card,
health, financial, educational, insider, or privileged
information, may be protected by state or federal law in
some way.
• Methods exist to obtain overseas evidence necessary to
forensic analysis.
• In certain jurisdictions, restrictions may exist that prohibit
the movement or transportation of relevant data to
another jurisdiction.
The Tools
• In certain jurisdictions, limitations relating to the types of
investigative tools available to conduct relevant forensic
analysis may exist.
• The functionality and nature of the use of investigative
tools implicate these limitations.
The Findings
• Understanding evidentiary requirements early on will
improve chances for admissibility of relevant findings
down the road.
• Whether and when to involve law enforcement in the
malware investigation is an important determination.
Sources of Investigative Authority
Jurisdictional Authority
Because computer forensics, the discipline, its tools,
and training, have grown exponentially in recent years,
legislation has emerged in the United States that often
requires digital investigators to obtain state-issued
requires digital investigators to obtain state-issued
licensure before engaging in computer forensic analysis
within a state’s borders.
Figure 4.1 Sources of investigative authority
When Private Investigation Includes Digital Forensics
• Approximately 45 states maintain private investigation
laws that generally require the investigator to submit an
application, pay a fee, possess certain experience
requirements, pass an examination, and periodically
renew the license once granted.1
• Many state laws generally define private investigation
to broadly include the “business of securing evidence to
be used before investigating committees or boards of
award or arbitration or in the trial of civil or criminal
cases and the preparation therefore.”2
• Although such laws do not appear to implicate digital
forensics conducted for investigatory purposes by
internal network administrators or IT departments on
data residing within a corporate environment or domain,3
once the investigation expands beyond the enterprise
environment (to other networks or an Internet service
provider, or involves the preservation of evidence for
provider, or involves the preservation of evidence for
the pursuit of some legal right or remedy), licensing
regulation appears to kick in within several state
jurisdictions.
Where Digital Forensics Requires PI Licensure
• Roughly 32 states’ statutes can be interpreted to include
digital forensic investigators, like those in force in
Florida, Georgia, Michigan, New York, Nevada,
Oregon, Pennsylvania, South Carolina, Texas, Virginia,
and Washington.
• On the other hand, some states exempt “technical
experts”4 or “any expert hired by an attorney at law for
consultation or litigation purposes”5 from private
investigation licensing requirements. Indeed, at least one
state, Delaware, has specifically excluded from
regulation “computer forensic specialists,” defined as
“persons who interpret, evaluate, test, or analyze pre-
existing data from computers, computer systems,
networks, or other electronic media, provided to them
by another person where that person owns, controls, or
possesses said computer, computer systems, networks,
or electronic media.”6 A subcommittee of the American
Bar Association (ABA) has urged the same result.7
• Given that most state licensing requirements vary and may
change on a fairly regular basis, consult the appropriate
state agency in the jurisdiction where you will perform
digital forensic analysis early and often. Navigate to
http://www.crimetime.com/licensing.htm or
http://www.pimagazine.com/private_investigator_license_requirements.html
to find relevant links pertaining to your jurisdiction and
obtain qualified legal advice to be sure.
Potential Consequences of Unlicensed Digital Forensics
• Some legislation contains specific language creating a
private right of action for licensing violations.
• Indirect penalties may include equitable relief stemming
from unlawful business practice in the form of an
injunction or restitution order, exclusion of any evidence
gathered by the unlicensed investigator, or a client’s
declaration of breach of contract and refusal to pay for
declaration of breach of contract and refusal to pay for
the investigator’s services.
Private Authority
Authorization to conduct digital forensic analysis, and
the limits of that authority, depend not just on how and
where the data to be analyzed lives, but also on the person
conducting the analysis. The digital investigator derives
authority to investigate from different sources with
different constraints on the scope and methodology
governing that investigation.
Company Employee
• Internal investigators assigned to work an investigative
matter on behalf of their corporation often derive
authority to investigate from well-defined job
descriptions tied to the maintenance and security of the
corporate computer network.
• Written incident response policies may similarly inform
the way in which a network administrator or corporate
security department uses network permissions and other
granted resources to launch and carry out corporate
investigative objectives.
• Chains of corporate command across information
security, human resources, legal, and management teams
will inform key investigative decisions about containment
of ongoing network attacks, how best to correct damage
to critical systems or data, whether and the extent to
which alteration of network status data for investigative
purposes is appropriate, or even the feasibility of shutting
down critical network components or resources to
facilitate the preservation of evidence.
Retained Expert
• Internal considerations also indirectly source the
authority of the external investigator hired by corporate
security or in-house counsel or outside counsel on behalf
of the victim corporation.
• More directly, the terms and conditions set forth in
engagement letters, service agreements, or
engagement letters, service agreements, or
statements of work often specifically authorize and
govern the external investigator’s access to and analysis
of relevant digital evidence.
• Non-disclosure provisions with respect to confidential or
proprietary corporate information may not only obligate
the digital investigator to certain confidentiality
requirements, but also may proscribe the way in which
relevant data can be permissibly transported (i.e., hand-
carried not couriered or shipped) or stored for analysis
(i.e., on a private network with no externally facing
connectivity).
• Service contracts may require special treatment of
personal, payment card, health, insider, and other
protected data that may be relevant to forensic
investigation (a topic addressed later in the “Protected
Data” section of this chapter).
• A victim corporation’s obligations to users of the
corporate network may further limit grants of authority
to both the internal and external digital investigator.
An employee’s claims of a reasonable expectation of
privacy to data subject to digital forensic analysis may be
defeated if the employer—through an employment
manual, policy, or contract, a banner displayed at
user login, or some other means—has provided notice
to the employee otherwise.8
Whether analysis may be conducted of a suspect file
residing on a workstation dedicated for onsite use by the
company’s third party auditors will depend on the
written terms of a third-party service or user agreement.
• Sanctions ranging from personnel or administrative
actions, to civil breach of contract or privacy actions, to
criminal penalties can be imposed against investigators
who exceed appropriate authority.
Statutory/Public Authority
Law enforcement conducted digital forensic
investigations are authorized from public sources.
investigations are authorized from public sources.
The Special Case of Law Enforcement
• Federal and state statutes authorize law enforcement to
conduct malware forensic investigations with certain
limitations.9
• Public authority for digital investigators in law enforcement
comes with legal process, most often in the form of
grand jury subpoenas, search warrants, or court orders.
• The type of process often dictates the scope of
authorized investigation, both in terms of what, where,
and the circumstances under which electronic data may
be obtained and analyzed.
• Attention to investigating within the scope of what has
been authorized is particularly critical in law enforcement
matters where evidence may be suppressed and charges
dismissed otherwise.10
Acting in Concert with Law Enforcement
• Retained experts may be deemed to be acting in concert
with law enforcement—and therefore similarly limited to
the scope of the authorized investigation—if the retained
expert’s investigation is conducted at the direction of, or
with substantial input from, law enforcement.
• For more information, refer to the discussion of whether,
when, and how to involve law enforcement in conducting
malware forensic investigations, appearing later in the
“Involving Law Enforcement” section of this chapter.
Statutory Limits on Authority
In addition to sources and limits of authority tied to the person
conducting the analysis, authority also comes from regulations
that consider aspects of the relevant data itself; namely the type
of data, the quality of the data, the location of the data, when
the data will be used, and how the data will be shared.
Stored Data
Stored data relevant to a malware-related investigation
Stored data relevant to a malware-related investigation
may not be available under some circumstances,
depending on the type of data, the type of network, and to
whom disclosure of the data is ultimately made.
Authorization to access stored data depends on whether
the data is stored by a private or public provider, and if by
a public provider, whether the data sought to be accessed
constitutes content or non-content information.11
Private Provider
• Authorized access to stored e-mail data on a private
network that does not provide mail service to the public
generally would not implicate Electronics
Communications Privacy Act (ECPA) prohibitions
against access and voluntary disclosure, even to law
enforcement.12
• E-mail content, transactional data relating to e-mail
transmission, and information about the relevant user on
the network can be accessed and voluntarily disclosed to
anyone at will.
Public Provider—Non-Content
• If the network is a public provider of e-mail service, like
AOL or Yahoo! for example, content of its subscribers’
e-mail, or even non-content subscriber or
transactional data relating to such e-mails in certain
circumstances, cannot be disclosed, unless certain
exceptions apply.
• A public provider can voluntarily disclose non-content
customer subscriber and transactional information
relating to a customer’s use of the public provider’s mail
service:
1. To anyone other than law enforcement
2. To law enforcement:
a. With the customer’s lawful consent; or
b. When necessary to protect the public provider’s own
rights and property; or
c. If the public provider reasonably believes an emergency
involving immediate danger of death or serious bodily
injury requires disclosure.13
Public Provider—Content
• With respect to the content of a customer subscriber’s e-
mail, a public provider can voluntarily disclose to law
enforcement:
a. With the customer’s lawful consent; or
b. When necessary to protect the public provider’s own
rights and property; or
c. If the public provider inadvertently obtains content and
learns that it pertains to the commission of a crime; or
d. If the public provider reasonably believes an emergency
involving immediate danger of death or serious bodily
injury requires disclosure.14
• Of course, if the public provider is served with a grand
jury subpoena or other legal process compelling
disclosure, that is a different story.
• Otherwise, through the distinctions between content and
non-content and disclosure to a person and disclosure to
law enforcement, ECPA endeavors to balance private
privacy with public safety.
Real-time Data
For digital investigators who need to real-time monitor
the content of Internet communications as they are
happening, it is important to understand the requirements
of and exceptions to the federal Wiretap Act, the model for
most state statutes on interception as well.
Content
• The Wiretap Act, often referred to as “Title III,” protects
the privacy of electronic communications by prohibiting
any person from intentionally intercepting, or attempting
to intercept, their contents by use of a device.15
• In most jurisdictions, electronic communications are
“intercepted” within the meaning of the Wiretap Act
only when such communications are acquired
only when such communications are acquired
contemporaneously with their transmission, as opposed
to stored after transmittal.16
• There are three exceptions to the Wiretap Act relevant to
the digital investigator: the provider exception; consent
of a party; and the computer trespasser exception.
Content—The Provider Exception
• The provider exception affords victim corporations and
their retained digital investigators investigating the
unauthorized use of the corporate network fairly broad
authority to monitor and disclose to others (including
law enforcement) evidence of unauthorized access and
use, so long as that effort is tailored to both minimize
interception and avoid disclosure of private
communications unrelated to the investigation.17
• In practical terms, while the installation of a sniffer to
record the intruder’s communication with the victim
network in an effort to combat ongoing fraudulent,
harmful, or invasive activity affecting the victim
entity’s rights or property may not violate the Wiretap
Act, the provider exception does not authorize the more
aggressive effort to “hack back” or otherwise intrude on
an intruder by gaining unauthorized access to the
attacking system (likely an innocent compromised
machine anyway).
• Do not design an investigative plan to capture all traffic to
the victimized network; instead avoid intercepting traffic
communications known to be innocuous.
Content—The Consent Exception
• The consent exception authorizes interception of
electronic communications where one of the parties to
the communication18 gives explicit consent or is
deemed upon actual notice to have given implied
consent to the interception.19
• Guidance from the Department of Justice recommends
that “organizations should consider deploying written
warnings, or “banners,” on the ports through which an
intruder is likely to access the organization’s system and
on which the organization may attempt to monitor an
intruder’s communications and traffic.
intruder’s communications and traffic.
• If a banner is already in place, it should be reviewed
periodically to ensure that it is appropriate for the type
of potential monitoring that could be used in response
to a cyber attack.20
• If banners are not in place at the victim company,
consider whether the obvious notice of such banners
would make monitoring of the ongoing activities of the
intruder more difficult (and unnecessarily so where the
provider exception remains available) before consulting
with counsel to tailor banner content best suited to the
type of monitoring proposed.
• Solid warnings often advise users that their access to the
system is being monitored, that monitoring data may be
disclosed to law enforcement, and that use of the system
constitutes consent to surveillance.
• Keep in mind that while the more common network ports
are bannerable, the less common (the choice of the
nimble hacker) often are not.
Content—The Computer Trespasser Exception—Acting
in Concert with Law Enforcement
• The computer trespasser exception gives law enforcement
the ability with the victim provider’s consent to intercept
communications exclusively between the provider and an
intruder who has gained unauthorized access to the
provider’s network.21
• This exception is not available to digital investigators
retained by the provider, but only to those acting in
concert with law enforcement.
• Do not forget the interplay of other limits of authority
discussed elsewhere in this chapter, bearing in mind that
such limitations may trump exceptions otherwise
available under the Wiretap Act to digital investigators
planning to conduct network surveillance on a victim’s
network.
Non-Content
• For digital investigators who need only collect real-time
the non-content portion of Internet communications—the
source and destination IP address associated with a
network user’s activity, the header and “hop”
network user’s activity, the header and “hop”
information associated with an e-mail sent to or
received by a network user, the port that handled the
network user’s communication a network user uses to
communicate—be mindful that an exception to the
federal Pen Registers and Trap and Trace Devices
statute22nonetheless must apply for the collection to
be legal.
• Although the statute generally prohibits the real-time
capture of traffic data relating to electronic
communications, provider and consent exceptions
similar and broader to those found in the Wiretap Act
are available.
• Specifically, corporate network administrators and the
digital investigators they retain to assist have fairly
broad authority to use a pen/trap device on the
corporate network without court order so long as the
collection of non-content:
Relates to the operation, maintenance, and testing of the
network
Protects the rights or property of the network provider
Protects network users from abuse of or unlawful use of
service
Is based on consent
• Remember that surveillance of the content of any
communication would implicate the separate provisions
and exceptions of the Wiretap Act.
Protected Data
For the digital investigator tasked with performing
forensic analysis on malicious code designed to access,
copy, or otherwise remove valuable sensitive, confidential,
or proprietary information, understanding the nature of
federal and state protections of this data will help inform
necessary investigative and evidentiary determinations
along the way.
Federal Protection of Financial Information
• Responding to an incident at a financial institution that
• Responding to an incident at a financial institution that
compromises customer accounts may implicate the
provisions of the Gramm Leach Bliley Act, also known
as the Financial Services Modernization Act of 1999,
which protects the privacy and security of consumer
financial information that financial institutions
collect, hold, and process.23
• The Act generally defines a “financial institution” as any
institution that is significantly engaged in financial
activities.”24
• The regulation only protects consumers who obtain
financial products and services primarily for person,
family, or household purposes.
• The regulation:
Requires a financial institution in specified circumstances
to provide notice to customers about its privacy policies
and practices;
Describes the conditions under which a financial
institution may disclose non-public personal information
about consumers to non-affiliated third parties; and
Provides a method for consumers to prevent a financial
institution from disclosing that information to most non-
affiliated third parties by “opting out” of that disclosure,
subject to certain limited exceptions.
• In addition to these requirements, the regulations set forth
standards for how financial institutions must maintain
information security programs to protect the security,
confidentiality, and integrity of customer information.
Specifically, financial institutions must maintain adequate
administrative, technical, and physical safeguards
reasonably designed to:
Ensure the security and confidentiality of customer
information;
Protect against any anticipated threats or hazards to the
security or integrity of such information; and
Protect against unauthorized access to or use of such
information that could result in substantial harm or
inconvenience to any customer.
• Be careful when working with financial institution data to
obtain and document the scope of authorization to
obtain and document the scope of authorization to
access, transport, or disclose such data to others.25
Federal Protection of Health Information
• The Health Insurance Portability and Accountability Act
(HIPAA)26 applies generally to covered entities (health
plans, health-care clearinghouses, and health-care
providers who transmit any health information in
electronic form),27 and provides rules designed to ensure
the privacy and security of individually identifiable health
information (“protected health information”), including
such information transmitted or maintained in electronic
media (“electronic protected health information”).
• HIPAA specifically sets forth security standards for the
protection of electronic protected health information.
The regulation describes the circumstances in which
protected health information may be used and/or
disclosed, as well as the circumstances in which such
information must be used and/or disclosed.
The regulation also requires covered entities to establish
and maintain administrative, physical, and technical
safeguards to:
Ensure the confidentiality, integrity, and availability of all
electronic protected health information the covered
entity creates, receives, maintains, or transmits;
Protect against any reasonably anticipated threats or
hazards to the security or integrity of such information;
Protect against any reasonably anticipated uses or
disclosures of such information that are not otherwise
permitted or required by the regulation; and
Ensure compliance with the regulation by the covered
entity’s workforce.
• In February 2009, the American Recovery and
Reinvestment Act (ARRA) became law, subjecting
business associates—vendors, professional service
providers, and others that perform functions or activities
involving protected health information for or on behalf of
covered entities—to many of the health information
protection obligations that HIPAA imposes on covered
protection obligations that HIPAA imposes on covered
entities.28
• Given these stringent requirements, investigative steps
involving the need to access, review, analyze, or
otherwise handle electronic protected health information
should be thoroughly vetted with counsel to ensure
compliance with the HIPAA and ARRA security rules
and obligations.29
Federal Protection of Public Company Information
• The Sarbanes-Oxley Act (SOX)30 broadly requires
public companies to institute corporate governance
policies designed to facilitate the prevention, detection,
and handling of fraudulent acts or other instances of
corporate malfeasance committed by insiders.
• Other provisions of SOX were clearly designed to deter
and punish the intentional destruction of corporate
records.
• In the wake of SOX, many public companies overhauled
all kinds of corporate policies that may also implicate
more robust mechanisms for the way in which financial
and other digital corporate data is handled and stored.
• During the early assessment of the scope and limits of
authority to conduct any internal investigation at a public
company, be mindful that a SOX-compliant policy may
dictate or limit investigative steps.
Other Federally Protected Information
• Information About Children: The Child Online Privacy
Protection Act (COPPA) 31 prohibits unfair or deceptive
acts or practices in connection with the collection, use,
and/or disclosure of personal information from and about
children on the Internet. The Juvenile Justice and
Delinquency Prevention Act,32 governing both the
criminal prosecution and the delinquent adjudication of
minors in federal court, protects the juvenile defendant’s
identity from public disclosure.33 If digital investigation
leads to a child, consult counsel for guidance on the
restrictions imposed by these federal laws.
• Child Pornography: 18 U.S.C. § 1466A proscribes
among other things the possession of obscene visual
representations of the sexual abuse of children. Consider
representations of the sexual abuse of children. Consider
including in any digital forensic services contract language
that reserves the right to report as contraband to
appropriate authorities any digital evidence encountered
that may constitute child pornography.
• Student Educational Records: The Family Education
Rights and Privacy Act34 prevents certain educational
institutions from disclosing a student’s “personally
identifiable education information,” including grades and
student loan information, without the student’s written
permission. Again, authority to access and disclose this
type of information should be properly vetted with the
covered educational institution or its counsel.
• Payment Card Information: The Payment Card
Industry Data Security Standards (PCI DSS) established
common industry security standards for storing,
transmitting, and using credit card data, as well as
managing computer systems, network devices, and the
software used to store, process, and transmit credit card
data. According to these established guidelines,
merchants who store, process, or transmit credit card
information, in the event of a security incident, must take
immediate action to investigate the incident, limit the
exposure of cardholder data, make certain disclosures,
and report investigation findings. When handling PCI
data during the course of digital investigation, be sure to
understand these heightened security standards and
requirements for disclosure and reporting.
• Privileged Information: Data relevant to the digital
investigator’s analysis may constitute or be commingled
with information that is protected by the attorney–client
privilege or the attorney work product doctrine. Digital
investigator access to or disclosing of that data, if not
performed at the direction of counsel, may be alleged to
constitute a waiver of these special protections.
State Law Protections
• Forty-four states have passed a data breach notification
law requiring owners of computerized data that include
consumer personal information to notify any affected
consumer following a data breach that compromises the
security, confidentiality, or integrity of that personal
information.
information.
• The statutes generally share the same key elements, but
vary in how those elements are defined, including the
definitions of “personal information,” the entities
covered by the statute, the kind of breach triggering
notification obligations, and the notification procedures
required.35
• Personal information has been defined across these
statutes to include some or all of the following:
Social Security, Alien Registration, tribal, and other
federal and state government issued identification
numbers
Drivers’ license and non-operating license identification
numbers
Date of birth
Individuals’ mothers’ maiden names
Passport number
Credit card and debit card numbers
Financial account numbers (checking, savings, other
demand deposit accounts)
Account passwords or personal identification numbers
(PINs)
Routing codes, unique identifiers, and any other number
or information that can be used to access financial
resources
Medical information or health insurance information
Insurance policy numbers
Individual taxpayer identification numbers (TINs),
employer taxpayer identification number (EINs), or other
tax information
Biometric data (fingerprints, voice print, retina or iris
image)
Individual DNA profile data
Digital signature or other electronic signature
Employee identification number
Voter identification numbers
Work-related evaluations
• Most statutes exempt reporting if the compromised
information is “encrypted,” although the statues do not
always set forth the standards for such encryption. Some
states exempt reporting if, under all circumstances, there
states exempt reporting if, under all circumstances, there
is no reasonable likelihood of harm, injury, or fraud to
customers. At least one state requires a “reasonable
investigation” before concluding no reasonable likelihood
of harm.
• Notification to the affected customers are ordinarily
made in writing, electronically, telephonically, or, in the
case of large-scale breaches, through publication. Under
most state statutes, Illinois being an exception,
notification can be delayed if it is determined that the
disclosure will impede or compromise a criminal
investigation.
• Understanding the breach notification requirements of the
state jurisdiction in which the investigation is conducted is
important to the integrity of the digital examiner’s work,
as the scope and extent of permissible authority to
handle relevant personal information may be different
than expected. Consult counsel for clear guidance on
how to navigate determinations of encryption exemption
and assess whether applicable notice requirements will
alter the course of what otherwise would have been a
more covert operation designed to avoid tipping the
subject or target.
Tools for Acquiring Data
The digital investigator’s selection of a particular tool often has
legal implications. Nascent judicial precedent in matters involving
digital evidence has yielded no requirement that a particular tool
be used for a particular purpose. Instead, reliability, a theme
interwoven throughout this chapter and this entire Field Guide,
often informs whether and the extent to which the digital
investigator’s findings are considered.
Business Use
Output from tools used during the ordinary course of
business is commonly admitted as evidence absent some
showing of alteration or inaccuracy.
showing of alteration or inaccuracy.
Ordinary Course
• Intrusion detection systems
• Firewalls, routers, VPN appliances
• Web, mail, and file servers
Business Purpose
• Output from ordinary course systems, devices, and
servers constitutes a record generated for a business—a
class of evidence for which there exists recognized
indicia of reliability.
• Documentation and custodial testimony will support
admissibility of such output.
Investigative Use
Output from tools deployed for an investigatory
purpose is evaluated differently. Which tool was deployed,
whether the tool was deployed properly, and how and
across what media the tool was deployed are important
considerations to determinations of reliability.
Tool
• Simple traceroutes
• WHOIS lookups
• Other network-based tools
Deployment
• Inside the victim network
Was deployment in furtherance of maintaining the
integrity and safety of the victim network environment?
Was deployment consistent with documented internal
policies and procedures?
• Outside the victim network
Did deployment avoid the possibility of unauthorized
access or damage to other systems?
Did deployment avoid violating other limits of authority
Did deployment avoid violating other limits of authority
discussed earlier in this chapter?
Findings
• Repeatable
• Supported by meticulous note taking
• Investigative steps were taken consistent with corporate
policy and personal, customary, and best practice.
• Investigative use of tools was consistent without sound
legal advice.
Dual Use
Hacker tools and tools to affect security or conduct
necessary investigation are often one in the same. The
proliferation of readily downloadable “hacker tools”
packaged for wide dispersion has resulted in legal
precedent in some jurisdictions that inadequately
addresses this “dual use,” causing public confusion about
where the line is between the two and what the liabilities
are when that line is crossed.
Multiple Countries—Council of Europe Convention of
Cybercrime36
• What It Is:
Legally binding multilateral instrument that addresses
computer-related crime.
Forty-three countries have signed or ratified it, including
the United States.37
Each participating country agrees to ensure that its
domestic laws criminalize several categories of
computer-related conduct.
One such category, titled “Misuse of Devices,” intends to
criminalize the intentional possession of or trafficking in
“hacker tools” designed to facilitate the commission of a
crime.
• The Problem:
Software providers, research and security analysts, and
digital investigators might get unintentionally but
nonetheless technically swept up in less than carefully
worded national laws implemented by participating
countries.
The official Commentary on the substantive provisions of
the Convention that include Article 6 provides little
further illumination,38 but it does seem to exclude
application to tools that might have both legitimate and
illegitimate purposes.
United Kingdom—Computer Misuse Act/Police and
Justice Act
• What It Is:
Proposed amendments to the Computer Misuse Act of
1990 to be implemented through the Police and Justice
Act of 2006.39
Designed to criminalize the distribution of hacker tools.
• The Problem:
No dual-use exclusion.
Simple sharing of common security tools with someone
other than a known and trusted colleague could violate
the law.
“Believed likely to be misused” standard of liability is
vague.
Prosecution guidance40 is similarly vague.
Germany—Amendments to Section 202c
• What It Is
Amendments to the German Code41 broadly prohibiting
unauthorized users from disabling or circumventing
computer security measures in order to access secure
data.
The amendments also proscribe the manufacturing,
programming, installing, or spreading of software that has
the primary goal of circumventing security measures.
the primary goal of circumventing security measures.
• The Problem
Security analysts throughout the globe have criticized the
law as vague, overbroad, and impossible to comply with.
German security researchers have pulled code and other
tools offline for fear of prosecution.
United States—Computer Fraud and Abuse Act
• The Issue
Despite the United States’ participation in the Council of
Europe Convention on Cybercrime, Congress has not
amended the Computer Fraud and Abuse Act (CFAA)
to include “devices.”
The CFAA does create misdemeanor criminal liability for
“knowingly and with intent to defraud traffic[king] in any
password or similar information through which a
computer may be accessed without authorization.”42
• The Problem
What does “similar information” mean? Does it include
the software and tools commonly used by digital
investigators to respond to a security incident? Is the
statute really no different than the British and German
statutes?
Here is the party line, appearing in a document titled
“Frequently Asked Questions about the Council of
Europe Convention on Cybercrime,”43 released by the
U.S. Department of Justice when ratification of the
Convention was announced:
Figure 4.2 U.S. Department of Justice, “Frequently asked
questions about the Council of Europe Convention on
Cybercrime”
The Lesson
• Pay close attention to the emerging laws on misuse of
devices, particularly when conducting forensic analysis in
the 43 countries that have committed to implement the
Convention and its provisions.
• When in doubt, obtain appropriate legal advice.
Acquiring Data across Borders
In the United States, subject to the sources and limitations of
authority discussed earlier in this chapter, digital investigators are
often tasked early in the course of internal investigations to
thoroughly preserve, collect, and analyze electronic data residing
across corporate networks. At times, however, discovery and
other data preservation obligations reach outside domestic
borders to, for example, a foreign subsidiary’s corporate
network, and may conflict with foreign data protection laws that
treat employee data residing on company computers, servers,
and equipment as the personal property of the individual
employee and not the corporation.
Workplace Data in Private or Civil Inquiries
Handling of workplace data depends on the context of
the inquiry. Although more formal mechanisms exist for
the collection of digital evidence pursuant to government
the collection of digital evidence pursuant to government
or criminal inquiries, country-specific data privacy laws
will govern private or civil inquiries.
Europe
• Although inapplicable to data efforts made in the context
of criminal law enforcement or government security
matters, the 1995 European Union Data Protection
Directive,44 a starting point for the enactment of country-
specific privacy laws within the 27 member countries that
subscribe to it,45 sets forth 8 general restrictions on the
handling of workplace data46:
Limited Purpose: Data should be processed for a
specific purpose and subsequently used or
communicated only in ways consistent with that purpose.
Integrity: Data should be kept accurate, up to date, and
no longer than necessary for the purposes for which
collected.
Notice: Data subjects should be informed of the purpose
of any data processing and the identity of the person or
entity determining the purposes and means of processing
the data.
Access/Consent: Data subjects have the right to obtain
copies of personal data related to them, rectify
inaccurate data, and potentially object to the processing.
Security: Appropriate measures to protect the data must
be taken.
Onward Transfer: Data may not be sent to countries
that do not afford “adequate” levels of protection for
personal data.
Sensitive Data: Additional protections must be applied
to special categories of data revealing the data subject’s
racial or ethnic origin, political opinions, religious or
philosophical beliefs, trade union membership, health, or
sex life.
Enforcement: Data subjects must have a remedy to
redress violations.
• With respect to the restriction on onward transfer, no
definition of “adequate” privacy protection is provided in
the European (EU) Directive. Absent unambiguous
consent obtained from former or current employee data
subjects that affords the digital investigator the ability to
subjects that affords the digital investigator the ability to
transport the data back to the lab,47 none of the other
exceptions to the “onward transfer” prohibition in the EU
Directive appear to apply to internal investigations
voluntarily conducted by a victim corporation responding
to an incident of computer fraud or abuse. As such, the
inability to establish the legal necessity for data transfers
for fact finding in an internal inquiry may require the
digital investigator to preserve, collect, and analyze
relevant data in the European country where it is found.
Data Transfers from Europe to the United States
• When the EU questioned whether “adequate” legal
protection for personal data potentially blocked all data
transfers from Europe to the United States, the U.S.
Department of Commerce responded by setting up a
Safe Harbor framework imposing safeguards on the
handling of personal data by certified individuals and
entities.48
• In 2000, the EU approved the Safe Harbor framework as
“adequate” legal protection for personal data, approval
that binds all the member states to the Directive.49
• A Safe Harbor certification by the certified entity amounts
to a representation to European regulators and
individuals working in the EU that “adequate” privacy
protection exists to permit the transfer of personal data
to that U.S. entity.50
• Safe Harbor certification may nonetheless conflict with the
onward transfer restrictions of member state legislation
implemented under the Directive, as well as “blocking
statutes,” such as the one in France that prohibits French
companies and their employees, agents, or officers from
disclosing to foreign litigants or public authorities
information of an “economic, commercial, industrial,
financial, or technical nature.”51
Workplace Data in Government or Criminal Inquiries
Other formal and informal mechanisms to obtain
overseas digital evidence may be useful in the context of
overseas digital evidence may be useful in the context of
an internal investigation, to comply with U.S. regulatory
requirements, or when a victim company makes a criminal
referral to law enforcement.
Mutual Legal Assistance Request (MLAT)
• Parties to a bilateral treaty that places an unambiguous
obligation on each signatory to provide assistance in
connection with criminal and in some instances regulatory
matters may make requests between central authorities
for the preservation and collection of computer media
and digital evidence residing in their respective
countries.52
• The requesting authority screens and forwards requests
from its own local, state, or national law enforcement
entities, and the receiving authority then has the ability to
delegate execution of the request to one of its entities.
• For foreign authorities seeking to gather evidence in the
United States, the U.S. Department of Justice is the
central authority, working through its Office of
International Affairs.
• The central authority at the receiving end of an MLAT
request may be very reluctant to exercise any discretion
to comply. That being said, most central authorities are
incentivized to fulfill MLAT requests so that similar
accommodation will accompany requests in the other
direction.
Letter Rogatory
• A less reliable, more time-consuming mechanism of the
MLAT is the letter rogatory or “letter of request,” which
is a formal request from a court in one country to “the
appropriate judicial authorities” in another country
requesting the production of relevant digital evidence.53
• The country receiving the request, however, has no
obligation to assist.
• The process can take a year or more.
Informal Assistance
• In addition to the widely known Council of Europe and
G8, a number of international organizations are
attempting to address the difficulties digital investigators
attempting to address the difficulties digital investigators
face in conducting network investigations that so often
involve the need to preserve and analyze overseas
evidence.
• Informal assistance and support through the following
organizations may prove helpful in understanding a
complicated international landscape:
Council of Europe Convention of Cybercrime
http://conventions.coe.int/Treaty/Commun/QueVoulezVous.asp?
NT=185&CM=1&CL=ENG (and more generally)
http://www.coe.int/t/dc/files/themes/cybercrime/default_EN.asp?
G8 High-Tech Crime Subgroup
(Data Preservation Checklists)
http://www.coe.int/t/dg1/legalcooperation/economiccrime/cybercrime/Documents/Points%20of%20Contact/24%208%20DataPreservationChecklists_en
Interpol
Information Technology Crime—Regional Working
Parties
http://www.interpol.int/public/TechnologyCrime/Default.asp
European Network of Forensic Science Institutes
(Memorandum signed for International Cooperation in
Forensic Science)
http://www.enfsi.eu/page.php?uid=1&nom=153
Asia-Pacific Economic Cooperation
Electronic Commerce Steering Group
http://www.apec.org/apec/apec_groups/committee_on_trade/electronic_commerce.html
Organization for Economic Cooperation & Development
Working Party on Information Security & Privacy
(APEC-OECD Workshop on Malware—Summary
Record—April 2007)
http://www.oecd.org/dataoecd/37/60/38738890
Organization of American States
Inter-American Cooperation Portal on Cyber-Crime
http://www.oas.org/juridico/english/cyber.htm
Involving Law Enforcement
Whether a victim company chooses to do nothing, pursue civil
remedies, or report an incident to law enforcement affects the
scope and nature of the work of the digital investigator. Analysis
of identified malware might become purely academic once the
intrusion is contained and the network secured. Malware
functionality might be the subject of written or oral testimony
presented in a civil action when the victim company seeks to
obtain monetary relief for the damage done. The possibility of
criminal referral adjusts the investigative landscape as well.
Understanding the process victim corporations go through to
decide about whether and when to involve law enforcement will
help realize relevant consequences for the digital investigator.
Victim Reluctance
Victim companies are often reluctant to report
incidents of computer crime.54
• The threat of public attention and embarrassment,
particularly to shareholders, often casts its cloud over
management.
• Nervous network administrators, fearful of losing their
jobs, perceive themselves as having failed to adequately
protect and monitor relevant systems and instead focus
on post-containment and prevention.
• Legal departments, having determined that little or no
breach notification to corporate customers was required
in the jurisdictions where the business operates, would
rather not rock the boat.
• Audit committees and boards often would rather pay the
cyber extortionist’s ransom demand in exchange for a
“promise” to destroy the stolen sensitive data, however
unlikely, and even when counseled otherwise, rather than
involve law enforcement.
Victim Misperception
Many companies misperceive that involving law
enforcement is simply not worth it.
• Victims are confused about which federal, state, or local
agency to contact.
agency to contact.
• Victims are concerned about law enforcement agent
technical inexperience, agency inattention, delay,
business interference, and damage to network equipment
and data.
• Victims fear the need to dedicate personnel resources to
support the referral.
• Victims exaggerate the unlikelihood that a hacker kid
living in a foreign country will ever see the inside of a
courtroom.
The Law Enforcement Perspective
Cybercrime prosecution and enforcement have never
been of higher priority among federal, state, and local
government.
• Because the present proliferation of computer fraud and
abuse is unparalleled,55 domestic and foreign
governments alike have invested significant resources in
the development and training of technical officers, agents,
and prosecutors to combat cybercrime in a nascent legal
environment.
• Law enforcement understands that internal and external
digital investigators are the first line of defense and in the
best positions to detect, initially investigate, and neatly
package some of the best evidence necessary for law
enforcement to successfully seek and obtain real
deterrence in the form of jail time, fines, and restitution.
• Evidence collected by internal and external digital
investigators is only enhanced by the legal process
(grand jury subpoena, search warrants) and data
preservation authority (pen registers, trap and traces,
wiretaps) available to law enforcement and not available
to any private party.
• International cooperation among law enforcement in the
fight against cybercrime has never been better, as even
juveniles are being hauled into federal court for their
cyber misdeeds.56
Walking the Line
Often the investigative goals of the victim company
and law enforcement diverge, leaving the digital
investigator at times in the middle. Stay out of it.
• The victim company may be more interested in protecting
its network or securing its information than, for example,
avoiding containment to allow law enforcement to obtain
necessary legal process to real-time monitor future
network events caused by the intruder.
• Despite misimpressions to the contrary, victim companies
rarely lose control over the investigation once a referral is
made; rather, law enforcement often requires early face
time and continued cooperation with the administrators
and investigators who are most intimate with and
knowledgeable of the affected systems and relevant
discovered data. Constant consultation is the norm.
• Although law enforcement will be careful not to direct any
future actions by the digital investigator, thereby creating
the possibility that a future court deems and suppresses
the investigator’s work as the work of the government
conducted in violation of the heightened legal standards
of process required of law enforcement, the digital
investigator may be required to testify before a grand
jury impaneled to determine if probable cause that a
crime was committed exists, or even to testify before a
trial jury on returned and filed charges.
• Remember the scope and limitations of authority that
apply, and let the victim company and law enforcement
reach a resolution that is mutually beneficial.
• Staying apprised of the direction of the investigation,
whether it stays private, becomes public, or proceeds on
parallel tracks (an option less favored by law
enforcement once involved), will help the digital
investigator focus on what matters most—repeatable,
reliable, and admissible findings under any circumstance.
Improving Chances for Admissibility
Thorough and meticulous recordkeeping, an impeccably
supportable and uninterrupted chain of custody, and a
fundamental understanding of basic notions governing the
reliability and integrity of evidence will secure best consideration
of the work of the digital investigator in any context, in any
forum, before any audience. Urgency tied to pulling off a quick,
efficient response to an emerging attack often makes seem less
important at the outset of any investigation the implementation of
these guiding principles. However, waiting until the attack is
under control and until the potentially exposed systems are
secured often makes it too difficult to recreate events from
memory with the same assurance of integrity and reliability as an
ongoing written record of every step taken.
Documentation
Concerns that recordkeeping creates potentially
discoverable work product, impeachment material, or
preliminary statements that may prove inconsistent with
ultimate findings are far outweighed by the future utility
to be in the best position to well evidence the objectivity,
completeness, reasonableness of those opinions.
• Document in sufficient technical detail each early effort to
identify and confirm the nature and scope of the incident.
• Keep, for example, a list of the specific systems affected,
the users logged on, the number of live connections, and
the processes running.
• Note when, how, and the substance of observations
made about the origin of attack; the number of files or
logs that were created, deleted, last accessed, modified,
or written to; user accounts or permissions that have
been added or altered; machines to which data may have
been sent; and the identity of other potential victims.
• Record observations about the lack of evidence—ones
that may be inconsistent with what was expected to be
found based on similar incident handling experiences.
• Keep a record of the methodology employed to avoid
altering, deleting, or modifying existing data on the
network.
network.
• Track measures taken to block harmful access to, or stop
continuing damage on the affected network, including
filtered or isolated areas.
• Remember early on to begin identifying and recording the
extent of damage to systems and the remediative costs
incurred—running notations that will make future
recovery from responsible parties and for any
subsequent criminal investigation that much easier.
Preservation
Careful preservation of digital evidence further
promotes repeatable, defensible, and reliable findings.
• At the outset, create forensically sound redundant hashed
images of original media, store one with the original
evidence, and use the remaining image as a working
copy for analysis. Do not simply logically copy data,
even server level data, when avoidable.
• Immediately preserve backup files and relevant logs.
• When preserving data, hash, hash, hash. Hash early to
correct potentially flawed evidence handling later.
• During analysis, hash to find or exclude from examination
known files.
• Consider using Camatasia or other screen capture
software to preserve live observations of illicit activity
before containment. This is a way to supplement
evidence obtained from enabled and extended network
logging.
• If legal counsel has approved the use of a “sniffer” or
other monitoring device to record communications
between the intruder and any server that is under attack,
be careful to preserve and document relevant information
about those recordings.
• The key is to use available forensic tools to enhance the
integrity, reliability, and repeatability of the work.
Chain of Custody
Meticulous chain of custody practices can make or
break the success of a digital forensic investigation.
• Although chain of custody goes to the weight not the
admissibility of the evidence in most court proceedings,
the concept remains nonetheless crucial, particularly
where evidence may be presented before grand juries,
arbitrators, or in similar alternative settings where
evidentiary rules are relaxed, and as such, inexplicable
interruptions in the chain may leave the evidence more
susceptible to simply being overlooked or ignored.
• The ability to establish that data and the investigative
records generated during the process are free from
contamination, misidentification, or alteration between
the time collected or generated and when offered as
evidence goes not just to the integrity of evidence but its
very relevance—no one will care about an item that
cannot be established as being what it is characterized to
be, or a record that cannot be placed in time or
attributed to some specific action.
• For data, the chain of custody form need not be a
treatise; simply record unique identifying information
about the item (serial number), note the date and
description of each action taken with respect to the item
(placed in storage, removed from storage, mounted for
examination, returned to storage), and identify the actor
at each step (presumably a limited universe of those with
access).
• A single actor responsible for generated records and
armed with a proper chain of custody form for data can
lay sufficient evidentiary foundation without having to
present every actor in the chain before the finder of fact.
State Private Investigator and Breach
Notification Statutes
State PI LicensingStatute
State Breach Notification
Statute
Alabama N/A N/A
Alaska N/A ALASKA STAT. § 45.48.010
Arizona
ARIZ. REV.
STAT. § 32- ARIZ. REV. STAT. § 44-7501
Michigan M.C.L.A §338.823 M.C.L.A § 445.72
Minnesota M.S.A. §326.3381 M.S.A. § 325E.61
Mississippi N/A MS ST § 75-24-29
Missouri MO ST §324.1104 MO ST § 407.1500
Montana MCA § 37-60-301 MCA § 30-14-1704
Nebraska
NEB. REV.
STAT. § 71-
3202
NEB. REV. STAT. §§ 87-801
Nevada
NEV. REV.
STAT. §
648.060
NEV. REV. STAT. §
603A.220
New
Hampshire
N.H. REV.
STAT. § 106-
F:5
N.H. REV. STAT. § 359-C:19
New Jersey N.J. STAT. §45:19-10 N.J. STAT. § 56:8-163
New Mexico 16.48.1.10NMAC N/A
New York
N.Y. GEN.
BUS. LAW §
70.2
N.Y. GEN. BUS. LAW §
899-aa
North
Carolina
N.C. GEN.
STAT. § 74C-2 N.C. GEN. STAT. § 75-65
North Dakota N.D. ADMIN.R. 93-02-01
N.D. CENT. CODE §§ 51-
30-01 et seq
Ohio
OHIO REV.
CODE §
4749.13
OHIO REV. CODE §
1349.19
Oklahoma
59 OKLA.
STAT. §
1750.4
74 OKLA. STAT. § 3113.1
Oregon
OR. REV.
STAT. §
703.405
OR. REV. STAT. §§
646A.600, 646A.602,
646A.604, 646A.624, and
646A.626
Pennsylvania 22 PA. STAT.§ 13
73 PA. STAT. §§ 2301–2308,
2329
§ 13 2329
Rhode Island
R.I. GEN.
LAWS § 5-5-
21
R.I. GEN. LAWS §§ 11-49.2-
1–11-49.2-7
South
Carolina
S.C. CODE §
40-18-70 S.C. CODE § 39-1-90
South Dakota N/A N/A
Tennessee
62 TENN.
CODE § 1175-
04-.06 (2)
TENN. CODE § 47-18-2107
Texas
TEX. OCC.
CODE
§1702.101
TEX. BUS. & COM. CODE §
521.053
Utah
UTAH CODE
§§ 53-9-107 2
(a) (i) and (ii)
UTAH CODE §§ 13-44-101,
13-44-201, 13-44-202, and
13-44-301
Vermont 26 V.S.A. §3179
9 V.S.A. § 2430 and 9 V.S.A.
§ 2435
Virginia VA CODE §9.1-139 C VA CODE § 18.2-186.6
Washington
WASH. REV.
CODE §
18.165.150
WASH. REV. CODE §
19.255.010
West Virginia W. VA. CODE§ 30-18-8
W. VA. CODE § 46A-2A-
101–105
Wisconsin WIS. RL §31.01 (2) WIS. STAT. § 134.98
Wyoming
Regulated by
local
jurisdictions
WYO. STAT. §§ 40-12-501
and 40-12-502
International Resources
Cross-Border Investigations
Treaties in Force: A List of Treaties and Other
International Agreements of the United States in
Force
Force
http://www.state.gov/documents/organization/89668
Preparation of Letters Rogatory
http://travel.state.gov/law/judicial/judicial_683.html
Organization of American States
Inter-American Cooperation Portal on Cyber-Crime
http://www.oas.org/juridico/english/cyber.htm
Council of Europe Convention of Cybercrime
http://conventions.coe.int/Treaty/Commun/QueVoulezVous.asp?
NT=185&CM=1&CL=ENG (and more generally)
http://www.coe.int/t/dc/files/themes/cybercrime/default_EN.asp?
European Commission 2010 Directive On Attacks
Against Information Systems
http://ec.europa.eu/home-
affairs/policies/crime/1_EN_ACT_part1_v101
European Network of Forensic Science Institutes
(Memorandum signed for International Cooperation in
Forensic Science)
http://www.enfsi.eu/page.php?uid=1&nom=153
G8 High-Tech Crime Subgroup
(Data Preservation Checklists)
http://www.coe.int/t/dg1/legalcooperation/economiccrime/cybercrime/Documents/Points%20of%20Contact/24%208%20DataPreservationChecklists_en
Interpol
Information Technology Crime—Regional Working Parties
http://www.interpol.int/public/TechnologyCrime/Default.asp
Asia-Pacific Economic Cooperation
Electronic Commerce Steering Group
http://www.apec.org/Groups/Committee-on-Trade-and-
Investment/Electronic-Commerce-Steering-Group.aspx
Organization for Economic Cooperation &
Development
Working Party on Information Security & Privacy
(APEC-OECD Workshop on Malware—Summary
Record—April 2007)
http://www.oecd.org/dataoecd/37/60/38738890
The Organisation for Economic Co-operation and
Development (OECD) Guidelines on the Protection
of Privacy and Transborder Flows of Personal Data
http://www.oecd.org/document/18/0,3746,en_2649_34255_1815186_1_1_1_1,00.html
The International Cyber Security Protection Alliance
(ICSPA) Cyber-Security News Feed
https://www.icspa.org/nc/media/cyber-security-news-feed/
Maurushat, A. (2010). Australia’s Accession to the
Maurushat, A. (2010). Australia’s Accession to the
Cybercrime Convention: Is the Convention Still
Relevant in Combating Cybercrime in the Era of
Botnets and Obfuscation Crime Tools?, University
of New South Wales Law Journal, Vol. 33(2), pp.
431–473.
Available at
http://www.austlii.edu.au/au/journals/UNSWLRS/2011/20.txt/cgi-
bin/download.cgi/download/au/journals/UNSWLRS/2011/20.rtf.
The Federal Rules: Evidence for Digital
Investigators
Relevance
All relevant evidence is admissible.
“Relevant evidence” means evidence having any tendency
to make the existence of any fact that is of consequence to the
determination of the action more probable or less probable than
it would be without the evidence.
Although relevant, evidence may be excluded if its
probative value is substantially outweighed by the danger of
unfair prejudice, confusion of the issues, misleading the jury, or
by considerations of undue delay, waste of time, or needless
presentation of cumulative evidence.
Authentication
The requirement of authentication or identification as a condition
precedent to admissibility is satisfied by evidence sufficient to
support a finding that the matter in question is what its proponent
claims.
Best Evidence
A duplicate is admissible to the same extent as an original unless
(1) a genuine question is raised as to the authenticity of the
(1) a genuine question is raised as to the authenticity of the
original or (2) in the circumstances it would be unfair to admit the
duplicate in lieu of the original.
Expert Testimony
If scientific, technical, or other specialized knowledge will assist
the trier of fact to understand the evidence or to determine a fact
in issue, a witness qualified as an expert by knowledge, skill,
experience, training, or education may testify thereto in the form
of an opinion or otherwise, if (1) the testimony is based upon
sufficient facts or data, (2) the testimony is the product of reliable
principles and methods, and (3) the witness has applied the
principles and methods reliably to the facts of the case.
The expert may testify in terms of opinion or inference and
give reasons therefore without first testifying to the underlying
facts or data, unless the court requires otherwise. The expert
may in any event be required to disclose the underlying facts or
data on cross-examination.
Limitations on Waiver of the Attorney—Client Privilege
Disclosure of attorney—client privilege or work product does
not operate as a waiver in a Federal or State proceeding if the:
1. Disclosure is inadvertent;
2 . Holder of the privilege or protection took reasonable
steps to prevent disclosure; and
3 . Holder promptly took reasonable steps to rectify the
error.
1 See, e.g., California’s “Private Investigator Act,” codified
at Cal. Bus. & Prof. Code § 7521 et seq.
2 See, e.g., Arizona Revised Statutes 32-2401-16. See
also Cal. Bus. & Prof. Code 7521(e); Nev.Rev. Stat.
Ann. § 648.012.
3 See, e.g., Michigan’s “Private Detective License Act,”
MCLS 338.24(a) (specifically excluding a “person
employed exclusively and regularly by an employer in
connection with the affairs of the employer only and
connection with the affairs of the employer only and
there exists a bona fide employer–employee relationship
for which the employee is reimbursed on a salary
basis”); Cal. Bus. & Prof. Code § 7522 (same).
4 See Louisiana’s “Private Investigators Law,” LA.R.S.
37:3503(8)(a)(iv). See also Kennard v. Rosenberg,
127 Cal.App.3d 340, 345-46 (1954) (interpreting
California’s Private Investigator Act) (“it was the intent
of the Legislature to require those who engage in
business as private investigators and detectives to first
procure a license so to do; that the statute was enacted
to regulate and control this business in the public
interest; that it was not intended to apply to persons
who, as experts, were employed as here, to make tests,
conduct experiments and act as consultants in a case
requiring the use of technical knowledge”).
5 Ohio Revised Code § 4749.01(H)(2).
6 See Delaware’s “Private Investigators and Private
Security Agencies Act,” codified at 24 Del. Code §§
1301 et seq.
7 See American Bar Association, Section of Science &
Technology Law, Resolution 301 (August 11–12,
2008), available at
www.americanbar.org/content/dam/aba/migrated/scitech/301
(“RESOLVED, That the American Bar Association
urges State, local and territorial legislatures, State
regulatory agencies, and other relevant government
agencies or entities, to refrain from requiring private
investigator licenses for persons engaged in: computer
or digital forensic services or in the acquisition, review,
or analysis of digital or computer-based information,
whether for purposes of obtaining or furnishing
information for evidentiary or other purposes, or for
providing expert testimony before a court; or network
or system vulnerability testing, including network scans
and risk assessment and analysis of computers
connected to a network”).
8 See, e.g., TBG Insurance Services Corp. v. Superior
Court, Cal.App.4th 443 (2002) (employee’s explicit
consent to written corporate monitoring policy
governing company home computer used for personal
purposes defeated reasonable expectation of privacy
claim).
claim).
9 See. e.g.. 18 U.S.C. § 2703.
10 See, e.g., United States v. Carey, 172 F.3d 1268
(10th Cir. 1999) (law enforcement may not expand the
scope of a computer search beyond its original
justification by opening files believed would constitute
evidence beyond the scope of the warrant).
11 See Electronic Communications Privacy Act (“ECPA”),
codified at 18 U.S.C. §§ 2701 et seq.
12 See 18 U.S.C. § 2701.
13 See 18 U.S.C. § 2702(c).
14 See 18 U.S.C. § 2702(b).
15 See 18 U.S.C. § 2511; in re Pharmatrak, Inc. Privacy
Litigation, 329 F.3d 9, 18 (1st Cir. 2003).
16 Interception involving the acquisition of information
stored in computer memory has in at least one
jurisdiction been found to violate the Wiretap Act. See
United States v. Councilman, 418 F.3d 67 (1st Cir.
2005) (en banc).
17 See 2511(2)(a)(i).
18 Note that some state surveillance statutes, like
California’s, require two-party consent.
19 18 U.S.C. § 2511(2)(d); United States v. Amen, 831
F.2d 373, 378 (2d Cir. 1987) (consent may be explicit
or implied); United States v. Workman, 80 F.3d 688,
693 (2d Cir. 1996) (proof that the consenting party
received actual notice of monitoring but used the
monitored system anyway established implied consent).
20 Appendix C, “Best Practices for Victim Response and
Reporting,” to “Prosecuting Computer Crimes,” U.S.
Department of Justice Computer Crime & Intellectual
Property Section (February 2007), available at
http://www.cybercrime.gov/ccmanual/appxc.html.
21 18 U.S.C. § 2511(2)(i).
22 18 U.S.C. §§ 3121–3127.
23 Public Law 106-12, 15 U.S.C. § 6801 et seq.,
hereinafter sometimes referred to as “GLB” or “the
Act.” The names in the popular GLB title of this statute
refer to three members of Congress who were its
instrumental sponsors, Senator Phil Gramm (R-TX),
Chairman of the Senate Banking Committee;
Chairman of the Senate Banking Committee;
Representative Jim Leach (R-IA), Chairman of the
House Banking Committee; and Representative Thomas
Bliley (R-VA), Chairman of the House Commerce
Committee.
24 16 CFR § 313(k)(1). For a list of common examples,
see 16 CFR § 313(k)(2) of the Act, available at
http://edocket.access.gpo.gov/cfr_2003/16cfr313.3.htm.
25 In addition to GLB, the Fair Credit Reporting Act, the
Internal Revenue Code, and a variety of state laws and
regulations provide consumers with protection in the
handling of their credit report and tax return information
by financial service providers. Pay particular attention to
the handling of this type of financial data. For a terrific
summary of the consumer protection laws that apply to
financial institutions, see
http://www.dfi.wa.gov/cu/summary.htm.
26 42 USC §§ 1302, 1320d, 1395; 45 CFR §§ 160, 162,
154.
27 Retail pharmacies are another perhaps less obvious
example of a “covered entity” required to comply with
HIPAA requirements. Pharmacies regularly collect,
handle, and store individually identifiable health
information during the ordinary course of business.
28 Public Law 111–5 (February 2009), codified at 2 CFR
§ 176, available at
http://www.gpo.gov/fdsys/pkg/PLAW-
111publ5/content-detail.html.
29 An excellent summary of the detailed provisions of
HIPAA is available at
http://www.omh.state.ny.us/omhweb/hipaa/phi_protection.html.
A thorough discussion of the ARRA extensions of
HIPAA is available at
http://www.cerner.com/uploadedFiles/Assessment_of_OCR_Proposed_HIPAA_Security_and_Privacy_ARRA_HITECH_Updates
30 17 CFR §§ 210, 228-29, 240, 249, 270.
31 16 CFR § 312.
32 18 U.S.C. §§ 5031 to 5042.
33 See 18 U.S.C. § 5038 (provisions concerning sealing
and safeguarding of records generated and maintained in
juvenile proceedings).
34 20 U.S.C. § 1232g.
35 A helpful chart updated as of July 1, 2009, that
35 A helpful chart updated as of July 1, 2009, that
summarizes existing state breach notification laws is
available at
http://www.digestiblelaw.com/files/upload/securitybreach .
36 The complete text of the Convention is available at
http://conventions.coe.int/Treaty/en/Treaties/Html/185.htm.
37 For a complete list of the party and signatory countries
to the Convention, see the map available at
http://www.coe.int/t/dc/files/themes/cybercrime/worldmap_en .
38 The complete text of the Convention Commentary is
available at
http://conventions.coe.int/Treaty/en/Reports/Html/185.htm.
39 The prospective version of the Police and Justice Act of
2006 is available at
http://www.statutelaw.gov.uk/content.aspx?
LegType=All+Legislation&title=Police+and+Justice+Act+2006&searchEnacted=0&extentMatchOnly=0&confersPower=0&blanketAmendment=0&sortAlpha=0&TYPE=QS&PageNumber=1&NavFrom=0&parentActiveTextDocId=2954345&ActiveTextDocId=2954404&filesize=24073
40 That guidance is available at
http://www.cps.gov.uk/legal/a_to_c/computer_misuse_act_1990/index.html.
41 The relevant provisions of the German Code can be
found (in German) at http://www.bmj.bund.de/files/-
/1317/RegE%20Computerkriminalit%C3%A4t .
42 See 18 U.S.C. §§ 1030(a)(6), (c)(2)(A).
43 See
http://www.justice.gov/criminal/cybercrime/COEFAQs.htm#topicE.
44 Directive 95/46EC of the European Parliament and of
the Council of 24 October 1995 on the Protection of
Individuals with Regard to the Processing of Personal
Data and on the Free Movement of Such Data,
available at
http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm.
45 The following 27 countries of the EU are required to
implement legislation under the Directive: Austria,
Belgium, Bulgaria, Cyprus, Czech Republic, Denmark,
Estonia, Finland, France, Germany, Greece, Hungary,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Poland, Portugal, Romania, Slovakia,
Slovenia, Spain, Sweden, and the United Kingdom. In
addition, a number of other countries have data
protection statutes that regulate access to employees’
data and cross-border data transfers, with ramifications
for the conduct of internal investigations by U.S.-based
digital investigators. For example, Iceland,
Liechtenstein, and Norway (together comprising the
Liechtenstein, and Norway (together comprising the
European Economic Area); Albania, Andorra, Bosnia
and Herzegovina, Croatia, Macedonia, and Switzerland
(European Union neighboring countries); and the
Russian Federation have laws similar to the EU Data
Protection Directive. See Wugmeister, M., Retzer, K.,
and Rich, C. (2007). Global Solution for Cross-Border
Data Transfers: Making the Case for Corporate Privacy
Rules, Geo. J. Intl L., 449, 455.
46 Boyd, V. (2006). Financial Privacy in the United States
and the European Union: A Path to Transatlantic
Regulatory Harmonization, Berkeley J. Intl L., 939,
958–959.
47 Directive, Art. 26(1) (a) (transfer “may take place on
condition that: (a) the data subject has given his consent
unambiguously to the proposed transfer”).
48 The Safe Harbor framework is comprised of a collection
of documents negotiated between the U.S. Department
of Commerce and the EU, including 7 privacy principles
http://export.gov/safeharbor/eu/eg_main_018475.asp
and 15 FAQs
http://export.gov/safeharbor/eu/eg_main_018493.asp.
49 See http://www.export.gov/static/SH_EU_Decision .
50 Over 1300 U.S. companies from over 100 industry
sectors have registered and been certified under the
Safe Harbor framework. See
http://web.ita .gov/safeharbor/SHList.nsf/WebPages/Search+by+Industry+
Sector.
51 See, e.g., Law No. 80-538 of July 16, 1980, Journal
Officiel de la Republique Francaise. The United
Kingdom, Canada, Australia, Sweden, the Netherlands,
and Japan have less restrictive blocking statutes as well.
52 For a list of bilateral mutual legal assistance treaties in
force, see
http://travel.state.gov/law/info/judicial/judicial_690.html.
53 The U.S. State Department offers guidance on the
procedural requirements for a letter rogatory at
http://travel.state.gov/law/judicial/judicial_683.html.
54 Magee, B. (2008). Firms Fear Stigma of Reporting
Cybercrime. business.scotsman.com (April 13, 2008),
available at
http://business.scotsman.com/ebusiness/Firms-fear-
http://business.scotsman.com/ebusiness/Firms-fear-
stigma-of-reporting.3976469.jp.
55 The “2007 Internet Crime Complaint Report,” available
at www.ic3.gov/media/annualreports.aspx, suggests a
$40 million year-end increase in reported losses from
the 206,884 complaints of crimes perpetrated over the
Internet reported to the FBI’s Internet Crime Complaint
Center during 2007.
56 See United States Attorney’s Office for the Central
District of California, Press Release No. 08-013,
February 11, 2008, “Young ‘Botherder’ Pleads Guilty
to Infecting Military Computers and Fraudulently
Installing Adware,” available at
http://www.usdoj.gov/usao/cac/pressroom/pr2008/013.html.
For added color, see Goodin, D. (2008). “I Was A
Teenage Bot Master: The Confessions of SoBe Owns,”
The Register (May 8, 2008), available at
http://www.theregister.co.uk/2008/05/08/downfall_of_botnet_master_sobe_owns/.
Chapter 5
File Identification and Profiling
Initial Analysis of a Suspect File on a Windows System
Solutions in this chapter:
• Overview of the File Profiling Process
• Profiling a Suspicious File
• File Similarity Indexing
• File Visualization
• File Signature Identification and Classification
• Embedded Artifact Extraction
• Symbolic and Debug Information
• Embedded File Metadata
• File Obfuscation: Packing and Encryption Identification
• Embedded Artifact Extraction Revisited
• Profiling Suspect Document Files
• Profiling Suspect Portable Document Format (PDF) Files
• Profiling Suspect Microsoft (MS) Office Files
• Profiling Suspect Compiled HTML Help Files
Introduction
This chapter addresses the methodology, techniques, and tools
for conducting an initial analysis of a suspect file. Some of the
techniques covered in this and other chapters may constitute
“reverse engineering” and thus fall within the proscriptions of
certain international, federal, state, or local laws. Similarly, some
of the referenced tools are considered “hacking tools” in some
jurisdictions, and are subject to similar legal regulation or use
restriction. Some of these legal limitations are set forth in Chapter
4. In addition to careful review of these considerations,
consultation with appropriate legal counsel prior to implementing
any of the techniques and tools discussed in these and
subsequent chapters is strongly advised and encouraged.
Analysis Tip
Safety First
Forensic analysis of a potentially dangerous file specimen
Forensic analysis of a potentially dangerous file specimen
requires a safe and secure lab environment. After extracting a
suspicious file from a system, place the file on an isolated or
“sandboxed” system or network to ensure that the code is
contained and unable to connect to, or otherwise affect, any
production system. Even though only a cursory static analysis of
the code is contemplated at this point of the investigation,
executable files nonetheless can be accidentally executed fairly
easily, potentially resulting in the contamination of, or damage to,
production systems.
Overview of the File Profiling Process
File profiling is essentially malware analysis
reconnaissance, an effort necessary to gain enough
information about the file specimen to render an informed
and intelligent decision about what the file is, how it
should be categorized or analyzed, and, in turn, how to
proceed with the larger investigation. Take detailed notes
during the process, not only about the suspicious file but
also about each investigative step taken.
A suspicious file may be fairly characterized as:
• Of unknown origin
• Unfamiliar
• Seemingly familiar, but located in an unusual place on the
system
• Unusually named and located in an unusual folder on the
system (e.g., C:\Documents and Settings\
[USER]\TEMP\a\xx.exe)
• Similarly named to a known or familiar file, but misspelled
or otherwise slightly varied (a technique known as file
camouflaging)
• File contents are hidden by obfuscation code
• Determined during the course of a system investigation to
conduct network connectivity or an other anomalous
activity
After extracting the suspicious file from the system,
After extracting the suspicious file from the system,
determining its purpose and functionality is often a good starting
place. This process, called file profiling, should answer the
following questions:
• What type of file is it?
• What is the intended purpose of the file?
• What is the functionality and capability of the file?
• What does the file suggest about the sophistication level
of the attacker?
• What is the target of the file—is it customized to the
victim system/network or a general attack?
• What affect does this file have on the system?
• What is the extent of the infection or compromise on the
system or network?
• What remediation steps are necessary because the file
exists on the system?
The file profiling process entails an initial or cursory
static analysis of the suspect code (Figure 5.1). Static analysis
is the process of analyzing executable binary code without
actually executing the file. A general approach to file profiling
involves the following steps:
• Detail: Identify and document system details pertaining
to the system from which the suspect file was obtained.
• Hash: Obtain a cryptographic hash value or “digital
fingerprint” of the suspect file.
• Compare: Conduct file similarity indexing of the file
against known samples.
• Classify: Identify and classify the type of file (including
the file format and the target architecture/platform), the
high-level language used to author the code, and the
compiler used to compile it.
• Visualize: Examine and compare suspect files in
graphical representation, revealing visual distribution of
the file contents.
• Scan: Scan the suspect file with anti-virus and anti-
spyware software to determine if the file has a known
malicious code signature.
• Examine: Examine the file with executable file analysis
tools to ascertain whether the file has malware
properties.
properties.
• Extract and Analyze: Conduct entity extraction and
analysis on the suspect file by reviewing any embedded
American Standard Code for Information Interchange
(ASCII) or Unicode strings contained within the file, and
by identifying and reviewing any file metadata and
symbolic information.
• Reveal: Identify any code obfuscation or armoring
techniques protecting the file from examination, including
packers, wrappers, or encryption.
• Correlate: Determine whether the file is dynamically or
statically linked, and identify whether the file has
dependencies.
• Research: Conduct online research relating to the
information you gathered from the suspect file and
determine whether the file has already been identified
and analyzed by security consultants, or conversely,
whether the file information is referenced on hacker or
other nefarious Web sites, forums, or blogs.
Figure 5.1 The file profiling process
Although all of these steps are valuable ways to learn
more about the suspect file, they may be executed in varying
more about the suspect file, they may be executed in varying
order or in modified form, depending upon the preexisting
information or circumstances surrounding the code.
• Be thorough and flexible.
• Familiarity with a wide variety of both command-line
interface (CLI) and Graphical User Interface (GUI) tools
will further broaden the scope of investigative options.
• Familiarity and comfort with a particular tool, or the
extent to which the reliability or efficacy of a tool is
perceived as superior, often dictate whether the tool is
incorporated into any given investigative arsenal.
• Further tool discussion and comparison can be found in
the Tool Box section at the end of this chapter.
Profiling a Suspicious File
This section presumes a basic understanding of how
Windows Portable Executable (PE) files are compiled. A
detailed discussion of this process can be found in the
Introductory Chapter.
System Details
If the suspicious file was extracted or copied from a victim
system, be certain to document the details obtained through the
live response techniques mentioned in Chapter 1, including
information about:
• The system’s operating system, version, service pack,
and patch level
• The file system
• The full system path where the file resided prior to
discovery
• Associated file system metadata, such as created,
modified, and accessed dates/times
• Details pertaining to any security software, including
personal firewall, anti-virus, or anti-spyware programs
Collectively, this information provides necessary file
context, as malware often manifests differently depending on the
permutations of the operating system and patch and software
installation.
File Name
Acquire and document the full file name
Identifying and documenting the suspicious file name is a
foundational step in file profiling. The file name, along with the
respective file hash value, will be the main identifier for the file
specimen.
• Be mindful to disable the Windows Folder View Option
“Hide extensions for known file types” on your analysis
system so that the file extension associated with the file is
visible and can be documented.
• Attackers often try to conceal their malicious programs by
using pseudo file extensions in an effort to trick victims
into executing the malicious program.
• Miss Identify (missidentify.exe)1 is a utility for finding
Win32 executable programs, regardless of file extension,
allowing the digital investigator to detect misnamed
executable files or hidden extensions.
• I n Figure 5.2, Miss Identify is used to reveal two
executable files that appear to be image files as a result
of hidden file extensions and icons embedded into the PE
Resources (discussed later in this chapter and in Chapter
6).
Figure 5.2 Using Miss Identify to uncover misnamed executable
files
files
Investigative Considerations
• Although the full file path in which a suspect file was
discovered on the victim system is not a part of the file
name per se, it is a valuable detail that can provide
further depth and context to a file profile. The full file
path should be noted during live response and post-
mortem forensic analysis, as discussed in Chapters 1 and
3, respectively.
File Size
Acquire and document the specimen’s file size
File size is a unique file variable that should be identified
and noted for each suspect file.
• Although file size in no way can predict the contents or
functionality of a file specimen, it can be used as a gauge
as to determine payload. For instance, a malware
specimen that contains its own SMTP engine or server
function will likely be larger than other specimens that are
modular and will likely connect to a remote server to
download additional files.
File Appearance
Note or screenshot a suspect file’s appearance as an
identifier for your report and catalog it for reference with
other samples.
Attackers often manipulate the icon associated with a file
to give a malicious file a harmless and recognizable appearance,
tricking users into executing the file.
• Documenting the file appearance is useful for reports and
for comparison and correlation with other malware
for comparison and correlation with other malware
samples.
• An intuitive and flexible tool to assist in obtaining screen
captures of files is MWSnap (Figure 5.3).2
Figure 5.3 MWSnap capturing the appearance of a suspicious
file
Hash Values
Generate a cryptographic hash value for the suspect
file to both serve as a unique identifier or digital
“fingerprint” for the file throughout the course of
analysis, and to share with other digital investigators who
already may have encountered and analyzed the same
specimen.
The Message-Digest 5 (MD5)3 algorithm generates a
128-bit hash value based upon the file contents and typically is
expressed in 32 hexadecimal characters.
• MD5 is widely considered the de facto standard for
generating hash values for malicious executable
identification.
• Other algorithms, such as Secure Hash Algorithm Version
1.0 (SHA1)4 can be used for the same purpose.
Investigative Considerations
• Generating an MD5 hash of the malware specimen is
• Generating an MD5 hash of the malware specimen is
particularly helpful for subsequent dynamic analysis of
the code. Whether the file copies itself to a new location,
extracts files from the original file, updates itself from a
remote Web site, or simply camouflages itself through
renaming, comparison of MD5 values for each sample
will enable determination of whether the samples are the
same or new specimens that require independent
analysis.
Command-Line Interface MD5 Tools
CLI hashing tools provide a simple and effective way to
collect hash values from suspicious files, the results of which can
be saved to a log file for later analysis.
• md5deep is a powerful MD5 hashing and analysis tool
suite written by Jesse Kornblum that gives the user
granular control over the hashing options, including
piecewise and recursive modes (Figure 5.4).5
• In addition to the MD5 algorithm, the md5deep suite
provides for alter-native algorithms by providing
additional utilities such as sha1deep, tigerdeep,
sha256deep, and whirlpooldeep, all of which come
included in the md5deep suite download.
Figure 5.4 Hashing a suspicious file with md5deep
GUI MD5 Tools
Despite the power and flexibility offered by these CLI MD5
tools, many digital investigators prefer to use GUI-based tools
during analysis, because they provide drag-and-drop
functionality and easy-to-read output. Similarly, tools that enable
a Windows Explorer shell extension, or “right-click” hashing,
provide a simple and efficient way to generate hash values during
analysis. A useful utility that offers a variety of scanning options
to acquire both MD5 and SHA1 hash values for suspect files is
Nirsoft’s HashMyFiles,6 depicted in Figure 5.5.
Figure 5.5 Using HashMyFiles to recursively scan a directory
for hash values
Other Tools to Consider
CLI Hashing Tools
Microsoft File Checksum Integrity Verifier
(FCIV)—http://www.microsoft.com/downloads/en/details.aspx?
FamilyID=B3C93558-31B7-47E2-A663-
7365C1686C08&displaylang=en
GNU Core
Utilities—http://gnuwin32.sourceforge.net/packages/coreutils.htm
MD5Summer—http://www.md5summer.org/
HashonClick—http://www.2brightsparks.com/onclick/hoc.html
Graphical MD5sum—http://www.toast442.org/md5/
Malcode Analyst
Pack—http://labs.idefense.com/software/malcode.php#more_malcode+analysis+pack
Visual MD5—http://www.tucows.com/preview/505450
(previously available from http://www.protect-
folder.com/)
SSDeepFE—http://sourceforge.net/project/showfiles.php?
group_id=215906&package_id=267714
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter and on the
companion Web site,
http://www.malwarefieldguide.com/Chapter5.html.
File Similarity Indexing
Comparing the suspect file to other malware specimens
collected or maintained in a private or public repository is
an important part of the file identification process.
An effective way to compare files for similarity is through
a process known as fuzzy hashing or Context Triggered
Piecewise Hashing (CTPH), which computes a series of
randomly sized checksums for a file, allowing file association
between files that are similar in file content but not identical.
• Use ssdeep,7 a file hashing tool that utilizes CTPH to
identify homologous files, to query suspicious file
specimens.
• Ssdeep can be used to generate a unique hash value for a
file, or compare an unknown file against a known file or
list of file hashes.
• In the vast arsenal of ssdeep’s file comparison modes
exists a “pretty matching mode,” wherein a file is
compared against another file and scored based upon
similarity (a score of 100 constituting an identical match).
• In Figure 5.6, a file that has been changed by one byte
and saved to a new file is scanned in conjunction with the
original file with ssdeep in “pretty matching mode.”
original file with ssdeep in “pretty matching mode.”
Although the one byte modification changes the MD5
hash values of the respective files, ssdeep detects the
files as nearly identical.
• Through these and other similar tools employing the
CTPH functionality, valuable information about a suspect
file may be gathered during the file identification process
to associate the suspect file with a particular specimen of
malware, a “family” of code, or a particular attack or set
of attacks. Further discussion regarding malware
“families,” or phylogeny, can be found in Chapter 6.
Figure 5.6 ssdeep “pretty matching mode”
Online Resources
Hash Repositories
Online hash repositories serve as a valuable resource for
querying hash values of suspect files. The hash values and
associated files maintained by the operators of these resources
are acquired through a variety of sources and methods, including
online file submission portals. Keep in mind that by submitting a
file or a search term to a third-party Web site, you are no longer
in control of that file or the data associated with that file.
Team Cymru Malware Hash
Registry—http://www.team-cymru.org/Services/MHR/
Zeus Tracker—https://zeustracker.abuse.ch/monitor.php
viCheck.ca Malware Hash
Query—https://www.vicheck.ca/md5query.php
VirusTotal Hash
Search—http://www.virustotal.com/search.html
File Visualization
Visualize file data in an effort to identify potential
anomalies and to quickly correlate like files.
Visualizing file data, particularly through byte-usage-
histograms, provides the digital investigator with a quick
reference about the data distribution in a file.
• Inspect suspect files with bytehist, a GUI-based tool for
generating byte-usage-histograms.8
• Bytehist makes histograms for all file types, but is geared
toward PE files, in that it makes separate sub-histograms
for each section of the executable file.
• Histogram visualization of executables can assist in
identifying file obfuscation techniques such as packers
and cryptors (discussed in the “File Obfuscation:
Packing and Encryption Identification” section later in
this chapter).
• Byte distribution in files concealed with additional
obfuscation code or with encrypted content will typically
manifest visually distinguishable from unobfuscated
versions of the same file, as shown in Figure 5.7, below,
which displays histogram visualization of the same file in
both a packed and unpacked condition with bytehist.
• Comparing histogram patterns of multiple suspect files can
also be used as a quick triage method to identify
potential like files based upon visualization of data
distribution.
• To further examine a suspicious binary file through
multiple visualization schemes, probe the file with BinVis,
a framework for visualizing binary file structures.9 BinVis
is discussed in greater detail in Chapter 6.
Figure 5.7 Visualizing files with bytehist
File Signature Identification and Classification
After gathering system details, acquiring a digital
fingerprint, and conducting a file index similarity inquiry,
additional profiling to identify and classify the suspect file
will prove an important part of any preliminary static
analysis.
This step in the file identification process often produces
a clearer idea about the nature and purpose of the malware, and
in turn, the type of damage the attack was intended to cause the
victim system.
• Identifying the file type is determining the nature of the file
from its file format or signature based upon available
data contained within the file.
• File type analysis, coupled with file classification, or a
determination of the native operating system and the
architecture for which the code was intended, are
fundamental aspects of malware analysis that often
dictate how and the direction in which your analytical
and investigative methodology will unfold.
File Types
The suspect file’s extension cannot serve as the sole indicator
of its contents; instead examination of the file’s signature is
paramount.
• A file signature is a unique sequence of identifying bytes
written to a file’s header. On a Windows system, a file
signature is normally contained within the first 20 bytes of
signature is normally contained within the first 20 bytes of
the file.
• Different file types have different file signatures; for
example, a Windows Bitmap image file (.bmp extension)
begins with the hexadecimal characters 42 4D in the first
two bytes of the file, characters that translate to the
letters “BM.”
• Most Windows-based malware specimens are executable
files, often ending in the extensions .exe, .dll, .com, .pif,
.drv, .qtx, .qts, .ocx, or .sys. The file signature for these
files is “MZ” or the hexadecimal characters 4D 5A,
found in the first two bytes of the file.
• Generally, there are two ways to identify a file’s signature.
First, query the file with a file identification tool.
Second, open and inspect the file in a hexadecimal
viewer or editor. Hexidecimal (or hex, as it is commonly
referred) is a numeral system with a base of 16, written
with the letters A–F and numbers 0–9 to represent the
decimal values 0–15. In computing, hexadecimal is used
to represent a byte as 2 hexadecimal characters (one
character for each 4-bit nibble), translating binary code
into a more human-readable format.
• By viewing a file in a hex editor, every byte of the file is
visible, assuming its contents are not obfuscated by
packing, encryption, or compression.
• MiniDumper by Marco Pontello10 is a convenient tool for
examining a file in hexadecimal format, as it displays a
dump of the file header only, as illustrated in Figure 5.8.
• Other hexadecimal viewers for Windows provide
additional functionality to achieve a more granular
analysis of a file, including strings identification, hash
value computation, multiple file comparison, and
templates for parsing the structures of specific file types.
Further discussion and comparison of hex editors can be
found in the Tool Box section at the end of this chapter, and on
the companion Web site,
http://www.malwarefieldguide.com/Chapter5.html.
File Signature Identification and Classification Tools
Unlike distributions of the Linux operating system that come
with the utility file preinstalled (which classifies a queried file
specimen based on the data contained in the file as compared
against a comprehensive list—or, magic file of known file
headers), Microsoft Windows operating systems have no
inherent equivalent command. Despite this apparent void in this
genre of analytical tools, there are a number of CLI and GUI
tools that have been developed to address file identification and
tools that have been developed to address file identification and
analysis for Windows systems.
CLI File Identification Tools
• Perhaps the closest tool to the Linux version of file is
File Identifier (version 0.6.1), developed by Optima
SC.11 Similar to file, File Identifier compares a queried
file against a magic-like database file.12
• In addition to conducting file identification through
signature matching, File Identifier also extracts file
metadata, as illustrated in Figure 5.9.
• In addition to providing a variety of different file scanning
modes, including a recursive mode for applying the tool
against directories and subdirectories of files, File
Identifier also offers Hypertext Markup Language
(HTML) and CVS report generation.
• As an alternative, TrID, a CLI file identifier written by
Marco Pontello,13 does not limit the classification of an
unknown file to one possible file type based on the file’s
signature, unlike other tools. Rather, it compares the
unknown file against a file signature database and
provides a series of possible results, ranked by order or
probability, as depicted in the analysis of the suspect file
in Figure 5.10.
• The TrID file database consists of approximately 4,000
different file signatures,14 and is constantly expanding,
due in part to Pontello’s distribution of TrIDScan, a
TrID counterpart tool that offers the ability to easily
create new file signatures that can be incorporated into
the TrID file signature database.15
Figure 5.9 Scanning a suspect file with File Identifier
Figure 5.10 Scanning a suspect file with TrID
GUI File Identification Tools
• There are a number of GUI-based file identification and
classification programs for use in the Windows
environment; many are intuitive to use and convenient for
an initial static analysis of any suspect file.
• TrIDNet,16 a GUI version of TrID, provides for quick
and convenient drag-and-drop functionality and an
intuitive interface, as shown in Figure 5.11.
• Like the CLI version, TrIDNet compares the suspect file
against a file database of nearly 4,000 file signatures,
scores the queried file based upon its characteristics, and
reveals a probability-based identification of the file.
Figure 5.11 A suspect file classified with TrIDNet
Other Tools to Consider
CLI File Identification Tools
Exetype—http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-
us/reskt4u4/rku4list.mspx?mfr=true
FileType—http://gnuwin32.sourceforge.net/packages/filetype.htm
Infoexe v. 1.32—http://www.exetools.com/file-
analyzers.htm
Peace v. 1.00—http://www.exetools.com/file-
analyzers.htm
Fileinfo v. 2.43—http://www.exetools.com/file-
analyzers.htm
GUI File Identification Tools
Digital Record Object Identifier
(DROID)—http://droid.sourceforge.net/
FileAlyzer—http://www.safer-
networking.org/en/filealyzer/index.html
WhatFile—http://www.sinnercomputing.com/dl.php?
prog=WhatFile
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter and on the
companion Web site,
http://www.malwarefieldguide.com/Chapter5.html.
Anti-virus Signatures
After identifying and classifying a suspect file, the next step in
the file profiling process is to query the file against anti-virus
engines to see if it is detected as malicious code.
• Approach this phase of the analysis in two separate steps:
First, manually scan the file with a number of anti-virus
programs locally installed on the malware analysis test
system to determine whether any alerts are generated for
the file. This manual step affords control over the
configuration of each program, ensures that the signature
database is up to date, and allows access to the
additional features of locally installed anti-virus tools (like
links to the vendor Web site), which may provide more
complete technical details about a detected specimen.
Second, submit the specimen to a number of free online
malware scanning services for a more comprehensive
view of any signatures associated with the file.
Local Malware Scanning
To scan malware locally, implement anti-virus software that
can be configured to scan on demand, as opposed to every time
a file is placed on the test system.
• Make sure that the AV program affords choice in
resolving malicious code detected by the anti-virus
program; many automatically delete, “repair,” or
quarantine the malware upon detection.
• Some examples of freeware anti-virus software for
installation on your local examiner system include:
Avast17
Investigative Considerations
• The fact that installed anti-virus software does not identify
the suspect file as malicious code is not dispositive.
Rather, it may mean simply that a signature for the
suspect file has not been generated by the vendor of the
anti-virus product, or that the attacker is “armoring” or
otherwise implanting a file protecting mechanism to
thwart detection.
• Although an anti-virus signature does not necessarily
dictate the nature and capability of identified malicious
code, it does shed potential insight into the purpose of
the program.
• Given that when a malicious code specimen is obtained
and when a signature is developed for it may vary
between anti-virus companies, scanning a suspect file
with multiple anti-virus engines is recommended.
Implementing this redundant approach helps ensure that
a malware specimen is identified by an existing virus
signature and provides a broader, more thorough
inspection of the file.
Web-based Malware Scanning Services
After running a suspect file through local anti-virus program
engines, consider submitting the malware specimen to an online
malware scanning service.
• Unlike vendor-specific malware specimen submission
Web sites, online malware scanning services will scan
Web sites, online malware scanning services will scan
submitted specimens against numerous anti-virus engines
to identify whether the submitted specimen is detected as
hostile code.
Web Service Features
VirusTotal:
http://www.virustotal.com
• Scans submitted file against 43 different anti-virus
engines
• “First seen” and “last seen” submission dates
provided for each specimen
• File size, MD5, SHA1, SHA256, and ssdeep values
generated for each submitted file
• File type identified with file and TrID
• PE file structure parsed
• Relevant Prevx, ThreatExpert, and Symantec
reports cross-referenced and hyperlinked.
• URL link scanning
• Robust search function, allowing the digital
investigator to search the VirusTotal (VT) database
• VT Community discussion function
• Python submission scripts available for batch
submission:
http://jon.oberheide.org/blog/2008/11/20/virustotal-
python-submission-script/
http://www.bryceboe.com/2010/09/01/submitting-
binaries-to-virustotal/
VirScan:
http://virscan.org/
• Scans submitted file against 36 different anti-virus
engines
• File size, MD5, and SHA1 values generated for each
submitted file
Jotti Online Malware
Scanner:
http://virusscan.jotti.org/en
• Scans submitted file against 19 different anti-virus
engines
• File size, MD5, and SHA1 values generated for each
submitted file
• File type identified with file magic file
• File type identified with file magic file
• Packing identification
Metascan Online
www.metascan-
online.com
• Scans submitted file with 19 different anti-virus
engines
• File size, MD5, and SHA1 values generated for each
submitted file
• File type identification
• Packing identification
• “Last scanned” dates
• During the course of inspecting the file, the scan results for
the respective anti-virus engines are presented in real
time on the Web page.
• These Web sites are distinct from online malware
analysis sandboxes that execute and process the
malware in an emulated Internet, or “sandboxed,”
network. The use of online malware analysis sandboxes
will be discussed in Chapter 6.
• Remember that submission of any specimen containing
personal, sensitive, proprietary, or otherwise confidential
information may violate the victim company’s corporate
policies or otherwise offend the ownership, privacy, or
other corporate or individual rights associated with that
information. Be careful to seek the appropriate legal
guidance in this regard, before releasing any such
specimen for third-party examination.
• Do not submit a suspicious file that is the crux of a
sensitive investigation (i.e., circumstances in which
disclosure of an investigation could cause irreparable
harm to a case) to online analysis resources, such as
anti-virus scanning services, in an effort not to alert the
attacker. The results relating to a submitted file to an
online malware analysis service are publicly available and
easily discoverable—many portals even have a search
function. Thus, as a result of submitting a suspect file, the
attacker may discover that his malware and nefarious
actions have been discovered, resulting in the destruction
of evidence, and potentially damaging your investigation.
• Assuming you have determined it is appropriate to do so,
submit the suspect file by uploading the file through the
Web site submission portal.
• Upon submission, the anti-virus engines will run against
• Upon submission, the anti-virus engines will run against
the suspect file. As each engine passes over the
submitted specimen, the file may be identified, as
manifested by a signature identification alert similar to
that depicted in Figure 5.12.
• If the file is not identified by any anti-virus engine, the field
next to the respective anti-virus software company will
either remain blank (in the case of VirusTotal and
VirScan), or state that no malicious code was detected
(in the case of Jotti Online Malware Scanner and
Metascan Online).
• The signature names attributed to the file provide an
excellent way to gain additional information about what
the file is and what it is capable of. By visiting the
respective anti-virus vendor Web sites and searching for
the signature or the offending file name, more often than
not a technical summary of the malware specimen can be
located.
• Alternatively, through search engine queries of the anti-
virus signature, hash value, or file name, information
security-related Web site descriptions or blogs
describing a researcher’s analysis of the hostile program
also may be encountered. Such information may
contribute to the discovery of additional investigative
leads and potentially reduce time spent analyzing the
specimen.
• Conversely, there is no better way to get a sense of your
malicious code specimen than thoroughly analyzing it
yourself; relying entirely on third-party analysis to resolve
a malicious code incident often has practical and real-
world limitations.
Figure 5.12 A suspect file submitted and scanned on VirusTotal
Embedded Artifact Extraction: Strings, Symbolic
Information, and File Metadata
In addition to identifying the file type and scanning
the file with anti-virus scanners to ascertain known
hostile code signatures, many other potentially important
facts can be gathered from the file itself.
Information about the expected behavior and function of
the file can be gleaned from entities within the file, like strings,
symbolic information, and file metadata.
• Although symbolic references and metadata may be
identified while parsing the strings of a file, these items
are treated separately and distinctly from one another
during the examination of a suspect file.
• Embedded artifacts—evidence contained within the
code or data of the suspect program—are best
inspected separately to promote organization and clearer
file context. Each inspection may shape or otherwise
frame the future course of investigation.
Strings
Some of the most valuable clues about the identifiers,
functionality, and commands associated with a suspect file can
be found within the embedded strings of the file. Strings are
be found within the embedded strings of the file. Strings are
plain-text ACSII and Unicode (contiguous) characters
embedded within a file. Although strings do not typically provide
a complete picture of the purpose and capability of a file, they
can help identify program functionality, file names, nicknames,
Uniform Resource Locators (URLs), e-mail addresses, and
error messages, among other things. Sifting through embedded
strings may yield the following information:
• Program Functionality: Often, the strings in a program
will reveal calls made by the program to a particular .dll
or function call. To help evaluate the significance of such
strings, the Windows API Reference Web site 24 and the
Microsoft Advanced Search engine25 are solid
references.
• File Names: The strings in a malicious executable often
reference the file name the malicious file will manifest as
on a victim system, or perhaps more interestingly, the
name the hacker bestowed on the malware. Further,
many malicious executables will reference or make calls
for additional files that are pulled down through a
network connection to a remote server.
• Moniker Identification (“greetz” and “shoutz”):
Although not as prevalent recently, some malicious
programs actually contain the attacker’s moniker hard-
coded within it. Similarly, attackers occasionally
reference, or give credit to, another hacker or hacking
crew in this way—references known as “greetz” or
“shoutz.” Like self-recognition references inside code,
however, greetz and shoutz are less frequent.26
• URL and Domain Name References: A malicious
program may require or call on additional files to update.
Alternatively, the program may use remote servers as
drop sites for tools or stolen victim data. As a result, the
malware may contain strings referencing the URLs or
domain names utilized by the code.
• Registry Information: Some malware specimens
reference registry keys or values that will be added or
modified upon installation. Often, as discussed in other
chapters, hostile programs create a persistence
mechanism through a registry autorun subkey, causing
the program to start up each time the system is rebooted.
the program to start up each time the system is rebooted.
• IP Addresses: Similar to URLs and domain names,
Internet Protocol (IP) addresses often are hard-coded
into malicious programs and serve as “phone home”
instructions, or in other instances, the direction of the
attack.
• E-mail Addresses: Some specimens of malicious code
e-mail the attacker information extracted from the victim
machine. For example, many of the Trojan horse variants
install a keylogger on the victim computers to collect
usernames and passwords and other sensitive
information, then transmit the information to a drop-site
e-mail address that serves as a central receptacle for the
stolen data. An attacker’s e-mail address is obviously a
significant evidentiary clue that can develop further
investigative leads.
• IRC Channels: Often the channel server and name of
the Internet Relay Chat (IRC) command and control
server used to herd armies of compromised computers
or botnets are hard-coded into the malware that infects
the zombie machines. Indeed, suspect files may even
reference multiple IRC channels for redundancy
purposes should one channel be lost or closed and
another channel comes online.
• Program Commands or Options: More often than not,
an attacker needs to interact with the malware he or she
is spreading, usually to promote the efficacy of the
spreading method. Some older bot variants use instant
messenger (IM) programs as an attack vector, and as
such, the command to invoke IM spreading can be
located within the program’s strings. Similarly,
command-line options and/or embedded help/usage
menu information can potentially reveal capabilities of a
target specimen.
• Error and Confirmation Messages: Confirmation and
error messages found in malware specimens (such as
“Exploit FTPD is running on port: %i, at thread
number: %i, total sends: %i”) often become significant
investigative leads and provide good insight into the
malware specimen’s capabilities.
Analysis Tip
Analysis Tip
False Leads: “Planted” Strings
Despite the potential value embedded strings may have in the
analysis of a suspect program, be aware that hackers and
malware authors often “plant” strings in their code to throw
digital investigators off track. Instances of false nicknames, e-
mail addresses, and domain names are fairly common. When
examining any given malware specimen and evaluating the
meaningfulness of its embedded strings, remember to consider
the entire context of the file and the digital crime scene.
Tools for Analyzing Embedded Strings
Unlike Linux and UNIX distributions, which typically come
preloaded with the strings utility, Windows operating systems
do not have a native tool to analyze strings. Thankfully, there are
a number of strings extracting utilities, both CLI and GUI,
available for use on Windows systems.
• A version of strings, named “strings.exe” has been
ported to Windows by Mark Russinovich of Microsoft
(formerly of Sysinternals).27
• Like the UNIX/Linux version of strings, Russinovich’s
ported version can query for both ASCII and Unicode
strings and by default searches for three or more
printable characters. Strings.exe can also recursively
scan subdirectories.
• BinText28 is an intuitive and powerful GUI-based strings
extraction program that displays ASCII, Unicode, and
resource strings, each identified by a distinct letter and
color on the left-hand side of the GUI (ASCII strings are
identified by a green “A,” Unicode Strings by a Red “U,”
and resource strings by a blue “R”), as displayed in
Figure 5.13.
• BinText identifies the file offset and memory address of
the discoverable strings in unique fields in the GUI.
Further, the tool provides drag-and-drop functionality
and a useful search feature, allowing the digital
investigator to query for particular strings within the
investigator to query for particular strings within the
output.
Figure 5.13 Examining a suspect file in BinText
Other Tools to Consider
GUI Strings Analysis Tools
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter, and on the
companion Web site,
http://www.malwarefieldguide.com/Chapter5.html.
Inspecting File Dependencies: Dynamic or Static Linking
During initial analysis of a suspect program, simply identifying
whether the file is a static or dynamically linked executable will
provide early guidance about the program’s functionality and
what to anticipate during later dynamic analysis of library and
system calls made during its execution.
• A number of tools can help quickly assess whether a
suspect binary is statically or dynamically linked.
• DUMPBIN,29 a command-line utility provided with
Microsoft Visual C++ in Microsoft Visual Studio,30
combines the functionality of the Microsoft development
tools LINK, LIB, and EXEHDR. Thus, DUMPBIN can parse a
suspect binary to provide valuable information about the
file format and structure, embedded symbolic
information, as well as the library files required by the
program.
• To identify an unknown binary file’s dependencies, query
the target file with DUMPBIN, using the /DEPENDENTS
argument, as shown in Figure 5.14.
• To obtain a better picture of the suspect file’s capabilities
based upon the dependencies it requires, research each
dependency separately, eliminating those that appear
benign or commonplace, and focus more on those that
seem more anomalous. Some of the better Web sites on
which to perform such research are listed in the textbox
Online Resources: Reference Pages.
Figure 5.14 DUMPBIN query of a suspect file
Online Resources
Reference Pages
It is handy during the inspection of embedded entities like strings,
dependencies, and API function call references to have reference
Web sites available for quick perusal. Consider adding these
Web sites to your browser toolbar for quick and easy reference.
Windows API Reference—http://msdn.microsoft.com/en-
us/library/aa383749%28v=vs.85%29.aspx
Process and Thread Functions
Reference—http://msdn.microsoft.com/en-
us/library/ms684847.aspx
Microsoft DLL Help Database—Retired by Microsoft in
February 2010, but archived on
http://web.archive.org/web/20090615190853/http://support.microsoft.com/dllhelp/
Microsoft Advanced Search
Engine—http://search.microsoft.com/advancedsearch.aspx?
mkt=en-US&setlang=en-US
Microsoft TechNet—http://technet.microsoft.com/en-us/
Microsoft Standard .Exe Files and Associated
.DLLs—http://technet.microsoft.com/en-
us/library/cc768380.aspx
• If the feel of a GUI tool to inspect file dependencies is
preferred, Tim Zabor has developed dumpbinGUI,31 a
sleek front-end for DUMPBIN, which includes
dumpbinCHM, a shell context menu that allows for a
right-click on the target file and a selection of the
DUMPBIN argument to be applied against a target file.
• To gain a more granular perspective of a target file’s
dependencies, a useful command-line and GUI utility is
Dependency Walker, 32 which builds a hierarchical tree
diagram of all dependent modules in the binary
executable—allowing drill-down identification of the files
that the dependencies require and invoke, as shown in
that the dependencies require and invoke, as shown in
Figure 5.15.
Figure 5.15 Examining a suspect file with Dependency Walker
Symbolic and Debug Information
The way in which an executable file is compiled and
linked by an attacker often leaves significant clues about
the nature and capabilities of a suspect program.
If an attacker does not strip an executable file of program
variable and function names known as symbols, which reside in
a structure within Windows executable files called the symbol
table, the program’s capabilities may be readily detected.
• To check for symbols in a binary, turn to the utility nm,
which is preinstalled in most distributions of the Linux
operating system. The nm command identifies symbolic
and debug information embedded in executable/object
files specimen.
• Although Windows systems do not have an inherent
equivalent of this utility, there are several other tools that
nicely extract the same symbol information.
• As with file dependencies, DUMPBIN can be used with the
/SYMBOLS argument to display the symbols present in a
Windows executable file’s symbol table.
• As previously discussed, there is a GUI alternative to the
DUMPBIN console program called dumpbinGUI, which
DUMPBIN console program called dumpbinGUI, which
also can be used to query target files for symbolic
information. DumpbinGUI is particularly helpful in that it
offers a shell context menu, allowing for a file to be right-
clicked and run through the program.
Embedded File Metadata
In addition to embedded strings and symbolic
information, an executable file may contain valuable
clues within its file metadata.
The term metadata refers to information about data. In a
forensic context, discussions pertaining to metadata typically
center on information that can be extracted from document files,
like those created with Microsoft Office applications. Metadata
may reveal the author of a document, the number of revisions,
and other private information about a file that normally would not
be displayed.
• Metadata also resides in executable files, and often these
data can provide valuable insight as to the compilation
date/time, origin, purpose, or functionality of the file.
• Metadata in the context of an executable file does not
reveal technical information related to file content, but
rather contains information about the origin, ownership,
and history of the file. In executable files, metadata can
be identified in a number of ways.
To create a binary executable file, a high-level
programming language must be compiled into an object
file, and in turn, be linked with any required libraries and
additional object code.
From this process alone, numerous potential metadata
footprints are left in the binary, including the high-level
language in which the program was written, the type and
version of the compiler and linker used to compile the
code, and the date and time of compilation.
• In addition to these pieces of information, other file
metadata may be present in a suspect program, including
metadata may be present in a suspect program, including
information relating to the following:
Metadata Artifacts
Program author Publisher Warnings
Program version Author/Creator Location
Operating system or platform in
which the executable was compiled
Created by
software Format
Intended operating system and
processor of the program
Modified by
software
Resource
Identifier
Console or GUI program Contributorinformation
Character
Set
Company or organization Copyrightinformation
Spoken or
Written
Language
Disclaimers License Subject
Comments Previous FileName
Hash
Values
Creation Date Modified Date AccessDate
Creation Date Modified Date Date
• These metadata artifacts are references from various parts
of the executable file structure. The goal of the metadata
harvesting process is to extract historical and identifying
clues before examining the actual executable file
structure.
• Later in this chapter (in the “Windows Portable
Executable Format” section), as well as in Chapter 6, we
will be taking a detailed look at the format and structure
of the PE file, and specifically where metadata artifacts
reside within it.
• Most of the metadata artifacts listed in the previous table
manifest in the strings embedded in the program; thus,
the strings parsing tools discussed earlier in this chapter
certainly can be used to discover them. However, for a
more methodical and concise exploration of an
unknown, suspect program, the tasks of examining the
strings of the file and harvesting file metadata are better
separated.
• To gather an overview of file metadata as a contextual
baseline, scan a suspect file with exiftool.33 A number
of GUI front-ends have been developed for exiftool
that provide for drag-and-drop functionality and
recursive scanning.
• Exiftool will provide the digital investigator with
temporal context, operating system, and target
environment identifiers, along with other helpful clues
such as linker version, as displayed in Figure 5.16.
However, further probing is often required to gather
additional metadata artifacts of value from a suspect
executable file.
• After gaining an overview of the file metadata, review or
“peel” the file for specific metadata artifacts in
chronological order of the compilation process—from
high-level source code to compiled executable. Initial
clues to look for include:
Identify the high-level language used to create the suspect
program
Determine the compiler (and linker version) used to
create the program
create the program
Ascertain the file compilation time and date
Identify the Regional Settings (Language Code and
Character Set) embedded within the binary during the
time of compilation
File version information
• Often, metadata items of interest are obfuscated by the
attacker through packing or encrypting the file (discussed
in the “File Obfuscation: Packing and Encryption
Identification” section, later in this chapter). If the file is
not obfuscated, the high-level programming language can
be quickly identified by GT2, a file format detection utility
with a shell context menu that allows for a right-click on
the target file.34
• Although GT2 can identify and parse many file formats, it is
particularly geared toward extracting data from PE files.
Figure 5.17 displays the output of GT2 extracting file
version information and identifying the high-level
programming language of a target file (Visual C++ 6.0).
• There are a number of other utilities that may be useful for
identifying the compiler used to create a binary
executable. Among them is PEid,35 a power utility for
examining PE files, including compiler and packing
identification. Another is Babak Farrokhi’s Language
2000 tool,36 an older compiler detection utility, which
identifies the compiler used to create a program and
extracts the program version information embedded in
the file.
• PE file metadata can also provide temporal context
surrounding an incident and contribute toward building
an investigative time line in conjunction with live response
and post-mortem forensic artifacts acquired from a
victim system.
• In particular, the date and time stamp when the
executable was compiled can be extracted from the
IMAGE_FILE_HEADER structure of a PE file. A
detailed discussion of the IMAGE_FILE_HEADER and
other PE file structures can be found in the section
“Windows Portable Executable File Format,” later in this
chapter.
chapter.
The compilation date and time can be quickly extracted
using Nick Harbour’s pestat command line utility.37
For digital investigators who prefer a graphical utility, as
depicted in Figure 5.18, MiTeC’s EXE Explorer38
intuitively extracts and displays the time stamp data (in
GMT).
• Looking back at the output in Figure 5.17, extensive file
version information was extracted, most likely obtained
from the executables Resource section (a topic covered
in depth in Chapter 6). Although this information is not
dispositive, these are substantial leads that can be further
pursued through online research.
• To gain further insight about the attacker, examine the
Language Code and Character Set identifiers embedded
within the IMAGE_RESOURCE_DIRECTORY
structure of the binary during the time of compilation.
These settings provide information about the native
attacker system environment or settings selected by the
attacker during compilation.
For example, looking at the data extracted in Figures
5.16 and 5.17, we learn that the regional settings in the
suspect executable include a Language Identifier Code
041904E3 (Russian)39 and a Character Set (Cyrillic).40
A granular examination of the Language and Character
codes can be conducted by parsing the Resource section
of a target file with a PE Analysis tool such as
HeavenTools’ PE Explorer, 41 as depicted below in
Figure 5.19.
Figure 5.16 Gathering metadata from a PE file with exiftool
Figure 5.17 PE metadata extracted with GT2
Figure 5.18 PE compilation date and time extracted with EXE
Explorer
Figure 5.19 Examining language and character codes with PE
Explorer
Online Resources
Online Resources
Locale Identifiers
Consider adding these Web sites to your browser toolbar for
quick and easy reference of Locale Identifiers.
Locale IDs Assigned by
Microsoft—http://msdn.microsoft.com/en-
us/goglobal/bb964664
Locale IDs, Inout Locales, and Language Collections
for Windows XP and Windows Server
2003—http://msdn.microsoft.com/en-
us/goglobal/bb895996
Investigative Consideration:
• A word of caution: As with embedded strings, file
metadata can be modified by an attacker. Time and date
stamps, file version information, and other seemingly
helpful metadata are often the target of alteration by
attackers who are looking to thwart the efforts of
researchers and investigators from tracking their attack.
File metadata must be reviewed and considered in
context with all of the digital and network-based
evidence collected from the incident scene.
File Obfuscation: Packing and Encryption
Identification
Thus far this chapter has focused on methods of
reviewing and analyzing data in and about a suspect file.
All too often, malware “in the wild” presents itself as
armored or obfuscated, primarily to circumvent network
security protection mechanisms like anti-virus software
and intrusion detection systems.
Obfuscation is also used to protect the executable’s
Obfuscation is also used to protect the executable’s
innards from the prying eyes of virus researchers, malware
analysts, and other information security professionals interested
in reverse-engineering and studying the code.
• Moreover, in today’s underground hacker economy, file
obfuscation is no longer used to just block the “good
guys,” but also to prevent other attackers from examining
the code. Savvy and opportunistic cyber criminals can
analyze the code, determine where the attacker is
controlling his infected computers or storing valuable
harvested information (like keylogger contents or credit
card information), and then “hijack” those resources
away to build their own botnet armies or enhance their
own illicit profits from phishing, spamming, click fraud, or
other forms of fraudulent online conduct.
• Given these “pitfalls,” attackers use a variety of utilities to
obscure and protect their file contents; it is not
uncommon to see more than one layer, or a combination,
of file obfuscation applied to hostile code to ensure it
remains undetectable.
• Some of the more predominant file obfuscation
mechanisms used by attackers to disguise their malware
include packers, encryption programs (known in hacker
circles as cryptors), and binders, joiners, and wrappers,
as graphically portrayed in Figure 5.20. Let’s take a
look at how these utilities work and how to spot them.
Figure 5.20 Obfuscating code
Packers
The terms packer, compressor, and packing are used in the
information security and hacker communities alike to refer
generally to file obfuscation programs.
• Packers are programs that allow the user to compress,
and in some instances encrypt, the contents of an
executable file.
• Packing programs work by compressing an original
executable binary, and in turn, obfuscating its contents
within the structure of a “new” executable file. The
packing program writes a decompression algorithm stub,
often at the end of the file, and modifies the executable
file’s entry point to the location of the stub.42
• As illustrated in Figure 5.21, upon execution of the
packed program, the decompression routine extracts the
original binary executable into memory during runtime
and then triggers its execution.
• In addition to unpacking programs that were created to
foil specific packers, there are numerous generic
unpackers and file dumping utilities that can be
implemented during runtime analysis of a packed
executable malware specimen. These tools will be
discussed in greater detail in Chapter 6.
Figure 5.21 Execution of a packed malware specimen
Cryptors
Executable file encryption programs or encryptors, better
known by their colloquial “underground” names cryptors (or
crypters) or protectors, serve the same purpose for attackers
as packing programs. They are designed to conceal the contents
of the executable program, render it undetectable by anti-virus
and IDS, and resist any reverse engineering or hijacking efforts.
• Unlike packing programs, cryptors accomplish this goal
by applying an encryption algorithm upon an executable
file, causing the target file’s contents to be scrambled and
undecipherable.
• Like file packers, cryptors write a stub containing a
decryption routine to the encrypted target executable,
thus causing the entry point in the original binary to be
altered. Upon execution, the cryptor program runs the
decryption routine and extracts the original executable
dynamically at runtime, as shown in Figure 5.22.
Figure 5.22 Execution of a cryptor protected executable file
Figure 5.22 Execution of a cryptor protected executable file
Packer and Cryptor Detection Tools
PEiD43 is the packer and cryptor freeware detection tool most
predominantly used by digital investigators, both because of its
high detection rates (more than 600 different signatures) and its
easy-to-use GUI interface that allows multiple file and directory
scanning with heuristic scanning options.
• PEiD allows drag-and-drop functionality to quickly
identify obfuscation signatures, as demonstrated in Figure
5.23.
• PEiD contains a plug-in interface44 and a myriad of plug-
ins that afford additional detection functionality. Plug-ins
are listed and described in the Tool Box section at the
end of this chapter.
• Entropy calculation—or the measurement of disorder in a
block of data45—and PE Entry Point (EP) anomaly
detection in a suspect file can be calculated with PEiD
using the “Extra Information” feature invoked by clicking
the double append button located at the bottom right
corner of the PEiD GUI. High entropy levels are
typically indicia that an obfuscation scheme has been
applied to a suspect file.
• In addition to PEiD, there are a number of other GUI-
based obfuscation detection tools that offer slightly
different features and plug-ins, including Mandiant’s Red
Curtain,46 NTCore’s PE Detective,47 and RDG.48 Refer
to the Tool Box section at the end of this chapter and on
the companion Web site,
http://www.malwarefieldguide.com/Chapter5.html, for
additional tool options.
Figure 5.23 Analyzing a suspect file with PEiD
CLI Packing and Cryptor Detection Tools
• In addition to these GUI-based tools, there are a few
handy python-based tools, making them extensible and
command-line operated.
• Pefile,49 developed by Ero Carrera, is a robust PE file
parsing utility as well as a packing identification tool. In
particular, some of its functionality includes the ability to
inspect the PE header and sections, obtain warnings for
suspicious and malformed values in the PE image, detect
file obfuscation with PEiD’s signatures, and generate
new PEiD signatures.
• Jim Clausing, a SANS Internet Storm Center Incident
Handler, wrote a similar python script for PE packer
identification based upon pefile, called packerid.py.50
Like pefile, packerid.py is extensible and can be run in
both the Windows and Linux environments, convenient
for many Linux purists who prefer to conduct malware
analysis in a Linux environment. Further, like pefile,
packerid.py can be configured to compare queried files
against various PE obfuscation signature databases,
including those used by PEiD51 and others created by
Panda Security.52 The output of packerid.py as applied
Panda Security.52 The output of packerid.py as applied
against a suspect binary can be seen in Figure 5.24.
• Another very helpful CLI-based packer detection utility is
SigBuster, written by Toni Koivunen of teamfurry.com.
SigBuster has a myriad of different scan options and
capabilities, and is written in Java, making it useful on
Linux and UNIX systems (Figure 5.25). Currently,
SigBuster is not publicly available, but is available to
anti-virus researchers and law enforcement. However,
SigBuster is implemented in the Anubis online malware
analysis sandbox where the public can submit specimens
for analysis.53
Figure 5.24 Inspecting a suspect file with packer.py on a Linux
system
Figure 5.25 Inspecting a suspect file with SigBuster on a Linux
system
Binders, Joiners, and Wrappers
Binders (also known as joiners or wrappers) in the Windows
environment simply take Windows PE files and roll them into a
single executable.
• The binder author can determine which file will execute
and whether the state will be normal or hidden. The copy
location of the file can be specified in the Windows,
system, or temp directories, and the action can be
specified to either open/execute or copy only.
• From the underground perspective, binders allow
attackers to combine their malicious code executable
together with a benign one, with the latter serving as an
effective delivery vehicle for the malicious code’s
distribution.
• There are many different binders available on the Internet;
a simple and most fully featured one is known as YAB
or “Yet Another Binder.”54
Embedded Artifact Extraction Revisited
After de-obfuscating a target specimen, conduct a file
profile of the unobscured file.
After successfully pulling malicious code from its armor
through the static and behavioral analysis techniques discussed in
Chapter 6, re-examine the unobscured program for strings,
Chapter 6, re-examine the unobscured program for strings,
symbolic information, file metadata, and PE structural details. In
this way, a comparison of the “before” and “after” file will reveal
more clearly the most important thing about the structure,
contents, and capabilities of the program.
Windows Portable Executable File Format
A robust understanding of the file format of a suspect
executable program that has targeted a Windows system
will best facilitate effective evaluation of the nature and
purpose of the file.
This section will cover the basic structure and contents of
the Windows PE file format. In Chapter 6 deeper analysis of PE
files will be conducted.
• The PE file format is derivative of the older Common
Object File Format (COFF) and shares with it some
structural commonalities.
• The PE file format not only applies to executable image
files, but also to DLLs and kernel-mode drivers.
Microsoft dubbed the newer executable format
“Portable Executable” with aspirations of making it
universal for all Windows platforms, an endeavor that
has proven successful.
• The PE file format is defined in the winnt.h header file in
the Microsoft Platform Software Development Kit
(SDK). Microsoft has documented the PE file
specification,55 and researchers have written
whitepapers focusing on its intricacies.56
• Despite these resources, PE file analysis is often tricky
and cumbersome.57 The difficultly lies in the fact that a
PE file is not a single, large continuous structure, but
rather a series of different structures and sub-
components that describe, point to, and contain data or
code, as illustrated graphically in Figure 5.26.
code, as illustrated graphically in Figure 5.26.
• To gain a clear and intuitive perspective of the entire PE
file format, run the suspect binary through a CLI tool,
like Matt Pietrek’s pedump utility,58 or pefile.py, so that
each structure and sub-component can be studied and
analyzed in a comprehensive view. Alternatively, for a
general graphical overview of the PE structure, load the
suspect file into a GUI-based PE analysis tool, such as
PEView,59 AnyWherePEViewer,60 and CFF Explorer61
(see Figure 5.27), among others.
• After reviewing the entirety of the PE file output, which
can often be rather extensive, consider “peeling” the data
slowly by reviewing each structure and sub-component
individually; that is, begin your analysis at the start of the
PE module and work your way through all of the
structures and sections, taking careful note of the data
that are present, and perhaps just as important, the data
that are not.
Figure 5.26 The Portable Executable (PE) file format
Figure 5.27 Parsing a suspect PE file with CFF Explorer
MS-DOS Header
The IMAGE_DOS_HEADER structure, or MS-DOS
header, is the file structure that every PE file begins with. For
investigative purposes, the MS-DOS header contains two
important pieces of information.
• First, the e_magic field contains the DOS executable file
signature, previously identified as “MZ” or the
hexadecimal characters 4D 5A, found in the first two
bytes of the file. Similarly, Borland Delphi executables
have a “P” in the file signature, following the MZ.
• Second, as shown in Figure 5.28, the e_lfanew field
points to the offset in the file where the PE header
begins, known as the IMAGE_NT_HEADERS
structure.
structure.
Figure 5.28 The e_magic and e_lfanew fields in
IMAGE_DOS_HEADER
MS-DOS Stub
The IMAGE_DOS_HEADER is followed by the MS-DOS
stub program, which serves primarily as a compatibility
notification method.
notification method.
• In particular, when the PE file format was first introduced,
many users operated in DOS and not within the
Windows GUI environment. If a PE file is mistakenly
executed in DOS, the MS-DOS stub prints out the
message “This program cannot be run in DOS mode.”
• The stub program is not essential for the successful
execution of a PE file, and many times attackers will
modify, delete, or otherwise obfuscate it (see Figure
5.29).
Figure 5.29 The MS-DOS Stub Program
PE Header
Below the MS-DOS stub, at the offset address designated by
t h e e_lfanew field, resides the IMAGE_NT_HEADERS
structure, also known simply as the PE Header.62
• As depicted in Figure 5.30, the PE Header is actually
comprised of the PE signature and two other data
structures: the IMAGE_FILE _HEADER structure and
the IMAGE_OPTIONAL_HEADER structure, which
contains its own substructure, the Data Directory.
Figure 5.30 The PE Header and its contents
• A PE file is identified by the 4-byte (or DWORD)
signature “PE” followed by two null values (ASCII
characters “PE” with the hexadecimal translation of 50
characters “PE” with the hexadecimal translation of 50
45 00 00). The signature appears in the file after the
MS-DOS stub, but need not be located at a particular
offset.
• The first sub-structure in the IMAGE_NT_HEADERS
structure is the IMAGE_FILE_HEADER, also known
as the COFF File header.63
• From an investigative perspective, this structure is
potentially comprised of informative data about the target
file, including, among other things (Figure 5.31)64:
Time and date the file was compiled/created
Target platform/processor
Number of sections in the Section Table
File characteristics, such as whether the file is executable
Whether symbols have been stripped from the file
Whether debugging information has been stripped from
the file
Figure 5.31 The IMAGE_FILE_HEADER structure
• To parse the IMAGE_FILE_HEADER for these details,
query the suspect file in PEView, a GUI-based tool that
provides an intuitive interface for navigating headers,
descriptors, and values for each field in the PE structure,
as shown in Figure 5.32.
Figure 5.32 Examining the Image_File_Header with PEView
• Following the IMAGE_FILE_HEADER structure is the
IMAGE_OPTIONAL_HEADER, better known simply
as the Optional Header, which is ironically not optional
as the executable will fail to load without it.65 (See
Figure 5.33.)
Figure 5.33 The IMAGE-OPTIONAL_HEADER structure
• The Optional Header is dense with a number of fields
containing items of interest to digital investigators that can
be extracted from this structure, including66:
Linker version used to compile the executable file
DLL characteristics
Pointer to address of entry point
Operating system version
Data Directory
In addition, the Optional Header also contains the
IMAGE_DATA_DIRECTORY structures, commonly referred
to as Data Directories. The IMAGE_DATA_DIRECTORY,
shown in Figure 5.34, contains 16 directories that identify values
and map the locations of other structures and sections within the
PE file.
Figure 5.34 The IMAGE_DATA_DIRECTORY structure
• Not all PE files have entries in all 16 Data Directories, so
when assessing a suspect executable, make note of
which directories are present.
Section Table
The last structure in the PE file is the
IMAGE_SECTION_HEADER, or Section Table, which
follows immediately after the IMAGE_DATA_DIRECTORY.
• The Section Table consists of individual entries, or section
headers, each 40 bytes in size and containing the name,
size, and description of the respective section.
• The IMAGE_FILE_HEADER (COFF header) structure
contains a “NumberOfSections” field, which identifies
the number of entries in the Section Table. The Section
Table entries are arranged in ascending order, starting
from the number one (see Figure 5.35).
Figure 5.35 Section Table
Online Resources
Exe Dump Utility
To get a feel for how pefile works, submit an executable file to
the Exe Dump Utility portal at
http://utilitymill.com/utility/Exe_Dump_Utility and receive a text
or HTML report containing the results of the file being processed
through pefile.
Profiling Suspect Document Files
During the course of profiling a suspect file, the digital
investigator may determine that a file specimen is not an
executable file, but rather a document file, requiring distinct
examination tools and techniques.
Malicious document files have become a
burgeoning threat and increasingly popular vector of
attack by malicious code adversaries.
Malicious documents crafted by attackers to exploit
vulnerabilities in document processing and rendering software
such as Adobe (Reader/Acrobat) and Microsoft Office (Word,
PowerPoint, Excel) are becoming increasingly more common.
• As document files are commonly exchanged in both
business and personal contexts, attackers frequently use
social engineering techniques to infect victims through this
vector—such as attaching a malicious document to an e-
mail seemingly sent from a recognizable or trusted party.
• Typically, malicious documents contain a malicious
scripting “trigger mechanism” that exploits an application
vulnerability and invokes embedded shellcode; in some
instances, an embedded executable file is invoked or a
network request is made to a remote resource for
additional malicious files.
• Malicious document analysis proposes the additional
challenges of navigating and understanding numerous file
formats and structures, as well as obfuscation techniques
to stymie the digital investigator’s efforts.
In this section we will examine the overall methodology
for examining malicious documents. As the facts and context of
each malicious code incident dictates the manner and means in
which the digital investigator will proceed with his investigation,
the techniques outlined in this section are not intended to be
the techniques outlined in this section are not intended to be
comprehensive or exhaustive, but rather to provide a solid
foundation relating to malicious document analysis.
• Malicious Document Analysis Methodology
Identify the suspicious file as a document file through file
identification tools
Scan the file to identify indicators of malice
Examine the file to discover relevant metadata
Examine the file structure to locate suspect embedded
artifacts, such as scripts, shellcode, or executable files
Extract suspect scripts/code/files
If required, decompress or de-obfuscate the suspect
scripts/code/files
Examine the suspect scripts/code/files
Identify correlative malicious code, file system, or
network artifacts previously discovered during live
response and post-mortem forensics
Determine relational context within the totality of the
infection process
Profiling Adobe Portable Document Format (PDF) Files
A solid understanding of the PDF file structure is
helpful to effectively analyze a malicious PDF file.
PDF File Format
A PDF document is a data structure comprised of a series of
elements Figure 5.37)67:
• File Header: The first line of a PDF file contains a
• File Header: The first line of a PDF file contains a
header, which contains 5 characters; the first three
characters are always “PDF,” and the remaining two
characters define the version number, for example,
“%PDF-1.6” (PDF versions range from 1.0 to 1.7).
• Body: The PDF file body contains a series of objects that
represent the contents of the document.
• Objects: The objects in the PDF file body represent
contents such as fonts, text, pages, and images.
Objects may reference other objects. These indirect
objects are labeled with two unique identifiers
collectively known as the object identifier: (1) an
object number and (2) a generation number.
After the object identifier is the definition (Figure 5.36)
of the indirect object, which is contained in between the
keywords “obj” and “endobj.” For example:
Indirect objects may be referred to from other locations
in the file by an indirect reference , or “references,”
which contains the object identifier and the keyword “R,”
for example: 11 0 R.
Objects that contain a large amount of data (such as
images, audio, fonts, movies, page descriptions, and
JavaScript) are represented as stream objects or
“streams.”68 Streams are identified by the keywords
stream and endstream, with any data contained in
between the words manifesting as the stream. Although a
stream may be of unlimited length, streams are typically
compressed to save space, making analysis challenging.
Careful attention should be paid to streams during
analysis, as attackers frequently take advantage of their
large data capacity and embed malicious scripting within
a stream inside of an object.
• Cross Reference (XREF) Table : The XREF table
serves as a file index and contains an entry for each
object. The entry contains the byte offset of the
respective object within the body of the file. The XREF
respective object within the body of the file. The XREF
Table is the only element within a PDF file with a fixed
format, enabling entries within the table to be accessed
randomly.69
• Trailer: The end of a PDF file contains a trailer, which
identifies the offset location of the XREF table and
certain special objects within the file body.70
Figure 5.36 Object definition
Figure 5.37 The Portable Document File format
In addition to the structural elements of a PDF, there are
embedded entities for investigative consideration, such as
dictionaries, action type keywords, and identifiable compression
schemes as described in the next chart.71
Keyword Relevance
/AA
Indicia of an additional-actions dictionary that
defined actions that will occur in response to
various trigger events affecting the document as
a whole.
a whole.
/Acroform
Interactive form dictionary; indicia that an
automated action will occur upon the opening
of the document.
/OpenAction
A value specifying a destination that will be
displayed, or an action that will occur when the
document is opened.
/URI
Indicia that a URI (uniform resource identifier)
will be resolved, such as a remote resource
containing additional malicious files.
/Encrypt
Indicia that encryption has been applied to the
contents of strings and streams in the document
to protect its contents.
/Named Indicia that a predefined action will beexecuted.
/JavaScript Indicia that the PDF contains JavaScript.
FlateDecode Indicia of a compression scheme encoded withthe zlib/deflate compression method.
/JBIG2Decode Indicia of a compression scheme encoded withthe JBIG2 compression method.
/JS Indicia that the PDF contains JavaScript.
/EmbeddedFiles Indicia of embedded file streams.
/Launch Indicia that an application will be launched or afile will be opened.
/Objstm Indicia of an object stream inside the body ofthe PDF document.
/Pages An indicator that interactive forms will beinvoked.
/RichMedia Indicia that the PDF contains JavaScript.
Pdf Profiling Process: CLI Tools
The following steps can be taken to examine a suspect PDF
The following steps can be taken to examine a suspect PDF
document:
Triage: Scan for Indicators of Malice
• Inspect the suspect file for indicators of malice—clues
within the file that suggest the file has nefarious
functionality—using Didier Stevens’ python utility,
pdfid.py.
• Pdfid.py scans the document for keywords and provides
the digital investigator with a tally of identified keywords
that are potentially indicative of a threat, such as those
previously described (Figure 5.38).
Figure 5.38 Scanning a suspect PDF file with pdfid.py
• An alternative to pdfid.py for triaging a suspect PDF is
the pdfscan.rb script in Origami, a Ruby framework for
parsing and analyzing PDF documents.72
• Further, the python utility pdf-parser.py (discussed in
greater detail later), when used with the –stats switch,
can be used to collect statistics about the objects present
in a target PDF file specimen.
in a target PDF file specimen.
Discover relevant metadata
• Meaningful metadata can provide temporal context,
authorship, and original document creation details about
a suspect file.
• Temporal metadata from the suspect file can be gathered
with pdfid.py using the –extra switch (Figure 5.39).
Figure 5.39 Metadata gathered from a suspect PDF with the
pdfid.py –extra command switch (left) and the Origami
framework printmetadata.rb script (right).
• Deeper metadata extraction, such as author, original
document name, and original document creation
application, among other details, can be acquired by
querying the suspect file with the Origami framework
printmetadata.rb script.
Examine the file structure and contents
• After conducting an initial assessment of the file, use
Didier Stevens’ pdf-parser.py tool to examine the
specimen’s file structure and contents to locate suspect
embedded artifacts, such as anomalous objects and
streams, as well as hostile scripting or shellcode. The
following commands are useful in probing the PDF file
specimen:
Command
Switch Purpose
–stats Displays statistics for the target PDF file
–search
String to search in indirect objects (except
streams)
–filter
Pass stream object through filters (FlateDecode
ASCIIHexDecode and ASCII85Decode only)
–object=
independent)
–reference=
ID of indirect object being referenced (version
independent)
–elements= Type of elements to select (cxtsi)
–raw Raw output for data and filters
–type= Type of indirect object to select
–verbose Displays malformed PDF elements
–extract=
Filename to extract to
–hash Displays hash of objects
–dump Dump unfiltered content of a stream
–disarm Disarms the target PDF file
• An alternative to pdf-parser.py is the pdfscan.rb script
from the Origami framework.
• Use the information collected with pdfid.py as a guide
for examining the suspect file with pdf-parser.py. For
instance, the pdfid.py results in Figure 5.38 revealed the
presence of JavaScript in the suspect file. Pdf-parser.py
can be used to dig deeper into the specimen, such as
locating and extracting this script.
Locating suspect scripts and shellcode
• To locate instances of JavaScript keywords in the suspect
file, use the –search switch and the string javascript,
as shown in Figure 5.40. The results of the query will
identify the relevant objects and references in the file.
Figure 5.40 Searching the suspect file for embedded JavaScript
with pdf-parser.py
• The relevant object can be further examined using the —
object=
Figure 5.41 Parsing a specific object with pdf-parser.py
Decompress suspect stream objects and reveal scripts
• Use the –filter and –raw switches to decompress the
contents of the stream object and reveal the scripting as
shown in Figure 5.42.
Figure 5.42 Decompressing the suspect stream object with pdf-
parser.py (Cont’d)
Extract suspect JavaScript for further analysis
• The suspicious JavaScript can be extracted by redirecting
the output in Figure 5.42 to a new file, such as
output.js, as shown in Figure 5.43.
Figure 5.43 Extracting suspicious JavaScript using pdf-
parser.py
• Other methods that can be used to extract the JavaScript
include:
Processing the target file with the jsunpack-n script,
pdf.py.73
Processing the target file with the Origami framework
script, extractjs.rb.74
Examine extracted JavaScript
• JavaScript extracted from a suspect PDF specimen can
be examined through a JavaScript engine such as Mozilla
Foundation’s SpiderMonkey.75
• A modified version of SpiderMonkey geared toward
malware analysis has been adapted by Didier Stevens.76
Extract shellcode from JavaScript
• Attackers commonly exploit application vulnerabilities in
Adobe Reader and Acrobat with malicious PDF files
containing JavaScript embedded with shellcode (typically
obfuscated in an unescape() function), as shown in
Figure 5.42.77
• Often, the shellcode payload is injected into memory
through performing a heap spray,78 and in turn, invoking
the execution of a PE file embedded (and frequently
encrypted) in the suspect PDF file.79
• The shellcode can be extracted from the JavaScript for
further analysis.
After copying the shellcode out of JavaScript, compile it
into a binary file for deeper analysis, such as
examination of strings, disassembling, or debugging.
Prior to compilation, be certain that the target
shellcode has been “unescaped”—or deciphered from
shellcode has been “unescaped”—or deciphered from
t h e unescape encoding—and placed into binary
format.
Shellcode can be compiled into a Windows executable
file with the python script shellcode2exe.py,80 the
convertshellcode.exe utility,81 and MalHostSetup
(included with OfficeMalScanner; discussed later in
this chapter in the “MS Office Dcoument Profiling
Process” section). Similarly, a shellcode2exe Web
portal exists for online conversion.82
Other Tools to Consider
CLI-based PDF Analysis Tools
PDF
Scanner—http://blogs.paretologic.com/malwarediaries/index.php/pdf-
scanner/
Origami—http://code.google.com/p/origami-framework/;
http://esec-lab.sogeti.com/dotclear/index.php?
pages/Origami
Open PDF Analysis Framework
(OPAF)—http://opaf.googlecode.com;
PDF
Miner—http://www.unixuser.org/~euske/python/pdfminer/index.html
PDF Tool Kit —http://www labs.com/tools/pdftk-the-
pdf-toolkit/
Malpdfobj—http://blog.9bplus.com/releasing-the-
malpdfobj-tool-beta
PDF Profiling Process: GUI Tools
GUI-based tools can be used to parse and analyze suspect
PDF files to gather additional data and context.
• Zynamics’ PDF Dissector83 provides an intuitive and
feature-rich environment allowing the digital investigator
to quickly identify elements in the PDF and navigate the
file structure.
• Anomalous strings can be queried through the tool’s text
search function, and suspect objects and streams can be
identified through a multifaceted viewing pane, as shown
in Figure 5.44, below.
Figure 5.44 Navigating the structure of a suspect PDF file with
PDF Dissector (Figure 5.45)
Figure 5.45 Executing JavaScript with the PDF Dissector
JavaScript interpreter
• The contents of a suspicious object can be further
examined by using the content tree feature of PDF
Dissector.
Once a target object or stream is selected, the contents
are displayed in a separate viewing pane.
Compressed streams are automatically filtered through
FlateDecode and decoded—the contents of which can
be examined in the tool’s built-in text or hexadecimal
viewers.
The contents of a suspicious stream object (raw or
decoded) can be saved to a new file for further analysis.
• PDF Dissector offers a variety of tools to decode,
execute, and analyze JavaScript, as well as extract
embedded shellcode.
• Identified JavaScript can be executed within the tool’s
• Identified JavaScript can be executed within the tool’s
built-in JavaScript interpreter.
• Embedded shellcode that is invoked by the JavaScript
can be identified in the Variables panel. Right-clicking
on the suspect shellcode allows the digital investigator to
copy the shellcode to the clipboard, inspect it within a
hexadecimal viewer, or save it to a file for further
analysis, as depicted in Figure 5.46.
Figure 5.46 Inspecting and saving shellcode extracted from a
suspect file
• Extracted shellcode can be examined in other GUI-based
PDF analysis tools, such as PDF Stream Dumper,84
PDFubar,85 and Malzilla,86 which are described in
further detail in the Tool Box section at the end of this
chapter.
• The Adobe Reader Emulator feature in PDF Dissector
allows the digital investigator to examine the suspect file
within the context of a document rendered by Adobe
within the context of a document rendered by Adobe
Reader, which may use certain API functions not
available in a JavaScript interpreter.
• Adobe Reader Emulator also parses the rendered
structure and reports known exploits in a PDF file
specimen by Common Vulnerabilities and Exposures
(CVE) number and description, as shown in Figure 5.47.
Figure 5.47 Examining a suspect PDF file through the Adobe
Reader Emulator
Online Resources
A number of online resources exist to scan suspicious PDF and
MS Office document files, scan URLs hosting PDF files, or run
suspicious document files in a sandboxed environment. Many of
suspicious document files in a sandboxed environment. Many of
these Web portals also serve as great research aids, providing
database search features to mine the results of previous
submissions.
JSunpack—a JavaScript unpacker and analysis portal,
http://jsunpack.jeek.org/dec/go.
ViCheck.ca—Malicious code analysis portal; numerous
tools and searchable database, https://www.vicheck.ca/.
MalOffice—Malicious document analysis system,
http://mwanalysis.org/?site=7&page=home.
WePawet—A service for detecting and analyzing Web-
based malware (Flash, JavaScript, and PDF files),
http://wepawet.iseclab.org/.
Shellcode2exe—Web portal that converts shellcode to a
Portable Executable file,
http://sandsprite.com/shellcode_2_exe.php.
Profiling Microsoft (MS) Office Files
Malicious MS Office documents are an increasingly
popular vector of attack against individuals and
organizations due to the commonality and prevalence of
Microsoft Office software and MS Office documents.
Microsoft Office Documents: Word, PowerPoint, Excel
MS Office documents such as Word documents, PowerPoint
presentations, and Excel spreadsheets are commonly exchanged
in both business and personal contexts. Although security
protocols, e-mail attachment filters, and other security practices
typically address executable file threats, MS Office files are often
regarded as innocuous and are trustingly opened by recipients.
Attackers frequently use social engineering techniques to infect
Attackers frequently use social engineering techniques to infect
victims through this vector, such as tricking a user to open an
MS Office document attached to an e-mail seemingly sent from a
recognizable or trusted party.
MS Office Documents: File Format
There are two distinct MS Office document file formats87:
• Binary File Format: Legacy versions of MS Office
(1997–2003) documents are binary format ( , .ppt,
.xls).88 These compound binary files are also referred
to as Object Linking and Embedding (OLE)
compound files or OLE Structured Storage files.89
They are a hierarchical collection of structures known as
storages (analogous to a directory) and streams
(analogous to files within a directory). Further, each
application within the MS Office suite has application-
specific file format nuances, as described in further detail
next. Malicious MS Office documents used by attackers
are typically binary format, likely due to the continued
prevalence of these files and the complexity in navigating
the file structures.
Microsoft Word90( )—Binary Word documents
consist of:
WordDocument Stream/Main Stream —This stream
contains the bulk of a Word document’s binary data.
Although this stream has no predefined structure, it
must contain a Word file header, known as the File
Information Block (FIB), located at offset 0.91 The
FIB contains information about the document and
specifies the file pointers to various elements that
comprise the document and information about the
length of the file.92
length of the file.92
Summary Information Streams—The summary
information for a binary Word document is stored in
two storage streams: Summary Information and
DocumentSummaryInformation.93
Table Stream (0Table or 1Table)—The Table Stream
contains data that is referenced from the FIB and
other parts of the file and stores various plex of
character positions (PLCs) and tables that describe
a document’s structure. Unless the file is encrypted,
this stream has no predefined structure.
Data Stream—An optional stream with no predefined
structure, this contains data referenced from the FIB
in the main stream or other parts of the file.
Object Streams—These contain binary data for OLE 2.0
objects embedded within the file.
Custom XML Storage (added in Word 2007).
Microsoft PowerPoint94(.ppt)—Binary PowerPoint
presentation files consist of:
Current User Stream—This maintains the
CurrentUserAtom record, which identifies the name of
the last user to open/modify a target presentation and
where the most recent user edit is located.
PowerPoint Document Stream—This maintains
information about the layout and contents of the
presentation.
Pictures Stream—(Optional) This contains information
about image files (JPG, PNG, etc.) embedded within
the presentation.
Summary Information Streams—(Optional) The
summary information for a binary PowerPoint
presentation is stored in two storage streams: Summary
Information and DocumentSummaryInformation.
Microsoft Excel95(.xls)—Microsoft Office Excel
workbooks are compound files saved in Binary
workbooks are compound files saved in Binary
Interchange File Format (BIFF) which contain
storages, numerous streams (including the main
workbook stream), and substreams. Further, Excel
workbook data consists of records, a foundational data
structure used to store information about features in each
workbook. Records are comprised of three
components: (1) a record type, (2) a record size, and (3)
record data.
• Office Open XML format: MS Office 2007 (and
newer versions of MS Office) use the Office Open XML
file format ( x, .pptx, and .xlsx), which provides an
extended XML vocabulary for word processing,
presentation, and workbook files.96
Unlike the binary file format, which requires particularized
tools to parse the file structure and contents, due to their
container structure, XML-based Office documents can
be dissected using archive management programs such
as WinRar,97 Unzip,98 or 7-Zip,99 by simply renaming
the target file specimen with an archive file extension
(.zip, .rar, or .7z), for example, specimen x to
specimen.rar.
XML-based Office documents are less vulnerable than
their binary predecessors, and as a result, attackers have
not significantly leveraged Office Open XML format files
as a vector of attack. Accordingly, this section will focus
on examining binary format Office documents.
MS Office Documents: Vulnerabilities and Exploits
Attackers typically leverage MS Office documents as a vector
of attack by crafting documents that exploit a vulnerability in an
MS Office suite application.
• These attacks generally rely upon a social engineering
triggering event—such as a spear phishing e-mail—
which causes the victim recipient to open the document,
executing the malicious code.
• Conversely, in lieu of targeting a particular application
vulnerability, an attacker can manipulate an MS Office
file to include a malicious Visual Basic for Applications
(VBA, or often simply referred to as VB) macro, the
execution of which can cause infection.
• By profiling a suspicious MS Office file, further insight as
to the nature and purpose of the file can be obtained; if
the file is determined to be malicious, clues regarding the
infection mechanism can be extracted for further
investigation.
MS Office Document Profiling Process
The following steps can be taken to examine a suspect MS
Office document:
Triage: Scan for Indicators of Malice
• As shown in Figure 5.48, query the suspect file with
Sourcefire’s officecat, a utility that processes
Microsoft Office files for the presence of exploit
conditions.100
Figure 5.48 Scanning a suspect Word document file with
officecat
• Officecat scans the suspect file and compares it against a
predefined set of signatures and reports whether the
suspect file is vulnerable. A list of the vulnerabilities
checked by officecat can be obtained by using the –
list switch.
• In addition, officecat output:
Identifies the suspect file type
Lists the applicable Microsoft Security Bulletin (MSB)
number
Lists the CVE identifier
Provides the unique officecat identification number
(OCID)
• You can further examine the suspect file for indicators of
malice with the Microsoft Office Visualization Tool
(OffVis).101
• OffVis is a GUI-based tool that parses binary formatted
MS Office files, allowing the digital investigator to
traverse the structure and contents of a target file through
a triple-paned graphical viewer, which displays:
A view of the raw file contents in a hexadecimal format
A hierarchical content tree view of the parsing results
A Parsing Notes section, which identifies anomalies in
the file
• When loading a target file into OffVis, select the
corresponding application-specific parser from the
parser drop-down menu, as shown in Figure 5.49.
OffVis uses unique binary format detection logic in each
application-specific parser to identify 16 different CVE
enumerated vulnerabilities; if a vulnerability is discovered
enumerated vulnerabilities; if a vulnerability is discovered
in the target file, the Parsing Notes identify the file as
Definitely Malicious, as shown in Figure 5.49, below.
Figure 5.49 Selecting a parser and examining a suspect MS
PowerPoint document with OffVis
• By double-clicking on the Definitely Malicious Parsing
Note, the raw content of the target file containing the
vulnerability is populated in the hexadecimal viewing
pane.
Discover Relevant Metadata
• Meaningful metadata can provide temporal context,
authorship, and original document creation details about
a suspect file. Insight into this information may provide
clues as to the origin and purpose of the attack.
clues as to the origin and purpose of the attack.
• To extract metadata details from the file specimen, query
the file with exiftool,102 as shown in Figure 5.50.
Examining the metadata contents, a number of valuable
contextual details are quickly elucidated, such as the
Windows code page language (Windows Simplified
Chinese), the purported company name in which the
license of Word was registered to that it generated the
document (VRHEIKER), as well as the file creation, access,
and modification dates.
Figure 5.50 Querying a suspect MS Word file with exiftool
(Cont’d)
• There are a number of others tools that can effectively
probe an MS Office document for metadata. However,
be mindful that some of these tools cause the target file
to open during the course of being processed, potentially
executing embedded malicious code. Be certain to
understand how your metadata extraction tool works
prior to implementing it during an examination.
Deeper Profiling with OfficeMalScanner
OfficeMalScanner is a malicious document forensic analysis
suite developed by Frank Boldewin that allows the digital
investigator to probe the structures and contents of a binary
format MS Office file for malicious artifacts—allowing for a
more complete profile of a suspect file.103
• The OfficeMalScanner suite of tools includes:
OfficeMalScanner (malicious MS Office file analysis
tool);
DisView (a lightweight disassembler);
MalHost-Setup (extracts shellcode and embeds it into a
host Portable Executable file); and
ScanDir (python script to scan an entire directory of
malicious documents)
Each tool will be examined in greater detail in this section.
• OfficeMalScanner has five different scanning options that
can be used to extract specific data from a suspect
file104:
Scanning
Option Purpose
Info
Parses and displays the OLE structures in the file and
saves located VB macrocode to disk.
Scans the a target file for generic shellcode patterns
using the following methods:
GetEIP
(Four methods) Scans for instances of
instructions to locate the EIP (instruction
pointer register, or program counter),
indicating the presence of embedded
shellcode.
Find
Kernel32
(Three methods) Scans for the presence
of instructions to identify the base
address of where the kernel32.dll image
is located in memory, a technique used
Scan
base is located in memory, a technique usedby shellcode to resolve addresses of
dependencies.
API
Hashing
Scans for the presence of instructions to
locate hash values of API function names
in memory, indicative of executable code.
Indirect
Function
calls
Searches for instructions that generate
calls to functions that are defined in other
files.
Suspicious
Strings
Scans for Windows function name strings
that are commonly found in malware.
Decryption
sequences
Scan searches for indicia of decryption
routines.
Embedded
OLE Data
Scans for unencrypted OLE compound
file signature. Identified OLE data is
dumped to disk (OfficeMalScanner
directory).
Function
prolog
Searches for code instructions relating to
the beginning of a function.
PE-File
Signature
Scans for unencrypted PE file signature.
Identified PE files are dumped to disk
(OfficeMalScanner directory).
brute
Scans for files encrypted with XOR and ADD with one-
byte key values of 0x00 through 0xFF. Each time a
buffer is decrypted, the scanner tries to identify PE
files or OLE data; if identified it is dumped to disk
(OfficeMalScanner directory).
debug
Scan in which located shellcode is disassembled and
displayed in textual disassembly view; located
embedded strings, OLE data and PE files are
displayed in a textual hexadecimal viewer.
inflate
Decompresses and extracts the contents of Office
Open XML formatted MS Office files (Office 2007–
Present) and places them into the examination
system’s /Temp directory.
• In addition to the information collected with the scanning
options, OfficeMalScanner rates scanned files on a
malicious index, scoring files based on four variables and
associated weighted values; the higher the malware index
score, the greater the number of malicious attributes
discovered in the file. As a result, the index rating can be
used as a triage mechanism for identifying files with
certain threshold values.105
Index Scoring
Executables 20
Code 10
Strings 2
OLE 1
Examine the file structure
• The structure of the suspect file can be quickly parsed
with OfficeMalScanner using the info switch (Figure
5.51). In addition to displaying the storages and streams,
t he info switch will extract any VB macro code
discovered in the file.
Figure 5.51 Parsing the structure of a suspect Word document
file with OfficeMalScanner
Locating and Extracting Embedded Executables
• After gaining an understanding of the suspect file’s
structure, examine the suspect file specimen for indicia of
shellcode and/or embedded executable files using the
scan command.
• If unencrypted shellcode, OLE or embedded executable
artifacts are discovered in the file, the contents are
automatically extracted and saved to disk. In the
example shown in Figure 5.52, an embedded OLE
artifact is discovered, extracted, and saved to disk.
Figure 5.52 Using the OfficeMalScanner scan command
• Scan the newly extracted file with the scan and info
commands in an effort to gather any further information
about the file.
• Many times, shellcode, OLE data, and PE files
embedded in malicious MS Office files are encrypted. In
an effort to locate these artifacts and defeat this
technique, use the OfficeMalScanner scan brute
command to scan the suspect file specimen with
common decryption algorithms. If files are detected with
this method, they are automatically extracted and saved
to disk, as shown in Figure 5.53.
Figure 5.53 OfficeMalScanner scan brute mode detecting and
extracting a PE embedded file
• Examine the extracted executable files through the file
profiling process and additional malware forensic
techniques discussed in Chapter 6 to gain further insight
about the nature, purpose, and functionality of the
program.
Examine Extracted Code
• To confirm your findings use the scan brute debug
command combination to display a textual hexadecimal
view output of the discovered and decrypted portable
executable file, as shown in Figure 5.54, below.
Figure 5.54 Examining an embedded PE file using
OfficeMalScanner
• The scan debug command can be used to examine
• The scan debug command can be used to examine
discovered (unencrypted) shellcode, PE, and OLE files
in greater detail.
Identified shellcode artifacts can be cursorily
disassembled and displayed in a textual disassembly
view.
Identified PE and OLE file artifacts are displayed in a
textual hexadecimal view.
• Debug mode is helpful for identifying the offset of
embedded shellcode in a suspect MS Office file and
gaining further insight into the functionality of the code, as
depicted in Figure 5.55.
Figure 5.55 Examining a malicious Word document file using
OfficeMalScanner in debug mode (Cont’d)
Locating and Extracting Shellcode with DisView and
MalHost-Setup
• If deeper probing of the shellcode is necessary, the
DisView (DisView.exe) utility—a lightweight
disassembler included with the OfficeMalScanner suite
—can further disassemble the target code.
• To use DisView, invoke the command against the target
file name and relevant memory offset. In Figure 5.56, the
offset 0x64cf was selected as it was previously identified
by the scan debug command as an offset with a
shellcode pattern (“Find kernel32 base” pattern).
Identifying the correct memory offset may require some
exploratory probing of different offsets.
Figure 5.56 Examining a suspect file with DisView
• Once the relevant offset is located, the shellcode can be
extracted and embedded into a host executable file
generated by MalHost-Setup (MalHost-Setup.exe).
• To use MalHost-Setup, invoke the command against the
target file, provide the name of the newly generated
executable file, and identify the relevant memory offset as
shown in Figure 5.57.
Figure 5.57 MalHost-Setup
• After the executable has been generated, it can be further
examined with using static and dynamic analysis tools
and techniques.
Profiling Microsoft Compiled HTML Help Files (CHM)
Although not as prevalent as PDF or Microsoft Office
document malware, Microsoft Compiled HTML Help Files
(CHM) can be used as a vector of attack, particularly as a
(CHM) can be used as a vector of attack, particularly as a
vehicle for Trojan Horse malware.
CHM files have a proprietary Microsoft file format. The
files typically consist of a series of HTML pages and associated
hyperlinks, compressed with LZX file compression.
• Attackers use malicious scripting to automatically invoke
a malicious file upon rendering of the help file contents.
• The malicious scripting often invokes a malicious binary,
such as a Windows executable or ActiveX control file,
that is surreptitiously embedded into the CHM file by the
attacker.
• In many instances the malicious scripting will be
hexadecimal encoded cipher text, adding an additional
layer of analysis.
• In addition to invoking a locally embedded binary,
scripting can also query an encoded URL to retrieve
additional malicious files.
CHM Profiling Process
The following steps can be taken to examine a suspect
CHM document:
Triage: Identify Indicators of Malice.
• Query the suspect CHM file for anomalous strings, such
as references to Windows Portable Executable files,
ActiveX control files, or other executable file types.
Often, these embedded artifacts are discoverable in
plaintext strings.
Discover Relevant Metadata
• Unlike other document types, the CHM file structure
does not store a vast amount of metadata. However,
meaningful metadata providing temporal and situational
meaningful metadata providing temporal and situational
context about the suspect CHM file can be acquired.
• Metadata can be extracted with exiftool,106 NLNZ
Metadata Extractor,107 and other utilities (Figure 5.58).
Figure 5.58 Querying a suspicious CHM file with exiftool
Examine the File Structure and Contents
• Decompile a suspect CHM file to look deeper into its file
structure and contents.
• CHM Decoder,108 a GUI-based utility, can be used to
decompile a suspect file—resulting in the extraction and
separation of file elements into individual files for closer
examination.
• To use CHM Decoder, select a target file, identify the
location where the output should be saved, and process
the file, as shown in Figure 5.59.
Figure 5.59 Decompiling a suspicious CHM file with CHM
Decoder
• Closer inspection of the extracted file content reveals a
suspicious executable file, “winhelp.exe,” which was
embedded within the CHM file specimen. File
identification and profiling can be conducted on this
executable file to gain further insight into its nature and
purpose. Further, if the file is indeed malicious, deeper
dynamic and static analysis should be conducted to
determine the scope of its functionality.
Locating Suspect Scripts
• Malicious executables concealed inside of CHM files are
typically triggered as a linked or an embedded resource
through HTML scripting. Be sure to examine HTML
files extracted as a result of decompiling a CHM file.
• In examining the extracted file, AOC2007.html, depicted
i n Figure 5.60, the triggering mechanism of the
winhelp.exe file is discovered:
Figure 5.60 Executable file triggering mechanism within HTML
Identifying and Decoding Obfuscated Scripts
• It is not uncommon for attackers to conceal the triggering
method by obfuscating the HTML scripting responsible
for invoking the embedded executable file. Often, in
malicious CHM files, the obfuscation method is
hexadecimal cipher text encoded in JavaScript unescape
or escape functions.
• This obfuscation method is also used to conceal malicious
VBScript embedded within HTML, which invokes
requests for malicious files hosted on remote URLs.
• I n Figure 5.61, the contents of a decompiled suspect
CHM file reveal a suspicious ActiveX control file,
“xpreload.ocx,” and the triggering mechanism (in clear
text) within the page.html file. The decrypted
hexadecimal cipher text reveals a call for the download
of additional malware from a remote URL.
Figure 5.61 Obfuscated scripting within HTML
Conclusion
• Preliminary static analysis in a Windows environment of a
suspect file can yield a wealth of valuable information
that will shape the direction of future dynamic and more
complete static analysis of the file.
• Through a logical, step-by-step file identification and
profiling process, and using a variety of different tools
and approaches, a meaningful file profile can be
ascertained. There are a wide variety of tools for
conducting a file profile, many of which were
demonstrated in this chapter.
• Independent of the tools used and the specific suspect file
examined, there is a need for a file profiling methodology
to ensure that data are acquired in as consistent and
repeatable a manner as possible. For forensic purposes,
it is also necessary to maintain detailed documentation of
the steps taken on a suspect file. Refer to the Field
Notes at the end of this chapter for documentation
guidance.
• The methodology in this chapter provides a robust
foundation for the forensic identification and profiling of a
target file. This methodology is not intended as a
checklist and may need to be altered for certain
situations, but it does increase the chances that much of
the relevant data will be obtained to build a file profile.
Furthermore, this methodology and the supporting
documentation will strengthen malware forensics as a
source of evidence, enabling an objective observer to
source of evidence, enabling an objective observer to
evaluate the reliability and accuracy of the file profiling
process and acquired data.
Pitfalls to Avoid
Submitting sensitive files to online anti-virus scanning
services or analysis sandboxes
Do not submit a suspicious file that is the crux of a sensitive
investigation (i.e., circumstances in which disclosure of an
investigation could cause irreparable harm to a case) to online
analysis resources such as anti-virus scanning services or
sandboxes in an effort not to alert the attacker.
By submitting a file to a third-party Web site, you are
no longer in control of that file or the data associated
with that file. Savvy attackers often conduct extensive
open source research and search engine queries to
determine if their malware has been detected.
The results relating to a submitted file to an online
malware analysis service are publicly available and easily
discoverable—many portals even have a search function.
Thus, as a result of submitting a suspect file, the attacker
may discover that his malware and nefarious actions
have been discovered, resulting in the destruction of
evidence and potentially damaging your investigation.
Conducting an incomplete file profile
An investigative course of action should not be based upon
an incomplete file profile.
Fully examine a suspect file in an effort to render an
informed and intelligent decision about what the file is,
how it should be categorized or analyzed, and in turn,
how to proceed with the larger investigation.
Take detailed notes during the process, not only about
the suspicious file but also about each investigative step
taken. Consult the Field Notes located in the
Appendices in this chapter for additional guidance and a
structured note taking format.
Relying upon file icons and extensions without further
context or deeper examination
Neither the file icon nor file extension associated with a
suspect file should be presumed to be accurate.
In conducting digital investigations, never presume that a
file extension is an accurate representation. File
camouflaging, or a technique that obfuscates the true
nature of a file by changing and hiding file extensions in
locations with similar real file types, is a trick commonly
used by hackers and bot herders to avoid detection of
malicious code distribution.
Similarly, the file icon associated with a file can easily be
modified by an attacker to appear like a contextually
appropriate or innocuous file. The file icon associated
with a Windows Portable Executable file can be inserted
or modified in the file Resources section.
Solely relying upon anti-virus signatures or third-party
analysis of a “similar” file specimen
Although anti-virus signatures can provide insight into the
nature of identified malicious code, they should not be solely
relied upon to reveal the purpose and functionality of a suspect
program. Conversely, the fact that a suspect file is not identified
by anti-virus programs does not mean that it is innocuous.
Third-party analysis of a “similar” file specimen can be
helpful guidance; it should not be considered dispositive in all
circumstances.
Anti-virus signatures are typically generated based upon
specific data contents or patterns identified in malicious
code. Signatures differ from heuristics—identifiable
malicious behavior or attributes that are non-specific to a
particular specimen (commonly used to detect zero-day
threats that have yet to be formally identified with a
signature).
Anti-virus signatures for a particular identified threat
vary between anti-virus vendors,109 but many times,
certain nomenclature, such as a malware classification
descriptor, is common across the signatures (e.g., the
words “Trojan,” “Dropper,” and “Backdoor” may be
used in many of the vendor signatures). These
classification descriptors may be a good starting point or
corroborate your findings, but should not be considered
dispositive; rather, they should be taken into
consideration toward the totality of the file profile.
Conversely, if there are no anti-virus signatures
associated with a suspect file, it may mean simply that a
signature for the file has not been generated by the
vendor of the anti-virus product, or that the attacker has
successfully (albeit likely temporarily) obfuscated the
successfully (albeit likely temporarily) obfuscated the
malware to thwart detection.
Third-party analysis of a similar malware specimen by a
reliable source can be an incredibly valuable resource,
and may even provide predictors of what will be
discovered in your particular specimen. Although this
correlative information should be considered in the
totality of your investigation, it should not replace
thorough independent analysis.
Examining a suspect file in a forensically unsound
laboratory environment
Suspect files should never be examined in a production
environment or on a system that has not been forensically
baselined to ensure that it is free of misleading artifacts.
Forensic analysis of potentially damaging code requires
a safe and secure lab environment. After extracting a
suspicious file from a victim system, place the file on an
isolated or “sandboxed” system or network, to ensure
that the code is contained and unable to connect to or
otherwise affect any production system.
Even though only a cursory static analysis of the code is
contemplated at this point of the investigation, executable
files nonetheless can be accidentally executed fairly
easily, potentially resulting in the contamination of or
damage to production systems.
It is strongly encouraged to examine malicious code
specimens in a predesigned and designated malicious
code laboratory, which can even be a field deployable
laptop computer. The lab system should be revertible,
that is, using a virtualization or host-based software
solution that allows the digital investigator to restore the
solution that allows the digital investigator to restore the
state of the system to a designated baseline
configuration.
The baseline configuration in which specimens are
examined should be thoroughly documented and free
from artifacts associated with other specimens, resulting
in forensic unsoundness, false positives, and mistaken
analytical conclusions.
Basing conclusions upon a file profile without additional
context or correlation
Do not make investigative conclusions without considering the
totality of the evidence.
A file profile must be reviewed and considered in
context with all of the digital and network-based
evidence collected from the incident scene.
Navigating to malicious URLS and IP addresses
Exercise caution and discretion in visiting URLs and IP
addresses embedded in, or associated with, a target malware
specimen.
These resources might be an early warning and
indicator capability employed by the attacker to notify
him/her that the malware is being examined.
Logs from the servers hosting these resources are of
great investigative value (i.e., other compromised sites,
visits from the attacker[s], etc.) to law enforcement,
Computer Emergency Response Teams (CERTs), and
Computer Emergency Response Teams (CERTs), and
other professionals seeking to remediate the malicious
activity and identify the attacker(s). Visits by those
independently researching the malware will leave
network impression evidence in the logs.
Selected Readings
Papers
1. Blonce A, Filiol E. Portable Document File (PDF)
Security Analysis and Malware Threats 2008;In:
http://www.blackhat.com/presentations/bh-europe-
08/Filiol/Presentation/bh-eu-08-filiol ; 2008.
2. Boldewin F. Analyzing MS Office Malware with
OfficeMalScanner 2009;In:
http://www.reconstructer.org/papers/Analyzing%20MSOffice%20malware%20with%20OfficeMalScanner.zip
; 2009.
3. Boldewin F. New Advances in MS Office Malware
Analysis 2008;In:
http://www.reconstructer.org/papers/New%20advances%20in%20Ms%20Office%20malware%20analysis
; 2008.
4. Dan B. Methods for Understanding and Analyzing
Targeted Attacks with Office Documents 2008;In:
http://www.blackhat.com/presentations/bh-jp-08/bh-
jp-08-Dang/BlackHat-Japan-08-Dang-Office-
Attacks ; 2008.
5. Raynal F, Delugré G, Aumaitre D. Malicious PDF
Origamis Strike Back 2010;In: www.security-
labs.org/fred/docs/hack.lu09-origamis-strike-
back ; 2010.
6. Raynal F, Delugré G. Malicious Origami in PDF
00E9;, 2008;In: www.security-
labs.org/fred/docs/pacsec08/pacsec08-fr-gd-full ;
00E9;, 2008.
7. Stevens D. Malicious PDF Documents Explained. IEEE
Security & Privacy Magazine. 2011;Vol. 9.
8. Stevens, D. (2010). Malicious PDF Analysis E-book. In
the Proceedings of BruCON, 2010,
http://didierstevens.com/files/data/malicious-pdf-
analysis-ebook.zip.
9. Stevens D. Malicious PDF Documents. ISSA Journal
2010;In:
https://www.issa.org/Library/Journals/2010/July/Stevens-
Malicious%20PDF%20Documents ; 2010.
10. Stevens D. Stepping Through a Malicious PDF
Document. HITB Magazine 2010;In:
http://magazine.hitb.org/issues/HITB-Ezine-Issue-
004 ; 2010.
11. Stevens D. Anatomy of Malicious PDF Documents.
HAKIN9 IT Security Magazine 2009.
12. Tzermias Z, et al. Combining Static and Dynamic
Analysis for the Detection of Malicious Documents
2011.
Online Resources
1. Holz T. Analyzing Malicious PDF Files 2009;In:
http://honeyblog.org/archives/12-Analyzing-
Malicious-PDF-Files.html ; 2009.
2. Selvaraj K, Gutierres NF. The Rise of PDF Malware
2010;In:
http://www.symantec.com/connect/blogs/rise-pdf-
malware ; 2010;In:
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/the_rise_of_pdf_malware
; 2010.
3. Zdrnja B. Sophisticated, Targeted Malicious PDF
Documents Exploiting CVE-2009-4324 2010;In:
http://isc.sans.edu/diary.html?storyid=7867 ; 2010.
4. Zeltser L. Analyzing Malicious Documents Cheat
Sheet 2010;In: http://zeltser.com/reverse-
malware/analyzing-malicious-documents.html ;
2010;In: http://zeltser.com/reverse-
malware/analyzing-malicious-document-files ;
2010.
Technical Specifications
Microsoft Office File Formats:
http://msdn.microsoft.com/en-us/library/cc313118.aspx
Microsoft Office File Format Documents:
http://msdn.microsoft.com/en-us/library/cc313105.aspx
Microsoft Office Binary (doc, xls, ppt) File Formats:
http://www.microsoft.com/interop/docs/officebinaryformats.mspx
Microsoft Compound Binary File Format:
http://msdn.microsoft.com/en-
us/library/dd942138%28PROT.13%29.aspx
us/library/dd942138%28PROT.13%29.aspx
http://download.microsoft.com/download/a/e/6/ae6e4142-
aa58-45c6-8dcf-a657e5900cd3/%5BMS-
CFB%5D
Microsoft Word ( ) Binary File Format:
http://msdn.microsoft.com/en-us/library/cc313153.aspx
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
DOC%5D
http://download.microsoft.com/download/5/0/1/501ED102-
E53F-4CE0-AA6B-B0F93629DDC6/Word97-
2007BinaryFileFormat(doc)Specification
Microsoft PowerPoint (.ppt) Binary File Format:
http://msdn.microsoft.com/en-us/library/cc313106.aspx
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
PPT%5D
http://download.microsoft.com/download/5/0/1/501ED102-
E53F-4CE0-AA6B-B0F93629DDC6/PowerPoint97-
2007BinaryFileFormat(ppt)Specification
Microsoft Excel (.xls) Binary File Format:
http://msdn.microsoft.com/en-us/library/cc313154.aspx
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
XLS%5D
http://download.microsoft.com/download/5/0/1/501ED102-
E53F-4CE0-AA6B-B0F93629DDC6/Excel97-
2007BinaryFileFormat(xls)Specification
Portable Document Format (PDF):
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008
1 For more information about Miss Identify, go to
http://missidentify.sourceforge.net/.
2 For more information about MWSnap, go to
http://www.mirekw.com/winfreeware/mwsnap.html.
3 For more information on the MD5 algorithm, go to
http://www.faqs.org/rfcs/rfc1321.html.
http://www.faqs.org/rfcs/rfc1321.html.
4 For more information on the SHA1 algorithm, go to
http://www.faqs.org/rfcs/rfc3174.html.
5 For more information about md5deep, go to
http://md5deep.sourceforge.net.
6 For more information about HashMyFiles, go to
http://www.nirsoft.net/utils/hash_my_files.html.
7 For more information about ssdeep, go to
http://ssdeep.sourceforge.net.
8 For more information about bytehist, go to
http://www.cert.at/downloads/software/bytehist_en.html.
9 For more information about BinVis, go to
http://code.google.com/p/binvis/.
10 For more information about MiniDumper, go to
http://mark0.net/soft-minidumper-e.html.
11 For more information about the File Identifier tool, go to
http://www.optimasc.com/products/fileid/index.html.
12 For more information about the Optima SC magic file,
go to http://www.optimasc.com/products/fileid/magic-
format and www.magicdb.org.
13 For more information about TrID, go to
http://mark0.net/soft-trid-e.html.
14 For a list of the file signatures and definitions, go to
http://mark0.net/soft-trid-deflist.html.
15 For more information about TrIdScan, go to
http://mark0.net/soft-tridscan-e.html.
16 For more information about TrIDNet, go to
http://mark0.net/soft-tridnet-e.html.
17 For more information about Avast, go to
http://www.avast.com/free-antivirus-download.
18 For more information about AGV, go to
http://free.avg.com/us-en/company-profile.
19 For more information Avira AntiVir Personal, go to
http://www.free-av.com/.
20 For more information about ClamWin, go to
http://www.clamwin.com.
21 For more information about F-Prot, go to http://www.f-
prot.com/products/home_use/linux/.
22 For more information about BitDefender, go to
http://www.bitdefender.com/PRODUCT-14-en–
BitDefender-Free-Edition.html.
BitDefender-Free-Edition.html.
23 For more information about Panda, go to
http://research.pandasecurity.com/free-commandline-
scanner/.
24 http://msdn.microsoft.com/microsoft.com/en-
us/library/aa383749.aspx.
25 http://search.microsoft.com/AdvancedSearch.aspx?
mkt=en-US&qsc0=0&FORM=BAFF.
26 One example of a greetz can be found inside the Zotob
worm code, in the phrase “Greetz to good friend
Coder” (http://www.f-
secure.com/weblog/archives/archive-082005.html).
27 For more information about strings.exe, go to
http://technet.microsoft.com/en-
us/sysinternals/bb897439.
28 For more information about BinText, go to
http://www.mcafee.com/us/downloads/free-
tools/bintext.aspx.
29 For more information about DUMPBIN, go to
http://support.microsoft.com/kb/177429.
30 For more information about Visual Studio, go to
http://www.microsoft.com/express/Downloads/#http://www.microsoft.com/express/Downloads/#
(Visual Studio Express version) and
http://www.microsoft.com/visualstudio/en-
us/products/2010-editions/professional/overview
(Visual Studio Professional).
31 For more information about dumpbinGUI, go to
http://www.cheztabor.com/dumpbinGUI/index.htm.
32 For more information about Dependency Walker, go to
http://www.dependencywalker.com/.
33 For more information about exiftool, go to
http://www.sno.phy.queensu.ca/~phil/exiftool/.
34 For more information about GT2, go to
http://philip.helger.com/gt/index.php.
35 For more information about PEiD, go to
http://www.peid.info.
36 For more information about Language 2000, go to
http://farrokhi.net/language/language.zip.
37 For more information about pestat, go to
http://www.rnicrosoft.net/.
38 For more information about EXE Explorer, go to
38 For more information about EXE Explorer, go to
http://www.mitec.cz/exe.html.
39 For a list of Language Identifier Codes, go to
http://msdn.microsoft.com/en-us/library/aa912040.aspx.
40 For a list of Character Codes, go to
http://msdn.microsoft.com/en-us/library/cc195051.aspx.
41 For more information about PE Explorer, go to
http://www.heaventools.com/overview.htm.
42 For a good discussion on file packing programs and
obfuscation code analysis, see Lenny Zeltser’s SANS
Forensics 610, Reverse-Engineering Malware:
Malware Analysis Tools and Techniques, 2010.
43 For more information about PEiD, go to http://peid.info/.
44 For more information on PEiD plug-ins, go to
http://www.peid.info/plugins/.
45 Lyda, R., and Hamrock, J. (2007). Using entropy
analysis to find encrypted and packed malware,
IEEE Security and Privacy (S&P).
46 For more information about Mandiant Red Curtain, go
to
http://www.mandiant.com/products/free_software/red_curtain/.
47 For more information about PE Detective, go to
http://www.ntcore.com/pedetective.php.
48 For more information about RDG, go to
http://www.rdgsoft.8k.com/.
49 For more information about pefile, go to
http://code.google.com/p/pefile/.
50 To obtain a copy of packerid.py, go to
http://handlers.dshield.org/jclausing/packerid.py.
51 http://www.peid.info/BobSoft/Downloads.html.
52
http://research.pandasecurity.com/blogs/images/userdb.txt.
53 For more information about Anubis, go to
http://anubis.iseclab.org/.
54 For more information about Yet Another Binder, go to
http://gsa.ca.com/pest/pest.aspx?ID=453073945.
55 http://msdn.microsoft.com/en-
us/windows/hardware/gg463119.aspx.
56 Some of the foundational whitepapers on the subject are
authored by Matt Pietrek, including: Peering Inside the
PE: A Tour of the Win32 Portable Executable File
Format (http://msdn.microsoft.com/en-
us/library/ms809762.aspx) and An In-Depth Look into
the Win32 Portable Executable File Format
(http://technet.microsoft.com/en-
us/library/bb985992.aspx).
57
http://www.openrce.org/reference_library/files/reference/PE%20Format .
58 http://www.wheaty.net/pedump.zip.
59 For more information about PEView, go to
http://www.magma.ca/~wjr/.
60 For more information about Anywhere PE Viewer, go to
http://www.ucware.com/apev/index.htm.
61 For more information about CFF Explorer, go to
http://www.ntcore.com/exsuite.php.
62 For more information about the
IMAGE_NT_HEADERS structure, go to
http://msdn.microsoft.com/en-
us/library/ms680336%28v=vs.85%29.aspx.
63 For more information about the
IMAGE_FILE_HEADER structure, go
http://msdn.microsoft.com/en-
us/library/ms680313%28v=vs.85%29.aspx.
64 Microsoft Portable Executable and Common Object File
Format Specification, Section 2.3, Revision 8.2—
September 21, 2010.
65 For more information about the
IMAGE_OPTIONAL_HEADER structure, go to
http://msdn.microsoft.com/en-
us/library/ms680339%28v=vs.85%29.aspx.
66 Microsoft Portable Executable and Common Object File
Format Specification, Section 2.4, Revision 8.2—
September 21, 2010.
67 For detailed information about the Portable Document
Format, see the Adobe Portable Document File
Specification (International Standard ISO 32000-
1:2008),
http://www.adobe.com/devnet/pdf/pdf_reference.html.
68 Portable Document Format Specification (International
Standard ISO 32000-1:2008), Section 7.3.8.1.
69 Portable Document Format Specification (International
Standard ISO 32000-1:2008), Section 7.5.4, Note 1.
70 Portable Document Format Specification (International
70 Portable Document Format Specification (International
Standard ISO 32000-1:2008), Section 7.5.5.
71 Further detail can be found in the PDF specification
documentation: Portable Document Format
Specification (International Standard ISO 32000-
1:2008); International Organization for Standardization
(ISO) 2008; Adobe Extensions to ISO 32000-1:2008,
Level 5; Adobe Supplement to the ISO 32000-1:2008,
Exension Level 3.
72 For more information about Origami, go to
http://code.google.com/p/origami-pdf/.
73 For more information about jsunpack-n, go to
https://code.google.com/p/jsunpack-n/.
74 For more information about Origami, go to
https://code.google.com/p/origami-pdf/.
75 For more information about SpiderMonkey, go to
http://www.mozilla.org/js/spidermonkey/.
76 For more information about Didier Stevens’ version of
SpiderMonkey, go to
http://blog.didierstevens.com/programs/spidermonkey/.
77 For an example of this paradigm, see “PDF file loader to
extract and analyze shellcode,”
http://www.hexblog.com/?p=110.
78 Heap spraying works by allocating multiple objects
containing the attacker’s exploit code in the program’s
heap—or the area of memory dynamically allocated for
the program during runtime. Ratanaworabhan, P.,
Livshits, B., and Zorn, B. (2008), NOZZLE: A
Defense Against Heap-spraying Code Injection
Attacks, SSYM’09 Proceedings of the 18th conference
on USENIX security symposium.
79 For an example of this infection paradigm, see “Explore
the CVE-2010-3654 matryoshka,”
http://www.computersecurityarticles.info/antivirus/explore-
the-cve-2010-3654-matryoshka/.
80 For more information about shellcode2exe, including its
implementation in other tools, see
http://winappdbg.sourceforge.net/blog/shellcode2exe.py;
http://breakingcode.wordpress.com/2010/01/18/quickpost-
converting-shellcode-to-executable-files-using-
inlineegg/; (as implemented in PDF Stream Dumper,
http://sandsprite.com/blogs/index.php?uid=7&pid=57);
http://sandsprite.com/blogs/index.php?uid=7&pid=57);
and (as implemented in the Malcode Analysts Pack,
http://labs.idefense.com/software/malcode.php#more_malcode+analysis+pack).
81 http://zeltser.com/reverse-
malware/ConvertShellcode.zip.
82 http://sandsprite.com/shellcode_2_exe.php.
83 For more information about PDF Dissector, go to
http://www.zynamics.com/dissector.html.
84 For more information about PDF Stream Dumper, go to
http://sandsprite.com/blogs/index.php?uid=7&pid=57.
85 For more information about PDFubar, go to
http://code.google.com/p/pdfubar/.
86 For more information about Malzilla, go to
http://malzilla.sourceforge.net/.
87 http://msdn.microsoft.com/en-
us/library/cc313105%28v=office.12%29.aspx.
88
http://www.microsoft.com/interop/docs/officebinaryformats.mspx;
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-
C7B2C1D997DB/OfficeFileFormatsProtocols.zip.
89
http://download.microsoft.com/download/0/B/E/0BE8BDD7-
E5E8-422A-ABFD-
4342ED7AD886/WindowsCompoundBinaryFileFormatSpecification .
90 The Microsoft Word Binary File Format specifications
can be found at
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
DOC%5D and at
http://download.microsoft.com/download/5/0/1/501ED102-
E53F-4CE0-AA6B-B0F93629DDC6/Word97-
2007BinaryFileFormat(doc)Specification .
91 http://msdn.microsoft.com/en-
us/library/dd926131%28office.12%29.aspx.
92 http://msdn.microsoft.com/en-
us/library/dd949344%28v=office.12%29.aspx.
93
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
OSHARED%5D .
94 The Microsoft PowerPoint Binary File Format
94 The Microsoft PowerPoint Binary File Format
specifications can be found at
http://msdn.microsoft.com/en-
us/library/cc313106%28v=office.12%29.aspx;
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
PPT%5D ; and
http://download.microsoft.com/download/5/0/1/501ED102-
E53F-4CE0-AA6B-B0F93629DDC6/PowerPoint97-
2007BinaryFileFormat(ppt)Specification .
95 The Microsoft Excel Binary File Format specification
can be found at http://msdn.microsoft.com/en-
us/library/cc313133%28v=office.12%29.aspx;
http://download.microsoft.com/download/2/4/8/24862317-
78F0-4C4B-B355-C7B2C1D997DB/%5BMS-
XLSB%5D .
96 The Office Open XML file format specification
documents can be found at
http://msdn.microsoft.com/en-
us/library/aa338205%28office.12%29.aspx.
97 For more information about WinRaR, go to
http://www.rarlab.com/.
98 For more information about Unzip, go to
http://www.info-zip.org/.
99 For more information about 7-Zip, go to http://www.7-
zip.org/.
100 For more information about officecat, go to
http://www.snort.org/vrt/vrt-resources/officecat.
101 For more information about OffVis, go to
http://blogs.technet.com/b/srd/archive/2009/09/14/offvis-
updated-office-file-format-training-video-created.aspx;
http://go.microsoft.com/fwlink/?LinkId=158791.
102 For more information about exiftool, go to
http://www.sno.phy.queensu.ca/~phil/exiftool/.
103 For more information about OfficeMalScanner, go to
http://www.reconstructer.org/code.html.
104 Boldewin, F. (2009). Analyzing MS Office Malware
with OfficeMalScanner,
http://www.reconstructer.org/papers/Analyzing%20MSOffice%20malware%20with%20OfficeMalScanner.zip
and Boldewin, F. (2009). New Advances in MS Office
Malware Analysis,
http://www.reconstructer.org/papers/New%20advances%20in%20Ms%20Office%20malware%20analysis
105 Boldewin, F., 2009, Analyzing MS Office Malware
with OfficeMalScanner, p. 8.
106 For more information about exiftool, go to
http://www.sno.phy.queensu.ca/~phil/exiftool/.
107 For more information about the National Library of
New Zealand (NLNZ) Metadata Extractor, go to
http://meta-extractor.sourceforge.net/.
108 For more information about CHM Decoder, go to
http://www.gridinsoft.com/chm.php.
109 The wide variety of anti-virus signature names for
certain threats caused the Mitre Corporation to create
the Common Malware Enumeration project “[t]o
provide single, common identifiers to new virus threats
and to the most prevalent virus threats in the wild to
reduce public confusion during malware incidents.” See
http://cme.mitre.org/index.html.
Chapter 6
Analysis of a Malware Specimen
Solutions in this chapter:
• Goals
• Guidelines for Examining a Malicious File Specimen
• Establishing the Environment Baseline
• Pre-execution Preparation: System and Network
Monitoring
• Execution Artifact Capture: Digital Impression and Trace
Evidence
• Executing the Malware Specimen
• Execution Trajectory Analysis: Observing Network,
Process, API, File System, and Registry Activity
• Automated Malware Analysis Frameworks
• Online Malware Analysis Sandboxes
• Defeating Obfuscation
• Embedded Artifacts Revisited
• Interacting with and Manipulating the Malware Specimen:
Exploring and Verifying Specimen Functionality and
Purpose
• Event Reconstruction and Artifact Review: Post-run Data
Analysis
• Digital Virology: Advanced Profiling through Malware
Taxonomy and Phylogeny
• Conclusion
• Conclusion
Introduction
Through the file profiling methodology, tools, and techniques
discussed in Chapter 5, substantial insight into the dependencies,
strings, anti-virus signatures, and metadata associated with a
suspect file can be gained, and then used to shape a predictive
assessment as to the specimen’s nature and functionality.
Building on that information, this chapter will further explore the
nature, purpose, and functionality of a suspect program by
conducting a dynamic and static analysis of the binary. Recall
that dynamic or behavioral analysis involves executing the
code and monitoring its behavior, interaction, and effect on the
host system, whereas static analysis is the process of analyzing
executable binary code without actually executing the file. During
the course of examining suspect programs in this chapter, we will
demonstrate the importance and inextricability of using both
dynamic and static analysis techniques to gain a better
understanding of a malicious code specimen. As the specimens
examined in this chapter are pieces of actual malicious code
“from the wild,” certain references such as domain names, IP
addresses, company names, and other sensitive identifiers are
obfuscated for privacy and security purposes.
Goals
While analyzing a suspect program, consider the following:
• What is the nature and purpose of the program?
• How does the program accomplish its purpose?
• How does the program interact with the host system?
• How does the program interact with the network?
• How does the attacker interact (command/control/etc.)
with the program?
• What does the program suggest about the sophistication
level of the attacker?
• Is there an identifiable vector of attack the program uses
to infect a host?
• What is the extent of the infection or compromise on the
system or network?
Though difficult to answer all of these questions—as
many times key pieces to the puzzle such as additional files or
network-based resources required by the program are no longer
available to the digital investigator—the methodology often paves
the way for an overall better understanding about the suspect
program.
When working through this material, remember that
When working through this material, remember that
“reverse-engineering” and some of the techniques discussed in
this chapter fall within the proscriptions of certain international,
federal, state, or local laws. Similarly, remember also that some
of the referenced tools may be considered “hacking tools” in
certain jurisdictions, and are subject to similar legal regulation or
use restriction. Please refer to Chapter 4 for more details, and
consult with counsel prior to implementing any of the techniques
and tools discussed in these and subsequent chapters.
Analysis Tip
Safety First
Forensic analysis of potentially damaging code requires a safe
and secure lab environment. After extracting a suspicious file
from a system, place the file on an isolated or “sandboxed”
system or network to ensure that the code is contained and
unable to connect to or otherwise affect any production system.
Similarly, ensure that the sandboxed laboratory environment is
not connected to the Internet, local area networks (LANs), or
other non-laboratory systems, as the execution of malicious
programs can potentially result in the contamination of, or
damage to, other systems.
Guidelines for Examining a
Malicious File Specimen
This chapter endeavors to establish a general guideline of the
tools and techniques that can be used to examine malicious
document files and executable binaries in a Windows
environment. However, given the seemingly endless number of
malicious code specimens now generated by attackers, often
with varying functions and purposes, flexibility and adjustment of
the methodology to meet the needs of each individual case is
most certainly necessary. Some of the basic precepts we will
explore include:
• Establishing the environment baseline
• Pre-execution preparation
• Executing the malicious code specimen
• System and network monitoring
• Environment emulation and adjustment
• Process spying
• Defeating obfuscation
• Disassembling
• Advanced PE analysis
• Interacting with and manipulating the malware specimen
• Interacting with and manipulating the malware specimen
• Exploring and verifying specimen functionality and
purpose
• Event reconstruction and artifact review
• Digital virology: Advanced profiling through malware
classification and phylogeny
Establishing the Environment
Baseline
There are a variety of malware laboratory
configuration options. In many instances, a specimen can
dictate the parameters of the lab environment, particularly
if the code requires numerous servers to fully function, or
more nefariously, employs anti-virtualization code to
stymie the digital investigator’s efforts to observe the code
in a virtualized host system.
Use of virtualization is particularly helpful during the
behavioral analysis of a malicious code specimen, as the analysis
often requires frequent stops and starts of the malicious program
in order to observe the nuances of the program’s behavior.
• A common and practical malware lab model will utilize
VMware (or another virtualization of preference, such as
VirtualBox)1 hosts to establish an emulated “infected”
system (typically Windows XP).2
• A “server” system (typically Linux) is used to supply any
hosts or services needed by the malware, such as Web
server, mail server, or IRC server.
• And if needed, a “monitoring” system (typically Linux)
that has network monitoring software available to
intercept network traffic to and from the victim system is
used.
Investigative Considerations
• Prior to taking a system “snapshot” (discussed in the
following section), install and configure all of the utilities
on the system that will likely be used during the course of
analysis. By applying this methodology, the created
baseline system environment can be repeatedly reused as
a “template.”
• Ideally, the infected system can be monitored locally, to
reduce the digital investigator’s need to monitor multiple
systems during an analysis session. However, many
malware specimens are “security conscious” and use
anti-forensic techniques, such as scanning the names of
running processes to identify and terminate known
security tools, including network sniffers, firewalls, anti-
virus software, and other applications.3
System “Snapshots”
Before beginning an examination of the malicious code
specimen, take a snapshot of the system that will be used as the
“victim” host on which the malicious code specimen will be
executed.
• Implement a utility that allows comparison of the state of
the system after the code is executed to the pristine or
original snapshot of the system state.
• In the Windows environment, there are two kinds of
utilities that we can implement that provide for this
functionality: host integrity monitors and installation
monitors.
Host Integrity Monitors
Host Integrity or File Integrity monitoring tools create a system
snapshot in which subsequent changes to objects residing on the
system will be captured and compared to the snapshot. These
tools typically monitor changes made to the file system, Registry,
and .ini files. Some commonly used host integrity system tools for
Windows include Winalysis,4WinPooch,5 RegShot (Figure
6.1),6 FingerPrint v2.1.3,7 and ESET SysInspector,8 which are
discussed in greater detail in the Tool Box section at the end of
the chapter and on the companion Web site.9
Figure 6.1 Configuring a snapshot with Regshot
Installation Monitors
Another utility commonly used by digital investigators to
identify changes made to a system as a result of executing an
unknown binary specimen is installation monitors (also known
as installation managers). Unlike host integrity systems, which
are intended to generally monitor all system changes, installation
monitoring tools serve as an executing or loading mechanism for
a target suspect program and track all of the changes resulting
from the execution or installation of the target program—typically
file system, Registry, and .ini file changes. Some examples of
installation monitors include InstallWatch,10 InCrtl5,11
InstallSpy,12 and SysAnalyzer (Figure 6.2).13
Figure 6.2 SysAnalyzer
The first objective in establishing the baseline system
environment is to create a system snapshot so that subsequent
changes to the system will be recorded.
changes to the system will be recorded.
• During this process, the host integrity monitor scans the
Registry and file system, creating a snapshot of the
system in its normal (pristine) system state.
• The resulting snapshot will serve as the baseline system
“template” to compare against subsequent system
changes resulting from the execution of a suspect
program on the host system (see Figure 6.3).
Figure 6.3 Creating a system snapshot with InstallSpy
• After creating a system snapshot, the digital investigator
can invoke the host integrity monitoring software to scan
the file system and Registry for changes that have
manifested on the system as a result of executing the
suspect program.
• Although the detail and structure of reports differ, each of
• Although the detail and structure of reports differ, each of
the above referenced monitoring utilities compile and
generate a report of the results after identifying the
changes.
Pre-Execution Preparation:
System and Network Monitoring
A valuable way to learn how a malicious code
specimen interacts with a victim system, and identify risks
that the malware poses to the system, is to monitor certain
aspects of the system during the runtime of the specimen.
Tools that monitor the host system and network activity
should be deployed prior to execution of a subject specimen and
during the course of the specimen’s runtime. In this way, the
tools will capture the activity of the specimen from the moment it
is executed. On a Windows system, there are five areas to
monitor during the dynamic analysis of malicious code specimen:
• Processes
• The file system
• The Registry
• Network activity
• API calls
To effectively monitor these aspects of an infected
malware lab system, use both passive and active monitoring
techniques (see Figure 6.4).
Figure 6.4 Implementation of passive and active monitoring
techniques
Analysis Tip
Document your “Digital Footprints”
The digital investigator should interact with the victim malware
lab system to the smallest degree practicable in an effort to
minimize “digital footprints” in collected data. Similarly, the digital
investigator should document any action taken that could result in
data that will manifest in the monitoring process, particularly if
another investigator or party will be reviewing the monitoring
output. For example, if, during the course of monitoring, the
digital investigator launches calc.exe to check a hexadecimal
value, it should be noted. Documenting investigative steps
minimizes perceived anomalies and distracting data that could
complicate analysis.
Passive System and Network Monitoring
Passive system monitoring involves the deployment of a
Passive system monitoring involves the deployment of a
host integrity or installation monitoring utility. These
utilities run in the background during the runtime of a
malicious code specimen, collecting information related to
the changes manifesting on the host system attributable to
the specimen.
After the specimen is run, a system integrity check is
performed by the implemented host integrity or installation
monitoring utility, which compares the system state before and
after execution of the specimen.
Active System and Network Monitoring
Active system monitoring involves running certain
utilities to gather real-time data relating to both the
behavior of the malicious code specimen and the resulting
impact on the infected host. The tools deployed will
capture process information, file system activity, API calls,
Registry, and network activity.
Processes Monitoring
After executing the suspect program, examine the properties
of the resulting process and other processes running on the
infected system. To obtain context about the newly created
suspect process, pay close attention to:
• The resulting process name and process identification
number (PID)
• The system path of the executable program responsible
for creating the process
for creating the process
• Any child processes related to the suspect process
• Modules loaded by the suspect program
• Associated handles
• Interplay and relational context to other system state
activity, such as network traffic and Registry changes
A valuable tool for gathering process information in a
clean, easy to navigate GUI is Process Explorer.14 As shown in
Figure 6.5, during the analysis of a malicious PDF file, spawned
processes are identified with Process Explorer; by right-clicking
on a target process and selecting “Properties,” deeper analysis
into the process can be conducted.
Figure 6.5 Monitoring process activity with Process Explorer
• Other utilities that similarly can gather these details include
CurrProcess,15 ProcessActivityView,16 Explorer
Suite/Task Explorer,17 Process Hacker,18 PrcView,19
and MiTec Process Viewer.20
and MiTec Process Viewer.20
File System Monitoring
In addition to examining process information, it is important to
also examine real-time file system activity on an infected system
during dynamic analysis.
• The de facto tool used by many digital investigators is
Process Monitor (ProcMon),21 an advanced monitoring
tool for Windows offered by Microsoft. Process
Monitor combines the features of two legacy Microsoft
tools, FileMon22 (File Monitor) and RegMon23 (Registry
Monitor), along with process, thread, and network port
monitoring functionality into one comprehensive tool.24
• To provide continuity, the Process Monitor user interface
incorporates the RegMon and FileMon icons, which
serve as switches that allow the user to filter captured
content by event type; since Process Monitor v2.94
events can also be filtered by process activity, network
port activity, and profiling events.
• The FileMon feature of Process Monitor reveals the
system path of the activity, files, and .dlls opened, read,
or deleted by each running process, as well as a status
column, which advises of the failure or success of the
monitored activity.
• For example, in Figure 6.6, the file system activity
resulting from the execution of a malicious PDF file is
captured in granularity with Process Monitor, allowing
the digital investigator to trace the trajectory of the
malicious PDF as it executes.
malicious PDF as it executes.
Figure 6.6 Monitoring file system activity during the execution of
a malicious PDF file with Process Monitor
• Having an “umbrella” tool such as Process Monitor,
which gathers information relating to all system aspects,
is particularly helpful because its use limits the number of
tools that the digital investigator needs to toggle between
to ensure that all of the pertinent real-time activity relating
to the suspect program is observed.
• Unlike the legacy tools FileMon and RegMon, Process
Monitor enables the digital investigator to save the
monitoring session in native Process Monitor Format
(PML), allowing the session to be loaded back into
Process Monitor for later analysis.
Other Tools to Consider
File and Directory Monitoring
There are a number of utilities that help keep tabs on system
behavior during the course of dynamic malware analysis. Many
of these tools serve as “tripwires,” alerting the digital investigator
to potential issues that warrant deeper investigation.
ProcessActivityView: Allows the digital investigator to
monitor the file system activity (file/folders opened,
closed, read/write) associated with a target process
(http://www.nirsoft.net/utils/process_activity_view.html).
Tiny Watcher: Runs in the background and monitors key
changes on the subject system, such as when an
application is installed or changed, modifications in
specific system folders, and changes to important areas
of the Registry (http://kubicle.dcmembers.com/watcher/).
DirMon: File system change monitoring utility for
Windows NT/2000/XP. The utility can be run either
observable to the digital investigator, or silently in the
background, and it generates the HTML log of file
system changes (http://www.gibinsoft.net/).
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter and on the
companion Web site,
http://www.malwarefieldguide.com/Chapter6.html.
Registry Monitoring
Just as the FileMon feature of Process Monitor is a staple
investigative tool for file system activity analysis, the RegMon
feature is commonly used in tandem and actively reveals which
processes are accessing the host system’s Registry, keys, and
the Registry data that is being read or written.
• Process Monitor includes a Registry Summary feature
• Process Monitor includes a Registry Summary feature
that provides an overview of Registry paths accessed
during active monitoring, with additional filtering based
upon event type.
• Unlike static Registry analysis tools, the advantage of
using Process Monitor with the RegMon feature during
dynamic analysis of a malicious code specimen is that it
provides the digital investigator with the ability to trace
how programs are interacting with the Registry in real
time.
• Figure 6.7 displays the RegMon feature of Process
Monitor capturing real-time Registry activity of a
malicious process creating an autorun entry for a newly
spawned child process.
Figure 6.7 Monitoring Registry activity with Process Monitor
using the RegMon feature
Analysis Tip
Auto-starting Artifacts
Auto-starting Artifacts
Another aspect of Registry monitoring the digital investigator
should consider is “auto-starting” artifacts. When a system is
rebooted, there are a number of places that the Windows
operating system uses to automatically start programs. These
auto-starting locations exist in particular folders, Registry keys,
system files, and other areas of the operating system. References
to malware may be found in these auto-starting locations as a
persistence mechanism, increasing the longevity of a hostile
program on an infected computer. The number and variety of
auto-start locations on the Windows operating system have led
to the development of tools for automatically displaying
programs that are configured to start automatically when the
computer boots. Some of the more commonly used tools for
discovering these artifacts include:
Autoruns: http://technet.microsoft.com/en-
us/sysinternals/bb963902.aspx.
WhatInStartup:
http://www.nirsoft.net/utils/what_run_in_startup.html
(supersedes currently available but obsolete tool,
StartupRun (Strun),
http://www.nirsoft.net/utils/strun.html).
Autostart Explorer:
http://www.misec.net/products/autostartexplorer/.
Autostart and Process Viewer:
http://www.konradp.com/products/autostart-and-
process-viewer/.
Network Activity
In addition to monitoring the activity on the infected host
system, monitoring the live network traffic to and from the
system during the course of running a suspect program is also
important. Monitoring and capturing the network serves a
number of investigative purposes.
• First, the collected traffic helps to identify the network
capabilities of the specimen. For instance, if the
specimen calls out for a Web server, the specimen relies
upon network connectivity to some degree, and perhaps
more important, the program’s interaction with the Web
server may potentially relate to the program’s vector of
attack, additional malicious payloads, or a command and
control structure associated with the program.
• Further, monitoring the network traffic associated with the
victim host will allow the digital investigator to further
explore the requirements of the specimen. If the network
traffic reveals that the hostile program is requesting a
Web server, the digital investigator will know to adjust
the laboratory environment to include a Web server, to
in effect “feed” the specimen’s needs to further
determine the purpose of the request.
• Windows systems are not natively equipped with a
network monitoring utility; however, a number of them
are readily available, ranging from lightweight to robust
and multifunctional, as shown in the box “Other Tools to
Consider: Network Monitoring Tools.” Windump, the
Windows functional equivalent of tcpdump, is a powerful
command-line-based network capture tool that can be
configured to scroll real-time network traffic to a
command console in a human readable format.
However, for the purpose of collecting real-time
network traffic during dynamic analysis of a suspect
program, it is advantageous to use a tool that provides
program, it is advantageous to use a tool that provides
an intuitive graphical interface.
• Perhaps one of the most widely used GUI-based network
traffic analyzing utilities is Wireshark.25 Wireshark is a
multi-platform, robust, live capture, and offline analysis
packet capture utility that provides the user with
powerful filtering options and the ability to read and write
numerous capture file formats.
Other Tools to Consider
Network Monitoring Tools
Capsa: Robust GUI-based network forensic tool for
monitoring and analyzing network traffic
(http://www.colasoft.com/capsa/).
IP Sniffer: Free packet sniffer and protocol analyzer
developed by Erwan’s Lab (http://erwan.l.free.fr).
Network Miner Network Forensic Analysis Tool
(NFAT): (http://www.netresec.com/?
page=NetworkMiner;
http://sourceforge.net/projects/networkminer/).
Network Probe: Highly configurable commercial network
monitoring utility (http://www.objectplanet.com/probe/).
PacketMon: Free GUI-based packet capture tool and
protocol analyzer
(http://www.analogx.com/CONTENTS/download/network/pmon.htm).
SmartSniff: Free lightweight GUI-based packet capture
tool and protocol analyzer, with handy dual-pane user
interface (http://www.nirsoft.net/utils/smsniff.html).
Sniff_hit: Lightweight network monitoring utility that is
included in the Malcode Analyst Pack and SysAnalyzer
tool suites offered by iDefense Labs (Verisign)
(http://labs.idefense.com/software/malcode.php).
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter.
Before running Wireshark for the purpose of capturing
and scrolling real-time network traffic emanating to and from a
host system, consider the deployment and configuration options.
• The first option is to deploy Wireshark locally on the host
victim system. This makes it easier for the digital
investigator to monitor the victim system and make
necessary environment adjustments. Recall, however,
that this is not always possible, because some malicious
code specimens terminate certain “nosey” security and
monitoring tools, including packet-analyzing utilities.
• As a result, an alternative is to deploy Wireshark from the
malware lab “monitoring” host to collect all network
traffic. The downside to this approach is that it requires
the investigator to frequently bounce between virtual
hosts in an effort to monitor the victim host system.
• Once the decision is made as to how the tool will be
deployed, Wireshark needs to be configured to capture
and display real-time traffic in the tool display pane.
• In the Wireshark Capture Options, as shown in Figure
6.8, select the applicable network interface from the top
toggle field, and enable packet capture in promiscuous
mode by clicking the box next to the option. Further, in
the Display Options, select “Update list of packets in live
capture” and “Automatic scrolling in live capture.”
Figure 6.8 Wireshark Capture Options
• At this point, no filters should be enabled on the traffic.
Later, during the course of investigation, applying
specific filters based upon identified or known network
artifacts may be appropriate.
Port Activity
In addition to monitoring the network traffic, examine real-time
open port activity on the infected system, and the port numbers
of the remote systems that are requested by the infected system.
• With this information, a quick picture of the network
• With this information, a quick picture of the network
capabilities of the specimen may be revealed. For
instance, if the specimen calls out to connect to a remote
system on port 25 (default port for Simple Mail Transfer
Protocol, SMTP), there is a strong possibility that the
suspect program is trying to connect to a mail server.
• The observable port activity serves as a road map for
what to look for in the captured network traffic. When
examining active ports on the infected system, the digital
investigator can observe the following information, if
available:
Local Internet Protocol (IP) address and port
Remote IP address and port
Remote host name
Protocol
State of connection
Process name and PID
Executable program associated with process
Executable program path
There are a number of free GUI-based utilities that can
be used to acquire this information. Some of the more popular
tools include:
• TCPView26 (Microsoft), which provides color-based
alerts for port activity (green for opening ports, yellow
for TIME_WAIT status, and red for closing ports)
• DeviceLock’s Active Ports utility27
• CurrPorts (Nirsoft),28 a robust and configurable tool that
provides the digital investigator with a number of filter
options and helpful HTML report features (see Figure
6.9)
6.9)
Figure 6.9 Port activity captured in CurrPorts
API Calls
Another active monitoring task to perform when conducting
dynamic analysis of a malicious code specimen is to intercept
API calls from the program to the operating system.
• The Microsoft Windows API provides services used by
all Windows-based programs and enables programs to
communicate with the operating system29; these
communications are referred to as API calls.
• API calls made by a suspect program can provide
significant insight as to the nature and purpose of the
program, such as file, network, and memory access.
• Thus, by monitoring the API calls, the digital investigator
can observe the executed program’s interaction with the
operating system. The intercepted information serves as
a great road map for the investigator, often pointing to
a great road map for the investigator, often pointing to
correlative clues regarding system or network activity.
• A powerful and feature-rich tool for intercepting API calls
is TracePlus/Win32,30 which can trace 34 categories of
API functions (comprising nearly 1,500 API calls).
• There are a variety of other utilities available for
intercepting API calls, some of which are more reliable
and robust than others. Many of these tools accomplish
the task of intercepting API calls by implementing .dll
injection—injecting a .dll into the address space of the
target process.
• Some of the more popular API call-monitoring utilities
include API Monitor,31APISpy32,32 Microsoft
Detours,33 APILogger (included with Malcode Analyst
Pack and SysAnalyzer),34 Kerberos,35 AutoDebug,36
WinAPIOverride,37 and Kakeeware’s Application
Monitor.38
• As a rule of thumb, the more robust the list of API
functions and calls accurately recognized by the tool, the
better. Similarly, for the purpose of malicious code
analysis, it is essential to have a utility that allows the user
to isolate the interception of API calls to a specific target
program. Otherwise, searching for the calls made by
your suspect program through “API noise” from other
applications will prove difficult.
• Further, it is very valuable to have a tool that enables the
digital investigator to isolate or “spy” only on certain
functions, as shown in Figure 6.10. We will explore the
purpose of that functionality later in the chapter, using the
Spy Studio utility.
Figure 6.10 Kakeeware API Monitor API Function Selection
Menu
Execution Artifact Capture:
Digital Impression and Trace
Evidence
Similar to real-world crime scenes, digital crime scenes
contain valuable impression and trace evidence that can
help identify suspect malware, effects of the infection on
the victim system, and potentially the suspect(s) who
deployed the malware. Collection of digital impression
and trace evidence is not a separate monitoring technique;
rather, it encompasses the totality of artifacts collected
through both active and passive system monitoring.
Impression Evidence
In the traditional forensic science and crime scene analysis
contexts, impression evidence is resulting marks, patterns, and
characteristics that have been pressed into a surface at the crime
scene, such as tire treads, footwear, and tool marks.
• Impression evidence is valuable evidence, because it can
be a unique identifier relating to the suspect or it can
reveal how certain events or aspects of the crime
occurred.
• Impression evidence is collected and preserved for
comparison with other evidence, impressions, exemplars,
or known specimens.
or known specimens.
• Traditionally, the manner in which investigators gather
impression evidence is through an impression cast, using
a material such as a plaster compound, silicone, or
powder to create a duplicate of the impression.
• Collected impressions can have individual or class
characteristics. Individual characteristics are those that
are unique to one entity or person. Conversely, class
characteristics are those that are common to a group.
Trace Evidence
Trace evidence in traditional crime scene analysis includes
hair, fibers, soils, particles, residues, and other material that is
introduced into the crime scene as a result of contact with the
suspect, or conversely, resulting from victim interaction and
contact away from the crime scene, which introduces the trace
evidence into the crime scene. This transfer of trace evidence
through contact is known as Locard’s Exchange
Principle—“every contact leaves a trace.”
Digital Impression Evidence
In the context of malware forensics, digital impression
evidence is the imprints and artifacts left in the physical memory,
file system, and Registry of the victim system resulting from the
execution and manifestation of suspect malicious code.
• Digital impression evidence can be a unique identifier
relating to a particular malicious code, or it can reveal
how certain events occurred while the suspect malware
how certain events occurred while the suspect malware
executed and manifested.
• Digital impression evidence can be collected and
preserved for correlation and comparison with other
evidence or known malicious code infection patterns and
artifacts. For instance, newly created files on the victim
file system should be collected and analyzed.
• Similar to real-world crime scene forensics, collected
digital impressions can have individual or class
characteristics.
Digital Trace Evidence
Digital trace evidence in the context of malware forensics are
files and other artifacts introduced into the victim system/digital
crime scene as a result of the suspect malware’s execution and
manifestation, or conversely, resulting from victim online activity,
which introduces the digital trace evidence into the crime scene.
The collection of digital impression and trace evidence
involves digital casting —or passively logging and collecting the
digital impression and trace evidence as the malware
executes—and augmenting real-time monitoring and analysis
during dynamic analysis of a suspect program. The resulting
“digital cast” supplements evidence collected through host
integrity and installation monitors, which reveal the resulting
system changes compared to a pristine system snapshot, but not
the totality of the execution trajectory and how the impression
and trace evidence manifested.
• A tool that is helpful to implement on the local system
during dynamic analysis to obtain digital impression and
trace evidence is Capture BAT (Behavioral Analysis
trace evidence is Capture BAT (Behavioral Analysis
Tool).39
• Developed by the New Zealand Honeynet Project for the
purpose of monitoring the state of a system during the
execution of applications and the processing of
documents, Capture BAT provides the digital
investigator with significant insight into how a suspect
executable operates and interacts with a host system,
gathering the resulting digital impression and trace
evidence.
• Capture BAT monitors state changes on a low kernel
level, but provides a powerful filtration mechanism to
exclude “event noise” that typically occurs on an idle
system or when using a specific application.
• This granular filtration mechanism enables the investigator
to intuitively identify processes that cause the various
state changes, such as file and Registry writes,
modifications, and deletions. For instance, as shown in
Figure 6.11, upon executing a malicious PDF file,
Capture BAT identifies and logs the creation of
processes and the resulting File system and Registry
activity.
Figure 6.11 Use of CaptureBat to obtain digital impression and
trace evidence
As discussed in Chapter 2, memory forensics is an
integral part of malware forensics. Recall that physical memory
can contain a wide variety of digital impression and trace
evidence, including malicious executables, associated system-
related data structures, and remnants of related user activities
and malicious events.
• The purpose of memory forensics in the scope of
analyzing a malware specimen in a laboratory
environment is to preserve physical memory during the
runtime of the malware, and in turn, find and extract data
directly relating to malware (and associated information)
that can provide additional context.
• Using the tools and techniques discussed in Chapter 2,
the digital investigator can harvest available metadata
including process details, network connections, and
including process details, network connections, and
other information associated with the malware for
analysis and comparison with volatile data preserved
from the live victim system in which the malware was
collected.
In addition to these tools and techniques, digital casting
of physical memory can be augmented by identifying digital
impression and trace evidence using FlyPaper40 and RECon.41
FlyPaper is a utility that loads a device driver causing
process artifacts to “stick” or reside in memory.
• FlyPaper is optimally used in a VMWare Workstation
environment as it is intended to be used in conjunction
with the VMWare snapshot function—preserving the
memory state of the guest system once it is infected by
the malware specimen.
• Once a snapshot of the infected system state is taken, the
.vmem file associated with the infected guest system can
be parsed in HBGary Responder, Mandiant
Memoryze/AuditViewer/Redline, and Volatility (see
Chapter 2 for a detailed discussion of these tools).
• A VMWare .vmem file is a virtual machine’s paging file
and contains the memory of the virtual machine (also
known as the guest); it is saved on the digital
investigator’s analysis system (also known as the
host).42
• To use FlyPaper, launch it within the malware laboratory
guest system prior to executing the target malware
specimen, as shown in Figure 6.12.
Figure 6.12 FlyPaper
• Execute the target malware specimen and allow it to run
for a few moments to ensure execution trajectory. During
the course of runtime, FlyPaper generates a log file (by
default, C:\flypaper.log ) detailing the behavior of the
malware and the resulting digital impression evidence left
on the infected guest system.
• Preserve the infected system state of the VMware guest
by taking a snapshot. Save the associated .vmem file for
the guest system for analysis in HBGary Responder, or
other memory forensic tool of choice.
REcon is a dynamic analysis utility included with
Responder Pro that records and graphs a suspect program’s
behavior during runtime.43 The resulting “recording,” in
conjunction with physical memory, can be examined in the scope
of temporal and relational contexts with Responder Pro using the
Timeline and Graph features. REcon is typically deployed in a
virtual environment, such as a VMWare Workstation guest
system, wherein the infected .vmem file can easily be collected for
analysis and to ensure that the system can be reverted to a
analysis and to ensure that the system can be reverted to a
pristine state after being potentially infected by a suspect
program.
• To use REcon, simply invoke the program and click the
“Start” button, as shown in Figure 6.13. Select “Launch
New” and select the target executable specimen for
analysis.
Figure 6.13 REcon
• Let the specimen run for a reasonable period of time to
ensure full execution trajectory and manifestation of
potential digital impression and trace evidence in
memory.
memory.
• Take a snapshot of the infected virtual guest system; after
the snapshot has completed stop REcon.
• Collect the resulting REcon Forensic Binary Journal
(.fbj) session file (by default residing in the root of C:\)
and the .vmem file associated with the infected VMWare
guest. These files will be processed concurrently in
Responder Pro.
• HBGary Responder 2 also offers a “Live Recon Session”
project option, which largely automates this process.
Executing the Malicious Code
Specimen
After taking a snapshot of the original system state and
preparing the environment for monitoring, you are ready
to execute your malicious code specimen.
• As mentioned earlier, the process of dynamically
monitoring a malicious code specimen often requires
plenty of pauses, review of the data collected in the
monitoring tools, reversion of virtual hosts (if you choose
to use virtualization), and re-execution of the specimen to
ensure that no behavior is missed during the course of
analysis.
• In this process, there are a number of ways in which the
malware specimen can be executed; often this choice is
contingent upon the passive and active monitoring tools
the digital investigator chooses to implement.
• Execution of a target specimen also is contingent upon file
profile. Unlike Portable Executable (PE) files that can be
invoked through other tools, as described below,
malicious document files such as PDFs, MS Office files,
and MS Compiled Help (CHM) files typically require
and MS Compiled Help (CHM) files typically require
the digital investigator to manually open and execute a
target file by double-clicking on it. It is through this
opening and rendering process that the infection
trajectory of the specimen is invoked.
Simple Execution: The first method is to simply execute
the program and begin monitoring the behavior of the
program and the related effects on the victim system.
Although this method certainly is a viable option, it does
not provide a window into the program’s interaction with
the host operating system. As described previously, this
method is often used for the execution of malicious
document files.
Installation Monitor: As discussed earlier, a common
approach is to load the suspect binary into an installation
monitoring utility such as InCtrl5 or InstallWatch and
execute the binary through the utility in an effort to
capture the changes that the program caused to the host
system because it was executed.
API Monitor: In an effort to spy on the program’s
behavior upon execution, the suspect program can be
launched through an API monitoring utility, which in turn
traces the calls and requests made by the program to the
operating system.
• No matter which execution method is chosen, it is
important to begin actively monitoring the host system
important to begin actively monitoring the host system
and network prior to the execution of the suspect
program to ensure that all of the program behavior and
activity is captured.
Analysis Tip
“Rehashing”
After the suspect program has been executed, obtain the hash
value for the program. Although this information was collected
during the file profiling process, recall that executing malicious
code often causes it to remove itself from the location of
execution and hide itself in a new, often non-standard, location
on the system. When this occurs, the malware may change file
names and file properties, making it difficult to detect and locate
without a corresponding hash. Comparing the original hash value
gathered during the file profiling process against the hash value
collected from the “new” file will allow for positive identification
of the file.
Malware execution can be viewed similarly to
traditional forensic disciplines, such as ballistics, that
examine trajectory—the path or progression of an entity.
In the digital crime scene reconstruction context,
“execution trajectory” is the behavior and interaction of
the malicious code specimen with the victim system and
external network resources from the point of execution
through the life cycle of the infection.
Critical aspects of execution trajectory analysis include:
• Network activity
• Process activity
• API function calls
• File system activity
• Registry activity
Network Activity: Network Trajectory,
Impression, and Trace Evidence
After executing a target malware specimen, observe immediate
requests made by the program, including:
A convenient and efficient way to capture the network
requests attributable to a malware specimen during execution
trajectory is to deploy a software firewall program in the lab
environment—particularly a firewall that offers network and
program rules acting as a “tripwire” when activity is triggered by
the program.
• Some examples of free firewall software available for
installation on your malware lab system include:
Zone Alarm44
Online Armor45
Comodo46
PC Tools47
Ashampoo48
• The real-time network traffic captured in Wireshark can
be used to correlate firewall activity (see Figure 6.14).
This layering of information collection is also
advantageous in instances where a malware specimen
h a s countersurveillance capabilities, such as
terminating processes associated with anti-virus, firewall,
and other security software.
Figure 6.14 The subject specimen requesting to resolve a
domain name
Often, in the beginning phase of execution trajectory, the
purpose or significance of a network request made by a malware
specimen is unknown.
• To enable a suspect program to fully execute and behave
as it would “in the wild,” the digital investigator will need
to adjust the laboratory environment to accommodate
the specimen’s request to resolve a network resource,
and in turn, facilitate the natural execution trajectory.
• Environment adjustment in the laboratory is an essential
process in behavioral analysis of a suspect program. A
common adjustment, particularly for modular malicious
code (such as banking Trojans, crimeware kits, and
bots), is to emulate DNS to resolve domain names hard-
coded into the target specimen.
Environment Emulation and Adjustment:
Network Trajectory Reconstruction
Through adjusting the malware lab environment and providing
the resources that the specimen needs, the digital investigator can
conduct network trajectory reconstruction or re-enact the
manner and path the specimen takes to successfully complete the
life cycle of infection.
There are a number of ways to adjust the lab
environment to resolve a domain name.
• The first method would be to set up a DNS server, in
which the lookup records would resolve the domain
name to an IP address of another system on the
laboratory network (typically the suggested Linux server
host). A great program to facilitate this method is Simple
DNS Plus, a lightweight and intuitive DNS program for
Windows systems.49
• An alternative to establishing a full-blown DNS server
would be to use a utility such as FakeDNS, which
comes as a part of the Malcode Analyst Pack tool suite
made available from iDefense.50 FakeDNS can be
configured to redirect all DNS queries to a local host or
to an IP address designated by the user (typically the
Linux server host). As shown in Figure 6.15, once
launched, FakeDNS listens for DNS traffic on UDP port
53 (the default port for DNS), and in this instance, will
redirect all DNS queries to the host supplied by the user
(in this instance, 192.168.186.139).
Figure 6.15 Resolving DNS queries with FakeDNS
• Another more simplistic solution is to modify the system
hosts file—the table on the host system that associates
IP addresses with host names as a means for resolving
host names. On Windows 2000, the hosts file resides in
the C:\WINNT\system32\drivers\etc directory and on
XP/Vista/Windows 7 systems, the hosts file resides in
the C:\WINDOWS\system32\drivers\etc directory.
To modify the entries in the hosts file, navigate to the
\etc directory and open the hosts file in notepad or
another text editor.
Add the relevant domain name entry by first entering the
IP address that you want the domain name to resolve to
(typically the IP address of the virtual Linux server
system in your malware laboratory), followed by a
space, and the target domain name to resolve. Example
entries are provided in the hosts file as guidance.
Network Trajectory Reconstruction:
Chaining
Chaining
After adjusting the environment to resolve a domain name for
the specimen, and pointing the domain to resolve to the IP
address of a virtual Linux server host on malware lab network,
monitor the specimen’s reaction and impact upon the victim
system.
• Keep close watch on the network traffic, as adding the
new domain entry and resolving the domain name may
cause the specimen to exhibit new network behavior.
For instance, the suspect program may reveal what it
was trying to “call out” or “phone” home to, such as a
Web server, FTP server, IRC server, or other remote
resource, as depicted in Figure 6.16.
Figure 6.16 A suspect program attempting to retrieve a file from
a Web server after a domain name is resolved
Perpetuating the infection life cycle and adjusting the
laboratory environment to fulfill the network trajectory is a
process known as trajectory chaining; be certain to document
each step of the trajectory and the associated chaining steps.
• To facilitate trajectory chaining, accommodate the
• To facilitate trajectory chaining, accommodate the
sequential requests made by the suspect program.
• For instance, to chain the request made by the malware
depicted in Figure 6.16, the digital investigator should
start a Web server on the virtual Linux host where the
domain name is pointed; done this way, the requested
connections are captured in the Web server log (see
Figure 6.17).
Figure 6.17 Capturing the requests of a malware specimen in a
Web server
• The data collected through network trajectory
reconstruction, such as that shown in Figure 6.17, may
not be immediately decipherable and will require
investigation of the resulting network impression and
trace evidence.
Network Impression and Trace Evidence
Network impression evidence includes the imprints and
artifacts in network traffic attributable to a suspect program.
artifacts in network traffic attributable to a suspect program.
Similarly, network trace evidence are files and other artifacts
introduced into network traffic, and in turn, onto the victim
system, as a result of the suspect malware’s execution and
manifestation, or conversely, resulting from victim online activity.
The following items of investigative significance can be gleaned
from network impression and trace evidence:
• The purpose of resolving a domain name. For
example, in Figure 6.17, the Web server log reveals that
the suspect program needed to resolve a domain name in
order to phone home to a Web server and download
additional files (msn_messenge and
descompact_msn ).
• Identifiers of modular malicious code likely
introduced as trace evidence onto the victim system.
The nature and purpose of the requested files is
unknown, but both have file extensions, giving the
initial impression that they are image files. To emulate
how the malware specimen would fully execute as it
would have in the wild, if possible, discreetly retrieve and
analyze the requested files and host them internally on
your malware lab server to perpetuate the execution
trajectory of the specimen.
• Functionality interpretation. The functionality displayed
by the specimen in the Web server log is commonly
referred to as a Trojan downloader , which is a Trojan
program that attempts to connect to other online
resources, such as Web or File Transfer Protocol (FTP)
servers and stealthy download additional files. Typically,
the downloaded files are additional malware, such as
backdoor or other Trojan programs.51
• Metadata. Significant network impression evidence
embedded in the captured Web traffic is the user-agent
string. A user-agent string identifies a client Web
string. A user-agent string identifies a client Web
browser and provides certain system details to the Web
server visited by the browser. In the instance of Figure
6.17, the user-agent string is “(compatible; MSIE 6.0;
Windows NT 5.1; SV1; EmbeddedWB 14,52
from:http://www.bsalsa.com/Embedded Web Browser
from:http://bsalsa.com/).” The digital investigator should
research and document findings relating to user-agent
strings; this metadata may provide further insight into the
attacker or malware functionality and purpose. For
instance, the bsalsa embedded Web browser in Figure
6.17 is a freeware package of Borland Delphi
components used to create customized Web browsing
applications and to add data downloading capabilities to
applications, among other things.52
Using a Netcat Listener
An alternative method that can be used to intercept the
contents of Web requests and other network connections is to
establish a netcat listener on a different host in the laboratory
network.
• Recall from Chapter 1 that netcat is a powerful
networking utility that reads and writes data across
network connections over TCP/IP or User Datagram
Protocol (UDP).53
• This is particularly helpful for establishing a network
listener on random TCP and UDP ports that a suspect
program uses to connect. Netcat is a favorite tool among
many digital investigators due to its flexibility and
diversity of use, and because it is often natively installed
diversity of use, and because it is often natively installed
on many Linux distributions. There is also a Windows
port available for download.54
• Upon learning on which remote port the suspect program
is requesting to connect, the digital investigator can utilize
netcat by establishing a netcat listener on the target
port of the Linux server host in the malware laboratory.
• Using the example in Figure 6.17, the suspect program is
requesting to download files from a Web server over
port 80. To establish a netcat listener on port 80 of the
Linux server, use the nc command with the –v (verbose)
–l (listen) –p (port) switches and identify the target port
number. (The –v switch is not required and simply
provides more verbose output, as shown in Figure 6.18.)
Figure 6.18 Establishing a netcat listener for the purpose of
collecting network impression evidence
Examining Process Activity
During dynamic analysis of a suspect program, the digital
investigator will want to gain process context, or a full
perspective about a spawned process and how it relates to the
system state and to other behavioral artifacts resulting from the
execution of the program.
• Using Process Explorer (or a similar process analysis
tool), collect basic process information, such as the
process name and PID. With subsequent queries, seek
further, particularly for the purpose of obtaining these
process details:
Process name and PID
Temporal context
Memory consumption
Process to executable program mapping
Process to user mapping
Child processes
Threads
Invoked libraries and dependencies
Command-line arguments used to invoke the process
Associated handles
Associated handles
Memory contents of the process
Relational context to system state and artifacts
• Further, by right-clicking on a suspect process in the
Process Explorer main viewing pane, the digital
investigator will be presented with a variety of other
features that can be used to probe the process further,
such as the strings in memory, threads, and associated
TCP/IP connections, as shown in Figure 6.19.
Figure 6.19 Analyzing a suspect process with Process Explorer
Process Spying: Monitoring API Calls
Recall that API calls are communications made by user-mode
programs to the operating system. Gaining a solid understanding
of the API calls made by a malware specimen will greatly assist
in static examination of the specimen in a disassembler.
• In examining the API calls made by a suspect program,
be mindful of queries relating to:
Creation or termination of a process;
Calls to anomalous files or resources;
Socket creation;
Network connectivity;
Information gathering about open Internet Explorer
Windows and
Registry modification, among other anomalous or
nefarious API calls.
• Figure 6.20, which will be used for demonstrative
purposes in this section, depicts a sample of API calls
made by a Banking Trojan.
Figure 6.20 Analyzing the API calls being made by a Banking
Trojan
• The captured API calls reveal that the specimen is
monitoring user Internet Explorer browser activity. By
correlating the various API calls and gaining an
understanding of the relational context between the calls,
the digital investigator can better determine the nature
and purpose of the specimen.
• Further examining the API calls, it is discernable that the
Banking Trojan uses Dynamic Data Exchange (DDE)
commands,55 which enable Windows applications to
share data. Internet Explorer supports DDE commands,
and in this instance, the suspect program leverages this
by issuing the www_GetWindowInfo command, which
returns the Uniform Resource Locator (URL) and
Window text currently displayed in an open Internet
Explorer browser window.
• Immediately after querying to identify the URL being
navigated to in the open browser, the Trojan uses the
FindWindowA function56 to locate window names that
match specified strings.
• In addition to identifying and comparing the names of the
open browser windows, the Trojan searches in the
WINDOWS\Help directory for specific file names using the
FindFirstFileA function.
Investigative Considerations
Investigative Considerations
• For full execution context, the digital investigator should
examine API calls in conjunction with file system activity,
and associated artifacts, such as suspicious files, that are
requested or invoked by a suspect program.
“Peeping Tom”: Window Spying
In addition to intercepting API calls, another useful technique
for gaining insight into execution trajectory is examining window
messages related to a suspect program.
• A tool that we can use to quickly acquire this information
is NirSoft’s WinLister utility.57
• With WinLister, the digital investigator can identify
numerous hidden windows relating to the malicious code
specimen.
• Items of investigative interest that can be uncovered in this
process include:
Title
Handle of the window
Location
Size
Class name
Associated process number
Name of the program that created the window
• In the example in Figure 6.21, the nature of the windows
associated with a suspect program reveals numerous
associated with a suspect program reveals numerous
references to Tforms (“forms”), which are objects used
in the creation of Delphi applications. This is a good clue
that we are analyzing a malicious code specimen written
in Delphi.
Figure 6.21 Displaying hidden program windows with WinLister
Examining File System Activity
During the dynamic analysis of a suspect program, gain full
perspective about file system activity that occurs on the victim
system and the relational context to other artifacts manifesting
during execution trajectory. Some of these considerations
during execution trajectory. Some of these considerations
include:
• Correlate the information gathered through the
interception of API calls with artifacts discovered in file
system activity.
• Correlate file system activity with process activity and
digital trace evidence such as dropped executables,
driver modules, hidden files, and anomalous text or
binary files. Monitoring common locations where
malware manifests to blend into the system, such as
“%systemroot%\system32,” may reveal anomalous items.
In addition to such traditional malware file artifacts,
consider functional context, including processes running
from suspicious locations in the file system, such as
newly created directories, or anomalous directories such
a s C:\Documents and Settings\\Local
Settings\Temp, among others.
• Correlate file system activity with Registry activity.
• Perform relational analysis, including correlation of
network impression and trace evidence with execution
trajectory on the file system, such as modification of the
hosts or lmhosts file.
Examining Registry Activity
During the runtime of the suspect program, gather correlative
information relating to the malware specimen’s interaction with
the Registry of the host system, including:
• Registry keys created during the execution life cycle of the
malware specimen, which may reveal where malware is
configured to auto-start
configured to auto-start
• Registry keys modified during the time period the
malware specimen was executed
• Registry keys deleted during the time period that the
malware specimen was executed
• Registry artifacts that provide clues about additional
components of the malware
Another interesting aspect about monitoring Registry
activity is that good clues are not necessarily those values or
keys created, modified, or queried by the suspect program;
rather, they are values or keys queried for, but not in existence,
on the host system. For instance, a suspect program may attempt
to query for Registry keys related to a particular program or
development environment, not present on a host system, which is
a great supporting clue that the program may require additional
components to be fully functional and successfully complete its
execution life cycle.
Automated Malware Analysis
Frameworks
A helpful solution for efficiently triaging and
processing malicious code specimens in an effort to gain
quick intelligence about the specimens is automating the
behavioral analysis process.
Over the last few years, a number of researchers have
developed automated malware analysis frameworks that
combine and automate a myriad of processes and tools to
collectively monitor and report on the runtime behavior of a
target malicious code specimen. These analysis frameworks
provide an effective and efficient means of processing a suspect
program to quickly gain actionable intelligence about the
specimen. Some examples of automated malware analysis
frameworks include:
• Buster Sandbox Analyzer (Buster)58: A flexible and
configurable sandbox platform based upon Sandboxie,59
a utility that creates an isolated abstraction area
(sandbox) on a host system preventing changes from
being made to the system. Buster monitors and analyzes
the execution trajectory and behavior of malicious code
specimens, including PE files, PDF files, and Microsoft
Office Documents, among others. Unlike many
automated solutions, Buster allows the digital investigator
to interact with the specimen when required (such as
clicking on a dialog box button or supplying missing
libraries where needed).
• ZeroWine60 and ZeroWine Tryouts 61: Developed by
• ZeroWine60 and ZeroWine Tryouts 61: Developed by
Jean Koret, both ZeroWine and ZeroWine Tryouts (an
offshoot of the original ZeroWine project) are open
source malicious code behavioral analysis platforms built
on Debian Linux in QEMU virtual machines that emulate
Windows systems using WINE. Intuitive to use, both
systems provide the digital investigator with Web-based
upload and reporting consoles. Although both systems
can dynamically analyze Windows executable files,
ZeroWine Tryouts can also conduct automated static
analysis of PDF files, as shown in Figure 6.22.
Figure 6.22 Analyzing an executable malware specimen in
ZeroWine and a malicious PDF file specimen in ZeroWine
Tryouts
• Minibis62: Developed by the Austrian Computer
• Minibis62: Developed by the Austrian Computer
Emergency Response Team (CERT.at), Minibis is a
malicious code behavioral analysis framework based on
Oracle VirtualBox virtualization and scripting of third-
party malicious code monitoring utilities, such as those
referenced in the Active System and Network
Monitoring section of this chapter.
• The Reusable Unknown Malware Analysis Net
(TRUMAN)63: A native hardware-based solution
developed by malware expert Joe Stewart of
SecureWorks, TRUMAN operates on a client-server
model with a custom Linux boot image to restore a fresh
Windows victim system image after each malware
specimen is processed. At the core of TRUMAN is a
series of scripts to emulate servers (DNS, Web, SMTP,
IRC, SQL, etc.) and pmodump, a perl-based tool that
parses physical memory for malicious process artifacts.
Although TRUMAN is no longer supported, in 2009 Jim
Clausing of the SANS Institute developed and published
enhancements for the platform.64
• Cuckoo Sandbox65: An open source malicious code
behavioral analysis platform developed by Claudio
Guarnieri that uses a Linux controller system (core
component), virtual machines (installed on VirtualBox),
Samba shares (to facilitate communication between the
controller and virtual machines), and analysis packages
(scripts that define automated operations that Windows
should conduct during the analysis of a target
specimen).66
Other Tools to Consider
Commercial Malware Sandboxes
GFI Sandbox (formerly Sunbelt CWSandbox):
Designed for Windows platforms, the GFI Sandbox
system monitors and analyzes malicious code specimens
during runtime. Capable of analyzing Windows
executable files and Microsoft Office Documents, among
other files types, GFI Sandbox reports on system
changes and network activity attributable to a target
specimen, along with proprietary Digital Behavior Traits
(DBT) for interpreting malware actions
(http://www.sunbeltsoftware.com/Malware-Research-
Analysis-Tools/Sunbelt-CWSandbox/).
Norman Sandbox Malware Analyzer: Built upon a
Windows Clone operating system, Norman Sandbox
executes and analyzes Windows executable files in an
emulated host and network environment, monitoring and
reporting on the target specimen’s behavior and impact
upon the system
(http://www.norman.com/business/sandbox_analyzer/).
Online Malware Analysis
Sandboxes
A helpful analytical option to either quickly obtain a
behavioral analysis overview of suspect program or to use
as a correlative investigative tool is to submit a malware
specimen to an online malware analysis sandbox.
These services are distinct from vendor-specific malware
specimen submission Web sites or online virus scanners such as
VirusTotal, Jotti Online Malware Scanner, and VirScan, as
discussed in Chapter 5.
• Online malware scanners execute and process the
malware in an emulated Internet, or “sandboxed,”
network and generally provide the submitting party a
comprehensive report detailing the system and network
activity captured in the sandboxed system and network.
• As we discussed with the submission of samples to virus
scanning Web sites, submission of any specimen
containing personal, sensitive, proprietary, or otherwise
confidential information may violate a victim company’s
corporate policies or otherwise offend the ownership,
privacy, or other corporate or individual rights
associated with that information. Seek the appropriate
legal guidance in this regard before releasing any such
specimen for third-party examination.
• Similarly, remember that by submitting a file to a third-
party Web site you are no longer in control of that file or
the data associated with that file. Savvy attackers often
conduct extensive open source research and search
conduct extensive open source research and search
engine queries to determine if their malware has been
detected. The results relating to a file submitted to an
online malware analysis service are publicly available and
easily discoverable—many portals even have a search
function. Thus, as a result of submitting a suspect file, the
attacker may discover that his malware and nefarious
actions have been discovered, resulting in the destruction
of evidence and potentially damaging your investigation.
• The following table is a comparative listing of currently
available online malware analysis sandboxes and their
respective features:
Web Service Features
Web Service Features
GFI Sandbox (formerly Sunbelt Sandbox)
http://www.sunbeltsecurity.com/sandbox/
• Conducts cursory
file profiling, including
file name and MD5
and SHA1 hash
values.
• Conducts behavioral
analysis of Windows
portable executable
files; monitors and
reports on process,
file system, Registry,
and network activity.
• Provides report via
e-mail address
supplied by user.
CWSandbox (academic)http://www.mwanalysis.org/
• Conducts cursory
file profiling, including
file name and MD5
and SHA1 hash
values.
• Conducts behavioral
analysis of Windows
portable executable
files; monitors and
reports on process,
file system, Registry,
and network activity.
• Conducts cursory
file profiling, including
file name, MD5 hash
value, time last
submitted (if
previously received),
Anubis http://anubis.iseclab.org/index.php
and a description of
the suspect file’s
identified behavioral
characteristics.
• Conducts behavioral
analysis of Windows
portable executable
files; monitors and
reports on process,
file system, Registry,
and network activity.
• Malicious URL
Scanner.
ThreatExpert http://www.threatexpert.com
• Conducts cursory
file profiling, including
file size, MD5 and
SHA1 hash values,
submission details,
duration of
processing, identified
anti-virus signatures,
and a threat
categorization based
upon the suspect file’s
identified behavioral
characteristics.
• Conducts behavioral
analysis of Windows
portable executable
files; monitors and
reports on process,
file system, Registry,
and network activity.
• Conducts cursory
Norman Sandbox Analyzer
http://www.norman.com/security_center/security_tools/
• Conducts cursory
file profiling, including
file size, MD5 and
SHA1 hash values,
packing detection, and
identified anti-virus
signatures.
• Conducts cursory
behavioral analysis of
Windows portable
executable files;
monitors and reports
on file system,
Registry, and network
activity.
• Provides basic text
report via e-mail
address supplied by
user.
Joe Sandbox Web (formerly Joebox)
http://www.joesecurity.org/service.php
• Commercial online
sandbox service.
• Conducts extensive
file profiling, including
file size, MD5 and
SHA1 hash values,
packing detection, PE
file analysis, and
metadata extraction.
• Conducts robust
behavioral analysis of
Windows executable
files (exe, dll, sys)
Microsoft Office
Document, and PDF
Document, and PDF
files; monitors and
reports on memory,
process, file system,
Registry, and network
activity.
• Provides HTML
report and session
screenshot and
session pcap file via e-
mail address supplied
by user.
NSI Malware Analysis Sandbox
http://www.netscty.com/malware-tool
• Sandbox based
upon TRUMAN
automated malware
analysis framework.
• Link to analytical
report is provided via
e-mail address
supplied by user.
Eureka http://eureka.cyber-ta.org/
• Conducts behavioral
and static analysis of
Windows portable
executable files;
provides assembly
code analysis of
unpacked specimen,
strings, control flow
exploration, API calls,
capabilities graph, and
DNS queries.
• Unpacked
executable specimen
is made available for
is made available for
download.
Comodo http://camas.comodo.com/ (Automated Analysis
System) http://valkyrie.comodo.com/ (“File Verdict
Service”)
• Conducts cursory
file profiling, including
file size and MD5,
SHA1, and SHA256
hash values.
• Conducts behavioral
analysis of Windows
portable executable
files; monitors and
reports on process,
file system, Registry,
and network activity.
BitBlaze http://bitblaze.cs.berkeley.edu/
• Conducts behavioral
and static analysis of
Windows portable
executable files;
provides assembly
code analysis of
unpacked specimen,
strings, and API calls.
Malfease https://malfease.oarci.net/
• Conducts extensive
file profiling, including
file size, MD5 and
SHA1 hash values,
identified file
signatures, packing
detection, PE file
analysis, byte
frequency analysis,
and metadata
extraction.
• User portal.
ViCheck.ca https://www.vicheck.ca/
• Processes PE files,
document files (PDF,
MS Office, CHM),
images, and archive
file, among others.
• Queries a submitted
file against viCheck
malware database, as
well as
Virustotal.com,
ThreatExpert.com,
and Team-Cymru
malware hash
databases.
• Conducts file profile
of target specimen,
including file format
identification, file size,
and
MD5/SHA1/SSDEEP
hash values. Provides
a hexdump for
submitted PE files.
• Processes target file
in Sandbox.
• Link to analytical
report is provided via
e-mail address
supplied by user.
• Tool portal that
allows users to search
the malware database
for
MD5/SHA1/SHA256
MD5/SHA1/SHA256
hash values, Master
Decoder, IP header
processing, and
IP/Domain Whois.
Defeating Obfuscation
As described inChapter 5 , malware is often protected
with obfuscation code preventing the digital investigator
from harvesting valuable information from the contents of
the file during initial cursory review, which would
potentially provide valuable insight into the nature and
purpose of the malware.
To gain meaningful clues that will assist in the continued
analysis of a malicious code specimen, the digital investigator will
need to remove the obfuscation.
• In order to fully explore a suspect program, including
reviewing the embedded artifacts or examining the
program in a disassembler, it is necessary to extract the
original program from its “armor.”
• Although there are many obfuscation programs available,
very few, such as UPX,67 have a native unpacking
feature or utility. There are a number of methods to
defeat file obfuscation, each with its own advantages and
limitations. Some of these methods include:
Custom unpacking tools
Dumping a suspect process from memory
Locating the Original Entry Point (OEP) with a debugger
and extracting the PE file
Custom Unpacking Tools
Using the tools and techniques described in Chapter 5, detect
and identify any obfuscation code concealing a target file
specimen. If a packing program is identified, conduct Internet
research about the program and you are bound to find an
“unpacker” program specifically created to defeat the packing
program.
• Some examples of this are UnFSG,68 UnMew,69
AspackDie,70 UnPECompact,71 and DeShrink.72
• These tools work with varying degrees of success, and
many are written by hackers referred to by a single
name. Unfortunately, as many of these tools are
“underground utilities,” there is also a possibility that an
unscrupulous coder has built malicious features into the
tool that may infect the user system or render it
vulnerable.
• Further, as these tools are not typically considered
forensic utilities, they may not be the best choice for
investigations that have the potential for litigation in court
or other proceedings in which findings need to be
validated. Use due care in selecting and implementing
these utilities.
In Figure 6.23, the unpacking utility AspackDie (which
unpacks executables obfuscated with ASPack) is demonstrated.
Figure 6.23 Using AspackDie to unpack a protected executable
• AspackDie is very simple to use. After executing the
program the user will be prompted to select a target file
to unpack.
• After choosing the target file, AspackDie does its “magic”
and provides the user with a message box revealing
whether the file was successfully unpacked, the version
of ASPack identified, and the path of the output file
where the new, unpacked version of the target
executable was written to disk (this is normally the same
directory where the target program resides).
Dumping a Suspect Process from Memory
Another method of defeating obfuscation is to “dump” the
unpacked program from memory once the decompression or
decryption routine of the obfuscation is completed. This is a
decryption routine of the obfuscation is completed. This is a
simple and common method used by many digital investigators,
but there are a few shortcomings that are examined in detail later
in this section.
• There are a number of tools that can assist in dumping, all
of which are PE editing tools as well. Some of the staple
utilities include LordPE,73 ProcDump,74 and PE Tools
(Xmas Edition).75
• Although these tools are used quite often by digital
investigators, they are considered by many in the industry
to be underground tools (i.e., PE Tools is available from
http://www.uinc.ru/—the “Underground Information
Center”).
• In addition to these tools, a number of process monitoring
utilities have been released that also provide a process
dumping feature, including Process Explorer,76
CurrProcess,77 Task Explorer,78 ProcessAnalyzer,79
Sysinternals ProcDump,80 and Dumper.81
To dump a suspect program from memory with LordPE
(the same procedure applies with ProcDump and PE Tools), first
execute the program in a lab environment.
• Once the program has executed, locate the process in the
upper pane of the tool, right-click on the process, and
choose “dump full” (see Figure 6.24). The digital
investigator will then need to name the newly dumped file
and the location to write the file to disk.
Figure 6.24 Using LordPE to dump a process from memory
Although using this method can be helpful for dumping an
obfuscation-free version of the program, for the purpose of
searching for strings or examining the file in a disassembler, the
resulting file typically cannot be executed because the PE import
table is often corrupted in the process of being dumped. (The
import table provides the Windows loader with the imported .dll
names and functions needed for the executable to properly load.)
Investigative Considerations
• Another shortcoming of dumping a running program from
memory is that it does not work for all forms of
obfuscation code. Savvy attackers have learned that
dumping is a part of the malware analyst’s arsenal for
peering into their programs. As a result, some attackers
use packers that have anti-dumping countermeasures,
which stymie the digital investigator’s ability to dump an
unpacked program from memory.
• In such instances, static analysis techniques, such as
• In such instances, static analysis techniques, such as
debugging, will be required to extract the specimen from
obfuscation code.
Other Tools to Consider
Automated Unpackers
• Polyunpack: Developed by researchers at Georgia Tech,
Polyunpack identifies and extracts hidden code during
the runtime of the target executable;
http://polyunpack.cc.gt.atl.ga.us/polyunpack.zip;
http://www.acsac.org/2006/papers/122 .
• Ether: Developed by researchers at Georgia Tech, Ether
is a malware analysis framework based upon virtual
hardware extensions to remain transparent/undetectable
to a target executable during the course of execution;
http://ether.gtisc.gatech.edu/;
http://ether.gtisc.gatech.edu/web_unpack/ (Online Ether
unpacking Portal).
• R eversing Labs Tools : Reversing engineering tools
(TitanEngine, TitanCore, TitanMist, NyxEngine) to
identify and deobfuscate malware;
http://www.reversinglabs.com/.
Locating the OEP and Extracting with
OllyDump
Another method of defeating obfuscation is to run the
Another method of defeating obfuscation is to run the
protected suspect program through a debugger, locate the OEP
of the original program as it is unpacked into memory, and then
extract the program.
• Because each packing and cryptor obfuscates the OEP of
the protected program in a different way, it requires
step-by-step tracing of a suspect program during
execution through a debugger. A debugger is a program
that enables software developers, and conversely,
reverse engineers, to conduct a controlled execution of a
program, allowing the user to trace the program as it
executes.
• In particular, a debugger allows the user to set
breakpoints during the execution of a target program,
which pause the execution, allowing for examination of
the program at the respective breakpoint.
A debugger used by many malware analysts is Oleh
Yuschuk’s powerful and free 32-bit debugger, OllyDbg.82
• OllyDbg has a user-friendly GUI and a variety of
configuration options. The main OllyDbg interface or
“CPU window” provides the analyst with five re-sizeable
viewing panes, including, among other things, a
disassembler view, a register window (which displays
and interprets the contents of CPU registers), and a
dump window (which reveals the contents of memory or
file).
• One of the many benefits of OllyDbg is the ability to add
functionality to the program through the use of plug-ins
and scripting, in which there is a rather sizeable
contributing community. A great resource for OllyDbg
Plug-ins is the Open Reverse Code Engineering
Plug-ins is the Open Reverse Code Engineering
(OpenRCE) Web site founded by Pedram Amini.83
Analysis Tip
Anti-debugging
Be aware that in some instances attackers attempt to protect
their malicious programs by implementing anti-debugging
mechanisms, which are used to detect if the program is being run
through a debugger. These techniques are used to stymie analysis
and reverse-engineering. A good article on Windows anti-
debugging titled the “Windows Anti-Debugging Reference” can
be found online at http://www.securityfocus.com/infocus/1893.
A useful plug-in to assist in extracting our suspect
program from its packing is OllyDump,84 which enables the
digital investigator to dump an active process to a PE file. The
nuances of this process will vary with different types of
obfuscation code, but the general methodology is similar. In the
following example, a malicious code specimen obfuscated with
ASPack85 (a common packing program) will be examined to
demonstrate the use of OllyDbg and OllyDump.
• To use OllyDump, a suspect program must first be loaded
into OllyDbg.
• Upon loading the obfuscated target specimen, a message
box will advise that the entry point for the program is
“outside the code” (see Figure 6.25). This is a common
error to receive when attempting to debug a specimen
that is obfuscated with a packing or cryptor program.
Figure 6.25 OllyDbg entry point alert
• After clicking through the warning, the digital investigator
will be greeted with another helpful message box. This
time OllyDbg will advise that based upon entropy
analysis, the loaded specimen appears to be compressed
or encrypted (see Figure 6.26).
• After clicking through the warning, the suspect program is
presented in the OllyDbg environment. To identify the
OEP of the specimen, execute the malicious code
specimen in OllyDbg (allowing the ASPack
decompression routine to occur) and in turn, have the
suspect program loaded into memory where it is no
longer protected (see Figure 6.27).
Figure 6.27 A suspect program loaded into OllyDbg
• Once the specimen is loaded into OllyDbg, execute it
using the F9 key.
• When the execution pauses, identify a PUSH instruction for
the suspect program. At this offset use the “follow in
dump” feature, which can be invoked by right-clicking
within the CPU window (see Figure 6.28). In addition,
set a hardware breakpoint so that when the code is
stepped over with the F8 key the OEP address of the
suspect program will be reached (see Figure 6.29).
Figure 6.28 “Following the dump” in OllyDbg
Figure 6.29 Finding the OEP of a suspect program
Once the OEP is located, the debugged process can be
dumped with the OllyDump plug-in, which can be invoked by
either right-clicking in the CPU pane or by selecting the plug-in
from the Plug-ins Menu as shown in Figure 6.30.
Figure 6.30 Dumping with OllyDump
In selecting to dump the debugged process, OllyDbg
presents the user with an interface revealing the OEP address of
the extracted binary, DC044, as shown in Figure 6.31. By
selecting to dump debugged process, the “new” unpacked binary
will need to be saved to disk.
Figure 6.31 Acquiring the OEP of a dumped suspect program
At this point, the dumped suspect program is unpacked,
but the Import Table and Import Address Table (“Imports”) are
most likely corrupted (this can be tested by attempting to
execute the program in the sandboxed environment). Refer to
Chapter 5 for a discussion about the Import Table and the
Portable Executable file structure.
• OllyDump has a feature to rebuild the Imports as do PE
Tools (Xmas Edition) and LordPE.
• An alternative, discussed in the next section, is to rebuild
the Imports while the suspect program is still loaded in
OllyDbg and running in memory.
Reconstructing the Imports
As we discussed in Chapter 5, dynamically linked executable
programs require certain dynamic link libraries (.dlls) to
successfully execute.
successfully execute.
• When a dynamically linked program is executed, the
Windows loader reads the Import Table and Import
Address Table of the PE structure, identifies and loads
the .dlls (and associated functions) required by the
program, and maps them into process address space.
Thus, if the Imports are corrupted, the program will not
be able to successfully execute and load into memory.
• The Imports can be reconstructed using Import
Reconstructor (ImpREC).86 While the suspect process
is still running after having been executed with OllyDbg,
attach to the suspect process by selecting it from the
ImpREC active process drop-down menu (Figure 6.32).
Figure 6.32 Selecting a dumped process with ImpREC
• After attaching to the process, supply the OEP of the
suspect program obtained during the dump program in
OllyDbg (DC044) in the ImpRec IAT Autosearch
feature window.
• By supplying the OEP and selecting IAT Autosearch,
ImpREC attempts to recover the original Import
Address Table of the dumped executable. ImpREC
provides the user with a message box if the address of
the original IAT is discovered, as displayed in Figure
6.33.
Figure 6.33 ImpREC
• By selecting the Get Imports function, ImpREC rebuilds
the Imports of the target executable. Each recovered
import is demarcated as to whether it is valid or invalid.
Further, the user can query ImpREC using the “Show
Invalid” or “Show Suspect” functions to identify
functions that may not have been properly recovered.
• Once the Imports of the target executable have been
recovered and validated, the newly “refurbished”
dumped executable can be saved to disk using the “Fix
Dump” function (see Figure 6.34).
Figure 6.34 Reconstructing the dumped binary in ImpREC
After saving the newly dumped and reconstructed binary,
re-scan it with a packing identification utility such as PEiD, to
verify that the obfuscation has been removed.
• Many of the packing detection utilities we discussed in
Chapter 5 also detect the signatures of compilers and
high-level programming languages.
• The digital investigator can further verify the functionality
of the binary by executing it—confirming that the
program executes and exhibits the same behavior as the
previous obfuscated version.
Embedded Artifact Extraction
Revisited
After successfully pulling an executable malicious
code specimen from its obfuscation code, re-examine the
specimen for embedded artifacts and conduct deeper static
analysis of the specimen.
Re-profile the newly deobfuscated executable file using
the tools, techniques, and protocol described in Chapter 5.
• Pay particular attention to strings, symbolic information,
and file metadata that may reveal clues relating to the
purpose and capabilities of the program.
• Disassemble the target executable in an effort to
determine the function and interrelationships of
embedded artifacts, and in turn, how the totality of these
relationships shape the functionality of the specimen,
including:
Triggering events
Relational context of API function calls
Anticipated digital impression and trace evidence on a
target system
Analysis Tip
Investigative Parallels
The digital investigator could think of dynamic analysis to some
degree as surveillance of a suspect. During the course of
surveillance, the investigator seeks to learn “what does the
suspect do, where does he go, who does he talk to,” etc. This
initial evidence collection helps provide a basic overview of the
suspect’s activity, but often additional investigation is required. A
detailed interrogation (in the parallel of malware forensics,
disassembly) of the suspect (code) can help identify the
remaining items of potential interest.
Examining the Suspect Program in a
Disassembler
During the course of dynamic analysis of a malicious code
specimen, active system monitoring will likely yield certain clues
into the functionality of the specimen. In particular, API calls
made by the specimen during execution trajectory provide
substantial insight into the manner in which the specimen operates
and the digital impression and trace evidence that will be left on
the affected system.
• Examine the specimen in IDA Pro, a powerful
disassembler and debugger offered by Hex-rays.com.87
A disassembler allows the digital investigator to explore
the assembly language of a target binary file, or the
instructions that will be executed by the processor of the
host system.
• IDA Pro is feature-rich, multi-processor capable, and
programmable, and has long been considered the de
facto disassembler for malicious code analysis and
facto disassembler for malicious code analysis and
research. Although it is beyond the scope of this book to
go into great detail about all of the capabilities IDA Pro
has to offer, there is a great reference guide called The
IDA Pro Book by Chris Eagle.88
By spying on the API calls made by a suspect program
during dynamic analysis, a helpful list of functions can be
identified for exploration within IDA Pro. The following
examples demonstrate leveraging the intelligence gathered during
API monitoring and using IDA Pro to parse a suspect malware
specimen. In particular, IDA Pro can be used to identify: (1)
triggering events; (2) relational context of API function calls; and
(3) anticipated network trajectory, digital impression, and trace
evidence.
Triggering Events
• Triggering events are environmental or functional context
variables that cause a malicious specimen to perform a
certain function. In Figure 6.35, IDA Pro was used to
locate the strings a specimen uses to compare against
open browser windows. The code of the malware
reveals numerous URLs for various financial institutions,
which the specimen monitors with the FindWindow
function.
Figure 6.35 Using IDA Pro to discover a triggering event
Relational Context of API Function Calls
• In addition to identifying triggering events, IDA Pro can
be used to identify the inextricability of certain function
calls, further revealing how a malware specimen
accomplishes its infection life cycle and intended
purpose.
• Looking further into the code of a target specimen from
Figure 6.36, the malware also uses the
GetForegroundWindow and GetWindowTextA functions in
tandem to identify the window that is currently in use and
obtain the text from the window.
Figure 6.36 Examining relational context between functions with
IDA Pro
• Deeper examination of the function with IDA Pro reveals
that the specimen uses the SendMessageA function to
relay back the discovered window titles. This method
allows the malware to selectively monitor the infected
user’s browser activity, targeting URLs that relate to the
specified financial institutions.
Anticipated Network Trajectory, Digital Impression, and
Trace Evidence
• In addition to determining the manner in which a malware
specimen performs a nefarious function, IDA Pro should
be used in an effort to identify digital trace evidence
potentially introduced onto a victim system.
• In particular, using IDA Pro, locate functions and
references to files a malware specimen tries to download
and execute. For example, in Figure 6.37, the malware
makes a call to download a file. After acquiring the file,
the malware executes the newly acquired binary through
the WinExec function.
Figure 6.37 Identifying potential digital impression and trace
evidence with IDA Pro
• This information reveals the likely network trajectory of
the malware, in addition to digital impression and trace
evidence likely introduced on a victim system affected by
the malware.
• Intelligence gathered through this process should be
correlated with live response and post-mortem forensic
findings in an effort to identify remediation
considerations.
Advanced PE Analysis: Examining PE
Resources and Dependencies
In addition to examining the suspect program for
embedded entities and inspecting the assembly
instructions in IDA Pro, re-examine certain PE structures
in the suspect program to gain further insight into the
nature and purpose of the program.
PE Resource Examination
The Resource Section (.rsrc) of the PE file contains
information pertaining to the names and types of Resources
embedded in the file.89
• Described in the Microsoft winnt.h header file,90 the
Resource Section is a hierarchical structure consisting of
the header pointing to an array of Resource entries. In a
PE file, this structure is collectively known as the
IMAGE_RESOURCE_DIRECTORY, depicted in Figure 6.38.
Figure 6.38 Image_resource_directory
• Standard Resource types include icon, cursor, bitmap,
menu, dialog box, enhanced metafile, font, HTML,
accelerator table, message table entry, string table entry,
and version information, among others. (A
comprehensive listing of the predefined Resource types
can be found in the winuser.h header file).91
• If references in the strings of a malware specimen connote
indicia of image files, the Resource Section should be
thoroughly examined.
• Resource information gives the digital investigator a
window into the intentions of the attacker. For instance:
Did the attacker make the icon associated with a
malware specimen appear to be innocuous to give the
victim a sense of comfort to click on it?
victim a sense of comfort to click on it?
Are there embedded images in the Resources that reveal
how the code will behave once executed?
Do dialog boxes reveal the purpose and/or capabilities of
the malware or the language likely to be spoken by the
intended victim?
Was version information (described next) modified to
make the specimen appear to be trustworthy?
• As discussed in Chapter 5, certain metadata can be
extracted from Windows PE files. This information
includes version information from the Resource
Section, which is unique textual data that describes and
identifies an executable file.
• Version information is typically supplied by the user who
compiled the executable during the course of
compilation. Version information includes:
File version
Product version
Target OS
Language
Company name
File description
Internal name
Legal copyright
Legal trademarks
Original file name
Product name
A number of different PE analysis tools and Resource
editing tools can be effectively used to parse and extract the
editing tools can be effectively used to parse and extract the
contents of a target executable’s resources, including PE
Explorer, Resource Hacker,92 CFF Explorer,93 and XN
Resource Editor.94 Unlike many PE Resource analysis tools
that simply identify that the binary contains picture data and
displays American Standard Code for Information Interchange
(ASCII) encoding of binary data, PE Explorer enables the digital
investigator to probe the Resources and display actual
embedded images, if available.
• Loading a suspect program into a PE Resource analysis
tool, the digital investigator will be presented with a
listing of the various Resources in the binary. Most tools
provide for a hierarchical “drill down” navigation
capability, similar to that of Windows Explorer. In
exploring Resources, start in ascending order and slowly
“peel” through the available Resources. (See Figure
6.39.)
Figure 6.39 Navigating PE Resources
• In Figure 6.40, a dialog box Resource reveals that the
target malware, a Wemon Trojan specimen, contains a
“GETPASSWORD1” dialog box with Cyrillic
characters; the dialog box requests a password to be
entered. A Resource such as this is a good clue,
suggesting not only that the malware has a password
nexus, but that the attacker and/or intended recipient can
read Russian.
Figure 6.40 Examining the resources of a suspect executable
with XN Resource Editor
• Similarly, in the example shown in Figure 6.41, the target
specimen contains a RCDATA Resource with an
embedded image of a virtual keyboard and Portuguese
text requesting a debit card password.
Figure 6.41 Extracting an embedded resource image with PE
Explorer
• RCDATA Resources are raw data Resources for an
application that permit the inclusion of binary data
directly into an executable file.95 Delphi executables
typically contain RCDATA Resources, which include
Tforms. For a discussion regarding the nuances of Delphi
specimens, see the Delphi Executables text box, below.
An alternative to manually exploring PE Resources is
using a Resource extraction tool, such as NirSoft’s
ResourceExract,96 which allows the digital investigator to select
a target binary and copy certain Resources, such as icons,
bitmap images, and cursor entries, into a destination folder.
• This approach is certainly quicker, but a downside is that
it is not as methodical and thorough, and valuable
Resources such as RCDATA and version information
can be missed. (See Figure 6.42.)
can be missed. (See Figure 6.42.)
Figure 6.42 Extracting Resources from a suspect executable
with Resource Extract
Analysis Tip
Delphi Executables
In the field, the digital investigator will likely encounter malware
written in Delphi (a development environment for Microsoft
Windows), such as Banking Trojans and Rogue AntiVirus
variants. Delphi executables often contain artifacts resulting from
development and compilation in the Delphi environment. These
artifacts, such as form files (TForms), contain valuable clues into
a target specimen. Delphi form artifacts typically reside in the
RCDATA resources of a target executable. In addition to
exploring these artifacts in PE Resource viewer, the following
exploring these artifacts in PE Resource viewer, the following
tools and techniques allow the digital investigator to dig further
into a Delphi executable specimen:
Decompiling a Delphi Executable Specimen
A very powerful tool for analyzing Delphi executables is DeDe,
which allows the investigator to decompile a target Delphi
executable, reverting the binary into a native project directory,
including .pas (source) files, .dfm (Delphi form files), and .dpr
(Delphi) project files. After extracting the components of the
executable, DeDe provides for an intuitive navigation window,
allowing the digital investigator to parse the contents of the
program. Individual components can be viewed for further
information by selecting the respective component, such as a
form (http://www.softpedia.com/get/Programming/Debuggers-
Decompilers-Dissasemblers/DeDe.shtml).
Viewing Delphi Forms
DeDe also comes with a DFM (Delphi Form) Inspector,
allowing the digital investigator to examine the form files
associated with the target executable file. However, for viewing
form information, we find that a better suited tool is DFM Editor,
which is available for Windows 95/98/ME/NT
4.x/2000/XP/2003/Vista (http://www.mitec.cz/dfm.html). DFM
Editor is a form editor for Borland Delphi forms in both text and
binary format. A particular helpful feature of DFM editor is its
ability to extract forms from compiled executables and .dlls
through its extraction tool. Upon loading a suspect executable,
DFM Editor provides the digital investigator with “Resources”
and “Info” tabs. The information contained in the Resources
table reveals the form Resources identified and extracted from
the target executable, whereas the “Info” tab reveals the
components that the suspect executable contains, similar to the
components that the suspect executable contains, similar to the
navigation window offered in DeDe. Upon selecting a target
form, the DFM Editor provides for an object tree view
navigation pane, enabling the digital investigator to drill down
through objects on a granular level.
Dependency Re-exploration
In addition to exploring the Resource section of a suspect
program, the file dependencies of a suspect program should be
re-examined to identify modules that the specimen invokes to
support its functionality.
• For instance, during the course of parsing the assembly
instructions of a binary in IDA Pro, the digital
investigator may learn that the suspect program relies on
certain functions. By re-examining the target executable’s
file dependencies, it is possible to identify which
imported libraries support the necessary functions.
• As discussed in Chapter 5, a helpful tool for gaining a
granular view of file dependencies is Dependency
Walker.97
• Using the collective results of API monitoring, file system
monitoring, and static binary analysis with IDA Pro,
identify the .dll files that are invoked by a target malware
specimen to support required functionality.
• In Figure 6.43, the Banking Trojan examined earlier in
this chapter invokes user32.dll to support its required
DDE functionality, as well as the FindWindow and
SendMessage functions. Further, the specimen loads
kernel32.dll to support the FindFirstFile function,
kernel32.dll to support the FindFirstFile function,
which is required for querying the text files the program
searches for during runtime.
Figure 6.43 Examining the dependencies of a target executable
with Dependency Walker
• After identifying the modules and associated functions
invoked by a suspect program, the digital investigator
can spy on the program’s behavior in a more aggressive
manner, such as API hooking, as described below in the
following section.
Interacting with and
Manipulating the Malware
Specimen: Exploring and
Verifying Functionality and
Purpose
After identifying the manner and means in which a
target malware specimen functions, manipulate the
specimen or the lab environment in an effort to interact
with the specimen and verify its functionality.
Unlike other phases of analysis that involve monitoring,
data analysis, and extraction to understand the functionality of a
target malware specimen, this phase of analysis focuses on
thinking like the attacker. In particular, the focal point is how is
the malware specimen used and how its functionality is
invoked.
• To accomplish this task, the digital investigator can
manipulate a target malware specimen in the following
ways:
API hooking
Prompting trigger events
Using client applications
API Hooking
A technique that can be used to isolate and spy on specific
functions of a suspect program, and in turn, confirm our findings
regarding a program’s functionality, is API hooking, or
intercepting specific API calls.
• A useful tool that can be used to accomplish this task is
SpyStudio, which is developed by Nektra.98
• Unlike the .dll injection technique discussed earlier,
SpyStudio uses a proprietary API framework called the
Deviare API to intercept function calls, allowing the
digital investigator to monitor and hook applications in
real time.
• Recall from previous examples where we examined a
suspect Banking Trojan’s dependencies, which revealed
that the functions invoked by the specimen were
primarily provided by the imports user32.dll and
kernel32.dll. Further, from our inspection of the
specimen’s assembly instructions and our previous API
monitoring sessions, we learned that the program
accomplishes its nefarious purpose by using the
FindWindowA and SendMessageA functions and DDE
commands, among others. With this information
SpyStudio can be configured to insert a hook to monitor
required functions.
• As shown in Figure 6.44, a hook is inserted into the
DDECreateString HandleA command through
user32.dll. Immediately after placing the hook, the
output interface of SpyStudio scrolled with the
WWW_GetWindowInfo request.
WWW_GetWindowInfo request.
Figure 6.44 Intercepting the WWW_GetWindowInfo function with
SpyStudio
• The same method can be used to confirm the suspect
program’s use of the FindWindowA, SendMessageA,
GetWindowTextA.
• For example, in Figure 6.45, the output resulting from the
interception of calls for the FindWindowA function
identifies numerous financial institution Web sites that are
being monitored vigilantly by the specimen.
Figure 6.45 Intercepting the FindWindowA function with
SpyStudio
• SpyStudio enables the digital investigator to monitor
several hooked functions simultaneously, intercepting and
revealing the relational context and interplay between the
functions.
Prompting Trigger Events
Recall from earlier in the chapter that execution trajectory is
the behavior and interaction of the malicious code specimen with
the victim system and external network resources from the point
of execution through the life cycle of the infection. As a part of
the trajectory, triggering events are those events that invoke
behavior or functionality from a specimen.
behavior or functionality from a specimen.
• Trigger events may be caused by victim behavior on the
infected system (such as typing on the keyboard—
invoking a keylogging feature) or through the introduction
of digital trace evidence from a remote resource (such as
the download of additional malicious files that provide
instructions to the specimen).
• Armed with information gathered through dynamic and
static analysis, the digital investigator can engineer the
laboratory environment in an effort to replicate the
particular triggering events used by a target specimen.
Although triggering events are specific relative to a target
specimen, some examples include:
Opening and using a particular targeted client application
Checking for the existence of specific files on the victim
system
Replicating victim interaction with the system such as
opening browser windows
Typing information into a Web form
Navigation to certain URLs
Setting up additional network resources sought by the
specimen
• To emulate a malware specimen’s interaction with the
target URLs, one approach would be to copy the
content of the target Web sites using utilities like
HTTrack99 (Windows and Linux) or wget (Linux) and
host the content on a Web server in your malicious code
laboratory—in essence, allowing the specimen to interact
with the Web site offline and locally.100
• An alternative approach is to resolve the predefined
• An alternative approach is to resolve the predefined
domains and URLs to a Web server running in the
laboratory network. Although the content of the Web
sites will not be similar, at a minimum the URLs will
resolve, which may be enough to trigger a response from
the specimen.
Investigative Considerations
• Triggering events that relate to specific files on the victim
system emphasize the need for a holistic investigative
approach. In particular, where possible, the digital
investigator should examine the physical memory and
hard drives of the victim system to corroborate trigger
events and recover relevant associated artifacts.
Client Applications
Certain types of malware are controlled by the attacker with a
client application or command and control interface. Thus, to
fully replicate the functionality and use of these specimens, the
digital investigator will need to use these control mechanisms.
• Unfortunately, as these are typically “underground”
applications, they may not be easy to acquire.
Furthermore, even when client applications are available
for download from underground forums, they are often
modified by attackers to have additional backdoors and
malicious features in an effort to infect the system of the
malicious features in an effort to infect the system of the
individual who downloaded the program. Use extreme
caution when conducting this kind of research.
• If a “clean” and “reliable” version of client software can
be obtained through a malicious code research Web
site,101 install it for use on a separate laboratory system
in an effort to replicate the remote attacker.
• Once the client application has been configured for
adaptation in the laboratory environment, execute the
malware specimen in the victim laboratory system in an
effort to trigger the specimen to connect to the remote
client.
• Explore the nature and capabilities of the program by
delving deeper and assuming control over the victim
system through the malicious code specimen. Further, in
gaining control over the victim system execute available
commands and features from the “attacker” system in an
effort to evaluate the attack capabilities of the specimen
and client (see Figure 6.46).
Figure 6.46 Interacting with a victim laboratory system using the
Poison Ivy client application
Event Reconstruction and
Artifact Review: Post-Run Data
Analysis
After analyzing a suspect malware specimen, and
gaining a clearer sense of the program’s functionality and
shortcomings, reconstruct the totality of the forensic
artifacts relating to the malicious code specimen. Examine
network and system impression evidence to determine the
impact the specimen made on the system as a result of
being executed and utilized.
Correlate related artifacts and try to reconstruct how the
specimen interacted with the host system and network. In
particular, examine digital impression and trace evidence
collected through both passive and active monitoring tools during
the course of execution trajectory, including:
• Passive monitoring artifacts
File system
Registry
Processes
• Active monitoring artifacts
Processes
File system
Registry
API calls
API calls
Network activity
• Physical memory artifacts
Example Event Reconstruction Case Scenario
To gain a clearer understanding of the Event Reconstruction
process, an example case scenario will be used for
demonstrative purposes. In particular, the investigative steps and
artifacts examined will be through the lens of analyzing the impact
that a Trojan crimeware specimen made on an infected victim
system. The basic facts of the scenario include:
• During dynamic and static analysis of the target specimen,
you determined it to be modular malicious code —
malware that has limited functionality requiring the
download of other files for additional functionality. Your
analysis reveals that the malware tries to connect to
remote resources for additional files.
• You learn that the execution trajectory on the victim
system created numerous new files and processes.
Further, the specimen required substantial environment
adjustment and emulation to complete trajectory and its
infection life cycle.
• To conduct your analysis, the sample Trojan crimeware
specimen was executed on an emulated victim laboratory
system (Windows XP SP2 VMware Guest), and a
server system (Ubuntu 10.10 VMware Guest) was
established to facilitate environment emulation and
trajectory chaining.
• Using the facts of this example case scenario as the basis,
the totality of the forensic artifacts relating to the
malicious code specimen can be reconstructed following
the guidelines in this section.
the guidelines in this section.
Passive Monitoring Artifacts
After executing and interacting with a malicious code specimen
on an infected victim system, assess the impact that the specimen
made on the system. In particular, compare the post-execution
system state to the state of the system prior to launching the
program (the “pristine” system state).
• Recall that the first step prior to executing a malicious
code specimen is to establish a baseline system
environment by taking a snapshot of the system state
using a host integrity or installation monitoring program.
• Once the dynamic analysis of the malware specimen is
completed, examine the post-runtime system state by
comparing it against the pre-run snapshot taken with a
host integrity or installation monitoring tool.
• For example, after running the Trojan crimeware
specimen presented in the example scenario and
comparing system snapshots, the installation monitoring
utility InstallWatch captured the creation of directories,
executable files, and prefetch files on the victim system
(Figure 6.47).
Figure 6.47 File system changes captured with InstallSpy
Figure 6.47 File system changes captured with InstallSpy
• Correlate host integrity or installation monitoring results
with other digital impression and trace evidence
collection methods. For instance, referenced earlier in
the Execution Artifact Capture: Digital Impression and
Trace Evidence section, CaptureBat collects granular
details regarding a malware specimen’s behavior and the
associated digital impression evidence left on the file
system and in the Registry of the affected system.
• A review of the CaptureBat log resulting from the
execution of the Trojan crimeware specimen (Figure
6.48) details execution trajectory resulting in a newly
created malicious process, qeise.exe, and relational
context with explorer.exe, which suggests possible
process injection.
Figure 6.48 CaptureBAT log
Active Monitoring Artifacts
For holistic context, compare data collected through active
monitoring with passive monitoring data.
• Track process creation, file system, and Registry changes.
• Confirm digital impression and trace evidence on the
affected system.
• Identify any inconsistencies or anomalies between the
data sets.
Figure 6.49 reveals the file system and Registry activity of
malicious processes spawned by the Trojan crimeware
specimen, as captured by Process Monitor. Later in the
execution trajectory (Figure 6.50), the malicious process
qeise.exe injects explorer.exe.
Figure 6.49 File system and Registry activity captured during
Figure 6.49 File system and Registry activity captured during
active monitoring in Process Monitor
Figure 6.50 Active monitoring capturing process injection
Analyzing Captured Network Traffic
As a general principle, in examining the post-run network data
there are five objectives:
1. Get an overview of the captured network traffic contents
to get a thumbnail sketch of the network activity and
where to probe deeper.
2. Replay and trace relevant or unusual traffic events.
3 . Gain insight into network trajectory and associated
network impression and trace evidence.
4. Conduct a granular inspection of specific packets and
traffic sequences if necessary.
5. Search the network traffic for particular trends or entities
5. Search the network traffic for particular trends or entities
if needed.
There are a number of network analysis and packet
decoding tools for Windows that enable the investigator to
accomplish these tasks. Some of the more commonly used tools
for this analysis include:
• Wireshark (discussed earlier in the chapter)
• RUMINT (a network forensic visualization tool)102
• Network Miner (a network forensic analysis tool)103
Trace and compare network trajectory evidence with
resulting digital impression and trace evidence on the victim
system. This is particularly important when analyzing modular
malicious code that retrieves additional files from remote
resources.
• For example, during the examination of the sample Trojan
crimeware specimen, environment emulation was
conducted to facilitate the needs of the specimen. In
particular, a configuration file needed by the specimen
was hosted on the malware laboratory Linux server,
enabling the Trojan to download it and accomplish the
execution trajectory and infection life cycle. This
sequence is a good example of digital trace evidence
introduced onto the victim system.
• After downloading the configuration file, substantial digital
impression evidence manifested on the victim system,
including the creation of new files. Further, the network
trajectory shifted, yet again, in an effort to report to
Web-based command and control structure.
• To gain an overview of network trajectory in relation to
the totality of system events and resulting digital
impression evidence, use a network forensic visualization
solution such as RUMINT.
RUMINT provides the digital investigator with the ability
to view network traffic through a myriad of different
visualization schemas, providing alternative context. This
is particularly useful when a series of environment
adjustments are made on the victim system.
Visualization schemas can be used in tandem, as shown
i n Figure 6.51. The Text Rainfall view reveals
reconstructed network traffic, including domain name
queries and a GET request for the configuration file
hosted on the Linux server. The Byte Frequency view
provides the digital investigator with a high-level view of
protocol activity and data transmission, which is helpful
for identifying data network traffic patterns.
Figure 6.51 Using RUMINT to visualize network traffic
Another post-execution event reconstruction task is collective
review of the API calls made by a suspect program, and how the
calls relate to the other artifacts discovered during the course of
analysis or during Event Reconstruction. Tools such as TracePlus
provide an API call capture summary, which is a great overview
for identifying the ratio and types of calls made by a malware
specimen during runtime.
Physical Memory Artifacts
Physical Memory Artifacts
Physical memory can contain a wide variety of digital
impression and trace evidence, including malicious executables,
associated system-related data structures, and remnants of
malicious events. Within the scope of Event Reconstruction, the
goals of memory analysis include:
• Harvest available metadata including process details,
network connections, and other information associated
with the malware specimen for analysis and comparison
with other digital impression and trace evidence identified
on the infected laboratory system.
• Perform keyword searches for any specific, known
details relating to the malware specimen that was
examined.
• Look for common indicators of malicious code including
memory injection and hooking (see Figure 6.52,
depicting the detection of process injection into
explorer.exe during the runtime of the Trojan
crimeware specimen).
Figure 6.52 Process injection detected with the Responder
Professional Digital DNA feature
• For each process of interest, recover the executable code
• For each process of interest, recover the executable code
from memory for further analysis.
• For each process of interest, extract associated data from
memory, including related encryption keys and captured
data such as usernames and passwords.
• Extract contextual details such as URLs, MFT entries,
and Registry values pertaining to the installation and
activities associated with malicious code.
• Perform temporal and relational analysis of information
extracted from memory, including a time line of events
and a process tree diagram.
Digital Virology: Advanced
Profiling Through Malware
Taxonomy and Phylogeny
After gaining a clearer picture about the nature,
purpose, and capabilities of a malicious code specimen
through dynamic and static analysis, catalog and classify
the specimen with the aim of identifying phylogenetic
relationships to other specimens.
Creating and maintaining a malware repository of
cataloged and classified specimens is a valuable and
recommended feature in the digital investigator’s malware
laboratory. Carefully classified malware in the repository
provides a powerful resource for comparing and correlating new
specimens.
A repository of cataloged and classified specimens
supports several benefits in a digital investigator’s malware
laboratory.
• Formalizes the information captured and reported for
each specimen of malware, increasing the consistency of
analysis and reporting.
• Knowledge reuse when analysis has already been
performed can be applied to a new specimen, saving
time and effort on malware analysis, particularly when
encryption and other challenging features are involved.
• Exchanges details about malware with other digital
investigators in a format that is intelligible and
immediately useful for their analysis.
• Reveals trends in malware infections that may be useful
for protecting against future attacks.
• Finds relationships between related malware that may
provide insight into their origin, composition, and
development. Such linkage may also reveal that a single
group of attackers is responsible for multiple incidents.
Malware taxonomy or cataloging and classifying a
malware specimen means correlating the information gathered
about the specimen through file profiling, behavioral and static
analysis, and, in turn, identifying the nature, purpose, and
capabilities of a specimen. This enables the digital investigator to
group the specimen into a category of like specimens. Malware
taxonomy borrows from traditional biological taxonomy, or the
science of classifying organisms.
• In some instances, going beyond classification and
endeavoring to identify the evolution, similarity in
features, and structure of a particular malware specimen
—or relationships to other specimens—is needed. For
example, during the course of an investigation you may
learn that a victim has been under attack over the course
of several months, and the attacker’s malware has
become more sophisticated as a result of
countermeasures attempted by the victim. Examining
phylogenetic relationships between all of the specimens
may identify important interrelationships and indicia of
evolution in the malware.
• In biology, phylogenetics is the study of evolutionary
relation among various groups of organisms.104 Applied
to malware, phylogeny is an estimation of the
evolutionary relationships between a set of malware
specimens.105 There have been a number of studies on
malware phylogeny modeling, as detailed in the following
malware phylogeny modeling, as detailed in the following
table.
Researcher(s) Research Model
Hayes,
Walenstein, and
Lakhotia
Evaluation of Malware
Phylogeny Modeling
Systems Using Automated
Variant Generation106
Automated variant
generation
Cesare and
Xiang
Classification of Malware
Using Structured Control
Flow107
Structured control
flow
Xiang
Flow107
flow
Wagener, State,
and Dulaunoy
Malware Behavior
Analysis108
Behavioral
analysis
Carrera and
Erdélyi
Digital Genome Mapping-
Advanced Binary
Malware Analysis109
Graph
similarity/clustering
Rieck, Holz,
Willems, Dussel,
and Laskov
Learning and Classification
of Malware Behavior110
Machine learning
techniques
Ye, Chen, Li,
and Jiang
Automatic Malware
Classification Using
Cluster Ensemble111
Hybrid
hierarchical
clustering (HHC)
Walenstein,
Venable, Hayes,
Thompson, and
Lahkhotia
Exploiting Similarity
Between Variants to
Defeat Malware112
“Vilo” method
Karim,
Walenstein, and
Lakhotia
Malware Phylogeny using
Maximal Π Patterns113
Π patterns in
string contents
Gupta, Kuppili,
Akella, and
Barford
An Empirical Study of
Malware Evolution114
Text mining and
pruning
On a practical level there are many investigative steps
that can be taken to comparatively analyze the contents and
functionality of malicious code specimens. These steps include:
• Context Triggered Piecewise Hashing (CTPH)
• Identifying textual and binary indicators of likeness
• Comparing function flowgraphs
• Process memory trajectory comparison
• Visualization
• Behavioral profiling and classification
• Behavioral profiling and classification
Context Triggered Piecewise Hashing
Recall from Chapter 5 that CTPH computes a series of
randomly sized checksums for a file, allowing file association
between files that are similar in file content but not identical.
• In the context of malware taxonomy and phylogeny,
sdeep, a file-hashing tool that utilizes CTPH, can be used
to query suspicious file specimens in an effort to identify
homologous files.115
• One scanning option, as demonstrated in Figure 6.53, is
to use the recursive (-r), bare (-b), and “pretty matching
mode” (-p) switches against a directory of malware
specimens; the output cleanly displays matches between
files.
Figure 6.53 Comparing a directory of files with ssdeep
Textual and Binary Indicators of Likeness
Another method the digital investigator can use to conduct
taxonomic and phylogenetic analysis of malware specimens is
through identifying similar embedded artifacts—textual or
binary information—in files. Two tools that can be used to assist
in this endeavor are YARA116 and HBGary’s FingerPrint.117
YARA is a flexible malware identification and
classification tool developed by Victor Manuel Álvarez of
Hispasec Systems. Using YARA, the digital investigator can
create rules that describe target malware families based upon
textual or binary information contained within specimens in those
families.118
• YARA can be invoked from the command line as a
stand-alone executable or the functionality can be
integrated into the digital investigator’s own Python
scripts through the yara-python extension.119
• The YARA rule syntax consists of the following
components:
Rule identifier: The rule “name” that typically describes
what the rule relates to. The rule identifier is case
sensitive and can contain any alphanumeric character
(including the underscore character), but cannot start
with a digit, and the identifier cannot exceed 128
characters.120
characters.120
String definition: Although not required for a rule, the
string definition is the section of the rule in which unique
textual or hexadecimal entities particular to a specimen
are defined. The string definition acts as a Boolean
variable for the rule condition.121
Condition: The rule condition is the logic of the rule; if
files queried with the rule meet the variables in the
condition, the files will be identified as matches.
• Rules can be written in a text editor of choice and saved
as “.yara” files.
• YARA rules can range from simple to very complex; it is
highly recommended that the digital investigator
familiarize himself with the YARA User’s Manual
(currently version 1.6) to gain a full understanding of
YARA’s functionality and limitations.122
• In Figure 6.54, a rule was created in an effort to identify
and classify Wemon Trojan specimens. 123 Recall from
the section Advanced PE Analysis Examining PE
Resources and Dependencies that the Wemon Trojan
contains unique PE resource artifacts. Further, extracted
strings reference a PE file (svchost.exe) and various
dynamic link libraries, when taken in totality, are unique
to the Wemon malware family.
Figure 6.54 A YARA rule to detect the Wemon Trojan
• After creating the rule and saving it as “wemon.yara,” a
directory of numerous malware specimens was queried
with YARA, applying the rule. The results of the query
are shown in Figure 6.55; seven different specimens
were identified and classified.
Figure 6.55 Results of scanning a directory with a YARA rule
Other Tools to Consider
Textual and Binary Indicators of Likeness
Scout Sniper (scoutsniper) is a command-line wrapper
program for YARA and ssdeep that can be used to scan target
directories on local and remote systems
(http://www.cutawaysecurity.com/blog/scout-sniper).
Further tool discussion and comparison can be found in the
Tool Box section at the end of this chapter.
The digital investigator can further probe malware
specimens for indicia of phylogenetic relationships, such as string
and byte patterns by using HBGary’s FingerPrint.124
and byte patterns by using HBGary’s FingerPrint.124
• Written in C#, FingerPrint is a framework (command-line
utility and XML database) for scanning portable
executable files and extracting attributive embedded
artifacts such as strings and metadata. Figure 6.56
displays the information extracted and cataloged for each
target file.
Figure 6.56 Probing a malicious code specimen with FingerPrint
• Results of the each scan are saved in a database named
“scan_history.xml,” which can be used to further query
and compare new specimens against previous
specimens.
• FingerPrint can be used to scan single or multiple files in a
variety of ways either against other specimens or the
scan history database. A command reference is provided
scan history database. A command reference is provided
in the following table.
Switch Function
fp [file or
directory] Acquire a dump of FingerPrint data
fp -c [file
1] [file 2] Compare two files
fp -c
[directory]
Scan a directory and compare it to the scan
history, showing a summary of results
fp -r
[directory] Recursively scan a directory
fp -db [file
1]
Compare a file to the scan history, only showing
> 80% matches
fp -dball
[file 1]
Compare a file to the scan history, showing all
comparisons
• The FingerPrint comparison scanning options are very
valuable toward identifying possible phylogenetic
relationships between targeted specimens. Figure 6.57
displays an example comparison of two different Wemon
Trojan specimens using the –c option.
Figure 6.57 Comparing malicious code specimens with
FingerPrint
• The resulting output provides a detailed report of matched
and unmatched variables between the two specimens;
the matches and mismatches are calculated and weighted
and a final match percentage is rendered.
• In addition to the native scanning capabilities, FingerPrint
is extendable through user-generated plug-ins called
“FingerPrints.” Details regarding how to create a
“FingerPrints.” Details regarding how to create a
FingerPrint are included in the “readme” file packaged
with FingerPrint.
Function Flowgraphs
Using ssdeep, YARA and FingerPrint, malicious code
specimens can be triaged, classified, and cataloged based upon
file content. Deeper comparison and exploration of similar
malware specimens can be accomplished by conducting a diff
(short for difference) of the specimens.
By diffing files, the digital investigator can identify
common features and functions between specimens, and
conversely (and perhaps more important) identify distinctions. In
particular, through this process, evolutionary factors such as
feature accretion125—or added features and capabilities in
malware—can be identified and considered toward establishing
phylogenetic relationships. Using BinDiff,126 an IDA Pro plug-in,
the digital investigator can diff two target executable file
specimens.
• One of the most powerful features of BinDiff is the Graph
GUI, which displays side-by-side comparative
flowgraphs of target code contents.
• BinDiff assigns a signature for each function in a target
executable based upon the number of codeblocks,
number of edges between codeblocks, and number of
calls to subfunctions.127
• Once the signatures are generated for the two target
executables, matches are created through a myriad of
Function Matching and Basicblock Matching
algorithms.128
algorithms.128
• BinDiff renders Similarity and Confidence values for
each matched function (shown in Figure 6.58) as well as
for the whole executable file.129
Figure 6.58 BinDiff plug-in interface in IDA Pro
Pre-processing
• Prior to invoking BinDiff, load the respective target
executable specimens into IDA Pro. Save the IDA
Database file (.idb) associated with the target
executables.
• In IDA Pro, open the IDA Database file for the first
target executable specimen.
• Using Figure 6.59 as a visual reference, BinDiff can be
invoked through the following steps:
1. Go to the Edit option in the IDA toolbar.
2. Select the Plugins menu.
3. Select the “Zynamics Bindiff” plug-in.
4. By virtue of selecting the BinDiff plug-in, the Diff Menu
box will appear. Click on the “Diff Database” box in the
menu; this will open Windows Explorer.
5. Select a second IDA Database file for comparison.
Figure 6.59 Selecting target files for comparison in BinDiff
• Upon loading the second target IDA Database file, four
additional tabs are presented in IDA: Matched
Functions, Statistics, Primary Unmatched, and
Secondary Unmatched.
Displaying Flowgraphs in the BinDiff Graph GUI
Displaying Flowgraphs in the BinDiff Graph GUI
• Upon identifying a function of interest, right-click on the
function and select “Visual Diff,” as shown in Figure
6.60. This invokes the BinDiff Graph GUI.
Figure 6.60 Invoking the BinDiff Graph GUI
The BinDiff Graph GUI displays the function flowgraphs
for the respective target executable files in an intuitive dual-paned
interface, enabling the digital investigator to navigate the target
flowgraphs contemporaneously, as shown in Figure 6.61.
Figure 6.61 BinDiff Graph GUI
• Using the mouse wheel, the flowgraphs can be zoomed in
or out.
• By “zooming out,” a high-level visualization of the function
flows is displayed, which is useful for visually comparing
the likenesses or contrasts in data. Similarly, a flowgraph
overview “map” for the respective target executables is
provided.
• By “zooming in,” the disassembled code is displayed in
detail.
• The graphical manifestation of the flowgraph can be
viewed in three distinct layouts to provide slightly
different context of the graphs: hierarchic, orthogonal,
and circular.
Process Memory Trajectory Analysis
As discussed in Chapter 5, malware in the wild often presents
itself as armored or obfuscated, primarily to circumvent network
security protection mechanisms like anti-virus software and
intrusion detection systems. Even if a specimen could be linked
to a certain family of malware based upon its content and similar
functions, obfuscation code such as packing may limit the digital
functions, obfuscation code such as packing may limit the digital
investigator’s ability to extract any meaningful data without first
deobfuscating the file.
• A technique that allows the digital investigator to compare
the contents and trajectory of deobfuscated malicious
code in memory during runtime is process memory
trajectory analysis, or the acquisition and comparison
of the process memory space associated with target
malware specimens while executed and resident in
memory. This technique is most effective when the
respective specimens manifest as distinct new processes
rather than injection into pre-existing processes.
• After executing the target specimen, locate the newly
spawned process in a process analysis tool that offers
process dumping functionality, and dump the process to
disk.
• For example, in Figure 6.62, using LordPE, the target
process is identified and selected in the tool’s process
viewer. The process dumping menu is invoked by right-
clicking on the target process; select “dump full” and
save the newly dumped process to disk.
Figure 6.62 Dumping process memory with LordPE
• Conduct the same process memory collection method for
each specimen of interest; determine the file size and
hash values associated with the process memory dump
files. As shown in Figure 6.63, the processes dumped
with LordPE have an identical file size but distinct MD5
hash values.
Figure 6.63 MD5 hash values of suspect process memory
• Query the respective process memory files with ssdeep in
an effort to determine similarity.130
As shown in Figure 6.64, applying ssdeep with the
recursive (-r), bare (-b), and pretty matching mode (-p)
options against the target specimen files prior to
execution, the files were scored as 96 (out of 100) in
similarity.
Figure 6.64 Querying target specimens and resulting process
memory dumps with ssdeep.
Conversely, in querying the respective process memory
files associated with the target malware specimens, the
files were scored 100 in similarity, revealing that the
specimens are the same once executed.
Visualization
As discussed in Chapter 5, visualization of binary file contents
provide the digital investigator with a quick reference about the
data distribution in a file. In addition to identifying obfuscation,
comparing data patterns of multiple suspect files can also be
used as a method of identifying potential like files based upon
visualization of data distribution.
• Target malware executable files can be viewed through a
variety of visualization schemas using BinVis.131
• To select an executable file for analysis, use the BinVis
toolbar, and select “File” “Open.”
• Once the executable is loaded into BinVis, choose a data
visualization schema in which to view the file using the
“View” toolbar option.
• BinVis has seven different data visualization schemas in
addition to a hexadecimal viewer and a strings viewer.
1. Byte Plot: Maps each byte in the file to a pixel in the
display window.
2. RBG Plot: Similar to Byte Plot but uses Red, Green, and
Blue pixels (3 bytes per pixel).
3. Bit Plot: Maps each bit in the file to a pixel in the display
window.
4. Attractor Plot: Visual plot display based upon chaos
4. Attractor Plot: Visual plot display based upon chaos
theory.
5 . Dot Plot: Displays detected sequences of repeated
bytes contained within a file.
6 . Byte Presence: A condensed version of Byte Plot
causing data patterns to be more pronounced.
7 . ByteCloud: Visual cloud of bytes generate from file
contents.
• A powerful feature of BinVis is coordinated windows—
the interplay between the various data display windows;
clicking on a target data region in one viewing pane
causes the data in the other open viewing panes to adjust
and transition to the same region.
• Another novel aspect of BinVis is the navigator feature.
Based upon a “VCR motif,” this interface allows the
digital investigator to navigate forward or backward
through the visualized data.
• In the example displayed in Figure 6.65, three malicious
code specimens were examined—two of which were
helpfile.exe and winsrv.exe. Visualizing the
executables through the BinVis Byte Presence view, the
two similar specimens are quickly discernable from the
third, dissimilar specimen.
Figure 6.65 Using BinVis to visually identify similar files
Visualization is also useful for examining the execution of
a malware specimen. As mentioned in the “Other Tools to
Consider: Automated Unpackers” text box earlier in the chapter,
Ether is a set of patches and applications that have been
customized for the Xen hardware virtualization framework to
transparently monitor malware during runtime; the results of the
monitoring are saved as a trace file.
Danny Quist of Offensive Computing developed the
Visualization of Executables for Reversing and Analysis (VERA)
architecture as a means to interpret Ether sessions and visually
represent the execution and flow of target executable
specimens.132 VERA can be used to visually compare the
runtime trajectory of malicious executable specimens toward the
effort of identifying phylogenetic relationships between
specimens.
• To process and visualize the Ether trace of a target
malicious executable, load the resulting Ether trace file
into VERA, and, in turn, provide the original executable
file.
• Upon processing the trace file, VERA generates two
graph files (.gml) called “All Addresses” (renders all
addresses in the executing specimen) and “Basic Block”
(renders the beginnings and ends of basic blocks).
• Upon selecting the graph file, VERA visually displays the
execution and flow of the target executable in the main
viewing pane. VERA provides the digital investigator a
series of mouse functions to “zoom in,” “zoom out,” and
navigate the results.
• As displayed in Figure 6.66, two similar Trojan horse
specimens are compared in distinct VERA sessions,
revealing very similar execution and runtime behavior.
This is valuable information toward cataloging and
qualifying phylogenetic relationships between specimens.
Further, a close-up of addresses within the specimen’s
runtime flow can be seen in the callout box.
Figure 6.66 Using VERA to visualize execution traces
Behavioral Profiling and Classification
In addition to comparing the visualized runtime trajectory of
In addition to comparing the visualized runtime trajectory of
target executables, the runtime behavioral profile of executables
can also be used as a method of identifying similar specimens.
• Malware behavioral profiles can be classified with
Malheur,133 a framework for automatic analysis of
malware behavior. Malheur is a command-line tool that
can be compiled on Linux, Macintosh OS X, and
OpenBSD platforms using the standard compilation
procedure for GNU software.134
• Malheur processes data sets —reports of malware
behavior recorded and compiled from the
CWSandbox/GFI SandBox.135 malware analysis
sandbox and into Malware Instruction Set (MIST)
format.136 MIST format is not intended for human
readability; rather, it is a generalization of observed
malware behavior specialized for machine learning and
data mining.
• Data sets can be submitted into Malheur as a directory or
a compressed archive (tar.gz, .zip, .pax, .cpio)
containing the textual reports for analysis.
Custom data sets can be created by the digital
investigator by converting reports from CWSandbox
using the cws2mist.py and mist2malheur.py Python
scripts associated with the project.137
A repository of data sets is maintained by the University
of Mannheim, Laboratory for Dependable Distributed
Systems, on their Mwanalysis Web site.138
• Malheur conducts four basic types of analysis:
Extraction of prototypes: Identifies and extracts a
subset of prototypes, or reports that are typical for a
group of homogenous behavior and represent the totality
group of homogenous behavior and represent the totality
of the larger reports corpus.139
Clustering of behavior: Identifies groups (clusters) of
reports containing similar behavior, allowing for the
discovery of unique classes of malware.140
Classification of behavior: Previously processed report
clusters can be further analyzed through classification,
or assigning unknown behavior to known groups of
malware. Through this method, Malheur can identify and
categorize unique malware variants.141
Incremental analysis: Malheur can be calibrated to
process (cluster and classify) reports in “chunks,”
reducing system resource requirements. This mode of
analysis is particularly beneficial for long-term
implementation of Malheur, such as automated
application of Malheur against regular malware feeds
from honeypot sensors.142
• A data set can be input into Malheur and processed using
the following steps:
1. Invoke malheur.
2. Use the –o (output) switch and identify the name of the
analysis output file (e.g., in Figure 6.67, the output file is
named out.txt).
Figure 6.67 Performing a clustering of a data set with Malheur
3. Select the action to be conducted. An action is the type
of analysis applied to the target data set. Actions include:
Action Result
distance Computes a distance matrix of the data set
prototype
Determines a set of prototypes representing the
target data set
cluster Clusters the data set
classify Classifies a data set
increment Performs incremental analysis of data set reports
protodist Computes a distance matrix for prototypes
4 . Incrementally apply analytical actions. For instance,
clustering of a data set must be conducted prior to
classification. Similarly, when clustering, Malheur
automatically extracts prototypes prior to conducting
cluster analysis, as shown in Figure 6.67.
5. Generated analytical results are saved as text files in the
5. Generated analytical results are saved as text files in the
Malheur home directory, which by default is ~/.malheur
(located in the user’s home directory).
6. The textual results can be visualized with custom Python
scripts (dynamic_threadgraph .py;
dynamic_treemap .py; static_threadgraph .py;
and static_treemap .py), which were developed
for Malheur and associated research projects.143
Conclusion
• Carefully consider and plan the malware laboratory
environment to ensure success during the various phases
of analysis. Establish a flexible, adjustable, and revertible
environment to capture the totality of a target specimen’s
execution trajectory and infection life cycle.
• To gain a holistic understanding of a target malware
specimen, dynamic and static analysis techniques are
often used inextricably. Deobfuscation, extracting
embedded artifacts, identifying trigger events, and
understanding execution and network trajectory may
require repeated and alternating uses of dynamic and
static techniques. Maintain detailed documentation of the
steps taken during the course of analysis. Refer to the
Field Notes at the end of this chapter for documentation
guidance.
• During the course of dynamic analysis, use passive and
active monitoring tools and other techniques to collect
digital impression and trace evidence. Such evidence,
when collectively examined along with results of dynamic
and static analysis, will elucidate the nature, purpose, and
functionality of a suspect program.
• Catalog and classify malicious code specimens in the
• Catalog and classify malicious code specimens in the
repository to compare, correlate, and identify
relationships between malware. Phylogenetic
relationships between specimens may provide insight into
their origin, composition, and development. Correlative
analysis of archived specimens may also reveal trends in
malware infections that may be useful for protecting
against future attacks.
Pitfalls to Avoid
Failure to establish an environment baseline
prior to examining a malware specimen
Analysis of a post-runtime system state without
comparison to a system baseline makes identifying
system changes challenging.
Before beginning an examination of the malicious code
specimen, establish a baseline environment by taking a
“snapshot” of the system that will be used as the “victim”
host on which the malicious code specimen will be
executed.
Implement a utility that allows comparison of the state
of the system after the code is executed to the pristine or
original snapshot of the system state. In this way,
changes made to the baseline (original) system state can
be quickly and accurately identified.
Incomplete evidence reconstruction
Limited or incomplete evidence reconstruction prevents
a holistic understanding of the nature, purpose, and
capabilities of a malicious code specimen. Further,
without fully reconstructing the artifacts and events
associated with the dynamic analysis of a malicious code
specimen, the digital investigator will have limited insight
into the impact the specimen makes on a victim system.
Fully examine and correlate data collected through
active and passive monitoring techniques to gain a
complete understanding about the malicious code
specimen’s capabilities and its effect on a victim system.
Take detailed notes, not only for specific monitoring
processes and results, but for the totality of the evidence
and how each evidentiary item interrelates (or does not
relate). Consult the Field Notes located at the end of this
chapter for additional guidance and a structured note-
taking format.
Incorrect execution of a malware specimen
Ineffectively executing a target malware specimen can
adversely impact all dynamic analysis investigative
findings.
Execution of a target specimen is often contingent upon
file profile. Unlike Portable Executable (PE) files that can
be invoked through other tools, such as installation
monitors or API monitors, malicious document files such
as PDFs, MS Office files, and MS Compiled Help
(CHM) files typically require the digital investigator to
manually open and execute a target file by double-
clicking on it.
Similarly, some malware specimens require user
interaction, such as mouse clicks through dialog boxes to
fully execute. A common example of this is rogue (fake)
anti-virus or scareware. Thus, statically executing such a
specimen through an installation monitor will not fully
capture the specimen’s execution trajectory, behavior,
and functionality.
Solely relying upon automated frameworks
or online sandbox analysis of a malware
specimen
Although automated malware analysis frameworks can
provide insight into the nature of identified malicious
code, they should not be solely relied upon to reveal the
purpose and functionality of a suspect program.
Conversely, the fact that automated analysis of a
malware specimen does not reveal indicia of infection
does not mean that it is innocuous.
Online malware sandbox analysis of a target or “similar”
malware specimen can be helpful guidance, but it should
not be considered dispositive in all circumstances.
Third-party analysis of a similar malware specimen by a
reliable source can be an incredibly valuable resource,
and may even provide predictors of what will be
discovered in your particular specimen.
This correlative information should be considered in the
totality of your investigation, but it should not replace
thorough independent analysis.
Submitting sensitive files to online analysis
sandboxes
Do not submit a malware specimen that is the crux of a
sensitive investigation (i.e., circumstances in which
disclosure of an investigation could cause irreparable
harm to a case) to online analysis sandboxes in an effort
not to alert the attacker.
By submitting a malware specimen to a third-party Web
site, you are no longer in control of that specimen or the
data associated with that specimen. Savvy attackers
often conduct extensive open source research and
search engine queries to determine if their malware has
been detected.
The results relating to a submitted specimen to an online
malware analysis service are publicly available and easily
discoverable. Many portals even have a search function.
Thus, as a result of submitting a target malware
specimen, the attacker may discover that his malware
and nefarious actions have been discovered, resulting in
the destruction of evidence and potentially damaging
the destruction of evidence and potentially damaging
your investigation.
Failure to adjust the laboratory
environment to ensure full execution
trajectory
The behavior and interaction of the malicious code
specimen with the victim system and external network
resources will likely not be revealed if the digital
investigator does not adjust the laboratory environment
based upon the specimen’s trajectory requirements.
Through adjusting the malware lab environment and
providing the resources that the specimen needs, the
digital investigator can conduct trajectory reconstruction
and re-enact the manner and path the specimen takes to
successfully complete the life cycle of infection.
Perpetuating the infection life cycle and adjusting the
laboratory environment to fulfill trajectory is a process
known as trajectory chaining; be certain to document
each step of the trajectory and the associated chaining
steps.
steps.
To facilitate trajectory chaining, accommodate the
sequential requests made by the suspect program.
Failure to examine evidence dynamics
during and after the execution of a malware
specimen
Do not make investigative conclusions without
considering the totality of evidence dynamics.
One of the primary goals of forensic analysis is to
reconstruct the events surrounding crime. Three common
analysis techniques that are used in crime reconstruction
are temporal, functional, and relational analysis.
The most common known form of temporal analysis is
the time line.
The goal of functional analysis is to understand what
actions were possible within the environment of the
malware incident, and how the malware actually behaves
within the environment (as opposed to what it was
capable of doing).
capable of doing).
Relational analysis involves studying how components
of malware interact, and how various systems involved in
a malware incident relate to each other.
Insight into the evidence dynamics created by a target
malware specimen can be acquired during active
monitoring as well as post-run evidence reconstruction,
such as the examination of passive monitoring data and
collected digital impression and trace evidence.
Failure to examine the embedded artifacts
of a target malware specimen after it is
extracted from obfuscation code
Critical clues embedded in a target malware specimen
can be missed if the specimen is not deeply examined
after it is extracted from obfuscation code. Failure to
gather this information can adversely affect investigative
findings and how to proceed with the larger investigation.
After removing a malware specimen from its
obfuscation code, harvest valuable information from the
contents of the file which would potentially provide
valuable insight into the nature and purpose of the
malware, such as strings, symbols, file metadata, file
dependencies, PE structure, and contents.
To gather additional meaningful clues that will assist in
the continued analysis of a malicious code specimen,
consider conducting a full file profile (including digital
virology processes) of the deobfuscated specimen.
Selected Readings
Books
1. Eagle C. The IDA Pro Book: The Unofficial Guide to
the World’s Most Popular Disassembler San Francisco,
CA: No Starch Press; 2008.
2. Ligh M, et al. Malware Analyst’s Cookbook and DVD:
Tools and Techniques for Fighting Malicious Code New
York: Wiley; 2010.
3. Malin C, Casey E, Aquilina J. Malware Forensics:
Investigating and Analyzing Malicious Code Burlington,
MA: Syngress; 2008.
4. Skoudis E, Zelster L. Malware: Fighting Malicious Code
Upper Saddle River, NJ: Prentice Hall; 2003.
5. Szor P. The Art of Computer Virus Research and
Defense Mountain View, CA: Symantec Press; 2005.
Paper
1. Bayer U, Kirda E, Kruegel C. Improving the
Efficiency of Dynamic Malware Analysis 2010.
2. Beuacamps P, Gnaedig I, Marion J. Behavior
Abstraction in Malware Analysis 2010.
3. Bilar D. Statistical Structures: Fingerprinting
Malware for Classification and Analysis 2008.
4. Brand M. Forensics Analysis Avoidance Techniques
of Malware 2007.
5. Hu X, Chiueh T, Shin K. Large-Scale Malware
Indexing Using Function-Call Graphs 2009.
6. Islam R, et al. Classification of Malware Based on
String and Function Feature Selection 2010.
7. Kang M, Poosankam P, Yin H. Renovo: A Hidden
Code Extractor for Packed Executables In WORM
’07 2007.
8. Kinable J, Kostakis O. Malware Classification Based on
Call Graph Clustering. Journal in Computer Virology.
Call Graph Clustering. Journal in Computer Virology.
2011;Volume 7.
9. Leder F, Steinbock B, Martini P. Classification and
Detection of Metamorphic Malware Using Value Set
Analysis 2009.
10. Park Y. Fast Malware Classification by Automated
Behavioral Graph Matching 2010.
11. Royal P, et al. PolyUnpack: Automating the Hidden-
Code Extraction of Unpack-Executing Malware
2006.
12. Sathyanarayan V, Kohli P, Bruhadeshwar B.
Signature Generation and Detection of Malware
Families 2008.
13. Yegneswaran, V. et al. (2008) Eureka: A Framework
for Enabling Static Analysis on Malware. Technical
Report Number SRI-CSL-08-01, SRI Project 17382.
14. Zhao H, et al. Malicious Executable Classification
Based on Behavioral Factor Analysis 2010.
1 For more information about VirtualBox, go to
http://www.virtualbox.org/.
2 Unless an examination or experiment is specific to Vista
or Windows 7, Windows XP is typically used as a
baseline victim platform by malicious code researchers
simply because it is still currently the predominant OS
deployed on workstations. See
http://blogs.techrepublic.com.com/it-numbers/?p=122.
3 For more information, go to http://www.f-secure.com/v-
descs/im-worm_w32_skipi_a.shtml.
4 Unfortunately, the Web site that offered Winalysis is no
longer operational, but with a little searching on the
Internet, the program can be found on many software
review sites, such as
http://www.tucows.com/preview/195902.
5 For more information about WinPooch, go to
http://sourceforge.net/projects/winpooch/.
6 For more information about RegShot, go to
http://sourceforge.net/projects/regshot.
7 For more information about FingerPrint 2.1.3, go to
http://www.2brightsparks.com/assets/software/FingerPrint_Setup.zip.
8 For more information about ESET SysInspector, go to
http://www.eset.com/us/download/free-antivirus-utilities.
9 http://www.malwarefieldguide.com/Chapter6.html.
10 For more information about InstallWatch, go to the
archive version of the Epsilon Squared Web site,
http://web.archive.org/web/20090216115519/http://epsilonsquared.com/,
and download URL,
http://web.archive.org/web/20090216115249/http://www.epsilonsquared.com/anonymous/InstallWatchPro25.exe
11 For more information about InCtrl5, go to
http://www.pcmag.com/article2/0,1759,9882,00.asp.
12 For more information about InstallSpy, go to
http://www.2brightsparks.com/assets/software/InstallSpy_Setup.zip.
13 For more information about SysAnalyzer, go to
http://labs.idefense.com/software/malcode.php.
14 For more information about Process Explorer, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896653.aspx.
15 For more information about CurrProcess, go to
http://www.nirsoft.net/utils/cprocess.html.
16 For more information about ProcessActivityView, go to
http://www.nirsoft.net/utils/process_activity_view.html.
17 For more information about Explorer Suite/Task
Explorer, go to http://ntcore.com/exsuite.php.
18 For more information about Process Hacker, go to
http://processhacker.sourceforge.net/.
19 For more information about PrcVeiw, go to
http://www.teamcti.com/pview/prcview.htm.
20 For more information about MiTec Process Viewer, go
to http://www.mitec.cz/Downloads/PV.zip.
21 For more information about Process Monitor, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896645.aspx.
22 For more information about FileMon, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896642.aspx.
23 For more information about RegMon, go to
http://technet.microsoft.com/en-
us/sysinternals/bb896652.aspx.
us/sysinternals/bb896652.aspx.
24 Process Monitor runs on Windows 2000 SP4 with
Update Rollup 1, Windows XP SP2, Windows Server
2003 SP1, and Windows Vista, as well as ×64 versions
of Windows XP, Windows Server 2003 SP1, and
Windows Vista.
25 For more information about Wireshark, go to
http://www.wireshark.org/.
26 For more information about TCPView, go to
http://technet.microsoft.com/en-
us/sysinternals/bb897437.aspx.
27 For more information about Active Ports, go to
http://www.devicelock.com/freeware.html.
28 For more information about CurrPorts, go to
http://www.nirsoft.net/utils/cports.html.
29 http://msdn.microsoft.com/en-
us/library/aa383723(VS.85).aspx.
30 For more information about TracePlus/Win32, go to
http://www.sstinc.com/windows.html.
31 For more information about API Monitor, go to
http://www.rohitab.com/apimonitor/.
32 For more information about APISpy32, go to
http://www.internals.com.
33 For more information about Microsoft Detours, go to
http://research.microsoft.com/en-us/projects/detours/.
34 For more information about APILogger, go to
http://labs.idefense.com/software/malcode.php.
35 For more information about Kerberos, go to
http://www.wasm.ru/baixado.php?mode=tool&id=313.
36 For more information about AutoDebug, go to
http://www.autodebug.com/.
37 For more information about WinAPIOverRide, go to
http://jacquelin.potier.free.fr/winapioverride32/.
38 For more information about Application Monitor, go to
http://www.kakeeware.com/i_kam.php.
39 For more information about Capture BAT, go to
https://www.honeynet.org/node/315 and http://www.nz-
honeynet.org/cbatabout.html.
40 For more information about FlyPaper, go to
http://www.hbgary.com/free-tools#flypaper.
41 For more information about REcon, go to
41 For more information about REcon, go to
http://www.hbgary.com/recon.
42 On Windows 2000, Windows XP, and Windows
Server 2003 systems the default system path for the
.vmem file of a respective virtual machine is
C:\Documents and Settings\\My
Documents\My Virtual Machines\.
On Vista and Windows 7 systems, the default path is
C:\Users\\Documents\Virtual Machines\ \.
43 For more information about REcon, go to
http://www.hbgary.com/recon.
44 http://www.zonealarm.com/security/en-us/zonealarm-pc-
security-free-firewall.htm.
45 http://www.online-armor.com/downloads.php.
46 http://personalfirewall.comodo.com/.
47 http://www.pctools.com/firewall/.
48
http://www.ashampoo.com/en/usd/pin/0050/Security_Software/Ashampoo-
FireWall-FREE.
49 For more information about Simple DNS Plus, go to
http://www.simpledns.com/.
50 For more information about FakeDNS, go to
http://labs.idefense.com/software/malcode.php.
51 For more information about Trojan Downloaders, go to
http://www.f-secure.com/en_EMEA-Labs/virus-
encyclopedia/encyclopedia/trojan-downloader.html.
52 http://www.bsalsa.com.
53 For more information about netcat, go to
http://netcat.sourceforge.net/.
54 For more information, go to
http://joncraton.org/files/nc111nt.zip.
55 For more information about DDE, go to
http://support.microsoft.com/kb/160957.
56 http://msdn.microsoft.com/en-
us/library/ms633499(VS.85).aspx.
57 For more information about Winlister, go to
http://www.nirsoft.net/utils/winlister.html.
58 For more information about Buster Sandbox Analyzer,
go to http://bsa.isoftware.nl/.
59 For more information about Sandboxie, go to
http://www.sandboxie.com/.
http://www.sandboxie.com/.
60 For more information about ZeroWine, go to
http://zerowine.sourceforge.net/.
61 For more information about ZeroWine Tryouts, go to
http://zerowine-tryout.sourceforge.net/.
62 http://cert.at/downloads/software/minibis_en.html;
http://cert.at/static/downloads/papers/cert.at-
mass_malware_analysis_1.0 .
63 For more information about TRUMAN, go to
http://www.secureworks.com/research/tools/truman.html.
64
http://www.sans.org/reading_room/whitepapers/tools/building-
automated-behavioral-malware-analysis-environment-
open-source-software_33129.
65 For more information about Cuckoo Sandbox, go to
http://www.cuckoobox.org/.
66 http://cuckoobox.org/doc/0.1/setup.html.
67 For more information about UPX, go to
http://upx.sourceforge.net/.
68 For more information about UnFSG, go to
http://www.zerorev.net/reversing/index.php?
path=Unpackers%2C+Dumpers+and+Decrypters%2FUnFSG+2.0/.
69 For more information about UnMew, go to
http://www.zerorev.net/reversing/index.php?
path=Unpackers%2C+Dumpers+and+Decrypters%2FUNMew+10-
11/.
70 For more information about AspackDie, go to
http://www.woodmann.com/crackz/Packers.htm.
71 For more information about UnPECompact, go to
http://www.zerorev.net/reversing/index.php?
path=Unpackers%2C+Dumpers+and+Decrypters%2FUnPECompact+1.32/.
72 For more information about DeShrink, go to
http://www.woodmann.com/crackz/Packers.htm.
73 For more information about LordPE, go to
http://www.woodmann.net/collaborative/tools/index.php/LordPE.
74 For more information about ProcDump, go to
http://www.fortunecity.com/millenium/firemansam/962/html/procdump.html.
75 For more information about PETools, go to
http://www.uinc.ru/files/neox/PE_Tools.shtml;
http://www.petools.org.ru/.
76 For more information about Process Explorer, go to
http://technet.microsoft.com/en-
http://technet.microsoft.com/en-
us/sysinternals/bb896653.aspx.
77 For more information about CurrProcess, go to
http://www.nirsoft.net/utils/cprocess.html.
78 For more information about Task Explorer, go to
http://www.ntcore.com/exsuite.php.
79 ProcessAnalyzer comes with SysAnalyzer, which is
available from
http://labs.idefense.com/software/malcode.php.
80 For more information about ProcDump, go to
http://technet.microsoft.com/en-
us/sysinternals/dd996900.
81 Dumper comes with WinAPIOveride32, which is
available from
http://jacquelin.potier.free.fr/winapioverride32.
82 For more information about OllyDbg, go to
http://www.ollydbg.de/.
83
http://www.openrce.org/downloads/browse/OllyDbg_Plugins.
84 For more information about OllyDump, go to
http://www.openrce.org/downloads/details/108/OllyDump.
85 For more information about ASPack, go to
http://www.aspack.com/.
86 For more information about ImpREC, go to
http://www.woodmann.com/collaborative/tools/index.php/ImpREC.
87 For more information about IDA Pro, go to
http://www.hex-rays.com/idapro/. Although the tool
sells for approximately $600.00, there is a freeware
version (with slightly less functionality, features, and
support) for non-commercial use available for download
(http://www.hex-
rays.com/idapro/idadownfreeware.htm).
88 http://www.amazon.com/IDA-Pro-Book-Unofficial-
Disassembler/dp/1593271786.
89
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx;
http://msdn.microsoft.com/en-
us/magazine/cc301805.aspx.
90 Winnt.h file, line 7691.
91 Winuser.h file, line 160.
92 For more information about Resource Hacker, go to
http://www.angusj.com/resourcehacker/.
93 For more information about CFF Explorer, go to
http://www.ntcore.com/exsuite.php.
94 For more information about XN Resource Editor, go to
http://www.wilsonc.demon.co.uk/d10resourceeditor.htm.
95 http://msdn.microsoft.com/en-
us/library/aa381039(v=vs.85).aspx.
96 For more information about ResourceExtract, go to
http://www.nirsoft.net/utils/resources_extract.html.
97 For more information about Dependency Walker, go to
http://www.dependencywalker.com/.
98 For more information about SpyStudio, go to
http://www.nektra.com/products/spystudio/.
99 For more information about HTTrack, go to
http://www.httrack.com/.
100 There are some legal and ethical considerations with this
method. First, the content of the Web site may be
copyright protected or otherwise categorized as
intellectual property and fall within the proscriptions of
certain international, federal, state, or local laws, making
it a violation of civil or criminal law to copy it without
permission. Similarly, as the tools are used to acquire
the contents of a Web site by recursively copying
directories, HTML, images, and other files hosted on
the target Web site, they may be considered “hacking
tools” in some jurisdictions. Also, the act of recursively
copying the content of a site may also be considered an
aggressive or hostile computing activity and potentially
viewed as unethical or illegal in some jurisdictions.
Consultation with appropriate legal counsel prior to
implementing these tools and techniques is strongly
advised and encouraged.
101 Some of the more popular malicious code repository
Web sites for digital investigators and researchers
include Offensive Computing
(www.offensivecomputing.net) and VX Heavens
(http://vx.netlux.org/).
102 For more information about RUMINT, go to
http://rumint.org/.
103 For more information about Network Miner, go to
http://networkminer.sourceforge.net/.
104 Edwards, A.W.F., Cavalli-Sforza, L.L., Systematics
104 Edwards, A.W.F., Cavalli-Sforza, L.L., Systematics
Assoc. Publ. No. 6: Phenetic and Phylogenetic
Classification ed. Reconstruction of Evolutionary
Trees. pp. 67–76.
105 Hayes, M., Walnstein, A., and Lakhotia, A. (2009).
Evaluation of Malware Phylogeny Modelling Systems
Using Automated Variant Generation, Journal in
Computer Virology, Vol. 5, no. 4, pp. 335–343.
106 Journal in Computer Virology, 2009, Vol. 5, no. 4,
pp. 335–343.
107 8th Australasian Symposium on Parallel and Distributed
Computing (AusPDC 2010), 2010.
108 Journal in Computer Virology, Vol. 4, no. 4, pp.
279–287.
109 Proceedings of the 14th Virus Bulletin Conference
2004, pp. 187–197.
110 Detection of Intrusions and Malware, and Vulnerability
Assessment Lecture Notes, Computer Science, 2008,
Vol. 5137/2008, pp. 108–125.
111 Proceedings of the 16th ACM SIGKDD International
Conference on Knowledge Discovery and Data Mining.
112 Proceedings of BlackHat DC 2007.
113 Proceedings of EICAR 2005 Conference.
114 Proceedings of the First International Conference on
Communication Systems and NETworks, 2009.
115 For more information about ssdeep, go to
http://ssdeep.sourceforge.net.
116 For more information about YARA, go to
http://code.google.com/p/yara-project/.
117 For more information about HBGary Fingerprint, go to
http://www.hbgary.com/free-tools#fingerprint.
118 YARA User’s Manual Version 1.5.
119 YARA User’s Manual Version 1.5, p. 22.
120 YARA User’s Manual Version 1.5, pp. 3–4.
121 YARA User’s Manual Version 1.5, p. 4.
122 http://code.google.com/p/yara-
project/downloads/detail?
name=YARA%20User%27s%20Manual%201.6 .
123 http://malwareresearchgroup.com/2010/10/detection-
of-the-latest-variant-of-wemon-trojan/;
http://www.threatexpert.com/report.aspx?
md5=43cd9f8b3330468721b8b123a6b22126.
124 For more information about HBGary FingerPrint, go to
http://www.hbgary.com/free-tools#fingerprint.
125 Hayes, M., Walenstein, A., and, Lakhotia, A. (2009).
Evaluation of Malware Phylogeny Modeling Systems
Using Automated Variant Generation, Journal in
Computer Virology, Vol. 5, no. 4, pp. 335–343.
126 For more information about BinDiff, go to
http://www.zynamics.com/bindiff.html.
127 Zynamics BinDiff 3.2 Manual, pp. 6–7.
128 For details on the BinDiff Matching Strategy and
process, refer to the BinDiff 3.2 Manual.
129 Zynamics BinDiff 3.2 Manual, pp. 11–12.
130 For a detailed discussion of ssdeep, refer to Chapter 5.
131 For more information about BinVis, go to
http://code.google.com/p/binvis/.
132 For more information about VERA, go to
http://www.offensivecomputing.net/?q=node/1689,
http://csr.lanl.gov/vera/vera-manual , and
http://www.offensivecomputing.net/vizsec09/dquist-
vizsec09 .
133 For more information about Malheur, go to
http://www.mlsec.org/malheur/, http://honeyblog
.org/junkyard/paper/malheur-TR-2009 (Rieck, K.,
Trinius, P., Willems, C., and Holz, T. (2011).
Automatic Analysis of Malware Behavior using Machine
Learning, Journal of Computer Security, 19(3).
134 http://www.mlsec.org/malheur/install.html.
135 http://www.sunbeltsecurity.com/sandbox/.
136 Phillip, T., Carsten, W., Thorsten H., and Konrad R.
(2009). A Malware Instruction Set for Behavioral-
Based Analysis. Technical Report TR-2009-07,
University of Mannheim
(www.mlsec.org/malheur/docs/mist-tr ).
137 The Python scripts can be found on
http://mwanalysis.org/inmas/maschinellesLernen/mist/.
138 http://pi1.informatik.uni-mannheim.de/malheur/.
139 Automatic Analysis of Malware Behavior Using
Machine Learning, p. 8; Rieck, K. (2011). Malheur
Version 0.5.0, User Manual, p. 2.
Version 0.5.0, User Manual, p. 2.
140 Rieck, K. (2011). Malheur Version 0.5.0, User
Manual, p. 2.
141 Rieck, K. (2011). Malheur Version 0.5.0, User
Manual, p. 2.
142 Rieck, K. (2011). Malheur Version 0.5.0, User
Manual, p. 2.
143 The Python scripts can be found on
https://mwanalysis.org/inmas/backend/visualisierung/.
Index
Page numbers followed by f indicates a figure and t indicates
a table.
A
ABA, See American Bar Association (ABA)
AccessData FTK Enterprise, 175f
Active monitoring artifacts, 429, 429f
Active network connections, 15–16
Active system monitoring, 371–379
CurrProcess, 372
DirMon, 373
Explorer Suite/Task Explorer, 372
File Monitor, 372
file system monitoring, 372–373, 373f
MiTec Process Viewer, 372
process activity monitoring, 371f
Process Hacker, 372
ProcessActivityView, 372, 373
registry monitoring, 372, 374, 374f
registry monitoring, 372, 374, 374f
Tiny Watcher, 373
Address Resolution Protocol (ARP), 17
ARP cache, 17
American Bar Association (ABA), 207
American Recovery and Reinvestment Act (ARRA), 215
American Standard Code for Information Interchange (ASCII),
32, 418
AnalogX TextScan, 258
Anti-debugging mechanisms, 407
Antivirus, 160
freeware, 252
logs, 161, 167
signatures, 251, 252
Anubis, 401t
API call
analysis, 431
interception, 378–379, 379f
monitoring, 386, 394–395
API hooking, 422–424
ARP, see Address Resolution Protocol (ARP)
ARRA, see American Recovery and Reinvestment Act (ARRA)
ASCII, see American Standard Code for Information
Interchange (ASCII)
AspackDie, 403, 404f
AuditViewer, 102
configuration options screenshot, 102f
in listing drivers, 108f
memory injection detection, 124f
Memoryze output, 103f
open file, viewing, 111f
suspicious memory sections, 123f
tabs, 102
Austrian Computer Emergency Response Team (CERT.at), 398
Auto starting artifacts, 375
Autorun locations, 165
Autostart and Process Viewer, 375
Autostart Explorer, 375
Autostart Explorer, 375
Auto-starting locations inspection, 31–32
Avira A/V software, 161f
B
Banking Trojan, 394f
Behavioral profiling and classification, 446–448
BIFF, see Binary Interchange File Format (BIFF)
Binary Interchange File Format (BIFF), 297
Binders, 272
BinDiff, 440, 440f–442f
BinNavi, 415
BinText, 258, 258f
Biometric data, 218
BitBlaze, 402t
Breach notification statutes, 233t
Buster, see Buster Sandbox Analyzer (Buster)
Buster, see Buster Sandbox Analyzer (Buster)
Buster Sandbox Analyzer (Buster), 397
Byte Frequency view, 431
C
Capsa, 376
Capture BAT, see Capture Behavioral Analysis Tool (Capture
BAT)
Capture Behavioral Analysis Tool (Capture BAT), 381
log, 428f
use of, 382f
CERT.at, see Austrian Computer Emergency Response Team
(CERT.at)
CFAA, see Computer Fraud Abuse and Act (CFAA)
Chain of custody, 230
Child Online Privacy Protection Act (COPPA), 216
CLI, see Command line Interface (CLI)
Client applications, 425, 425–426
Clipboard contents, 27, 28f
COFF, see Common Object File Format (COFF)
COFF File header, see IMAGE_FILE_HEADER
Command history collection, 26
Command line Interface (CLI), 5, 240
file identification tools, 249–250
MD5 tools, 243–244
packing and cryptor detection tools, 270–272
PDF analysis tools, 291
Command-line
memory analysis utilities, 99–102
parameters, 20
utilities, 6
Common Object File Format (COFF), 272
Common Vulnerabilities and Exposures (CVE), 294
Comodo, 402t
Compressor, see File obfuscation
Computer forensic specialists, 207
CVE, see Common Vulnerabilities and Exposures (CVE)
CWSandbox, 400t
Cybercrime prosecution, 227
D
Data, across borders, 222–226
data transfers, 224
informal assistance, 225
letter of request, 225
MLAT, 225
Safe Harbor certification, 224
workplace data, 222–226
Data, authority over
federal protection of health information, 215
federal protection of public company information, 216
information about children, 216
PCI DSS, 217
privileged information, 217
protected data, 213–218
real-time data, 211–213
state law protections, 217
stored data, 210–211
student educational records, 216
Data acquiring tools, 218–222
Data acquiring tools, 218–222
business purpose, 219
dual use, 220–222
hacker tools, 220
investigative use, 219
network security and diagnostic tools legitimacy, 222f
ordinary course, 219
Data directory, 279
Data sources, 126, 157
Data structures, 112–117
event logs, 112
investigative considerations, 116–117
master file table, 112–113, 113f
registry entries, 113–116
services, 113
windows operating system, 118, see also Memory
forensics
DBT, see Digital Behavior Traits (DBT)
DDE, see Dynamic Data Exchange (DDE)
DDNA, see Digital DNA (DDNA)
Decompiling CHM file, 310f
Delphi executables, 420
Delphi executables, 420
DeShrink, 403
Deviare API, 423
Digital Behavior Traits (DBT), 399
Digital casting, 381
Digital crime scenes, 380
Digital DNA (DDNA), 104
malicious process extracted using, 125f
Digital evidence, 93
preservation, 229–230
Digital footprints documentation, 370
Digital forensics, 207
consequences of unlicensed, 207
law enforcement, 209, see also Legal considerations
Digital impression evidence, 380–381
Digital investigator, 208
computer trespasser exception, 213
consent exception, 212
non-content portion, 213
protected data, 213–218
provider exception, 211
real-time monitor, 211, see also Legal considerations
Digital trace evidence, 381–385
Digital virology, 432–448
malware cataloging, 433
malware phylogeny, 432, 434t, see also Investigative steps
on malicious code
DirMon, 373
DLL injection, 21
dlllist option, 100f, 107
DLLs, see Dynamic Link Libraries (DLLs)
DNS, see Domain Name Service (DNS)
Domain controller security event logs, 168
Domain name, resolving, 391
Domain Name Service (DNS), 4
DNS queries, 16
select data forensic preservation, 29–30
target NTUSER.dat selection, 37f
trusted host relationship, 30–31
user account and group policy information review, 33, see
also Malware incident response
Norman Sandbox Analyzer, 399, 401t
NSI Malware Analysis Sandbox, 401t
NTFS journal, 170
O
Obfuscation code removal, 402
anti-debugging mechanisms, 407
CurrProcess, 405
Dumper, 405
dumping suspect process, 404–405, 410f
locating OEP and extracting, 406–410, 409f, 410f
LordPE, 404, 405f
OllyDbg, 406, 407, 408f
PE Tools, 404
ProcDump, 404, 405
Process Explorer, 405
ProcessAnalyzer, 405
reconstructing imports, 411–412
script identification and decoding, 310, 311f
Task Explorer, 405
Task Explorer, 405
UPX, 403, see also Unpacker program
OEP, see Original Entry Point (OEP)
OfficeMalScanner, 301, 301–308
OllyDbg, 406, 407, 408f
OllyDump, 407, 410, 410f
OPAF, see Open PDF Analysis Framework (OPAF)
Open files, 25
files opened locally, 25
files opened remotely, 25–26, see also Volatile data
collection methodology
Open PDF Analysis Framework (OPAF), 291
Open port information extraction, 110, 110f
Open Systems Interconnect (OSI), 17
Origami, 291
Original Entry Point (OEP), 403
orphanthreads volatility plug-in, 102
OSI, see Open Systems Interconnect (OSI)
P
Packed malware specimen execution, 268f
Packers, 267–268
and cryptor detection tools, 269–270, see also File
obfuscation
PacketMon, 376
Packing, see File obfuscation
Parsing
suspect PE file, 274f
tools, 163
Pasco, 38
Passive monitoring artifacts, 427–428
Payment Card Industry Data Security Standards (PCI DSS),
217
PCI DSS, see Payment Card Industry Data Security Standards
(PCI DSS)
PDF, see Portable document format (PDF)
PDF, see Portable document format (PDF)
PE files, see Portable Executable files (PE files)
PEB, see Process environment block (PEB)
Personal identification numbers (PINs), 218
Personal information, 217
Personally Identifiable Information (PII), 110
PHI, see Protected Health Information (PHI)
Physical memory
artifacts, 432
identification, 10f
Physical memory acquisition, 5, 6
command-line utilities, 6
with FastDump, 6f
with FastDump Pro, 7f
investigative considerations, 5
on live windows system, 5
remote, 8–11
remote forensics tools, 11
from remote subject system, 11f
tools for, 7, see also Volatile data collection methodology
PID, see Process Identification (PID)
PID, see Process Identification (PID)
PII, see Personally Identifiable Information (PII)
PINs, see Personal identification numbers (PINs)
PML, see Process Monitor Format (PML)
Poison Ivy client application, 426f
Polyunpack, 406
Port activity monitoring, 377–378
Portable document format (PDF), 237
document elements, 282
file format, 282–284
miner, 291
scanner, 291
tool kit, 291
Portable Executable files (PE files), 385
PE Header, 275–279, 277f
PE Tools, 404
resource examination, 416–420
Post-mortem forensics, 155–156
file system examination, 169–170
forensic analysis, 156–159
forensic analysis, 156–159
forensic reconstruction, 173–174
keyword searching, 172
malware discovery and extraction, 159–169, 174–175
registry examination, 170–172, see also Windows file
system examination
Post-run data analysis, 426–432, 426, 427
active monitoring artifacts, 429, 429f
API call analysis, 431
Byte Frequency view, 431
CaptureBAT log, 428f
captured file system and registry, 428f, 429f
captured network traffic analysis, 430–431
detected Process Injection, 432f
passive monitoring artifacts, 427–428
physical memory artifacts, 432
RUMINT, 430, 431f
Text Rainfall view, 431
Visualization schemas, 431
PrcView, 372
Pre-execution Preparation: System and Network Monitoring
Prefetch files, 31, 163–164
inspection, 31
related to Poison Ivy malware, 163f
tools for parsing, 163
tools for parsing, 163
Preview Disk function, 39, 39f
Private investigation, 206
Privileged information, 217
ProcDump, 404, 405
Process activity
examination, 393
monitoring, 371f
Process environment block (PEB), 118
Process Explorer, 393, 393f, 405
Process Hacker, 372
Process Identification (PID), 18, 100, 371
Process information collection, 18–22
child processes, 20–21
command-line parameters, 20
dependencies loaded by running processes, 21–22
executable program mapping process, 19
exported DLLs, 22
file handles, 21
file handles, 21
memory usage, 19
process memory content capture, 22
process name and process identification, 18–19
temporal context, 18–19
user mapping process, 20, see also Volatile data collection
methodology
Process Injection, detected, 432f
Process memory
content capture, 22
trajectory analysis, 442–444, 443f
Process Monitor, 372, 373, 373f
Process Monitor Format (PML), 373
ProcessActivityView, 372, 373
ProcessAnalyzer, 405
procexedump option, 119
Profiling Compiled HTML help files, 308
decompiling CHM file, 310f
file structure and content examination, 309
locating suspect scripts, 309
malice indicators, 308
metadata discovery, 309
metadata discovery, 309
obfuscated script identification and decoding, 310, 311f
Profiling Microsoft Office files, 295, 298–301
extracted code examination, 305
file format, 295–298
file structure examination, 303
locating and extracting embedded executables, 304
locating and extracting shellcode, 307
malice indicators, 298
metadata discovery, 299
OfficeMalScanner, 301, 301–308
vulnerabilities and exploits, 298
Profiling suspect PDF files, 281–284
embedded entities, 284
file format, 282–284, 283f
file structure and contents examination, 286
GUI tools, 292–294
javascript extraction, 290
locating suspect scripts and shellcode, 287
malice indicators, 285
metadata discovery, 285
online resources, 295
parsing specific object, 288f
shellcode extraction, 291
suspect object decompression, 287, 288f
Trailer, 283
Trailer, 283
XREF, 283
Profiling suspicious file, 240–243
file appearance record, 242, 242f
file name acquisition, 241–242
file size acquisition, 242
hash values, 242–243, 243
investigative considerations, 241
system details, 240, see also File profiling ; Profiling
Compiled HTML help files ; Profiling Microsoft Office files
; Profiling suspect PDF files
Protected data, 213–218
child pornography, 216
children information, 216
financial information, 214
health information, 215
payment card information, 217
privileged information, 217
public company information, 216
state law protections, 217
student educational records, 216, see also Legal
considerations
Protected Health Information (PHI), 110
Protected storage (pstore), 38
Protected storage (pstore), 38
psdiff plug-in, 100
Psloggedon, 15, see also Command line Interface (CLI)
psscan plug-in, 99, 100f
pstore, see Protected storage (pstore)
R
RAM, see Random access memory (RAM)
Random access memory (RAM), 3
RECon, 383, 384, 384f
Registry
activity examination, 397
contents, 34
Monitor, 372
remnants, 163
remote analysis, 35–37
Viewer, 171f
Registry entries, 113–116
HBGary Responder, 116
hivedump plug-in, 116f, 117f
hivelist plug-in, 115f
hivelist plug-in, 115f
regobjkeys plug-in, 115f, see also Data structures
Registry monitoring, 374, 374f
auto starting artifacts, 375
Autostart and Process Viewer, 375
Autostart Explorer, 375
RegMon, 374f
WhatInStartup, 375
RegMon, 374f
regobjkeys plug-in, 115f
RegRipper, 37, 170
item extraction, 171f
Rehashing, 386
Remote forensics tools, 11
Resource Extract, 419, 421f
Restore points, 171–172
Reusable Unknown Malware Analysis Net, the (TRUMAN),
399
Reversing Labs Tools, 406
RUMINT, 430, 431f
S
Safe Harbor certification, 224
Safety tip, 238, 364
Sandboxie, 397
Sarbanes-Oxley Act (SOX), 216
Scheduled tasks determination, 27
Scout Sniper, 437
SDK, see Software Development Kit (SDK)
Section table, 280–281, 280f
Secure Hash Algorithm Version 1.0 (SHA1), 243
Security
configuration, 30
conscious malware, 366
Services and drivers identification, 23, 113
installed drivers examination, 24–25
running services examination, 24, see also Data structures ;
running services examination, 24, see also Data structures ;
Volatile data collection methodology
SHA1, see Secure Hash Algorithm Version 1.0 (SHA1)
Shellcode extraction, 291
SIA, see Standard Information Attribute (SIA)
Simple DNS Plus, 388
Simple Mail Transfer Protocol (SMTP), 377
SmartSniff, 376
SMTP, see Simple Mail Transfer Protocol (SMTP)
Sniff_hit, 376
Software Development Kit (SDK), 272
SOX, see Sarbanes-Oxley Act (SOX)
SpyStudio, 422, 423, 423f, 424, 424f
ssdeep, 160, 246f, 435, 435f
SSDeepFE, 244
Standard Information Attribute (SIA), 170
Stateful information, 2, see also Volatile data
Strex, see String Extractor (Strex)
String Extractor (Strex), 258
Strings, 255–257
Student educational records, 216
Subject system detail collection, 11–13
enabled protocols, 13
network configuration, 12
with psinfo, 14f
system date and time, 11–12
system environment, 13
system identifiers, 12
system uptime, 13
uptime command, 13f, see also Volatile data collection
methodology
Sunbelt Sandbox, see GFI Sandbox
Suspect program examination, 413–415
Suspicious file, 238
extraction, 39–40, 41–42, 41f
svcscan plug-in, 114f
SysAnalyzer, 368f
System
environment, 13
files, 169
identifiers, 12
resources, 21
System monitoring, 369–380
digital footprints documentation, 370
monitoring technique implementation, 370f
passive system monitoring, 370
on Windows system, 369, see also Active system
monitoring ; Network activity monitoring
T
Target NTUSER.dat selection, 37f
Task Explorer, 405
Taxpayer identification numbers (TINs), 218
TCP, see Transmission Control Protocol (TCP)
TCPView, 378
Text Rainfall view, 431
TextExtract, 258
Textual and binary indicators of likeness, 435–438
ThreatExpert, 401t
TINs, see Taxpayer identification numbers (TINs)
Tiny Watcher, 373
Title III, see Wiretap Act
Trace evidence, 380
Traffic monitoring, 375
Trailer, 283
Transmission Control Protocol (TCP), 16
TrID, 249, 250f
Triggering events, 414, 424
Trojan horse program, 109
TRUMAN, see Reusable Unknown Malware Analysis Net, the
TRUMAN, see Reusable Unknown Malware Analysis Net, the
(TRUMAN)
U
UDP, see User Datagram Protocol (UDP)
UnFSG, 403
Uniform Resource Locator (URL), 15, 255, 395
Universal Serial Bus (USB), 4, 34
UnMew, 403
Unpacker program, 403
AspackDie, 403, 404f
DeShrink, 403
Ether, 406
Polyunpack, 406
Reversing Labs Tools, 406
UnFSG, 403
UnMew, 403
UnPECompact, 403
uptime command, 13f
UPX, 403
URL, see Uniform Resource Locator (URL)
USB, see Universal Serial Bus (USB)
User account
and group policy information review, 33
and logon activities, 168–169
User Datagram Protocol (UDP), 391
User mapping process, 20
UserAssist, 170
V
VERA, 446, 446f
Verifying Specimen Functionality and Purpose
ViCheck.ca, 402t
VirScan, 253
Virtual Private Network (VPN), 12
Virtualization, 365
Virus scanners, 400
VirusTotal, 253, 254f
Visual MD5, 244
Visual Sniffer, 376
Visualization, 431, 444–446
VMWare, 383, 384
Volatile data, 2
preservation, 4–5
Volatile data collection methodology, 2, 4–18
active network connections, 15–16
ARP cache, 17
clipboard contents, 27, 28f
command history collection, 26
DNS queries, 16
GUI-based memory dumping tools, 7
local vs. remote collection, 3–4
logged in user identification, 13–17
NetBIOS connections, 16–17
netcat commands, 3f
Netstat-ano command, 16, 16f
network connections and activity, 15
open files determination, 25
open ports correlation, 22–27
open ports correlation, 22–27
physical memory acquisition, 5, 6
process information collection, 18–22
scheduled tasks determination, 27
services and drivers identification, 23
shares identification, 26, 26f
subject system detail collection, 11–13
volatile data preservation, 4–5, 5, see also Malware
incident response
Volatility, 121
commands to open ports, 110f
csrpslist plug-in, 101, 101f
dlllist option, 100f, 107
dynamic link libraries listing, 108f
files option in, 110, 110f
loaded modules listing, 107f
malfind plug-in, 123f
malware concealment technique detection, 122
procexedump option, 119
psdiff plug-in, 100
psscan plug-in, 99, 100f
regobjkeys plug-in, 115f
service extraction, 113
svcscan plug-in, 114f
version 1.3, 119, see also Forensic tools, memory
VPN, see Virtual Private Network (VPN)
VPN, see Virtual Private Network (VPN)
W
Web browsing artifacts examination, 37–38
cookie files examination, 38
malware artifact discovery and extraction, 39
protected storage, 38
suspicious files extraction, 39–40, 41–42, see also
Malware incident response
Web browsing history, 167
WhatInStartup, 375
Window spying, 395
Windows, 118
event logs, 166
memory forensics tools, 98, 98–118
Windows file system examination
examination, 169–170
file system data structures, 169
forensic examination, 155
forensic reconstruction, 173–174
functional analysis, 173
malware discovery and extraction, 159–169, 174–175, see
also Malware ; Post-mortem forensics
also Malware ; Post-mortem forensics
Windows forensic analysis, 156–159, 157
investigative considerations, 157–159
Windows process memory, 118–120, 121–125
analysis, 121–125
dumping, 118–120, 120f
executable file recovery, 118–119
extraction, 120
recovery, 119–120
running AntiVirus, 119, see also Memory forensics
Windows Registry Database (WiReD), 163
Windows registry examination, 170–172
locations, 170
Registry Viewer, 171f
restore points, 171–172
temporal analysis, 170
UserAssist, 170, see also Malware ; Post-mortem
forensics
Windump, 375
WinLister, 395, 396f
WinMD5, 244
WiReD, see Windows Registry Database (WiReD)
Wireshark, 375, 376, 377f
Wiretap Act, 211
Wrappers, see Binders
X
XREF, see Cross Reference (XREF)
Y
YAB, see Yet Another Binder (YAB)
YARA, 435, 436f, 437f
Yet Another Binder (YAB), 272
Z
ZeroWine, 398
ZeroWine Tryouts, 398
What Will You Get?
We provide professional writing services to help you score straight A’s by submitting custom written assignments that mirror your guidelines.
Premium Quality
Get result-oriented writing and never worry about grades anymore. We follow the highest quality standards to make sure that you get perfect assignments.
Experienced Writers
Our writers have experience in dealing with papers of every educational level. You can surely rely on the expertise of our qualified professionals.
On-Time Delivery
Your deadline is our threshold for success and we take it very seriously. We make sure you receive your papers before your predefined time.
24/7 Customer Support
Someone from our customer support team is always here to respond to your questions. So, hit us up if you have got any ambiguity or concern.
Complete Confidentiality
Sit back and relax while we help you out with writing your papers. We have an ultimate policy for keeping your personal and order-related details a secret.
Authentic Sources
We assure you that your document will be thoroughly checked for plagiarism and grammatical errors as we use highly authentic and licit sources.
Moneyback Guarantee
Still reluctant about placing an order? Our 100% Moneyback Guarantee backs you up on rare occasions where you aren’t satisfied with the writing.
Order Tracking
You don’t have to wait for an update for hours; you can track the progress of your order any time you want. We share the status after each step.
From brainstorming your paper's outline to perfecting its grammar, we perform every step carefully to make your paper worthy of A grade.
Preferred Writer
Hire your preferred writer anytime. Simply specify if you want your preferred expert to write your paper and we’ll make that happen.
Grammar Check Report
Get an elaborate and authentic grammar check report with your work to have the grammar goodness sealed in your document.
One Page Summary
You can purchase this feature if you want our writers to sum up your paper in the form of a concise and well-articulated summary.
Plagiarism Report
You don’t have to worry about plagiarism anymore. Get a plagiarism report to certify the uniqueness of your work.
Free Features $66FREE
Most Qualified Writer
$10FREE
Plagiarism Scan Report
$10FREE
Unlimited Revisions
$08FREE
Paper Formatting
$05FREE
Cover Page
$05FREE
Referencing & Bibliography
$10FREE
Dedicated User Area
$08FREE
24/7 Order Tracking
$05FREE
Periodic Email Alerts
$05FREE
Our Services
Join us for the best experience while seeking writing assistance in your college life. A good grade is all you need to boost up your academic excellence and we are all about it.
On-time Delivery
24/7 Order Tracking
Access to Authentic Sources
Academic Writing
We create perfect papers according to the guidelines.
Professional Editing
We seamlessly edit out errors from your papers.
Thorough Proofreading
We thoroughly read your final draft to identify errors.
Thorough Proofreading
We thoroughly read your final draft to identify errors.
Delegate Your Challenging Writing Tasks to Experienced Professionals
Work with ultimate peace of mind because we ensure that your academic work is our responsibility and your grades are a top concern for us!
We Analyze Your Problem and Offer Customized Writing
We understand your guidelines first before delivering any writing service. You can discuss your writing needs and we will have them evaluated by our dedicated team.
Clear elicitation of your requirements.
Customized writing as per your needs.
We Mirror Your Guidelines to Deliver Quality Services
We write your papers in a standardized way. We complete your work in such a way that it turns out to be a perfect description of your guidelines.
Proactive analysis of your writing.
Active communication to understand requirements.
We Handle Your Writing Tasks to Ensure Excellent Grades
We promise you excellent grades and academic excellence that you always longed for. Our writers stay in touch with you via email.
Thorough research and analysis for every order.
Deliverance of reliable writing service to improve your grades.
