Linux System
■ ■Chapter 2
Malware Incident
Response: Volatile
Data Collection and
Examination on a
Live Linux System
Introduction
Just as there is a time for surgery rather than an autopsy, there is a need for live forensic inspection of a potentially compromised computer rather than an in-depth examination of a forensic duplicate of the disk. Preserving data from a live system is often necessary to ascertain whether it has malicious code installed, and the volatile data gathered at this initial stage of a malware incident can provide valuable leads, including remote servers the malware is communicating with.
There are various native Linux commands that are useful for collecting volatile data from a live computer. Since the commands on a compromised system can be undermined by malware and cannot be trusted, it is necessary to use a toolkit of utilities for capturing volatile data that have minimal interaction with the subject operating system. Using such trusted binaries is a critical part of any live examination, and can reveal information that is hidden by a rootkit. However, when a loadable kernel module (LKM) rootkit is involved, even statically compiled binaries that do not rely on components of the subject system are ineffective, making it necessary to explore creative counter- measures and rely on memory forensics and file system forensics.
This chapter provides an overall methodology for preserving volatile data on a Linux machine in a forensically sound manner, and uses case examples to demonstrate the strengths and shortcomings of the information that is available through the operating system.
Volatile Data Collection Methodology
The following guidelines are provided to give a clearer sense of the types of volatile data that can be preserved to gain a better understanding of malware. The usefulness of volatile data is demonstrated in the context of practical case scenarios, and various tools are used to provide examples of data. As noted in Chapter 1, prior to running utilities on a live system, it is important to assess them on a test computer to document their potential impact on an evidentiary system.
Be aware that the majority of UNIX systems have a script utility that can record commands that are run as well as the output of each command, providing the supporting documentation that is the cornerstone of digital forensics. Note that script caches data in memory and only writes the full recorded information when it is terminated, unless the script -f option is used to flush commands as executed, which reduces the amount of information that is lost in the event of a system failure during the collection process. By default, the script commands saves data to the current location. To avoid the risk of overwriting portions of the evidentiary system, digital investigators must specify an output file on the command line to direct the output to a specific collection device.
1. On the compromised machine, run a trusted command shell from a toolkit with statically compiled binaries (e.g., on the Helix CD).
2. Run script to start a log of your keystrokes.
3. Note the date and time of the computer and compare it with a reliable time source. 4. Capture the full contents of memory using dd.
5. Gather hostname, Internet Protocol (IP) address, and operating system details. 6. Gather system status and environment details, including whether a network sniffer is
7. Identify users logged onto the system. Use who or w to determine who is currently logged in. Verify that a legitimate user established each session.
8. Determine network connections and activity. Use netstat to view open connections to the computer.
9. Use ps to view the processes running on the computer, and try to determine if any unusual processes are running.
10. Use lsof to determine what files and sockets are being accessed. 11. Examine loaded modules and drivers.
12. Examine connected hostnames. 13. Examine command line history. 14. Identify mounted shares.
15. Check for unauthorized accounts, groups, shares, and other system resources and configurations.
16. Determine scheduled tasks.
17. Terminate script to finish logging of your keystrokes by typing exit.
In some cases, it is also necessary to capture some 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. It is also recommended that the collection of volatile data be automated, to avoid missteps and omissions.
Before delving into each of these areas, the following case scenario involving a rootkit named “T0rnkit” is presented to give an overview of the response process. The author of T0rnkit was the first individual to be arrested under the United Kingdom’s Computer Misuse Act for creating this type of malicious software. Several commands demonstrated in this scenario will be discussed in more detail later in the chapter. The netstat command is commonly used by incident responders to view network connections, ps is used to show running processes on a UNIX system, and lsof is used to show which ports and files are being accessed by each process, and which user account is associated with each process. The output of lsof can be useful for finding programs and files created by an intruder, and can be compared with the output from ps to find discrepancies caused by rootkits.
Continued