SSD-Insider: Internal Defense of Solid-State Drive

against Ransomware with Perfect Data Recovery

SungHa Baek Youngdon Jung Aziz Mohaisen Sungjin Lee DaeHun Nyang
Inha University DGIST UCF DGIST Inha University
Abstract—Ransomware is a malware that encrypts victim’s days of not being able to operate because it could not access
data, where the decryption key is released after a ransom is paid patients medical records [2].
by the data owner to the attacker. Many ransomware attacks
were reported recently, making anti-ransomware a crucial need Ransomwares are generally classified in two groups: locker
in security operation, and an issue for the security community to and crypto ransomwares [3]. Locker ransomware prevents
tackle. In this paper, we propose a new approach to defending users from accessing an infected machine, while crypto ran-
against ransomware inside NAND flash-based SSDs. To realize somwares, such as WannaCry, CryptoWall, TeslaCrypt (a.k.a.
the idea of defense-inside-SSDs, both a lightweight detection AlphaCrypt) and Locky, lock users’ data by encrypting the data
technique and a perfect recovery algorithm to be used as a to prevent users’ data access. Most of the newly discovered
part of SSDs firmware should be developed. To this end, we ransomwares were crypto ransomware, compared to 80% of
propose a new set of lightweight behavioral features on ran-
crypto ransomwares in 2015 [3]. As such, more attention
somware’s overwriting pattern, which are invariant across various
ransomwares. Our features rely on observing the block I/O should be paid to crypto ransomwares and their defenses,
request headers only, and not the payload. For perfect and instant which is the case of this work.
recovery, we also propose using the delayed deletion feature of In this work, we propose a new approach to ransomware
SSDs, which is intrinsic to NAND flash. To demonstrate their detection and recovery by introducing the concept of NAND
feasibility, we implement our algorithms atop an open-channel
SSD as a working prototype called SSD-Insider. In experiments
flash internal defense. Unlike the application layer detection
using eight real-world and two in-house ransomwares with systems, our approach is universal to every platform (oper-
various background applications running, SSD-Insider achieved ating system, filesystem, hardware configuration, etc.), and
a detection accuracy 0% FRR/FAR in most scenarios, and only provides immunity for systems without requiring any vaccine
5% FAR when heavy overwriting resembling ransomware’s data software. By introducing six invariant features of ransomware
wiping occurs. SSD-Insider detects ransomware activity within for a machine learning algorithm and by taking advantage of
10s, and recovers instantly an infected SSD within 1s with 0% SSD’s unique nature, we develop a behavior-based detection
data loss. The additional software overheads incurred by the and recovery system that runs inside SSDs as a form of
SSD-Insider is just 147 ns and 254 ns for 4-KB reads and writes, storage firmware. With our ransomware detection and recovery
respectively, which is negligible considering NAND chip latency algorithms built in, SSDs can effectively detect ransomwares’
(50-1000 µs).
activity and perfectly recover user’s data, even when 1) a
user does not run any ransomware monitoring application,
I. I NTRODUCTION 2) the OS (or middleware) does not execute any ransomware
monitoring task, 3) it works for an unknown OS, an unknown
Ransomware, a type of malicious software (malware) that file system and unknown applications, and 4) it confronts
holds a user’s data hostage to collect ransom, has been on previously unknown ransomwares. We realize the ransomware
the rise. To extort ransom from data owners, ransomware detection and recovery algorithms in a system, called SSD-
encrypts data using strong encryption algorithms, and the Insider, which works as a universal platform. To this end, in
decryption keys are released only after a ransom is paid by the this paper we deliver the following contributions:
data owners. Ransomware tries to subvert standard malware
• We design six invariant features to capture ran-
defenses by using complex command and control (C&C)
somwares’ behavioral characteristics. We use the
networks that utilize anonymous communication systems such
block address, size, and type of an IO request to an
as Tor, and by collecting ransom using cryptocurrency, such
SSD, and analyze their correlation with ransomware
as Bitcoin, which is very difficult to track. The high potential
activities using various real-world ransomwares.
financial gains to attackers and the difficulty of defending
against ransomwares make them a “profitable business” to • We build a machine learning technique for detecting
cybercriminals. For example, the Nayana web hosting firm ransomware using a binary decision tree using ID3
in South Korea was attacked by a crypto ransomware called (Iterative Dichotomiser 3) [4].
Erebus in 2017, where more than 3,400 web sites were affected
• We design a new Flash Translation Layer (FTL)
according to the Korea Internet and Security Agency. As a
scheme that supports an instant recovery of infected
result Nayana paid 1.14 million USD to the attackers in three
files by leveraging the intrinsic delayed deletion fea-
installments to get the key, and even then could not totally
ture of NAND flash.
recover the data [1]. Similar attacks were reported in the US.
For example, in 2016, the Hollywood Presbyterian Medical • To show the feasibility of our system inside an SSD,
Center was infected by a crypto ransomware, and had to pay we implement SSD-Insider using an open-channel
40 bitcoins (about $17,000 at that time) to the attacker after 10 SSD platform as a working prototype.
 • We evaluate SSD-Insider using eight real-world ran-
somwares and in-house ransomwares while various
background applications were running. Our implemen-
tation of SSD-Insider has 100% detection accuracy,
with less than 10 seconds of detection latency. SSD-
Insider also recovered encrypted files within 1 second,
and without any data loss after recovery.

II. M OTIVATION
A. Limitations of legacy approaches (a) Ransomware action vs. overwrit- (b) Ransomware and normal app’s
ing frequency. cumulative overwriting frequencies
It is necessary to define effective ransomware-specific
features so that a detector can recognize ransomware activity Fig. 1: Ransomware’s overwriting behavior (WannaCry, Jaff, Mole, and Cryp-
immediately and accurately. However, it is difficult to de- toShield ransomwares): (a) There is a strong correlation between active period
tect ransomware only by observing their signatures, because of ransomware and the number of overwritings per second (= OW IO), and
their binaries change frequently. For example, an interesting (b) Cumulative values of overwritings show that ransomware does overwriting
very frequently.
“ransomware-as-a-service” model called TOX was found in
2015, which helps inexperienced attackers to easily build a
variant ransomware [5]. Ransomware also can easily evade
anti-ransomware, firewall rule sets, and spam filters. The before being infected. However, a report in 2013 showed that
mutable nature of ransomware makes it also harder to detect 24% of personal computers (PCs) were unprotected by any
only by signatures, and pushes the detection paradigm further anti-virus software [7]. Furthermore, more than 90% of devices
into the realm of behavior-based defenses. that had anti-virus had not run a full system scan using their
File type-based or content-based detection and data loss. anti-virus within the last seven days. Even worse, anti-virus
The most recognizable change after/during a ransomware’s definitions were out of date in more than 15% of the PCs [8].
activity is that a number of files are changed by their types or Also, cracked anti-virus software could get PC infected as well.
by contents. Scaife et al. have observed important features Finally, killing a ransomware detector process would not be an
that could be strong indicators of ransomware [6]. Among issue to the creator of ransomware when characteristics of most
them, the most important indicators include the following. 1) commercial detector software are well known in advance.
File type change which is necessarily followed by ransomware
activities. 2) The similarity measure between an original file B. Our approach: SSD-installed ransomware detector
and its modified version is very low – since ransomware
normally encrypts the victim file. 3) High entropy is also a Our approach is not to detect ransomware in the application
strong evidence of encryption, but it is sometimes hard to layer or in the OS layer, but to put the detector inside an
be distinguished from compression that also has very high SSD. By doing so, we can solve the most crucial problems
entropy. 4) A large number of file may be an indicator, in ransomware detection: 1) Protection of users having no
although a weak one given that the deletion of many files anti-ransomware software installed, and 2) high overhead for
happens usually regardless of ransomware action. recovery of data loss caused by detection latency.
Since the content-based detection monitors a large volume Challenges for detection and recovery. To realize our ap-
of data in real time, it inevitably results in high CPU and proach, we have to solve the following problems:
memory overheads. Particularly, this approach involves tweaks
in OS, which requires privilege escalation for the monitoring • SSD-Insider should work as a part of SSD firmware,
software. Considering that the detector can be infected as which means that it should detect ransomware only
well, this approach is not desirable. Also, while the accuracy with limited CPU power and memory. Monitoring
of content-based detection is very high owing to plenty of content alteration incurs too much overhead to an SSD
context information, this approach has to back up contents system as we discussed. Thus, SSD-Insider should be
constantly for every writing requests to recover the already- able to extract ransomware’s behavioral characteristics
encrypted files. This constant back up process results in a by seeing only IO request headers instead of seeing
prohibitive overhead. As such, most works falling under this the whole request data. The IO request header include
approach have focused on how to detect ransomware as early only a logical block address, read/write type, and
as possible to minimize the overhead for recovery. File type- the size of data. This limited view of ransomware
based detection involves smaller overhead than content-based activity makes detection more difficult, considering
detection, but it can be easily evaded by ransomware to alter that much more context and information are available
forcibly file extensions or the magic numbers for a given file to application layer detectors including file names, file
type. sizes, file access time, process IDs, process names, and
the amount of memory the process is using, etc.
Application layer detection and its security. Most of the
solutions against ransomware run in the application layer, thus • Detection latency is inevitable by any means, so
they cannot secure the system in the worst case. First of all, some portion of disk blocks will have been already
in these solutions, users should be aware of the danger of ran- encrypted. A method to provide perfect data recovery
somware, and they should install the anti-ransomware software even under detection latency should be provided.

2
 Our approach to address the two challenging problems the original files cannot be recovered, it is necessary to
above is to use overwriting patterns as ransomware features “overwrite” the original files either by the encrypted contents
for detection and to take advantage of SSD’s delayed deletion, or by random contents. Indeed, all of the ransomware samples
which is an intrinsic feature of NAND flash memory for we collected were found to conduct overwriting immediately
recovery. after reading and encrypting the victim’s files. We note that
the overwriting is technically equivalent to “unrecoverable
Overwriting patterns as lightweight and invariant features. permanent erasure” conducted by a ransomware. To capture
To recognize ransomware activity by viewing only the dis- ransomware’s behavioral traits, and to find features capable
tribution of IO request headers, we have paid attention to a of distinguishing ransomware from normal applications with
ransomware’s very unique behavior, overwriting. Overwriting similar overwriting behavior, we conducted experiments that
in SSD is defined as the event of updating the same logical run several ransomwares and applications (data wiping, DB
block address (LBA) to remove the data in the block after a update, IO stress test, etc) in a sandbox and found the following
block read. Fig. 1(a) shows how long WannaCry and Mole six features; four principal features and two secondary ones1 :
ransomwares were in action during 1-second time slices when
overwriting frequency varies; it shows that the more frequent • OW IO denotes the number of overwritings for a time
overwriting occurs, the longer WannaCry and Mole have slice (e.g., 1 sec).
been running. Fig. 1(b) further shows the cumulative graph
of the number of overwriting requests for four ransomware • OW ST is the fraction of overwritten blocks over the
(WannaCry, Jaff, Mole, and CryptoShield) and four normal ap- total number of write requests during a time window.
plications (data wiping, P2P download, cloud storage synchro- • PW IO is the number of overwritings for a time
nization, and compression). We notice that ransomwares have window consisting of N time slices.
a relatively high growth rate compared to normal applications.
While WannaCry and Mole stand out, Jaff and CryptoShield • AVGW IO is the average length of continuously over-
have a relatively low growth rate, alluding to a difficulty in written blocks in a current time window.
distinguishing them from the normal applications. Even so, it
• OW SLOPE is the fraction of the number of over-
is clear that ransomwares cannot but permanently delete victim
writings during a current time slice over the average
files by overwriting them by either encrypted or other unrelated
number of overwritings over the previous time win-
data. Also, ransomwares should overwrite as soon as possible
dow.
to decrease the user’s chance of recovery.
• IO is the fraction of the number of overwritings
Using SSD’s delayed deletion for perfect and instant
during a current time slice over the average number
recovery. To deal with the inability to perform in-place updates
of writings over the previous time slice
in NAND flash, the logical block address is separated from the
physical block address in SSDs. Therefore, a storage firmware OWIO. OW IO is the most significant feature indicating the
(called FTL) running inside SSDs maintains an address map- property of reading, encrypting and overwriting the same
ping table and remaps overwritten LBAs to free physical space. block of a file for a short period of time. Fig. 1(a) shows
With FTL’s address remapping, all the new data is appended to how long WannaCry and Mole ransomwares were running
storage media, which enables us to hide the out-of-place update during 1-second windows when varying the value of OW IO.
nature of NAND flash. However, since old versions of data It shows that the more frequent overwriting occurs, the longer
are left in the flash, which wastes storage space, FTL’s other WannaCry and Mole have been in action. Also, the overwriting
module, the garbage collector (GC), reclaims the free space frequency of normal applications, as can be seen in Fig. 1(b),
occupied by old versions. As observant readers might notice, is not as high as that of ransomwares except for data wiping
SSDs always keep old versions of data that were overwritten applications (i.e., less than 100K). This supports our hypothesis
by new data until they are permanently erased by GC. SSD- that heavy overwriting follows reading operation within a short
Insider takes advantage of the built-in backup capability of duration, when ransomwares are active. We utilize OW IO, the
SSDs. SSD-Insider keeps track of old versions of data inside overwriting frequency as one of indicators of ransomware. This
SSDs and never removes them until the ransomware detection feature, however, can also be observed during normal program
algorithm confirms that the new versions are not affected by execution such as DB update after email synchronization (e.g.,
ransomwares. If a ransomware attack is detected, SSD-Insider outlook), cloud storage synchronization (e.g., dropbox), OS
can quickly recover the original data by rolling back a mapping update (MS Windows update), software installation, temporary
table so that it points to the old versions. Since only an update file creation for web browsing, and during the operation of anti-
of mapping table entries is required, the roll-back process can virus software, data wiper, disk stress tools, etc. For example,
be completed rapidly without having to copy data physically. Fig. 1(b) shows cumulative values of OW IO for four ran-
somwares (e.g., WannaCry, Mole, CryptoShield, and Jaff) and
III. D ESIGN OF SSD-I NSIDER for four normal applications (e.g., data wiping, cloud storage,
compression, P2P download). The accumulated number of a
A. Invariant features of ransomware data wiping program is as high as that of ransomwares as
shown in Fig. 1(b), and that of CryptoShield is as low as that
Based on how they overwrite encrypted files, ransomware
of cloud storage update and P2P download. Therefore, more
can be categorized into three classes: in-place overwriting
(Class A), out-of-place overwriting (Class B), and deleting 1 Throughout this paper, overwriting is limited to overwritten data blocks
and overwriting the original file (Class C) [6]. Considering that have been read within the last N seconds (time window), where N is a
that attacker’s chances to get ransom become higher when parameter adjusted based on the desired detection speed and accuracy.

3
 (a) Correlation between active period (b) Cumulative values of OW ST (c) Correlation between active period (d) Cumulative values of PW IO
of ransomware and OW ST of ransomware and PW IO

(e) Correlation between active period (f) Cumulative values of AV GW IO (g) Correlation between active period (h) Correlation between active period
of ransomware and AV GW IO of ransomware and IO of ransomware and OW SLOPE

Fig. 2: Six ransomware features capture ransomware’s behavioral characteristics (See also Fig. 1 for OW IO).

features distinguishing ransomwares from these applications applications, which is shown in Fig. 2(f), where its correlation
are necessary to detection precisely. with the active period is shown in Fig. 2(e).
OWST. One of the hard-to-distinguish applications is data wip- Secondary features. The four aforementioned features are the
ing as we have seen in Fig. 1(b). The noticeable feature is how principal features of SSD-Insider. The other auxiliary features
many overwritings there are among writing requests within are IO and OW SLOPE, where OW SLOPE captures ran-
a time window, where duplicate overwritings over a single somware’s behavior of abrupt increase of overwriting volume.
block are counted only once. Typical data wiping applications Their correlations with ransomware’s active period are shown
require multiple overwritings over a single block to securely in Fig. 2(g) and Fig. 2(h).
erase data, which incurs low OW ST value compared to that of
Owing to the resource limitation and the tight time-bound
a ransomware. For example, the DoD 5220.22-M [9] requires
characteristics of the SSD system, we utilized a binary deci-
7 overwritings per one read IO over the same block. Fig. 2(b)
sion tree, instead of using more powerful machine learning
confirms that OW ST captures the high rate of overwriting in
algorithms, such as support vector machine or even deep
write IOs that occur during ransomware operation, where the
learning. For the training algorithm of the tree, we used the
strong correlation between OW ST and the active period of
ID3 algorithm [4].
ransomware is clearly shown in Fig. 2(a).
PWIO. Sometimes, CPU-intensive or IO-intensive jobs might B. Ransomware detecting algorithm
be running while a ransomware is in operation. In this case,
the speed of ransomware slows down, thus the IO requests of Data structure for detection. All I/O requests are monitored
ransomware are dispersed over rather a long time span. For for ransomware detection, and each request consists of four
example, the ransomware Jaff is too slow to be detected by items: Time, LBA, IOMode, and Length. Time denotes when
OW IO and OW ST. However, PW IO, the accumulated number the request was generated in the system. LBA is the starting
of overwritings during a longer-term window (10s) instead of address where the data is read or written, IOMode represents
a short-term slice (1s) of OW IO captures it very well as shown the request type (R/W), and Length is the number of blocks
in Fig. 2(d), whereas its correlation shown to be strong with for the request. A request is denoted by IOReq, and Length is
the ransomware activity period as shown in Fig. 2(c). assumed to be 1. A time window is defined over I/O requests
as a duration of monitoring to detects periodically suspicious
AVGWIO. AVGW IO captures the run-length characteristics behavior of ransomware, and is used as 10s in our experiments.
of ransomware’s attack target. Because the ransomware mainly It consists of N time slices, and it slides by a time slice
targets documents and images, it does not involve overwriting (e.g., 1s) at every check point. To evaluate values of the six
operations over many continuous blocks, unlike data wiping, features, we build a counting table that basically stores IOReq’s
defragmentation, and DB updates. Thus, the length of continu- run-length of overwriting. During a time slice, SSD-Insider
ously overwritten blocks is relatively shorter than that of those counts IOReq, and updates the counting table according to

4
 (a) Counting table holds the run-length of overwritings for each time (b) Counting table update example using basic functions (NewEntry, UpdateEn-
slice. tryR, SplitEntry, UpdateEntryW, and MergeEntry)

Fig. 3: Design of SSD-Insider: data structure and working examples

Algorithm 1 RansomwareDetection
Require: N
1: for all reqi do
2: if the time slice expires then
3: Calculate 6 attributes for N time slices
4: r ansomt =DecisionTree I D3 (6 attributes)
5: Score = Score + r ansomt
6: Slide TimeWindow by one time slice
7: Score = Score − r ansomt −10
8: end if
9: if reqi is write-req then
10: Count overwritten blocks if reqi is already in the table
11: Merge or split the runs of overwritten blocks
12: else
13: Make a new entry and adjust the runs of overwritten blocks Fig. 4: Sliding time window and detecting ransomware activity
14: end if
15: end for

PW IO as shown in
3 of Fig. 3(a).
the counting value and LBA. The counting table consists of SSD-Insider’s real-time detection. The detection algorithm is
entries that store each consecutive overwriting. An entry is described in Algorithm 1. Using an example, how to keep track
composed of Time, LBA, RL, and WL. Time denotes the time of run-length of overwriting during each time slice and window
slice number at which the entry is created or updated. LBA is described in Fig. 3(b). IOReqs used in this example are
is the starting address of a consecutive overwriting. RL is the assumed to have (IOMode, LBA) and the Length is used as 1.
total length of Read IO that occurs consecutively from the Roughly speaking, the algorithm updates the tables according
LBA. WL is the total length of write IO, i.e., consecutive to the IO request type. When it is a write request, it checks
overwriting, occurring after a read IO has occurred. A hash whether it is an overwriting command or not and counts (Line
table consisting of LBAs for keys is defined for fast access of 10). Also, because it is collecting the run-length of overwritten
the counting table. Since an entry in the counting table stores blocks, it manages the runs of overwritten blocks (Line 11).
a consecutive IOReq, multiple LBAs can be merged into an For a read request, it makes a new entry in the table or just
entry. Using the counting and the hash tables, we can calculate update it to make a longer run (Line 13). When a time slice
values of the six features. That is, IO is the sum of all read expires, it drops the obsolete entries in the counting table by
(RIO) and write IOs (W IO) during the current time slice ( 1 sliding the window (Line 6), and adjust Score by subtracting
in Fig. 3(a)). OW IO is the sum of WLs for the current time the dropped entry (Line 7). Six feature values are calculated
slice. PW IO is the sum of all WLs stored in the counting table using the counting table (Line 3), and the values are fed
from t − 11 to t − 1 (assuming N = 10, as in our experiments), to the ID3 decision tree (DecisionTreeI D3 ) to obtain 0 or 1
when the current time is t. AVGW IO is the average WL of results (Line 4), where 1 means that the system at the current
all entries from t − 10 to t in the counting table as in 2 of checkpoint is highly likely to be under attack of a ransomware,
Fig. 3(a). OW ST is the current time slice’s OW IO divided by and 0 means otherwise. For a time window (10s), the outputs
W IO. Finally, OW SLOPE is the value of OW IO divided by of the decision tree are all added up to give a score ranging

5
from 0 to 10 as shown in Fig. 4 (Line 5). To determine whether Safe Maybe Unsafe Ransomware
① detection
ransomware is active or not, we used a threshold value 3 in Written LBA 7 8 10 9 13 11
our experiment (See section V-B). Time
t-10 t

C. Instant recovery algorithm ③ Locate an infected ② Scan the queue

mapping entry t t-10
In order to support the recovery of damaged files, SSD-
11 26 22
Back 11
22 13
21 9
20 ǜǜǜ Front
Insider’s recovery algorithm should keep track of all the
④
ǜǜ Recovery Queue
ǜ
changes made to files, maintaining original versions. It also Recover
Mapping Table the old entry
should retain data persistence/consistency and should not
compromise I/O performance. In addition, SSD-Insider must PPA 21 22 23 24 25 26 27 28 29 30
be designed in a cost-effective manner so that it can be ǜǜǜ
11 11
ǜǜǜ NAND
Flash
implemented in SSD environments. The proposed recovery
algorithm is devised to satisfy all of the aforementioned Fig. 5: Data recovery process in SSD-Insider. After ransomware is detected
requirements. In the following subsections, we explain how the ( )
1 at time t, the SSD-Insider FTL scans the recovery queue ( ), 2 examining
SSD-Insider’s FTL handles I/O requests while leaving change LBAs, old PBAs, and timestamps. For LBAs 9, 13, and 11 that were recently
logs for recovery and detail its recovery process. We also overwritten (i.e., > t − 10), the SSD-Insider cannot guarantee their safety.
Therefore, SSD-Insider locates a mapping entry in the mapping table ( ) 3
discuss issues related to GC. and updates the entry so that it points to the physical location of the original
data ( ).
4 In case of LBA 11, its mapping entry is reverted from PPA 26
Data recovery process. Once the data recovery process is to PPA 22 that contains old but safe data. For LBAs 7, 8, and 10 that were
triggered by the detection algorithm, the SSD-Insider notifies written 10 seconds ago (i.e., ≤ t − 10), SSD-Insider guarantees that their data
users of which suspicious behaviors are detected 2 . If a user are safe, and thus their mapping entries are not updated.
responds that ransomware attack is suspected, SSD-Insider’s
FTL first makes an SSD read-only, ignoring all the writes
sent to it. As illustrated in Fig. 5, the SSD-Insider’s FTL then their new versions are confirmed safe. For this reason, the SSD-
scans backup entries in the queue from the back to the front, Insider’s FTL has to copy even invalid pages during GC if it is
replacing individual mapping entries with the corresponding unsure if they are encrypted by ransomware or not. Compared
backup entries. Backup entries staying in the queue for longer with typical FTLs, therefore, SSD-Insider would require more
than 10 seconds are ignored during the recovery process. After page copies for GC. However, since only a limited number
the recovery process finishes, the status of the mapping table is of pages stay in the queue, extra page copies caused by
rolled back to the time just before 10 seconds. This roll-back SSD-Insider are trivial. According to our experiments, SSD-
process is accomplished within one second because it does Insider exhibits almost 0% and 22% higher GC overheads than
not involve any data copies, but just updating the mapping existing FTLs under the average- and the worst-case scenarios,
table. After the storage is recovered, SSD-Insider asks users respectively (see Section 5).
to reboot the system and to get rid of ransomwares using
anti-virus programs. The recovery algorithm aims at restoring
the status of the SSD to 10 seconds earlier, but this process IV. I MPLEMENTATION OF SSD-I NSIDER
is done without any awareness of data consistency between We implemented SSD-Insider’s detection and recovery
files and their metadata (e.g., inodes). Thus, a recovered SSD algorithms in an in-house open-channel SSD3 prototype illus-
could have an inconsistent status, where on-disk file-system trated in Fig. 6. Our in-house SSD card was composed of 8
structures and files are partially updated and thus inconsistent. channels and 8 ways with a custom flash controller. It offered
This consistency problem can be resolved by means of a file- a capacity of 512 GB with 700 MB/s write and 1.2 GB/s read
system check/recovery tool (e.g., fsck). fsck is designed to throughputs, which were comparable to commercial SSDs. To
restore a consistent file system after sudden power loss or a evaluate SSD-Insider in terms of performance and overhead,
system failure. The SSD status after SSD-Insider’s recovery we used a x86 host with Intel’s Xeon CPU running at 3.0 GHz
is similar to one after sudden power loss or system failures. and 4 GB DRAM. Our SSD card was connected to the x86
Only the differences are: 1) it is intentionally caused by SSD host through a PCIe interface. Ubuntu 16.04 with the Linux
firmware and 2) it looks like that a power failure happened 10 kernel 4.10 was used as a host OS.
seconds before ransomware attacks. A series of experiments
on EXT4 show that file-system is successfully recovered to a
consistent state with fsck (see Section V-B). V. E XPERIMENTAL R ESULTS
Garbage collection. Garbage collection (GC) is the only way A. Ransomware data sets
of permanently erasing actual contents in flash. Old versions
of data stored in flash pages should not be erased by GC until For our evaluation, we collected various well-known ran-
somwares such as Locky.bdf, Locky.bbs, Zerber.ufb, Wan-
2 This notification to end users can be made by using a customizable I/O naCry, Jaff, Mole, GlobeImposter, and CryptoShield [12].
interface facility with an integrated user application. The modern storage
interface standards provide a way of adding user-defined commands so that 3 Unlike off-the-shelf SSDs, the open-channel SSD platform enables us to
the host and the storage device exchanges maintenance information [10], [11]. implement and test various FTL algorithms because all those algorithms are
In our case, a ‘ransomware attack alarm’ can be added as a new command. run on the block device layer of the host system [11]. Even if the FTL
Once the host receives an alarm from the SSD, it launches the application that algorithms, along with the detection/recovery algorithms, are implemented in
displays a warning message and gets a response from users to decide whether the block layer, they could be directly adopted to the SSD firmware because
a ransomware attack is suspected or not. of no differences in the design principle.

6
 Windows 10 (Guest OS)

Linux 4.10 Ransomware

Ransomware
Ransomware
Ransomware
(Host OS) TypeAA
Type
Type AA
Type

Virtual Disk

Experimental Setup
Raw Block Dev
Block Dev Block Dev
Driver Driver FTL
(Unmodified) (Modified) SSD-Insider
SATA PCIe
NAND Flash Cards HDD Open Channel SSD
(Linux OS Image)

(a) Open-channel SSD card (b) The SSD card attached to a x86 host via PCIe (c) A diagram of our experimental setup
Fig. 6: SSD-Insider’s working prototype and experimental setup

TABLE I: Data set with various combinations of ransomwares and applications type includes compression (Bandizip), video encoding (Daum
for training and testing of SSD-Insider pot encoder), 4) Normal app type includes video playback
(Daum pot player), email synchronization (Outlook), P2P
Application Type Application Ransomware download (BitTorrent), web-browsing (Chrome), SQLite activ-
For training ities (Kakaotalk), and software installation such as VS (Viusal
Ransom only none Locky.bbs
Heavy overwriting WPM (DataWiping) none
Studio 2015) and AutoCAD 2016. Various combinations of
Heavy overwriting MySQL (Database) none a ransomware and a background application were used for
Heavy overwriting Dropbox (CloudStorage) none learning decision trees with ID3, and also for performance
IO-intensive DiskMark (IOStress) Zerber.ufb evaluation. The whole dataset and evaluation scenarios for
IO-intensive IOMeter (IOStress) Zerber.ufb the experiment are summarized in Table I. For evaluation,
IO-intensive hdtunepro (IOStress) Zerber.ufb
Normal App AutoCAD/VS (Install) Locky.bdf experiment with each combination was conducted 20 times,
Normal App Chrome (WebSurfing) Locky.bbs and the average was taken. We also note that as shown in the
Normal App OutlookSync Locky.bdf table no ransomware for training is included for testing to show
Normal App WindowUpdate Locky.bdf how accurately and promptly SSD-Insider detects unknown
Normal App BitTorrent (P2PDown) none
Normal App Kakaotalk (SQLite) none
ransomwares.
For testing
Ransom only none WannaCry B. Performance evaluation
Heavy overwriting Dropbox (CloudStorage) In-house (outplace)
Heavy overwriting WPM (DataWiping) GlobeImposter Ransomware detection accuracy. To evaluate the accuracy
Heavy overwriting MySQL (Database) In-house (inplace) of SSD-Insider detection algorithms, we measured FAR (false
IO-intensive IOMeter (IOStress) CryptoShield acceptance rate) and FRR (false rejection rate) of the detection
CPU-intensive Bandizip (Compression) Mole
CPU-intensive PotEncoder (VideoEncode) Jaff algorithm varying the threshold of the score value (or the
Normal App AutoCAD/VS(Install) GlobeImposter frequency of which the decision tree reports ransomware
Normal App PotPlayer (VideoDecode) WannaCry activity for a time window) to detect ransomware. Fig. 7
Normal App OutlookSync Mole summarizes our experimental results on accuracy in terms of
Normal App BitTorrent (P2PDown) WannaCry
Normal App Chrome (WebSurfing) GlobeImposter
FAR/FRR. Even though there is some variation, depending on
the scenario, with the threshold with 3 the detection algorithm
could detect ransomware’s activity accurately under all types of
As well as those, we have implemented two new and in- background applications. We report that the worst background
house ransomwares that are not reported to the public us- noise in terms of FRR came from IO-intensive and CPU-
ing open source ransomwares from github [13], [14] – one intensive jobs as shown in Fig. 7(b) and Fig. 7(c). That is,
of them has an ‘in-place update’ encryption attack while they interfered with ransomware to slow down the speed of
the other is based on an ‘out-of-place update’. To evalu- overwriting by heavy usage of CPU and IO. In terms of
ate SSD-Insider’s performance, we set up the environment FAR, the worst scenario came mostly from heavy overwriting
where ransomware ran with typical background applications, type, such as DataWiping and Database applications as shown
including three application types: applications with high rate in Fig. 7(b). This is because heavy overwriting applications
of overwriting, CPU-intensive, and IO-intensive applications. confused our detector by their similarity in behavior. However,
While heavy overwriting applications confuse our detector, as can be seen in Fig. 7, even in such heavy CPU, IO usage
CPU/IO-intensive applications disturb the detector by slowing and heavy overwriting scenarios, SSD-Insider detected very
down ransomware’s activity. Even the normal application class accurately ransomware activity with the threshold value 3.
included applications with relatively high IO compared to FRRs in all scenarios were 0%, and FARs were close to 0%
user’s casual usage pattern. The background applications were with the threshold value 3, which means that SSD-Insider
divided into four types: 1) Heavy overwriting type includes did not miss any ransomware activity, but sometimes falsely
data wiping tool (WPM satisfying DoD 5220.22-M), cloud recognized normal application’s activity as that of ransomware.
storage synchronization (Dropbox), and heavy database update Before recovery process starts, SSD-Insider prompts users to
(MySQL 5.5), 2) IO-intensive type includes IO stress tools confirm whether she will start the recovery process or not.
such as IOMeter, HDtunepro, DiskMark, 3) CPU-intensive False alarm might interrupt users, but it would rarely happen

7
 (a) Heavy overwriting (b) IO-intensive (c) CPU-intensive (d) Normal App
Fig. 7: SSD-Insider’s detection accuracy varying the score during a time window (10s) When the threshold score (or, the threshold frequency of the decision
tree’s reporting of ransomware activity for a time window) is set to 3, FRR is 0% and FAR is at most 5% only when heavy overwriting such as data wiping.
Elapsed time (nanosecond)

500 1600 2x108

Conventional SSD
FTL code 1400 FTL code 1.8x10
8
SSD-Insider
400 SSD-Insider SSD-Insider 8
1200 1.6x10

1000 1.4x108

# of page copies
300 8
800 1.2x10
200 600 1x108

400 8x107
100 6x107
200
0 0 4x107
2x107
Wannacry
CloudStorage
DataWiping
Database
IOStress
Compression
VideoEncode
Install
VideoDecode
OutlookSync
P2PDown
WebSurfing
Wannacry
CloudStorage
DataWiping
Database
IOStress
Compression
VideoEncode
Install
VideoDecode
OutlookSync
P2PDown
WebSurfing

IO

Vi

In

Vi

P2

W
lo

at

at

om

ut
st
de

de
an

eb
St

PD
ud

aW ge

ab

al

lo
re

oE n

oD
na

Su
pr

ok
St

ow
as

ss

es
ip
cr

nc

ec

rfi
S
or

e
in

n
y

si

yn

ng
o

od
a

de

c
e
(a) Read elapsed time (b) Write elapsed time Fig. 9: A comparison of GC costs
Fig. 8: Impact of SSD-Insider on I/O elapsed times for ransomware-infected
SSDs with various background applications running
by 2) the SSD-Insider detection/recovery algorithms, excluding
NAND device latency. To confirm the feasibility of SSD-
only with heavy DB update, data wiping, and software install Insider on embedded processors, we intentionally slowed down
even at most FAR 5% as shown in Fig. 7. the host CPU clock from 3 GHz to 1.2 GHz on which
SSD-Insider runs. Compared with the conventional FTL, read
Data consistency. To evaluate data consistency, we intention- and write latencies with SSD-Insider increased by 23.5% and
ally exposed the host to ransomware attacks repeatedly 100 15.6%, on average. More specifically, the elapsed times taken
times using a custom ransomware we developed. It mimicked for the FTL (without SSD-Insider) to handle 4-KB block reads
the common behaviors of well-known ransomwares and in- and writes were 477 ns and 1,372 ns, respectively. The extra
fected larger than 1 GB files at an arbitrary point of time. overheads added by the SSD-Insider detection/recovery algo-
Once SSD-Insider detected the activities of the ransomware, rithms were just 147 ns and 254 ns, respectively. Considering
it stopped servicing writes from the host, asked the user if it that NAND chip’s page-read and page-write latency is 50 µs
would recover the files, recovered infected files if the answer and 500 µs [15], these extra delays account for a negligible
was yes, and asked users to reboot the host. After the reboot, a portion of the total I/O latency – 0.3% for reads and 0.04% for
fsck tool was triggered to find and resolve data inconsistency. writes – and do not affect the user-perceived response times.
After fsck finished, we saw if the file system was still in the
consistent state. We also checked if all the infected files were Garbage collection cost. SSD-Insider recovery algorithm has
rolled back to unencrypted versions. Table II summarizes the to copy invalid pages to keep old versions of data during
results, confirming that infected SSDs successfully returned to GC for data recovery later. Moreover, since those old pages
a consistent status with no encrypted files left. occupy additional space, it would lead to more frequent GC
invocations, which negatively affects both I/O performance
and storage lifetime. In order to assess SSD-Insider under the
TABLE II: A summary of file-system consistency checks worst-case scenario where GC costs are high, we filled up 90%
# of Corruption Files left of the SSD with user files and ran traces on it. As depicted in
Type of corruption Fig. 9, even under the worst-case scenario, the SSD-Insider’s
occurrences not resolved encrypted
No corruption 0 - - FTL required 22% more page copies, on average 4 . For the
Wrong free-block count 100 × × traces except for Compression, VideoEncode, and WannaCry,
Wrong inode-block count 100 × × only a few page copies were observed. This was because they
Free-space bitmap 61 × ×
4 The FTL algorithm used was based on page-level mapping with greedy
C. Overhead evaluation victim selection, which was almost the same as an open-source FTL imple-
mentation in the Linux kernel [11]. Even though detailed architectures of
I/O elapsed time. For the 12 testing traces in Table I, we commercial SSDs are unknown, literature reports that proprietary FTLs are
measured read/write elapsed times increased by SSD-Insider. based on similar schemes [16]. Hence, it may be safe that our experimental
Fig. 8 shows the length of time spent by 1) the FTL codes and setup at least suffices to understand the impact of SSD-Insider GC costs.

8
 TABLE III: DRAM requirements for SSD-Insider servers or block store and prevented malware programs (e.g.,
backdoors and Trojan horses) from being inserted by attack-
Data structure Unit size # of entries DRAM size (MB) ers [30]. It used rule-based policies that triggered alarms when
Hash table 42 Bytes 250,000 10 MB suspicious I/O behaviors were detected. Paul et al. extended
Counting table 12 Bytes 1,000 0.03MB an idea of the above work so that the behavior-based intrusion
Recovery queue 12 Bytes 2,621,440 30 MB
detection was done inside storage device [27]. Our approach
was directly inspired by the ideas of the aforementioned works,
did not require many page copies for cleaning. We also carried but we focused on detecting ransomware behaviors rather than
out experiments with 70% SSD space utilization to understand typical malware (e.g., virus programs). Moreover, we proposed
GC overheads under the average case, and found that extra the overhead-free recovery scheme that took advantage of the
page copies caused by SSD-Insider were almost zero. This physical natures of NAND flash. Park et al. have presented a
indicates that the effect of SSD-Insider on the increase of GC brief concept of self-defensible SSDs, claiming that the backup
costs is negligible. capability of SSDs would be effective to protect user data from
DRAM requirement. For the ransomware detection and re- ransomware attacks [31]. The basic idea of self-defensible
covery, SSD-Insider has to maintain additional data structures, SSDs is similar to that of SSD-Insider, but it presents only
such as a hash table, a counting table, and a recovery queue. idea-sketch but did not explore the ransomware features.
TABLE III lists DRAM required by SSD-Insider. The total size Huang et al. proposed FalshGuard that has a firmware-level
of DRAM needed to run SSD-Insider is 40.03 MB, which is recovery system, but it focused only on recovery process but
an affordable size for modern SSDs typically equipped with not on detection algorithm [32]
more than 1 GB DRAM [17], [18], [19].
VII. C ONCLUSION
VI. R ELATED W ORK In this paper, we have proposed a new set of behavioral
For detection of ransomwares, signature matching is the features of ransomware, which is invariant across various
most popular tool used by many anti-virus software. However, ransomwares and lightweight enough to be used in SSDs. By
an attacker can easily create ransomware variants with different presenting various experimental results, the discovered features
signatures to evade detection. Instead of checking ransomware have been shown to be strong indicators of ransomware
signatures, a file integrity monitor can detect ransomware activity. We also have developed a perfect recovery algorithm
activities. Tripwire is a system file monitoring tool, doing of infected files using the delayed deletion feature of SSD. To
hash comparison for checking illegal modification, but it is not show the feasibility of our techniques, the detection/recovery
appropriate for user files which might change frequently [20]. algorithms were implemented in an open-channel SSD as a
Drastic changes of a user file’s content in a short time period working prototype called SSD-Insider.Our evaluation results
may be a strong indicator for ransomware activities. Also, showed that SSD-Insider was accurate and fast for detection,
encrypted files have very high entropy, but ordinary files not. and it could perfectly recover an infected SSD in a second
CryptoDrop and Unveil monitors in real-time user’s data for without any data loss. We believe that SSD-Insider opens a
changes [6], [21]. They use file type changes, drastic changes new direction of anti-ransomware research – better defense
in file contents, and Shannon entropy as primary indicators to and recovery algorithms on other malicious software would
distinguish ransomware’s activity. It also uses deletion and file be developed based on the similar concept of SSD-Insider,
type funneling of a large number of files as secondary indi- which are left for our future work.
cators. CryptoDrop effectively detected ransomware’s activity,
Acknowledgement. This research was supported by Global
but some of the encrypted files could not be recovered. To
Research Lab. (GRL) Program of the National Research Foun-
detect early before a ransomware encrypts any files, Moore
dation (NRF) funded by Ministry of Science, ICT (Information
proposed to use honeypot [22]. Orman described a monitoring
and Communication Technologies) and Future Planning(NRF-
technique, which observes in real-time repetitive loops that
2016K1A1A2912757). This work was supported in part
both symmetric and public key algorithms such as AES and
by the Basic Science Research Program through the Na-
RSA should have necessarily [23]. However, it should be noted
tional Research Foundation of Korea funded by the Min-
that monitoring calls to encryption libraries is not enough,
istry of Education under Grant NRF-2016R1C1B2011415,
because encryption can be easily implemented using prevailed
and in part by NRF grants NRF-2016K1A1A2912757, NRF-
open source software. Canfora et al. developed detection
2017R1E1A1A01077410, and NSF grant CNS-1809000. Dae-
schemes of ransomware’s abnormal behavior using Hidden
Hun Nyang and Sungjin Lee are the corresponding authors.
Markov Model (HMM) and structural entropy [24]. Cabaj
et al. utilized Software-Defined Network (SDN) to detect
and mitigate ransomware [25]. Continella et al. proposed a R EFERENCES
file-system level solution, called ShieldFS, for ransomware
[1] “Korean web host hands over 1 billion won to ransomware
detection and recovery [26]. To detect ransomware, ShiledFS crooks,” 2017. [Online]. Available: http://www.zdnet.com/article/
monitored various activities and information available at the korean-web-host-hands-over-1-billion-won-to-\\ransomware-crooks/
file system level. [2] C. Everette, “Ransomware: to pay or not to pay?” Computer Fraud &
Security, vol. 2016, no. 4, pp. 8–12, 2016.
Numerous techniques have been studied to defense hacker
[3] “An istr special report: Ransomware and businesses 2016,”
attacks at the level of storage systems [27], [28], [29], [30]. 2016. [Online]. Available: https://www.symantec.com/content/
Pennington et al. proposed a storage-based intrusion detec- en/us/enterprise/media/security response/whitepapers/ISTR2016
tion technique that monitored suspicious activities inside file Ransomware and Businesses.pdf

9
 [4] J. R. Quinlan, “Induction of decision trees,” Mach. Learn., vol. 1, no. 1, tripwire: A file system integrity checker,” in Proceedings of the ACM
pp. 81–106, 1986. Conference on Computer and Communications Security, 1994.
[5] J. Walter, Meet tox: Ransomware for the rest of us. mcafee-labs/meet- [21] A. Kharaz, S. Arshad, C. Mulliner, W. Robertson, and E. Kirda,
tox-ransomware-for-the-rest-of-us/, 2015. [Online]. Available: https: “Unveil: A large-scale, automated approach to detecting ransomware,”
//blogs.mcafee.com/ in Proceedings of the 8th ACM International Conference on Embedded
[6] N. Scaife, H. Carter, P. Traynor, and K. Butler, “Cryptolock (and Software, ser. USENIX Security ’16. USENIX, 2016, pp. 757–772.
drop it): Stopping ransomware attacks on user data,” in Proceedings [22] C. Moore, “Detecting ransomware with honeypot techniques,” in Pro-
of Distributed Computing Systems (ICDCS). 2016 IEEE International ceedings of Cybersecurity and Cyberforensics Conference, 2016.
Conference on, 2016, pp. 303–312. [23] H. Orman, “Evil offspring – ransomware and crypto technology,” IEEE
[7] “Latest security intelligence report shows 24 percent of pcs are Internet Computing, vol. 20, no. 5, pp. 89–94, October 2016.
unprotected,” 2013. [Online]. Available: https://blogs.microsoft. [24] G. Canfora, F. Mercaldo, and C. A. Visaggio, “An hmm and structural
com/blog/2013/04/17/latest-security-intelligence-report-shows-24-\ entropy based detector for android malware: An empirical study,”
\percent-of-pcs-are-unprotected/ Computers & Security, vol. 61, pp. 1–18, 2016.
[8] “Opswat: Antivirus and compromised device report,” [25] K. Cabaj and W. Mazurczyk, “Using software-defined networking for
2015. [Online]. Available: https://www.opswat.com/resources/reports/ ransomware mitigation: The case of cryptowall,” IEEE Network, vol. 30,
antivirus-and-compromised-device-january-2015 no. 6, pp. 14–20, Dec 2016.
[9] National Industrial Security Program Operating Manual (NISPOM), [26] A. Continella, A. Guagnelli, G. Zingaro, G. De Pasquale, A. Barenghi,
Department of Defense, 2006. S. Zanero, and F. Maggi, “Shieldfs: A self-healing, ransomware-aware
[10] Seagate SMART Attribute Specification, Seagate, 2011. filesystem,” in Proceedings of the Annual Conference on Computer
[11] M. Bjørling, J. Gonzalez, and P. Bonnet, “Lightnvm: The linux open- Security Applications, 2016, pp. 336–347.
channel SSD subsystem,” in USENIX Conference on File and Storage [27] A. G. Pennington, J. D. Strunk, J. L. Griffin, C. A. N. Soules,
Technologies (FAST 17), 2017, pp. 359–374. G. R. Goodson, and G. R. Ganger, “Storage-based intrusion detection:
[12] “Virus total.” [Online]. Available: https://www.virustotal.com/ Watching storage activity for suspicious behavior,” in Proceedings of
the Conference on USENIX Security Symposium, 2003, pp. 10–10.
[13] “Virtual gangster.” [Online]. Available: https://github.com/roothaxor/
Ransom [28] G. A. Gibson, D. F. Nagle, K. Amiri, F. W. Chang, E. Feinberg,
H. Gobioff, C. Lee, B. Ozceri, E. Riedel, and D. Rochberg, “A case for
[14] “A poc windows crypt.” [Online]. Available: https://github.com/ network-attached secure disks,” 1996.
mauri870/ransomware
[29] K. R. Butler, S. McLaughlin, and P. D. McDaniel, “Rootkit-resistant
[15] MT29F8G08AAAWP NAND Flash Memory Specification, Micron Tech- disks,” in Proceedings of the ACM Conference on Computer and
nology, Inc., 2012. Communications Security, 2008, pp. 403–416.
[16] F. Chen, D. A. Koufaty, and X. Zhang, “Understanding intrinsic [30] N. R. Paul, “Disk-level behavioral malware detection,” Ph.D. disserta-
characteristics and system implications of flash memory based solid tion, 2008.
state drives,” in Proceedings of the International Joint Conference on
[31] J.-Y. Paik, K. Shin, and E.-S. Cho, “Poster: Self-defensible storage
Measurement and Modeling of Computer Systems, 2009, pp. 181–192.
devices based on flash memory against ransomware,” in Proceedings
[17] Hitachi accelerated flash, Hitachi, 2015. of IEEE Symposium on Security and Privacy, 2016.
[18] Samsung SSD 840 EVO data sheet, rev. 1.1, Samsung, 2013. [32] J. Huang, J. Xu, and X. Xing, “Flashguard: Leveraging intrinsic flash
[19] PS3110 controller, PHISON, 2014. properties to defend against encryption ransomware,” in Proceedings of
[20] G. H. Kim and E. H. Spafford, “The design and implementation of ACM Conference on Computer and Communications Security (CCS),
2017.

10