This document discusses live data collection during incident response and computer forensics investigations. It describes the goals of preserving volatile evidence while minimizing changes to the system. When to perform a live response is outlined, such as when volatile data contains critical information. Factors for selecting live response tools and what types of data to collect are provided. Best practices for collection such as automating, documenting, and testing processes on a test system first are recommended. Options for live data collection on Windows systems including prebuilt toolkits and building custom tools are presented. Memory collection using full memory dumps and specific tools is also covered.

1. Chapter 7
Live Data Collection
Fall 2022 - Incident Response & Computer Forensics
1

2. The Goal
 Preserving volatile evidence
 Risks involved
 The data collection process may cause excessive change to the
system
 May disrupt system functionality or even cause the system to crash
 May destroy evidence
 May also alert the attacker
 One must make effort to minimize the change to suspect’s
computer
2

3. When to Perform A Live Response
 If you think volatile data contains critical information not
found anywhere else
 Forensic duplication is difficult (e.g., too many systems
to collect data from)
 Forensic duplication may fail
 Reasons exist to preserve as much data as possible
 Risk
 Any interaction with a system makes changes to system state
3

4. Selecting a Live Response Tool
 Factors evaluating live response tools
 Is the tool accepted in the forensic community?
 Does it work in common OS environment?
 Does it collect data that is helpful?
 How much time does it take to collect data?
 Can the tool be configured?
 Can the output be easily reviewed and understood?
 Always use trusted tools/files
4

5. What to Collect?
 Two types of data can be collected
 Data that describe the current state of the system
 Data that is less volatile and shows what has happened in the
past
 Live Response data
 System date, time, time zone
 OS version information
 General system information: memory, hard-disk, etc.
 Local user account information
 Network interface information
 Network connections and associated processes
 Files and other open handles
 …
(See pages 140 – 141 in the textbook for a suggested list)
5

6. Collection Best Practices
 Before running live response on a suspect system,
practice on a test system
 Run the tests multiple times and on more than one
system
 Minimize the time spent on system during data collection
 The suspect system may have been infected with
malware. So,
 Document what you do and when you do it
 Do not interact with the suspect system unless there is a plan
 Use tools that minimize the impact on the target system
6

7. Collection Best Practices
 The suspect system may have been infected with
malware (continued)
 Use tools that keep a log and compute checksums of output
 Automate the collection process
 Try to collect data in order of volatility
 Treat the data collected as evidence
 Do not keep any important files etc. on the media that you
connect to suspect’s system
 Do not do anything that will result in unnecessary modifications to
suspect’s system – unless it is absolutely necessary
 Do not perform analysis on suspect’s system
7

8. Live Data Collection on MS
Windows Systems
 Three options
 Use a prebuilt toolkit
 Create your own
 Use a hybrid of the above two
8

9. Live Data Collection on MS
Windows Systems
 Prebuilt Toolkit: Mandiant Redline
 A GUI tool
 The “Collector” can be stored on a removable media and run on
systems of interest
 Collects information from 25 different categories
 Disadvantage:
 Does not keep a log of what it did
 Does not compute MD5 hash of data it creates
9

10. Live Data Collection on MS
Windows Systems
 Do It Yourself
 Build for both 32-bit and 64-bit versions of Windows
 Some tools are built into the OS and some are third-party tools
 Always copy tools from a clean system to have the trusted
binaries
 Avoid GUI as much as you can
 It is a good practice to rename the tools
 Test the kit after every update you make to it
10

11. Collecting Memory Data
 Full Memory Dump
 Mandiant Memoryze
 AccessData’s FTK Imager Lite
 Does not need installation and will run directly from a folder
 Can image both memory and hard drives
11