The Volatility Framework in the extraction of digital artifacts from RAM

Introduction

With the increase in the use of the Internet and other technological advancements, attacks on Information Systems have been on the rise . The advances have necessitated a new breed of professional who can use the tools available to him or her for mitigating cyber and malware attacks. Just as the offenses are committed electronically, mitigation activities can also be carried out in the same way. Digital forensic tools are often used for investigating malicious acts and in the collection of evidence or information on breaches (Baláž & Hlinka, 2012). Moreover, such tools are also useful for testing both standalone systems and networks. One challenge to the assessment of malware activity has been the nature of computer systems. Volatile memory forms one of the most integral parts of a computer system (Kornblum & ManTech, 2006). Since digital forensics aims at collecting the evidence in a way that does not alter it and obtaining all the evidence that was left behind by the perpetrator, it becomes quite challenging to accomplish because the data store in volatile memory is likely to get lost. Volatility Framework has been designed to navigate some of the most common issues when scanning volatile memory. For this reason, Volatility is an excellent tool for examining the digital memory for malware activity.

Literature Review

According to Ptacek & Newsham (1998), a vast majority of the intrusion detection systems that were in place at the time of their article were driven off of audit logs provided by the Operating System. The logs formed the foundational basis for detecting attacks by looking out for any suspicious patterns in the activity on a computer system. The authors further noted that while Intrusion Detection Systems (IDS) that had been designed in this way (host-based and multi-host IDS) were good at identifying attacks started by the local users, they were inept at identifying network events that occurred at a low level. Ptacek & Newsham thus proposed a paradigm shift in the design of anti-malware programs. Kornblum & ManTech (2006), spoke about the emerging field of digital memory forensics, then still in its infancy, but with the promise to provide the measures required to eliminate malware from computer systems. According to the authors, evidence could also be collected from the computer system through a variety of tools. Petroni, Walters, Fraser, & Arbaugh (2006), developed the Forensic Analysis Toolkit (FATKit) which was meant to automate the process of low-level digital artifact extraction from volatile memory.

Building on the experience he had from FATKit, Aaron Walters proposed the Volatility Framework as a “Volatile memory artifact extraction utility framework” in 2007. At the time, it was a purely theoretical concept whose implementation was in doubt. By 2009, Law, Chow, Lai, & Hayson had proposed another host-based digital forensics tool for botnet investigation. In the same year, Zhang, Wang, & Zhang (2009), had proposed a similar solution, only that this used the Kernel Processor Control Region (KPCR) data structure in Windows to inspect volatile memory. As advances in the technologies used to extract digital evidence were made, Chan et al. (2011), proposed a tool named as ‘Cafegrid’ which could not only be used for in-depth analysis, but also for the collection of digital evidence from data structures. The tool would have been able to operate in both Linux and Windows. In 2011, Lempereur, Merabti, & Shi proposed a framework that could monitor system behavior and give information on any hidden processes, files, or network connections that were in use in the system. Balaz & Hlinka (2012), came up with different ways through which volatile memory contents could be acquired for forensic analysis, although they limited their research to Linux systems only. In 2014, the development of Volatility Framework alpha was completed with the first stable release emerging in 2016.

What is the Volatility Framework?

Over the last decade or so, digital forensic research has increasingly focused on the identification, collection, and investigation of digital artifacts, which as a result of the studies, is a reasonably well-understood concept (Walters, 2007). Once forensic analysts had discovered the digital artifacts existed, the next step was to find out where they are and how to recover them. For a long time, the challenge that remained was how to extract digital artifacts from volatile memory like RAM. However, with the introduction of the Volatility Framework, it is no longer as big a problem as it was initially. The Volatility Framework, or just Volatility, refers to an open collection of tools – and plugins – implemented in Python and licensed under the terms of the GNU General Public License. The Volatility Framework is an apt tool for the extraction of digital artifacts from volatile memory (RAM) samples. According to Carrier (2005), digital forensic artifacts are typically a function of the Operating System, physical media, file system, and user-level applications that compromise a system, with each of these affecting the digital evidence that is created and what is left behind. With Volatility, though, the extraction techniques that are performed operate entirely independent of the system being investigated but without compromising the visibility of underlying processes and services or affecting the runtime state of the system (Walters, 2007). The framework offers an introduction to the techniques and complexities of looking for and collecting digital forensic artifacts from volatile memory samples.  

Why Use Volatility Framework?

            Volatility Framework has some advantages over other memory inspection tools, making it a perfect choice for an investigator. One of these is the fact that it allows uninterrupted operation of the memory. According to Bashir & Khan (2013), running a forensic tool has the potential to affect the data. When the data is held in memory, the chances of data being altered increases exponentially. Volatility’s advantage is the fact that it was designed by people with a background in forensic investigation so that it would not get in the way, even as it performs the tasks that analysts typically have to do themselves (Ligh, Case, Levy, & Walters, 2014). Consequently, it offers a single, cohesive framework that can analyze memory dumps from both 32-bit and 64-bit version of Windows, Linux, Mac OS, and Android systems. And since the software features a modular architecture, it promises to support future Operating Systems through the inclusion of additive modules. The reason why Volatility runs on all target devices is that was written in Python, as opposed to other frameworks which require the .Net core to run (Dolan-Gavitt, 2008). As a result, the Volatility Framework can run anywhere that Python can run. Volatility also has the advantage of an unparalleled feature set which makes reverse engineering a cinch. Perhaps the most significant reason why a person should utilize it is that it has already generated a robust community of practitioners and researchers in incident response, forensics, and malware analysis. As such, an investigator is sure to find numerous resources to help them get up to speed with the framework.

How is the Volatility Framework used?

While investigating a system for malware or other forms of forensic evidence, it at times becomes necessary for the forensic investigator to look for any malicious programs located on the compromised system that might be lurking in the background. When this happens, memory analysis is by far the best tool for identifying any programs or malware that may be running without the necessary access settings (Baláž & Hlinka, 2012). While carrying out forensics, and especially when the attack is suspected to have involved some form of malware, an essential step in the process is to analyze the Random Access Memory (RAM). Since malware programs typically consumer RAM resources, it is easy to identify any network activities, running processes, and even open connections that might be malicious or intended to compromise the system in some way (Dolan-Gavitt, 2008; Haruyama & Suzuki, 2012). One of the best aspects of using Volatility Framework for malware analysis, forensics, or even intrusion detection is the ease with which it can identify malware that runs in the background. More importantly, it is built to overcome some of the issues inherent in these processes like the losses of memory as a result of a probe for viruses and other malware. Volatility Framework makes use of crash dumps and raw dumps to inspect what is going on in the volatile memory (Ligh, Case, Levy, & Walters, 2014). Moreover, it can also serve as a way to analyze VirtualBox and VMware dumps. An invaluable advantage of using Volatility is that it does its work with minimal impact on system resources and almost entirely independent of the system on which investigations are taking place.

While checking for malware, one of the first – and most critical – stages is carrying out an integrity verification. During the process, the MD5 hash of the malicious system is computed to authenticate the acquired image before the analysis process begins (Dolan-Gavitt, Payne, & Lee, 2011). Once this is done, the volatility analysis process takes place. The Volatility tool is run to identify whether a system is infected or not. Typically, the progression involves an analysis of the memory dump to identify the running processes (Kawakoya, Iwamura, & Itoh, 2010). Volatility serves this need by determining profiles, then the “pslist” plugin is used to show the processes found in the dump. The investigator then looks at the processes listed specifically seeking out multiple but similar processes, since some malware tends to replicate itself, and those that have been added recently, assuming the checks are fairly regular (Sylve, Case, Marziale, & Richard, 2012). Usually, the “pstree” plugin is run to show the processes in a tree format so that the program that is responsible for the malicious processes can be easily identified.  After that, the “malfind” plug-in is applied to check for corrupted Dynamic Link Libraries (DLLs) which are then highlighted (Ligh, Case, Levy, & Walters, 2014). The “malfind” switch can also dump the malicious DLL’s into a designated directory after which they can be scanned by an antivirus and anti-malware program. According to Stevens & Casey (2010), some malware programs can also execute scripts through the command line. The Volatility Framework also has a “cmdscan” flag which can be used to show a recent history of the commands that were run on the terminal of the compromised machine.

How would being knowledgeable in the framework help an incident response investigator?

One of the most significant benefits that Volatility offers an incident response investigator is the fact that it is Open Source (GPLv2). As a result, one can not only read it but also learn it and extend it. With some knowledge of Python, the scripting language used to implement it – which is a must-have in any investigator’s arsenal – one can easily extend the program to suit his or her specific needs.  The fact that the framework is open also implies that the person using it does not have to work with a program that gives no indication of its internal working and how the values that it throws out come from, or even how they were interpreted. Competing products suffer from unnecessary complexity which almost always translates to the need to compile DLLs. Others do not even expose a programming API in the first place. Volatility’s open nature is also an advantage since any flaws in the system can be fixed in a relatively straightforward manner and without having to resort to the usual wait for vendors to confirm the bugs and publish patches. Since the framework runs on Windows, Linux, and Mac OS, the investigator can work in the system with which he or she is most conversant.  

A similar advantage of the Volatility Framework derives from how extensible it is. Aside from the modular architecture, Volatility is also bundled with a scriptable API which makes it exceedingly easy for the investigator to innovate on his own. A forensic analyst can add all the necessary functionality that will support the execution of the task at hand. More than that, since the framework supports a large number of file formats across multiple Operating Systems, Volatility can analyze crash dumps, raw dumps, hibernation files, VMware files, VirtualBox dumps, Linux Memory Extractor (LiME) files, and even Expert Witness Files (EWF). More importantly, interoperability rules make it simple to convert the data from one format to another. One only needs to imagine how important it is to be able to analyze a dump file, in whatever form it comes in, as quickly as possible to discover how critical a tool Volatility is in incident response situations. Volatility can also access direct physical memory as long as the target machine has a FireWire port. The most important advantage, though, has to be that the Volatility Framework has algorithms that can efficiently analyze massive memory dumps without a significant bump in the use of system resources, or significant consumption of memory, which according to Haruyama & Suzuki (2012) is a hallmark of good design.

How to extract cached TrueCrypt passwords and master keys using Volatility?

Balogh & Pondelik (2011), came up with a procedure to recover the decryption keys from the dump of the live image of a volatile memory. Their proposal was specifically targeted at Windows and Linux machines running TrueCrypt, a free and open source program that was the golden standard for real-time disk encryption. The authors’ technique was particularly important since it had been disclosed that one of the pitfalls, and a precarious one at that, of TrueCrypt disk encryption, was that it relied on saving the master keys in the RAM to provide fully transparent encryption (Balogh & Pondelik, 2011). If the master keys were not saved on the disk, then the only other option – based on the implementation of TrueCrypt – would have been to write plain text keys to an alternative storage location, and with significant overheads in performance (Zhang, Zhou, & Fan, 2014). Simply put, since the design of the software necessitated that master keys are available in the RAM, they could be intercepted and used to breach the system’s security. The only way to stop such an attack would then be to turn off the machine to flush the RAM. When TrueCrypt is used for disk encryption, it typically uses the AES encryption scheme in XTS mode which uses two 256-bit keys together to form one 512-bit, or 64 bytes, master key (Zhang, Zhou, & Fan, 2014). For an attacker, the benefit of this is that the patterns to AES keys are easily discernible from other from other seemingly random bits of data. As a result, one can quickly identify the two keys that need to be joined together to form the concatenated master key. Thus, it is probably accurate to state that TrueCrypt is not safe, based on its design, and therefore cannot be used safely.

Conclusion

In conclusion, the Volatility Framework is an important tool in the arsenal of any Incident Response Investigator. Not only is it expandable though a programmable API, but it is also modular, open-source, and has a robust user community. Since the framework is can be extended through the use of plugins, supports virtually all the available operating systems, and has a light performance footprint, there is no reason not to use the framework.

References

Baláž, A., & Hlinka, R. (2012, November). Forensic analysis of compromised systems. In Emerging eLearning Technologies & Applications (ICETA), 2012 IEEE 10th International Conference on (pp. 27-30). IEEE.

Balogh, Š., & Pondelik, M. (2011, September). Capturing encryption keys for digital analysis. In Intelligent Data Acquisition and Advanced Computing Systems (IDAACS), 2011 IEEE 6th International Conference on (Vol. 2, pp. 759-763). IEEE.

Bashir, M. S., & Khan, M. N. A. (2013). Triage in live digital forensic analysis. International journal of Forensic Computer Science, 1, 35-44.

Carrier, B. (2005). File system forensic analysis. Addison-Wesley Professional.

Chan, E., Venkataraman, S., Tkach, N., Larson, K., Gutierrez, A., & Campbell, R. H. (2011, May). Characterizing data structures for volatile forensics. In Systematic Approaches to Digital Forensic Engineering (SADFE), 2011 IEEE Sixth International Workshop on (pp. 1-9). IEEE.

Dolan-Gavitt, B. (2008). Forensic analysis of the Windows registry in memory. digital investigation, 5, S26-S32.

Dolan-Gavitt, B., Payne, B., & Lee, W. (2011). Leveraging forensic tools for virtual machine introspection. Georgia Institute of Technology.

Haruyama, T., & Suzuki, H. (2012). One-byte modification for breaking memory forensic analysis. Black Hat Europe.

Kawakoya, Y., Iwamura, M., & Itoh, M. (2010, October). Memory behavior-based automatic malware unpacking in stealth debugging environment. In Malicious and Unwanted Software (MALWARE), 2010 5th International Conference on (pp. 39-46). IEEE.

Kornblum, J. D., & ManTech, C. F. I. A. (2006). Exploiting the rootkit paradox with windows memory analysis. International Journal of Digital Evidence, 5(1), 1-5.

Law, F. Y., Chow, K. P., Lai, P. K., & Hayson, K. S. (2009, September). A host-based approach to botnet investigation?. In International Conference on Digital Forensics and Cyber Crime (pp. 161-170). Springer, Berlin, Heidelberg.

Lempereur, B., Merabti, M., & Shi, Q. (2011, December). Information flow monitoring: model, policy, and analysis. In Developments in E-systems Engineering (DeSE), 2011 (pp. 227-232). IEEE.

Ligh, M. H., Case, A., Levy, J., & Walters, A. (2014). The art of memory forensics: detecting malware and threats in windows, linux, and Mac memory. John Wiley & Sons.

Petroni, N. L., Walters, A., Fraser, T., & Arbaugh, W. A. (2006). FATKit: A framework for the extraction and analysis of digital forensic data from volatile system memory. Digital Investigation, 3(4), 197-210.

Ptacek, T. H., & Newsham, T. N. (1998). Insertion, evasion, and denial of service: Eluding network intrusion detection. Secure Networks Inc. Calgary Alberta.

Stevens, R. M., & Casey, E. (2010). Extracting Windows command line details from physical memory. digital investigation, 7, S57-S63.

Sylve, J., Case, A., Marziale, L., & Richard, G. G. (2012). Acquisition and analysis of volatile memory from android devices. Digital Investigation, 8(3), 175-184.

Van Baar, R. B., Alink, W., & Van Ballegooij, A. R. (2008). Forensic memory analysis: Files mapped in memory. digital investigation, 5, S52-S57.

Walters, A. (2007). The volatility framework: Volatile memory artifact extraction utility framework.

Zhang, R., Wang, L., & Zhang, S. (2009, August). Windows memory analysis based on kpcr. In Information Assurance and Security, 2009. IAS’09. Fifth International Conference on (Vol. 2, pp. 677-680). IEEE.

Zhang, L., Zhou, Y., & Fan, J. (2014, May). The forensic analysis of encrypted Truecrypt volumes. In Progress in Informatics and Computing (PIC), 2014 International Conference on (pp. 405-409). IEEE.