Skip to content

Grenzen der BCF: wann sie Ihnen nichts sagt, und was Sie stattdessen verwenden

Keine Zeitstempel, keine Hashes, keine Benutzerzuordnung, kein Skript-Tracking. Die RecentFileCache.bcf ist schmaler als ihr Ruf. Hier ist, wozu Sie greifen sollten.

Veröffentlicht am 7 Min. Lesezeit

Die RecentFileCache.bcf hat einen leisen Ruf unter DFIR-Leuten, die wissen, dass sie existiert. Der Ruf ist größtenteils verdient. Das Artefakt ist klein, spezifisch und sauber. Aber es ist auch schmaler, als die Leute zwischen den Fällen in Erinnerung haben. Nach ein paar Monaten ohne Win7-Box neigt man dazu, zu überschätzen, was die BCF beantworten kann.

Das ist die ehrliche Liste dessen, was die BCF nicht liefert, und was man daneben ziehen sollte.

Keine Zeitstempel pro Eintrag

Die Datei enthält Pfade. Das ist es. Es gibt kein Feld für "first seen," "last run" oder "execution count." Eine Binärdatei erscheint in der BCF, wenn sie seit dem letzten Bewertungsdurchlauf gelaufen ist. Das ist ein einziges Informationsbit über das gesamte Fenster der Arbeitslebenszeit der Datei.

Das, was einem Zeitstempel am nächsten kommt und das die BCF bietet, ist die eigene Last-Modified-Zeit der Datei auf der Disk, die Ihnen sagt, wann der Appraiser zuletzt darauf geschrieben hat. Dieser Zeitstempel gilt für die gesamte Datei. Sie können ihn nicht verwenden, um Einträge innerhalb der Datei zu ordnen. Sie können ihn nicht verwenden, um zu sagen "diese Binärdatei lief am Dienstag."

Wenn Sie Zeitstempel brauchen:

  • Prefetch. Bis zu acht Last-Run-Zeiten pro ausführbarer Datei auf Win7 (das ältere .pf-Format), mit vollständigen Erstellungs- und Modifikations-Metadaten.
  • USN-Journal. Für wann die Binärdatei auf der Disk erschien, geändert oder gelöscht wurde. Granularität auf Operationsebene.
  • Master File Table. Standard Information und File Name Attribut-Zeitstempel. Nützlich, wenn die Binärdatei gelöscht wurde.
  • Security 4688 oder Sysmon 1. Prozesserstellungsereignisse mit vollständigen Zeitstempeln und Befehlszeilen, falls das Logging an war. Auf einer Standard-Win7-Installation war es das nicht.

Die BCF sagt Ihnen, dass etwas passiert ist. Die anderen Artefakte sagen Ihnen, wann.

Keine Hashes

Es gibt keinen Hash in der BCF. Weder SHA1, noch MD5, noch den abgeschnittenen PE-Header-Hash, den die AmCache aufzeichnet. Wenn Sie zu Threat Intel pivotieren wollen, brauchen Sie die Binärdatei selbst.

Drei Wege, den Hash zu bekommen:

  • Ziehen Sie die Binärdatei von der Disk und hashen Sie sie. Trivial, wenn die Datei noch da ist.
  • Rekonstruieren Sie aus einem Backup, einem Pagefile oder einem RAM-Dump. Weniger zuverlässig, aber manchmal die einzige Option.
  • Hashen Sie die referenzierte Binärdatei der passenden Prefetch-Datei, indem Sie die .pf lesen und zurückgehen. Das Prefetch speichert auch nicht den Hash der Binärdatei, aber es gibt Ihnen den genauen Pfad, und Sie können sie aus dem Volume holen.

Wenn die Binärdatei gelöscht wurde und es kein Backup gibt, lässt die BCF Sie ohne Hash zurück. Permanente Lücke.

Keine Benutzerzuordnung

Die BCF ist pro Maschine. Es gibt kein Feld für "lief als bob" oder "lief als SYSTEM." Eine Binärdatei, die als Service lief, und eine Binärdatei, die als interaktiver Benutzer lief, sehen in der Datei identisch aus.

Quellen für Zuordnung, in grober Präferenzreihenfolge:

  • Security 4688 mit SubjectUserSid. Am saubersten. Oft auf Win7 nicht vorhanden, es sei denn, die Audit Policy wurde optimiert.
  • Sysmon 1 mit User. Am besten, aber Sysmon auf Win7 ist in der Wildbahn eine seltene Bestie.
  • Das NTUSER.DAT des Benutzers und MUICache unter den Benutzer-Hives. MUICache zeichnet ausführbare Dateien auf, mit denen der Benutzer über Explorer interagiert hat. Nicht autoritativ, aber bestätigend.
  • LNK-Dateien in den Recent- und Office Recent-Ordnern des Benutzers. Wenn ein Benutzer die Binärdatei doppelt geklickt hat, existiert wahrscheinlich ein LNK.
  • Jump Lists. Für ausführbare Dateien, die angepinnt werden können oder kürzlich verwendet wurden.

Damit ein BCF-Eintrag zu "Benutzer hat das ausgeführt" wird, brauchen Sie mindestens eine dieser bestätigenden Quellen. Die BCF allein trägt diese Behauptung nie.

Kein Skript-Tracking

Das ist die Einschränkung, die die Leute am häufigsten auf dem falschen Fuß erwischt. Die BCF verfolgt Starts von ausführbaren Dateien. Eine powershell.exe-Aufrufung, die zehn verschiedene Skripte ausgeführt hat, produziert einen BCF-Eintrag: \??\C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Dasselbe für cscript.exe, wscript.exe, mshta.exe, cmd.exe, regsvr32.exe, rundll32.exe.

Die Interpreter sind in der BCF. Die Skripte, die sie ausgeführt haben, sind es nicht.

Für Skript-Level-Sichtbarkeit auf Win7:

  • PowerShell-4688-artiges Logging über Microsoft-Windows-PowerShell/Operational (Event-ID 4103, 4104), aber nur wenn Script Block Logging aktiviert war. Fast niemand hatte das auf Win7 standardmäßig an.
  • Windows PowerShell Classic Log, Windows PowerShell.evtx. Weniger informativ als das Operational Log, aber einen Blick wert.
  • LNK-Dateien für explizit doppelt geklickte Skripte.
  • Browser-Verlauf für Downloads von Skript-Dateien, gepaart mit Recycle Bin für das, was gelöscht wurde.
  • Die tatsächlichen Skriptdateien auf der Disk, wo die user/AppData/Temp-Pfade typischerweise liegen.

Eine BCF, die zeigt, dass cscript.exe lief, ist interessant. Eine BCF, die zeigt, dass cscript.exe lief und Sie das Skript nicht auf der Disk finden können, ist interessanter. Pivotieren Sie zum USN-Journal für die Spur des gelöschten Skripts.

Kein DLL- oder Library-Tracking

Im Gegensatz zu Prefetch zeichnet die BCF die in einen Prozess geladenen DLLs nicht auf. Eine Binärdatei, die eine bösartige DLL geladen hat, und eine Binärdatei, die sauber lief, sehen in der Datei identisch aus.

Wenn Sie DLL-Sideloading oder Process Hollowing vermuten, sagt Ihnen die BCF, dass der Host-Prozess lief. Sie sagt Ihnen nicht, was hineingeladen wurde. Greifen Sie zu:

  • Prefetch-Liste der referenzierten Dateien.
  • Sysmon Event-ID 7 (ImageLoaded). Auf Win7 in der Praxis fast nie vorhanden.
  • Memory-Analyse aus einem RAM-Dump.
  • Die Registry-Schlüssel KnownDlls und ImageFileExecutionOptions für Sideloading-Vektoren.

Kein Netzwerk- oder Persistenzkontext

Die BCF zeichnet das Netzwerk nicht auf. Sie zeigt keine DNS-Lookups, ausgehenden Verbindungen oder Listening Ports. Sie zeichnet keine Persistenzmechanismen auf. Eine Binärdatei, die einen Service installiert, einen Run Key abgesetzt oder eine geplante Aufgabe registriert hat, ist nur ein Eintrag in der BCF; die Installationsaktivität taucht nicht auf.

Für diese:

  • Registry für Run-Keys, Services und ASEPs.
  • Task Scheduler Tasks-Ordner und das EVTX Operational Log.
  • SRUM, das nur auf Win8+ existiert, also nicht im Scope eines BCF-Hosts. Aber zu wissen für wenn der Host etwas anderes ist.
  • DNS-Cache im Speicher, wenn Sie einen RAM-Dump haben.

Keine Abdeckung über das Bewertungsfenster hinaus

Die BCF enthält Binärdateien, die seit dem letzten Bewertungsdurchlauf gelaufen sind. Das sind ungefähr die letzten 24 Stunden auf einem gesunden Host. Ältere Ausführungen sind weg.

Das Artefakt für längere Ausführungshistorie auf Win7 ist Shimcache, das in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache lebt und viel mehr Einträge mit Last-Modified-Zeitstempeln enthält. Shimcache macht schwächere Behauptungen (die Binärdatei wurde untersucht, nicht notwendigerweise ausgeführt), deckt aber ein breiteres Fenster ab. Verwenden Sie es für die Frage "ist das jemals auf dem Host gelaufen?"; verwenden Sie die BCF für die Frage "ist das kürzlich gelaufen?".

Keine Abdeckung auf modernem Windows

Wenn der Host Windows 8 oder später ist, ist die BCF weg. Gehen Sie stattdessen zur AmCache. Die AmCache hat ihre eigenen Grenzen (sie ist mehr Inventur als Ausführungsbeweis), aber sie ist die richtige primäre Quelle auf diesen Builds.

Die Form einer vollständigen Antwort

Ein BCF-Hit ist nie die ganze Geschichte. Die Form einer vollständigen Behauptung für "Binärdatei X lief auf Host Y zur Zeit T als Benutzer Z und tat Folgendes" erfordert:

  • BCF oder Prefetch für die Ausführung selbst.
  • Prefetch oder EVTX für den Zeitstempel.
  • EVTX, MUICache oder LNK für den Benutzer.
  • Prefetch-Referenced-Files, Sysmon ImageLoaded oder Memory für das, was sie geladen hat.
  • USN-Journal und MFT für den Lebenszyklus der Datei auf der Disk.
  • Registry, geplante Aufgaben und Services für Persistenz.
  • Netzwerk-Logs, Browser-Verlauf oder Memory für ausgehende Aktivität.

Die BCF trägt das sauberste "ist es gelaufen?"-Bit bei. Alles andere braucht eine andere Quelle. Behandeln Sie die Datei als Schnellcheck, nicht als Mittelpunkt der Untersuchung.

Weiterführende Literatur

  • Harlan Carvey, Windows Forensic Analysis Toolkit. Die Kapitel über Programmausführungs-Artefakte sind für Win7-Fälle immer noch relevant.
  • Eric Zimmerman, Tool-Dokumentation. Für die bestätigenden Artefakte (Prefetch, Shimcache, AmCache, MFT), die Sie mit der BCF paaren werden.

Wenn die BCF das einzige Artefakt ist, das Sie haben, wird der Fall arm an Beweisen sein. Wenn die BCF eines von sieben Artefakten ist, die Sie haben, kann sie echtes Gewicht tragen. Der Unterschied ist der Rest der Kette.

Verwandte Artikel

Der Lebenszyklus der BCF hängt an einer einzigen geplanten Aufgabe. Verstehen Sie, wann ProgramDataUpdater läuft, wann sie die Datei leert und wie Sie einen deaktivierten Appraiser erkennen.
Ein kurzes, spezifisches Artefakt, das nur auf Windows 7 und Server 2008 R2 existiert, aber wenn Sie es haben, ist es einer der saubersten Beweise für kürzliche Ausführung im DFIR.
Die BCF und die AmCache lösen überlappende Probleme auf verschiedenen Windows-Versionen. Zu wissen, welche Sie haben und warum, entscheidet, was Sie behaupten können.