← Zurück zu allen Beiträgen

Windows Prefetch verstehen

Windows-Prefetch-Dateien (.pf) liegen in C:\Windows\Prefetch\ und enthalten Metadaten zu jeder ausführbaren Datei, die das Betriebssystem auf einem Workstation-Host gestartet hat. Sie sind das zuverlässigste Ausführungsartefakt, das die meisten Analysten in einer normalen Woche überhaupt anfassen. Eine Binärdatei muss nicht installiert, persistent, signiert oder überhaupt noch auf der Festplatte vorhanden sein, damit ihre .pf-Datei erhalten bleibt.

Jede .pf-Datei trägt den Namen <EXECUTABLE>-<HASH>.pf. Die acht Hex-Zeichen sind ein Hash des vollständigen Startpfads, codiert in UTF-16, mit dem Präfix \DEVICE\HARDDISKVOLUME{n}\. Der Byte-Inhalt der Binärdatei selbst fließt nie in den Hash ein. Zwei Kopien einer identischen Binärdatei unter C:\Program Files\Tool\tool.exe und C:\Users\victim\AppData\Local\Temp\tool.exe erzeugen zwei unterschiedliche .pf-Dateien. Genau diese Eigenschaft macht es möglich, dass Prefetch eine legitime Herstellerbinärdatei von derselben Binärdatei unterscheidet, die in ein Benutzerverzeichnis abgelegt wurde.

Was eine geparste .pf-Datei tatsächlich enthält

Für jede .pf-Datei, die in den Parser gelegt wird, erhalten Sie:

  • Den im SCCA-Payload aufgezeichneten Namen der ausführbaren Datei.
  • Die SCCA-Versionsnummer. v17 unter XP/Vista/7, v23 unter Win8, v26 unter Win8.1, v30 unter Win10, v31 unter Win11. Die Version sagt Ihnen, welches Header-Layout gilt und wie viele Last-Run-Slots existieren.
  • Den Ausführungszähler. Monoton. SysMain erhöht ihn ausschließlich; ein Wert, der zwischen zwei Erfassungen sinkt, ist unter normalem Windows-Verhalten unmöglich.
  • Last-Run-Zeiten. Bis zu acht FILETIME-Werte ab v26+, einer in früheren Versionen. Jeder ist ein u64 mit 100-Nanosekunden-Ticks seit dem 01.01.1601 UTC, in UTC, und markiert den Zeitpunkt, an dem Windows die Überwachung des Prozesses begonnen hat.
  • Volume-Informationen. Gerätepfad, NTFS-Seriennummer und Erstellungszeitstempel für jedes Volume, auf das die Binärdatei verwiesen hat. Die Seriennummer ist dieselbe, die LNK-Dateien und die MFT aufzeichnen.
  • Die Dateimetrik-Liste. Jeden Pfad, den Windows in den ersten zehn Sekunden der überwachten Ausführung verfolgt hat: DLLs, Konfigurationsdateien, Datendateien, alles, was einen Page Fault auf einer Datei verursacht hat, die Windows kannte. Typischerweise einige hundert Einträge bei einer echten Anwendung.

Das reicht, um zu beantworten, ob diese Binärdatei lief, wann, woher und was sie berührt hat, was etwa 70 % der Ausführungsfragen eines normalen Einsatzes abdeckt.

Warum clientseitiges WebAssembly

.pf-Dateien sind Beweismittel. Sie zur Verarbeitung an einen Drittanbieter-Webdienst hochzuladen, untergräbt die Beweiskette und legt Dateipfade, Volume-Seriennummern und Benutzerverzeichnisnamen offen, die für sich genommen sensibel sein können. Der Parser auf dieser Seite kompiliert einen reinen Rust-SCCA-Decoder (frnsc-prefetch) zu WebAssembly und führt ihn in einem Web Worker innerhalb des Browsers aus. Die Bytes verlassen den Rechner nie. Kein Upload-Endpunkt, keine Telemetrie über Dateiinhalte.

Die entsprechenden Desktop-Tools sind PECmd (Eric Zimmerman, .NET) und libscca (libyal, C mit Python-Bindings über pyscca). Wählen Sie, was in Ihre Pipeline passt. Für eine schnelle Triage auf einem Host, auf dem Sie lieber nichts installieren möchten, ist der Browser-Parser schneller als die Bereitstellung einer Tooling-VM.

Das Kompressionsproblem ab Win8

Ab Windows 8 komprimiert SysMain die .pf-Dateien, bevor sie auf die Festplatte geschrieben werden. Jede Datei beginnt mit MAM\x04, gefolgt von einem u32-Feld mit der unkomprimierten Größe und anschließend einem Xpress-Huffman-komprimierten Payload. Tools aus der Zeit vor Windows 8, die nicht aktualisiert wurden, lesen die MAM-Bytes als Anfang eines SCCA-Headers und produzieren stillschweigend falsche Ausgaben. Wenn ein Parser behauptet, Windows 10 zu unterstützen, aber Ihre Dateien nicht lesen kann, prüfen Sie als Erstes, ob er überhaupt einen Xpress-Huffman-Decoder in der Pipeline hat.

Der Parser auf dieser Seite erkennt MAM-komprimierte und unkomprimierte Legacy-Dateien automatisch. Das MAM-Framing hat sich seit Windows 8 nicht geändert; nur der SCCA-Payload darin hat sich verändert.

Wie man die Ergebnisse liest

Für die Triage sortieren Sie absteigend nach der NTFS-Erstellungszeit und sehen sich die jüngsten Einträge zuerst an. Sortieren Sie aufsteigend nach Ausführungszähler und sehen Sie sich die Binärdateien mit nur einer Ausführung an. Diese sind in der Regel interessanter als jene, die hundertmal liefen. Erweitern Sie für jeden Kandidaten die Dateimetrik-Liste und suchen Sie nach DLL-Ladepfaden in benutzerbeschreibbaren Verzeichnissen, Verweisen auf Dokumente, die zu einer Phishing-Behauptung passen, oder nach Konfigurationsdateien in \AppData\Roaming\, die zu bekannten Malware-Mustern passen.

Dann untermauern Sie. Prefetch allein beweist, dass ein Prozess gestartet wurde. Es beweist nicht, wer ihn gestartet hat, mit welchen Argumenten, oder dass die Binärdatei auf der Festplatte heute die Binärdatei ist, die damals lief. Kombinieren Sie mit AmCache für den SHA-1, Shimcache zur Pfad-Bestätigung, dem USN-Journal, um zu wissen, wann die Binärdatei auf der Festplatte erschien, und der Security- oder Sysmon-EVTX für Befehlszeile und Benutzerkontext. Der dedizierte Beitrag zu Prefetch als Beweismittel führt durch den vollständigen Workflow.

Probieren Sie es aus

Legen Sie eine .pf-Datei oder ein gesamtes C:\Windows\Prefetch\-Verzeichnis in den Parser. Sie erhalten eine sortierbare, durchsuchbare Tabelle jeder Ausführung mit Drilldown in Volumes und die Dateimetrik-Liste. Klicken Sie auf Download JSON, um strukturierte Ausgaben für jq, ein Notebook oder Ihre Falltimeline zu exportieren.

Weiterführende Literatur