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 perime-
ter than inside networks which opens up vulnerabilities. Directed cyber-attacks
towards the energy sector which leverages this fact has increased and can have dis-
astrous 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 mali-
cious by reaching total risk values above the threshold of 100 in their exact imple-
mentation. 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 flow between solution components . . . . . . . . . . . . . . . . . . 25
5 Process flow 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 files . . . . . . . . . . . . . . . . . . . . . . 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 logoff 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 Artificial 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 Configuration 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 Specification. 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 com-
mands automate tasks via scripts and batch files, 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 func-
tion 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 appli-
cations 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, pass-
words and credit card details by disguising oneself as a trustworthy entity in an
electronic communication. Typically carried out by email spoofing or instant mes-
saging, 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 exe-
cute 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 definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 definition

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 definitions
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 defining 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 recon-
naissance 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 com-
pared 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 analy-
sis 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-off 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 efficient 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 Infiltration
The attackers used spear phishing via email with a Microsoft Office 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 em-
bedded 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 configured 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 file 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 Infiltration
The attackers make use of three different 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 soft-
ware 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 file and
set the registry to run it on the next startup. Another example is the infection of an in-
staller 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 files

and file structure, running processes, internet settings, Basic Input/Ouput System
(BIOS) versions and email addresses.

• Stealing contacts by collecting details from local Outlook files.

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 com-
mands which include taking screenshots, updating itself, downloading DLLs, starting
executables, running shell commands and listing directories. The results of the com-
mands 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 com-
mands. 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 cre-
dentials 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 authen-
tication 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 re-
sulted in 225 000 customers being without electricity for three hours.[11] These were the
first 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 different security measures and environments of
the three companies. Hence Ukrainian government officials claimed that Russian security
services were behind the attack.

3.4.1 Infiltration
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 Office 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 even-
tually found their way into network segments where SCADA servers and workstations
existed. Although not proven, the attackers must have performed reconnaissance ac-
tions 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 different
Distribution Management Systems (DMSs) that required the attackers to gather network
information specifically 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 in-
formation 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 specifically 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 figure 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 different 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 exe-
cutable. It implements a subset of the IEC 61850 protocol used to perform protection,
automation, metering, monitoring and control of electrical substation automation sys-
tems. 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 com-
ponents 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 defined 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 cen-
ters. Both of these however is highly difficult 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 differ-
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 finding
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 sim-
ulated 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 Mansfield-Devine mentions.[1]

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

Module Logging enables log creations in the Windows ”Event Center” at the ex-
ecution of PowerShell cmdlets. The term ”Module logging” comes from the fact that
PowerShell has a setup of modules that consists of predefined 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 file is created that contains the code for the module cmdlets.
The logs created by this option contains the executed command along with all param-
eters 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 com-
puters file 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 docu-
ment files in diverse formats.

Logstash is a data collection engine that unifies 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 different
types of operational data to Elasticsearch either directly or through Logstash, where the
data might be enhanced or archived. There are seven different 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 in-
formation about network resources and application-specific data. Administrators can
use ADDS to organize users, computers and other hardware into a hierarchical con-
tainer 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 figure 2. It was constructed as a typical partial setup of a corporate network involving
office 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 \ M i c r o s o f t \Windows\ S t a r t Menu\
Programs \ S t a r t u p \ WindowsShell . l n k ” −PathType L e a f ) )
{
copy ” $env : l o g o n s e r v e r \SYSVOL\ S t u p i d K e y l o g g e r −a p p l i c a t i o n \
WindowsShell . exe ” $env : appdata$
copy ” $env : l o g o n s e r v e r \SYSVOL\ S t u p i d K e y l o g g e r −a p p l i c a t i o n \
WindowsShell . l n k ” ” $env : appdata \ M i c r o s o f t \Windows\ S t a r t
Menu\ Programs \ S t a r t u p ”
s t a r t ”” ” $env : appdata \ M i c r o s o f t \Windows\ S t a r t Menu\
Programs \ S t a r t u p \ WindowsShell . l n k ”
}

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 . l o g ”
”\\DCExt\ P u b l i c $ \ Record−$env : computername−$env : username . l o g ”

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 en-
abled 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 cre-
dentials are also synced between machines, making all credentials saved by users acces-
sible 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 find that the user has Google Chrome
installed. They then continue by running script 28 and 29 (since Microsoft Edge is in-
stalled 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 appli-
cation 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 findings
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 mon-
itoring 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 com-
mands 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 first 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 ”ipconfig.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 figure 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-flow between all these components can be seen in figure 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-defined configuration.

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

24
Solution

Figure 4: Process flow 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 gener-
ated 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 ” = {
” s c r i p t n a m e ” = ” P s S c r i p t . ps1 ” ,
” h o s t a p p l i c a t i o n ” = ”C: \ Windows\ System32 \ WindowsPowerShell
\ v1 . 0 \ p o w e r s h e l l . exe −N o P r o f i l e ” ,
”main command” = ”Get−LocalGroup | ForEach−Object { $ ; Get
−LocalGroupMember −Group \” $ \ ” } ” ,
” version ” = ”5.1.17134.590” ,
”command” = ”Get−LocalGroupMember ” ,
” parameters = [
”−Group A d m i n i s t r a t o r s ”
]
}

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 flow 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 en-
able/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 pro-
gram 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 insert-
ed/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 im-
plementations 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 responsi-
bility 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 configured 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 definitions of what mali-
cious commands looks like. Two parameters that would affect 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.config 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\\Profiles 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
ipconfig
/ 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 execu-
tion 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 creden-
tials 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
fulfilled 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 file 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 simplifies the effort 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 log-
ging 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 benefit 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 beneficial.
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 ex-
ecuted. 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 files executed, or output that is written to the file
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 possi-
bility 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 execu-
tion 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 per-
mission 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 confirmed 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 different tools
at their disposal than PowerShell but are much keener on using PowerShell to keep a
low profile. 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 flow of information to and from it. As such the only needed com-
ponent 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 filtering 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 flaws, 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 log-
ging 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 be-
ginning 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 Mansfield-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/, (ac-
cessed: 06.02.2019).
[7] R. Falcone, Shamoon 3 Targets Oil and Gas Organization, 2018, https://unit42.
paloaltonetworks . com / shamoon - 3 - targets - oil - gas - organization/, (ac-
cessed: 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 sys-
tems, 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. Hoffman, 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: \ U s e r s −Force | s e l e c t Name

C.5

n e t u s e r <<admin username based on language >>

C.6

net accounts
C.7

Get−LocalGroup | ForEach−Object { $ ; Get−LocalGroupMember −

Group ” $ ”}
C.8

ipconfig / all
C.9

f i n d s t r / s i password ∗ . xml ∗ . i n i ∗ . t x t ∗ . c o n f i g
C.10

cmd / c ” d i r /S /B ∗ p a s s ∗ . t x t == ∗ p a s s ∗ . xml == ∗ p a s s ∗ . i n i == ∗
c r e d ∗ == ∗ 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

r e g query ”HKLM\SOFTWARE\ M i c r o s o f t \Windows NT\ C u r r e n t v e r s i o n \

Winlogon ”
r e g query ”HKLM\SYSTEM\ Current \ C o n t r o l S e t \ S e r v i c e s \SNMP”
r e g query ”HKCU\ S o f t w a r e \SimonTatham\PuTTY\ S e s s i o n s ”
r e g query HKEY LOCAL MACHINE\SOFTWARE\RealVNC\WinVNC4 /v
password

r e g query HKLM / f password / t REG SZ / s

r e g query HKCU / f password / t REG SZ / s
C.12

Get−C h i l d i t e m −Path C: \ i n e t p u b \ −I n c l u d e web . c o n f i g −F i l e −

Recurse −E r r o r A c t i o n S i l e n t l y C o n t i n u e
C.13

cmd / c WLAN extract . bat [D.1]

C.14

Get−WmiObject −C l a s s Win32 Product

Get−ChildItem ’C: \ Program F i l e s ’ , ’C: \ Program F i l e s ( x86 ) ’ | f t
Parent , Name , LastWriteTime
Get−ChildItem −path R e g i s t r y : : HKEY LOCAL MACHINE\SOFTWARE | f t
Name
Get−Item Pro per ty HKLM: \ S o f t w a r e \Wow6432Node\ M i c r o s o f t \Windows\
C u r r e n t V e r s i o n \ U n i n s t a l l \∗ | S e l e c t −Object DisplayName ,
D i s p l a y V e r s i o n , P u b l i s h e r , I n s t a l l D a t e | Format−Table −
AutoSize
C.15

t a s k l i s t /v
net s t a r t
s c . exe query
wmic s e r v i c e l i s t b r i e f
Get−S e r v i c e
Get−WmiObject −Query ” S e l e c t ∗ from Win32 Process ” | where { $ .
Name −n o t l i k e ” s v c h o s t ∗”} | S e l e c t Name , Handle , @{ L ab el=”
Owner ” ; E x p r e s s i o n={$ . GetOwner ( ) . User }} | f t −AutoSize
C.16

55
t a s k l i s t /v / f i ” username eq system ”
C.17

REG QUERY ”HKLM\SOFTWARE\ M i c r o s o f t \ P o w e r S h e l l \1\

P o w e r S h e l l E n g i n e ” /v P o w e r S h e l l V e r s i o n
C.18

cmd / c ” s c h t a s k s / query / f o LIST 2>n u l | f i n d s t r TaskName”

Get−ScheduledTask | where { $ . TaskPath −n o t l i k e ”\ M i c r o s o f t ∗”}
| f t TaskName , TaskPath , S t a t e
C.19

r e g query HKLM\ S o f t w a r e \ M i c r o s o f t \Windows\ C u r r e n t V e r s i o n \R

r e g query HKCU\ S o f t w a r e \ M i c r o s o f t \Windows\ C u r r e n t V e r s i o n \Run
r e g query HKCU\ S o f t w a r e \ M i c r o s o f t \Windows\ C u r r e n t V e r s i o n \
RunOnce
d i r ” $env :APPDATA\ M i c r o s o f t \Windows\ S t a r t Menu\ Programs \ S t a r t u p
”
d i r ”C: \ ProgramData \ M i c r o s o f t \Windows\ S t a r t Menu\ Programs \
StartUp ”
C.20

$hash = @{}
$one = wmic s e r v i c e l i s t f u l l | f i n d s t r / i ” pathname ” | f i n d s t r
/ i /v ” system32 ” | % { $ t = $ − s p l i t ’ = ’ ; $ t [ 1 ] }
$two = s c . exe query s t a t e=a l l | f i n d s t r ”SERVICE NAME: ” | % { $ t
= $ − s p l i t ’ ’ ; $ t [ 1 ] } | % { s c . exe qc ” $ ”} | f i n d s t r ”
BINARY PATH NAME” | % { $ t = $ − s p l i t ” : ” ; $ t [ 1 ] }
$one + $two | % { i f ( $ . S t a r t s W i t h ( ’ ” ’ ) ) { $ r = $ − s p l i t ’ ” ’ ;
$ s = $ r [ 1 ] } e l s e { $ r = $ − s p l i t ’ ’ ; $ 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 W i n 3 2 S e r v i c e −P r o p e r t y 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
’ ” ∗ ’ } | s e l e c t PathName , DisplayName , Name
C.22

r e g query HKLM\SOFTWARE\ P o l i c i e s \ M i c r o s o f t \Windows\ I n s t a l l e r /v

AlwaysInstallElevated

56
r e g query HKCU\SOFTWARE\ P o l i c i e s \ M i c r o s o f t \Windows\ I n s t a l l e r /v
AlwaysInstallElevated
C.23

m s i e x e c / q u i e t /qn / i C: \ e v i l . msi
C.24

Set−MpPreference −D i s a b l e R e a l t i m e M o n i t o r i n g $ t r u e
C.25

REG QUERY ”HKCU\ S o f t w a r e \ M i c r o s o f t \ Terminal S e r v e r C l i e n t \

Servers ” /s
C.26

Get−PSDrive
C.27

$hash = @{}
$ i n p u t p a t h s = ” $env : l o c a l a p p d a t a \ Packages \ M i c r o s o f t .
MicrosoftEdge 8wekyb3d8bbwe \AC\#!001\ M i c r o s o f t E d g e \ C o o k i e s
\ ∗ ” , ” $env : l o c a l a p p d a t a \ M o z i l l a \ F i r e f o x \ P r o f i l e s \ s3xrny7d .
d e f a u l t \ c a c h e 2 \ e n t r i e s \ ∗ ” , ” $env : l o c a l a p p d a t a \ Google \Chrome\
User Data\ D e f a u l t \ Cache \ data ∗”
$ r e g e x = ”\ 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 } \ b h t t p s ? : \ / \ / (www\ . ) ?[ −a−zA−Z0−9@: % .
\+˜#=]{2 ,256}\b”
$ i n p u t p a t h s | % { s e l e c t −s t r i n g −Path $ −P a t t e r n $ r e g e x −
AllMatches | % { $ . Matches } | % { $ . Value } | %{ i f ( $hash .
$ −eq $ n u l l ) { $ } ;
$hash . $ = 1}}
C.28

Get-ChromeCreds2.ps1[21]
C.29

[ v o i d ] [ Windows . S e c u r i t y . C r e d e n t i a l s . PasswordVault , Windows .

S e c u r i t y . C r e d e n t i a l s , ContentType=WindowsRuntime ]
$ v a u l t = New−Object Windows . S e c u r i t y . C r e d e n t i a l s . PasswordVault
$vault . RetrieveAll ( ) | % { $ . RetrievePassword ( ) ; $ }

57
C.30

( [ a d s i s e a r c h e r ] ” o b j e c t C a t e g o r y=User ” ) . F i n d a l l ( ) | ForEach { $ .
p r o p e r t i e s . samaccountname }
C.31

1 . . 2 5 4 | % { n s l o o k u p ”<<network subnet , eg 192.168.0. > > $ ” } |

s e l e c t −s t r i n g ”Name” −Context 0 , 1
C.32

$ p i n g = New−Object System . Net . N e t w o r k i n f o r m a t i o n . Ping

1 . . 2 5 4 | % { $ p i n g . send(”<<network subnet , eg 192.168.0. > > $ ” )
| s e l e c t address , s t at u s }
C.33

f u n c t i o n t e s t p o r t ( $hostname =’ yahoo . com ’ , $ p o r t =80 , $ t i m e o u t =100)

{
$requestCallback = $state = $null
$ c l i e n t = New−Object System . Net . S o c k e t s . T c p C l i e n t
$beginConnect = $ c l i e n t . BeginConnect ( $hostname , $port ,
$requestCallback , $state )
S t a r t −S l e e p − m i l l i $timeOut
i f ( $ c l i e n t . Connected ) { $open = $ t r u e } e l s e { $open =
$false }
$ c l i e n t . Close ()
[ p s c u s t o m o b j e c t ]@{ hostname=$hostname ; p o r t=$ p o r t ; open=$open }
}

<<s t a r t port >>..<<end port>> | % { t e s t p o r t −hostname <<host>> −

p o r t $ } | Format−Table −AutoSize
C.34

f u n c t i o n t e s t p o r t ( $hostname =’ yahoo . com ’ , $ p o r t =80 , $ t i m e o u t =100)

{
$requestCallback = $state = $null
$ c l i e n t = New−Object System . Net . S o c k e t s . T c p C l i e n t
$beginConnect = $ c l i e n t . BeginConnect ( $hostname , $port ,
$requestCallback , $state )
S t a r t −S l e e p − m i l l i $timeOut
i f ( $ c l i e n t . Connected ) { $open = $ t r u e } e l s e { $open =
$false }
$ c l i e n t . Close ()

58
 [ p s c u s t o m o b j e c t ]@{ hostname=$hostname ; p o r t=$ p o r t ; open=$open }
}

1 . . 2 5 4 | % { t e s t p o r t −hostname ”<<network subnet , eg

192.168.0. > > $ ” −p o r t <<port >>} | Format−Table −AutoSize
C.35

$hash = @{}
$ b a s e u r l = <<h o s t name/ ip>>
$ o u t p u t f o l d e r = <<output f o l d e r >>

f u n c t i o n Scrape ( $ u r l ) {
Write−Host $ u r l
$hash . $ u r l = 1 ;
$ r e s = 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 . r e p l a c e (”/” ,” ”) + ” . txt ”)
$ r e s | S e l e c t −Object −Expand L i n k s | S e l e c t h r e f | %{ i f
( $hash . ( $ b a s e u r l + $ . h r e f ) −eq $ n u l l −And $ . h r e f .
S t a r t s W i t h ( ” / ” ) ) { S c r a p e ( $ b a s e u r l + $ . h r e f ) }}
}

Scrape $ b a s e u r l
C.36

f u n c t i o n c o n n e c t r e m o t e ( $hostname , $account , $password ) {

$ p a s s = ConvertTo−S e c u r e S t r i n g $password −AsPlainText −
Force
$ c r e d= New−Object System . Management . Automation . P S C r e d e n t i a l
( $account , $ p a s s )
Enter−P S S e s s i o n −ComputerName $hostname −C r e d e n t i a l $ c r e d
}

c o n n e c t r e m o t e −hostname <<s e r v e r name>> −a c c o u n t <<u s e r name>>

−password <<u s e r password>>
C.37

f u n c t i o n t e s t −c r e d ( $username , $password ) {

$CurrentDomain = ”LDAP: / / ” + ( [ ADSI ] ” ” ) . d i s t i n g u i s h e d N a m e

59
 $domain = New−Object System . D i r e c t o r y S e r v i c e s .
D i r e c t o r y E n t r y ( $CurrentDomain , $UserName , $Password )

i f ( $domain . name −eq $ n u l l )

{
w r i t e −h o s t ” Username and password d o e s not match”
}
else
{
w r i t e −h o s t ” Username and password match”
}
}

t e s t −c r e d −username <<u s e r name>> −password <<password>>

C.38

( [ a d s i s e a r c h e r ]”(& ( o b j e c t C a t e g o r y=User ) ( samaccountname=<<u s e r

name>>) ) ” ) . FindOne ( ) | % { [ d a t e t i m e ] : : FromFileTime ( [ i n t 6 4
] : : Parse ( $ . p r o p e r t i e s . item ( ” l a s t L o g o n ” ) ) ) }
C.39

( [ a d s i s e a r c h e r ] ” o b j e c t C a t e g o r y=User ” ) . F i n d a l l ( ) | % { $ s = ” $ (
$ . p r o p e r t i e s . samaccountname ) − $ ( $ . p r o p e r t i e s . d e s c r i p t i o n )
” ; $s }
C.40

( [ a d s i s e a r c h e r ]”(& ( o b j e c t C a t e g o r y=User ) ( samaccountname=<<u s e r

name>>) ) ” ) . FindOne ( ) | % { $ . p r o p e r t i e s . memberof }

D Command-line and PowerShell scripts

D.1 WLAN extract.bat

c l s & echo . & f o r / f ” t o k e n s=4 d e l i m s =: ” %a i n ( ’ n e t s h wlan

show p r o f i l e s ˆ | f i n d ” P r o f i l e ” ’ ) do @echo o f f > n u l & (
n e t s h wlan show p r o f i l e s name=%a key=c l e a r | f i n d s t r ”SSID
Cipher Content ” | f i n d /v ”Number” & echo . ) & @echo on

E System Configurations
E.1 Winlogbeat
E.1.1 winlogbeat.yml

60
LogStash

winlogbeat . event logs :

− name : Windows P o w e r S h e l l
e v e n t i d : 800
i g n o r e o l d e r : 2h
− name : S e c u r i t y
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 :
contains :
w i n l o g . e v e n t d a t a . ParentProcessName : ” p o w e r s h e l l . exe ”
− not :
contains :
w i n l o g . e v e n t d a t a . ParentProcessName : ”cmd . exe ”

setup . template . s e t t i n g s :
index . number of shards : 3

output . l o g s t a s h :
hosts : [”192.168.131.2:5044”]

processors :
− add host metadata : ˜
E.2 LogStash
E.2.1 pipelines.yml

− pipeline . id : powershell post

p i p e l i n e . workers : 2
path . c o n f i g : ” c o n f i g / PsPost . c o n f ”
− pipeline . id : powershell pre
queue . type : p e r s i s t e d
p i p e l i n e . workers : 2
path . c o n f i g : ” c o n f i g / PsPre . c o n f ”
E.2.2 PsPre.conf

input {
beats {
p o r t => ”5044”
}

61
LogStash

filter {
i f [ w i n l o g ] [ e v e n t i d ] == 800 {

grok {
match => {
” [ w i n l o g ] [ e v e n t d a t a ] [ param2 ] ” => ” D e t a i l S e q u e n c e=%{INT
: [ temp ] [ nr ] : i n t }%{GREEDYDATA} D e t a i l T o t a l=%{INT : [ temp
] [ o f ] : i n t }%{GREEDYDATA} SequenceNumber=%{INT : [ temp ] [
p s i d ] : i n t }”
}
}

i f [ temp ] [ o f ] > 1{
i f [ temp ] [ nr ] == 1{
aggregate {
t a s k i d => ”%{[ h o s t ] [ i d ] } %{[temp ] [ p s i d ] } ”
map action => ” c r e a t e ”
code => ”map [ ’ param3 ’ ] = e v e n t . g e t ( ’ [ w i n l o g ] [
e v e n t d a t a ] [ param3 ] ’ ) ”
}
} e l s e i f [ temp ] [ nr ] < [ temp ] [ o f ] {
aggregate {
t a s k i d => ”%{[ h o s t ] [ i d ] } %{[temp ] [ p s i d ] } ”
map action => ” update ”
code => ”map [ ’ param3 ’ ] += e v e n t . g e t ( ’ [ w i n l o g ] [
e v e n t d a t a ] [ param3 ] ’ ) ”
}
} e l s e i f [ temp ] [ nr ] == [ temp ] [ o f ] {
aggregate {
t a s k i d => ”%{[ h o s t ] [ i d ] } %{[temp ] [ p s i d ] } ”
map action => ” update ”
code => ”map [ ’ param3 ’ ] += e v e n t . g e t ( ’ [ w i n l o g ] [
e v e n t d a t a ] [ param3 ] ’ ) ; e v e n t . s e t ( ’ [ w i n l o g ] [
e v e n t d a t a ] [ param3 ] ’ , map [ ’ param3 ’ ] ) ”
e n d o f t a s k => t r u e
t i m e o u t => 120
}
}
}

i f [ temp ] [ nr ] == [ temp ] [ o f ] {
grok {

62
LogStash

match => {
” [ w i n l o g ] [ e v e n t d a t a ] [ param2 ] ” => ”\ t H o s t A p p l i c a t i o n
=%{DATA: [ p o w e r s h e l l ] [ h o s t a p p l i c a t i o n ] } \ n\
t E n g i n e V e r s i o n=%{DATA: [ p o w e r s h e l l ] [ v e r s i o n ] } \ n\ t%{
DATA}\ tScriptName=%{DATA: [ p o w e r s h e l l ] [ s c r i p t n a m e
] } \ 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 \ p o w e r s h e l l . rb ”
}
mutate {
r e m o v e f i e l d => [ ” [ w i n l o g ] [ e v e n t d a t a ] ” , ”temp ” , ”
message ” ]
}
} else {
drop {}
}

} e l s e i f [ w i n l o g ] [ e v e n t i d ] == 4688 {
mutate {
a d d f i e l d => {
” [ p o w e r s h e l l ] [ s c r i p t n a m e ] ” => ””
” [ p o w e r s h e l l ] [ h o s t a p p l i c a t i o n ] ” => ”%{[ w i n l o g ] [
e v e n t d a t a ] [ ParentProcessName ] } ”
” [ p o w e r s h e l l ] [ main command ] ” => ”%{[ w i n l o g ] [ e v e n t d a t a
] [ CommandLine ] } ”
}
}
grok {
match => {
” [ w i n l o g ] [ e v e n t d a t a ] [ CommandLine ] ” => ’ ( ? < [ p o w e r s h e l l
] [ command] >[A−Za−z ] ∗ ? ( ? = \ . | | $ ) ) . ∗ ? ( \ s | $ )%{
GREEDYDATA: [ p o w e r s h e l l ] [ p a r a m e t e r s ] } ’
}
}
i f (”” in [ powershell ] [ parameters ] ) {
ruby {
code => ’ e v e n t . s e t ( ” [ p o w e r s h e l l ] [ p a r a m e t e r s ] ” , e v e n t .
get ( ” [ powershell ] [ parameters ] ” ) . s p l i t (/\ s
( ? = ( ? : [ ˆ ” ] | ” [ ˆ ” ] ∗ ” ) ∗$ ) /) ) ’
}
} else {

63
LogStash

mutate {
update => { ” [ p o w e r s h e l l ] [ p a r a m e t e r s ] ” => [ ] }
}
}
}
}

output {
tcp {
c o d e c => j s o n l i n e s
p o r t => ”9432”
h o s t => ” l o c a l h o s t ”
}
}
E.2.3 PsPost.conf

input {
tcp {
p o r t => ”9555”
c o d e c => ” j s o n l i n e s ”
}
}

filter {
}

output {
elasticsearch {
h o s t s => [ ’ h t t p : / / l o c a l h o s t : 9 2 0 0 ’ ]
}
}
E.2.4 powershell.rb

def f i l t e r ( event )
r e t v a l = Array . new
payload = e v e n t . g e t ( ’ [ w i n l o g ] [ e v e n t d a t a ] [ param3 ] ’ )
commands = payload . s p l i t ( ’ CommandInvocation ( ’ )

i f commands . l e n g t h > 1
f o r i i n 1 . . commands . l e n g t h −1
# Find t h e c u r r e n t command b e i n g e x e c u t e d
name = commands [ i ] [ / ˆ . ∗ ? ( ? = \ ) ) / ]
e v e n t . s e t ( ’ [ p o w e r s h e l l ] [ command ] ’ , name )

64
Elasticsearch

# Skip commands not o f i n t e r e s t

next i f [ ’ ForEach−Object ’ , ’ Out−D e f a u l t ’ , ’ Set−StrictMode
’ , ’Add−Member ’ , ’ Format−Table ’ , ’
PSConsoleHostReadline ’ , ’ Write−Host ’ ] . i n c l u d e ? name
# Skip . exe c a l l s i n module l o g g i n g
next i f name . match ( / . ∗ \ . exe / )
# f i n d a l l parameter names
r = commands [ i ] . s c a n (/(?<=name=\”) . ∗ ? ( ? = \ ” ; ) / )
# f i n d a l l parameter v a l u e s
v = commands [ i ] . s c a n (/(?<= v a l u e =\”) . ∗ ? ( ? = \ ” $ | \ ” \ n ) / )
# merge p a r a m e t e r s with t h e i r v a l u e s
i f r . length > 0
x = r . z i p ( v ) . map { | par , v a l | ’ − ’ + par + ’ ’ + ( v a l ==
n i l ? ’ ’ : val )}
event . s e t ( ’ [ powershell ] [ parameters ] ’ , x )
end
r e t v a l . push ( e v e n t . c l o n e )
end
end

return retval

end
E.3 Elasticsearch
E.3.1 elasticsearch.yml

node . name : node−1

network . h o s t : 1 9 2 . 1 6 8 . 1 3 1 . 2
h t t p . p o r t : 9200
discovery . seed hosts : [”127.0.0.1” , ” [ : : 1 ] ” ]
c l u s t e r . i n i t i a l m a s t e r n o d e s : [ ” node −1”]
E.4 Kibana
E.4.1 kibana.yml

e l a s t i c s e a r c h . hosts : [ ” http : / / 1 9 2 . 1 6 8 . 1 3 1 . 2 : 9 2 0 0 ” ]

F Windows Event Log Examples

F.1 800

<Event xmlns=”h t t p : / / schemas . m i c r o s o f t . com/ win /2004/08/ e v e n t s /

e v e n t”>

65
4688

<System>
<P r o v i d e r Name=”P o w e r S h e l l ” />
<EventID Q u a l i f i e r s =”0”>800</EventID>
<Level >4</Level >
<Task>8</Task>
<Keywords>0x80000000000000 </Keywords>
<TimeCreated SystemTime=”2019−05−20T13 : 4 0 : 2 5 . 2 1 4 4 4 1 6 0 0 Z” />
<EventRecordID >9303</EventRecordID>
<Channel>Windows PowerShell </Channel>
<Computer>Test . E x t e r n a l . TestBed . se </Computer>
<S e c u r i t y />
</System>
<EventData>
<Data>Get−LocalGroupMember −Group ” A d m i n i s t r a t o r s ”</Data>
<Data> D e t a i l S e q u e n c e=1
D e t a i l T o t a l =1

SequenceNumber=321

U s e r I d=TestBed \ User
HostName=ConsoleHost
HostVersion =5.1.14124.390
HostId=d74aa6d4−a61b−4ad8 −92ca −8f 8 7 2 6 4 c e 3 2 5
H o s t A p p l i c a t i o n=C: \ Windows\ System32 \ WindowsPowerShell \
v1 . 0 \ p o w e r s h e l l . exe
EngineVersion =5.1.14124.390
RunspaceId =311eb544 −9c23 −4ce8−fab5 −6263 fb2ed9b4
P i p e l i n e I d =109
ScriptName=
CommandLine=Get−LocalGroupMember −Group ” A d m i n i s t r a t o r s
”</Data>
<Data>CommandInvocation ( Get−LocalGroupMember ) : ”Get−
LocalGroupMember ”
ParameterBinding ( Get−LocalGroupMember ) : name=”Group ” ; v a l u e=”
Administrators ”
</Data>
</EventData>
</Event>
F.2 4688

<Event xmlns=”h t t p : / / schemas . m i c r o s o f t . com/ win /2004/08/ e v e n t s /

e v e n t”>
<System>

66
4688

<P r o v i d e r Name=”M i c r o s o f t −Windows−S e c u r i t y −A u d i t i n g ” Guid

=”{2119625−5422−4994−A5BA−3E3B0008C30D}” />
<EventID >4688</EventID>
<Version >2</Version >
<Level >0</Level >
<Task >23142</Task>
<Opcode>0</Opcode>
<Keywords>0x4010033000000000 </Keywords>
<TimeCreated SystemTime=”2019−04−26T08 : 1 9 : 0 3 . 4 8 9 3 7 8 9 0 0 Z” />
<EventRecordID >1067816</ EventRecordID>
<C o r r e l a t i o n />
<E x e c u t i o n P r o c e s s I D =”2” ThreadID =”8260” />
<Channel>S e c u r i t y </Channel>
<Computer>PCTEST. domain . org </Computer>
<S e c u r i t y />
</System>
<EventData>
<Data Name=”S u b j e c t U s e r S i d”>S
−1−5−11−1958571442−1511111993−426229303−5177</Data>
<Data Name=”SubjectUserName”>u s e r </Data>
<Data Name=”SubjectDomainName”>Domain</Data>
<Data Name=”S u b j e c t L o g o n I d ”>0xac9e155 </Data>
<Data Name=”NewProcessId”>0x2164 </Data>
<Data Name=”NewProcessName”>C: \ Windows\ System32 \ i p c o n f i g .
exe </Data>
<Data Name=”TokenElevationType”>%%5536</Data>
<Data Name=”P r o c e s s I d ”>0x26e8 </Data>
<Data Name=”CommandLine”>”C: \WINDOWS\ system32 \ i p c o n f i g . exe
”</Data>
<Data Name=”T a r g e t U s e r S i d”>S−0−0−0</Data>
<Data Name=”TargetUserName”>−</Data>
<Data Name=”TargetDomainName”>−</Data>
<Data Name=”TargetLogonId”>0x0</Data>
<Data Name=”ParentProcessName”>C: \ Windows\ System32 \
WindowsPowerShell \ v1 . 0 \ p o w e r s h e l l . exe </Data>
<Data Name=”MandatoryLabel”>S−4−16−8111</Data>
</EventData>
</Event>

67