Windows 10 Sicherheitsmechanismen Und Integration in Den Elastic Stack

Windows 10 Sicherheitsmechanismen und Integration
in den Elastic Stack
Windows 10 security mechanisms and integration in

the Elastic Stack
Masterarbeit
Zur Erlangung des akademischen Grades
Master of Science
der Fachhochschule FH Campus Wien

Masterstudiengang: IT-Security
Vorgelegt von:
Patrick Matula, BSc
Personenkennzeichen:
c1810537018
ErstbetreuerIn / ErstbegutachterIn:
FH-Hon.Prof. Priv.-Doz. Mag. DI. DI. Dr.techn. Karl Michael Göschka
Eingereicht am:
15.05.2020
Erklärung:
Ich erkläre, dass die vorliegende Masterarbeit von mir selbst verfasst wurde und ich keine
anderen als die angeführten Behelfe verwendet bzw. mich auch sonst keiner unerlaubter
Hilfe bedient habe.
Ich versichere, dass ich diese Masterarbeit bisher weder im In- noch im Ausland (einer
Beurteilerin/einem Beurteiler zur Begutachtung) in irgendeiner Form als Prüfungsarbeit
vorgelegt habe.
Weiters versichere ich, dass die von mir eingereichten Exemplare (ausgedruckt und
elektronisch) identisch sind.
Datum: 15.05.2020 .............. Unterschrift:

............................................
i
Kurzfassung
Das Microsoft Betriebssystem Windows ist im Desktop Bereich marktführend. Aufgrund

dessen ist das Betriebssystem Windows ein attraktives Angriffsziel. Microsoft hat durch die
Einführung von Sicherheitssystemen intensiv daran gearbeitet, das Betriebssystem
sicherer zu machen. Die Methodik der Arbeit besteht aus einer Literaturrecherche,
empirischen Tests und eigenen Analysen. Die Basis für etliche neue
Sicherheitskomponenten ist das Modell von „Virtualization-based Security“. Durch dieses
Modell wird es ermöglicht, einen sicheren Kernel-Mode und User-Mode zu implementieren.
Damit sind sicherheitskritische Komponenten auch vor Administratorinnen und
Administratoren geschützt und ein Angriff auf diese Systeme wird erheblich erschwert. Die
integrierten Sicherheitsmechanismen sind die Grundlage des Windows Betriebssystems.
Diese integrierten Sicherheitsmechanismen sind im System oft ohne zusätzliche
Konfigurationen aktiviert. Die Sicherheitskomponenten sind meist mit einer umfangreichen
Konfiguration sowie anderen Auswirkungen verbunden und werden anschließend
behandelt. Eine wesentliche Erkenntnis der Sicherheitskomponenten ist, dass diese oft
inkompatibel mit veralteter Software sind. Die für den Benutzer nicht transparenten
Sicherheitskomponenten sind eine Einschränkung in der Verwendung des
Betriebssystems. Eine bedachte Vorgehensweise beim Ausrollen dieser
Sicherheitskomponenten und entsprechende Einschulungen der Benutzer sind
empfehlenswert. Aufgrund der Vielzahl der Angriffsmöglichkeiten wird im letzten Kapitel
die Integration mit dem Elastic Stack durchgeführt. Der Fokus liegt dabei auf der Prüfung
der Funktionalität und des Fortschritts der im Jahr 2019 eingeführten Elastic Security
Information and Event Management (SIEM) Applikation. Diese erfolgt durch sieben
definierte Testszenarien, um Angriffe zu simulieren. Die Testszenarien umfassen die
Ausführung eines Exploits, eine unübliche PowerShell Aktivität, ein verdächtiges Makro in
einem Microsoft Office Dokument, eine Bruteforce Attacke auf das Zielsystem, Einbindung
einer Sigma Regel, Verifizierung einer vorgestellten Sicherheitskomponente und
Erkennung von Kryptojacking. Die vordefinierten Regeln funktionieren und sind sinnvoll
kategorisiert. Elastic SIEM erkennt die Angriffe dessen Schutz auf Windows Defender
basiert nicht oder nur eingeschränkt. Die Einbindung von Performance Metriken für eine
Angriffserkennung ist im Standard nicht vorgesehen, lässt sich allerdings mit Metricbeat
problemlos umsetzen. Eine (verbesserte) Integration der Windows Komponenten
(beispielsweise Windows Defender) wäre wünschenswert.
ii
Abstract
The Microsoft operating system Windows is the market leader within the desktop sector.
Because of this market leadership, the Windows operating system is an attractive target.
Microsoft has worked hard to make the operating system more secure by introducing
security systems. The methodology of this thesis consists of a literature research,
empirical tests and own analyzes. The basis for several new security components is the
model of "virtualization-based security". This model implements safe kernel-mode and a
safe user-mode. This means that security-critical components are also protected from
administrators and attacking these systems is made more difficult. The integrated security
mechanisms are the basis of the Windows operating system in terms of security. These
integrated security mechanisms are often activated in the system without additional
configurations. The security components are usually associated with extensive
configuration and other effects which will be discussed subsequently. Security components
are often incompatible with outdated software. The security components that are not
transparent to the user are a limitation in the use of the operating system. A careful
approach when rolling out these safety components and appropriate user training are
recommended. Due to the large number of attack options, the integration with the elastic
stack is carried out in the last chapter. The focus is on testing the functionality and progress
of the Elastic Security Information and Event Management (SIEM) application launched in
2019. This is done using seven defined test scenarios to simulate attacks. The test
scenarios include the execution of an exploit, an unusual PowerShell activity, a suspicious
macro in a Microsoft Office document, a brute force attack on the target system, integration
of a sigma rule, verification of a presented security component and detection of
cryptojacking. The predefined rules work and are sensibly categorized. Elastic SIEM does
not detect the attacks whose protection is based on Windows Defender or only to a limited
extent. The integration of performance metrics for attack detection is not provided in the
standard, but can be easily implemented with Metricbeat. An (improved) integration of the
Windows components (e.g. Windows Defender) would be desirable.
3
Inhalt
KURZFASSUNG ................................................................................................ II
ABSTRACT ..................................................................................................... 3
1. EINLEITUNG ............................................................................................. 7
2. MICROSOFT WINDOWS ............................................................................. 8
2.1 Windows Internals ............................................................................ 8
2.1.1 Begriffsdefinitionen ........................................................................................8
2.1.2 User-Mode / Kernel-Mode .............................................................................9
2.1.3 Prozesse ..................................................................................................... 10
2.1.4 Speichermanagement.................................................................................. 11
2.1.5 Zusammenfassung ...................................................................................... 12
3. WINDOWS SICHERHEIT ........................................................................... 12

3.1 Integrierte Sicherheitsmechanismen ............................................ 14
3.1.1 Security identifiers ....................................................................................... 14
3.1.2 Integritätslevel ............................................................................................. 14
3.1.3 Tokens ........................................................................................................ 15
3.1.4 Impersonation .............................................................................................. 15
3.1.5 Account Rights, Privileges und Super privileges .......................................... 15
3.1.6 User Account Control................................................................................... 16
3.1.7 Trusted Platform Module ............................................................................. 16
3.1.8 Antimalware Scan Interface ......................................................................... 16
3.1.9 Bootvorgang sichern .................................................................................... 17
3.1.10 Address Space Layout Randomization .................................................... 18
3.1.11 Control Flow Guard.................................................................................. 19
3.1.12 Data Execution Prevention ...................................................................... 20
3.1.13 Kernel Patch Protection ........................................................................... 21
3.1.14 Zusammenhang ....................................................................................... 21
3.2 Übersicht und Zusammenhang der Sicherheitskomponenten .. 21
3.3 AppLocker ....................................................................................... 22
3.3.1 Funktionsweise ............................................................................................ 23
3.3.2 Konfiguration ............................................................................................... 23
3.3.3 Auswirkungen auf Benutzer ......................................................................... 24
3.3.4 Auswirkungen auf die Applikationsentwicklung ............................................ 25
3.4 BitLocker ......................................................................................... 25
3.4.1 Funktionsweise ............................................................................................ 25
4
3.4.2 Konfiguration ............................................................................................... 26
3.5 Controlled Folder Access .............................................................. 27
3.5.1 Funktionsweise ............................................................................................ 28
3.5.3 Auswirkung auf die Applikationsentwicklung ................................................ 29
3.6 Windows Defender Application Control ....................................... 29
3.6.1 Funktionsweise ............................................................................................ 30
3.6.2 Auswirkungen auf Benutzer/ die Applikationsentwicklung ............................ 31
3.7 Windows Defender Application Guard ......................................... 31
3.7.1 Konfiguration ............................................................................................... 31
3.7.2 Auswirkung auf Benutzer ............................................................................. 32
3.8 Windows Defender Credential Guard ........................................... 32
3.8.1 Funktionsweise ............................................................................................ 32
3.8.2 Konfiguration ............................................................................................... 33
3.9 Windows Defender Exploit Guard ................................................. 35
3.9.1 Funktionsweise ............................................................................................ 38
3.10 Windows Defender Firewall ........................................................ 39
3.10.1 Funktionsweise ........................................................................................ 39
3.10.2 Auswirkung auf Benutzer ......................................................................... 40
3.10.3 Auswirkung auf die Applikationsentwicklung ............................................ 40
4. ELASTIC STACK ..................................................................................... 40

4.1 Security Information and Event Management ............................. 41
4.2 Implementierung ............................................................................. 42
4.2.1 Konfiguration des Elastic Stacks.................................................................. 43
4.2.2 Sichere Konfiguration des Elastic Stacks ..................................................... 43
4.2.3 Einbindung des Windows 10 Clients ............................................................ 44
4.3 Elastic SIEM .................................................................................... 47
4.3.1 Testszenario 1: Exploit ................................................................................ 48
4.3.2 Testszenario 2: PowerShell ......................................................................... 49
4.3.3 Testszenario 3: Microsoft Office .................................................................. 51
5
4.3.4 Testszenario 4: Login Bruteforce ................................................................. 52
4.3.5 Testszenario 5: Passwort Dump Erkennung (Sigma Regel) ........................ 53
4.3.6 Testszenario 6: Controlled Folder Access.................................................... 54
4.3.7 Testszenario 7: Kryptojacking ...................................................................... 56
4.3.8 Gesamtübersicht ......................................................................................... 58
5. RELATED WORK .................................................................................... 59

6. ZUSAMMENFASSUNG .............................................................................. 61
7. AUSBLICK .............................................................................................. 61
ABKÜRZUNGSVERZEICHNIS .......................................................................... LXII
SCHLÜSSELBEGRIFFE ................................................................................. LXIV
LITERATURVERZEICHNIS ............................................................................... 65
ABBILDUNGSVERZEICHNIS ............................................................................ 74
TABELLENVERZEICHNIS ................................................................................ 76
6
1. EINLEITUNG
Windows ist das Betriebssystem, welches im Desktop Bereich marktführend ist [1].
Aufgrund dessen ist Windows ein attraktives Angriffsziel. Microsoft hat viele
Erweiterungen am Betriebssystem durchgeführt um die Sicherheit zu erhöhen.
Einige Erweiterungen (Sicherheitskomponenten) erfordern eine zusätzliche
Konfiguration. Diese Konfiguration muss vom Administrator sicher, aber auch dem
jeweiligen Unternehmen angepasst, durchgeführt werden. In Systemen mit einer
großen Anzahl an Windows Clients ist eine zusätzliche Herausforderung die
Angriffe zentral zu erkennen. Diese Arbeit verbindet daher die zwei
Themengebiete: Windows Sicherheit und zentralisierte Angriffserkennung.
Die Methodik im ersten Themengebiet besteht aus einer Literaturrecherche ergänzt
durch eigenständige Analysen. Im zweiten Themengebiet besteht die
Vorgehensweise primär aus empirischen Tests und wird durch Grundlagenliteratur
ergänzt.
In dieser Arbeit, werden sicherheitsrelevante Features, die meist eine erhöhte
Implikation auf das System haben, als Sicherheitskomponenten bezeichnet.
Abhängig von der jeweiligen Sicherheitskomponente, hat diese meist
Auswirkungen auf deren Verwendung. Ein „Application-Whitelisting“ (wie
beispielsweise bei AppLocker oder „Windows Defender Application Control“)
beschränkt den Benutzer eine beliebige ausführbare Datei zu starten. Im Aspekt
der Applikationsentwicklung, kann ein Einsatz einer solchen
Sicherheitskomponente ebenso problematisch sein. „Legacy“-Applikationen
versuchen beispielsweise ausführbare Dateien nicht unter dem dafür
vorgesehenen Pfad (%programfiles%) abzulegen. Diese Routinen müssen,
vorausgesetzt dass eine Verschlechterung der Konfiguration bezüglich der
Sicherheitskomponente nicht erlaubt ist, angepasst werden.
Für die zentrale Angriffserkennung wurde Elastic Stack eingesetzt. Um den
technischen Fortschritt des im Jahre 2019 erschienen Produkts zu prüfen, wurden
sieben Testszenarien definiert. Es gibt bereits 92 Regeln für die Erkennung von
Angriffen. Im Zuge dieser Arbeit wurden dabei drei der „built-in“ Regeln überprüft.
Die Erkennung und grafische Darstellung im Elastic Stack hat sehr gut funktioniert.
Das Erstellen von eigenen Regeln ist ebenso möglich und wurde mit den anderen
Testszenarien erprobt. Im siebten Testszenario wurde die Erkennung eines
Kryptojacking Angriffs über die Ressourcen-Auslastung erforscht. Auch wenn die
Einbindung des entsprechenden Beats (Metricbeat) im Standard nicht vorgesehen
ist, hat dies in der Elastic SIEM ohne Probleme funktioniert.
Eine bessere Integration mit dem Windows Betriebssystem bzw. dessen
Sicherheitsfunktionalitäten wäre wünschenswert, damit mehr Angriffe (ohne
manuelle Tätigkeit) erkannt werden. Im Folgenden beginnt die Arbeit, mit einer
Einführung des Betriebssystems bzw. der Sicherheitsmechanismen auf Prozess-
und Speichermanagementebene (siehe Kapitel 2). Besonders hervorgehoben wird
das Modell von „Virtualization-based Security“, welches einen sicheren Kernel-
Mode und User-Mode zur Verfügung stellt.
Anschließend werden integrierte Sicherheitsmechanismen bzw. Konzepte
vorgestellt (siehe Kapitel 3.1). Dies umfasst beispielsweise die Absicherung des
Bootvorgangs, Tokens oder auch Integritätslevel.
7
Danach werden verschiedene aktuelle Sicherheitskomponenten analysiert. Der
Fokus dieser Analyse liegt sowohl darauf, die Sicherheitskomponenten technisch
zu erläutern, als auch darauf, die Auswirkungen auf die Anwendenden und auf die
Applikationsentwicklung darzustellen.
Das zweite Themengebiet, Elastic Stack, beschäftigt sich mit der neu eingeführten
Elastic Security Information and Event Management (SIEM) Applikation (siehe
Kapitel 4). Diese erst im Jahr 2019 eingeführte Applikation innerhalb des Elastic
Stacks soll auf Fortschritt und Analysefähigkeiten geprüft werden. Um diese
Prüfung zu ermöglichen, wurden sieben verschiedene Angriffsszenarien definiert
und im Zuge dieser Arbeit durchgeführt (siehe Kapitel 4.3).
2. MICROSOFT WINDOWS
Beginnend mit Windows 8 und Windows Phone 8 wurde ein Kernel für beide
Systeme eingeführt. Dieser gemeinsame Kernel heißt „OneCore“ und ist auf PCs,
Smartphones, Xbox One, HoloLens und Internet of Things Geräten implementiert
(siehe [2], S. 3). Als Grundlage für die vorgestellten Mechanismen und praktische
Tests wird das Desktopbetriebssystem Windows 10 Enterprise herangezogen. Der
Grund dafür ist, dass viele wichtige sicherheitsrelevante Funktionalitäten nur in
dieser Version zur Verfügung stehen [3].
2.1 Windows Internals
Im Kapitel Windows Sicherheit werden die grundlegenden
Sicherheitsmechanismen des Windows Betriebssystems vorgestellt. Die
Grundlagen des Betriebssystems, welche für die Sicherheitsmechanismen
notwendig sind, werden im folgenden Kapitel erklärt.
2.1.1 Begriffsdefinitionen
Wichtige Begriffe sollen in der nachstehenden Tabelle zusammengefasst werden,
da viele von ihnen oft als Synonyme verwendet werden.
8
Begriff Beschreibung
Windows API-Funktionen Dokumentierte aufrufbare Subroutinen
der Windows API.
“System calls” Vom User-Mode aufrufbare
undokumentierte Services.
Routinen Ausschließlich vom Kernel-Mode
aufrufbare Subroutinen.
Windows Services Prozesse die vom „Windows service
control manager“ gestartet werden.
„Dynamic link libraries” (DLLs) Aufrufbare Subroutinen, die zwischen
den ausführbaren Dateien geteilt
werden können.
Tabelle 1: Begriffsdefinitionen Windows (siehe [2], S. 7)
2.1.2 User-Mode / Kernel-Mode

Windows unterstützt zwei „privilege levels“, die auf der Central Processing Unit
(CPU) entsprechend abgebildet sind (siehe [2], S. 23). Standardapplikationen
laufen im User-Mode, betriebssystemkritischer Code (beispielsweise Gerätetreiber)
laufen hingegen im Kernel-Mode. Die Trennung dient dazu, dass eine Applikation,
die im User-Mode läuft, nicht die Systemstabilität gefährden kann. Der Kernel-Mode
hat Zugriff auf den gesamten Speicher und auf alle CPU-Instruktionen. Dadurch
können auch Sicherheitsmechanismen entschärft werden, denn mit Windows 2000
wurde die Treibersignierung eingeführt. Seit Windows 7 müssen alle Treiber nach
dem Standard Windows Hardware Quality Lab (WHQL) zertifiziert werden, damit
diese in das System geladen werden können.
Mit Windows 10 bzw. Server 2016 wurde das „Virtualization-based Security“ (VBS)
Konzept eingeführt (siehe [2], S. 59), um sich vor schadhaftem Code im Kernel-
Mode zu schützen. Trotz Signierung des Kernel-Mode Code (beispielsweise
Gerätetreiber) können Sicherheitslücken dazu führen, dass fremder Code injiziert
wird. Mit VBS wird eine zusätzliche Trennung zwischen „traditionellem“ Kernel-
Mode und „Secure“ Kernel-Mode vollzogen.
9
Abbildung 1: VBS Architektur (siehe [2], S. 59), [4]
In Abbildung 1 ist auf der linken Seite der bereits vorgestellte traditionelle Aufbau
von User-Mode und Kernel-Mode. Auf der rechten Seite wird der traditionelle
Aufbau mit einem isolierten User-Mode und einem „Secure“ Kernel-Mode erweitert.
Hier werden User-Mode und Kernel-Mode als „Virtual Trust Level (VTL) 0“ und der
Isolierte User-Mode und „Secure“ Kernel-Mode als „VTL 1“ bezeichnet. Die VTLs
bilden daher eine zusätzliche Trennung zu der horizontalen zwischen User-Mode
und Kernel-Mode. Der Kernel-Mode kann nicht auf VTL1 Komponenten
(beispielsweise auf den isolierten User-Mode) zugreifen.
Mit diesem Konzept wird erreicht, dass auch schadhafte Treiber oder
Systemservices von Drittherstellern keine Auswirkungen auf das
Kernbetriebssystem haben. In den isolierten User-Mode können nur speziell
signierte ausführbare Dateien geladen werden, diese werden dann als „Trustlets“
bezeichnet. Neue „Trustlets“ können ausschließlich mit Zugriff auf den „Secure
Kernel“ erstellt werden und diesen hat nur Microsoft. Die technische
Implementierung und Trennung der VTLs wird durch den Hypervisor (Microsoft
Hyper-V [5]) bzw. durch „Second Level Address Translation“ (SLAT) [6] erreicht.
Um die Integrität der Funktionalität sicherzustellen, ist es notwendig, bereits den
Bootvorgang abzusichern (siehe Kapitel 3.1.9). In dem Fall, da sich bereits vor dem
Betriebssystem Schadsoftware manifestiert hat, besteht die Gefahr, dass dieser
Sicherheitsmechanismus (VBS) ebenso manipuliert wurde.
2.1.3 Prozesse
Ein Prozess wird wie folgt beschrieben: „… a process is a container for a set of
resources used when executing the instance of the program.” (siehe [2], S. 8).
Diese Ressourcen sind: privater Speicher, ein ausführbares Programm, eine Liste
von offenen „handles“, ein Sicherheitskontext, eine Prozess-ID und zu mindestens
ein „Thread“. Ein Administrator kann viele verschiedene Operationen mit diesen
Prozessen ausführen (beispielsweise das Lesen des Prozessspeichers oder das
Anhalten von Threads), allerdings erweist sich das im Bereich „Digital Rights
Management“ für die Medienindustrie als hinderlich. Um diese digitalen Inhalte zu
schützen, wurden „Protected Processes“ eingeführt. Diese können von jeder User-
10
Mode Applikation erstellt werden, sofern diese mit dem speziellen „Windows Media
Certificate“ ausgestattet sind (siehe [2], S. 113).
Mit Windows 8.1 wurde begonnen, das beschriebene Modell zu adaptieren und für
Zwecke abseits des Digital Rights Management zu nutzen. Daher wurde „Protected
Process Light“ (PPL) eingeführt. Diese Prozesse sind genauso geschützt wie die
„Protected Processes“, mit dem Unterschied, dass anhand unterschiedlicher
Zertifikate, verschiedene Zugriffsschutzstufen gültig sind. Eine vollständige Tabelle
findet sich auf [2], S. 115. Nachfolgend werden die Signaturen mit dem höchsten
Zugriffsschutz abfallend benannt:
• „WinSystem“
• „WinTcb“
• „Windows”
• „Lsa“
• „Anti-malware”
• „Authenticode“
• „None“.
Das „Windows Media Certificate“ ist dann nicht mehr notwendig, dafür wurde die
„Code Integrity“ von Microsoft um zwei spezielle „Enhanced Key Usage“ (EKU)
erweitert. Damit wird sichergestellt, dass sich Malware nicht selbst als geschützten
Prozess starten kann [7].
Unabhängig davon gibt es noch das Modell des „minimal processes“, das sich im
Wesentlichen dadurch unterscheidet, da es keinen User-Mode Speicher hat. Die
Prozesse „system process“ und „memory compression process“ sind „minimal
processes“ (siehe [2], S. 120).
2.1.4 Speichermanagement
Grundsätzlich ist zwischen dem virtuellen Speicher („virtual memory“) und dem
physikalischen Speicher („physical memory“) zu unterscheiden. Der physikalische
Speicher ist jener der im Computersystem hardwaretechnisch verbaut ist. Der
virtuelle Speicher wird vom implementierten „Memory Manager“ erzeugt. Das
täuscht den laufenden Prozessen einen exklusiven Speicher vor. Dabei kann der
Prozess in diesen Speicher schreiben und lesen und der „Memory Manager“
kümmert sich um die Abbildung auf den physikalischen Speicher. Jeder 64-bit
Prozess im Windows 10 glaubt, es gibt 128 TB Speicher (siehe [2], S. 21). Der
„Memory Manager“ stellt verschiedene Services zur Verfügung.
11
Abbildung 2: Speicher API (siehe [2], S. 309)
Wie in Abbildung 2 zu sehen ist, kann der „Memory Manager“ von unterschiedlichen
APIs im User-Mode angesprochen werden. Damit ein User-Mode Prozess nicht
einen anderen User-Mode Prozess bzw. das Betriebssystem selbst beeinflussen
kann, schützt Windows den Speicher mit vier verschiedenen Implementierungen
(siehe [2], S. 317).
Der erste Schutzmechanismus ist, dass der Zugriff auf die systemweiten
Komponenten nur im Kernel-Mode gestattet ist. Der zweite Mechanismus ist, dass
jeder Prozess seinen „private address space“ zur Verfügung hat und dieser für
andere Prozesse nicht einsehbar ist. Ein weiterer Mechanismus ist, dass die
unterstützten Prozessoren einen hardwarekontrollierten Schutz bieten. Als
Beispiele seien hier „PAGE_READONLY“ oder „PAGE_TARGETS_INVALID“
angeführt. Welche konkreten Attribute hier zur Verfügung stehen, hängt vom
Prozessor ab. Der vierte Mechanismus ist, dass „shared memory section objects“
mit Windows Access Control Lists (ACLs) ausgestattet sind. Daher werden bei
jedem Zugriff die Berechtigungen des jeweiligen Prozesses, der den Zugriff
durchführt, überprüft.
2.1.5 Zusammenfassung
Die in dem Kapitel 2.1 vorgestellten Mechanismen sind im Betriebssystem
verankert. Dessen Existenz ist im Optimalfall komplett transparent und wirkt sich
nicht auf die Verwendung des Betriebssystems aus. Diese Mechanismen sind
allerdings eine wichtige Grundlage um bereits auf dieser „low-level“-Ebene einen
Schutz zu bieten. Wesentlich ist dabei das Modell von VBS, welches die Grundlage
für einige nachfolgende Sicherheitskomponenten bildet.
3. WINDOWS SICHERHEIT
Verschiedene Komponenten sind für die Windows Sicherheit im Betriebssystem
implementiert. Die wichtigsten Sicherheitskomponenten werden in der folgenden
Tabelle zusammengefasst.
12
Komponente Beschreibung
„Security Reference Monitor“ (SRM) Die Komponente (in Ntoskrnl.exe) ist
zuständig für Zugriffsdatenstrukturen
um den Security Kontext zu
repräsentieren. Zu den Aufgaben
zählen zusätzlich die
Zugriffsprüfungen als auch das
Manipulieren von Privilegien.
„Local Security Authority Subsystem Die Lsasrv.dll implementiert die
Service” (Lsass) Funktionalitäten der
Passwortrichtlinien oder welcher
Benutzer am Computer angemeldet
ist. Lsass ist besonders
schützenswert, da in dieser
Komponente auch die User-
Authentifizierung integriert ist.
LSAIso.exe Wird von Lsass verwendet und ist als
„Windows Defender Credential Guard“
bekannt. Damit werden die Hashes
vom Benutzer sicher in VTL 1
abgelegt.
Lsass “policy database” Die Datenbank enthält die “local
system security policy settings“ und ist
in der Registry unter
HKEY_LOCAL_MACHINE\SECURITY
abgelegt. Diese beinhaltet welcher
Login (Interaktiv, Netzwerk und
Dienste) mit welchem Benutzer
durchgeführt werden darf. Zusätzlich
werden „cached domain logons“
gespeichert.
“Security Accounts Manager” (SAM) SAM verwaltet die SAM Datenbank
und beinhaltet die Benutzer und
Gruppen die auf der lokalen Maschine
definiert sind.
SAM Datenbank Die SAM Datenbank beinhaltet lokale
Benutzer samt Passwörtern. Die
Datenbank ist unter
HKEY_LOCAL_MASCHINE\SAM
gespeichert.
Active Directory (AD) Das AD beinhaltet diverse Passwörter
und Privilegien der Domäne.
“Authentication packages” “Authentication packages” sind DLLs
die im Lsass Prozess verwendet
13
werden, um Username und Passwort
zu überprüfen. Bei Erfolg, wird ein
entsprechender Token des Lsass
Prozesses generiert.
“Interactive logon manager” Ist für die interaktiven Logons
(Winlogon) zuständig.
“Logon user interface” (LogonUI) Ist das Interface für den Logon und
wird mittels „credential providers“
umgesetzt.
“Credential providers” (CPs) Ist für die Authentifizierung durch
unterschiedliche Möglichkeiten
(beispielsweise: „Smartcard“ oder
„Fingerprint) zuständig.
“Network logon service” (Netlogon) Ist für die sichere Kommunikation zu
dem „Domain Controller“ zuständig.
Netlogon.dll ist in einem Standard
Service (SvcHost) abgebildet.
“Kernel Security Device Driver” Ist ein Kernel-Modul mit der
(KSecDD) Implementierung für „advanced local
procedure call” (ALPC). Dies wird
beispielsweise für „Encrypting File
System“ (EFS) benötigt.
“AppLocker” Dieser Mechanismus erlaubt nur vom
Administrator vorgegebene
ausführbare Dateien. AppLocker
besteht aus einem Treiber (AppId.sys)
und einem Service (AppIdSvc.dll) und
ist in einem Standard Service
(SvcHost) abgebildet.
Tabelle 2: Windows Sicherheitskomponenten (siehe [2], S. 608)
3.1 Integrierte Sicherheitsmechanismen

3.1.1 Security identifiers
Entitäten werden über „Security Identifiers“ (SID) eindeutig identifiziert. Winlogon
erstellt bei jedem erstmaligen Login eine SID. Diese SID wird verwendet, um die
Zugriffskontrollen zu prüfen. SID sind 48 Bit lang und haben einen variablen 32 Bit
Anteil. Es gibt einige vordefinierte SIDs, die bei jedem System gleich sind [8].
3.1.2 Integritätslevel
Integritätslevel ist ein wichtiges Konzept für die Berechtigungsstruktur (siehe [2], S.
628). Integritätslevel ermöglichen eine Isolierung innerhalb eines Benutzerkontos.
Die verschiedenen „level“ sind: „Untrusted“ (0), „Low“ (1), „Medium“ (2), „High“ (3),
„System“ (4) und „Protected“ (5). Jeder Prozess hat ein Integritätslevel und dieses
14
ist im Token abgebildet. Die Integrität wird normalerweise über den Elternprozess
vererbt. Die beschriebenen Integritätslevel sind für Prozesse, während es für
Objekte eine Struktur mit dem Namen „mandatory label“ (siehe [2], S. 630) gibt.
Dabei gibt es drei verschiedene Richtlinien für die Objekte. „No-Write-Up“ stellt
sicher, dass nicht von einem niedrigeren Integritätslevel geschrieben werden kann.
„No-Read-Up“ ist das Lese-Äquivalent zu „No-Write-Up”. „No-Execute-Up” ist für
Objekte, die COM-Klassen implementiert haben, und beschränkt die Ausführung
eines niedrigeren Integritätslevels.
3.1.3 Tokens
Tokens werden verwendet um den Security Kontext in Prozessen und Threads zu
repräsentieren (siehe [2], S. 634). Lsass erstellt einen initialen Token für den
angemeldeten Benutzer. Dabei wird überprüft ob dieser Benutzer in einer
privilegierten Gruppe ist oder ein Privileg hat. Ob auf ein Objekt zugegriffen werden
kann, entscheiden zwei Mechanismen. Der erste Mechanismus ist die Benutzer-
SID des Tokens und der zweite Mechanismus ist das „privilege array“ in dem
Token. Es ist auch möglich „restricted tokens“ zu erzeugen. Das dient
hauptsächlich dazu, die Privilegien zu bearbeiten, um unsicheren Code, Privilegien
zu erlauben ohne überflüssige Privilegien zu vergeben (siehe [2], S. 644).
3.1.4 Impersonation
„Impersonation“ ist ein Windows Feature, um die Berechtigungen eines Benutzers
zu übernehmen (siehe [2], S. 642). Als Beispiel sei hier angeführt, dass ein
Benutzer eine Datei auf einem New Technology File System (NTFS) Share löschen
möchte. In dieser Client- und Server-Architektur müsste der Server die SID des
Clients abfragen und dann die Berechtigungen der lokalen Datei prüfen, um zu
wissen, ob der Client die Datei löschen darf. Dieser Ansatz ist fehleranfällig und
unzuverlässig, daher die „Impersonation“. Dabei übernimmt der Server das
Sicherheitsprofil des Clients. Ab diesem Zeitpunkt kann der Server als „Client“
agieren und die Abfrage durchführen. Nach der jeweiligen Operation wird das
Sicherheitsprofil wieder zurückgesetzt.
3.1.5 Account Rights, Privileges und Super privileges
Die Funktion LsaLogonUser ist zuständig dafür, dass die „Account Rights“
angewendet werden (siehe [2], S. 668). Beispielsweise ist es möglich, dem
Benutzer zu verbieten, sich lokal auf einer Maschine anzumelden. „Privileges“
werden von der Local Security Authority (LSA) erzwungen und angewendet (siehe
[2], S. 670). Im Betriebssystem gibt es einige vordefinierte „Privileges“, die alle im
Software Development Kit (SDK) definiert sind und mit „SE_“ beginnen. „Privileges“
werden im Token gespeichert und können aktiviert oder deaktiviert sein. „Super
privileges“ sind mächtige „Privileges“, da diese Privilegien Zugriff auf Ressourcen
ermöglichen, die für diesen Benutzerkontext verboten wären. Ein Beispiel für ein
„Super Priviliege“ wäre SeTakeOwnershipPrivilege. Damit kann der Besitzer
von jedem Objekt manipuliert werden (siehe [2], S. 676). Wenn der Benutzer seine
SID in das Besitzer-Feld schreibt, können dadurch auch die Berechtigungen der
Datei geändert werden und beispielsweise für genau diesen Benutzer einen
Vollzugriff vergeben. Zusammengefasst kann also ein Benutzer, der auf diese Datei
keinen Zugriff hat, aufgrund des „Super Privilege“ das Besitzer-Feld überschreiben
und die gewünschten ACLs vergeben.
15
3.1.6 User Account Control
Die „User Account Control“ (UAC) führt eine strikte Trennung zwischen normalen
Benutzerrechten und Administrationsrechten durch (siehe [2], S. 722). Mit
Windows Vista wurde dieses Feature implementiert und aktiv geschalten. Die
UAC führt dazu, dass bei Änderungen von Systemeinstellungen oder dem
Schreiben in administrativen Pfaden ein Popup-Fenster mit der Bestätigung bzw.
Eingabe eines privilegierten Benutzers kam. Vor Windows Vista war ein
Standardbenutzer auch gleichzeitig immer Administrator und die Software, die
geschrieben wurde, ging davon aus, dass sie mit diesen Rechten ausgeführt wird.
Das hatte zur Folge, dass eine User-Mode Applikation ohne Probleme in das
Verzeichnis %programfiles% schreiben konnte. UAC ermöglichte, obwohl der
Benutzer als Administrator angemeldet war, dass die Applikationen mit
Userrechten ausgeführt wurde. Diese Einschränkung hatte zur Folge, dass viele
Applikationen nicht mehr ordnungsgemäß funktionierten, da diese in Bereiche
schreiben wollten in die ein normaler Benutzer nicht schreiben darf.
Die Lösung dafür, war eine Implementierung von „File System and registry
virtualization“. Sobald ein Prozess virtualisiert ist, kann dieser Prozess versuchen
die Datei %windir%\data.dat zu schreiben. Allerdings wird dieser Schreibversuch
umgeleitet auf %localappdata%\VirtualStore\Windows\data.dat. Das gleiche
Prinzip gibt es für die Registry auch und funktioniert von der Idee her ident. Es
gibt sieben Gründe, warum ein Prozess nicht virtualisiert wird (siehe [2], S. 723).
Die zwei wichtigsten in diesem Kontext sind, dass 64-bit Applikationen nicht
virtualisiert werden und wenn diese bereits mit Administrationsrechten laufen. Die
UAC ist auf vier Stufen konfigurierbar (siehe [2], S. 734). Zusammengefasst ist
der Unterschied ob die UAC aktiviert ist und falls dem so ist, ob die „elevation“
bzw. „elevation prompt“ auf einem „Secure“-Desktop oder „normal“-Desktop
erscheint.
3.1.7 Trusted Platform Module
„Trusted Platform Module“ (TPM) ist ein sicherer Mikrocontroller mit
kryptografischen Funktionalitäten [9]. Ein Zugriff außerhalb des TPMs ist nur mit
den definierten Schnittstellen möglich, um die kryptografischen Funktionen und
Geheimnisse zu schützen. Eine wichtige Eigenschaft ist, dass diese Geheimnisse,
die das TPM speichert, hardwaretechnisch an das physische TPM gebunden sind
und diese Geheimnisse daher auch nie das TPM Modul verlassen können. Es ist
möglich, TPM Module zu virtualisieren (vTPM) um diese beispielsweise in virtuellen
Maschinen zu nutzen. Die genaue technische Umsetzung ist allerdings vom
Hypervisor abhängig.
3.1.8 Antimalware Scan Interface
„Antimalware Scan Interface“ (AMSI) ermöglicht es Skript-basierende Angriffe zu
erkennen und zu blocken [10]. Alle Applikationen können AMSI benutzen, um
vorher zu prüfen, ob das ausführende Skript sicherheitsbedenklich ist oder nicht.
Das Konzept ist, dass der Inhalt unabhängig von den Verschleierungsmethoden
(oft in Dateien) unverschleiert an die „Script-Engine“ weitergereicht wird, damit die
„Script-Engine“ diesen auch verarbeiten kann. Exakt in dieser Verbindung kann
AMSI verwendet werden, um den Inhalt zu prüfen. Damit wird der Angriffsvektor für
dateibasierende Attacken als auch „fileless“-Attacken minimiert [11].
16
3.1.9 Bootvorgang sichern
Microsoft stellt vier Sicherheitsmechanismen zur Verfügung um den Bootvorgang
abzusichern [12]. Dabei geht es vor allem darum, sich vor Rootkits zu schützen, die
aktiv sind bevor das Betriebssystem gestartet wird.
Abbildung 3: Boot Schutzmechanismen [12]
17
In Abbildung 3 wird dargestellt, welche Komponenten aufgrund des sicheren
Startvorgangs geschützt sind und welche potentiellen Angriffe nicht mehr
funktionieren. Die Phasen werden in den folgenden Kapiteln näher erläutert.
3.1.9.1 Secure Boot
Der Bootloader lädt das Betriebssystem, wobei der Bootloader nicht wissen kann
ob das Betriebssystem valide ist oder ob beispielsweise gerade ein Rootkit geladen
wird. Mit Unified Extensible Firmware Interface (UEFI) ist es möglich zu prüfen, ob
die Firmware digital signiert wurde. Wenn „Secure Boot“ aktiviert ist, lädt die
Firmware den Bootloader nur wenn dieser digital signiert ist oder die digitale
Signatur des Benutzers vom Bootloader akzeptiert wird. „Secure Boot“ ist eine
notwendige Grundlage um die Funktionalität von VBS (siehe Kapitel User-Mode /
Kernel-Mode2.1.2) sicherzustellen.
3.1.9.2 Trusted Boot
Der Bootloader, der in der „Secure Boot“ Phase für integer befunden worden ist,
lädt nun den Windows 10 Kernel. Dieser wird allerdings auch nur geladen, nachdem
die digitale Signatur des Windows 10 Kernel überprüft worden ist. Alle weiteren
Überprüfungen führt nun der Windows 10 Kernel selbst durch.
3.1.9.3 Early Launch Anti-Malware
„Early Launch Anti-Malware“ (ELAM) ist ein Treiber, der garantiert vor allen anderen
Treibern geladen wird die nicht von Microsoft selbst stammen. ELAM überprüft
diese Treiber und verifiziert ob diese vertrauenswürdig sind. Falls diese nicht
vertrauenswürdig sind, werden sie auch nicht geladen.
3.1.9.4 Measured Boot
Damit ist es möglich von externer Stelle zu prüfen ob ein Computer mit einem
Rootkit infiziert worden ist oder nicht. Dabei wird eine Liste von allen Treibern,
Bootloader und Firmware an den Server gesendet und dieser verifiziert die korrekte
Signatur.
3.1.10 Address Space Layout Randomization
Jeder Prozess hat einen virtuellen Speicher (siehe Kapitel 2.1.3). Dieser ist in
bestimmte Regionen unterteilt.
18
Abbildung 4: Speicherlayout mit „Address Space Layout Randomization“ (siehe [2], S. 366)
Wie in Abbildung 4 zu sehen, gibt es einige definierte Regionen im Speicherlayout.

Dazu zählen das „Image/Executable“, die dazugehörigen DLLs und der Heap mit
mehreren Stacks. Durch den Einsatz von „Address Space Layout Randomization“
(ASLR) ist es einem Angreifer nicht möglich bestimmte Adressen hartkodiert zu
verwenden. Für das „Executable“ wird die Adresse beim Laden berechnet. Bei
DLLs, die zwar grundsätzlich auch einen Code enthalten, aber die von einem
„Executable“ geladen werden müssen, werden die Adressen nur beim Systemstart
berechnet. Damit ist es weiterhin möglich, dass sich verschiedene Prozesse die
gleiche DLL teilen. Somit stellt der „Memory Manager“ das entsprechende „section
object“ zur Verfügung (siehe [2], S. 368). Jeder Stack von jedem Thread wird
(sofern nicht das StackRandomizationDisabled gesetzt ist) an einer anderen
Adresse abgelegt. Auch der Heap wird randomisiert, wobei der Bereich vor der
„Base address“ manuell freigegeben („deallocated“) wird, damit eine Bruteforce
Attacke eine „Access violation“ zur Folge hat (siehe [2], S. 369).
3.1.11 Control Flow Guard
Wegen der Einführung von „Data Execution Prevention“ (DEP) und „Arbitarary
Code Guard“ (ACG) sind Techniken wie „return-oriented-programming“ (ROP) oder
„jump-oriented-programming“ (JOP) als Angreifer wieder interessant geworden
(siehe [2], S. 740). Der Schutzmechanismus wird „Control Flow Guard“ (CFG)
genannt und überprüft ob die Adresse eine bekannte Funktion ist. Handelt es sich
um keine bekannte Adresse wird der ausführende Prozess terminiert. Diesen
Mechanismus gibt es sowohl für User-Mode als auch für Kernel-Mode Threads.
19
Damit CFG entsprechend angewendet wird, muss dies als Kompiler-Option
mitgegeben werden.
Abbildung 5: CFG (siehe [2], S. 749)
In Abbildung 5 wird der Ablauf des CFG dargestellt. Die Überprüfung, ob eine
Funktion valide ist oder nicht, wird mittels einer Bitmap abgebildet. In jeder 64-Bit
Applikation wird dafür 2TB virtueller Speicher reserviert. Diese Bitmap Darstellung
zeigt an, ob keine valide Funktion {0,0}, eine valide Funktion passend für die 16-
Byte Adressen {1,0} oder eine valide Funktion irgendwo innerhalb einer 16-Byte
Adresse {1,1} vorliegt. Ein selbstgeschriebener Assembly-Code macht es
notwendig davon auszugehen, dass sich nicht jede Funktion an die 16-Byte
Adressen hält, aber trotzdem valide ist. Der Ablauf funktioniert im Kernel-Mode sehr
ähnlich, wird jedoch erst mittels VBS effektiv, da zwar die CFG-Bitmaps im VTL 0
lesbar, aber nicht schreibbar sind.
3.1.12 Data Execution Prevention
„Data Execution Prevention“ (DEP) ist ein Sicherheitsmechanismus, um gezielt
Bereiche im Arbeitsspeicher als „nicht ausführbar“ zu markieren. Daher ist DEP
auch oft unter dem Namen „no-execute“ (NX) bekannt. Dabei wird ein
entsprechendes Bit gesetzt, um der CPU mitzuteilen, ob dieser Bereich ausführbar
sein darf oder nicht. Bei einem Versuch auf diesem Bereich etwas auszuführen,
meldet Windows entweder ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY im
Kernel-Mode oder STATUS_ACCESS_VIOLATION im User-Mode (siehe [2], S.
319). In einem 64-bit Betriebssystem, sind alle Prozesse (32bit und 64bit) als auch
Gerätetreiber durch DEP geschützt. Allerdings gibt es Möglichkeiten, diese
Schutzmechanismen in der ausführbaren Datei selbst zu unterbinden.
20
3.1.13 Kernel Patch Protection
Der Kernel hat Zugriff auf alles. Dementsprechend ist es auch möglich, Aufrufe in
den Kernel zu modifizieren. Schutzmechanismen können dafür allerdings ebenfalls
nur im Kernel-Mode implementiert werden und es gibt daher keine reale „security
boundary“. Nichtsdestotrotz wurden einige Überprüfungen implementiert (siehe [2],
Table 7-23). PatchGuard wird die Komponente genannt, die genau diese
Schutzmechanismen implementiert hat. HyperGuard erweitert den PatchGuard um
bestimmte Funktionalitäten und basiert auf VBS. Mit aktivem HyperGuard besteht
nun eine wirkliche „security boundary“ und macht beispielsweise eine
Verschleierung nicht mehr notwendig.
3.1.14 Zusammenhang
Viele der vorgestellten integrierten Sicherheitsmechanismen sind für den Benutzer
transparent. Die meisten müssen nicht konfiguriert werden, sondern sind bereits im
Betriebssystem inkludiert. Andere werden beispielsweise von den „Original
Equipment Manufacturers“ vorkonfiguriert, damit diese bereits beim Erhalt des
Clients funktionieren. Eine wesentliche Erkenntnis ist, dass die Absicherung des
Bootvorgangs essentiell ist. Wenn der Bootvorgang nicht abgesichert ist, können
die darauf aufbauenden Sicherheitsfunktionalitäten kompromittiert werden.
Zusätzlich gilt das „least privilege“-Prinzip, insbesondere bezogen auf (Super)-
Privilegen, da ansonsten untergeordnete Funktionalitäten wie eine ACL
ausgehebelt werden können. Bei dem Einsatz von Applikation gilt es darauf zu
achten, dass diese programmspezifische Sicherheitsmechanismen (ASLR, CFG,
DEP) unterstützen und verwenden.
3.2 Übersicht und Zusammenhang der Sicherheitskomponenten
In den nachfolgenden Kapiteln werden die unterschiedlichsten
Sicherheitskomponenten vorgestellt. Es gibt eine Vielzahl an Mechanismen, die für
die Sicherheit im Betriebssystem zuständig sind. Der Fokus liegt auf den
Sicherheitskomponenten, die in einem Unternehmensumfeld eingesetzt werden
können. Die vorgestellten Mechanismen sind größere Komponenten und verändern
in der Regel das Betriebssystemverhalten erheblich. Ebenso wichtige Maßnahmen,
die aber nicht Fokus dieser Arbeit sind, gibt es auch noch zur Härtung eines
Betriebssystems. Diese sind allerdings sehr konkret und oft nur eine Komponente
um eine Sicherheitsfunktionalität erweitert (beispielsweise UNC-Hardening). Für
die Konfiguration der Sicherheitsfeatures wird ein virtualisiertes Windows 10 in der
Version 1909 genutzt. Die Virtualisierungsplattform ist VMware Workstation 15 Pro.
Die verwendete Hardware ist ein Lenovo X1 20HQ.
Microsoft unterscheidet im Unternehmensumfeld zwischen drei Gebieten [13]:
• „Identity and access management“
• „Threat protection“
• „Information protection“.
Im Bereich „Identity and access management” [14] werden die Themen:
• „Protect derived domain credentials with Windows Defender Credential
Guard” (siehe Kapitel 3.8)
• „User Account Control” (siehe Kapitel 3.1.6)
21
behandelt. Im Rahmen von „Threat Protection“ [15] wird der gesamte Unterbereich
„Attack surface reduction“ [16] behandelt (siehe Kapitel 3.3, 3.4, 3.5, 3.9, 3.5, 3.10).
Im Bereich „Information protection“ werden die Themen:
• „BitLocker“ (siehe Kapitel 3.4)
• „Secure the Windows 10 boot process“ (siehe Kapitel 3.1.9)
• „Trusted Platform Module“ (siehe Kapitel 3.1.7)
bearbeitet.
3.3 AppLocker
AppLocker ermöglicht es, verschiedene ausführbare Dateien zu blockieren (siehe
[2], S. 757). AppLocker ist der Nachfolger der „Software Restriction Policies“ (SRP)
und wird daher an manchen Stellen (beispielsweise in der Registry) als „SRPv2“
bezeichnet. Grundsätzlich kann der AppLocker sowohl ein Whitelisting als auch ein
Blacklisting System umsetzen. Für ein sicheres System ist allerdings nur die
Whitelisting Methodik zulässig (siehe [17], Kap. 3b). Zusätzlich können die Regeln
in den „Enforced“ oder „Audit“ Modus geschalten werden. Nur im „Enforced“ Modus
werden die ausführbaren Dateien geblockt. Verschiedene ausführbare Dateien
können geblockt werden. Die Konfiguration erfolgt entweder über PowerShell oder
Gruppenrichtlinien.
Konfigurationskategorie Dateien
„Executable Rules“ .exe
.com
„Windows Installer Rules“ .mst
.msi
.msp
„Script Rules“ .js
.ps1
.vbs
.cmd
.bat
„Packaged App Rules“ .appx
„DLL Rules“ .dll
.ocx
Tabelle 3: AppLocker blockbare Dateien [18]
In Tabelle 3 werden alle blockbaren Dateien angeführt. Die „DLL Rules“ müssen
zusätzlich unter „Erweitert“ aktiviert werden, da diese als sehr „performance“-
intensiv gelten.
22
3.3.1 Funktionsweise
Die grundlegende Architektur [19] wird in Abbildung 6 dargestellt.
Abbildung 6: AppLocker Architektur [19]
Im Gegensatz zur SRP, besteht der AppLocker aus einem Kernelmodul

(APPID.SYS), welches die Sicherheit verglichen zu einem reinen User-Mode
Programm erhöht. Zusätzlich gibt es ein Service (AppIDSvc) das mittels Svchost
die appidsvc.dll hostet. Diese DLL nutzt dabei SAFER API [20]. SAFER API
liefert die Informationen, ob beispielsweise eine Datei ausführbar ist. AppLocker
blockt eine ausführbare Datei, mithilfe der Konfiguration bestehend aus:
• Erlauben / Blocken
• Benutzer / Gruppe
• Eigenschaften der Datei (Freigabe aufgrund: Pfad, Hash, digitale Signatur)
Dabei wird erst die tatsächliche Ausführung geblockt und nicht das Erzeugen des
Objektes [21].
3.3.2 Konfiguration
Im Unternehmensumfeld werden oft „Group Policy Objects“ (GPOs) verwendet um
Windows Computer zu konfigurieren. Wie bereits in Kapitel 3.2 erläutert, gibt es
vordefinierte Kategorien und nur diese können konfiguriert werden. Dabei können
auch Standardregeln erstellt werden, damit die Dateien unter %windir%,
%programfiles% und alle Dateien die vom „built-in“-Administrator ausgeführt
werden erlaubt sind. Nicht unwesentlich ist, dass die %programfiles% Variable im
AppLocker sowohl die Windows Variablen %programfiles% und
%programfiles(x86)% abdeckt. Neben dieser Konfiguration der Regeln, muss das
Service „Application Identifier“ (AppIDSvc) gestartet werden.
Der Microsoft Mitarbeiter Aaron Margosis, stellt den AaronLocker [22] zur
Verfügung. AaronLocker ist eine Zusammenstellung von Scripts, die das aktuelle
System analysieren und AppLocker Regeln zur Verfügung stellen können. Die
Standardregeln wurden auf dem Testsystem angewendet. Zusätzlich wurde
AaronLocker heruntergeladen, wobei AccessChk [23] heruntergeladen werden
muss. Dies kann manuell geschehen oder über ein entsprechendes Supportskript
23
im AaronLocker Ordner (/Support/DownloadAccesschk.ps1). Im Zuge dieser
Implementierung, soll eine nicht veränderte Windows Installation geprüft werden.
AaronLocker hilft dabei, diese Regeln mit dem PowerShell Skript Create-
Policies.ps1 (semi-)automatisiert zu erstellen. Nachdem das Skript ausgeführt
wurde, gibt es den Ordner „ScanResults“. Darin befinden sich sowohl Text-Dateien,
als auch XML-Dateien. Optional könnten nun die weiteren PowerShell-Skripte
angepasst werden, um unternehmensspezifische Besonderheiten zu
berücksichtigen. Im Ordner „Outputs“ finden sich so zwei XML-Dateien. Eine Datei
hat im Namen „Audit“ und die andere „Enforced“. Der Vorteil von diesen XML-
Dateien ist, dass sie in eine GPO importiert werden können.
Abbildung 7: Importieren der AppLocker Regelsätze von AaronLocker
Wie in Abbildung 7 zu sehen ist, wurden bei einer Standardkonfiguration 107

Regeln erzeugt und importiert.
Abbildung 8: AppLocker Regelauszug („executable“ Dateien)
In Abbildung 8 ist ein Auszug der 107 importierten Regeln zu sehen, wobei die hier
ausgewählte Kategorie den ausführbaren Dateien entspricht. Dabei finden sich
einige Regeln, die auch im Standardregelset zu finden sind (beispielsweise alle
„executable“ Dateien zu erlauben die im „Program Files“ Verzeichnis gespeichert
sind). Zusätzlich ist sowohl der Einsatz von Einschränkungen auf Usergruppen, als
auch explizite „Deny“-Regeln zu sehen. Zudem können Ausnahmen definiert
werden, so wie dies in der Regel für das Windows Verzeichnis geschehen ist. Das
ist architekturbedingt notwendig, da ein nicht privilegierter Benutzer in bestimmte
Windows Verzeichnisse schreiben können sollte.
3.3.3 Auswirkungen auf Benutzer

AppLocker wirkt sich direkt auf den Benutzer aus. Ohne AppLocker kann ein
Benutzer mit Standardrechten keine Installation durchführen, aber trotzdem
funktionieren portable ausführbare Dateien („portable Apps“). Mit einem
konfigurierten AppLocker funktionieren diese „portable Apps“ nicht mehr bzw. nur
nach expliziter Freigabe. Ein weiteres Beispiel für die Blockierung sind
Applikationen die „on-the-fly“ generiert und dann vom Benutzer heruntergeladen
24
sowie ausgeführt werden (beispielsweise von Meeting-Software wie „WebEx“ [24]
oder „Go To Meeting“ [25]).
3.3.4 Auswirkungen auf die Applikationsentwicklung
Bei der Applikationsentwicklung für Desktopapplikationen ist der Leitfaden [26] zu
befolgen. Dabei sind die Anforderungen sechs („Apps must digitally sign files and
drivers“) und zehn („Apps must install to the correct folders by default“) für eine
aktive AppLocker Konfiguration wichtig. Die Anforderung sechs beschreibt dabei
die digitale Signierung der ausführbaren Dateien. Diese digitale Signatur kann in
die AppLocker Konfiguration importiert werden. Dadurch werden alle Dateien
automatisch mit dieser digitalen Signatur erlaubt. Im Standardregelwerk werden in
der Konfiguration, die Verzeichnisse %programfiles% und %programfiles(x86)%
erlaubt. Jedes Programm, dass sich in diese Verzeichnisse installiert, ist
automatisch erlaubt. Die Installation in diese Verzeichnisse erfordert allerdings
Administrationsrechte.
3.4 BitLocker
BitLocker [27] ist eine Sicherheitsmaßnahme (Verschlüsselung) gegen Offline-
Attacken. Diese Offline-Attacken können das physische Stehlen aber auch das
Booten eines anderen Betriebssystems nutzlos machen. BitLocker kann in zwei
verschiedenen Modi operieren (siehe [28], S. 164):
• Standard
• BitLocker To Go
Standard ist der Modus für die Verschlüsselung einer Disk im System. BitLocker To
Go stellt eine Verschlüsselung für entfernbare Festplatten (USB-Sticks) zur
Verfügung. Der Fokus liegt auf dem Standard-Modus und erfüllt im Wesentlichen
zwei Aspekte (siehe [28], S. 164):
• Verschlüsselt die gesamte Windows Betriebssystem-Disk
• Verifiziert die Integrität der Boot-Komponenten
Im Folgenden werden die fünf Hauptkomponenten betrachtet, die für eine BitLocker
Verschlüsselung notwendig sind.
25
Abbildung 9: BitLocker Komponentenübersicht (siehe [28], S. 165)
Die Grundlage ist oft das TPM, das seit vielen Jahren zur Standardausstattung
eines PCs gehört. Um dieses TPM ansprechen zu können, gibt es das Kernelmodul
TPM.SYS. Der Boot-Manager greift ebenso auf das TPM zu, um einen
authentifizierten Zugriff der Disk zu ermöglichen. Der „BitLocker filter driver“
ermöglicht die „on-the-fly“ Ver- und Entschlüsselung. Das TPM base Service (TBS)
ist im Wesentlichen die User-Mode Implementierung des TPM.SYS. Das TBS stellt
unter anderem den „TPM WMI provider“ zur Verfügung, um eine entsprechende
Konfiguration vornehmen zu können. Ausgehend von dem „TPM WMI provider“
wird die TPM MMC und der „BitLocker WMI provider“ zur Verfügung gestellt.
3.4.2 Konfiguration
Es gibt verschiedene Möglichkeiten BitLocker zu aktivieren. Im
Unternehmensumfeld, wird das Aktivieren vermutlich in den Installationsprozesse
des Betriebssystems integriert, um sicherzustellen, dass bei der Auslieferung
BitLocker bereits aktiviert ist.
Abbildung 10: BitLocker Aktivierung
Im Zuge dieser Arbeit wurde der grafische Installationsmodus gewählt. Dabei sind
zwei wesentliche Angaben vorzunehmen.
Die erste Angabe ist, wo der Sicherungsschlüssel abgespeichert werden soll. Dies
kann in ein Microsoft Konto synchronisiert, als Text-Datei abgespeichert (allerdings
nicht auf der Festplatte die verschlüsselt werden soll) oder ausgedruckt werden.
26
Die zweite sicherheitsrelevante Entscheidung ist, welcher Verschlüsselungsmodus
eingesetzt werden soll. Die Standardeinstellung dazu ist der XTS-AES 128bit.
Abbildung 11: BitLocker Status des Verschlüsselungsvorgang
Mit dem Kommando manage-bde.exe -status C: kann der aktuelle Status

angezeigt werden. Wie in Abbildung 11 zu sehen ist, läuft die Verschlüsselung
noch. Sobald 100% erlangt sind, wird dieser Status im manage-bde reflektiert und
grafisch mit einem Schlosssymbol im Explorer an der entsprechenden Disk
angezeigt.
Abhängig von der BitLocker Konfiguration kann es notwendig sein, beispielsweise
beim Starten ein Passwort einzugeben. Allerdings ist es auch möglich, BitLocker
ohne Interaktionen zu konfigurieren und damit ist es für den Benutzer transparent.
Zusätzlich gibt es den Aspekt, dass ein fremdes Betriebssystem zwar gestartet
werden kann, die Daten jedoch auf der Disk nicht störungsfrei manipuliert werden
können. Ein nicht schadhaftes Szenario wäre dabei, dass das Betriebssystem
korrupt ist und Daten von der Disk gesichert werden sollen. Dieses Szenario ist
aufgrund der Verschlüsselung nicht mehr einfach durchzuführen.
Die Applikationen wissen nicht, dass die Disk verschlüsselt ist und bei Disk-
Aktivitäten werden weiterhin die bekannten APIs verwendet, um den Zugriff auf die
Disk zu ermöglichen.
3.5 Controlled Folder Access
„Controlled Folder Access” ist ein Sicherheitsmechanismus aufbauend auf
„Windows Defender Antivirus real-time protection“ [29]. Damit können Ordner vor
unerwünschten Prozessen schützen. Im vordefinierten Regelset werden vor allem
die persönlichen Ordner geschützt. Diese Sicherheitsmaßnahme soll insbesondere
vor Ransomware [30] schützen, da diese oft ohne privilegierte Rechte großen
Schaden anrichtet.
27
In [31] wird beschrieben, wie „Controlled Folder Access“ aktiviert werden kann. Der
Pfad C:\users\%username%\favorites ist im Standardregelset definiert.
Abbildung 12: Controlled Folder Access – PowerShell
Abbildung 12 zeigt den Versuch des Prozesses powershell.exe, die Datei

process.txt in dem Verzeichnis C:\users\%username%\favorites zu
speichern. Aufgrund des aktivierten „Controlled Folder Access“ wird die Datei nicht
geschrieben. In den Voraussetzungen [32] ist auch zu finden, dass „Windows
Defender Antivirus real-time protection“ aktiv sein muss. Aufgrund der wenigen
Informationen zu der Funktionsweise wird die Funktionalität analysiert.
Abbildung 13: Process Monitor - Schreibzugriff mittels PowerShell.exe
Als Analysewerkzeug wird Process Monitor verwendet. In Abbildung 13 ist das

Ereignis mit dem Schreibvorgang zu sehen. Path ist dabei die Datei, die
geschrieben werden soll. Desired Access mit Generic Write sagt, dass ein
Schreibvorgang angestrebt wird. Die Operation IRP_MJ_CREATE [33] ist das “I/O
Request Packet” (IRP) Request, allerdings ist das Result nicht SUCCESS, sondern
NAME NOT FOUND.
28
Abbildung 14: Aktivitäten Controlled Folder Access
Anschließend gibt es einige Aktivitäten von MsMpEng.exe (Windows Defender

Antimalware Service Executable). In den jeweiligen Stacks konnten nur Aktivitäten
im Kernel (ntoskrnl.exe) und im Filter Manager (FLTMGR.SYS) festgestellt
werden. Damit ist die Analyse stimmig, unter der Voraussetzung, dass die
„Windows Defender Antivirus real-time protection“ dafür zuständig ist.
Benutzer können nicht mehr beliebige Programme verwenden, um Dateien in das
Dateisystem bzw. in die „kontrollierten“ Verzeichnisse zu schreiben. Die benötigten
Prozesse müssen entsprechend freigegeben werden.
3.5.3 Auswirkung auf die Applikationsentwicklung
Die Applikationsentwicklung kann keine gesonderten Vorkehrungen treffen, da die
Funktionalität ausschließlich von der Konfiguration der Systemadministration
abhängt.
3.6 Windows Defender Application Control
„Windows Defender Application Control“ (WDAC) [34], vormals bekannt unter
„Device Guard”, schützt vor Veränderungen/Manipulationen am System selbst.
Application Control baut auf das „Windows Code Integrity Service“ bestehend aus
„Kernel-Mode Code Signing” (KMCS), „User-Mode Code Integrity“ (UMCI) und
„HyperVisor Code Integrity“ (HVCI) (siehe [2], S. 617). Die Idee bei „Application
Control“ ist dem Konzept von „AppLocker“ sehr nahe. Beides sind
Implementierungen, um „Application whitelisting“ umzusetzen. Allerdings ist WDAC
mittels VBS wesentlich robuster und tiefer im System integriert. WDAC ist jedoch
sehr strikt und durch die „Code Integrity Policy“ beschränkt. Daher ist es manchmal
notwendig, WDAC und AppLocker in Kombination einzusetzen (siehe [35],
Abschnitt „When to use both WDAC and AppLocker together“).
Kernel-Mode Signierung aktiv User-Mode Signierung aktiv

Nur signierter Code kann geladen Nur signierter User-Mode Images
werden können geladen werden
Geladener signierter Code kann nicht User-Mode Applikationen können
verändert werden nichtexistierende ausführbare Code
Pages als schreibbar definieren
Dynamisch allokierter Code ist Dynamisch allokierter Code ist
verboten verboten
29
UEFI Laufzeit Code kann nicht Alle PowerShell Skripte die
verändert werden Windows/.NET Funktionen aufrufen
können, müssen signiert sein
Nur signierter Kernel-Mode Code (Ring
0) kann ausgeführt werden
Tabelle 4: Kernel-Mode Signierung und User-Mode Signierung (siehe [2], S. 618)
Eine umfangreiche Analyse stellt das Bundesamt für Sicherheit in der
Informationstechnik (BSI) [36] zur Verfügung, wobei die wichtigsten Komponenten
und Zusammenhänge an dieser Stelle zusammengefasst werden. Die Code-
Integrität ist im Wesentlichen in den DLLs ci.dll und skci.dll implementiert.
Dabei wird (siehe [36], S. 23) zwischen den folgenden Kategorien unterschieden:
• „initalization“
• „image integrity verification“
• „miscellaneous“.
„Initalization“ beschreibt Teile der Implementierung, die zur Initialisierung und
Selbstkontrolle der Code-Integritätsfunktionalität dienen.
Die „image integrity verification“ unterscheidet zwischen „image sections“ und
„signature placement“. Der Unterschied ist, dass die „image sections“-Überprüfung
auf das Image abzielt (im Wesentlichen mit Hash-Methoden sichergestellt). Bei
„signature placement“ wird hingegen die Überprüfung der Images basierend auf
Zertifikaten durchgeführt.
Die Kategorie „miscellaneous“ enthält Funktionalitäten wie Statusabfragen oder
Hashverfahren. Die ci.dll ist im normalen Kernel (VTL 0) implementiert, während
die skci.dll im „Secure Kernel“ (VTL 1) zu finden ist. Die WDAC Initialisierung
besteht aus drei Funktionen (siehe [36], S. 27):
• OslpProcessSIPolicy
• OslpLoadAllModules
• OslBuildCodeIntegrityLoaderBlock.
Eine wichtige Aufgabe von OslpProcessSIPolicy ist es, die Integrität der
signierten WDAG Policy zu überprüfen. Nachdem die WDAG Policy überprüft und
gelesen wurde, werden alle ausführbaren Dateien mittels WDAG Policy überprüft.
Der Boot-Manager verifiziert die Integrität des Windows Loader und nach
erfolgreichem Überprüfen übergibt der Windows Loader die Funktionalität des
Überprüfens an den Kernel. Daher ist es essentiell, dass die Code-Integrität Policy
auf einem System erzeugt wird, ohne bereits befallen zu sein, da die Code-Integrität
Policy bzw. WDAG die Images nicht semantisch überprüft. Um WDAC einzusetzen,
ist es notwendig, die entsprechenden Einstellungen über Gruppenrichtlinien und
die Code-Integritätsrichtlinie (eine .p7b Datei) zu aktivieren [37]. Der Vorgang ist,
dass das System entsprechend gescannt wird und in eine XML-Datei erstellt wird.
Diese XML-Datei wird dann in ein binäres Format (.bin) umgewandelt und sie kann
30
auch in der Gruppenrichtlinie angegeben werden. Allerdings wird die Datei dann
lokal auf eine .p7b Datei konvertiert und angewendet [38].
3.6.2 Auswirkungen auf Benutzer/ die Applikationsentwicklung
Die Auswirkungen sind analog zu jenen von AppLocker (siehe Kapiteln 3.3.3 und
3.3.4). Im Gegensatz zu AppLocker ist WDAC nur auf eine ganze Maschine
anwendbar. Um für Benutzer/Benutzergruppen granulare Freigaben zu definieren,
ist weiterhin der Einsatz von AppLocker notwendig.
3.7 Windows Defender Application Guard
„Windows Defender Application Guard“ (WDAG) ist ein Sandbox Mechanismus für
den Microsoft Edge Browser [39]. Das Ziel bei einer aufgerufenen Website ist es,
diese mittels VBS zu isolieren. Dabei ist WDAG in der Standardkonfiguration als
einmaligen Container zu sehen, der nach der Browsersitzung komplett entfernt und
bei einem erneuten Aufruf neu initialisiert wird. WDAG kann entweder im
„Standalone“- oder „Enterprise-managed“-Modus verwendet werden. Im
„Standalone“-Modus muss der Benutzer selbst den Microsoft Edge mit „Application
Guard“ starten. Bei dem Modus „Enterprise-managed“ verteilt die
Systemadministration eine Liste mit vertrauenswürdigen URLs. Bei jeder neuen
URL wird überprüft, ob diese auf der Liste steht. Falls dem so ist, wird die URL
weiterhin im nicht isolierten Modus aufgerufen. Sofern die URL nicht auf der Liste
steht, wird ein „Application Guard“ Tab geöffnet.
3.7.1 Konfiguration
WDAG ist über die Windows Features installierbar. Sobald ein „Application Guard
Tab” gestartet wird, öffnet sich ein zusätzlicher Edge Browser mit einem
entsprechenden „Application Guard“ Icon.
Abbildung 15: WDAG im "Process Explorer"
Dieser „Application Guard“ Edge Browser befindet sich in einer kleinen virtuellen
Maschine. Der Browser ist daher, wie in Abbildung 15 zu sehen ist, ein spezieller
„Remote Desktop Protocol“ (RDP)-Client zu dieser virtuellen Maschine. Diese
virtuelle Maschine kann über den vmmem [40] Prozess überwacht werden.
31
3.7.2 Auswirkung auf Benutzer
In einem Unternehmensumfeld, wird WDAG vermutlich im „Enterprise-managed“-
Mode verwendet. Das kann auf den Benutzer direkte Auswirkungen haben, in dem
Dateien beispielsweise nicht mehr direkt auf dem Filesystem des Hosts gespeichert
werden können.
Abbildung 16: WDAG PDF-Download
Als Beispiel wurde ein PDF aus dem Internet auf den Desktop heruntergeladen.
Abbildung 16 zeigt dabei, dass ein spezieller Benutzer (wdagutilityaccount)
verwendet wird und nicht der eigentliche Benutzer des Systems (patrick). Dieses
PDF kann außerhalb der virtuellen Maschine auch nicht kopiert werden.
In modernen Webapplikationen ist es möglich, Dateien auf das Dateisystem
abzulegen oder eine Interaktion mit dem Betriebssystem zu ermöglichen. Abhängig
von der genauen Funktionalität können diese Komponenten/Features nicht mehr
funktionieren.
3.8 Windows Defender Credential Guard
Passwörter sind eine sicherheitskritische Komponente in einem System. In einer
Windows Systemlandschaft gibt es im Wesentlichen drei Arten von Passwörtern
(siehe [2], S. 612):
• Passwort
• „NT one-way function” (NT OWF)
• „Ticket-granting ticket“ (TGT)
Das Passwort wird verwendet, um sich als interaktiver User auf einer Maschine
anzumelden. NT OWF ist ein Hash und sollte (aufgrund des zugrundeliegenden
MD4) nicht mehr verwendet werden. Dieser Hash wird vom NT LAN (NTLM)
Manager verwendet. Das TGT ist die modernere Version von NT OWF und ergibt
sich aus dem Kerberos Protokoll. All diese Passwörter werden auf einem System
ohne „Windows Defender Credential Guard" (WDCG) oder „LSA Protection“ im
Lsass-Prozess gehalten. „LSA Protection“ [41] schützt den Lsass-Prozess gegen
User-Mode Angriffe. „LSA Protection“ schützt daher nicht gegen Angriffe aus dem
Kernel-Mode bzw. gegen Angriffe, die aufgrund von Treibern mit Sicherheitslücken,
Angriffe ermöglichen.
WDCG nutzt den VBS Mechanismus, um die Passwörter in einem Trustlet in VTL
1 (siehe Kapitel 2.1.2) zu speichern.
32
Abbildung 17: WDCG [42]
VTL 1 hat nicht den gesamten NT Kernel nochmals implementiert, sondern nur
einen geringen Funktionsumfang (siehe [2], S. 614). Durch diesen sind auch kein
I/O Zugriff und dadurch keine direkte Kommunikation mit dem Key Distribution
Center (KDC) möglich. Sobald WDCG aktiv ist, wird zusätzlich zu dem Lsass-
Prozess ein LsaIso-Prozess erzeugt. Der Lsass-Prozess dient weiterhin der
Kommunikation zur „Außenwelt“, fungiert aber im Hinblick auf die Passwörter nur
mehr als eine Art Proxy. Die Passwörter selbst sind im sicheren VTL 1 LsaIso-
Speicher und müssen vom Lsass-Prozess abgefragt werden. Diese Informationen
reicht der Lsass-Prozess dann weiter an den anfragenden Dienst.
In Kapitel 2.1.2 wird die entsprechende Trennung zwischen VTL 0 und VTL 1
beschrieben, allerdings gibt es manchmal die Notwendigkeit zwischen VTL 0 und
VTL 1 zu kommunizieren. Aus dieser Notwendigkeit ist eine Kommunikation mittels
„Advanced Local Inter-Process Communication“ (ALPC) möglich. Eine weitere
Frage ist, wenn der Lsass-Prozess als eine Art Proxy dient und die Informationen
(Passwörter) weiterleitet, kann der Lsass-Prozess dann nicht weiterhin die
Informationen lesen? Um sicherzustellen, dass der Lsass-Prozess diese
Informationen nicht lesen kann, wird die Nachricht verschlüsselt. VTL 1 erstellt
einen „Session key“. Dieser wird verschlüsselt an den KDC gesendet. Der KDC
kann die Nachrichten ebenso verschlüsselt senden. Damit bekommt der Lsass-
Prozess zwar alle Nachrichten, diese sind aber verschlüsselt und können daher
nicht eingesehen werden.
3.8.2 Konfiguration
Bevor WDCG am System konfiguriert wird, werden mit Mimikatz [43] die
Anmeldedaten des Lsass-Prozess gelesen. Dazu muss lediglich das Tool
heruntergeladen werden.
33
Abbildung 18: Anmeldedaten des Lsass-Prozesses lesen
In einer administrativen PowerShell Konsole, wird mit privilege::debug das

entsprechende Privileg angefordert um anschließend mit
sekurlsa::logonPasswords die Passwörter vom Lsass-Prozess zu lesen. Um
diese Anmeldedaten zu sichern, wird nun WDCG aktiviert [44]. Wieder gibt es
mehrere Möglichkeiten, diese zu aktivieren. Im Zuge dieser Evaluierung wird die
Methode über Gruppenrichtlinien gewählt.
34
Abbildung 19: WDCG aktiviert
Nachdem WDCG aktiviert ist und mittels Mimikatz versucht wird die Anmeldedaten
des Lsass-Prozess zu lesen, werden ausschließlich verschlüsselte Daten
ausgegeben. Der Schutz gegen diese Attacke ist daher erfolgreich.
Sicherheitstechnisch relevant ist, dass die Konfiguration (wie von Microsoft
empfohlen) mit „Enabled with UEFI Lock“ aktiviert ist, damit WDCG nicht ohne
physische Anwesenheit deaktiviert werden kann.
Auf [45] finden sich einige Erwägungen/Auswirkungen. Für den Benutzer sind
etwaige Auswirkungen, dass „Wireless Local Area Networks“ (WLANs), die auf MS-
CHAPv2 basieren, zwar verwendet werden, die Passwörter aber nicht gespeichert
werden können. Zusätzlich können die gespeicherten Anmeldedaten des Remote
Desktop Clients nicht gespeichert werden und sind nach einer Installation des
WDCG verloren. In den „Credential Manager“ gespeicherte Windows
Anmeldedaten werden mit der Installation des WDCG gelöscht. Die Applikation
sollte dann die Anmeldedaten nochmals abfragen und diese werden anschließend
sicher mit WDCG gespeichert.
Für „normale“ Applikationen hat der Einsatz des WDCG keine Auswirkungen.
Applikationen, die allerdings die Anmeldedaten verwalten möchten, können mit
dem Einsatz von WDCG nicht mehr vom Lsass-Prozess lesen [46]. Software die
als „Security Support Provider“ auftreten, können nicht bereits gespeicherte
Passwörter zwar abfragen (durch WDCG geschützt), aber neu eingegebene
können mitgelesen werden [47].
3.9 Windows Defender Exploit Guard

Windows Defender Exploit Guard (WDEG) [48] ist ein Schutzmechanismus, der
sowohl auf Prozess, als auch auf Betriebssystem-Ebene verschiedene Gefahren
unterbinden kann. WDEG ist das Nachfolgeprodukt von „Enhanced Mitigation
Experience Toolkit“ (EMET) [49]. EMET wird allerdings seit dem 31.7.2018 nicht
mehr von Microsoft unterstützt [50]. WDEG unterteilt sich in die Kategorien: „Exploit
Guard“ und „Attack Surface Reduction“ (ASR).
35
Maßnahme Systemweit Applikationsweit
anwendbar anwendbar
„Control Flow Guard“ (CFG)  
„Data Execution Prevention“ (DEP)  
„Force randomization for images“  
„Randomize memory allocations“  
„Validate exception chains“  
„Validate heap integrity“  
„Arbitrary code guard“  
„Block low integrity images“  
„Block remote images“  
„Block untrusted fonts“  
„Code integrity guard“  
„Disable extension points“  
„Disable Win32k system calls“  
„Do not allow child processes”  
„Export address filtering”  
„Import address filtering”  
„Simulate execution”  
„Validate API inovcation”  
„Validate handle usage”  
„Validate image dependency integrity”  
„Validate stack integrity”  
Tabelle 5: „Exploit Protection" [51]
Tabelle 5 fasst die aktuellen Maßnahmen zusammen [51], wobei diese bei Bedarf
(neue Angriffsmethode) von Microsoft erweitert werden können. Einige
Sicherheitsmechanismen wurden in grundlegender Funktionsweise in Kapitel 3.1
erklärt. Dazu zählen:
• „Address Space Layout Randomization“ (siehe Kapitel 3.1.10)
• CFG (siehe Kapitel 3.1.11)
• DEP (siehe Kapitel 3.1.12).
Wie bereits erwähnt, gibt es zu den „Exploit Protection“ Mechanismen auch noch
„ASR Rules“. Diese „ASR Rules“ sind spezifische Aktivitäten, die geblockt werden
können.
36
Regel GUID
„Block executable content from email client and BE9BA2D9-53EA-
webmail” 4CDC-84E5-
9B1EEEE46550
„Block all Office applications from creating child D4F940AB-401B-
processes” 4EFC-AADC-
AD5F3C50688A
„Block Office applications from creating executable 3B576869-A4EC-4529-
content” 8536-B80A7769E899
„Block Office applications from injecting code into other 75668C1F-73B5-4CF0-
processes” BB93-3ECF5CB7CC84
„Block JavaScript or VBScript from launching D3E037E1-3EB8-
downloaded executable content” 44C8-A917-
57927947596D
„Block execution of potentially obfuscated scripts” 5BEB7EFE-FD9A-
4556-801D-
275E5FFC04CC
„Block Win32 API calls from Office macro” 92E97FA1-2EDF-4476-
BDD6-
9DD0B4DDDC7B
„Block executable files from running unless they meet 01443614-cd74-433a-
a prevalence, age, or trusted list criterion“ b99e-2ecdc07bfc25
„Use advanced protection against ransomware” c1db55ab-c21a-4637-
bb3f-a12568109d35
„Block credential stealing from the Windows local 9e6c4e1f-7d60-472f-
security authority subsystem (lsass.exe)” ba1a-a39ef669e4b2
„Block process creations originating from PSExec and d1e49aac-8f56-4280-
WMI commands” b9ba-993a6d77406c
„Block untrusted and unsigned processes that run from b2b3f03d-6a65-4f7b-
USB” a9c7-1c7ef74a9ba4
„Block Office communication application from creating 26190899-1602-49e8-
child processes” 8b27-eb1d0a1ce869
„Block Adobe Reader from creating child processes” 7674ba52-37eb-4a4f-
a9a1-f0f9a1619a2c
„Block persistence through WMI event subscription” e6db77e5-3df2-4cf1-
b95a-636979351e5b
Tabelle 6: „ASR Rules" [52]
Wie anhand der Beschreibungen aus Tabelle 6 hervorgehen, werden spezifische

Aktivitäten, oft in Verbindung mit spezieller Software (wie Microsoft Office oder
Adobe Reader) unterbunden. Die GUIDs sind für die Konfiguration (über
37
Gruppenrichtlinien) notwendig. Die Idee hinter WDEG ist es verdächtige Aktivitäten
(sowohl bei „Exploit Guard“ als auch bei ASR) zu unterbinden.
Der Vorteil ist, dass viele Exploits zumindest einen dieser beschriebenen
Mechanismen verwenden und durch das Blocken, der Exploit gestoppt werden
kann, obwohl die anfällige Applikation nach wie vor eine Sicherheitslücke hat. Der
Einsatz des WDEG ist, abhängig natürlich von der jeweiligen Umgebung, nicht
einfach flächendeckend einzusetzen. Es ist durchaus möglich, dass Applikationen
(auch wenn diese keine Malware/Exploits sind) einen dieser Mechanismen nutzen.
Mit dem Einsatz von WDEG würde die nicht schadhafte Applikation nicht mehr
funktionieren. Zusätzlich ist es nicht möglich, jede Maßnahme in einen
Beobachtungsmodus zu schalten [51]. Dadurch können auch Tests vor dem
produktiven Einsatz nur teilweise erfolgen.
Der Einsatz des WDEG kann über unterschiedliche Schnittstellen erfolgen. Dabei
ist es beispielsweise möglich, mit PowerShell die entsprechenden ausführbaren
Dateien mit den verschiedenen WDEG Features zu konfigurieren. Microsoft bietet
dafür eine „Baseline“ an [53]. Dabei ist zu beachten, dass Microsoft selbst vor
Konfigurationen mit WDEG warnt und diese nur eingesetzt werden können, wenn
sie sehr oft getestet wurden. In der Version 1909 hat Microsoft die Baseline zu
WDEG aufgrund der Rückmeldungen, dass einige Applikationen mit diesen
Einstellungen inkompatibel sind, wieder entfernt.
Die Implementierung am Testsystem erfolgte mittels Scripts [54]. Die erfolgreiche
Ausführung kann durch Get-ProcessMitigation überprüft werden. Die „ASR
Rules“ haben dagegen kein PowerShell Kommando zum Überprüfen. Allerdings
kann direkt in der Registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
Defender\Windows Defender Exploit Guard\ASR\Rules nachvollzogen
werden, ob die „ASR Rules“ richtig konfiguriert sind.
Abbildung 20: „ASR Rules" in der Ereignisanzeige
38
Die praktische Überprüfung erfolgt mittels psexec.exe und dem Aufruf einer
cmd.exe. Dabei zeigt Abbildung 20, dass der WDEG diesen Aufruf erfolgreich
erkennen und blocken würde.
Wenn WDEG eingeschalten ist, können diverse Applikationen nicht mehr
funktionieren (meist wird die Reaktion ein Absturz der Applikation sein). Zusätzlich
ist zu bedenken, dass diese Mechanismen dann auch nicht mehr verwendet
werden können, selbst wenn die Applikation keine Schadsoftware ist.
Die meisten Maßnahmen die WDEG blockt, sollten in einem modernen Programm
nicht implementiert sein. Allerdings neigen gerade ältere Applikationen dazu,
gewisse Regeln, die erst durch die Sicherheitsmechanismen aktuell sind, zu
brechen. Für die Applikationsentwicklung gilt [26], insbesondere in diesem
Zusammenhang, das Kapitel „Apps support Windows security features“.
3.10 Windows Defender Firewall

Windows Defender Firewall enthält neben den klassischen Funktionalitäten (Paket
Filter) auch Features wie Firewall Profile und „Connection security rules“ (siehe
[55], Modul 12). Wenn ein Windows Gerät einem Netzwerk hinzugefügt wird, kann
ausgewählt werden, in welcher Netzwerkumgebung es sich befindet (Domäne,
Privat oder Gast).
Diese Netzwerkprofile werden auch in Firewallprofilen abgebildet. Daher ist es
möglich, für jedes Netzwerkprofil ein Firewallregelset zu erstellen. Aufbauend auf
den jeweiligen Profilen, können Firewallregeln erstellt werden, die grundsätzlich in
Eingehende und Ausgehende unterteilt werden. Diese Regeln können aufgrund
verschiedener Eigenschaften fein granuliert werden, beispielsweise durch das
betroffene „executable“, den Port oder IP-Adressen.
Die Windows Defender Firewall unterstützt auch IPsec [56]. IPsec wird über
„Connection security rules“ definiert und ermöglicht eine weitere Granulierung der
eingehenden bzw. ausgehenden Firewallregeln. Die IPsec Authentifizierung kann
über Kerberos, NTLMv2, Zertifikat oder „Preshared Key“ erfolgen.
Die Firewallregeln wurden wie in der Online-Referenz [57] implementiert. Dabei
wurden die Regeln über die lokalen Gruppenrichtlinien konfiguriert. Das Regelset
wurde im binären Format exportiert und zwecks Reproduzierbarkeit zur Verfügung
gestellt [58].
Die Windows Defender Firewall hat ein Service und beinhaltet folgendes:
C:\Windows\system32\svchost.exe -k
LocalServiceNoNetworkFirewall -p. Mittels ProcessHacker [59] lässt sich
feststellen, dass die folgenden DLLs in das Service gemappt sind:
FirewallAPI.dll, fwbase.dll und fwpolicyiomgr.dll.
39
Abbildung 21: Windows Defender Firewall Service
Abbildung 21 zeigt die Abhängigkeiten des Services „Windows Defender Firewall“.

Dabei ist eine wesentliche Komponente das Service „Base Filtering Engine“, das
für IPSec und „Firewall management“ zuständig ist. Des Weiteren ist „Windows
Defender Firewall Authorization Driver“ der Treiber (Kernel-Mode) für die „Windows
Defender Firewall“ und ist in der mpsdrv.sys implementiert.
3.10.2 Auswirkung auf Benutzer
Sofern die Applikationen auf der Host Firewall entsprechend freigeschalten sind,
sollte der Benutzer keine Einschränkung erfahren. Dabei sind auch ausgehende
Verbindungen per Standard erlaubt und bieten daher eine gewisse Flexibilität.
3.10.3 Auswirkung auf die Applikationsentwicklung
Wenn eine Applikation entwickelt wird, besteht diese bei beteiligter
Netzwerkkommunikation oft aus einer Server-Client Komponente. Dabei ist zu
beachten, dass der Client die Kommunikation zum Server aufbaut (eine
ausgehende Verbindung) und nicht umgekehrt der Server zum Client. Eingehende
Verbindungen werden per Standard geblockt, ausgehende Verbindungen sind
hingegen per Standard erlaubt (in der Annahme, dass der Client grundsätzlich
Services anfordert, die benötigt werden). Zusätzlich sollte bei den konkret
verwendeten Firewallregelsets darauf geachtet werden, dass auch die Server die
entsprechenden Cipher/Algorithmen unterstützen, da ansonsten die zwei
Maschinen nicht miteinander kommunizieren können.
4. ELASTIC STACK
Elastic [60] ist ein Unternehmen mit unterschiedlichen Softwareprodukten. Der
Elastic Stack besteht aus den beiden Produkten Elasticsearch [61] und Kibana [62].
Die Hauptprodukte bestehen aus dem Elastic Stack, Logstash [63] und den
unterschiedlichen Beats [64]. Das Ziel der Softwaresuite (in dem Kontext dieser
Arbeit) ist es, Logdateien in unterschiedlichen Formaten zu zentralisieren,
aufzubereiten und dann eine Analyse mit grafischer Aufbereitung zu ermöglichen.
40
Abbildung 22: Elastic Architektur (siehe [65], „Chapter 1: Introduction to Data Driven Architecture”)
Abbildung 22 zeigt die Architektur der Hauptprodukte. Die Elasticsearch

Komponente beinhaltet alle Daten, die von den Beats bzw. Logstash geliefert
werden.
Logstash ist eine Möglichkeit, die Daten vorab zu manipulieren. Ein Beispiel für
Logstash wäre, dass die IP-Adressen in dem Logfile mit der geografischen Lokation
ergänzt werden.
Beats sind Agents, die Daten von den jeweiligen Maschinen an Logstash oder an
Elasticsearch senden. Es gibt unterschiedliche Beats für unterschiedliche
Anwendungsfälle. Winlogbeat [66] wäre ein Beispiel für einen Beat, der die Daten
vom Windows Event-log weiterleitet.
Kibana ist eine Weboberfläche, die die Daten von Elasticsearch grafisch aufbereitet
und als Analysewerkzeug dient. X-pack in der Elasticsearch und Kibana-
Komponente bedeutet, dass es in diesen Komponenten kostenpflichtige Features
gibt. Diese werden im Zuge dieser Arbeit allerdings nicht verwendet.
4.1 Security Information and Event Management
Ein SIEM [67] sammelt Daten aus unterschiedlichen Quellen, normalisiert diese
und analysiert sie auf sicherheitsrelevante Events. Um zeitgerecht auf diese
sicherheitskritischen Events reagieren zu können, ist eine Alarmierung oft ebenfalls
Bestandteil des SIEMs. Ein SIEM bietet generell folgende Dienste (siehe [67], S.
28):
• „Log management“
• „IT regulatory compliance“
41
• „Event correlation”
• „Active response”
• „Endpoint security”.
„Log management“ beinhaltet das Sammeln von relevanten System- und
Applikationsereignissen („Events“). Je mehr Systeme in das SIEM eingebunden
sind, desto vollständiger ist die Datengrundlage. In der Regel wird mit den
besonders sicherheitskritischen Systemen (beispielsweise Firewall) begonnen.
Neben dem Zentralisieren übernimmt die SIEM auch die Organisation, Archivierung
und Normalisierung der Daten.
„IT regulatory compliance“, beschreibt das Filtern der empfangenen Daten, um die
„Compliance“ zu prüfen bzw. sicherzustellen. SIEM Hersteller bieten meistens
vorgefertigte Richtlinien an, die anhand der Logdateien geprüft werden können. Ein
Beispiel für solch eine Richtlinie wären die fehlgeschlagenen Installationen der
Sicherheitspatches. Zusätzlich können, angepasst an das Unternehmen und die
jeweiligen Bedürfnisse, eigene Regeln erstellt werden, um diese gegenüber der
vorhandenen Datenbasis zu prüfen.
„Event Correlation“ sorgt zu mindest für ein Teilbild gegenüber einem Szenario.
Einzelne Events sind in einem großen System meist schwer zu interpretieren. Die
Korrelation bildet eine Gesamtsicht auf die Situation und ermöglicht eine sinnvolle
Analyse der Events. Als Beispiel sei hier ein ausgefallenes System herangezogen.
Der Ausfall eines Systems kann viele Gründe haben und nur eine Teilmenge davon
ist sicherheitsrelevant. Eine Analyse des Einzelevents könnte ergeben, dass die
Maschine aufgrund eines „BlueScreen of Death“ (BSOD) nicht mehr erreichbar ist.
Die Event Korrelation könnte zeigen, dass bereits 30 Minuten vor diesem Absturz
eine ungewöhnlich hohe Menge an Netzwerkverkehr mit einem bestimmten Client
vorausging. Das könnte darauf hindeuten, dass ein sicherheitsrelevanter Angriff auf
das System erfolgt ist. Eine Event Korrelation, abhängig von der Datenbasis, würde
auch andere Aspekte aufzeigen.
„Active Response“ ist die Möglichkeit, dass das SIEM selbstständig Aktionen
durchführt. Aufgrund der Datenbasis, die gefiltert und analysiert bzw. korreliert wird,
kann das SIEM mithilfe der definierten Regeln, potentielle Gefahren erkennen und
Aktionen (beispielsweise das Setzen von ACLs) ausführen.
„Endpoint Security“ bedeutet, dass die SIEM oft eine Intelligenz bezüglich „Endpoint
Security“-Produkten mitbringt und beispielsweise auf den Aktualitätsstand der
Definitionsupdates zugreifen kann. SIEMs sind daher ein komplexes Werkzeug in
einer IT-Infrastruktur und erfordern viel Engagement. Dies wird auch in der
Referenz [67], S. 74 beschrieben: „It takes an enormous amount of effort to create
a fully featured SIEM.”.
4.2 Implementierung
Als Testsystem wird Lenovo X1 2017 (20HQS03P00) und als Hypervisor VMware
Workstation 15 Pro eingesetzt. Die virtuellen Maschinen sind in Tabelle 7 mit den
entsprechenden Konfigurationen beschrieben:
42
Computername Betriebssystem CPU RAM Rolle
winclient Windows 10 2 vCPU 4GB Gehärtetes
1909 System + Beats
winsrv Windows Server 2 vCPU 4GB Elastic Stack
2019
Tabelle 7: Testumgebung virtueller Maschinen
Für den winclient sind gesonderte Konfigurationen notwendig, damit die

Sicherheitskomponenten funktionieren. Dabei ist es wichtig, dass der virtuellen
Maschine im VMware Management zusätzlich eine TPM Komponente hinzugefügt
wird. Damit diese TPM Komponente genutzt werden kann, muss die virtuelle
Maschine im VMware Management verschlüsselt werden. In den erweiterten
Einstellungen der virtuellen Maschine ist Enabling VBS, will also enable
UEFI, secure boot, Intel VT-x/EPT and IOMMU und bei Firmware Typ
UEFI mit Enable secure boot zu konfigurieren.
4.2.1 Konfiguration des Elastic Stacks
Der Elastic Stack wird auf dem Windows Server 2019 installiert. Dabei werden die
Installationsquellen von Elastic heruntergeladen und wie in den Dokumentationen
konfiguriert [68]. Für die Elasticsearch Konfiguration ist elasticsearch.yml und
für Kibana kibana.yml zuständig. In der Elasticsearch Konfiguration müssen die
folgenden Parameter korrekt gesetzt werden, damit der Elasticsearch Server über
das Netzwerk erreichbar ist: network.host, discovery.seed_hosts und
cluster.initial_master_nodes. In der Kibana Konfiguration müssen
folgende Parameter definiert werden, um die Verfügbarkeit im Netzwerk und die
Kommunikation mit dem Elasticsearch Server zu ermöglichen: server.host und
elasticsearch.hosts.
4.2.2 Sichere Konfiguration des Elastic Stacks
Ab der Elasticsearch Version 7.1.0 sind grundlegende Sicherheitsfeatures in der
kostenlosen Version inkludiert [69]. Sowohl Elasticsearch als auch Kibana werden
mit „Hypertext Transfer Protocol Secure“ (HTTPS) und User Authentifizierung
abgesichert [70] [71] [72].
Abbildung 23: Elastic Stack sichere Kommunikation
Abbildung 23 zeigt die aktuelle Elastic Konfiguration in der Testumgebung. Für die
sichere HTTP Verbindung wurden selbst signierte Zertifikate verwendet. Für die
43
Authentifizierung der Benutzer liegt eine entsprechend ausführbare Datei von
Elastic bei, um diese anzulegen und ein Passwort zu vergeben. Zusätzlich wurde
eine Windows Firewall am Windows Server 2019 konfiguriert, damit der Zugriff
weiter eingeschränkt ist.
4.2.3 Einbindung des Windows 10 Clients

Beats (siehe Kapitel 4) liefern die Daten zum Elastic Stack. Es gibt viele
unterschiedliche Beats für die unterschiedlichen Anwendungsbereiche. Für den
Windows Logfile Transfer bietet sich winlogbeat an. Dieser Beat kann nativ
Windows Events lesen und sendet diese aufbereitet an den Elastic Stack. In der
Winlogbeat Konfiguration werden die Sicherheits- und Sysmonlogs (siehe Kapitel
4.2.3.2) definiert, um diese an den Elastic Stack zu übertragen.
4.2.3.1 Windows Events
Windows Event-log [73] gibt es seit Windows Vista und ist ein Teil der „Event
Tracing for Windows“ (ETW) API. ETW besteht aus drei Komponenten [74]:
• „Controllers“
• „Providers“
• „Consumers“.
Abbildung 24: Event Tracing [74]
Abbildung 24 zeigt den Zusammenhang zwischen den drei Komponenten. Die

„Provider“ stellen Events zur Verfügung, die „Consumers“ können diese Events
konsumieren. Ein „Provider“ registriert einen Namen mit einer GUID und benennt
Events.
Die „Controllers“ sind zuständig für eine „Event tracing sessions“. Diese Sitzung ist
notwendig und stellt den Buffer bereit, wodurch die „Provider“ Events entsprechend
44
senden und die „Consumers“ sie konsumieren können. Jedes Event hat
vordefinierte Felder, die benutzt werden sollten, um das Event zu beschreiben. Die
vordefinierten Felder sind:
• ID
• „Keyword“
• „Severity level“
• „Task“
• „Opcode“.
Die Event IDs repräsentieren einen bestimmten Status innerhalb eines Providers.
Die Kombination des Providers (GUID) mit der ID ist eindeutig. „Keywords“ sind in
einer 64-bit Maske spezifiziert und beschreiben eine Subkomponente innerhalb
eines Providers. „Severity level“ definiert den Detailgrad des Providers. Die Levels
sind vordefiniert [75] und reichen von „Verbose“ bis „LogAlways“.
„Tasks“ identifizieren eine Übermenge von Subkomponenten innerhalb eines
Providers. Die „Tasks“ sind als 16-bit Wert definiert und werden meist gemeinsam
mit dem „Opcode“ betrachtet. „Opcode“ ist ein 8-bit Wert, der die ausführende
Operation der Subkomponente beschreibt.
4.2.3.2 Sysmon
Die von Microsoft zur Verfügung gestellten Events sind beschränkt und beziehen
sich oft auf das nicht-interaktive Systemverhalten. Sysmon [76] ist ein Tool der
Sysinternals-Suite die es ermöglicht, verschiedene Aktivitäten zu protokollieren.
Die Protokollierung findet in dem Event-log statt, wodurch eine Übermittlung mittels
winlogbeat möglich ist. Sysmon selbst besteht aus einem Boot-Treiber und
installiert sich als Windows Service. Die generierten Events finden sich im
Eventviewer unter Applications and Services
Logs/Microsoft/Windows/Sysmon/Operational.
Sysmon unterstützt dabei die folgenden Hashes: SHA1, MD5, SHA256 und
IMPHASH. IMPHASH [77] extrahiert die geladenen Module und bildet dadurch
Hashwerte. Abhängig von der Änderung der Malware kann diese zwar selbst einen
anderen beispielsweise SHA256 Wert haben, allerdings bleibt der IMPHASH ident.
Event-ID Funktion Beschreibung
1 Prozesserstellung Neu erzeugte Prozesse werden
inklusiver kompletter Command-Line
aufgezeichnet.
2 Ein Prozess ändert den Manipuliert den Zeitstempel für die
Erstellungszeitstempel einer Erstellung einer Datei.
Datei
3 Netzwerkverbindung Zeichnet die Netzwerkverbindung auf
(Quelle und Ziel) inkl. Prozess-ID.
4 Sysmon Service Status Dieses Event wird generiert, wenn
ändert sich das Sysmon Service gestoppt oder
gestartet wird.
5 Prozessterminierung Verstorbene Prozesse werden inkl.
Zeit und Prozess-ID aufgezeichnet.
45
6 Treiber wurde geladen Wenn ein Treiber im System geladen
wird, wird dies aufgezeichnet. Falls
die Datei nach dem Laden gelöscht
wird, wird das ebenfalls
aufgezeichnet.
7 Module wurde geladen Wenn ein Modul innerhalb eines
Prozesses geladen wird, erfolgt eine
Aufzeichnung.
8 „Remote Thread“ wird Dieses Event beschreibt den
erzeugt Vorgang, wenn ein Prozess ein
„Thread“ in einem anderen Prozess
erzeugt.
9 „Raw Access Read“ Immer wenn ein Prozess mit der
Annotation \\.\ versucht etwas zu
lesen, wird dies in diesem Event
vermerkt.
10 Prozess Zugriff Das Event wird ausgelöst, wenn ein
Prozess einen anderen Prozess
startet.
11 Datei wird erzeugt Wenn eine Datei erzeugt oder
überschrieben wird, löst das Event
11 aus.
12,13,14 Registry Events In den Events 12,13 und 14 werden
verschiedene Aktivitäten, im
Schreibzugriff oder in der Registry
aufgezeichnet.
15 „File Create Stream Hash“ Wird erzeugt, wenn ein benannter
„File Stream“ geöffnet wird.
17 Pipe wird erzeugt Eine benannte Pipe wird erzeugt
(meist für Interprozess-
Kommunikation).
18 Pipe wird verbunden Dieses Event zeichnet Client und
Server bei einer Pipe-Verbindung
auf.
19,20,21 WMI Events Verschiedene „Windows
Management Instrumentation“ (WMI)
Aktivitäten werden aufgezeichnet.
22 DNS Events Wenn ein Prozess eine DNS-Abfrage
durchführt, wird dies, unabhängig
von dem Ergebnis der DNS-Abfrage
in diesem Event protokolliert.
255 Fehler Fehler innerhalb des Sysmon
Services.
Tabelle 8: Sysmon Events [76]

46
In Tabelle 8 werden alle möglichen Sysmon Events aufgelistet. Die Steuerung,
wodurch Events vom Sysmon Service aufgezeichnet werden, funktioniert über eine
Konfigurationsdatei im XML-Format. Essentiell ist dabei, harmlose Events zu filtern,
um eine hohe Qualität der Datenbasis zu erhalten. Die de-facto Standard
Konfiguration ist SwiftOnSecurity [78]. Viele Sysmon Konfigurationen forken die
Konfiguration von SwiftOnSecurity. Als Beispiel sei hier die Sysmon Konfiguration
von ion-storm erwähnt [79]. Diese Konfiguration basiert darauf, die entsprechenden
Vektoren von MITRE ATT&CK abzudecken [80]. ATT&CK kategorisiert
verschiedene sicherheitsrelevante Techniken (beispielsweise „Privilege
Escalation“ oder „Persistence“) [81]. Die Installation auf dem Testsystem erfolgt mit
sysmon.exe -accepteula -i sysmonconfig-export.xml.
4.3 Elastic SIEM

Elastic SIEM ist ein Produkt, welches erst im Sommer 2019 eingeführt wurde [82].
Es basiert auf dem etablierten Elastic Stack und soll speziell den Anforderungen
einer SIEM (siehe Kapitel 4.1) entsprechen. Wesentlich ist dabei das im Februar
2019 eingeführte „Elastic Common Schema“ [83]. Zusammengefasst, werden hier
Inhalte der verschiedenen Quellen extrahiert und in einem Schema gebündelt.
Damit soll, unabhängig vom Beat oder Produkt, erreicht werden, dass
beispielsweise der Name des Computers („hostname“) auch immer über ein
bestimmtes Feld ansprechbar ist. Ein gutes Beispiel wird in einem Blogbeitrag von
Elastic gezeigt [84]:
Abbildung 25: Effektivität des Elastic Common Schema [84]
Wie in Abbildung 25 zu sehen ist, wird eine Elastic Abfrage für eine Quell-IP-
Adresse aus den unterschiedlichen Systemen durch eine einzige Anweisung
ersetzt. Damit werden die Abfragen nicht nur leserlicher, sondern die Gefahr, ein
System mit einer Abfrage zu exkludieren, verringert sich.
Im Elastic SIEM wird zwischen „Host“ und „Network“ Daten unterschieden.
Unterschiedliche Beats auf unterschiedlichen Systemen können entsprechende
Daten an den Elastic Stack senden. Ein Beispiel für Netzwerk-Daten wäre den Beat
„Filebeat“ [85] auf einer Cisco Firewall [86] zu installieren. Für „Host“-Daten ist
winlogbeat für Windows-Systeme ein Beispiel, wobei mit der Implementierung von
Sysmon die harten Grenzen verschwimmen. Die Daten kommen zwar nach wie vor
von einem Computer („Host“), allerdings können diese auch über das Netzwerk
Daten enthalten.
47
In der aktuell eingesetzten Version von Elasticsearch gibt es in der Elastic SIEM
Applikation die zusätzliche Funktionalität „Detections“. Diese analysiert SIEM
relevante Eventlogs und prüft sie anhand von Regeln. Elastic bietet dabei 92
Regeln an, die aber erst aktiviert werden müssen. Neben diesen 92 Regeln ist es
möglich, auch selbst Regeln hinzuzufügen oder vorhandene zu duplizieren und
anzupassen. Die Regelsprache ist dabei „Kibana Query Language“ (KQL). In den
nachstehenden Testszenarien werden die zutreffenden Bereiche für eine Analyse
herangezogen. Die einzelnen Subfunktionalitäten werden in den passenden
Szenarien beschrieben. Das Ziel der Szenarien ist, zu prüfen, was Elastic SIEM
erkennt und wie die Darstellung in Kibana erfolgt.
4.3.1 Testszenario 1: Exploit
Als Exploit wird eine Kombination aus CVE-2019-1405 und CVE-2019-1322
herangezogen [87]. Zusammengefasst, ermöglicht ein logischer Fehler in der COM
Komponente von Windows (CVE-2019-1405) das Ausführen von Kommandos als
Local Service. Die zweite Sicherheitslücke besteht darin, dass das Windows
Service „Update Orchestrator Service“ eine Konfiguration ermöglichte, wodurch
verschiedene Kommandos im System Kontext ausgeführt werden (CVE-2019-
1322). Die Kombination beider Sicherheitslücken ermöglicht einem unprivilegierten
Benutzer, Kommandos als System auszuführen. Als Exploit wurde ein bereits
kompiliertes Proof-of-Concept herangezogen [88].
4.3.1.1 Durchführung
Der Exploit wurde von der Referenz [88] heruntergeladen, dafür ist es notwendig,
den Windows Defender zu deaktivieren, da diese Datei ansonsten sofort gelöscht
wird. Der Prozess stürzt kurz nach der Ausführung ab. Im Event-Log ist zu sehen,
dass die Applikation mit dem Fehlercode 0xc0000005 (Zugriff verweigert) [89]
abstürzt. Das ist ein erwartetes Fehlverhalten, da die Sicherheitslücke von
Microsoft bereits geschlossen wurde.
4.3.1.2 Ergebnis
Im Elastic SIEM gibt es unter der Kategorie „Host“ den Tab „Uncommon
Processes“. In dieser Ansicht, ist auch der Prozess COMahawk64.exe zu sehen.
48
Abbildung 26: Elastic SIEM – „Uncommon Processes"
Allerdings finden sich hier sehr viele legitime Prozesse, daher reicht dies als
einziger Indikator nicht aus. Eine Recherche zeigt, dass die „Uncommon
processes“ von der Anzahl der eingebundenen Host-Systeme abhängig sind [90].
Es ist daher nicht auszuschließen, dass sich die „false positives“ durch weitere
Windows Clients verringern. Weitere Indikatoren sind in der Elastic SIEM nicht zu
finden. Eine zusätzliche Erkennungsmöglichkeit, außerhalb der SIEM, ist, das
Event-Log „Windows Defender/Operational“ streng zu überwachen.
4.3.2 Testszenario 2: PowerShell
Die PowerShell Suite [91] stellt mehrere Skripts zur Verfügung um verschiedene
Angriffe auf ein System durchzuführen. Als Skript wurde das Invoke-
PowerShellTcp.ps1 verwendet [92].
Um eine Durchführung zu ermöglichen, muss der Windows Defender (Echtzeit und
Cloud-basierender Schutz) deaktiviert werden. Der Skript Inhalt wurde kopiert und
mit „. .\invokepstcp.ps1“ ausgeführt. Anschließend steht in dieser
unprivilegierten PowerShell Instanz die Funktion Invoke-PowerShellTcp zur
Verfügung. Der Aufruf erfolgt dabei wie folgt: Invoke-PowerShellTcp -Bind
-Port 4446. Damit dieser Port auf Verfügbarkeit geprüft werden kann, muss
sichergestellt werden, dass keine Firewall Regel diesen eingehenden
Netzwerkverkehr auf Port 4445 blockiert. Aus Sicht eines Angreifers, wird PuTTy
verwendet, um sich über den Port 4446 zu verbinden.
49
Abbildung 27: PowerShell Sitzung über TCP
Das erfolgreiche Verbinden wird in Abbildung 27 gezeigt. In dieser interaktiven

PowerShell Sitzung ist es nun möglich, Kommandos auf dem Zielrechner
abzusetzen.
4.3.2.2 Ergebnis
Das Starten des PowerShell Skripts bzw. das Öffnen des Ports auf dem Zielsystem
ist im Elastic SIEM nicht ersichtlich.
Abbildung 28: Elastic SIEM Signal Event "Telnet Port Activity"
Nach dem Verbindungsaufbau, wurde die Netzwerkaktivität von der bereits

eingebauten Elastic SIEM Signal Regel „Telnet Port Activity“ erkannt (siehe
Abbildung 28). Die Farben kategorisieren je nach der Schwere der Aktivitäten. Die
Events mit dem „Risk Score“ 21 (Grün) sind legitime Verwendungen von sc.exe,
die währenddessen stattgefunden haben. Mit einem deutlich höheren „Risk Score“,
50
nämlich 47 (Blau), wird die „Telnet Port Activity“ Regel angezeigt. Die Quelle dafür
ist ein Sysmon-Event.
4.3.3 Testszenario 3: Microsoft Office

Aufgrund von „Application Whitelisting“ (siehe Kapitel 3.3, 3.5) sind manipulierte
Office-Dateien [93] ein interessanter Angriffsvektor [94]. Dabei wird innerhalb der
Office-Dateien oft ein Makro [95] abgelegt und der Benutzer dazu (subtil)
aufgefordert, die Makros zu aktivieren. Das bekannte „Application Whitelisting“
kann dieses Verhalten nicht unterbinden, da die ausführbare Datei die Office-Suite
ist (beispielsweise Word). Um dies zu unterbinden, müssen die Makros selbst
abgesichert sein. Dies kann mittels Signierung oder Ablegen an einen
vertrauenswürdigen Ort [96] durchgeführt werden.
Microsoft Office 2016 wurde auf dem Zielsystem installiert. Danach wurde ein Word
Dokument und ein Makro mit dem nachstehenden Inhalt erstellt.
Abbildung 29: Makro PowerShell
Abbildung 29 zeigt dabei einen sehr einfachen Code, um eine powershell.exe zu

starten. Das Beispiel ist stark vereinfacht und soll verdeutlichen wie einfach
beliebige Dateien ausgeführt werden können. Nach dem Ausführen des Makros
öffnet sich ein interaktives PowerShell Konsolenfenster.
4.3.3.2 Ergebnis
Eine bereits mitgelieferte Regel mit dem Namen „Suspicious MS Office Child
Process“ hat die folgende Definition (siehe Abbildung 30):
51
Abbildung 30: Definition von „Suspicious MS Office Child Process"
Das SIEM zeigt im Elastic allerdings kein Signal-Event an. Der Grund dafür ist, dass
die Abfrage „case-sensitiv“ ist und bei einer Office Installation das Word
„WINWORD.EXE“ heißt und nicht „winword.exe“. Die „Detection Rule“ wurde
dupliziert und der „process.parent.name“ auf „process.parent.name.text“ geändert,
um die Abfrage „case-insensitiv“ zu machen. Anschließend wurde das Event auch
korrekt von der SIEM erkannt.
4.3.4 Testszenario 4: Login Bruteforce
Als viertes Szenario soll ein Bruteforce Angriff auf dem Zielsystem stattfinden. Die
Anmeldungen werden über RDP [97] simuliert. Dabei werden die Anmeldungen
über das Protokoll TCP auf dem Port 3389 durchgeführt.
Damit die RDP Anmeldungen durchgeführt werden können, müssen diese auf dem
Zielsystem aktiviert werden können. Die Aktivierung erfolgt über „Advanced system
settings“ -> „Remote“ -> „Allow remote connections to this computer”. Der
Bruteforce Angriff wird durch einen lokalen RDP Client auf dem Hostsystem
simuliert.
52
4.3.4.2 Ergebnis
Abbildung 31: Elastic Bruteforce
Die fehlgeschlagenen Anmeldeversuche sind in der „Host“-Übersicht zu finden

(siehe Abbildung 31). Im „Authentication“ Tab finden sich dann weitere
Informationen darüber. Die relevanten Informationen bestehen aus: Benutzer,
Anzahl der fehlgeschlagenen Versuche, Quell-IP-Adresse und Zielsystem.
Zusätzlich werden die fehlgeschlagenen Versuche auch in der Regel „RDP
(Remote Desktop Protocol) from the Internet“ unter „Detections“ mit einem „Risk
score“ von 47 angezeigt.
4.3.5 Testszenario 5: Passwort Dump Erkennung (Sigma Regel)

Elastic bietet nur eine begrenzte Anzahl an Erkennungsregeln. Es ist möglich
eigene Regeln zu definieren. Die Anzahl der neuen Angriffsvektoren steigt
allerdings laufend. Sigma [98] ist ein flexibles generisches Signaturformat. Das Ziel
ist es Signaturen zu definieren und diese in das jeweilige SIEM System importieren
zu können. Alle offiziellen Sigma Regeln finden sich im GitHub Repository [99] und
können mit dem Python Tool sigmac für das entsprechende SIEM konvertiert
werden. In diesem Szenario soll eine spezifische Sigma Regel konvertiert und in
das Elastic SIEM importiert werden. Als Tool wird eine Website verwendet, welche
von Sigma auf das entsprechende SIEM (Elastic) konvertiert [100]. Als Sigma
Regeln wird die „QuarksPwDump Dump File“ [101] herangezogen.
Zusammengefasst beschreibt die Sigma Regel, dass eine Datei unter
\AppData\Local\Temp mit dem Namen SAM-*.dmp erzeugt wird. Die
Konvertierung funktioniert leider nicht perfekt. Das Ergebnis der Konvertierung ist:
(winlog.channel:"Microsoft\-Windows\-Sysmon\/Operational"
AND winlog.event_id:"11" AND
file.path.keyword:*\\AppData\\Local\\Temp\\SAM\-*.dmp*)
Abbildung 32: Sigma Regel konvertiert (Original)
53
Das “Escapen” des winlog.channel führt zu einer fehlerhaften Abfrage. Die korrekte
Abfrage in KQL lautet daher wie folgt:
winlog.channel : "Microsoft-Windows-Sysmon/Operational"
AND winlog.event_id : "11" and
file.path:*\\AppData\\Local\\Temp\\SAM*.dmp
Abbildung 33: Sigma Regel konvertiert (KQL-konform)
Um den Angriff zu simulieren wurden aus dem Prozess cmd.exe Dateien mit dem
Namen: SAM-2.dmp und SAM-3.dmp unter
C:\Users\patrick\AppData\Local\Temp erstellt. Das Originalprojekt
QuarksPwDump [102] auf GitHub ist unter Visual Studio 2019 nicht mehr
kompilierbar.
4.3.5.2 Ergebnis
Mit der modifizierten (und damit KQL konformen) Regel wurde der Angriff bzw. die
Simulation erkannt. Die Erkennung zeigt in diesem Zuge auch, dass es durchaus
„false positives“ geben kann, da in dieser Sigma Regel lediglich die Erstellung einer
Datei geprüft wird.
4.3.6 Testszenario 6: Controlled Folder Access
Im Kapitel 3.5 wurde bereits die Sicherheitskomponente „Controlled Folder Access“
vorgestellt. Es wird dieselbe Vorgehensweise wie in Kapitel 3.5 gewählt, allerdings
nun mit der Elastic (SIEM) Anbindung, um anschließend zu prüfen ob die Elastic
SIEM den unerlaubten Zugriff erkennt. Unter C:\Users\patrick\documents
wird ein Ordner mit dem Namen Testszenario6 erstellt. Dieser Ordner wird
entsprechend in die „Controlled Folder Access“ Zugriffsliste eingetragen.
Als Angriffssimulation wird von einer PowerShell.exe versucht in das
Verzeichnis Testszenario6 zu schreiben.
Abbildung 34: PowerShell.exe versucht in einen "Controlled Folder Access" zu schreiben
Wie erwartet wird der Zugriff durch den Microsoft Windows Defender unterbunden.
4.3.6.2 Ergebnis
Im Elastic SIEM erscheint allerdings kein Event. Ein Ansatz wäre eine
entsprechende Regel im Elastic SIEM zu definieren. Diese Regel wäre allerdings
unabhängig von der jeweiligen „Controlled Folder Access“-Konfiguration.
54
4.3.6.3 Anpassung der Konfiguration für die Erkennung
Um eine Elastic SIEM Regel zu definieren, welche abhängig von der
Sicherheitskomponente ist, muss eine entsprechende Kibana Abfrage in KQL
erstellt werden. „Controlled Folder Access“ ist realisiert durch Microsoft Windows
Defender und Ereignisse sind unter dem Eventlog Windows
Defender/Operational zu finden.
Abbildung 35: Event "Controlled Folder Access"
Abbildung 35 zeigt das Event im Event-Viewer. Das Event hat zwei unabhängige
Charakteristiken, wodurch es eindeutig identifizierbar ist:
• Event-ID (1123)
• Der Text „Controlled Folder Access“ in den Event-Daten
Die Dokumentation von der Microsoft [103] zeigt, dass sowohl die Event-ID 1123
(„Blocked Controlled folder access event“) als auch die Event-ID 1127 („Blocked
Controlled folder access sector write block event“) für die Sicherheitskomponente
relevant sind. Die Abfrage gegen den Text ist zwar möglich, aber ineffizienter als
die Abfrage der Event-IDs. Die daraus resultierende Abfrage ist in Abbildung 36
definiert.
winlog.channel :"Microsoft-Windows-Windows Defender/Operational" and
event.code: 1123 or event.code: 1127
Abbildung 36: "Controlled Folder Access" Abfrage in KQL
Diese Abfrage kann entweder als gespeicherte Abfrage in der SIEM Regel
verwendet oder manuell in die Regel eingefügt werden.
55
Abbildung 37: Regeldefinition "Controlled Folder Access"
Die Regeldefinition (siehe Abbildung 37) wurde entsprechend umgesetzt.

Anschließend wurde das Event im Elastic SIEM richtig erkannt. Diese generische
Regel bietet daher eine Integration von „Controlled Folder Access“ in das Elastic
SIEM System.
4.3.7 Testszenario 7: Kryptojacking
Kryptomining beschreibt die Berechnung (und damit Erhalt) von Kryptowährung
[104]. Das Kryptomining ist sehr rechenintensiv und dadurch ein kostenintensives
Unterfangen. Kryptojacking [105] ist eine Schadsoftware die auf dem Rechner des
Opfers Kryptowährung berechnet. Die errechneten Kryptowährungen werden dem
Angreifer gesendet, der selbst keinen Rechenaufwand hatte. Kryptojacking war im
Jahre 2019 stärker verbreitet als Ransomware [106].
Es gibt verschiedene Möglichkeiten diesen Angriff zu erkennen. Eine Möglichkeit
wäre auf verdächtige Prozessnamen oder etwaige Objekte im Betriebssystem zu
prüfen. Im Zuge dieses Testszenarios wird ein Ansatz über die Performance-
Metriken gewählt. Als Beat wird dabei Metricbeat [107] eingesetzt. Die Idee ist
anhand der CPU-Auslastung, Kryptojacking festzustellen.
4.3.7.1 Integration Metricbeat
Metricbeat wurde heruntergeladen und über das von Elastic zur Verfügung gestellte
Microsoft Installer (MSI) installiert. Die in diesem Szenario notwendige Metricbeat
Konfiguration beschränkt sich auf die Komponenten CPU und Prozesse [108].
56
metricbeat.modules:
- module: system
metricsets: [cpu]
cpu.metrics: [percentages, normalized_percentages, ticks]
- module: system
metricsets: ["process"]
processes: ['.*']
Abbildung 38: Metricbeat CPU und Prozesse Konfiguration
Die zusätzliche Metricbeat Konfiguration ist in Abbildung 38 dargestellt. Die zur

Verfügung gestellten Metriken von Metricbeat sind in [109] definiert.
Um Kryptojacking zu erkennen werden zwei Charakteristiken herangezogen. Das
erste Charakteristikum ist, dass das Programm nicht von einem Administrator
installiert wurde. Üblicherweise werden die Programme unter C:\Program Files
bzw. C:\Program Files (x86) installiert. In der Abfrage wird geprüft ob der
Prozess unter C:\Users ausgeführt wird. Als zweites Charakteristikum wird die
CPU-Auslastung des jeweiligen Prozesses herangezogen. Dabei ist zu bedenken,
dass es als normales Verhalten gilt, wenn der Prozess eine kurze Zeit eine hohe
CPU-Last verursacht. Es ist daher entscheidend den Faktor Zeit miteinzubeziehen.
Mit den zur Verfügung gestellten Metriken wird
system.process.cpu.total.value verwendet, diese kumuliert die CPU-Last
des Prozesses.
system.process.cmdline:*C\:\\Users* and system.process.cpu.total.value >=
4000000
Abbildung 39: Kryptojacking Erkennung in KQL
Mit der Abfrage aus Abbildung 39 wird eine Elastic Regel erstellt. Wichtig für die
Regelerstellung ist es metricbeat-* als zusätzliche Quelle zu definieren, da
diese nicht im Standardset definiert ist. Der Wert für
system.process.cpu.total.value ist für die Testumgebung ausreichend,
allerdings nicht universell gültig sondern von dem jeweiligen System abhängig.
Zusätzlich ist noch anzumerken, dass „false postives“ möglich sind und die Abfrage
in einem anderen System, mit beispielsweise Prozessausnahmen, angepasst
werden muss um die „false positives“ zu verringern.
Um Kryptojacking zu simulieren, wird das Tool CPUSTRES [110] verwendet.
57
Abbildung 40: CPUSTRES Konfiguration
Die in Abbildung 40 gezeigte Konfiguration verursacht in der virtuellen Maschine

eine Auslastung von ca. 85% CPU.
4.3.7.3 Ergebnis
Die Erkennung funktioniert entsprechend der Elastic Regel. Die aktuelle
Konfiguration löst die Alarmierung, sofern ein Prozess einmal den Kriterien
entspricht, immer wieder aus. Es gibt mehrere Möglichkeiten dieses Verhalten zu
verbessern. Eine einfache Verbesserung wäre es nicht nur ein Minimum (4000000),
sondern auch ein Maximum (beispielsweise 4000500) zu definieren. Damit werden
innerhalb des Elastic SIEM Systems keine weiteren Events generiert, wenn der
Prozess weitere CPU-Last verursacht.
4.3.8 Gesamtübersicht
Nachdem die Testszenarien durchgeführt wurden, stellt Elastic SIEM eine
Gesamtübersicht dar:
Abbildung 41: Elastic SIEM Gesamtübersicht
Die in Abbildung 41 gezeigte Gesamtübersicht kategorisiert die Angriffe nach

MITRE ATT&CK Metriken. Mittels „View Events“ können die Events angezeigt
werden, die sich von der Gesamtübersicht ableiten lassen. Zusätzlich kann die
Kategorisierung von signal.rule.threat.tactic.name auf beispielsweise
signal.rule.name geändert werden, um die Regeln, die angeschlagen haben,
direkt angezeigt zu bekommen.
58
5. RELATED WORK
In der finnischen Masterarbeit [111] wird die praktische Implementierung der
Windows Sicherheitsmechanismen durchgeführt. Die daraus resultierenden
Implementierungen wurden auf die KATAKRI [112] Kriterien geprüft. Die finnische
Masterarbeit hat einen starken Fokus auf die praktische Implementierung der
Sicherheitskomponenten, deren Auswahl an KATAKRI gekoppelt ist. Zusätzlich
findet im Gegensatz zu dieser Arbeit keine Darstellung der Auswirkungen statt.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) in Deutschland führt
Sicherheitsanalysen von sicherheitskritischen Funktionen von Windows 10 durch.
Das Ziel ist es, aus der Analyse Härtungsmaßnahmen abzuleiten. Das Projekt ist
noch nicht fertiggestellt, doch das veröffentlichte Material umfasst aktuell ca. 30
Prozent. Im Kontext dieser Arbeit interessante Kapitel sind die bearbeiteten
Themenfelder: TPM und UEFI, „Virtualization-based Security“ und „Device Guard“.
Eine weitere Arbeit [113] beschäftigt sich mit der Optimierung/Konfiguration von
Windows Sicherheitsfeatures. Der Fokus liegt dabei auf dem Blocken von
Schadsoftware und den „Hack Tools“ auf USB-Geräten. Das Paper [114]
beschäftigt sich mit dem Thema Device Guard und AppLocker. Dabei wird anhand
von Schadsoftware die Möglichkeiten von Device Guard und AppLocker
demonstriert. Zusätzlich wird auch der Vergleich mit der Antiviren-Erkennung
herangezogen, um einen Vergleich der Wirksamkeit darzustellen.
In diesem Paper [115] werden Eventlogs für eine Sicherheitsanalyse
herangezogen. Das Ziel von diesem Paper ist es, Optimierungsmöglichkeiten
aufzuzeigen, um weniger Events zu übertragen. Dies hat zwei wesentliche Vorteile:
Die Entlastung der Infrastruktur und die Erleichterung der Analyse. Im Gegensatz
zu der vorliegenden Arbeit beschäftigt sich die Arbeit allerdings nicht, mit der
Analyse der Angriffe selbst.
Mit der Definition von Erkennungsregeln befasst sich die folgende Arbeit [116].
Dabei werden die zwei Angriffskategorien „Denial of Service“ und „Zero Day
Threats“ betrachtet. In Bezug auf diese Arbeit ist ausschließlich der Angriff mittels
„Zero Day Threats“ von Interesse. Dabei werden auf Basis des Windows
Betriebssystems die „Zero Day Threats“ analysiert. „Zero Day Threats“ sind Angriffe
die eine Sicherheitslücke ausnutzen obwohl diese erst bekannt geworden ist und
der Hersteller noch keine Zeit hatte diese zu schließen. Es werden dabei insgesamt
vier Überwachungsmöglichkeiten vorgestellt, um einen „Zero Day Threat“ zu
erkennen. Diese Methoden könnten in zusätzliche Elastic SIEM Regeln
implementiert werden, um so eine Erkennung zu ermöglichen. Die Grundlage dafür
ist, dass die Quell-Informationen bereitgestellt werden können (beispielsweise
mittels Sysmon).
Ein aktuelles Paper aus dem Jahr 2019 beschäftigt sich mit der Netzwerkanalyse
von Betriebssystemen [117]. Das Ziel war es, das Betriebssystem bzw. die darauf
installierte Software ausschließlich anhand des Netzwerkverkehrs zu erkennen. In
der Betriebssystemauswahl fand sich unter Linux und Mac OS X auch Windows
(sowohl Windows 10 als auch Windows Server 2016).
Die Datensammlung und Analyse erfolgte in ArcSight [118] und ist eine
kostenpflichtige SIEM Lösung. Als Datenquellen wurde sowohl lokal
aufgezeichneter Netzwerkverkehr mittels Tcpdump herangezogen als auch remote
59
aufgezeichneter Netzwerkverkehr von der Firewall und „NetFlow“ [119]. Auch
ArcSight verwendet, ähnlich wie Elastic, ein Meta-Schema um die verschiedenen
Log-Dateien auswerten zu können. Die meiste Netzwerkaktivität erzeugt Windows,
allerdings waren alle Betriebssysteme aufgrund der periodischen Abfragen
identifizierbar. Auch konnten Applikationen (wie beispielsweise der Anti-
Virenschutz Eset [120]) aufgrund des Netzwerkverkehrs identifiziert werden. Die
vorliegende Arbeit behandelt ausschließlich die „Host“-Informationen und nicht die
Netzwerkaktivitäten.
Ein Framework für Angriffsmodellierung und Sicherheitsbewertung stellt dieses
Paper [121] vor. Dieses Framework liefert dem SIEM System mit den öffentlich
zugänglichen Sicherheitsdaten (bekannte Angriffe) und der eigenen Infrastruktur
zusätzliche Informationen. Im Wesentlichen besteht das Framework aus vier
Komponenten (siehe [121], S. 3):
• „Security Ontology Database“
• „Attack Graph Generation“
• „Attack Graph Processing“
• „Decision Support“
Die prototypische Implementierung „AMSEC“ erzeugt dabei Angriffsgraphen (im
XML-Format). Diese Angriffsgraphen beinhalten drei Status: eine Angriffsaktion,
ein Szenario ohne Ausnutzung einer Sicherheitslücke (beispielsweise ein Ping)
und ein Szenario mit Ausnutzung einer Sicherheitslücke („Exploit“). Mit diesen
Informationen kann ein SIEM weitere Warnungen in der Infrastruktur präventiv
aufzeigen. Im Kontext dieser Arbeit, wäre „AMSEC“ eine zusätzliche Software die
Informationen an den Elastic Stack sendet. Die Auswertung erfolgt mittels Kibana.
Die Normalisierung und Analyse von Events aus unterschiedlichen Systemen
werden in [122] thematisiert. Die Source-Quellen sind unterteilt in Betriebssystem,
Software und Hardware. Als Basis-Technologie wird hier „Common Event
Expression“ (CEE) [123] verwendet. Im Zuge des Papers, wird zwischen dem
Extrahieren von Events und dem Neugenieren von Events unterschieden.
Exemplarisch werden Webserver Logs mittels „Regular Expression“ in eine
Datenstruktur („key/value pair“) konvertiert.
Der Prozess um neue Events zu generieren besteht aus drei Schritten:
• „Defining Static Fields“
• „Defining Event Tags“
• „Creating Common Log Entries“
Interessant dabei ist das eigens entwickelte Format „Object Log Format“ (OLM),
welches im dritten Schritt Verwendung findet. Dieses Log-Format basiert zwar auf
CEE liefert aber zusätzliche sicherheitsrelevante Informationen. Die technischen
Details zu OLM sind zwar bewusst nicht Teil des Papers, allerdings ist es damit
möglich Angriffe plattformunabhängig zu analysieren. Dies wird auch anhand von
drei Beispielen (Angriffe auf SSH, SMTP und HTTP) gezeigt. Andere
Softwaresysteme mit gleicher Funktion könnten aufgrund des OLM analysiert
werden.
60
6. ZUSAMMENFASSUNG
Um die Sicherheit in einem Betriebssystem zu verstehen, müssen die
grundlegenden Mechanismen von Prozess- und Speichermanagement bekannt
sein. Eine wesentliche Erneuerung ist dabei die „Virtualization-based Security“, die
es ermöglicht, den User-Mode sowie Kernel-Mode gehärtet und abgesichert für die
wichtigen Systemdienste zur Verfügung zu stellen. Dieser gesicherte Bereich ist
auch vor privilegierten Benutzer geschützt und etliche neue
Sicherheitskomponenten basieren auf „Virtualization-based Security“. Im
Anschluss wurden integrierte Sicherheitsmechanismen ausgeführt. Diese
integrierten Sicherheitsmechanismen, wie Integritätslevel oder Tokens, werden im
Windows verwendet und stellen sicher, dass grundlegende Sicherheitsmodelle
(beispielsweise Zugriffskontrolle) implementiert sind. Im Anschluss wurden
relevante Sicherheitskomponenten vorgestellt. Jede Sicherheitskomponente wurde
in den Aspekten Funktionsweise, Konfiguration, Auswirkungen auf die
Benutzerinnen und Benutzer und Auswirkungen auf die Applikationsentwicklung
erläutert. Damit sind Auswirkungen und Konfigurationsaufwand für jede
Sicherheitskomponente gegenübergestellt.
Der Elastic Stack ist im Bereich zentralisiertes Logging ein etabliertes Produkt. Im
Juni 2019 wurde von Elastic eine SIEM Applikation (realisiert durch eine
Erweiterung in Elasticsearch und Kibana) eingeführt. Um den Fortschritt der SIEM
Applikation zu prüfen, wurden sieben Angriffsszenarien definiert.
Zusammengefasst hat der Großteil der „Detection rules“ gut funktioniert.
Aktuell liefert Elastic 92 Regeln mit, wobei selbst neue Regeln erstellt oder
vorhandene dupliziert und angepasst werden können. Das „Authentication“-Tab hat
die Anmeldungen (erfolgreiche als auch nicht erfolgreiche) ebenfalls korrekt
angezeigt. Lediglich der „Uncommon Processes“-Tab zeigt viele legitime Prozesse
an. Dies könnte aber an dem Testszenario liegen und daran, dass nur ein Client in
den Elastic Stack eingebunden ist. Alle Angriffe konnten in der Elastic SIEM nach
der Implementierung der entsprechenden Regeln erkannt werden. Nichtsdestotrotz
wäre eine Integration des Windows Defender wünschenswert. Damit würden
Angriffe wie beim Testszenario 1 und 6 automatisiert erfasst werden.
7. AUSBLICK
Diese Arbeit teilt sich im Wesentlichen in zwei Bereiche auf: Windows (Client)
Sicherheit und Elastic SIEM. Ein Aspekt, der in dieser Arbeit im Bereich Windows
(Client) Sicherheit nahezu gänzlich ausgelassen wurde, sind Angriffsvektoren auf
die Sicherheitskomponenten. Eine tiefergehende Analyse mittels „Reverse
Engineering“ einer einzelnen Sicherheitskomponente könnte sicherheitsschwache
Implementierungsbereiche aufzeigen.
Elastic entwickelt intensiv an Elastic SIEM weiter. Eine erneute Evaluierung und
das Aufzeigen der Möglichkeiten in einer oder zwei Versionsupgrades könnten
massive Änderungen aufweisen. Eine andere Möglichkeit wäre, Elastic SIEM auf
die Skalierung (mehr eingebundene Computer) zu evaluieren. Dabei sollte der
Fokus darauf liegen, ob und wie ein Angriff auf einem einzelnen Computer in einem
Netzwerk mit beispielsweise über 1000 Computern festgestellt werden kann.
61
Abkürzungsverzeichnis
ACL Access Control Lists

AD Active Directory
ALPC Advanced local procedure call
ASLR Address Space Layout Randomization
BSI Bundesamt für Sicherheit in der Informationstechnik
BSOD Bluescreen of Death
CEE Common Event Expression
COM Component Object Model
CPU Central Processing Unit
DLL Dynamic link libraries
EKU Enhanced Key Usage
ELAM Early Launch Anti-Malware
GPO Group Policy Object
GUID Globally Unique Identifier
HTTP(S) HyperText Transfer Protocol (Secure)
HVCI HyperVisor Code Integrity
JOP Jump-oriented Programming
KDC Key Distribution Center
KQL Kibana Query Language
LSA Local Security Authority
NT New Technology
NTFS New Technology File System
NX No eXecute
OLM Object Log Format
PPL Protected Processes Light
RDP Remote Desktop Protocol
SAM Security Accounts Manager
SDK Software Development Kit
SID Security Identifier
SIEM Security Information and Event Management
SMTP Simple Mail Transfer Protocol
SRP Software Restriction Policy
SSH Secure Shell
TBS TPM base Service
TCP Transmission Control Protocol
lxii
TGT Ticket-granting Ticket
TPM Trusted Platform Module
UAC User Account Control
UEFI Unified Extensible Firmware Interface
UMCI User Mode Code Integrity
VBS Virtualization-based Security
VTL Virtual Trust Level
WDAC Windows Defender Application Control
WDAG Windows Defender Application Guard
WDCG Windows Defender Credential Guard
WDEG Windows Defender Exploit Guard
WHQL Windows Hardware Quality Lab
WLAN Wireless LAN Area Network
WMI Windows Management Instrumentation
lxiii
Schlüsselbegriffe
Windows Sicherheit
Virtualization-based Security
Elastic
SIEM
lxiv
LITERATURVERZEICHNIS
[1] “Netmarketshare - Betriebssystemverbreitung im Desktop Bereich,” 03 08

2019. [Online]. Available: https://netmarketshare.com/operating-system-
market-share.aspx.
[2] P. Yosifovich, A. Ionescu, M. E. Russinovich and D. A. Solomon, Windows
Internals 7th Edition - Part 1, Microsoft Press, 2017.
[3] “microsoft.com - Vergleich Windows Business Versionen,” [Online].
Available: https://www.microsoft.com/de-de/windowsforbusiness/compare.
[Accessed 03 08 2019].
[4] S. Laiho, “Discover Windows 10 internals,” [Online]. Available:
https://channel9.msdn.com/Events/Ignite/2016/BRK4021. [Accessed 08 08
2019].
[5] “Microsoft Hyper-V,” [Online]. Available: https://docs.microsoft.com/en-
us/windows-server/virtualization/hyper-v/hyper-v-on-windows-server.
[Accessed 16 02 2020].
[6] “SLAT Patent,” [Online]. Available:
https://patentimages.storage.googleapis.com/44/73/c6/242ff087fbe06f/US
7428626.pdf. [Accessed 16 02 2020].
[7] A. Ionescu, “alex-ionescu.com - Protected Processes Light (PPL),” [Online].
Available: http://www.alex-ionescu.com/?p=146. [Accessed 04 08 2019].
[8] “Windows SIDs,” [Online]. Available: https://support.microsoft.com/en-
us/help/243330/well-known-security-identifiers-in-windows-operating-
systems. [Accessed 26 08 2019].
[9] S. Bajikar, “Trusted Platform Module (TPM) based Security on,” in Intel,
2002.
[10] “AMSI - Microsoft,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/win32/amsi/antimalware-scan-interface-portal. [Accessed 10
11 2019].
[11] “AMSI - Schutz vor Malware,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps.
[Accessed 10 11 2019].
[12] “Windows 10 - Securing Windows Boot Proccess,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/security/information-
protection/secure-the-windows-10-boot-process. [Accessed 10 11 2019].
[13] “Windows 10 Enterprise Security,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/security/. [Accessed 01 02
2020].
65
[14] “Identity Protection,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/identity-protection/. [Accessed 01 02 2020].
[15] “Threat Protection,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/threat-protection/. [Accessed 01 02 2020].
[16] “Threat Protection - Attack surface reduction,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/security/threat-
protection/microsoft-defender-atp/overview-attack-surface-reduction.
[Accessed 01 02 2020].
[17] J. H. Saltzer and M. D. Schroeder, “The protection of information in
computer systems,” in Proceedings of the IEEE, 1975.
[18] “AppLocker - Übersicht,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/threat-protection/windows-defender-application-
control/applocker/what-is-applocker. [Accessed 15 12 2019].
[19] J. Forshaw, “AppLocker - Architektur,” [Online]. Available:
https://www.tiraniddo.dev/2019/11/the-internals-of-applocker-part-1.html.
[Accessed 25 01 2020].
[20] “SAFER API (Microsoft),” [Online]. Available: https://docs.microsoft.com/en-
us/windows/win32/secmgmt/management-functions#safer-functions.
[Accessed 01 25 2020].
[21] J. Forshaw, “AppLocker - Blocking Prozess,” [Online]. Available:
https://www.tiraniddo.dev/2019/11/the-internals-of-applocker-part-2.html.
[Accessed 25 01 2020].
[22] A. Margosis, “AaronLocker,” [Online]. Available:
https://github.com/microsoft/AaronLocker. [Accessed 25 01 2020].
[23] “AccessChk,” [Online]. Available: https://docs.microsoft.com/en-
us/sysinternals/downloads/accesschk. [Accessed 08 02 2020].
[24] “WebEx,” [Online]. Available: https://www.webex.com/. [Accessed 16 02
2020].
[25] “Go To Meeting,” [Online]. Available: https://www.gotomeeting.com/de-at.
[Accessed 16 02 2020].
[26] “Certification requirements for Windows Desktop Apps,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/win32/win_cert/certification-
requirements-for-windows-desktop-apps. [Accessed 25 01 2020].
[27] “BitLocker - Microsoft,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/information-protection/bitlocker/bitlocker-overview.
[Accessed 25 01 2020].
[28] M. E. Russinovich, D. A. Solomon and A. Ionescu, Windows Internals 6th
Edition, Part 2, Microsoft Press, 2012.
[29] “Controlled Folder Access,” [Online]. Available:
66
protection/microsoft-defender-atp/controlled-folders. [Accessed 06 02
2020].
[30] R. Brewer, “Ransomware attacks: detection, prevention and cure,” in
Network Security - Volume 2016, Issue 9, 2016.
[31] “Controlled Folder Access - Aktivierung,” [Online]. Available:
protection/microsoft-defender-atp/enable-controlled-folders. [Accessed 08
02 2020].
[32] “Controlled Folder Access - Voraussetzungen,” [Online]. Available:
protection/microsoft-defender-atp/controlled-folders. [Accessed 08 02
2020].
[33] “IRP_MJ_CREATE,” [Online]. Available: https://docs.microsoft.com/en-
us/windows-hardware/drivers/ifs/irp-mj-create. [Accessed 08 02 2020].
[34] “Application Control,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/threat-protection/device-guard/introduction-to-device-
guard-virtualization-based-security-and-windows-defender-application-
control. [Accessed 02 02 2020].
[35] “Windows Defender Application Control,” [Online]. Available:
protection/windows-defender-application-control/windows-defender-
application-control. [Accessed 02 02 2020].
[36] “Device Guard - BSI Analyse,” [Online]. Available:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-
Sicherheit/SiSyPHus/Workpackage7_Device_Guard.pdf. [Accessed 02 02
2020].
[37] “WDAC - Verteilung der Konfiguration,” [Online]. Available:
protection/windows-defender-application-control/deploy-windows-
defender-application-control-policies-using-group-policy. [Accessed 13 02
2020].
[38] “WDAG - Policys erzwingen,” [Online]. Available:
protection/windows-defender-application-control/enforce-windows-
defender-application-control-policies. [Accessed 13 02 2020].
[39] “Windows Defender Application Guard,” [Online]. Available:
protection/windows-defender-application-guard/wd-app-guard-overview.
[Accessed 07 02 2020].
[40] “vmmem Prozess,” [Online]. Available:
https://devblogs.microsoft.com/oldnewthing/20180717-00/?p=99265.
[Accessed 16 02 2020].
67
[41] “LSA Protection,” [Online]. Available: https://docs.microsoft.com/en-
us/windows-server/security/credentials-protection-and-
management/configuring-additional-lsa-protection. [Accessed 01 02 2020].
[42] “Credential Guard - Funktionsweise,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/security/identity-
protection/credential-guard/credential-guard-how-it-works. [Accessed 01 02
2020].
[43] “Mimikatz,” [Online]. Available: https://github.com/gentilkiwi/mimikatz.
[Accessed 08 02 2020].
[44] “Windows Defender Credential Guard - Konfiguration,” [Online]. Available:
protection/credential-guard/credential-guard-manage. [Accessed 08 02
2020].
[45] “Credential Guard - Erwägungen,” [Online]. Available:
protection/credential-guard/credential-guard-considerations. [Accessed 02
02 2020].
[46] “Credential Guard - 3rd Party Security Support Provider,” [Online].
Available: https://docs.microsoft.com/en-
us/windows/win32/w8cookbook/third-party-security-support-providers-with-
credential-guard. [Accessed 02 02 2020].
[47] “Credential Guard - SSP,” [Online]. Available:
https://blog.nviso.eu/2018/01/09/windows-credential-guard-mimikatz/.
[Accessed 02 02 2020].
[48] “Windows Defender Exploit Guard,” [Online]. Available:
protection/microsoft-defender-atp/exploit-protection. [Accessed 06 02
2020].
[49] “EMET,” [Online]. Available: https://www.microsoft.com/en-
us/download/details.aspx?id=50766. [Accessed 06 02 2020].
[50] “EMET - End of Life,” [Online]. Available: https://support.microsoft.com/de-
at/help/2458544/the-enhanced-mitigation-experience-toolkit. [Accessed 06
02 2020].
[51] “WDEG - Mitigations,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/threat-protection/microsoft-defender-atp/customize-
exploit-protection. [Accessed 06 02 2020].
[52] “"ASR Rules",” [Online]. Available: https://docs.microsoft.com/en-
us/windows/security/threat-protection/microsoft-defender-atp/attack-
surface-reduction. [Accessed 06 02 2020].
[53] “Microsoft Security Baseline 1909,” [Online]. Available:
https://techcommunity.microsoft.com/t5/microsoft-security-
68
baselines/security-baseline-final-for-windows-10-v1909-and-windows-
server/ba-p/1023093. [Accessed 13 02 2020].
[54] G. Haslinger, “WDEG Baseline Scripts,” [Online]. Available:
https://github.com/gunnarhaslinger/Windows-Defender-Exploit-Guard-
Configuration. [Accessed 15 02 2020].
[55] “20744C- Securing Windows Server 2016,” in Microsoft Training.
[56] B. Schneier and N. Ferguson, “A Cryptographic Evaluation of IPsec,” in
Counterpane Internet Security, Inc., 1999.
[57] “Windows Defender Firewall - Hardening Guide,” [Online]. Available:
https://medium.com/@cryps1s/endpoint-isolation-with-the-windows-
firewall-462a795f4cfb. [Accessed 07 02 2020].
[58] “Windows Firewall Endpoint Isolation - Export,” [Online]. Available:
https://github.com/pmatula/windows-firewall-endpoint-isolation. [Accessed
10 02 2020].
[59] “ProcessHacker,” [Online]. Available: https://processhacker.sourceforge.io/.
[Accessed 13 02 2020].
[60] “Elastic,” [Online]. Available: https://www.elastic.co/. [Accessed 29 02
2020].
[61] “Elasticsearch,” [Online]. Available: https://www.elastic.co/elasticsearch.
[Accessed 29 02 2020].
[62] “Kibana,” [Online]. Available: https://www.elastic.co/kibana. [Accessed 29
02 2020].
[63] “Logstash,” [Online]. Available: https://www.elastic.co/logstash. [Accessed
29 02 2020].
[64] “Beats,” [Online]. Available: https://www.elastic.co/beats. [Accessed 29 02
2020].
[65] B. Azarmi, Learning Kibana 5.0, Packt Publishing, 2017.
[66] “Winlogbeat,” [Online]. Available:
https://www.elastic.co/de/beats/winlogbeat. [Accessed 29 02 2020].
[67] S. Bhatt, P. K. Manadhata and L. Zomlot, “The Operational Role of Security
Information and Event Management Systems,” IEEE Security & Privacy (
Volume: 12 , Issue: 5 , Sept.-Oct. 2014 ), 2014.
[68] “Elastic Stack Installationsdokumentation,” [Online]. Available:
https://www.elastic.co/guide/en/elastic-stack/current/installing-elastic-
stack.html. [Accessed 05 03 2020].
[69] “Elasticsearch Sicherheitsfeatures Version 7.1.0,” [Online]. Available:
https://www.elastic.co/blog/security-for-elasticsearch-is-now-free.
[Accessed 05 03 2020].
69
[70] “Elasticsearch TLS,” [Online]. Available:
https://www.elastic.co/guide/en/elasticsearch/reference/current/ssl-tls.html.
[Accessed 05 03 2020].
[71] “Elasticsearch Node Zertifikate,” [Online]. Available:
https://www.elastic.co/guide/en/elasticsearch/reference/7.6/configuring-
tls.html#node-certificates. [Accessed 05 03 2020].
[72] “Kibana Sicherheit,” [Online]. Available:
https://www.elastic.co/guide/en/kibana/7.6/using-kibana-with-security.html.
[Accessed 05 03 2020].
[73] “Windows Eventlog,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/win32/wes/windows-event-log. [Accessed 15 03 2020].
[74] “Event Tracing,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/win32/etw/about-event-tracing. [Accessed 15 03 2020].
[75] “Severity Levels,” [Online]. Available: https://docs.microsoft.com/en-
us/windows/win32/wes/defining-severity-levels. [Accessed 15 03 2020].
[76] “Sysmon,” [Online]. Available: https://docs.microsoft.com/en-
us/sysinternals/downloads/sysmon. [Accessed 22 03 2020].
[77] C. Balles and A. Sharfuddin, “Breaking Imphash,” in Cornell University,
2019.
[78] “SwiftOnSecurity Sysmon Konfiguration,” [Online]. Available:
https://github.com/SwiftOnSecurity/sysmon-config. [Accessed 22 03 2020].
[79] “Sysmon Konfiguration ion-storm,” [Online]. Available:
https://github.com/ion-storm/sysmon-config. [Accessed 22 03 2020].
[80] “MITRE ATT&CK,” [Online]. Available: https://attack.mitre.org/. [Accessed
22 03 2020].
[81] “ATT&CK Metriken,” [Online]. Available:
https://attack.mitre.org/matrices/enterprise/. [Accessed 22 03 2020].
[82] “Elastic SIEM Ankündigung,” [Online]. Available:
https://www.elastic.co/blog/introducing-elastic-siem. [Accessed 22 03
2020].
[83] “Elastic Common Schema,” [Online]. Available:
https://www.elastic.co/guide/en/ecs/current/index.html. [Accessed 22 03
2020].
[84] “Einführung Elastic Common Schema,” [Online]. Available:
https://www.elastic.co/de/blog/introducing-the-elastic-common-schema.
[Accessed 22 03 2020].
[85] “Filebeat,” [Online]. Available: https://www.elastic.co/beats/filebeat.
[Accessed 22 03 2020].
70
[86] “Cisco Firewall,” [Online]. Available:
https://www.cisco.com/c/de_at/products/security/firewalls/index.html.
[Accessed 22 03 2020].
[87] “CVE-2019-1405 and CVE-2019-1322 – Elevation to SYSTEM via the UPnP
Device Host Service and the Update Orchestrator Service,” [Online].
Available: https://www.nccgroup.trust/uk/about-us/newsroom-and-
events/blogs/2019/november/cve-2019-1405-and-cve-2019-1322-
elevation-to-system-via-the-upnp-device-host-service-and-the-update-
orchestrator-service/. [Accessed 29 03 2020].
[88] “COMahawk - CVE-2019-1405 und CVE-2019-1322,” [Online]. Available:
https://github.com/apt69/COMahawk. [Accessed 29 03 2020].
[89] “Microsoft Error Code Lookup Tool,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-
code-lookup-tool. [Accessed 31 03 2020].
[90] “Uncommon Processes,” [Online]. Available:
https://discuss.elastic.co/t/uncommon-processes/190115. [Accessed 05 04
2020].
[91] “Nishang PowerShell Suite,” [Online]. Available:
https://github.com/samratashok/nishang. [Accessed 02 04 2020].
[92] “Nishang - Invoke-PowerShellTcp,” [Online]. Available:
https://github.com/samratashok/nishang/blob/master/Shells/Invoke-
PowerShellTcp.ps1. [Accessed 02 04 2020].
[93] “Microsoft Office,” [Online]. Available: https://docs.microsoft.com/en-
us/office/. [Accessed 04 04 2020].
[94] “Gefahren von Makros in Office-Dateien,” [Online]. Available:
https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-
2016-can-block-macros-and-help-prevent-infection/. [Accessed 04 04
2020].
[95] “Makros Office,” [Online]. Available: https://docs.microsoft.com/en-
us/office/vba/library-reference/concepts/getting-started-with-vba-in-office.
[Accessed 04 04 2020].
[96] “Office Makro Sicherheit Australian Cyber Gov,” [Online]. Available:
https://www.cyber.gov.au/publications/microsoft-office-macro-security.
[Accessed 04 04 2020].
[97] “Remote Display Protocol,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/win32/termserv/remote-
desktop-protocol. [Accessed 04 04 2020].
[98] F. Roth, “Sigma,” [Online]. Available: https://github.com/Neo23x0/sigma.
[Accessed 02 05 2020].
71
[99] F. Roth, “Sigma Regeln,” [Online]. Available:
https://github.com/Neo23x0/sigma/tree/master/rules. [Accessed 02 05
2020].
[100] “Sigma Regel Konverter online,” [Online]. Available: https://uncoder.io/.
[Accessed 02 05 2020].
[101] “Sigma Regel SAM Dump ins AppData,” [Online]. Available:
https://github.com/NVISO-BE/sigma-
public/blob/master/rules/windows/sysmon/sysmon_quarkspw_filedump.ym
l. [Accessed 02 05 2020].
[102] “QuarksPwDump,” [Online]. Available:
https://github.com/quarkslab/quarkspwdump. [Accessed 02 05 2020].
[103] “Event-IDs Microsoft Defender,” [Online]. Available:
protection/microsoft-defender-atp/event-views. [Accessed 02 05 2020].
[104] J. Hosp, Kryptowährungen: Bitcoin, Ethereum, Blockchain, ICOs & Co.
einfach erklärt, FinanzBuch Verlag, 2018.
[105] K. Sigler, “Crypto-jacking: how cyber-criminals are exploiting the crypto-
currency boom,” in Computer Fraud & Security, 2018.
[106] “Kryptomining Trend 2019,” [Online]. Available:
https://www.ikarussecurity.com/security-news/neuer-malware-trend-crypto-
miner-uebertreffen-ransomware/. [Accessed 02 05 2020].
[107] “Metricbeat,” [Online]. Available:
https://www.elastic.co/de/beats/metricbeat. [Accessed 02 05 2020].
[108] “Metricbeat CPU und Prozesse,” [Online]. Available:
https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-
module-system.html. [Accessed 02 05 2020].
[109] “Metricbeat Metriken,” [Online]. Available:
https://www.elastic.co/guide/en/beats/metricbeat/current/exported-fields-
system.html. [Accessed 03 05 2020].
[110] P. Yosifovich, “CPUStres,” [Online]. Available:
https://docs.microsoft.com/en-us/sysinternals/downloads/cpustres.
[Accessed 03 05 2020].
[111] “Practical implementation of Windows end-point security,” [Online].
Available:
https://www.theseus.fi/bitstream/handle/10024/139806/Leppanen_Tuomo.
pdf?sequence=1. [Accessed 05 04 2020].
[112] “Katakri,” [Online]. Available:
https://www.defmin.fi/files/3417/Katakri_2015_Information_security_audit_t
ool_for_authorities_Finland.pdf. [Accessed 05 04 2020].
72
[113] D. Pham, M. Halgamuge, A. Syed and P. Mendis, “Optimizing Windows
Security Features to Block Malware and Hack,” in PIERS Proceedings,
2010.
[114] R. Durve and A. Bouridane, “Windows 10 Security Hardening using Device
Guard Whitelisting and AppLocker Blacklisting,” in 2017 Seventh
International Conference on Emerging Security Technologies (EST), 2017.
[115] J. Baráth, “Optimizing windows 10 logging to detect network security,” in
2017 Communication and Information Technologies (KIT), 2017.
[116] K. Sornalakshmi, “Detection of DoS attack and Zero Day Threat with SIEM,”
in International Conference on Intelligent Computing and Control Systems,
2017.
[117] J. Baráth, “Network behavior analysis of selected operating systems,” in
Communication and Information Technologies (KIT), 2019.
[118] “ArcSight,” [Online]. Available: https://www.microfocus.com/en-
us/products/siem-security-information-event-management/overview.
[Accessed 15 05 2020].
[119] R. Hofstede, P. Celeda, B. Trammell, I. Drago, R. Sadre, A. Sperotto and A.
Pras, “Flow Monitoring Explained: From Packet Capture to Data Analysis
with NetFlow and IPFIX,” in Institute of Electrical and Electronics Engineers
Inc., 2014.
[120] “Eset,” [Online]. Available: https://www.eset.com/at/. [Accessed 15 05
2020].
[121] I. Kotenko and A. Chechulin, “Attack Modeling and Security Evaluation
Component,” in Attack Modeling and Security Evaluation Component, 2012.
[122] A. Azodi, D. Jäger, F. Cheng and C. Meinel, “Pushing the Limits in Event
Normalisation to Improve Attack Detection in IDS/SIEM Systems,” in
International Conference on Advanced Cloud and Big Data, 2013.
[123] “Common Event Expression,” 2010. [Online]. Available:
https://cee.mitre.org/docs/CEE_Architecture_Overview-v0.5.pdf.
[Accessed 15 05 2020].
[124] “TPM Fundamentals - Microsoft,” [Online]. Available:
https://docs.microsoft.com/en-us/windows/security/information-
protection/tpm/tpm-fundamentals. [Accessed 10 11 2019].
[125] D. R. Miller, S. Harris, A. Harper, S. Vandyke and C. Blask, “Security
Information and Event Management (Siem) Implementation,” McGraw-Hill
Osborne Media, 2010.
[126] “SiSyPHuS Windows 10 BSI,” [Online]. Available:
https://www.bsi.bund.de/DE/Themen/Cyber-
Sicherheit/Empfehlungen/SiSyPHuS_Win10/SiSyPHuS_node.html.
[Accessed 05 04 2020].
73
Abbildungsverzeichnis
Abbildung 1: VBS Architektur (siehe [2], S. 59), [4] ......................................................... 10

Abbildung 2: Speicher API (siehe [2], S. 309) ................................................................. 12
Abbildung 3: Boot Schutzmechanismen [12] ................................................................... 17
Abbildung 4: Speicherlayout mit „Address Space Layout Randomization“ (siehe [2], S. 366)
................................................................................................................................ 19
Abbildung 5: CFG (siehe [2], S. 749) .............................................................................. 20
Abbildung 6: AppLocker Architektur [19] ......................................................................... 23
Abbildung 7: Importieren der AppLocker Regelsätze von AaronLocker ........................... 24
Abbildung 8: AppLocker Regelauszug („executable“ Dateien) ........................................ 24
Abbildung 9: BitLocker Komponentenübersicht (siehe [28], S. 165) ................................ 26
Abbildung 10: BitLocker Aktivierung................................................................................ 26
Abbildung 11: BitLocker Status des Verschlüsselungsvorgang ....................................... 27
Abbildung 12: Controlled Folder Access – PowerShell.................................................... 28
Abbildung 13: Process Monitor - Schreibzugriff mittels PowerShell.exe .......................... 28
Abbildung 14: Aktivitäten Controlled Folder Access ........................................................ 29
Abbildung 15: WDAG im "Process Explorer" ................................................................... 31
Abbildung 16: WDAG PDF-Download ............................................................................. 32
Abbildung 17: WDCG [42] ............................................................................................... 33
Abbildung 18: Anmeldedaten des Lsass-Prozesses lesen .............................................. 34
Abbildung 19: WDCG aktiviert ........................................................................................ 35
Abbildung 20: „ASR Rules" in der Ereignisanzeige ......................................................... 38
Abbildung 21: Windows Defender Firewall Service ......................................................... 40
Abbildung 22: Elastic Architektur (siehe [65], „Chapter 1: Introduction to Data Driven
Architecture”) .......................................................................................................... 41
Abbildung 23: Elastic Stack sichere Kommunikation ....................................................... 43
Abbildung 24: Event Tracing [74] .................................................................................... 44
Abbildung 25: Effektivität des Elastic Common Schema [84] .......................................... 47
Abbildung 26: Elastic SIEM – „Uncommon Processes" ................................................... 49
Abbildung 27: PowerShell Sitzung über TCP .................................................................. 50
Abbildung 28: Elastic SIEM Signal Event "Telnet Port Activity" ....................................... 50
Abbildung 29: Makro PowerShell .................................................................................... 51
Abbildung 30: Definition von „Suspicious MS Office Child Process" ................................ 52
Abbildung 31: Elastic Bruteforce ..................................................................................... 53
Abbildung 32: Sigma Regel konvertiert (Original)............................................................ 53
Abbildung 33: Sigma Regel konvertiert (KQL-konform) ................................................... 54
74
Abbildung 34: PowerShell.exe versucht in einen "Controlled Folder Access" zu schreiben
................................................................................................................................ 54
Abbildung 35: Event "Controlled Folder Access" ............................................................. 55
Abbildung 36: "Controlled Folder Access" Abfrage in KQL .............................................. 55
Abbildung 37: Regeldefinition "Controlled Folder Access"............................................... 56
Abbildung 38: Metricbeat CPU und Prozesse Konfiguration............................................ 57
Abbildung 39: Kryptojacking Erkennung in KQL .............................................................. 57
Abbildung 40: CPUSTRES Konfiguration ........................................................................ 58
Abbildung 41: Elastic SIEM Gesamtübersicht ................................................................. 58
75
Tabellenverzeichnis
Tabelle 1: Begriffsdefinitionen Windows (siehe [2], S. 7)...................................................9
Tabelle 2: Windows Sicherheitskomponenten (siehe [2], S. 608) .................................... 14
Tabelle 3: AppLocker blockbare Dateien [18] .................................................................. 22
Tabelle 4: Kernel-Mode Signierung und User-Mode Signierung (siehe [2], S. 618) ......... 30
Tabelle 5: „Exploit Protection" [51] .................................................................................. 36
Tabelle 6: „ASR Rules" [52] ............................................................................................ 37
Tabelle 7: Testumgebung virtueller Maschinen ............................................................... 43
Tabelle 8: Sysmon Events [76] ....................................................................................... 46
76

Windows 10 Sicherheitsmechanismen Und Integration in Den Elastic Stack

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Windows 10 Sicherheitsmechanismen Und Integration in Den Elastic Stack

Hochgeladen von

Copyright:

Verfügbare Formate

Windows 10 Sicherheitsmechanismen und Integration

in den Elastic Stack

Windows 10 security mechanisms and integration in

der Fachhochschule FH Campus Wien

Datum: 15.05.2020 .............. Unterschrift:

Das Microsoft Betriebssystem Windows ist im Desktop Bereich marktführend. Aufgrund

3. WINDOWS SICHERHEIT ........................................................................... 12

4. ELASTIC STACK ..................................................................................... 40

5. RELATED WORK .................................................................................... 59

Tabelle 1: Begriffsdefinitionen Windows (siehe [2], S. 7)

2.1.2 User-Mode / Kernel-Mode

Tabelle 2: Windows Sicherheitskomponenten (siehe [2], S. 608)

3.1 Integrierte Sicherheitsmechanismen

Abbildung 3: Boot Schutzmechanismen [12]

Wie in Abbildung 4 zu sehen, gibt es einige definierte Regionen im Speicherlayout.

Abbildung 5: CFG (siehe [2], S. 749)

Tabelle 3: AppLocker blockbare Dateien [18]

Abbildung 6: AppLocker Architektur [19]

Im Gegensatz zur SRP, besteht der AppLocker aus einem Kernelmodul

Abbildung 7: Importieren der AppLocker Regelsätze von AaronLocker

Wie in Abbildung 7 zu sehen ist, wurden bei einer Standardkonfiguration 107

Abbildung 8: AppLocker Regelauszug („executable“ Dateien)

3.3.3 Auswirkungen auf Benutzer

Abbildung 10: BitLocker Aktivierung

Abbildung 11: BitLocker Status des Verschlüsselungsvorgang

Mit dem Kommando manage-bde.exe -status C: kann der aktuelle Status

Abbildung 12: Controlled Folder Access – PowerShell

Abbildung 12 zeigt den Versuch des Prozesses powershell.exe, die Datei

Abbildung 13: Process Monitor - Schreibzugriff mittels PowerShell.exe

Als Analysewerkzeug wird Process Monitor verwendet. In Abbildung 13 ist das

Anschließend gibt es einige Aktivitäten von MsMpEng.exe (Windows Defender

Kernel-Mode Signierung aktiv User-Mode Signierung aktiv

Tabelle 4: Kernel-Mode Signierung und User-Mode Signierung (siehe [2], S. 618)

Abbildung 15: WDAG im "Process Explorer"

Abbildung 16: WDAG PDF-Download

In einer administrativen PowerShell Konsole, wird mit privilege::debug das

3.9 Windows Defender Exploit Guard

Tabelle 5: „Exploit Protection" [51]

Tabelle 6: „ASR Rules" [52]

Wie anhand der Beschreibungen aus Tabelle 6 hervorgehen, werden spezifische

Abbildung 20: „ASR Rules" in der Ereignisanzeige

3.10 Windows Defender Firewall

Abbildung 21 zeigt die Abhängigkeiten des Services „Windows Defender Firewall“.

Abbildung 22 zeigt die Architektur der Hauptprodukte. Die Elasticsearch

Tabelle 7: Testumgebung virtueller Maschinen

Für den winclient sind gesonderte Konfigurationen notwendig, damit die

Abbildung 23: Elastic Stack sichere Kommunikation

4.2.3 Einbindung des Windows 10 Clients

Abbildung 24: Event Tracing [74]

Abbildung 24 zeigt den Zusammenhang zwischen den drei Komponenten. Die

Tabelle 8: Sysmon Events [76]

4.3 Elastic SIEM

Abbildung 25: Effektivität des Elastic Common Schema [84]

Das erfolgreiche Verbinden wird in Abbildung 27 gezeigt. In dieser interaktiven

Abbildung 28: Elastic SIEM Signal Event "Telnet Port Activity"

Nach dem Verbindungsaufbau, wurde die Netzwerkaktivität von der bereits

4.3.3 Testszenario 3: Microsoft Office

Abbildung 29: Makro PowerShell

Abbildung 29 zeigt dabei einen sehr einfachen Code, um eine powershell.exe zu

Abbildung 31: Elastic Bruteforce

Die fehlgeschlagenen Anmeldeversuche sind in der „Host“-Übersicht zu finden

4.3.5 Testszenario 5: Passwort Dump Erkennung (Sigma Regel)

Abbildung 32: Sigma Regel konvertiert (Original)