PowerShell IV – Arbeitsspeicher-Forensik

Dies ist der vierte 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 führt allgemein in die Arbeitsspeicher-Forensik ein, die eine relativ neue Untersuchungsmethode für Incident Responder und Forensiker gegen moderne Bedrohungen wie PowerShell-Angriffe ist.
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.

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.

Arbeitsspeicher-Forensik

Arbeitsspeicher-Forensik befasst sich mit dem Finden und Auswerten von forensischen Artefakten aus dem Arbeitsspeicher eines Computers. Der Arbeitsspeicher (Random Access Memory, RAM) enthält wichtige Informationen über den Laufzeitzustand des Rechners, solange er mit Strom versorgt wird. Durch das Erstellen eines Speicherabbildes und seine Analyse auf einem anderen System kann rekonstruiert werden: welche Anwendungen auf dem Rechner liefen (Prozesse), auf welche Dateien sie zugriffen, welche Netzwerkverbindungen aktiv waren ^{[4, S. 571]}.

Memory-Forensik gilt inzwischen als integraler Bestandteil einer forensischen Untersuchung, weil im RAM Beweismittel gefunden werden können, die bei einer klassischen Post-mortem-Analyse nicht mehr erhoben werden können oder die sich ausschließlich im Arbeitsspeicher befinden ^{[2, S. 20]}.

Arbeitsspeicher-Akquisition

Arbeitsspeicher-Akquisition oder Memory Imaging bezeichnet den Vorgang, eine Bit für Bit identische Kopie des Arbeitsspeichers zu erzeugen, und hat sich zu einem der ersten Schritte bei forensischen Untersuchungen entwickelt ^[1]. Neben der forensischen Kopie des physischen Arbeitsspeichers sollte auch eine Kopie des virtuellen Arbeitsspeichers in Form der Auslagerungsdatei pagefile.sys erstellt werden. In die Auslagerungsdatei werden, wie der Name sagt, Daten ausgelagert, falls der physisch verfügbare Speicher an seine Kapazitätsgrenzen stößt ^{[2, S. 20]}.

Die Sicherheitsforscher Walters und Petroni haben 2007 nachgewiesen, dass im Arbeitsspeicher Daten eines Prozesses auch noch Stunden nach dessen Ende verfügbar sind. Der Arbeitsspeicher kann somit wesentliche Beweismittel wie hergestellte Netzwerkverbindungen, ausgeführte Prozesse und Passwörter enthalten ^{[3, S. 4]}.

Folgende Tabelle aus der damaligen Arbeit von Walters/Petroni zeigt anhand von zwei Rechnern mit 256 und 512 MB RAM, dass ein Großteil des Arbeitsspeicherinhaltes über einen relativ langen Zeitraum unverändert bleibt.

Tabelle 1: Veränderung des Arbeitsspeicherinhalts

	Rechner mit 256 MB RAM			Rechner mit 512 MB
Minuten	Differenz	Gesamt	% Gleich	Differenz	Gesamt	% Gleich
0	0	268.435.456	100,00	0	536.870.912	100,00
5	14.175.676	268.435.456	94,72	10.059.162	536.870.912	98,12
10	16.253.700	268.435.456	93,94	12.272.451	536.870.912	97,71
60	25.731.960	268.435.456	90,41	17.804.666	536.870.912	96,68
120	54.416.944	268.435.456	79,73	20.542.693	536.870.912	96,17
900	70.430.438	268.435.456	73,76	77.252.490	536.870.912	85,61

Quelle: [3, S. 4]

Arbeitsspeicherabbilder sollten auf dem untersuchten Rechner niemals auf dessen Festplatte abgelegt werden, weil sie dabei forensische Artefakte in deren als frei markiertem Speicherbereich überschreiben können. Beim Anlegen eines Abbildes auf einem Wechseldatenträger oder einem Netzlaufwerk sollte der Forensiker darauf achten, dass sich etwaige Malware über diesen Weg nicht ausbreiten kann ^{[4, S. 571]}.

Zusätzlich zum Erstellen des Abbildes des kompletten Arbeitsspeichers ist abzuwägen, ob Kopien einzelner verdächtiger Prozesse gezogen werden. Bei der späteren Analyse kann dann mit handlicheren, bereits eingegrenzten Datenmengen gearbeitet werden ^{[5, S. 155]}.

Arbeitsspeicher-Analyse

Computer-Forensiker begannen erstmals Anfang der 2000er-Jahre, sich mit der Analyse des Arbeitsspeichers eines untersuchten Rechners zu befassen, als sich die Erkenntnis durchsetzte, dass über neue Schnittstellen ein Abbild des Speichers eines laufenden Systems erstellt werden konnte. Anstoß zu diesem neuen Ansatz war Malware, die mit bisherigen Techniken der digitalen Forensik nur sehr schwierig oder gar nicht entdeckt werden konnte ^{[6, S. 6]}. Wie in einem vorherigen Artikel beschrieben, bietet sich etwa Windows PowerShell durch seine enge Einbindung in Windows für bösartige Zwecke an, weil damit der Bedarf entfällt, eine Binärdatei auf der Festplatte abzulegen. Alle Befehle werden lediglich im flüchtigen Arbeitsspeicher ausgeführt. Damit wird nicht nur das Erkennen durch Malwarescanner erschwert – die Flüchtigkeit der Beweismittel behindert auch eine forensische Untersuchung.

Zum damaligen Zeitpunkt gab es jedoch keine spezialisierten Werkzeuge, um aus den Rohdaten in den erstellten Abbildern Informationen auszulesen, die im Kontext einer forensischen Untersuchung relevant waren. Forensiker nutzten in der Unix-Welt etablierte Programme zur Verarbeitung von Zeichenketten wie strings und grep, um interessante Stellen in den Speicherabbildern zu finden ^[7]. Diese Methode förderte relevante Details zutage – mit ihr konnte aber nicht rekonstruiert werden, von welchem Programm oder welchem Benutzer die gefundenen Daten stammten.

Diese Vorgehensweise wird als unstrukturierte Analyse bezeichnet, weil sie ein Speicherabbild als Folge von Bytes betrachtet. Sie wird noch heute eingesetzt, wenn ein Forensiker etwa nach Passwörtern oder Schlüsseln sucht.

Notwendig waren jedoch Werkzeuge, um eine strukturierte Untersuchung zu ermöglichen. Im Sommer 2005 richtete der Digital Forensic Research Workshop (DFRWS), eine Non-Profit-Organisation zur Vernetzung von Digital-Forensikern, einen Wettbewerb zur Untersuchung des Arbeitsspeichers aus (Memory Analysis Challenge). Der DFRWS veröffentlichte zwei Speicherabbilder von kompromittierten Windows-Systemen und forderte die Gemeinschaft der Sicherheitsforscher heraus, durch Auswerten des Arbeitsspeichers einen vorgegebenen Fragenkatalog über die Sicherheitsvorfälle zu beantworten ^[7].

Der Wettbewerb führte zur Publikation von zwei Werkzeugen, die der Arbeitsspeicherforensik den Weg geebnet haben: Der Sicherheitsforscher Chris Betz schrieb memparser ^[8]; George Garner und Robert-Jan Mora entwickelten KntList ^[9]. Mit beiden Werkzeugen war es erstmals möglich, aus den Rohdaten eines Arbeitsspeicherabbilds automatisiert auszulesen, welche Prozesse zum Zeitpunkt dessen Erstellung auf dem Rechner aktiv waren.

Bei der Arbeitsspeicher-Analyse können wie bei anderen forensischen Methoden zwei Einsatzszenarios unterschieden werden: die unmittelbare Live-Analyse auf einem laufenden System und die nachträgliche Post-mortem-Analyse auf einem Arbeitsspeicherabbild ^{[10, S. 90-91]}. Deren Vor- und Nachteile müssen jeweils gegeneinander abgewogen werden.

Bei der Live-Untersuchung liegt der Schwerpunkt auf raschen Ergebnissen. Akquisition und Analyse erfolgen in einem Schritt. Als Nachteile sind zu sehen, dass der Vorgang der Live-Analyse (nach dem Verlassen des Tatorts) nicht wiederholbar ist, in einer potentiell kompromittierten Umgebung stattfindet und der Analysevorgang selbst Beweismittel zerstören kann ^{[11, S. 9]}.

Die Post-mortem-Analyse fokussiert sich auf die Produktion der bestmöglichen Beweismittel. Akquisition und Analyse sind zwei aufeinander folgende Schritte; lediglich die Akquisition findet in einer nicht vertrauenswürdigen Umgebung statt. Die Analyse ist wiederholbar; die Werkzeuge, die dabei zum Einsatz kommen, sind nicht durch das Betriebssystem des untersuchten Rechners eingeschränkt.

Die Methodik zum Untersuchen von Arbeitsspeicherabbildern ähnelt der von klassischen Beweismitteln. Sobald der Arbeitsspeicher verlässlich gesichert wurde, werden Daten und Metadaten für die weitere Analyse rekonstruiert. Eine wesentliche Herausforderung liegt, wie bei anderen Techniken der digitalen Forensik, darin, sowohl Programmcode und Daten voneinander zu unterscheiden wie auch bösartigen Code und damit verbundene Daten von der viel größeren Menge an legitimen, gutartigen Daten zu trennen ^{[5, S. 124]}.

Durch Arbeitsspeicher-Forensik können Straftaten zeitlich (wann), relational (wer, was, wo) und funktionell (wie) aufgeklärt werden. Ebenso kann die Memory-Forensik dazu dienen, klassische anti-forensische Maßnahmen zu umgehen, wie selbstentpackenden Code oder das Überschreiben von Dateien auf der Festplatte ^{[12, S. 51]}.

Beim Untersuchen eines möglichen Schadcodes sind die wesentlichen Ziele: das Sammeln von Metadaten wie Prozessdetails und Netzwerkverbindungen; das Wiederherstellen des Programmcodes von jedem als interessant bewerteten Prozess, falls möglich; das Sammeln der verknüpften Daten für jeden als interessant bewerteten Prozess, etwa Schlüssel oder Zugangsdaten ^{[5, S. 124]}.

Die Arbeitsspeicher-Analyse hat sich zu einer der flexibelsten und umfassendsten Methoden für die digitale Forensik im Allgemeinen entwickelt. Darüber hinaus ist sie zu einem integralen Bestandteil der Incident Response geworden.

Werkzeuge zur Arbeitsspeicher-Akquisition

Unter Windows gibt es eine Vielzahl von Programmen für das Erstellen eines Speicherabbildes. Das bekannteste ist DumpIt, weil es einfach bedienbar und mit vielen Versionen von Windows kompatibel ist. Weitere verbreitete Akquisewerkzeuge sind Belkasoft RAM Capturer und Memoryze. ^[1]

Darüber hinaus bringt das Forensik-Framework Rekall eigene Akquisetools mit.

Ein Speicherabbild einer virtuellen Maschine kann häufig direkt mit der Virtualisierungssoftware angelegt werden. ^{[13, S. 35]}

Werkzeuge zur Arbeitsspeicher-Analyse

Volatility

Im März 2007 stellten die Sicherheitsforscher AAron Walters und Nick Petroni auf der Hacker-Konferenz Black Hat in Washington D.C. ein Memory-Forensik-Framework namens volatools vor ^[3], das ausschließlich mit Abbildern des Arbeitsspeichers von Windows-XP-Rechnern mit Service-Pack 2 funktionierte, jedoch bereits zahlreiche interessante Informationen aus den Rohdaten auslesen konnte ^[7]. Grundlage von volatools waren Ergebnisse ihrer richtungsweisenden Grundlagenforschung über Arbeitsspeicher-Forensik.

volatools wurde schließlich in Volatility umbenannt. Die im Dezember 2016 veröffentlichte aktuellste Version 2.6 unterstützt neben den neueren Microsoft-Betriebssystemen Windows Vista, 7, 8, 10 sowie Server von 2003 bis 2016 auch Linux-Speicherabbilder unterschiedlicher Kernel-Versionen sowie Mac-OSX-Abbilder seit dessen Version 10.5 Leopard ^[14].

Volatility hat sich inzwischen zu einem Standard-Framework an Werkzeugen für die unterschiedlichen Aufgaben bei der Memory-Forensik entwickelt, das unter der Open-Source-Lizenz GNU General Public License steht.

Die zentralen Komponenten von Volatility sind in der Skriptsprache Python geschrieben. Durch die Implementierung in Python kann das Framework von der Gemeinschaft der Sicherheitsforscher, in der sich diese Sprache großer Beliebtheit erfreut ^{[15, S. 81-83]}, leicht um neue Funktionen im Gewand von Erweiterungen ergänzt werden.

Die meisten modernen Betriebssysteme sind jedoch in C oder C++ geschrieben ^{[16, S. 73]}. Damit in Python die C-Datenstrukturen verarbeitet werden können, mit denen die Betriebssysteme etwa Prozesslisten und -informationen verwalten, bildet Volatility die Datenstrukturen in eigenen, VTypes genannten Datenstrukturen nach. In VTypes können vom Betriebssystem genutzte Datenstrukturen mit Namen, Positionen und Typisierung (etwa Zahl, Text-Zeichenkette oder Zeiger) definiert werden. Wenn Volatility in den Rohdaten des Arbeitsspeichers diese Strukturen findet, weiß das Werkzeug, wie es die zu Grunde liegenden Daten interpretieren muss ^{[17, S. 51-52]}.

Das Standardbuch zur Arbeitsspeicher-Analyse, „The Art of Memory Forensics” von Ligh et al., ^[17] beschreibt ausführlich die Entstehung von, die Konzepte hinter und den konkreten Einsatz des Kommandozeilenwerkzeugs Volatility.

Dennoch bleibt festzustellen, dass eine hohe Expertise notwendig ist, um die von Volatility ausgegebenen Informationen in den korrekten Zusammenhang mit anderen Ergebnissen der forensischen Untersuchung zu bringen. Es richtet sich daher hauptsächlich an Forscher aus dem universitären Umfeld und Sicherheitsexperten mit umfangreichem technischen Hintergrundwissen.

Rekall

Rekall ist eine Abspaltung (Fork) von Volatility. Der Hauptentwickler, der beim US-Konzern Google beschäftigte Michael Cohen, hat im Dezember 2011 eine erste Vorabversion von Rekall basierend auf dem Code von Volatility, noch unter dessen Namen veröffentlicht. Zwei Jahre später, im Dezember 2013, erschien Rekall als eigenständiges Werkzeug sowie integriert in Googles Rapid Response-Tool GRR ^{[18, S. 42]}. Zum damaligen Zeitpunkt unterstützte es mit Linux und Mac OSX mehr Betriebssysteme als der Vorgänger Volatility ^{[19, S. 6]}. Die aktuellste Version 1.7.1 erschien im November 2017 ^[20].

Seit der Abspaltung wurde praktisch der komplette Quelltext neu geschrieben mit Fokus auf Geschwindigkeit, Codequalität, Verlässlichkeit und schnelle Integrierbarkeit als Funktionsbibliothek in eigene Werkzeuge.

Rekall unterscheidet sich dadurch von Volatility, dass es die Betriebssystem-spezifischen Profile, die es zum Verarbeiten eines Arbeitsspeicherabbilds benötigt, nicht fest mit ausliefert, sondern erst beim Öffnen eines Speicherabbilds aus einem öffentlichen Verzeichnis im Web mit mehr als 200 Profilen lädt. Zudem erkennt Rekall das benötigte Profil automatisch, anders als Volatility, dem der Anwender das Betriebssystem des Speicherabbilds, dessen Version und Architektur (32- oder 64-bit) manuell angeben muss ^{[21, S. 4]}.

Durch diesen Ansatz ist Rekall schneller, verlässlicher gegen Methoden der Anti-Forensik wie das bewusste Überschreiben zentraler Speicherbereiche durch Malware und robuster gegenüber Änderungen neuerer Windows-Versionen. Denn die Profile enthalten konkrete Adressen relevanter Speicherbereiche mit wichtigen Metadaten, während Volatility die Adressen nur durch Signaturverfahren errät ^{[19, S. 5]}.

Rekall baut auf dem interaktiven Python-Kommandozeileninterpreter IPython auf, wodurch es neben dem klassischen, pro Befehl einmaligen Aufruf wie Volatility auch einen interaktiven Modus bietet, bei dem der Forensiker den aktuellen Anwendungskontext nicht immer wieder verlassen muss.

Zudem bietet Rekall eine Weboberfläche, die einfacher zu benutzen ist – aber im Gegensatz zu den Kommandozeilenoberflächen schlecht automatisiert benutzt werden kann.

Eine in Python für Rekall geschriebene Erweiterung funktioniert in allen drei Oberflächen, ohne dass der Erweiterungsautor sich selbst um die jeweils notwendige unterschiedliche Formatierung kümmern müsste ^{[21, S. 8]}.

Rekall hat inzwischen seinen Fokus von der reinen Memory-Analyse auf den kompletten Incident-Response-Zyklus erweitert: es unterstützt neben der Analyse auch die Memory-Akquisition und Live-Analyse ^{[22, S. 20]}.

Zur Arbeitsspeichersicherung bietet das Rekall-Projekt passende Werkzeuge für alle bei der Analyse unterstützten Betriebssysteme: für Windows das Tool WinPmem, für Linux pmem und für MacOSX MacPmem ^[23].

Dadurch kann Rekall mit zwei Befehlen zur Live-Analyse verwendet werden, unter Windows etwa: mem.exe –l, um den Akquisitionstreiber zu laden, gefolgt von rekal.exe -f \\.\pmem, um auf die bereitgestellte Schnittstelle zum Arbeitsspeicher zuzugreifen. (rekal.exe mit nur einem L ist kein Schreibfehler.)

In der Zwischenzeit wurde Rekall selbst um einen Parameter zur Live-Analyse ergänzt: Beim Aufruf von rekal.exe --live lädt Rekall automatisch die benötigten Akquisitionswerkzeuge.

FireEye Redline

FireEye Redline (vormals Mandiant Redline) ist die benutzerfreundlichste kostenlose Software zur Arbeitsspeicher-Analyse. Eine grafische Benutzeroberfläche führt den Anwender durch den Prozess der Bewertung des aktuellen Systems oder eines vorhandenen Arbeitsspeicherabbildes, um mögliche Infektionen zu finden.

Redline versucht, durch Heuristiken schnell auf potenziell schädliche Objekte und bekannte Indicators of Compromise (IOCs) hinzuweisen ^[24].

Das Windows-Programm bietet eine Reihe von Untersuchungsschritten, um potentielle Malware zu finden, indem es Prozesse, Netzwerkverbindungen, Speicherbereiche, Handles, Hooks und Treiber überprüft. Als Nachteil muss jedoch die lange Analysedauer gewertet werden ^[25].

Wiederherstellung der Befehlshistorie

Richard M. Stevens und Eoghan Casey haben 2010 den Fachartikel „Extracting Windows command line details from physical memory“ veröffentlicht, in dem sie jene Datenstrukturen im Arbeitsspeicher diskutieren, mit denen Windows XP die Befehlshistorie der Kommandozeile verwaltet ^[26].

Die klassische Befehlszeile von Microsoft Windows über das Konsolenprogramm cmd.exe wird von Angreifern häufig eingesetzt, um mit den eingebauten Möglichkeiten des Systems, bereits installierten Anwendungen oder neu aufgebrachten Binärdateien ihre Ziele zu erreichen. Im Gegensatz etwa zur Bash-Shell auf Unix-artigen Betriebssystemen ermöglicht die Windows-Befehlszeile nicht das Schreiben einer Befehlshistorie in eine Datei. Deswegen ist die Historie nur verfügbar, solange das Fenster mit dem Kommandoprompt geöffnet ist. Dies hat es unter Windows zunächst für Forensiker unmöglich gemacht, nachträglich die Handlungen von Angreifern auf der Befehlszeile zu rekonstruieren ^{[17, S. 523]}.

Aus der Befehlshistorie können wichtige Informationen gelesen werden, etwa welche Programme mit welchen Parametern aufgerufen wurden, welche Ordner und Dateien angesehen oder bearbeitet wurden. Ebenso können Merkmale ermittelt werden, die den Angreifer möglicherweise identifizieren, etwa Domainnamen oder IP-Adressen. In manchen Fällen kann die Befehlshistorie als einzige Quelle Hinweise auf gelöschte Dateien oder verdächtige Aktivitäten liefern ^{[26, S. 58]}.

Für die Befehlshistorie benutzt die Windows-Befehlszeile den DOSKEY-Befehl. DOSKEY war ursprünglich eine eigenständige Anwendung, die dann in das Konsolenprogramm der Windows-Befehlszeile integriert wurde. Ihre Datenstrukturen können auch nach dem Ende des Kommandozeileninterpreters im Arbeitsspeicher gefunden werden, wie Stevens und Casey in ihrer Arbeit zeigen.

Die Windows-Befehlszeile ist zwar textbasiert, muss aber mit dem Grafiksubsystem zusammenarbeiten, etwa um auf Größenänderungen ihres Konsolenfensters oder auf Kopieren und Einfügen von Text zu reagieren. Unter Windows XP dient das Client/Server Runtime Subsystem csrss.exe, das mit den höchstmöglichen Rechten als SYSTEM-Prozess läuft, als Schnittstelle zwischen textbasierten Konsolenanwendungen und der grafischen Benutzeroberfläche. Beginnend mit Windows 7 hat Microsoft diese Aufgaben auf den Console Host Process conhost.exe verlagert, der mit den Rechten des angemeldeten Benutzers arbeitet ^{[17, S. 524]}.

Das Konsolenprogramm cmd.exe ist nur der Client, der für die Ein- und Ausgaben verantwortlich ist, die je nach Betriebssystemgeneration der Serverdienstprozess csrss.exe oder conhost.exe verarbeitet. Dieser Dienstprozess wird erst beendet, wenn sich der Benutzer von Windows abmeldet. Das heißt, selbst nach dem Schließen der Befehlszeile kann ihre Historie samt fast allen Benutzereingaben und Programmausgaben aus dem Speicherbereich des jeweiligen Serverprozesses wiederhergestellt werden ^{[26, S. 62]}.

Eine einfache manuelle Untersuchung kann im Erstellen eines Speicherabbildes des Prozesses csrss.exe bzw. conhost.exe (Windows XP bzw. spätere Versionen) bestehen, sowie der anschließenden Suche nach interessanten Zeichenketten wie „.exe“, „cmd.exe“, „cmd /c“, „https://“, „https://”, „ftp -i“ ^{[27, S. 18]}.

Jedoch ist hier nach einer umfassenderen Unterstützung des Forensikers durch Memory-Analyse-Frameworks zu streben. Zu diesem Zweck wurden zwei Erweiterungen entwickelt: cmdscan und consoles, die ursprünglich für Volatility geschrieben und von dessen Abspaltung Rekall übernommen wurden.

Die Erweiterung cmdscan wurde aufbauend auf der Forschung von Stevens und Casey von einem der Autoren des „Malware Analyst’s Cookbook“, ^[4] Michael Hale Ligh, programmiert.

Stevens und Casey haben den kompletten Speicherbereich von csrss.exe nach bekannten Standardwerten abgesucht, jeden Treffer als eine bestimmte Datenstruktur behandelt und darauf Plausibilitätsprüfungen angewendet. Auf diese Weise können eingegebene Befehle rekonstruiert werden ^{[17, S. 531]}.

Einige Jahre nach Stevens und Casey setzte sich bei den Memory-Forensikern die Erkenntnis durch, dass sich in den Speicherabbildern der Dienstprozesse noch weitere Artefakte verbergen. Für eine forensische Untersuchung sind nicht nur die Eingaben eines Angreifers interessant, sondern auch die Ausgaben, welche die von ihm ausgeführten Programme auf dem untersuchten System erzeugen. Die Erweiterung consoles, ebenfalls von Ligh entwickelt, nutzt andere Datenstrukturen als cmdscan, um alle Ein- und Ausgaben im Konsolenfenster wiederherzustellen ^{[17, S. 532-534]}.

Folgende Abbildung vergleicht die Rekonstruktion einer Befehlshistorie mit den Volatility/Rekall-Erweiterungen cmdscan sowie consoles und zeigt den zusätzlichen Kontext, den consoles wiederherstellen kann.

Im April 2017 haben mehrere Forensikexperten ein PowerShell-Skript zur Speicheranalyse von Eingabeaufforderungen wie der traditionellen cmd.exe oder PowerShell eingeführt. Get-ShellContent lädt eine modifizierte Variante des String-Extraktionstools strings2 direkt in den Speicher und ist in der Lage, alle Zeichenketten eines beliebigen laufenden oder gesicherten Prozesses wiederherzustellen. Das Skript kann alle Eingaben und Ausgaben der untersuchten Eingabeaufforderung extrahieren ^[28].

Der nächste Artikel dieser Reihe stellt vor, mit welchen Methoden Incident Responder und IT-Forensiker PowerShell-Angriffe untersuchen können – darunter die Arbeitsspeicher-Analyse.

Ü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.