← Volver a todos los artículos

La primera mitad de cada conversación que tengo sobre Prefetch en un host Win10 o Win11 acaba siendo una conversación sobre SuperFetch, SysMain, ReadyBoost, y cómo sea que Microsoft estuviera llamando ese trimestre a las funciones de gestión de memoria. La mitad de la sala cree que son lo mismo. La otra mitad cree que Prefetch está obsoleto. Ambas mitades se equivocan, pero en direcciones distintas, y los malentendidos afectan a cuánto puedes fiarte del directorio Prefetch en un host moderno.

Este post es la versión limpia de esa conversación.

Qué es cada cosa realmente

Prefetch es la caché a nivel de archivo para el arranque de aplicaciones. Observa los primeros diez segundos de un proceso, escribe un .pf y usa ese archivo en el siguiente lanzamiento para pre-faltar las páginas que el proceso probablemente necesite. Vive en C:\Windows\Prefetch\. Este es el artefacto que nos interesa.

SuperFetch fue una función de gestión de memoria introducida en Windows Vista. Rastrea los patrones de uso de aplicaciones a lo largo del tiempo (no solo en el arranque, también durante el uso normal) y precarga páginas proactivamente en RAM durante los periodos ociosos, para que las aplicaciones más usadas arranquen más rápido. Escribe sus datos de seguimiento en archivos Ag*.db dentro de C:\Windows\Prefetch\. Esos .db no son archivos Prefetch. Son bases de datos de SuperFetch.

SysMain es como se llamó SuperFetch a partir de Windows 10 1709. Misma función, misma DLL de servicio (sysmain.dll), mismos archivos .db en el directorio Prefetch. El servicio que se llamaba "Superfetch" en services.msc ahora se llama "SysMain" en cualquier host actual Win10/11. El renombrado fue cosmético.

ReadyBoost es una función separada que usa almacenamiento USB flash como caché write-through para el conjunto de trabajo. No relevante para análisis forense de Prefetch, pero vive en la misma vecindad conceptual y por eso se confunde con los otros.

Los tres artefactos contiguos a Prefetch en un host Win10/11 son por tanto:

  • C:\Windows\Prefetch\<EXE>-<HASH>.pf: trazas Prefetch por aplicación, el artefacto que cubre este sitio entero.
  • C:\Windows\Prefetch\AgAppLaunch.db y compañía: bases de datos de SysMain, que son un artefacto separado (SRUM y las bases de SysMain son cosas distintas, ambas útiles, ninguna es Prefetch).
  • C:\Windows\Prefetch\NTOSBOOT-XXXXXXXX.pf: el Prefetch de arranque, regenerado en cada boot.

Si alguien dice "el directorio Prefetch" suele referirse al primero. Si dice "Prefetch" sin contexto, probablemente también, pero conviene ser preciso cuando se escribe un informe.

La cuestión de la deshabilitación en SSD

Aquí va la parte que reaparece una y otra vez.

En Vista y Windows 7, tanto Prefetch como SuperFetch estaban activados para todos en todo tipo de discos. En Windows 8, Microsoft añadió lógica para detectar SSDs y reducir o deshabilitar ciertas operaciones sobre ellos, bajo la teoría de que los SSD no se benefician del precarga secuencial como sí los HDD.

En Windows 10 esa lógica se volvió más agresiva. En Windows 11, más todavía.

Lo que "deshabilitado en SSD" significa en la práctica, hasta donde he podido determinar de la telemetría y la propia documentación variable de Microsoft:

  • El Prefetch de arranque (NTOSBOOT-XXXXXXXX.pf) siempre se escribe.
  • El Prefetch de aplicación (los .pf por .exe) se escribe parcialmente. Algunas aplicaciones producen .pf; otras no. La decisión parece tomarla SysMain con heurísticas sobre si la aplicación se beneficiaría del prefetch.
  • La precarga proactiva de SuperFetch/SysMain está mayormente deshabilitada en SSDs porque Microsoft considera que la reducción de latencia no compensa el coste de E/S.

La consecuencia forense: en un host Win10 o Win11 con SSD, la ausencia de un .pf para un ejecutable dado no es evidencia de que el ejecutable no se ejecutó. Es evidencia de que o bien el ejecutable no corrió, o SysMain decidió no escribir datos Prefetch para él.

Empíricamente he visto coberturas Prefetch del 60 % al 90 % en hosts Win11 sobre SSD, frente a casi el 100 % en hosts Win10 sobre HDD. El porcentaje exacto depende de la carga del host, de qué ejecutables han decidido saltarse las heurísticas de Microsoft y de si el sistema está bajo presión de memoria.

Si necesitas saber con certeza si un binario corrió, no te fíes de la ausencia de un .pf en un host SSD moderno. Combina con EVTX, AmCache y la telemetría real de ejecución de procesos del host.

Los interruptores del registro

La ruta del registro que controla todo esto es:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

Los valores que importan:

  • EnablePrefetcher (REG_DWORD). Controla el Prefetch de aplicación.
    • 0 = deshabilitado
    • 1 = solo Prefetch de aplicación
    • 2 = solo Prefetch de arranque
    • 3 = ambos (por defecto en la mayoría de SKUs cliente)
  • EnableSuperfetch (REG_DWORD). Mismos valores posibles, controla SuperFetch/SysMain.
  • EnableBootTrace (REG_DWORD). Controla la traza de arranque. Suele ser 0 en SKUs cliente con el resto activado.

En una instalación por defecto de Windows 10/11 Pro verás EnablePrefetcher = 3 y EnableSuperfetch = 3. En una instalación por defecto de Windows Server, ambos suelen ser 0. En hosts donde una política de grupo ha ajustado cosas, puedes ver cualquier valor.

La lógica de detección de SSD no cambia estos valores. Aun con EnablePrefetcher = 3, el SO puede seguir saltándose la escritura de ciertos .pf en un host SSD. No puedes inferir "el Prefetch estará completo" a partir de un 3 en el registro en Win10+.

El resumen honesto: el registro te dice si Prefetch está habilitado administrativamente. No te dice si Prefetch se escribió realmente para una ejecución dada. En Win7 y anteriores esas dos afirmaciones eran lo mismo. En Win10+ no lo son.

Qué cambió en Win10 1709

La release 1709 ("Fall Creators Update") es la versión en la que:

  • SuperFetch pasó a llamarse SysMain.
  • El anillo de ocho marcas temporales de ejecución del Prefetch de aplicación empezó a recortarse agresivamente durante las ventanas de mantenimiento ocioso. Un .pf que debería mostrar ocho ejecuciones podría mostrar solo tres en un host que lleva tiempo encendido.
  • El salto SSD-aware en las escrituras de .pf se volvió más agresivo que en builds anteriores de Win10.

Si lees literatura DFIR antigua sobre Prefetch (cualquier cosa escrita antes de 2018), asume que el autor trabajaba en un mundo pre-1709 y que algunas de sus suposiciones sobre cobertura Prefetch ya no se sostienen.

La más consecuente es el recorte de marcas temporales. La enseñanza clásica es "Prefetch guarda las últimas ocho ejecuciones". La corregida es "Prefetch guarda hasta ocho, con Win10 1709+ recortando entradas antiguas oportunísticamente". Un .pf con tres marcas temporales no significa que el binario corrió tres veces. Significa que el contador de ejecuciones dice una cosa (la cota inferior) y el array de marcas temporales muestra tres que sobrevivieron al recorte.

Windows Server

Vale repetirlo claramente: Prefetch está deshabilitado por defecto en Windows Server. De 2008 R2 a 2022, el valor por defecto de EnablePrefetcher en una instalación nueva de servidor es 0. SysMain también está apagado.

Muchas redes activan Prefetch en servidores vía GPO. Muchas no. Si trabajas un caso de servidor y el directorio Prefetch está vacío, lo primero a comprobar es si Prefetch llegó a estar activado en ese host. Saca la hive SYSTEM, lee el valor, comprueba el LastWrite. Si el valor se escribió por última vez en el momento de instalación del SO y es 0, la ausencia de .pf no dice nada sobre qué corrió.

Si el valor se cambió a 3 hace seis meses y el directorio solo tiene archivos .pf de los últimos seis meses, es consistente. Si el valor cambió hace dos días y el directorio tiene archivos anteriores al cambio, tienes una discrepancia que explicar (normalmente significa que la política se aplicó hace poco pero el directorio tiene archivos de la época de instalación del SO o de un estado de política anterior).

Qué verificar antes de fiarse de un .pf

Antes de citar Prefetch en un informe en un host Win10/11, compruebo:

  1. ¿Está habilitado Prefetch? Saca EnablePrefetcher y EnableSuperfetch de la hive SYSTEM. Anota el LastWrite de PrefetchParameters.
  2. ¿Estaba habilitado en el momento de los eventos que me interesan? Si el valor cambió durante la ventana sospechosa, el cambio forma parte de la cronología.
  3. ¿El host es SSD o HDD? Comprueba el tipo de disco desde la información del sistema. En SSD, baja tu confianza en "ausencia de .pf = ausencia de ejecución".
  4. ¿El host es un servidor? Si sí, factoriza el estado por defecto apagado y el historial de políticas.
  5. ¿Hay archivos Ag*.db en el directorio Prefetch? Si sí, SysMain ha estado en marcha y su base de datos puede tener datos de ejecución adicionales separados de los archivos .pf.
  6. ¿PECmd parsea los .pf limpiamente? Archivos inconsistentes o que fallan la validación del parser merecen una segunda mirada por manipulación.

Si los seis salen bien, la evidencia Prefetch es sólida. Si alguno no, la evidencia Prefetch sigue teniendo valor pero con salvedades que deberían aparecer en el informe.

Una nota sobre las bases de SysMain

Los archivos Ag*.db del directorio Prefetch son un artefacto separado que merece su propia discusión algún día. En breve: AgAppLaunch.db rastrea cuentas y tiempos de lanzamiento de aplicaciones a lo largo de ventanas más largas que Prefetch. Puede corroborar Prefetch y a veces cubre ejecuciones que Prefetch perdió.

Existen herramientas para parsearlas, pero son menos maduras que los parsers de Prefetch. Eric Zimmerman ha escrito sobre ellas. El formato no está documentado por Microsoft y es de ingeniería inversa, así que trata cualquier salida de parser con escepticismo apropiado.

Lo que le digo a los clientes

En Win7 y anteriores, Prefetch es exhaustivo. En Win10 sobre HDD, exhaustivo. En Win10 sobre SSD, parcial. En Win11 sobre SSD, más parcial. En Windows Server, condicionado a la política.

La respuesta correcta a "¿hay un Prefetch para el binario X?" nunca es la única pregunta. La respuesta correcta a "¿debería esperar encontrar uno dada la configuración de este host?" es la pregunta a hacerse antes.

Lecturas adicionales