Monitoring Malicious Powershell Usage Through Log Analysis

Monitoring malicious PowerShell usage through log analysis

Jesper Magnusson

Computer Science and Engineering, master's level 2019

Luleå University of Technology Department of Computer Science, Electrical and Space Engineering (This page is intentionally left almost blank) Abstract Security has become a hot topic around the world but focuses more on the perimeter than inside networks which opens up vulnerabilities. Directed cyber-attacks towards the energy sector which leverages this fact has increased and can have disastrous effect, even on national level. To counter this, a solution to monitor the usage of the most powerful and popular built-in tool among attackers - PowerShell - was implemented. A test-bed was set up reflecting a corporate network with two separate active directory domains, one for office clients and one for critical infrastructure. It was shown that attackers only needed to overtake the office active directory domain in order for gain easy access to the critical active directory domain. To simulate attacks of this type, a collection of malicious scripts was gathered from which a number of possible scenarios for taking over the office active directory domain via PowerShell was created. Windows has several options for logging executions of PowerShell commands on machines. The one used and deemed most beneficiary was ”Module logging” with the addition of a filtered result of process creation logs. To monitor the logs created on the office client from PowerShell executions, a system based on the ”ELK stack” was set up. This system gathered, processed, stored and visualized logs along with the result of their analysis. The system analyzed logs with the aid of a custom software called ”ESPSA” which based on different parameters and contexts assigned every execution with a risk value indicating the level of maliciousness. To be able to assign risk values, the maliciousness of every command had to be evaluated. This was done with the aid of a mathematical expression that gave values between 0 and 100 based on the probability of benign execution and the security risk of the actual command. The evaluation shows that all simulated attack scenarios were detected as malicious by reaching total risk values above the threshold of 100 in their exact implementation. It also shows that possible branching of these attacks could instead lead to a value below the threshold and become undetectable. Evaluation also shows that ”Module logging” is unable to detect certain types of executions, primarily those of .NET Framework interactions, which affects the monitoring possibilities for malicious behavior severely.

i List of Figures

1 Industroyer overview ...... 10 2 Test-bed used for vulnerability evaluation ...... 15 3 Test-bed with implemented solution ...... 24 4 Process ﬂow between solution components ...... 25 5 Process ﬂow between ESPSA components ...... 27 6 Example graph of Akima Cubic Spline Interpolation for time risk factoring with working hours between 8 and 17 ...... 31 7 3D plot of equation 2 ...... 42

List of Tables

1 Malicious PowerShell scripts ...... 16 2 enabled GPOs for PowerShell logging ...... 23 3 PowerShell command risk assignments ...... 32 4 Outcome of simulation - Local ﬁles ...... 37 5 Outcome of simulation - MSI packages ...... 38 6 Outcome of simulation - Saved browser credentials ...... 39

List of Listings

1 PowerShell logon script ...... 20 2 PowerShell logoﬀ script ...... 21 3 Added log structure by Logstash ...... 26

List of Equations

1 PowerShell execution risk evaluation ...... 30 2 PowerShell command risk assignment ...... 32

ii Abbreviations

AD Active Directory. 5, 7, 8, 14–16, 18–22, 36, 37, 39, 40

AD DS Active Directory Domain Services. viii, 14–16, 20–22

AI Artiﬁcial Intelligence. 49

BHIPS Behavioural Host Intrusion Prevention System. 3

BIOS Basic Input/Ouput System. 7, 16

C# C Sharp. 24, 27

C&C command-and-control. 5–9, 11, 12, 20

CLI Command Line Interface. 13

CMD Command Prompt. iii, 45, 48, Glossary: Command Prompt

CNN Convolutional Neural Network. 3

COM Component Object Model. 12

CPU Central Processing Unit. 8

DC Domain Controller. viii, 15, 16, 21, 40

DCOM Distributed COM. 12

DHCP Dynamic Host Conﬁguration Protocol. 16

DLL Dynamic-Link Library. 6–8, 11, 12

DMS Distribution Management System. 9, 10

DNS Domain Name System. 17, 19

DoS Denial-of-Service. iii, 10, 12, Glossary: Denial-of-Service

FIFO First In First Out. 28

FTP File Transfer Protocol. 21

GPO Group Policy Object. ii, viii, 4, 13, 15, 16, 20, 21, 23, 25, 43–45

HMI Human-Machine Interface. 9

HTML HyperText Markup Language. 7, 19

iii HTTP Hyper-Text Transfer Protocol. 5, 7, 8, 25

HTTPS Hyper-Text Transfer Protocol Secure. 11

ICS Industrial Control System. 9

IP Internet Protocol. 6–8, 11, 12, 16, 18, 22

IT Information Technology. 1, 9

JAR Java Archive. 6, 7

JS JavaScript. 7

JSON JavaScript Object Notation. 25–29, 31

MAC Media Access Control. 16

MMS Manufacturing Message Speciﬁcation. 12

MSI Microsoft Windows Installer. ii, viii, ix, 18, 21, 22, 37, 38, 40

NLP Natural Language Processing. 3

OLE Object Linking and Embedding. iv, 7, 12

OPC OLE for Process Control. iv, 7, 8, 12

OPC DA OPC Data Access. 12

OS operating system. 1, 6–8, 13, 16, 22

PDF Portable Document Format. 6

PLC Programmable Logic Controller. 7

RADIUS Remote Authentication Dial-In User Service. 22

RAT Remote Access Trojan. iv, 1, 8, 22, 42, 45, Glossary: Remote Access Trojan

RDP Remote Desktop Protocol. 16, 18, 20

RTU Remote Terminal Unit. 11

SCADA Supervisory Control And Data Acquisition. 7–10, 20

SIEM Security Information and Event Management. 4, 46

SMB Server Message Block. 7

iv SQL Structured Query Language. 12

TCP Transmission Control Protocol. 11, 25, 27, 29

UAC User Access Control. v, 5, Glossary: User Access Control

UPS Uninterruptible Power Supply. 10

URL Uniform Resource Locator. 18, 22

VLAN Virtual Local Area Network. 16

VPN Virtual Private Network. 9

WLAN Wireless Local Area Network. 17

WMI Windows Management Instrumentation. 2

WPA Wi-Fi Protected Access. 16

WSL Windows Subsystem for Linux. 45, 48

XDP XML Data Package. 6

XML Extensible Markup Language. v, 6, 21, 36

Glossary

Command Prompt a command line interpreter application available in most Windows operating systems. It is used to execute entered commands. Most of those commands automate tasks via scripts and batch ﬁles, perform advanced administrative functions, and troubleshoot or solve certain kinds of Windows issues. iii, 45

Denial-of-Service a type of cyber-attack in which a malicious actor aims to render a computer or other device unavailable to its intended users. attacks typically function by overwhelming or flooding a targeted machine with requests until normal traffic is unable to be processed. iii, 10 keylogger software or hardware which records (logs) the keys struck on a keyboard, typically covertly, so that person using the keyboard is unaware that their actions are being monitored. 20–22, 37 machine learning the scientific study of algorithms and statistical models that computer systems use to effectively perform a specific task without using explicit instructions, relying on patterns and inference instead. 3, 22

v non-malware attack attacks in which an attacker uses existing software, allowed applications and authorized protocols to carry out malicious activities. Non-malware attacks can gain control of computers without downloading any malicious files, hence the name. Non-malware attacks are also referred to as file-less, memory- based or “living-off-the-land” attacks. 2, 3, 13, 21 phishing the fraudulent attempt to obtain sensitive information such as usernames, passwords and credit card details by disguising oneself as a trustworthy entity in an electronic communication. Typically carried out by email spoofing or instant messaging, it often directs users to enter personal information at a fake website which matches the look and feel of the legitimate site. vi, 11 polling a technique that continually interrogates a peripheral device to see if it has data to transfer. 8 regex regex is a sequence of characters that define a search pattern. 31–36 Remote Access Trojan a type of malware that allows a malicious party access to a computer system through a remote network connection. iv, 1 sandboxing a security mechanism for separating running programs, usually to mitigate system failures or software vulnerabilities from spreading. It is often used to execute untested or untrusted programs or code, possibly from unverified or untrusted third parties, suppliers, users or websites, without risking harm to the host machine or operating system. 2 social engineering attack the term used for a broad range of malicious activities accom- plished through human interactions. It uses psychological manipulation to trick users into making security mistakes or giving away sensitive information. 2 spear phishing a phishing method that targets specific individuals or groups within an organization. It is a potent variant of phishing, a malicious tactic which uses emails, social media, instant messaging, and other platforms to get users to divulge personal information or perform actions that cause network compromise, data loss, or financial loss. While phishing tactics may rely on shotgun methods that deliver mass emails to random individuals, spear phishing focuses on specific targets and involve prior research. 9

User Access Control security feature in Windows that aims to improve security by lim- iting application software to standard user privileges until an administrator autho- rizes an increase or elevation. v, 5 watering hole attack a computer attack strategy, in which the victim is a selected group (organization, industry, or region). In this attack, the attacker guesses or observes which websites the group often uses and infects one or more of them with malware. Eventually, some member of the targeted group becomes infected. 7

vi web scraping extracting data from websites either manually or by automated bots or web crawlers. 19 wrapper a method of making one type of software act as an encapsulation of another software, enabling its execution by acting as an adapter. 21, 22, 37

vii Table of Contents

1 Introduction 1 1.1 Background ...... 1 1.2 Motivation ...... 1 1.3 Problem deﬁnition ...... 1 1.4 Delimitations ...... 2 1.5 Thesis structure ...... 2

2 Related Work 2 2.1 Fileless attacks ...... 2 2.2 Deep neural networks ...... 3 2.3 LogRhytm SIEM ...... 4 2.4 ELK stack threat hunting ...... 4

3 Theory 4 3.1 Attacks ...... 4 3.2 Shamoon analysis ...... 5 3.2.1 Infiltration ...... 5 3.2.2 Attack ...... 5 3.3 Energetic bear analysis ...... 6 3.3.1 Infiltration ...... 6 3.3.2 Attack ...... 7 3.4 Black energy analysis ...... 8 3.4.1 Infiltration ...... 9 3.4.2 Reconnaissance ...... 9 3.4.3 Attack ...... 9 3.5 Industroyer analysis ...... 10 3.5.1 Structure ...... 11 3.6 Choice of PowerShell ...... 12 3.7 PowerShell ...... 13 3.7.1 Logging capabilities ...... 13 3.8 Elastic stack ...... 13 3.9 Active Directory Domain Services (AD DS) ...... 14 3.9.1 Group Policy Object (GPO) ...... 15 3.9.2 Domain Controller (DC) ...... 15

4 Implementation 15 4.1 Testing ...... 15 4.1.1 Test-bed ...... 15 4.1.2 Test tools ...... 16 4.2 Attack Simulation Scenarios ...... 19 4.2.1 Local ﬁles ...... 21 4.2.2 Microsoft Windows Installer (MSI) packages ...... 21

viii 4.2.3 Saved browser credentials ...... 22 4.3 Solution ...... 22 4.3.1 Prerequisites ...... 23 4.3.2 System Overview ...... 23 4.3.3 Beats ...... 25 4.3.4 Logstash ...... 25 4.3.5 Elasticsearch ...... 26 4.3.6 Kibana ...... 26 4.3.7 ESPSA ...... 27 4.3.7.1 Overview ...... 27 4.3.7.2 Architecture ...... 27 4.3.7.3 TCP Reader/TCP Sender ...... 29 4.3.7.4 Aggregator ...... 29 4.3.7.5 Processor ...... 29 4.3.7.6 Command risks ...... 31

5 Evaluation 36 5.1 Local ﬁles ...... 36 5.2 MSI packages ...... 37 5.3 Saved browser credentials ...... 39

6 Discussion 40 6.1 Evaluation results ...... 40 6.2 Assigned risk values ...... 41 6.3 Browser security ...... 42 6.4 PowerShell ...... 42 6.4.1 Logging capabilities ...... 42 6.4.2 Choice of enabled GPOs ...... 43 6.4.3 Other defences ...... 44 6.4.3.1 ExecutionPolicy ...... 44 6.4.3.2 Disabling PowerShell ...... 45 6.4.4 Monitoring obstacles ...... 45 6.5 Elastic Stack ...... 46 6.6 ESPSA ...... 46 6.6.1 Execution time risk interpolation ...... 46 6.6.2 Risk half-life ...... 47 6.6.3 Aggregator ...... 47 6.6.4 Output waste ...... 48

7 Conclusions and future work 48 7.1 Future work ...... 48

References 50

ix Appendices 52

x 1 Introduction

1.1 Background Security has become a hot topic around the world, especially in the world of Information Technology (IT). Although a lot of focus lies on ensuring security at the perimeter [1] - in other words protecting things from the outside coming in, there is less work concerning security post-infection where attackers have successfully infected a system and has gained remote access via for example a Remote Access Trojans (RATs). One reason could be that it is trickier to separate actions made by legitimate users and those made by malicious parties. Nonetheless it is as important as protecting the perimeter as it can be bypassed by various techniques, and not having security measures past the perimeter thus gives the attacker maximum chances of reaching their goal. PowerShell is a very powerful tool that is increasingly used in cyber-attacks. Its wide scope in usability and interoperability with other tools along with its capability of running in the background makes it favorable for attackers. It also helps to blend into normal system usage and avoid detection by other security measures such as anti-virus software as its built into the Windows operating system (OS).

1.2 Motivation Directed cyber-attacks has increased lately and has become more and more sophisticated. In some cases, these attacks have resulted in disruptions and damage to cyber-physical infrastructure, in other words digital systems controlling physical processes. This is especially true in the case of attacks directed towards the energy sector and attacks that are suspected to be funded by governments. These attacks often leverage the fact that security inside the network is incomplete. This can have disastrous effects, if considering power deliverance, since most societal function today are dependent on a steady supply of electricity. It could possibly even have effects on national security if functions such as military or health care are affected.

1.3 Problem deﬁnition This thesis focuses on securing the existence of PowerShell by monitoring how it is being used. The goal is to use built-in logging functionality to extract executed commands into a system that analyzes them and assigns quantitative risk levels based on risk deﬁnitions of PowerShell commands. These risk levels are then to be used as means of detecting bad behavior by the event of surpassing a threshold value. By being detected, attacks are able to be mitigated before they make damage to critical infrastructure. The problem is derived from a performed analysis of major directed cyber-attacks that has been done against the energy sector around the world.

1 Delimitations

1.4 Delimitations This thesis does not examine actual malicious PowerShell script executions done against corporations because of the lack of access to such a database. It does also not consider baselines for what constitutes normal behavior around PowerShell usage at a global or even national level. Even with access to such information, the time required to process it would be too great. Additionally, only a subset of possible PowerShell commands is considered in this thesis. The work of examining and deﬁning risks of every command is to extensive because of the vast amount of possible executions.

1.5 Thesis structure In section 2, related work is presented that describes works of others that has relations with the work conducted in this thesis. Section 3 describes the analyses of directed cyber-attacks towards the energy sector. It also describes the steps taken to conclude that PowerShell is a good point of mitigation to prevent similar attacks. Section 4 describes the setup used to test attacks against a corporate network as well as the construction of the attack scenarios used to successfully compromise this network. It also describes the architecture of the solution, how it operates and around which attributes it was constructed. Section 5 displays the results of running the simulated attacks formed in section 4 inside an environment where the solution is actively monitoring. Section 6 delves into details around topics such as the evaluation results formed in section 5, the implementation of the solution, PowerShell and logging capabilities. Section 7 summarizes the conclusions made of this thesis as well as what future work can be done to improve the solution.

2 Related Work

2.1 Fileless attacks

In the article Fileless attacks: compromising targets without malware[1] Steve Mansfield- Devine describes how attackers have gone from using capabilities in injected malware to attack to using built in functionality such as Windows Management Instrumentation (WMI) or PowerShell. He also mentions that attackers use ”tried-and-trusted” methods such as application vulnerabilities, environment misconfigurations and social engineering attacks to gain initial foothold in environments. People and the security industry are also homed in on malware and how to detect it and not the threat of non-malware attacks which are on the rise and far more successfully executed. One reason for their success rate - he writes - could be the reduced number of screenings. Things like sandboxing and reduced privileges does not occur for PowerShell as it does for unknown files. This reduced scrutiny along with the fact that PowerShell offers the same functionality contributes to the fact that attackers are moving towards

2 Deep neural networks non-malware attacks. According to Steve the use of these attacks - that involves reconnaissance and tailored social engineering - usually were conducted by nation-state actors but have increasingly become attractive for ordinary cyber-criminals. He also states that non-malware attacks are more varied and harder to test as compared to malware samples by the fact that standardized testing environments are hard to create, and the process of testing requires high levels of skill and knowledge. Samples can also easily be shared and transferred as information about non-malware attacks is harder to share. Steve writes that we should shift our attention from what files exist on systems to what activities that takes place to identify malicious behavior. Existing Behavioural Host In- trusion Prevention Systems (BHIPSs) which is supposed to make up for the failings of signature-based anti-virus tools are inflexible and conservative around behavioral analysis since endpoint computers house all kind of user interactions that would be identified as malicious. The way he thinks is to go is something called ”event sharing”, where actions are not judged in a single point in time but put in context. Things like past events and historical re-occurrence are things to take into consideration. This is where machine learning comes in handy. He also describes a solution in which endpoint devices are less impacted in regard to performance compared to current anti-viruses as all data processing is performed at a remote location and instructions are passed to the endpoint devices when alerts occur.

2.2 Deep neural networks

In the paper Detecting Malicious PowerShell Commands using Deep Neural Networks[2] Danny Hendler, Shay Kels and Amir Rubin describes their approach to analyzing Pow- erShell commands. They evaluated two types of machine learning detectors - of types Convolutional Neural Networks (CNNs) and Recurrent Neural Networks - as well as Natural Language Processing (NLP) detectors based on character n-grams and bag-of- words. The end aim was to detect malicious commands based on commands as well as obfuscation methods. For evaluation and model training they used a dataset totaling 66388 distinct Pow- erShell commands of which 6290 were labeled as malicious. Their detectors worked on commands in clear-text (as they are inputted). It was shown that every detector gen- erally decreased their success-rate in response to lowered rates of false-positives, which required a trade-oﬀ to be found as both rates are equally important. The outcome of their evaluation was that the best detection results were given by combining the deep learning model and natural language processing model that performed best separately - 4-CNN and 3-gram - at a false-positive rate lower than 10−3. Their ensemble detector tested 12004 clean commands and 471 malicious commands with a success rate of 0.995 and a false-positive rate of 5.831e−4.

3 LogRhytm SIEM

2.3 LogRhytm SIEM Greg Foss released a guide in which he described how to setup PowerShell monitoring in the LogRythm Security Information and Event Management (SIEM) tool.[3] His solution works by enabling PowerShell logging via PowerShell profiles, inserting these logs into the SIEM and configuring it to alert when certain commands are executed. The solution has some downsides that are of concern. Configuring logging via profile files brings with it the need to ensure the integrity of that file in order to maintain the creation of logs. It is also questionable if not the ”−NoProfile” parameter to PowerShell will bypass this. Another downside is that the logging enabled by the profile generates a vast number of logs since it logs both a starting and stopping event for each command. The solution can also be bypassed quite easily - as Greg Foss even mentions in the paper - by obfuscating the code they execute. This comes from the fact that the commands that are alerted upon are the function names of functions in well-known open-source PowerShell attack frameworks, which anti-virus vendors already reacts upon (at least Windows Defender).

2.4 ELK stack threat hunting Roberto Rodriguez wrote a guide in 2017 where he described how to collect logs from PowerShell, insert them into the ELK Stack and handle the results.[4] The solution involved enabling logging via Group Policy Object (GPO), mutating the logs in Logstash and in the end visualize all the gathered data in Kibana. The negative side of this solution is that none of the gathered data is automatically analyzed. Manual analysis of all incoming data must be done in order for threats to be discovered. This wastes a lot of human resources, especially in the case of high generation of data. The detection and response time also become unnecessarily high because of this.

3 Theory

3.1 Attacks

The biggest cyber-attacks made towards the energy sector[5] are:

• Slammer

• Stuxnet

• Shamoon

• Energetic Bear

• Black Energy

• Industroyer

4 Shamoon analysis

Of those six, Slammer and Stuxnet was excluded from evaluation. The reason for that is that they occurred for ten years ago or more and has not re-emerged in newer instances.

3.2 Shamoon analysis Shamoon was an attack that targeted a Saudi Arabian company in 2012 and damaged 30 000 systems with a malware called ”Disttrack”.[6] The malware spreads in the network and is eﬃcient in destroying data and making systems inoperable. Since then, numerous new variants of this attack have been found up until December 2018.[7]

3.2.1 Inﬁltration The attackers used spear phishing via email with a Microsoft Oﬃce document (primarily Word documents) as an attachment.[8] This attachment in turn contained macros that enabled the malicious document to run two PowerShell scripts. These scripts deployed tools and malware on the compromised machine which in turn is used to study and gather information such as Active Directory (AD) domain name, credentials, network topology and critical servers. The system access is also used to connect to other systems, escalate privileges and spread the tools and malware to aid information gathering. These actions were performed weeks in advance of the actual Disttrack outbreak.

3.2.2 Attack The Disttrack malware consists of three parts: ”the dropper”, ”communications” and ”wiper” components.[6] It spreads to other systems by logging in to remote systems in the same network segment by using hard-coded credentials and AD domain names that most likely were stolen prior to the execution of the malware. Additionally, the malware is able to download extra applications to the system as well as remotely setting wiping dates.

Dropper The dropper extracts the communications and wiper components from embedded resources by reading a specified number of bytes from a given offset and decrypt- ing it with a specified key. Upon logging into remote systems in the step of spreading the malware, the dropper attempts to open the service manager and start the RemoteReg- istry. By doing so the malware tries to disable User Access Control (UAC) by altering the registry. After disabling UAC it copies itself to an executable in the Windows/system32 folder and checks if it has administrator privileges on the system. If it does it creates a service to launch itself. If it does not it creates a scheduled task to launch itself 90 seconds from the current time for 3 minutes instead of creating a service.

Communications The communications component interacts with a command-and- control (C&C) server using Hyper-Text Transfer Protocol (HTTP) requests. In these

5 Energetic bear analysis attacks this module was conﬁgured with an Internet Protocol (IP) address not pointing to a C&C server, suggesting that the attackers were uninterested in having remote access to the systems but instead only wanted to cause damage. In the case of an operational C&C server the module sends a GET request with parameters indicating running time of the system, IP address, OS version and keyboard layout. The response of the request can be one of two commands: Content of an executable to run on the system or saving a time-stamp to a ﬁle on which to start wiping the system.

Wiper The dropper does not install the wiper component until it decides it is time to wipe the system. The time-stamp for this decision is either hard-coded or exists in a file that is created on command from the C&C server. When the dropper decides it is time to start wiping, it saves the wiper component as an executable in the Windows/system32 folder. and immediately launches it. The wiper starts by extracting a driver from its resource section and installs it by creating a service. The driver is a commercial product called ”RawDisk” which provides direct access to files, disks and partitions. With the driver it starts to write to protected system locations such as the master boot record and to partition tables of storage volumes. It also overwrites the local profile folders in C:/Users and all the files therein. After completing all overwrites it issues a command to force the computer to reboot, after which it can no longer boot because of the overwritten partition tables. The wiper can be configured to wipe systems in three different ways. It can use a predefined image by overwriting files and partition tables with it. It can also use random values either to overwrite contents directly with it or use it as a key and overwrite contents with the RC4 stream cipher algorithm.

3.3 Energetic bear analysis ”Energetic Bear”/”Crouching Yeti” is a hacker group which targets many sectors, with the primary being the industrial and energy sector.[9,10] They have actively been involved in attacks since 2010.

3.3.1 Inﬁltration The attackers make use of three diﬀerent approaches to infect the victim’s environments.

Spear-phishing The attackers use a malicious XML Data Package (XDP) file which is actually a Portable Document Format (PDF) file packaged within a Extensible Markup Language (XML) container. This is a known obfuscation method that makes detection harder. the XDP file contains two files, one is a ”Havex Loader” Dynamic-Link Library (DLL) malware and the other is a Java Archive (JAR) file. It then infects the machine by using a Flash exploit to execute the JAR file and eventually copy the malware unto the system and run it.

6 Energetic bear analysis

Waterholing The attackers also infect legitimate websites to perform watering hole attacks. One variant is performed by inserting a link into the web page or the JavaScript (JS) file used on the web page. This link initiates a request for an image when the page loads from a specific IP address. This link then redirects to another link forcing the use of the Server Message Block (SMB) protocol. This way the attacker can extract the IP address, user name, AD domain name, and hash of the user’s password from the session. The second approach compromises legitimate websites by making them redirect visitors to malicious JAR or HyperText Markup Language (HTML) files. These files in turn uses exploits in Java and Internet Explorer (version 7 and 8) to download the ”Havex” malware, the ”Karagany” backdoor and other helper tools onto the victim’s computer.

Software installers The attackers also infect machines by infecting legitimate software installers of third-party providers. One example is the hijacking of a camera driver by SwissRanger, which was altered to load a malicious ”Sysmain” backdoor DLL ﬁle and set the registry to run it on the next startup. Another example is the infection of an installer from the company eWon, which is a Belgian producer of Supervisory Control And Data Acquisition (SCADA) systems and industrial network equipment. Their installer was altered to load the Havex malware onto the system. A third example is that of the company MB Connect Line which specializes in remote maintenance of Programmable Logic Controller (PLC) systems. Their freely downloadable installer for the software mbCHECK was compromised.

3.3.2 Attack Havex Once the systems have been breached by the Havex malware, it begins to download additional DLL files from C&C centers by hijacking the Windows Explorer process to send HTTP requests. The entire DLL files are encoded as text comments inside the response from the C&C server and are identified by a specific start and end tag. The contents are also usually encrypted and compressed before encoded into the response. The additional malware downloaded have different goals in mind. They are used for different purposes, including collecting information about the victim’s system, the victims file system, other systems in the network or harvesting passwords. All the harvested information is then compressed, encrypted and sent back to the C&C centers by the Havex malware. The identified purposes are:

• OLE for Process Control (OPC) scanning to enumerate and extract information about the OPC servers running in the local network.

• Gaining a wide variety of system information including OS information, list of ﬁles and ﬁle structure, running processes, internet settings, Basic Input/Ouput System (BIOS) versions and email addresses.

• Stealing contacts by collecting details from local Outlook ﬁles.

7 Black energy analysis

• Stealing passwords by embedding the tool ”BrowserPasswordDecryptor 2.0” which decrypts and dumps credentials stored by password managers of various browsers.

• Scanning the local network and looking for hosts listening on ports related to OPC/SCADA software.

Sysmain The Sysmain backdoor is a RAT. It starts by permanently attaching itself to the system and then begins to gather information. It gathers information regarding running processes, files in the file system, default browser, user- and computer names and network information. At completion it sends this information to its C&C server and then begins polling the server for further instructions using the HTTP protocol. 11 commands make the backdoor able to execute shell commands, launch additional executables or libraries, collect unauthorized data and examine the filesystem. But it can also be commanded to change cipher keys or delete its traces from the system.

ClientX The ClientX backdoor is a .NET RAT similar to the Sysmain backdoor. By polling its C&C servers it receives its next order. In the orders it looks for ”havexhavex” tags which envelops encrypted and encoded data of its next command. It has 13 commands which include taking screenshots, updating itself, downloading DLLs, starting executables, running shell commands and listing directories. The results of the commands are stored in the registry and later posted to the C&C server.

Karagany The Karagany backdoor connects to its C&C servers and waits for commands. It is able to download and run executables, load/delete modules, read files, reboot the system, update itself and remove all of its components. It also extracts credentials from the password manager of Internet Explorer and injects a DLL file into processes of web browsers. This DLL listens to outgoing traffic and extracts any authentication details sent over unencrypted HTTP. The known modules of this backdoor are:

• A screenshot module which uses the ”Ducklink CmdCapture” third party free software. Besides saving a screenshot it also logs additional information around the screenshot. This information includes time-stamp of capture, computer name, username, Central Processing Unit (CPU) architecture, OS version, IP address, AD domain name, logon server, desktop details and environmental variables.

• A module for listing documents and other files. It is used for listing files of specific extensions or who have names that includes specific substrings.

3.4 Black energy analysis In 2015 three power companies where victims of a coordinated cyber-attack which resulted in 225 000 customers being without electricity for three hours.[11] These were the ﬁrst publicly acknowledged attacks that resulted in power outages.

8 Black energy analysis

The attacks were sophisticated and is likely to been carried out by an actor with considerable structure and resources at disposal. The attacker demonstrated a variability in its methods and tactics to match the diﬀerent security measures and environments of the three companies. Hence Ukrainian government oﬃcials claimed that Russian security services were behind the attack.

3.4.1 Inﬁltration The attacker’s way into the corporate network relied on three components working to- gether. They used variants of the ”BlackEnergy3” malware contained inside manipulated Microsoft Oﬃce documents distributed by spear phishing via email. The main targets of the distribution were people working in administration or IT at the companies. Upon opening the documents, a message displayed that asked the users to enable using macros. Upon allowing macros, the BlackEnergy3 malware was installed.

3.4.2 Reconnaissance Once installed, the malware connected to C&C centers and enabled the attackers to communicate with the infected systems and gather information. Then the attackers spent six months harvesting credentials, escalate privileges and move laterally through the companies to systemically take over IT systems and ensure persistent access to the networks. The attackers however quickly moved away from their vulnerable C&C access to blending into the victim’s systems as authorized users to further secure their control. The attackers continued by identifying Virtual Private Network (VPN) connections and other means of access into the Industrial Control System (ICS) network and eventually found their way into network segments where SCADA servers and workstations existed. Although not proven, the attackers must have performed reconnaissance actions to discover seriel-to-ethernet devices that interpret commands from the SCADA network to the substation control systems. Each of the three victims all used diﬀerent Distribution Management Systems (DMSs) that required the attackers to gather network information speciﬁcally around each of those systems.

3.4.3 Attack The attack was performed primarily by using native means of access into the SCADA systems and use their Human-Machine Interface (HMI) to take substations offline, but several sub-parts of the attack was made to worsen the effect of the entire attack. A custom written firmware was created for the serial-to-ethernet devices. This firmware was uploaded by using existing remote administration tools on operator workstations and was designed to render the devices inoperable and unrecoverable. Thus, ensuring that remote commands could not be issued to bring the substations back online. A customized ”KillDisk” software was also installed throughout the environment to lock out the operators from their systems. On some Windows systems, the software made the systems unbootable by manipulating or deleting the master boot record. On other systems, the software merely deleted log files and system events.

9 Industroyer analysis

One of the victims also had a Uninterruptible Power Supply (UPS) that was reconfig- ured in such a way that when the attack caused the power outage, the UPS would fail and impact the power in the company’s buildings or data centers. Finally, the attackers also issued a Denial-of-Service (DoS) attack on the company’s telephonic call center. The goal was first seen as keeping customers from relaying information of the extensiveness of the outage to the companies but was later changed to causing frustration among the customers for not being able to reach customer support or gain clarity regarding the outage. It is highly likely that this attack was developed and tested in the attacker’s own environments prior to the actual attack. The multitude of stages in the attack and the professionalism in executing them indicates that the attacker’s capabilities and custom code were evaluated before actually used. To efficiently interact with the three different DMS, the attackers also had to study and evaluate the systems individually.

3.5 Industroyer analysis

Figure 1: Industroyer overview

”Industroyer” is a malware speciﬁcally designed to target electric power systems. It is suspected to be used in the cyber-attack on Ukrainian grid operators in 2016.[12] It is notable that this malware does not infect embedded industrial equipment, it infects Windows machines in SCADA environments and substations that has access to critical

10 Industroyer analysis devices. The malware itself has no function of reaching such a host on its own. Therefore, initial compromises are required beforehand, such as phishing attacks followed by lateral movement inside the network from other vectors.[13]

3.5.1 Structure The overview of the structure of the malware can be seen in ﬁgure 1.

Main backdoor The core component in the malware is the ”Main backdoor”. It connects to a C&C center via Hyper-Text Transfer Protocol Secure (HTTPS) to receive instructions from the attacker. Most of the servers it connects to uses Tor software. Once the attacker gets a hold of administrator privileges, they are able to update the Main backdoor into a version with higher privileges running as a Windows service. It does so by hijacking registries of an already existing non-critical service.

Additional backdoor The ”Additional backdoor” is a backup solution for cases where the Main backdoor is detected or/and disabled. It is a trojan inserted into the Windows Notepad application. Once the attacker has administrator privileges it replaces the original Notepad with the infected version. Every time the infected application starts, it contacts a C&C center diﬀerent from the original one. Other than that, the Notepad application remains fully functional.

Launcher component This component is a separate executable. It contains a specific time stamp that once reached launches two separate threads. The first thread will try to load a payload DLL file and configuration file supplied by a parameter when the attacker launches the executable. The second thread will launch the ”Data wiper” component after one or two hours.

101 payload This payload partly implements the protocol IEC 101 for monitoring and controlling electric power systems. The configuration file identifies a process name that this component tries to terminate on the running machine. This process is the application the attacker suspects to be the one communicating with the Remote Terminal Unit (RTU). The file also contains names of serial ports which it uses to communicate with the RTU and maintain its control over it.

104 payload This payload leverages the IEC 104 protocol that extends IEC 101 with Transmission Control Protocol (TCP)/IP capabilities. The configuration file of this payload is highly configurable and contains multiple entries of ”STATION ”. Each entry launches a separate thread in which actions described within the entry takes place, which includes terminating a given process, start communicating with the given IP address on a given port.

11 Choice of PowerShell

61850 payload This payload - unlike the previous payloads - is a standalone executable. It implements a subset of the IEC 61850 protocol used to perform protection, automation, metering, monitoring and control of electrical substation automation systems. It begins by reading its configuration file in order to obtain a list of IP addresses it will try and communicate with. The payload then manipulates the targets switches and breakers with the use of Manufacturing Message Specification (MMS) commands.

OPC DA payload This payload implements a client for the OPC Data Access (OPC DA) protocol. OPC is a standard based on Microsoft technologies such as Object Link- ing and Embedding (OLE), Component Object Model (COM) and Distributed COM (DCOM) where OPC DA enables real-time data exchange between distributed components in a client-server fashion. This payload is standalone with an executable and a DLL file. It requires no configuration file because it enumerates all OPC servers and tries to change the state of OPC items therein.

Additional tools Additional tools included in this malware is a custom-made port scanner that can scan deﬁned ranges of IP addresses and ports. Another tool is a DoS tool that targets Siemens SIPROTEC devices, rendering them unresponsive.

Data wiper This component is used in the final stage of the attack. It manipulates the registries for all windows services, making the system unbootable. Next it scans the entire system and partially rewrites file with selected extensions. The extensions include Windows binaries, archives, backup files, Structured Query Language (SQL) server files and various configuration files. Finally, it tries to terminate all processes (including system processes) except for its own, which will leave the system unresponsive and eventually crashing.

3.6 Choice of PowerShell From the description of the attacks in sections 3.2, 3.3, 3.4 and 3.5 the combined attack tree for all attacks depicted in appendix A formed. Examining the attack tree leads to the conclusion that there exist two domains in which all of these attacks have in common that can be directly targeted to render them unsuccessful. The domains are malware installation and communication with C&C centers. Both of these however is highly diﬃcult to control. Malware installation is done through exploits and obfuscations that is ever changing and even big security companies have trouble mitigating. Communication with C&C centers is also done with diﬀer- ent obfuscation methods and shifting endpoint addresses, making it hard to detect and block. The best approach is a mix of infection spreading and malware installation directly on critical infrastructure. The reason being that the attackers are at their most vulnerable during the infection spreading. The lateral movement within the network is mostly performed by individuals and not automated malware since anti-virus software are quite successful at detecting and stopping it.[14] Secondly the attacker must be creative to

12 PowerShell gather information and take control over the network without being compromised but seen as a legitimate user in the network. Since attackers do not have control over the other systems in the network they must perform more traditional methods of scanning, stealing credentials and other means of gaining more control in the network and ﬁnding the critical infrastructure. This makes the attackers vulnerable as they are more visible doing this and it takes longer time. This puts higher odds on succeeding the mitigation at this stage than any other. The mitigation of malware installation is required to completely remove all routes to the compromise of critical infrastructure. To minimize the risks of being compromised and being removed before gaining a foothold in the network, attackers tend to ”live of the land” or in other words perform non-malware attacks. That is why PowerShell was chosen as the tool used by the simulated attacker. Not only is PowerShell a very powerful tool in skilled hands, but it is also delivered as a part of the Windows OS and already proven to be widely used in cyber-attacks as Steve Mansﬁeld-Devine mentions.[1]

3.7 PowerShell 3.7.1 Logging capabilities There are three diﬀerent logging options for PowerShell that can be enabled via GPO.

Module Logging enables log creations in the Windows ”Event Center” at the execution of PowerShell cmdlets. The term ”Module logging” comes from the fact that PowerShell has a setup of modules that consists of predeﬁned functions called cmdlets. Some modules are built in and some can be dynamically loaded into PowerShell at time of need. Modules can also be created and loaded into PowerShell by normal users, where a .PSM1 ﬁle is created that contains the code for the module cmdlets. The logs created by this option contains the executed command along with all parameters passed to it in clear-text.

Script Block Logging enables the logging of script blocks in the Windows ”Event Center” as they are processed by PowerShell. Running a script would lead to the content of the script being logged. If the logged script in turn launches another script, that script would be subsequently logged.

Transcription logging logs records of every PowerShell session locally on the computers ﬁle system. The logged content is essentially what would be visible through the Command Line Interface (CLI) if the execution was made through it, in other words what was inputted, and the result written back to the user.

3.8 Elastic stack The Elastic stack is a collection of open-source solutions designed to collect, analyze and visualize data. It is made available on a freemium business model, meaning that it is

13 Active Directory Domain Services (AD DS) free to download and use but requires a license for certain features such as integrated machine-learning analytic tools. It contains four solutions designed to not only integrate with each other but with many other applications.

Elasticsearch is a RESTful distributed search engine built on top of Apache Lucene and released under an Apache license. It is Java-based and can search and index document ﬁles in diverse formats.

Logstash is a data collection engine that uniﬁes data from disparate sources, enriches it, transforms it and distributes it. The product was originally optimized for log data but has expanded the scope to take data from all possible sources.

Kibana is an open source data visualization and exploration tool that is specialized for large volumes of streaming and real-time data. The software makes huge and complex data streams more easily and quickly understandable through graphic representation.

Beats are “data shippers” that are installed on servers as agents used to send diﬀerent types of operational data to Elasticsearch either directly or through Logstash, where the data might be enhanced or archived. There are seven diﬀerent types of Beats, one being ”Winlogbeat” that extracts logs from ”Windows event center”.

3.9 Active Directory Domain Services (AD DS) Active Directory (AD) has been renamed to Active Directory Domain Services (AD DS) following the launch of Windows Server 2008, at which time the directory service became a server service among other services. Through Active Directory Domain Services (AD DS) you can create a scalable, secure and manageable infrastructure for users and for resource management. One can also benefit from directory-prepared applications such as Microsoft Exchange Server. The AD DS server role means that a distributed database stores and manages information about network resources and application-specific data. Administrators can use ADDS to organize users, computers and other hardware into a hierarchical container structure. The hierarchy facilitates delegation of permissions and facilitates the handling of large amounts of information. AD DS can be used to simplify access and publication of resources using Role-Based Access Control. The basic idea is that new members/resources are made to members in predefined roles. The membership of these predefined roles is also managed by other predefined administrative roles. This can ultimately mean, for example for a new user, it becomes a member of an institutional role that gives access to the user’s file area, common file area, provides computer settings, installs applications, installs print queues, and provides security settings. This minimizes the work involved in managing new users/resources and gives greater control over the environment, both for administrators and operators.

14 4. IMPLEMENTATION

It is also possible to provide settings/applications to devices other than Microsoft- based, for example. Linux, Android, iOS and Macintosh.

3.9.1 Group Policy Object (GPO) a Group Policy Object (GPO) is a collection of settings that define what a system will look like and how it will behave for a defined group of users. The GPO is associated with selected AD containers, such as sites, domains, or organizational units. GPOs can be created that defines registry-based polices, security options, software installation and maintenance options, scripts options, and folder redirection options.

3.9.2 Domain Controller (DC) a AD Domain Controller (DC) is the server in the network that runs AD DS and is thus responsible for authenticating users, storing user information and enforcing the security policies of the AD domain.

4 Implementation

4.1 Testing 4.1.1 Test-bed

Figure 2: Test-bed used for vulnerability evaluation

The test bed used for evaluating the vulnerability of PowerShell exploitation is depicted in ﬁgure 2. It was constructed as a typical partial setup of a corporate network involving oﬃce clients as well as critical servers.

15 Testing

The colored arrows depict the ability for traffic to flow by restrictions of Virtual Local Area Networks (VLANs) and firewall rules. All arrow groupings equal traffic without any restrictions except for the green arrow which the firewall limited to Remote Desktop Protocol (RDP) traffic against ”Jump server” by filtering on port 3389. The two greyed areas represent virtual environments. As such there were two separate virtual environments hosting the servers in the test-bed. The laptop used was a physical HP ProBook 6570b with the latest drivers and BIOS version. The OS running on it was Windows 10 1803. The laptop had two ways of connecting to the network, either by ethernet or a wireless access point over an Wi-Fi Protected Access (WPA)2 Enterprise connection. The anti-virus run on the client was the built in Windows Defender. All the virtual servers were running Windows Server 2016 version 1607. Both the AD domain controllers started with the default implementation of the AD DS along with the addition of two users each, one administrator account and one normal user account, all with different credentials. The first-tier DC (the one on the right in figure 2) housed a custom GPO to map a network drive on the laptop to a local folder on the DC. The firewall used was a pfSense 2.4.4 running on FreeBSD.

4.1.2 Test tools Table 4.1.2 shows the PowerShell commands considered during testing along with the security risk they posed and why attackers might have used them. All the commands are ordered in regard of potential execution order, going from local commands that are less visible to commands that are more visible by example network connections.

Table 1: Malicious PowerShell scripts ID Security risk (Appendix) Finding OS, OS version, organization name, language, AD DC server name, processor, BIOS version, AD domain name, 1 (C.1) installed hotfixes, network cards, IP address, Media Access Control (MAC) address, Dynamic Host Configuration Protocol (DHCP) settings, computer name Prints local user accounts. Can be used to find out names of 2 (C.2) local administrator accounts. Prints AD domain username and group memberships. Can be 3 (C.3) used to find out what permissions the current account has. Prints previously logged in users. Can be used to get a better 4 (C.4) idea of who uses the machine.

16 Testing

ID Security risk (Appendix) Prints local administrator account information. Can be used 5 (C.5) to find out if the local admin account is active, when it last logged on, what its password policy is, and more. Prints password policy information for local accounts. Can be 6 (C.6) used to help brute forcing unnoticed. Prints local groups and their members. Can be used to get an 7 (C.7) understanding of what local accounts there are and what permissions they have. Prints the configured Domain Name System (DNS) servers. 8 (C.8) Can be used to locate internal DNS servers without scanning the network. Finds files with the word password in their content. Can find 9 (C.9) clear-text passwords that help advance the attack. 10 (C.10) Finds files in which clear-text passwords usually may reside. Finds registries containing the word password or are known to 11 (C.11) contain clear-text passwords. Can find passwords that help advance the attack. Finds config files in development codebases. These files 12 (C.12) normally contain passwords that can help advance the attack. Prints stored Wireless Local Area Network (WLAN) 13 (C.13) passwords from saved connections. Prints installed programs and packages. Can help find 14 (C.14) programs that are exploitable to help advance the attack. Prints system processes/services. Gives a better picture of 15 (C.15) how the machine is used. Prints processes running as system. Aids in finding processes 16 (C.16) exploitable for privilege escalation. Prints the version of PowerShell. Gives knowledge of what 17 (C.17) features PowerShell has and thus what is possible to execute and not. 18 (C.18) Prints scheduled tasks 19 (C.19) Prints programs run at startup Prints file permissions for service executables. Can be used to 20 (C.20) locate executables that can be replaced and run at a higher privilege level.

17 Testing

ID Security risk (Appendix) Finds services with unquoted pathnames. Can be used to locate services that can help gain privilege escalation by 21 (C.21) exploiting how the function CreateProcess interprets pathnames. Checks if MSI packages installed by users are installed under 22 (C.22) elevated privileges. Can be used to package own malware scripts as a MSI package to run scripts elevated. Installs a MSI silently without user interaction. Can be used 23 (C.23) to escalate privileges after script 22 returns true. Disables the real-time monitoring of Windows Defender. Can 24 (C.24) be used to bypass malware detection when using/downloading malicious tools. Requires administrator privileges. Prints hosts previously connected to through RDP along with saved credentials. Can be used to find normal RDP 25 (C.25) destinations for the infected user without scanning the network as well as pivoting through the network with normal patterns without the need for brute forcing. Prints all mapped network drives and their network locations. 26 (C.26) Can be used to locate file servers and potentially shared folders to spread infections via infected files. Finds all Uniform Resource Locators (URLs) and intranet IP addresses that web-browsers have cached content from. Can 27 (C.27) be used to locate ip-addresses of internal web-services without scanning for them. Extracts collections of URLs, usernames and passwords that have been saved by Chrome. Can be used to find credentials 28 (C.28) for AD domain accounts, alternatively passwords of other accounts to try brute forcing AD domain accounts. Extracts collections of URLs, usernames and passwords that have been saved by Edge or Internet Explorer in their 29 (C.29) password manager. Can be used to find credentials for AD domain accounts, alternatively passwords of other accounts to try brute forcing AD domain accounts. Looks up the usernames of all users in the AD domain. Can 30 (C.30) be used to locate high privilege account names or account names in general to look for in results of other scripts.

18 Attack Simulation Scenarios

ID Security risk (Appendix) Looks up DNS results with host-names within a network 31 (C.31) subnet. Can be used to find out ip-addresses and names of hosts alive on a subnet. Searches for addresses in subnet responding to ping. Can be 32 (C.32) used to find ip-addresses of running hosts in a subnet. Scans a host for a range of ports. Can be used to find out 33 (C.33) what applications or protocols a certain host uses and thus its nature. Scans a whole subnet for a specific port. Can be used to 34 (C.34) search for hosts running specific applications or using specific protocols. used for web scraping static HTML page contents of a website reachable through link chains from the root. Can be used to 35 (C.35) extract information from internal websites only accessible to corporate users. Opens a remote PowerShell session towards the target server. 36 (C.36) Can be used to pivot into the network unnoticed and execute PowerShell commands on other systems. Tests if a given AD domain username and password matches. 37 (C.37) Can be used in brute force attacks. Returns a timestamp of the last successful login of the account. Can be used in brute force attacks to know when the 38 (C.38) consecutive failed login attempts have been reset in order to avoid account lockouts. Returns the description fields of all AD domain users. Could 39 (C.39) be used to search for users where the corresponding password is written in the description field Returns group membership of users. Could be used to search 40 (C.40) for users in a particular group or the groups a compromised user is a member of.

4.2 Attack Simulation Scenarios To enable evaluation of any type of solution, testing scenarios had to be implemented that mimics real attacks. As described in section 3.2, 3.3 and 3.4, one common denominator in the infection

19 Attack Simulation Scenarios

Listing 1: PowerShell logon script i f (−Not ( Test−Path ”$env:appdata \ Microsoft \Windows\ Star t Menu\ Programs\ Startup \ WindowsShell. lnk” −PathType Leaf)) { copy ”$env:logonserver \SYSVOL\ StupidKeylogger−application \ WindowsShell.exe” $env:appdata$ copy ”$env:logonserver \SYSVOL\ StupidKeylogger−application \ WindowsShell.lnk” ”$env:appdata \ Microsoft \Windows\ Star t Menu\Programs\ Startup ” start ”” ”$env:appdata \ Microsoft \Windows\ Star t Menu\ Programs\ Startup \ WindowsShell. lnk” } methods used by the examined attacks is spear fishing. That means that the attackers have researched the organization prior to the infection to locate targets of high value, meaning targets whose device and accounts yield higher levels of access and permissions in the network. As such the premise is taken that the simulated attacks have successfully infected a high privilege user with an unnoticeable C&C malware. In this case this user is the one having the permission to connect to the jump server by RDP. As also described in the sections 3.2, 3.3 and 3.4; the step following gaining access to critical infrastructure is the deployment of automated software to do damage. Thus, the assumption is also made that when access is gained to the SCADA server, the battle is lost. The premise for the goal of the scenarios is however successfully taking over the first tier AD DS. As seen in the test-bed (figure 2), the attackers have not at that stage found their way into the critical infrastructure, another AD environment outside their control is in the way. This however is no major problem since the devices connecting into that environment resides in the AD domain they control. There is a wide variety of ways for attackers to gain access into the next AD domain. The procedure tested and proven here is the injection of a keylogger on all computers by a GPO. Step one was to inject ”StupidKeylogger”[15] into the shared SYSVOL folder of the AD domain controller. This action has two advantages. Firstly, this folder replicates between AD domain controllers which makes it easier in environments of multiple controllers to find the files from the user computers. Secondly this folder is used for sharing of group or user policy information without user interaction, making actions in it less likely to be discovered. Step two was to inject the logon PowerShell script in listing 1 as well as the logoff PowerShell script in listing 2 into a GPO. The choice of GPO is arbitrary. The more GPOs to choose from the better since it lessens the probability of the alterations to be discovered by chance. The one requirement is that it has as broad appliance in the environment as possible. This approach also required two more alterations to the GPO. The anti-virus running on the endpoints - Windows Defender - blocked and removed the keylogger initially, as

20 Attack Simulation Scenarios

Listing 2: PowerShell logoff script copy ”$env:appdata \Record. log” ”\\DCExt\ Public$ \Record−$env :computername−$env:username. log” it should. Luckily Defender is also manageable through GPO. By setting the keys ”Turn on behavior monitoring” and ”Monitor file and program activity on your computer” in ”Computer Configurations\Administrative Templates\Windows Components\Windows Defender\Real-time Protection\” to disabled, the keylogger was left unnoticed by De- fender without Defender making any sign at all to the user that functions had been disabled. The logoff script in listing 2 pushes the collected data by the keylogger to a mapped network drive located on the DC, but could as easily be rewritten to push the data for example by File Transfer Protocol (FTP) to a remote server to minimize the visibility of malicious activity. As just described, attackers can quite easily find users that accesses servers in the uncontrolled AD domain and steal the credentials from them in order to delve deeper into the network if they gain control of the first-tier AD DS. Since the credentials of everyone accessing the jump server can be sniffed and all such users normally reside in the first-tier AD domain, full access is achieved despite eventual access controls in the second-tier AD DS. The following test scenarios thus works from these premises and work towards the goal of gaining control of the first-tier AD DS through PowerShell on the laptop, executing commands in user-context. All scenarios are executed in a non-malware attack fashion, meaning that they for example do not exploit bugs to gain access to the AD DS but connects ”legally” with administrative credentials found in different ways.

4.2.1 Local files This scenario involves searching local files for credentials. There are many local files that may contain credentials other than those written manually by users. Configuration files or source-code for applications are two examples of such files. After running script 9 in table 4.1.2, the attackers found credentials saved in a local XML file. By running script 37 and 40 they confirmed that the found credential where for a AD domain administrator privileged account. Once the attackers got control of a AD domain administrator account, script 36 enabled them to open a PowerShell remote session towards the logon server found by script 1. At this point the attackers has full access to the organizations AD DS and most likely starts by injecting their own administrator account into the AD domain userbase.

4.2.2 MSI packages In this scenario the attacker is able to gain administrator privileges by running scripts with a MSI package wrapper. This behavior for MSI packages can be enabled by settings. One reason for it may be to allow users to install applications that require administrative

21 Solution permissions, without the administrator being required to handout local administrator accounts or manually approve each installation. First the attackers run script 22 from table 4.1.2 which returns indications that MSI packages are automatically installed under elevated forms. Then they run their malicious script wrappers through script 23 to gain administrator privileges. At this point the attackers can choose from a variety of ways to go forward. For example, they can now run modules of Mimikatz, Metasploit or Powersploit that requires elevated privileges in PowerShell. In this case the attackers continue with the same approach described in the beginning of section 4.2. By running script 24 they disable the real-time monitoring of Windows Defender and then continue by running a keylogger downloaded via the RAT (not through PowerShell). The attackers can then sit back and await the collection of AD domain administrator credentials that they later use in script 36 to take control over the AD DS as described in section 4.2.1.

4.2.3 Saved browser credentials This scenario searches for credentials saved by browsers internal password vaults. All modern browsers have the functionality of saving used credentials for sites. These credentials are also synced between machines, making all credentials saved by users accessible regardless of location as long as the same browser was used. These credentials are encrypted based on user-context, making them secure for outsiders but accessible for applications running under the same user-context. By running script 14 in table 4.1.2 the attackers ﬁnd that the user has Google Chrome installed. They then continue by running script 28 and 29 (since Microsoft Edge is installed per default in Windows 10) to gain all saved credentials in the two browsers. Unfortunately, the user had saved credentials for an internal administrative web application which used Remote Authentication Dial-In User Service (RADIUS) (or something similar) for authentication via AD domain users. Since script 28 and 29 both yields credentials and the site URL/IP address that they were saved for, intranet sites are easily distinguished from other globally accessible websites. Besides that, there is also a high chance for the username of administrator accounts to contain the word admin, meaning that it is feasible in this case to argue that script 37 and 40 only needed to be run once in order for attackers to ensure the ﬁndings of administrator credentials. The continuance of this scenario involves running script 36 with the found credentials to take control over the AD as described in section 4.2.1.

4.3 Solution The solution to mitigate the malicious possibilities of PowerShell was chosen to be monitoring and analyzing logs from Windows ”Event center”. As opposed to using machine learning to detect maliciousness in clear-text commands as Danny, Shay and Amir did,[2] the chosen approach is to let built-in functionality in the Windows OS aid in the de- obfuscation of commands, thus making analyzing easier.

22 Solution

Windows have several built-in logging options for monitoring the executions of commands on machines, all with their strengths and weaknesses which can be read about in section 6.4.1.

4.3.1 Prerequisites To be able to monitor and analyze logs, one must ﬁrst enable the creation of these logs on the Windows machine. This was done with the aid of GPOs. The GPOs that was enabled can be seen in table 4.3.1. The result of this activation is Module Logging logs from all modules (see section 3.7.1) as well as logs describing the creation of processes. The latter is used to monitor usage of administrative executables such as ”ipconﬁg.exe”.

Table 2: enabled GPOs for PowerShell logging Parameter ID Path (if needed) Computer Configuration\Administrative 1 Templates\Windows Components\Windows * PowerShell\Turn on Module Logging Computer Configuration\Administrative 2 Templates\System\Audit Process Creation\Include command line in process creation events Computer Configuration\Windows Settings\Security 3 Settings\Advanced Audit Policy Configuration\Audit Success Policies\Detailed Tracking\Audit Process Creation

4.3.2 System Overview The solution set up was composed of several components. Most of these components are from ”The Elastic Stack”.[16] The Implementation can be seen in ﬁgure 3 which depicts the layout of the test-bed with the implemented solution.

23 Solution

Figure 3: Test-bed with implemented solution

A new Windows server was added to the test-bed named ”ELK”. It housed most of the components used from The Elastic Stack - Logstash, Elasticsearch and Kibana. It also housed ”ESPSA” (Elastic Stack PowerShell Analyzer) - a custom designed program written in C Sharp (C#). A variant of Beats called ”Winlogbeat” was installed on the client (the laptop) as well. The work-ﬂow between all these components can be seen in ﬁgure 4 and a description of each step is listed below:

1. Beats reads logs from Windows Event Log and forwards them to Logstash.

2. Logstash processes the logs by extracting and structuring wanted data and remov- ing unnecessary data. It then forwards the processed logs to ESPSA.

3. ESPSA analyzes the incoming logs and assigns to them a risk-value calculated by factors around which command was executed and in what context it was executed. It then forwards the evaluated logs along with their risk-value back to Logstash.

4. Logstash forwards the evaluated logs into Elasticsearch.

5. Kibana makes queries to Elasticsearch based on its user-deﬁned conﬁguration.

6. Elasticsearch returns the data queried for, after which Kibana uses it to create visualizations.

24 Solution

Figure 4: Process ﬂow between solution components

4.3.3 Beats The Winlogbeat client installed on the laptop as seen in figure 3 was responsible for collecting certain types of logs that Windows creates and forward them to Logstash. The configuration file for Winlogbeat can be seen in appendix E.1.1. The client searches for two kinds of event logs, those with an ID of 800 and those with an ID of 4688. 800 is an operational log of PowerShell and contains information around module execution. This type of log is the result of enabling GPO 1 in table 4.3.1. An example log can be seen in appendix F.1 generated by executing the PowerShell command ’Get−LocalGroupMember −Name ”Administrators”’. The Winlogbeat client sends all generated logs of this type to Logstash encoded as JavaScript Object Notation (JSON). 4688 is an audit event for creating new processes on the machine and is enabled by GPO 3 in table 4.3.1. Enabling GPO 2 enriches these logs by appending the command line issued for creating this process. An example log can be seen in appendix F.2 generated by executing the command ’ipconfig’. These types of logs are filtered before sent to Logstash. The Winlogbeat client only sends those which describes processes created by the application powershell.exe or cmd.exe.

4.3.4 Logstash Logstash was responsible for handling log entries incoming both from Winlogbeat clients but also from ESPSA. It had several configuration files: pipelines.yml, PsPre.conf, PsPost.conf and powershell.rb, which can be found in appendix E.2.1, E.2.2, E.2.3, and E.2.4 respectively. It also has a configuration file called logstash.yml which was kept unaltered from installation defaults. The configuration files told Logstash to run two pipelines in parallel. One which directly forwarded input from ESPSA by TCP into Elasticsearch by HTTP and one which mutated the logs from Beats prior to forwarding them into ESPSA by TCP. The

25 Solution

Listing 3: Added log structure by Logstash ”powershell” = { ” script name” = ”PsScript.ps1”, ” h o s t application” = ”C: \ Windows\System32\WindowsPowerShell \v1 . 0 \ powershell.exe −NoProfile”, ”main command” = ”Get−LocalGroup | ForEach−Object { $ ; Get −LocalGroupMember −Group \” $ \”}”, ”version” = ”5.1.17134.590”, ”command” = ”Get−LocalGroupMember” , ”parameters = [ ”−Group Administrators” ] } mutating pipeline was configured by PsPre.conf and handles 800 events and 4688 events in different ways since they contain different information’s in different structures. In the end they both resulted in added structure to the root of the log JSON object that was vital for the goal of the solution. The added structure contained what command was run, what parameters it had, the application running the command along with additional parameters to the application and lastly the name of the script-file the command was run from. An example of the resulting structure can be seen in listing 3. The mutating pipeline was also responsible for aggregating event logs of type 800, this due to the existence of limitations on the size of logs that resulted in splitting if exceeded. Before it forwarded logs to ESPSA, it removed unwanted fields from it, like the ones used to extract vital information. Logstash also drops logs of executions that is explicitly defined to be dropped. This was done merely to early cut out harmless commands that also tended to generate a lot of data.

4.3.5 Elasticsearch Elasticsearch acted as the database for all incoming logs and was kept as close to default configurations as possible. The configuration file for it - elasticsearch.yml in appendix E.3.1 - was only altered to enable communications with Kibana.

4.3.6 Kibana Kibana was the visualization tool used to visualize queries on the data stored in Elas- ticsearch. It too was kept as close to default configuration as possible. Its configuration file kibana.yml in appendix E.4.1 only contains a connection string to Elasticsearch. The goal of using Kibana was the creation of a dashboard containing a single line chart. This line chart was set to query for the maximum risk-value of inserted logs by ESPSA in relation to the time-stamps on the logs. This way, high numbers of log sources could be

26 Solution visualized in a single chart. An increase in the risk-value displayed in the graph would then indicate that at least one machine was at risk.

4.3.7 ESPSA 4.3.7.1 Overview The ESPSA software was composed mainly by four components, the data flow between them is depicted in figure 5. The ”TCP Reader” is responsible for reading incoming data and parse it into JSON formatted logs that it then forwards. The ”Aggregator” accepts the incoming logs and accumulates them for a while before forwarding them in a chronological order, the reason for this is described in section 4.3.7.4. The ”Processor” is the module that does the actual log analysis. In the end it stamps the logs with a quantitative risk value based on various contexts and circumstances before passing it along. The ”TCP Sender” is the last module in the line and is essentially the opposite of the sender in the beginning. It takes JSON logs that it sends out to defined targets over TCP.

Figure 5: Process ﬂow between ESPSA components

4.3.7.2 Architecture ESPSA was built in C# around two major principles: modularity and fault tolerance. The reason for that is that ESPSA is dependent upon many systems. It communicates with both Logstash and Elasticsearch, beyond that it also handles logs generated by

27 Solution

PowerShell and Windows that are enhanced by Beats. All these dependencies exist in different versions and may even exist in multiple versions in the same environment (mainly Windows and PowerShell). In such a case it is preferable to be able to enable/disable and tweak modules to fit the requirements of the environment in which it is operating. It also improves the dynamic of the system as it makes it easier to enhance by only needing to make new modules and ensure the security of that new module instead of the entire program. Fault tolerance is critical for this kind of software. Its purpose is to analyze logs at a high pace from a high number of systems in an environment. Any exceptions occurring during execution must be properly handled, otherwise the program will crash. Even though Logstash buffers logs in its outgoing queue, the potential high flow of logs can quickly result in this buffer overflowing even in the case of direct detection of failure by IT-personnel. Detecting a crash of the program is not that easy either, unless the environment produces a steady flow of logs continually, one cannot differentiate a crash from a ”calm” period since the only consequence of a crash is the lack of input into Elasticsearch. The modularity of the program is constructed in three different ways, the main program modules - as seen in figure 5 - are connected by blocking First In First Out (FIFO) queues, meaning that modules with the same ”connectors” can be easily inserted/removed from the process flow. These queues also work to improve the performance of the program. Every main module is run in parallel and when a queue is empty, the module requesting data from it will be blocked until data becomes available. Thus, con- suming no resources when unable to perform any work. The second way that modularity was introduces was to separate internal services that any module used by dependency injection. As seen in appendix B, self-contained services such as network operations or error logging is conceptualized through interfaces. This means that behavior can be altered by simply changing a parameter to a module. For instance, error logging can be changed from writing to a local text file to populating a database without needing to change any behavior of the module itself. One need only construct the different implementations of the interface and control what object is injected into the module via settings. The last implementation of modularity involves log handling. Different parts of the program need to acquire information contained within the log object, and since it is a JSON object, this access must be done dynamically. The problem with this is that the structure of the log may evolve over time, requiring a more dynamic approach to enable this access. Therefore, access to log information is done via dependency injection of anonymous functions that handles this access. Fault tolerance was constructed in two different ways. One was to make sure that no unhandled exceptions occurred and by taking the fastest way out of an exception. For instance, when an incoming log is unable to be parsed into a JSON object, the log is simply dropped instead of undergoing any salvage operation. This approach is to keep the program as fast and simple as possible - less complexity means less probability for unhandled failures. The second way to increase fault tolerance is also a complement to the first tactic. Any major exception is error logged, including the log content if the operation that failed was tied to it. These logs are supposed to serve as a basis for future

28 Solution improvement of the program or the entire system.

4.3.7.3 TCP Reader/TCP Sender The responsibilities for the reader and sender are quite straightforward. They act as the bridge between incoming data and the program as well as between the program and outgoing data. They are prefixed by ”TCP” simply because of the use of TCP in the tested solution, but since the actual reading of data is abstracted by an interface, any source and means can be used, including parsing of local files. The reader and sender both have the limitation that JSON objects that are read and written are separated by a new-line character. This comes from the fact that any means of communication composed of a continually opened channel needs a delimiter of some sort. This is also true for any other thinkable interface that returns batches of objects. It is however also acceptable to have batches composed of one single object. The reader and sender differ on one account. The reader accepts incoming data, try to parse it into a JSON object and then passing it along to the Aggregator if successfully parsed, throwing it away otherwise. The sender however has a different approach, a kind of extra fault tolerance for connectivity issues. It accepts JSON objects from the Processor and deserializes it into a byte array and then tries to push it through the interface of the connectivity service. If unsuccessful, the sender will try to reconnect through the service and try again. If unsuccessful the second try, the sender will log the error and return the log to the back of the sending queue populated by the processor. This way there will be no loss of data in the case of temporary outage of for example network connectivity.

4.3.7.4 Aggregator The Aggregator exist only for enabling compatibility with Logstash. ESPSA requires logs to be processed in a chronological order to ensure correct analytic results. Logstash however cannot guarantee this when delivering the logs. Thus, it becomes the responsibility of the Aggregator to perform this task. The Aggregator makes use of a central class called RetentionCollection which does most of the work. It is a collection that holds logs and can be told to extract and return logs that has an execution time-stamp above a certain age. The Aggregator thus both accepts logs from the TCP Reader and inserts them into this collection, but also periodically extracts logs of a certain age and forwards them to the processor in a chronological order. This enables unordered incoming logs to ”catch up” and be reordered into their correct position before being processed.

4.3.7.5 Processor The Processor is the heart of the program and is responsible for the actual analysis and enhancement of logs. It has as well as the Aggregator one major class that does the most of its work, the RiskCalculator. The Processor’s analysis of logs includes originating from the result of the previous log of the current source, meaning that it must be able to fetch

29 Solution the last processed log for sources it encounters. Thus, the Processor has two levels of caches, which implementation is free of choice by means of abstraction via interface. In this case however the first level cache was local memory and the second level was a client connection to Elasticsearch. There is a distinction between the first and second level cache. Beyond checking the first level cache for specific entries before checking the second level, the Processor only maintains the first, meaning that the Processor inserts analyzed logs into the first level cache for future needs but never into the second level cache. If both caches would come up empty, the Processor would assume that the current log is the absolute first for this source and skip the attribution of the past log to the analysis.

Risk Calculator The Risk Calculator is responsible for the actual analysis of the log and coming up with a quantitative number of the security risk the current log imposes. It calculates the new risk value as a ”base risk value” gained from the class RiskLookup multiplied by a factor given by the time of day of the execution. It then sums this value with a degradation of the risk value from the previous log. The equation used is:

yp yc = tpc + a(tc) ∗ r(bc) (1) 2 h

Where:

yc: is the risk value to be assigned the log

yp: is the risk value assigned to the previous log

tpc: is the hours between the current and previous log h: is the conﬁgured half-life of risk values in hours

a(tc): is the Akima interpolation of the time-stamp of the log

r(bc): is the base risk of the PowerShell content of the log

The time-of-day factor a(tc) used in equation 1 was calculated through an Akima Cubic Spline interpolation. The reason for choosing this solution is that it enables a dynamic setting of working hours and still maintain the same ”appearance” of the graph. In this case the wanted ”appearance” was a factor of 1 during work hours with quite a rapid increase to 2 after hours followed by an increase to 3 just before the starting hour and a rapid decrease to 1 again. Figure 6 shows a graph of an example interpolation with working hours between 8 and 17.

30 Solution

Figure 6: Example graph of Akima Cubic Spline Interpolation for time risk factoring with working hours between 8 and 17

RiskLookup This class is responsible for calculating the risk values that the Power- Shell content in logs pose entirely on their own. It uses a local JSON configuration file to make a dictionary of configurations capable of calculating risks in a custom manner. Each command can be configured with a base risk value and an arbitrary set of extra risk values that are added to the base risk based on criterions. The only supported criteria is regex queries performed on the command parameters. One can define an array of queries or a single query per criteria, regardless they must all be evaluated true for the extra risk value to be applied. Each query is tested against all parameters for a match. The complete set of criterions are all expressed in the file CommandRiskMappings.json. The risk values gained from custom evaluation is later also magnified based on certain static criterions. Three factors are taken in consideration and they all revolve around the presence of certain parameters to the PowerShell application. -EncodedCommand obfuscates scripts into base64 encoding and can be used to bypass detection, -NoProfile excludes PowerShell profiles from loading during execution and can be used to ensure that no unknown setting interferes with the execution, -WindowStyle Hidden hides the application window and can be used to run scripts unnoticed.

4.3.7.6 Command risks To assign risk values to incoming execution logs there must be deﬁnitions of what malicious commands looks like. Two parameters that would aﬀect the potential maliciousness of an execution is the probability of benign execution and the security risk the command could pose. Following this idea, commands along with possible arguments where assigned a risk value according to the function

31 Solution

ro rc = 10 ∗ (2) pl

Where:

rc: is the risk value to be assigned the command and potential argument on a scale of 0 to 100

pl: is the possibility for execution by legitimate users on a scale of 1 to 10

ro: is the security risk of the outcome/information that the command gives on a scale of 0 to 10

Table 4.3.7.6 displays the assignment of risks of all commands identified from appendix C. Each command has one or several regex parameter queries that adds its defined risk value to the total risk value every time evaluated true on a parameter. Every query is also checked against all parameters for matches. The first parameter regex of every command in the table containing a single asterisk defines the base risk value that command has regardless of parameters.

Table 3: PowerShell command risk assignments

Command Parameter regex pl ro rc Get−LocalGroup * 7 2 2.85

* 7 2 2.85 Get− LocalGroupMember −Group[ \”]∗(A|a)dmin 7 4 5.70 * 10 2 2 −Path.∗\\Startup 5 4 12.50 −Path.∗C:\\Users 7 2 2.85 Get−ChildItem −Path.∗Program Files 7 3 4.29 −Force.∗True 7 3 4.29 −Include.∗web.conﬁg 2 7 25.00 −Path.∗Registry::.∗Software 5 4 8.00 * 6 3 5.00 Win32 Product 5 3 6.00 Get−WmiObject Win32 Process 4 3 7.50 Win32 Service 4 6 15.00

32 Solution

Command Parameter regex pl ro rc Get−Service * 4 6 15.00 Get−ScheduledTask * 5 5 10.00 Get−PSDrive * 7 7 10.00 Get−Process * 4 3 7.50 * 9 2 2.22 Select−String −Path.∗Firefox\\Proﬁles 1 10 100 −Path.∗Chrome\\User Data 1 10 100 * 3 8 26.67 Invoke−WebRequest −UseDefaultCredentials 2 9 45.00

* 5 3 6 ConvertTo− SecureString −AsPlainText True 4 4 10.00 Invoke−Expression * 3 8 26.67 Start−Sleep * 2 1 5.00 * 8 0 0 −ArgumentList.∗Chrome\\User Data 1 10 100 −TypeName.∗Windows\.Security\. 1 10 100 Credentials\.PasswordVault New−Object −TypeName.∗Net\.Networkinformation 2 4 20.00 \.Ping −TypeName.∗Net\.Sockets\.TcpClient 2 5 25.00 −TypeName.∗DirectoryServices\. 2 8 40.00 DirectoryEntry −TypeName.∗Security\.Cryptography 2 8 40.00 −TypeName.∗Automation\. 7 5 7.14 PSCredential * 8 0 0 −FilterScript.∗−notlike.∗svchost 2 4 20.00 Where−Object −FilterScript.∗−notlike.∗Microsoft 2 4 20.00 −FilterScript.∗−notlike.∗Windows 2 4 20.00 −FilterScript.∗−eq.∗Auto 6 4 6.67 Enter−PSSession * 2 10 50.00

33 Solution

Command Parameter regex pl ro rc * 1 9 90 Set−MpPreference −DisableRealtimeMonitoring True 1 10 100 * 10 2 2 Get−ItemProperty −Path.∗Windows\\CurrentVersion\\ 5 4 8 Uninstall systeminfo * 6 4 6.67 * 10 2 2.00 ipconﬁg /all 8 3 3.75 * 9 2 2.22 ˆ/s$ 8 6 7.50 query 9 2 2.22 password 3 8 26.67 Currentversion\\Winlogon 6 4 6.67

reg Services\\SNMP 4 6 15.00 PuTTY 2 8 40.00 RealVNC\\WinVNC4 3 6 20.00 PowerShellEngine 3 3 10.00 Windows.∗Run 5 4 12.50 AlwaysInstallElevated 3 7 23.33 Terminal Server Client 3 3 10.00 * 10 1 1.00 user 7 3 4.29 net accounts 7 3 4.29 Administrator 5 5 10.00 start 4 3 7.50 * 8 2 2.50 whoami /all 6 3 5.00

34 Solution

Command Parameter regex pl ro rc * 10 1 1.00 ˆ/.∗s 9 1 1.11 ˆ/.∗i 9 1 1.11 \.xml$ 7 3 4.29 \. ini$ 5 5 10.00 findstr \.config$ 7 5 7.14 password 3 8 26.67 system32 3 6 12.00 binary path name 2 8 40.00 service name 2 5 25.00 SSID Cipher Content 1 10 100 * 10 2 2.00 pass 3 8 26.67 cred 3 8 26.67 \.xml 7 3 4.29 dir \. ini 5 5 10.00 \. config 7 5 7.14 vnc 3 8 26.67 Startup 5 4 12.50 * 4 3 7.50 tasklist eq system 3 6 12.00 * 6 3 5.00 netsh wlan 4 3 7.50 * 4 6 15.00 sc query 4 6 15.00 ˆqc 2 8 40.00 * 6 3 5.00 msiexec /quiet 6 6 10.00 /qn 3 6 20.00

35 5. EVALUATION

Command Parameter regex pl ro rc * 8 2 4.37 wmic service 4 6 15.00 startup 5 4 12.50 * 8 3 3.75 schtasks ˆ/query 5 5 10.00 icacls * 3 7 23.33 * 10 1 1.00 nslookup ˆ172\\.(1[6−9]|2[0−9]|3[01]) 6 3 5.00 |ˆ10\\.|ˆ192\\.168\\. * 10 1 1.00 ping ˆ172\\.(1[6−9]|2[0−9]|3[01]) 10 3 3.00 |ˆ10\\.|ˆ192\\.168\\.

5 Evaluation

To evaluate the solution, the scenarios described in section 4.2.1, 4.2.2 and 4.2.3 was run in a test-bed setup as pictured in figure 3. The risk configurations of ESPSA was assigned as described in table 4.3.7.6. The commands of each scenario were run manually and sequentially in the order they are described in each respective section. All execution was done during daytime (configured working hours in ESPSA) directly inputted into a PowerShell session window. The upper limit threshold for categorizing malicious behavior was 100 as was the basis for the risk assignment equation 2 used.

5.1 Local files This evaluation was done on the scenario described in section 4.2.1 where clear text credentials are found in local files. In this evaluation the username admin and password pass123 was found in a local XML file. The infected computer lied in the AD domain External.TestBed.se with a login controller named DCEXT. Table 5.1 displays the data relating to the simulation and PowerShell that where inserted into Elasticsearch during the simulation in a chronological fashion.

36 MSI packages

Table 4: Outcome of simulation - Local files Risk Command Parameter(s) value /si password ∗.xml findstr 51.32 ∗. ini ∗.txt ∗. config −TypeName System.DirectoryServices. New−Object DirectoryEntry 91.30 −ArgumentList LDAP://DC=External, DC=TestBed,DC=se, admin, pass123 systeminfo 97.90

−AsPlainText True ConvertTo− 113.86 SecureString −Force True −String pass123 −TypeName System.Management. New−Object Automation.PSCredential 121.00 −ArgumentList admin, System.Security. SecureString −ComputerName DCEXT Enter−PSSession 171.00 −Credential System.Management. Automation.PSCredential

5.2 MSI packages This evaluation was done on the scenario described in section 4.2.2 where a setting enabling installation of MSI packages to run with elevated privileges automatically is exploited. The script wrapper run to enable PowerShell execution that disables Win- dows Defender was C:\evil.msi. The later found credentials of the keylogger was the username admin and password pass123. The infected computer lied in the AD domain External.TestBed.se with a login controller named DCEXT. Table 5.2 displays the data relating to the simulation and PowerShell that where inserted into Elasticsearch during

37 MSI packages the simulation in a chronological fashion.

Table 5: Outcome of simulation - MSI packages Risk Command Parameter(s) value query HKLM\\SOFTWARE\\Policies\\ reg 27.77 Microsoft\\Windows\\Installer /v AlwaysInstallElevated query HKCU\\SOFTWARE\\Policies\\ reg 55.53 Microsoft\\Windows\\Installer /v AlwaysInstallElevated ∗ /quiet /qn msiexec 90.51 /i C:\\evil.msi −DisableRealtimeMonitoring True −QuarantinePurgeItemsAfterDelay 0 Set−MpPreference 280.48 −ReportingAdditionalActionTimeOut 0 ... −TypeName System.DirectoryServices. New−Object DirectoryEntry 320.36 −ArgumentList LDAP://DC=External, DC=TestBed,DC=se, admin, pass123 systeminfo 326.79

−AsPlainText True ConvertTo− 342.66 SecureString −Force True −String pass123

38 Saved browser credentials

Risk Command Parameter(s) value −TypeName System.Management. New−Object Automation.PSCredential 349.80 −ArgumentList admin, System.Security. SecureString −ComputerName DCEXT Enter−PSSession 399.80 −Credential System.Management. Automation.PSCredential

5.3 Saved browser credentials This evaluation was done on the scenario described in section 4.2.3 where stored credentials of browsers are extracted. The found AD domain credentials stored by the browsers for the logged in user Test was the username admin and password pass123. The infected computer lied in the AD domain External.TestBed.se with a login controller named DCEXT. Table 5.3 displays the data relating to the simulation and PowerShell that where inserted into Elasticsearch during the simulation in a chronological fashion.

Table 6: Outcome of simulation - Saved browser credentials Risk Command Parameter(s) value −Path HKLM:\\Software\\ Get−ItemProperty Wow6432Node\\Microsoft\\Windows\\ 10.00 CurrentVersion\\Uninstall\\∗ −ArgumentList C:\\Users\\Test\\ AppData\\Local\\Google\\Chrome\\ New−Object User Data\\Default\\Login Data, Open, 115.00 Read, ReadWrite −TypeName IO.FileStream −ArgumentList System.IO.FileStream, New−Object System.Text.Latin1Encoding 125.00 −TypeName IO.StreamReader −TypeName Windows.Security. New−Object 224.94 Credentials.PasswordVault

39 6. DISCUSSION

Risk Command Parameter(s) value −TypeName System.DirectoryServices. New−Object DirectoryEntry 264.84 −ArgumentList LDAP://DC=External, DC=TestBed,DC=se, admin, pass123 systeminfo 271.29

−AsPlainText True ConvertTo− 287.17 SecureString −Force True −String pass123 −TypeName System.Management. New−Object Automation.PSCredential 294.31 −ArgumentList admin, System.Security. SecureString −ComputerName DCEXT Enter−PSSession 344.30 −Credential System.Management. Automation.PSCredential

6 Discussion

6.1 Evaluation results As seen in table 5.1, 5.2 and 5.3, each of the run scenarios would result in a warning indication for observing parties since they exceed the value of 100. This is however only certain for the exact executions simulated. Alternative executions could very well leave a vulnerability exploitable without exceeding the threshold. The fact that all scenarios end with the same approach to reach the AD DC is what makes all the scenarios exceed the threshold. Looking at table 5.1 describing the simulation of clear text passwords in local files, if the attackers would choose an alternative way to reach the AD DC - a way not involving PowerShell execution - the final risk value after the attackers ensured the findings of AD domain administrator credentials would be 97.90. The same is true for the risk of elevated installation of MSI packages described in table 5.2. If the attackers installed a malicious MSI package that does not involve running PowerShell (or maybe circumvents the logging), the final risk value would stop at 90.51. This shows that for this approach to be successful, one cannot solely rely on the fact of automatically logging the usage of PowerShell. An active effort must be made to ensure

40 Assigned risk values minimal existence of vulnerabilities in systems exploitable via PowerShell. That way attackers that use PowerShell will probe for vulnerabilities and in the meantime running up the total risk value for the infected system. Beside heightening the probability for catching infections, it would also heighten the probability for mitigating infections before any damage or spreading has been done.

6.2 Assigned risk values The definition of risk assignment displayed in table4.3.7.6 can be questioned for their correctness or questioned for the actual existence of correct values for that matter. Equation 2 used in the assignment of risk values (rc) has the parameters of probability for benign execution (pl) and security risks of execution (ro) for the reason of minimizing false positives. The used values of these parameters when calculating risk values is however not derived from research or polls. The security risks of commands are more certain as they are derived from the output or actions that commands result in. The probabilities for benign execution however are uncertain as trustworthy estimates would require insight in real world usage of PowerShell. These parameters surely also fluctuate going from environment to environment, making assignments that are globally accurate very difficult if not impossible. There is a possibility that more accurate numbers could be found by enhancing the equation used. There is a possibility of additional parameters having impact on the risk value that could be introduced. One improvement quite clearly present is the parameters impact on the risk value. As can be seen in figure 7, the higher risk values are quite centralized at the extremes (high values of ro and low values of pl). The equation should be remade so the spike in its graph have a ”straighter” descent towards the center of the graph, giving higher risk values for parameters pl < 5 and ro > 5. How the optimal equation graph should look like is debatable and left outside the scope of this thesis.

41 Browser security

Figure 7: 3D plot of equation 2

6.3 Browser security The existence and simplicity of the commands used to extract credentials from browsers in the scenario described in section 4.2.3 raises some questions around the security of browsers. It is however not that they lack security, but how security is implemented. All passwords that are stored by the browsers are indeed encrypted, making them secure if someone would steal your hard-drive. It is the fact that they are encrypted by Windows functionality that uses user context that is problematic. This implies that the only requisite to decrypt the credentials is to be logged in as the correct user, which is fulﬁlled when having RATs operating in user context. This vulnerability is not reduced by the fact that these password managers synchronize credentials over systems, making all credentials ever saved accessible regardless of what system they were saved on.

6.4 PowerShell 6.4.1 Logging capabilities Module Logging The strength of Module logging is that it logs every call to a cmdlet with all parameters in clear text. This means that it is very easy to see exactly what commands has been executed. It also proves useful in the cases of loops, pipelines, conditionals and variable usage since a mere view of the script content would not tell you what commands was run, how many times they were run or what parameters they were run with. It is also very resilient to obfuscation methods. For example, it is possible to run scripts by downloading text from the internet into a variable and then pass this variable to a function that would interpret the text as a script and run it. This scenario would leave a script ﬁle view alternative totally blind as nothing can be seen about

42 PowerShell the content of the script executed. Module logging however would still log every single cmdlet execution inside this obfuscation method. Module logging also ignores aliases that exists for cmdlets. Meaning that aliases and case-sensitivity can be ignored which greatly simpliﬁes the eﬀort needed to analyze. The downside of Module logging is that it only logs cmdlets. Many malicious scripts make quite extensive use of .NET Framework functions and classes, which Module logging logs nothing about. This means that an enlightened attacker who knows about the presence of Module logging could potentially make scripts that run without logging a single bit of information during its execution since the .NET Framework is so widely applicable to all sorts of dilemmas.

Script Block Logging This logging is also very resilient to obfuscation methods as it logs scripts as they are passed to the PowerShell engine, as all scripts must be if anything is to be executed. It also has the beneﬁt of having the entire script written out in clear text, meaning that all types of operations are visible no matter what type. One could also argue that the visibility of conditional branches not executed is beneﬁcial. The downside of Script Block Logging is where Module logging is strong, there is no way of getting the details of executions of conditional branches or inside loops or pipelines. The usage of variables also leaves uncertainty of what exactly has been executed. Unlike Module logging you also must deal with case-sensitivity and aliases for commands.

Transcription logging Can be useful since it logs everything exactly as it appears in the console window, both input and output. The downside of it is that it thus logs nothing about the content of script ﬁles executed, or output that is written to the ﬁle system.

6.4.2 Choice of enabled GPOs The choice of enabled GPOs can be seen in table 4.3.1. The result of enabling these was to gain visibility into both PowerShell cmdlet invocations as well as invocations of system executables such as ipconfig.exe. In the case of the executables, some filtering was necessary since the GPOs enables logging of every process creation. The only process creations of interest were the ones that had been created by PowerShell. Those created by cmd.exe was also included to increase the scope of visibility and to cope with the fact that Command Line executions could be fired by PowerShell as well. The positive aspect of these GPOs is that everything is written out in a straight forward fashion, meaning that the load on the solution is lowered since little resources is needed to extract the information needed from the logs. Unfortunately, the findings of the negative aspects of Module logging described in section 6.4.1 was found to late. The choice for Module logging was made on the premise that it logged executions of all functions, including those in .NET Framework. The fact that it does not leaves a very big security hole in the solution. One consideration is if it is not more beneficial to change direction towards Script Block logging and analysis of script

43 PowerShell content. One loses the preciseness of executions, but the inclusion of .NET Framework executions may be more valuable. One could counter that loss with generalizations and risk assessments of reused results of commands whether it is via variables or pipelines as well as finding malicious execution paths in the regard of conditional branching. One concern for that approach is the efficiency diminishing of ESPSA since it absolutely will affect it negatively. Another concern is the management of aliases for commands that exists. One other aspect is that PowerShell is under constant development. There is a possibility that the logging capabilities will change in the future, for the better or the worse. Would the Module logging be enhanced to include all types of executions including static functions and class methods, then Module logging would be far more superior than Script Block logging in the aspect of automated PowerShell execution analysis.

6.4.3 Other defences 6.4.3.1 ExecutionPolicy One of the built-in defenses in PowerShell is ExecutionPolicy. It can be set via GPO and offers settable restrictions on the execution of script files and loading of configuration files. The possible values are:[17]

AllSigned: Requires that all scripts and configuration files are signed by a trusted publisher, including scripts written on the local computer. Bypass: Nothing is blocked and there are no warnings or prompts. Default: Sets the default execution policy. Restricted for Windows clients or RemoteSigned for Windows servers. RemoteSigned: Requires that all scripts and configuration files downloaded from the Internet are signed by a trusted publisher. The default execution policy for Windows server computers. Restricted: Does not load configuration files or run scripts. The default execution policy Windows client computers. Undefined: No execution policy is set for the scope. Removes an assigned execution policy from a scope that is not set by a Group Policy. If the execution policy in all scopes is Undefined, the effective execution policy is Restricted. Unrestricted: Loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs. The default execution policy for non-Windows computers and cannot be changed.

It is however very easy to bypass this kind of restriction. As Sutherland describes, there are at least 15 ways to do it.[18] The one tested and conﬁrmed was to download the script from the internet and running it with the command Invoke-Expression.

44 PowerShell

6.4.3.2 Disabling PowerShell There is also the option of completely blocking the execution of PowerShell on machines via GPO.[19] The question is if it is such a good idea. If one looks on the premise that was made for this solution, the attackers had already exploited a vulnerability to achieve remote system access via a RAT. It is then very likely that attackers have diﬀerent tools at their disposal than PowerShell but are much keener on using PowerShell to keep a low proﬁle. To disable PowerShell might thus not yield the desired outcome, it might just force the attacker to other means instead of blocking them out. The best approach would then be to keep PowerShell enabled if an adequate level of monitoring can be achieved.

6.4.4 Monitoring obstacles PowerShell houses some difficulties and obstacles when dealing with monitoring. First, there exists multiple commands that yield the same result. One example is appendix C.14, where every command returns installed software on a system. There is also a probability that there exist more commands to do that as well. Every command however does not completely mimic the others, there are differences between what they return. The overlap between them however is large enough for all of them to be suitable in many scenarios. This complicates the assurance of visibility in behaviors since covering one command is not enough, meaning that all commands must be examined in detail (all possible parameters) for complete assurance of visibility to be established. PowerShell also has aliases for commands. One example is that the execution of the command gwmi fires an execution of the command Get-WmiObject. This makes it problematic to configure commands since one does not know if the command configured is the one which will be run upon execution. The upside is that this problem disappears when complete visibility is achieved as described above. The interoperability of PowerShell is also an issue when trying to monitor its usage. The fact that PowerShell can fire executables and launch Command Prompt (CMD) scripts makes it harder to monitor. Executables and CMD scripts differ quite in structure compared to PowerShell cmdlets and scripts. Cmdlets have all its parameters named whereas executables have flags and distinct orders of its parameters. This means that thought most be given to parameter appearance and order when judging executions of executables, which differ between most executables. It becomes more problematic with the fact that some executables completely change their behavior depending on how they are executed. One example is reg.exe, where the first parameter of query or add changes the behavior from searching the registry to adding values to it. Another example is findstr.exe that searches for text within files normally but if placed inside a pipeline can search for text within results of other commands. Another issue occurs with the introduction of Windows Subsystem for Linux (WSL). According to Chris Hoffman it is possible to call Linux bash scripts from within Power- Shell just as CMD scripts are.[20] This adds yet another source of commands and possible exploits to the pool that needs to be examined. Chris also writes about the mutual ac-

45 Elastic Stack cess between the file-systems of Windows and the Linux subsystem, yielding implications regarding monitoring as both file-systems must be considered for both shells. Additionally, the logging options described in section 6.4.1 have the risk of not being consistent. This became clear with Module logging regarding calling executables. If an executable was called as a single command, there would be no information logged about the execution. However, if the executable was called as part of a pipeline, the calling of the executable would be logged. This behavior is unwanted as it results in a duplicate log since the calling of executables are fetched from another source. These peculiar cases are hard to find and can cause issues when making themselves known during production deployment.

6.5 Elastic Stack The usage of components from the Elastic Stack in the solution is not vital. These components can be replaced by any type of SIEM solution while still maintaining the functionality. The core application in this solution is ESPSA. The Elastic Stack components are only there to handle the ﬂow of information to and from it. As such the only needed component for a minimal functional solution is Beats or a similar product. The extraction of log data from endpoints is not a capability of ESPSA, all the other responsibilities however can be integrated into ESPSA. The log transformations done by Logstash and the log ﬁltering done by Beats can easily be made an extended responsibility of ESPSA. If historical data and visualizations are unwanted, maybe by wanting ESPSA to only issue real-time warnings itself, Elasticsearch and Kibana would also be unnecessary.

6.6 ESPSA 6.6.1 Execution time risk interpolation The first approach used to be able to calculate the risk factor to be applied considering time-of-day aspects of executions was a static equation of the fourth degree. The reason for that approach was mere efficiency optimization. A curve was interpolated that followed the one in figure 6 quite well, there was some oscillation around the turning points which could affect the result in a negative way. In the end Akima Cubic Spline was chosen to enable the dynamic choice of working hours and still maintain the same characteristics of the graph. Other cubic splines resulted in such oscillations around turning points that made it impossible to even get a ”near enough” good value. No efficiency measurements was made on the selected solution since no alternative was considered. There is a possibility that it can be improved by construction of a simple range check of the value, the chosen curve layout certainly is simple enough for it to be viable. The only negative aspect for such a solution is the loss of ”smoothness” in the curve, which would give a less accurate result right around the turning points. For example, the possibility for executions beyond work hours decreases increasingly as time progresses since the odds of people working overtime decreases in

46 ESPSA the same manner. Thus, the curve should mirror that and increase in a logarithmic manner.

6.6.2 Risk half-life The solution uses the approach of having a logarithmic decrease in risk level as time passes. This must of course happen one way or another otherwise every system will eventually reach alerting levels. This approach however has some ﬂaws, it does not cope very well with legitimate users running the same commands repeatedly because they forgot the result. This is extra troublesome since it is very likely that only legitimate users will behave this way. Malicious users will run commands and then extracts the results and save them, thus have no need for running the same command again. This only increases the risks for false positives and not the chances of detecting malicious usage. Another approach would be to have a retention policy for executed commands. Mean- ing that executed commands are saved for a period of time and accounts for the total risk level during that period. Another execution of the same command would not count again and thus eliminating the issue. In other words, one would sum the risks of all unique commands during a running window period as the total risk level. The problem with this approach however is that it can be quite cumbersome to implement and the impact on performance is unclear.

6.6.3 Aggregator The Aggregator in ESPSA is responsible for keeping incoming logs in chronological order. It can however not guarantee this. The aggregation is performed by periodically extracting logs of a certain age based on the time-stamp for execution. The probability for correct ordering increases as the chosen age is increased, but one does not want to have a too high delay between execution and input to Elasticsearch. The risk of having to low threshold value is that the delay that Beats and Logstash introduces is unknown. Any disruption in communications between Beats and Logstash or between Logstash and ESPSA would also result in logs being buffered. At the time that communication is resumed, a batch of logs would be transmitted that could directly lie beyond the threshold value and thus risk incorrect ordering. This could also be true in the case that systems experience high loads and therefore lag in the transmission. An implementation that completely solves this issue may be non-existent. At some point the application must take the logs buffered so far and filter them. One possible solution would be to check event record ids. Windows enumerates all created logs in an incremental fashion with an integer number that can be used to determine if all logs in a certain range has been delivered. The issue with this id is that it counts per log source and not per event type, meaning that in the case of multiple events being written to the same log source, the ids will have gaps if only one event type is considered. This is the case for the logs used by this solution, since the logs for launched executables are filtered.

47 7. CONCLUSIONS AND FUTURE WORK

6.6.4 Output waste In the current implementation of the solution there exists a filter inside the ruby script powershell.rb used by Logstash that filters out unwanted commands from logging. This should be moved to ESPSA to centralize the processing and simplify the overall design. In addition, ESPSA should be improved to drop all logs that does not increase the total risk level as they are unnecessary, currently ESPSA sends all processed logs to Elasticsearch regardless. It should however store all commands that are dropped as it could be executions that are not configured but should be included. Additionally, it could be beneficial to store executions that have configured queries but where none were applied to gain insight in missing queries for configured commands as well.

7 Conclusions and future work

It is quite possible to ensure security around PowerShell usage with the aid of automatic log analysis. However, work must be performed around it to be successful. As many vulnerabilities as possible must be patched on every monitored machine as to maximize the attackers command invocation rate in case of a breach. Any present vulnerabilities may only require a couple of commands to exploit, which complicates mitigation as it becomes harder to detect malicious usage and increases damage done or infection spread up until mitigation. Much work is needed to gain enough visibility around PowerShell usage because of its nature. PowerShell has high usability on its own, but the possibility for it to utilize CMD, WSL, .Net Framework and executables makes its scope extremely wide and difficult to cover. Things like multiple suitable commands for the same purpose and command aliases also aggravates the aim for complete monitoring coverage. Unfortunately, the logging capabilities of PowerShell are currently flawed. Neither Module logging or Script Block logging grants a complete insight in the usage of Pow- erShell and even built in security measures of PowerShell are easily sidestepped. The logging options also have the tendency to contain inconsistencies in what they log, which could lead to unwanted side-effects such as duplicate logging of executions. How the logging capabilities will evolve looking forward is also unclear. Newer versions of PowerShell might improve the overall capabilities, impair it or make one option favorable over the other. Currently the most favorable option is deemed to be Script Block logging in the sense of information given, even if the extraction of this information is more complicated as it needs an intelligent parser.

7.1 Future work The solution presented can be improved in many ways. The issues brought up in section 6.6 are all points of improvements that can be made to improve the quality and reliability of ESPSA. Some of them are improvements of current implementations and some can be made as alternative features that can be chosen via settings. Section 6.4.2 also brings up

48 Future work a possibility for an additional feature, namely a parser and analyzing tool for PowerShell script blocks. If looking at the solution, there are some improvements that can be made there as well to heighten the quality of the solution. In case of a breach the malicious usage of PowerShell may be conducted at night, which gives the attacker much more time to reach their goal than when conducted during working hours. In the worst-case scenario, they begin attacking right after work end and are not mitigated until work begins again. To counter this, some kind of automated response must be introduced. One candidate solution is some kind of measure - a locally installed client or access control measures via example a firewall - that can isolate machines that are conducting malicious usage from the rest of the network. The temporary disconnection of systems is surely to prefer over risk giving attackers enough time to reach their goal. One issue that can occur - and that surely becomes enlarged by an implementation of the improvement of automation described above - is the risk of false positives. Normal usage can and will at some point result in threshold breaches. As described in the beginning of this section, there is also the need for finding and patching vulnerabilities on machines for this solution to be efficient. This would most likely be done via automated running of scripts that searches and reports its findings. What way can be better to find vulnerabilities usable through PowerShell than to actually ”ask” PowerShell. These automated scripts would also be counted towards the threshold value and without a doubt pass it by a large margin. This is where Artificial Intelligence (AI) would come in handy. By using it to perform behavior analysis on the risk value, one can make the system react to the outliers of this analysis instead of on the risk value itself. That way both regular running scripts and normal usage can be accounted for and still re- spond to cases where the behavior deviates, thus lessen the risk for false positives. For this purpose, the Elastic Stack can prove beneficial since it provides machine learning functionality for these types of analyzes in exchange of a license fee. As described in section 6.2, the risk assessment function must also be improved to give more accurate values in relation to its parameters. Some method must also be applied to reassure the right values of the parameters of executions if looking at a global appliance.

49 REFERENCES References

References

[1] Steve Mansﬁeld-Devine, Network Security. Apr2017 2017, 2017, 7–11, DOI 10. 1016/S1353-4858(17)30037-5. [2] Danny Hendler, Shay Kels, Amir Rubin in Proceedings of the 2018 ACM Asia Con- ference on Computer and Communications Security, May 29, 2018, Association for Computing Machinery, Inc, 2018, pp. 187–197, DOI 10.1145/3196494.3196511. [3] G. Foss, PowerShell Command Line Logging, 2015, https://logrhythm.com/ blog/powershell-command-line-logging/, (accessed: 15.05.2019). [4] R. Rodriguez, Enabling Enhanced PowerShell logging Shipping Logs to an ELK Stack for Threat Hunting, 2017, https://cyberwardog.blogspot.com/2017/ 06/enabling-enhanced-ps-logging-shipping.html, (accessed: 15.05.2019). [5] Cybelius, THE 6 BIGGEST CYBERATTACKS AGAINST THE ENERGY IN- DUSTRY, 2017, http : / / www . cybelius . fr / en / 2017 / 12 / 19 / industrie - energetique-top-6-des-plus-grandes-cyberattaques/, (accessed: 01.02.2019). [6] R. Falcone, Shamoon 2: Return of the Disttrack Wiper, 2016, https://unit42. paloaltonetworks.com/unit42-shamoon-2-return-disttrack-wiper/, (accessed: 06.02.2019). [7] R. Falcone, Shamoon 3 Targets Oil and Gas Organization, 2018, https://unit42. paloaltonetworks.com/shamoon- 3- targets- oil- gas- organization/, (accessed: 06.02.2019). [8] K. Albano, The Full Shamoon: How the Devastating Malware Was Inserted Into Networks, 2017, https://securityintelligence.com/the- full- shamoon- how- the- devastating- malware- was- inserted- into- networks/, (accessed: 06.02.2019). [9] K. Lab, Energetic Bear — Crouching Yeti, 2018, https://media.kasperskycontenthub. com/wp-content/uploads/sites/43/2018/03/08080817/EB-YetiJuly2014- Public.pdf, (accessed: 05.02.2019). [10] K. Lab, Energetic Bear / Crouching Yeti: attacks on servers, 2018, https://ics- cert.kaspersky.com/reports/2018/04/23/energetic- bear- crouching- yeti-attacks-on-servers/, (accessed: 05.02.2019). [11] E-ISAC, Analysis of the Cyber Attack on the Ukrainian Power Grid, 2016, https: / / ics . sans . org / media / E - ISAC _ SANS _ Ukraine _ DUC _ 5 . pdf, (accessed: 04.02.2019). [12] A. Cherepanov, WIN32/INDUSTROYER, A new threat for industrial control systems, 2017, https://www.welivesecurity.com/wp-content/uploads/2017/ 06/Win32_Industroyer.pdf, (accessed: 01.02.2019). [13] E. V. Velzen, Crash Override: What Does The Threat Mean For Utilities?, 2017, https://encs.eu/2017/06/13/crash-override-threat-mean-utilities/, (accessed: 01.02.2019).

50 References References

[14] W. Williamson, Lateral Movement: When Cyber Attacks Go Sideways, 2016, https://www.securityweek.com/lateral-movement-when-cyber-attacks- go-sideways, (accessed: 11.02.2019). [15] M. Kamal, StupidKeylogger, 2017, https://github.com/MinhasKamal/StupidKeylogger, (accessed: 19.03.2019). [16] E. B.V., The Elastic Stack 7.0, 2019, https://www.elastic.co/products/, (accessed: 24.04.2019). [17] Microsoft, Set-ExecutionPolicy, 2019, https://docs.microsoft.com/en-us/ powershell/module/microsoft.powershell.security/set-executionpolicy? view=powershell-5.0, (accessed: 14.05.2019). [18] S. Sutherland, 15 Ways to Bypass the PowerShell Execution Policy, 2014, https: / / blog . netspi . com / 15 - ways - to - bypass - the - powershell - execution - policy/, (accessed: 15.05.2019). [19] top-password, How to Disable PowerShell with Software Restriction Policies GPO, 2018, https://www.top- password.com/blog/disable- powershell- with- software-restriction-policies-gpo/, (accessed: 15.05.2019). [20] C. Hoﬀman, Everything You Can Do With Windows 10’s New Bash Shell, 2018, https : / / www . howtogeek . com / 265900 / everything - you - can - do - with - windows-10s-new-bash-shell/, (accessed: 22.05.2019). [21] K. Milan, Get-ChromeCreds2.ps1, 2017, https://raw.githubusercontent.com/ kerrymilan / Get - ChromeCreds2 / master / Get - ChromeCreds2 . ps1, (accessed: 05.03.2019).

51 Appendices

A Attack tree

52 B. ESPSA CLASS DIAGRAM

B ESPSA Class Diagram

53 C. POWERSHELL COMMANDS

C PowerShell Commands

C.1 systeminfo C.2 net user C.3 whoami / a l l C.4

Get−ChildItem C: \ Users −Force | s e l e c t Name C.5 net user <> C.6 net accounts C.7

Get−LocalGroup | ForEach−Object { $ ; Get−LocalGroupMember − Group ” $ ”} C.8 ipconfig /all C.9 findstr /si password ∗ . xml ∗ . i n i ∗ . txt ∗ . c o n f i g C.10 cmd /c ”dir /S /B ∗ pass ∗ . txt == ∗ pass ∗ . xml == ∗ pass ∗ . i n i == ∗ cred ∗ == ∗vnc∗ == ∗ . c o n f i g ∗” C.11

54 REG QUERY HKLM /F ” password ” / t REG SZ /S /K REG QUERY HKCU /F ” password ” / t REG SZ /S /K reg query ”HKLM\SOFTWARE\ Microsoft \Windows NT\ Currentversion \ Winlogon” reg query ”HKLM\SYSTEM\ Current \ ControlSet \ S e r v i c e s \SNMP” reg query ”HKCU\ Software \SimonTatham\PuTTY\ S e s s i o n s ” reg query HKEY LOCAL MACHINE\SOFTWARE\RealVNC\WinVNC4 /v password reg query HKLM /f password /t REG SZ / s reg query HKCU /f password /t REG SZ / s C.12

Get−Childitem −Path C: \ inetpub \ −Include web.config −F i l e − Recurse −ErrorAction SilentlyContinue C.13 cmd /c WLAN extract. bat[D.1] C.14

Get−WmiObject −Class Win32 Product Get−ChildItem ’C: \ Program Files ’, ’C: \ Program Files (x86)’ | f t Parent ,Name, LastWriteTime Get−ChildItem −path Registry ::HKEY LOCAL MACHINE\SOFTWARE | f t Name Get−ItemProperty HKLM: \ Software \Wow6432Node\ Microsoft \Windows\ CurrentVersion \ U n i n s t a l l \∗ | S e l e c t −Object DisplayName , DisplayVersion , Publisher , InstallDate | Format−Table − AutoSize C.15 t a s k l i s t /v net s t a r t sc.exe query wmic service list brief Get−S e r v i c e Get−WmiObject −Query ”Select ∗ from Win32 Process ” | where { $ . Name −notlike ”svchost ∗”} | Select Name, Handle, @{ Label=” Owner”; Expression={$ .GetOwner() .User }} | f t −AutoSize C.16

55 tasklist /v /fi ”username eq system” C.17

REG QUERY ”HKLM\SOFTWARE\ Microsoft \ PowerShell \1\ PowerShellEngine” /v PowerShellVersion C.18 cmd /c ”schtasks /query /fo LIST 2>nul | findstr TaskName” Get−ScheduledTask | where { $ . TaskPath −n o t l i k e ”\ Microsoft ∗”} | ft TaskName,TaskPath , State C.19 reg query HKLM\ Software \ Microsoft \Windows\ CurrentVersion \R reg query HKCU\ Software \ Microsoft \Windows\ CurrentVersion \Run reg query HKCU\ Software \ Microsoft \Windows\ CurrentVersion \ RunOnce d i r ”$env :APPDATA\ Microsoft \Windows\ Star t Menu\Programs\ Startup ” d i r ”C: \ ProgramData\ Microsoft \Windows\ Star t Menu\Programs\ StartUp ” C.20

$hash = @{} $one = wmic service list full | findstr /i ”pathname” | f i n d s t r /i /v ”system32” | % { $t = $ −split ’=’; $t[1] } $two = sc.exe query state=all | f i n d s t r ”SERVICE NAME: ” | % { $t = $ −split ’ ’; $t[1] } | % { sc . exe qc ” $ ”} | f i n d s t r ” BINARY PATH NAME” | % { $t = $ −split ”: ”; $t[1] } $one + $two | % { i f ( $ .StartsWith(’”’)) { $r = $ −s p l i t ’ ” ’ ; $s = $r [ 1 ] } e l s e { $r = $ −split ’ ’; $s = $r[0] } $s } | %{ i f ( $hash . $ −eq $ n u l l ) { $ } ; $hash . $ = 1} | % { i c a c l s $ } C.21 gwmi −c l a s s Win32 Service −Property Name, DisplayName , PathName , StartMode | Where { $ . StartMode −eq ”Auto” −and $ . PathName −n o t l i k e ”C: \ Windows∗” −and $ . PathName −n o t l i k e ’”∗ ’} | select PathName,DisplayName ,Name C.22 reg query HKLM\SOFTWARE\ P o l i c i e s \ Microsoft \Windows\ Installer /v AlwaysInstallElevated

56 reg query HKCU\SOFTWARE\ P o l i c i e s \ Microsoft \Windows\ Installer /v AlwaysInstallElevated C.23 msiexec /quiet /qn /i C: \ e v i l . msi C.24

Set−MpPreference −DisableRealtimeMonitoring $true C.25

REG QUERY ”HKCU\ Software \ Microsoft \ Terminal Server Client \ S e r v e r s ” / s C.26

Get−PSDrive C.27

$hash = @{} $input paths = ”$env:localappdata \ Packages \ Microsoft . MicrosoftEdge 8wekyb3d8bbwe \AC\#!001\ MicrosoftEdge \ Cookies \∗”, ”$env:localappdata \ Mozilla \ F i r e f o x \ P r o f i l e s \ s3xrny7d . d e f a u l t \ cache2 \ e n t r i e s \∗”, ”$env:localappdata \ Google \Chrome\ User Data\ Default \Cache\ data ∗” $regex = ”\ b172 \ . \ d { 1 , 3 }\ .[16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] \ . \ d {1 ,3}\b | \ b10 \ . \ d {1 ,3}\.\ d {1 ,3}\.\ d{1 ,3}\b | \ b192 \ . 1 6 8 \ . \ d {1 ,3}\.\ d{1 ,3}\ bhttps ? : \ / \ / (www\ .)?[−a−zA−Z0−9@:%. \+˜#=]{2,256}\b” $input paths | % { s e l e c t −s t r i n g −Path $ −Pattern $regex − AllMatches | % { $ . Matches } | % { $ . Value } | %{ i f ( $hash . $ −eq $ n u l l ) { $ } ; $hash . $ = 1}} C.28

Get-ChromeCreds2.ps1[21] C.29

[void ][Windows. Security . Credentials .PasswordVault ,Windows. Security . Credentials ,ContentType=WindowsRuntime] $vault = New−Object Windows. Security . Credentials .PasswordVault $vault.RetrieveAll() | % { $ .RetrievePassword() ;$ }

57 C.30

([ adsisearcher]”objectCategory=User”). Findall() | ForEach { $ . properties .samaccountname} C.31

1 . . 2 5 4 | % { nslookup ”< > $ ” } | s e l e c t −string ”Name” −Context 0 ,1 C.32

$ping = New−Object System.Net.Networkinformation.Ping 1 . . 2 5 4 | % { $ping .send(”< > $ ”) | select address, status } C.33 function testport ($hostname=’yahoo.com’ ,$port=80,$timeout=100) { $requestCallback = $state = $null $client = New−Object System.Net.Sockets.TcpClient $beginConnect = $client .BeginConnect($hostname,$port , $requestCallback , $state) Start −Sleep −milli $timeOut if ($client.Connected) { $open = $true } e l s e { $open = $ f a l s e } $client.Close() [pscustomobject]@{hostname=$hostname ; port=$port ; open=$open} }

<>..<> | % { t e s t p o r t −hostname <> − port $ } | Format−Table −AutoSize C.34 function testport ($hostname=’yahoo.com’ ,$port=80,$timeout=100) { $requestCallback = $state = $null $client = New−Object System.Net.Sockets.TcpClient $beginConnect = $client .BeginConnect($hostname,$port , $requestCallback , $state) Start −Sleep −milli $timeOut if ($client.Connected) { $open = $true } e l s e { $open = $ f a l s e } $client.Close()

~~58 [pscustomobject]@{hostname=$hostname ; port=$port ; open=$open} }~~

~~1 . . 2 5 4 | % { t e s t p o r t −hostname ”< > $ ” −port <>} | Format−Table −AutoSize C.35~~

$hash = @{} $ b a s e u r l = <> $ o u t p u t f o l d e r = <> function Scrape ($url) { Write−Host $ u r l $hash.$url = 1; $res = Invoke−WebRequest −Uri $ u r l − UseDefaultCredentials $ r e s | S e l e c t −Object −Expand Content > ( $ o u t p u t f o l d e r + $url.replace(”/”,” ”) + ”.txt”) $ r e s | S e l e c t −Object −Expand Links | S e l e c t h r e f | %{ i f ($hash.( $base u r l + $ . h r e f ) −eq $ n u l l −And $ . h r e f . StartsWith(”/”)) { Scrape ($base u r l + $ . h r e f ) }} }

Scrape $base u r l C.36 function connect remote ($hostname ,$account ,$password) { $pass = ConvertTo−SecureString $password −AsPlainText − Force $cred= New−Object System.Management.Automation. PSCredential ($account, $pass ) Enter−PSSession −ComputerName $hostname −Credential $cred } connect remote −hostname <~~> −account <> −password <> C.37 function test −cred($username ,$password) {~~

~~$CurrentDomain = ”LDAP://” + ([ADSI]””) .distinguishedName~~

~~59 $domain = New−Object System.DirectoryServices. DirectoryEntry($CurrentDomain ,$UserName,$Password)~~

if ($domain.name −eq $ n u l l ) { write −host ”Username and password does not match” } e l s e { write −host ”Username and password match” } } t e s t −cred −username <> −password <> C.38

~~([ adsisearcher]”(& (objectCategory=User) (samaccountname=<>) )”).FindOne() | % { [datetime ]::FromFileTime( [int64 ] : : Parse ( $ .properties.item(”lastLogon”) ) ) } C.39~~

~~([ adsisearcher]”objectCategory=User”). Findall() | % { $s = ”$ ( $ . properties .samaccountname) − $ ( $ .properties.description) ” ; $s } C.40~~

~~([ adsisearcher]”(& (objectCategory=User) (samaccountname=<>) )”).FindOne() | % { $ . properties .memberof} D Command-line and PowerShell scripts~~

D.1 WLAN extract.bat cls & echo. & for /f ”tokens=4 delims=: ” %a in (’netsh wlan show profiles ˆ | find ”Profile ”’) do @echo off > nul & ( netsh wlan show profiles name=%a key=clear | findstr ”SSID Cipher Content” | find /v ”Number” & echo.) & @echo on E System Conﬁgurations

~~E.1 Winlogbeat E.1.1 winlogbeat.yml~~

60 LogStash winlogbeat. event l o g s : − name: Windows PowerShell e v e n t i d : 800 i g n o r e o l d e r : 2h − name: Security e v e n t i d : 4688 i g n o r e o l d e r : 2h processors: − drop event : when : and : − not : c o n t a i n s : winlog.event data.ParentProcessName: ”powershell.exe” − not : c o n t a i n s : winlog.event data .ParentProcessName: ”cmd.exe” setup.template. settings : index.number of shards : 3 output.logstash: hosts: [”192.168.131.2:5044”] processors: − add host metadata : ˜ E.2 LogStash E.2.1 pipelines.yml

− pipeline.id: powershell p o s t pipeline.workers: 2 path.config: ”config/PsPost.conf” − pipeline.id: powershell p r e queue.type: persisted pipeline.workers: 2 path.config: ”config/PsPre.conf” E.2.2 PsPre.conf input { beats { port => ”5044” }

~~61 LogStash~~

~~} f i l t e r { if [winlog][event i d ] == 800 {~~

grok { match => { ”[winlog ][ event data ][param2]” => ”DetailSequence=%{INT :[temp][nr]: int }%{GREEDYDATA} DetailTotal=%{INT : [ temp ] [ o f ] : i n t }%{GREEDYDATA}SequenceNumber=%{INT:[temp][ psid ] : i n t }” } }

if [temp][of] > 1{ if [temp][nr] == 1{ aggregate { t a s k i d => ”%{[ host ] [ id ] } %{[temp][ psid] } ” map action => ” c r e a t e ” code => ”map[’param3’] = event.get( ’[winlog][ event data ][param3] ’)” } } else if [temp][nr] < [ temp ] [ o f ] { aggregate { t a s k i d => ”%{[ host ] [ id ] } %{[temp][ psid] } ” map action => ” update ” code => ”map[’param3’] += event.get( ’[winlog ][ event data ][param3] ’)” } } else if [temp][nr] == [temp][of] { aggregate { t a s k i d => ”%{[ host ] [ id ] } %{[temp][ psid] } ” map action => ” update ” code => ”map[’param3’] += event.get( ’[winlog ][ event data][param3]’); event.set(’[winlog][ event data ][param3] ’ , map[ ’param3’])” e n d o f t a s k => true timeout => 120 } } }

~~if [temp][nr] == [temp][of] { grok {~~

~~62 LogStash~~

match => { ”[winlog ][ event data ][param2]” => ”\ tHostApplication =%{DATA:[ powershell ][ host application] }\ n\ tEngineVersion=%{DATA:[ powershell ][ version] }\ n\ t%{ DATA}\ tScriptName=%{DATA:[ powershell ][ script name ] }\ n\tCommandLine=%{GREEDYDATA: [ p o w e r s h e l l ] [ main command ] } ” } } ruby { path => ”C: \ l o g s t a s h \ s c r i p t s \ powershell.rb” } mutate { r e m o v e f i e l d => [ ”[winlog][event data]”, ”temp”, ” message ” ] } } e l s e { drop {} }

} else if [winlog][event i d ] == 4688 { mutate { a d d f i e l d => { ”[powershell ][ script name ] ” => ”” ”[powershell ][ host application]” => ”%{[ winlog ] [ event data ][ ParentProcessName] } ” ”[powershell ][main command ] ” => ”%{[winlog ][ event data ] [ CommandLine] } ” } } grok { match => { ”[winlog ][ event data ][CommandLine]” => ’(? <[powershell ] [ command] >[A−Za−z ] ∗ ? ( ? = \ . | | $ ) ) . ∗ ?( \ s | $ )%{ GREEDYDATA:[ powershell ][ parameters ] } ’ } } if (”” in [powershell][parameters]) { ruby { code => ’event.set(”[powershell ][parameters]”, event. get(”[powershell ][parameters]”). split(/\ s ( ? = ( ? : [ ˆ ” ] | ” [ ˆ ” ] ∗ ”) ∗$ ) /) ) ’ } } e l s e {

~~63 LogStash~~

mutate { update => { ”[powershell ][parameters]” => [] } } } } } output { tcp { codec => j s o n l i n e s port => ”9432” host => ”localhost” } } E.2.3 PsPost.conf input { tcp { port => ”9555” codec => ” j s o n l i n e s ” } } f i l t e r { } output { elasticsearch { hosts => [’http://localhost:9200’] } } E.2.4 powershell.rb def filter(event) retval = Array.new payload = event.get(’[winlog][event data ][param3] ’) commands = payload. split (’CommandInvocation( ’)

~~if commands.length > 1 for i in 1..commands.length −1 # Find the current command being executed name = commands[ i ][/ˆ. ∗ ? ( ? = \ ))/] event.set ( ’[powershell ][command] ’ , name)~~

~~64 Elasticsearch~~

# Skip commands not of interest next if [’ForEach−Object’, ’Out−Default’, ’Set−StrictMode ’ , ’Add−Member’ , ’Format−Table ’ , ’ PSConsoleHostReadline ’ , ’Write−Host ’]. include? name # Skip .exe calls in module logging next if name.match(/. ∗ \ . exe /) # find all parameter names r = commands[ i ]. scan(/(?<=name=\”). ∗ ? ( ? = \ ”;)/) # find all parameter values v = commands[ i ]. scan(/(?<= value =\”).∗?(?=\” $ |\”\ n) /) # merge parameters with their values i f r . length > 0 x = r.zip(v).map { | par , val | ’ − ’+par+ ’ ’ + (val== nil ? ’’ : val) } event.set(’[powershell][parameters]’, x) end retval .push(event.clone) end end

return retval end E.3 Elasticsearch E.3.1 elasticsearch.yml node.name: node−1 network.host: 192.168.131.2 http.port: 9200 discovery.seed hosts: [”127.0.0.1”, ”[::1]”] cluster.initial m a s t e r nodes: [”node −1”] E.4 Kibana E.4.1 kibana.yml elasticsearch.hosts: [”http://192.168.131.2:9200”] F Windows Event Log Examples

~~F.1 800~~

~~65 4688~~

~~800 4 8 0x80000000000000 9303 Windows PowerShell Test.External.TestBed.se ~~Get−LocalGroupMember −Group ”Administrators” DetailSequence=1 DetailTotal=1~~~~

~~SequenceNumber=321~~

UserId=TestBed\ User HostName=ConsoleHost HostVersion=5.1.14124.390 HostId=d74aa6d4−a61b−4ad8−92ca−8f87264ce325 HostApplication=C: \ Windows\System32\WindowsPowerShell\ v1 . 0 \ powershell.exe EngineVersion=5.1.14124.390 RunspaceId=311eb544−9c23−4ce8−fab5 −6263fb2ed9b4 PipelineId=109 ScriptName= CommandLine=Get−LocalGroupMember −Group ”Administrators ” CommandInvocation(Get−LocalGroupMember) : ”Get− LocalGroupMember” ParameterBinding(Get−LocalGroupMember) : name=”Group”; value=” Administrators” F.2 4688

~~66 4688~~

4688 2 0 23142 0 0x4010033000000000 1067816 Security PCTEST. domain . org S −1−5−11−1958571442−1511111993−426229303−5177 user Domain 0xac9e155 0x2164 C: \ Windows\System32\ i p c o n f i g . exe %%5536 0x26e8 ”C: \WINDOWS\ system32 \ ipconfig.exe ” S−0−0−0 − − 0x0 C: \ Windows\System32\ WindowsPowerShell\v1 . 0 \ powershell.exe S−4−16−8111