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
• 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 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:
• Examine logs (system logs, AntiVirus logs, Web browser history, etc.)
• 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 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.
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 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 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 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 “MicrosoftWindowsCurrentVersionApp Paths” that contains a list of executable paths for installed applications. The Windows 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 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 “WindowsTasks” 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 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 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 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 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
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
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 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:WINNTJava, 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 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 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 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 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 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 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:I386SYSTEM32” 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.
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, 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.
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.
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 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.pdf ; 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.pdf ; 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.pdf ; 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.pdf ; 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.pdf ; 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.pdf ; 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.pdf ; 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.
2 http://wetstonetech.com/cgi-bin/shop.cgi?view,2.
3 http://ssdeep.sourceforge.net.
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.
10 http://www.syngress.com/information-security-and-system-administrators/Microsoft-Log-Parser-Toolkit/.
11 http://accessdata.com/products/computer-forensics/decryption.
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.