Manipulation an Windows Prefetch erkennen

Prefetch ist eines der saubersten Ausführungsartefakte, die Windows erzeugt, und genau deshalb haben es kompetente Angreifer im Visier. Die gute Nachricht: Angreifer sind bei Prefetch häufiger schlampig als vorsichtig, und jede gängige Manipulationsform hinterlässt anderswo auf dem Host eine Spur. Hier ist, wie das jeweils aussieht, wenn Sie sich mit den Daten hinsetzen.

Flächendeckende Löschung

Die grobe Variante ist del /q C:\Windows\Prefetch\*.pf oder ein PowerShell-Äquivalent. Sie ist schnell, sie ist laut und sie funktioniert, solange niemand das Ergebnis mit einer Baseline vergleicht.

Signal: Dateianzahl, die deutlich unter dem liegt, was OS-Version und Uptime produzieren sollten. Eine Windows-11-Workstation, die seit sechs Monaten online ist und mit zwölf .pf-Dateien dasteht, ist keine saubere Installation. Selbst ein frisches Win10-Image erreicht innerhalb einer Woche die niedrigen Hunderter.

Gegenanalyse: Dateilöschungen sind USN-Events. Ziehen Sie das USN-Journal und grep nach .pf, um Dateinamen und Löschzeitstempel zu rekonstruieren. Das NTFS-$LogFile (noch resident, viel kürzeres Zeitfenster) enthält oft denselben Beleg mit Attribut-Details. Der eigene MFT-Eintrag des Verzeichnisses behält eine Last-Modified-Zeit, die den Zeitpunkt der Bereinigung festnagelt. Kombinieren Sie mit dem Security- oder Sysmon-EVTX rund um dieses Fenster und Sie identifizieren in der Regel den Prozess, der es getan hat.

Gezielte Löschung

Die sorgfältige Variante: nur die einzelne .pf-Datei der bösartigen Binärdatei löschen, alles andere stehen lassen. Allein anhand der Dateianzahl deutlich schwerer zu erkennen.

Signal: eine Ausführung, die Sie anderweitig nachweisen können — Security 4688, Sysmon EID 1, AmCache, Shimcache, LNK- oder Jump-List-Einträge —, ohne dass eine entsprechende .pf-Datei existiert. Auf einem Host, auf dem EnablePrefetcher = 3 und der SysMain-Dienst aktiv ist, ist diese Lücke kein Zufall.

Gegenanalyse: Carven Sie den unallozierten Bereich des Systemvolumes. Xpress-Huffman-komprimiertes Prefetch beginnt mit MAM\x04 — eine Vier-Byte-Signatur, die in normalen Daten selten ist. Sowohl bulk_extractor als auch eine schnelle scalpel-Regel holen gelöschte .pf-Dateien zurück, sofern ihre Cluster noch nicht wiederverwendet wurden. Prüfen Sie auch Volume Shadow Copies; Prefetch-Verzeichnisse überleben oft in älteren Snapshots.

Eingeschleuste Prefetch-Dateien

Eine .pf von einer anderen Maschine auf das Ziel kopieren. Wird verwendet, um ein Alibi zu fabrizieren, in Red-Team-Übungen, um SOC-Erkennung zu testen, gelegentlich von Malware, die so wirken will, als wäre sie schon länger da.

Signal: Der 8-Zeichen-Hash im Dateinamen passt nicht zu dem, was die Hash-Funktion 5 unter Win7+ für den im Payload eingebetteten Pfad der ausführbaren Datei erzeugt. Neu berechnen und vergleichen. Eine Abweichung ist schlüssig.

Weitere Hinweise: NTFS-Dateisatz-Zeitstempel, die den FILETIME-Werten in der Datei widersprechen (eine .pf kann nicht gelaufen sein, bevor sie existierte); identische Ausführungszeitstempel über „verschiedene" Einträge hinweg, was meist bedeutet, dass der Angreifer dieselbe Vorlage kopiert hat und vergaß, die Byte-Bereiche zu variieren; Volume-Seriennummern in der Volume-Informationssektion, die nicht zu den Volumes dieses Hosts passen.

Gefälschte Ausführungszähler und Zeitstempel

Die chirurgische Variante: eine echte .pf in-place bearbeiten, um den Ausführungszähler zu senken oder die acht Last-Run-FILETIME-Slots neu zu schreiben. Selten, weil dafür ein Verständnis des SCCA-Layouts erforderlich ist, aber es kommt vor.

Signal: Wo SCCA-Prüfsummen vorhanden sind, scheitern sie. Die Last-Modified-Zeit in der MFT deckt sich nicht mit dem jüngsten FILETIME in der Datei. Ausführungszähler, die zwischen zwei Erfassungen sinken, sind unter normalem Windows-Verhalten unmöglich — SysMain zählt nur hoch —, also bedeutet ein Rückgang, dass etwas die Datei überschrieben hat.

Prefetch vor dem Angriff deaktiviert

Die billigste Anti-Forensik besteht darin, das Artefakt erst gar nicht entstehen zu lassen. Setzen Sie EnablePrefetcher = 0 und EnableSuperfetch = 0, stoppen Sie SysMain, und der Host schreibt keinerlei .pf-Dateien mehr. Im Beitrag zum deaktivierten Server finden Sie das Registry-Layout im Detail.

Signal: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher = 0 auf einer Workstation, deren Standardwert 3 ist, kombiniert mit einem leeren C:\Windows\Prefetch\. Gegenprüfung über den Registry-Hive-Parser gegen eine ältere Volume Shadow Copy — wenn der Wert mitten in der Uptime von 3 auf 0 gewechselt hat, sagt Ihnen die LastWrite-Zeit der SYSTEM-Hive, wann es geschah, und das EVTX für dieses Fenster meist, wer es war.

Zusammenführen

Die Frage in einem strittigen Fall lautet selten „Wurde diese Binärdatei ausgeführt?". Sie lautet „Kann ich die Behauptung verteidigen, dass diese .pf das aussagt, was sie aussagt?". Behandeln Sie jeden Eintrag wie jedes andere Beweisstück: untermauern Sie ihn. Ein einzelner Prefetch-Treffer ist ein Hinweis. Ein Prefetch-Treffer, der mit AmCache-Hashes, Shimcache-Pfaden, USN-Schreibevents und einem Security 4688 oder Sysmon 1 zusammenpasst, ist Zeugenaussage.

Weiterführende Literatur

• Joachim Metz, libscca-Dokumentation — für das exakte Feldlayout, das Sie zum Erkennen von In-Place-Edits benötigen.
• Eric Zimmerman, PECmd — legt die SCCA-Felder offen, die Sie gegen den Dateinamen-Hash gegenprüfen.