„Lief das Programm?" ist die einfachste Frage in einer Windows-Untersuchung und die, die Analysten am häufigsten falsch beantworten. Die Versuchung besteht darin, eine .pf-Datei mit dem richtigen Namen zu finden und das so zu nennen. In der Mehrzahl der Fälle ist das korrekt. In der Minderheit ist es gefährlich, und genau in dieser Minderheit leben strittige Untersuchungen.

In diesem Beitrag geht es um die Grenzen der Prefetch-Ausführungsbeweis-Aussage. Was sie wirklich sagt. Was sie nicht sagt. Und wie Sie sie mit den Artefakten festigen, die daneben überleben.

Die Aussage, präzise formuliert

Wenn der Prefetch-Dienst beobachtet, dass ein Prozess startet, und durch die ersten zehn Sekunden seiner Ausführung kommt, schreibt (oder aktualisiert) er eine .pf-Datei. Der Dateiname bettet den Binärdatei-Namen des Executables (in Großbuchstaben, auf 29 Zeichen abgeschnitten) und einen aus dem vollständigen Pfad abgeleiteten Hash ein.

Die Aussage, die eine .pf-Datei stützt, sorgfältig formuliert, lautet also:

Ein Prozess wurde auf diesem Host gestartet, dessen primäre ausführbare Datei den Namen EXAMPLE.EXE hatte und dessen aufgelöster Pfad den Hash 0x1234ABCD erzeugte, zu den im Array der Ausführungszeitstempel der Datei aufgezeichneten Zeiten, und wurde vom Prefetch-Dienst lange genug beobachtet, um aufgezeichnet zu werden.

Alles außerhalb dieses Satzes ist Schlussfolgerung, nicht direkter Beweis.

Das ist immer noch eine stärkere Aussage als das, was Sie von Shimcache („Windows hat die Metadaten dieser Binärdatei irgendwann angesehen") oder AmCache („Windows hat diese Binärdatei für Kompatibilitätszwecke aufgezählt, was normalerweise, aber nicht immer Ausführung impliziert") erhalten. Prefetch verlangt, dass der Prozess tatsächlich startet. Das ist schwer aus Versehen zu fälschen.

Wie der Pfad-Hash funktioniert und wo er lügt

Der Hash im Dateinamen ist kein Inhalts-Hash. Er ist eine Funktion des vollständigen Pfads des Executables (mit einigen zusätzlichen Kontextfeldern auf neueren Windows-Builds, wie Befehlszeilenargumenten und Paketkennungen für UWP-Apps). Zwei Binärdateien mit demselben Namen in zwei verschiedenen Verzeichnissen erzeugen zwei verschiedene .pf-Dateien. Das ist die Eigenschaft, mit der Sie auf einen Blick C:\Program Files\PsExec.exe von C:\Users\victim\AppData\Local\Temp\PsExec.exe unterscheiden können.

Aber der Pfad ist die einzige Eingabe, nicht die Binärdatei. Wenn C:\Users\victim\AppData\Local\Temp\PsExec.exe heute lief und gestern eine völlig andere Datei an diesem Pfad lebte (ebenfalls PsExec.exe heißend), teilen sie sich eine .pf-Datei. Die Ausführungszeitstempel stapeln sich zusammen. Der Ausführungszähler erhöht sich. Die Load-Liste wird mit den Daten des jüngsten Laufs überschrieben.

Das ist der Fehlerfall, den ich am häufigsten gesehen habe. Ein Angreifer wirft ein Tool ab, führt es aus, löscht es, und später landet eine harmlose Datei am selben Pfad. Der ursprüngliche Prefetch-Datensatz ist noch da, aber der Pfad auf der Festplatte zeigt jetzt auf etwas völlig anderes. Ein Analyst, der nur den Pfad und die aktuell auf der Festplatte liegende Datei betrachtet, schließt, dass die harmlose Datei lief. Die harmlose Datei lief nicht. Etwas anderes mit demselben Pfad lief.

Die Abhilfe ist, der Pfad-Auflösung allein niemals zu vertrauen. Paaren Sie die .pf mit dem MFT-Eintrag für diesen Pfad zur Ausführungszeit, holen Sie die Dateireferenznummer und prüfen Sie, ob sich die Datei-ID seitdem geändert hat.

Dateinamen-Kollisionen und das 29-Zeichen-Problem

Das interne Feld für den Namen der ausführbaren Datei ist 29 Zeichen plus Null-Terminator, UTF-16LE. Binärdatei-Namen, die länger sind, werden abgeschnitten.

Wenn Sie jemals zwei .pf-Dateien mit Namen wie

LONGNAMEDEXECUTABLE_VERSION_A-12345678.pf
LONGNAMEDEXECUTABLE_VERSION_B-87654321.pf

gesehen haben und beide internen Namensfelder LONGNAMEDEXECUTABLE_VERSION_ lauten, haben Sie eine Kollision im Namen, aber unterschiedliche Hashes. Die Hashes sind das, was unterscheidet.

Umgekehrt ist der Hash-Raum weit, aber nicht unendlich, und der Hash ist ein 32-Bit-Wert. Hash-Kollisionen über Pfade hinweg kommen vor. Sie sind in freier Wildbahn selten, aber nicht unerhört, und auf einem ausgelasteten Host mit Tausenden von Binärdateien sollten Sie nicht überrascht sein, zwei .pf-Dateien mit denselben Hash-Bytes zu sehen, wenn sich die Binärdatei-Namen unterscheiden. Die Kombination aus Name und Hash ist der eindeutige Schlüssel, nicht eines allein.

Der „Executable nach Erstellung der .pf ersetzt"-Edge-Case

Hier ist die Version dieses Falls, die mir tatsächlich in Einsätzen begegnet ist.

Tag 0, ein Angreifer kopiert m1m1.exe (umbenannte Mimikatz) nach C:\Users\Public\m1m1.exe. Führt es aus. Windows erstellt M1M1.EXE-AABBCCDD.pf. Die Load-Liste zeigt \Windows\System32\sekurlsa.dll und andere Artefakte, die nach Mimikatz schreien.

Tag 3 löscht der Angreifer die Binärdatei.

Tag 7 schreibt ein interner Benutzer, völlig unbeteiligt, ein kleines Utility, nennt es m1m1.exe, legt es in C:\Users\Public\ ab und führt es aus. Windows aktualisiert die bestehende .pf-Datei (gleicher Pfad, gleicher Hash). Die Load-Liste spiegelt jetzt das harmlose Utility wider. Der Ausführungszähler ist jetzt 2. Die jüngste Ausführungszeit ist Tag 7.

Eine flüchtige Lesung sagt „Binärdatei lief zweimal, jüngster Lauf sieht harmlos aus". Die korrekte Lesung braucht zusätzliche Artefakte. Die MFT zeigt, dass die Datei in C:\Users\Public\m1m1.exe am Tag 0 erstellt, am Tag 3 gelöscht und am Tag 7 mit einer anderen Dateireferenz neu erstellt wurde. Das USN-Journal hat beide Lebenszyklen. AmCache hat möglicherweise noch den Hash der Tag-0-Binärdatei, auch nachdem sie gelöscht wurde. Sysmon Event ID 1 hat die Befehlszeile und SHA-256 beider Ausführungen, wenn es lief.

Prefetch allein sagt „lief zweimal". Prefetch plus die umgebenden Artefakte sagt „zwei unterschiedliche Binärdateien mit demselben Pfad liefen, hier sind die Hashes, hier ist welcher Benutzer, hier ist, was sie taten".

Wenn Sie in einem solchen Fall bei Prefetch allein anhalten, liegen Sie auf die peinlichste Weise falsch: zuversichtlich.

Paaren Sie mit EVTX 4688 und Sysmon EID 1

Die zwei Events, die Sie neben jeder Prefetch-Ausführungsaussage wollen, sind Security 4688 (Prozesserstellung, falls aktiviert) und Sysmon Event ID 1 (Prozesserstellung, mit Befehlszeile, Parent, Hashes, Integritätsstufe). Diese sind im EVTX.

Abgleich auf:

1. Ausführungspfad. Das NewProcessName- oder Image-Feld von 4688/EID 1 sollte mit dem aufgelösten Pfad übereinstimmen, den Prefetch aufgezeichnet hat.
2. Ausführungszeit. Die Prefetch-„Last run"-Zeit und die Event-Zeit sollten auf Sekunden übereinstimmen. Größere Lücken sind nicht zwingend falsch, aber untersuchungswürdig; die häufigste Ursache ist Uhren-Drift zwischen verschiedenen Log-Quellen.
3. Prozess-Integritätsstufe und Benutzerkontext. Prefetch ist pro Maschine und sagt nichts darüber, wer die Binärdatei lief. Sysmon und 4688 geben Ihnen den SID. Wenn die .pf einer Binärdatei zehn Ausführungen zeigt und Sysmon nur fünf protokolliert, fehlen Ihnen Logs, oder die anderen fünf passierten in einem Fenster, in dem Sysmon aus war, oder jemand hat das Eventlog manipuliert.

Das Paar ist viel stärker als jedes für sich. Prefetch gibt Ihnen ein vollständiges Inventar jeder Binärdatei, die lief (vorbehaltlich der SSD/Server-Vorbehalte, die anderswo abgedeckt sind); EVTX gibt Ihnen die Per-Execution-Details. Verwenden Sie sie zusammen und die „Lief das?"-Frage hört auf, mehrdeutig zu sein.

Wenn Sie keines haben, gibt Ihnen RAM eine Live-Prozessliste, sofern der Host nicht neu gestartet hat, und das Pagefile hat manchmal Prozessartefakte. Nach einem Reboot ohne EVTX und ohne Prefetch sind Sie meist auf AmCache und Schlussfolgerungen reduziert.

„Lief einmal" von „lief im Rauschen" unterscheiden

Der Prefetch-Ausführungszähler lügt nicht über die untere Grenze. Wenn er 12 Ausführungen sagt, lief die Binärdatei mindestens 12 Mal. Ob sie mehr lief (weil einige Ausführungen aus dem Acht-Zeitstempel-Ring herausgealtert sind oder Win10 1709+ ältere Einträge gekürzt hat), ist offen.

Wozu der Ausführungszähler in diesem Zusammenhang gut ist, ist der Kontrast. Auf einem Host mit einer psexec.exe-.pf, die 200 Ausführungen und einen Pfad innerhalb von Program Files zeigt, schauen Sie auf das tägliche Werkzeug eines Sysadmins. Auf demselben Host mit einer separaten psexec.exe-.pf, die 1 Ausführung und einen Pfad unter \AppData\Local\Temp\ zeigt, schauen Sie auf etwas, das kürzlich ankam und einmal lief. Die zweite .pf ist die, die zu untersuchen ist.

Kontraintuitiv sind die Prefetch-Dateien mit einer Ausführung in einer Intrusion gewöhnlich die interessanten. Many-Run-Prefetch-Dateien sind gewöhnlich Hintergrundrauschen, es sei denn, sie leben an verdächtigen Orten.

Ein Workflow, der hält

Wenn die Frage lautet „lief das auf diesem Host", führe ich die folgende Sequenz aus:

1. .pf-Datei nach Name und Hash identifizieren.
2. Ihre Ausführungszeitstempel und den Ausführungszähler lesen. Den aufgezeichneten Pfad notieren.
3. Den MFT-Eintrag für diesen Pfad holen und prüfen, dass die Dateireferenz mit dem übereinstimmt, was Prefetch sah.
4. Mit EVTX 4688 und Sysmon EID 1 auf den Laufzeiten querverweisen.
5. AmCache auf den Datei-Hash prüfen. Wenn er zu einem bekannten Sample passt, wird der Fall einfacher.
6. Wenn die Binärdatei nicht mehr auf der Festplatte ist, das USN-Journal auf Lösch-Events rund um die Laufzeiten prüfen.

Wenn die Schritte 3 bis 6 alle übereinstimmen, ist die Ausführungsaussage im Wesentlichen unanfechtbar. Wenn sie nicht übereinstimmen, haben Sie etwas Interessanteres als einen einfachen Ausführungsbeweis; Sie haben Hinweise auf Manipulation, Ersetzung oder eine komplexere Sequenz, als der Prefetch-Eintrag allein vermuten lässt.

Weiterführende Literatur

• Eric Zimmerman, PECmd — der Parser. Lesen Sie die Release Notes für das, was sich über Windows-Builds geändert hat.
• Andrea Fortuna, Forensic analysis of Prefetch files — klarer Bericht mit Beispielen.
• Microsoft, Audit Process Creation (event 4688) — das Partner-Artefakt, einschließlich der Befehlszeile-in-4688-Audit-Policy, die die meisten Estates nicht eingeschaltet haben.

Prefetch beantwortet „die Binärdatei lief". Sysmon beantwortet „das ist, was sie tat". Behandeln Sie sie als komplementär und Sie werden nicht zu kurz kommen.