← Zurück zu allen Beiträgen

Die erste Hälfte jedes Gesprächs, das ich über Prefetch auf einem Win10- oder Win11-Host führe, verwandelt sich in ein Gespräch über SuperFetch, SysMain, ReadyBoost und was auch immer Microsoft die Speicherverwaltungs-Features in einem bestimmten Quartal gerade nannte. Die Hälfte der Anwesenden denkt, sie seien dasselbe. Die Hälfte denkt, Prefetch sei deprecated. Beide Hälften liegen falsch, aber in unterschiedliche Richtungen, und die Missverständnisse beeinflussen, wie weit man dem Prefetch-Verzeichnis auf einem modernen Host trauen kann.

Dieser Beitrag ist die saubere Version dieses Gesprächs.

Was jedes davon tatsächlich ist

Prefetch ist der dateiweise Cache für Anwendungsstart. Beobachtet die ersten zehn Sekunden eines Prozesses, schreibt eine .pf-Datei und verwendet diese Datei beim nächsten Start, um die Seiten vorzuladen, die der Prozess wahrscheinlich braucht. Lebt in C:\Windows\Prefetch\. Das ist das Artefakt, das uns interessiert.

SuperFetch war ein Speicherverwaltungs-Feature, das mit Windows Vista eingeführt wurde. Es verfolgt die Anwendungsnutzungsmuster im Zeitverlauf (nicht nur beim Start, sondern während der normalen Nutzung) und lädt häufig verwendete Anwendungen während Idle-Phasen proaktiv in den RAM, damit sie schneller starten. Es schreibt seine Tracking-Daten in Ag*.db-Dateien in C:\Windows\Prefetch\. Diese .db-Dateien sind keine Prefetch-Dateien. Sie sind SuperFetch-Datenbanken.

SysMain ist das, wozu SuperFetch in Windows 10 1709 umbenannt wurde. Gleiches Feature, gleiche Dienstbinärdatei (sysmain.dll), gleiche .db-Dateien im Prefetch-Verzeichnis. Der Dienst, der in services.msc „Superfetch" hieß, heißt auf jedem aktuellen Win10/11-Host „SysMain". Die Umbenennung war kosmetisch.

ReadyBoost ist ein separates Feature, das USB-Flash-Speicher als Write-Through-Cache für den Working Set verwendet. Nicht relevant für forensische Prefetch-Analyse, lebt aber im selben konzeptionellen Umfeld und wird daher mit den anderen verwechselt.

Die drei Prefetch-angrenzenden Artefakte auf einem Win10/11-Host sind daher:

  • C:\Windows\Prefetch\<EXE>-<HASH>.pf: Per-Anwendungs-Prefetch-Spuren, das Artefakt, um das es auf dieser ganzen Seite geht.
  • C:\Windows\Prefetch\AgAppLaunch.db und Freunde: SysMain-Datenbanken, die ein separates Artefakt sind (SRUM und SysMain-Datenbanken sind unterschiedliche Dinge, beide nützlich, beide nicht Prefetch).
  • C:\Windows\Prefetch\NTOSBOOT-XXXXXXXX.pf: das Boot-Prefetch, bei jedem Boot regeneriert.

Wenn jemand „das Prefetch-Verzeichnis" sagt, meint er üblicherweise das erste. Wenn er „Prefetch" ohne Kontext sagt, meint er vermutlich auch das erste, aber es lohnt sich, beim Schreiben eines Berichts präzise zu sein.

Die SSD-Deaktivierungsfrage

Hier ist der Teil, der immer wieder hochkommt.

Auf Vista und Windows 7 waren sowohl Prefetch als auch SuperFetch für alle aktiviert, auf jedem Festplattentyp. Auf Windows 8 fügte Microsoft Logik hinzu, um SSDs zu erkennen und bestimmte Operationen darauf zu reduzieren oder zu deaktivieren, basierend auf der Annahme, dass SSDs nicht so von sequenziellem Vorladen profitieren, wie HDDs es tun.

Auf Windows 10 wurde diese Logik aggressiver. Auf Windows 11 noch aggressiver.

Was „auf SSDs deaktiviert" in der Praxis bedeutet, soweit ich es aus Telemetrie und Microsofts eigener variabler Dokumentation feststellen konnte:

  • Boot-Prefetch (NTOSBOOT-XXXXXXXX.pf) wird immer geschrieben.
  • Anwendungs-Prefetch (per-.exe-.pf-Dateien) wird teilweise geschrieben. Einige Anwendungen erzeugen .pf-Dateien; andere nicht. Die Entscheidung scheint von SysMain anhand von Heuristiken getroffen zu werden, ob die Anwendung vom Prefetching profitieren würde.
  • Proaktives Vorladen via SuperFetch/SysMain ist auf SSDs weitgehend deaktiviert, weil Microsoft die Latenzreduktion den I/O-Kosten nicht wert findet.

Die forensische Konsequenz: Auf einem Win10- oder Win11-Host mit SSD ist die Abwesenheit einer .pf-Datei für eine bestimmte ausführbare Datei kein Beweis dafür, dass die Binärdatei nicht lief. Es ist ein Beweis dafür, dass entweder die Binärdatei nicht lief oder SysMain entschied, keine Prefetch-Daten dafür zu schreiben.

Empirisch habe ich Prefetch-Abdeckungen von 60 % bis 90 % auf SSD-gestützten Win11-Hosts gesehen, verglichen mit nahezu 100 % auf HDD-gestützten Win10-Hosts. Der genaue Prozentsatz hängt vom Workload des Hosts, davon, welche ausführbaren Dateien Microsofts Heuristiken überspringen, und davon, ob das System unter Speicherdruck steht.

Wenn Sie mit Sicherheit wissen müssen, ob eine Binärdatei lief, verlassen Sie sich nicht auf die Abwesenheit einer .pf-Datei auf einem modernen SSD-gestützten Host. Paaren Sie mit EVTX, AmCache und der tatsächlichen Prozess-Ausführungs-Telemetrie des Hosts.

Die Registry-Schalter

Der Registry-Pfad, der all das steuert, ist:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

Die Werte, die zählen:

  • EnablePrefetcher (REG_DWORD). Steuert Anwendungs-Prefetch.
    • 0 = deaktiviert
    • 1 = nur Anwendungs-Prefetch
    • 2 = nur Boot-Prefetch
    • 3 = beides (Standard auf den meisten Client-SKUs)
  • EnableSuperfetch (REG_DWORD). Gleiche möglichen Werte, steuert SuperFetch/SysMain.
  • EnableBootTrace (REG_DWORD). Steuert die Boot-Trace. Üblicherweise 0 auf Client-SKUs, die den Rest aktiviert haben.

Auf einer Standard-Windows-10/11-Pro-Installation sehen Sie EnablePrefetcher = 3 und EnableSuperfetch = 3. Auf einer Standard-Windows-Server-Installation sind beide typischerweise 0. Auf Hosts, auf denen Gruppenrichtlinien Dinge angepasst haben, können Sie jeden Wert sehen.

Die SSD-Erkennungslogik ändert diese Werte nicht. Auch bei EnablePrefetcher = 3 kann das OS auf einem SSD-gestützten Host bestimmte .pf-Dateien immer noch überspringen. Sie können aus einer 3 in der Registry auf Win10+ nicht schließen, dass „Prefetch vollständig sein wird".

Die ehrliche Zusammenfassung: Die Registry sagt Ihnen, ob Prefetch administrativ aktiviert ist. Sie sagt nicht, ob Prefetch für eine bestimmte Ausführung tatsächlich geschrieben wurde. Auf Win7 und früher waren diese beiden Aussagen identisch. Auf Win10+ nicht.

Was sich bei Win10 1709 änderte

Das 1709-Release („Fall Creators Update") ist die Version, in der:

  • SuperFetch zu SysMain umbenannt wurde.
  • Der Acht-Ausführungszeitstempel-Ring von Anwendungs-Prefetch begann, während Idle-Wartungsfenstern aggressiv gekürzt zu werden. Eine .pf, die acht Ausführungszeiten zeigen sollte, zeigt vielleicht nur drei auf einem Host, der eine Weile läuft.
  • Das SSD-bewusste Überspringen von .pf-Schreibvorgängen aggressiver wurde als in früheren Win10-Builds.

Wenn Sie ältere DFIR-Literatur über Prefetch lesen (alles, was vor 2018 geschrieben wurde), gehen Sie davon aus, dass der Autor in einer Pre-1709-Welt arbeitete und einige seiner Annahmen über Prefetch-Abdeckung nicht mehr gelten.

Die folgenreichste davon ist das Kürzen der Zeitstempel. Die klassische Lehre lautet „Prefetch behält die letzten acht Ausführungszeiten". Die korrigierte Lehre lautet „Prefetch behält bis zu acht Ausführungszeiten, wobei Win10 1709+ ältere Einträge opportunistisch kürzt". Eine .pf, die drei Zeitstempel zeigt, bedeutet nicht, dass die Binärdatei dreimal lief. Es bedeutet, dass der Ausführungszähler eine Sache sagt (die untere Grenze der Gesamtläufe) und das Zeitstempel-Array drei Zeiten zeigt, die das Kürzen überlebt haben.

Windows Server

Erneut klar gesagt: Prefetch ist auf Windows Server standardmäßig deaktiviert. Von 2008 R2 bis 2022 ist der Standardwert von EnablePrefetcher auf einer frischen Server-Installation 0. SysMain ist ebenfalls aus.

Viele Estates aktivieren Prefetch auf Servern per GPO. Viele nicht. Wenn Sie an einem Server-Engagement arbeiten und das Prefetch-Verzeichnis leer ist, ist das Erste, was zu prüfen ist, ob Prefetch auf diesem Host je aktiviert war. Ziehen Sie die SYSTEM-Hive, lesen Sie den Wert, prüfen Sie die LastWrite-Zeit. Wenn der Wert zuletzt zur OS-Installationszeit geschrieben wurde und 0 lautet, sagt die Abwesenheit von .pf-Dateien nichts darüber, was lief.

Wenn der Wert vor sechs Monaten auf 3 geändert wurde und das Verzeichnis nur .pf-Dateien aus den letzten sechs Monaten enthält, ist das konsistent. Wenn der Wert vor zwei Tagen geändert wurde und das Verzeichnis Dateien von davor enthält, haben Sie eine Diskrepanz, die zu erklären ist (üblicherweise wurde die Policy kürzlich angewendet, aber das Verzeichnis hat Dateien aus der OS-Installations-Ära oder aus einem früheren Policy-Zustand).

Was vor dem Vertrauen in eine .pf-Datei zu verifizieren ist

Bevor ich Prefetch in einem Bericht auf einem Win10/11-Host zitiere, prüfe ich:

  1. Ist Prefetch aktiviert? Ziehen Sie EnablePrefetcher und EnableSuperfetch aus der SYSTEM-Hive. Notieren Sie die LastWrite-Zeit auf PrefetchParameters.
  2. War es zum Zeitpunkt der relevanten Ereignisse aktiviert? Wenn der Wert während des verdächtigen Fensters geändert wurde, ist die Änderung Teil der Timeline.
  3. Ist der Host SSD oder HDD? Prüfen Sie den Festplattentyp aus den Systeminfos. Auf SSDs senken Sie Ihre Konfidenz in „Abwesenheit von .pf = Abwesenheit von Ausführung".
  4. Ist der Host ein Server? Wenn ja, berücksichtigen Sie den Standardzustand „aus" und die Policy-Historie.
  5. Gibt es Ag*.db-Dateien im Prefetch-Verzeichnis? Wenn ja, läuft SysMain, und seine Datenbank kann zusätzliche Ausführungsdaten enthalten, die von .pf-Dateien getrennt sind.
  6. Parst PECmd die .pf-Dateien sauber? Inkonsistente Dateien oder Dateien, die die Parser-Validierung nicht bestehen, verdienen einen zweiten Blick auf Manipulation.

Wenn alle sechs in Ordnung sind, ist die Prefetch-Evidenz solide. Wenn nicht, hat die Prefetch-Evidenz immer noch Wert, aber mit Vorbehalten, die im Bericht erscheinen sollten.

Eine Notiz zu den SysMain-Datenbanken

Die Ag*.db-Dateien im Prefetch-Verzeichnis sind ein separates Artefakt und eines Tages eine eigene Diskussion wert. Kurz: AgAppLaunch.db verfolgt Anwendungs-Launch-Zähler und -Zeiten über längere Fenster, als Prefetch es tut. Es kann Prefetch untermauern und manchmal Ausführungen abdecken, die Prefetch übersehen hat.

Tools, um diese zu parsen, existieren, sind aber weniger ausgereift als Prefetch-Parser. Eric Zimmerman hat darüber geschrieben. Das Format ist von Microsoft undokumentiert und reverse-engineert, behandeln Sie Parser-Output also mit angemessener Skepsis.

Was ich Kunden erzähle

Auf Win7 und früher ist Prefetch umfassend. Auf Win10 HDD-gestützt: umfassend. Auf Win10 SSD-gestützt: teilweise. Auf Win11 SSD-gestützt: noch teilweiser. Auf Windows Server: abhängig von der Policy.

Die richtige Antwort auf „gibt es eine Prefetch-Datei für Binärdatei X" ist nie die einzige Frage. Die richtige Antwort auf „sollte ich eine erwarten angesichts der Konfiguration dieses Hosts" ist die Frage, die vor der ersten zu stellen ist.

Weiterführende Literatur