Límites del BCF: cuándo no te dice nada, y qué usar en su lugar

El RecentFileCache.bcf tiene una reputación silenciosa entre la gente de DFIR que sabe que existe. La reputación es mayormente merecida. El artefacto es pequeño, específico y limpio. Pero también es más estrecho de lo que la gente recuerda entre casos. Después de unos meses sin tocar una caja Win7 tiendes a sobreestimar lo que el BCF puede responder.

Esta es la lista honesta de lo que el BCF no te da, y qué tirar junto con él.

Sin marcas de tiempo por entrada

El archivo contiene rutas. Eso es todo. No hay campo para "primer visto," "última ejecución" o "conteo de ejecuciones". Un binario aparece en el BCF si corrió desde el último pase de evaluación. Ese es un único bit de información a lo largo de toda la ventana de la vida laboral del archivo.

Lo más cercano a una marca de tiempo que ofrece el BCF es la propia hora de última modificación del archivo en disco, que te dice cuándo el appraiser le escribió por última vez. Esa marca de tiempo aplica al archivo entero. No puedes usarla para ordenar entradas dentro del archivo. No puedes usarla para decir "este binario corrió el martes".

Si necesitas marcas de tiempo:

• Prefetch. Hasta ocho últimas horas de ejecución por ejecutable en Win7 (el formato .pf antiguo), con metadatos completos de creación y modificación.
• USN journal. Para cuándo el binario apareció en disco, fue modificado o borrado. Granularidad a nivel de operación.
• Master File Table. Marcas de tiempo del atributo Standard Information y File Name. Útil cuando el binario ha sido borrado.
• Security 4688 o Sysmon 1. Eventos de creación de proceso con marcas de tiempo completas y líneas de comando, asumiendo que el logging estaba activo. En una instalación Win7 por defecto, no lo estaba.

El BCF te dice que algo pasó. Los otros artefactos te dicen cuándo.

Sin hashes

No hay hash en el BCF. Ni SHA1, ni MD5, ni el hash truncado de cabecera PE que el AmCache registra. Si quieres pivotar a threat intel, necesitas el binario mismo.

Tres formas de obtener el hash:

• Saca el binario del disco y hashéalo. Trivial si el archivo sigue ahí.
• Reconstruir desde un backup, un pagefile, o un volcado de RAM. Menos fiable pero a veces la única opción.
• Hashear el binario referenciado por el archivo Prefetch correspondiente leyendo el .pf y volviendo atrás. El Prefetch tampoco almacena el hash del binario, pero te da la ruta exacta y puedes recuperarlo del volumen.

Si el binario ha sido borrado y no hay backup, el BCF te deja sin hash. Hueco permanente.

Sin atribución de usuario

El BCF es por máquina. No hay campo para "corrió como bob" o "corrió como SYSTEM". Un binario que corrió como servicio y un binario que corrió como usuario interactivo se ven idénticos en el archivo.

Fuentes de atribución, en orden aproximado de preferencia:

• Security 4688 con SubjectUserSid. Lo más limpio. A menudo no presente en Win7 a menos que la política de auditoría haya sido afinada.
• Sysmon 1 con User. Lo mejor, pero Sysmon en Win7 es una bestia rara en el campo.
• El NTUSER.DAT del usuario y MUICache bajo los hives de usuario. MUICache registra ejecutables con los que el usuario ha interactuado vía Explorer. No autoritativo pero corroborante.
• Archivos LNK en las carpetas Recent y Office Recent del usuario. Si un usuario hizo doble click en el binario, probablemente exista un LNK.
• Jump lists. Para ejecutables que se pueden anclar o han sido usados recientemente.

Para que una entrada BCF se convierta en "usuario ejecutó esto", necesitas al menos una de esas fuentes corroborantes. El BCF solo nunca carga esa afirmación.

Sin tracking de scripts

Esta es la limitación que más a menudo pilla a la gente desprevenida. El BCF rastrea lanzamientos de ejecutables. Una invocación de powershell.exe que corrió diez scripts distintos produce una entrada BCF: \??\C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Lo mismo para cscript.exe, wscript.exe, mshta.exe, cmd.exe, regsvr32.exe, rundll32.exe.

Los intérpretes están en el BCF. Los scripts que corrieron no.

Para visibilidad a nivel de script en Win7:

• Logging tipo PowerShell 4688 vía Microsoft-Windows-PowerShell/Operational (event ID 4103, 4104), pero solo si Script Block Logging estaba activado. Casi nadie lo tenía activado por defecto en Win7.
• Log clásico de Windows PowerShell, Windows PowerShell.evtx. Menos informativo que el Operational pero vale la pena revisar.
• Archivos LNK para scripts explícitamente doble-clickeados.
• Historial del navegador para descargas de archivos de script, emparejado con papelera de reciclaje para lo que fue borrado.
• Los archivos de script reales en disco, donde típicamente viven las rutas user/AppData/Temp.

Un BCF que muestra que cscript.exe corrió es interesante. Un BCF que muestra que cscript.exe corrió y no puedes encontrar el script en disco es más interesante. Pivota al USN journal para el rastro del script borrado.

Sin tracking de DLL o librerías

A diferencia de Prefetch, el BCF no registra las DLLs cargadas en un proceso. Un binario que cargó una DLL maliciosa y un binario que corrió limpio se ven idénticos en el archivo.

Si sospechas de DLL sideloading o process hollowing, el BCF te dice que el proceso host corrió. No te dice qué fue cargado en él. Echa mano de:

• La lista de archivos referenciados de Prefetch.
• Sysmon Event ID 7 (ImageLoaded). Casi nunca presente en Win7 en la práctica.
• Análisis de memoria desde un volcado de RAM.
• Las claves de registro KnownDlls e ImageFileExecutionOptions para vectores de sideloading.

Sin contexto de red o persistencia

El BCF no registra la red. No muestra lookups DNS, conexiones salientes ni puertos a la escucha. No registra mecanismos de persistencia. Un binario que instaló un servicio, soltó una clave Run o registró una tarea programada es simplemente una entrada en el BCF; la actividad de instalación no aflora.

Para eso:

• Registry para claves Run, Services y ASEPs.
• Carpeta Tasks del Task Scheduler y el log operativo EVTX.
• SRUM, que solo existe en Win8+, así que no está en alcance en un host BCF. Pero vale la pena saberlo para cuando el host sea otra cosa.
• Caché DNS en memoria si tienes un volcado de RAM.

Sin cobertura más allá de la ventana de evaluación

El BCF contiene binarios que corrieron desde el último pase de evaluación. Eso son aproximadamente las últimas 24 horas en un host sano. Las ejecuciones más antiguas se han ido.

El artefacto para historial de ejecución más largo en Win7 es Shimcache, que vive en HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache y contiene muchas más entradas con marcas de tiempo de última modificación. Shimcache hace afirmaciones más débiles (el binario fue examinado, no necesariamente ejecutado) pero cubre una ventana más amplia. Úsalo para la pregunta "¿alguna vez corrió esto en el host?"; usa el BCF para la pregunta "¿corrió esto recientemente?".

Sin cobertura en Windows moderno

Si el host es Windows 8 o posterior, el BCF no está. Ve al AmCache en su lugar. El AmCache tiene sus propios límites (es más inventario que evidencia de ejecución) pero es la fuente primaria correcta en esos builds.

La forma de una respuesta completa

Un hit de BCF nunca es la historia completa. La forma de una afirmación completa para "el binario X corrió en el host Y a la hora T como el usuario Z e hizo lo siguiente" requiere:

• BCF o Prefetch para la ejecución en sí.
• Prefetch o EVTX para la marca de tiempo.
• EVTX, MUICache o LNK para el usuario.
• Archivos referenciados de Prefetch, Sysmon ImageLoaded o memoria para lo que cargó.
• USN journal y MFT para el ciclo de vida del archivo en disco.
• Registro, tareas programadas y servicios para persistencia.
• Logs de red, historial de navegador o memoria para actividad saliente.

El BCF aporta el bit más limpio de "¿corrió?". Todo lo demás necesita otra fuente. Trata el archivo como una verificación rápida, no como la pieza central de la investigación.

Lecturas adicionales

• Harlan Carvey, Windows Forensic Analysis Toolkit. Los capítulos sobre artefactos de ejecución de programa siguen siendo relevantes para casos Win7.
• Eric Zimmerman, documentación de herramientas. Para los artefactos corroborantes (Prefetch, Shimcache, AmCache, MFT) que vas a emparejar con el BCF.

Si el BCF es el único artefacto que tienes, el caso va a ser pobre en evidencia. Si el BCF es uno de siete artefactos que tienes, puede cargar peso real. La diferencia es el resto de la cadena.