← Zurück zu allen Beiträgen

Angreifer wissen von Prefetch. Manche versuchen, es auszuhebeln. Die meisten versuchen es und scheitern, denn die Dinge, die man tun muss, um Prefetch zu unterdrücken, hinterlassen eigene Spuren, und die Dinge, die man unterdrücken kann, zählen nur, wenn man auch alles bereinigt, was die Binärdatei berührt hat — was niemand vollständig schafft.

Dieser Beitrag ist ein Durchgang durch die Anti-Forensik-Techniken, die ich tatsächlich gegen Prefetch im Einsatz gesehen habe, geordnet danach, wie viel sie den Angreifer kosten und wie sehr sie die Untersuchung behindern.

Den Prefetcher-Dienst deaktivieren

Der gründlichste Ansatz. Setzen Sie HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher auf 0. Neustart. Prefetch hört auf, neue .pf-Dateien für neue Prozesse zu schreiben.

Drei Probleme für den Angreifer.

Erstens ist die Registry-Änderung selbst laut. Die LastWrite-Zeit von PrefetchParameters aktualisiert sich in dem Moment, in dem der Wert geschrieben wird. Wenn Sie Registry-Transaktionslogs, VSC-Snapshots oder auch nur eine Baseline des Wertes vom selben Host vor dem Vorfall haben, ist die Änderung sichtbar. Der forensische Wert von „EnablePrefetcher wurde gerade zwei Stunden vor dem verdächtigen Fenster geändert" ist hoch.

Zweitens wirkt die Änderung nicht sofort. Der Prefetcher-Dienst cached den Zustand im Speicher. Neue Prefetch-Einträge werden noch eine Zeit lang nach der Registry-Änderung geschrieben, üblicherweise bis das System neu gestartet oder der Dienst neu gestartet wird. Ein Angreifer, der die Registry kippt und seine Tools dreißig Sekunden später ausführt, hat möglicherweise trotzdem .pf-Dateien erzeugt. Ich habe diesen Fall mehrmals gesehen.

Drittens wird das bestehende Prefetch-Verzeichnis durch die Änderung nicht gelöscht. Alle .pf-Dateien aus der Zeit vor der Deaktivierung sind noch da. Wenn der Angreifer sie nicht zusätzlich gelöscht hat, haben Sie eine Aufzeichnung von allem, was bis zum Moment der Änderung auf dem Host lief.

Erkennung: Durchsuchen Sie die SYSTEM-Hive nach der LastWrite-Zeit auf PrefetchParameters und vergleichen Sie sie mit Ihrer Timeline. Wenn der Wert auf 0 oder 1 steht (wo die Policy des Hosts 3 vorsieht), prüfen Sie VSC-Snapshots, wann die Änderung passierte. Eine Änderung innerhalb des verdächtigen Fensters ist selbst ein Ereignis, das untersucht werden sollte, unabhängig davon, was danach getan wurde.

Einzelne .pf-Dateien löschen

Die mit Abstand häufigste Technik. Nach dem Ausführen eines Tools löscht der Angreifer einfach C:\Windows\Prefetch\TOOLNAME-XXXXXXXX.pf. Dafür braucht es Administratorrechte (das Prefetch-Verzeichnis ist geschützt), aber wer Angriffstools laufen lässt, hat sie üblicherweise.

Die Löschung gelingt. Die .pf-Datei ist weg. Der offensichtliche Beweis auch.

Was überlebt:

  • Die MFT. Jede gelöschte .pf-Datei hinterlässt einen MFT-Eintrag, der erhalten bleibt, bis der Slot wiederverwendet wird. Der Eintrag bewahrt Dateiname, Größe, Zeitstempel und (wenn der Eintrag noch resident ist oder die Löschung kurz zurückliegt) manchmal Dateiinhalte. Eine gezielte Löschung einer einzigen .pf bleibt in der MFT sichtbar als „gelöschte Datei, Name PREFETCH/EVIL-AABBCCDD.pf", bis etwas anderes den Eintrag beansprucht.
  • Das USN-Journal. Die Löschung erzeugt einen FILE_DELETE|CLOSE-USN-Datensatz mit dem Dateinamen der .pf. Auf einem stark genutzten Host rollt das Journal über, aber auf den meisten Hosts sehen Sie Wochen USN-Historie. Die Löschung steht drin.
  • Die eigenen NTFS-Zeitstempel des Prefetch-Verzeichnisses. Die Modified-Zeit des Verzeichnisses aktualisiert sich bei jedem Hinzufügen oder Entfernen einer Datei. Wenn Sie eine Baseline haben, ist die Löschung sichtbar. Wenn Sie VSCs haben, sehen Sie den Verzeichnisstand davor.
  • Die anderen Artefakte, die dieselbe Binärdatei referenzierten. AmCache hat noch den Hash. Shimcache hat noch den Namen der Binärdatei. Die MFT hat noch die Binärdatei, sofern sie nicht ebenfalls gelöscht wurde. Die Benutzer-Run-Historie in der Registry hat das Programm noch in UserAssist oder RunMRU. Prefetch ist eines von vielen.

Erkennung: Listen Sie die gelöschten MFT-Einträge des Prefetch-Verzeichnisses auf. Jeder .pf-Dateiname in der Liste der gelöschten Einträge, der nicht im Live-Verzeichnis existiert, ist eine Löschung. Paaren Sie es mit USN-Datensätzen. Der Dateiname gibt Ihnen meist den Namen der ausführbaren Datei; von dort können Sie zu AmCache, Shimcache und dem Rest pivotieren.

Ich habe Fälle abgeschlossen, in denen das einzige direkte Artefakt eines bekannten Angreifer-Tools der MFT-Eintrag für eine gelöschte .pf-Datei war. Die .pf selbst war weg, aber die Rückstände der Löschung nannten das Tool klar beim Namen.

Das gesamte Prefetch-Verzeichnis wipen

Eine aggressivere Variante: alles in C:\Windows\Prefetch\ löschen. Manche Angreifer machen das routinemäßig als Teil ihrer Bereinigung.

Dieselben Rückstände überleben. Die MFT zeigt jetzt dutzende oder hunderte gelöschter .pf-Dateinamen. Das USN-Journal zeigt die Löschungen in Folge, oft im Sekundentakt. Die NTFS-Zeitstempel des Verzeichnisses aktualisieren sich auf den Zeitpunkt des Wipes.

Ein Prefetch-Verzeichnis, das leer ist (oder nur NTOSBOOT-XXXXXXXX.pf enthält, das beim Boot regeneriert wird), auf einer Workstation, die seit Monaten läuft, ist ein schreiendes Warnsignal. Der Normalzustand des Verzeichnisses auf einem lang laufenden Host sind Hunderte Dateien. Leer bedeutet, dass jemand es geleert hat.

Erkennung: Zählen Sie die Einträge im Live-Verzeichnis und vergleichen Sie mit der erwarteten Anzahl für Alter und Nutzung des Hosts. Leere oder fast leere Prefetch-Verzeichnisse auf alten Hosts sind eine zu erklärende Anomalie, kein zu akzeptierender Befund.

Der „Rename vor Run"-Trick

Der clevere Angriff. Kopieren Sie Ihr Tool auf die Festplatte, benennen Sie es in etwas Unauffälliges um, führen Sie es aus, benennen Sie es danach zurück oder löschen Sie es. Der Gedanke: Der Dateiname der .pf-Datei bettet den Binärdateinamen aus dem Executable ein, sodass eine Binärdatei namens update.exe eine UPDATE.EXE-XXXXXXXX.pf erzeugt. Mischen Sie sich unter die bestehenden update.exe-Prefetch-Einträge des Hosts und verstecken Sie sich in aller Öffentlichkeit.

Das ist teilweise wirksam und sehr gut erkennbar.

Was für den Angreifer funktioniert: Der Dateiname der .pf ist tatsächlich nur der Dateiname der ausführbaren Datei zum Ausführungszeitpunkt. Benennen Sie mimikatz.exe vor der Ausführung in update.exe um und Sie erhalten UPDATE.EXE-XXXXXXXX.pf, nicht MIMIKATZ.EXE-XXXXXXXX.pf. Ein Analyst, der das Prefetch-Verzeichnis nach MIMI durchsucht, findet nichts.

Was für den Angreifer nicht funktioniert:

  • Der Hash im Dateinamen kodiert weiterhin den Pfad. Eine umbenannte Mimikatz unter C:\Users\Public\update.exe erzeugt einen anderen Hash als die legitime update.exe unter C:\Program Files\<Hersteller>\update.exe. Sie können den doppelten Namen mit zwei unterschiedlichen Hashes erkennen.
  • Die Load-Liste verrät die Binärdatei weiterhin. Die umbenannte Mimikatz lädt noch immer DLLs vom sekurlsa.dll-Typ und berührt LSASS-nahe Pfade. Section C der .pf zeigt diese Pfade unabhängig vom Namen der ausführbaren Datei.
  • Der von Prefetch aufgezeichnete Pfad der ausführbaren Datei ist immer noch der reale Pfad, von dem die Binärdatei lief. Auch umbenannt lebt die Binärdatei irgendwo, und die .pf weiß, wo. C:\Users\Public\update.exe als Prefetch-Pfad auf einem Host, auf dem update.exe unter Program Files leben sollte, ist selbst schon eine Anomalie.

Erkennung: Suchen Sie nie allein nach dem Namen der ausführbaren Datei. Suchen Sie im Prefetch-Verzeichnis nach jeder Binärdatei, deren aufgezeichneter Pfad außerhalb der Standard-System- oder Programmverzeichnisse liegt, unabhängig vom Namen. Die Menge der „Binärdateien mit benutzerschreibbaren Pfaden" ist auf einem normalen Host klein. Der Rename-Trick ergänzt diese Menge; er verschwindet nicht darin.

.pf-Dateien in-place modifizieren

Der fortgeschrittene Ansatz. Einige Angreifer haben Tools geschrieben, die Prefetch-Dateien bearbeiten: den Ausführungszähler reduzieren, einen Ausführungszeitstempel entfernen, einen Pfad aus der Load-Liste herausschneiden. Ich habe das in sieben Jahren Praxis zweimal versucht gesehen.

Es ist sehr fragil. Das Prefetch-Dateiformat hat interne Offsets, Section-Size-Felder und (auf einigen Versionen) Prüfsummen. Den Ausführungszähler zu bearbeiten, ohne den Rest der Struktur neu zu schreiben, ist machbar. Die Load-Liste zu bearbeiten erfordert das Neuberechnen von Offsets durch Section A und Section C und gelingt selten korrekt.

Erkennung: strukturelle Validierung. Lassen Sie die Datei durch einen strikten Parser laufen, der jeden Offset und jede Länge gegen die deklarierten Größen der Datei prüft. Tools wie PECmd melden inkonsistente Dateien, auch wenn sie diese nicht immer ablehnen. Eine .pf-Datei, deren interne Größen nicht zur On-Disk-Größe passen oder deren Section A String-Offsets außerhalb von Section C referenziert, ist entweder beschädigt oder manipuliert.

Ich habe in einer realen Untersuchung noch keine erfolgreiche In-place-Manipulation persönlich erwischt. Die Versuche, die ich gesehen habe, produzierten Dateien, die offensichtliche Invarianten brachen. Allerdings ist die Technik für einen ausgefeilten Angreifer plausibel, und ich würde nicht annehmen, dass eine Prefetch-Datei kanonisch ist, nur weil sie parst.

Warum Prefetch länger überlebt als Shimcache

Shimcache schreibt nur beim Herunterfahren. Ein Angreifer, der weiß, was er tut, kann den Shimcache wegblasen, indem er das System unsauber beendet oder den AppCompatCache-Registry-Wert vor dem Herunterfahren überschreibt.

Prefetch schreibt kontinuierlich, als Nebeneffekt des normalen Betriebs. Es gibt kein „Flush beim Herunterfahren", das man überspringen kann. Um zu verhindern, dass eine .pf-Datei geschrieben wird, muss man den Prefetch-Dienst stoppen, bevor die Binärdatei läuft — was die Registry-Änderung von oben erfordert, die selbst laut ist. Um eine .pf-Datei nach dem Schreiben zu entfernen, muss man sie löschen, was MFT- und USN-Rückstände hinterlässt.

Deshalb vertraue ich Prefetch mehr als Shimcache für Ausführungsbehauptungen. Nicht weil Prefetch genauer ist (Shimcache deckt in mancher Hinsicht mehr Binärdateien ab), sondern weil Prefetch schwerer zu unterdrücken ist, ohne Spuren zu hinterlassen.

Gegenmaßnahmen für Verteidiger

Wenn Sie auf der Verteidigerseite stehen, erschweren die folgenden Punkte einem Angreifer das Bereinigen von Prefetch:

  1. Leiten Sie das USN-Journal an ein SIEM weiter. Selbst ein Sampling-Feed erfasst Massen-.pf-Löschungen in Sekunden.
  2. Auditieren Sie Registry-Schreibvorgänge auf PrefetchParameters über die EVTX-Registry-Audit-Policy oder Sysmon EID 13. Jede Änderung an EnablePrefetcher oder EnableSuperfetch ist alarmwürdig.
  3. Snapshotten Sie die Prefetch-Verzeichnisliste nächtlich. Ein Diff von gestern Abend auf heute morgen fängt Massenlöschungen und Massenanlagen.
  4. Snapshotten Sie auch die SRUM- und AmCache-Datenbanken. Verteidigung in der Tiefe über Ausführungsartefakte hinweg bedeutet, dass ein Angreifer vier Dinge bereinigen muss, nicht eines.
  5. Blockieren Sie Schreibzugriffe auf C:\Windows\Prefetch\ aus Nicht-System-Kontexten per WDAC- oder AppLocker-Regeln. Die meisten Angreifer laufen mit SYSTEM und umgehen das, aber die Hürde anzuheben ist selten verschenkt.

Was ich Kunden erzähle

Prefetch ist das Artefakt, das Angreifer am häufigsten zu bereinigen meinen und am häufigsten nicht bereinigt haben. Die Technik, die tatsächlich funktioniert (deaktivieren, ausführen, reaktivieren), ist die operativ aufwendigste, erfordert Neustart-Timing und ist über Registry-Änderungsverfolgung am besten erkennbar. Die populärste Technik (die .pf nach dem Lauf löschen) hinterlässt Rückstände, die Sie in MFT, USN und benachbarten Artefakten als Pivot nutzen können.

Behandeln Sie ein leeres oder frisch beschnittenes Prefetch-Verzeichnis nicht als Abwesenheit von Beweisen, sondern als Beweis einer Intervention. Dann finden Sie die Intervention.

Weiterführende Literatur