Investigando un host Win7 con el BCF: un breve recorrido

Este es un recorrido compuesto sacado de un puñado de casos similares. El host es ficticio. Los artefactos y el flujo de trabajo no. La idea es mostrar cuánto contribuyó realmente el RecentFileCache.bcf a una investigación con forma real, y ser honesto sobre dónde no contribuyó.

El host

WS-FIN-014. Una estación de trabajo Windows 7 SP1 en el departamento de finanzas de un cliente de manufactura. Unido a dominio. Última actualización hace catorce meses. Propiedad de un controller que trabaja desde la oficina cuatro días por semana. El SOC lo marcó por una alerta de HTTP POST to a low-reputation domain del NDR perimetral. El destino se resolvió a un proveedor de hosting en una jurisdicción con la que el cliente no hace negocios.

Alcance del triaje: confirmar o descartar un compromiso. Presupuesto de tiempo: medio día.

Lo que tiramos

En orden de adquisición, porque el orden importa cuando el ciclo del appraiser puede vaciar el BCF:

C:\Windows\AppCompat\Programs\RecentFileCache.bcf.
El directorio de Prefetch.
Hives del registro en vivo vía reg save: SOFTWARE, SYSTEM, SECURITY, NTUSER.DAT para el usuario logueado.
Microsoft-Windows-TaskScheduler%4Operational.evtx y los logs estándar System/Security.
Un snapshot del USN journal del volumen de arranque.
La MFT.
Un volcado dirigido de C:\Users\<controller>\AppData\ para datos LNK, jump list y recently-used.

Sin volcado de RAM. El endpoint había sido reiniciado antes de que tuviéramos acceso a la red, lo cual es una historia aparte.

El contenido del BCF

Tras parsear, el BCF tenía 14 rutas. La lista completa:

\??\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

Las primeras diez fueron poco notables: componentes estándar de Office y del SO que un usuario de finanzas toca a diario. Las interesantes fueron las últimas cuatro:

sb_v2.exe en AppData\Local\Temp.
phc.exe en AppData\Roaming\printerhelper\.
update_check.exe en C:\Windows\Temp\.
cscript.exe, que en sí mismo está bien, pero sin una historia de macro de Office a la que vincularlo.

Tres de las cuatro estaban en directorios con permiso de escritura por usuario. Eso por sí solo no es condenatorio. Software legítimo aterriza en estas rutas todo el tiempo. Pero la combinación de nombres y ubicaciones fue suficiente para escalar cada una.

Corroboración ronda uno: Prefetch

Pasé cada una de las cuatro por Prefetch primero.

sb_v2.exe: un archivo .pf, marca de última ejecución hace tres días a las 14:22 UTC. Conteo de ejecuciones de uno. La lista cargada incluyó WININET.DLL, URLMON.DLL y BCRYPT.DLL. Sin sorpresa para algo que contacta la red.

phc.exe: un .pf, marca de última ejecución hace tres días a las 14:24 UTC. Conteo de ejecuciones de siete. El alto conteo de ejecuciones era interesante; se había ejecutado múltiples veces a lo largo de la semana anterior. La lista cargada incluyó WINHTTP.DLL y CRYPT32.DLL.

update_check.exe: un .pf, marca de última ejecución hace tres días a las 14:23 UTC. Conteo de ejecuciones de uno.

cscript.exe: un .pf, marca de última ejecución hace tres días a las 14:22 UTC. Conteo de ejecuciones de 12 a lo largo del mes anterior.

Así que las cuatro corrieron dentro de una ventana de dos minutos hace tres días, y cscript.exe y phc.exe llevaban corriendo más tiempo. Esa fue la primera forma real: un clúster de ejecuciones hace tres días, encima de algo de mayor recorrido que parecía presencia establecida.

El BCF me dijo que estos binarios corrieron. Prefetch me dijo cuándo y con qué frecuencia. Ya, el BCF había hecho su trabajo (probar la ejecución) y estaba siendo eclipsado por Prefetch para el trabajo de timeline.

Corroboración ronda dos: MFT y USN

Entradas MFT para cada binario:

sb_v2.exe: creado hace tres días a las 14:21 UTC. Un minuto antes de su única ejecución.
phc.exe: creado hace veintitrés días a las 09:11 UTC. Múltiples modificaciones desde entonces.
update_check.exe: creado hace tres días a las 14:21 UTC.

El USN journal añadió detalle. sb_v2.exe tenía una secuencia FileCreate | DataExtend | Close desde iexplore.exe como contexto del proceso originador (USN no te da un PID directamente, pero las marcas de tiempo coincidían con una ejecución de iexplore.exe en el BCF y Prefetch). El usuario había visitado un sitio, el navegador había escrito el archivo, y el archivo se había ejecutado en sesenta segundos.

update_check.exe tenía un patrón de creación similar, originándose alrededor del mismo momento, con iexplore.exe nuevamente en el contexto implícito.

phc.exe era diferente. El USN mostró un FileCreate hace veintitrés días, originándose desde msiexec.exe. Eso hacía que pareciera que un instalador lo había soltado. La MFT confirmó que el directorio padre printerhelper fue creado en el mismo momento.

La forma tras MFT y USN: dos binarios soltados por una sesión de navegador hace tres días, más un binario instalado hace tres semanas por lo que parecía un MSI.

Corroboración ronda tres: registro y persistencia

El contexto del padre del directorio printerhelper me apuntó al registro. Bajo HKCU\Software\Microsoft\Windows\CurrentVersion\Run había una entrada llamada PrinterHelperCore con el valor "C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe" /q. La marca de tiempo de última escritura en la clave coincidía con la fecha de instalación del MSI.

Persistencia. La cosa que el BCF nunca podría decirme por sí solo.

La clave Run también explicó el alto conteo de ejecuciones en Prefetch: cada logon ejecutaba phc.exe. Siete ejecuciones en tres semanas coincidían con el patrón de logon del usuario.

Sin persistencia para sb_v2.exe o update_check.exe. Ambas parecían payloads de un solo disparo.

Corroboración ronda cuatro: EVTX

El Security log era escaso. La política de auditoría estaba en los defaults de Win7; sin 4688s para líneas de comando. El log operativo del TaskScheduler estaba limpio para ProgramDataUpdater, con pares 200/201 regulares aproximadamente cada 26 horas. El appraiser había estado corriendo según el calendario. Eso importaba porque explicaba por qué el BCF solo tenía 14 entradas: cualquier cosa de antes del último pase de evaluación (aproximadamente 18 horas antes de la adquisición) había sido procesada fuera.

El System log tenía un evento de instalación de servicio de hace dos semanas que no coincidía con la persistencia que ya tenía, pero al seguirlo era una actualización de driver de impresora. Coincidencia.

La entrada EVTX más útil vino de Microsoft-Windows-Windows Defender/Operational. Defender había puesto en cuarentena un archivo hace tres días a las 14:23 UTC, dos segundos después de que corriera update_check.exe. El nombre de cuarentena coincidía con una firma genérica de downloader. Eso me dio mi primer hit de familia de malware y confirmó que el clúster de hace tres días era real.

Qué hizo el usuario

Los archivos LNK y el historial del navegador rellenaron el elemento humano. El usuario había recibido un email hace tres días a las 14:18, abierto un enlace tres minutos después, y llegado a una página falsa de actualización de software. El historial del navegador mostraba la cadena de navegación. El log del download manager de Internet Explorer tenía las descargas de archivos.

La instalación del MSI de hace tres semanas fue más difícil de atribuir. El usuario no recordaba haber instalado software de impresora. El MSI en sí ya no estaba en el disco, pero el USN journal tenía su existencia efímera en Downloads. El historial del navegador de hace tres semanas mostró una navegación a un dominio falso de actualización de drivers. Mismo patrón que la actividad reciente, infraestructura de aspecto de campaña diferente.

Qué contribuyó realmente el BCF

Honestamente: me apuntó rápido a los cuatro binarios interesantes. Para eso sirve.

No me dio:

Las marcas de tiempo. Prefetch sí.
La persistencia. El registro sí.
La cadena de drop. USN y el historial del navegador sí.
La atribución de usuario. LNK, historial del navegador y MUICache sí.
El hit de familia de malware. El log de Defender sí.
La vinculación de campaña. El historial de red y de navegador sí.

El BCF me dio una shortlist de 14 líneas para triar. Sin él habría empezado desde Prefetch y habría llegado a los mismos cuatro binarios, solo que más lento. Con él, el primer pase tomó unos diez minutos. Toda la cadena de corroboración tomó la mayor parte del día.

Si el host hubiera sido Win10, habría usado el AmCache para el mismo propósito. La forma de la investigación habría sido la misma; el artefacto de entrada habría sido diferente.

Qué entró en el reporte

El reporte afirmaba:

El host fue comprometido hace al menos tres semanas vía un instalador falso de driver de impresora.
El compromiso estableció persistencia vía una clave HKCU Run.
Hace tres días, el mismo usuario cayó por un señuelo falso similar de actualización, que dejó dos binarios adicionales. Uno fue puesto en cuarentena por Defender. El otro (sb_v2.exe) se ejecutó e hizo contacto de red.
El contacto de red fue la alerta que el SOC marcó.
El binario de persistencia (phc.exe) seguía corriendo en el host hasta el aislamiento.

El BCF apoyó el punto tres (el clúster de ejecuciones recientes) directamente. Apoyó el punto uno indirectamente (su inclusión de phc.exe fue el puente al hallazgo de persistencia). Los otros puntos vinieron de artefactos corroborantes.

Qué habría perdido sin el BCF

Probablemente nada. Prefetch cubrió el mismo terreno para estos binarios en particular. El rol del BCF aquí fue un filtro de triaje rápido, no una fuente de evidencia única.

Esa es la respuesta honesta sobre la mayoría de los casos del BCF. Es un artefacto limpio, rápido y estrecho. Rara vez te dice algo que nada más pueda. Su valor es la velocidad con la que te apunta a los archivos correctos.

Lecturas adicionales

SANS, póster de Windows Forensic Analysis. La distribución de la cadena de artefactos está anticuada para Win10 pero las casillas de Win7 siguen aplicando.
David Cowen, casos de estudio de Forensic Lunch. Mucha forma realista de IR en builds antiguos de Windows.

Si tienes un endpoint Win7 marcado mañana, agarra el BCF primero. Preocúpate por todo lo demás después.