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 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 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 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 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.
• 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 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. 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 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
Other Tools to Consider
Data Carving Tools
DataLifter http://www.datalifter.com
Temporal, Functional, and Relational Analysis
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.
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, 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
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 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.
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 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 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.
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.pdf.
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 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.