Representing attacks in a cyber range

(1)

Linköpings universitet

Linköping University | Department of Computer and Information Science

Master thesis, 30 ECTS | Datateknik

202019 | LIU-IDA/LITH-EX-A--2019/042--SE

Represen ng a acks in a cyber

range

Representa on av a acker i en cyber range

Niklas Hä y

Supervisor : Felipe Boeira Examiner : Mikael Asplund

(2)

Upphovsrä

De a dokument hålls llgängligt på Internet – eller dess fram da ersä are – under 25 år från pub-liceringsdatum under förutsä ning a inga extraordinära omständigheter uppstår. Tillgång ll doku-mentet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och a använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och llgäng-ligheten nns lösningar av teknisk och administra v art. Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i så-dant sammanhang som är kränkande för upphovsmannens li erära eller konstnärliga anseende eller egenart. För y erligare informa on om Linköping University Electronic Press se förlagets hemsida h p://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years star ng from the date of publica on barring excep onal circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility. According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement. For addi onal informa on about the Linköping University Electronic Press and its procedures for publica on and for assurance of document integrity, please refer to its www home page: h p://www.ep.liu.se/.

(3)

Abstract

Trained security experts can be a mitigating factor to sophisticated cyberattacks that aim to violate the confidentiality, integrity, and availability of information. Reproducible sessions in a safe training environment is an effective way of increasing the excellence of security experts. One approach to achieving this is by using cyber ranges, which essentially is a set of hardware nodes that can virtually represent a large organization or system. The Swedish Defense Research Agency (FOI) develops and maintains a fully functioning cyber range and has the ability to automatically deploy sophisticated attacks against organizations and systems represented in this cyber range through a system called SVED.

In this thesis, the capability to deploy different types of cyberattacks through SVED against virtual organizations in a cyber range, CRATE, is investigated. This is done by building a dataset of publicly disclosed security incidents from a database and at-tempting to represent each of them in SVED, and subsequently instantiating these attack representations against organizations in CRATE.

The results show that the prevalence of at least one CVE-entry (Common Vulnera-bilities and Exposures) in the incident description is a key factor to be able to represent an attack in SVED. When such an entry does exist, SVED is likely able to implement a representation of the attack. However, for certain type of attacks a CVE-entry is not enough to determine how an attack was carried out, which is why some attacks are harder to implement in SVED. This was the case for Denial of Service (DoS) attacks, which are too reliant on infrastructure rather than one or more vulnerabilities, and SQL injections, which are more reliant on the implementation of database access.

Finally, CRATE is able to handle almost all attacks implemented in SVED, given that the correct vulnerable application software is installed on at least one machine in one of the organizations in CRATE.

(4)

Acknowledgements

I would like to express my gratitude to the Swedish Defence Research Agency (FOI) for allowing me to write my thesis in collaboration with them. In particular, I would like to thank Teodor Sommestad at FOI for his continuous guidance, support, and feedback while supervis-ing my work. I would also like to thank Hannes Holm at FOI for helpsupervis-ing me understand the technical systems and networks used, as well as answering my countless technical questions on SVED and CRATE.

Furthermore, I would like to thank my supervisor and examiner at the Department of Com-puter and Information Science, Felipe Boeira and Mikael Asplund, for their honest and valuable input on my thesis writing.

Finally, as I look back at my five years of studies in Linköping, I would like to take the opportunity to thank all the students and personnel at Linköping University that I had the great pleasure of interacting with throughout my education.

Linköping, June 2019 Niklas Hätty

(5)

List of Figures

2.1 An illustration of an attack described in the STIX language. The icons are recreated from the official STIX language for illustrative purposes. . . 8 2.2 The four vital components of the A4 _{threat model. . . .} ₉

3.1 An example of an organization represented in CRATE. Image is directly taken from the CRATE-web, the administrative pages of CRATE. . . 11 3.2 The relationship between the components of CRATE, SVED, and Metasploit. . . . 13 3.3 A reverse connection between the injector and victim. . . 14 3.4 Illustration of an attack graph corresponding to the attack. . . 15 4.1 Flowchart for implementing an attack in SVED and instantiating it in CRATE. . . 20 5.1 Visualization of the incidents discarded at each phase. . . 25

(8)

List of Tables

2.1 Tactics in the ATT&CK framework. . . 8

2.2 Subcategories for the four components of the VERIS framework . . . 9

3.1 Important settings for the exploit/windows/fileformat/ms09_067_excel_featheader module . . . 14

4.1 Comparison of frameworks to describe incidents and attacks. . . 17

4.2 Final framework of variables used in the investigation. . . 18

4.3 Comparison of databases containing publicly available incidents or attacks. . . 18

5.1 Incidents that contained enough information, but could not be implemented in SVED. 26 5.2 Incidents that were implemented in SVED . . . 27

(9)

1 Introduction

The challenge to avoid or mitigate threats within the cyberspace is ever increasing. As tech-nology advances, so does the attacks against computer systems and networks. Furthermore, attacks or incidents in the cyberspace have a few unique characteristics which make them particularly challenging to defend against. For example, it may not always be obvious that a system has been attacked, or what information has been stolen or destroyed. In the computer world, logs can be hard to interpret, and realizing that a system is under attack requires knowledge and trained security experts.

One effective approach to educate security experts is through experiment and training sessions using realistic scenarios. The idea is naturally that knowledge comes from experience, which when dealing with rare and sophisticated computer attacks can be very hard to gain. In the real world golf and shooting ranges exist, and the equivalent in the cyber world would be cyber ranges, which has seen increased usage in recent years. In practice, a cyber range is a cluster of many virtual hardware nodes which together form a simulated system or network, e.g. a complete office network. Training by performing experiments in a cyber range has a few distinct benefits which makes it both safe and efficient. First, no malicious code or behavior have to run on a system outside the training environment, and thus there is no risk that an attack in some form damages real systems. Second, using a virtual environment makes it easy to restore the system or network back to its original state after an experiment, making the training process efficient and reproducible.

FOI is a Swedish research agency that does research on information security. In the scope of this, FOI develops and maintains the Cyber Range And Training Environment (CRATE). The cyber range consists of around 800 hardware nodes with approximately 10000 virtual nodes that can represent several networks, e.g. a office network. To easily deploy attacks against systems and networks in CRATE, FOI has developed the tool ”Scanning, Vulnerabilities, Exploits and Detection” (SVED) [1]. SVED makes it possible to make a simple but realistic representation of a sophisticated attack, instantiate it against an organization in CRATE, and document the outcome. An attack in SVED is a essentially a set of logical steps that together form a sort of attack graph, each node or module representing one step of the attack. One attack in SVED could for example be a malicious file being sent to a naive victim through email, where one module would be the creation of the malicious file.

(10)

1.1. Problem Definition

1.1 Problem Definition

Using systems like SVED to represent attacks is an effective way to create a reusable set of attacks without having a live person perform all steps of an attack manually each time. The benefit it clear, but SVED also has its limitations as to what type of actions it can represent. For example, a hardware failure in a computer that causes unpredictable behavior is naturally not something SVED could realistically represent fully. The research in the area of realistic attack representation in a cyber ranger is a rather is rather scare, and the accuracy of the result from training sessions using such training sessions have been questioned [2]. One problem in particular is that there is a difference between the training environment inside a cyber range and the live, operational environment, which may make the results unreliable [1]. With this in mind, it is surprising that the academic research on systems that can be used to orchestrate reproducible attacks in cyber ranges is so scarce. There seems to be no academic consensus on the required capabilities of cyber ranges and systems like SVED.

In this thesis, the capabilities of SVED are investigated, where the aim is to investigate which attacks SVED and by extension CRATE can accurately represent in its current state. The investigation is performed in four steps. First, real and publicly disclosed security attacks are selected on certain criteria and then sampled from a publicly available database of incidents. Second, these attacks are described according to a description model built on existing research in the field. The aim of this step is to accurately describe an attack in a way that makes it possible to represent it in SVED. For example, if a computer was breached using a known vulnerability with an attached CVE-entry1_{, it provides a lot of information on how the attack}

was carried out on a technical level. Third, attacks with enough information available are, if feasible, implemented in SVED. If an attack cannot fully be represented in SVED, a partial or slightly altered representation is implemented. The implementations in SVED are then tested against previously set up networks in CRATE. Finally, the process of representing each attack is evaluated and quantified. In more specific terms, this thesis aims to answer the following research questions:

1. Can attacks be represented in SVED using information from databases of publicly avail-able security incidents?

2. Are there categories of attacks that are harder, or easier, to represent in SVED? 3. Can the implemented attacks in SVED be successfully instantiated in CRATE?

The investigation is both theoretical and practical. In the theoretical part, attacks are essentially described and compared to each other. The hypothesis is that some types of attacks, or some parts of an attacks are easier to represent in SVED than others.

1.2 Delimitations

One important point to make about cyber ranges is that the systems, machines, or worksta-tions they virtualize are just a set of different computers. This means that any attack could theoretically be recreated fully by for example using the exact same malicious file or code used in the real attack. This approach is both hard and inefficient in practice for several reasons. First, such files are generally hard to retrieve and reverse engineer. Second, many attacks are incredibly complex and would take an enormous effort to recreate. Finally, this defeats the purpose of using tools like SVED which is to orchestrate attacks in simple ways.

Setting up networks in CRATE, e.g. an office network, is out of scope for this thesis. The investigation, particularly in relation to the fourth research question, thus relies on networks and machines already set up in CRATE.

1_{Common Vulnerabilities and Exposures is a database of vulnerabilities each identified with a CVE-entry:}

(11)

1.3. Thesis Organization

Finally, the implementation and deployment of attacks does not take measures that limit the effectiveness of attacks into consideration. This means that all mitigating factors such as anti-virus and internal firewalls were excluded or circumvented on purpose during the in-vestigation. The reason for this is that such features could easily break any attack, e.g. by intentionally blocking certain actions taken that are certain to happen when deploying attacks using SVED.

1.3 Thesis Organization

Chapter 2 presents the theoretical concepts necessary to understand the work done, as well as the limited research done in the area. In Chapter 3, a thorough introduction to cyber ranges, as well as some background to practical uses of cyber ranges. The method of the work done is presented in detail in Chapter 4, and the results of the investigation is presented in Chapter 5. The thesis ends with a discussion of the results and method used in Chapter 6 and a conclusion in Chapter 7 which answers the research questions.

(12)

2 Theory and Related Work

This chapter presents the theoretical concepts and terminologies that are necessary in order to understand the work done in this thesis. First, related work in the research area is discussed. Second, fundamental concepts related to attacks in a cyberspace context are covered. Third, the previous work done on relevant frameworks and methods to describe and classify incidents and attacks are presented.

2.1 Related Work

The academic research and previous work on the capabilities and applications of cyber ranges and systems like SVED to represent realistic attacks is, to the best of my knowledge, very scarce. There are likely several reasons for this. First, cyber ranges are a relatively new concept, and have not yet gained any real traction in the academic world. Second, cyber ranges are expensive which means that its uses are largely limited to large organizations or nations with resources to develop and maintain many servers. Third, while some research on cyber ranges in general exist, very few touch realistic representation. However, the cyber range field is a promising area of research and while the number of studies directly related to the work in this thesis are few, this is likely to change in the future. In this section, a few studies that are indirectly related to the work in this thesis are discussed.

2.1.1 Cyber Range Research

In an overview of a particular cyber range by Ferguson et al. [3], the authors discuss the motivation, advantages, and features of the cyber range. The authors claim that an inte-grated automation toolkit to deploy security tests exist, but unfortunately there is no direct information on which type of attacks such a system could, or should, realistically represent.

2.1.2 Cyber Security Simulation Research

In a study on cyber security simulation, Kavak et al. [4] introduce the concept of LVC (Live-Virtual-Constructive) simulation experiments and review existing literature on the basis of this characterization. Live simulation involves real actors interacting with networks and systems, virtual involves real actors interacting with simulated networks and systems, and constructive

(13)

2.2. Fundamental Concepts and Terminology

involves simulated actors interacting with simulated networks and systems. The authors make an interesting observation that despite the prevalence of humans involved in security incidents and attacks, simulations involving such actors are limited.

Some research has been done on realistic representation of simulated test environments. Berk et al. [5] investigated network traffic data and compared real network traffic to the equivalent from a simulated environment. The researchers found that the simulated data of-ten differed heavily from real network traffic, and thus failed to provide a realistic simulated environment. Their methodology involves making distinctions about different types of real-ism and argue that perfect realreal-ism is most often not possible nor required. Instead, a test environment has to be good enough for the specific purpose. These types of arguments are interesting considering that the purpose of SVED and CRATE is to represent an environment that is good enough to be used in training experiments. The question is thus shifted towards what can be considered good enough, which ultimately is one underlying aim of this thesis.

2.1.3 Incident and Attack Description

FOI conducts research on incident response challenges with a focus on the team responding to security incidents. In a study done by researchers at FOI using CRATE [6], 16 elements that are important to describe an incident with as much information as possible were presented. In this study, frameworks relevant to this thesis are discussed and compared to the suggestion of the authors. Furthermore, the study concludes that incident descriptions with more information elements described are generally of higher quality.

2.2 Fundamental Concepts and Terminology

An abundance of definitions exists on fundamental concepts in cyber security. Therefore, these concepts are described here as they are used in this thesis.

2.2.1 Incidents and Attacks

An incident occurs when abnormal behavior is identified that can potentially endanger the confidentiality, integrity, or availability of information. An attack, or a computer security incident, is an extension of this definition, where an intentional act or attempt to endanger these principles occur [7]. For example, accidentally publishing administrative credentials of a service would be considered an incident, whereas the intentional act of stealing the credentials through malicious behavior would be considered an attack on the service. In this thesis, all attacks are also considered to be incidents.

2.2.2 Advanced Persistent Threat

Some attacks are more sophisticated than others. One prevalent type of such sophisticated attacks is named Advanced Persistent Threats (APT). Attacks are classified as APTs given the following characteristics: i) complex and sophisticated in nature, often utilizing exploits that have not been disclosed publicly before (”zero-day exploits”), ii) persistent, meaning that the attack aims to exploit a system or network for a longer time and iii) stealthy and covert, so that the adversaries can perform the goal of the attack without being noticed and mitigated [8]. APTs are therefore a class of dangerous attacks, in many cases probably carried out by state-backed groups [9].

2.2.3 Attack Graphs

Attack graphs have long been used to describe an attack on a system in terms of logical steps taken [10]. Attack graphs are a formal representation that describe how an adversary may

(14)

2.3. Frameworks for Describing Incidents and Attacks

exploit a system, which due to the complexity of many attacks is helpful for analysis and defense strategy. The main purpose is understanding the goal and vector of a complex attack, which is crucial when it comes to representing attacks in systems like SVED.

The attack graphs used in this thesis consist of nodes which represent actions, and edges which define the next action.

2.2.4 Vulnerability Analysis

Vulnerability analysis or assessment is a technique used to find vulnerabilities before they are exploited. The process usually involves automated tools called scanners which discover and flag potential vulnerabilities present in a system. Vulnerability scanners such as OpenVAS1 is often a first step towards finding vulnerabilities. One problem when performing an automated vulnerability analysis is however the relatively high rate of false negatives that are found.

2.2.5 Penetration Testing

The act of actively testing for vulnerabilities by trying to breach a system or network is called penetration testing. A penetration tester therefore acts as an attacker that, with permission from the system owners, finds and discloses security vulnerabilities. For this purpose, many different frameworks and tools exists that make this process more efficient and effective. In contrast to the previously mentioned vulnerability analysis, penetration testing actively exploit a system and therefore mostly avoid the problem of false negatives.

2.2.6 Metasploit

One of the most popular penetration testing frameworks is the Metasploit framework. This framework consists of plug-ins, interfaces and libraries with modules used to conduct penetra-tion testing of a system. The purpose is to find previously undisclosed vulnerabilities present in the system under test. [11]

While Metasploit is primarily targeted towards penetration testers, the modules can suc-cessfully be used to carry out attacks against systems which are not authorized to be tested. In other words, the main difference between penetration testing and attacking a system using Metasploit is the intent and authorization of the user. For example, one Metasploit module may host a malicious web server that when accessed by a user creates a backdoor.

2.3 Frameworks for Describing Incidents and Attacks

Describing and defining incidents in cyber security is important yet complex. Due to the enormous amount of hardware and software interacting with each other, the combination of attack steps are near infinite. For example, a social engineering attack with the aim to impersonate an employee at a company in order to gain unauthorized access is very different from a Denial of Service (DoS) attack which temporarily disrupts a system or network. But these seemingly different attacks may share a few similarities, such as the initial vector of attack, which could be a malicious email attachment. Investigating such similarities by using systematic frameworks is incredibly useful for understanding patterns, incidents, and when defending against threats. For example, Franklin et al.[12] conclude that such frameworks can be used to separate a real incident from a false positive when classifying potential incidents.

Due to the large number of variations of attacks, an abundance of systems to describe them exist, each focusing on slightly different aspects of cyber security. Therefore, some important and recognized systems and frameworks are presented and discussed in this section.

(15)

2.3.1 Lockheed Martin Cyber Kill Chain

Cyber Kill Chain (CKC) is an intelligence-based framework or model that aims to counter APTs by describing a threat as a chain of events leading up to a successful attack. By providing a framework to map countermeasures to each step on an attack, a threat can be stopped easier [13]. In addition to acting as baseline for defensive purposes, CKC can also be used to describe an attack and its phases, especially APTs. The seven links that an attack consists of in CKC are in chronological order:

1. Reconnaissance Harvesting information such as email addresses and personal informa-tion.

2. Weaponization Creating an exploit with a working backdoor. 3. Delivery Delivering the malicious exploit and payload to a victim.

4. Exploitation Use the weaponized exploit to trigger a vulnerability on the victim’s system. 5. Installation Make the backdoor persistent by installing the malicious software.

6. Command & Control (C&C) Infrastructure to remotely control the victim.

7. Actions on objectives The final step that carries out the intended objective of the at-tack.

CKC is successful in describing the essential parts of an attack, while at the same time allowing for more technical details to be detailed under each of the seven links, e.g. how a delivery was carried out.

2.3.2 MITRE ATT&CK Matrix

Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) [14] is a technique and framework to describe an attack and the methods used by an adversary. ATT&CK has been used in studies to evaluate incident response techniques [12]. The framework is comprehensive and consists of eleven categories named ”tactics”, each with several sub-categories named ”techniques”. Together, they form a full matrix. MITRE ATT&CK shares many similarities with CKC, of which it is derived from. Essentially, a few tactics in the ATT&CK matrix can be considered one link in CKC. The full description of each tactic in the matrix can be found in Table 2.1, and the full list of techniques is presented by MITRE [15].

2.3.3 STIX

Structured Threat Information Expression (STIX) is a framework to describe the events of an attack in a structured and comprehensive manner. The second version of STIX defines a lan-guage that consists of twelve STIX Domain Objects (SDOs) that can describe the relationship between elements of a threat or incident. Each object can have a set of attributes that includes more technical details of the object. In addition to the twelve objects, STIX also consists of two STIX Relationship Objects (SROs) that realizes the previously mentioned relationship between objects in the language. [16]

Figure 2.1 provides a small example of an attack described with objects in STIX. The benefit of STIX is that it is a generic language that can describe many different types of attacks. In addition to this, the objects and relationships can be visualized, which is something that may be hard with other frameworks.

(16)

Table 2.1: Tactics in the ATT&CK framework.

Tactic Description Example

Initial Access The vector of an attack Spearphishing link Execution How the malicious code is executed on the

vic-tim

User execution Persistence Steps taken towards giving an adversary

per-sistent access

Installed application startup Privilege

Escala-tion

Steps taken to gain additional permissions on a system

Access Token Manipulation Defense Evasion Action taken to avoid detection and defenses Encrypted payload

Credential Access Action taken to access credentials Brute force passwords Discovery Knowledge gain of network or system

compo-nents

Network scanning Lateral Movement Movement from one system to another within

the network

Remote services Collection Action to collect information on a system Local file copy

Exfiltration Action to transferring file from the system Transferring files to C&C

Command and

Control (C&C)

Communication between adversary and con-trolled systems

Communication over com-mon ports

Figure 2.1: An illustration of an attack described in the STIX language. The icons are recreated from the official STIX language for illustrative purposes.

2.3.4 VERIS

The Vocabulary for Event Recording and Incident Sharing (VERIS) [17] is a community-driven framework with a special focus on responsible sharing of incident details. VERIS, like the previously discussed frameworks, tries to solve the problem of quality information on security incidents. The framework is largely based on the A4 _{threat model developed by the}

Verizon RISK team2_{. This model categorizes incidents using four main components, as shown}

in Figure 2.2.

2_{The Verizon RISK Team: http://www.verizonenterprise.com/products/security/incident-response/.}

(17)

Figure 2.2: The four vital components of the A4 _{threat model.}

Table 2.2: Subcategories for the four components of the VERIS framework

Actor Action Asset Attribute

Internal Hacking Variety Confidentiality/Possession External Malware Ownership Integrity/Authenticity Third-party Social Management Availability/Utility

Misuse Hosting

Physical Accessibility

Error Cloud

Environmental Notes

The four components of the VERIS framework describe a solid overview of an incident. Furthermore, each of the categories consists of a set of subcategories or descriptions. Table 2.2 provides a brief overview of these categories. It should also be noted that each of the subcategories have further descriptions which are described by the community initiative [17]. As an example, an incident classified with the VERIS framework could be an external (actor) malware attack (action) against a server (asset) which compromises the confidentiality of the information (attribute). While this framework is less technical than STIX and the MITRE ATT&CK Matrix since there are fewer possibilities to add technical details, it still provides quality information on a potential breach, attack, or incident.

(18)

3 Cyber Ranges and SVED

A fundamental problem that computer security experts and researchers must deal with is testing, experimenting, and training in a safe and reliable way. A cyberattack most often contains some form of malicious code, which even during an experiment has to be executed somewhere it may cause harm. This problem is not unique to the cyber security field, but to any field that have to deal with systems that can potentially cause damage, such as in the military sector. In some cases, cyberattacks cause physical damage and not just damage software systems, such as the infamous Stuxnet attack [18] in 2010. Such attacks show that cyberattacks can involve dangerous pieces of software that can cause damage to both software and hardware and needs to be handled with care.

While having a duplicate but separate system or network used solely for conducting exper-iments and security training would be ideal from a security standpoint, it is in many cases an unrealistic approach. In recent years, efforts have been made to solve this problem by using cyber ranges, which essentially are highly adaptable test beds of computers that can be used to perform realistic experiments and training sessions [3]. Cyber ranges do not inherently solve the problem of experimenting with attacks that may harm physical systems, but they provide a virtualized sandbox environment that can be completely separate from a real system and thus making the process safer.

In practice, a cyber range is a cluster of servers that virtualize a large number of nodes. These nodes are used to represent entire networks fully — from workstations to firewalls and different types of servers. Figure 3.1 depicts a complete organization represented in CRATE.

3.1 Cyber Range and Training Environment

The cyber range used in the investigation in this thesis is CRATE, which is developed and maintained by FOI. Today, CRATE consists of around 800 servers with over 10000 virtual nodes. Setting up and deploying networks, or organizations as they are called in CRATE, can be cumbersome depending on the requirements and is therefore out of the scope for this thesis. Thus, the investigation relies on existing organizations already set up in CRATE. The networks and systems set up contain a number of different computers running on different operating systems. The virtual machines also have a large number of applications installed that are typically seen in the wild, with some versions more vulnerable to attacks than others.

(19)

3.2. SVED: Scanning, Vulnerabilities, Exploits and Detection

Figure 3.1: An example of an organization represented in CRATE. Image is directly taken from the CRATE-web, the administrative pages of CRATE.

The purpose is to represent a realistic scenario that can be used when experimenting, or in an incident response training context.

3.2 SVED: Scanning, Vulnerabilities, Exploits and Detection

While CRATE is a fully functioning cyber range and an effective environment to experiment with attacks in real time, it lacks the capability to orchestrate automated attacks against its represented organizations. For example, attacking an organization in CRATE using live expert hackers, while fully possible, is costly and not very reproducible. This type of practice is often referred to as red team versus blue team and requires a lot of expertise and hands-on knowledge on both the defending and attacking side. The tool SVED [1] fills this gap by providing a framework to set up attacks that can be deployed against organizations in CRATE.

3.2.1 Attacks in SVED

Attacks are represented in SVED using a flowchart-like diagram which is similar to the previ-ously described attack graphs. In essence this is a set of nodes separated by logical decisions. Each node in the attack graphs represents one type of action, for example sending an email, or mounting a portable memory drive to some computer. The edges tie actions together and decide the next course of action depending on the outcome of one or more previous actions. For example, it is possible to decide the next action to be performed by looking at the success or failure of the previous action. A common scenario here would be trying to run several different exploits until one succeeds before moving on to the next phase of the attack. For simplicity’s sake, these diagrams are referred to as attack graphs in this thesis.

Each node in SVED has a state which describes the current status of the node, such as INITIALIZED, SUCCESSFUL, or FAILED, which makes these logical decisions possible to evaluate.

(20)

3.2. SVED: Scanning, Vulnerabilities, Exploits and Detection

Furthermore, it also allows the end user to see if an attack was successful or not by looking at the success status of each node throughout the attack.

An important distinction to make here is that the attacks in SVED are not simulated. Attacks in SVED are real attacks deployed against virtualized servers in CRATE. This means that successful attacks represented in SVED could also be successful on similar systems in the real world.

3.2.2 Metasploit

In addition to general actions such as sending an email, SVED can fully utilize the entire Metasploit framework to create attacks. This means that all modules available to a penetration tester using Metasploit is also available when orchestrating attacks in SVED. This is one of the strongest features of SVED as it allows the end user to make use of thousands of exploit modules already created by the Metasploit community, without having detailed knowledge of their inner workings. For example, instead of using an exact copy of the malicious malware used in the aforementioned Stuxnet attack, Metasploit modules exist that exploit the same vulnerability, but not necessarily in the exact same way.

3.2.3 Simulating Live User Behavior

Instead of having a live user perform actions that would trigger an exploit or run a malicious program, SVED has the ability to utilize a bot to perform these actions automatically. A bot in SVED is simply an AutoIt script1_{launched automatically on the machine, which then}

listens for commands from an injector. As such, the bot can perform any action that a real, albeit sometimes naive, user could perform to get infected or exploited.

3.2.4 Infrastructure of SVED

All actions in SVED are carried out by a special type of servers in CRATE called ”injectors”, which run an operating system focused on ethical hacking and penetration testing, Kali Linux2_.

The injectors are special servers that represent an attacker, which together with SVED make it possible to represent an attack and carry it out by simply constructing a valid attack graph in SVED. Furthermore, injectors have the ability to switch to any virtual local area network (VLAN) of an organization in CRATE. The benefit of this is that some actions need to be performed from the internal network of an organization, e.g. when simulating an attack from an insider actor. Similarly, other actions need to originate from an external network to simulate an external attacker e.g. when trying to breach a firewall. Figure 3.2 visualizes the relationship between CRATE, SVED, and Metasploit.

3.2.5 Additional SVED Features

Aside from creating and deploying attacks, SVED has a few features that are more utility-based and act as a link between SVED and organizations in CRATE. One such feature is a full encyclopedia in the form of a database that allows for queries including vulnerabilities (CVE-entries), Metasploit modules, and vulnerable machines. This tool is effective when searching for organizations or individual machines vulnerable to a specific CVE-entry or Metasploit mod-ule. The vulnerability assessment is done using a popular open source tool called OpenVAS. However, while tools that assess the vulnerability of a system are useful, they are not always reliable and may include both false positives and negatives [19].

1_{AutoIt is a scripting language that automates tasks using the graphical interface in Windows, together}

with general scripting features. https://www.autoitscript.com/site/autoit/

(21)

3.3. Example Attack in SVED

Figure 3.2: The relationship between the components of CRATE, SVED, and Metasploit.

Finally, SVED has a full and comprehensive logging system that logs every action done by an injector when deploying an attack. This makes it easy to track the progress of an attack in real time, as well as analyzing an attack after it has finished running.

3.3 Example Attack in SVED

To better understand the results, a comprehensive example of a successful attack that was previously represented in SVED is provided in this section. The attack creates a malicious file that is sent by email to a victim. When this email attachment is saved and the file is executed, a backdoor is established on the victim’s machine. Once a backdoor has been established, all files with a .pdf-extension are stolen and sent to the attacker. The corresponding attack graph to this attack is presented in Figure 3.4.

3.3.1 Phase 1: Setting Up The Attack in SVED

Before creating an attack, some initial elements have to be included into the SVED attack such as injectors (attacking servers) and organizations (victim servers) that are going to be used in the attack. Since the injectors are computers that may be busy with other tasks, they have to be reset, which is an action available in SVED called ”Reset injector”.

3.3.2 Phase 2: Setting Up a Backdoor

In this phase, a malicious file is created exploiting a known vulnerability. This is done by using a Metasploit module called exploit/windows/fileformat/ms09_067_excel_featheader, which exploits a vulnerability in Microsoft Excel. This vulnerability is identified as CVE-2009-31293_{. This module requires a few settings, of which some important ones are presented}

in Table 3.1. The most important setting is the payload, which is the method used to set up communication between the injector and the victim. In this example, a reverse connec-tion is used to communicate. When the malicious file is executed on the victim machine, a connection on a chosen port is initiated by the victim automatically. A separate Metasploit module called a listener is set up that listens for incoming connections from the victim. A reverse connection is effective since firewalls typically only block incoming connections and not outgoing connections, such as when the victim unknowingly initiates a connection. Figure

(22)

Figure 3.3: A reverse connection between the injector and victim.

Table 3.1: Important settings for the exploit/windows/fileformat/ms09_067_excel_featheader module

Setting Value Description

Payload windows/meterpreter/reverse_tcp Reverse connection as shown in Fig-ure 3.3.

LHOST IP address of the listener

-LPORT Port used to communicate

-Target Microsoft Office 2003 SP0 on Win-dows XP SP3

The operating system and application that is targeted on the victim.

3.3 presents the setup of the injector, victim, and the backdoor. Once a connection has been established between the victim and injector, the backdoor is open and can be used further.

3.3.3 Phase 3: Delivering The Malware

In this phase, a malicious file has been created, and the injector is listening for incoming connections. To deliver the malicious file, an email is sent using a badly configured mail server in one of the organizations in CRATE.

3.3.4 Phase 4: Executing The Malicious File

Having someone physically log into the victim machine, opening the email, and running the malicious file would be possible, but it would defeat the purpose of automatically launching an attack. Instead, a bot is deployed on the victim to simulate a naive user opening a malicious file. The bot performs the actions a naive user otherwise would have to do to get infected. These bots are utilizing the SVED AutoIt feature previously mentioned.

3.3.5 Phase 5: Attacking the User

Once the malicious file has been executed on the victim machine, a successful backdoor has been set up. The injector now fully controls the victim using a special Metasploit environment called Meterpreter, which makes it possible to run scripts and use a shell on the victim’s computer. In this case, a module is used that is able to run Meterpreter commands. To search and exfiltrate all pdf-files from one hard-drive, in this case the C:/ drive on the victim’s computer, the module executes the following commands:

$ run f i l e _ c o l l e c t o r −r −d C: / − f ∗ . pdf −o / sved / f i l e s / l i s t _ o f _ f i l e s . l s t $ run f i l e _ c o l l e c t o r − i / sved / f i l e s / l i s t _ o f _ f i l e s . l s t − l / sved / f i l e s / The files are then uploaded to the injector, and thus the attack has finished successfully.

(23)

(24)

4 Method

This chapter presents a detailed view of the methodology employed in this thesis. The work is largely split into four distinct parts which follow a chronological and structured order. First, a description framework is created in order to have a structured way of describing the incidents used in a consistent and reliable way. Second, a dataset of publicly available incidents is created through selection and sampling of publicly available incidents. These incidents are described according to the description framework in order to build a dataset that can be used to create representations in SVED. Third, a representation of the attack is, if possible, implemented in SVED. Finally, the attacks are deployed to organizations in CRATE to see if the attack can be successful.

In summary, the work can be defined as these four steps: 1. Creating a description framework for incidents and attacks. 2. Building a dataset of attack descriptions.

3. Implementing a representation of the attacks in SVED. 4. Instantiating the attacks against an organization in CRATE.

4.1 Creating a Description Framework for Incidents and Attacks

The difficulty of defining and describing incidents and attacks was previously discussed in Chapter 2 where an overview of relevant frameworks was presented. The purpose of having a structured description is to attempt to quantify the results. That is, making it possible to easily go from a description to an potential implementation in SVED, or find out why it is not possible.

To tackle the challenge of describing an attack in this thesis, several frameworks were considered and compared to each other. First, the decision to build the description framework based on an existing one was made. This is motivated by the sheer number of frameworks already existing, and the workload required to develop and validate a new framework tailored to the work in this thesis. The framework needed to have a few characteristics to be effective. First, the framework had have been used in previous research. Second, the framework had to contain a lot of technical information in order to go from the description to the representation

(25)

4.1. Creating a Description Framework for Incidents and Attacks

Table 4.1: Comparison of frameworks to describe incidents and attacks. Framework Academic research

prevalence

Technical informa-tion

Flexibility Recommendations

MITRE ATT&CK Ma-trix

Yes [14] 11 tactics, many

tech-niques

Fully modifiable FOI, CERT-SE

STIX Yes [20] Possible to add Not modifiable outside

framework

FOI

VERIS Yes [21] Not required Yes

-Lockheed Martin CKC Possibly, not found Less technical No, chain is defined

clearly

CERT-SE

in SVED. Because the idea was to tailor the framework to fit the needs and scope of this thesis, the framework also had to be somewhat flexible to change without breaking.

Due to the relatively scarce related work in the area, the framework choice had to be eval-uated and at least on some level validated. In order to do this, the method was discussed with experts in the field. First, security experts at FOI came with valuable input and recommended ATT&CK initially. Second, a security and incident expert from the Computer Security Inci-dent Response Team (CERT-SE) was consulted on the choice of framework. In this discussion, it was concluded that i) to the best of their knowledge, CKC is the most prominent framework used in the field, ii) the ATT&CK framework is relevant and involves slightly more technical information, and iii) ATT&CK lacks the very important variable of attack vector1_.

With this information collected, a comparison of the frameworks explained in Chapter 2 is listed in Table 4.1.

An initial review of the frameworks showed that they are, in essence, very similar. For example, the MITRE ATT&CK Matrix is derived from the later stages of Cyber Kill Chain2. Furthermore, efforts have been made to express ATT&CK tactics and techniques in STIX3_.

The basis of the description framework to use in the investigation was decided to be the MITRE ATT&CK Matrix. The rationale is that the ATT&CK Matrix has the most fitting technical details required for the implementation stage of this thesis. Furthermore, as opposed to CKC which is foremost targeted towards APTs, not all elements need to be described in the ATT&CK framework. A valid attack can therefore be described with some information missing, such as a DoS attack without any lateral movement involved. This was proven to be the case for the data set of attacks used.

The framework was modified to better fit the incidents investigated. First, the techniques for each of the eleven tactics in the matrix were discarded. The reason for this is that the techniques were deemed to be too specific and platform dependent. Furthermore, with such a large number of specific techniques, the amount of incidents for each technique would most likely be too few to draw any conclusion from, thus not adding any value to the results. Second, the scope of the investigation was narrowed down for time restrictive purposes. At this point, a decision was made to discard a few tactics to better focus on the important aspects of an attack and narrow the scope. Therefore, the tactics defense evasion, credential access, discovery, and lateral movement were discarded. These tactics were chosen to be discarded since the dataset of incidents used did in most cases not contain much technical information describing the method used with regards to the tactics, and an initial review showed that it therefore would be hard to draw any conclusion using these tactics.

Finally, to be able to draw any conclusion on what type of attacks that can be represented in SVED, a variable that describes the category of an attack was added to the framework, e.g. a DoS attack. This categorization is derived from the VERIS framework under the action

1_{MITRE has since included ”Initial Access” in their framework which essentially describes the attack vector.} 2_{As described by the MITRE Corporation: https://attack.mitre.org/wiki/Introduction_and_Overview.}

Retrieved 2018-04-20.

(26)

4.2. Building a Dataset of Attack Descriptions

Table 4.2: Final framework of variables used in the investigation.

Tactic Description Example

Category The overall category an attack belongs to DoS

Initial Access The vector of an attack Malicious email attachment

Execution How the malicious code is executed on the victim User execution

Persistence Steps taken towards giving an adversary persistent access Installed application startup

Privilege Escalation Steps taken to gain additional permissions on a system, e.g.

a vulnerability

CVE-2009-3129

Collection Action to collect information on a system Local file copy

Exfiltration Action to transferring file from the system Transferring files to C&C

Command and Control (C&C)

Communication between adversary and controlled systems Communication over common ports

Table 4.3: Comparison of databases containing publicly available incidents or attacks.

Database Entries Timespan Focus area

The VERIS community database4 ₆₀₀₀₊ _2010-2014 _None

OWASP WASC Web Hacking Incidents Database5 1500+ 2000-2015 Web incidents

Repository of Industrial Security Incidents (RISI)6 ₂₄₂ _1982-2015 _{Industrial incidents}

component presented in Chapter 2, which describes how an action was carried out under the field ”action.variety”.

The full framework with variables used can be found in Table 4.2.

4.2 Building a Dataset of Attack Descriptions

Systems and networks are continuously targeted by attackers with different motives and vectors of attack. While some attacks cause no harm due to some underlying academic motive or simple curiosity, many are carried out with malicious intent that leads to a security related incident. When doing academic research on such incidents, it is beneficial to have a dataset with as much information as possible and properly categorized. Unfortunately, such datasets are typically not publicly available due to their sensitive nature. Commercial stakeholders are not often inclined to disclose information about incidents or admit to any wrongdoing. This means that a challenging but important part of the work was to build a dataset of incidents for this investigation. A few databases exist with incidents or attacks that were found and initially considered. In order to make sure the dataset was comprehensive and realistic, the database that incidents were collected from had to contain a lot of different types of attacks. The database would ideally also contain numerous of incidents spanning over several years, preferably recent. Table 4.3 compares the databases according to these criteria.

The aforementioned databases or datasets are all relatively scarce. First, the RISI database is discontinued, and contains no new incidents in recent years. Furthermore, this database is targeted towards industrial targets, which is not the focus in this investigation. The OWASP WHID, while comprehensive, is targeted towards web application breaches. Therefore, data was gathered using incidents from the VERIS Community Database, which is a community-driven initiative to publicly disclose security-related incidents. VCDB was chosen as a source of security incidents for several reasons. First, the database is comprehensive with over 6000 incidents from several industries using many different vulnerabilities and attack vectors. Sec-ond, VCDB is a proper database which makes it easy to query and extract information on incidents, which is crucial with a dataset of this magnitude. Third, the database is at least partially aimed towards research in incident handling and IT-security, which makes the data less biased towards specific commercial stakeholders in the IT-security field.

(27)

4.3. Implementing a representation of the attacks in SVED

4.2.1 Selection and Sampling of Incidents

The database contained over 6000 security incidents, which for the scope of this thesis were too many to investigate individually with high reliability. Furthermore, an initial review showed that many incidents were not directly related to information security and could thus not be considered as candidates to be implemented in SVED or instantiated in CRATE. Therefore, a systematic approach to select and sample incidents was used. The sampling was done with a script written in Python that interacted with the database. First, incidents that did not contain the subcategories ”hacking” or ”malware” in the ”action” component were excluded. This decision was made and is motivated by the fact that these are the type of incidents that cyber ranges and by extension SVED can reasonably be able to handle. For example, an attack where the physical servers of an office building are stolen during a break-in does technically and rightfully constitute as a security-related incident. However, cyber ranges are not primarily designed to handle such events, except perhaps through vague simulations, which would then likely lead to a heavily skewed result.

The selected and sampled incidents were then described using the framework introduced in Table 4.2. This was done individually for each of the incidents. Information was taken directly from the database entry in VCDB, as well as any direct references listed in the database entry. Depending on the type of incident and the external references available, an entry in VCDB may contain deep technical information describing each step of an attack in detail, or in some cases only a short summary in a news article. This makes the information gathering step challenging.

4.3 Implementing a representation of the attacks in SVED

The next stage of the investigation was to implement the attacks in SVED and test the successful implementations against organizations in CRATE. The purpose and goal of this stage was to create an attack graph corresponding to the information gathered on an attack, or at least in such a way that the essential parts of an attack remained intact. What this means in practice is further elaborated on in this section.

The process of building the attack graph and deploying the attack against organizations in CRATE can be generalized into a few systematic phases. Figure 4.1 outlines this process and its phases.

4.3.1 Phase 1: Further Information Gathering

Most of the sampled incidents did not contain enough information in the database entry to be able to properly describe and finally implement them in SVED. To fill this gap, further information on the incident or attack had to be gathered from various sources. In addition to the reference entries in the VCDB, a few reliable stakeholders in the industry that regu-larly present technical information on attacks were identified and used for further information gathering. These were FireEye7_{, Kaspersky SecureList}8_{and Symantec Security Center}9_.

After this stage, some attacks or incidents still lacked vital information needed to be con-sidered for implementation in SVED. Therefore, attacks missing information in more than half of the fields in the framework presented in Table 4.2 were ultimately discarded due to lack of information.

4.3.2 Phase 2: Manual Penetration Testing

Once an attack passed the previous phase and included enough information, it had to be implemented in SVED. However, before the implementation was done in SVED, the attacks

7_{https://www.fireeye.com} 8_{https://securelist.com}

(28)

(29)

were recreated manually using injector servers and tested against potential vulnerable machines in CRATE. This step serves a few valuable purposes. First, most tasks that SVED has the ability to do can also be done manually, albeit losing the reproducibility and automatic features of SVED. Performing these steps manually will isolate and remove any errors that SVED may produce, and makes the implementation process in SVED faster and more efficient. Second, manually running parts of an attack while testing is most of the times faster than letting SVED direct the injectors as SVED introduces some unavoidable overhead.

The manual penetration testing involves two parts. The first step was to find the correct Metasploit modules, or general actions that were done during the attack. While this may seem hard to do at a first glance, it is most often fairly trivial. This holds due to the fact that almost all attacks exploit some form of vulnerability to achieve its goal, either by escalating privileges or in some way perform an action that should not be allowed. The correct Metasploit modules were found by querying the SVED encyclopedia or the Exploit Database by Rapid710 _using

a CVE-entry. If no Metasploit module was found, phase three was initiated to find potential SVED modules that could be used in the attack.

The second step in this phase was to find a vulnerable machine in CRATE using manual penetration tests with the Metasploit modules or general actions described previously in this phase. This was done in three steps to make sure a vulnerable machine was not missed. First, the SVED encyclopedia was used that includes the results from a vulnerability scanner to find potentially vulnerable machines. As mentioned before, such scanners are sometimes unreliable and may include false positives. This means that some machines were flagged as vulnerable by the scanner but turned out not to be when testing. In that case, a machine with a vulnerable version of the application, as specified by the Metasploit module description, were tested instead. The simple explanation for why a machine should be vulnerable but turn out not to be is that attacks are very sensitive to the environment they try to attack, such as hidden settings that accidentally break an exploit. Finally, if this did not yield any success, a machine with a previous version of the application was tested.

Due to the unreliable nature of exploits in the wild and Metasploit, a module was tested several times against a potential vulnerable machine. If this did not yield any result in either of the three aforementioned steps, the result was that no vulnerable machine could be found for this attack. However, this does not mean that the attack could not be implemented in SVED, but that the instantiation in CRATE was very likely to fail.

4.3.3 Phase 3: Implementation

In this phase, the attack graph was created in SVED. Each attack in SVED can be seen as a set of logical decisions using Metasploit modules or the native SVED modules. Since the correct Metasploit modules had already been found in the previous phase, if such modules existed, this phase was fairly straightforward. If no Metasploit module had been found, potential SVED modules had to be identified, e.g. modules to generate a general malware and store it on a virtual portable storage device. If a vulnerable machine had not been found, for example if no Metasploit modules had been found in the previous phase, the same process was used in this phase to find a vulnerable machine. This time this was done manually, and not through SVED.

If an attack contained actions that could not be recreated in SVED due to lack of modules, they were discarded with the reasoning that no SVED or Metasploit modules could be found. However, since modules exploiting the exact same vulnerability or performed an action in the exact same manner as the attack may be hard to find, a system to discard attacks where applicable was defined. This was done by using the framework descriptions of the attacks in earlier phases, and by looking at most of the variables and tactics in the framework, while

(30)

other variables such as category was not considered. Here, each of these variables and the acceptable replacement actions are described.

4.3.3.1 Persistence

Attacks that provide a persistent access to a system have numerous ways to do so. In SVED, modules can add persistence by creating a file that runs on system startup. Furthermore, the Metasploit Meterpreter has scripts that provide a persistent backdoor. For simplicity, the SVED implementations make use of these two methods of achieving persistence. Attacks that in some way automatically run on system startup are therefore considered to be equal to these methods. If an attack provides persistence in some other way, the attack cannot be implemented in SVED.

4.3.3.2 Privilege Escalation

When an attack contains elements that escalate privileges through some vulnerability, the representation of the attack in SVED attack must exploit the exact same vulnerability by using Metasploit or SVED modules. To distinguish between vulnerabilities, the CVE entry of the vulnerability is used. If the exact same vulnerability cannot be used, the attack cannot be implemented in SVED.

4.3.3.3 Execution

To perform the execution part of an attack, as in executing the malicious software or trigger a vulnerability, the AutoIt bot feature or other SVED features listed as general SVED action is used. If the execution cannot be performed through the graphical interface of an operating system through the AutoIt bot, or by using the general SVED actions, the attack cannot be implemented in SVED.

4.3.3.4 Collection

If an attack collects information such as local files, passwords or similar, the SVED repre-sentation has to collect information of similar type, but not the exact same. This means that an attack that collects credit card information can be represented in SVED as an attack that collect generic information of the same format. This is because the availability of such information is not a part of SVED and thus not of interest in this thesis.

4.3.3.5 Exfiltration

Attacks that exfiltrate data such as local files or database entries can only do so by using the Meterpreter console, or any module in SVED that exfiltrate data. Attacks can then exfiltrate by sending it to to the command & control. If an attack uses any other way of exfiltrating data, the attack cannot be implemented in SVED.

4.3.3.6 Command & Control

The Command & Control features of SVED are largely limited to setting up backdoors us-ing the Metasploit Meterpreter console. Thus, the attacks implemented in SVED are usus-ing the Meterpreter console and any attack that uses simple two-way communication is consid-ered acceptable. If an attack uses any other form of communication, the attack cannot be implemented in SVED.

(31)

4.4. Instantiating the Attacks Against an Organization in CRATE

4.4 Instantiating the Attacks Against an Organization in CRATE

Once a corresponding attack graph of an attack was implemented in SVED, the different nodes, modules, and actions had to be further configured and tested against an organization or single systems in CRATE. This phase was iterative and time consuming since successfully configuring an attack was proven to be rather error prone and somewhat unreliable in SVED. Finally, the attack was deployed using SVED, and the outcome of the attacks were observed. Evaluating the result of an attack was a fairly simple process. First, any attack that did not contain enough information was already discarded in previous phases. The possible outcomes of an attack were i) Successful or ii) Not successful. Successful attacks are attacks that run without errors in SVED, which also means that the objective of an attack was achieved. In the case of an unsuccessful attack, the possible reasons were due to no available modules in SVED/Metasploit, or no vulnerable organization in CRATE, or in some cases other reasons.

(32)

5 Results

This chapter contains the results of the investigation. First, quantitative data on the sampled incidents is presented, outlining the number of incidents still present in each step of the method, as well as the outcome of all instantiated attacks in SVED. Third, relevant tables of incidents are presented. The organization of this chapter follows the previous chapter, without the creation of the description framework.

5.1 Building a Dataset of Attack Descriptions

In the method described in Chapter 4 incidents meeting certain criteria were sampled from the VCDB through a script. The method is outlined with its different phases in Figure 4.1. In the sampling phase 150 incidents were randomly selected, of which incidents with the included action ”hacking” and ”malware” were 75 each. A fairly significant number of incidents were duplicates belonging to the same campaign of incidents, which meant that the resulting sampled unique incidents were 116. The duplicates were considered as such because the database entry was identical to another sampled incident with another VCDB ID. Simply put, they were different instances of the same attack.

5.1.1 Phase 1

In the information gathering phase, 27 incidents and attacks could be described with enough information to be considered for implementation. The rest of the incidents were discarded.

5.2 Implementing a Representation of the attacks in SVED

The implementation step contained a few more phases. As mentioned before, 27 incidents were considered for implementation.

5.2.1 Phase 2

In this phase, matching Metasploit modules were looked for. If one matching were found, it was used in the attack. However, no incidents were discarded when none was found, since the SVED modules could still potentially be used in the next phase.

(33)

5.2. Implementing a Representation of the attacks in SVED

5.2.2 Phase 3

In phase 3, nine incidents were discarded because a good enough representation could not be implemented in SVED. In all cases but two, the reason was that Metasploit or SVED modules did not exist. In the other two cases, not enough technical information existed in order to determine which attack method that was used. These incidents are presented in Table 5.1.

The nine incidents that were discarded were of a few different categories. Two such cate-gories that are more prevalent are SQL injections and DoS attacks. While modules that per-form SQL injections were found in Metasploit, a direct match between a vulnerability/Metas-ploit module and incident could not be found. This means that general SQL injections could most likely be implemented in SVED, but specific incidents such as the real life ones sampled from VCDB could in this instance not be represented in SVED. The same thing also applies to the sampled DoS attacks. Furthermore, DoS attacks can be measured by the amount of traffic as a measurement of ”strength”. This was proven to be hard to replicate from the incident descriptions, and were thus not possible represent accurately in SVED.

At this stage, 18 incidents and attacks from the original 116 unique incidents were suc-cessfully implemented and represented in SVED. Table 5.2 presents the 18 incidents that were implemented in SVED.

(34)

5.2. Implementing a Representation of the attacks in SVED T able 5.1: Inciden ts that con tained enough information, but could not b e implemen ted in SVED. V CDB ID Category Initial access P ersistence Privilege es-calation Execution Collection Exfiltration C&C Reason 8FB8D399- 0A41- 4806-9C20- 1C48A761DB36 SQL injection Exploit public facing applica-tion N/A N/A SQL injection on w eb applica-tion User informa-tion Database calls None

Missing SVED/Metas- ploit

mo

dules

AE37CCC0- E461-4196- BE64- 73E292CAABE9

Use of bac kdo or or C&C Sp earphishing link A uto-run mal-w are -User launc h ma-licious file Keystrok es, lo-cal files Sen t to C&C Email serv er

mo dules 8A0FB892- 4C6C- 4979-91C6- 536AA72A8AF0 Unkno wn Exploit public facing applica-tion N/A CVE-2012-5385 Clien t load w eb-site User informa-tion (Apple-IDs) Sen t to C&C

-Missing SVED/Metas- ploit

mo dules 99800B97-2383- 45CA-98EA- 8DC3290D343D SQL injection Exploit public facing applica-tion -N/A -User informa-tion Database calls N/A

mo dules 979DBD94- B0F5-4944- B7BF- DA51F9F52392 Denial of Ser-vice Exploit public facing applica-tion N/A N/A F raudulen t syn-c hronization re-quests N/A N/A N/A Missing in-formation on attac k metho d 4DC627D4- 21CC- 44CD-976A- 1B181C2127BF Denial of Ser-vice Exploit public facing applica-tion N/A N/A -N/A N/A N/A Missing in-formation on attac k metho d 0DF5F C98-ADDB- 48BF-8104- D20188692336 Abuse of func-tionalit y/Brute force/Use of stolen creden-tials Sp earphishing email -No User launc h ma-licious file T ax records Database calls No

mo