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.