Read an Excerpt
Malware Forensics Field Guide for Windows Systems
Digital Forensics Field Guides
Syngress
Copyright © 2012 Elsevier, Inc.
All right reserved.
ISBN: 978-1-59749-473-1
Chapter One
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
• Malware Artifact Discovery and Extraction from a Live Windows System
INTRODUCTION
This chapter demonstrates the value of preserving volatile and select nonvolatile 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.
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.
• 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 "<toolname>20101020host1.txt" on the collection system.
• 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 Commandline 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 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 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.
• FastDump Community 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.
• 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):
• FastDump Pro 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):
GUI-based Memory Dumping Tools
* Agile Risk Management's Nigilant32 is a GUI-based incident response tool.
• Nigilant32 provides an intuitive interface and simplistic 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.
• 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 service 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.
• 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.
(Continues...)
Excerpted from Malware Forensics Field Guide for Windows Systems Copyright © 2012 by Elsevier, Inc.. Excerpted by permission of Syngress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
