Evolution of Digital Forensics in Virtualization by Using
Virtual Machine Introspection
James Poore*
Juan Carlos Flores
Travis Atkison
Louisiana Tech University
Ruston, LA 71270
Louisiana Tech University
Ruston, LA 71270
Louisiana Tech University
Ruston, LA 71270
[email protected]
[email protected]
[email protected]
ABSTRACT
Computer virtualization is not a new technology, it has become
increasingly important because of the many advantages it offers to
businesses and individuals to reduce costs, while introducing new
challenges to the field of digital forensics. As virtualization
continues to be adopted by more and more companies every year,
malware and hacker attacks are going to have an increasing effect
on virtualized systems. Therefore, the increasing growth of
virtualization has created the need for a new generation of
computer forensic tools and techniques to analyze these
compromised systems.
Because of the rapid growth of
virtualization, new techniques to interact with virtual systems
have been developed. Some of these techniques reduce the
limitations of traditional forensics tools abilities to analyze the
virtual system. Virtual Machine Introspection (VMI) is one of
these techniques that have formed the basis for a number of novel
approaches in the fields of cyber security and digital forensics.
This paper explores how VMI improves traditional digital
forensics to overcome its downfalls when used to investigate
virtual machines, especially during a live analysis of the machine.
Categories and Subject Descriptors
D.4.6 [Operating Systems]: Security and Protection
General Terms
Security, Legal Aspects
Keywords
Digital forensics, Virtual Machine, Virtual Machine Introspection,
Cyber Security, Virtualization, Live Analysis
1. INTRODUCTION
In the early days of computing, virtualization was heavily used on
mainframes to isolate different users from one another. With the
success of mainstream personal computing that occurred starting
in the 1980’s, virtualization was almost forgotten as more and
more computers started showing up in homes and offices.
Recently however, there has been a rebirth of virtualization as it
offers both business and individuals alike many advantages that
cannot be achieved with just the use of physical machines.
With the increased use of virtualization and the increase of
criminal attacks against computers it is very important that a
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ACMSE'13, April 4-6, 2013, Savannah, GA, USA.
Copyright 2013 ACM 978-1-4503-1901-0/13/04...$15.00
* Corresponding Author
method of analyzing virtual machines exists. Currently digital
forensics is a very vast field in which there are many
developments of novel approaches for investigating digital crimes.
Unfortunately most of these approaches are designed for use on
physical machines with the ability to shut down the machine if
needed. In most cases these approaches do not apply to virtual
machines used in the business sector.
In this paper the concept and benefits of using virtual machine
introspection with digital forensics are discussed. First, it is
shown how traditional digital forensics operates without virtual
machine introspection. Then virtual machine introspection is
explained and a testing environment is detailed. Lastly, results
from the experiments are detailed and explained, showing
evidence of the benefits of using virtual machine introspection
with digital forensics to analyze a virtual machine as it is running.
2. BACKGROUND
2.1 Virtualization
Virtualization was first used to isolate different users that were
simultaneously accessing a mainframe server, but it lost
importance as personal computers became cheaper and more
popular around the world. Recently however, virtualization has
grown in popularity again because of the advantages it offers to
businesses and individuals to reduce costs and provide versatility.
Virtualization technology has developed rapidly because of the
steep decrease in hardware costs and concurrent increase in
hardware computing power [1]. Many companies have made
extensive use of virtualization to virtualize even entire networks
to reduce costs and increase service efficiency [3]. It simulates an
actual machine and applications as well as operations system do
not notice that they are running on a virtualized system rather than
a physical machine [6]. Virtualization provides the opportunity for
multiple operating systems to exist on a single physical machine
by creating a virtual machine for each operating system. Those
operating systems can range from a Windows environment to a
Linux environment without the limitation of running a single
operating system per physical machine. A virtual machine
simulates its own set of hardware (CPU, hard disk, memory,
network controller, and other components), which allows software
to execute as if was executed in a physical system [2].
Although virtualization offers many advantages, it introduces new
challenges to the field of digital forensics and cyber security. In
the field of digital forensics, investigators need to detect and
analyze such virtual environments as they become more common
in personal computers and data centers. In a case in which a
virtual machine is used to commit a crime, obtaining an image of
the physical computer hard drive provides little evidence, if any,
since all the evidence is in the virtual hard drive. Given that a
virtual machine is a representation of a physical machine,
vulnerabilities and attacks that affect a physical system also affect
its virtual representation. It is logical to assume that traditional
digital forensics tools and techniques used to analyze a physical
machine are good enough to analyze a virtual machine. However,
the same flaws found in common digital forensic tools when they
are used to analyze physical machines are also found when used
on virtual machines. They can contaminate evidence during a live
forensics analysis of a physical machine. In data centers, for
instance, analyzing many virtual machines at the same time will
not be possible with traditional tools that are used to analyze a
single system at the time. Therefore, new or improved tools and
techniques are necessary to protect and analyze virtual machines.
2.2 Digital Forensics
2.2.1 Introduction to Digital Forensics
Digital forensics is becoming increasingly important as criminals
aggressively expand the use of digital technology for illegal and
malicious activities. Digital forensics has developed rapidly, due
to rise in computer-related crimes. Computer forensics, which is a
branch of digital forensics, “is the scientific collection, recovery
preservation, legal analysis and presentation of data held or
retrieved from computer storage media in such a way that the
information can be used as evidence in a court of law” [9, 10]. It
focuses on obtaining and analyzing digital information for
criminal, civil and administrative cases [11]. Preserving the
integrity of the data on the machine and collecting that data in a
way that others involved in the case can trust it are some of the
challenges in digital forensics. Whether it is a system
administrator or a forensic investigator, they must provide
assurance that the data is interpreted in the same way as though it
is interpreted on the machine being investigated.
2.2.2 Live and Dead Analysis
Live analysis and dead analysis are two common types of
investigations in digital forensics. Simply put, a live analysis is
done on a machine while it is running. Examining a machine
while it is running is not ideal, because many changes to the state
of the system are made during the investigation, but is
occasionally necessary. These changes contaminate the evidence
and affect the validation of the evidence in a case. In the last
decade, live analysis has become very important because of the
evidence that is present while the machine is running. Information
about the open files, running processes, network connections,
volatile malware and encryption keys are common examples of
the types of data that an investigator can recover from a running
operating system. Performing a live analysis in many data center
systems, for instance, is required because these systems must be
running for as long as possible to keep providing their services.
Dead analysis, on the other hand, is performed while a machine is
off. An identical image of the machine’s storage media is created
and analyzed to extract data from it. By working with an image of
the original storage media, the possibilities of contaminating the
original source of evidence are reduced. It is easier to investigate
static data from a system that is off than active data from a system
that is constantly running and changing. Because performing a
dead analysis of a virtual machine is very similar to the analysis of
a physical machine, dead analysis is out of the scope of this paper.
2.2.3 Issues with Digital Forensics in Virtualization
Traditionally, during a live analysis, a forensic investigator
accesses the system environment to gather information that is
temporary or volatile in the system and that cannot be obtained
from the storage media alone. An investigator uses third-party
forensic tools or tools that are already built into the system to
gather information about the system. Most of these applications
make use of the operating system APIs to gather information
about the system. The problem with running software within the
system is that the software makes changes to the state of the
machine and contaminates evidence. This violates one of the main
rules in digital forensics, which is not to alter the original data of a
system during an investigation. A solution to the memory state
alteration problem is to create a memory image of the virtual
machine to analyze it offline and reduce the time spend within the
system; however, creating the memory image is traditionally done
from within the operating system and so the problem persists.
Although the investigator has the option to preserve the state of
the VM before it is analyzed by creating a snapshot of the virtual
machine, this is not suitable when the VM is actively being
attacked because evidence is missed.
3. IMPLEMENTING VMI WITH
TRADITIONAL DIGITAL FORENSICS
3.1 Virtual Machine Introspection
Virtual machine introspection (VMI), a term first used by
Garfinkel and Rosenblum [4], is a virtualization technique that is
used to monitor a virtual machine through its hypervisor or a
privileged virtual machine. It allows extracting information from a
virtual machine without affecting its functionality or memory
state. VMI allows applications to run in an isolated virtualized
machine to monitor the state of other virtual machines without
affecting their operation. By isolating applications in a virtual
machine and using VMI, the applications are protected from
malware or direct attacks that affect other virtual machines. The
goal of VMI is to make the observation of a VM’s states and
events possible from outside the VM [8]. This allows, for
instance, placing an intrusion detection system (IDS) in an
isolated virtual machine to check for any intrusions in other
virtual machines. If one of the virtual machines is successfully
compromised, the IDS is not affected because it is isolated in a
separated virtual machine. IntroVirt [12] Livewire [4] and
VMWall [13] are examples of applications that have been
developed or proposed through research in VMI. Although some
of these tools take a different approach to perform VMI, they
show that potential in VMI to secure or examine virtual machines.
In order to interpret OS-level data structures, VMI applications
must translate virtual addresses to their physical location in
memory. A set of page tables is used to perform the virtual to
physical location mapping on x86-based systems. Virtual memory
becomes accessible once the page tables for the kernel address
space are located. This allows applications to extract more
meaningful data about the state of the system [5]. Once the data is
extracted the application must understand the low-level data to
gather high-level data, which introduces the semantic gap
problem.
In
Xen,
for
instance,
the
function
xc_map_foreing_range() in the XenControl Library map the
memory from one VM into another VM. After this memory is
mapped, it is treated as local memory, providing for fast
monitoring capabilities [7]. VMI libraries, such as XenAcess, that
view the memory content of another VM use this same function.
VMI has become very important in virtualization because it
allows doing things that were almost impossible in physical
systems; however, the semantic gap problem is still present and
most be solved to take advantage of the full potential of VMI [22].
3.2 Semantic Gap
A raw representation of the current, monitored virtual machine is
obtained when introspection of the state of a virtual machine is
made. This information become difficult to interpret because
native operating system PI’s are not available; therefore,
information about the system must be gathered by locating and
examining the internal data structures that the in-guest API’s use
[5]. This inability to get high-level data from low-level data
describes what is known as the semantic gap problem. Several
approaches have been proposed to try to narrow or skip the
semantic gap; however, this is an active area of research [4, 5, 20,
22].
Out-of-band delivery, in-band delivery, and derivation are three
patterns used to bridge the semantic gap when using virtual
machine introspection [21]. With the out-of-band pattern, the
semantic knowledge is received in advance, before VMI begins.
The information that is obtained from this approach is not bound
to the current state of the virtual machine being monitored. One
of the main advantages of this technique is that it allows complete
access to the system state. However, it is not guest portable, that
is, if the system software is changed or replaced, the description
of the software architecture must also be changed to reflect this.
In-band delivery uses an internal component of the introspected
virtual machine to provide information about what is happening in
the virtual machine. It avoids the semantic gap by making use of
the guest OS’s inherent knowledge of the software architecture.
Nevertheless, this is not safe because an attacker or piece of
malware can compromise the component that provides the
information. In the derivation pattern, information about the
introspected machine is derived through semantic knowledge of
the hardware architecture. Because it makes no use of the guest
software, it is guest portable. Furthermore, it allows complete
access to the system state as well as offline analysis support.
There are several drawbacks with the derivation pattern. There is
a lot of information that cannot be extracted by only making use
of hardware architectural knowledge. Hence, a lot of information
that is present in the state is lost through the view generating
function [21, 22].
3.3 Digital Forensics with VMI
Given that a forensic investigator must access the system
environment to access its volatile data or create an image of it, a
technique must be created so that no changes are made to the
system during the investigation of a virtual machine. VMI allows
such technique to exist by allowing an investigator monitor a
virtual machine without affecting its state. It allows a forensic
investigator to access the virtual machine memory space by
interacting with the virtual machine from the outside with readonly rights, so that no changes are made to the state of the virtual
machine. This feature of VMI has helped the creation of many
great applications for the field of cyber security, but very few
have been created for the field of digital forensics since most
common traditional forensic tools are used. By using VMI many
of the problems found in forensic live analysis are solved, but the
semantic gap problem remains. Even after a memory dump is
extracted from the virtual machine, its content has to be
understood before useful data can be extracted out of it. Running
tools within the virtual machine to make use of its APIs while it is
running is a logical solution, but these tools contaminate evidence
because of the changes made by the tools when executed within
the system. Likewise, the tools being run within the system can be
compromised by malware in the system to make it display
erroneous information, which is what rootkits commonly do.
Rootkits hide the execution of malware binaries from users in the
system. They do this by injecting malicious code into a running
binary or by tampering with the binary image on disk [16].
As mentioned previously, live analysis has become very important
because of the large amount of useful information that is only
available while the system is running. Although during a live
analysis many changes are made to the state of the system, VMI
can overcome many of the drawbacks in live analyses allowing an
investigator to monitor a virtual machine without affecting its
state. In order to do this, forensic software with VMI capabilities
is required to gather evidence of a virtual machine without
accessing it directly. Nevertheless, the semantic gap problem is
still an issue to fully understand the VM’s memory content and
see what is happening in it. One method to overcome this is to
create new applications that understand the low-level data that is
extracted from the virtual machine by using VMI [5]. This is a
complex process because in order to write these new applications
a lot of knowledge is required about the internals of an operating
system, which is difficult in close source operating systems. It is
also impractical because these new tools are not compatible with
all other operating systems. There have been several methods that
bridge or skip the semantic gap problem instead of solving it. A
solution to this problem is to have software that runs within the
virtual machine to gather information about the state of the virtual
machine and send that information to software running outside of
the virtual machine; however, if an attacker compromises the
virtual machine, he can control the software running in the VM to
send erroneous information back. For instance, a call to a process
list tool is made to get a list of all the active processes on the
system to be sent out to the caller waiting outside of the VM;
however, a rootkit makes the internal tool send out a modified list
of processes, which hides the processes its processes running in
the system.
Extending the capabilities of common forensic tools to make them
work with VMI is another solution to the semantic gap problem.
Making use of the advances in common live analysis tools and
combining them with VMI narrows the semantic gap problem by
reusing what other forensic tools are already capable of doing.
Volatility is a forensic tool that can extract information about
open ports, active processes and other data from a memory dump
image [14]. Volatility also deals with the semantic gap problem
because it has to understand the memory dump raw data to extract
meaningful information from it; however, a lot of work has been
done and is being done with Volatility to improve its capabilities
of extracting high-level semantic information from low-level data
sources. By adding VMI capabilities to this type of tools, a lot of
work can be saved and the semantic gap can be narrowed when
working with VMI.
4. METHODOLOGY
This paper focuses on how VMI can transform the field of digital
forensics to overcome its flaws when used to analyze virtual
machines. Therefore, it looks into some of the strengths that VMI
offers to the field of digital forensics to make it feasible to analyze
virtual machines. In order to do this, experiments were done to
obtain results from different scenarios that included virtualization
and common forensic tools. Figure 1 illustrates an abstract model
about how the systems were set up to test VMI tools with
traditional digital forensic tools and techniques.
The experiments were done in the following way. A test tool was
modified to obtain a list of processes that were running within a
Windows XP virtual machine. A configuration file was created
based on the offset values that were obtained for Windows XP
SP3. Since the version of libVMI library used for the experiments
does not provide a way to obtain the offset values from within
Windows virtual machines, the offset values had to be obtained by
machine to create the memory image, hence the virtual machine
had to be accessed to install the FTK tool and extract the memory
image from it. The memory image was stored and analyzed
offline with an unmodified version of Volatility to gather
information about the virtual machine. The clean VM was then
infected with rootkit to generate evidence and collect it during the
experiments. Likewise, the virtual machine was attacked and
compromised by using the Backtrack system that was set up on
the local network. A very well known Windows vulnerability in
the Windows XP virtual machine was exploited by using
Metasploit, available in the Backtrack Linux distribution. The
system was attacked to generate evidence that can be collected
during the experiments
Figure 1. System setups for experiments.
looking at the type definitions of Windows XP SP3 in Volatility
[15]. In order to demonstrate that the VMI process list tool
accurately list the processes running on the Windows domU VM,
it had to be compared with built-in tools that run within the virtual
machine. The built-in common tool for Windows XP Professional,
task list, was run within the domU virtual machine to obtain a list
of processes that were running on it. After this was done, the VMI
process-list tool was executed from within dom0 to obtain a list of
the processes running within domU. Both process lists were stored
to compare them later on. It should be noted that the process lists
were created to show that the virtual machine was in a clean state
and to compare them later on with other process list from an
infected virtual machine. The virtual machine was then infected
with a rootkit to obtain new process lists from both tools and
compare them.
Even though writing single purpose tools to obtain different types
of information from domU commonly needed in digital forensics
seems like a good strategy, the semantic gap is still a problem in
the development of each tool. Hence, a better strategy is necessary
to overcome this problem. Adapters such as pyVMI can be used to
extend the capabilities of certain forensic tools that have already
narrowed the semantic gap in certain areas. Volatility can be
expanded with pyVMI to analyze a running virtual machine by
suing VMI. In order to demonstrate that this is feasible, other
experiments were done. A traditional method was used with
Volatility to analyze a couple of virtual machines. The virtual
machines were analyzed while they were in a clean and infected
state to compare the changes made to the system and how these
changes can be detected. Since Volatility is traditionally used to
analyze memory images, a memory image of the virtual machines
had to be created and analyze offline. For these experiments the
memory image had to be created from within the virtual machine.
A modified version of the Volatility that uses VMI was then used
to analyze a couple of virtual machines from within dom0 without
accessing the virtual machine to create a memory image.
First of all, a clean Windows XP SP3 virtual machine was
accessed to create an image of its memory state, which is
normally done during a traditional live analysis of a physical
machine. Forensics Tool Kit, FTK imager was used to create the
memory image, which was then stored in an USB memory drive
[17]. FTK is an industry standard forensic tool that can create
memory images of Windows operating systems as well as other
forensic tasks. FTK imager had to be installed on the virtual
Metasploit was used to compromise the virtual machine by using
the ms08_067_netapi vulnerability. Meterpreter, a popular
payload available in Metasploit, was used to keep control of the
system. A few backdoors were installed on the system as well and
hidden with the rootkit used to infect the virtual machine. While
the system was being attacked, another memory image was
created with FTK Imager and stored in a USB flash drive. This
new memory image was analyzed offline to compare the results
with the results that were obtained earlier in the analysis. It should
be noticed that both images were analyzed with the unmodified
version of Volatility to demonstrate what can be obtained during a
traditional digital forensic analysis. A new Windows XP clone
was used to analyze it with the modified version of Volatility. The
procedure was similar to what was done previously with the
unmodified version of Volatility; however, the modified version
of Volatility with VMI was used from within dom0. The results
from this new set of experiments were required to compare them
with the results obtained from the unmodified versions of
Volatility. Comparing these results helps to contrasts the
techniques used in both sets of experiments and how VMI
overcomes flaws commonly found in traditional digital forensic
techniques. Volatility was patched and used within dom0 to
analyze the memory content of the domU virtual machine. The
configuration file for libVMI had to be recreated for the Windows
XP virtual machine. Since Volatility was using VMI, a memory
image of the virtual machine was not required, thus no software
had to be installed on the virtual machine to create the memory
image. Volatility contains a large number of plug-ins to gather
different types of information, but only a set of plug-ins were used
to make the comparison of results more specific. Processes
running in the machine, loaded modules, sockets and network
connections are the type of information that was obtain from the
virtual machine while it was in a clean state and an infected state.
The results were stored in a safe place to compare them later with
other results. After the Windows XP virtual machine in is clean
state was analyzed and the results stored in a safe location, the
Windows XP virtual machine was infected with a rootkit and
attacked with Metasploit from the Backtrack system located in the
local network. The modified version of Volatility was used to
analyze the infected Windows XP virtual machine to collect
information about what was happening in the virtual machine. The
results were stored to compare them with other results obtained
earlier.
A Windows 2003 SP2 virtual machine was created to do similar
experiments. A new configuration file had to be created for the
Windows 2003 virtual machine. Since it was a Microsoft’s
Windows operating system, the module that comes with libVMI
cannot be used to obtain the offset values for this operating
system. Even though Windows 2003 and Windows XP are
similar, they use different offsets values. These values were
obtained by looking at what offset value was in the Volatility type
definitions. The configuration file was created with the new offset
values for Windows 2003 and the file was stored in dom0. The
Windows 2003 virtual machine was analyzed with Volatility from
within dom0 while it was in a clean state. Since VMI was being
used with Volatility, a memory image of the Windows 2003
virtual machine was required. The results were obtained and
stored to compare them with other results related to this virtual
machine. The Windows 2003 was infected with a rootkit, a remote
access tool (RAT) and a stealth key-logger to collect evidence
from a different set of malicious programs. The remote access tool
used to infect the virtual machine was created using CyberGate,
this allows an individual to have remote control of the system
[18]. The key-logger, Armadax, was used to infect the system
[19]. Armadax allows an individual to log all keystrokes and send
somewhere on the Internet. Some of the processes that belong to
the key-logger can be hidden, if the individual so desires. After
the Windows 2003 virtual machine was infected, it was analyzed
with the modified version of Volatility from within dom0 to
gather information about what was on the system. It should be
noted that only the modified version of volatility was used this
time to analyze the virtual machine in its clean and infected state.
This demonstrated that the virtual machine can be analyzed by
using only VMI and how it can log changes in the system almost
immediately. The results from both experiments were stored to
analyze and compare them.
Clones of the domU VM were used during all the experiments to
keep identical environments for each experiment. At the
beginning of each experiment, each used domU virtual machine
was rolled back, so that experiments were done in an identical
environment. Comparing results obtain during a clean and
infected state helped to contrast the methods and the tools used
during the experiments. Likewise, this helped to see how VMI
overcomes flaws of traditional digital forensics especially in live
analyses to get more accurate results from a digital forensics point
of view. Even though XenAccess can only be used with Xen to
create VMI tools, libVMI is used to create VMI tools for the Xen
hypervisor as well as the KVM hypervisor. It should be noted that
all the results were stored in text files or screenshots were taken of
the terminal window to show them in figures placed in the
following section.
Figure 2. Processes running on clean Windows XP VM.
Figure 3. Processes running on the VM after its infection.
5. RESULTS
Based on the experimenting environment that was described in the
previous section, the experiments were conducted. For the first
experiment, a process list that contains information about the
currently active processes in the clean VM was obtained by using
the task list tool built in to Windows. This type of tool is usually
used during the active analysis of an attack to see if any unknown
processes are running on the system. The tool listed the processes
that were running on the system as illustrated in Figure 2.
Since the state of the VM was clean and no other software had
been installed, only Windows XP default processes were found to
be running on the VM. After the results were obtained from the
task list tool, the system was infected with the rootkit and a
backdoor was open and hidden, to experiment if the built-in
process list tool in Windows XP detects and lists the processes
that belong to the rootkit and back door. As illustrated in Figure
3, the built-in process list tool, tasklist, keeps listing the same
processes and no changes are seen except for the execution of the
tool itself.
The rootkit used in this experiment is known for being stealthy, as
it injects code into all running processes on the machine; likewise,
Figure 4. Hidden processes revealed with VMI tool.
it patches several Win32 API’s so that it can filter the information
that is provided back to software that uses those API’s. Hence, it
is able to hide itself from tools that are executed on the machine.
This exposes one of the main downfalls of performing a live
analysis on an infected machine with traditional forensic tools.
Tools that are run on the system can relay erroneous information
regarding the state of the system if the system is compromised
with similar types of malware as those used in this experiment.
Since the tool runs at the same or lower level as the malware, the
malware can control what the tool sees and detects. After this was
complete, the modified VMI process list tool was experimented
and used to list the processes run on domU from within dom0.
After the configuration file for the VM was setup, the VMI tool
was run from the terminal in dom0. The tool ran in a considerably
short amount of time and listed the processes that were not listed
with the process list tool supplied with Windows XP, as illustrated
in Figure 4.
Although the rootkit was able to hide its processes from the
Windows tasklist tool, the VMI tool was able to reveal the
processes because it does not depend on the operating system
API’s to obtain the information in needs to list the processes
running within the machine. It obtains the information directly
from memory by transforming the low level data into high level
information that is understood by the investigator. It should be
noted that the VMI tool did not list the process for the tasklist tool
that was listed in Figure 2 and Figure 3. This is due to the fact
that the tasklist tool process quits running as soon as it is finished
listing the processes running on the system. After the process list
has been generated, the tasklist tool quits running even if the
terminal remains open. As a result the VMI tool did not list it
because it was used after the tasklist tool had listed all of the
process running on the machine and had therefore quit itself.
6. CONCLUSION
With the increasing use of virtualization in computing today, and
the rise of criminal activity towards computers there is a demand
for the ability to analyze virtual systems while they are under
attack. Combining virtual machine introspection, VMI, with
traditional practices of digital forensics provides investigators and
businesses a way to do so. In this paper, we discussed virtual
machine introspection and digital forensics, and we showed some
of this issues that arrive with the use of traditional digital
forensics on a virtual machine. Also mentioned are issues with
VMI such as the semantic gap problem. Lastly, we showed how
the two could be combined to achieve a method of investigation
that allows a virtual machine to be analyzed while it is running
without affecting its state and provide result from conducting
experiments on virtual machines using this technique. While the
techniques detailed are not the ultimate solution to forensic
analysis of virtual machines, they do provide a great step forward.
ACKNOWLEDGMENTS
This material is based upon work supported by the U.S. Air Force,
Air Force Research Laboratory under Award No. FA9550-10-10289.
7. REFERENCES
[1] Qian L., Chuliang W., Minglu L., Yuan Lu., An In-VM
Measuring Framework for Increasing Virtual Machine
Security in Clouds, Security & Privacy, IEEE, Vol. 8, No. 6,
pp. 56-62, Nov-Dec 2010.
[2] D. Bem and E. Huebner, Computer Forensics Analysis in a
Virtual Environment, International Journal of Digital
Evidence, Vol. 6, No. 2, 2007.
[3] Gavrilovska, A., S. Kumar. Abstract High-Performance
Hypervisor Architectures: Virtualization in HPC Systems.
Proc. Of HPCVirt 2007, Portugal, Mar 2007.
[7] Payne, B., Carbone, M., Lee, W., Secure and Flexible
Monitoring of Virtual Machines. Computer Security and
Applications Conference, 2007. ACSAC 2007. Twenty-Third
Annual, Vol., No., pp. 385-397, 10-14 Dec 2007 doi:
10.1109/ACSAC.2007.10
[8] Bahram, S., Jiang, X., Wang, Z., Xu, D., Rhee, J., Li, J.,
Srinivasan, D., DKSM: Subverting Virtual Machine
Introspection for Fun and Profit. Reliable Distributed
Systems, 2010 29th IEEE Symposium on, Vol., No., pp. 8291, Oct 31 2010-Nov 3 2010.
[9] Kruse II, W. G. and Heiser, J. G., Computer Forensics:
Incident Response Essentials (1st ed.): Addison Wesley
Professional, 2002.
[10] Thomas, D. S. and K. Forcht, Legal Methods of Using
Computer Forensics Techniques for Computer Crime
Analysis and Investigation. Issues in Information System
5(2). 2004.
[11] B. Nelson, A. Phillips, F. Enfinger, C. Steuart, Guide to
Computer Forensics and Investigations. Canada: Thomson
Learning, 2004.
[12] A. Joshi, S. T. King, G. W. Dunlap and P. M. Chen,
Detecting Past and Present Intrusions Through VulnerabilitySpecific Predicates, In SOSP ’05: Proceedings of the
Twentieth ACM Symposium on Operating System
Principles, (New York, NY, USA), pp. 91-104, ACM, 2005.
[13] A. Sri Vastava and J. T. Gin, Tamp Resistant, ApplicationAware Blocking of Malicious Network Connections. In
Proceeding of RAID. pp. 39-58, 2008.
[14] A. Walters, The Volatility Framework: Volatile Memory
Artifact Extraction Utility Framework, November 2011
[Online] https://www.volatilesystems.com/default/volatility.
[15] Volatility, Windows XP SP3 Type Definitions, Volatile
Systems, March 2012 [Online]
http://code.google.com/p/volatilty/source/browse/trunk/volati
lity/plugins/overlays/windows/xp_sp3_x86_vtypes.py.
[16] L. Litty, H. Lagar-Cavilla and D. Lie, Hypervisor Support for
Identifying Covertly Executing Binaries, In SS ’08:
Proceedings of the 17th Conference on Security Symposium,
(Berkeley, CA, USA), pp. 243-258, USENIX Association,
2008.
[17] AccessData, FTK Imager, AccessData, November 2011.
[Online] http://accessdata.com/support/adownloads.
[18] Cyber-Software, CyberGate, Cyber-Software. April 2012.
[Online] http://www.cyber-software.org/site/?p=490.
[19] Armadax Software, Armadax Keylogger, Armadax Software,
2012. [Online] http://www.armadax.com/keylogger/.
[4] T. Garfinkel and M. Rosenblum, A Virtual Machine
Introspection Based Architecture for Intrusion Detection, In
Proc. Network and Distributed Systems Security
Symposium, pp. 191-206, 2003.
[20] Dolan-Gavitt, B., Leek, T., Zhivich, M., Lee, W., Virtuoso:
Narrowing the Semantic Gap in Virtual Machine
Introspection. Proceedings of the IEEE Symposium on
Security and Privacy (Oakland), May 2011.
[5] Payne, B., Lee W., Dolan-Gavitt, B., Leveraging Forensic
Tools for Virtual Machine Introspection. Technical Report.
Georgia Institute of Technology, GT-CS-11-05, 2011.
[21] Pfoh, J., Schneider, C., and Eckert, C., A Formal Model for
Virtual Machine Introspection, in Proceedings of the 2nd
Workshop on Virtual Machine Security (VMSec ’09),
(Chicago, Illinois, USA), pp. 110, ACM Press, Nov 2009.
[6] Nance K., hay, B., Bishop, M., Investigating the Implications
of Virtual Machines Introspection for digital forensics.
International Conference on Availability, Reliability and
Security. 2009.
[22] Cruz, J. C. F., Atkison, T., Evolution of Traditional Digital
Forensics. ACMSE’12.