A preliminary study of the effects of a novice hacker's learning process on a computer hardware and base operating system component performance

Item Type Thesis

Authors Mikijanic, Christine

Rights Attribution-NonCommercial-NoDerivs 3.0 United States

Download date 28/09/2021 04:10:10

Item License http://creativecommons.org/licenses/by-nc-nd/3.0/us/

Link to Item http://hdl.handle.net/20.500.12648/710 A Preliminary Study of the Effects of a Novice Hacker’s Learning Process on a Computer Hardware and Base Operating System Component Performance

By

Christine Mikijanic

In Partial Fulfillment of the Requirement for the Degree of

MASTER OF SCIENCE

In

The Department of Computer Science State University of New York New Paltz, New York 12561

May 2020 A Preliminary Study of the Effects of a Novice Hacker’s Learning Process on a Computer Hardware and Base Operating System Component Performance

Christine Mikijanic State University of New York at New Paltz

______We, the thesis committee for the above candidate for the Master of Science degree, hereby recommend acceptance of this thesis.

CHIRAKKAL EASWARAN Professor Chirakkal Easwaran, Thesis Advisor Computer Science Department, SUNY New Paltz

CHRISTOPHER V. DEROBERTIS Christopher V. Derobertis, Thesis Committee Member IBM Corporation

PAUL CHAUVET Paul Chauvet, Thesis Committee Member Computer Science and Academic Computing, SUNY New Paltz

Approved on 5/13/2020

Submitted in partial fulfillment of the requirements for the Master of Science degree in Computer Science at the State University of New York at New Paltz Dedication

I dedicate this thesis to the people who have supported and believed in me over the past years of my life. There are many friends and loved ones who number among them. Listing them all would make a book in and of itself. However, this especially goes for my parents – the first and foremost people in line. To my mother, I thank you for teaching me determination and courage.

To my father, for his strength and wisdom – and his belief: that as long as there are criminals, there will always be those that fight them. It’s true. The apple really doesn’t fall far from the tree. Acknowledgments

A great number of people contributed to this study through their knowledge, dedication, and guidance. My utmost thanks to Christopher V. DeRobertis, STSM of Secure Engineering Threat and Abuse Case Strategist from IBM, for volunteering his time, energy, and wisdom during this process. I would also like to extend this gratitude to my committee members, Department Chair

Professor Chirakkal Easwaran and Information Security Officer Paul Chauvet from SUNY New

Paltz. Another round of thanks goes to the faculty and staff at the Department of Computer

Science at SUNY New Paltz, with a special thank you to Professor Emeritus Paul Zuckerman.

Finally, to all those who connected with me during the time of this writing to offer their knowledge and support, I offer my thanks and appreciation. iv

Abstract

One of the major problems in computer security today is the mitigation of damage caused by malware. Common approaches for gathering information about this threat have been to investigate and utilize the structure of a malware attack for prevention and reduction of damage, or analysis of the effect of malware originally found in the wild on target computer systems. This thesis provides a means of determining whether or not sufficient information exists to examine the possibility of finding or identifying an inexperienced hacker inside of a computer system.

Analysis of pseudo-ransomware inside a virtual machine was performed, with investigation into the performance of the system’s hardware and base operating system components. It was discovered that CPU load was the core of indicators that displayed the presence of possible ransomware, as it consistently displayed longer process completion times and signs of strain under intensified usage. Furthermore, this factor could be paired with statistics for other areas of the system in order to provide more detail about the attack itself. Contents

Chapter

1 Introduction 1

2 Background 2

2.1 Introduction ...... 2

2.2 Statement of the Problem ...... 3

2.3 Purpose of the Study ...... 4

2.4 Significance of the Study...... 4

2.5 Definition of Terms ...... 4

2.6 Assumptions ...... 9

2.7 Limitations ...... 10

2.8 Delimitations ...... 11

3 Related Work 14

4 Methodology 19

4.1 Introduction ...... 19

4.2 Methodological Approach ...... 20

4.3 Methods of Data Collection ...... 21 4.4 Methods of Analysis ...... 22

4.5 Justification of Methodological Choices ...... 22

5 Research Findings 24

6 Conclusions and Suggestions for Future Research 40

6.1 Summary of Findings ...... 40

6.2 Suggestions for Future Research ...... 40

6.3 Conclusion ...... 42

References 45

Appendix

A Python Code for Pseudo-Ransomware 56

B Python Code for Experiment Mainline 60

C Python Code for Experiment Utilities 68

Tables

Table

1a 50 MB Run Time Deltas, Part 1 ...... 26 1b 50 MB Run Time Deltas, Part 2 ...... 26

2a 100 MB Run Time Deltas, Part 1 ...... 27

2b 100 MB Run Time Deltas, Part 2 ...... 28

Figures

1 Comp. of System CPU Utilization Between a 50MB and a 100MB Run . 25

2 Comp. of User CPU Utilization Between a 50MB and a 100MB Run. . . 25

3 Time Delta for 50MB Experiment Runs...... 27

4 Time Delta for 100MB Experiment Runs...... 28

5 Comparison of Processes Between a 50MB and a 100MB Run ...... 30

6 Comparison of Kernel Entropy Between a 50MB and a 100MB Run . . 31

7 Comparison of Disk Usage Between a 50MB and a 100MB Run . . . . . 31

8 Comparison of Active Memory Between a 50MB and a 100MB Run. . 32

9 Comparison of Available Memory Between a 50MB and a 100MB Run 32

10 Comparison of Memory Percent Available

Between a 50MB and a 100MB Run ...... 33

11 Comparison of Memory Committed as Physical RAM

Between a 50MB and a 100MB Run ...... 33 12 Comparison of Free Memory Between a 50MB and a 100MB Run. . . 34

13 Comp. of Page Tables Accessed Between a 50MB and a 100MB Run 34

14 Comparison of Memory Used Between a 50MB and a 100MB Run. . . 35

15 Comparison of Percent of Memory in Use

Between a 50MB and a 100MB Run ...... 35

16 Comp. of Buffered Memory Between a 50MB and a 100MB Run . . . . 36

17 Comp. of Memory Cashed Between a 50MB and a 100MB Run...... 36

18 Comp. of Inactive Memory Between a 50MB and a 100MB Run . . . . . 37

19 Comp. of Memory Mapped Between a 50MB and a 100MB Run . . . . . 38

20 Comparison of Slab Memory Between a 50MB and a 100MB Run. . . . 38

21 Comp. of Reclaimable Memory Between a 50MB and a 100MB Run. . 39

22 Comparison of Unreclaimable Memory

Between a 50MB and a 100MB Run ...... 39 1

Chapter 1

Introduction

When people talk about computing and cyber attacks, they normally think about the end result. People see the nasty pop-up on their computer, hijacked accounts, and the bills in the mail for services that have been appropriated by the criminals [1]. However, there actually is a process needed to launch a well-defined cyber or malware, attack. Experts are in disagreement over the actual steps, but all of them agree on the general flow. Perhaps one of the most famous outlines of the structure of a malware attack is the Cyber Kill Chain; this particular version was created by Lockheed Martin, in conjunction with the United States Military. It has been adapted into many different forms, but generally breaks down the flow of an attack into seven steps: reconnaissance, weaponization, delivery, exploitation, installation, command and control, actions on objective [2]. When an attack is discussed, the conversation often implicitly references the last five steps. However, the first two steps, reconnaissance and weaponization, are possibly the most important in initializing an attack. This thesis is an investigation of detecting an inexperienced hacker learning through these first steps. 2

Chapter 2

Background

2.1 Introduction

Although it might be possible to detect a hacker at the beginning of the attack, in the reconnaissance state, it is nevertheless exceedingly controversial to implement any kind of tracking mechanism at all. The truth is that the potential for abuse of any laws and regulations passed to monitor the freedom of information is quite high. Any sort of legal actions implemented would have to be delicately enabled, or not at all. Since ‘delicate’ is not exactly a word that is usually used to describe legal processes, the common response for law enforcement and subject matter experts is to refrain from monitoring communications or information access patterns as much as possible. Indeed, true reconnaissance by an experienced hacker is beyond the scope of this work. In general, the complexity of tracking on the defender’s side is increased exponentially due to social, technological and moral constraints. It is thus considered out of reach for all authorities except for government agencies, and sometimes, not even then [3], [4],

[5], [6]. This is unfortunate, since conscious, logical, and equal opportunity in the monitoring of violent material could not only provide alerts for things like potential hackers, but also for issues like school shootings, terrorist attacks, and other violent crimes. It would be best to stop a criminal in the first or second phase of an attack. However, if it is not possible or extremely difficult, for legal or ethical reasons, perhaps it would be best to consider another perspective.

2.2 Statement of the Problem 3

There has been quite a bit of research into finding and capturing criminals who are already performing illegal activities in public and private systems; but unfortunately, this kind of measure is reactionary, not proactive. As technology advances, so too does the crime which utilizes these tools. The process of attribution is incredibly complex for these kinds of crimes [7], and experienced criminals and nation state actors can be all but undetectable [8]. Therefore, it was hypothesized that there might be information which could possibly be used to find and identify the signs of a budding hacker in the system rather than an experienced one that has already launched an attack, which then could be processed, organized, and used to perform a reasonable assessment that could be forwarded to technical experts and law enforcement for further evaluation. If this was truly something that could be accomplished, the data might be enough to determine if a person would be a danger to society. However, all manner of engineers have their own tricks and tools for insuring safety in their product, and clear indications that something malicious is going on in a system are needed. Considering this, there are three areas where security needs to be insured: on the firmware level, the operating system level, and the application level. Over the course of computer history, there have been numerous ways that security has been ensured on these different levels; but nowadays, this has generally been put into practice by the construction of a multitude of tooling and APIs (or Application Programming

Interfaces) for each level, as can be seen with the Linux operating system [9], [10], [11], [12],

[13]. Logically, starting at the most basic components and working through to the most complex is usually an efficient way to address a problem – for computers, that means starting with the firmware or operating system level and moving forward to the applications. Furthermore, it would be best to find and identify the presence of an inexperienced hacker through their 4 malware’s behavior before any significant damage has occurred or in the middle of the malware attack process.

2.3 Purpose of the Study

An experiment will be officially conducted to investigate this problem in the spring semester of 2020 at the State University of New York at New Paltz, as part of the Computer

Science department. The goal of this study is to determine if there is enough information to possibly identify an inexperienced hacker inside of a computer system. This particular study will use the fundamental components of a machine as the investigation area, specifically examining the components near and around border of the firmware and operating system level.

2.4 Significance of the Study

Based on the results gathered from this study, it will be possible to determine whether or not the field of current research around the problem of detecting, identifying, tracking, and locating inexperienced criminals using computer technology can be expanded.

2.5 Definition of Terms

‘in the wild’ – Phrase used to describe any location that is not inside a lab, such as a corporations

servers, an individual’s laptops, a mobile device, and so on [14].

API – Acronym for a software programming tool and technique known as Application

Programming Interface. APIs can be considered the standardized nuts and bolts of the

coding world, and each API is written to accomplish a very specific atomic task that a

programmer would like to accomplish [13]. 5 black hat hacker – A hacker that takes illegal actions to gain access to resources they are not

entitled to work with [15]. blue team – In industry, a group of people that has been directed to defend a target [16]. byte – The main unit of memory inside of a computer, which consists of eight bits. In traditional

computing, there are only two states for a bit, either 0 or 1 [17]. cat (command) – basic Linux command invoking a utility that prints data to standard output,

which is usually set to a text terminal [18].

CPU – A hardware piece of the computer known as the Central Processing Unit; colloquially

thought of as the brain of the computer. Any sort of task that has computations will use

this part of the machine. For instance, any sort of program that has graphics, games, uses

search features, sorting feature, calculations or number crunching, and all sorts of

algorithms in general. Although in most discussions, the word is used in ways that imply

that there is only one CPU in any sort of computer system, there may actually be more

than one CPU. In servers and mainframes, multiple CPUs are the rule rather than the

exception [19]. cybersecurity – A sub-field and set of skills within Computer Science which specifically

explores the methodologies between attacking and defending others using computer

technology [20] [21]. decryption – The process of changing data back into a form that is readable, and can be therefore

be easily used by humans or machines [22]. encryption – The process of changing data into a form that is not readable by humans or

machines [23]. 6 firmware – The layer that translates program code into machine code, connecting the operating

system to the hardware devices [24]. function – A piece of code that is selected and moved out of the main body and invoked via a

specific call, due to the numerous locations where the pattern occurs in the body of the

main program [25]. gigabytes – Unit of memory equal to one billion bytes [26]. hacker – Someone who exploits computer technology in order to gain access to information, or

to perform actions to which they are not authorized [15]. hardware – The physical components of a computer: USB ports, motherboard, and disc drives,

etcetera [27].

I/O – A catch-all acronym for Input-Output. Simplified, this is the area of the computer that

submits data from memory to the CPU, sends it to other regions of memory, transmits it

out of the computer completely, and handles incoming traffic from outside networks.

Using the metaphor of the human body, this section could be thought of as a

conglomeration of all the parts that move material and information around, such as the

circulatory system, nervous system, or the digestive system [28]. interesting – For the purposes of this study, something can be defined as interesting if it defines

behavior which is distinct, unique, and can be noted as outside the norm.

IoT (devices) – Any sort of computational device inserted in a machine that is not traditionally

attached to a computer. This includes washing machines, refrigerators, baby monitors,

security cameras, cars, and so forth [29]. kilobytes – Unit of memory equal to a thousand bytes [17]. 7

Linux – Popular operating system used for both industry and research purposes [30]. load – Colloquial term that refers to the amount of usage of a particular a component of a

computer system [31]. malware – Software program that is specifically designed to perform malicious actions inside of

a computer. There are may types of malware, including back doors, ransomware,

spyware, Trojan horses, viruses, and worms [32]. megabytes – Unit of memory equal to one million bytes [17]. memory – Hardware component where data inside a computer resides [33]. network – I/O links that connect multiple computers to one another [34]. operating system or OS – The layer of the computer that functions as the main interface between

the user and the machine, translating program code into actions and behaviors with which

a human user can understand and interact [35]. pegger – Industry colloquial term for a program that is specifically built to take the load of a

computer from zero to maxed out in a short amount of time. programming language – Set of terms and symbols which together create a human readable

linguistic written communication which can be used to tell a computer to perform

specific actions [36]. pseudo-malware/pseudo-ransomware – A piece of software that is essentially a mock-up, yet it

behaves in a similar fashion and has all of the main characteristics of a true strain of

malware/ransomware. However, it would likely take a sizable amount of effort to

weaponize the program. 8

Python – A popular programming language, commonly used in industry and taught all level of

primary and secondary education institutions [37]. ransomware – Specific type of malware that is built by an attacker to encrypt a user’s personal

files and data [38]. red team – In industry, a group of people that has been given authorization and directed to attack

a target [16]. software – The immaterial parts of a computer; for example, user applications and operating

systems [39]. throttler – Computer industry colloquial term for a program that is specifically built to increase

the load on components in a computer. user space – The region of computer memory allocated for applications, and where those

program execute [40]. virtual machine (VM) – a program that emulates a fully functional, working computer system.

These sorts of systems are directly based off of standard systems that can be found on the

market, and are often substituted for a regular computer system both for private use and

in industry [41]. weaponization – The process of building a piece of ransomware, occasionally to attack a specific

target [2]. white hat hacker – A hacker who is either employed by, or legally permitted to perform attacks

against a certain target. These kinds of hackers are commonly employed by large

corporations and companies in order to test the safety and stability of not only the

products and services sold to the public, but also to discover any sorts of deficiencies 9

within the business’ own computer networks and overall resources [15].

2.6 Assumptions

When doing computer science research, out of all of the operating systems, Linux is usually the platform of choice. This is because it is open source, customizable, and well documented. In the future, all of these characteristics may change when new operating systems are created; however, it is highly likely that Linux will remain as the researcher's favorite as well as the developer's for many years to come [42]. The Linux operating system is employed in a variety of capacities: regular computers such as desktops and laptops, servers, mainframes, and even on smartphones and Internet of Things (or IoT) devices [31], [42]. This study requires emulation of an inexperienced hacker – it is a solid assumption that the individual in question probably would not have access to a high performance or low throughput machine for large scale computing, as these kinds of machines generally have restricted access enforced for both physical and virtual components due to industry regulations. However, the core assumption with this study is that people who are inexperienced make mistakes. There is a wealth of information on this topic in general [43], [44], [45], [46], [47] but the focus for this study was on those learning computer skills and inexperienced hackers in general. Thus, the assumption was made that, like all people learning a new skill, an inexperienced hacker would make mistakes while going through the learning process, thus allowing their efforts to be tracked on the firmware, operating system, or application layer inside of a machine. Also, like most people who are unfamiliar to a task, it was assumed that an inexperienced hacker would use the tools that are most familiar to them – this is something that is well known in other fields. As Abraham Maslow said, in 1966 [48]: “I suppose it is tempting, if the only tool you have is a hammer, to treat 10 everything as if it were a nail”. Furthermore, data analytics is an integral part of modern daily life, and this study was no exception. While system maintenance tasks and other minor procedures might be going on in the background, the overall impact from these processes should be minimal compared to user activity. Furthermore, when examined alone, neither the spikes in

CPU utilization, I/O access patterns, or memory requests can give the full picture. There are many valid reasons why strange behavior may be seen in these areas. For instance, CPU spikes happen all the time when people play games, stream media, and use all types of computation- heavy software [49], [50]. Crypto APIs may be frequently called if someone is studying security, rather than creating malware. Odd access requests may unfortunately mean that the system is poorly regulated or that flawed rules exist. It is the merging, analysis, and conclusions generated from the combined data that might be able to indicate that a hacker is learning in the system.

2.7 Limitations

In order to implement this experiment, an Asus ROG Strix SCAR Edition GL703GS was acquired. The machine was equipped with thirty two gigabytes of memory, two hundred and fifty six gigabytes of solid state storage, and a one terabyte hard disk drive. The machine also comes equipped with an Intel Kaby Lake Core i7-8750H Central Processing Unit or CPU for short [51].

These specifications were chosen because of the amount of storage available. Large amounts of storage combined with powerful central processing units enable the machine to more closely mimic the actual behavior of other machines when using virtual emulators [52]. The base OS used for the experiment was set up as Windows 10. This was chosen due to its general usability and adaptability. VirtualBox version 6.0.14 r133895 (Qt5.6.2) [53] was installed on the machine as a virtualization platform, and one of the Linux brand OSes was selected as the main 11 experiment OS because of the brand's flexibility, detailed and expansive documentation, and open source roots. Ubuntu was chosen as the main operating system type, due to its plethora of monitoring tools. From these base components, a VM was initialized with 4069 Megabytes of base memory, 30 Gigabytes total memory, one CPU core, and a 100% execution cap. The system was updated to Ubuntu 19.10. InfluxDB version 1.7.10, Telegraf 1.14, and Grafana version 6.7.1 were installed. This choice of hardware, operating system and monitoring software, meant that context switching between CPUs or the creation and distribution between multiple threads would not be able to be examined. The small size of the virtual machine also meant that any sort of process that took too much virtual or actual storage might be killed by the operating system, which indeed happened as discussed later.

2.8 Delimitations

As there are a multitude of different kinds of computer attacks [21], to narrow down the scope of the study to a reasonable size, the field of ransomware was picked. Research was completed on the behaviors of crypto-ransomware and its construction, on ease of access for information about cyber attack implantation, the different characteristics of operating system brands on the market, and which brand of operating systems would be best for experiment implementation [54], [55]. An investigation was also conducted in order to learn more about the crypto APIs on the market today, how they function and how they are used by engineers, along with general security software and common industry analysis methods [55]. Furthermore, while an inexperienced hacker might have access to IoT devices, it was decided that the focus of this study would not include these sorts of devices. Also, since the goal was to see if an inexperienced hacker could be tracked, tools and techniques that needed sophisticated skills were 12 ruled out. It was also decided that real malware would not be used in this study, and specifically, that a new piece of ransomware would not be created since this study would be published publicly. This was due to safety concerns; after all, the last thing the world needs is yet another piece of ransomware running roughshod over the internet, plus, this study is meant to add to the knowledge library of cybersecurity experts, not black hat hackers. The pseudo-malware needed to be written in a common programming language taught in many public schools, colleges and universities, and thus be familiar to the vast majority of students in computer science in general, including any inexperienced hacker. So in turn, the programming language chosen for this study was python, which is often used to teach the basics of software engineering and computer science. As for the pseudo-ransomware itself, it was created to model a very simple form of the family—the program grabs a file and moves the contents into storage, deletes the original file, and then encrypts the data using asymmetric encryption. The encrypted data is then written to a new file in place of the original. Although ransomware in the wild may use both symmetric and asymmetric APIs, the pseudo-ransomware was constructed to use asymmetric only. Also, the cryptographic components of the pseudo-malware were open source, and easily accessible (see

Appendix A). In order to remove the chance that background tasks might have an impact on the data due to general damage from wear and tear on the system, the hardware being used for the experiments was acquired as new, specifically for this study. Also, it should be noted that while data was being gathered, there was nothing running on the user space in the VM except for the script used to generate and gather data. Data analysis would be performed to look for specific patterns that had both dips and valleys during psudo-ransomware execution, since the goal was to see the possibility of stating whether or not there is the possibility that there is enough 13 information to find or identify an inexperienced hacker inside of a computer system while the attack is underway. 14

Chapter 3

Related Work

Malware detection is a well defined and a notable research field, with significant advances in the subject. When breaking down ransomware analysis by computer component, detection of malware through the use of a network is a well tread path. Krzysztof Cabaj, Marcin

Gregorczyk, and Wojciech Mazurczyk examined two strains of crypt-ransomware, monitoring

HTTP traffic by breaking down and categorizing data packets based on size and message contents. While they did utilize CPU statistics in their study, this was as a measure of performance. Their experiments proved that it was possible to use machine learning with a software defined network in order to detect the transmission of messages relating to the malware infection process from the infected computer back to the server proxy set up to monitor the ransomware’s progress [56]. Jiaye Pan, Yi Zhuang and Binglin Sun took a different perspective on the issue, instead working on the construction and proposal of a new method for the transmission of network data. They proposed a new protocol, which they call HTTA, in order to secure massive amounts of data flowing between web browsers, and other sorts of network viewing homologous applications. As seen from their use of the keyword ‘neighbor’ in their code, this approach gives a nod to the kNN, or k-Nearest-Neighbor algorithm. No particular strains from the wild, or substitutions were specifically mentioned in their research [57].

In the area of platform-based detection methods, Sangmoon Jung and Yoojae Won conducted their experiments on a Windows system, specifically looking at platform agnostic methods. They proposed a new process for detecting ransomware on any sort of system, based on analysis of header information and the entropy within this contextual metadata. The two used 15 five strains of crypto-ransomware commonly found in the wild at the time of the publication.

Furthermore, as their process examined generated files, it took place within the kernel level of the operating system. However, although the process was CPU focused, it did not take into account any statistics from the CPU as part of the process [58]. Shubair Abdulla and Altyeb

Altaher took a different tact, specifically investigating malware detection on mobile devices, and the Android system. The effectiveness of a distinct classification approach was the target of the research, and they were able to determine that when an inference system called the Information

Grain Ration method was used to select features such as HEAD_PHONE_STATE,

WRITE_APN_SETTINGS, GET_ACCOUNTS, and so on, and an algorithm called the Adaptive

Neuro-Fuzzy Inference System, also known as k-ANFIS, was applied for detection, it was possible to detect the presence of malware with significant accuracy [59]. Nir Nissim and Aviad

Cohen are two of the specialists in virtual machine analysis, proving that it is possible to use memory to identify the state of a virtual machine that may be infected with ransomware. This was done by employing machine learning, and running the data through the algorithm from a volatile image of a VM, an image commonly known as a snapshot. These virtual machines had been infected with real versions of ransomware that have been found in the wild, and it was concluded that it was possible to determine with sufficient accuracy that a VM had been infected with malware. They performed this analysis by using meta-features such as the number of specific types of processes and whether or not they could be displayed by different kinds of process listing tools, the number of services running, and the number of threads [60]. They completed further investigation into detection in VM volatile memory via an algorithm called 16 sequential mining, on trusted system calls with Yuval Lapidot and Yuval Elovici [61]. This VM- based research was expanded by Nir Nissim and Aviad Cohen, with investigation into analysis of memory using a data mining algorithm called the MinHash method [62].

Other research has specifically focused on programs that can be used to detect and analyze malware, or performed direct analysis on the malware programs themselves. An intrusion detection system, or IDS, is a type of program that is specifically employed in order to detect malicious behavior inside of a computer system. Yanping Shen, Kangfeng Zheng,

Chunhua Wu investigated algorithms that could be employed in specific software that can be used during a phase of the infection process. In their study, they performed an analysis of the k-

Nearest-Neighbor formula in comparison to a CCHPSO based approach. The CCHPSO framework they describe utilizes a conglomeration of the binary particle swarm optimization and the hybrid standard particle swarm. Rather than use a strain of malware that can be found in the wild in order to judge the effects on a system itself, the study simulated the behavior of an infected system by employing a standard research data set that is commonly used in order to gauge the effectiveness of intrusion detection systems [63]. Matej Zuzcak, Tomas Sochor and

Milan Zenka focused on Windows-based network intrusion detection systems. Although they included an analysis of CPU load as part of their study, this was mainly as a measure of IDS performance, in conjunction with network traffic [64]. Finally, analyzing the damage after the fact is a valued field as well. Aaron Zimba, Zhaoshun Wang, Hongsong Chen and Mwenge

Mulenga contributed with a study that geared to expand the knowledge base for digital forensics.

The researchers performed an autopsy on different kinds of ransomware and crypto mining malware strains found in the wild. They outlined the taxonomy of the extended family of 17 cryptoviral attacks with a general discussion of environmental factors, before going into detail on construction, specific characteristics of different strains, and attack patterns [65]. Chunhua Xiao,

Lei Zhang, Weichen Liu, Linfeng Cheng, Pengda Li, Yanyue Pan, and Neil Bergmann worked parallel to these veins of study, specifically looking into defensive methods of protection on enterprise-level systems, or in other words, industry-grade computing devices. They describe a stack set-up with encryption integrated into the file system and hardware instructions using a byte-addressable non-volatile memory management scheme, also known as NVM. While their study did not specifically utilize any form of ransomware or malware, due to the use of encryption technologies, the authors employed examination of the CPU cycles in order to evaluate the proposed machine instruction set [66].

There has been research conducted to see if it is possible to identify malware from outside the physical or virtual boundaries of a computer system. Nader Sehatbakhsh, Alireza

Nazari, Monjur Alam, Frank Werner, Yuanda Zhu, Alenka Zajic, and Milos Prvulovic specifically propose a process of detecting malware on devices that may not be accessible by traditional means, such as remotely located embedded systems, Internet of Things devices, and other kinds of resource constrained systems. These kinds of computational systems may not have the memory space for intrusion detection systems, along with other preventative or detective measures. They found that by monitoring the electronic signals emitted from outside of the device, it was possible to pick up the presence of malware. Due to the nature of the study, the authors were monitoring the CPU and electromagnetic impulses, not specifically examining how the CPU, memory and other components were responding inside of the machine. They were looking from an outside position at external forces emitted by an amalgamated whole [67]. 18

Therefore, extensive research has been completed on ransomware’s effect on specific components of a computer system, detection on specific platforms, and platform agnostic methods. Studies have also been conducted to examine the phases of the ransomware infection process, analysis of specific strains of malware, and their effects. However, as all of these studies have used ransomware in the wild, by definition, the indicators and factors profile the work of experienced black hat hackers. Furthermore, while many of these studies have examined network performance, CPU usage, and memory, not one of them directly focused affect of malware on the different parts of the computer and how these components interact under the strain of ransomware. Thus, these studies have led up to the current research. 19

Chapter 4

Methodology

4.1 Introduction

Since this study is based on the use and misuse of cryptology features, by definition, components that examine data that might have information about cryptographic processes must be created first. Before going in to the details of how to track cryptographic misuse, it was first necessary to understand what cryptography actually is. Merriam-Webster says that it is [68]:

“Secret writing”, “The enciphering and deciphering of messages in secret code or cipher”, or

“The computerized encoding and decoding of information”. These definitions, while true, do not actually explain what cryptography means to the computer. Software engineers and developers have their own definition, as can be seen in a web page made by the developers behind

GPGTools, a macOS mail support add-on product [69]. They state, “Cryptography is the science of using mathematics to encrypt and decrypt data”. That means, on a surface level, any action that manipulates cryptographic data is based on mathematical computations. For this experiment, this latter definition is the one that will be used, as it can be seen in practice inside of any computing device or platform. Essentially, when a crypto API service is used to perform a crypto-specific computation, the user gives some sort of data related to cryptographic processes to the API, and the function calls subsequently deeper APIs until it reaches the firmware- hardware area. At this point, the crypto operation is completed down in the CPU, and the result is rippled back up to the API. Like most mathematical computations, this is a CPU heavy operation. As seen, there is very little input-output, or I/O, involved. Whenever a cryptographic computation is executed, there is a noticeable and traceable spike in CPU activity. 20

4.2 Methodological Approach

It was hypothesized that through the use of an operating system monitoring service and basic analytics, it would be possible to locate information that could be used to find and identify the signs of a budding hacker in the system. This kind of information needed to be able to be processed, organized, and used to perform a reasonable assessment that could be forwarded to technical experts and law enforcement for further evaluation. However, the goal of this experiment was not to make working and sellable software or to make and evaluate the effects of functional ransomware, but to prove the hypothesis. That said, there are quite a few operations that need to be completed to make this happen. Pseudo-ransomware was constructed first in order to have usable tool that would be safe to measure the effects of malware. This program took data from a file in a specific folder, copied the information to memory, deleted the original file, encrypted the data and created a new file using the encrypted data. In order to create a more realistic environment, whereby a victim would require the decryption of his or her data, this process was included in the pseudo-ransomware functionality. From there, InfluxDB, Telegraf, and Grafana were installed on a virtual machine. Three kinds of throttlers were constructed—

Internal I/O throttlers, CPU peggers, and external network based I/O throttlers. These groupings were chosen in order to examine not only how the system processed data inside of the machine, but whether or not traffic being sent to and from an external system would affect the results. A script was then constructed which contained eight groups of tests: (1) regular system behavior,

(2) execution of the pseudo-ransomware by itself, (3) a single run of the internal I/O throttlers only, (4) pseudo-ransomware running with internal I/O throttlers running at the same time, (5)

CPU peggers running alone, (6) pseudo-ransomware running with CPU peggers running 21 concurrently, (7) external I/O throttlers executing by themselves, and (8) pseudo-ransomware running with external I/O throttlers running simultaneously. All of this functionality was split off into helper functions, while the first script, which outlined the different sub-experiments contained the mainline program. For simplicity’s sake, the main difference that would be initialized between different runs was hard-coded into one of the helper functions, specifically the function known as prepatoryWork(), which contained an array of the different file sizes that would be generated for each sub-experiments. These arrays would be used during program execution to generate two sets of files, one in kilobytes and one in megabytes. The sizes were chosen so that a power of ten and an increment would be present to be analyzed. Inside of the files themselves, the space was filled with random data generated from the /dev/urandom tool, a ubiquitous special device file that can be found on all UNIX-based operating systems [70]. The different effects on memory, CPU, overall process generation, I/O, disc, kernel, and overall system performance were plotted on a scatter plot with a simple two-dimensional x- and y-axis, one of which was time. The data collected from these runs was then analyzed with the goal of discovering any unusual characteristics, patterns and insights.

4.3 Methods of Data Collection

Before execution, the script was set up with an array of one of three hard-coded parameter arrays: group “1,5,10,50”, group “1,5,10,50,100”, and group “1,5,10,50,100,500”.

Once the parameters for file generation were set, the mainline program was kicked off in a terminal, and permitted to run by itself on the VM until the entire program had finished. No other user programs were executed during this time period, while system maintenance tasks were permitted to run. Over the course of several weeks, the data from ten runs for the sets of group 22

“1,5,10,50” and group “1,5,10,50,100” were collected. Only one run was initiated for the set of

“1,5,10,50,100,500”, since the process running the experiment was killed by the system upon reaching CPU heavy sub-experiments. The data was then extracted from the InfluxDB program, and ported into a spreadsheet format for analysis.

4.4 Methods of Analysis

Analysis of the data fundamentally revolved around the need to remove any random noise that was generated during the run. An average was calculated between the data points of each run, for each grouping of sizes. From there, the averages were calculated to make a graph for different performance areas inside the system, for each of the three sizes. The performance areas chosen were: CPU, disk, Kernel, memory, processes, and overall system usage. Spikes and drops in the data were then correlated with the time that different sub-experiments were run, and conclusions drawn from the specific patterns of execution and system usage generated for each grouping.

4.5 Justification of Methodological Choices

When it came to the size of the files, it was not the particular number that was a factor, but rather the power that was a factor. Also, unlike in most performance experiments, the goal was not to see if the performance of the machine could be optimized for the experiments, but rather to simulate, as close to a natural setting as possible of a computer infected by a malware created by an inexperienced hacker. Because of that, file sizes were specifically chosen that did not revolve around powers of two—or sizes in bytes—but rather sizes that people would expect to see or generate in day to day life. This is due to the fact that, while computers use powers of 23 two, humans typically use powers of ten. For tooling, /dev/urandom was chosen precisely because it is so ubiquitous, and thus for the characteristic of replication of the study, it would be easy to find and use. A script was written, also to increase repeatability. Furthermore, as stated above, pseudo-ransomware was chosen as the driving factor, precisely because the aim was to limit the chances that any of the information used to create, run, or evaluate in this study could be used for nefarious purposes. 24

Chapter 5

Research Findings

There are a number of areas where spikes could be seen in system utilization during the experiment. Staring with CPU, for overall usage, there was specifically heavy usage for the

Number 5 and 6 series experiments. It was possible to see the spike from running them by themselves (5s), and then from concurrent runs of the pseudo-ransomware and the CPU peggers.

Of all of the experiments, 6B was the highest – where dev/urandom and the pseudo-ransomware were run concurrently. It was even possible to see 6A, 6B, and 6C as unique, distinct events in

CPU system usage history (see fig. 1). The same pattern occurred in reverse for user CPU usage.

Furthermore, there was also significant CPU usage for the user during the entire duration of the experiment (see fig.2). This can be labeled as interesting for a number of reasons. First off, while single execution of CPU peggers alone created a short spike (as seen in the 5 series), running the

CPU processes concurrently with the pseudo-ransomware distinctly lengthened the amount of time that the system needed in order to complete the ransomware encryption process. A simple examination of the start and end times of the experiments shows that having two CPU-heavy activities executing at the same time lengthens the execution time of the longer process significantly. When only malware was run in the 50MB scenario, on average it took 27 minutes,

16 seconds and 368.580 milliseconds (see table 1a, table 1b and fig. 3). For the 100 MB scenario, on average it took 1 hour, 8 minutes, 24 seconds and 194.491 milliseconds to complete (see table

2a, table 2b and fig. 4). In the case of Experiment 6A, this time was doubled, for the case of 6B it took a little under one and three quarters time, and for 6C, this floated just under one and a half time. 25 26

Experiment Run Phase 100MB Run 1 100MB Run 2 100MB Run 3 100MB Run 4 100MB Run 5 ExperimentID 1, Time Delta 00:00:15.013244 00:00:15.013312 00:00:15.004299 00:00:15.015427 00:00:15.000849 ExperimentID 2, Time Delta 00:26:58.788967 00:27:30.690428 00:26:56.085313 00:27:16.930372 00:27:30.773946 ExperimentID 3A, Time Delta 00:00:02.035885 00:00:03.032524 00:00:03.040689 00:00:03.031425 00:00:04.039045 ExperimentID 3B, Time Delta 00:00:04.014801 00:00:05.017307 00:00:03.022316 00:00:05.014913 00:00:05.023381 ExperimentID 4A, Time Delta 00:26:59.237621 00:27:27.285665 00:26:54.227298 00:26:58.272378 00:27:07.267016 ExperimentID 4B, Time Delta 00:26:57.232171 00:27:17.276878 00:26:54.248279 00:27:07.262371 00:27:06.244366 ExperimentID 5A, Time Delta 00:00:31.854072 00:00:31.395007 00:00:32.004180 00:00:31.944299 00:00:32.305800 ExperimentID 5B, Time Delta 00:00:06.468021 00:00:06.583405 00:00:06.103812 00:00:06.460775 00:00:06.449618 ExperimentID 5C, Time Delta 00:00:29.571032 00:00:29.378342 00:00:29.563559 00:00:29.543876 00:00:29.644455 ExperimentID 6A, Time Delta 00:55:05.596327 00:54:22.647680 00:54:24.607557 00:54:43.287091 00:55:05.767321 ExperimentID 6B, Time Delta 00:47:45.540247 00:47:49.536236 00:49:01.591711 00:47:00.502835 00:46:59.503698 ExperimentID 6C, Time Delta 00:39:40.140998 00:40:06.145323 00:38:59.118826 00:41:11.229269 00:40:02.200156 ExperimentID 7A, Time Delta 00:00:06.265566 00:00:05.244920 00:00:06.210355 00:00:07.225575 00:00:04.266734 ExperimentID 7B, Time Delta 00:00:02.087460 00:00:04.054264 00:00:02.074521 00:00:04.087248 00:00:06.052065 ExperimentID 7C, Time Delta 00:00:04.587976 00:00:05.258176 00:00:04.572790 00:00:04.605157 00:00:04.590871 ExperimentID 8A, Time Delta 00:27:08.316286 00:27:07.310715 00:27:17.319947 00:30:03.505926 00:27:18.381758 ExperimentID 8B, Time Delta 00:27:12.260217 00:26:57.211667 00:26:56.200529 00:27:34.281392 00:27:05.197679 ExperimentID 8C, Time Delta 00:27:21.492262 00:28:00.511874 00:27:04.508427 00:27:44.524480 00:27:16.447697

Full Run, Time Delta 05:08:18.017316 05:10:16.328618 05:07:57.776042 05:13:17.379678 05:09:28.098592

Table 1a: 50 MB Run Time Deltas, Part 1

Experiment Run Phase 100MB Run 6 100MB Run 7 100MB Run 8 100MB Run 9 100MB Run 10 Average ExperimentID 1, Time Delta 00:00:15.009048 00:00:15.010160 00:00:15.015060 00:00:15.012939 00:00:15.015223 00:00:15.010956 ExperimentID 2, Time Delta 00:27:58.858696 00:26:56.999705 00:27:10.254005 00:27:18.649843 00:27:05.654523 00:27:16.368580 ExperimentID 3A, Time Delta 00:00:02.091322 00:00:02.042706 00:00:03.095391 00:00:02.057122 00:00:03.030767 00:00:02.749688 ExperimentID 3B, Time Delta 00:00:03.014752 00:00:05.019999 00:00:05.021732 00:00:04.016478 00:00:03.014180 00:00:04.217986 ExperimentID 4A, Time Delta 00:27:18.273679 00:26:53.251562 00:27:39.380061 00:26:55.284460 00:26:59.232456 00:27:07.171220 ExperimentID 4B, Time Delta 00:27:23.298452 00:26:53.251562 00:26:56.262287 00:27:05.275334 00:27:01.199386 00:27:04.155109 ExperimentID 5A, Time Delta 00:00:30.783670 00:00:31.917700 00:00:32.152023 00:00:39.599653 00:00:32.310665 00:00:32.626707 ExperimentID 5B, Time Delta 00:00:06.749836 00:00:06.597588 00:00:06.473460 00:00:06.584295 00:00:07.013345 00:00:06.548416 ExperimentID 5C, Time Delta 00:00:30.976408 00:00:29.290531 00:00:29.837713 00:00:29.225698 00:00:29.329748 00:00:29.636136 ExperimentID 6A, Time Delta 00:55:15.160421 00:54:26.862539 00:55:07.767815 00:54:41.644730 00:55:11.490888 00:54:50.483237 ExperimentID 6B, Time Delta 00:48:43.588900 00:46:44.423731 00:47:47.479105 00:47:31.500527 00:47:43.496337 00:47:42.716333 ExperimentID 6C, Time Delta 00:40:32.237795 00:39:34.178261 00:39:14.157893 00:40:07.181052 00:40:37.158684 00:40:00.374826 ExperimentID 7A, Time Delta 00:00:07.231913 00:00:08.190775 00:00:04.221474 00:00:05.238242 00:00:07.280466 00:00:06.137602 ExperimentID 7B, Time Delta 00:00:02.082623 00:00:04.038603 00:00:02.072302 00:00:04.051559 00:00:02.088424 00:00:03.268907 ExperimentID 7C, Time Delta 00:00:04.589176 00:00:04.599058 00:00:04.587187 00:00:04.605666 00:00:04.639868 00:00:04.663593 ExperimentID 8A, Time Delta 00:27:26.315364 00:27:02.294157 00:27:17.329418 00:27:05.306896 00:27:18.369701 00:27:30.445017 ExperimentID 8B, Time Delta 00:27:07.220896 00:27:04.201094 00:26:57.199021 00:26:54.180965 00:27:16.284212 00:27:06.423767 ExperimentID 8C, Time Delta 00:27:17.469471 00:27:01.491504 00:27:04.457161 00:27:07.453631 00:27:15.460808 00:27:19.381731

Full Run, Time Delta 05:12:37.347916 05:06:30.639671 05:08:32.630283 05:08:39.790694 05:10:08.299555 05:09:34.630837

Table 1b: 50MB Run Time Deltas, Part 2 27

Experiment Run Phase 100MB Run 1 100MB Run 2 100MB Run 3 100MB Run 4 100MB Run 5 100MB Run 6 ExperimentID 1, Time Delta 00:00:15.002306 00:00:15.014259 00:00:15.011870 00:00:15.007172 00:00:15.008237 00:00:15.007609 ExperimentID 2, Time Delta 01:07:41.712474 01:08:06.765349 01:08:37.559132 01:08:46.434781 01:08:22.130159 01:08:51.776492 ExperimentID 3A, Time Delta 00:00:02.187085 00:00:02.052723 00:00:01.028951 00:00:04.097027 00:00:01.037136 00:00:01.031530 ExperimentID 3B, Time Delta 00:00:03.015154 00:00:05.018985 00:00:05.018071 00:00:05.016707 00:00:04.016534 00:00:04.018793 ExperimentID 4A, Time Delta 01:09:28.259785 01:08:42.161646 01:08:38.158939 01:07:51.046633 01:08:35.168146 01:08:50.197613 ExperimentID 4B, Time Delta 01:09:22.250461 01:08:29.159031 01:08:49.111689 01:08:17.150582 01:08:25.057365 01:08:52.227188 ExperimentID 5A, Time Delta 00:00:32.496203 00:00:32.402574 00:00:32.095437 00:00:31.820456 00:00:32.029431 00:00:32.807537 ExperimentID 5B, Time Delta 00:00:06.681518 00:00:06.798219 00:00:06.904123 00:00:06.780711 00:00:06.806979 00:00:06.861877 ExperimentID 5C, Time Delta 00:00:29.482382 00:00:29.346737 00:00:28.951313 00:00:29.897942 00:00:29.029825 00:00:29.682121 ExperimentID 6A, Time Delta 02:16:43.893751 02:18:10.202269 02:17:27.542557 02:17:51.057881 02:16:18.319539 02:19:00.138723 ExperimentID 6B, Time Delta 01:58:08.988589 01:59:30.287684 02:00:28.212360 01:59:24.106885 02:00:06.149568 02:00:43.441571 ExperimentID 6C, Time Delta 01:40:18.454200 01:37:08.248364 01:37:08.215397 01:35:25.058299 01:34:57.041399 01:35:31.136344 ExperimentID 7A, Time Delta 00:00:06.198222 00:00:06.926624 00:00:06.257265 00:00:08.220771 00:00:06.177138 00:00:05.270323 ExperimentID 7B, Time Delta 00:00:06.049798 00:00:02.379259 00:00:04.046963 00:00:02.074601 00:00:02.069997 00:00:04.059117 ExperimentID 7C, Time Delta 00:00:04.588646 00:00:04.681321 00:00:04.589260 00:00:04.604329 00:00:04.580739 00:00:04.581826 ExperimentID 8A, Time Delta 01:08:25.236723 01:09:01.409032 01:08:38.264086 01:08:25.246899 01:08:28.218609 01:08:19.314858 ExperimentID 8B, Time Delta 01:08:04.941487 01:16:40.663004 01:07:58.985421 01:08:55.058845 01:08:50.249365 01:07:54.040287 ExperimentID 8C, Time Delta 01:08:12.652162 01:15:36.456004 01:09:00.652666 01:08:36.603277 01:09:20.887947 01:08:52.797285

Full Run, Time Delta 12:50:13.816646 13:05:14.326946 12:50:22.387266 12:47:06.363051 12:46:51.312432 12:50:27.984391

Table 2a: 100 MB Run Time Deltas, Part 1 28

Experiment Run Phase 100MB Run 7 100MB Run 8 100MB Run 9 100MB Run 10 Average ExperimentID 1, Time Delta 00:00:15.015830 00:00:15.014599 00:00:15.011781 00:00:15.014387 00:00:15.010805 ExperimentID 2, Time Delta 01:07:56.557494 01:08:54.838207 01:08:00.888365 01:08:43.282461 01:08:24.194491 ExperimentID 3A, Time Delta 00:00:03.033641 00:00:04.029510 00:00:04.032761 00:00:03.031300 00:00:02.556166 ExperimentID 3B, Time Delta 00:00:05.015832 00:00:04.022310 00:00:03.014507 00:00:03.017073 00:00:04.117397 ExperimentID 4A, Time Delta 01:08:52.226718 01:07:46.183717 01:07:47.196528 01:08:35.222903 01:08:30.582263 ExperimentID 4B, Time Delta 01:08:20.138570 01:08:05.120391 01:07:44.171512 01:08:05.190189 01:08:26.957698 ExperimentID 5A, Time Delta 00:00:33.109445 00:00:32.937419 00:00:32.123722 00:00:32.305148 00:00:32.412737 ExperimentID 5B, Time Delta 00:00:06.999438 00:00:06.986904 00:00:06.886878 00:00:06.763876 00:00:06.847052 ExperimentID 5C, Time Delta 00:00:29.949141 00:00:29.533959 00:00:29.368433 00:00:29.537205 00:00:29.477906 ExperimentID 6A, Time Delta 02:19:19.614793 02:16:13.731834 02:16:08.546340 02:17:34.253161 02:17:28.730085 ExperimentID 6B, Time Delta 01:58:50.354524 01:57:04.146870 01:56:59.227782 01:57:01.159715 01:58:49.607555 ExperimentID 6C, Time Delta 01:35:55.190014 01:35:54.221009 01:34:34.115654 01:35:12.187309 01:36:12.386799 ExperimentID 7A, Time Delta 00:00:07.202520 00:00:07.246758 00:00:04.191574 00:00:07.198589 00:00:06.488978 ExperimentID 7B, Time Delta 00:00:02.086079 00:00:04.080165 00:00:04.092223 00:00:04.040669 00:00:03.497887 ExperimentID 7C, Time Delta 00:00:04.664303 00:00:04.591648 00:00:04.610075 00:00:04.585982 00:00:04.607813 ExperimentID 8A, Time Delta 01:08:31.330082 01:08:07.356291 01:08:23.390509 01:08:22.307381 01:08:28.207447 ExperimentID 8B, Time Delta 01:08:17.105977 01:08:31.081231 01:08:03.057975 01:07:58.044252 01:09:07.322784 ExperimentID 8C, Time Delta 01:08:24.835114 01:08:28.775907 01:08:34.732203 01:09:32.916474 01:09:28.130904

Full Run, Time Delta 12:48:07.360594 12:42:34.088901 12:39:59.819839 12:44:45.045924 12:48:34.250599

Table 2b: 100 MB Run Time Deltas, Part 2 29

It can be seen that this had a distinct impact on the number of threads in operation at any given time—for each execution of the full group of experiments, the number of processes repeatedly jumped to three, and notably rose to four, during the execution of sub-experiments 6B and 6C

(see fig. 5). This means that rather than have the CPU finish the execution of one task and move onto another, a situation is generated where both processes are actively battling for control over the single CPU. This fight is escalated to the point that extra processes will be generated to handle the load. In fact, kernel entropy spikes to a plateau during the execution of 6C, reaching approximately 3.7 kilobytes (see fig. 6). A decrease in free disk space can already be noted upon the execution of 4B, where a cat command of a nearby directory is executed during the pseudo- ransomware execution. From there, the free space steadily declines, before entering a turbulent period around the execution of experiment 6B and 6C where space is allocated and freed at a rapid pace (see fig. 7). As memory has been evaluated thoroughly in prior research listed above, this study exclusively evaluated whether or not there was any intersection of heavy memory usage activity with CPU usage. Looking at active memory during 6A and 6B, there are clear indicators that differentiate these sub-experiments from general usage during the rest of the experiment. The same pattern can be noted with active (see fig. 8), available memory (see fig. 9), available memory percent (see fig. 10), committed as (see fig. 11), free (see fig. 12), paged tables

(see fig. 13), used (see fig. 14), and used percent (see fig. 15). Therefore, as 6A is a large user mathematical calculation, and 6B uses an internal CPU-heavy tool, it is possible to note that if internal CPU-heavy system processes are being used at the same time as the pseudo-ransomware is executing, there is a notable effect on memory utilization. It is also possible to see in buffered memory, that there is a sharp decrease upon the start of experiment 6A. Buffered memory starts 30 slowly recovering, and grows during experiment 6B, but was not able to fully stabilize until long after the full experiment run was completed (see fig. 16). 31

As referenced on page 29, entropy spikes to 3.7 kilobytes.

Decrease in free disk space after experiment 4B, and then continues to decline further for the 6 series experiments. 32

A similar pattern occurs for active memory (Figure 8) with the impact shown in a similar pattern in reverse for available memory (Figure 9). 33

A similar pattern as shown active memory on page 32 occurs for both memory percent available (Figure 10), and memory committed as physical RAM (Figure 11). 34

A similar pattern as discussed on page 29, and shown on previous pages 32 and 33 occurs for free memory (Figure 12) and page tables accessed (Figure 13). 35

A similar pattern as discussed on page 29, and shown on previous pages 32, 33 and 34 occurs for memory used (Figure 14) and percent of memory in use (Figure 15). 36

As is discussed on page 29, and will be discussed later on page 37, a new pattern appears for buffered memory (Figure 16), however the pattern is repeated in memory cached (Figure 17). 37

Permutations of this pattern can be seen in cached memory (see fig. 17), inactive memory (see fig. 18), mapped (see fig. 19), slab (see fig. 20), system reclaimable (see fig. 21) and system unreclaimable (see fig. 22). Also noteworthy was that a run containing a file of 500 MB was killed by python. It is unknown whether or not this was a proportional hit to memory based on

CPU usage. It is suspected that this was a self-defense mechanism due to memory starvation by the operating system or python, however, further examination of this aspect was beyond the scope of this research. 38

As discussed on page 37, the pattern is repeated in mapped memory (Figure 19) and slab memory (Figure 20) 39

As discussed on page 37, the pattern is repeated in reclaimable memory (Figure 21) and unreclaimable memory (Figure 21) 40

Chapter 6

Conclusions and Suggestions for Future Research

6.1 Summary of Findings

As a result of this study, it is reasonable to assert that it might be possible to pick up the presence of ransomware by using CPU monitoring, especially if the system is one that is commonly used to process CPU heavy tasks. There is also plenty of evidence to suggest that it is possible to not only examine the aftereffects of ransomware, but to monitor its progress as the attack is ongoing—especially if an inexperienced hacker developed the malware strain. If CPU- bound processes are taking notably longer than usual (as seen from the ransomware itself), this may be an indicator that the system is infected, and the CPU is struggling to handle loads. It may be prudent if there is excessive and unexpected CPU usage for the system to be shutdown, and an administrator evaluate the situation for potential ransomware. Furthermore, CPU usage statistics can be paired with memory, disk, kernel and process statistics as anchors in order to provide secondary validation that malware is present in the system and to track its progress. User CPU usage is important as well, since there may be an occurrence of one user stealing all of the CPU cycles when ransomware is present on the system – or heavy CPU usage from a user ID when that is not habitual behavior (such as in the case of a hijacked ID).

6.2 Suggestions for Future Research

There are many possibilities that can be explored in further investigations in this topic.

First and foremost, this particular study can be expanded to to see further correlation between the different elements. As this was simply a preliminary investigation to determine data quality and 41 the plausibility of making further hypotheses, the space that was examined was rather broad as well as being a fairly cursory affair. A deeper look into the material that was used for this particular study would yield even more data, and that would further delineate the subject matter.

Moreover, there should be additional research on how ransomware affects CPU utilization specifically, as well as deeper inquiries into how ransomware affects the interlocking components of the CPU, I/O and the memory in different permutations. This study was conducted on a VM system with only one CPU. As previously noted, in an industry setting, multiple CPUs are standard in computer system setups. For example, an IBM z machine actually has the space for two kinds of crypto-specifc CPUs. The first one, or CPACF, is built directly into the machine and sits around relatively close to the data. It is not a particularly strong crypto processor in comparison to other kinds of enterprise hardware components, but it is relatively stable and does an efficient job of handling cryptographic and security operations [71], [72]. The second crypto card, called the HSM or the Hardware Security Module, is an add-on that can be connected to the machine [73], [74]. Unlike CPACF, the HSM is incredibly powerful, but since it sits away from the data, additional I/O is necessary in order to reach the card. This means that

CPACF is better for data processing that only requires quick, brief bursts of crypto utilization that needs a lot of I/O, while the HSM is better for material that needs an extensive amount of crypto operations. CPACF is there by default. The HSM is not. In this sort of scenario, if a machine was infected with ransomware, the additional load would be transferred to the HSM.

This study suggest that even with a dedicated cryptographic coprocessor, the increase to the CPU load would affect regular processing in this additional CPU, as well as be able to be monitored and tracked as distinct events. However, additional research is needed to confirm this hypothesis. 42

In that vein, this particular study was meant to explore the possibility of monitoring. There should also be research into the possibility that these factors could be used to automate safety procedures and preventative measures in the case that there could be an issue with the machine.

For example, if the system can freeze tasks that are behaving oddly according to usage statistics, and flag an operator to investigate if it is due to potential malware on the machine. On top of that, this particular study was constructed to look at crypto-ransomware—a very small area of malware. It would be highly profitable to make an inquiry as to whether or not there are specific usage patterns which can be used as early warning signs with other strains of malware. Lastly, this study was particularly looking at the results of an inexperienced hacker’s mistakes, not the kinds of mistakes that could or would be made. It would be beneficial for further research to be conducted into the topic of learning behaviors and errors of inexperienced hackers. Moreover, while this study noted that processes were killed during attempts to work with large files, this factor was not one of the main scopes of the research. It would behoove further study to examine this factor, and it’s correlation with malware.

6.3 Conclusion

The field of cybersecurity is ever-evolving, constantly shifting and twisting as the tools used for the battle between attackers and defenders are broken, built and tested. It is highly unlikely that the criminals will cease and desist. The FBI’s Internet Crimes Complaint center (or

IC3 2019) Internet Crime Report indicates the opposite – in no uncertain terms, cyber crime is on the rise. For ransomware alone, the FBI noted losses of more than eight-point-nine billion dollars of financial loss for victims who reported “a ransomware event” [75]. The National

Cybersecurity Center of Excellence released a report about measures against ransomware in 43 conjunction with the National Institute of Standards and Technology in January of 2020.

However these are measure that can be in defense and resolution of the situation after the infection has already occurred [76]. By sheer necessity, in the future those on the side of the law will be forced to think of unconventional ways in order to gain the upper hand. Traditionally, the role of testing and defending a system’s security set up has been split into two teams: the red team and the blue team. In this day and age, the industry is also seeing the arrival of a new team called the purple team, where the members take turns with the duties of both the red and blue team, switching sides in order to familiarize themselves with and implement both processes [16].

Cybersecurity experts are already starting to think outside the box. White hat hackers are usually involved with these groups as members of a red team. However, the grouping of hackers is not strictly separated, either. While there are individuals that attempt to strictly conform to either the white hat or the black hat perspectives, there are also people as part of a third group – the grey hat hackers, who float back and forth and skirt the line between the two camps. Grey hat hackers may not ask for permission before investigating vulnerabilities or defects in a system, and if the party that owns the vulnerability does not respond when the individual reaches out to report the issue, the grey hat hacker may post the vulnerability in a public location online [15]. While their intentions might be considered good, this behavior can cause chaos and unintended negative outcomes. Therefore, it would probably be best to channel these kinds of worthy aims in a positive direction while these individuals are still learning their craft. This thesis addressed an unseasoned hacker’s potential to interfere with the functioning of a computer system in general, and indicated that it might be possible to locate these kinds of individuals inside of a targeted system. It is important to recognize that computers come in all shapes in sizes, and therefore 44 people have different avenues in which to learn and cause disturbances. Computers are such a fundamental part of our daily lives, that it is unimaginable to consider a world where we would be without them. Journalist Brian Krebs specializes in technology and cybersecurity investigative reporting. His advice to all computer users and technology service providers can be distilled into one sentence [77]: “Assume you are compromised”. At this point, it would behoove cybersecurity experts to be looking ahead. There has been extensive research into stopping, tracking, and locating accomplished criminals that use computers as their modus operandi. It is time to investigate the potential in identifying and stopping this kind of behavior before it becomes criminalized. 45

References

[1] A. Smith, “Americans' views about cybersecurity policy,” Pew Research Center: Internet,

Science & Tech, 26-Jan-2017. [Online]. Available:

https://www.pewresearch.org/internet/2017/01/26/3-attitudes-about-cybersecurity-policy/.

[Accessed: 31-Mar-2020].

[2] “Cyber Kill Chain® | Lockheed Martin,” Lockheed Martin Corporation | Lockheed Martin.

[Online]. Available: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-

chain.html. [Accessed: 31-Mar-2020].

[3] R. A. Grimes, “Why Internet crime goes unpunished,” CSO | Security news, features and

analysis about prevention, protection and business innovation., 10-Jan-2012. [Online].

Available: https://www.csoonline.com/article/2618598/why-internet-crime-goes-

unpunished.html. [Accessed: 31-Mar-2020].

[4] K. B. Williams, “Judges struggle with cyber crime punishment,” TheHill, 09-Jan-2016.

[Online]. Available: https://thehill.com/policy/cybersecurity/265285-judges-struggle-with-

cyber-crime-punishment. [Accessed: 31-Mar-2020].

[5] M. Eoyang, A. Peters, I. Mehta, and B. Gaskew, “To Catch a Hacker: Toward a

comprehensive strategy to identify, pursue, and punish malicious cyber actors – Third

Way,” Third Way, 29-Oct-2018. [Online]. Available: https://www.thirdway.org/report/to-

catch-a-hacker-toward-a-comprehensive-strategy-to-identify-pursue-and-punish-malicious-

cyber-actors. [Accessed: 31-Mar-2020].

[6] B. Schneier, “Why proving source of a cyberattack is so damn difficult,” CNN - Breaking

News, Latest News and Videos, 06-Jan-2017. [Online]. Available: 46

https://www.cnn.com/2017/01/05/opinions/proving-source-of-dnc-hacks-difficult-opinion-

schneier/index.html. [Accessed: 31-Mar-2020].

[7] R. A. Grimes, “Why it's so hard to prosecute cyber criminals,” CSO | Security news, features

and analysis about prevention, protection and business innovation., 06-Dec-2016. [Online].

Available: https://www.csoonline.com/article/3147398/why-its-so-hard-to-prosecute-cyber-

criminals.html. [Accessed: 31-Mar-2020].

[8] “How Do Cybercriminals Get Caught?,” Official Site | Norton™ - Antivirus & Anti-Malware

Software, 2020. [Online]. Available: https://us.norton.com/internetsecurity-emerging-

threats-how-do-cybercriminals-get-caught.html. [Accessed: 31-Mar-2020].

[9] “Linux Firmware API - The Linux Kernel documentation,” The Linux Kernel Archives.

[Online]. Available: https://www.kernel.org/doc/html/v4.14/driver-api/firmware/index.html.

[Accessed: 31-Mar-2020].

[10] “The Linux Kernel API,” The Linux Kernel Archives. [Online]. Available:

https://www.kernel.org/doc/htmldocs/kernel-api/. [Accessed: 31-Mar-2020].

[11] P. Gazarov, “What is an API? In English, please.,” freeCodeCamp.org: Learn to code, 19-

Dec-2019. [Online]. Available: https://www.freecodecamp.org/news/what-is-an-api-in-

english-please-b880a3214a82/. [Accessed: 31-Mar-2020].

[12] C. Hoffman, “What Is an API?,” How-To Geek - We Explain Technology, 21-Mar-2018.

[Online]. Available: https://www.howtogeek.com/343877/what-is-an-api/. [Accessed: 31-

Mar-2020].

[13] “API Definition,” The Tech Terms Computer Dictionary, 20-Jun-2016. [Online]. Available:

https://techterms.com/definition/api. [Accessed: 31-Mar-2020]. 47

[14] M. Rouse, “What is in the wild? - Definition from WhatIs.com,” SearchSecurity -

TechTarget, Sep-2005. [Online]. Available: https://searchsecurity.techtarget.com/definition/

in-the-wild. [Accessed: 31-Mar-2020].

[15] “What is the Difference Between Black, White and Grey Hat Hackers?,” Official Site |

Norton™ - Antivirus & Anti-Malware Software. [Online]. Available:

https://us.norton.com/internetsecurity-emerging-threats-what-is-the-difference-between-

black-white-and-grey-hat-hackers.html. [Accessed: 31-Mar-2020].

[16] M. Talon, “Security in Plain English: What are Red, Blue, and Purple Teams?,”

SecureAuth: Multi-Factor Authentication, Adaptive Authentication, 21-Mar-2018. [Online].

Available: https://www.secureauth.com/blog/security-plain-english-what-are-red-blue-and-

purple-teams-0. [Accessed: 31-Mar-2020].

[17] “Byte Definition,” The Tech Terms Computer Dictionary, 02-May-2019. [Online].

Available: https://techterms.com/definition/byte. [Accessed: 31-Mar-2020].

[18] “Cat command in Linux with examples,” GeeksforGeeks | A computer science portal for

geeks, 15-May-2019. [Online]. Available: https://www.geeksforgeeks.org/cat-command-in-

linux-with-examples/. [Accessed: 31-Mar-2020].

[19] “CPU (Central Processing Unit) Definition,” The Tech Terms Computer Dictionary, 11-Jul-

2014. [Online]. Available: https://techterms.com/definition/cpu. [Accessed: 31-Mar-2020].

[20] “Security Tip (ST04-001),” What is Cybersecurity? | CISA, 06-May-2009. [Online].

Available: https://www.us-cert.gov/ncas/tips/ST04-001. [Accessed: 31-Mar-2020].

[21] A. G. Johansen, “What is cyber security? What you need to know,” Official Site | Norton™

- Antivirus & Anti-Malware, 2020. [Online]. Available: 48

https://us.norton.com/internetsecurity-malware-what-is-cybersecurity-what-you-need-to-

know.html. [Accessed: 31-Mar-2020].

[22] “What is Decryption?,” Computer Hope's Free Computer Help, 26-Apr-2017. [Online].

Available: https://www.computerhope.com/jargon/d/decrypti.htm. [Accessed: 31-Mar-

2020].

[23] “Encryption Definition,” The Tech Terms Computer Dictionary, 11-Nov-2014. [Online].

Available: https://techterms.com/definition/encryption. [Accessed: 31-Mar-2020].

[24] “Firmware Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/firmware. [Accessed: 31-Mar-2020].

[25] “Function Definition,” The Tech Terms Computer Dictionary, 28-Dec-2010. [Online].

Available: https://techterms.com/definition/function. [Accessed: 31-Mar-2020].

[26] “Gigabyte Definition,” The Tech Terms Computer Dictionary, 26-Feb-2013. [Online].

Available: https://techterms.com/definition/gigabyte. [Accessed: 31-Mar-2020].

[27] “Hardware Definition,” The Tech Terms Computer Dictionary, 05-Dec-2006. [Online].

Available: https://techterms.com/definition/hardware. [Accessed: 31-Mar-2020].

[28] “I/O (Input/Output) Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/io. [Accessed: 31-Mar-2020].

[29] “Internet of Things Definition,” The Tech Terms Computer Dictionary, 16-Jan-2015.

[Online]. Available: https://techterms.com/definition/internet_of_things. [Accessed: 31-

Mar-2020].

[30] “Linux Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/linux. [Accessed: 31-Mar-2020]. 49

[31] Praveen, “What exactly is a load average?,” Linux Tech Support, 23-Oct-2008. [Online].

Available: http://linuxtechsupport.blogspot.com/2008/10/what-exactly-is-load-average.html.

[Accessed: 31-Mar-2020].

[32] “Malware Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/malware. [Accessed: 31-Mar-2020].

[33] “Memory Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/memory. [Accessed: 31-Mar-2020].

[34] “Network Definition,” The Tech Terms Computer Dictionary, 19-Jan-2018. [Online].

Available: https://techterms.com/definition/network. [Accessed: 31-Mar-2020].

[35] “Operating System Definition,” The Tech Terms Computer Dictionary, 23-Jul-2016.

[Online]. Available: https://techterms.com/definition/operating_system. [Accessed: 31-Mar-

2020].

[36] “Programming Language Definition,” The Tech Terms Computer Dictionary, 23-Sep-2011.

[Online]. Available: https://techterms.com/definition/programming_language. [Accessed:

31-Mar-2020].

[37] “Python Definition,” The Tech Terms Computer Dictionary, 15-Jun-2010. [Online].

Available: https://techterms.com/definition/python. [Accessed: 31-Mar-2020].

[38] “Ransomware Definition,” The Tech Terms Computer Dictionary. [Online]. Available:

https://techterms.com/definition/ransomware. [Accessed: 31-Mar-2020].

[39] “Software Definition,” The Tech Terms Computer Dictionary, 05-Dec-2006. [Online].

Available: https://techterms.com/definition/software. [Accessed: 31-Mar-2020].

[40] “User Space Definition,” The Tech Terms Computer Dictionary, 31-Oct-2017. [Online]. 50

Available: https://techterms.com/definition/user_space. [Accessed: 31-Mar-2020].

[41] “Virtual Machine Definition,” The Tech Terms Computer Dictionary, 21-Sep-2018.

[Online]. Available: https://techterms.com/definition/virtual_machine. [Accessed: 31-Mar-

2020].

[42] “Linux Case Study - The Linux Foundation,” The Linux Foundation – Supporting Open

Source Ecosystems, 2020. [Online]. Available:

https://www.linuxfoundation.org/projects/case-studies/linux/. [Accessed: 31-Mar-2020].

[43] “Why inexperienced people make mistakes,” Med League Legal Nurse consultant &

medical expert witness, 26-Jan-2010. [Online]. Available:

https://www.medleague.com/why-inexperienced-people-make-mistakes-expert/. [Accessed:

31-Mar-2020].

[44] “Learning by Making Mistakes - Teacher Buddy Helps,” Search Results Web Result with

Site Links Teacher Buddy Helps - Where Teachers Thrive and Learning Grows, 2020.

[Online]. Available: https://teacherbuddyhelps.com/classroom-management/learning-by-

making-mistakes/. [Accessed: 31-Mar-2020].

[45] R. Curwin, “It's a Mistake Not to Use Mistakes as Part of the Learning Process,” Edutopia:

Home, 28-Oct-2014. [Online]. Available: https://www.edutopia.org/blog/use-mistakes-in-

learning-process-richard-curwin. [Accessed: 31-Mar-2020].

[46] A. Morin, “5 Ways To Turn Your Mistake Into A Valuable Life Lesson,” Forbes, 17-Jul-

2017. [Online]. Available: https://www.forbes.com/sites/amymorin/2017/07/17/5-ways-to-

turn-your-mistake-into-a-valuable-life-lesson/#40999c811c01. [Accessed: 31-Mar-2020].

[47] A. L. Eva, “Why We Should Embrace Mistakes in School,” Greater Good: The Science of a 51

Meaningful Life - UC Berkeley, 28-Nov-2017. [Online]. Available:

https://greatergood.berkeley.edu/article/item/why_we_should_embrace_mistakes_in_school.

[Accessed: 31-Mar-2020].

[48] A. H. Maslow, The Psychology of Science: A Reconnaissance. New York: Harper and Row,

1966, pp 15.

[49] B. Hale, “7 CPU Intensive Games for Benchmarking Your CPU,” Tech Guided | Tech

Guides, Reviews, & Info, 29-Apr-2019. [Online]. Available: https://techguided.com/most-

cpu-intensive-games/. [Accessed: 31-Mar-2020].

[50] U. Asim, “The Most CPU-Intensive Games and Software for CPU Testing,” The Tech

Lounge: Your Guide in a World of Tech, Apps and Soft, 17-Jun-2019. [Online]. Available:

https://www.thetechlounge.com/blog/cpu-intensive-games-and-software/. [Accessed: 31-

Mar-2020].

[51] A. Girbea, “Asus ROG Strix GL703GS SCAR Edition - i7-8750H, GTX 1070 and 17-inch

screen with GSync,” UltrabookReview.com - Ultrabook Reviews 2020, Comparisons and

News, 21-Jan-2019. [Online]. Available: https://www.ultrabookreview.com/19927-review-

asus-rog-strix-gl703/. [Accessed: 31-Mar-2020].

[52] D. Davis, “10 Steps to Increase VMware System Performance,” Petri - IT Knowledgebase,

08-Jan-2009. [Online]. Available:

https://www.petri.com/virtual_increase_vmware_performance. [Accessed: 31-Mar-2020].

[53] “Downloads – Oracle VM VirtualBox,” Oracle VM VirtualBox. [Online]. Available: https://

www.virtualbox.org/wiki/Downloads. [Accessed: 31-Mar-2020].

[54] P. Zuckerman, “Independent Study in Computer Science,” in Independent Study in 52

Computer Science, 2019.

[55] P. Chauvet, “Independent Study in Computer Science,” in Independent Study in Computer

Science, 2019.

[56] K. Cabaj, M. Gregorczyk, and W. Mazurczyk, “Software-defined networking-based crypto

ransomware detection using HTTP traffic characteristics,” Computers & Electrical

Engineering, vol. 66, pp. 353–368, 2018. [Online]. ScienceDirect.

[57] J. Pan, Y. Zhuang, and B. Sun, “Efficient and Transparent Method for Large-Scale TLS

Traffic Analysis of Browsers and Analogous Programs,” Security and Communication

Networks, vol. 2019, pp. 1–22, 2019. [Online]. Gale OneFile.

[58] S. Jung and Y. Won, “Ransomware detection method based on context-aware entropy

analysis,” Soft Computing, vol. 22, no. 20, pp. 6731–6740, 2018. [Online]. EBSCOhost.

[59] S. Abdulla and A. Altaher, “Intelligent Approach for Android Malware Detection,” KSII

Transactions on Internet and Information Systems, vol. 9, no. 8, pp. 2964–2983, 2015.

[Online]. Gale OneFile.

[60] A. Cohen and N. Nissim, “Trusted detection of ransomware in a private cloud using

machine learning methods leveraging meta-features from volatile memory,” Expert Systems

with Applications, vol. 102, pp. 158–178, 2018. [Online]. ScienceDirect.

[61] N. Nissim, Y. Lapidot, A. Cohen, and Y. Elovici, “Trusted system-calls analysis

methodology aimed at detection of compromised virtual machines using sequential mining,”

Knowledge-Based Systems, vol. 153, pp. 147–175, 2018. [Online]. ScienceDirect.

[62] N. Nissim, O. Lahav, A. Cohen, Y. Elovici, and L. Rokach, “Volatile memory analysis

using the MinHash method for efficient and secured detection of malware in private cloud,” 53

Computers & Security, vol. 87, 2019.

[63] Y. Shen, K. Zheng, C. Wu, and Y. Yang, “A Neighbor Prototype Selection Method Based

on CCHPSO for Intrusion Detection,” Security and Communication Networks, vol. 2019,

pp. 1–9, 2019. [Online]. Gale OneFile.

[64] M. Zuzčák, T. Sochor, and M. Zenka, “Intrusion Detection System for Home Windows

based Computers,” KSII Transactions on Internet and Information Systems, vol. 13, no. 9,

pp. 4706-4726, 2019. [Online]. Gale OneFile.

[65] A. Zimba, Z. Wang, H. Chen, and M. Mulenga, “Recent Advances in Cryptovirology: State-

of-the-Art Crypto Mining and Crypto Ransomware Attacks,” KSII Transactions on Internet

and Information Systems, vol. 13, no. 6, pp. 3258-3279, 2019. [Online]. Gale OneFile.

[66] C. Xiao, L. Zhang, W. Liu, L. Cheng, P. Li, Y. Pan, and N. Bergmann, “NV-eCryptfs:

Accelerating Enterprise-Level Cryptographic File System with Non-Volatile Memory,”

IEEE Transactions on Computers, vol. 68, no. 9, pp. 1338–1352, Jan. 2019. [Online]. IEEE

Computer Society Digital Library.

[67] N. Sehatbakhsh, A. Nazari, M. Alam, F. Werner, Y. Zhu, A. Zajic, and M. Prvulovic,

“REMOTE: Robust External Malware Detection Framework by Using Electromagnetic

Signals,” IEEE Transactions on Computers, vol. 69, no. 3, pp. 312–326, Jan. 2020.

[Online]. IEEE Computer Society Digital Library.

[68] “Cryptography | Definition of Cryptography by Merriam-Webster,” Search Results Web

Result with Site Links Dictionary by Merriam-Webster: America's most-trusted online

dictionary. [Online]. Available: https://www.merriam-webster.com/dictionary/cryptography.

[Accessed: 31-Mar-2020]. 54

[69] “Introduction to Cryptography / Tutorials / Knowledge Base - GPGTools Support,”

GPGTools Support: Welcome. [Online]. Available: https://gpgtools.tenderapp.com/kb/how-

to/introduction-to-cryptography. [Accessed: 01-Apr-2020].

[70] “urandom(4): kernel random number source devices - Linux man page,” die.net. [Online].

Available: https://linux.die.net/man/4/urandom. [Accessed: 01-Apr-2020].

[71] “CP Assist for Cryptographic Functions (CPACF),” IBM Knowledge Center, 2014.

[Online]. Available:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.csfb3

00/csfb3za218.htm. [Accessed: 01-Apr-2020].

[72] “Protected-key CPACF,” IBM - United States. [Online]. Available:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.csfb500/

a_Protected_key_CPACF.htm. [Accessed: 01-Apr-2020].

[73] “Hardware Security Module - Overview,” IBM - United States. [Online]. Available: https://

www.ibm.com/cloud/hardware-security-module. [Accessed: 01-Apr-2020].

[74] “4767 x64 CCA releases,” IBM - United States. [Online]. Available:

https://www.ibm.com/security/cryptocards/pciecc2/releases. [Accessed: 01-Apr-2020].

[75] IC3 2019 Internet Crime Report. Cybersecurity and Infrastructure Security Agency, 2020.

[76] J. Cawthra, M. Ekstrom, L. Lusty, J. Sexton, and J. Sweetnam, Data Integrity: Detecting

and Responding to Ransomware and Other Destructive Events. National Cybersecurity

Center of Excellence, 2020.

[77] B. Krebs, “What the Marriott Breach Says About Security,” Krebs on Security, 01-Dec- 55

2018. [Online]. Available: https://krebsonsecurity.com/2018/12/what-the-marriott-breach- says-about-security/. [Accessed: 01-Apr-2020]. 56

Appendix

Python Code for Pseudo-Ransomware - Contents of encryption_program_folderCentric.py: 57 58 59 60

Python Code for Experiment Mainline - Contents of ExperimentMainline.py: 61 62 63 64 65 66 67 68

Python Code for Experiment Utilities - Contents of ExperimentUtilities.py 69 70 71 72 73