Collecting Volatile and Non-volatile Data

by 11:00 2 comments
Volatile Data
Volatile data is stored in memory of a live system (or in transit on a data bus) and would be lost when the system was powered down. Volatile data resides in registries, cache,and RAM, which is probably the most significant source. A system’s RAM contains the programs running on the system(operating -systems, services, applications, etc.) and the data being used by those programs. The contents of RAM change constantly and contain many pieces of information that may be useful to an investigation. Because RAM and other volatile data are dynamic, collection of this information should occur in real time. Other examples of volatile data include: 
System time :  Analysts should record the time and date on the system under suspicion, and it should be compared against the actual time and date. Inconsistencies should be noted. Recording dates and times allows analysts to document when an incident investigation began, when volatile data was collected and when an incident investigation ended.
Network connections : Capturing a snapshot of existing network connections will give analysts an idea of what ports are open, what processes have established connections and clues about what data has been transmitted.
Command history : Reviewing the command history on a suspicious system shows recent user activities and serves as an audit trail of investigative activity. To the extent possible, command histories should be obtained for each user account on a suspicious system. Commands to look for include those used to manage user accounts, configure peripherals and install software.
Running  Processes : Examining the list of processes running on a system will help analysts detect malicious or rogue processes. When retrieving volatile data, analysts must be aware that malicious programs may have names that seem valid. Other clues to look for are processes running at odd times and unusual user ids associated with running processes.
Tips  for Collecting Volatile Data
  • Do not shut-down or restart a system under investigation until all relevant volatile data has been recorded. Remember that volatile data goes away when a system is shut-down.
  • Also, data on the hard drive may change when a system is restarted.
  • Maintain a log of all actions taken on a live system. Having an audit trail that records the data collection process will prove useful should an investigation lead to legal or internal disciplinary actions.
  • Dump RAM to a forensically sterile, removable storage device. RAM contains information about running processes and other associated data. Neglecting to record this information onto clean media risks destroying the reliability of the data and jeopardizing the outcome of an investigation.
  • Record system date, time and command history. Capturing system date and time provides a record of when an investigation begins and ends. Command histories reveal what processes or programs users initiated.
  • Do not use the administrative utilities on the compromised system during an investigation. Attackers may give malicious software names that seem harmless. Be extremely cautious particularly when running diagnostic utilities. A general rule is to treat every file on a suspicious system as though it has been compromised.
Non-volatile data 
Non-volatile data is that which remains unchanged when a system loses power or is shut down. Examples of non-volatile data are emails, word processing documents, spreadsheets and various “deleted” files. Such data is typically recovered from hard drives. Non-volatile data can also exist in slack space, swap files and unallocated drive space. Other sources of non-volatile data include CD-ROMs, USB thumb drives, smart phones and PDAs. Most of the information collected during an incident response will come from non-volatile data sources. While it is fundamentally different from volatile data, analysts must exercise the same care and caution when gathering non-volatile data. Non-volatile data that can be recovered from a hard drive includes:
Temporary (temp) files : A temp file is created by a program when it cannot allocate enough memory for its tasks or the program is working on a large set of data. Generally, temp files are deleted when a program terminates. However, some programs create temp files and leave them behind.
System registries : A registry is a database that contains information and settings for a system’s hardware, operating system, user preferences and computing activities.
Event logs : In accordance with system administrator-established parameters, event logs record certain events, providing an audit trail that can be used to diagnose problems or to investigate suspicious activity.
Boot sectors : Hard drives in production environments are typically organized into multiple partitions. Each partition may have a different operating system. Boot sectors contain instructions for booting operating systems.
Web browser cache : Web browsers allow users to cache locally the contents of web pages to speed future access to frequently visited sites. Downloaded content remains on the hard drive until deleted. However, even after the cache
is deleted, data can remain in the unallocated space of the hard drive.
Cookies : Web servers interact with web browsers through cookies: small packages of data used to track, validate and maintain specific information about users. Cookies may have an expiration date at which the browser deletes it.
Cookies without an expiration date are deleted at the end of a user session. Users may also delete cookies at their request. However, like the web browser cache, cookie data  may remain in the unallocated space of the hard drive after it is deleted. 
Tips  for  Collecting Non-Volatile Data
  • Develop and implement a chain of custody, which is a process to track collected information and to preserve the integrity of the information. Following a documented chain of custody is required if the data collected will be used in a legal proceeding. Beyond the legal requirements for gathering evidence, it is a best practice to conduct all breach investigations using a standard methodology for data collection.
  • Make a bit-by-bit copy (bit-stream) of the system’s hard drive which captures every bit on the hard drive, including slack space, unallocated space, and the swap file.
  • Calculate hash values of the bit-stream drive images and other files under investigation. To hash data means to transform existing data into a small stream of characters that serves as a fingerprint of the data. Hashing drives and files ensures their integrity and authenticity. These characteristics must be preserved if evidence is to be used in legal proceedings.
  • Do not work on original digital evidence. This is self-explanatory but can be overlooked. After making a bit-by-bit duplicate of a suspicious drive, the original drives should be accessed as little as possible. Any investigative work should be performed on the bit-stream image.
  • Carry a digital voice recorder to record conversations with personnel involved in the investigation. Breach investigations often involve a whirlwind of conversations, declarations and other assertions that may be useful as an investigation progresses. Using a digital voice recorder saves analysts from having to recall all the minutiae that surfaces during an investigation. Archive/organize/associate all digital voice files along with other evidence collected during an investigation.    
  • Summary  : After a breach happens is the wrong time to think about how evidence will be collected, processed and reported. Prudent organizations will have in place a defined, documented and tested data collection process before a breach occurs. In the past, computer forensics was the exclusive domain of law enforcement. Digital data collection efforts focused only on capturing non volatile data. However, technological evolution and the emergence of more sophisticated attacks prompted developments in computer forensics. New data collection methodologies have been adopted that focus on collecting both non-volatile and volatile data during an incident response. Both types of data are important to an investigation.

Vuppala Dhanunjaya

IT Security and Cyber Forensic Analyst

2 comments: