Wiping, Löschung und Bereinigungstools

Wiping- und Bereinigungstools entfernen Inhalte, sind aber selbst Programme: Sie werden heruntergeladen und ausgeführt, und sie benennen Dateien um, überschreiben und löschen sie. Jede dieser Aktionen wird irgendwo aufgezeichnet. Diese Lektion unterscheidet das Löschen vom Überschreiben und vom sicheren Löschen, beschreibt die typischen Spuren gängiger Wiping- und Bereinigungstools und zeigt, wie Sie verbliebene Daten wiederherstellen und einen Befund formulieren, ohne über die Beweislage hinauszugehen.

Das Ziel des Prüfers

Wenn Inhalte durch Wiping beseitigt wurden, ändert sich die Frage von „Was enthielt die Datei?“ zu „Wurde sie durch Wiping beseitigt, wann, durch welches Konto und was war das Ziel?“ Das Wiping ist selbst ein Ereignis, das von denselben Artefakten wie jede andere Aktivität aufgezeichnet wird (Module 1 und 2). Ein durch mehrere Quellen gestützter Wiping-Befund ist auch dann von Bedeutung, wenn keine Inhalte erhalten bleiben. Dieselbe Analyse weist zudem auf Kopien hin, die das Tool nicht erfasst hat.

Löschen, Überschreiben und sicheres Löschen

• Löschen markiert Metadaten und Cluster als frei; der Inhalt bleibt bis zur Wiederverwendung erhalten (Lektion 1.8).
• Überschreiben schreibt neue Bytes in die Cluster, die den Inhalt enthielten. Wenn ein Programm unter NTFS den vorhandenen Bereich einer gewöhnlichen Datei überschreibt, werden die Daten normalerweise wieder in dieselben Cluster geschrieben. Bei komprimierten Dateien, Sparse-Dateien und EFS-verschlüsselten Dateien ist das anders: NTFS verwaltet sie in Einheiten von 16 Clustern und schreibt neue Daten in neu zugewiesene Cluster, sodass die alten Daten im freien Speicherplatz verbleiben. Auch ein Programm, das durch Schreiben einer neuen Datei und Ersetzen der alten Datei „speichert“, hinterlässt die alten Cluster als nicht zugewiesen statt überschrieben.
• Sicheres Löschen kombiniert das Überschreiben des Inhalts, das Verschleiern des Namens und das Löschen. Wiping des freien Speicherplatzes füllt nicht zugewiesenen Speicherplatz mit temporären Dateien und überschreibt diese, wodurch zuvor gelöschte Inhalte vernichtet werden.

NIST SP 800-88 Rev. 1 (2014, inzwischen durch Rev. 2, 2025, ersetzt) stellte fest, dass auf magnetischen Medien ein einzelner Überschreibdurchgang eine Wiederherstellung normalerweise verhindert. Erwarten Sie daher nach einem vollständigen Durchgang keine Überreste.

TRIM ist die wichtigste Ursache für falsch positive Befunde. Auf einer SSD führt normales Löschen mit anschließendem TRIM meist dazu, dass die freigegebenen Blöcke beim Lesen Nullen zurückgeben (oder einen anderen festen Wert, je nach Laufwerk). Genullte Cluster allein sind daher kein Beweis für ein Wiping-Tool. Ein Wiping-Befund benötigt die eigenen Spuren des Tools: Ausführung, Umbenennungen und Fülldateien.

Wiping-Tools und ihre Spuren

Gängige Beispiele sind SDelete (Sysinternals, Befehlszeile), Eraser (grafisch, mit einem Eintrag im Explorer-Kontextmenü), BleachBit (Windows und Linux), Drive Wiper von CCleaner, das integrierte cipher /w und GNU shred.

Ausführung und Installation

Ein Wiping-Tool erzeugt die Ausführungsartefakte aus Lektion 2.3: Prefetch (Ausführungsanzahl, Ausführungszeitpunkte und referenzierte Dateien, zu denen bei einem Wiping-Tool auch dessen Ziele gehören können), Amcache (Pfad und SHA-1, der die genaue Binärdatei nach deren Löschung identifiziert), BAM (letzte Ausführung pro Benutzer-SID) und Shimcache (Vorhandensein). UserAssist zeichnet nur Starts über den Explorer auf, sodass eine Befehlszeilenausführung von SDelete oder cipher dort nicht erscheint. Installierte Tools fügen einen Uninstall-Unterschlüssel unter SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (oder dessen WOW6432Node-Gegenstück), einen Ordner in Program Files und bei MSI-Paketen Ereignisse von MsiInstaller im Anwendungsprotokoll wie 11707 und 1033 hinzu. Downloadaufzeichnungen zeigen, woher ein portables Tool stammt. cipher.exe wird mit Windows ausgeliefert, daher sind nur seine Ausführungsspuren relevant.

Tools speichern außerdem eigene Einstellungen:

• Sysinternals-Tools speichern die Lizenzannahme normalerweise als DWORD EulaAccepted = 1 unter Software\Sysinternals\<tool> in der NTUSER.DAT des Benutzers, beispielsweise Software\Sysinternals\SDelete. Dies verknüpft das Tool mit einem Konto, und der LastWrite-Zeitstempel des Schlüssels liegt üblicherweise nahe an der ersten Ausführung.
• Installierte CCleaner-Versionen speichern Einstellungen unter dem Schlüssel Software\Piriform\CCleaner des Benutzers (portable Versionen verwenden eine Datei ccleaner.ini neben dem Programm). Die Werte zeigen, welche Bereinigungsoptionen ausgewählt wurden. Ihre Namen variieren je nach Version; bestätigen Sie die Bedeutung daher durch Tests mit derselben Version.
• BleachBit speichert Einstellungen in bleachbit.ini: unter Linux in ~/.config/bleachbit/ und unter Windows im Ordner %APPDATA%\BleachBit\ des Benutzers oder bei der portablen Ausgabe neben dem Programm.

Dateisystemmuster

Microsoft dokumentiert, dass SDelete eine Datei nach dem Überschreiben 26-mal umbenennt, dabei jedes Zeichen des Namens durch den jeweils nächsten Buchstaben ersetzt (foo.txt wird zunächst zu AAA.AAA) und sie anschließend löscht. Unter NTFS hinterlässt dies bekanntermaßen für eine MFT-Referenznummer innerhalb etwa einer Sekunde DATA_OVERWRITE (0x00000001), dann Umbenennungspaare aus RENAME_OLD_NAME (0x00001000) und RENAME_NEW_NAME (0x00002000), die von ausschließlich aus A bestehenden Namen zu ausschließlich aus Z bestehenden Namen derselben Länge wie das Original reichen (bei einem 8.3-Namen von AAAAAAAA.AAA bis ZZZZZZZZ.ZZZ), und abschließend FILE_DELETE (0x00000200) mit CLOSE (0x80000000). Sechsundzwanzig Umbenennungen ergeben mindestens 52 Umbenennungsdatensätze, sodass eine solche Häufung in $UsnJrnl auffällt. $LogFile kann dieselben Vorgänge für einen kürzeren Zeitraum enthalten (Lektion 1.4). Veröffentlichte Tests zeigen, dass sich der ursprüngliche Name mitunter aus älteren Datensätzen mit derselben MFT-Referenz, etwa FILE_CREATE oder DATA_EXTEND, wiederherstellen lässt, sofern diese noch im Journal vorhanden sind.

Wiping des freien Speicherplatzes hinterlässt andere Muster: eine oder mehrere sehr große Dateien, die wachsen, bis das Volume voll ist, und anschließend gelöscht werden, sowie unter NTFS (von SDelete dokumentiert) viele kleine Dateien, die freie MFT-Datensätze belegen. Dadurch werden gelöschte MFT-Datensätze unter neuen Namen wiederverwendet und alte gelöschte Metadaten vernichtet. Microsoft dokumentiert, dass cipher /w drei Durchgänge schreibt (0x00, 0xFF, dann Zufallsdaten). Es verwendet temporäre Dateien in einem Ordner namens EFSTMPWP im Stammverzeichnis des Volumes. Der Ordnername kann in der MFT, in $UsnJrnl oder im Verzeichnis-Slack erhalten bleiben.

GNU shred überschreibt an Ort und Stelle (standardmäßig drei Durchgänge in aktuellen coreutils-Versionen). Mit -u benennt es die Datei bekanntermaßen vor dem Entfernen des Verzeichniseintrags in Namen aus Nullen mit abnehmender Länge um. Die Dokumentation warnt davor, dass es auf Dateisystemen, die Daten journalisieren, Copy-on-Write verwenden oder Snapshots vorhalten, sowie auf SSDs weniger wirksam ist. Suchen Sie in der Shell-Historie danach.

Bereinigungstools und die Lücken, die sie hinterlassen

Bereinigungstools wie CCleaner, BleachBit und die Windows-Datenträgerbereinigung löschen überwiegend, statt Inhalte zu überschreiben: Browserverlauf und -cache, zuletzt verwendete Elemente, Sprunglisten, temporäre Dateien, Miniaturansicht-Caches, Prefetch und manchmal Ereignisprotokolle. Die Abdeckung ist nie vollständig. Suchen Sie daher nach Unstimmigkeiten:

• Prefetch enthält nur Dateien, die nach einem bestimmten Zeitpunkt erstellt wurden, während Amcache, BAM, Shimcache und SRUM weiterhin frühere Programme verzeichnen.
• RecentDocs und LNK-Dateien zuletzt verwendeter Elemente sind leer, aber Shellbags (Lektion 2.5), die viele Bereinigungstools standardmäßig nicht erfassen, führen die Ordner weiterhin auf.
• Ein Browserverlauf, dessen ältester Besuch erst wenige Minuten zurückliegt, bei einem Monate zuvor erstellten Profil.
• Das Sicherheitsereignis 1102 oder das Systemereignis 104 dokumentiert ein geleertes Protokoll (Lektion 7.2).
• Die eigene Prefetch-Datei des Bereinigungstools wird etwa 10 Sekunden nach dessen Start geschrieben. Daher übersteht sie die Bereinigung häufig und ermöglicht deren zeitliche Einordnung.

Der früheste erhaltene Eintrag in den bereinigten Artefakten ermöglicht eine Schätzung des Bereinigungszeitpunkts. Bereinigte Dateien werden meist nur gelöscht, sodass $UsnJrnl Häufungen von FILE_DELETE-Datensätzen zeigt und die Inhalte möglicherweise wiederherstellbar sind.

Aktionen und Spuren im Überblick

Grenzen der Interpretation

„Ein Bereinigungstool wurde ausgeführt“ ist eine Tatsache; „der Benutzer beabsichtigte, Beweismittel zu vernichten“ ist eine Schlussfolgerung über die Absicht. Bereinigungstools können zeitgesteuert ausgeführt werden, IT-Mitarbeiter können sie ausführen, und Standardoptionen bereinigen Artefakte, die niemand einzeln ausgewählt hat. Berichten Sie über das Tool, den Zeitpunkt, das Konto, die Ziele und die Einstellungen sowie über den für die Interpretation relevanten Kontext: ein einzelnes benanntes Ziel gegenüber einer allgemeinen Bereinigung, eine erstmalige Ausführung, ein Download kurz vor der Nutzung, die anschließende Löschung des Tools und die zeitliche Beziehung zu anderen fallrelevanten Ereignissen. Überlassen Sie die Beurteilung der Absicht der entscheidenden Instanz.

Wiederherstellung verbliebener Daten

• Volumeschattenkopien (Lektion 2.9) können frühere Versionen enthalten, sofern sie nicht ebenfalls gelöscht wurden.
• Andere Kopien: Cloud-Synchronisierungsordner, E-Mail-Anhänge, andere Wechseldatenträger, Sicherungen und die ursprüngliche Quelle.
• Arbeitsspeicher, Auslagerungsdatei und Ruhezustandsdatei (Lektion 5.4) können Fragmente oder Namen enthalten.
• Carving (Lektion 1.8) funktioniert weiterhin, wenn ein Wiping-Vorgang unterbrochen wurde, unvollständig war oder nur auf einige Dateien angewendet wurde.
• NTFS-Journale und Verzeichnis-Slack bewahren häufig Namen auf.

Durchgerechnetes Beispiel: sdelete64 und q3-files.7z

In dieser Variante des gemeinsamen Falls führt das FAT32-Volume im USB-Abbild (VSN 1A2B-3C4D) q3-files.7z nicht mehr auf. FAT32 besitzt kein Journal, und $UsnJrnl auf C: zeichnet nur C: auf. Die Belege stammen daher vom Host und aus dem Verzeichnis.

1. Prefetch. SDELETE64.EXE-<hash>.pf zeigt eine Ausführungsanzahl von 1 und als letzte Ausführung den FILETIME-Wert 0x01DCB3BFC40639A0 = 134.179.725.123.140.000. Geteilt durch 10.000.000: 13.417.972.512,314 s; abzüglich 11.644.473.600 ergibt Unix 1.773.498.912,314; abzüglich 1.773.446.400 (2026-03-14T00:00:00Z) verbleiben 52.512,314 s = 14 h 35 min 12,314 s, also 2026-03-14T14:35:12Z. Zu den referenzierten Dateien gehören \VOLUME{…}\USERS\ANA\DOWNLOADS\SDELETE\SDELETE64.EXE und \VOLUME{…}\CLIENTS\Q3-FILES.7Z; die Volume-Informationen nennen die Seriennummer 1A2B3C4D: das USB-Volume.
2. Amcache. c:\users\ana\downloads\sdelete\sdelete64.exe mit FileId 0000e1b4c2d9a07f3b65c8d1e2f40a9b7c3d5e6f1a28 (zur Veranschaulichung): SHA-1 e1b4c2d9a07f3b65c8d1e2f40a9b7c3d5e6f1a28, zum Vergleich mit der vom Anbieter veröffentlichten Binärdatei.
3. BAM und NTUSER.DAT. Unter S-1-5-21-…-1001 stehen die Daten 90 CB 61 C8 BF B3 DC 01 = 0x01DCB3BFC861CB90 = 2026-03-14T14:35:19.625Z, 7 Sekunden nach dem Prefetch-Zeitpunkt. Anas Software\Sysinternals\SDelete enthält EulaAccepted = 1 mit LastWrite 2026-03-14T14:35:12Z. Es gibt keinen UserAssist-Eintrag, was mit einem Start über die Befehlszeile vereinbar ist.
4. FAT-Verzeichnis. Das Verzeichnis \Clients enthält einen gelöschten Eintrag, dessen 11-Byte-Namensfeld E5 5A 5A 5A 5A 5A 5A 5A 5A 5A 20 lautet: 0xE5 hat das erste Zeichen ersetzt, sodass ?ZZZZZZZ.ZZ verbleibt (Tools zeigen möglicherweise _ an). Der Name behält die Länge von q3-files.7z (8 + 2 Zeichen), wie es die dokumentierten Buchstabenumbenennungen erwarten lassen. Die Schreibzeit 69 5C = 0x5C69: 0x5C69 >> 11 = 11, (0x5C69 >> 5) & 0x3F = 35, (0x5C69 & 0x1F) × 2 = 18, also 11:35:18 Ortszeit; Datum 6E 5C = 2026-03-14; plus 3 h ergibt 14:35:18Z. Das Größenfeld C9 36 D2 03 = 64.108.233 Bytes entspricht der Größe des Archivs. Bei 64 Sektoren pro Cluster (32.768 Bytes) ergibt das ceil(64.108.233 / 32.768) = 1.957 Cluster; der erste beginnt nicht mehr mit der 7z-Signatur 37 7A BC AF 27 1C. Manche Wiping-Tools kürzen Dateien zuerst, sodass eine erhaltene Größenangabe nicht garantiert ist.
5. Was verschwunden ist und was erhalten bleibt. Der Inhalt auf E: und der ursprüngliche Name im Verzeichnis sind verschwunden. Der Name bleibt in Prefetch und in etwaigen LNK- oder Sprunglisteneinträgen für das Archiv erhalten (Lektion 2.4). Der Inhalt bleibt in der um 14:01:03Z erstellten OneDrive-Kopie erhalten (Lektion 4.6), mit derselben Größe und einem berechenbaren Hash. SRUM kann außerdem Schreibvorgänge von sdelete64.exe im Intervall 14:31:09Z–15:31:09Z ana zuordnen.

Formulierter Befund. „SDelete (sdelete64.exe, SHA-1 wie oben) wurde einmal, um 2026-03-14T14:35:12Z, unter dem Konto ana (S-1-5-21-…-1001) ausgeführt und referenzierte Q3-FILES.7Z auf dem Volume 1A2B-3C4D. Dieses Volume enthält einen gelöschten Eintrag mit einem ausschließlich aus Buchstaben bestehenden Namen derselben Länge, zuletzt geschrieben um 14:35:18Z, mit der Größe des Archivs und ohne 7z-Inhalt. Dies ist mit einer sicheren Löschung von E:\Clients\q3-files.7z durch dieses Tool vereinbar. Eine um 14:01:41Z hochgeladene Kopie bleibt in OneDrive erhalten.“

Prüfungsschwerpunkt: Rechnen Sie damit, den Ausführungszeitpunkt, die Benutzer-SID oder den SHA-1 eines Wiping-Tools anhand von Ausführungsartefakten angeben und das Muster der Buchstabenumbenennungen in $UsnJrnl oder einem FAT-Verzeichnis erkennen zu müssen. Fragen können prüfen, ob Sie wissen, dass Nullen auf einer SSD mit TRIM vereinbar und kein Beweis für Wiping sind, welche Artefakte ein Bereinigungstool intakt lässt und worin der Unterschied zwischen dem Nachweis einer Tool-Ausführung und dem Nachweis einer Absicht besteht.

Kernpunkte

• Wiping ist ein Ereignis: Weisen Sie Tool, Zeitpunkt, Konto und Ziel nach, auch wenn der Inhalt verschwunden ist.
• Ausführungsartefakte (referenzierte Dateien in Prefetch, SHA-1 in Amcache, BAM pro SID) und Tool-Einstellungen (EulaAccepted, CCleaner-Schlüssel, bleachbit.ini) identifizieren das Wiping-Tool und den Benutzer.
• Für SDelete ist dokumentiert, dass es eine Datei vor dem Löschen 26-mal mit wiederholten Buchstaben umbenennt. Unter NTFS hinterlässt dies eine Häufung von Umbenennungsdatensätzen in $UsnJrnl; cipher /w verwendet einen Ordner namens EFSTMPWP.
• Nullen allein beweisen kein Wiping: TRIM auf SSDs erzeugt sie nach normalem Löschen.
• Bereinigungstools hinterlassen Lücken neben intakten Quellen. Vergleichen Sie Prefetch mit Amcache, BAM und SRUM sowie RecentDocs mit Shellbags.
• Suchen Sie in Schattenkopien, Cloud-Ordnern, anderen Medien und Speicherdateien nach erhaltenen Kopien und treffen Sie Aussagen zur Absicht nur insoweit, wie es die Beweislage zulässt.