# Peeler: Profiling Kernel-Level Events to Detect Ransomware

Muhammad Ejaz Ahmed, Hyoungshick Kim, Seyit Camtepe, and Surya Nepal M. E.
Ahmed, S. Camtepe, and S. Nepal are with Data61 CSIRO, Sydney, Australia
(e-mail: {ejaz.ahmed, seyit.camtepe, surya.nepal}@data61.csiro.au). H. Kim is
with the College of Software, Sungkyunkwan University (SKKU), Suwon, Korea
(e-mail<EMAIL_ADDRESS>
###### Abstract

Ransomware is a growing threat that typically operates by either encrypting a
victim’s files or locking a victim’s computer until the victim pays a ransom.
However, it is still challenging to detect such malware timely with existing
traditional malware detection techniques. In this paper, we present a novel
ransomware detection system, called “Peeler” (Profiling kErnEl -Level Events
to detect Ransomware). Peeler deviates from signatures for individual
ransomware samples and relies on common and generic characteristics of
ransomware depicted at the kernel-level. Analyzing diverse ransomware
families, we observed ransomware’s inherent behavioral characteristics such as
stealth operations performed before the attack, file I/O request patterns,
process spawning, and correlations among kernel-level events. Based on those
characteristics, we develop Peeler that continuously monitors a target
system’s kernel events and detects ransomware attacks on the system. Our
experimental results show that Peeler achieves more than 99% detection rate
with 0.58% false-positive rate against 43 distinct ransomware families,
containing samples from both crypto and screen-locker types of ransomware. For
crypto ransomware, Peeler detects them promptly after only one file is lost
(within 115 milliseconds on average). Peeler utilizes around 4.9% of CPU time
with only 9.8 MB memory under the normal workload condition. Our analysis
demonstrates that Peeler can efficiently detect diverse malware families by
monitoring their kernel-level events.

###### Index Terms:

Ransomware detection, Crypto ransomware, Screen-locker, Malware behavior
analysis, Machine learning

##  I Introduction

Ransomware is a class of malware that has significantly impacted enterprises
and consumers. The goal of such type of malware is to obtain financial gain by
holding a victim’s system or resources as a hostage through encrypting the
victim’s files (called crypto ransomware) or locking the victim’s desktop
screen (termed as screen-locker ransomware). Recent statistics of ransomware
shows that in the first three quarters of 2019, 151.9 million ransomware
attacks were launched targeting enterprises and consumers [1, 2]. The average
payment to release files to the victims spiked to $84,116 in the last quarter
of 2019, more than double what it was in the previous quarter [3]. In 2019,
the U.S. alone was hit by an unprecedented barrage of ransomware attacks that
impacted more than 966 government agencies, educational institutions, and
healthcare providers at a potential cost of around $7.5 billion [4]. As such,
ransomware represents one of the most visible threats to enterprises as well
as users. Therefore, a large number of proposals have recently been proposed
to fight against ransomware as follows: machine learning models (e.g., [5, 6,
7, 8, 9]), use of decoy files (e.g., [10, 11, 7]), use of a key escrow
mechanism (e.g., [12]) and file I/O pattern profiling (e.g., [13, 14, 15, 16,
17, 9, 18, 7, 19]).

However, these techniques have at least one of the following limitations: 1)
Localised visibility: existing approaches with limited localized visibility
would struggle to detect certain type of malicious activities. For example,
ransomware may first attempt to delete Windows backup files, disable anti-
malware, or real-time monitoring services on the victim’s machine to remain
undetected before actually starting to encrypt user files. Techniques relying
on file I/O request patterns, cryptographic primitives, or network traffic
would fail to detect these activities making it challenging to recover from
the attack. If suspicious activities are detected timely, ransomware can be
detected without data loss. 2) No guarantee on data loss: most approaches do
not provide any recovery or minimal data loss guarantees, i.e., late detection
after several files have already been encrypted, or the computer has been
locked [14, 10, 20, 15, 9]. Scaife et al. [15] proposed CryptoDrop which is
based on the premise that ransomware aggressively encrypts user files. Their
approach is able to detect a ransomware attack after a median of ten file
losses. REDFISH [13] detects the ransomware activity when ten files are lost,
and the detection time took around 20 seconds. Similarly, RWGuard [10] took
8.87 seconds on average to detect all malicious processes spawned by
ransomware. 3) Not flexible: Most crypto ransomware detection approaches [10,
13, 15, 20] are built upon either file I/O patterns or cryptographic
primitives, however, these techniques are not applicable to detect screen-
locker ransomware requiring a separate module to detect them. For instance, in
addition to detect crypto ransomware (based on file I/O request patterns),
Kharraz et al. [14] developed computer vision-based machine learning module
just to detect screen-locker ransomware. Similarly, PayBreak [12] can decrypt
files only for the ransomware families that use system provided crypto
functions. Such inflexibilities in existing approaches make it difficult to
incorporate for different types of malware.

Moreover, to collect a diverse set of system events efficiently and consume
them in a real-time is in itself a challenging task [20]. For instance,
Windows OS audit policies (auditpol.exe) allow users to enable several types
of system events, but those are only a subset of all the telemetry available
in Windows systems limiting its visibility [21]. There are several types of
data sources available, but they can not be easily enabled using an audit
policy. Similarly, there are certain APIs (e.g., Win32 Event Tracing API,
System.Diagnostic.Eventing, TraceEvent) that allow us to log system events
interactively, but they incur higher CPU and memory overheads [20]. For an
effective ransomware detection scheme, diverse set of data sources should be
easily accessible for analysis with minimum overhead.

To address the shortcomings identified above, we develop a novel ransomware
detection system, called “Peeler” (Profiling kErnEl -Level Events to detect
Ransomware), which tracks ransomware activities from a ransomware binary
execution on a victim’s computer to the display of a ransom note on the
victim’s screen. For a successful attack, ransomware first aim to remain
undetected by anti-malware services on a victim’s computer. To achieve
stealthiness, ransomware may disable real-time monitoring, archive scanning,
or even delete its own binary from the disk. After that, they launch the
actual attack – encryption of user files or locking users’ desktop screens,
and finally, payment guidance activities, e.g., change background display
picture containing ransom payment note. Peeler exploit several behavioural
characteristics observed during the execution of a ransomware and develop a
set of methodologies by leveraging rule-based, file I/O patterns-based
matcher, and machine learning models.

Peeler provides comprehensive visibility via broad and deep monitoring of
current and historical security configurations and events associated with
sensitive operations. Unlike existing approaches that either rely on APIs or
command line tools to collect system events, Peeler extract required system
events from native layer of Windows OS using Windows Event Tracing (ETW)
framework. As a result, Peeler performs significantly better compared to
existing APIs and tools. Moreover, Peeler can intercept events from system-
wide Windows OS providers (e.g., there are more than 1,100 providers in
Windows 10) providing greater visibility. Finally, the generated system events
can consumed in a real-time for early detection. Our key contributions are
summarized below:

  * •

Accurate: We develop a set of methodologies based on comprehensive analysis of
ransomware from binary execution on victim’s computer to the display of a
ransom note at the victim’s computer screen, and design a fast and highly
accurate ransomware detection system, called Peeler. It relies on suspicious
commands, file I/O event patterns, and two classification models with 13
system behavior features to achieve both fast detection and high detection
accuracy. Overall, Peeler achieves 99.52% detection accuracy with a false
positive rate of only 0.58% against 43 ransomware families – the largest
dataset so far in terms of its diversity. Moreover, Peeler achieves 100% and
99.5% detection accuracy against crypto and screen-locker ransomware,
respectively.

  * •

Fast: We measure the detection time of Peeler against both crypto and screen-
locker ransomware families. Peeler took 115.3 milliseconds on average to
detect crypto ransomware. Compared to the best existing crypto ransomware
detection solution, Peeler is about five times faster. In addition, Peeler
took 16.4 seconds on average to detect screen-locker ransomware while the
execution time of screen-locker ransomware to lock the victim’s desktop screen
completely is 302.8 seconds on average, demonstrating that Peeler can also
detect screen-locker ransomware at an early stage before locking a victim’s
system.

  * •

Transferable: We evaluate Peeler (without new training) against 86 samples
from 26 new and unseen ransomware families, including crypto, screen-locker,
and general malware samples. Peeler achieved more than 95% detection accuracy
in detecting new and unseen ransomware samples. Additionally, Peeler also
detected 9 out of 16 samples from general malware.

##  II Key characteristics to detect ransomware

Typically, a ransomware attack consists of three stages: perform stealth
operations to remain undetected, launch the actual attack, and display ransom
note after a successful attack. In the first stage, all necessary actions
required to perform a successful ransomware attack without being detected are
executed. For instance, ransomware may attempt to change Windows OS
configurations (e.g., disable real-time monitoring) to remain undetected by
anti-malware services. In the second stage, the actual attack is launched,
e.g., adversaries delete Windows OS shadow copies to prevent the victim from
restoring the Windows OS to the previous version. In the final stage, a ransom
note, along with guidance, is provided to the victim.

Peeler exploits the differences in system behavioral characteristics between
ransomware and benign applications. We collected kernel-level events generated
by diverse ransomware samples and benign applications and analyzed those
events to gain insights into the unique and inherent system behaviors of
ransomware. This section explores those characteristics in detail.

TABLE I: Set of actions required to perform attacks.

Goal |  Action
---|---
Stealth |  Delete the ransomware executable from the disk.
Kill the task responsible for running malware.
Set boot entry elements to ignore errors if there is a failed boot or failed
checkpoint.
Modify registry values to hide files and filename extensions.
Turn off User Account Control (UAC) to remain undetected.
Disable archive scanning, real-time monitoring by anti-malware services.
Attack |  Delete Windows OS shadow copies to prevent victim from restoring Windows OS.
Disable automatic repair feature in Windows OS.
Start executing malicious tasks, e.g., encryption of user files, with highest
privileges.
Launch encoded PowerShell commands to change configurations.
Stop or bypass detection by a number of popular anti-malware services
including Windows OS Defender.
Deny the specific rights to delete child folders.
Payment guidance |  Change Windows OS wallpaper informing the victim about attack.
Change background display picture containing ransom payment notes.
Open read-me document such as notepad containing all information about ransom
payment.

###  II-A Malicious commands

To maximize the impact of the encryption, ransomware performs malicious
activities with the following three goals.

####  II-A1 Stealthiness

Ransomware tries to remain undetected by anti-malware services or Windows OS
defenders running on the victim’s computer. For example, they may disable the
following services: runtime monitoring, archive scanning, automatic startup
repair (see Table I). Moreover, they may delete ransomware executable from the
disk, stop all anti-malware services, or turn off User Account Control (UAC).

####  II-A2 Infeasibility of recovery

Ransomware deletes the shadow copies and the system’s backup/restore data
automatically created by Windows OS. For example, vssadmin is a default
Windows OS utility that controls volume shadow copies of user files on a given
computer. These shadow copies are regularly used as a recovery point, and
additionally, they can be leveraged to re-establish or return the file to a
previous state if they are destroyed or lost due to some reasons. Adversary
exploits Vssadmin utility, by executing the command vssadmin.exe delete
shadows /all /quiet, to delete Windows OS shadow copies, making it impossible
to restore the system back to its previous state. Of course, there are also
other ways to delete shadow copies such as via PowerShell, wmic, etc. The
ransomware can leverage Windows OS program net.exe commands to stop or bypass
detection by several popular antivirus software, in addition to defeating
Windows OS Defender, e.g., net.exe stop avpsus /y stops Windows OS process
Kaspersky Seamless Update Service which is used by Thanos ransomware family.
Moreover, ransomware sometimes tries to kill the processes related to specific
programs, such as SQL server, to initiate the encryption of the user files on
which these programs were operating. After encrypting user files, ransomware
shows a ransom note and payment guidelines.

####  II-A3 Post-attack guidance on ransom payment

Finally, a ransom note is displayed along with a read-me document to help the
victim pay the ransom and restore the system files. The ransomware writer
typically adds a registry key to the autorun path to show the ransom note
window to achieve this.

Table I lists the set of actions performed by typical ransomware to achieve
respective goals. The actual list of commands used in real-world ransomware
are listed in Table I is given in Appendix -C. By intercepting such malicious
commands, ransomware could be effectively detected. For instance, Hendler et
al. [22, 23] proposed deep learning approaches to detect malicious PowerShell
commands. However, in practice, malicious commands could be launched not only
by PowerShell, but also from Windows OS legitimate utilities, such as
vssadmin, wmic, etc. We consider all malicious command sources rather than
relying on malicious commands executed from a specific program.

###  II-B File I/O patterns

Our analysis on collected events reveals that crypto ransomware samples
typically encrypt a user’s file by performing the following four steps: access
the file (access), read the content of the file (read), write the encrypted
content to a temporary memory or new file (write), and overwrite/delete the
user’s original file (overwrite/delete). For example, Figure 1 shows a
sequence of file I/O events from a variant of Cerber. These events align with
the observed four file I/O steps as follows: 1) in the access step, the
ransomware sample accesses a file (D_186.wav) with the FileCreate event; 2) in
the read step, the ransomware sample reads the content of D_186.wav with the
two Read events; 3) in the write step, the ransomware sample writes the
encrypted content to the same file with the two Write events; and 4) in the
overwrite step, the file is finally renamed with the Rename, FileDelete, and
FileCreate events. As shown in Figure 1, the FileDelete operation removes the
content of the original file D_186.wav and FileCreate assigns a new name
2O8nlobpEl.8cbe. We note that the File Key remains the same for all events
even though the original file’s name and extension are changed.

Figure 1: File I/O events generated by Cerber ransomware.

We observe that most crypto ransomware samples follow similar steps to lock a
victim’s files. However, the locking strategy adopted by each ransomware
sample can be different. For example, some families lock a file without
creating a temporary file, whereas others choose to lock a file via a
temporary file; some deletes the original file, whereas others decide to
overwrite. We perform numerous trials and experiments and observe four
_generic_ file I/O patterns that characterize behaviors of most crypto
ransomware families. We briefly summarize our findings as follows.

  1. 1.

Memory-to-File with Post-Overwrite: As shown in Figure 1, some crypto
ransomware samples directly overwrite a user’s file with its encrypted data
without creating a new file. The I/O events pattern observed is to overwrite
the encrypted data to the original file and then rename its file name. This
pattern can be observed in the following ransomware families: Cerber, Keypass,
Telsacrypt, and Gandcrab.

  2. 2.

Memory-to-File with Pre-Overwrite: This file I/O events pattern is similar to
“Memory-to-File with Post-Overwrite” except that the original file is first
renamed, and then the encrypted data is overwritten to that file. This pattern
can be observed in samples from Locky ransomware family. Figure 2 shows a
sequence of file I/O events generated from a sample in the Locky family. We
can see that the original file is first renamed.

  3. 3.

File-to-File with Delete: Some crypto ransomware samples create a new file and
copy the encrypted data of the original file to the new file instead of
overwriting the original file itself. After completing the copy process, the
original file is finally deleted. This pattern can be observed in the
following families: InfinityCrypt, Dharma, Malevich, Sage, and Syrk. Figure 9
in Appendix -A shows a sequence of file I/O events generated from a sample in
the InfinityCrypt family. We can see that the ransomware sample reads the file
with the file key (FFFFB203AFD146F0) and writes it (in an encrypted form) to
the file with the file key (FFFFB203AFD14160). After copying all the file
content to the new file, the original file with the file key
(FFFFB203AFD146F0) is deleted.

  4. 4.

File-to-File with Rename and Delete: This file I/O events pattern is similar
to “File-to-File with Delete” except that the new file is renamed after
copying the encrypted data of the original file to the new file. This pattern
can be observed in samples from the WannaCry ransomware family. Figure 10 in
Appendix -A shows a sequence of file I/O events generated from a sample in the
WannaCry family. After copying all the file content to the new file, the file
is renamed from nasa.txt.WNCRYT to nasa.txt.WNCRY.

Figure 2: File I/O events generated by Locky ransomware.

We show that most families from crypto ransomware follow one of the four file
I/O patterns above described.

###  II-C Application process tree

Applications can spawn one or more processes if it is needed. If a process in
an application creates another process, then the creator process is called
parent process, and the created process is called child process. We observe
that some ransomware families spawns many child processes in a certain pattern
compare to that of benign applications. For example, Figure 3 shows a snapshot
of the application process tree of VirLock ransomware during its execution.
VirLock is self-reproducing ransomware that not only locks a victim’s screen
but also infects her files. Both behaviors – self-reproducing and infecting
files – were observed in the application process tree of VirLock. We can see
locker.exe is replicated at level 3 of the tree.

Figure 3: Application process tree of VirLock.

To infect a victim’s files, VirLock performs stealthy malicious activities to
deceive victims. For instance, while creating files in the victim’s computer,
VirLock modifies the registry in the following ways: 1) disable Windows OS
User Account Control (UAC), which is a feature that was designed to prevent
unauthorized changes in desktop computers; 2) hide all files that are created
on the victim’s desktop; and 3) hide all created file extensions. As shown in
Figure 3, three child processes (reg.exe in red color) perform the actual
registry modifications. The corresponding command line execution is shown at
the bottom of Figure 3.

In contrast, most benign applications create far less number of spawned
processes compare to the screen-locker ransomware. Figure 4 shows the
application process trees of six benign applications (Chrome, Adobe Acrobat
Reader, MS Visual Studio 2019, MS Office 365 ProPlus, Spotify, and MS
Outlook).

Figure 4: Application process trees of benign applications.

Our observations on the behaviors of ransomware families show that more than
60% of samples spawn multiple processes. For instance, VirLock ransomware
sample spawns 44 processes on average. On the other hand, our observations on
more than 50 most popular benign Microsoft applications show that they spawn
16 processes on average, significantly smaller to that generated by a screen-
locker ransomware sample.

###  II-D Correlations between system events

We analyzed the system events generated by ransomware samples and observed
that there exist strong correlations between some events for the operations of
ransomware. For example, all files read must be written (encrypted), which
naturally shows a correlation between Read and Write events. Furthermore,
similar correlations are exhibited among events collected from different
providers such as File, Process, Image, and Thread because ransomware samples
generate a large file Read and Write events to perform malicious tasks. Such
relationships between certain events can be quantified by using the
correlation coefficients of the events (see Table II).

TABLE II: Correlation coefficients for some events.

Events pair | Ransomware | Benign applications
---|---|---
(File Read, File Write) | 0.9433 | 0.3500
(Process End, Image Unload) | 0.9451 | 0.7174
(Process Start, Image Load) | 0.9476 | 0.7397
(Thread Start, Thread End) | 0.9560 | 0.6585

For example, a crypto ransomware sample generates Read and Write events
regularly. As presented in Table II, there exists a strong correlation between
the number of Read events and the number of Write events. Such a correlation
relationship may not appear in benign applications’ Read and Write requests.
Similarly, during ransomware execution, we observe the correlation between the
number of Start processes and the number of image Load events, the correlation
between the number of End processes and the number of image Unload events, and
the correlation between the number of Start threads and the number of End
thread events. These correlation coefficients are computed from the analysis
performed on 206 ransomware samples and 50 most popular benign applications.
Figure 5 shows correlation among three pairs of events (Read and Write, Start
and Load, End and Unload). We clearly observe strong correlations for
ransomware compared to benign applications. Therefore, Peeler uses those
correlations to detect ransomware.

Figure 5: Correlations among some event types for ransomware and benign
applications.

##  III System Design

Peeler is designed to minimize the overall damage by ransomware attacks using
three different detection modules. Our design principle is to detect
ransomware attacks as early as possible because the number of encrypted files
(i.e., the victim’s damage) can be increased if the attack detection is
delayed. Therefore, our design principle is to detect it immediately by using
a simple pattern matching first as soon as the first file is encrypted. We
believe that the sacrifice of one file is our best effort scenario in the view
of dynamic analysis because Peeler leverages file I/O event patterns that can
be generated when a file is encrypted by a ransomware.

To overcome the limitations of existing rule-based detectors, we consider not
only specific rules to detect atomic observables (e.g., a known malicious file
hash or a specific registry key modification) but also generic rules to
identify ransomware’s inherent behaviors. In practice, considering both
specific and generic rules is essential in designing effective malware
detection engines and the defenders’ security posture [24]. Based on this
principle, Peeler’s rules are categorized as follows: 1) key observables such
as an indicator of compromise (e.g., malicious commands trying to delete
Windows OS shadow copy); and 2) generic system event sequences (file I/O
patterns discussed in Section II-B).

To detect some sophisticated ransomware samples that are not detected by the
rule-based approach, Peeler additionally adopts two different machine learning
models by extracting behavioral features from process execution patterns (see
Section II-C) and correlations among various system events (see Section
III-E2) for ransomware’s activities.

###  III-A Overview

Peeler has three main ransomware detection modules: 1) malicious command
detector, 2) file I/O pattern matcher, and 3) machine learning-based
classifier. Figure 6 illustrates the overall design of Peeler. Peeler monitors
system events continuously to detect ransomware attacks in real-time and uses
them to perform ransomware detection. The malicious command detector uses pre-
defined rules to check whether malicious commands are executed by processes in
which the execution of those commands are mainly observed in ransomware
activities. The file I/O pattern matcher takes _kernel-level_ file I/O events
as input and looks for suspicious file I/O patterns that can be shown for
ransomware. Once a pattern that characterizes ransomware behavior is detected,
Peeler generates an alert. Machine learning-based classifier module extracts
features from application process tree and system events providers (Process,
Image, File, and Thread). The application process tree features are used to
build a multinomial logistic regression model, whereas the system event
features are used to build a Support Vector Machine (SVM) model. For
detection, the scores from both classification models are fused as an ensemble
approach, and then detection is performed.

Figure 6: Overview of Peeler.

Algorithm 1 enlists all the key steps required for ransomware detection. A
window size $W$ and a set of rules ($R_{s}$) are given as inputs to Algorithm
1. As shown in Figure 6, the system events monitor collects kernel events and
forwards them to three modules (the malicious command detector, the file I/O
pattern matcher, and the machine learning-based classifier) in parallel. There
are two differences between these modules: 1) malicious command detector and
file I/O pattern matcher consumes events generated from the Process and File
providers to identify malicious commands and suspicious file I/O patterns,
respectively. Whereas ML-based classifier utilizes events from all four
providers (File, Process, Image, and Thread) and application process tree
features to detect both crypto and screen-locker ransomware. 2) Malicious
command detector and file I/O pattern matcher performs analysis on a per-event
basis (Step 3 and 7, respectively), whereas ML-based classifier accumulates
events for $W$ seconds (Step 11) and then processes them in a batch (Step 12).
If all modules do not detect suspicious activities by ransomware, Peeler
continuously monitors the system (Step 15).

###  III-B System events monitor

Peeler provides a module called _system events monitor_ which relies on Event
Tracing for Windows111ETW was first introduced in Windows 2000 and is now
built-in to all Windows OS versions. (ETW) framework. ETW is a built-in,
general-purpose logging and diagnostic framework in Windows OS. It is
efficient (high speed and low overhead), flexible (consume events in a real-
time or log to a file), and provide greater visibility into the system such
that it allows to register to more than 1,100 subsystem providers [25] to
receive and consume events. ETW framework is available for usage in both APIs
and, command line tools and applications. The usage of ETW-based command line
tools and applications are more common compared to ETW APIs (e.g.,TraceEvent,
System.Diagnostic.Eventing, Event Tracing) to view system events [20].

Algorithm 1 Overall Process of Peeler

1:Input:  $W$ and $R_{s}$

2:while true do

3: System events monitor receives an $event$ from ETW.

4:/* Input events to both detectors in parallel.*/

5: if event type is Process Start then

6: Extract command from commandLine and match against rules in $R_{s}$.

7: if command matched to a rule in $R_{s}$ then

8: Raise the alert and halt the process using PID.

9: if event is from File provider then

10: CryptoMatcher = FileIOPatternMatcher(event, $RE_{crypt}$)

11: if CryptoMatcher then

12: Raise the alert and halt the process using PID.

13: IncomingEvents = Accumulate all events in a $W$ seconds window.

14: MLClassifierLabel = ML-basedClassifier(IncomingEvents)

15: if MLClassifierLabel then

16: Raise the alert and halt the process using PID.

17: else Keep on monitoring the system.

Existing malware detection techniques either use built-in tools such as
Logman, TraceRpt, Event Viewer, etc. or third party applications such as
Xperf, PerfView, Microsoft Message Analyser, etc. However, the above mentioned
tools suffer from at least one of the following issues: 1) they fail to parse
events in real time, i.e., events are first logged to disk then parse, 2) they
allow only subset of all telemetry available in Windows OS [21], and 3) high
overhead in terms of CPU and memory. Table III compares existing ETW-based
approaches for event collection with Peeler’s system events monitor in terms
of performance metrics.

TABLE III: Tools and applications using ETW framework.

Metric | Command line tools and applications | ETW APIs | Peeler
---|---|---|---
Visibility | limited | limited | greater
Real-time | $\times$ | ✓ | ✓
Lightweight | ✓ | $\times$ | ✓
Native | $\times$ | $\times$ | ✓
Static support | ✓ | ✓ | ✓

We designed a module called system events monitor based on ETW. Our module is
light-weight because it directly interacts with the native layer and performs
filtering of the system events. In terms of visibility, Peeler extract events
from the following providers: Process, Image, File, Thread. A unified data
model (UDM) containing a set of events is extracted and then consumed to
detect ransomware. The data obtained by Peeler’s system events monitor are in
the form of a continuous sequence of events $t_{i}$. An event is represented
as: $t_{i}=<PID,TID,Prov.,EType,E_{timestamp},E_{attrs}>,$ where PID is a
process identifier, TID is a thread identifier corresponding to the process
$PID$. Prov. is provider name, EType is event name,$E_{timestamp}$ is the time
of event occurrence, and $E_{attrs}$ is a set of attributes of the event
$E_{name}$.

Each event has a schema describing the type of data contained in the event
payload. The overall data schema is listed in Table IV. To implement the
system events monitor in Peeler, we used an open-source project krabsetw [26],
which is a C++ library that simplifies interactions with ETW. We modified
krabsetw both at API and native layer to collect the events only needed for
Peeler.

TABLE IV: Providers and events used in Peeler.

Provider | Event | Event schema
---|---|---
Common attributes | Provider-specific event attributes
Process | Start, End | PID, TID, Prov., Event, Timestamp | SessionId, ParentId
ImageFileName, CommandLine
File | Read, Write | PID, TID, Prov., Event, Timestamp | FileKey, FileObject, IoSize
Rename, Delete | PID, TID, Prov., Event, Timestamp | FileKey, FileObject
FileCreate, FileDelete | PID, TID, Prov., Event, Timestamp | FileObject, FileName
Thread | Start, End | PID, TID, Prov., Event, Timestamp | ParentId
Image | Load, Unload | PID, TID, Prov., Event, Timestamp | ImageSize, FileName

###  III-C Malicious commands detector

Peeler uses a component called _malicious command detecter_ to filter
suspicious activities conducted by ransomware using the database for malicious
commands which are needed to perform ransomware’s activities (see Table I).
Peeler can collect malicious commands from the Process’s Command line argument
(see Table IV). Typically, the commandLine attribute of the Process contains
the actual commands (see example commands in Table XVIII in Appendix -C). For
example, Windows OS utility net.exe can start, stop, pause or restart any
service using the command net.exe stop ServiceName launched via convenient
script/batch file or command prompt. If an adversary leverages such commands
to stop several anti-malware services, Peeler can detect the process using
pre-defined rules. Similarly, utility taskkill.exe ends one or more tasks or
processes. Typically, ransomware specify the image name of the process to be
terminated (e.g., taskkill.exe /IM ImageName). The sc.exe utility modifies the
value of a service’s entries in the registry and service control manager
database. Ransomware may attempt to disable several defending services on the
victim’s machine before starting encryption. Peeler uses rules based on
utility names and actions performed in order to detect ransomware infection.

###  III-D File I/O pattern matcher

To effectively detect suspicious file I/O patterns, Peeler relies on detecting
a sequence of suspicious file I/O events, as discussed in Section II-B.
Algorithm 2 is composed of three main stages for detecting crypto ransomware.
The input to the Algorithm is events from file I/O provider. An event is
specified as event = $<$PID, EType, FileObject, FileName, FileKey$>$ and with
a set of regular expressions, $RE_{crypt}$. PID and EType refer to the process
identifier and event type, respectively. FileObject is a unique key assigned
to every file, whereas FileName contains the name of a file with full path.
FileKey is an identifier that is used to find the file on which an event is
performed. For example, the event schema for Read and Write (see Table IV)
does not contain FileName attribute. In order to obtain the file name, the
FileKey attribute of the Read/Write event is matched with the FileObject
attribute of the FileCreate event.

####  III-D1 Preparing the data

The continuous stream of incoming file I/O events are first processed such
that they are added to a separate list based on the file they are operating
on. Whenever a user’s file is accessed (i.e., FileCreate event is received),
an events list FileEventsList is created and the corresponding event
(FileCreate) with respective attributes is added to that list. All subsequent
file I/O operation events (such as Read, Write, Rename, Delete, FileCreate,
and FileDelete) on that file are added to its FileEventsList (Step 1 – 6 in
Algorithm 9).

However, it is challenging to accurately add all file I/O events corresponding
to a user’s file to its respective FileEventsList. Because a single file may
have multiple FileObject keys and vice versa. For example, as shown in Figure
9, the FileObject keys for Read and Write events on the file D_186.wav are not
the same, but the actual file on which the operations are performed is the
same. To ensure that all events associated with a file are fully recorded,
Peeler leverages both FileObject and FileName attributes to accurately
identify a user’s file.

Algorithm 2 FileIOPatternMatcher.

1:Input:  event = $<$PID, EType, FileObject, FileName, FileKey$>$

2:Output:  Benign and Ransomware

3:

4:Stage 1: Preparing the data

5:if EType is ‘FileCreate’ then

6: if FileObject and FileName are newly observed then

7: Create events list FileEventsList for the newly observed file.

8: Add event to FileEventsList.

9:else add event to respective file’s FileEventsList.

10:

11:Stage 2: File I/O patterns detection

12:if the number of unique ETypes in the FileEventsList is equal or greater
than four then

13: Extract Etypes sequence from FileEventsList.

14: if Etypes sequence matched to at-least one of the file I/O patterns in
Section II-B then

15: Flag the process PID in event.

16: Ransomware = True

17:else continue

18:

19:Stage 3: Filtering false positives.

20:if FilePath are different in FileEventsList’s events then

21: Benign = True

22:if PIDs in FileEventsList’s events are not same then

23: Benign = True

####  III-D2 File I/O pattern matcher

Suspicious file I/O patterns are detected by analyzing the sequence of events
in the list FileEventsList corresponding to a file. If the number of unique
ETypes is equal to or more than four (Step 6 in Algorithm 9), the events in
the list are analyzed for suspicious patterns. Peeler enforces the four unique
events constraint to reduce unnecessary computational overhead because at
least four unique event types are required to encrypt a user file (see Figures
1–10). If the sequence of incoming events in FileEventsList matches with file
I/O patterns in SectionII-B, i.e., file access, read, write (encrypted
content), and file renaming operations are performed in order on a user’s
file, Peeler captures this sequence as the evidence of crypto ransomware
activity for a security warning.

We note that the Memory-to-File operations can be distinguished from the File-
to-File operations by using the FileObject keys. When the same file is
overwritten, we observe that the FileObject key remains the same for all file
I/O events, e.g., the sequence of events to encrypt the file D_186.wav are
shown in Figure 1 for Cerber ransomware. For File-to-File operations, multiple
files associated with FileObject keys are needed. That is, in this case, the
file I/O events from multiple files are accumulated into the same
FileEventsList list.

####  III-D3 Filtering false positives

We observe that some benign applications may generate ransomware-like file I/O
patterns. For example, some benign applications may overwrite Windows OS’s
Activation Tokens file (tokens.dat), which can lead to false positives because
it generates file I/O events that look similar to Memory-to-File patterns. We
applied the following two heuristics to reduce the possibility of such false-
positive cases (see Stage 3 in Algorithm 2):

  * •

If FilePaths in FileEventsList are not directing to the same file, this is
ignored because the file encrypted must be in the same location.

  * •

All the file I/O events must be performed by the same process (i.e., the same
PID) with exception for the system and explorer.exe processes. For example,
event lists in Figures 9 and 10 show that system process (PID = $4$) is
involved. Similarly, explorer.exe is a system process that assists other
processes in performing tasks.

###  III-E Machine learning-based classifier

Peeler uses two different machine learning-based (ML-based) classifiers with
application process tree features, and system event features to detect
ransomware samples that cannot be detected by the file I/O pattern matcher.
Algorithm 3 enlists all the steps for ML-based classifiers. The input to the
algorithm is a set of events accumulated over $W$ seconds window. In our
current implementation, we empirically set $W=5$ to optimize the speed-
accuracy tradeoff. Features are extracted to build two machine learning models
(Step 1–4 in Algorithm 3). The built machine learning models are then used to
detect ransomware attacks (Step 5–7 in Algorithm 3).

Algorithm 3 ML-basedClassifier.

1:Input:  IncomingEvents

2:Output:  Benign and Ransomware

3:

4:Stage 1: Feature sets extraction and model building.

5:$FV_{MLR}$ = extract application process tree features from IncomingEvents
(see Table V).

6:$FV_{SVM}$ = extract system events features from IncomingEvents (see Table
V).

7:M1 = Build ML Multinomial logistic regression model with $FV_{MLR}$ feature
set.

8:M2 = Build ML SVM-RBF model with $FV_{SVM}$ feature set.

9:

10:Stage 2: Attack detection.

11:Extract feature set vectors for test samples.

12:Test $FV_{MLR}$ and $FV_{SVM}$ features on models M1 and M2, respectively.

13:Fuse scores from models and provide the class label (either benign or
ransomware) as output.

####  III-E1 Building the first classifier with the application process tree
features

Windows OS applications are typically descended from the parent process called
explorer.exe. Therefore, all applications’ processes share explorer.exe as
their parent process. As discussed in Section II-C, we observed that several
ransomware samples spawn significantly larger number of child processes
compared to benign applications. Based on this observation, Peeler constructs
a machine learning model using the application process tree features. Peeler
specifically extracts the following features from the application process
tree: the number of processes, the number of unique processes, the number of
threads created by processes, the maximum depth level of the tree, and the
number of leaf nodes in the tree. For the first classifier using the feature
set $FV_{MLR}$ (see Table V), we selected a multinomial logistic regression
(MLR) model because we do not assume linear relationships among the features
in $FV_{MLR}$ [27] and MSR produces the best performance with those features.

####  III-E2 Building the second classifier with the system event features

As discussed in Section II-D, Peeler leverages four providers’ (File, Process,
Image, and Thread) events exhibiting casualties. In total, the following four
pairs of events are used: (Read, Write), (Start, Load), (End, Unload), and
(Start, End). To capture these casualties simply, Peeler extracts frequency
features (see Table V) and train an SVM model based on feature set $FV_{SVM}$
for classification. We selected SVM with RBF kernel because it is lightweight
and produces the best accuracy results with $FV_{SVM}$.

TABLE V: Feature extraction.

Feature set | Feature | Model
---|---|---
$FV_{\text{MLR}}$ | # of processes | MLR
Sum of threads from processes
Maximum depth level of process tree
# of leaf nodes
# of unique process names
$FV_{\text{SVM}}$ | # of process start | SVM-RBF
# of process end
# of DLL image loads
# of DLL image unloads
# of file reads
# of file writes
# of threads start
# of thread end

####  III-E3 Attack detection

Peeler uses two classification models (MLR and SVM-RBF), and finally decides
the classification outcome by fusing their scores. We note that MLR and SVM-
RBF are constructed with different feature sets – MLR is trained with
$FV_{\text{MLR}}$ while SVM-RBF is trained $FV_{\text{SVM}}$ (see Table V).
The scores from the two models are fused by taking their average for
detection.

##  IV Dataset collection

We aimed to collect a ransomware dataset containing diverse ransomware
families rather than similar ransomware variants. Therefore, we collected
ransomware samples from several sources including VirusTotal [28], malware
repository [29], malwares [30], and other online communities. Also, we
collected benign applications exhibiting at least one of the following
behaviors: 1) encryption or compression capabilities, 2) spawning multiple
processes, and 3) most commonly used benign applications (see Appendix -B) to
evaluate Peeler’s robustness against false positives.

###  IV-A Ransomware

We collected 28,034 ransomware samples from VirusTotal [28], MalwareBazaar
[31], malware repository [29], malwares [30], and other online communities.
However, we excluded many malware samples from our final dataset for
experiments. First, we found that many samples were not actual ransomware
samples, although they were classified as ransomware by some vendors in
VirusTotal. Therefore we discarded such samples. This finding is consistent
with the observation in the previous work [15]. Second, ransomware often needs
to interact with command-and-control (C&C) servers to perform their malicious
activities. However, several ransomware samples did not often work
appropriately because their corresponding C&C servers were taken-down. Also,
some sophisticated malware samples can detect the analysis environment and
remain inactive to evade detection [32]. More importantly, samples from a few
ransomware families we observed were significantly larger compared to other
families. For example, we found more than 20,000 ransomware samples from
Virlock family including Virlock Gen.1, VirLock Gen.4, and VirLock Gen.8
variants. Therefore, we kept limited samples from Virlock family and discarded
other samples. Finally, We collected 292 active samples from 67 ransomware
families that perform their activities correctly. We used 206 ransomware
samples from 43 ransomware families (see Table VI) in the first set of
experiments. Out of 43 families, 34 (102 samples) were from crypto, and 9 (104
samples) were from screen-locker types of ransomware. The remaining 24
ransomware families with 86 samples were collected at later stage of data
collection and used to evaluate Peeler on new and unseen ransomware samples.

TABLE VI: Ransomware families, types, and samples.

no. | Family | Type | Samples | no. | Family | Type | Samples
---|---|---|---|---|---|---|---
1 | Cerber | Crypto | 33 | 23 | Petya | Crypto | 1
2 | Sodinokibi | Crypto | 14 | 24 | Satana | Crypto | 1
3 | GoldenEye | Crypto | 12 | 25 | Shade | Crypto | 1
4 | Sage | Crypto | 5 | 26 | Syrk | Crypto | 1
5 | Locky | Crypto | 5 | 27 | TeslaCrypt | Crypto | 1
6 | Dharma | Crypto | 3 | 28 | ucyLocker | Crypto | 1
7 | dotExe | Crypto | 3 | 29 | Unlock92 | Crypto | 1
8 | Troldesh | Crypto | 1 | 30 | Vipasana | Crypto | 1
9 | WannaCry | Crypto | 3 | 31 | Xorist | Crypto | 2
10 | Da Vinci Code | Crypto | 1 | 32 | Malevich | Crypto | 1
11 | CryptoShield | Crypto | 1 | 33 | Jigsaw | Crypto | 1
12 | CryptoWire | Crypto | 1 | 34 | Adobe | Crypto | 1
13 | District | Crypto | 1 | 35 | Virlock.Gen.5 | Screen | 83
14 | Gandcrab | Crypto | 1 | 36 | LockScreen.AGU | Screen | 12
15 | GlobeImposter | Crypto | 1 | 37 | Alphabet | Screen | 2
16 | Hexadecimal | Crypto | 1 | 38 | EgyptianGhosts | Screen | 1
17 | InfinityCrypt | Crypto | 1 | 39 | Lockey-Pay | Screen | 1
18 | IS (Ordinpt) | Crypto | 1 | 40 | Blue-Howl | Screen | 1
19 | Keypass | Crypto | 1 | 41 | ShellLocker | Screen | 1
20 | Lockcrypt | Crypto | 1 | 42 | DerialLock | Screen | 1
21 | Pack14 | Crypto | 1 | 43 | Trojan.Ransom | Screen | 1
22 | PocrimCrypt | Crypto | 1 | -
Total samples: 206, crypto = 102, screen-locker = 104

####  IV-A1 User environment and ground truth (labeled) dataset

We used VirtualBox 6.1 [33] to create and manage the computing environment
locally for experiments. Rather than using artificially generated data, we
used a real user’s data running on the Windows 10 64Bit operating system (a
copied version of real user data) to set up a benign user’s environment
realistically. Multimedia files (e.g., bmp, jpeg, png, and mp4), Microsoft
office documents (e.g., docx, xlsx and pptx files), and other important files
(e.g., cpp, py, pdf and wav files) were copied to various directories in
different locations. We note that those files are typically most attractive
targets for ransomware.

Each ransomware sample was executed and then manually labeled by each family
type. We ran each ransomware sample for ten minutes or until all user files
were encrypted. It took more than 90 days to run all samples and collect data.
We only considered those samples that encrypted user files or locked desktop
screens. If no files were modified, we excluded them from our dataset. We also
obtained labeled ransomware samples from two well-known malware repositories
[31, 29]. Many ransomware families use their respective names as file
extensions after encrypting a user file, e.g., WannaCry adds .wncry file
extension after encrypting a user file, similarly, Ranzy, Ryuk, and Peta add
.rnz, .ryuk, and .peta file extensions, respectively. Moreover, we manually
verified label ransomware family from VirusTotal’s vendors, i.e., if more than
15 vendors assign the same label to a sample, we label it accordingly.

####  IV-A2 Diversity in our dataset

Table VI presents a list of ransomware families that are used in our
evaluation. To the best of our knowledge, this is the most comprehensive
dataset containing diverse ransomware families. According to previous work
[34, 15], the use of diverse families is more important than the number of
ransomware samples from a few families for evaluating the performance of
ransomware detectors. For instance, building a model on 1,000 Locky (and its
variants) ransomware samples should prove no more useful than building a model
on just one Locky sample [34]. Scaife et al. [15] confirmed that due to the
homogeneous nature of file I/O behavior among samples within each family, a
small number of representative samples in each family are sufficient to
evaluate the detection performance. It is because the core behavioral traits
shown by crypto ransomware in encrypting data attack does not change from one
variant to the other within a family. Since our study covered more than eight
times the number of families from previous study [35], and more than two times
the number of families covered in studies [14, 15] and there was not much
diversity within families, there was little need to collect additional
samples.

###  IV-B Benign applications

We also collected the dataset for popularly used applications that are
typically installed on a benign user’s computer. In addition to popularly used
applications, we also considered several benign applications that could
resemble ransomware in certain behavioral aspects. The reason is to
investigate false positive rates when benign applications potentially resemble
ransomware. We divide the benign dataset into three main categories targeting
various types of ransomware: 1) benign applications with file I/O patterns
resembling crypto ransomware, 2) benign applications spawning many processes,
and 3) commonly used benign applications.

####  IV-B1 Benign applications resembling crypto ransomware

Benign applications performing encryption or compression might generate file
I/O patterns similar to crypto ransomware that could result in false
positives. To evaluate Peeler against, we collected data from several crypto-
like benign applications, listed in Appendix -B. There are key differences in
file I/O patterns generated by encryption/compression tools compared to
crypto-ransomware. Firstly, unlike ransomware incurring a massive number of
repeated file I/O patterns, the encryption/compression tools operate on a
limited number of files only. Secondly, the original user files remain intact,
i.e., not overwritten or deleted, even after compression or encryption is
performed. It is, therefore, doubtful that benign applications show ransomware
file I/O patterns. Thirdly, unlike crypto ransomware that encrypts user files
arbitrarily, benign applications create a dedicated process that needs
sophisticated inputs from the OS to complete the task. For instance, the
compression tool 7-zip takes several parameters to specify target files. Each
tool in Appendix -B is run twice – for compression and decompression, on a
given set of files to collect data.

####  IV-B2 Benign applications spawning many processes

We collected the dataset containing applications that spawn many child
processes to evaluate Peeler’s robustness against false positives. We found
that certain benign applications such as Pycharm and Visual Studio create many
spawned processes that may resemble screen-locker ransomware. The list of
benign applications is shown in Appendix -B. We collected data by running each
application individually.

####  IV-B3 Commonly used benign application

We also collected user’s system usage data under normal conditions while
interacting with commonly used applications. A user runs many different
applications at the same time. For example, the user read a document using
Adobe Acrobat Reader, switched to the internet browser to view online reviews
about a product, and then used Adobe Acrobat Reader again. Our goal here is to
analyze system events generated in an interleaved manner from commonly used
benign applications. The collected data is for around 12 hours of computer
usage. During data collection, the user interacted with multiple applications
from the list of benign applications in Appendix -B.

##  V Evaluation

We demonstrate Peeler’s performance in detection accuracy, detection time, and
CPU/memory overheads. For evaluation, we used the dataset described in Section
IV. For training, 20% of both screen-locker ransomware and benign applications
randomly are selected. We used a small training dataset (only 20% of the
entire dataset) for the following reasons: 1) the size of a training set is
typically limited in the real world; 2) we want to increase the number of
testing samples as many as possible for making Peeler robust against unseen
ransomware samples; 3) we want to reduce the size of model for quick training.
All the remaining ransomware and benign samples (i.e., 80% of the total
samples) are used for testing purposes.

###  V-A Detection accuracy

Table VII shows the summary of Peeler’s detection accuracy. Overall, Peeler
achieved 99.52% accuracy with a false positive rate of only 0.58%. Since we
used only 20% of applications selected randomly for training, all performance
statistics are averaged after 100 runs to mitigate biases in training and
testing datasets. Similarly, Peeler achieved high precision and F1 score,
which are greater than 99%.

TABLE VII: Peeler’s detection accuracy.

Acc. (%) | TPR (%) | FPR (%) | FNR (%) | Prec. (%) | Rec. (%) | F1 (%)
---|---|---|---|---|---|---
99.52 | 99.63 | 0.58 | 0.37 | 99.41 | 99.63 | 99.52

####  V-A1 False positive analysis

Minimizing false positives is essential to develop practically useful malware
detectors because excessive false positives can annoy users and undermine the
system’s effectiveness. We evaluate Peeler’s performance against three
different types of benign application scenarios (see Table VIII):

TABLE VIII: Peeler’s false positive analysis.

Scenario | TNR (%) | FPR (%) | FNR (%)
---|---|---|---
Crypto-like benign apps | 98.27 | 1.72 | 0.96
Locker-like benign apps | 99.5 | 0.31 | 0.5
Commonly used benign apps | 99.78 | 0.21 | 0.87
All ransomware | 99.42 | 0.58 | 0.37

Crypto ransomware-like benign applications. For behavior-based crypto
ransomware detection solutions, a significant challenge is not to detect
benign applications having compression or encryption capabilities because
their system behaviors might be similar to crypto ransomware.

We deeply investigated 11 different applications using compression or
encryption operations on a large number of files like crypto ransomware (see
Appendix -B). We observed that event sequences of some benign applications
such as ZipExtractor and BreeZip are quite similar to those of typical crypto
ransomware, but they do not restrict access to files via encryption, unlike
crypto ransomware.

Table VIII shows that Peeler correctly detects 98.27% with a false positive
rate of 1.72% even against crypto ransomware-like benign applications.

Benign applications spawning many processes. Certain ransomware spawns many
child processes. Therefore, we examine how Peeler’s performance can be
degraded with benign apps having such behaviors. For this analysis, we
investigated 34 most popular applications from Microsoft’s Windows OS Store
(https://www.microsoft.com/en-us/store/apps/windows) (see Appendix -B) and
selected 18 applications showing such behaviors. Table IX presents the
applications’ process tree-related feature ($FV_{MLR}$) values of three
representative benign applications showing such behaviors. We observe that
Pycharm and Visual Studio spawned 140 and 46 child processes, respectively.
Interestingly, Chrome spawns 42 processes, but the depth of its applications’
tree is one, and the number of threads created by these processes is 1,480. We
examined the results of Peeler with those 18 applications.

TABLE IX: Benign applications’ process tree features.

Application | # processes | Depth | # leaf nodes | # unique processes | # threads
---|---|---|---|---|---
Pycharm | 140 | 4 | 70 | 11 | 993
Visual Studio | 46 | 4 | 29 | 21 | 568
Chrome | 42 | 1 | 41 | 2 | 1,480

Table VIII shows that Peeler correctly detected 99.5% with a false positive
rate of 0.31% even though these benign applications spawned many processes.
The reason for this detection is because Peeler also considers the other set
of features ($FV_{SVM}$), which are related to system events.

Commonly used benign applications. We also evaluated Peeler’s performance with
commonly used benign applications such as Microsoft Office, Adobe Acrobat
Reader, email client, and instant messengers, as presented in Sectoin IV-B.

We show that Peeler correctly detects all benign activities performed by a
user achieving a detection rate of 99.78%. The false positive and true
negative rates under normal system usage are 0.21% and 0.87%, respectively.
Note that the overall detection accuracy in all three scenarios is above 99%.

####  V-A2 False negative analysis

The false negative rate for ransomware detection is another important metric
to evaluate the effectiveness of Peeler. Table X shows that the overall false
negative rate is above 0.37%. The false negative rates for crypto and screen-
locker ransomware are 0% and 0.5%, respectively.

TABLE X: Peeler’s false negative rate analysis.

Ransomware | TPR (%) | FPR (%) | FNR (%)
---|---|---|---
Crypto | 100 | 0.8 | 0
Screen-locker | 99.50 | 0.31 | 0.50
All ransomware | 99.63 | 0.58 | 0.37

###  V-B Detection time

For crypto ransomware, the detection time refers to the time interval between
the end of the detection and the end of encryption on a file by a process,
that is, how long it takes Peeler to detect the ransomware attack after a
ransom sample encrypts a file. We excluded the time to be taken for the file
encryption because that time can be varied depending on the file size.

Figure 7 shows that Peeler can detect over 70% of samples within 115
milliseconds with the mean time of 115.3 milliseconds, demonstrating that
Peeler outperforms existing crypto ransomware detection solutions in detection
time. Peeler can promptly detect crypto ransomware with a simple, file I/O
pattern matching, unlike other existing solutions relying on complicated file
activity (e.g., identifying encryption operations based on entropy
computation) analysis or machine learning models.

These detection time results demonstrate the superiority of Peeler compared
with existing crypto ransomware detection solutions. Cryptolock [15] detects
crypto ransomware after 10 files are encrypted. Similarly, Mehnaz et al. [10]
presented a solution which takes on average 8.87 seconds to detect malicious
processes.

Figure 7: CDF of the crypto ransomware detection time.

For screen-locker ransomware, the detection time refers to the time interval
between the end of the detection and the start activity by a ransomware
process. Peeler, on average, took 16.4 seconds to detect screen-locker
ransomware while the execution time of screen-locker ransomware to lock user’s
desktop screen completely is 302.8 seconds on average, demonstrating that
Peeler can detect screen-locker ransomware at a very early stage that prevents
an attacker from locking a victim’s system. Figure 8 shows the probability
density function of screen-locker detection time. Moreover, the detection time
is not affected even if ransomware is running in parallel to many other
irrelevant system applications because Peeler’s system events monitor directly
intercept the events and then analyse them.

Figure 8: Probability density function of detection times for screen-locker
ransomware with mean ($\mu$) and standard deviation ($\sigma$).

###  V-C Robustness against unseen families

To test Peeler against unseen ransomware families, we additionally collected
new and unseen ransomware samples after three months from the first
experiments and monitored online repositories for new or unseen ransomware
samples. A total of 70 samples from more than 24 distinct unseen or new
ransomware families are tested. We used the previously constructed Peeler
without retraining. All samples tested in this experiment are manually
verified from VirusTotal and other online malware repositories to confirm
their family and type.

Peeler was able to correctly detect 67 samples from total 70 new and unseen
ransomware samples achieving more than 95% detection rate. The ransomware
families and the number of corresponding samples tested are given in Table XI.

Peeler can also detect 9 out of 16 conventional malware samples even though
those samples do not have ransomware capabilities. For example, our
investigation revealed that Backdoor.Generic is a malware family that enables
attackers to control infected computers remotely to create large groups of
zombie computers (botnets), which are then used for malicious purposes without
the user’s knowledge. We surmise that those malware samples have some common
behaviors that can be observed from ransomware.

TABLE XI: Detection of unseen ransomware and malware.

Type/ Detection | Family | Sample | Family | Sample
---|---|---|---|---
Ransomware 95.7% (67/70) | Ryuk | 6 | Zeppelin | 6
Ranzy | 4 | Netwalker | 2
Core | 3 | Fox | 3
Crpren | 1 | MedusaLocker | 1
Balaclava | 5 | Crylock | 7
Matrix | 4 | DarkSide | 4
Ragnarlocker | 2 | HiddenTear | 2
Mespinoza | 5 | Thanos | 3
Vaggen | 3 | Mountlocker | 2
Nemty | 2 | Phobos | 1
Jsworm | 1 | Winlock | 1
Maze | 1 | Unknown | 1
Malware 56.2% (9/16) | Backdoor.Generic | 2 | Unknown | 14

###  V-D Model-specific detection accuracy.

We constructed Peeler by building multiple detection components (file I/O
pattern matcher and machine learning-based classifier). Here we show the
effectiveness of each component in detecting ransomware. Table XII and XIII
show the evaluation results of both components, respectively.

TABLE XII: File I/O pattern matcher’s performance.

Ransomware | TPR (%) | FPR (%) | FNR (%) | Prec. (%) | Rec. (%) | F1 score (%)
---|---|---|---|---|---|---
Crypto | 95.19 | 0 | 4.81 | 100 | 95.19 | 97.53
Screen-locker | 33.33 | 0 | 66.66 | 100 | 33.33 | 50.00
All ransomware | 65.50 | 0 | 34.5 | 100 | 65.50 | 79.15

Table XII shows that the file I/O pattern matcher achieves the detection rate
of 95.19% with the false rate of 0% in detecting crypto ransomware; however,
it is not effective in detecting screen-locker ransomware.

Table XIII shows that the machine learning-based classifier works well in
detecting both crypto and screen-locker ransomware. The machine learning-based
classifier achieves more than 98% detection accuracy with less than 2% false
rate in detecting both types of ransomware attacks. The high detection rate of
the machine learning-based classifier can be attributed to the feature vectors
($FV_{\text{MLR}}$ and $FV_{\text{SVM}}$). However, to boost the detection
time, we can first apply the file I/O pattern matcher and then use the machine
learning-based classifier only when the file I/O pattern matcher fails to
detect.

TABLE XIII: Machine learning-based classifier’s performance.

Ransomware | TPR (%) | FPR (%) | FNR (%) | Prec. (%) | Rec. (%) | F1 score (%)
---|---|---|---|---|---|---
Crypto | 98.45 | 1.84 | 1.54 | 98.24 | 98.45 | 98.29
Screen-locker | 99.5 | 0.31 | 0.50 | 99.68 | 99.50 | 99.59
All ransomware | 99.05 | 1.9 | 0.94 | 98.19 | 99.05 | 98.59

Each component can work as an alternative and complementary detection method
to the other component. For instance, the file I/O pattern matcher failed to
detect some crypto ransomware samples such as Hexadecimal, Cryptowire,
CryptoShield, and CryptoLock, but the machine learning-based classifier
successfully detected them.

###  V-E CPU and memory overheads

We evaluate the performance of Peeler with respect to CPU and memory
overheads. Since Peeler intercepts low-level kernel events and then analyzes
them to detect ransomware attacks, its performance overheads in CPU and memory
can typically be changed depending on the system’s workload. For instance, we
observe that if computationally intensive tasks are running, the overheads of
Peeler inherently increase because Peeler should frequently intercept a high
number of kernel events generated from such computationally intensive
processes.

TABLE XIV: CPU and memory overheads of Peeler.

Workload | CPU (%) | Memory (MB)
---|---|---
Mean | Std. | Mean | Std.
Low | 2.7 | 2.0 | 9.8 | 0.3
Normal | 4.9 | 2.2 | 9.8 | 0.4
High | 15.8 | 3.9 | 11.3 | 1.9

Our experiments were conducted on a computing device equipped with two Intel
Core(TM) i5-7300U (2.60GHz) CPUs and 8GB RAM, running 64-bit Windows 10
Enterprise edition operating system. Our CPU and memory usage results were
measured based on this environment. We considered the three workload
conditions as follows: Low, Normal, and High workload conditions. Under the
low workload condition, Peeler is only running in the background and
continuously collecting system events and writing them to a log file. Under
the normal workload condition, we additionally performed the following tasks:
1) drafting an MS Word document; 2) using Chrome for browsing online material;
and 3) reading a document using Adobe Acrobat Reader. Under the high workload
condition, we additionally ran a CPU intensive algorithm as a background
process. We note that an anti-malware program called CylanceProtect and
default Windows OS services were continuously running in the background for
all workload conditions.

Table XIV shows CPU and memory usage of Peeler. We observe that mean CPU usage
and the standard deviation are 4.9% and 2.2%, respectively, under the normal
workload condition.

Table XIV also shows that mean memory usage is around 9.8MB under the low or
normal workload conditions, which is quite stable and has less variation
(standard deviation is 0.4MB). Under the high workload condition, the average
CPU usage of Peeler significantly increases to 15.8% with a standard deviation
of 3.9% while its average memory usage slightly increases to 11.3MB memory
with a standard deviation of 1.9MB.

##  VI Discussion and limitations

###  VI-A Comparison with existing solutions

As mentioned in Section I, there are many existing methods to detect
ransomware attacks. However, since most existing solutions used their own
dataset for evaluation, and their source code is not opened, we do not
directly compare Peeler with those solutions. Alternatively, we compare Peeler
with those solutions according to their experimental results reported in their
papers. Table XV shows a summary of the comparison results.

TABLE XV: Comparison with existing approaches.

Method | TPR (%) | FPR (%) | Files lost | Screen-locker? | Samples/families | Real-time
---|---|---|---|---|---|---
Redemption [6] | 100 | 0.8 | 5 | $\times$ | 677/29 | $\times$
CryptoLock [15] | 100 | 0.03 | 10 | $\times$ | 492/14 | $\times$
UNVEIL [14] | 96.3 | 0 | - | $\checkmark$ | 2121/ - | $\times$
REDFISH [13] | 100 | - | 10 | $\times$ | 54/19 | $\times$
RWGuard [10] | - | 0.1 | partial recovery | $\times$ | \- /14 | $\checkmark$
Elderan [9] | 93.3 | 1.6 | - | $\times$ | 582/11 | $\times$
CM&CB [36] | 98 | Vary | - | $\times$ | 8/ - | $\times$
RansHunt [37] | 97 | 3 | - | $\times$ | 360/20 | $\times$
ShieldFS [7] | 100 | 0.038 | - | $\times$ | 383/11 | $\times$
Peeler | 99.63 | 0.58 | 1 | $\checkmark$ | 206/43 | $\checkmark$

We can see that the ransomware detection rates overall ranges from 93% to
100%. However, it is important to note that the number of ransomware
samples/families used for evaluation is different for each approach.
CryptoLock [15], Redemption [6], REDFISH [13], and ShieldFS [7] achieved 100%
detection rates, but those solutions were tested on 14, 29, 19, and 11
ransomware families only, respectively. In contrast, Peeler was tested against
43 distinct ransomware families, including both crypto and screen locker
ransomware, and still achieved a 99.63% detection rate. For the false positive
rate with benign applications, Peeler achieved 0.58% FPR, which would be
comparable with the other solutions. For ransomware detection, one of the most
critical evaluation metrics is the number of user files lost before a
ransomware sample is detected. Peeler detects ransomware immediately after a
single file alone is encrypted, indicating that Peeler outperforms other
solutions.From Table XV, we can see that only two solutions (Peeler and UNVEIL
[14]) considered the detection of screen-locker ransomware. However, Peeler’s
detection time (16.4 seconds on average) would significantly be faster than
UNVEIL. Although Kharaz et al. [14] did not report the exact detection time of
UNVEIL, we surmise that UNVEIL would take longer detection time because it
needs to capture screenshots of a victim’s desktop periodically, and then
compute the similarity between the captured images.

###  VI-B Secure implementation of Peeler

Peeler runs in a privileged kernel mode with administrative rights because it
needs to collect kernel-level events from four main kernel providers (File,
Process, Image, and Thread). Therefore, the integrity of Peeler can be
securely protected against malicious processes running in the user mode.
However, if we consider powerful attackers (e.g., rootkit-based ransomware)
with the root privilege, we additionally need to consider deploying a kernel
protection mechanism to protect Peeler against attackers. Recently, several
techniques (e.g., real-time kernel protection (RKP) [38]) have been proposed
to protect the kernel code and objects from unauthorized modifications. With
such a secure kernel protection mechanism, we can implement Peeler as a
Windows OS service running on the kernel.

###  VI-C Peeler’s extension to other computing environments

In order to extend Peeler to other computing environments such as Linux or
Android, two aspects are needed to be considered: platform-depended system
events and key ransomware behavioral characteristics. The later remains
platform-independent because the key behavioral characteristics of ransomware
remain almost the same no matter which platform they target. However, system
events for other computing environments need to be carefully analyzed to
extend Peeler to these environments. For instance, the suspicious file I/O
patterns and corresponding regular expressions should be updated to reflect
platform-dependent system events.

###  VI-D Limitations

In our experiments, the tested benign applications are only a part of a
massive number of benign applications. Therefore, we can still have a chance
to encounter (unknown) benign applications that generate suspicious file I/O
patterns that might result in false positives. For instance, when Windows OS
creates a backup file tokens.dat.bak from the file of tokens.dat, we found
that the sequence of kernel-level file I/O events generated from a benign
process can lead to a false positive result from the file I/O pattern matcher.

A sophisticated malware could memory map a user file and then copy the block
of memory, using memcpy() to evade file I/O patterns. The Windows OS may not
observe any write operation in such scenario, and therefore, Peeler may not
detect such attacks.

##  VII Related work

We categorize the literature regarding ransomware detection into three groups:
1) crypto ransomware detection techniques that are mainly based on certain
behavioral indicators (e.g., file I/O event patterns), 2) machine learning-
based approaches that build models by leveraging system behavior feature, and
3) decoy-based approaches that deploy decoy files and monitor if ransomware
samples to tamper with the decoy files.

Crypto ransomware detection. There were several proposals to monitor file I/O
request patterns of applications to detect crypto ransomware. Kharraz et al.
[14] studied crypto ransomware families’ file I/O request patterns and
presented a dynamic analysis-based ransomware detection system called UNVEIL.
UNVEIL detected 13,647 ransomware samples from a dataset of 148,223 general
malware samples. Kharraz et al. [6] proposed another ransomware detection
system using file I/O patterns, achieving a 100% detection rate with 0.8%
false positive on 677 samples from 29 ransomware families. Scaife et al. [15]
also presented a system called CryptoDrop that detect ransomware based on
suspicious file activities, e.g., tampering with a large number of file
accesses within a time interval. According to the experimental results, the
number of lost files is ten on average. Moratto et al. [13] proposed a
ransomware detection algorithm with a copy of the network traffic, without
impacting a user’s activities. Their proposed system achieved a 100% detection
rate with 19 different ransomware families after the loss of ten files.

Machine learning based ransomware detection. RWGuard [10] is a machine
learning-based crypto ransomware detection system. It achieved a 0.1% false
positive rate incurring a 1.9% CPU overhead with 14 crypto ransomware
families. RWGuard leverages the features about processes’ I/O requests and
changes performed on files because RWGuard was mainly designed to detect
crypto ransomware only. Sgandurra et al. [9] proposed EldeRan, another machine
learning approach that builds a model using system activities such as API
invocations, registry event, and file operations that are performed by
applications. EldeRan achieved a 93.3% detection rate with a 1.6% false alarm
rate with 582 samples from 11 ransomware families. Hirano et al. [39] and Al-
rimy [19] proposed behavior-based machine learning models for ransomware
detection. Hirano et al. selected five-dimensional features that were
extracted both from ransomware and benign applications’ I/O log files.
Nieuwenhuizen [34] proposed another behavioral-based machine learning model
using a feature set that quantifies the behavioral traits for ransomware’s
malicious activities.

Decoy files based ransomware detection. Decoy techniques [10, 11, 7] have also
been frequently proposed to detect ransomware attacks. For example, Gomez et
al. [11] developed a tool called R-Locker using honey files to trap the
ransomware. When file operations are performed on honey files by a process,
the process is detected and completely blocked because benign processes do not
perform any file operations on honey files. However, if decoy files are
generated, which look different from real user files, sophisticated ransomware
samples ignore decoy files [10]. Moreover, it is also unclear how those
solutions would detect some ransomware families (e.g., Petya) that affect
predefined system files only.

##  VIII Conclusion

We propose a new effective and efficient solution called Peeler to detect
ransomware attacks using their system behaviors. Peeler is built on both rule-
based detection (e.g., malicious commands detector and I/O pattern matcher)
and machine learning models to improve the detection accuracy and reduce the
detection time. Most crypto ransomware can be detected by the I/O pattern
matcher efficiently; the crypto ransomware that cannot be detected by the I/O
pattern matcher or screen-locker ransomware can be detected by the machine
learning models more accurately.

To show the effectiveness of Peeler, we evaluate its performance with 43
ransomware families containing crypto ransomware and screen-locker ransomware.
In the experiments, Peeler achieved 99.52% accuracy with a false positive rate
of only 0.58%. Moreover, Peeler is efficient in detecting crypto ransomware –
over 70% of crypto ransomware samples can be detected within 115 milliseconds.
Although Peeler’s detection time (16.4 seconds on average) is relatively
slower for screen-locker ransomware, it is still sufficient to detect it
because it typically takes a longer time (302.8 seconds on average) to lock a
victim’s system entirely.

## References

  * [1] First Three Quarters of 2019: 7.2 Billion Malware Attacks, 151.9 Million Ransomware Attacks.  https://www.securitymagazine.com/articles/91133-first-three-quarters-of-2019-72-billion-malware-attacks-1519-million-ransomware-attacks.
  * [2] B. A. S. Al-rimy, M. A. Maarof, and S. Z. M. Shaid, “Ransomware threat success factors, taxonomy, and countermeasures: A survey and research directions,” Computers & Security, vol. 74, pp. 144–166, 2018.
  * [3] N. Popper, Ransomware Attacks Grow, Crippling Cities and Businesses.  https://www.nytimes.com/2020/02/09/technology/ransomware-attacks.html.
  * [4] The State of Ransomware in the US.  https://blog.emsisoft.com/en/34822/the-state-of-ransomware-in-the-us-report-and-statistics-2019/.
  * [5] S. Sivakorn, K. Jee, Y. Sun, L. Kort-Parn, Z. Li, C. Lumezanu, Z. Wu, L.-A. Tang, and D. Li, “Countering malicious processes with process-dns association.,” in Network and Distributed Systems Security, 2019.
  * [6] A. Kharraz and E. Kirda, “Redemption: Real-time protection against ransomware at end-hosts,” in International Symposium on Research in Attacks, Intrusions, and Defenses, pp. 98–119, 2017.
  * [7] A. Continella, A. Guagnelli, G. Zingaro, G. De Pasquale, A. Barenghi, S. Zanero, and F. Maggi, “Shieldfs: a self-healing, ransomware-aware filesystem,” in Proceedings of the 32nd Annual Conference on Computer Security Applications, pp. 336–347, 2016.
  * [8] S. Homayoun, A. Dehghantanha, M. Ahmadzadeh, S. Hashemi, and R. Khayami, “Know abnormal, find evil: frequent pattern mining for ransomware threat hunting and intelligence,” IEEE transactions on emerging topics in computing, 2017\.
  * [9] D. Sgandurra, L. Muñoz-González, R. Mohsen, and E. C. Lupu, “Automated dynamic analysis of ransomware: Benefits, limitations and use for detection,” arXiv preprint arXiv:1609.03020, 2016.
  * [10] S. Mehnaz, A. Mudgerikar, and E. Bertino, “RWGuard: A real-time detection system against cryptographic ransomware,” in International Symposium on Research in Attacks, Intrusions, and Defenses, pp. 114–136, 2018.
  * [11] J. Gómez-Hernández, L. Álvarez-González, and P. García-Teodoro, “R-Locker: Thwarting ransomware action through a honeyfile-based approach,” Computers & Security, vol. 73, pp. 389–398, 2018.
  * [12] E. Kolodenker, W. Koch, G. Stringhini, and M. Egele, “Paybreak: Defense against cryptographic ransomware,” in Proceedings ACM on Asia Conference on Computer and Communications Security, pp. 599–611, 2017.
  * [13] D. Morato, E. Berrueta, E. Magaña, and M. Izal, “Ransomware early detection by the analysis of file sharing traffic,” Journal of Network and Computer Applications, vol. 124, pp. 14–32, 2018.
  * [14] A. Kharaz, S. Arshad, C. Mulliner, W. Robertson, and E. Kirda, “UNVEIL: A large-scale, automated approach to detecting ransomware,” in 25th USENIX Security Symposium (USENIX Security 16), pp. 757–772, 2016.
  * [15] N. Scaife, H. Carter, P. Traynor, and K. R. Butler, “Cryptolock (and drop it): stopping ransomware attacks on user data,” in 36th IEEE International Conference on Distributed Computing Systems (ICDCS), pp. 303–312, 2016.
  * [16] J. Huang, J. Xu, X. Xing, P. Liu, and M. K. Qureshi, “Flashguard: Leveraging intrinsic flash properties to defend against encryption ransomware,” in Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 2231–2244, 2017.
  * [17] S. M. Milajerdi, B. Eshete, R. Gjomemo, and V. Venkatakrishnan, “Poirot: Aligning attack behavior with kernel audit records for cyber threat hunting,” in Proceedings of ACM SIGSAC Conference on Computer and Communications Security, pp. 1795–1812, 2019.
  * [18] L. Zhao and M. Mannan, “TEE-aided write protection against privileged data tampering,” arXiv preprint arXiv:1905.10723, 2019.
  * [19] B. A. S. Al-rimy, M. A. Maarof, and S. Z. M. Shaid, “A 0-day aware crypto-ransomware early behavioral detection framework,” in International Conference of Reliable Information and Communication Technology, pp. 758–766, 2017.
  * [20] B. Lelonek and N. Rogers, Make ETW greate again.  https://ruxcon.org.au/assets/2016/slides/ETW_16_RUXCON_NJR_no_notes.pdf.
  * [21] R. Rodriguez, Threat Hunting with ETW events and HELK — Part 1: Installing SilkETW, 2019.  https://medium.com/threat-hunters-forge/threat-hunting-with-etw-events-and-helk-part-1-installing-silketw-6eb74815e4a0.
  * [22] D. Hendler, S. Kels, and A. Rubin, “Detecting malicious powershell commands using deep neural networks,” in Proceedings of the 2018 on Asia Conference on Computer and Communications Security, pp. 187–197, 2018.
  * [23] D. Hendler, S. Kels, and A. Rubin, “Amsi-based detection of malicious powershell code using contextual embeddings,” in Proceedings of the 15th ACM Asia Conference on Computer and Communications Security, pp. 679–693, 2020.
  * [24] Chronicle, “Yara-l: A new detection language for modern threats [white paper],” in https://go.chronicle.security/hubfs/YARA-L%20Overview%20White%20Paper.pdf, pp. 1–9, 2020.
  * [25] About Event Tracing.  https://docs.microsoft.com/en-us/windows/win32/etw/about-event-tracing.
  * [26] Krabsetw.  https://github.com/microsoft/krabsetw.
  * [27] A. Bayaga, “Multinomial logistic regression: Usage and application in risk analysis.,” Journal of applied quantitative methods, vol. 5, no. 2, 2010\.
  * [28] VirusTotal.  https://www.virustotal.com/.
  * [29] A Live Malware Repository.  https://github.com/ytisf/theZoo.
  * [30] Malware samples.  https://github.com/fabrimagic72/malware-samples.
  * [31] MalwareBazaar.  https://bazaar.abuse.ch/.
  * [32] N. Miramirkhani, M. P. Appini, N. Nikiforakis, and M. Polychronakis, “Spotless sandboxes: Evading malware analysis systems using wear-and-tear artifacts,” in IEEE Symposium on Security and Privacy (SP), pp. 1009–1024, 2017.
  * [33] VirtualBox.  https://www.virtualbox.org.
  * [34] D. Nieuwenhuizen, “A behavioural-based approach to ransomware detection,” Whitepaper. MWR Labs Whitepaper, 2017.
  * [35] A. Kharraz, W. Robertson, D. Balzarotti, L. Bilge, and E. Kirda, “Cutting the gordian knot: A look under the hood of ransomware attacks,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pp. 3–24, 2015.
  * [36] M. M. Ahmadian, H. R. Shahriari, and S. M. Ghaffarian, “Connection-monitor & connection-breaker: A novel approach for prevention and detection of high survivable ransomwares,” in IEEE International Iranian Society of Cryptology Conference on Information Security and Cryptology (ISCISC), pp. 79–84, 2015.
  * [37] M. M. Hasan and M. M. Rahman, “RansHunt: A support vector machines based ransomware analysis framework with integrated feature set,” in 20th IEEE International Conference of Computer and Information Technology (ICCIT), pp. 1–7, 2017.
  * [38] A. M. Azab, P. Ning, J. Shah, Q. Chen, R. Bhutkar, G. Ganesh, J. Ma, and W. Shen, “Hypervision across worlds: Real-time kernel protection from the arm trustzone secure world,” in Proceedings of ACM SIGSAC Conference on Computer and Communications Security, pp. 90–102, 2014.
  * [39] M. Hirano and R. Kobayashi, “Machine learning based ransomware detection using storage access patterns obtained from live-forensic hypervisor,” in Sixth IEEE International Conference on Internet of Things: Systems, Management and Security (IOTSMS), pp. 1–6, 2019.

###  -A File encryption patterns

Figure 9: File I/O events generated by InfinityCrypt ransomware. Figure 10:
File I/O events generated by Wannacry ransomware.

###  -B Benign applications

In this section, we present benign applications that potentially show
ransomware-like behavior that are used in evaluation of Peeler: 1) benign
encryption, compression and shredder applications (Table XVI), 2) benign
applications most commonly used, and 3) benign application spawning multiple
processes (Table XVII).

TABLE XVI: Ransomware-like benign applications.

Tool | Application | Operation | Version
---|---|---|---
Compression | 7-zip | Compression | 19.00
7-zip | Decompression
Winzip | Compression | 24
Winzip | Decompression
Winrar | Compression | 5.80
Winrar | Decompression
BreeZip | Compression | -
BreeZip | Decompression
Alzip | Compression | 11.04
Alzip | Decompression
PeazipWinrar | Compression | 7.1.1
PeazipWinrar | Decompression
Encryption | AESCrypt | Encryption | 310.00
AESCrypt | Decryption
AxCrypt | Encryption | -
AxCrypt | Decryption
Shredder | Eraser | Delete | 6.2.0.2986
Ccleaner | Delete | -
Windows Delete | Delete | -

TABLE XVII: Benign applications spawning multiple processes.

Type | Application | Version | spawn processes?
---|---|---|---
Office | MS Word | 16.0.11929.20436 | $\times$
MS Powerpoint | 16.0.11929.20436 | $\times$
MS Excel | 16.0.11929.20436 | $\times$
MS Outlook | 16.0.11929.20436 | ✓
Trio Office: Word, Slide, Spreadsheet | - | ✓
Development | Pycharm | 11.0.3+12-b304.56 amd64 | ✓
Matlab | R2019a | ✓
Visual Studio C++ | 2019 community version | ✓
Android Studio | 191.6010548 | ✓
Tools | Adobe Acrobat Reader | 20.006.20034 | ✓
Adobe Photoshop Express | 3.0.316 | $\times$
PhotoScape | 3.7 | $\times$
Cool File Viewer | - | $\times$
PicArt Photo Studio | - | $\times$
Paint 3D | - | $\times$
Cloud and Internet | Dropbox | - | $\times$
Googledrive | - | $\times$
Internet Explorer | 11.1039.17763 | ✓
Google Chrome | 80.0.3987.132 | ✓
Remote Desktop | - | $\times$
Messenger | Telegram | 1.9.7 | $\times$
WhatApp | 0.4.930 | ✓
Skype | 1.9.7 | $\times$
Facebook Messenger | - | ✓
Document | Wordpad | - | $\times$
Notepad | - | $\times$
OneNote | 16001.12527.20128.0 | $\times$
Media player | VLC | 3.0.8 | $\times$
Netflix | 6.95.602 | $\times$
GOM Player | 2.3.49.5312 | $\times$
Miscellaneous | Spotify | - | ✓
KeePass Password manager | 1.38 | $\times$
Discord | - | $\times$
Facebook | - | $\times$

###  -C Malicious commands triggered during ransomware execution

In Table XVIII, we show example malicious commands extracted by Peeler during
ransomware execution. This is not an exhaustive list of malicious commands
instead we show few important malicious commands found during ransomware
execution.

TABLE XVIII: Malicious commands.

no |  Command
---|---
1 |  vssadmin.exe delete shadows /all /quiet
2 |  bcdedit.exe /set default recoveryenabled No
3 |  bcdedit.exe /set default bootstatuspolicy ignoreallfailures
4 |  powershell.exe -e Get WmiObject Win32_Shadowcopy | ForEach-Object{$_.Delete();}
5 |  taskkill /t /f /im mal.exe
6 |  del mal.exe
7 |  reg add HKCU $\backslash$Software$\backslash$Microsoft$\backslash$Windows$\backslash$
CurrentVersion$\backslash$Explorer$\backslash$Advanced /f /v HideFileExt /t
REG_DWORD /d 1
8 |  reg add HKCU $\backslash$Software$\backslash$Microsoft$\backslash$Windows$\backslash$
CurrentVersion$\backslash$Explorer$\backslash$Advanced /f /v Hidden /t
REG_DWORD /d 2
9 |  reg add HKCU $\backslash$Software$\backslash$Microsoft$\backslash$Windows$\backslash$
CurrentVersion$\backslash$Explorer$\backslash$Advanced /f /v EnableLUA /d 0
/tREG_DWORD /f
10 |  reg add HKCU$\backslash$Control Panel$\backslash$Desktop /v Wallpaper /t REG_SZ /d PathtoRansomNoteImage /f
11 |  reg add HKCU$\backslash$Control Panel$\backslash$Desktop /v WallpaperStyle /t REG_SZ /d "0" /f
12 |  reg add HKCU$\backslash$Control Panel$\backslash$Desktop /v TileWallpaper /t REG_SZ /d "0" /f
13 |  powershell.exe -ExecutionPolicy Restricted -Command Write-Host ’Final result: 1’;
14 |  powershell.exe Set-MpPreference -DisableArchiveScanning $true;
15 |  powershell.exe Set-MpPreference -DisableBlockAtFirstSeen $true;
16 |  icacls Path /deny *S-1-1-0:(OI)(CI)(DE,DC)
17 |  icacls . /grant Everyone:F /T /C /Q
18 |  notepad.exe C:$\backslash$Users$\backslash$USER$\backslash$Music$\backslash$# RESTORING FILES #.TXT
19 |  cscript C:$\backslash$Users$\backslash$kim105$\backslash$AppData$\backslash$Local$\backslash$Temp/SUwk.vbs
20 |  wmic.exe shadowcopy delete
21 |  net.exe stop vss
22 |  net.exe stop McAfeeDLPAgentService /y
23 |  schtasks /create /sc onlogon /tn TASK_NAME /rl highest /tr PATH_TO_EXE
24 |  vssadmin.exe resize shadowstorage /for=c: /on=c: /maxsize=401MB