ENGR 489 (ENGINEERING PROJECT) 2023 1

DRAKVUF Malware Sandbox

Sukhjinder Singh

Abstract—A sandbox is a system that provides a safe environ- or network. The efficacy of static analysis has been greatly
ment for analysis and deployment of malware samples while all reduced over the years due to the proliferation of metamorphic
the activities of the malware are captured and logged. DRAKVUF malware with malware authors using complex techniques such
is an open-source black box analysis sandbox based on the
popular Cuckoo sandbox system. The current implementation as anti-analysis to perform detection evasion [4].
of DRAKVUF has shortcomings in terms of the web user Basic dynamic analysis and advanced dynamic analysis also
interface, which restricts user customisation of the analysis have drawbacks; namely, the number of samples that need
environment variables. This project will extend DRAKVUF’s to be analysed by malware analysts. This puts a burden on
web user interface to support new capabilities such as, an hardware resources used to analyse the samples [4]. Modern
operating system with various configurations and easy selection
and assignment of environment variables that are currently malware can also leverage anti-analysis techniques for dy-
hidden within the DRAKVUF configuration files or command namic analysis. This is done by the detection of monitoring
line interface. The queuing system of DRAKVUF is also extended environments and hiding in unmonitored corners of the system
to allow for multiple samples to be analysed at once. The [4].
reporting component is significantly improved by implementing Sandboxes are an advanced dynamic analysis method for
the capability to generate and send comprehensive reports to a
given email address provided by the user during submission. The running untrusted programs in a safe environment without
reporting interface also provides historical data on previously fear of harming “real” systems. Sandboxes comprise of vir-
submitted malware samples. tualised environments that often simulate operating systems
The improved DRAKVUF system is hosted on an ECS server and network services in some fashion to ensure that the
and is accessible to staff and students to submit and analyse software or malware being tested will function normally [2].
potentially malicious samples. The success of this project is
determined through a successful deployment and fully opera-
However, they do not offer the opportunity to customise how
tional malware sandbox of DRAKVUF sandbox instance and a the malware samples should be evaluated. This leads to results
developed web interface. being imposed due to restrictions on the choice of operating
systems, installed packages, how long the execution will last,
and many other things.
I. I NTRODUCTION
II. T HE P ROBLEM
M ALWARE analysis is the process of examining a piece
of malicious software (malware sample) to understand
its behaviour and purpose. The information provided by this
Dynamic malware analysis requires a safe and isolated envi-
ronment to run malware samples. This can be done in a variety
analysis can be used to develop defences against malware, of ways, sandboxes being a very safe way of execution and
such as antivirus signatures and firewalls [1]. analysis [3]. However, sandboxes can be resource intensive,
There are two types of malware analysis: “static” and detectable, and complex to set up and operate [4].
“dynamic”. Static malware analysis is a technique that ex- DRAKVUF is an open-source software that provides a
amines the code and properties of a malicious file without foundation for a malware analysis sandbox [5]. It provides a
executing it. Dynamic malware analysis is any examination platform for stealthy malware analysis as its footprint is nearly
performed after executing malware [2]. This generally requires undetectable from the malware’s perspective [5]. DRAKVUF
the malware sample to be executed in a system that is set provides a basic web interface that gives users limited cus-
up in a closed, isolated virtual environment so that it can be tomisability on how the sandbox will run the malware samples
studied thoroughly without the risk to a production system. and how reports will be delivered to users.
Malware analysed using the static analysis technique is much The current web interface for the DRAKVUF sandbox lacks
safer than using the dynamic analysis technique. Basic static essential features and functionalities, limiting its usability and
analysis and advanced static analysis are the two steps of hindering efficient malware analysis. Namely the interface
the static analysis method used to analyse malware [3]. On does not support the selection of multiple virtual environments,
the other hand, basic dynamic malware analysis involves it restricts the duration of malware sample execution, and it
running malware samples in controlled environments, such does not have a job management system, which will need
as virtual machines, to observe their behaviour and identify to be implemented for managing submitted jobs. This defi-
malicious activities. Advanced dynamic malware analysis goes ciency inhibits effective management of DRAKVUF instances,
beyond basic observation by utilising techniques like code and impedes analysis of submitted jobs, and fails to provide a
memory analysis, network traffic monitoring, and behaviour comprehensive solution for malware analysis.
profiling to gain deeper insights into the malware’s capabil- The aim of this project is to extend the capabilities of
ities, evasion techniques, and potential impact on a system the current DRAKVUF web interface by allowing users to
customise their analysis environment and provide an easy-to-
This project was supervised by Masood Mansoori and Lisa Patterson use interface for managing malware sample submission and
ENGR 489 (ENGINEERING PROJECT) 2023 2

queuing. When the malware sample is launched and evaluated, an avenue to observe malware execution by allowing external
there will be functionality added to DRAKVUF to email the access to the state of the virtualised hardware components.
results to the user. This technique is commonly referred to as Virtual Machine
Introspection (VMI) [4]. To access the components externally
III. P ROJECT O BJECTIVES DRAKVUF uses active VMI through breakpoint injection to
A successful implementation and solution of DRAKVUF hijack an arbitrary process within the VM to initiate the start
will meet these functional requirements: of the malware sample [4]. Breakpoint injection is a technique
used to inject a breakpoint into a running process. When this
• Be remotely accessible through a web interface.
is done, the process will stop executing at the breakpoint
• The system must show the available virtual machines and
and DRAKVUF will be able to modify it and continue the
operating system and their respective configurations for
execution. By using existing processes running within the VM,
the user to select.
DRAKVUF does not introduce any new code or artifact into
• The system must allow management of multiple instances
the analysis VM, thus greatly improving stealthiness [4]. In
of DRAKVUF, including shutting down or restarting the
contrast, the Cuckoo sandbox injects a Python script into the
instances, and managing the submitted jobs.
analysis VM which can be detected by malware.
• Support multiple operating systems and versions such as
DRAKVUF can also track changes and deletions to files
Windows 7 and Windows 10.
within the VM [6]. This is done using a technique called
• The system must allow configuration attributes of
shadow paging to track the changes made to files. Shadow
DRAKVUF to be altered and set through the web inter-
paging creates a copy of each file in the sandbox and the
face such as: which VM to execute malware on, analysis
copy is called the shadow page [6]. DRAKVUF can read
time, modules included in analysis.
the contents of the shadow pages and compare them with the
• The system must allow submission of a file to be anal-
original files to see what changes were made to the files. This
ysed by the operating systems above, through the web
is very helpful for malware analysts to determine how different
interface.
types of malware work and help identify and track malware
• The system should allow a user to download the reports
infections.
generated by DRAKVUF or view them through the web
interface.
• The system must allow a report to be emailed to a
V. R ELATED W ORK
designated email address provided by the user. There are a number of open-source sandboxes available to
And the following non-functional requirements: analyse malware samples. Many popular or defacto malware
• Efficiency: Concurrency of analysing many malware
sandboxes have been analysed to weigh their pros and cons
samples is to be maximised while performance overhead compared to DRAKVUF sandbox.
for analysing a single sample is to be minimised.
• Stealth: The monitored environment should not be able A. Cuckoo
to detect the presence of DRAKVUF. Cuckoo is a sandbox technology that is widely used by
• Isolation: DRAKVUF should be isolated from the anal- researchers and malware analysts in the industry to carry
ysis virtual machines to protect against tampering. out dynamic malware analysis. Cuckoo accomplishes this by
creating a virtual environment like DRAKVUF, however, to
IV. BACKGROUND R ESEARCH analyse the malware, an in-guest (agent) module is required.
There are several pieces of literature outlining the capabil- Due to the metamorphic nature of many modern malwares,
ities of the DRAKVUF sandbox from reputable sources such they have the potential to hide themselves or act benignly
as Intel [4] and the Institute for System Programming of the in the analysis environment if the agent is detected [7].
Russian Academy of Sciences [6]. Both discuss the challenges DRAKVUF solves this problem by utilising the breakpoint
that DRAKVUF solves around the anti-analysis techniques injection technique to execute the dynamic malware analysis
that malware employs to hide from malware analysis. [7].
DRAKVUF uses the Xen hypervisor to get around the The architecture diagram of Cuckoo is shown in Fig. 1. It
challenges that modern malwares present with anti-analysis consists of three main components, the cuckoo host machine,
techniques [4]. The Xen hypervisor offers novel techniques the virtual network, and the analysis guests. There is also
to eliminate blind-spots created by kernel-mode rootkits by the analysis manager and agent modules that are passed into
extending the scope of monitoring to include kernel internal the analysis guests. The user interacts with Cuckoo from
functions and to monitor file system accesses through the ker- the host machine either through a command-line interface
nel’s heap allocations. It also enables DRAKVUF to improve or through a web interface like DRAKVUF. The analysis
stealth by starting the execution of malware samples without manager is responsible for submitting malware samples and
leaving traces in the analysis machine [4]. This is a feature that collecting the reports after the malware analysis is completed
other popular sandbox solutions like Cuckoo and CWSandbox [7]. The Cuckoo host interacts with the analysis virtual
do not possess. machines though the virtual network and an in-VM Python
DRAKVUF is implemented using the virtualisation technol- agent module is installed within the guest OS to start the
ogy on Intel Central Processing Units (CPUs). This provides analysis automatically when the malware sample is received.
ENGR 489 (ENGINEERING PROJECT) 2023 3

The Python agent is responsible for receiving the malware Cuckoo consumed more disk space than DRAKVUF when
sample, executing it, and sending the analysis report back to memory dumping was enabled [7]. However, DRAKVUF used
the analysis manager [7]. more disk space when memory dumping was disabled.

100 Samples (memory dump 100 Samples (memory dump

enabled) disabled)
DRAKVUF 5.96 gigabytes (5.96%) 5.96 gigabytes (5.96%)
Cuckoo 11.01 gigabytes (11.02%) 0.16 gigabytes (0.02%)

TABLE III: Disk space utilisation [7]

Cuckoo was been officially discontinued at the time of

writing this final report, and the project was archived on
GitHub in April 2021 [8].

B. CWSandbox
CWSandbox was one of the first dynamic malware analysis
systems to utilise a sandbox environment for monitoring the
interaction between the OS and the malware [4]. It operates
similarly to Cuckoo where it injects a kernel driver into
Windows OS that hooks all exported APIs to intercept the
Fig. 1: Cuckoo Architecture Diagram [7] system call performed by user-space programs. This is not
as advanced as DRAKVUF as it is vulnerable to detection
Cuckoo and DRAKVUF were compared side by side in and tampering and the interface provided by the sandbox is
[7], and the superior sandbox solution is determined through insufficient for tracking kernel-mode rootkits [4].
a series of experiments. The criteria for determining which
C. Sandbox Solution Comparison
sandbox solution was best was:
1. Duration and throughput analysis A summary of comparisons is provided in Table IV:
2. Space analysis Criteria / DRAKVUF
Cuckoo Sandbox CWSandbox
The first experiment that was conducted compared the Parameter Sandbox
duration of time that it took for Cuckoo and DRAKVUF - It does
to analyse malware samples and the throughput of each X - It uses an not use any in- X - It uses an
sandbox. Throughtput determines how many malware samples in-guest agent, the guest agent, in-guest agent, the
Stealth-
malware may not the malware malware may not
can be analysed by a system in a given amount of time. The iness
exhibit its true exhibits its exhibit its true
experiment used a set of 40, 100 and 200 malware samples. malicious nature. true malicious malicious nature.
These tests illustrated that DRAKVUF took less time than nature.
Cuckoo to analyse them and that DRAKVUF also had a - It can trace - It can trace - It can trace
higher throughput than Cuckoo [7]. Based on the experiment System all system calls all system calls all system calls
call initiated by initiated by initiated by
the authors concluded that DRAKVUF is a faster and more malware. malware. malware.
efficient tool for dynamic malware analysis than Cuckoo
X - It cannot - It can trace X - It cannot
(results shown in the Tables I and II). Kernel
trace out kernel all kernel trace out kernel
function
functions. functions. functions.
40 Samples 100 Samples 200 Samples
DRAKVUF 22 min 34 s 50 min 1 h 41 min 39 s - It supports - It supports X - It requires
Cuckoo 32 min 16 s 1 h 5 min 23 s 2 h 8 min 53 s Autom- the submission of the submission of manual interaction
ation malware samples malware samples to upload and
TABLE I: Duration to carry out malware analysis [7] automatically. automatically. analyse files.
- Windows XP/ - Windows XP/
Guest OS 7/8/10, 7/8/10,
Throughput = Total Number of samples analysed success- support Linux 2.6
- Windows 7
Linux 2.6
fully / Duration (Time taken) or above or above

40 Samples 100 Samples 200 Samples - Isolated - Isolated - Isolated

DRAKVUF 0.029542097 0.029666667 0.029185112 Isolation environment for environment for environment for
Cuckoo 0.020661157 0.022686719 0.023018234 malware analysis. malware analysis. malware analysis.
- It can dump - It can dump - It can dump
Memory
TABLE II: Throughput values [7] Snapshot
the main memory the main memory the main memory
of guest OS. of guest OS. of guest OS.

The second experiment that was conducted compared the

disk utilisation of DRAKVUF and Cuckoo during malware TABLE IV: Comparison between Cuckoo, DRAKVUF, and
analysis. It used a set of 100 malware samples and found that CWSandbox
ENGR 489 (ENGINEERING PROJECT) 2023 4

VI. D ESIGN 2) DRAKVUF v0.8: This version introduced new plugins

like codemon, hidsim and filetracer for Linux. It also saw
Prior to the implementation of the DRAKVUF sandbox, major cleanups to libinjector with improvements and bug fixes.
the software and technology stack were researched. The Despite these enhacements, we did not select this version due
DRAKVUF sandbox is built on top of a few layers of software to our specific requirements and the compatibility with the
and hardware technologies: DRAKVUF Sandbox version we were considering.
• Intel VT-x and EPT: Extensions to x64 architecture that 3) DRAKVUF Sandbox v0.17 Series: The v0.17 series
allows virtual machines to run natively on a CPU [9]. introduced features like arch-based prefixes to profile names,
• Xen: Hypervisor, spawns virtual machines and exposes rewritten tree generation in postprocess, and support for
interfaces for interaction and introspection [9]. various file extensions to be analysed. Despite these en-
• LibVMI: Abstracts away introspection interfaces, pro- hancements, we opted for v0.18.2 due to its more advanced
vides utilities for reading/writing VM memory, parsing features and improvements that aligned better with our project
VMs’ kernel and handling notifications about certain requirements.
events happening in a VM [9]. 4) DRAKVUF Sandbox v0.18.1 and earlier: These versions
• DRAKVUF: Stealthily hooks various parts of a guest were evaluated based on their feature set, stability, and user
VM and logs interesting events [9]. feedback. For instance v0.18.1 introduced fixes like silencing
• DRAKVUF Sandbox: Provides user friendly web inter- sample errors and fixing process tree generation. However,
face built using React and high-level analyses. v0.18.2 offered more comprehensive improvements and bug
The DRAKVUF Sandbox is divided into two packages: fixes, making it a more attractive option for our project.
Our final decision to go with DRAKVUF v1.0 and
• drakcore: It is the system core, provides a web interface,
DRAKVUF Sandbox v0.18.2 was influenced by a combination
an internal task queue and object storage [9].
of factors including feature richness, stability, and compatibil-
– drakweb: Web interface that allows user to interact ity. DRAKVUF v1.0 offered a stable and reliable platform for
with the sandbox with either REST API or GUI [9]. black-box binary analysis. In combination with DRAKVUF
– draksystem: Internal task management system, used Sandbox v0.18.2, we were confident in achieving an optimal
for dispatching jobs between workers [9]. malware analysis environment.
– drakminio: Built-in object storage in which analysis
results are stored [9].
– drakpostprocess: Responsible for processing raw B. Deployment Approach
analysis logs into a more useable form [9]. Two primary deployment approaches were considered: bare
• drakrun: It is the sandbox worker, wrapper for metal and virtual machine (VM) deployment. In the bare
DRAKVUF, responsible for managing VMs, running metal deployment, the DRAKVUF system would be installed
analyses and sending results for postprocessing [9]. directly on a physical machine, offering direct access to
– drakrun 1..n: Fetches incoming sample [9]. hardware resources and optimal performance. VM deployment
involves installing the DRAKVUF system on virtual machines
DRAKVUF Sandbox is built around “karton”, which is a that run on physical machines, offering flexibility and ease of
microservice framework created at CERT Poland as a spe- management at the expense of some performance overhead.
cialised tool for building flexible malware analysis pipelines.
For this project, after careful consideration, VM deployment
Its main goal is routing tasks between multiple services [9].
was selected as the preferred approach. The decision was
influenced by several critical factors, including the need for
flexibility and the desire for a system that could be easily
A. DRAKVUF Versions
scaled and managed. With the VM approach offering features
A large aspect of the design phase involved selecting the such as snapshots. These can be used in the case of system
appropriate versions of DRAKVUF and DRAKVUF Sandbox breaking errors where restoring from snapshots would revert
to be implemented in the project. This decision was instru- the system back to a stable state.
mental in ensuring that the system not only met the technical While bare metal offers performance benefits, the flexibility
requirements but also optimised performance, security, and of a VM deployment was deemed more critical for the
reliability. project’s success. The ability to efficiently manage, scale, and
We initially considered various releases of DRAKVUF and adapt the system to modifications outweighed the marginal
DRAKVUF Sandbox, evaluating their features, bug fixes, and performance gains of a bare metal setup.
improvements. The versions under consideration were sourced The VM deployment was facilitated on a robust workstation,
from their official repositories on GitHub [10] [11]. equipped with virtualisation-optimised hardware to mitigate
1) DRAKVUF v0.7: This version introduced new plugins performance overhead. The workstation was capable of hosting
and tools such as procdump, apimon, and REPL. It also added multiple VMs simultaneously, ensuring that the DRAKVUF
a new helper library, libusermode, for monitoring usermode system and its auxiliary components could be efficiently
code. However we found that DRAKVUF v1.0 offered more managed and scaled as per the projects needs.
stability and features that were crucial for our project’s suc- DRAKVUF supports nested virtualisation out of the box
cess. but is limited to only one hypervisor which is VMWare
ENGR 489 (ENGINEERING PROJECT) 2023 5

Workstation Player, this made the choice for which hypervisor Name Home Desktop
to go with very easy. CPU Intel Core i7-10700KF
RAM 32GB RAM
GPU NVIDIA RTX 3050

C. Hardware VT-x & EPT Features

Equipped with VT-x but lacks
CPU Performance Counters and IOMMU
The hardware selection is a critical aspect of our design Despite the impressive memory and
process, directly influencing the performance, efficiency, and Limitations graphics capabilities, the absence
of EPT features was a drawback.
effectiveness of the DRAKVUF system for malware analysis.
Our goal was to ensure optimal compatibility, performance,
TABLE VIII: Home Desktop Specifications
and reliability.
Table V lists the requirements for DRAKVUF [9]:
Name Dell Optiplex 7000
Intel with VT-x and Intel Core i7-12700
CPU CPU
Extended Page Table (EPT) features
RAM 16GB RAM
Debian 10 Buster
Ubuntu 18.04 Bionic Equipped with VT-x,
Host system VT-x & EPT Features
Ubuntu 20.04 Focal CPU Performance Counters and IOMMU
with at least 2 Core CPU and 5GB RAM
This supports the required
Windows 7 (x64) Limitations configuration of DRAKVUF
Guest system
Windows 10 (x64; experimental support) but is low on memory.

TABLE V: DRAKVUF Hardware and OS Requirements TABLE IX: Dell Optiplex 7000 Specifications

After a comprehensive evaluation, we selected the Dell

We evaluated several hardware options to determine
Optiplex 7000 which was supplied by Victoria University of
the most suitable platform for deploying DRAKVUF and
Wellington with an Intel Core i7-12700 and 16GB RAM for
DRAKVUF Sandbox. The candidates are presented in Tables
our deployment.
VI through IX:
The Dell Optiplex emerged as the optimal choice due to
several compelling reasons:
Name Intel NUC
• CPU: The Intel Core i7-12700 processor offers a robust
CPU Intel i7-5557U performance, ensuring that the system can handle com-
RAM 16GB RAM plex malware analysis tasks efficiently. With a clock rate
Equipped with VT-x but lacks of up to 4.90 GHz and 12 Cores.
VT-x & EPT Features • Memory: With 16GB RAM, it provides ample memory to
CPU Performance Counters and IOMMU
While compact and efficient,
support the intensive workloads associated with malware
the absence of CPU Performance Counters analysis.
Limitations
and IOMMU was a significant • VTx Support: The inclusion of VTx ensures enhanced
limitation for DRAKVUFs requirements
virtualisation capabilities, a crucial feature for the effec-
tive deployment of DRAKVUF.
TABLE VI: Intel NUC Specifications • CPU Performance Counters: The availability of CPU
Performance Counters is pivotal for detailed analysis and
monitoring, offering insights that are instrumental for
comprehensive malware analysis.
Name MSI Leopard Laptop
• IOMMU: The support for IOMMU (Input-Output Mem-
CPU Intel Core i7-9750H ory Management Unit) enhances the security and perfor-
RAM 16GB RAM mance of the system, especially in virtualised environ-
GPU NVIDIA GTX 1660ti
ments.
Equipped with VT-x but lacks
The Dell Optiplex’s combination of processing power, mem-
VT-x & EPT Features ory capacity, and essential features like VTx and EPT such as
CPU Performance Counters and IOMMU
The inclusion of a dedicated GPU
CPU Performance Counters, and IOMMU ensures a balanced,
was a plus, but high-performance platform for DRAKVUF. This hardware
Limitations
the lack of EPT features made selection aligns with our project requirements, offering optimal
it less ideal for our needs.
performance, security, and reliability for hypervisor-level mal-
ware analysis. It also meant that we could deploy the sandbox
TABLE VII: MSI Leopard Specifications to a university owned workstation that can be kept within the
ENGR 489 (ENGINEERING PROJECT) 2023 6

university’s network when we had to remotely deploy it to the The project inherited ReactJS, a widely acclaimed JavaScript
network as defined in the project requirements. library known for enabling the development of highly re-
sponsive and dynamic user interfaces. While the choice of
D. Operating System (Host and Guests) ReactJS was not a selection per se, its inherent benefits,
such as its component-based structure, efficiency, and robust
The choice of operating systems for both the host and guest
ecosystem, were instrumental in continuing the development
machines is a crucial aspect of the design, directly impact-
process. The existing codebase, built upon ReactJS, facilitated
ing the efficiency, security, and overall performance of the
a seamless continuation of the enhancement and refinement
malware analysis environment. In this context, we evaluated
of the DRAKVUF web UI, ensuring an interactive and user-
various operating systems, considering their compatibility with
friendly interface for efficient malware analysis and data
the hardware, support for Xen hypervisor, security features,
visualisation.
and ease of use.
We explored a few different operating systems for the
host known for their robustness, security and support for F. DRAKVUF Architecture
virtualisation. The architecture diagram is illustrated in Fig. 2, based on
1) Windows 10: Windows 10 was considered for its user- the DRAKVUF System, the core of the diagram is a detailed
friendly interface, robust security features, and widespread use. look at the DRAKVUF system, showcasing different compo-
However, the need for a UNIX system to execute specific nents and their interconnections, represented by rectangles and
commands and scripts efficiently, and the compatibility with arrows to indicate data and process flow.
Xen hypervisor, were factors that influenced our decision.
2) Ubuntu 18.04 LTS: Known for its stability and security,
this OS was another strong candidate. However, we were
inclined towards Ubuntu 20.04 LTS due to its enhanced
features, improved security, and extended support, ensuring a
future-proof and reliable host environment.

For the Guest OS, the focus was on Windows operating

systems, given their prevalence in enterprise environments
and the significant volume of malware targeting Windows.
The options were also only limited to Windows due to the
compatibility of DRAKVUF. The only supported versions
were Windows 7 x64 and Windows 10 x64, with the latter
having experimental support.
3) Windows 7 x64: This OS was a primary option due to its
compatibility with a wide range of malware samples, including
those targeting legacy systems. Its inclusion ensures a compre-
hensive analysis of malware variants exploiting vulnerabilities
specific to this OS.
4) Windows 10 x64: This OS was considered for its modern Fig. 2: DRAKVUF Design Architecture Diagram
features and security enhancements. However, its experimental
support posed challenges, necessitating thorough testing to 1) Key Components and Processes:
ensure reliability and effectiveness in the malware analysis • DRAKVUF: On the left, the DRAKVUF system is illus-
environment. trated, emphasising the breakpoint injection process as
The considerations of host OS options underscored the discussed in the Related Work section.
importance of a UNIX-based system, leading to the selection • Virtual Memory: Various elements and concepts related
of Ubuntu 20.04 LTS for its advanced features, security, and to virtualised memory, introspection, and the hypervisor
compatibility with Xen. For the guest OS, the supported are highlighted.
options of Windows 7 x64 and Windows 10 x64 were both se- • Hardware & Hypervisor: The two boxes at the bottom
lected to ensure a diverse and encompassing malware analysis serves as a visual representation of a computer system
setup, capable of handling a broad spectrum of malware types and the Xen hypervisor sitting on top of it.
and behaviours. This selection process ensures an optimal 2) Labels and Annotations:
balance of compatibility, performance, and security for the
• Dom0 - Secure VM: Indicates a secure virtual machine
malware analysis environment.
environment.
• Windows 7 and 10: Specifies the operating system under
E. Programming Languages analysis or inspection.
In the context of programming languages for the • DRAKVUF: The main focus, a tool for malware analysis.
DRAKVUF web UI, the utilisation of ReactJS was predeter- • Kernel Debugging: Indicates processes related to
mined, as it serves as the foundation for the existing codebase. analysing and inspecting the system kernel.
ENGR 489 (ENGINEERING PROJECT) 2023 7

• Malware Samples: Points to the types of files being and deny them delivery to their email servers. The reports
analysed. also vary in size and this could lead to issues when trying
• LibVMI: A library for virtual machine introspection. to attach them to emails. Providing the user with a link to
• System Calls, Analysis, VM, Introspector, User Space, the report would ensure that the emails would reach their
VMI Memory Acquisition, Kernel Space, Kernel Func- recipients without ending up undelivered or in their junk/spam
tions: These labels provide insights into various processes folders.
and areas within the virtual memory and malware analysis There were also considerations made to what tool was going
ecosystem. to be used to send the emails. The following were the options
• Virtualised Memory, Xen, Hypervisor, Hardware: Indi- that we considered:
cates the underlying infrastructure supporting the virtual • EmailJS
memory system and malware analysis. • SendGrid
• ‘mail’ command on Linux

G. Submitted Sample Lifecycle EmailJS facilitates the sending of emails directly from
The lifecycle diagram is illustrated in Fig. 3, for the submit- JavaScript (frontend), eliminating the need for server-side
ted samples on DRAKVUF’s web UI. This outlines what the code. It supports various email services, is easy to setup, and
DRAKVUF system does once a sample is submitted. It helped offered a user-friendly API.
with setting up the email feature where the report would be SendGrid is a cloud-based email delivery service that assists
retrieved after finishing the analysis. We can see when and businesses in sending transactional and marketing emails. It
where the sample analysis results are stored. is known for its scalability, reliability, and comprehensive
The lifecycle of the malware analysis consists of five main analytics.
parts as seen in Fig. 3: The mail command on Linux is a utility that allows users to
send emails from the command line. It is straightforward but
1. User job submission.
may require additional configuration and lacks the flexibility
2. Job dispatch to one of the VMs.
and features provided by dedicated email services.
3. Malware analysis.
After a thorough evaluation, we chose EmailJS. EmailJS
4. Raw result sent back to host machine.
offers a straightforward integration process, making it easy to
5. Postprocessing of results in readable format.
embed the email sending functionality within the DRAKVUF
web UI. It eliminates the need for server-side code to send
emails, reducing complexity and enhancing the security of the
application. It also supports a wide range of email services and
allows for the customisation of emails templates, ensuring that
users receive well-formatted, informative emails.
The integration of EmailJS into the DRAKVUF web UI
involves utilising its API to trigger emails upon the completion
of malware analysis. Users who provide their email addresses
during the submission of samples for analysis will receive
Fig. 3: Submitted Sample Lifecycle notifications with a link after the analysis is completed. The
email templates are designed to be informative yet concise,
ensuring users receive relevant data in an easily digestible
H. Reporting Emails format.
One of the identified project requirements was to implement Within EmailJS there are options to setup an email address
a feature in the current web UI that would send an email that the reports are sent from. We created a Gmail account,
to a provided email address containing the finished report [email protected], which is a placeholder for an
from DRAKVUF. This functionality would ensure that users official Victoria University email address. The setup was
are promptly informed, allowing for timely review and action straightforward, it required signing into the Gmail account
based on the analysis results. We explored several methods through a Google API integration within EmailJS. This was
to implement this feature, each evaluated based on reliability, the only step that was required for EmailJS to send emails as
ease of integration, and user experience. the Owhiti Sandbox email. The EmailJS tool uses Google’s
There were two options that we came up with for what the mailservers to send the reporting emails.
email would contain. These were:
• Email the entire report as an attachment VII. I MPLEMENTATION
• Email a link to the generated report In the subsequent sections of this chapter, DRAKVUF’s
Each approach had pros and cons but in the end we chose to implementation process is discussed, including the configura-
provide a link to the generated report rather than providing an tion of DRAKVUF and DRAKVUF Sandbox. The following
attachment. This was due to the fact that malicious samples sections provide an overview of the tools used during the
would be submitted for analysis, email providers could flag development phase, the deployment process, and the technical
hashes and key details of the email attachment as malicious aspects of the implementation.
ENGR 489 (ENGINEERING PROJECT) 2023 8

A. Host Setup recommended specifications. As such, we assigned 2 vCPUs

The first step for implementation was deploying a host and a designated RAM of 3072MB to the VM. Using a Virtual
environment that the DRAKVUF system would sit on. Network Connection (VNC), we connected to the DRAKVUF
During the deployment many challenges were faced includ- VM on localhost:5900 to complete the Windows installation
ing hardware compatibility issues and limited log access and and setup the environment for sample analysis.
documentation for troubleshooting. The hardware compatibil- The environment setup required a few steps that were
ity issues that we encountered were due to the Xen hypervisor identified through trial and error. These were:
failing to load because of the onboard GPU driver being too • Modification of User Account Settings to allow files to
modern on the Dell computer that contained the deployment. be opened without a prompt for admin rights.
This issue was resolved by running the DRAKVUF sandbox • Modification of Local Security settings to allow binaries
in a VM. This fixed the problem with a GPU able to be to make modifications to the Windows Registry without
virtualised. admin approval.
A type-2 VM hypervisor was needed to run the host, • Installation of the .NET 4.0 binaries and libraries.
VMWare Workstation Player 17 was chosen. This is due to • Installation of Microsoft Office 2007 suite for the analysis
VMWare being the only supported nested virtualisation option. of Microsoft Office files.
The hypervisor has features like snapshots where it is easy to • Modification of the Registry values for the Microsoft
test different configurations and restore working configurations Office installation to allow for Visual Basic scripts to be
of the sandbox in case something were to go wrong. My run in the suite from the command line.
supervisor also made me aware of the fact that the Dell • kernel32.dll injected into the System32 folder for ‘drak-
computer that was being used was on a lease by the school. setup postinstall’ command to run properly.
This meant that having the deployment on a VM would be
Once the first Guest OS was installed it was time to install
very simple to move to another machine if the lease ended on
the second one which was Windows 10 x64 v2004.
the computer with the deployment on.
The specifications of the host VM on which DRAKVUF We encountered many issues during the deployment of the
was deployed on are: second guest OS. The most critical of them being that Win-
dows 10 support was still experimental, which was addressed
• Intel i7-12700 (All 12 Cores)
in the latest release of DRAKVUF Sandbox (v0.19.0). This
– Virtualise Intel VT-x / EPT version was however, still under development and was unre-
– Virtualise CPU Performance Counters liable due to many scenarios where the installation failed and
– Virtualise IOMMU where it did not provide analysis results. The main limitation
• 12GB RAM was that DRAKVUF Sandbox v0.19.0 was not compatible
• 400GB Storage with DRAKVUF v1.0. It was compatible with DRAKVUF
• Ubuntu 20.04 v1.1 but this has not been released yet and both versions are
This set the foundation for the DRAKVUF system to be still under development as of writing this report. The other
easily installed and for it to be compatible within the host issue was that DRAKVUF Sandbox did not support two guest
environment. OS’s. A university researcher also had issues with multiple
guest OS support and he indicated that through the utilisation
B. DRAKVUF and DRAKVUF Sandbox Deployment of DRAKVUF’s scaling feature, another operating system is
DRAKVUF was implemented using nested virtualisation able to be installed. After testing this approach Windows 10
using Xen running on the VM host environment that was was able to be installed on the DRAKVUF system but was
deployed on the provided Dell Optiplex 7000. To begin not reliable. The scaling feature offers to provide multiple
the DRAKVUF implementation, we first installed both the instances of drakrun workers. If there are multiple users of
identified versions of DRAKVUF and DRAKVUF Sandbox the sandbox, scaling can be used to allow all of them to
stack that we would use to submit malware samples to submit and view analysis reports of samples. By manually
the analysis engine. Once the underlying components were injecting a different OS for the second drakrun worker multiple
installed, DRAKVUF created a local host server instance that guest OS’s can be deployed. Due to issues of experimental
hosts the sandbox interface on port 6300. support for Windows 10, system stability and reliability this
1) Guest OS Deployment: DRAKVUF requires a Windows option was not implemented in the final deployment. Instead
environment to execute the samples and perform analysis. we implemented multiple instances of the Windows 7 guest
Subsequently, the next step in the implementation was to OS which would serve multiple users of the sandbox without
generate a clean Windows 7 and 10 ISO image that could the need to wait for other users to complete their analyses.
use to configure the analysis environment. Once the Windows 7 guest OS was installed, we scaled
We initiated this process with the installation of a Windows the instance to three which was a number that fit with the
7 ISO. The Windows version we used was Windows 7 x64 project requirements and allowed the DRAKVUF Sandbox to
Professional SP1 as it provided the Local Security settings run reliably.
tool by default on install. We then installed ProcDot which is a tool that creates
This Windows deployment was configured to create a virtual behavioural graphs based on the execution of samples and
machine with more than the DRAKVUF documentation’s [9] their interactions within the guest environment. This was
ENGR 489 (ENGINEERING PROJECT) 2023 9

installed and placed in a folder (/opt/procdot/procmon2dot) a link to the analysis results, is sent to the user. The email
where DRAKVUF could access and use it. sending process is handled by EmailJS, ensuring reliability
After the installation was completed using the ‘draksetup and security.
postinstall’ command provided by the DRAKVUF sandbox sendEmail(link) {
stack, we could navigate to the web UI (http://localhost:6300/) if(this.recipientEmailAddress){
and upload some samples to ensure the analysis engine was link = webLink + link;
const templateParams = {
configured successfully. to_email:
this.recipientEmailAddress,
C. Web UI Modification Environment message: link
}
To make modifications to DRAKVUF’s existing web UI a
working DRAKVUF Sandbox instance was required. From the emailjs.send(serviceID,
templateID, templateParams,
deployment setup previously, we had downloaded the source publicKey)
code for the DRAKVUF Sandbox. The code needed to be
linked with the current sandbox deployment, the following .then((res) => {
console.log(`res: ', res);
commands were used to do this: this.clearRecipientEmailAddress();
• cd drakcore/drakcore/frontend })
.catch((err) => {
• npm install console.log(`err: ', err);
• export REACT APP API SERVER=http://localhost:6300/ });
• npm start }
}
After these prerequisites were completed we could begin
with the Web UI modifications with a NodeJS development The implementation was thoroughly tested to ensure the
server that would demonstrate live changes to the web UI on reliability and accuracy of the email notification. Each email
the address, http://localhost:3000/ contains a direct link to the specific analysis results on the
1) Reporting Emails: The implementation of the reporting DRAKVUF web UI, ensuring users can easily access and
emails feature was a critical step in enhancing the user review the findings.
experience of the DRAKVUF web UI. This feature ensures 2) Analysis Time: The implementation of an analysis time
that users are promptly notified via email with the results of slider was a significant feature for the web UI. It provides
the malware analysis. users with the ability to specify the analysis time when
The EmailJS library was imported into the project, enabling uploading a sample for evaluation. This feature ensures that
the direct sending of emails from the client-side application users have flexibility and control over the duration of the
without the need for a backend server to handle email sending. analysis, allowing for a more customised and user-centric
The ‘emailjs-com’ library was integrated into the application experience. Malware also does not finish execution within a
as shown below. set timeframe, having this slider makes it easier for the user
import emailjs from `emailjs-com'; to control how long the analysis is carried out for.
A dedicated ’MinuteSlider’ component was created in React
The service ID, template ID and public key were configured to facilitate the user’s input for specifying the analysis time.
to authenticate and enable the email sending process through This component is rendered as a slider input element, allowing
EmailJS. These configurations were essential to ensure the users to easily adjust the analysis time according to their needs.
security and integrity of the email sending process.
class MinuteSlider extends Component {
const serviceID = `service_------'; render() {
const templateID = `template_------'; return (
const publicKey = `--------------'; <input
onInput={this.props.onInput}
Functions were implemented to set, get, and clear the className=``custom-range"
recipient’s email address. These functions ensure that the email type=``range"
address is correctly handled, stored temporarily for sending the name={this.props.name}
min={60 * this.props.min}
email, and then cleared to maintain privacy and security. max={60 * this.props.max}
setRecipientEmail(recipientEmailAddress){ step={60}
this.recipientEmailAddress = defaultValue={60 * this.props.default}
recipientEmailAddress; />
}, );
getRecipientEmail(){ }
return recipientEmailAddress; }
},
clearRecipientEmailAddress(){ The ’MinuteSlider’ component is configured with properties
this.recipientEmailAddress = null; to set the minimum, maximum, and default values for the
},
analysis time. The values are calculated in seconds, with the
The ’sendEmail’ function was implemented to send emails slider stepping in 60-second intervals to represent minutes.
to users containing the results of the malware analysis. If a The onInput event handler is used to capture the user’s input
recipient email address is provided, an email, complete with and update the state accordingly.
ENGR 489 (ENGINEERING PROJECT) 2023 10

<MinuteSlider They provide clear steps for users on how to submit a file
min={1} for analysis and what the different configuration options mean.
max={10}
default={10}
name=``analysisTime" D. Building drakcore Package and final deployment
onInput={this.handleInput}
/> After the web UI modifications were made the system
needed to be built and deployed again as the changes were on a
The ’handleInput’ function is implemented to manage the NodeJS development server and not on the actual DRAKVUF
state updates when the user adjusts the ’MinuteSlider’. The instance that was deployed. This process ensures that the
analysis time, represented in seconds, is stored in the compo- updated and enhanced web UI is packaged and ready for
nent’s state to be used during the sample upload process. deployment, allowing users to benefit from the new features
handleInput(event) { and improvements.
this.setState({ error: null }); During the build process, a significant challenge was en-
const field = event.target.name;
if (field === ``analysisTime") { countered. The SSL certificates of some external packages
this.setState({timeout: such as Minio and Python had expired, leading to issues
event.target.value}); in building the drakcore package. This obstacle required
}
} immediate attention to ensure the successful compilation and
packaging of the updated web UI.
The selected analysis time is displayed to the user in To address this issue, a meticulous review of the build
minutes, offering a clear and understandable representation of process was undertaken, and the problematic external package
the duration for which the analysis will run. links were identified. The expired SSL certificates necessitated
<small>{this.state.timeout/60} min</small> the modification of these links to ensure the seamless retrieval
of the required packages. The build process was guided by the
The implementation was rigorously tested to ensure that instructions provided in the official documentation for building
the slider responds accurately to user input and that the the drakcore package [12].
selected analysis time is correctly stored and utilised during the After the package was built we had to deploy the entire
sample analysis process. The feature was validated to ensure a DRAKVUF system again as per the steps outlined in Section
seamless user experience, accurately influencing the duration B of the implementation chapter.
of the malware analysis. Following this implementation and deployment, the
3) Virtual Machine Configuration: A modification made DRAKVUF system on the Dell Optiplex workstation was
to the web UI was the addition of the Virtual Machine transitioned to a more robust and accessible environment.
Configuration section. This is a static table that shows the The deployment was extended to the Engineering and Com-
available configurations of virtual machines. It pulls the details puter Science (ECS) school servers to enhance accessibility
from Xen and displays them as seen in Fig. 4 below. and performance. The web address for the deployment is
‘http://103.196.108.47:6300/’. This move was instrumental in
elevating the system’s availability, making it remotely acces-
sible to users. The integration into the ECS servers marked
a significant milestone, ensuring that the system’s capabilities
could be leveraged efficiently and securely.
Fig. 4: Available Configurations Screenshot The connection to the network switch was a pivotal aspect of
this deployment, ensuring network integration and data flow.
Since only one guest OS was implemented there is only one By being connected to the network switch, the DRAKVUF
configuration available. There are however multiple instances system was effectively positioned within the university’s DMZ.
available of that one guest OS. This strategic placement ensured that the system was not
4) Instructions: Instructions for the sample upload page only secure but also benefited from the enhanced network
were added. There was ambiguity around what was and was infrastructure, ensuring high-speed data processing and trans-
not needed for the analysis to run and what file types the mission.
system accepted. The instructions pose as a guide to help new
users how to navigate and use the upload sample page. VIII. E VALUATION
The instructions can be viewed in Fig. 5 below. The methods used to assess this project’s effectiveness are
presented in this section. This covers the survey’s methodology
and questions. Following the data gathering, this section ad-
dresses the project’s applicability and the solution’s measured
effectiveness.

A. Survey
A survey was undertaken to measure usability and user
Fig. 5: Submission Instructions Screenshot satisfaction when performing malware analysis through the
ENGR 489 (ENGINEERING PROJECT) 2023 11

DRAKVUF Sandbox. Eight individuals undertook the survey. comments and feedback regarding the proposed system, which
All individuals within the survey pool were associated with gives insight into possible future developments.
the Owhiti Cyber Security group, which included students and 2) Survey Results: Eight individuals completed the survey,
academic researchers. Participants were emailed the survey with the overall trend being that they were satisfied with the
specifications, which included the steps required to gain access tool’s usability and the information it provided.
to submission samples if they did not have any on their The subjects’ feedback on usability was generally positive.
computer alongside a link to the DRAKVUF Sandbox web A majority expressed that submitting a file for analysis on
UI. The subjects were then asked to access the tool and fill DRAKVUF was straightforward, attributing their positive ex-
out a web survey provided via a Microsoft Form. perience to the intuitive design and user-friendly interface.
1) Survey Questions: The survey consisted of nine ques- The ease of locating and selecting additional configuration
tions that asked users about their prior knowledge and about options was also highlighted, with most participants agreeing
the tool’s usability. It encouraged individuals to use the tool or strongly agreeing on its simplicity.
to perform analysis and extract information which enabled The email notification system received positive feedback.
them to answer specific questions. The questions asked and Five participants received the email notifications in their inbox,
the reasoning behind them are summarised below: three did not receive any. Upon further inspection however,
1. Have you ever used an online malware sandbox it revealed that the users that did not receive a notification
before? This question targeted an evaluation of the subject’s did not enter their email address into the input box, meaning
prior knowledge on sandboxes and if they were familiar with the system functioned appropriately. However, for any future
how to submit samples and the common configuration settings surveys, the point to provide an email address should be
on them. emphasised.
2. Do you know how a malware sandbox works? This Participants provided valuable insights on potential en-
question targeted an evaluation of the subject’s prior knowl- hancements. Suggestions included the incorporation of more
edge on sandboxes and if they were familiar with the inner- detailed explanations of features and a progress bar to inform
workings of them. users of the analysis status.
The following questions were choice questions, they The consistency in the ‘look and feel’ of the sandbox
spanned from Strongly Disagree to Strongly Agree and as- throughout the process was generally well-received, with most
sessed the usability, effectiveness and feel of the web UI. participants agreeing or strongly agreeing on its consistency.
3. It was easy and intuitive to submit a file for analysis on However, one participant noted that the graphics for the
DRAKVUF This question targeted an evaluation of the tool’s behavioural graph did not align with the overall UI design,
usability to gauge if it was too complicated and required more suggesting an area for aesthetic enhancement.
explanation or if users could understand the different features The feedback from the eight participants provides invaluable
and perform analysis. insights for the refinement of the DRAKVUF web UI. The
general satisfaction with the tool’s usability is encouraging,
4. It was easy to find and select additional configuration
while the identified areas for improvement offer clear path-
options (eg: Analysis Time, Modules enabled, Email input,
ways for enhancement.
etc.) This question tests a subject’s ability to find and select
Although the survey had a small pool of participants re-
additional configuration options on the web UI.
garding usability testing, eight participants allowed us to find
5. It was easy to find and view/download the logs and
almost as many usability problems as you’d find using many
reporting artefacts created by the sandbox This question
more test participants [13].
targets the evaluation of the tool’s reporting feature and if sub-
jects were able to easily find the artefacts and view/download
them. B. Functional Evaluation
6. The sandbox ‘look and feel’ was consistent throughout The DRAKVUF web UI, deployed on the ECS servers
the whole process This question targets the evaluation of the on Friday 22nd September 2023, has been tested to ensure
tool’s ‘look and feel’ and if the subjects found it consistent its functionality, reliability, and efficiency. The web UI has
throughout the process. proven to be a robust tool, consistently delivering accurate
7. Did you receive an email for the sample file submission and comprehensive results without any failures or significant
results in your inbox or junk mail? (After inputting your issues since deployment.
email in the ‘Customise’ options) This question aims to find There have been more than 30 sample submissions to the
out whether the email was received in the Inbox or Junk folder web UI since deployment, without failure. Compared to the
(or not received at all), to see if there are any bugs with this Cuckoo system that the Owhiti Cyber Security group currently
feature. uses this is a dramatic increase in reliability. My supervisors
8. Is there any new functionality you would like to have indicated that the Cuckoo system is notorious for crashing
be added to this system? We can use this information to even while it is not in use. DRAKVUF has been active for
provide further features based on the information provided by three weeks now on the ECS servers and has not failed nor
the subjects. crashed.
9. Is there any other feedback/suggestions you would A detailed examination of one of the sample submission
like to provide? This question provides space for additional instances provides a comprehensive insight into the system’s
ENGR 489 (ENGINEERING PROJECT) 2023 12

capabilities. The web UI is structured to offer a user-friendly C. Project Requirements Evaluation

experience, ensuring that users can navigate through diverse The evaluation of the DRAKVUF Malware Sandbox project
sections to access the required information. The sample in is essential to assess the alignment with the initial require-
question is a famous ransomware based malware called Wan- ments. This section provides an analysis of the met and unmet
naCry. It is a heavily documented ransomware, when it was requirements.
first released, it infected over 230,000 computers across 150 The project has achieved notable successes. The web in-
different countries. terface is remotely accessible and user-friendly - confirmed
The analysis results are presented in a well-organised man- by positive user feedback. The email notification system
ner, offering a blend of graphical and textual data. The be- is operational, ensuring users are informed of the analysis
havioural graph, for instance, provides a visual representation results in a timely manner. The file submission process is
of the malware’s behaviours. It maps out the interactions and straightforward, and users have found the instructions clear
activities of the malware, offering a clear and concise view of and helpful.
its operational patterns. For the case of WannaCry, it shows However, there remains an unmet requirement pertaining to
that a script (cscript.exe) is used to encrypt all of the files in the support for multiple operating systems. The initial objec-
the analysis environment. Then a program is created called tive was to incorporate two operating systems, Windows 7 and
WannaDecryptor.exe which is the tool the victim is given Windows 10, to offer a diverse and adaptable environment for
access to after the ransom has been paid. Using DRAKVUF malware analysis. This diversity was aimed at ensuring that the
malware analyst’s can locate where the WannaDecryptor.exe tool could be utilised for a comprehensive analysis, catering
tool is stored and can find and use it without having to pay the to a wide array of malware designed for different operating
ransom the attackers want. This visual aid is instrumental in systems. However, the current implementation is confined to a
quickly understanding the malware’s behaviour, interactions, single guest OS type. This limitation is attributed to constraints
and potential impact on the system. related to resource allocation, technical complexities associ-
The detailed logs and reports generated by the system are ated with integrating multiple operating systems, challenges in
another significant asset. They offer a granular view of the ensuring stable and reliable performance across the platforms,
malware’s headers and operations, including metadata (as seen and the lack of support in the official stable release of the
in Fig. 6, system calls, and file interactions. For malware system.
analysts, this level of detail is invaluable. For the case of The DRAKVUF Malware Sandbox project has made sig-
WannaCry the report provides many Indicators of Compromise nificant progress on the original implementation. The unmet
(IoCs) such as its hashes, IP addresses, and specific arguments requirement does not overshadow the achievements but rather
passed to Windows DLLs. DRAKVUF not only aids in offers an opportunity for growth and enhancement.
understanding the specific characteristics and behaviours of
the malware but also facilitates the development of effective
countermeasures and mitigation strategies. IX. C ONCLUSION
The DRAKVUF Malware Sandbox project, represents a
significant stride in the field of malware analysis. The project
successfully extended the DRAKVUF sandbox’s web UI, en-
hancing capabilities. The project was designed to be remotely
accessible through a web interface and showed the available
virtual machine and operating system along with their respec-
tive configurations. It allowed the management of multiple
instances of DRAKVUF and supported the submission of
a file to be analysed by the operating systems through the
web interface. Users could download the reports generated
by DRAKVUF or view them through the web interface, and
reports could also be emailed to a designated address provided
Fig. 6: DRAKVUF - WannaCry Metadata Results by the user.
Despite the project’s achievements, it faced challenges in-
The system’s capability to provide a detailed analysis of cluding the limitation of supporting only one guest OS type.
the memory dumps is another noteworthy feature. Analysts However, the accomplishments in enhancing the user interface,
can delve deep into this aspect, extracting critical information improving the reporting component, and extending the queuing
that can be pivotal in understanding the malware’s infiltra- system are notable milestones that contribute to the project’s
tion techniques, propagation mechanisms, and data exfiltration overall success.
strategies. In conclusion, the DRAKVUF Malware Sandbox project
For more information on DRAKVUFs findings on shows the potential of continuous innovation and refinement in
the ransomware WannaCry, please visit this link: malware analysis. While there are areas for improvement, the
http://103.196.108.47:6300/analysis/a72d43bf-0994-4eda- achievements made are significant and lay a robust foundation
9891-4387acd29187. for future enhancements. The project not only contributes to
Screenshots of the analysis can be viewed in the appendix. the body of knowledge in malware analysis but also offers
ENGR 489 (ENGINEERING PROJECT) 2023 13

practical solutions that can be adopted and adapted in real- R EFERENCES

world scenarios to understand and mitigate the impacts of [1] S. Megira, A. Pangesti, and F. Wibowo, “Malware analysis and detection
malware effectively. The collaborative and iterative approach using reverse engineering technique,” in Journal of Physics: Conference
to the project’s development ensures that it remains responsive Series, vol. 1140, no. 1. IOP Publishing, 2018, p. 012042.
[2] M. Sikorski and A. Honig, Practical Malware Analysis: The Hands-On
to emerging needs and challenges in the dynamic landscape Guide to Dissecting Malicious Software. No Starch Press, 2012.
of cybersecurity. [3] S. YusirwanS, Y. Prayudi, and I. Riadi, “Implementation of malware
analysis using static and dynamic analysis method,” International Jour-
nal of Computer Applications, vol. 117, no. 6, pp. 11–15, 2015.
X. F UTURE W ORK [4] T. K. Lengyel, S. Maresca, B. D. Payne, G. D. Webster, S. Vogl, and
A. Kiayias, “Scalability, fidelity and stealth in the drakvuf dynamic
As the DRAKVUF Malware Sandbox project comes to a malware analysis system,” in Proceedings of the 30th Annual Computer
close, several opportunities for future work and enhancement Security Applications Conference. ACM, 2014, pp. 386–395.
[5] “Drakvuf® black-box binary analysis system.” [Online]. Available:
have been identified to augment its functionality, efficiency, https://drakvuf.com/
and user experience. [6] S. Kovalev, “Reading the contents of deleted and modified files in
the virtualization based black-box binary analysis system drakvuf,”
Proceedings of the Institute for System Programming of the RAS, vol. 30,
A. Integration of Multiple Operating Systems no. 5, pp. 109–122, 2018.
[7] A. A. R. Melvin and G. J. W. Kathrine, “A quest for best: A de-
One of the primary areas for future development is the inte- tailed comparison between drakvuf-vmi-based and cuckoo sandbox-
gration of multiple operating systems. The current limitation based technique for dynamic malware analysis,” in Intelligence in Big
Data Technologies—Beyond the Hype: Proceedings of ICBDCC 2019.
to a single guest OS can be expanded to include a variety Springer, 2021, pp. 275–290.
of operating systems, enhancing the sandbox’s versatility and [8] C. Sandbox, “Cuckoo sandbox is an automated dynamic
making it adaptable to a broader range of malware types. malware analysis system,” 2021. [Online]. Available: https:
//github.com/cuckoosandbox/cuckoo
There is currently an issue on the DRAKVUF Sandbox [9] “Understanding the sandbox - drakvuf sandbox v0.18.2 documentation.”
GitHub [14] that outlines the same problem. [Online]. Available: https://drakvuf-sandbox.readthedocs.io/en/latest/
understanding sandbox.html
[10] Tklengyel, “Releases · tklengyel/drakvuf,” 2021. [Online]. Available:
https://github.com/tklengyel/drakvuf/releases
B. Incorporation of Machine Learning and AI [11] CERT-Polska, “Releases · cert-polska/drakvuf-sandbox,” 2021. [Online].
The integration of machine learning and artificial intelli- Available: https://github.com/CERT-Polska/drakvuf-sandbox/releases
[12] “Building installation packages - drakvuf sandbox v0.18.2 documen-
gence algorithms can augment the sandbox’s capability to tation.” [Online]. Available: https://drakvuf-sandbox.readthedocs.io/en/
identify, analyse, and mitigate malware. These technologies latest/building packages.html
can enhance the accuracy and speed of malware detection and [13] J. Nielsen, “How many test users in a usability study?” 2012. [Online].
Available: https://www.nngroup.com/articles/how-many-test-users/
analysis, offering predictive and prescriptive insights. [14] CERT-Polska, “Support for multiple os malware analysis · issue 462
· cert-polska/drakvuf-sandbox.” [Online]. Available: https://github.com/
CERT-Polska/drakvuf-sandbox/issues/462
C. Integration with Elastic Stack for Comprehensive Visuali-
sations
The integration of DRAKVUF Malware Sandbox with Elas-
tic Stack is a considered step to improve data interpretation and
usability. This integration allows for efficient data management
and real-time processing, enhancing the tool’s responsiveness.
Users can benefit from interactive visualisations, offering a
clear and direct understanding of malware analysis findings.
The use of Elastic Stack enables the creation of custom
dashboards, allowing users to personalise data views and
analytics according to specific needs. The advanced analytics
feature of Elastic Stack provides deeper insights into malware
trends and patterns. Data integration protocols and APIs will
be developed to ensure a smooth transfer of data between
DRAKVUF and Elastic Stack, maintaining data consistency
and reliability.

ACKNOWLEDGMENTS
I would like to thank my two supervisors Masood Man-
soori and Lisa Patterson for providing support throughout the
project. It would not be in the current state without their
help. I would also like to thank Muhammad Shabbir Abbasi
for his support with the multiple OS feature. Although the
implementation was not stable; it provided insights into the
workings of the system.
ENGR 489 (ENGINEERING PROJECT) 2023 14

A PPENDICES

DRAKVUF A NALYSIS - WANNAC RY M ETADATA AND P ROCESS T REE O UTPUT

DRAKVUF A NALYSIS - WANNAC RY B EHAVIOURAL G RAPH O UTPUT

ENGR 489 (ENGINEERING PROJECT) 2023 15

DRAKVUF A NALYSIS - WANNAC RY L OGS O UTPUT

DRAKVUF A NALYSIS - WANNAC RY API C ALLS O UTPUT