2013 Seventh International Conference on IT Security Incident Management and IT Forensics

Visualizing Indicators of Rootkit Infections in Memory Forensics

Stefan Vömel Hermann Lenz

Department of Computer Science Thor GmbH
Friedrich-Alexander-University Landwehrstraße 1, 67346 Speyer, Germany
Martensstraße 3, 91058 Erlangen, Germany [email protected]
[email protected]

Abstract
Research in the area of memory forensics has been flourishing over the last years, and powerful analysis
frameworks such as Volatility have been developed. While these frameworks permit examining a forensic memory
snapshot in great detail, they mainly aim at experienced investigators with a thorough knowledge of operating
system internals. On the other hand, result correlation and interpretation is especially demanding for personnel
with only marginal forensic expertise as they are often found in IT departments of smaller- and medium-sized
enterprises. This task becomes even more challenging when attempting to detect traces of sophisticated malicious
applications such as rootkits.
In this paper, we present rkfinder, a plug-in for the well-known forensic framework DFF, that integrates
major capabilities of Volatility into an intuitive and easy-to-use graphical user interface. Rkfinder generates an
abstract, tree-like view of the system state, implements checks that are capable of revealing inconsistencies, and
automatically highlights suspicious objects that may indicate the presence of a threat. Thereby, potential sources
of a system infection are better visible and can be better addressed in the course of incident response.

Keywords
memory forensics; memory analysis; rootkit detection; Digital Forensics Framework; Volatility

I. I NTRODUCTION
A forensic analysis of volatile data in system RAM may reveal a substantial amount of evidence
from a computer in question. Recovered artifacts can include state- and runtime-specific information
such as the list of running and priorly executed processes [5, 19, 50], currently logged-on users [17],
open network connections [39, 45, 51, 63] as well as accessed files [15, 56], and may prove invaluable
when verifying hypotheses and drawing conclusions. In comparison to hard disk-centric approaches in
computer forensics, the value of memory-based examinations is often equal or can even lead to more
expressive results. For instance, a number of malicious software applications are known to run solely in
memory and, therefore, would remain undetected in the course of a traditional, persistent data-oriented
investigation [41, 44, 54]. Likewise, a forensic analysis of a hard drive would quickly face a dead end
in case a suspect used file or full disk encryption technologies and was unwilling to share the respective
decryption key. RAM forensics, in contrast, has turned out to be a suitable measure for such scenarios
[26, 27, 35, 40]. Last but not least, the size of a forensic memory snapshot is typically several orders
of magnitude smaller than the image of a hard drive, i.e., especially the acquisition process may be
finished more quickly and in a timely and cost-effective manner [62].
Taking these aspects into consideration, it comes at no surprise that research in the area of memory
forensics has been flourishing over the past years [60]. With the Volatility Framework, a powerful, free
open source tool has been published that is capable of efficiently processing RAM images of various
operating systems [57, 58]. Due to its modular architecture, recent analysis techniques and research

978-0-7695-4955-2/13 $26.00 © 2013 IEEE 122

DOI 10.1109/IMF.2013.12
directions can be easily integrated into the framework, making Volatility one of the standard solutions
for memory forensics-related tasks at the time of this writing.1
While reports generated by the application are rich in information, they mainly aim at forensic experts
that have an in-depth knowledge of operating system structures and internals. Result interpretation
for forensically lesser experienced practitioners, on the other hand, is complex and demanding. The
previously mentioned modular structure of the framework becomes an additional burden in this respect,
as users must explicitly decide what modules to run. Moreover, as a complete summary report is missing,
the output of executed modules must be matched and manually brought into connection. As we have
already pointed out, especially for personnel with only marginally-developed forensic expertise this may
be a daunting task and becomes even more challenging when scanning a system for malicious software.
Within the last years, the proficiency of malware applications has risen [33], and sophisticated methods
for system infection and contamination have been developed. Prominent examples that have been widely
discussed on the media include the Stuxnet [21] and Flame [37] worm that succeeded in running
stealthily on compromised machines for a significant time. Although modern malware species typically
fall into several classification categories to date [53], one type of a particularly dangerous software
variant are rootkits that are able to present a modified view of a computer’s state to the user by
subverting internal system structures. To detect such a rootkit, security experts commonly try to find
subtle inconsistencies that indicate the presence of a threat. Especially IT employees in smaller- and
medium-sized enterprises (SME) frequently lack training with regard to these activities though and,
therefore, may fail to properly notice and assess the severity of an incident.
Motivation for this Paper and Results
In order to cope with these issues, we present a plug-in (“rkfinder”) for the popular open source
forensic framework DFF [3]. Rkfinder integrates major capabilities of the Volatility Framework into
the graphical interface of DFF and thereby facilitates the analysis of a forensic memory snapshot even
for less experienced users. In addition, rkfinder filters, extends, and associates the output of different
Volatility modules to generate an abstract, tree-like view of the system state. By implementing several
consistency checks and automatically highlighting suspicious objects that have possibly been tampered
with or may be part of a rootkit infection, potential sources of an incident are directly visible and may
be better addressed in the course of a first response.
Last but not least, while research in the area of memory forensics has mainly concentrated on
identifying, finding, and extracting potential evidence to date, properly correlating and documenting
the respective information has been widely neglected so far. With respect to the classic investigation
process [9], it is therefore necessary to consider the reporting and presentation phases more carefully.
We hope that, by explicitly listing and summarizing essential pieces of evidence, our plug-in is capable
of better bridging this gap and helping investigators complete a case more efficiently.
Related Work
As we have already indicated, memory forensics has received broad attention over the last years,
and a lot of research has been done to learn (kernel) structures that, for instance, describe processes,
threads, and network resources. An overview of the relevant literature in this field is given by Vömel
and Freiling [60].
Various authors have examined RAM images specifically with respect to malicious software. However,
studies either frequently focus on certain technical aspects (e.g., see Burdach [5], Dolan-Gavitt [15],
1
For an overview of selected cases, please refer to the Volatility Documentation Project [59].

123
Schuster [51]) or on investigating particular malware samples. With respect to the latter, a collection
of exemplary analysis reports is provided by the Volatility Documentation Project [59]. On the other
hand, works that outline the forensic memory analysis process from a more holistic point of view or
that address the needs of users with little forensic expertise as they may frequently be found in, e.g.,
smaller and medium-sized enterprises are still sparse [39].
Methods for rootkit discovery have been extensively discussed, both in the academic as well as
industrial context. With regard to a running machine, a number of applications have been released
that are capable of successfully revealing system infections. Prominent examples include, for instance,
GMER [25], RootkitRevealer [11], or IceSword [46]. Although many of the available solutions show
good or even excellent detection rates [23, 55], they must be critically judged from a forensic point of
view, because they increase the level of data pollution and, thus, heavily violate the principle of non-
interference [42]. In addition, since operations significantly change the system state, the reproducibility
of results may not be guaranteed. Similar arguments hold true for live response activities that are
proposed by several researchers to find traces of installed rootkits [8, 10, 43]. In contrast, the rkfinder
software we present in this paper performs a post-mortem memory analysis and can therefore take best
practices in computer forensics more carefully into account. Walters and Petroni [62] and Waits et al.
[61] consider such approaches as generally more sound and stress the reliability and trustworthiness of
the gathered evidence.
Outline of the Paper
The remainder of the paper is outlined as follows: In Section II, we give a brief definition of
rootkits, illustrate their main characteristics, and shortly describe the different classes these threats
are typically categorized into. We also discuss several major analysis techniques for revealing potential
system inconsistencies and detecting rootkits with the help of a forensic memory image. The latter
form the foundation for the rkfinder plug-in that integrates various modules of the Volatility Framework
into DFF. Implementation-specific explanations regarding this plug-in are subject of Section III. Last
but not least, we present an evaluation of our software in Section IV, based on an analysis of various
rootkit-infected machines. We conclude with a short summary of our work and indicate opportunities
for future research in Section V.
II. BACKGROUND
In the following section, we briefly recapitulate major properties of rootkits and introduce the pre-
vailing rootkit classes that define the basic mode of operation of these threats. An understanding of
the individual classes does not only help estimate the level of potential system modification that can
be achieved by a particular species, but also indicates the level of effort that is required to detect
its presence. An overview of fundamental rootkit techniques as well as a description of how these
techniques can be revealed in the course of a memory-based analysis are subject of Section II-B. With
respect to this, it is important to note that our explanations always refer to the family of Microsoft
Windows operating systems unless otherwise stated.
A. Rootkits and Rootkit Classes
According to Hoglund and Butler [28, p. 4], a rootkit “is a set of programs and code that allows a
permanent or consistent, undetectable presence on a computer”. Taking this definition into account, major
capabilities of such a program are hiding specific system resources, e.g., files, network connections, or
registry keys, from legitimate system users and, preferably, other, security-related applications. The main
purpose of a rootkit is thus helping an attacker maintain access once a computer has been compromised.

124
 Rootkits are typically categorized into different classes, in dependence of the system layer they operate
on [8, 14, 22]:
• Application-level or user-space rootkits run in non-privileged mode on ring 3 of the x86 processor
architecture, i.e., they have limited access to hardware resources. In the past, this type of malicious
software simply replaced or modified trusted (user-space) binaries with malicious content. In
contrast, a common technique on the Windows operating platform to date is to intercept calls
to certain system functions such as FindFirstFile in order to manipulate output and filter
results. However, due to their high layer of operation, application-level rootkits are comparatively
the easiest to detect, particularly by programs being rooted deeper into the system core.
• Library-level rootkits frequently run on ring 3 of the x86 processor as well. As opposed to
application-level rootkits, they solely target specific system components though, e.g., the standard
user-mode library kernel32.dll. As the code of these files is injected into every process, a
large number of programs can be compromised at the same time with only little effort.
• Kernel-level rootkits typically comprise a malicious device driver and aim at the lowest layer of the
operating system. Once in kernel mode, system structures can be substantially modified, because
the respective code is executed in privileged mode on ring 0 of the x86 processor with full access
permissions. Due to these characteristics, this type of threat can severely affect the integrity of a
machine. On the other hand, kernel-level rootkits are usually tightly bound to a platform and must
be carefully designed because even the slightest programming error may lead to a system crash
that potentially raises suspicion.
Please note that two other classes of rootkits, virtualized and firmware-based rootkits, are frequently
distinguished in the literature as well [28]. As these types of threats are not in the focus of our work and
potentially require special hardware for detection [47], they are not further considered in the remainder
of this paper.
B. Rootkit System Modification Techniques and Detection
In the following, we describe various techniques that are commonly applied by rootkits to subvert
internal operating system structures. We also discuss how these manipulations can be revealed by
analyzing a forensic memory snapshot of the computer in question. The explanations presented in
this section form the foundation for the design and implementation of the rkfkinder plug-in we will
illustrate in Section III.
Hooking
Malicious programs frequently install hooks to manipulate the program flow of an application. A hook
intercepts calls to certain system functions and temporarily transfers execution to a custom routine, the
hooking function, that is controlled by an attacker. The hooking function is typically responsible for
manipulating or filtering results. For instance, the Hacker Defender rootkit [29] implements hooks for
the Windows API functions EnumServicesStatus and EnumServicesStatusEx [29]. As the
names suggest, these functions enumerate the list of system services running on a machine. By installing
a hook, however, pre-defined services can be excluded from the list, thereby effectively hiding resources
from the eyes of unsuspecting users.
Various hooking techniques have been discussed in the literature [14, 30], for instance, IAT or EAT
hooks that target the import or export address table of an executable. Slightly more sophisticated are
inline hooks that directly overwrite the prologue of a function in memory with an unconditional jump
to the hooking procedure. When the desired modifications have been completed, a so-called trampoline

125
function is launched in the next step that restores the original instructions and resumes execution of the
original function body.
With the help of memory forensics, hooks can be detected quite easily by verifying a function truly
falls in the address space of the respective library. In case of inline hooks, this additionally requires
disassembling and checking the first instructions for a relative jump to an external resource. More details
about this process can be found in the works of Ligh et al. [39].
Whereas the previously illustrated techniques operate in user space, an attacker may also implement
hooks deeper in the system core. A prominent target is, for instance, the System Service Dispatch
Table (SSDT), a data array of two internal tables that store pointers to kernel functions [48].2 While
the first table references native functions implemented in the ntoskrnl.exe executive, the second,
shadow table points to GUI-related functions defined in win32k.sys. In order to call one of those
functions, an application must first transition from user into kernel mode via a sysenter or syscall
instruction. As part of this instruction, a so-called system service number is passed to a dispatcher routine
that identifies both the table and position the respective function resides in [48].3 Thus, by manipulating
a pointer in a SSDT, all programs that make use of the corresponding function are compromised.
In the course of a memory-based investigation, such types of hooks can be detected quite trivially as
well. For this purpose, it is only necessary to make sure all functions either fall in the address space of
the previously mentioned ntoskrnl.exe executive or the Windows win32k.sys subsystem [39].
Dolan-Gavitt [18] points out though that the SSDT is not a global structure. Therefore, the described
verification process must be repeated for all running threads to derive a complete view of the system
state.
Direct Kernel Object Manipulation
As an alternative to hooks, more advanced malicious applications may also modify core operat-
ing system structures directly in memory. This technique, known as Direct Kernel Object Manipula-
tion (DKOM), is implemented by rootkits such as FU [6], FUTo [52], or Shadow Walker [54]. In
comparison to hooking, a DKOM attack is typically harder to detect, especially for users with solely
little expertise in malware analysis, and requires monitoring central kernel resources. On the other hand,
malicious kernel modification must be carefully implemented, as any programming error may likely
cause a system crash. As pointed out by Kornblum [36], such unexpected instabilities and misbehavior
can quickly raise suspicion and potentially indicate a malware infection.
From a technical perspective, DKOM is frequently used for process hiding [4]: Internally, a Windows
process is represented by an _EPROCESS structure that contains an ActiveProcessLinks field
[48]. This field points to a doubly linked list in which all running system processes are associated with
each other. By modifying the FLINK and BLINK members of the list, i.e., pointers to the previous
and following list entries, it is possible to prevent a process from being enumerated and displayed in
common list walking programs such as the Task Manager. Ligh et al. [39] have demonstrated that
similar procedures can be applied to effectively hide network resources as well.
With regard to memory forensics, discovering a DKOM attack typically relies on a cross view
approach, i.e., estimating the trustworthiness of results by looking at elements from different perspectives
and trying to find possible inconsistencies. For this purpose, the forensic RAM snapshot is physically
scanned for specific kernel structures with the help of signatures and matched with the output of
traditional system utilities. For processes, Schuster [50] and Carr [7] were first in defining distinct rule
2
Please note that the array in fact consists of four entries of which only the first two are used in practice, however [18].
3
For a complete list of system service numbers, please refer to Jurczyk [34].

126
sets. Dolan-Gavitt et al. [19] later presented an improved, robust version that only included essential
fields in the signature body, i.e., attempting to modify such a field instantly led to a “blue screen” and
a subsequent warm reboot. Thereby, a gap for malicious software to evade detection was effectively
closed. The rkfinder plug-in we will illustrate in Section III implements cross viewing techniques for
various kernel resources and automatically highlights suspicious objects that were identified in this
process.
Malicious Library Injection
The functionality of rootkits such as CloakDLL [13] or Vanquish [64] is based on dynamically loaded
libraries (DLLs) that are injected at runtime into the address space of legitimate system processes, e.g.,
by calling the LoadLibrary API function. The list of libraries a process references is saved in the
Process Environment Block (PEB), a structure that is accessible in user mode. Specifically, the PEB
contains a Ldr field that points to three doubly linked lists with entries of type LDR_DATA_TABLE_
ENTRY [48]. Each entry refers to a loaded module and stores its corresponding name, path, and size.
Similar to the DKOM approach, it is possible to remove an entry from one or all lists and, thereby,
exclude the respective library from showing up in common system maintenance programs. On the other
hand, as the actual library code is still left untouched in memory, the execution process is not interrupted
and remains unaffected.
When performing a forensic memory analysis, the list of loaded modules should be carefully exam-
ined with respect to such manipulations. To detect a hidden, maliciously injected library, DLL-related
information stored in the PEB of a process should be first checked for inconsistencies and then matched
with the list of memory-mapped files, derived from the Virtual Address Descriptor (VAD) tree. Virtual
Address Descriptors are data structures “the memory manager maintains (...) to keep track of which
virtual addresses have been reserved in the process’s address space” [48, p. 788]. In dependence of its
type, a node in the tree can point to a so-called control area that, in turn, references a _File_Object
structure [15, 56]. With the help of the latter, the name of the respective mapped file can be recovered.
Thus, by repeating the previous steps for the remaining nodes in the tree, the list of loaded libraries
can be restored.
Code Injection
The previously described VAD tree is also helpful for revealing maliciously injected code in the
course of a RAM-based investigation: Apart from the start and end address of the respective memory
range, a VAD entry stores several flags that, for instance, specify access rights for the corresponding
pages. Particularly interesting are pages that are marked as executable but are not associated to memory-
mapped files. Such unusual (privately allocated) sections frequently contain portions of shellcode [39].
A malware identification tool (e.g., Yara [2]) can be used to confirm the findings in this case. The
rkfinder plug-in provides this functionality and automatically marks all involved elements to make users
aware of a potential system compromise.
Manipulation of Other Resources
When conducting a forensic memory analysis, several other anomalies should be carefully examined
as well that possibly indicate a system infection. One such anomaly is the existence of so-called orphan
threads that cannot be associated to a corresponding parent process or system driver. As Ligh et al.
[39] note, certain malware families initially create a kernel- or user-mode thread before unlinking its
parent from the respective module or process list.4 In doing so, the presence of the malicious software
4
To unlink a driver or process, the corresponding doubly-linked list can be traversed as explained in Section II-B, starting from the
global symbol PsLoadedModuleList or PsActiveProcessHead, respectively.

127
is concealed, but the malevolent code is still being executed. Thus, an orphaned thread is oftentimes a
sign of an incident and deserves closer inspection.
The same is true for system services that are not displayed in system maintenance applications such as
the Microsoft Management Console (MMC). When a service is created, an entry to the HKEY_LOCAL_
MACHINE\System\CurrentControlSet\Service key in the Windows registry is added by
default. In order to cover traces, malware may attempt to delete said entry and, in the next step, remove
the service from the internal service database [31]. In accordance to earlier explanations, this effectively
hides the resource while the actual code keeps running.
Given a memory snapshot, the technique can be revealed by physically scanning the address space of
the Service Control Manager (SCM, services.exe) and manually rebuilding the individual service
records. Although the structure of these records is officially undocumented, it has been well described
in the literature [20, 39]: Particularly important is a tag field that stores an identifier (sErv) for system
services at a fixed position. Searching the SCM process space for occurrences of this identifier therefore
permits obtaining a genuine and unaltered service list.
III. D ETECTING S USPICIOUS O BJECTS WITH rkfinder
Based on the explanations outlined in the previous sections, we have designed the rkfinder software
that is capable of identifying potential sources of an incident, given a forensic memory image of the
system in question. Rkfinder is embedded as a plug-in into the Digital Forensics Framework (DFF) [3], a
free, open source investigation platform. DFF is in active development and has gained a good reputation
in the forensic community after winning the Digital Forensics Research Workshop (DFRWS) challenge
in 2010 [32]. In comparison to similar products such as PyFlag [12], DFF has a “clean, simple GUI”
and can be efficiently operated even by novice investigators and practitioners with only little forensic
expertise [1, pp. 221-222]. One of its major benefits is the modular structure that permits extending the
functionality of the platform on the fly. Our rkfinder plug-in makes use of this capability and integrates
various modules of the Volatility Framework [58] into the DFF interface. Thereby, a snapshot of a
computer’s RAM can be comfortably inspected upon traces of possible rootkit infections, and even IT
personell without expert knowledge are able to get a comprehensive overview of the system state and
its integrity.
In the following section, we briefly explain the architecture of DFF. A description of the implemen-
tation process of the rkfinder plug-in is subject of Section III-B.
A. Integration of rkfinder into the Architecture of DFF
According to the DFF documentation, the platform is divided into three layers [3]: The core layer
provides fundamental functions that are required to execute the different software modules and process
their respective output. Part of this layer is the Virtual File System (VFS), a hierarchy that is responsible
for organizing the analyzed data. Information that is associated with the VFS is represented in the form
of nodes. By default, a node consists of a name and size attribute, but can be extended to include
further details. For instance, the rkfinder plug-in defines a process node with various attributes that
store, e.g, the name, identifier as well as start and end times of an executable.
Tightly linked with the core is the plug-in layer that adds specific features via individual modules to
the framework. Modules can either be written in the Python or C++ programming language and inherit
basic node manipulation methods (e.g., read / write) from a parent class. In addition, modules can
be “stacked” to create different levels of abstraction. For example, the rkfinder plug-in automatically
dumps portions of memory that may contain malicious shellcode (see Section II-B). With the help of

128
 Figure 1: Integration of the rkfinder Plug-In in the DFF Architecture

another module (e.g., the internal hexadecimal viewer hexedit), these portions can then be further
analyzed.
Finally, the user interface layer addresses the documentation and presentation phase of the classic
forensic process models [9] and allows structuring, aggregating as well as filtering the extracted evidence.
As can already be seen, rkfinder operates on the plug-in and user interface layer. The former permits
developing a separate module that runs independently from other DFF components. In particular, as
the heart of the platform is left untouched, the software can be executed on different versions of the
Microsoft Windows and Linux family. The module-specific approach also ensures easy installation and
maintenance of the code because the respective files only need to be copied to the DFF working directory.
On the other hand, all internal operations are largely encapsulated. Thus, after loading a memory image,
an investigation may be started with a single click. Final reports are then presented in the user-friendly
DFF interface, so that “even a novice should not have much trouble getting oriented” [1, pp. 221-222].
As rkfinder especially targets employees with lesser developed forensic expertise, e.g., IT personell in
smaller- and medium-sized enterprises, these characteristics are of great benefit.
In Figure 1, a summary of the DFF architecture and the integration of the rkfinder plug-in is depicted.
Accordingly, a user solely interacts with the top layer of the forensic framework, while the actual memory
analysis and rootkit detection process is abstracted by rkfinder, in close cooperation with Volatility. A
detailed description of the latter mode of operation is given in the next section.
B. Rkfinder’s Mode of Operation
Rkfinder implements cross viewing techniques for rootkit detection, i.e., possibly suspicious elements
are discovered by analyzing the system state from different angles and checking results for mismatches
and inconsistencies. The approach is based on the assumption that anomalies that are identified in
this process frequently indicate a malware infection, because it is difficult for malicious software to
consistently subvert operating system structures and evade both post-mortem and live investigative
measures.
As we have already pointed out, rkfinder relies on functionality of the Volatility Framework internally.
For this purpose, the object hierarchy of the memory analysis framework must be first imported into
DFF. Since Volatility is also written in Python, this is an easy task.

129
 Module Name Description
Searches the memory image for possibly installed malicious Win-
apihooks
dows API hooks.
Locates the tcpip.sys driver file in memory and iterates the
connections
_TCPT_OBJECT list to enumerate open network connections.
Physically scans the snapshot with the help of signatures for
connscan
_TCPT_OBJECT structures to find open network connections.
Obtains the list of loaded libraries by analyzing the list of
dlllist LDR_DATA_TABLE_ENTRY structures that are referenced in the
Process Environment Block of a process.
Physically scans the memory image with the help of signatures
filescan
for _FILE_OBJECT structures to find open files.
malfind Searches the memory dump for possibly injected malicious code.
Physically scans the memory dump with the help of signatures
modscan for LDR_DATA_TABLE_ENTRY structures to find loaded (kernel)
modules.
Obtains the list of loaded kernel drivers by analyzing the list of
modules LDR_DATA_TABLE_ENTRY structures, starting from the global
symbol PsLoadedModuleList.
Iterates members of the ActiveProcessLinks to enumerate
pslist
the list of running processes.
Physically scans the memory image for _EPROCESS structures to
psscan
generate the list of (currently and previously) running processes.
Locates the tcpip.sys driver file in memory and iterates the
sockets
_ADDRESS_OBJECT list to enumerate the list of open sockets.
Physically scans the memory image with the help of signatures
sockscan
for _TCPT_OBJECT structures to find open sockets.
Physically scans the address space of the Service Control Manager
svcscan with the help of signatures for _SERVICE_RECORD structures to
find hidden services.
Physically scans the memory image for _ETHREAD structures to
thrdscan
create the list of (currently and previously) running threads.
Applies various heuristics, e.g., matching the ExitTime field
threads with other fields of an _ETHREAD structure, to determine the list
of running threads (see Ligh [38]).
Obtains information about a node in the Virtual Address Descrip-
vadinfo tor (VAD) tree, including the VAD flags that, for instance, define
the access permissions for the respective pages.

Table I: List of Volatility Modules Implemented in rkfinder

Similar to DFF, Volatility is divided into separate modules, whereas each module performs a specific
task. The corresponding operations are executed by calling a calculate method that returns a generic
data object with the respective module output. By hooking this method, we are able to obtain the
data object for further processing within DFF. A summary and brief description of the integrated
Volatility modules is given in Table I, the individual components that are invoked for detecting the
rootkit manipulation techniques as outlined in Section II-B are listed in Table II.
As can be seen, one cross view is created by examining common operating system resources and
comparing results with those of signature-based scanners. For instance, to generate the list of system
processes, the pslist module iterates the ActiveProcess Links list as described in the Direct
Kernel Object Manipulation part of Section II-B. As opposed to this, the psscan module physically
searches a memory image for definitions of _EPROCESS structures. By matching the output of the
two modules, kernel-level rootkits such as FU or FUTo that actively employ DKOM techniques can
be discovered. One pitfall is, however, that modules may return data inconsistently. For example, the
previously mentioned psscan module returns both the list of currently as well as priorly running

130
 Rootkit Technique Volatility Module(s) Invoked for Detection
Hooking apihooks
connections, connscan, dlllist, mod- scan,
DKOM modules, pslist, psscan, sockets, sockscan,
thrdscan, threads
Library Injection dlllist, filescan, vadinfo
Code Injection malfind
Service Manipulation svcscan
Thread Orphaning thrdscan

Table II: List of Invoked Volatility Modules to Detect Specific Rootkit Techniques

processes. The latter information, on the other hand, is not included in the result set of pslist.
Therefore, in order to avoid false positives, module output must be carefully validated. In addition,
while certain rootkit techniques such as user-space hooks can be revealed quite comfortably (see
Section II-B, Hooking), the corresponding hidden resources may be more difficult to detect and can be
easily overlooked unless they are appropriately highlighted. The Hacker Defender rootkit, for instance,
intercepts various Windows API functions to conceal pre-defined elements at runtime from common
system maintenance programs. The external view of an investigator remains unaffected from this type
of system modification in the course of a post-mortem analysis though. As a consequence, the formerly
hidden elements are regularly displayed in forensic applications but may be harder to distinguish from
legitimate objects, especially if an attacker attempted to obscure (file) names and attributes such as
timestamps. In this case, finding the true source of an incident may be particularly challenging for
inexperienced users.
To cope with this issue, rkfinder is capable of considering reports of a basic live response in its
analysis. These reports may include, for instance, output of the Task Manager or the built-in netstat
utility. Ideally, the respective programs are run shortly after acquiring the contents of RAM. Thereby,
data pollution due to concurrent activity is reduced to a minimum, and the risk of introducing false
positives is decreased. As we will see in Section IV, the procedure of matching live analysis reports
with the post-mortem data of the memory image creates a second cross view layer that helps uncover
many common rootkit species found “in the wild” today.
The results of the investigation are visualized in a tree-like pane of the graphical DFF interface (see
Figure 2). In the left pane, nodes are hierarchically ordered and can be expanded to display further
details. For example, by clicking on a process item, the corresponding threads, loaded libraries, and
open network connections are shown. Additional meta information about a node are presented in the
right pane of the interface. For processes, this includes the respective command line of the executable,
the start and end times, the number of references (handles) to files and other resources as well as
the name and identifier of the parent structure. In contrast, when selecting a network connection item,
information about the binding and listening port as well as the underlying protocol are listed. An example
of the mode of operation is illustrated in Figure 2: As shown in the left part of the figure, rkfinder
has detected inconsistencies between the internal and external view regarding the two files nc.exe
and hxdef100.exe. These files are automatically marked in red and, thus, immediately make a user
aware of a potential problem.5 Clicking on the first item reveals that a (hidden) socket was opened
on port 1234 of the system (see Figure 2(b)). The second item represents the main component of
the Hacker Defender rootkit that is concealed from default system maintenance programs but has been
automatically discovered by analyzing the memory snapshot. In the next step, a user could, for instance,
5
For better visualization, suspicious objects are additionally encircled by a rectangle in Figure 2(a).

131
 (a) Process-Specific View that Indicates Potential Sources of a (b) Meta Information View that Displays Details about a
System Infection. Specific Item.

Figure 2: Analysis of Threats with rkfinder

analyze the individual threads that were started by the program or select the Injected Code node to get
a report about all process pages malicious instructions were inserted into.
Apart from the process-specific view, rkfinder creates a network, services, and system library per-
spective that allows quickly browsing through the respective evidence. Thereby, users are able to get a
comprehensive overview of the system state within a short time and may start examining artifacts they are
most interested in. For better usability, all suspicious objects are also summarized in a distinct category.
In comparison to the original, command line-based unrelated output of Volatility, this is a significant
help for less experienced investigators to directly identify possibly infected areas of a machine and
decide upon further measures to address a threat.
IV. E VALUATION AND D ISCUSSION OF THE D ETECTION P ERFORMANCE
We have evaluated our software in a preliminary study with the help of memory images acquired
from six rootkit-infected machines. All machines were running a default installation of Microsoft
Windows XP (SP 2) and were set up within a virtual (VMware-based) environment. This configuration
permitted suspending a system any time. In such a case, the contents of RAM was temporarily saved
to hard disk and could be easily duplicated for later analysis.
To simulate a realistic attack, we copied a number of security- and network-related applications to
each system. For instance, we installed netcat [24], a simple utility for sending and receiving data over
a network connection, and created a basic listening service on a local port. The rootkits were configured
to hide all runtime information and resources involved, provided the respective capability was offered
by the malicious software.
Once a system had been infected, we suspended the virtual machine and obtained a memory snapshot
as outlined above. Immediately after the acquisition process, we briefly resumed the machine and

132
launched a custom script that executed certain operating system commands to determine, for example,
the list of running processes, open network connections, and installed services. The output of these
commands was saved to a file and, together with the previously created memory image, transferred
to a trusted workstation. The image was then opened in DFF, and the rkfinder plug-in was started.
As described in Section III, rkfinder correlated the output of various Volatility modules and matched
the external view of the framework with the internal view of the operating system. Thereby, system
inconsistencies could be effectively revealed.
Primary objective of our evaluation was assessing in how far rkfinder – in cooperation with Volatility –
was capable of identifying and properly visualizing all rootkit-related manipulations performed in a
system compromise. As such, a rootkit was considered as being discovered when the respective system
modifications and involved artifacts were correctly highlighted in the DFF interface. As we have already
argued, we believe that marking the sources of a potential system infection is particularly helpful for
users with only marginally forensic expertise, as they are often found in IT departments of smaller- and
medium-sized enterprises. A more extensive evaluation of our software with respect to this target group
is, however, still missing at the time of this writing.
A. Analysis Results
In the following, we present the results of our analysis. The list of rootkits we considered in our study
is shown in Table III. The different species represent examples of the rootkit classes we introduced in
Section II-A and are commonly found “in the wild” to date [14]. As can be seen, all threats are able
to hide at least individual processes. Most rootkits, however, implement additional capabilities such
as concealing network connections, loaded drivers, or entries in the system registry. In the course of a
forensic analysis, these manipulations should be revealed to a preferably high degree. The corresponding
detection results with respect to our plug-in are listed in Table IV. A checkmark () denotes that a
(hidden) resource could be successfully discovered. In contrast, a dash (-) denotes that the system
modification remained unnoticed. In case a rootkit was incapable of hiding a specific object, the entry
in the respective column was labeled as n/a.
We now discuss the results shown in Table IV more thoroughly: Generally speaking, rkfinder could
successfully identify all modifications apart from maliciously inserted registry keys. The latter func-
tionality, although planned, is not included in our software yet, because it is possible that portions of
the registry are either paged out to disk or have not been transferred into memory at a given point
in time (see Section V). Thus, more testing is required from our part to verify the reliability of this
feature. Furthermore, although FU, FUTo, and Hacker Defender were assumed to effectively hide system
drivers according to their documentation, these operations failed for all three rootkits, and the items
were regularly displayed in system maintenance programs and, correspondingly, in the module list of
our plug-in. Due to the consistence of the external and internal view, rkfinder was not able to detect any
anomalies, however. Therefore, the respective items could not be highlighted as being suspicious. The
same is true for NTIllusion that did neither succeed at concealing the netcat process from standard
task management programs nor removing the injected library from the doubly-linked list of loaded
DLLs (see Section II-B, Malicious Library Injection). Again, due to the missing mismatch between
the external and internal perspective, these elements were not marked as suspicious even though they
were included in rkfinder’s list of running processes and libraries, respectively. It is noteworthy though
that other authors [15, 23] have reported NTIllusion to work as expected, so further testing, e.g., with
different versions of the software, is required as well to properly assess the behavior of the threat.
With regard to the rootkit functions outlined in Section II-B, it is interesting to verify if and to what
degree a specific technique could be discovered: Hooking was used by four out of six rootkits (Hacker

133
 Supports
Supports Supports Supports Supports
Registry
Rootkit Type Process Socket Service Driver
Key
Hiding Hiding Hiding Hiding
Hiding
BH-Rootkit-NT K  -  - -
FU K  - - - 
FUTo K  - - - 
Hacker Defender U     
NTIllusion L    - -
Vanquish L   -  -

Table III: List of Rootkits Considered in the Evaluation

(Note: A rootkit of type K refers to a kernel-level rootkit, a rootkit of type U to a user-level rootkit,
and a rootkit of type L to a library-level rootkit.)

Rootkit Processes Registry Keys Sockets Services Drivers

BH-Rootkit-NT  n/a  n/a n/a
FU  n/a n/a n/a -
FUTo  n/a n/a n/a -
Hacker Defender  -   -
NTIllusion - -  n/a n/a
Vanquish  - n/a  n/a

Table IV: Discovery of Rootkit-Manipulated Objects

Defender, NTIllusion, Vanquish, and the kernel-based BH-Rootkit-NT) to intercept and manipulate data
processing. In our evaluation, rkfinder was capable of identifying all hooks that were mentioned in the
respective manuals. As we will see later, however, a hooked function does not necessarily indicate the
presence of malicious software, so respective findings should be carefully examined.
Subverting system structures with the help of Direct Kernel Object Manipulation was pursued by
two kernel-level rootkits, FU and FUTo. This type of attack could be discovered by traversing the
corresponding linked lists of objects and comparing the individual elements with the results of signature-
based scanners. For this purpose, rkfinder correlated the output of several Volatility modules, e.g.,
pslist and psscan (see Section III-B), and successfully discovered the presence of both rootkits.
As we have already pointed out, marking the maliciously injected library of the NTIllusion rootkit
as suspicious failed, because matching the list of loaded modules with the Virtual Address Descriptor
tree did not yield any inconsistencies. With respect to the second library-level rootkit Vanquish, this
operation proved fruitful, however. Likewise, rkfinder succeeded in identifying the respective pages that
contained injected code for both species.
Last but not least, two rootkits, Hacker Defender and Vanquish, are known to install custom services
that are hidden from the Service Control Manager. With the help of the svcscan module that is part of
the Volatility Framework, these modifications were correctly recognized, and the corresponding services
were uncovered. A summary of the detection results can be found in Table V.
B. Weaknesses and Limitations of the Plug-In
In the development process of the rkfinder plug-in, strong emphasis was put on correctly highlighting
system modifications as well as suspicious elements, while reducing the number of false positives to a
minimum. Although we were capable of successfully detecting common rootkits, the software still has
to struggle with several weaknesses and limitations that have to be better addressed in the future: First
of all, as we have indicated in the previous section, hooked functions that are found on a machine are

134
 Rootkit Technique Employed by Detection Rate
BH-Rootkit-NT, Hacker Defender, NTIllusion,
Hooking 4/4
Vanquish
DKOM FU, FUTo 2/2
Library Injection NTIllusion, Vanquish 1/2
Code Injection NTIllusion, Vanquish 2/2
Service Manipulation Hacker Defender, Vanquish 2/2

Table V: Detection Rates for Different Rootkit Techniques

not necessarily a sign of a system infection. In a test with three live production servers of a chemical
company, various hooks were discovered that were installed by legitimate, security-related applications.
In fact, Freiling and Schwittay [23, p. 15] argue that “identifying malicious hooks can sometimes be
difficult, because a lot of software, especially Antivirus software, uses benign hooking”.
Moreover, even though we managed to discover the injected library of the Vanquish rootkit by
processing the Virtual Address Descriptor tree, Dolan-Gavitt [15] has argued that the structure is
susceptible to Direct Kernel Object Manipulation as well. Such anti forensic techniques may significantly
affect the progress of an investigation and falsify results. Oddly enough, however, malicious applications
that do not actively cover their traces are the hardest species to mark as suspicious in the end, because
cross viewing does not reveal any anomalies. In this case, an investigator must manually analyze the
reports of the plug-in and identify sources of a system infection without additional program support.
Last but not least, it is important to keep in mind that, similar to other detection programs, the rkfinder
software can reflect a deceptive picture of a computer’s state in case the presence of a threat remains
unnoticed. From a psychological point of view, these false negatives are especially dangerous, because
users may incorrectly perceive the level of system security as satisfactory and, as a result, possibly react
less sensitively to future anomalies. Even though our methodology of matching the internal and external
view has proven capable of identifying common rootkits present “in the wild” to date, we have also
mentioned other classes of malware, for instance, virtualized rootkits (e.g., Blue Pill [49]), that would
be impossible to reveal with our plug-in. In such a situation, consulting more experienced investigators
is advisable.
V. C ONCLUSION
We have presented rkfinder, a plug-in for the popular open source investigation platform DFF.
Rkfinder integrates several modules of the memory analysis framework Volatility into the graphical
DFF interface. By processing, correlating, and filtering the respective module output, the plug-in is
able to discover and automatically highlight potential traces of a system compromise, given a memory
snapshot of the machine in question. Thereby, analysts can quickly get a comprehensive overview of
the system state and gain a solid foundation for addressing the threat in the course of a first response.
Due to these characteristics, rkfinder particularly targets users with solely little forensic expertise as,
for instance, they are often found in IT departments of smaller- and medium-sized enterprises.
In a preliminary study, we have evaluated the software based on six rootkit samples that are frequently
faced in practice to date. The rootkits operated on different layers of the operating system and were able
to subvert system structures in both user as well as kernel space. All samples offered at least process
hiding capabilities. In most cases, however, other resources such as network sockets, registry keys,
or loaded drivers could be effectively concealed as well. Matching the external view of the analysis
platform with the internal view of the operating system as well as with the results of a basic live
analysis proved especially useful for revealing these modifications. Weaknesses of the software are

135
the incapability to parse the Windows registry and to correctly distinguish maliciously installed hooks
from legitimate function interceptions, e.g., due to security-related products such as virus scanners. In
addition, psychological biases can arise in case threats remain undiscovered, tempting users to get a
false sense of the system state and the level of security.
Opportunities for Future Research
So far, the performance of rkfinder has unfortunately only been assessed with a limited number
of rootkits. Even though the considered samples are known to be spread “in the wild” [8, 14], they
are mostly dated, and their behavior is well documented in the literature. It is therefore planned to
significantly extend the study and include more modern and sophisticated species in the evaluation. In
fact, it would be possible to broaden the evaluation even further and study other types of malicious
software, e.g., trojan horses or backdoors, as well. By better taking advantage of the classification
capabilities of the integrated Yara utility (see Section II-B), different families of malware may be
distinguished, and rkfinder could evolve to a more generic analysis tool.
With respect to the development process of the plug-in, it is necessary to implement additional
detection features. In particular, the software should be capable of examining in-memory registry data,
e.g., the well-known run keys such as HKLM\Microsoft\ Windows\CurrentVersion\Run that
are frequently manipulated by malware to automatically load applications at system start. Dolan-Gavitt
[16] has noted though that the respective hives do not necessarily need to be held in RAM in their
entirety. Consequently, analysis tools should be carefully designed and “able to handle missing data
without crashing” [16, p. S30].
Last but not least, taking certain heuristics into account when investigating a memory image may
further increase detection quality. For instance, Ligh et al. [39] have proposed to examine the execution
priority of a thread in order to identify suspicious behavior. Other examples include checking the parent-
child hierarchy of a process or the list of access privileges for anomalies. It is important to keep in
mind, however, that such procedures always bear the risk of introducing false positives. Therefore, the
respective program parts should be carefully tested before being applied in a forensic investigation.
Acknowledgments
We would like to thank Felix Freiling, Thomas Schreck, and Tilo Müller for giving us valuable
feedback and suggestions for improvement of our work.
R EFERENCES
[1] C. Altheide and H. Carvey, Digital Forensics with Open Source Tools. Syngress Publishing, 2011.
[2] V. M. Alvarez and M. Wiacek, “Yara - A Malware Identification and Classification Tool,” 2011.
http://code.google.com/p/yara-project/
[3] ArxSys, “DFF: Digital Forensics Framework,” 2009. http://www.arxsys.fr/
[4] D. Bilby, “Low Down and Dirty: Anti-Forensic Rootkits,” in Proceedings of Ruxcon, 2006.
[5] M. Burdach, “An Introduction to Windows Memory Forensic,” 2005. http://forensic.seccure.net/
pdf/introduction to windows memory forensic.pdf
[6] J. Butler, “FU Rootkit,” 2005. http://www.rootkit.com/board project fused.php?did=proj12
[7] C. Carr, “GREPEXEC: Grepping Executive Objects from Pool Memory,” 2006. http:
//uninformed.org/?v=4&a=2&t=pdf
[8] H. Carvey, Windows Forensic Analysis. Syngress Publishing, 2007.
[9] E. Casey, Digital Evidence and Computer Crime - Forensic Science, Computers, and the Internet,
3rd Edition. Academic Press, 2011.

136
[10] E. Chan, S. Venkataraman, F. David, and A. Chaugule, “Forenscope: A Framework for Live
Forensics,” in Proceedings of the 26th Annual Computer Security Applications Conference, 2010.
[11] B. Cogswell and M. Russinovich, “RootkitRevealer,” 2006. http://technet.microsoft.com/de-de/
sysinternals/bb897445.aspx
[12] M. Cohen, “PyFlag - An Advanced Network Forensic Framework,” in Proceedings of the Digital
Forensic Research Workshop (DFRWS), 2008.
[13] Darawk, “CloakDll,” 2005. http://www.darawk.com/code/CloakDll.cpp
[14] M. Davis, S. Bodmer, and A. Lemasters, Hacking Exposed - Malware & Rootkits. McGraw Hill,
2010.
[15] B. Dolan-Gavitt, “The VAD Tree: A Process-Eye View of Physical Memory,” Digital Investigation,
Vol. 4, No. 1, pp. 62–64, 2007.
[16] B. Dolan-Gavitt, “Forensic Analysis of the Windows Registry in Memory,” Digital Investigation,
Vol. 5, No. 1, pp. S26–S32, 2008.
[17] B. Dolan-Gavitt, “Linking Processes to Users,” 2008. http://moyix.blogspot.com/2008/08/
linking-processes-to-users.html
[18] B. Dolan-Gavitt, “Auditing the System Call Table,” 2008. http://moyix.blogspot.de/2008/08/
auditing-system-call-table.html
[19] B. Dolan-Gavitt, A. Srivastava, P. Traynor, and J. Giffin, “Robust Signatures for Kernel Data
Structures,” in Proceedings of the 16th ACM Conference on Computer and Communications
Security, 2009.
[20] Doug, “Reverse Engineering the Service Control Manager (SCM),” The CodeBreakers-Journal,
Vol. 1, No. 1, 2004.
[21] N. Falliere, L. O. Murchu, and E. Chien, “W32.Stuxnet Dossier,” 2011. http://www.symantec.
com/content/en/us/enterprise/media/security response/whitepapers/w32 stuxnet dossier.pdf
[22] D. Farmer and W. Venema, Forensic Discovery. Addison Wesley, 2005.
[23] F. C. Freiling and B. Schwittay, “Towards Reliable Rootkit Detection in Live Response,” in
Proceedings of IT Incident Management & IT Forensics (IMF), 2007.
[24] G. Giacobbi, “The GNU Netcat Project,” 2006. http://netcat.sourceforge.net/
[25] GMER, “GMER - Rootkit Detector and Remover,” 2012. http://www.gmer.net/
[26] J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul, J. A. Calandrino, A. J. Feldman,
J. Appelbaum, and E. W. Felten, “Lest We Remember: Cold-Boot Attacks on Encryption Keys,”
Communications of the ACM, Vol. 52, No. 5, pp. 91–98, 2009.
[27] C. Hargreaves and H. Chivers, “Recovery of Encryption Keys from Memory Using a Linear Scan,”
in Proceedings of the 2008 Third International Conference on Availability, Reliability and Security,
2008.
[28] G. Hoglund and J. Butler, Rootkits: Subverting the Windows Kernel. Addison Wesley, 2005.
[29] HolyFather, “Hacker Defender,” 2005. http://www.hxdef.org/download/hxdef100r.zip
[30] HolyFather, “Hooking Windows API - Technics of Hooking API functions on Windows,” The
CodeBreakers-Journal, Vol. 1, No. 4, 2004.
[31] i.m.weasel, “How to REALLY REALLY Hide from the SC Manager,” 2006. http:
//www.rootkit.com/newsread.php?newsid=419
[32] S. Jacob, “Digital Forensics Research Workshop Challenge 2010 - Analysis Report,” 2010.
http://sandbox.dfrws.org/2010/jacob/dfrws-2010-challenge-analysis.pdf
[33] M. Jakobsson and Z. Ramzan, Crimeware: Understanding New Attacks and Defenses. Addison
Wesley, 2008.
[34] M. Jurczyk, “Windows X86 System Call Table,” 2011. http://j00ru.vexillium.org/ntapi/

137
[35] B. Kaplan, “RAM Is Key - Extracting Disk Encryption Keys from Volatile Memory,” Master’s
Thesis, Carnegie Mellon University, 2007.
[36] J. D. Kornblum, “Exploiting the Rootkit Paradox with Windows Memory Analysis,” International
Journal of Digital Evidence, Vol. 5, No. 1, pp. 1–5, 2006.
[37] Laboratory of Cryptography and System Security, “sKyWIper (a.k.a. Flame a.k.a. Flamer): A
Complex Malware for Targeted Attacks,” Budapest University of Technology and Economics,
Tech. Rep., 2012. http://www.crysys.hu/skywiper/skywiper.pdf
[38] M. H. Ligh, “Investigating Windows Threads with Volatility,” 2011. http://mnin.blogspot.de/2011/
04/investigating-windows-threads-with.html#!/2011/04/investigating-windows-threads-with.html
[39] M. H. Ligh, S. Adair, B. Hartstein, and M. Richard, Malware Analyst’s Cookbook and DVD: Tools
and Techniques for Fighting Malicious Code. Wiley, 2010.
[40] C. Maartmann-Moe, S. E. Thorkildsen, and A. Årnes, “The Persistence of Memory: Forensic
Identification and Extraction of Cryptographic Keys,” Digital Investigation, Vol. 6, No. S1, pp.
S132–S140, 2009.
[41] M. Miller, “Metasploit’s Meterpreter,” 2004. http://dev.metasploit.com/documents/meterpreter.pdf
[42] S. Mocas, “Building Theoretical Underpinnings for Digital Forensics Research,” Digital Investi-
gation, Vol. 1, No. 1, pp. 61–68, 2004.
[43] D. Molina, M. Zimmerman, G. Roberts, M. Eaddie, and G. Peterson, “Timely Rootkit Detection
During Live Response,” in Proceedings of the International Conference for Information Processing,
2007.
[44] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N. Weaver, “Inside the Slammer
Worm,” IEEE Security and Privacy, Vol. 1, No. 3, pp. 33–39, 2003.
[45] J. Okolica and G. L. Peterson, “Windows Operating Systems Agnostic Memory Analysis,” Digital
Investigation, Vol. 7, No. 1, pp. S48–S56, 2010.
[46] J. Pan, “IceSword,” 2005. http://www.xfocus.net/tools/200509/1085.html
[47] N. L. Petroni, T. Fraser, J. Molina, and W. A. Arbaugh, “Copilot - A Coprocessor-Based Kernel
Runtime Integrity Monitor,” in Proceedings of the 13th USENIX Security Symposium, 2004.
[48] M. E. Russinovich, D. A. Solomon, and A. Ionescu, Microsoft Windows Internals, 5th Edition.
Microsoft Press, 2009.
[49] J. Rutkowska, “Subverting Vista Kernel for Fun and Profit,” 2006. http://www.blackhat.com/
presentations/bh-usa-06/BH-US-06-Rutkowska.pdf
[50] A. Schuster, “Searching for Processes and Threads in Microsoft Windows Memory Dumps,” Digital
Investigation, Vol. 3, No. 1, pp. 10–16, 2006.
[51] A. Schuster, “Pool Allocations as an Information Source in Windows Memory Forensics,” in
Proceedings of IT-Incident Management & IT-Forensics (IMF), 2006.
[52] P. Silberman and C.H.A.O.S., “FUTo,” 2006. http://uninformed.org/?v=3&a=7&t=sumry
[53] E. Skoudis and L. Zeltser, Malware: Fighting Malicious Code. Prentice Hall PTR, 2003.
[54] S. Sparks and J. Butler, “Shadow Walker - Raising the Bar for Rootkit Detection,” 2005.
http://www.blackhat.com/presentations/bh-jp-05/bh-jp-05-sparks-butler.pdf
[55] A. D. Todd, J. Benson, G. L. Peterson, T. Franz, M. Stevens, and R. A. Raines, “Analysis of Tools
for Detecting Rootkits and Hidden Processes,” in Proceedings of the International Conference for
Information Processing, 2007.
[56] R. van Baar, W. Alink, and A. van Ballegooij, “Forensic Memory Analysis: Files Mapped in
Memory,” in Proceedings of the Digital Forensic Research Workshop (DFRWS), 2008.
[57] Volatile Systems, LLC, “The Volatility Framework: Volatile Memory Artifact Extraction Utility
Framework,” 2008. https://www.volatilesystems.com/default/volatility

138
[58] Volatile Systems, LLC, “Volatility - An Advanced Memory Forensics Framework,” 2012.
http://code.google.com/p/volatility/
[59] Volatile Systems, LLC, “Volatility Documentation Project,” 2012. http://code.google.com/p/
volatility/wiki/VolatilityDocumentationProject
[60] S. Vömel and F. C. Freiling, “A Survey of Main Memory Acquisition and Analysis Techniques
for the Windows Operating System,” Digital Investigation, Vol. 8, No. 1, pp. 3–22, 2011.
[61] C. Waits, J. A. Akinyele, R. Nolan, and L. Rogers, “Computer Forensics: Results of Live
Response Inquiry vs. Memory Image Analysis,” 2008. http://www.sei.cmu.edu
[62] A. Walters and N. L. Petroni, “Volatools: Integrating Volatile Memory Forensics into the Digital
Investigation Process,” in Proceedings of Black Hat DC, 2007.
[63] L. Wang, L. Xu, and S. Zhang, “Network Connections Information Extraction of 64-Bit Windows
7 Memory Images,” Forensics in Telecommunications, Information, and Multimedia, Vol. 56, pp.
90–98, 2011.
[64] XShadow, “Vanquish v0.2.1,” 2005. http://rootkit.com/project.php?id=9

139