Windows-Artefakte · Lektion 9 von 9
Papierkorb und Volumeschattenkopien
10 Min. Lesezeit
Wenn ein Benutzer unter Windows eine Datei löscht, ist sie häufig nicht wirklich verschwunden. Beim Löschen über den Explorer wird die Datei normalerweise in den Papierkorb verschoben, zusammen mit einem kleinen Datensatz darüber, woher sie stammt, wann sie gelöscht wurde und wer sie gelöscht hat. Volumeschattenkopien können ältere Versionen ganzer Volumes bewahren. Diese Lektion behandelt beides unter Windows 10 und 11: wie die Daten gespeichert werden, wie Sie sie dekodieren, was sie belegen und wo ihre Grenzen liegen. In der Fallarbeit und in der Prüfung ist der Papierkorb eine wahrscheinliche Quelle für einen exakten ursprünglichen Pfad, einen Löschzeitpunkt oder eine SID.
Der Papierkorb unter Windows Vista und höher
Jedes als fest eingebunden geltende Volume mit einem Papierkorb enthält unabhängig vom Dateisystem einen versteckten Systemordner X:\$Recycle.Bin\. Darin erstellt Windows für jeden Benutzer, der auf diesem Volume etwas gelöscht hat, einen Unterordner, der nach dessen Sicherheitskennung (SID) benannt ist, beispielsweise C:\$Recycle.Bin\S-1-5-21-1844237615-456351123-789044191-1001\. Der Papierkorb ist somit volume- und benutzerspezifisch: Eine von D: gelöschte Datei gelangt nach D:\$Recycle.Bin, nicht nach C:. Der SID-Ordner ordnet jede Löschung einem Konto zu. Um die SID einem Benutzernamen zuzuordnen, verwenden Sie den Schlüssel ProfileList in der SOFTWARE-Hive oder die SAM-Hive (Lektion 2.2).
Jedes gelöschte Element wird zu einem Paar von Einträgen mit demselben zufälligen Namensbestandteil:
$I+ 6 zufällige Zeichen + ursprüngliche Erweiterung, beispielsweise$IABC123.pdf: eine kleine Metadatendatei, die den ursprünglichen Pfad, die Größe und den Löschzeitpunkt enthält.$R+ dieselben 6 Zeichen + Erweiterung, beispielsweise$RABC123.pdf: der Inhalt. Wurde ein Ordner gelöscht, ist$R…ein Ordner, der die ursprünglichen Dateien und Unterordner weiterhin unter ihren ursprünglichen Namen enthält.
Auf demselben Volume ist das Verschieben einer Datei in den Papierkorb eine Umbenennung (ein Verschiebevorgang), kein Kopiervorgang. Die $R-Datei behält den MFT-Datensatz und die Daten der ursprünglichen Datei, sodass ihr Hashwert mit dem der ursprünglichen Datei übereinstimmt. Die Umbenennung erscheint normalerweise auch im Änderungsjournal $UsnJrnl (Lektion 1.4). Jeder SID-Ordner enthält normalerweise auch eine Datei desktop.ini, die kein Beleg für eine Löschung ist.
| Windows-Version | Speicherort | Metadatenformat |
|---|---|---|
| XP und früher | C:\RECYCLER\<SID>\ | Eine Datei INFO2, die alle gelöschten Elemente auflistet (nur von historischer Bedeutung) |
| Vista bis 8.1 | X:\$Recycle.Bin\<SID>\ | $I-Datei, Version 1, 544 Bytes |
| 10 und 11 | X:\$Recycle.Bin\<SID>\ | $I-Datei, Version 2, variable Länge |
Das Format der $I-Datei
Alle Ganzzahlen in der $I-Datei sind im Little-Endian-Format gespeichert.
| Offset | Größe | Feld (Version 2, Windows 10 und höher) |
|---|---|---|
| 0x00 (0) | 8 Bytes | Header/Version: 2 |
| 0x08 (8) | 8 Bytes | Ursprüngliche Dateigröße in Bytes (bei einem Ordner die Gesamtgröße seines Inhalts) |
| 0x10 (16) | 8 Bytes | Löschzeitpunkt, FILETIME, UTC |
| 0x18 (24) | 4 Bytes | Länge des Pfads in UTF-16-Zeichen, einschließlich des abschließenden Nullzeichens |
| 0x1C (28) | variabel | Ursprünglicher vollständiger Pfad, UTF-16LE, mit abschließendem Nullzeichen (00 00) |
Version 1 (Vista bis 8.1) hat dieselben ersten 24 Bytes, wobei das Versionsfeld auf 1 gesetzt ist. Sie hat kein Längenfeld: Der Pfad beginnt bei Offset 24 in einem festen Feld von 520 Bytes (260 UTF-16-Zeichen), das mit Nullen aufgefüllt wird. Daher ist jede $I-Datei der Version 1 genau 24 + 520 = 544 Bytes groß. Eine Datei der Version 2 ist 28 + 2 × (Pfadlänge) Bytes groß. Ein Parser, der das Versionsfeld prüft, kann beide Formate lesen.
FILETIME, das in Lektion 2.1 behandelt wurde, ist ein 64-Bit-Zähler von 100-Nanosekunden-Intervallen seit 1601-01-01 00:00:00 UTC. Der Löschzeitpunkt in $I wird in UTC gespeichert, sodass die Zeitzoneneinstellung des Systems ihn nicht verändert.
Durchgerechnetes Beispiel: Dekodieren einer $I-Datei
Eine Triage-Datensammlung enthält die 94 Bytes lange Datei C:\$Recycle.Bin\S-1-5-21-1844237615-456351123-789044191-1001\$IABC123.pdf. Ihr Inhalt:
| Offset | Bytes (hex) | Bedeutung |
|---|---|---|
| 0x00 | 02 00 00 00 00 00 00 00 | Version 2 |
| 0x08 | 24 CB 03 00 00 00 00 00 | Größe |
| 0x10 | 2A 35 0D 7F D1 B3 DC 01 | Löschzeitpunkt |
| 0x18 | 21 00 00 00 | Pfadlänge |
| 0x1C | 43 00 3A 00 5C 00 55 00 73 00 … | C:\Us… |
- Version. 2, daher handelt es sich um das Windows-10/11-Format und das Feld für die Pfadlänge ist vorhanden.
- Größe. Kehren Sie die Byte-Reihenfolge um: 0x0003CB24 = 3 × 65.536 + 0xCB24 (52.004) = 196.608 + 52.004 = 248.612 Bytes.
- Löschzeitpunkt. Kehren Sie die Byte-Reihenfolge um: 0x01DCB3D17F0D352A = 134.179.801.275.381.034. Ziehen Sie den FILETIME-Wert der Unix-Epoche, 116.444.736.000.000.000, ab: Das Ergebnis ist 17.735.065.275.381.034 Hundert-Nanosekunden-Intervalle oder 1.773.506.527,5381034 Sekunden seit 1970-01-01. 1.773.506.527 = 20.526 Tage × 86.400 + 60.127 Sekunden. 20.526 Tage nach 1970-01-01 ist 2026-03-14. 60.127 Sekunden = 16 h (57.600) + 42 min (2.520) + 7 s. Der Löschzeitpunkt ist 2026-03-14T16:42:07Z (sekundengenau; der vollständige Wert ist 16:42:07.5381034).
- Pfadlänge. 0x21 = 33 Zeichen einschließlich des Nullzeichens. 28 + 33 × 2 = 94 Bytes, was mit der Dateigröße übereinstimmt; der Datensatz ist somit vollständig.
- Pfad. Dekodieren Sie 32 UTF-16LE-Zeichen (0x43 0x00 =
C, 0x3A 0x00 =:, 0x5C 0x00 =\…):C:\Users\ana\Documents\offer.pdf.
Bestätigen Sie das Ergebnis anhand weiterer Befunde: Die Größe von $RABC123.pdf sollte 248.612 Bytes betragen, ihr Hashwert ist der Hashwert des gelöschten Dokuments, und die SID …-1001 sollte dem Konto ana zugeordnet werden können. RBCmd ist ein Beispiel für einen kostenlosen Parser: RBCmd.exe -d "C:\$Recycle.Bin" --csv out schreibt eine Zeile pro $I-Datei (das Programm liest auch INFO2). Verwenden Sie es, um Ihre manuelle Dekodierung zu überprüfen.
Was der Papierkorb nicht aufzeichnet
- Wiederherstellen und Leeren. Beim Wiederherstellen eines Elements wird
$Rzurück auf den ursprünglichen Pfad umbenannt und$Igelöscht. Beim Leeren des Papierkorbs oder beim Löschen eines einzelnen Elements darin werden beide gelöscht. Die MFT-Datensätze und Cluster der entfernten Dateien werden anschließend nicht zugeordnet und können bis zu ihrer Wiederverwendung mit den Methoden aus Lektion 1.8 wiederhergestellt werden. Eine auf diese Weise wiederhergestellte$I-Datei liefert weiterhin den ursprünglichen Pfad und den Löschzeitpunkt. - Umgehen des Papierkorbs. Umschalt+Entf,
delin der Eingabeaufforderung,Remove-Itemin PowerShell und die meisten Programme, die Dateien direkt löschen, verwenden den Papierkorb nicht. Elemente, die von Netzwerkfreigaben gelöscht werden, werden ebenfalls normalerweise direkt gelöscht. Das Fehlen einer$I-Datei beweist daher nicht, dass eine Datei nicht gelöscht wurde. - Größenbeschränkungen. Der Papierkorb jedes Volumes hat eine maximale Größe, die der Benutzer ändern kann. Bei Dateien, die für den Papierkorb zu groß sind, bietet der Explorer stattdessen das endgültige Löschen an. Die Einstellung wird pro Benutzer unter
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\{volume GUID}mit den WertenMaxCapacity(in MB) undNukeOnDelete(1 bedeutet, dass der Papierkorb für dieses Volume umgangen wird) gespeichert. - Wechselmedien-Volumes. Dateien, die über den Explorer von Laufwerken gelöscht werden, die Windows als Wechselmedien behandelt, etwa die meisten USB-Sticks, werden normalerweise endgültig gelöscht. USB-Festplatten, die sich als fest eingebunden melden, erhalten wie interne Volumes einen
$Recycle.Bin. Wenn Sie ein USB-Abbild untersuchen, prüfen Sie auch dessen Stammverzeichnis auf$Recycle.Binund SID-Ordner.
Volumeschattenkopien
Der Volumeschattenkopie-Dienst (VSS) erstellt zeitpunktbezogene Momentaufnahmen eines Volumes. Die Momentaufnahmen arbeiten auf Blockebene und nach dem Copy-on-Write-Prinzip: Wenn eine Momentaufnahme existiert und ein Block des aktuellen Volumes überschrieben werden soll, wird zunächst der alte Inhalt dieses Blocks in einem differenziellen Speicherbereich gesichert. Eine Momentaufnahme besteht daher aus dem aktuellen Volume und jedem seit ihrer Erstellung gesicherten Block. Die Speicherung erfolgt im versteckten Ordner System Volume Information im Stammverzeichnis des Volumes, in Dateien, deren Namen die GUID {3808876b-c176-4e48-b7ae-04046e6cc752} enthalten. Diese Dateien lassen sich nicht wie gewöhnliche Dateien lesen; sie müssen mit einem Parser ausgewertet werden.
Momentaufnahmen werden durch die Systemwiederherstellung (Wiederherstellungspunkte), Windows Update und viele Installationsprogramme, durch Sicherungssoftware sowie manuell erstellt: unter Windows Server mit vssadmin create shadow und unter Clienteditionen mit wmic shadowcopy call create Volume=C:\ (WMIC ist bei Neuinstallationen von Windows 11 24H2 standardmäßig nicht vorhanden und wird ab 25H2 entfernt; verwenden Sie stattdessen in PowerShell Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume="C:\"}) oder über die WMI-Klasse Win32_ShadowCopy. Standardmäßig bewahrt ein Volume höchstens 64 Momentaufnahmen auf (konfigurierbar). Der Speicherplatz wird durch ein mit vssadmin resize shadowstorage festgelegtes Kontingent begrenzt. Die ältesten Momentaufnahmen werden gelöscht, wenn das Kontingent oder die maximale Anzahl erreicht ist.
Der Computerschutz (Systemwiederherstellung) ist unter Windows 10 und 11 für das Systemlaufwerk häufig standardmäßig deaktiviert. Ob er aktiviert ist, hängt vom Gerät, der Art der Windows-Installation und der Datenträgergröße ab. Prüfen Sie dies, statt Annahmen zu treffen; viele moderne Systeme haben überhaupt keine Schattenkopien.
Forensischer Wert. Eine Momentaufnahme kann frühere Versionen später geänderter Dateien, nach der Momentaufnahme gelöschte Dateien, ältere Registry-Hives (beispielsweise eine NTUSER.DAT aus der Zeit vor dem Löschen eines Schlüssels) und Ereignisprotokolle aus der Zeit vor deren Leerung liefern. Vergleichen Sie jede Momentaufnahme mit dem aktuellen Volume und dokumentieren Sie für jedes Element, aus welcher Momentaufnahme es stammt und wann diese erstellt wurde.
Zugriff auf einem laufenden System. vssadmin list shadows listet jede Momentaufnahme mit ihrer ID, ihrem Erstellungszeitpunkt und ihrem Gerätenamen auf, beispielsweise \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3. mklink /d C:\vss3 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ macht sie als Ordner zugänglich. Der abschließende Backslash ist erforderlich.
Zugriff in einem Abbild. vshadowinfo aus libvshadow listet die Momentaufnahmen eines Volumes auf (wobei -o den Byte-Offset des Volumes im Abbild angibt), und vshadowmount stellt jede davon als rohe Volumedatei (vss1, vss2 …) bereit, die schreibgeschützt eingebunden oder mit The Sleuth Kit verarbeitet werden kann. Arsenal Image Mounter und andere Werkzeuge können ein Abbild zusammen mit seinen Momentaufnahmen unter Windows einbinden.
Löschung durch Angreifer. Ransomware und Eindringlinge führen häufig vssadmin delete shadows /all /quiet oder wmic shadowcopy delete aus, um eine Wiederherstellung zu verhindern. Die Löschung selbst hinterlässt Spuren, etwa Prozesserstellungsereignisse, Prefetch-Dateien und den Befehlsverlauf; Modul 7 behandelt diese.
Bei einer Triage-Datensammlung werden ausgewählte Dateien unter Beibehaltung ihrer ursprünglichen Pfade kopiert. Sie enthält normalerweise keine Schattenkopien, da diese keine gewöhnlichen Dateien sind. Rechnen Sie bei der auf Triage-Datensammlungen basierenden Fallarbeit damit, wesentlich häufiger mit dem Papierkorb als mit VSS zu arbeiten.
Vergleich der beiden
| Aspekt | Papierkorb | Volumeschattenkopien |
|---|---|---|
| Was bewahrt wird | Über den Explorer gelöschte Elemente: Inhalt sowie ursprünglicher Pfad, Größe und Löschzeitpunkt | Ältere Blöcke des gesamten Volumes: frühere Dateiversionen, gelöschte Dateien, Hives, Protokolle |
| Wo | X:\$Recycle.Bin\<SID>\, $I/$R-Paare | X:\System Volume Information\, Dateien {3808876b-…} |
| Wer und wann | Benutzer aus dem SID-Ordner, UTC-Löschzeitpunkt aus $I | Erstellungszeitpunkt jeder Momentaufnahme; keine Benutzerzuordnung |
| Grenzen | Wird durch Umschalt+Entf, Befehlszeile und große Dateien umgangen; wird vom Benutzer geleert | Häufig deaktiviert; Kontingent- und Anzahlbeschränkungen; Löschung durch Angreifer |
| In einer Triage-Datensammlung | Normalerweise enthalten | Normalerweise nicht enthalten |
Prüfungsschwerpunkt: Rechnen Sie damit, eine$I-Datei von Hand dekodieren oder die Ausgabe eines Werkzeugs überprüfen zu müssen: den ursprünglichen Pfad, die Größe und den UTC-Löschzeitpunkt, die SID des löschenden Benutzers und den Hashwert der zugehörigen$R-Datei. Kennen Sie den Aufbau der Versionen 1 und 2, ihre Erkennungsmerkmale und die Spuren, die Wiederherstellen, Leeren und Umschalt+Entf hinterlassen. Bei VSS sollten Sie wissen, wie Momentaufnahmen funktionieren, wo sie gespeichert werden, wie Sie sie auflisten und darauf zugreifen und weshalb sie in einer Triage-Datensammlung normalerweise fehlen.
Kernpunkte
- Jedes als fest eingebunden geltende Volume hat einen eigenen
$Recycle.Binmit einem Unterordner pro Benutzer-SID; jedes gelöschte Element wird zu einem Paar aus$I(Metadaten) und$R(Inhalt) mit denselben 6 zufälligen Zeichen. $IVersion 2: Version bei 0, Größe bei 8, FILETIME-Löschzeitpunkt (UTC) bei 16, Pfadlänge bei 24, UTF-16LE-Pfad bei 28. Version 1 hat eine feste Größe von 544 Bytes mit dem Pfad bei 24.- Beim Wiederherstellen wird
$Rzurück umbenannt und$Igelöscht; beim Leeren werden beide gelöscht, und ihre MFT-Datensätze und Cluster werden nicht zugeordnet und sind möglicherweise wiederherstellbar. - Umschalt+Entf, das Löschen über die Befehlszeile und zu große Dateien umgehen den Papierkorb. Eine fehlende
$I-Datei beweist daher nicht, dass eine Datei niemals gelöscht wurde. - VSS-Momentaufnahmen sind Copy-on-Write-Blockmomentaufnahmen in
System Volume Information; sie können ältere Dateien, Hives und Protokolle bewahren, sind jedoch häufig deaktiviert oder werden von Angreifern gelöscht. - Triage-Datensammlungen enthalten normalerweise den Papierkorb, aber keine Schattenkopien.