← Volver a todos los artículos

Entendiendo Windows Prefetch

Los archivos .pf de Windows Prefetch viven en C:\Windows\Prefetch\ y registran metadatos de cada ejecutable que el sistema operativo ha lanzado en un host de estación de trabajo. Son el artefacto de ejecución más fiable que la mayoría de analistas toca en una semana normal. Un binario no necesita estar instalado, ser persistente, estar firmado ni siquiera seguir presente en disco para que su .pf se conserve.

Cada .pf se llama <EXECUTABLE>-<HASH>.pf. Los ocho caracteres hexadecimales son un hash de la ruta completa de lanzamiento codificada en UTF-16, con el prefijo \DEVICE\HARDDISKVOLUME{n}\. El contenido binario del propio ejecutable nunca entra en el hash. Dos copias de un binario idéntico ubicadas en C:\Program Files\Tool\tool.exe y en C:\Users\victim\AppData\Local\Temp\tool.exe producen dos archivos .pf distintos. Esa propiedad es exactamente la razón por la que Prefetch puede distinguir un binario legítimo del proveedor del mismo binario colocado en un directorio de usuario.

Qué contiene realmente un .pf parseado

Por cada .pf que sueltas en el parser, obtienes:

  • Nombre del ejecutable tal como aparece en el payload SCCA.
  • Número de versión SCCA. v17 en XP/Vista/7, v23 en Win8, v26 en Win8.1, v30 en Win10, v31 en Win11. La versión indica qué disposición de cabecera aplica y cuántos slots de última ejecución existen.
  • Contador de ejecuciones. Monotónico. SysMain solo lo incrementa; un valor que disminuye entre dos recolecciones es imposible bajo comportamiento normal de Windows.
  • Tiempos de última ejecución. Hasta ocho valores FILETIME en v26+, uno en versiones anteriores. Cada uno es un u64 de ticks de 100 nanosegundos desde el 01/01/1601 UTC, expresado en UTC, que marca el momento en que Windows comenzó a monitorizar el proceso.
  • Información de volumen. Ruta del dispositivo, número de serie NTFS y marca de tiempo de creación de cada volumen al que hizo referencia el binario. El número de serie es el mismo que registran los archivos LNK y la MFT.
  • Lista de métricas de archivos. Cada ruta que Windows trazó durante los primeros diez segundos de ejecución monitorizada: DLLs, archivos de configuración, archivos de datos, cualquier cosa que produjera una falla de página sobre un archivo conocido por Windows. Típicamente unos cientos de entradas en una aplicación real.

Eso basta para responder si este binario se ejecutó, cuándo, desde dónde y qué tocó, lo que cubre aproximadamente el 70 % de las preguntas de ejecución en un caso normal.

Por qué WebAssembly del lado del cliente

Los archivos .pf son evidencia. Subirlos a un servicio web de terceros para parsearlos rompe la cadena de custodia y expone rutas, números de serie de volúmenes y nombres de directorios de perfil de usuario que pueden ser sensibles por sí solos. El parser de este sitio compila un decodificador SCCA en Rust puro (frnsc-prefetch) a WebAssembly y lo ejecuta en un Web Worker dentro del navegador. Los bytes nunca salen de la máquina. No hay endpoint de subida, ni telemetría sobre el contenido del archivo.

Las herramientas equivalentes para escritorio son PECmd (Eric Zimmerman, .NET) y libscca (libyal, C con bindings de Python a través de pyscca). Usa la que mejor encaje en tu pipeline. Para una triage rápida en un host donde preferirías no instalar nada, el parser de navegador es más rápido que aprovisionar una VM con herramientas.

El problema de compresión en Win8+

Desde Windows 8, SysMain comprime los archivos .pf antes de escribirlos en disco. Cada archivo empieza por MAM\x04, seguido de un campo u32 con el tamaño sin comprimir, y a continuación un payload comprimido con Xpress Huffman. Las herramientas anteriores a Windows 8 que no se hayan actualizado leerán los bytes MAM como si fueran el inicio de una cabecera SCCA y producirán resultados incorrectos en silencio. Si un parser dice soportar Windows 10 pero no puede leer tus archivos, lo primero que hay que comprobar es si lleva siquiera un decodificador Xpress Huffman en su pipeline.

El parser de este sitio detecta automáticamente los archivos comprimidos con MAM y los antiguos sin comprimir. El framing MAM no ha cambiado desde Windows 8; solo ha variado el payload SCCA contenido en su interior.

Cómo interpretar lo que obtienes

Para la triage, ordena de forma descendente por la hora de creación NTFS y mira primero las entradas recientes. Ordena ascendentemente por contador de ejecuciones y observa los binarios de una sola ejecución: suelen ser más interesantes que los que se ejecutaron cien veces. Para cada candidato, expande la lista de métricas de archivos y busca rutas de carga de DLL en directorios escribibles por el usuario, referencias a documentos que coincidan con una hipótesis de phishing, o archivos de configuración en \AppData\Roaming\ que coincidan con patrones conocidos de malware.

Después corrobora. Prefetch por sí solo prueba que un proceso arrancó. No prueba quién lo arrancó, con qué argumentos, ni que el binario actualmente en disco sea el binario que se ejecutó. Combínalo con AmCache para el SHA-1, Shimcache para corroboración de ruta, el USN journal para saber cuándo apareció el binario en disco, y el EVTX de Security o Sysmon para línea de comandos y contexto de usuario. El artículo dedicado a Prefetch como prueba recorre el workflow completo.

Pruébalo

Suelta un .pf o un directorio C:\Windows\Prefetch\ completo en el parser. Obtendrás una tabla ordenable y buscable de cada ejecución con detalle desplegable de volúmenes y la lista de métricas de archivos. Pulsa Descargar JSON para exportar salida estructurada a jq, a un notebook o a tu línea de tiempo del caso.

Lecturas adicionales