RecentFileCache-Befunde validieren: Pivots und False Positives

Ein verdächtig aussehender Pfad in RecentFileCache.bcf ist ein Lead, kein Urteil. Das Artefakt sagt dir, dass AppCompat eine Datei gesehen hat — mehr nicht. Dieser Post ist die Checkliste, die du durchgehst, bevor du "der Angreifer führte C:\Users\Public\update.exe aus" in deinen Bericht schreibst.

Die Validierungskette

Ein "ausgeführt"-Befund mit hoher Konfidenz für einen einzelnen Pfad ist meist eine Kette aus drei oder vier sich einander bestätigenden Artefakten:

RecentFileCache (Pfad gesehen)
       ↓
Prefetch (Ausführungszeitstempel + Counter)             ← stärkster Einzelkorroborator
       ↓
Amcache.hve (SHA-1, Herausgeber, Installationszustand)  ← reichere Metadaten derselben Ära
       ↓
MFT / $LogFile (Erstellung, Löschung, MFT-Record)       ← wann/wie die Datei sich bewegte
       ↓
Binary auf Platte → Hash → VT / Threat Intel            ← Identität

Stoppe auf jeder Stufe, sobald sie den darüberliegenden widerspricht. Ein Pfad in .bcf ohne Prefetch und ohne Amcache-Eintrag bedeutet eines von: (a) die Datei wurde gesehen, aber nie ausgeführt, (b) die Datei lief, aber Prefetch ist deaktiviert / der Eintrag rotierte raus, (c) ProgramDataUpdater feuerte vor dem Shutdown nie. Alle drei sind häufig.

Pivot-Spezifika

Prefetch

Die relevante Datei ist C:\Windows\Prefetch\<NAME_GROSS>-<8-HEX-HASH>.pf. Zwei Pfade mit dem gleichen Basename ergeben unterschiedliche Prefetch-Dateien, weil der Hash den Pfad der Binary einbezieht. Nutze den Schwester-Parser prefetch-parser client-seitig oder PECmd.exe auf Windows.

Konfidenz-Lesung:

• Prefetch existiert, Lauf-Counter ≥ 1, letzter Lauf in Stunden zum Vorfallsfenster → starke Ausführungsbestätigung.
• Prefetch existiert, Lauf-Counter = 1, letzter Lauf = Erstellungszeit der Datei → einmal kurz nach dem Drop ausgeführt, konsistent mit "den Dropper gestartet".
• Kein Prefetch trotz mehrerer bestätigender Artefakte → prüfen, ob Prefetch deaktiviert war (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher) — bekannter Anti-Forensik-Schritt.

Amcache.hve

Gleiches Verzeichnis wie .bcf. Parsen mit amcache-parser. Schlüsselfelder zum Lesen:

• SHA-1 — pivotieren zu VT oder deinem internen Store. Ein Hash hier heißt, AppCompat hat die Datei zur Beförderungszeit gehasht.
• Publisher + PublisherName — leer heißt, die Binary war unsigned. Der meiste Malware landet hier.
• Schlüssel-LastWritten — wann der Registry-Schlüssel zuletzt angefasst wurde. Der nächste-zur-Ausführung-Zeitstempel, den dir die Registry gibt.
• AppPath — der von Amcache aufgezeichnete Pfad. Gegen den .bcf-Pfad vergleichen; Mismatches treten auf, wenn die Datei verschoben wurde.

MFT und $LogFile

Benutze MFTECmd.exe oder mft-parser, um den MFT-Record der Binary aufzudecken. Du willst:

• $STANDARD_INFORMATION Created, Modified, Accessed, MFT-changed — das volle Zeitstempel-Bild, inklusive Anzeichen von Timestomping (z.B. $SI Modified ≠ $FILE_NAME Modified).
• $LogFile-Einträge, die Erstellung, Umbenennung oder Löschung der Datei festhalten — nützlich, wenn die Datei nicht mehr auf der Platte ist.

Hash auf Platte → Threat Intel

Wenn der Pfad noch auflöst, gibt dir certutil -hashfile <path> SHA256 (Win7+) oder Get-FileHash (PowerShell) in Sekunden einen SHA-256. Pivotiere zu VirusTotal, MalwareBazaar, der IOC-Datenbank deines EDR, internem MISP etc.

False Positives, die Leute erwischen

Nicht jeder seltsam aussehende Pfad ist bösartig. Die folgenden Muster verbrennen Analysten jedes Quartal:

• MSI-Per-Session-Entpackungen. Viele Installer extrahieren nach C:\Users\<user>\AppData\Local\Temp\{GUID}\setup.exe und laufen von dort. Sieht lehrbuchhaft verdächtig aus; meist legitim. Mit der signierten Natur des Eltern-Installers und dem Alter des Temp-Ordners validieren.
• Endpoint-Protection-Quarantänepfade. Manche AV-Produkte verschieben detektierte Dateien nach C:\ProgramData\<Vendor>\Quarantine\.... Der Pfad sieht alarmierend aus, aber die Datei ist bereits neutralisiert.
• Build-/CI-Artefakte auf Dev-Workstations. Entwicklermaschinen haben D:\build\bin\Debug\app.exe, C:\Users\dev\source\repos\foo\bin\foo.exe etc., die "ungewöhnliches Laufwerk + zufällig aussehender Basename" matchen, im Kontext aber völlig normal sind.
• Squirrel-artige Auto-Updater. Apps wie Discord, Atom, VS Code legen versionierte Binaries unter %LOCALAPPDATA%\<App>\app-<version>\<App>.exe ab und führen sich selbst neu aus. Sieht aus wie "eine einzelne Binary, die sich ständig umzieht" — ist nur Auto-Update.
• Der Office-"Click-to-Run"-Cache. C:\Program Files\Common Files\microsoft shared\ClickToRun\... produziert viele Pfad-Varianten; lern die Form, damit du aufhörst, daran zu pivotieren.
• Windows-Update-Paket-Cache. C:\Windows\SoftwareDistribution\Download\<GUID>\... ist normal.

Praktisches mentales Modell: Temp-/AppData-Pfade mit einem signierten Eltern-Installer, der sie einmal startet und dann nie wieder, sind Rauschen. Dieselben Pfade, die wiederholt von einer unsignierten Binary aufgerufen werden, sind es nicht.

Der Berichtssatz

Wenn deine Kette zusammenhält, sieht der verteidigbare Satz in einem Bericht etwa so aus:

"RecentFileCache.bcf, Prefetch und Amcache.hve zeigen konsistent, dass C:\Users\Public\update.exe auf dem System vorhanden war; Prefetch verzeichnet zwei Ausführungen am 2026-05-23 zwischen 14:11 und 14:17 UTC; Amcache verzeichnet den SHA-1 d2b7…f0c1, der mit der VirusTotal-Probe übereinstimmt, die erstmals am 2026-05-20 mit Detektionen von N Anbietern gesehen wurde."

Wenn eines dieser drei Artefakte fehlt, stufe die Sprache entsprechend ab ("eine Datei an diesem Pfad wurde vom AppCompat-Scanner beobachtet").

Weiter

Der finale Post deckt ab, was ein Angreifer tun würde, um diese ganze Kette stummzuschalten — und die Signale, die ihn verraten, wenn er es versucht.