Paper: Ethical HackingPowershell for Defense- Powershell Logging

Datum: 05.04.2019Verfasser: Daniel Feichter B.Sc.

Inhalt

1 Einleitung 1

2 Powershell Logging 22.1 Script Block Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Transcription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Versuchsdurchführung 63.1 Versuch 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Versuch 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Versuch 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Abbildungsverzeichnis III

Tabellenverzeichnis IV

Literatur V

II

1 Einleitung

Um die Kompromittierung eines Zielrechners zu erreichen, verwenden Red Teamer unterschiedlicheArten von Malware. Speziell seit 2017 gibt es einen starken Zuwachs an Fileless Attacks, in denenFileless Malware zum Einsatz kommt und der Kategorie low-observable characteristics (loc) zugeord-net werden. Wie bereits im Paper AMSI Disabling Part I erwähnt, orientiert sich ein Red Teamerfür einen erfolgreichen Angriff immer entlang der Cyberkill Chain, so auch im Fall der Fileless Attack(Abb.1.1). [2]

Abb. 1.1: Darstellung der unterschiedlichen Phasen einer Fileless Attack [2]

Für einen Blue Teamer ist diese Art von Angriff sehr schwer zu erkennen, da Fileless Malware aus-schließlich im Arbeitsspeicher operiert und somit auf der Festplatte des Zielsystems keine Spurenhinterlässt. Des Weiteren sind Statistiken zufolge, Angriffe in denen Fileless Malware verwendet wird,ca. 10 mal erfolgreicher im Vergleich zu Angriffen, in denen Filebased Malware zum Einsatz kommt.Für die Ausführung von Fileless Maleware gibt es mehrere Möglichkeiten, wie zum Beispiel überWMIC oder den Task Scheduler. Sehr häufg wird jedoch Powershell für die Ausführung von FilelessMalware verwendet, nicht zuletzt aufgrund dessen, da Powershell bereits in Windows implementiertist und somit aus Sicht eines Red Teamers nicht nachträglich installiert werden muss. Des Weiterenist Powershell sehr tief im Windows-Core verankert und bietet durch seinen mächtigen Umfang einigeAngriffsvektoren für Red Teamer. Unter anderem nutzen Diese Powershell für folgende Angriffsakti-vitäten: [1, 5]

• Information gathering

• Persistence

• Privilege escalation

• Credential theft

• Lateral movement

• Data destruction

• Data exfiltration

1

2 Powershell Logging

Wie bereits erwähnt, ist Fileless Malware für Blue Teamer sehr schwer zu entdecken, da Diese im Ar-beitspeichers des kompromittierten Systems operiert. Dennoch ist die Erkennung von Fileless Malwarenicht unmöglich. Die ersten Möglichkeiten Powershell Code zu analysieren führte Microsoft bereitsmit Powershell V2 ein. Zu Beginn war hier jedoch das Verhältniss von Nutzen zu Aufwand eherunvorteilhaft. Doch mit der stetigen Weiterentwicklung und den darauf folgenden Powershell Versio-nen wurde der Nutzen gegenüber den Aufwand bezogen auf die Powershell Logging Möglichkeitenbesser und besser. Mit der Powershell V5 führte Microsoft unter anderem die unten angeführtenMöglichkeiten für das Powershell Logging ein. Interessant ist auch der Entwicklungsverlauf der un-terschiedlichen Powershell Generationen bezogen auf Red- und Blue Teamer Möglichkeiten, weshalbdie Abb.2.1 eingefügt wurde. [3]

• Script Block Logging

• Transcription

Abb. 2.1: Darstellung Entwicklungsverlauf bzw. der Möglickeiten von Powershell für Red- und BlueTeamer [4]

Bevor auf Details der unterschiedliche Logging Möglichkeiten eingegangen wird, ist noch wichtigzu verstehen, dass in der Malware Analyse- und Forensikphase die Kompromittierung des Systemsvermutlich bereits stattgefunden hat. Die Aufgabe des Blue Teamers besteht nun zum einen darin,den bisherigen Schaden zu analysieren und zum anderen weitere Schäden zu verhindern. In diesemPaper wollen wir uns die Analysemöglichkeiten des Script Block Loggings und Transcription unterPowershell V5 anschauen.

2.1 Script Block Logging

Script Block Logging kurz SBL bietet Verteidigern unter Powershell V5 die Möglichkeit PowershellCode im Event Log von Windows aufzuzeichnen. Somit haben Blue Teamer bei Verdacht auf Kom-promittierung die Chance, Fileless Maleware im Nachhinein zu finden und zu analysieren. Beim Script

2

Block Logging werden jedoch keine geblockte Powershell Scripts (durch AV) im Event Log aufge-zeichnet -wie manch einer zu Beginn vermuten mag- nein, es werden je nach Einstellungsart von SBLnur laut Microsoft verdächtiger Powershell Code oder alle Script Blöcke im Powershell\OperationalEvent Log aufgezeichnet. Standardmäßig befindet sich SBL im not configured Mode, in diesemModus werden Script Blöcke aufgezeichnet, die bestimmte Trigger beinhalten (Tokens). So werdenzum Beispiel Script Blöcke von Microsoft als malicious eingestuft, die unter anderem folgende Tokensenthalten. [3]

• Invoke Expressions - IEX

• System.Reflection.AssemblyName

• System.Reflection.Emit.AssemblyBuilderAcces

• System.Runtime.InteropServices.MarshalAsAttribute

• TOKEN PRIVILEGES

• SE PRIVILEGE ENABLED

• Bypass

Abb. 2.2: Lokale Konfigurationsmöglichkeit Script Block Logging per Group Policy Editor

Dies spiegelt jedoch nur einen kleinen Teil der Tokens wieder, die ein verdächtiges Verhalten beiMicrosoft triggern, weitere Tokens findent man im Netz. Befindet sich SBL im not configured Mode sowerden im Powershell Operational Event Log alle verdächtigen Script Blöcke mit dem Level Warningund der Event ID 4104 aufgezeichnet. Es gibt jedoch auch die Möglichkeit, das SBL dezidiert zuaktivieren. In diesem Modus (Verbose Mode) sollen alle Script Blöcke einer Powershell Session imPowershell Operational Event Log eingetragen werden, nicht nur jene, die als Verdächtig eingestuftwerden. Durch die dezidierte Aktivierung von SBL sollen Blue Teamer die Möglichkeit haben, denvollen Umfang eines Fileless Malware Angriffs zu erfassen. Alles Script Blöcke die als nicht verdächtigeingestuft werden, bekommen im Event log einen 4104 Verbose oder 4104 Information Eintrag.Ein großer Vorteil von SBL ist, dass durch die Powershell Engine ausgeführter kodierter- (Base64,XOR, ROT13) oder obfuskierter Schadcode dekodiert und als Klartext im Event Log eingetragenwird. Natürlich wäre das primäre Ziel, die Ausführung des Powershell Codes bereits zu unterbinden(dann erfolgt auch kein Script Block Logging), doch das ist nicht die Aufgabe von SBL. Durch SBLhat man nicht die Möglichkeit einen Angriff zu verhindern, doch gibt es einem Blue Teamer dieOption, sonst sehr schwer ausfinding zu machende Fileless Malware Aktivitäten unabhänging vomRAM Status des kompromittierenden Rechners zu analysieren. Generell braucht es für die dezidierte

3

Aktivierung von SBL keine 3rd Party Software, da diese im Group Policy Editor (lokal aus gesehen)aktiviert werden kann (Abb.2.2). [3]

• Group Policy Editor\Local Computer Policy\Administrative Templates\Windows Com-ponents\Windows Powershell\Script Block Logging

Es gibt jedoch auch das Powershell Modul ScriptBlockLoggingAnalyzer, welches es uns ermöglicht,per Powershell direkt mit den SBL Konfigurationsmöglichkeiten zu interagieren. So können wir zumBeispiel das SBL vollständig aktivieren, deaktivieren, Events abrufen oder auch die maximale Spei-cher größe des Logfiles bestimmen. Eine Erhöhung der maximalen SBL Logfilesize empfieht sich, dadiese Standardmäßig auf 10Mb eingestellt ist. Die Installation und eine Übersicht der dazugehörigenPowershell Commands kann in Abb.2.3 betrachtet werden. [6]

Abb. 2.3: Installation des Powershell Modul ScriptBlockLoggingAnalyzer unter Powershell V5 undÜbersicht der dazugehörigen Powershell Commands

2.2 Transcription

Eine weitere Möglichkeit Fileless Malware Angriffe per .txt File aufzuzeichnen, bietet Transcriptionunter Powershell V5. Transcription erstellt einen eindeutigen Datensatz für jede PowerShell Session,einschließlich aller Eingabe und Ausgabe, genau so, wie sie in der Sitzung angezeigt wird. Transcrip-tions werden in Textdateien geschrieben und nach Benutzer und Sitzung aufgeteilt. Transcriptionsenthalten auch Zeitstempel und Metadaten für jeden Befehl, um die Analyse zu erleichtern. Beider Transkription wird jedoch nur das aufgezeichnet, was in der PowerShell Session angezeigt wird.Dies beinhaltet nicht den Inhalt der ausgeführten Skripts oder die Ausgabe, die an andere Ziele wiedas Dateisystem geschrieben wurde. Des Weiteren werden Powershell-Transcriptions automatisch miteinem Dateinamen benannt, damit Kollisionen vermieden werden. Die Bezeichnungen der Transcrip-tionsfiles beginnen jeweils mit PowerShell-transcript. Standardmäßig werden Transcriptions in denlokalen Dokumentenordner des Benutzers geschrieben. Sie können jedoch an einem beliebigen Ortauf dem lokalen System oder im Netzwerk konfiguriert werden. Eine bewährte Methode besteht darin,Transcriptions auf eine Remote-Netzwerkfreigabe mit Schreibzugriff zu schreiben, in der Verteidigerdie Daten leicht überprüfen und von Angreifern nicht leicht gelöscht werden können.Transcriptionssind sehr speichereffizient (weniger als 6KB pro Ausführung von Invoke-Mimikatz) und lassen sichleicht komprimieren. Die Aktivierung von Transcription erfolgt unter: (Abb.2.3) [3].

4

• Group Policy Editor\Local Computer Policy\Administrative Templates\Windows Com-ponents\Windows Powershell\Transcription

Abb. 2.4: Konfigurationsmöglichkeit Transcription per Group Policy Editor

5

3 Versuchsdurchführung

In den folgenden Versuchen soll gezeigt werden, wie mittels aktiviertem Script Block Logging undTranscription am kompromittierten Zielrechner Fileless Malware aufgezeichnet und unabhänging vomStatus des Arbeitsspeichers im Nachhinein analysiert werden kann. Für die Komprimitierung wirdeine selbst erstellte Fileless Malware verwendet, die ursprünglich mit PS-Empire erzeugt und imVersuch 3 mit Invoke-Obfuscation weiter verarbeitet wird. Da die Dekodierung bzw. Deobfuskierungder verwendete Powershell Codes nur bei erfolgreicher Komprittierung des Zielrechners durch dieAusführung über Powershell Engine erfolgt, deaktivieren wir für alle Versuche den Windows Defender.Das soll nicht bedeuten, dass der Windows Defender in Realität ein unüberwindbares Hinderniss wäre,nur soll es hier nicht um das Bypassen des Defenders gehen, sondern um den Fall der Malware-Analysenach einer Kompromittierung. Für den Versuch kommen folgende Komponenten zum Einsatz.

• Windows 10 (Stand 1809 Anfang April 2019)

• Power Modul ScriptBlockLoggingAnalyzer

• Invoke-Obfuscation

• Kali Linux 2019.1

• PS-Empire

3.1 Versuch 1

Der Versuch 1 wird mit folgender Konfiguration durchgeführt.

• Script Bock Logging: not configured

• Transcription: enabled

• Windows Defender: deaktiviert

• PS-Empire: Base64 kodiert

In der Abb.3.2 ist zu erkennen, dass per CMD die Fileless Malware ausgeführt wird. Da der Win-dows Defender zu Testzwecken deaktiviert wurde, kann der Base64 kodierte Powershell Code durchdie Powershell Engine ausgeführt und dekodiert werden. Der dekodierte Code operiert nur im Ar-beitsspeicher des Zielrechners und wird von Microsoft als schädlich eingestuft wird. Deshalb wirdbereits im SBL not configured Mode im Powershell Operational Log ein Event ID 4104 Warningerstellt (Abb.3.3). Der Powershell Code wird vermutlich deswegen als malicious eingestuft, da DieserTokens wie z.B. Invoke Expression oder System.Management.Automation.AmsiUtils usw. ent-hält. In der Abb.3.4 ist für den selben ausgeführten Powershell Code das Logging durch Transcriptiondargestellt. Es ist erkennbar, dass für die Powershell Session ein .txt File erstellt wird und alle Daten-sätze beeinhaltet die in der Powershell Session verwendet wurden. Interessant ist hierbei, das nebendem dekodierten- auch noch der ursprüngliche Base64 kodierte Code aufgezeichnet wird.

6

Abb. 3.1: Abbildung zeigt den nicht konfigurierten Status von SBL am Zielrechner

Abb. 3.2: Ausführung des Base64 kodierten Powershell Codes per CMD

Abb. 3.3: Darstellung des dekodierten Base64 Powershell Codes im Event Log durch Script BlockLogging im not configured Mode nach Ausführung durch die Powershell Engine

7

Abb. 3.4: Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell LoggingFunktion Transcription

3.2 Versuch 2

Der Versuch wird mit folgender Konfiguration durchgeführt.

• Script Bock Logging: enabled

• Transcription: enabled

• Windows Defender: deaktiviert

• PS-Empire: Base64 kodiert

In diesem Versuch aktivieren wir vor der Schadcodeausführung dezidiert das Script Block Logging lokalmittels Group Policy Editor. Wie in Abb.3.6 erkennbar, wir auch in dieser Einstellung der dekodierteScript Block durch SBL im Event Log aufgezeichnet. Des Weiteren ist in Abb.3.7 erkennbar, dasszusätzlich noch ein Eintrag mit dem Level-Verbose aufgezeichnet wird. Auch hier wird durch dieaktivierte Transcription ein .txt File von der Powershell Session erstellt. Im Grunde beinhaltet das.txt File die selben Ergebnisse wie im 1. Versuch. Einziger Unterschied zu erkennen ist, dass nochzusätzlich gewisse Einträge zur Powershell Pipline aufgezeichnet werden.

Abb. 3.5: Zusätzlicher Verbose Eintrag im Event Log bei dezidiert aktiviertem SBL

8

Abb. 3.6: Darstellung des dekodierten Base64 Powershell Codes im Event Log durch Script BlockLogging nach Ausführung durch die Powershell Engine

Abb. 3.7: Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell LoggingFunktion Transcription

9

3.3 Versuch 3

Im letzten Versuch verwenden wir statt der Dekodierung eine Obfsukierung für den Powershell Code.Dafür decodieren wir zuerst den Base 64 Code und obuskieren Diesen mit Invoke Obfuscation. Indiesem Fall verwenden wir die Option String-Obfuscation und obfuskieren insgesamt 2 mal (Abb.3.8und Abb.3.9). Sehr interessant ist in den Abbildungen 3.10-3.12 im Event Log des SBL zu sehen, dasshier die Stufenweise Deobfuskierung des ursprünglich obfuskierten Power Shell Codes aufgezeichnetwird. Im Gegensatz zu den Versuchen 1 und 2 in denen der Base64 kodierte Code verwendet wurde,ist ersichtlich, dass neben dem deobfuskierten Klartext auch der ursprünglich obfuskierte Code vomSBL aufgezeichet wird. In dem erstellten .txt File durch Transcription ist in Abb.3.13 zu erkennen,dass im Vergleich zu den Versuchen 1 und 2 hier nur der obfuskierte Powershell Code der 2. Stufeaufgezeichnet wird.

Der Versuch wird mit folgender Konfiguration durchgeführt.

• Script Bock Logging: not configured

• Transcription: enabled

• Windows Defender: deaktiviert

• PS-Empire: Base64 dekodiert

• Invoke-Obfuscation: String Obfuscation

Abb. 3.8: 1. Stufe der Obfuskierung durch String Obfuscation Option Concatenate

10

Abb. 3.9: 2. Stufe der Obfuskierung durch String Obfuscation Option Reorder

Abb. 3.10: Darstellung des obfuskierten Powershell Codes der 2. Stufe im Event Log durch ScriptBlock Logging im not configured Mode nach Ausführung durch die Powershell Engine

11

Abb. 3.11: Darstellung des obfuskierten Powershell Codes der 1. Stufe im Event Log durch ScriptBlock Logging im not configured Mode nach Ausführung durch die Powershell Engine

Abb. 3.12: Darstellung des original Power Shell Code in Klartext mittels 2. Stufen Deobfuskierungdurch die Powershell Engine

12

Abb. 3.13: Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell Log-ging Funktion Transcription

3.4 Zusammenfassung

Durch die vermehrte Zunahme von Filless Malware Angriffe in den letzten Jahren, haben es BlueTeamer immer schwerer ihr System abzusichern bzw. die Malware im System zu identifizieren. Seitder Einführung von Powershell V5 liefert Microsoft jedoch ein paar interessante Möglichkeiten für dieAufzeichnung und Analyse von Fileless Malware Angriffen. So gibt es zum Beispiel die Möglichkeitdes Script Block Loggings, bei dem bereits standardmäßig im not configured Mode ein als maliciouseingestufter Powershell Code im Event Log aufgezeichnet wird. Der Eintrag erfolgt mit der EventID 4104 Level-Warning. Des Weiteren kann das Script Block Logging per dezidierter Aktivierung inden Verbos Mode gesetzt werden, in dem alle Script Blöcke einer Powershell Session im Event logeingetragen werden sollen. Diese werden ebenfalls mit der Event ID 4104 aufgezeichnet, allerdings mitdem Level-Verbose gekennzeichnet. In unseren Versuchen stellte sich SBL als sehr gutes Werkzeugfür Blue Teamer dar, eine mögliche Kompromittierung des Systems unabhängig vom Status desArbeitsspeichers festzustellen und zu analysieren. Interessant zu sehen in den Ergebnissen (Tab.3.1),unabhänig davon, ob der Powershell Code dekodiert oder obfuskiert ist, in allen 3 Versuchen wirdbereits im SBL Status not configured ein Eintrag im Powershell Operational Event Log mit der ID4104-Warning erstellt. Auch ist erkennbar, dass bei Verwendung des Base64 kodierten Codes durchdas SBL keine Aufzeichnung des ursprünglichen Codes stattfindet. In diesem Fall ist im Event Lognur ein Eintrag mit dem Klartext erkennbar. Im Vergleich dazu, wird im Versuch 3 die stufenweiseDeobfuskierung als Event 4104 eingetragen. Betrachtet man die Ergebnisse in den Tab.3.1 so stelltsich berechtigt die Frage, warum soll ein Systemadministrator das Script Block Logging dezidiertaktivieren in dem er es in den Verbose Mode setzt, wenn doch in allen 3 Versuchen die FilelessMalware bereits im not configured Mode im Powershell Operational Event Log aufgezeichnet wird.Hierbei muss jedoch beachtet werden, dass es natürlich auch Fileless Maleware gibt die z.B. vomWindows Defender nicht erkannt-, durch die Powershell Engine ausgeführt und vom SBL im notconfiured Mode nicht erkannt wird, da die Malware Tokens enthält die kein schädliches Verhaltenbei Microsoft triggern bzw. durch eine gezielte Obfuskierung den Defender an seine Grenzen der

13

Dekodierung bzw. Deobfuskierung bringt (wird in einem weiteren Paper behandelt). Des Weiterenbietet der Verbose Mode einem Blue Teamer die Option einen Fileless Malware im vollen Ausmaß zubetrachten, sprich es können auch Powershell Loggings im Nachhinein betrachtet werden, die im notconfigured Mode im Event Log nicht eingetragen worden wären.

Neben dem Script Block Logging bietet auch die Powershell Logging Variante Transcription inter-essante Ansätze. Bei dieser Logging Methode wird für jede Powershell Session lokal am Rechner imVerzeichnis Dokumente ein .txt File mit sämtlichen Datensätze der ausgeführten Powershell Sessionerstellt. Das Verzeichnis kann jedoch auch wahlweise an einen externen Server bzw. Laufwerk aus-gelagert werden, so sind Logfiles zum einen vor Angriffen besser geschützt und zum anderen für dasBlue Team besser verwaltbar. In den Versuchen mit Transcription konnte man beobachten, dass beider Aufzeichnung des ursprünglich ausgeführten Codes bezogen auf die Verschleierung Unterschiedegab. So wird bei der Obfuskierung nur die 2. Obfuskierunsstufe im .txt File eingetragen. Auch konnteman beobachten, dass die Aufzeichnung des Malware Codes in Klartext nur in den Versuchen 1 und2 mit der Base64 Kodierung erfolgte.

Zum Abschluss kann gesagt werden, dass Microsoft seit Powershell V5 mit dem SBL und Transcriptionzwei gute Möglichkeiten in der Fileless Malware Attack Analyse bietet. Derzeit kann jedoch einekodierte oder obfuskierte Malware nur als Klartext betrachtet werden, wenn Diese durch die PowershellEngine ausgeführt wird. Sprich der Fileless Angriff konnte bereits erfolgreich ausgeführt werden undder Blue Teamer befindet sich bereits in der Phase eines kompromittierenden Systems. Grundsätzlichist das OK, da SBL und Transcription nicht als direktes Malware Verteidigungswerkezug dienen sollen.Es wäre jedoch auch interessant über eine Möglichkeit zu verfügen, eine kodierte bzw. obfuskierteFileless Malware eines verhinderten Angriffs durch den Defender durch das SBL oder Transcriptionin Klartext betrachten zu können.

Tab. 3.1: Übersicht der Ergebnisse Script Block Logging

Versuch SBL Status Event LogWarning

Event LogVerbose

Aufz. Ur-sprünglicherCode

Aufz. Codein Klartext

1 not configu-red

Ja Nein Nein Ja

2 enabled Ja Ja Nein Ja3 not configu-

redJa Nein Ja (Beide

Obfuskie-rungsstufen)

Ja

Tab. 3.2: Übersicht der Ergebnisse Transcription

Versuch Transcr. Status Erstellung .txt Aufz. Ur-sprünglicherCode

Aufz. Code inKlartext

1 enabled Ja Ja Ja2 enabled Ja Ja Ja3 enabled Ja Ja (nur 2. Obfus-

kierunsstufe)Nein

14

Abbildungen

1.1 Darstellung der unterschiedlichen Phasen einer Fileless Attack [2] . . . . . . . . . . . 1

2.1 Darstellung Entwicklungsverlauf bzw. der Möglickeiten von Powershell für Red- undBlue Teamer [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Lokale Konfigurationsmöglichkeit Script Block Logging per Group Policy Editor . . . 32.3 Installation des Powershell Modul ScriptBlockLoggingAnalyzer unter Powershell V5

und Übersicht der dazugehörigen Powershell Commands . . . . . . . . . . . . . . . . 42.4 Konfigurationsmöglichkeit Transcription per Group Policy Editor . . . . . . . . . . . 5

3.1 Abbildung zeigt den nicht konfigurierten Status von SBL am Zielrechner . . . . . . . 73.2 Ausführung des Base64 kodierten Powershell Codes per CMD . . . . . . . . . . . . . 73.3 Darstellung des dekodierten Base64 Powershell Codes im Event Log durch Script

Block Logging im not configured Mode nach Ausführung durch die Powershell Engine 73.4 Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell

Logging Funktion Transcription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Zusätzlicher Verbose Eintrag im Event Log bei dezidiert aktiviertem SBL . . . . . . 83.6 Darstellung des dekodierten Base64 Powershell Codes im Event Log durch Script

Block Logging nach Ausführung durch die Powershell Engine . . . . . . . . . . . . . 93.7 Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell

Logging Funktion Transcription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.8 1. Stufe der Obfuskierung durch String Obfuscation Option Concatenate . . . . . . . 103.9 2. Stufe der Obfuskierung durch String Obfuscation Option Reorder . . . . . . . . . 113.10 Darstellung des obfuskierten Powershell Codes der 2. Stufe im Event Log durch Script

Block Logging im not configured Mode nach Ausführung durch die Powershell Engine 113.11 Darstellung des obfuskierten Powershell Codes der 1. Stufe im Event Log durch Script

Block Logging im not configured Mode nach Ausführung durch die Powershell Engine 123.12 Darstellung des original Power Shell Code in Klartext mittels 2. Stufen Deobfuskierung

durch die Powershell Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.13 Darstellung der gespeicherten Powershell Session in .txt Form durch die Power Shell

Logging Funktion Transcription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Tabellenverzeichnis

III

Tabellen

3.1 Übersicht der Ergebnisse Script Block Logging . . . . . . . . . . . . . . . . . . . . . 143.2 Übersicht der Ergebnisse Transcription . . . . . . . . . . . . . . . . . . . . . . . . . 14

IV

Literatur

[1] . Fileless Attacks. url: https : / / download . bitdefender . com / resources / media /

materials/Filess_Attacks_Whitepaper_2018_labs.pdf.

[2] . What is Fileless Malware? url: https://www.mcafee.com/enterprise/en-us/security-awareness/ransomware/what-is-fileless-malware.html.

[3] Matthew Dunwoody. Greater Visibility Through PowerShell Logging. 2016. url: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html.

[4] Mina Hao. Attack and Defense Around PowerShell Event Logging. 2019. url: https : / /nsfocusglobal.com/Attack-and-Defense-Around-PowerShell-Event-Logging.

[5] Chad Tilbury. Investigating PowerShell: Command and Script Logging. 2018. url: https://www.crowdstrike.com/blog/investigating- powershell- command- and- script-

logging/.

[6] Dr.Tobias Weltner. ScriptBlockLoggingAnalyzer 1.2. 2018. url: https : / / www .

powershellgallery.com/packages/ScriptBlockLoggingAnalyzer/1.2.

V