PowerShell VI – Verteidigung

Dies ist der sechste und letzte 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 beschreibt, durch welche Maßnahmen IT-Sicherheitsverantwortliche ihre Organisationen vor PowerShell-Angriffen schützen können.

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.

Der fünfte Artikel der Reihe stellte vor, mit welchen Methoden Incident Responder und IT-Forensiker PowerShell-Angriffe untersuchen können, darunter die Arbeitsspeicher-Analyse.

Unzureichende Sicherheitsmechanismen

Der Sicherheitsforscher Sean Metcalf beschreibt in einer Präsentation, die er im Mai 2016 auf der Konferenz BSides in Baltimore hielt, warum manche übliche Sicherheitsmaßnahmen gegen Angriffe mit PowerShell versagen ^{[1, S. 6-13]}, die von anderen Experten vorgeschlagen werden ^{[2, S. 11-15]}.

Ausführungsrichtlinien

Die Ausführungsrichtlinien (Execution Policies) von PowerShell und die Möglichkeit, nur digital signierte Skripte ausführen zu lassen, sind Safety-Funktionen, die PowerShell-Anwender vor unbedachten eigenen Aktionen schützen sollen – sie sind keine Security-Funktionen und können trivial umgangen werden ^{[3, S. 7]}.

Die Standardrichtlinie für Client-Betriebssysteme (wie Windows 7) und Serversysteme bis hin zu Windows Server 2012 ist Restricted – es werden nur einzelne Befehle, aber keine Skripte ausgeführt. Ab Windows Server 2012 R2 wurde die Standardrichtline für Windows Server gelockert, um das Ausführen von heruntergeladenen, digital signierten Skripten zu ermöglichen (RemoteSigned) ^[4].

Bereits 2014 kursierten im Kreis der Sicherheitsforscher zahlreiche Möglichkeiten, die Ausführungsrichtlinie zu umgehen: vom praktischen „Skript in die interaktive PowerShell-Befehlszeile kopieren“ bis hin zum kreativen „Ausführungsrichtlinie durch Ändern des Authorization Managers deaktivieren“ ^[5].

Der einfachste Weg, die Ausführungsrichtline zu umgehen, besteht wohl darin, den PowerShell-Interpreter mit dem Parameter ExecutionPolicy aufzurufen, der systemweite Voreinstellungen überschreibt: powershell.exe -ExecutionPolicy Bypass ^{[6, S. 423]}.

Dies entspricht auch den Designzielen von Microsoft, das diese Funktionen explizit nicht zum Schutz vor intelligenten Angreifern entworfen hat ^{[7, S. 294-295]}.

Constrained Language Mode vor PowerShell 5

Ebenso ungeeignet als Security-Maßnahme – vor PowerShell 5 – ist der eingeschränkte PowerShell-Modus. Im Constrained Language Mode sind bestimmte Befehle und Funktionen gesperrt, etwa zum Herunterladen von Dateien oder zum Erzeugen von neuen Objekten.

Der eingeschränkte Modus kann in älteren PowerShell-Versionen durch ein Kommando jedoch einfach deaktiviert werden ^{[2, S. 90-91]}.

AppLocker-Einschränkungen der Standard-PowerShell-Interpreter

Die Ausführung des PowerShell-Kommandozeileninterpreters powershell.exe durch Gruppenrichtlinien ^[8] oder die in Windows eingebaute Anwendungs-Whitelisting-Lösung AppLocker ^{[1, S. 8]} zu verhindern, beseitigt ebenfalls nicht das Risiko von Angriffen über PowerShell.

AppLocker-Richtlinien unterstützen so genannte Skriptregeln, um die Ausführung von PowerShell-Skripten nur aus bestimmten Ordnern zu ermöglichen. Ebenso steuern Executable Rules, welche Programme ausgeführt werden können, identifiziert über den Dateipfad oder eine digitale Signatur. Auf diese Weise können nicht-administrative Benutzer daran gehindert werden, den PowerShell-Interpreter auszuführen (Blacklisting) ^[9].

Daher mag es sinnvoll erscheinen, powershell.exe zu blockieren. Dadurch wird die Bedrohung jedoch nicht vollständig entfernt, da PowerShell viel mehr ist als die einzelne ausführbare Datei powershell.exe.

Einerseits können PowerShell-Skripte mit der mitinstallierten grafischen Entwicklungsumgebung Integrated Scripting Environment (ISE) powershell_ise.exe ausgeführt werden ^[10] oder auf Microsoft-SQL-Servern mit der dort verfügbaren Konsolenanwendung sqlps.exe ^[11].

Andererseits kann ein Angreifer jene Komponenten des .NET-Frameworks, die PowerShell interpretieren, in andere Prozesse einbinden, welche durch die Ausführungsrichtlinien von AppLocker erlaubt sind. PowerShell-Skripte werden von der Bibliothek System.Management.Automation.dll verarbeitet, einer der Hauptkomponenten des Windows-Betriebssystems, die nicht einfach entfernt werden kann. Da PowerShell Teil des .NET-Frameworks ist, kann ein Angreifer diese Systembibliothek, die PowerShell-Skripte interpretiert, in andere legitime Prozesse einfügen und so eine Laufzeitumgebung erstellen, die dem Standardinterpreter powershell.exe ähnelt. So kann ein Angreifer immer noch PowerShell-Skripte ausführen – unentdeckt ^[12].

Sicherheitsforscher haben Projekte veröffentlicht, die das Umgehen von PowerShell-Application-Blacklisting als schlüsselfertige Lösung anbieten: PS>Attack von Jared Haight wurde im März 2016 auf der Konferenz CarolinaCon vorgestellt und p0wnedShell von Cornelis de Plaa einige Monate später veröffentlicht. Beide Projekte wurden in einem vorherigen Artikel vorgestellt.

Die meisten PowerShell-Angriffswerkzeuge, die außerhalb des standardmäßigen PowerShell-Interpreters powershell.exe ausgeführt werden – wie PS>Attack und p0wnedShell – basieren auf Unmanaged PowerShell des Sicherheitsforschers Lee Christensen. Unmanaged PowerShell verwendet das .NET-Framework zum Erstellen einer PowerShell-Laufzeitumgebung aus einem nicht verwalteten Prozess mit der PowerShell-Kernbibliothek System.Management.Automation.dll als Referenz ^[13]. Gleiches funktioniert mit der Bibliothek System.Management.Automation.ni.dll.

PowerShell-Angriffe verhindern

Der australische Nachrichtendienst Australian Signals Directorate (ASD) hat im März 2016 das empfehlenswerte Dokument Securing PowerShell in the Enterprise veröffentlicht ^[14].

Seit Anfang 2018 gibt es auf der Lernplattform edX den von Microsoft geschriebenen, kostenlos belegbaren Onlinekurs PowerShell Security Best Practices.

Microsoft bietet Werkzeuge an, um die Vielzahl der möglichen Sicherheitsmaßnahmen ^[16] effektiv zu priorisieren ^[17].

PowerShell 5

PowerShell Version 5, eingeführt mit Windows 10, erhöht den Schwierigkeitsgrad für Angreifer deutlich. PowerShell 5 ist in Windows 10 vorinstalliert und kann nachträglich installiert werden unter Windows Server 2012 (R2) und 2008 R2 SP1, Windows 8.1 und Windows 7 SP1 ^[18].

Der Constrained Language Mode wurde in PowerShell Version 5 derart verbessert, dass er nicht mehr einfach ausgehebelt werden kann und ermöglicht somit ein effektives Whitelisting oder Blacklisting – also explizites Erlauben bzw. Verbieten – von bestimmten Befehlen ^{[3, S. 7]}. In früheren Versionen enthielt PowerShell eine undokumentierte Debugging-Umgebungsvariable, die geändert werden konnte, um die Durchsetzung des eingeschränkten Sprachmodus zu entfernen ^[19].

Der Constrained Language Mode ist einer der vier Sprachmodi von PowerShell, die festlegen, welche Elemente der PowerShell-Skriptsprache verfügbar sind und auf welche Teile des zugrunde liegenden Betriebssystems sie zugreifen können.

Die anderen drei Modi sind: der Full Language Mode, der alle Elemente der PowerShell-Sprache zulässt; der Restricted Language Mode, in dem vorhandene Befehle funktionieren, die Sprachelemente von PowerShell aber deutlich eingeschränkt sind; sowie der No Language Mode, in dem Benutzer nur Befehle ausführen können, aber keine Elemente der PowerShell-Programmiersprache verwenden können ^[20].

Im Gegensatz zum Restricted Mode beschränkt der Constrained Mode nicht die Sprachelemente, die für Skripting vorgesehen sind ^[21]. Er wurde “designed to support day-to-day administrative tasks, yet restricts access […] that can be used to invoke arbitrary Windows APIs” ^[19]; verboten ist etwa .NET-Skripting, das Cmdlet Add-Type und der Zugriff auf Objekte des Component Object Model (COM).

In Version 5 wechselt PowerShell automatisch in den eingeschränkten Sprachmodus für interaktive Eingaben und Skripte, wenn AppLocker aktiviert und im «Allow Mode» ist, in dem nur bestimmte Anwendungen ausgeführt werden können. In diesem Fall ist es einem Angreifer nicht möglich, den Sprachmodus zu ändern und bösartige Skripte auszuführen ^[20]. Wenn PowerShell jedoch aus einem Verzeichnis ausgeführt wird, das von AppLocker zugelassen ist, oder wenn signierter Code ausgeführt wird, läuft PowerShell-Code im Full Language Mode ^[22].

Darüber hinaus bietet PowerShell mit Version 5 sichere Codegenerierungs-APIs, um nicht-vertrauenswürdige Benutzereingaben zu verarbeiten und Eingabevalidierung und -bereinigung (Sanitization) zu ermöglichen ^{[23, S. 10]}. In PowerShell-Skripten hilft dies, Code-Injection-Schwachstellen zu vermeiden, die den bekannten SQL-Injektionen ähneln, welche Websites plagen ^[21].

Just Enough Administration (JEA) ist eine Funktion der Version 5, die es nicht-administrativen PowerShell-Benutzern ermöglicht, bestimmte Aufgaben auszuführen, ohne dass ihnen Administratorrechte zugewiesen werden müssen. Im Rahmen von JEA können die verfügbaren Befehle, Parameter und Parameterwerte eingeschränkt werden ^[24]. Außerdem kann zwangsweise Skriptblock-Protokollierung und Transkription der Sitzung aktiviert werden ^{[23, S. 12]}.

Mit der Verbreitung von Sicherheitsmechanismen wie dem verbesserten Constrained Language Mode müssen Angreifer Wege finden, um diese neuen Hindernisse zu umgehen. Sie können etwa ältere Versionen von PowerShell aufrufen, denen diese neuen Sicherheitsfunktionen fehlen: ein so genannter PowerShell-Downgrade-Angriff ^[25].

PowerShell-Downgrade-Angriffe können verhindert werden, indem die PowerShell-2.0-Funktion aus neueren Windows-Versionen entfernt wird ^[26]. Außerdem können PowerShell-2.0-spezifische Bibliotheken mithilfe einer Whitelisting-Lösung wie AppLocker blockiert werden ^[27].

Weitere Sicherheitsmechanismen

Sicherheitsmechanismen, die neben dem Einsatz von PowerShell in mindestens Version 5 – und den eben beschriebenen Sicherheitsmechanismen Constrained Language Mode, Sanitization und Just Enough Administration – tatsächlich geeignet sind, um Angriffe mit PowerShell zu verhindern oder zu erschweren, werden im Folgenden erläutert.

Anwendungs-Whitelisting-Lösungen wie AppLocker können dazu genutzt werden, Anwendern das Ausführen jeglicher Programme von benutzerdefinierten Pfaden (wie dem Benutzerprofil oder dem Eigene-Dateien-Ordner) zu verbieten, womit die initiale Kompromittierung verhindert und zuvor beschriebene Umgehungstechniken ausgehebelt werden ^{[2, S. 108]}.

Zum gleichen Zweck sollte bereits das Speichern von unbekannten ausführbaren Dateien in temporären Ordnern verboten werden ^[8].

Analog dazu kann das Blockieren von Makros in Microsoft-Office-Anwendungen Angreifer daran hindern, einen erfolgreichen Phishing-Angriff über präparierte Office-Dokumente auszuführen ^{[2, S. 108]}.

Zudem sollten AppLocker-Richtlinien mit so genannten Skriptregeln eingerichtet werden, um die Ausführung von PowerShell-Skripten nur aus bestimmten Ordnern oder für bestimmte Benutzer zu ermöglichen. (Auch wenn dafür bereits Mechanismen zur Umgehung durch Angreifer bekannt sind ^[28].)

Normale Benutzer sollten keine lokalen Administratorrechte haben. Ein erfolgreich kompromittiertes Benutzerkonto gibt einem Angreifer dadurch nicht sofort administrative Rechte ^{[2, S. 108]}.

Schließlich können das starke Einschränken von PowerShell Remoting ^{[2, S. 73, 86]} und sehr restriktive ausgehende Regeln in den lokalen Windows-Firewalls ^{[29, S. 32]} einen Angreifer an einer schnellen Ausbreitung im Netzwerk hindern.

PowerShell-Angriffe erkennen

Anti-Malware Scan Interface

Das Anti-Malware Scan Interface (AMSI), eingeführt mit Windows 10, ermöglicht Herstellern von Malwarescannern, innerhalb von PowerShell-Umgebungen ablaufende Aktionen auf schadhafte Aktivitäten zu prüfen ^{[2, S. 103-106]}. AMSI beseitigt damit deren blinden Fleck – Skript-Engines, die zur Laufzeit generierten Code ausführen – durch den Angreifer leichtes Spiel hatten. Im Fall von PowerShell scannt AMSI jeden Quelltextabschnitt, bevor er an die PowerShell-Bibliothek System.Management.Automation.dll zur Ausführung übergeben wird. Die Architektur ist in unten stehender Abbildung dargestellt ^[30].

Dieser Ansatz erkennt sogar verschleierten bösartigen Code, wie Lee Holmes von Microsofts PowerShell-Team erklärt: “While the malicious script might go through several passes of deobfuscation, it ultimately needs to supply the scripting engine with plain, unobfuscated code“ ^[30]. Kurz zuvor kann die Anwendung die AMSI-APIs aufrufen, um einen Scan anzufordern.

Jedoch nutzen die Antimalware-Hersteller die neue Schnittstelle erst zögerlich; nur Microsoft selbst sowie die Dritthersteller AVG, ESET, BitDefender, Avast und seit Kurzem Kasperksy haben ihre Scanner bislang damit ausgerüstet. Malware-Scanner anderer Branchengrößen wie F-Secure, McAfee, Symantec und Sophos haben AMSI noch nicht implementiert ^[31].

Wie so oft beim Wettrüsten in der Sicherheitsindustrie gibt es bereits bekannte Wege, die Sicherheitsmaßnahme AMSI zu umgehen ^[32].

Einbruchserkennung und Logging, Logging, Logging

Die Kommunikation im internen Netzwerk sowie mit Systemen außerhalb kann durch ein geeignetes Einbruchserkennungssystem (Intrusion Detection System, IDS) überwacht werden, um ungewöhnlichen und bösartigen Verkehr zu erfassen. Dazu ist bei der auf einen Alarm folgenden manuellen Untersuchung für die Verteidiger jedoch notwendig zu wissen, wie normaler Netzwerkverkehr aussieht.

Um laufende Angriffe mit PowerShell oder eine bestehende Kompromittierung erkennen zu können, wird vor allem das Protokollieren (Logging) jeglicher Aktivitäten durch PowerShell empfohlen. Zunächst sollten alle ab PowerShell Version 5 verfügbaren erweiterten Funktionen zur Ereignisprotokollierung aktiviert werden: Skriptblock-Protokollierung, Transkription und Modul-Logging (das bereits seit Version 3 sinnvoll genutzt werden kann) ^[33].

Die Protokolldaten sollten nicht nur lokal auf den einzelnen Rechner vorgehalten, sondern an einen zentralen Logserver übermittelt werden ^{[2, S. 108]}.

Diese an einer Stelle gesammelten Daten können auf ungewöhnliche Muster hin analysiert werden, etwa: ein normaler niedrig-privilegierter Benutzerzugang führt mit PowerShell Aktionen auf zehn unterschiedlichen Rechnern aus ^{[2, S. 89-91]}. Der Entwickler des beliebten offensiven PowerShell-Skripts Powercat weist darauf hin, dass sich Verteidiger nicht mehr darauf verlassen können, von automatisierten Sicherheitssystemen auf bekannte Probleme hingewiesen zu werden – stattdessen müssen sie aktiv nach Abweichungen von normalem Systemverhalten und den Gründen dafür suchen ^{[36, S. 17]}.

Beispielsweise mit der Loganalysesoftware Splunk können aggregierte PowerShell-Logdaten zentral auf verdächtige Angriffsmuster untersucht werden ^[37].

Mehr Informationen zum Thema Protokollieren (Logging) in PowerShell stehen in einem vorherigen Artikel dieser Reihe. Neben den dort beschriebenen Heuristiken gibt es etwa neue Forschungsansätze, mit maschinellem Lernen über Natural Language Processing (NLP) bösartige PowerShell-Befehle zu erkennen, die bereits von ersten Herstellern implementiert wurden ^[39].

In Windows-Ereignisprotokollen werden zudem auch Aktivitäten von Angreifern verzeichnet, die versuchen, Sicherheitsmechanismen von PowerShell zu umgehen. PowerShell-Downgrade-Angriffe etwa können über das Standard-PowerShell-Ereignisprotokoll (ID 400) erkannt werden ^[25].

Angriffe mit Hilfe von PowerShell verhindern und erkennen

Administratoren können in PowerShell geschriebene Skripte auch einsetzen, um sich gegen (fast) jegliche Angriffe – nicht nur auf den durch PowerShell selbst geöffneten Angriffsvektoren – besser zu schützen oder diese zu erkennen.

Etwa können Sicherheitseinstellungen auf mehreren Rechnern geprüft und gegebenenfalls verschärft werden; für Zugänge mit Administratorrechten können sichere Zufallspasswörter erzeugt werden ^{[40, S. 43]}; Logdateien können automatisiert nach Angriffsmustern durchsucht werden; schließlich kann ein einfaches Intrusion Detection System (IDS) in Form von PowerShell-Skripten implementiert werden ^[41].

Forensische Untersuchungen mit Hilfe von PowerShell

PowerShell eignet sich nicht nur zum Angreifen, sondern beeinflusst auch, wie die Verteidiger eines Unternehmensnetzwerkes auf Angriffe von außen reagieren.

Zunächst bietet sich PowerShell Remoting für Personen an, die im Unternehmen auf einen möglichen Sicherheitsvorfall reagieren (Incident Responder). Damit können sie aus der Ferne mit Bordmitteln auf einen potentiell kompromittierten Rechner zuzugreifen. Hierbei ist jedoch abzuwägen, dass der Incident Responder durch seine PowerShell-Sitzung womöglich solche Änderungen am entfernten Rechner hervorruft, die eine spätere eingehende Untersuchung von forensischen Beweisen durch einen Verlust an Integrität beeinträchtigen (Locard’sches Prinzip).

Genauso wie Angreifer und Penetrationstester PowerShell-Skriptsammlungen für ihren jeweiligen Einsatzzweck erstellt haben, veröffentlichten auch mit der Verteidigung befasste Sicherheitsexperten Frameworks, die PowerShell als sichere und skalierbare Lösung für Incident Response nutzen ^{[42, S. 14]}, darunter PowerForensics (ehemals Invoke-IR), Kansa, PoshSec und PowerShell Arsenal ^{[2, S. 62]}.

Besonders verbreitet sind die Frameworks PowerForensics und Kansa. PowerForensics hat sich der Verarbeitung von Ereignislogs und der Live-Untersuchung von Dateisystemen verschrieben ^{[43, S. 4]}. Kansa sammelt per PowerShell Remoting skalierbar und erweiterbar Daten über den Zustand von allen damit überwachten Systemen. Die von Kansa aggregierten Daten können einerseits individuell abgefragt werden, andererseits mit Frequenzanalysen auf Anomalien und so genannte Indicators of Compromise (IOCs) untersucht werden, also auf bekannte Anzeichen für einen Einbruch.

Besonders effizient ist PowerShell für Incident Responder einsetzbar: um ungewöhnliche Anmeldungen am Netzwerk festzustellen; um auf dem zu untersuchenden Zielrechner nach Hinweisen auf einen erfolgreichen Angriff zu suchen sowie die Reichweite der Kompromittierung abzuschätzen; um gegebenenfalls versteckte Persistenzmechanismen der Angreifer aufzudecken; sowie die Wiederherstellung von befallenen Rechnern und Diensten teilweise zu automatisieren ^{[44, S. 1]}.

Jedoch ist festzustellen, dass auf PowerShell basierende Forensik-Frameworks keine umfassende Lösung für jeden denkbaren Forensik-Anwendungsfall sind ^{[42, S. 14]}.

Fazit

Die US-Sicherheitsfirma Carbon Black stellt zum Abschluss ihrer Untersuchung von Angriffen mit PowerShell fest: PowerShell ist eine in Windows-Umgebungen allgegenwärtige Technologie, die in der Vielzahl ihrer Anwendungen für legitime Zwecke verwendet wird. Sie kann kaum von Administratoren aus ihrer IT-Umgebung entfernt werden – im Gegensatz zu anderen von Angreifern häufig genutzten Techniken wie Oracle Java oder Adobe Flash ^{[45, S. 16]}.

Zudem werde die fortlaufende Entwicklung von Frameworks wie Empire dazu führen, dass PowerShell von immer mehr Akteuren in jeder Art von Angriff häufiger eingesetzt werde – von in die Breite streuender Malware bis hin zu gezielten fortgeschrittenen Attacken. Da Unternehmen und Behörden es häufig versäumen, den Einsatz von PowerShell einzuschränken und zu überwachen, rechnen die Analysten damit, dass die Sicherheitslage in dieser Hinsicht schlechter wird, bevor sie sich durch den gestiegenen Druck der Angreifer nachhaltig verbessert ^{[45, S. 16]}.

Eine Bedrohungsprognose des Sicherheitsherstellers McAfee Labs für 2016 und folgende Jahre rechnet damit, dass schwierig zu erkennende Angriffe in den kommenden fünf Jahren stark zunehmen werden – darunter Angriffe über eingebaute Fernwartungsfunktionalitäten wie Windows Remote Desktop oder PowerShell Remoting.

Die Autoren des McAfee-Berichts merken an, der Vorteil von PowerShell sei, dass Angreifer direkte Kontrolle über die angegriffenen Systeme erlangen und böswillige Software ohne Auslösen von Sicherheitsmechanismen installieren könnten. Besonders schwierig sei das Erkennen eines Angriffs, wenn die Anmeldung mit gestohlenen legitimen Zugangsdaten erfolge. Demzufolge gehen die Sicherheitsforscher davon aus, dass der Diebstahl von Passwörtern und anderen Zugangsdaten in gleichem Maße steigen werde.

Kazanciyan und Hastings deuten die weite Verbreitung von PowerShell in durchschnittlichen Unternehmensnetzwerken auf Windows-Basis, die stetige Verbesserung von PowerShell-Angriffswerkzeugen und das Sammeln von PowerShell-Kenntnissen unter den Angreifern als Verkettung unglücklicher Umstände („perfekter Sturm“) für all jene, die ein Netzwerk schützen oder einen möglichen Sicherheitsvorfall untersuchen ^{[47, S. 4-5]}.

Microsoft selbst bezeichnet PowerShell als die sicherste verfügbare Skriptsprache, denn es bietet (ab Version 5) zahlreiche Sicherheitsmechanismen – die jedoch oft nicht per Standard aktiv sind, sondern erst von Administratoren konfiguriert werden müssen ^[48].

Dem gegenüber stehen neuere Untersuchungsmethoden wie die Arbeitsspeicheranalyse, die sich zu einer der flexibelsten und umfangreichsten Methoden zur forensischen Untersuchung von Computern entwickelt hat und zu einem festen Bestandteil der Incident Response geworden ist ^{[49, S. 571]}. „Da Schadsoftware zumindest in Teilen des Hauptspeichers vorhanden sein muss[,] um ausgeführt werden zu können, ist es unmöglich[,] alle Spuren einer Infektion zur Laufzeit aus dem Speicher zu beseitigen.“ ^{[50, S. 5]}

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