Prefetch es uno de esos artefactos a los que se llama "prueba de ejecución" tantas veces que la gente se olvida de preguntar qué prueba en realidad. Prueba que Windows arrancó un proceso ejecutando un binario con un nombre y un hash de ruta determinados. Eso basta para cerrar muchos casos. No basta para cerrarlos todos, y en esa diferencia es donde he visto a analistas hacer afirmaciones que no podían defender.

Este post es la versión de "qué nos dice Prefetch" que escribiría para alguien que está a punto de entrar en una investigación disputada.

Qué es Prefetch, en palabras claras

Windows observa los primeros diez segundos de cada proceso recién iniciado. Registra qué archivos toca, qué DLLs carga y cómo se traen las páginas de memoria. Esa traza se comprime y se guarda como un archivo .pf en C:\Windows\Prefetch\. La próxima vez que arranca el mismo ejecutable, Windows lee el .pf para precargar las páginas que espera necesitar; de ahí el nombre.

Ese es el propósito operativo. El valor forense es accidental: como Windows necesita saber qué precargar, tiene que recordar que el ejecutable corrió. Así que Prefetch mantiene un registro por binario con las últimas ocho ejecuciones, el total de ejecuciones, la ruta resuelta del binario y una lista de archivos que el binario cargó.

El formato del nombre es <EXECNAME>-<HASH>.pf, donde el hash se calcula a partir de la ruta completa (y en Win10+, a veces de otro contexto) para que el mismo binario lanzado desde dos ubicaciones distintas dé dos archivos .pf diferentes. Esto importa: un atacante que copia psexec.exe a C:\Users\victim\AppData\Local\Temp\ produce una entrada Prefetch distinta de la psexec.exe legítima en C:\Program Files\. Distingues los dos de un vistazo.

Qué prueba en realidad

Un archivo .pf prueba que un ejecutable con el nombre embebido fue arrancado, es decir, que se creó un proceso y corrió lo suficiente como para ser observado por el servicio Prefetch. Es una afirmación sólida. Más sólida que Shimcache, más sólida que AmCache y más sólida que el USN journal por sí solo.

Lo que no prueba:

• No prueba que el archivo en la ruta actualmente en disco sea el archivo que se ejecutó. Prefetch registra la ruta del ejecutable, no su hash. Si evil.exe se borró y luego se dejó un evil.exe benigno en su lugar, el .pf referencia "el ejecutable en esa ruta", que ahora es un archivo distinto.
• No prueba que un humano lo lanzara. Windows arranca procesos por todo tipo de razones automatizadas. Un .pf para cmd.exe significa que cmd arrancó; no significa que un usuario teclease nada en él.
• No prueba qué hizo el binario una vez en ejecución. Obtienes la lista de carga, no la línea de comandos. Para argumentos necesitas Sysmon EID 1 o Security 4688.
• No prueba ejecución en un contexto de usuario específico. Prefetch es por máquina. La pregunta "quién" necesita otro artefacto.

Si te llevas solo una cosa: Prefetch es evidencia de ejecución a nivel de binario, no a nivel de usuario, comando o comportamiento.

Las peculiaridades de Win10/11 que muerden

Durante años la línea era "Windows guarda las últimas ocho ejecuciones". En Win10 1709+ eso pasó a ser hasta ocho como máximo, pero rutinariamente menos: Windows empezó a expirar entradas antiguas agresivamente durante las ventanas de mantenimiento. Si lees un .pf y solo encuentras tres marcas temporales de ejecución, no concluyas que el binario solo se ejecutó tres veces. Se ejecutó al menos tres veces.

En Win11 22H2 y posteriores, Prefetch sobre SSDs queda parcialmente deshabilitado por el SO bajo ciertas condiciones. Microsoft lo llama optimización. Desde la forense es un agujero. En hosts Win11 sobre SSD he visto cobertura de Prefetch caer al 60 % de las ejecuciones, más o menos. Comprueba siempre HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher y EnableSuperfetch en el host antes de suponer que Prefetch está completo. El valor por defecto 3 significa que ambos están activos; 0 significa apagado.

Los servidores son peores. Prefetch está deshabilitado por defecto en Windows Server. Muchas redes tienen una GPO que lo activa, muchas no. Si estás haciendo DFIR en un servidor y no hay directorio Prefetch o está vacío, puede ser simplemente el valor por defecto, no manipulación del adversario.

El formato MAM (Prefetch comprimido en Win10+) es incompatible con los parsers offline más antiguos. El PECmd de Eric Zimmerman lo maneja correctamente; muchos de los parsers de Python antiguos no, y producen silenciosamente resultados erróneos. He visto informes construidos sobre salidas de prefetchparser.py desde un host Win10 que eran estructuralmente equivocados porque el parser se saltó silenciosamente los archivos MAM.

Leer las marcas temporales sin caer en engaños

Cada .pf lleva hasta ocho tiempos de ejecución y un tiempo de "última ejecución". El formato es FILETIME (intervalos de 100 nanosegundos desde 1601 UTC), y los tiempos son cuándo Windows empezó a monitorizar el proceso, no cuándo el binario estuvo en disco. Esa distinción importa en un caso específico.

Last run menos Created (del propio .pf, según NTFS) es aproximadamente la vida útil de la entrada. Si Last run es reciente pero el .pf fue creado hace dos años, el binario ha estado ejecutándose en este host dos años. Eso por sí solo descarta la hipótesis "es la primera vez que vemos esta herramienta". Combínalo con la MFT para las propias fechas del binario.

Donde veo a analistas quemarse: comparar un "Last run" de un .pf con un "Process create" de un 4688 en otro punto del host y tratarlos como la misma hora. Están cerca pero no son idénticos, y el offset varía entre compilaciones y cargas de CPU. Dentro de unos segundos es normal. Si ves un minuto de hueco, estás mirando la misma ejecución. Si ves una hora, estás mirando dos ejecuciones distintas.

La lista de carga de archivos y para qué sirve

Más allá del contador de ejecuciones, cada .pf lleva una lista de archivos que el ejecutable abrió en sus primeros diez segundos. Hasta ~1000 entradas en un binario normal, todas almacenadas como rutas que Windows resolvió en ese momento. Esta es la parte que la mayoría de la gente sobrevuela.

La lista de carga es donde miro cuando necesito responder "qué tocó este proceso". Tres patrones que busco rutinariamente:

• Evidencia de secuestro del orden de búsqueda de DLL. Un binario de confianza cargando una DLL desde \AppData\Local\Temp\ en lugar de \System32\ aparece como una ruta en la lista de carga. Ordena por prefijo de ruta.
• Archivos de configuración de malware. Mucho malware de commodity carga su configuración desde un nombre fijo junto al binario. \AppData\Roaming\<tool>\config.bin y rutas similares son indicios claros.
• Aperturas de documentos. Si winword.exe tiene \Users\bob\Documents\offer-letter.docx en su lista de carga y estás investigando una afirmación de phishing, eso corrobora que el documento se abrió en este host. Combina con los archivos LNK y las jump lists para el contexto a nivel de usuario.

La lista de carga no incluye archivos escritos, solo leídos (en el sentido amplio de que Windows rastrea fallas de página sobre ellos). Para escrituras necesitas Sysmon EID 11.

Antiforense y qué aguanta

Los atacantes pueden borrar y borran archivos .pf. Tres cosas a saber:

1. Borrar el .pf no borra el rastro de la MFT. Una eliminación Prefetch deja un registro USN FileDelete | Close y una entrada MFT que perdura hasta reutilizarse. Si el directorio parece sospechosamente vacío, parsea el USN journal.
2. Deshabilitar Prefetcher en mitad de una investigación es fácil y detectable. Un cambio de valor de registro en PrefetchParameters actualiza el LastWrite de la hive SYSTEM. Compara contra snapshots VSC.
3. Los .pf de los binarios que el atacante trajo consigo suelen quedarse atrás. Es el regalo que sigue dando. Los atacantes limpian los lugares obvios — el propio binario, el directorio de staging — y olvidan Prefetch. He cerrado casos donde la única evidencia superviviente de una mimikatz renombrada era el MIMI-xxxxxx.pf que nunca se limpió.

Un workflow que aplico de verdad

Orden de operaciones en un host donde Prefetch importa:

1. Adquiere todo el directorio C:\Windows\Prefetch\. Preserva las marcas temporales del sistema de archivos; no copies con nada que las resetee.
2. Lista por Created de NTFS, descendente. Cualquier cosa creada durante la ventana sospechosa va a la lista corta.
3. Parsea a una tabla plana: nombre de archivo, nombre del ejecutable, ruta, contador de ejecuciones, últimas 8 ejecuciones.
4. Ordena por contador de ejecuciones ascendente. Binarios de una sola ejecución con rutas en localizaciones escribibles por el usuario son interesantes. Binarios de muchas ejecuciones en \System32\ son normales.
5. Para cada fila interesante, saca la lista de carga y busca los patrones anteriores.
6. Corrobora con Sysmon / Security EVTX emparejando ruta y tiempos de ejecución. Aquí es donde el hit Prefetch se convierte en afirmación defendible de ejecución.

El paso 4 es donde más coacheo a los analistas. Contra intuitivamente, los archivos Prefetch de una sola ejecución suelen ser los más interesantes en una intrusión. Los de muchas ejecuciones suelen ser ruido de fondo a menos que vivan en lugares sospechosos.

Dónde encaja Prefetch en el panorama de artefactos

Es una herramienta entre varias, y las afirmaciones más fuertes lo combinan con otras. Prefetch pone un nombre en la lista. AmCache pone un hash al lado. Shimcache dice que Windows miró el archivo en algún momento. La MFT ubica el archivo en tiempo y espacio. El USN journal narra qué le pasó. Sysmon y Security te dicen quién, cuándo y con qué argumentos.

Trata Prefetch como pieza clave de "el binario corrió" y lo usarás bien. Trátalo como respuesta a "qué pasó en este host" y te equivocarás.

Leer archivos .pf en el navegador

El parser de este sitio decodifica Prefetch comprimido MAM de Win10/11 además del formato SCCA antiguo en tu navegador, sin subir nada. Suelta un .pf (o todo el directorio) y obtienes el nombre del ejecutable, el contador de ejecuciones, los ocho tiempos de ejecución y la lista de carga en una tabla ordenable. Útil cuando los contenidos Prefetch del host son lo bastante sensibles como para que prefieras no entregarlos a un servicio externo.

Lecturas adicionales

• Yogesh Khatri, Análisis forense de archivos Prefetch en Windows y entregas posteriores: siguen siendo de los textos más claros sobre el formato.
• Eric Zimmerman, PECmd: el parser offline a usar.
• Microsoft Docs, Memory Management — PrefetchParameters: para los interruptores de registro reales.

Si el servicio Prefetch estaba deshabilitado, nada de lo anterior te salvará. Comprueba primero.