von Frank Ully

Dies ist der fünfte Teil einer mehrteiligen Reihe über Windows PowerShell und darüber, wie Angreifer es missbrauchen, wie Incident Responder und Forensiker diese Angriffe erkennen können – und welche Verteidigungslinien IT-Sicherheitsverantwortliche ziehen können.

Dieser Artikel stellt vor, mit welchen Methoden Incident Responder und IT-Forensiker PowerShell-Angriffe untersuchen können – darunter die Arbeitsspeicher-Analyse.

Der erste Artikel der Reihe beschrieb die Phasen echter Angriffe und stellte das Konzept der Post Exploitation vor; anschließend folgte eine Einführung in die technischen Grundlagen von Windows PowerShell und dessen Remoting-Funktion.

Der zweite Artikel der Reihe beleuchtete, welche Eigenschaften PowerShell als Angriffswerkzeug so beliebt machen, und erläuterte die Eignung für und den Einsatz von PowerShell in echter Schadsoftware und durch Angreifergruppen.

Der dritte Artikel der Reihe stellte öffentlich verfügbare Skriptsammlungen mit offensiven PowerShell-Skripten für Post Exploitation vor, darunter PowerShell Empire.

Der vierte Artikel der Reihe führte allgemein in die Arbeitsspeicher-Forensik ein, die eine relativ neue Untersuchungsmethode für Incident Responder und Forensiker gegen moderne Bedrohungen wie PowerShell-Angriffe ist.

 

Angriffe mit PowerShell wurden erstmals systematisch von den beiden Sicherheitsforschern Ryan Kazanciyan und Matt Hastings in einem Whitepaper untersucht, das sie im August 2014 auf der Sicherheitskonferenz Black Hat vorstellten [1, S. 4-22].

Für ausgewählte Aktivitäten der Post Exploitation wie auch für einzelne PowerShell-Skripte hat das japanische Computer Emergency Response Team (CERT) Ende 2017 eine umfangreiche Liste mit jeweils erzeugten forensischen Artefakten veröffentlicht [2].

Netzwerkverkehr

Ein fester Bestandteil von Post-mortem-Untersuchungen ist die Analyse von Mitschnitten verdächtigten Netzwerkverkehrs. Lediglich das Finden des richtigen Einstiegspunktes und die Suche nach interessanten Mustern stellt bei den dort anfallenden Datenmengen eine Herausforderung dar [3, S. 153].

Die eingebaute Remoting-Funktion von PowerShell, mit der andere Rechner ferngesteuert werden können, läuft transportverschlüsselt über die TCP-Ports 5985 (gekapselt in HTTP) oder 5986 (gekapselt in das abermals verschlüsselte HTTPS). Ein etwaiger Mitschnitt einer Remoting-Sitzung entzieht sich also einer detaillierten Analyse des Klartextes [4, S. 47].

Bei einer Remoting-Sitzung über Port 5985 können in den unverschlüsselten HTTP-Kopfzeilen lediglich Metadaten über den Fernsteuerungsvorgang ausgelesen werden: der Benutzername, unter dessen Rechten die Sitzung läuft, sowie die Version des PowerShell-Clients [1, S. 6].

Das Post-Exploitation-Framework PowerShell Empire verrät sich in aufgezeichnetem Netzwerkverkehr durch eine hohe Entropie innerhalb der unverschlüsselten HTTP-POST-Anfragen und viele darin eingestreute Bytefolgen mit nicht-druckbaren Zeichen [5, S. 48].

Abbildung 1: Netzwerkmitschnitt von Empire-Datenverkehr in Wireshark (Quelle: https://artofpwn.com/offensive-and-defensive-powershell-ii.html)

Ereignisprotokollierung

Das Durchsuchen von Systemprotokollen, die im Zuge einer standardmäßig laufenden Protokollierung (Logging) von wichtigen Systemereignissen unter Windows erzeugt werden, ist wichtiger Bestandteil sowohl einer Post-mortem-Analyse als auch häufig überhaupt erst der Anlass zum Anstoßen einer forensischen Untersuchung [3, S. 151].

Eine einfache Protokollierung ist beginnend mit der PowerShell-Version 3 möglich und standardmäßig aktiviert [6, S. 30]. PowerShell 3 ist erstmals vorinstalliert auf Windows 8 und Windows Server 2012, kann aber auf Windows 7 und Windows Server 2008 nachträglich aufgespielt werden [6, S. 6].

Frühere Versionen von Windows PowerShell bieten nur spärliche Einstellungen zur Auditierung; die dabei angelegten Protokolleinträge reichen für eine forensische Untersuchung nicht aus [1, S. 10].

Abbildung 2: PowerShell Session Start in PowerShell 2.0 (Quelle: [7])

Das Standard-Verzeichnis, in dem PowerShell-Protokolldateien abgelegt werden, ist: C:\Windows\System32\Winevt\Logs\

Beim Ausführen eines einzelnen PowerShell-Befehls oder eines kompletten Skriptes können Ereigniseinträge in folgenden Protokolldateien erstellt werden; unabhängig davon, ob PowerShell direkt auf dem Rechner gestartet wurde oder per Remoting aus der Ferne [1, S. 10]:

  • Windows PowerShell.evtx
  • Microsoft-Windows-PowerShell/Operational.evtx
  • Microsoft-Windows-PowerShell/Analytic.etl

Schließlich können über die Remoting-Funktion Befehle auf anderen Rechnern im Netzwerk ausgeführt werden. Remoting baut auf dem Protokoll Windows Remote Management (WinRM) auf, dessen Logdateien auf Quell- und Zielrechner Hinweise auf die PowerShell-Aktivitäten enthalten können [1, S. 10]:

  • Microsoft-Windows-WinRM/Operational.evtx
  • Microsoft-Windows-WinRM/Analytic.etl

Protokolleinträge unter Windows zeichnen sich durch eindeutige Ereignisnummern (Event IDs) aus. Die Gesamtheit der für PowerShell relevanten Ereignisnummern ist zu umfangreich, um sie in diesem Artikel detailliert zu behandeln. Gute Übersichten zu diesen Ereignisnummern finden sich in einem Blogeintrag von EventSentry [26], im Kazanciyan/Hastings-Whitepaper [1, S. 11-16] und für Remoting auf der Rückseite des SANS-Hunt-Evil-Posters 2018 [24, S. 2].

Beispielhaft genannt seien die Event-IDs 400 („Engine state is changed from None to Available”) und 403 („Engine state is changed from Available to Stopped”), die beim Start bzw. Ende einer PowerShell-Sitzung erzeugt werden.

Ein Ereignis mit der ID 4688 („A new process has been created”) wird etwa protokolliert, wenn von PowerShell aus ein externes Programm gestartet wurde; und gibt Informationen darüber, welcher Prozess erstellt wurde, welche Parameter, falls vorhanden, an den Prozess übergeben wurden und welcher sein übergeordneter Prozess ist [8, S. 21-22].

Abbildung 3: Protokolleintrag über Prozesserstellung (Quelle: [9])

Um laufende Angriffe mit PowerShell oder eine bestehende Kompromittierung erkennen zu können, wird vor allem das erweiterte Protokollieren jeglicher Aktivitäten durch PowerShell empfohlen, insbesondere von dadurch ausgelösten automatisierten Downloads [11, S. 86]: „Extended logging is key to make an investigation easier and we strongly recommend system administrators to enable this feature.“ [6, S. 29] Verdächtig sind auch solche Aktivitäten, die Einstellungen zum Logging manipulieren.

Abbildung 4: Erweiterter PowerShell-Ereignisprotokolleintrag (Quelle: [6, S. 31])

Mit PowerShell-Version 3 wurde die modulweise Protokollierung (Module Logging) eingeführt, die PowerShell-Befehle, ihre Eingabeparameter sowie ihre Ausgabe detailliert aufzeichnet. Modulweise Ereignisprotokollierung muss jedoch im Voraus von einem Administrator für jedes Modul aktiviert worden sein. Dieser Nachweis wird in Ereignissen mit ID 4103 erfasst, die im Ereignisprotokoll von Microsoft Windows PowerShell Operational gespeichert sind.

Ein Beispiel für ein Modul-Protokoll findet sich unter [12].

Die Protokolldaten sollten nicht nur auf den einzelnen Rechner vorgehalten, sondern auf einen zentralen Logserver übermittelt werden [13, S. 108], denn die lokal gesammelten Daten können sowohl bei einer anti-forensischen Verschleierung durch einen Angreifer gelöscht werden als auch durch die schiere Datenmenge, die bei einer detaillierten Protokollierung anfällt, überschrieben werden.

Die an einer Stelle gesammelten Daten können zudem auf ungewöhnliche Muster hin analysiert werden, etwa: ein normaler niedrig-privilegierter Benutzerzugang führt mit PowerShell Aktionen auf zehn unterschiedlichen Rechnern aus [13, S. 89-91].

Wenn ein PowerShell-Skript Befehle oder Techniken enthält, die von Microsoft als verdächtig eingestuft werden, wird ab PowerShell 5 ein Protokolleintrag auf Warnniveau erstellt – es sei denn, diese Funktion wurde explizit deaktiviert. Es ist zu beachten, dass Microsoft diese Standardprotokollierung verdächtiger Skripte nicht als Sicherheitsmerkmal betrachtet [7].

Skriptblock-Protokollierung

In PowerShell ist ein Skriptblock die Basisebene des ausführbaren Codes [14]. Ein Skriptblock kann ein interaktiv eingegebener Befehl sein, der dem PowerShell-Interpreter über einen Parameter übergeben wird – oder Code, der in einer Funktion gekapselt ist. Bevor PowerShell verschleierten Quelltext (obfuscated code) ausführt, muss es ihn natürlich dekodieren. Nachdem der Code dekodiert wurde, kann seine unverschleierte Form an ein Ereignisprotokoll gesendet werden, bevor der Code tatsächlich ausgeführt wird [15].

Script Block Logging, das mit PowerShell-Version 5 eingeführt wurde, tut genau das und hat Verteidigern ein neues Werkzeug an die Hand gegeben, um aufzudecken, was obfuskierter Code tatsächlich macht [16]. Damit hat Microsoft erstmals das ausführliche Protokollieren von Skripten ermöglicht.

PowerShell-Version 5 ist auf Windows 10 vorinstalliert und kann auf Windows Server 2012 (R2) und 2008 R2 SP1, Windows 8.1 sowie 7 SP1 nachinstalliert werden [17] .

PowerShell Script Block Logging protokolliert den Inhalt aller PowerShell-Befehle, die verarbeitet wurden, einschließlich erst zur Laufzeit erzeugtem PowerShell-Code sowie wieder lesbar gemachtem, zuvor verschleiertem Quelltext. Dieser Mechanismus zeichnet auch dynamisch generierten Code auf, der darauf ausgerichtet ist, einer Erkennung zu entgehen [14]. Wenn die Skriptblock-Protokollierung aktiviert ist, protokolliert PowerShell die entsprechenden Ereignisse mit der ID 4104 im Protokoll Microsoft-Windows-PowerShell/Operational [16].

Script Block Logging gilt für jede Anwendung, welche die PowerShell-Bibliotheken verwendet, und kann über eine Gruppenrichtlinie oder die Registrierung aktiviert werden [16]. Die Ausgabe des ausgeführten Codes wird jedoch nicht protokolliert [7].

Abbildung 5: Skriptblock-Protokolleintrag für einen obfuskierten Befehl, vor der Ausführung (Quelle: [18, S. 9])

Im Standard verzeichnet Script Block Logging nur die erste Ausführung eines Skriptblocks. Es kann jedoch eine Option zum Protokollieren von Start-/Stop-Ereignissen für Skriptblockaufrufe aktiviert werden, sodass PowerShell jedes Mal Protokolleinträge erstellt, wenn eine Skriptblockausführung gestartet oder gestoppt wird [16].

Abbildung 6: Skriptblock-Protokolleintrag für einen zuvor obfuskierten Befehl, nach der Ausführung (Quelle: [18, S. 9])

Ebenfalls protokolliert wird der Aufruf der PowerShell-Komponenten in anderen Programmen als dem Kommandozeileninterpreter powershell.exe. Denn Angreifer können die Komponenten des .NET-Frameworks, die PowerShell-Skripte interpretieren, in eigene sowie andere erlaubte Prozesse laden und damit auch ohne den Aufruf von powershell.exe PowerShell-Skripte ausführen [19, S. 294].

Selbst wenn ein Angreifer nach der Attacke versucht, seine Spuren zu verwischen und seine Skripte löscht, kann ein vollständiges Ereignisprotokoll den im Klartext durchsuchbaren Quelltext seines Schadcodes enthalten. Der Sicherheitsforscher Sean Metcalf hat eine lange Liste von interessanten Suchbegriffen veröffentlicht, mit denen die erweiterten Protokolleinträge von PowerShell 5 durchforstet werden können [13, S. 75-87].

Beispielsweise kann so das Skript Invoke-Shellcode aus dem PowerSploit-Framework erkannt werden. PowerSploit wurde 2012 von Matt Graeber veröffentlicht; es war das erste für Windows PowerShell geschriebene Framework, das öffentlich verfügbar war [13, S. 17]. Invoke-Shellcode demonstriert die offensiven Möglichkeiten, die PowerShell und das darunter liegende .NET-Framework bieten: Das Skript ermöglicht es, vom Angreifer erzeugten Schadcode in den Speicherbereich eines anderen Prozesses zu injizieren und dort auszuführen [13, S. 17]. Aufrufe von Invoke-Shellcode können etwa in Skriptblock-Protokollen durch Suche nach folgenden Zeichenketten gefunden werden [6, S. 30-31]:

  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
  • System.MulticastDelegate
  • System.Reflection.CallingConventions.

Während einerseits die Protokollierung jedes Skriptblocks den Einblick in das vertiefen kann, was auf dem System mit PowerShell passiert, können andererseits sensible Daten an Orten landen, die für normale Benutzer lesbar sind. Damit würde das Sicherheitsziel Vertraulichkeit dem Ziel Integrität geopfert. PowerShell-Logging-Daten von sensiblen Systemen könnten es einem Angreifer ermöglichen, seine Privilegien zu erhöhen [18, S. 10]. Als Lösung bietet Microsoft Protected Event Logging an, das optional Anmeldeinformationen und andere vertrauliche Daten mit der Cryptographic Message Syntax – einem Standard für kryptographisch gesicherte Nachrichten – verschlüsselt, bevor sie protokolliert werden [20].

Ein Beispiel für ein Skriptblock-Protokoll findet sich unter [21].

Transkription

Transkription (Aufzeichnung) ist eine mögliche Lösung, um eine vollständige Zusammenfassung dessen zu erhalten, was in einer PowerShell-Sitzung geschieht: Transkription protokolliert alle Befehle in jener Form, in der sie eingegeben wurden, sowie die daraus resultierende Ausgabe, genauso wie sie auf dem Bildschirm angezeigt wurde – als ob jemand über die Schulter schaut und mitschreibt [16].

Dies bedeutet jedoch, dass Code von aufgerufenen Skripten oder Ausgaben, die ins Dateisysteme geschrieben wurden, nicht aufgezeichnet werden. Windows speichert Transkripte je nach Benutzer und Sitzung in verschiedene Textdateien und ergänzt optional Zeitstempel und andere Metadaten, die die Analyse zu erleichtern. Im Vergleich zu Log-Einträgen sind Transkripte speichereffizienter, können komprimiert und mit Standard-Textmanipulationswerkzeugen wie grep überprüft werden.

Vor PowerShell-Version 5 konnte die Transkription einer Sitzung mit dem Befehl Start-Transcript manuell gestartet werden. Nicht transkribiert wurden allerdings Remoting-Sitzungen sowie Sitzungen, die nicht direkt im Kommandozeileninterpreter powershell.exe laufen. War automatische Transkription gewünscht, musste der Befehl zum Aktivieren der Transkription in das Startprofil jedes Systems aufgenommen werden, und ein Angreifer konnte die Transkription einfach durch den Befehl Stop-Transcript außer Kraft setzen [7].

PowerShell 5 verbessert die bestehende Lösung: Die Transkription kann nun bequem und manipulationssicher über eine Gruppenrichtlinie oder in der Registrierung aktiviert werden und protokolliert alle PowerShell-Sitzungen unabhängig vom Host. Der Dateiname eines Transkripts beginnt mit PowerShell_transcript, enthält den Namen des Computers, einen Hash zur Vermeidung von Dateinamenskollisionen und eine detaillierte Startzeit. Optional können im Transkript jedem Befehl eine Kopfzeile mit einem Zeitstempel hinzugefügt werden.

Transkripte werden standardmäßig in den Dokumentenordner des aktuellen Benutzers geschrieben, aber jeder Pfad auf dem lokalen System oder im lokalen Netzwerk kann als Zielverzeichnis konfiguriert werden. Es wird empfohlen, Transkripte auf eine zentrale Netzwerkfreigabe auszugeben, die so konfiguriert wurde, dass sie nur beschrieben werden kann; dort können Angreifer Transkripte nicht einfach löschen.

Ein Beispiel für ein PowerShell-Transkript findet sich unter [22].

Arbeitsspeicher

Eine der wichtigsten Techniken für eine detaillierte forensische Untersuchung von PowerShell-Angriffen ist die Analyse des als Datei gesicherten Arbeitsspeicherinhalts eines kompromittierten Rechners mit einem Arbeitsspeicher-Forensik-Framework [4, S. 10].

Die Autoren von des Angriffswerkzeugs PowerShell Empire legen es etwa bewusst darauf an, dass der Empire-Agent im Arbeitsspeicher unverschlüsselt im Quelltext abrufbar ist und ausgeführte Aktionen entschlüsselt werden können. Dadurch sollen Incident Responder darauf trainiert werden, routinemäßig eine Arbeitsspeicheranalyse durchzuführen [5, S. 50].

Der Sicherheitsdienstleister Symantec hat in seinem Ende 2016 erschienenen Bericht „The Increased Use of PowerShell in Attacks“ ausgewertet [6, S. 11], von welchen Prozessen aus jeweils PowerShell-Skripte gestartet wurden, die nicht zuvor von E-Mail-Filtern oder Signatur-basiert ausgefiltert wurden und so von Symantecs verhaltensbasiertem Malwareschutz auf dem Zielrechner untersucht werden konnten, wie in Tabelle 1 dargestellt.

Dabei zeigt sich, dass bei allen (guten wie bösartigen) untersuchten Skripten 55 Prozent durch cmd.exe, also von der Standard-Kommandozeile von Windows aus, gestartet wurden – bei den als bösartig klassifizierten Skripten wurden 95 Prozent auf diese Weise ausgeführt [6, S. 11].

In einem früheren Artikel wurde beschrieben, wie die Befehlshistorie dieser klassischen Kommandozeile über Arbeitsspeicher-Forensik ausgelesen werden kann.

Tabelle 1: Elternprozesse von PowerShell-Skripten

Elternprozess Anteil bei bösartigen PowerShell-Skripten Anteil bei allen PowerShell-Skripten
cmd.exe 95,04 % 54,99 %
wmiprvse.exe 2,88 % 1,86 %
powershell.exe 0,84 % unter 1 %
explorer.exe 0,40 % 4,11 %
windowsupdatebox.exe 0,22 % 2,48 %
taskeng.exe 0,11 % 2,04 %
winword.exe 0,07 % 1,85 %
msiexec.exe 0 % 7,91 %
excel.exe 0 % 5,39 %
msaccess.exe 0 % 3,74 %

Quelle: [6, S. 11]

Wenn PowerShell vom Startmenü aus aufgerufen wird, startet es als untergeordneter Prozess von explorer.exe. Bei den meisten PowerShell-Angriffen wird PowerShell jedoch mit dem Befehlszeileninterpreter cmd.exe gestartet [6, S. 11]. Darüber hinaus kann der Großelternprozess (jener Prozess, der den Prozess gestartet hat, der schließlich PowerShell ausführt) ein Indicator of Compromise (IOC) sein, also ein bekanntes Anzeichen für einen Einbruch.

Wenn beispielsweise der Prozess cmd.exe, der powershell.exe gestartet hat, vom Textverarbeitungsprogramm winword.exe oder von Scripting-Komponenten wie mshta.exe oder wscript.exe aufgerufen wird, ist dies höchst verdächtig [9]. Ein ähnliches Zeichen für einen Angriff ist ein von PowerShell initiierter PowerShell-Prozess, “because attackers will often nest encoded payloads as command lines, the net result is a multilevel [PowerShell] process tree” [10, S. 14].

Ein in JScript oder VBScript geschriebenes Skript, das PowerShell aufruft und die Standard-Rechneranwendung von Windows startet, erzeugt beispielsweise den in der folgenden Abbildung gezeigten Prozessablauf. Der Skriptinterpreter WScript.exe ist dabei der Elternprozess für PowerShell, das wiederum der Elternprozess für conhost.exe ist, welches schließlich die Rechenanwendung calc.exe startet [9].

Abbildung 7: Ablauf eines Prozessstarts für ein Beispielskript (Quelle: [9])

Die Incident-Response-Analysten Chad Tilbury und Jaron Bradley des Sicherheitsdienstleisters CrowdStrike haben in einer Webpräsentation Wege aufgezeigt, wie unter Bezug auf die Vorarbeiten von Stevens und Casey Details über lokal ausgeführte PowerShell-Befehle aus dem Arbeitsspeicher ermittelt werden können [23].

Aus dem conhost.exe-Prozess, der zur selben Zeit wie powershell.exe gestartet wurde, kann mit der Methode von Stevens/Casey ausgelesen werden, welche Parameter an PowerShell übergeben wurden.

Abbildung 8: Prozessbaum bei der Kommandozeile und bei PowerShell (Quelle: [23, S. 17])

Komplette PowerShell-Skripte können aus einem Speicherabbild des Prozesses powershell.exe wiederhergestellt werden, der die Dateinamen aller ausgeführten Skripte sowie die Skripte selbst vollständig Unicode-enkodiert enthält [23, S. 22].

Die Namen der Skripte können durch eine Suche im Speicherabbild nach dem regulären Ausdruck: \.ps1$ gefunden werden.

Abbildung 9: Wiederherstellung von Skriptnamen aus powershell.exe (Quelle: [23, S. 24])

Die Inhalte der Skripte wiederum können durch die Suche nach mutmaßlich interessanten PowerShell-Befehlen im powershell.exe-Prozessabbild gefunden werden.

Die in den Skripten des Post-Exploitation-Frameworks PowerSloit am häufigsten verwendeten Kombinationen von PowerShell-Verben und Nomen sind etwa [23, S. 22]:

Out-Null, Add-Member, Add-SignedIntAsUnsigned, New-Object, Write-Verbose, Get-DelegateType, Get-ProcAddress, Write-Output, Write-Warning, Write-BytesToMemory

Nach ihnen kann im Prozessabbild ebenso gesucht werden wie nach Hinweisen auf andere bekannte Angriffswerkzeuge wie Mimikatz, das zum Diebstahl von Anmeldedaten dient [13, S. 37].

Abbildung 10: Wiederherstellung von Skriptinhalten aus powershell.exe (Quelle: [23, S. 23])

Kazanciyan und Hastings fokussierten sich in ihrem Whitepaper bei der Arbeitsspeicher-Analyse auf PowerShell-Remoting-Sitzungen über den WinRM-Dienst, die der Angreifer also von einem anderen Rechner aus gestartet hat – und die dadurch noch schwieriger als lokale Sitzungen zu untersuchen sind. Dabei stellten sie fest, dass bei Remoting-Sitzungen einer der Windows-Servicedienstprozesse svchost.exe eine Instanz von c:\windows\system32\wsmprovhost.exe startet, dem Host-Prozess für WinRM-Erweiterungen [1, S. 6].

Falls der PowerShell-Befehl eine interaktive Sitzung beginnt oder ein eingebautes Cmdlet startet, laufen diese direkt im Prozess wsmprovhost.exe. Falls der Befehl ein separates Binärprogramm startet, wird dieses als Kindprozess von wsmprovhost.exe geladen.

Egal, was der PowerShell-Befehl bewirkt, im Prozessspeicher von wsmprovhost.exe bleiben PowerShell-Objekte und Fragmente des Remoting-Protokolls erhalten. Jedoch beendet sich wsmprovhost.exe sofort nach Ende einer Remoting-Sitzung, also in der Praxis zu schnell, als dass von einem Forensiker bereits ein Arbeitsspeicherabbild erstellt worden sein könnte [1, S. 7].

Vielversprechender für eine Untersuchung ist jene Instanz des Windows-Servicedienstprozesses svchost.exe, die wsmprovhost.exe gestartet hatte; sie wird nach Ende einer PowerShell-Sitzung nicht beendet. Der Speicherbereich dieses Dienstprozesses kann Fragmente des Remoting-Protokolls enthalten, aus denen PowerShell-Befehle und Cmdlets im Klartext ausgelesen werden können [1, S. 8].

Folgende Tabelle zeigt im Überblick, aus welchen Prozessen und Betriebssystem-Artefakten Beweismittel über Remoting-Sitzungen in welchem Umfang und bis zu welchem Zeitpunkt entnommen werden können.

Tabelle 2: Beweismittel zu PowerShell-Remoting-Sitzungen

wsmprovhost.exe svchost.exe Kernelspeicher Auslagerungsdatei
Beweismittel Beste Quelle für Befehlshistorie und Ausgaben von Befehlen Fragmente der Eingaben und Ausgaben über Remoting Fragmente der Eingaben und Ausgaben über Remoting Fragmente der Eingaben und Ausgaben über Remoting
Umfang Inhalte einer einzelnen Remoting-Sitzung Abhängig von der Zahl der Remoting-Sitzungen Abhängig von der Zahl der Remoting-Sitzungen Abhängig von der Nutzung des Arbeitsspeichers
Maximale Lebensdauer Ende der Remoting-Sitzung Neustart Neustart Variiert – kann einen Neustart überleben

Quelle: [4, S. 13]

Prefetch-Dateien

Der so genannte Prefetch-Mechanismus dient seit Windows XP dazu, den Startvorgang des Betriebssystems und darauf laufender Anwendungen zu beschleunigen [2, S. 129]. Der Applikationsprefetcher prüft 10 Sekunden nach dem Start einer Anwendung unter anderem, wie sie aufgerufen wurde und welche weiteren Komponenten sie nachgeladen hat. Er speichert seine Ergebnisse in Dateien mit der Endung .pf im Verzeichnis \Windows\Prefetch des Systemlaufwerks [3, S. 130]. Deswegen dienen die Prefetch-Dateien Forensikern häufig als Nachweis, dass Programme auf dem untersuchten Rechner vorhanden waren – selbst, wenn sie von einem Wechseldatenträger wie einem USB-Stick gestartet oder inzwischen deinstalliert wurden [3, S. 131]. Beim Betrachten der Inhalte einer Prefetch-Datei kann folgendes nachgewiesen werden: der komplette Pfad der Anwendung; wann die Anwendung das erste und das letzte Mal gestartet wurde; wie oft sie ausgeführt wurde; auf welche Dateien die Anwendung in den ersten zehn Sekunden ihrer Ausführung zugegriffen hat [1, S. 5].

Die Prefetch-Datei für den PowerShell-Interpreter powershell.exe kann die Pfade zu ausgeführten PowerShell-Skripten enthalten, wenn die Skripte innerhalb von 10 Sekunden nach Interpreterstart aufgerufen wurden, etwa indem sie der Angreifer direkt als Parameter übergeben hat. Befehl auf der Kommandozeile etwa: powershell.exe -File C:\temp\persistence.ps1

Beim Untersuchen eines möglichen PowerShell-Angriffs sollte der Forensiker also den Zeitstempel der Erstellung sowie der letzten Ausführung der Prefetch-Datei des PowerShell-Interpreters prüfen und den Inhalt der Datei auf Pfade zu PowerShell-Skripten mit der Endung .ps1 durchsuchen [1, S. 5-6].

Bei Remoting entsteht auf dem Zielrechner ebenfalls eine Prefetch-Datei – für wsmprovhost.exe [24, S. 2].

Registrierungsdatenbank

Die Windows-Registrierungsdatenbank (auch Registry genannt) gilt gemeinhin als für die Computer-Forensik unschätzbar wertvolle Quelle, weil sie eine umfassende Datenbank ist, in der sowohl Einstellungen aller integrierten Systemdienste wie auch der zusätzlich installierten Anwendungen zentral gespeichert werden [3, S. 124].

Laut dem Whitepaper von Kazanciyan/Hastings werden bei PowerShell-Angriffen in der Registrierungsdatenbank keine Einträge erzeugt, die auf die Ausführung von konkreten Skripten in PowerShell oder eine Fernsteuerung über dessen Remoting-Funktionalität hindeuten [1, S. 4].

Neuere forensische Registry-Artefakte wie Amcache (Registrierungsdatei Amcache.hve) und Shimcache (auch bekannt als AppCompatCache, der Daten zur Anwendungskompatibilität speichert) [25] enthalten jedoch bei Remoting – auf dem Ausgangssystem für powershell.exe und auf dem Zielsystem für wsmprovhost.exe – zeitbezogene Metadaten, zum Beispiel über die erste Ausführung [24, S. 2].

 
Der nächste Artikel dieser Reihe beschreibt, durch welche Maßnahmen IT-Sicherheitsverantwortliche ihre Organisationen vor PowerShell-Angriffen schützen können.

Über den Autor

Frank Ully studierte Technische Redaktion an der Hochschule Karlsruhe – Technik und Wirtschaft und schloss das Studium als Diplom-Technikredakteur ab (inzwischen: Master Kommunikation und Medienmanagement). Noch während seines Studiums baute er die Abteilung Unternehmenskommunikation und Dokumentation eines Berliner Softwareherstellers auf und leitete sie einige Jahre. Später betreute Frank Ully dort interne Anwendersysteme und war für die IT-Sicherheit verantwortlich. Berufsbegleitend schloss er den Masterstudiengang Security Management mit Spezialisierung auf IT-Sicherheit an der Technischen Hochschule Brandenburg ab und zertifizierte sich zum Offensive Security Certified Expert (OSCE) sowie Offensive Security Certified Professional (OSCP). Frank Ully verfügt zudem über die Zertifikate GIAC Reverse Engineering Malware (GREM) sowie Linux Professional Institute Certification Level 3 (LPIC-3) und ist zertifizierter OSSTMM Professional Security Tester (OPST). Zum Ende seines Masterstudiums begann er im November 2017 seine Arbeit als Penetration Tester und Security Consultant bei Oneconsult Deutschland. Seit April 2018 ist Frank Ully Senior Penetration Tester & Security Consultant.

Über Oneconsult

Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cyber Security Services Partner mit Büros in der Schweiz und Deutschland und 1500+ weltweit durchgeführten Security-Projekten.

Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cyber Security-Spezialisten mit 35+ hochqualifizierten Cyber Security Experten, darunter zertifizierte Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Incident Response & IT Forensics Expertenteams von Oneconsult zählen.

www.oneconsult.com


[1]: https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf
[2]: https://jpcertcc.github.io/ToolAnalysisResultSheet/
[3]: A. Geschonneck, Computer-Forensik: Computerstraftaten erkennen, ermitteln, aufklären, 5. Auflage, Heidelberg: dpunkt, 2011.
[4]: https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks.pdf
[5]: http://www.slideshare.net/harmj0y/building-an-empire-with-powershell
[6]: https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/increased-use-of-powershell-in-attacks-16-en.pdf
[7]: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html
[8]: https://cdn.securelist.com/files/2015/10/Pontiroli_Martinez-VB2015-2.pdf
[9]: http://securityaffairs.co/wordpress/65570/hacking/powershell-attacks.html
[10]: https://www.carbonblack.com/wp-content/uploads/2016/04/Cb-Powershell-Deep-Dive-A-United-Threat-Research-Report-1.pdf
[11]: http://dansolutions.com/wp-content/uploads/2015/10/DerbyCon-2015-Metcalf-RedvsBlue-ADAttackAndDefense-Presented-Final.pdf
[12]: https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/powershell-logging-appendix-a.pdf
[13]: https://adsecurity.org/wp-content/uploads/2016/05/BSidesCharm-2016-PowerShellSecurity-Defending-the-Enterprise-from-the-Latest-Attack-Platform-FINAL.pdf
[14]: https://blogs.technet.microsoft.com/srd/2015/06/10/advances-in-scripting-security-and-protection-in-windows-10-and-powershell-v5/
[15]: https://blog.stealthbits.com/ways-to-detect-and-mitigate-powershell-attack
[16]: https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
[17]: https://blogs.msdn.microsoft.com/powershell/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available/
[18]: https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/2017/ncc_group_whitepaper-managing-powershell-in-a-corporate-environment.pdf
[19]: D. Jones, J. Hicks and R. Siddaway, PowerShell in Depth, 2nd edition, Shelter Island: Manning, 2015.
[20]: https://docs.microsoft.com/en-us/powershell/wmf/5.0/audit_cms
[21]: https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/powershell-logging-appendix-b.pdf
[22]: https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/powershell-logging-appendix-c.pdf
[23]: https://vimeo.com/100442934
[24]: https://digital-forensics.sans.org/media/SANS_Poster_2018_Hunt_Evil_FINAL.pdf
[25]: https://www.andreafortuna.org/cybersecurity/amcache-and-shimcache-in-forensic-analysis/
[26]: https://www.eventsentry.com/blog/2018/01/powershell-p0wrh11-securing-powershell.html