ShellBags und USB-Forensik: ein Ermittlungsbeispiel

TL;DR. In diesem fiktiven Fall zeigen die ShellBags von svc_backup auf der Workstation FIN-WKS-07 innerhalb von 45 Minuten: Navigation in Downloads\tools.zip, einen neuen Ordner unter ProgramData\Intel, die Freigabe \\FILESRV01\Finance (Payroll, dann Board) und E:\exfil\finance_2026 auf einem zweiten Laufwerk. Die ShellBags belegen, dass das Konto zu jedem Ordner navigiert ist, und liefern Reihenfolge und ungefähre Zeiten. Sie belegen nicht, dass eine Datei kopiert wurde. Der Bericht hält die Navigation fest und verweist auf die Artefakte, die den Rest belegen können.

Fiktives Szenario. Alles Folgende basiert auf den synthetischen Hives hinter der Schaltfläche Beispiel testen des ShellBags Parser: Konto, Rechner, Freigabe, SID und Uhrzeiten sind erfunden. Der Fall setzt dieselbe Geschichte fort wie die Schwester-Parser-Websites (ein kompromittiertes Dienstkonto auf FIN-WKS-07). Keine reale Organisation oder Person ist betroffen.

Die Fragestellung

Das Finanzteam meldet, dass Vorstandsunterlagen auf einer Paste-Seite aufgetaucht sind. Das SOC sieht am 2026-09-14 eine interaktive Anmeldung von svc_backup an FIN-WKS-07, einem Dienstkonto, das sich nie interaktiv anmelden sollte. Frage an die ShellBags: Welche Ordner hat dieses Konto im Explorer durchsucht, und in welcher Reihenfolge?

Sicherung

Der Incident Responder sicherte C:\Users\svc_backup\NTUSER.DAT und ...\AppData\Local\Microsoft\Windows\UsrClass.dat mit ihren .LOG1/.LOG2-Dateien über das KAPE-Target RegistryHivesUser (siehe Speicherort der ShellBags). Keiner der Hives war dirty. Der UsrClass-Wurzelschlüssel lautet S-1-5-21-3623811015-3361044348-30300820-1119_Classes, und die Shell Folders in NTUSER verweisen auf C:\Users\svc_backup; beide Hives gehören also zum selben Konto.

Was der Parser zeigt

Beide Hives im ShellBags Parser abgelegt ergeben 20 Einträge. Mit aktiviertem Nur markierte sind diese interessant:

Pfad	Typ	Verwendete Zeit	Hinweise	MFT (Eintrag/Seq.)
`My Computer\C:\Users\svc_backup\Downloads\tools.zip\x64`	Verzeichnis im Archiv	letzte Interaktion 10:07:20	Archiv	0 (ohne Bedeutung)
`My Computer\C:\ProgramData\Intel`	Verzeichnis	letzte Interaktion 10:09:05	vom Benutzer beschreibbar	91233/1
`\\FILESRV01\Finance`	Netzwerk	letzte Interaktion 10:31:07	Netzwerk	n/a
`\\FILESRV01\Finance\Payroll`	Verzeichnis	letzter Schreibzugriff des Schlüssels 10:32:40	Netzwerk	70112/1
`\\FILESRV01\Finance\Board`	Verzeichnis	letzte Interaktion 10:36:18	Netzwerk	70140/1
`My Computer\E:\exfil`	Verzeichnis	letzte Interaktion 10:45:51	anderes Laufwerk	35/1
`My Computer\E:\exfil\finance_2026`	Verzeichnis	letzte Interaktion 10:45:51	anderes Laufwerk	36/1

Alle Zeiten am 2026-09-14, in UTC. „Letzte Interaktion“ bedeutet, dass der Eintrag an erster Stelle der MRUListEx seines Elternschlüssels stand und dessen LastWrite übernimmt; „letzter Schreibzugriff des Schlüssels“ ist der des eigenen Schlüssels. Der Unterschied ist wichtig: siehe ShellBags-Zeitstempel erklärt.

Auswertung, Eintrag für Eintrag

1. Das Toolkit in einem ZIP

tools.zip ist ein File-Entry-Item unter Downloads, und x64 liegt im Baum darunter. Der Benutzer hat das ZIP also im Explorer als komprimierten Ordner geöffnet und ist in dessen Verzeichnis x64 navigiert. Die eingebetteten Zeiten des ZIP (erstellt 10:06:12, geändert 10:06:40, Zugriff 10:07:02) sind seine Dateisystemzeiten zum Zeitpunkt der Aufzeichnung und passen zu einem Download gegen 10:06. Der Schlüssel tools.zip wurde zuletzt um 10:07:20 geschrieben, mit x64 an erster MRU-Position: Navigation im Archiv gegen 10:07.

Was es nicht zeigt: das Entpacken. Das Durchsuchen eines ZIP im Explorer entpackt es nicht. Suchen Sie die entpackten Dateien in der MFT und im USN-Journal. Mehr dazu in ShellBags und ZIP-Dateien.

2. Ein neuer Ordner in ProgramData

C:\ProgramData\Intel hatte seine letzte Interaktion um 10:09:05. Seine eingebettete Erstellungszeit ist 10:09:00, während ProgramData selbst vom 2026-09-01 stammt. Ein Ordner mit Herstellernamen, eine Minute vor dem Durchsuchen an einem vom Benutzer beschreibbaren Ort angelegt, ist ein klassisches Staging-Muster. Über die MFT-Referenz (Eintrag 91233, Sequenz 1) holen Sie seinen Datensatz und seine Kinder aus der $MFT. Liegen Ausführungsartefakte vor (Prefetch, Amcache, BAM in der Registry), prüfen Sie, was aus diesem Ordner lief.

3. Die Finanzfreigabe

Drei Fakten:

\\FILESRV01 war das zuletzt genutzte Kind von Network und Finance das zuletzt genutzte Kind von \\FILESRV01, als diese Schlüssel um 10:31:07 geschrieben wurden.
Die MRUListEx von Finance lautet 1, 0: Board (Slot 1) wurde nach Payroll (Slot 0) genutzt.
Board erbt den LastWrite von Finance, 10:36:18. Payroll nicht; der LastWrite seines eigenen Schlüssels (10:32:40), ohne Unterschlüssel, nähert an, wann sein Eintrag aufgezeichnet wurde.

Belastbare Formulierung: „Das Konto navigierte zu \\FILESRV01\Finance\Payroll und später zu \\FILESRV01\Finance\Board; Board war um 10:36:18 UTC der zuletzt genutzte Unterordner von Finance.“ Die eingebetteten MFT-Referenzen (70112, 70140) sind NTFS-Datensätze des Dateiservers und nützlich, wenn Sie FILESRV01 untersuchen. Serverseitig kann die Überwachung des Freigabezugriffs (Sicherheitsereignisse 5140 und 5145, sofern aktiviert) die Sitzung und die berührten Dateien bestätigen.

4. Das zweite Laufwerk

E: war um 10:45:51 das zuletzt genutzte Kind von My Computer, und exfil\finance_2026 wurde zu diesem Zeitpunkt durchsucht. Laut ihren eingebetteten Zeiten wurde exfil um 10:40 und finance_2026 um 10:45 angelegt. Beide tragen MFT-Referenzen; das Volume E: war damals also NTFS-formatiert. Niedrige Eintragsnummern wie 35 und 36 passen zu einem frisch formatierten Volume, ein Hinweis, den es zu prüfen gilt, keine Schlussfolgerung.

Der Parser markiert es als „Anderes Laufwerk (USB?)“, weil der Buchstabe nicht C: ist. ShellBags allein können nicht sagen, dass es USB war. Das ergibt sich aus der Gerätehistorie im SYSTEM-Hive, den setupapi- und Ereignisprotokollen und aus LNK-Dateien mit passender Volume-Seriennummer.

5. Papierkorb um 10:50

Der Wurzelschlüssel BagMRU wurde zuletzt um 10:50:03 geschrieben, mit Recycle Bin an erster Stelle. Das Konto öffnete den Papierkorb fünf Minuten nach der Aktivität auf E:. Für sich genommen eine Nebensache. Im Kontext ein Grund, $Recycle.Bin auszuwerten (Papierkorb-Parser), um zu sehen, was gelöscht wurde.

Die Zeitachse

Zeit (UTC)	ShellBags-Befund	Nächstes zu prüfendes Artefakt
~10:02	Erste Explorer-Aktivität im NTUSER-Baum (`My Computer\C:`)	Anmeldeereignisse (4624 Typ 2/10)
~10:07	Navigation in `Downloads\tools.zip\x64`	MFT/USN für das Entpacken, Zone.Identifier
10:09	`ProgramData\Intel` (um 10:09 angelegt)	Prefetch/Amcache/BAM für Binärdateien dort
10:31–10:36	`\\FILESRV01\Finance`, `Payroll`, dann `Board`	LNK/Jump Lists, 5140/5145 auf dem Server
10:40–10:45	`E:\exfil`, `finance_2026` angelegt und durchsucht	USB-Historie, Volume-Seriennummer in LNK-Dateien
10:50	Papierkorb	`$I`-Dateien in `$Recycle.Bin`

Was die ShellBags nicht sagen können

Dass eine Datei geöffnet, kopiert oder hochgeladen wurde.
Dass E: ein USB-Gerät war, oder welches.
Irgendetwas, das auf der Konsole geschah: In der begleitenden Geschichte hinterlassen die Befehlszeilenwerkzeuge des Angreifers überhaupt keine ShellBags.
Dass keine weiteren Ordner durchsucht wurden: Eine Explorer-Sitzung unter einem anderen Konto oder bereinigte Schlüssel würden nicht erscheinen.

Deshalb ist der ShellBags-Abschnitt des Berichts kurz und präzise, und jede Zeile der Zeitachse hat eine Spalte „nächstes Artefakt“. Zur Wahl der Artefakte siehe ShellBags vs. LNK-Dateien, Jump Lists und RecentDocs.

Selbst nachvollziehen

Öffnen Sie den ShellBags Parser, klicken Sie auf Beispiel testen, aktivieren Sie Nur markierte und wechseln Sie zwischen Baum und Zeitachse. Die Schritt-für-Schritt-Anleitung erklärt jeden Bereich.