• No results found

Validating the Meta Attack Language using MITRE ATT&CK matrix

N/A
N/A
Protected

Academic year: 2021

Share "Validating the Meta Attack Language using MITRE ATT&CK matrix"

Copied!
80
0
0

Loading.... (view fulltext now)

Full text

(1)

IN

DEGREE PROJECT COMPUTER ENGINEERING,

FIRST CYCLE, 15 CREDITS ,

STOCKHOLM SWEDEN 2019

Validating the Meta Attack

Language using MITRE ATT&CK

matrix

EDVIN SPARF

OSCAR ÅBERG

KTH ROYAL INSTITUTE OF TECHNOLOGY

(2)
(3)

Validating the Meta Attack

Language using MITRE

ATT&CK Matrix

EDVIN SPARF & OSCAR ÅBERG

Degree Project in Computer Science Date: June 9, 2019

Supervisor: Robert Lagerström Examiner: Örjan Ekeberg

School of Electrical Engineering and Computer Science

Swedish title: Validering av Meta Attack Language med hjälp av MITRE ATT&CK Matrix

(4)
(5)

iii

Abstract

When more and more devices are getting connected to each other and to the in-ternet, the security of such devices becomes increasingly important. For large organizations with hundreds or even thousands of connected devices, it can be hard to determine the weak spots of the network in terms of security. A way of finding these weak spots is by using threat modelling. One language which can be used for this is the Meta Attack Language(MAL). The purpose of this report is to study which types of cyber attacks can be expressed with MAL. To do so eleven different attack techniques from the cyber attack database MITRE ATT&CK matrix are implemented in MAL. The report shows that many dif-ferent attacks can be implemented in MAL.Since all of the randomly selected attacks were possible to implement in MAL this suggests that it is possible to implement all of the attacks from the MITRE ATT&CK matrix in MAL.

(6)

iv

Sammanfattning

När fler och fler enheter kopplas ihop med varandra och med internet blir säker-heten för dessa enheter allt viktigare. Stora organisationer, som kan ha hundra-tals eller tusenhundra-tals uppkopplade enheter, kan ha svårt att hitta svagheter i deras säkerhet. Dessa svagheter kan hittas med hjälp av hotmodellering. Meta At-tack Language(MAL) kan användas för detta. Syftet med denna rapport är att studera vilka sorts cyberattacker som kan implementeras i MAL. För att gö-ra detta har elva attacktekniker från cybegö-rattacksdatabasen MITRE ATT&CK matrix implementerats i MAL. Rapporten visar att flera olika sorters cyber-attacker kan implementeras i MAL. Eftersom slumpmässigt valda attacktek-nikerna gick att implementera i MAL, är det troligt att alla attacktekattacktek-nikerna i MITRE ATT&CK matrix kan implementeras i MAL.

(7)

Contents

1 Introduction 1 1.1 Problem Statement . . . 2 1.2 Scope . . . 2 1.3 Outline . . . 2 2 Background 3 2.1 Threat modelling . . . 3 2.2 Domain-specific language (DSL) . . . 3

2.3 Meta attack language (MAL) . . . 4

2.3.1 Testing MAL . . . 5

2.4 MITRE ATT&CK Matrix . . . 5

2.4.1 Initial Access . . . 6 2.4.2 Execution . . . 6 2.4.3 Persistence . . . 7 2.4.4 Privilege Escalation . . . 7 2.4.5 Defense Evasion . . . 7 2.4.6 Credential Access . . . 7 2.4.7 Discovery . . . 8 2.4.8 Lateral Movement . . . 8 2.4.9 Collection . . . 8 2.4.10 Exfiltration . . . 8

2.4.11 Command and Control . . . 9

2.5 Related Work . . . 10

3 Methods 11 3.1 AttackLang . . . 13

4 Results 14 4.1 Test for individual MAL files . . . 14

4.2 Tests run against attackLang . . . 16

(8)

vi CONTENTS

4.3 Real world attack . . . 18

4.4 Attack Graphs . . . 20 5 Discussion 22 5.1 Future work . . . 23 6 Conclusions 24 Bibliography 25 A Source Code 29 A.1 spearphishingLink.mal . . . 29 A.2 commandLineInterface.mal . . . 30 A.3 audioCapture.mal . . . 31 A.4 bootkit.mal . . . 32 A.5 credentialDumping.mal . . . 34 A.6 dataCompressed.mal . . . 35 A.7 dataObfuscation.mal . . . 36 A.8 fileDeletion.mal . . . 36 A.9 passwordPolicyDiscovery.mal . . . 37 A.10 processInjection.mal . . . 38 A.11 replicationThroughRemovableMedia.mal . . . 42 A.12 AttackLang.mal . . . 43

A.13 commandLineInterfaceTest.java for attackLang . . . 50

A.14 replicationThroughRemovableMediaTest.java for attackLang . 51 A.15 dataObfuscationTest.java for attackLang . . . 53

A.16 spearphishingLinkTest.java for attackLang . . . 55

A.17 realWorldExampelTest.java for attackLang . . . 59

A.18 commandLineInterfaceTest.java . . . 62

A.19 spearphishingLinkTest.java . . . 63

B Test Output 66 B.1 attacklang test . . . 66

B.2 command line inter test . . . 69

(9)

Chapter 1

Introduction

The implications of security breaches such as the one at Equifax in 2017, in which criminals accessed personal information of over 140 million users, shows the importance of companies taking computer security seriously[1]. This security breach also shows how little knowledge some big corporations have of the security of their systems. The importance of helping reduce this is-sue can be seen by the level of investment[2]and recognition[3]startups which are working on this are currently receiving.

Graphical representation has been used for modelling cyber attacks for a long time. An example of this is the “Attack Trees” introduced in a paper by Schneier[4]. Since then, an effort has been made to automate the process of creating these attack graphs[5] and thus making them more useful for more complex systems. A problem with attack graphs is that they have to be made specifically for a specific system and may, therefore, be costly. To avoid this, domain-specific languages can be used. Domain-specific languages are used to make certain expression and calculations easier within a restricted area and allow its func-tions to be reused by others in the same domain[6]. The Meta Attack language can be used to make such domain-specific languages[7]. The Meta Attack Language(MAL) was made to make it easier to program and understand the modelling of cybersecurity attacks. When MAL-code is compiled with its spe-cific compiler it is compiled to Java code which can then be run. With MAL specific attacks against a system can be turned into code and then simulated. These codified attacks can then be used and reused by people who are experts in the field of computer security. MAL has already been used to develop the domain specific language vechileLang, which models the IT infrastructure of

(10)

2 CHAPTER 1. INTRODUCTION

vehicles. Many of the most common attacks facing systems today can be found in the MITRE ATT&CK Matrix made by MITRE Corporation[8]. If the at-tacks in the ATT&CK Matrix could be implemented in MAL it would show that MAL could be used to model a wide variety of different cyber attacks.

1.1

Problem Statement

What type of attacks can be expressed by the Meta Attack Language (MAL)? This will be examined by creating a set of MAL-specifications based on the enterprise ATT&CK matrix from MITRE, and then validating these specifica-tions using known attacks. How the set of attack techniques from the MITRE ATT&CK matrix is selected is explained in chapter 3.

1.2

Scope

The report will be limited by both the time and the information available. MAL is a programing language which is still under development which limits the amount of information and documentation which exists. There will also be a limit to the number of attack techniques that can be implemented from the MITRE ATT&CK Matrix and the information there. Especially the at times lackluster information about how to mitigate and or detect the attacks made it hard to implement protections against all types of attacks. The ATT&CK Matrix gained an additional column called Impact very late in the project and thus we were unable to implement a technique from this new column.

1.3

Outline

In the next section, Background, background information necessary for the sections after it is presented. This includes descriptions and definitions of Threat Modelling, The Meta Attack Language and the MITRE ATT&CK Ma-trix. Section three is called Methodology and it contains details of how the work was performed to receive the results in the section after. The Result section contains the results from the test cases as well as the generated at-tack graphs. In the Discussion section, the results are discussed in addition to sources of error and similar. The final section Conclusions answers the prob-lem statement.

(11)

Chapter 2

Background

2.1

Threat modelling

In a threat model, all of the threats which have been found for a specific system and its associated security goals are specified. Threats are also based on the system’s behaviour model. A threat model shows the relations and transitions between different attack steps throughout the system[9].

An early example of threat modelling can be found in a paper by Schneier [4] where he introduced the so-called “Attack Trees”. By modelling the threats imposed on a system graphically it can be easier to see where the weakest links in the system are located and in turn find where it is motivated to in-crease security. As noted by Schneier in his paper, it is not smart to inin-crease the length of the encryption key if other parts of a system are significantly less secure than the encryption used.

2.2

Domain-specific language (DSL)

A DSL is a type of programing language which is developed for the purpose of creating code for a specific type of problem. DSL:s has been defined by van Deursen et al[10] as

A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usu-ally restricted to, a particular problem domain.

(12)

4 CHAPTER 2. BACKGROUND

DSL:s can be Turing complete language but they do not need to be. The im-portant thing for a DSL is that is a language specifically built or used for a task, examples of these types of languages are LA

TEX and CSS. DSL:s are compiled down to general purpose languages. The purpose of DSL:s are to improve the ease and the time it takes to write a program[6].DSL:s can also allow for greater expressiveness compared to general purpose languages(GPL:s). As a result of these factors, increased productivity and decreased maintenance costs can be achieved in the specified domain compared to if GPL:s were used[11].

2.3

Meta attack language (MAL)

The approach is to test the feasibility of implementing generic types of attacks against a specific system to find the existing vulnerabilities with the help of MAL. In MAL it is possible to create a digital representation of a system. This is represented in the code through different objects describing different components in a system, possible entry points and how it is protected. An example of such an implementation is brute-forcing a password with the help of a cracking dictionary. To brute-force a password with a dictionary takes approximately 18 hours.

c l a s s C r e d e n t i a l s {

& d i c t i o n a r y C r a c k [ 1 8 . 0 ] }

After running a simulation with the help of MAL an attack graph will be re-turned with the path to compromise the system. Also, the time to compromise the system is returned. Time to compromise means the time from the start of the attack until it reaches the sensitive systems[7].

Some of the important keywords in MAL are category and asset. Category can be thought of as an equivalent of a Java package whereas an asset corre-sponds to a Java class. There are also a few important keywords. In figure 2.1 an explanation of the different symbols which will be used can be found [12].

(13)

CHAPTER 2. BACKGROUND 5

Figure 2.1: MAL symbols used in our project

2.3.1

Testing MAL

When testing the compiled code the MAL project has a few of its own testing methods which can be used with the jUnit package. All of these are assertion methods and there is six of them in total. assertUncompromised() checks if the attack step was unsuccessful in compromising its target. assertUncom-promisedFrom(parent) works similarly but the attack step must come from the specified parent. assertCompromisedInstantaneously() checks if the target was compromised immediately. assertCompromisedInstantaneouslyFrom(parent) as expected checks if the target was compromised instantaneously from the specified parent attack step. assertCompromisedWithEffort() checks if the tar-get was compromised after some time and/or effort was spent. assertCompro-misedWithEffortFrom(parent) does the same as the previous method but starts from a specific parent attack step [12].

2.4

MITRE ATT&CK Matrix

MITRE ATT&CK is a knowledge base consisting of different tactics and tech-niques. A tactic in this instance refers to an adversary’s goal for performing a specific action. Techniques refer to how a tactical goal is achieved. For exam-ple, Initial Access is a tactic because it is the goal of the adversary, whereas Spearphishing link is a technique because it is how the adversary might get ini-tial access. Just as in the example all of the techniques are linked to a specific tactic. This is visualized in the MITRE ATT&CK Matrix. Each tactic has its

(14)

6 CHAPTER 2. BACKGROUND

own column where all of its associated techniques can be found. In figure 2.2 a small part of the MITRE ATT&CK Matrix can be seen. In particular, it is important to note that some techniques appear under multiple tactics, as can be seen in the second row where Accessibility Features are techniques under both Persistence and Privilege Escalation[13].

Figure 2.2: Some tactics and some of their techniques in MITRE ATT&CK Matrix.

A more in-depth description of the tactics and their associated techniques which we will implement in MAL follows below. In each section, a tactic and one of its techniques will be described. The techniques mentioned in the section below are the ones which will be implemented in MAL. At least one technique from each tactic will be implemented in MAL.

2.4.1

Initial Access

Initial access is the first step used to get access to a system. There are many different ways to create this first access to a system[14].

• Spearphishing Link: Sends the target an email with a link which when clicked downloads malicious code. Uses social engineering to convince the targeted user to click the link[15].

2.4.2

Execution

This tactic involves around the execution of some code the adversary wants to execute. After the adversary has initial access, the tactic of execution could be

(15)

CHAPTER 2. BACKGROUND 7

used to get access to other parts of the network[16].

• Command-Line Interface: Command-line interface is one of the most common interfaces in an operating system. If the adversary has admin privileges they can do anything they want. Even with a lower level of access in the command line an adversary can change or delete files[17].

2.4.3

Persistence

The tactic of Persistence is about the adversary getting a persistent presence on a system. An adversary also needs to keep this presence if there is a restart or similar[18].

• Bootkit: Adversary runs code that modifies the boot section of a hard drive so something runs before the operating system is started[19].

2.4.4

Privilege Escalation

Privilege Escalation is about the adversary gaining more and more privileges to ensure the adversary can use the features the adversary wants to[20].

• Process injection: Process injection is a method to run a program along-side an older program that is run. Running the program alongalong-side the other program can give the adversary’s program access to memory, sys-tem resources or elevated privileges[21].

2.4.5

Defense Evasion

The tactic of Defense Evasion is about an adversary through various tech-niques avoiding detection of a system’s defensive software such as antivirus programs. Sometimes techniques used in other tactics also help here[22].

• File Deletion: The adversary removes tools, code and files used in the at-tack to leave the least amount of things after the atat-tack has happened[23].

2.4.6

Credential Access

Credential access is about an adversary getting control over a system used in an enterprise environment by getting and using the legitimate access credentials of one of the employees in the organization[24].

• Credential dumping: This technique is about an adversary getting login credentials from the operating system or hardware[25].

(16)

8 CHAPTER 2. BACKGROUND

2.4.7

Discovery

This tactic is about an adversary through various techniques gaining knowl-edge about a system or network. The information and knowlknowl-edge gained are used to see what further actions can be taken[26].

• Password Policy Discovery: When gaining information about a system, an adversary can access the company’s password policy. By doing this the adversary can highly limit the passwords to try and thus increasing the chance of success[27].

2.4.8

Lateral Movement

Lateral movement is a collection of techniques that lets the adversary control remote systems and networks[28].

• Replication through removable media: Replication through removable media is a technique which allows an adversary to gain access to more systems within a network by maliciously altering files or adding files on removable media[29].

2.4.9

Collection

Different ways to identify and gather sensitive information on a system or net-work before sending it[30].

• Audio capture: The technique of Audio capture is to use peripherals and/or software of an attacked system to record and listen to sensitive conversations[31].

2.4.10

Exfiltration

Exfiltration refers to the technique to exfiltrate files or information from a net-work[32].

• Data Compressed: An adversary might compress the data which is to be exfiltrated to reduce packet size and thus avoid getting detected by the security features of the system[33].

(17)

CHAPTER 2. BACKGROUND 9

2.4.11

Command and Control

Command and control represent the different ways an adversary can control and communicate to a system through a compromised unit in a system or net-work[34].

• Data Obfuscation: The technique of Data Obfuscation is using encrypted or otherwise difficult to find or read Command and Control communi-cation. An example of this is adding junk data to the traffic sent via the used protocol[35].

(18)

10 CHAPTER 2. BACKGROUND

2.5

Related Work

Our work is mainly related to previous work about the Meta Attack Lan-guage(MAL) and threat modelling with attack graphs.

The Meta Attack Language has been used in other research to create Do-main Specific Languages(DSL). One such example is vehicleLang written by Sotirios Katsikeas[36] which is a DSL created in MAL for the purpose to iden-tify vulnerabilities in vehicles. The program models vehicles.

In another report by Katsikeas et al[37], cyber attacks against vehicles were identified and used as test cases. The language was also verified by interview-ing a domain expert from the automotive industry.

SecuriCAD is a program developed to easily create a threat model for a sys-tem. When run, it generates attack graphs and calculates the average time to compromise[38].

(19)

Chapter 3

Methods

Java and the library jUnit was used to write the tests and Maven was used to compile and run the tests. Maven and the MAL-compiler were used to com-pile the MAL code into Java code.

Each of the Mitre ATT&CK-techniques mentioned in section 6 was imple-mented in MAL. To be able to realistically model an attack on a system, a simple system was also modelled. Each Mitre ATT&CK technique was first its own file with its own small system model.

The reason why only the techniques described in section 6 were chosen was mainly due to time constraints. Implementing all of the 230 techniques[39]in the MITRE ATT&CK matrix(excluding the Impact section) simply would have been unfeasible considering the time available. Instead, one technique from each tactic was chosen. This choice was made to increase the likelihood of finding a real-world attack corresponding to the chosen techniques.

One technique was selected from each of the 11 categories which exists in the MITRE ATT&CK Matrix. If the selected technique was for a unique sys-tem, such as only for macOS or Windows, another technique in the category was arbitrarily chosen.

In the different implementations of MITRE ATT&CK-techniques, there are three categories used to represent the different assets which exist. The three categories which exist are hardware, software and person. Examples of a few of the assets are OS, browser, removable media, user and external network. To see all of the assets and how they are related, see section 3.1 and figure 3.1.

(20)

12 CHAPTER 3. METHODS

Note however that not all of the assets were used in all of the individual files. To show how the implementation of all of the different techniques as indi-vidual files was conducted, a more detailed description of the implementa-tion of spearphishing link follows below. The MAL implementaimplementa-tion of the spearphishing link is very simplified from the real world. In the simplified test there only are four assets: user, os, browser and computer. An attack is consid-ered successful if the attacker steals the user’s login info och downloads a file to the computer. The browser asset in the spearphishing link attack contains all the logic for the attack. The browser has two different defences and two ways to use the spearphishing link to compromise a system.

When a suitable source was found, the probability distribution feature in MAL was used. This feature allows for the coder to choose a probability distribution and a percentage for the success rate of the attack step. If no source was found, implementation of this was skipped.

a s s e t B r o w s e r { | s p e a r p h i s h i n g L i n k −> download , s t e a l C r e d e n t i a l s & d o w n l o a d −> os . compromise | s t e a l C r e d e n t i a l s −> u s e r . compromise # p h i s h i n g _ d e t e c t i o n −> s p e a r p h i s h i n g L i n k # a n t i v i r u s −> download }

(21)

CHAPTER 3. METHODS 13

Figure 3.1: Graphical meta model for attackLang

3.1

AttackLang

All of the individual attacks from the MITRE ATT&CK-techniques which were implemented in MAL were then combined into one unified system called attackLang. The reason for this was to create a more complete representation of a system. This allows us to more clearly see how one attack step leads into the next and so on. In figure 3.1 a graphical metamodel of attackLang can be found. It shows the different assets and how they are connected. A dashed line with a triangle at the end signifies inheritance whereas the straight lines show how the assets are related.

(22)

Chapter 4

Results

In this section, the results of the different tests will be presented. There are two types of tests. The first type of tests are tests run on the individual represen-tation of an attack in individual MAL files. Another type of tests are tests run against attackLang with is a combined MAL file of the different attacks. To see the full test results, as well as the full MAL- and Java code, see Appendix A and B respectively.

4.1

Test for individual MAL files

Here is a part of the spearphishing link test code for the individual MAL file. In the test, four assets are created. The two false parameters in the browser input field are to set the two possible defenses to not exist for this test.

U s e r u s e r = new U s e r ( " WebUser " ) ;

C o m p u t e r comp = new C o m p u t e r ( " U s e r C o m p u t e r " ) ; B r o w s e r b r o w s e r = new B r o w s e r ( " B r o w s e r " , f a l s e ,

f a l s e ) ;

OS o s = new OS ( "OS" ) ;

To verify that the expected result happens there are different types of asser-tions(described in section 2.3.1). In this test, the expected result is that the system is compromised.

(23)

CHAPTER 4. RESULTS 15

comp . c o m p r o m i s e . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; u s e r . c o m p r o m i s e . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ;

The two assets checked for in the test.

A test which works as expected has a result which looks like this:

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− T E S T S −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− R u n n i n g s i m p l e T e s t No a t t a c k e r p r o f i l e s e l e c t e d ! T r y i n g d e f a u l t p a t h . . . + U s e r C o m p u t e r . c o m p r o m i s e was r e a c h e d i n s t a n t a n e o u s l y f r o m B r o w s e r . s p e a r p h i s h i n g L i n k a s e x p e c t e d . + WebUser . c o m p r o m i s e was r e a c h e d i n s t a n t a n e o u s l y f r o m B r o w s e r . s p e a r p h i s h i n g L i n k a s e x p e c t e d . T e s t s r u n : 1 , F a i l u r e s : 0 , E r r o r s : 0 , S k i p p e d : 0 , Time e l a p s e d : 0 . 0 7 9 s e c R e s u l t s : T e s t s r u n : 1 , F a i l u r e s : 0 , E r r o r s : 0 , S k i p p e d : 0 Result from test run

(24)

16 CHAPTER 4. RESULTS

4.2

Tests run against attackLang

For the tests run against attackLang the following techniques are tested: spearphish-ing link, data obfuscation, replication through removable media, command-line interface and a real-world attack.

There where multiple tests run for each of the tests. The spearphishing link test was run in four configurations due to there being two possible defenses against this attack. One is an antivirus which protects against agent downloads and the other is a spearphishing link detection which protects against all spearphishing link attacks. The four tests ended with one of the following codes:

u s e r . s t o l e n C r e d e n t i a l s .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; c o m p u t e r . i n f e c t e d C o m p u t e r .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; Test with no protection enabled.

u s e r . s t o l e n C r e d e n t i a l s . a s s e r t U n c o m p r o m i s e d ( ) ; c o m p u t e r . i n f e c t e d C o m p u t e r . a s s e r t U n c o m p r o m i s e d ( ) ;

Test with all protections enabled.

u s e r . s t o l e n C r e d e n t i a l s . a s s e r t U n c o m p r o m i s e d ( ) ; c o m p u t e r . i n f e c t e d C o m p u t e r . a s s e r t U n c o m p r o m i s e d ( ) ;

Antivirus enabled, spearphishing link detection disabled. u s e r . s t o l e n C r e d e n t i a l s .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ;

c o m p u t e r . i n f e c t e d C o m p u t e r . a s s e r t U n c o m p r o m i s e d ( ) ; Antivirus disabled, spearphishing link detection enabled.

All of the tests for the spearphishing link test started at the same point which was user.linkClicked. After that, the four tests ended with one of the four checks shown in the code snippets above. The first two tests test if all or none of the protections exists for the expected outcome. In the third test case, only the spearphishing detection is activated and the expected result is that the system is not compromised. The fourth test is the reverse of the third test. In this test, the system is expected to be protected from file downloads but not form stealing credentials. All of the tests were successful.

(25)

CHAPTER 4. RESULTS 17

For the command-line interface test, there was an assumption made. The as-sumption is that the tests are run from the point that the adversary has access to a user account ether remotely or physically. In some tests, the admin account is protected and in others not. The test endpoint is when the adversary has admin rights.

a d m i n i s t r a t o r . a d m i n R i g h t s .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; User has admin access.

a d m i n i s t r a t o r . a d m i n R i g h t s . a s s e r t U n c o m p r o m i s e d ( ) ; User has admin access.

If the adversary has access to the user info of a user the test expects that the system is compromised. Otherwise, it is expected to be secure. All of the tests were successful.

Replication through removable media had two tests. One test is for when the operating system has autorun enabled and the other if it is disabled.

c o m p u t e r . i n f e c t e d C o m p u t e r .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; Autorun enabled.

c o m p u t e r . i n f e c t e d C o m p u t e r . a s s e r t U n c o m p r o m i s e d ( ) ; Autorun disabled.

The system is expected to be compromised if infected removable media is inserted in the computer with autorun enabled. Otherwise, it is expected to be secure. All of the tests were successful.

(26)

18 CHAPTER 4. RESULTS

The data obfuscation has the infected computer step as its start point. It then checks that an adversary could reach the data obfuscation step and then reach the upload step. There is a defence against this called network intrusion de-tection and prevention systems. All of the tests were successful.

a d v e r s a r y . o b f u s c a t e D a t a .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; e x t e r n a l N e t w o r k . u p l o a d .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y F r o m ( a d v e r s a r y . o b f u s c a t e D a t a ) ;

Network intrusion detection and prevention systems disabled. a d v e r s a r y . o b f u s c a t e D a t a .

a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ;

e x t e r n a l N e t w o r k . u p l o a d . a s s e r t U n c o m p r o m i s e d F r o m ( a d v e r s a r y . o b f u s c a t e D a t a ) ;

Network intrusion detection and prevention systems enabled.

4.3

Real world attack

The last of the tests which were run is a real-world test we chose[40].The test is split up into three test steps. The first step in the test is a spearphishing link which can infect the computer. After this step, there is supposed to be a database attack step to collect the information. Since this attack is not one of the implemented attack steps in MAL, the step is treated as a black box which just works. The second step goes from the infected computer step to the data obfuscation step. Lastly, the third step tests if the collected and obfuscated data can reach the upload step.

(27)

CHAPTER 4. RESULTS 19 / / A t t a c k A t t a c k e r a t t a c k e r = new A t t a c k e r ( ) ; a t t a c k e r . a d d A t t a c k P o i n t ( u s e r . l i n k C l i c k e d ) ; a t t a c k e r . a t t a c k ( ) ; / / S e c t i o n 3 : A s s e r t i o n s c o m p u t e r . i n f e c t e d C o m p u t e r . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; Start- and endpoint for step 1.

/ / A t t a c k A t t a c k e r a t t a c k e r = new A t t a c k e r ( ) ; a t t a c k e r . a d d A t t a c k P o i n t ( c o m p u t e r . i n f e c t e d C o m p u t e r ) ; a t t a c k e r . a t t a c k ( ) ; / / S e c t i o n 3 : A s s e r t i o n s a d v e r s a r y . o b f u s c a t e D a t a . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; Start- and endpoint for step 2.

/ / A t t a c k A t t a c k e r a t t a c k e r = new A t t a c k e r ( ) ; a t t a c k e r . a d d A t t a c k P o i n t ( a d v e r s a r y . o b f u s c a t e D a t a ) ; a t t a c k e r . a t t a c k ( ) ; / / S e c t i o n 3 : A s s e r t i o n s e x t e r n a l N e t w o r k . u p l o a d . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; Start- and endpoint for step 3.

(28)

20 CHAPTER 4. RESULTS

4.4

Attack Graphs

This is the generated attack graph from the spearphishing link MAL file. In the figure 4.1 all of the assets are opened to make it possible to see the differ-ent attack steps and defenses all of the assets have and how they are connected. In figure 4.2 the attack graph for attackLang is shown. The figure shows the steps that are used to steal a user login information. Note however that only a few of the connections are shown, as showing all of the connections would make the figure to cluttered.

(29)

CHAPTER 4. RESULTS 21

(30)

Chapter 5

Discussion

The generated attack graphs for attackLang and the individual MAL-files looked as expected considering the examples from the MAL BoK and other sources. The attack graphs also make sense since it has similarities with the graphical metamodel in this report. All of the tests also worked as expected, both for individual MAL-files and for attackLang. The MITRE ATT&CK-techniques seems possible to implement in MAL correctly given sufficient time.

An issue which was encountered was that not all of the attack steps could not be properly tested due to their size and scope. Some of the techniques really just had one attack step and no defence. Due to this, it was not possible to write any meaningful tests for these few techniques. This could be due to our implementation of these techniques as attack steps or it could be due to how they were described in the MITRE ATT&CK matrix.

One of the features which have not been implemented due to time constraints is all variations of defences. There are a few types of defences that have not been implemented. One is defences which protect data for a given time or effort like passwords at least temporarily protects against brute-force attacks. The second type is the probability that a person does something like clicking on a link or inserting an infected USB or similar.

Due to the techniques being picked randomly, it might be that we got unlucky and just got multiple techniques with hard to implement defences. Another result of picking columns randomly was that it was hard to find real attacks which used the specific attack steps which were implemented. One such at-tack was found in the end but some parts of the atat-tack were not something

(31)

CHAPTER 5. DISCUSSION 23

we had previously implemented in MAL. Thus we had to skip the steps in the middle which we had not implemented in MAL when designing the test. All of the tests run on the 11 implemented attack techniques in MAL were successful. This means that almost 5% of the attacks in the matrix were im-plemented successfully in MAL. Since the techniques were arbitrarily chosen from each of the categories, it could be argued that all of the attacks in the MITRE ATT&CK matrix is possible to implement in MAL.

Due to the results from the tests run on the implemented MAL code it seems to be likely that the entirety of the MITRE ATT&CK matrix can be imple-mented in MAL. This would mean that if a complete version of attackLang was created, it could then be used to relatively fast and easy create a test im-plementation of a user system. This could then be used to see which weak points the system has and what could be done to minimise the threats to the system.

5.1

Future work

As the study conducted in this paper only implements a few of the cyber attack techniques of the MITRE ATT&CK matrix, there are many possibilities for further research. Here are a few of these possibilities:

• Implementing all of the techniques in the ATT&CK matrix in MAL would be a much stronger validation of MAL. This includes all of the techniques in the recently added Impact tactic.

• If more or all of the techniques are to be implemented in MAL, how should this be done? Is it more efficient to continue working on our big combined file attackLang or should it be done piece by piece? Could the process be automated and thus make the process faster?

• Another way of implementing more parts of the ATT&CK matrix in MAL could be to find an existing attack and implementing all of the techniques it uses. This would avoid the problem we had of it being hard to find real attacks.

• Relating the work to MITRE:s Cyber Threat Intelligence repository on Github.

(32)

Chapter 6

Conclusions

What type of attacks can be expressed by the Meta Attack Language (MAL)? Based on the implementation and test runs of the randomly selected techniques of the MITRE ATT&CK matrix, it is probable that all of the different MITRE ATT&CK-techniques could be implemented in MAL. This would mean that a wide variety of cyber attacks can be expressed in MAL. The fact that a real attack was able to be implemented and tested against further strengthens this argument.

(33)

Bibliography

[1] Kate Fazzini. The great Equifax mystery: 17 months later, the stolen data has never been found, and experts are starting to suspect a spy scheme. 2019. url: https://www.cnbc.com/2019/02/13/ equifax- mystery- where- is- the- data.html. (Retrieved 2019-03-29).

[2] Susanna Lidström. Företaget som hittar energisystemens säkerhetshål. 2018. url: https : / / www . energivarlden . se / artikel / foretaget-som-hittar-energisystemens-sakerhetshal/. (Retrieved 2019-03-29).

[3] Mattias Malmqvist. Svensk teknik simulerar cyberattacker – nu testar de Klarnas moln. 2019. url: https://computersweden.idg. se / 2 . 2683 / 1 . 715831 / svensk teknik simulerar -cyberattacker-klarnas-moln. (Retrieved 2019-03-29). [4] Bruce Schneier. “Attack Trees”. In: Dr. Dobb’s Journal (1999).

[5] Oleg Sheyner et al. “Automated generation and analysis of attack graphs”. In: Proceedings 2002 IEEE Symposium on Security and Privacy, Berke-ley, CA, USA, May 12–15, 2002. 2002.

[6] Greg Michaelson. “Are there domain specific languages?” In: Proceed-ings of the 1st International Workshop on Real World Domain Specific Languages, Barcelona, Spain, March 12–12, 2016. 2016.

[7] Pontus Johnson, Robert Lagerström, and Mathias Ekstedt. “A Meta Lan-guage for Threat Modeling and Attack Simulations”. In: Proceedings ofInternational Conference on Availability, Reliability and Security, Ham-burg,Germany, August 27–30, 2018 (ARES 2018). 2018.

[8] MITRE Coprporation. MITRE ATT&CK. Retrieved: 2019-02-10. url: https://attack.mitre.org/.

(34)

26 BIBLIOGRAPHY

[9] Dianxang Xu and Kendall Nygard. “A Threat-Driven Approach to Mod-eling and Verifying Secure Software”. In: Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, Long Beach, California, USA, November 7-11, 2005. 2005.

[10] Arie van Deursen, Paul Klint, and Joost Visser. “Domain-Specific Lan-guages: An Annotated Bibliography”. In: ACM SIGPLAN Notices 35.6 (June 2000), pp. 26–36.

[11] Marjan Hernik, Jan Heering, and Anthony M. Sloane. “When and How to Develop Domain-Specific Languages”. In: ACM Computing Surveys (CSUR) 37.4 (Dec. 2005), pp. 316–344.

[12] Engla Ling et al. MAL BoK: the Meta Attack Language Body of Knowl-edge and User Guide version 1.0, MAL version 0.0.3-2. 2019.

[13] Blake Storm. ATT&CK 101. Retrieved: 2019-03-18. 2018. url: https: //www.mitre.org/capabilities/cybersecurity/overview/ cybersecurity-blog/attck-101.

[14] MITRE Coprporation. Initial Access. Retrieved: 2019-02-10. url: https: //attack.mitre.org/tactics/TA0001/.

[15] MITRE Coprporation. Spearphishing link. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/T1192/.

[16] MITRE Coprporation. Execution. Retrieved: 2019-02-10. url: https: //attack.mitre.org/tactics/TA0002/.

[17] MITRE Coprporation. Command-line interface. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/T1059/. [18] MITRE Coprporation. Persistence. Retrieved: 2019-02-10. url: https:

//attack.mitre.org/tactics/TA0003/.

[19] MITRE Coprporation. Bootkit. Retrieved: 2019-02-10. url: https: //attack.mitre.org/techniques/T1067/.

[20] MITRE Coprporation. Privilege Escalation. Retrieved: 2019-02-10. url: https://attack.mitre.org/tactics/TA0004/.

[21] MITRE Coprporation. Process Injection. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/T1055/. [22] MITRE Coprporation. Defense Evasion. Retrieved: 2019-02-10. url:

https://attack.mitre.org/tactics/TA0005/.

[23] MITRE Coprporation. File Deletion. Retrieved: 2019-02-10. url: https: //attack.mitre.org/techniques/T1107/.

(35)

BIBLIOGRAPHY 27

[24] MITRE Coprporation. Credential Access. Retrieved: 2019-02-10. url: https://attack.mitre.org/tactics/TA0006/.

[25] MITRE Coprporation. Credential Dumping. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/T1003/.

[26] MITRE Coprporation. Discovery. Retrieved: 2019-02-10. url: https: //attack.mitre.org/tactics/TA0007/.

[27] MITRE Coprporation. Password Policy Discovery. Retrieved: 2019-02-10. url: https : / / attack . mitre . org / techniques / T1201/.

[28] MITRE Coprporation. Lateral Movement. Retrieved: 2019-02-10. url: https://attack.mitre.org/tactics/TA0008/.

[29] MITRE Coprporation. Replication through Removable Media. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/ T1091/.

[30] MITRE Coprporation. Collection. Retrieved: 2019-02-10. url: https: //attack.mitre.org/tactics/TA0009/.

[31] MITRE Coprporation. Audio Capture. Retrieved: 2019-02-10. url: https: //attack.mitre.org/techniques/T1123/.

[32] MITRE Coprporation. Exfiltration. Retrieved: 2019-02-10. url: https: //attack.mitre.org/tactics/TA0010/.

[33] MITRE Coprporation. Data Compressed. Retrieved: 2019-02-10. url: https://attack.mitre.org/techniques/T1002/. [34] MITRE Coprporation. Command and Control. Retrieved: 2019-02-10.

url: https://attack.mitre.org/tactics/TA0011/. [35] MITRE Coprporation. Data Obfuscation. Retrieved: 2019-02-10. url:

https://attack.mitre.org/techniques/T1001/. [36] Sotirios Katsikeas. “vehicleLang: a probabilistic modeling and

simula-tion language for vehicular cyber attacks”. MA thesis. KTH, 2018. [37] Sotirios Katsikeas et al. “Probabilistic Modeling and Simulation of

Ve-hicular Cyber Attacks: An Application of the Meta Attack Language”. In: Proceedings of the 5th International Conference on Information Sys-tems Security and Privacy (ICISSP). 2019.

(36)

28 BIBLIOGRAPHY

[38] Pontus Johnson et al. “Securi CAD by Foreseeti: A CAD Tool for Enter-prise Cyber Security Management”. In: Proceedings of the 19th IEEE International EDOC Conference, Adelaide, SA, Australia, Sept. 2015. 2015.

[39] MITRE Coprporation. Enterprise techniques. Retrieved: 2019-05-10. url: https://attack.mitre.org/techniques/enterprise/. [40] FireEye. Spear-Phishing Attacks - Why they are successful and how to

stop them. Retrieved: 2019-05-10. url: https://www.fireeye. com/content/dam/fireeye-www/global/en/products/ pdfs/wp-fireeye-how-stop-spearphishing.pdf.

(37)

Appendix A

Source Code

A.1

spearphishingLink.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | c o m p r o m i s e } } c a t e g o r y S o f t w a r e { a s s e t B r o w s e r { | s p e a r p h i s h i n g L i n k −> download , s t e a l C r e d e n t i a l s & d o w n l o a d −> os . compromise | s t e a l C r e d e n t i a l s −> u s e r . compromise # p h i s h i n g _ d e t e c t i o n −> s p e a r p h i s h i n g L i n k # a n t i v i r u s −> download } a s s e t OS { 29

(38)

30 APPENDIX A. SOURCE CODE | c o m p r o m i s e −> c o m p u t e r . compromise } } c a t e g o r y P e r s o n { a s s e t U s e r { | c o m p r o m i s e i n f o : " a c c e s s ␣ t o ␣ o n e ␣ u s e r ␣ p a s s w o r d " } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1−∗ [ o s ] OS OS [ o s ] 1 <−− s y s t e m −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ b r o w s e r ] B r o w s e r }

A.2

commandLineInterface.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | c o m p r o m i s e } } c a t e g o r y S o f t w a r e { a s s e t OS { | u s e r L o g i n −> u s e r . adminLogin

(39)

APPENDIX A. SOURCE CODE 31 # p a s s w o r d E n c r y p t i o n −> u s e r . adminLogin | c o m m a n d L i n e A c c e s s −> c o m p u t e r . compromise } } c a t e g o r y P e r s o n { a s s e t U s e r { | a d m i n L o g i n −> a d m i n i s t r a t o r . a d m i n R i g h t s # p a s s w o r d E n c r y p t i o n −> a d m i n i s t r a t o r . a d m i n R i g h t s } a s s e t A d m i n i s t r a t o r { | a d m i n R i g h t s i n f o : " a c c e s s ␣ t o ␣ o n e ␣ s u d o ␣ p a s s w o r d " −> os . commandLineAccess } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r OS [ o s ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r }

A.3

audioCapture.mal

(40)

32 APPENDIX A. SOURCE CODE c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | h a v e M i c r p h o n e −> compromise & c o m p r o m i s e −> n e t w o r k . s e n d i n f o } a s s e t N e t w o r k { | s e n d i n f o } } a s s o c i a t i o n s { / / U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ n e t w o r k ] N e t w o r k C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1 [ n e t w o r k ] N e t w o r k }

A.4

bootkit.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | c o m p r o m i s e −> n e t w o r k . s e n d I n f o } a s s e t N e t w o r k { | s e n d I n f o | d o w n l o d e F i l e −> os . downloded }

(41)

APPENDIX A. SOURCE CODE 33 } c a t e g o r y S o f t w a r e { a b s t r a c t A s s e t OS { | u s e r L o g i n −> u s e r . adminLogin # p a s s w o r d E n c r y p t i o n −> u s e r . adminLogin | d o w n l o d e d −> r u n F i l e | r u n F i l e −> c o m p u t e r . compromise } a s s e t L i n u x e x t e n d s OS { } a s s e t Windows e x t e n d s OS { } } c a t e g o r y P e r s o n { a s s e t U s e r { | a d m i n L o g i n −> a d m i n i s t r a t o r . a d m i n R i g h t s # p a s s w o r d E n c r y p t i o n −> a d m i n i s t r a t o r . a d m i n R i g h t s } a s s e t A d m i n i s t r a t o r { | a d m i n R i g h t s −> n e t w o r k . d o w n l o d e F i l e i n f o : " a c c e s s ␣ t o ␣ o n e ␣ s u d o ␣ p a s s w o r d " } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] ∗ <−− s y s t e m −−> 1 [ n e t w o r k ] N e t w o r k C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1−∗ [ o s ] OS OS [ o s ] 1 <−− s y s t e m −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS

(42)

34 APPENDIX A. SOURCE CODE U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r OS [ o s ] 1 <−− s y s t e m −−> 1 [ l i n u x ] L i n u x OS [ o s ] 1 <−− s y s t e m −−> 1 [ windows ] Windows N e t w o r k [ n e t w o r k ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r OS [ o s ] 1 <−− s y s t e m −−> 1 [ windows ] Windows OS [ o s ] 1 <−− s y s t e m −−> 1 [ n e t w o r k ] N e t w o r k }

A.5

credentialDumping.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { } a s s e t N e t w o r k { } } c a t e g o r y S o f t w a r e { a b s t r a c t A s s e t OS { | u s e r L o g i n −> u s e r . adminLogin # p a s s w o r d E n c r y p t i o n −> u s e r . adminLogin }

(43)

APPENDIX A. SOURCE CODE 35 } c a t e g o r y P e r s o n { a s s e t U s e r { | a d m i n L o g i n −> a d m i n i s t r a t o r . a d m i n R i g h t s # p a s s w o r d E n c r y p t i o n −> a d m i n i s t r a t o r . a d m i n R i g h t s | u s e r C r e d e n t i a l −> os . u s e r L o g i n } a s s e t A d m i n i s t r a t o r { | a d m i n R i g h t s −> u s e r . u s e r C r e d e n t i a l i n f o : " a c c e s s ␣ t o ␣ o n e ␣ s u d o ␣ p a s s w o r d " } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r }

A.6

dataCompressed.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t N e t w o r k { | s e n d i n f o } }

(44)

36 APPENDIX A. SOURCE CODE c a t e g o r y P e r s o n { a s s e t A d v e r s a r y { | c o m p r e s s D a t a −> n e t w o r k . s e n d i n f o } } a s s o c i a t i o n s { A d v e r s a r y [ a d v e r s a r y ] 1−∗ <−− u s e −−> 1−∗ [ n e t w o r k ] N e t w o r k }

A.7

dataObfuscation.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t N e t w o r k { | s e n d i n f o S e c r e t l y } } c a t e g o r y P e r s o n { a s s e t A d v e r s a r y { | o b f u s c a t e D a t a −> n e t w o r k . s e n d i n f o S e c r e t l y } } a s s o c i a t i o n s { A d v e r s a r y [ a d v e r s a r y ] 1−∗ <−− u s e −−> 1−∗ [ n e t w o r k ] N e t w o r k }

A.8

fileDeletion.mal

(45)

APPENDIX A. SOURCE CODE 37 c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | d e l e t e F i l e s } } c a t e g o r y P e r s o n { a s s e t U s e r { | e d i t F i l e −> c o m p u t e r . d e l e t e F i l e s i n f o : " " } } a s s o c i a t i o n s { U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r }

A.9

passwordPolicyDiscovery.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { } a s s e t N e t w o r k { | s e n d I n f o } } c a t e g o r y S o f t w a r e { a s s e t OS { | p o l i c y D i s c o v e r y −> n e t w o r k . s e n d I n f o

(46)

38 APPENDIX A. SOURCE CODE } } c a t e g o r y P e r s o n { a s s e t U s e r { | c o m m a n d l i n e U s a g e −> os . p o l i c y D i s c o v e r y } } a s s o c i a t i o n s { U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS OS [ o s ] 1 <−− s y s t e m −−> 1 [ n e t w o r k ] N e t w o r k }

A.10

processInjection.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | c o m p r o m i s e } } c a t e g o r y S o f t w a r e { a b s t r a c t A s s e t OS { | u s e r L o g i n −> u s e r . adminLogin # p a s s w o r d E n c r y p t i o n −> u s e r . adminLogin | d o w n l o d e d −> r u n F i l e | r u n F i l e −> c o m p u t e r . compromise }

(47)

APPENDIX A. SOURCE CODE 39 a s s e t L i n u x e x t e n d s OS { | p t r a c e S y s t e m C a l l s −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | v d s o H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | l d P r e l o a d −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | l d L i b r a r y P a t h −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | r e a d O r W r i t e M e m −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " } a s s e t MacOS e x t e n d s OS { | p t r a c e S y s t e m C a l l s −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | v d s o H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | d y l d I n s e r t L i b r a i e s −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | r e a d O r W r i t e M e m −> a d m i n i s t r a t o r . runCodeAdmin

(48)

40 APPENDIX A. SOURCE CODE i n f o : " " } a s s e t Windows e x t e n d s OS { | d y n a m i c L i n k L i b r a r y I n j e c t i o n −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " A n o t h e r ␣ p r o c e s s ␣ w i t h ␣ a l l ␣ i t s ␣ t h r e a d s ␣ i s ␣ r u n n i n g ␣ i n s i d e ␣ a n o t h e r ␣ v i r t u a l ␣ a d d r e s s ␣ s p a c e " | p o r t a b l e E x e c u t a b l e I n j e c t i o n −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | t h r e a d E x e c u t i o n H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | a s y n c h r o n o u s P r o c e d u r e C a l l −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " | t h r e a d L o c a l S t o r a g e −> a d m i n i s t r a t o r . runCodeAdmin i n f o : " " } } c a t e g o r y P e r s o n { a s s e t U s e r { | a d m i n L o g i n −> a d m i n i s t r a t o r . a d m i n R i g h t s # p a s s w o r d E n c r y p t i o n −> a d m i n i s t r a t o r . a d m i n R i g h t s | r u n C o d e −> windows . d y n a m i c L i n k L i b r a r y I n j e c t i o n , windows . p o r t a b l e E x e c u t a b l e I n j e c t i o n , windows . t h r e a d E x e c u t i o n H i j a c k i n g , windows . a s y n c h r o n o u s P r o c e d u r e C a l l ,

(49)

APPENDIX A. SOURCE CODE 41 windows . t h r e a d L o c a l S t o r a g e , l i n u x . l d L i b r a r y P a t h , l i n u x . v d s o H i j a c k i n g , l i n u x . readOrWriteMem , l i n u x . l d P r e l o a d , l i n u x . p t r a c e S y s t e m C a l l s , macOS . p t r a c e S y s t e m C a l l s , macOS . readOrWriteMem , macOS . v d s o H i j a c k i n g , macOS . d y l d I n s e r t L i b r a i e s } a s s e t A d m i n i s t r a t o r { | a d m i n R i g h t s −> c o m p u t e r . compromise i n f o : " a c c e s s ␣ t o ␣ o n e ␣ s u d o ␣ p a s s w o r d " | runCodeAdmin −> a d m i n R i g h t s } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1−∗ [ o s ] OS OS [ o s ] 1 <−− s y s t e m −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ o s ] OS U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ c o m p u t e r ] C o m p u t e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r OS [ o s ] 1 <−− s y s t e m −−> 1 [ l i n u x ] L i n u x OS [ o s ] 1 <−− s y s t e m −−> 1 [ windows ] Windows OS [ o s ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r C o m p u t e r [ c o m p u t e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r U s e r [ u s e r ] 1 <−− s y s t e m −−> 1 [ windows ] Windows U s e r [ u s e r ] 1 <−− s y s t e m −−> 1 [ l i n u x ] L i n u x

(50)

42 APPENDIX A. SOURCE CODE U s e r [ u s e r ] 1 <−− s y s t e m −−> 1 [ macOS ] MacOS }

A.11

replicationThroughRemovableMedia.mal

c a t e g o r y H a r d w a r e i n f o : " " { a s s e t C o m p u t e r { | c o m p r o m i s e } a s s e t R e m o v a b l e M e d i a { | c o m p r o m i s e −> c o n n e c t e d & c o n n e c t e d −> c o m p u t e r . compromise } } c a t e g o r y P e r s o n { a s s e t E m p l o y e e { | i n s e r t M e d i a −> removableMedia . c o n n e c t e d | r e m o v e M e d i a −> i n s e r t M e d i a } } a s s o c i a t i o n s {

(51)

APPENDIX A. SOURCE CODE 43 E m p l o y e e [ e m p l o y e e ] 1−∗ <−− u s e −−> 1−∗ [ r e m o v a b l e M e d i a ] R e m o v a b l e M e d i a C o m p u t e r [ c o m p u t e r ] 1 <−− s y s t e m −−> 1 [ r e m o v a b l e M e d i a ] R e m o v a b l e M e d i a }

A.12

AttackLang.mal

c a t e g o r y P e r s o n { a s s e t U s e r { | s t o l e n C r e d e n t i a l s −> c o m p u t e r . s e n d D a t a , a d v e r s a r y . c o m p r e s s D a t a , a d v e r s a r y . o b f u s c a t e D a t a | l i n k C l i c k e d [ U n i f o r m D i s t r i b u t i o n ( 2 0 , 1 ) ] r a t i o n a l e : " 20 ␣%␣ l i n k ␣ h t t p s : / / f a u i 1 − f i l e s . c s . f a u . d e / f i l e p o o l / p u b l i c a t i o n s / z i n a /2017 − b e n e n s o n −u n p a c k i n g −s p e a r −p h i s h i n g . p d f " −> b r o w s e r . s p e a r p h i s h i n g L i n k | a d m i n L o g i n −> adminCheck & a d m i n C h e c k −> a d m i n i s t r a t o r . a d m i n R i g h t s , o s . a d m i n T e r m i n a l # a d m i n A c c e s s −> adminCheck | u s e r C r e d e n t i a l −> employee . u s e r L o g i n | e d i t F i l e −> c o m p u t e r . d e l e t e F i l e s | c o m m a n d l i n e U s a g e −> os . p o l i c y D i s c o v e r y | r u n C o d e −> windows . d y n a m i c L i n k L i b r a r y I n j e c t i o n , windows . p o r t a b l e E x e c u t a b l e I n j e c t i o n , windows . t h r e a d E x e c u t i o n H i j a c k i n g , windows . a s y n c h r o n o u s P r o c e d u r e C a l l , windows . t h r e a d L o c a l S t o r a g e ,

(52)

44 APPENDIX A. SOURCE CODE l i n u x . l d L i b r a r y P a t h , l i n u x . v d s o H i j a c k i n g , l i n u x . readOrWriteMem , l i n u x . l d P r e l o a d , l i n u x . p t r a c e S y s t e m C a l l s , macOS . p t r a c e S y s t e m C a l l s , macOS . readOrWriteMem , macOS . v d s o H i j a c k i n g , macOS . d y l d I n s e r t L i b r a i e s , o s . r u n F i l e } a s s e t A d m i n i s t r a t o r { | a d m i n R i g h t s i n f o : " a c c e s s ␣ t o ␣ o n e ␣ s u d o ␣ p a s s w o r d " −> runCodeAdmin | runCodeAdmin −> c o m p u t e r . i n f e c t e d C o m p u t e r } a s s e t A d v e r s a r y { | c o m p r e s s D a t a −> e x t e r n a l N e t w o r k . s e n d I n f o | o b f u s c a t e D a t a −> e x t e r n a l N e t w o r k . s e n d I n f o S e c r e t l y | s p e a r p h i s h i n g L i n k A t t a c k −> b r o w s e r . s p e a r p h i s h i n g L i n k , u s e r . l i n k C l i c k e d } a s s e t E m p l o y e e { | i n s e r t M e d i a −> removableMedia . c o n n e c t e d | r e m o v e M e d i a −> i n s e r t M e d i a | u s e r L o g i n −> l o g i n C h e c k

(53)

APPENDIX A. SOURCE CODE 45 & l o g i n C h e c k −> u s e r . adminLogin # p a s s w o r d E n c r y p t i o n −> l o g i n C h e c k } } c a t e g o r y H a r d w a r e { a s s e t C o m p u t e r { | c o n n e c t e d T o N e t w o r k i n f o : " To␣ b e ␣ u s e d ␣ t o ␣ e n s u r e ␣ t h a t ␣ c o m p u t e r s ␣ m u s t ␣ b e ␣ c o n n e c t e d ␣ t o ␣ b e ␣ a b l e ␣ t o ␣ s e n d ␣ d a t a ␣ v i a ␣ t h e ␣ i n t e r n e t " | s e n d D a t a −> e x t e r n a l N e t w o r k . s e n d I n f o , e x t e r n a l N e t w o r k . s e n d I n f o S e c r e t l y | i n f e c t e d C o m p u t e r −> e x t e r n a l N e t w o r k . s e n d I n f o , r e m o v a b l e M e d i a . i n f e c t e d M e d i a , c o l l e c t A u d i o , a d v e r s a r y . c o m p r e s s D a t a , a d v e r s a r y . o b f u s c a t e D a t a | d e l e t e F i l e s | h a v e M i c r p h o n e −> c o l l e c t A u d i o & c o l l e c t A u d i o −> s e n d D a t a } a s s e t E x t e r n a l N e t w o r k { & n e t w o r k I n t r u s i o n D e t e c t i o n A n d P r e v e n t i o n S y s t e m s C h e c k −> u p l o a d # n e t w o r k I n t r u s i o n D e t e c t i o n A n d P r e v e n t i o n S y s t e m s

(54)

46 APPENDIX A. SOURCE CODE −> n e t w o r k I n t r u s i o n D e t e c t i o n A n d P r e v e n t i o n S y s t e m s C h e c k | u p l o a d | c o l l e c t S e n d I n f o −> n e t w o r k I n t r u s i o n D e t e c t i o n A n d P r e v e n t i o n S y s t e m s C h e c k | s e n d I n f o −> c o l l e c t S e n d I n f o | s e n d I n f o S e c r e t l y −> c o l l e c t S e n d I n f o | d o w n l o a d e F i l e −> c o m p u t e r . i n f e c t e d C o m p u t e r } a s s e t P r i v a t e N e t w o r k { | c o n n e c t T o O t h e r C o m p u t e r i n f o : " p r o b l e m " } a s s e t R e m o v a b l e M e d i a { | i n f e c t e d M e d i a −> c o n n e c t e d & c o n n e c t e d −> os . autoRun } } c a t e g o r y S o f t w a r e { a s s e t B r o w s e r { | s p e a r p h i s h i n g L i n k −> d e t e c t i o n C h e c k & d e t e c t i o n C h e c k −> os . downloaded , u s e r . s t o l e n C r e d e n t i a l s

(55)

APPENDIX A. SOURCE CODE 47 # p h i s h i n g D e t e c t i o n −> d e t e c t i o n C h e c k } a b s t r a c t A s s e t OS { | d o w n l o a d e d −> a n t i v i r u s C h e c k & a n t i v i r u s C h e c k −> r u n F i l e , e x t e r n a l N e t w o r k . d o w n l o a d e F i l e # a n t i v i r u s −> a n t i v i r u s C h e c k | r u n F i l e −> c o m p u t e r . i n f e c t e d C o m p u t e r | a u t o R u n −> a u t o R u n D i s a b l e d C h e c k & a u t o R u n D i s a b l e d C h e c k −> r u n F i l e # a u t o R u n D i s a b l e d −> a u t o R u n D i s a b l e d C h e c k | p o l i c y D i s c o v e r y −> c o m p u t e r . s e n d D a t a | c o m m a n d L i n e I n t e r f a c e −> a d m i n T e r m i n a l & a d m i n T e r m i n a l −> c o m p u t e r . i n f e c t e d C o m p u t e r | i n f e c t e d O S −> c o m p u t e r . i n f e c t e d C o m p u t e r } a s s e t L i n u x e x t e n d s OS { | p t r a c e S y s t e m C a l l s −> a d m i n i s t r a t o r . runCodeAdmin | v d s o H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin | l d P r e l o a d −> a d m i n i s t r a t o r . runCodeAdmin | l d L i b r a r y P a t h −> a d m i n i s t r a t o r . runCodeAdmin | r e a d O r W r i t e M e m

(56)

48 APPENDIX A. SOURCE CODE −> a d m i n i s t r a t o r . runCodeAdmin } a s s e t MacOS e x t e n d s OS { | p t r a c e S y s t e m C a l l s −> a d m i n i s t r a t o r . runCodeAdmin | v d s o H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin | d y l d I n s e r t L i b r a i e s −> a d m i n i s t r a t o r . runCodeAdmin | r e a d O r W r i t e M e m −> a d m i n i s t r a t o r . runCodeAdmin } a s s e t Windows e x t e n d s OS { | d y n a m i c L i n k L i b r a r y I n j e c t i o n i n f o : " A n o t h e r ␣ p r o c e s s ␣ w i t h ␣ a l l ␣ i t s ␣ t h r e a d s ␣ i s ␣ r u n n i n g ␣ i n s i d e ␣ a n o t h e r ␣ v i r t u a l ␣ a d d r e s s ␣ s p a c e " −> a d m i n i s t r a t o r . runCodeAdmin | p o r t a b l e E x e c u t a b l e I n j e c t i o n −> a d m i n i s t r a t o r . runCodeAdmin | t h r e a d E x e c u t i o n H i j a c k i n g −> a d m i n i s t r a t o r . runCodeAdmin | a s y n c h r o n o u s P r o c e d u r e C a l l −> a d m i n i s t r a t o r . runCodeAdmin | t h r e a d L o c a l S t o r a g e −> a d m i n i s t r a t o r . runCodeAdmin } } a s s o c i a t i o n s { C o m p u t e r [ c o m p u t e r ] 1−∗ <−− s y s t e m −−> 1−∗ [ o s ] OS C o m p u t e r [ c o m p u t e r ] 1−∗ <−− s y s t e m −−> 1 [ e x t e r n a l N e t w o r k ] E x t e r n a l N e t w o r k C o m p u t e r [ c o m p u t e r ] 1−∗ <−− s y s t e m −−> 1−∗ [ r e m o v a b l e M e d i a ] R e m o v a b l e M e d i a E x t e r n a l N e t w o r k [ e x t e r n a l N e t w o r k ] 1 <−− s y s t e m −−> 1 [ os ] OS

(57)

APPENDIX A. SOURCE CODE 49 R e m o v a b l e M e d i a [ r e m o v a b l e M e d i a ] 1 <−− s y s t e m −−> 1 [ o s ] OS A d m i n i s t r a t o r [ a d m i n i s t r a t o r ] 1−∗ <−− u i −−> 1−∗ [ c o m p u t e r ] C o m p u t e r B r o w s e r [ b r o w s e r ] 1−∗ <−− u i −−> 1−∗ [ u s e r ] U s e r A d m i n i s t r a t o r [ a d m i n i s t r a t o r ] 1−∗ <−− u i −−> 1−∗ [ o s ] OS R e m o v a b l e M e d i a [ r e m o v a b l e M e d i a ] 1−∗ <−− u i −−> 1−∗ [ e m p l o y e e ] E m p l o y e e C o m p u t e r [ c o m p u t e r ] 1−∗ <−− u i −−> 1−∗ [ u s e r ] U s e r U s e r [ u s e r ] 1−∗ <−− u i −−> 1−∗ [ o s ] OS U s e r [ w i n U s e r ] 1−∗ <−− u i −−> 1−∗ [ windows ] Windows U s e r [ l i n x U s e r ] 1−∗ <−− u i −−> 1−∗ [ l i n u x ] L i n u x A d m i n i s t r a t o r [ a d m i n i s t r a t o r ] 1 <−− s y s t e m −−> 1 [ e x t e r n a l N e t w o r k ] E x t e r n a l N e t w o r k

U s e r [ m a cUse r ] 1−∗ <−− u i −−> 1−∗ [ macOS ] MacOS A d v e r s a r y [ a d v e r s a r y ] 1−∗ <−− u i −−> 1−∗ [ c o m p u t e r ] C o m p u t e r OS [ o s ] 1−∗ <−− s o f t w a r e −−> 1−∗ [ b r o w s e r ] B r o w s e r U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d m i n i s t r a t o r ] A d m i n i s t r a t o r U s e r [ u s e r ] 1 <−− u s e −−> 1 [ e m p l o y e e ] E m p l o y e e U s e r [ u s e r ] 1−∗ <−− u s e −−> 1−∗ [ a d v e r s a r y ] A d v e r s a r y A d v e r s a r y [ a d v e r s a r y ] 1−∗ <−− a t t a c k −−> 1−∗ [ b r o w s e r ] B r o w s e r E x t e r n a l N e t w o r k [ e x t e r n a l N e t w o r k ] 1−∗ <−− a t t a c k −−> 1−∗ [ a d v e r s a r y ] A d v e r s a r y }

(58)

50 APPENDIX A. SOURCE CODE

A.13

commandLineInterfaceTest.java for

at-tackLang

i m p o r t o r g . j u n i t . T e s t ; i m p o r t c o r e . ∗ ; i m p o r t a t t a c k . ∗ ; p u b l i c c l a s s c o m m a n d L i n e I n t e r f a c e T e s t { @Test p u b l i c v o i d t e s t 1 ( ) { / / S e c t i o n 1 : A s s e t i n s t a n t i a t i o n OS o s = new OS ( " o s " , t r u e , f a l s e ) ; U s e r u s e r = new U s e r ( " u s e r " , f a l s e ) ; E m p l o y e e e m p l o y e e = new E m p l o y e e ( " e m p l o y e e " , f a l s e ) ; A d m i n i s t r a t o r a d m i n i s t r a t o r = new A d m i n i s t r a t o r ( " a d m i n i s t r a t o r " ) ; C o m p u t e r c o m p u t e r = new C o m p u t e r ( " c o m p u t e r " ) ; / / S e c t i o n 2 : A s s e t c o n n e c t i o n s and a t t a c k e r c r e a t i o n c o m p u t e r . addOs ( o s ) ; u s e r . a d d C o m p u t e r ( c o m p u t e r ) ; u s e r . a d d A d m i n i s t r a t o r ( a d m i n i s t r a t o r ) ; u s e r . a d d E m p l o y e e ( e m p l o y e e ) ; a d m i n i s t r a t o r . addOs ( o s ) ; A t t a c k e r a t t a c k e r = new A t t a c k e r ( ) ; a t t a c k e r . a d d A t t a c k P o i n t ( u s e r . u s e r C r e d e n t i a l ) ; a t t a c k e r . a t t a c k ( ) ; / / S e c t i o n 3 : A s s e r t i o n s a d m i n i s t r a t o r . a d m i n R i g h t s . a s s e r t C o m p r o m i s e d I n s t a n t a n e o u s l y ( ) ; }

(59)

APPENDIX A. SOURCE CODE 51 @Test p u b l i c v o i d t e s t 2 ( ) { OS o s = new OS ( " o s " , t r u e , f a l s e ) ; U s e r u s e r = new U s e r ( " u s e r " , t r u e ) ; E m p l o y e e e m p l o y e e = new E m p l o y e e ( " e m p l o y e e " , t r u e ) ; A d m i n i s t r a t o r a d m i n i s t r a t o r = new A d m i n i s t r a t o r ( " a d m i n i s t r a t o r " ) ; C o m p u t e r c o m p u t e r = new C o m p u t e r ( " c o m p u t e r " ) ; c o m p u t e r . addOs ( o s ) ; u s e r . a d d C o m p u t e r ( c o m p u t e r ) ; u s e r . a d d A d m i n i s t r a t o r ( a d m i n i s t r a t o r ) ; u s e r . a d d E m p l o y e e ( e m p l o y e e ) ; e m p l o y e e . a d d U s e r ( u s e r ) ; a d m i n i s t r a t o r . addOs ( o s ) ; A t t a c k e r a t t a c k e r = new A t t a c k e r ( ) ; a t t a c k e r . a d d A t t a c k P o i n t ( u s e r . u s e r C r e d e n t i a l ) ; a t t a c k e r . a t t a c k ( ) ; a d m i n i s t r a t o r . a d m i n R i g h t s . a s s e r t U n c o m p r o m i s e d ( ) ; } }

A.14

replicationThroughRemovableMediaTest.java

for attackLang

i m p o r t o r g . j u n i t . T e s t ; i m p o r t c o r e . ∗ ; i m p o r t a t t a c k . ∗ ; p u b l i c c l a s s r e p l i c a t i o n T h r o u g h R e m o v a b l e M e d i a T e s t { @Test

References

Related documents

Stöden omfattar statliga lån och kreditgarantier; anstånd med skatter och avgifter; tillfälligt sänkta arbetsgivaravgifter under pandemins första fas; ökat statligt ansvar

För att uppskatta den totala effekten av reformerna måste dock hänsyn tas till såväl samt- liga priseffekter som sammansättningseffekter, till följd av ökad försäljningsandel

Samtidigt som man redan idag skickar mindre försändelser direkt till kund skulle även denna verksamhet kunna behållas för att täcka in leveranser som

SecuriCAD användes för att generera attackgrafer och informationen om tekniker och subtekniker är till största delen hämtad från teknikbeskrivningen i MITRE ATT&amp;CK Matrix

The language is created with Meta Attack Language and is based on the knowledgeable attack- and mitigation steps of MITRE ATT&amp;CK Enterprise Matrix.. Since all possible attack

Re-examination of the actual 2 ♀♀ (ZML) revealed that they are Andrena labialis (det.. Andrena jacobi Perkins: Paxton &amp; al. -Species synonymy- Schwarz &amp; al. scotica while

Combining this information with dispatch information from the environmental schedule which applies to the location would enable Holland America Group to create a database where

Industrial Emissions Directive, supplemented by horizontal legislation (e.g., Framework Directives on Waste and Water, Emissions Trading System, etc) and guidance on operating