Untersuchung eines Win7 Hosts mit der BCF: eine kurze Walkthrough

Das ist eine zusammengesetzte Walkthrough, gezeichnet aus einer Handvoll ähnlicher Fälle. Der Host ist fiktiv. Die Artefakte und der Workflow sind es nicht. Der Punkt ist zu zeigen, wie viel die RecentFileCache.bcf tatsächlich zu einer realistischen Untersuchung beigetragen hat, und ehrlich darüber zu sein, wo sie es nicht getan hat.

Der Host

WS-FIN-014. Eine Windows 7 SP1 Workstation in der Finanzabteilung eines Fertigungskunden. Domain-gejoint. Zuletzt vor vierzehn Monaten gepatcht. Im Besitz eines Controllers, der vier Tage pro Woche aus dem Büro arbeitet. Das SOC markierte ihn auf einer Warnung HTTP POST to a low-reputation domain von der Perimeter-NDR. Das Ziel wurde zu einem Hosting-Provider in einer Jurisdiktion aufgelöst, in der der Kunde keine Geschäfte tätigt.

Triage-Scope: Kompromittierung bestätigen oder ausschließen. Zeitbudget: ein halber Tag.

Was wir gezogen haben

In der Reihenfolge der Erfassung, weil die Reihenfolge wichtig ist, wenn der Appraiser-Zyklus die BCF leeren kann:

C:\Windows\AppCompat\Programs\RecentFileCache.bcf.
Das Prefetch-Verzeichnis.
Live-Registry-Hives via reg save: SOFTWARE, SYSTEM, SECURITY, NTUSER.DAT für den eingeloggten Benutzer.
Microsoft-Windows-TaskScheduler%4Operational.evtx und die Standard-System-/Security-Logs.
Einen USN-Journal-Snapshot vom Boot-Volume.
Die MFT.
Einen gezielten Dump von C:\Users\<controller>\AppData\ für LNK-, Jump-List- und Recently-Used-Daten.

Kein RAM-Dump. Der Endpoint war neu gebootet worden, bevor wir Netzwerkzugriff bekamen, was eine eigene Geschichte ist.

Der BCF-Inhalt

Nach dem Parsen enthielt die BCF 14 Pfade. Die vollständige Liste:

\??\C:\Windows\System32\rundll32.exe
\??\C:\Windows\System32\msiexec.exe
\??\C:\Windows\System32\wermgr.exe
\??\C:\Windows\System32\WerFault.exe
\??\C:\Windows\System32\dllhost.exe
\??\C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE
\??\C:\Program Files\Microsoft Office\Office14\EXCEL.EXE
\??\C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
\??\C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
\??\C:\Program Files\Internet Explorer\iexplore.exe
\??\C:\Users\jharper\AppData\Local\Temp\sb_v2.exe
\??\C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe
\??\C:\Windows\Temp\update_check.exe
\??\C:\Windows\System32\cscript.exe

Die ersten zehn waren unauffällig: Standard-Office- und OS-Komponenten, die ein Finanzbenutzer täglich anfasst. Die interessanten waren die letzten vier:

sb_v2.exe in AppData\Local\Temp.
phc.exe in AppData\Roaming\printerhelper\.
update_check.exe in C:\Windows\Temp\.
cscript.exe, was selbst in Ordnung ist, aber ohne Office-Makro-Geschichte, an die man es anhängen kann.

Drei der vier waren in benutzerbeschreibbaren Verzeichnissen. Das allein ist nicht belastend. Legitime Software landet ständig in diesen Pfaden. Aber die Kombination aus Namen und Standorten reichte aus, um jeden einzelnen zu eskalieren.

Korroboration Runde eins: Prefetch

Ich habe jedes der vier zuerst durch das Prefetch gegangen.

sb_v2.exe: eine .pf-Datei, letzter Lauf vor drei Tagen um 14:22 UTC. Run Count von eins. Loaded list enthielt WININET.DLL, URLMON.DLL und BCRYPT.DLL. Keine Überraschung für etwas, das das Netzwerk kontaktiert.

phc.exe: eine .pf, letzter Lauf vor drei Tagen um 14:24 UTC. Run Count von sieben. Der hohe Run Count war interessant; sie war im Laufe der vorherigen Woche mehrfach ausgeführt worden. Loaded list enthielt WINHTTP.DLL und CRYPT32.DLL.

update_check.exe: eine .pf, letzter Lauf vor drei Tagen um 14:23 UTC. Run Count von eins.

cscript.exe: eine .pf, letzter Lauf vor drei Tagen um 14:22 UTC. Run Count von 12 im Laufe des vorherigen Monats.

Also liefen alle vier innerhalb eines Zwei-Minuten-Fensters vor drei Tagen, und cscript.exe und phc.exe liefen länger als das. Das war die erste echte Form: ein Cluster von Ausführungen vor drei Tagen, oben drauf eine länger laufende Sache, die wie etablierte Präsenz aussah.

Die BCF sagte mir, dass diese Binärdateien liefen. Prefetch sagte mir wann und wie oft. Bereits hatte die BCF ihre Aufgabe erfüllt (Ausführung nachweisen) und wurde von Prefetch für die Timeline-Arbeit überholt.

Korroboration Runde zwei: MFT und USN

MFT-Einträge für jede Binärdatei:

sb_v2.exe: vor drei Tagen um 14:21 UTC erstellt. Eine Minute vor seiner einzigen Ausführung.
phc.exe: vor dreiundzwanzig Tagen um 09:11 UTC erstellt. Mehrere Modifikationen seitdem.
update_check.exe: vor drei Tagen um 14:21 UTC erstellt.

Das USN-Journal fügte Details hinzu. sb_v2.exe hatte eine FileCreate | DataExtend | Close-Sequenz mit iexplore.exe als ursprünglichem Prozesskontext (USN gibt einem keine PID direkt, aber die Zeitstempel passten zu einer iexplore.exe-Ausführung in der BCF und im Prefetch). Der Benutzer hatte eine Seite besucht, der Browser hatte die Datei geschrieben, und die Datei hatte innerhalb von sechzig Sekunden ausgeführt.

update_check.exe hatte ein ähnliches Erstellungsmuster, mit Ursprung etwa zur selben Zeit, mit iexplore.exe wieder im impliziten Kontext.

phc.exe war anders. Das USN zeigte ein FileCreate vor dreiundzwanzig Tagen, mit Ursprung in msiexec.exe. Das ließ es aussehen, als hätte ein Installer es abgesetzt. Die MFT bestätigte, dass das Elternverzeichnis printerhelper zum gleichen Zeitpunkt erstellt wurde.

Die Form nach MFT und USN: zwei Binärdateien, die vor drei Tagen von einer Browser-Session abgesetzt wurden, plus eine Binärdatei, die vor drei Wochen von dem installiert wurde, was nach einer MSI aussah.

Korroboration Runde drei: Registry und Persistenz

Der Kontext des Elternverzeichnisses von printerhelper brachte mich zur Registry. Unter HKCU\Software\Microsoft\Windows\CurrentVersion\Run war ein Eintrag namens PrinterHelperCore mit dem Wert "C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe" /q. Last-Write-Zeitstempel auf dem Schlüssel passte zum MSI-Installationsdatum.

Persistenz. Die Sache, die die BCF mir niemals von sich aus sagen könnte.

Der Run Key erklärte auch den hohen Run Count im Prefetch: Jedes Logon führte phc.exe aus. Sieben Läufe in drei Wochen passten zum Logon-Muster des Benutzers.

Keine Persistenz für sb_v2.exe oder update_check.exe. Beide sahen aus wie One-Shot-Payloads.

Korroboration Runde vier: EVTX

Das Security Log war dünn. Audit Policy war auf den Win7-Defaults; keine 4688s für Befehlszeilen. Das TaskScheduler Operational Log war sauber für ProgramDataUpdater, mit regelmäßigen 200/201-Paaren ungefähr alle 26 Stunden. Der Appraiser lief planmäßig. Das war wichtig, weil es erklärte, warum die BCF nur 14 Einträge hatte: Alles von vor dem letzten Bewertungsdurchlauf (ungefähr 18 Stunden vor der Erfassung) war herausverarbeitet worden.

Das System Log hatte ein Service-Install-Event vor zwei Wochen, das nicht zu der Persistenz passte, die ich bereits hatte, aber bei der Nachverfolgung war es ein Druckertreiber-Update. Zufall.

Der nützlichste EVTX-Eintrag kam aus Microsoft-Windows-Windows Defender/Operational. Defender hatte vor drei Tagen um 14:23 UTC eine Datei in Quarantäne gestellt, zwei Sekunden nachdem update_check.exe lief. Der Quarantäne-Name passte zu einer generischen Downloader-Signatur. Das gab mir meinen ersten Malware-Family-Hit und bestätigte, dass das Cluster vor drei Tagen real war.

Was der Benutzer tat

LNK-Dateien und Browser-History füllten das menschliche Element. Der Benutzer hatte vor drei Tagen um 14:18 eine E-Mail erhalten, drei Minuten später einen Link geöffnet und eine gefälschte Software-Update-Seite erreicht. Die Browser-History zeigte die Navigationskette. Das Internet Explorer Download-Manager-Log hatte die Dateiabwürfe.

Die MSI-Installation vor drei Wochen war schwieriger zuzuordnen. Der Benutzer erinnerte sich nicht daran, Druckersoftware installiert zu haben. Die MSI selbst war nicht mehr auf der Disk, aber das USN-Journal hatte ihre kurzlebige Existenz in Downloads. Die Browser-History vor drei Wochen zeigte eine Navigation zu einer gefälschten Driver-Update-Domain. Gleiches Muster wie die jüngste Aktivität, andere Kampagnen-aussehende Infrastruktur.

Was die BCF tatsächlich beigetragen hat

Ehrlich gesagt: Sie hat mich schnell auf die vier interessanten Binärdateien hingewiesen. Dafür ist sie da.

Sie gab mir nicht:

Die Zeitstempel. Prefetch tat das.
Die Persistenz. Die Registry tat das.
Die Drop-Kette. USN und die Browser-History taten das.
Die Benutzerzuordnung. LNK, Browser-History und MUICache taten das.
Den Malware-Family-Hit. Defenders Log tat das.
Die Kampagnen-Verknüpfung. Netzwerk und Browser-History taten das.

Die BCF gab mir eine 14-zeilige Shortlist zur Triage. Ohne sie hätte ich mit Prefetch angefangen und wäre bei den gleichen vier Binärdateien angekommen, nur langsamer. Mit ihr dauerte der erste Durchgang etwa zehn Minuten. Die gesamte Korroborationskette dauerte den Großteil des Tages.

Wäre der Host Win10 gewesen, hätte ich die AmCache für denselben Zweck verwendet. Die Form der Untersuchung wäre dieselbe gewesen; das Einstiegsartefakt wäre anders gewesen.

Was in den Bericht kam

Der Bericht behauptete:

Der Host wurde vor mindestens drei Wochen über einen gefälschten Druckertreiber-Installer kompromittiert.
Die Kompromittierung etablierte Persistenz über einen HKCU Run Key.
Vor drei Tagen ist derselbe Benutzer auf einen ähnlichen gefälschten Update-Köder hereingefallen, der zwei zusätzliche Binärdateien absetzte. Eine wurde von Defender in Quarantäne gestellt. Die andere (sb_v2.exe) wurde ausgeführt und stellte Netzwerkkontakt her.
Der Netzwerkkontakt war der Alarm, den das SOC markierte.
Die Persistenz-Binärdatei (phc.exe) lief noch auf dem Host bis zur Isolierung.

Die BCF unterstützte Punkt drei (das Cluster der jüngsten Ausführungen) direkt. Sie unterstützte Punkt eins indirekt (ihre Aufnahme von phc.exe war die Brücke zum Persistenz-Befund). Die anderen Punkte kamen von bestätigenden Artefakten.

Was ich ohne die BCF verpasst hätte

Wahrscheinlich nichts. Prefetch deckte den gleichen Boden für diese speziellen Binärdateien ab. Die Rolle der BCF hier war ein Fast-Triage-Filter, keine einzigartige Beweisquelle.

Das ist die ehrliche Antwort über die meisten BCF-Fälle. Es ist ein sauberes, schnelles, schmales Artefakt. Es sagt einem selten etwas, was nichts anderes kann. Sein Wert liegt in der Geschwindigkeit, mit der es Sie auf die richtigen Dateien hinweist.

Weiterführende Literatur

SANS, Windows Forensic Analysis Poster. Das Artefakt-Ketten-Layout ist für Win10 veraltet, aber die Win7-Boxen gelten immer noch.
David Cowen, Forensic Lunch Fallstudien. Viel realistische IR-Form bei älteren Windows-Builds.

Wenn Sie morgen einen Win7 Endpoint markiert haben, schnappen Sie sich die BCF zuerst. Sorgen Sie sich um alles andere als Zweites.