Detectar manipulación de Windows Prefetch

Prefetch es uno de los artefactos de ejecución más limpios que produce Windows, y por eso mismo los atacantes competentes van a por él. La buena noticia: los atacantes son descuidados con prefetch más veces de las que son cuidadosos, y cada forma habitual de manipulación deja un rastro en otra parte del host. Aquí está cómo se ve cada una cuando te sientas con los datos.

Borrado masivo

La opción tosca es del /q C:\Windows\Prefetch\*.pf o un equivalente en PowerShell. Es rápida, ruidosa y funciona mientras nadie compare el resultado con una línea base.

Señal: número de archivos muy por debajo de lo que la versión del SO y el tiempo de actividad deberían producir. Una estación Windows 11 que lleva seis meses encendida con doce archivos .pf no es una instalación limpia. Incluso una imagen recién instalada de Win10 llega a las centenas en una semana.

Contra-análisis: las eliminaciones de archivos son eventos USN. Tira del USN journal y grep por .pf para recuperar nombres y marcas temporales de cuándo se eliminaron. El $LogFile de NTFS (aún residente, ventana mucho más corta) suele contener la misma evidencia con detalle de atributos. La propia entrada MFT del directorio retiene una hora de última modificación que fija cuándo se ejecutó la purga. Combina con el EVTX de Security o Sysmon alrededor de esa ventana y normalmente identificas el proceso que lo hizo.

Borrado dirigido

La versión cuidadosa: borrar solo el .pf perteneciente al binario malicioso y dejar el resto intacto. Mucho más difícil de detectar solo por número de archivos.

Señal: una ejecución que puedes probar en otro sitio (Security 4688, Sysmon EID 1, AmCache, Shimcache, entradas LNK o jump list) sin su correspondiente .pf. En un host donde EnablePrefetcher = 3 y el servicio SysMain ha estado funcionando, esa ausencia no es casualidad.

Contra-análisis: carva el espacio no asignado del volumen del sistema. El prefetch comprimido con Xpress Huffman empieza con MAM\x04: una firma de cuatro bytes poco frecuente en datos normales. Tanto bulk_extractor como una regla rápida de scalpel recuperan los .pf borrados si sus clústeres no se han reutilizado. Comprueba también las Volume Shadow Copies; los directorios prefetch suelen sobrevivir en snapshots antiguos.

Archivos prefetch plantados

Soltar un .pf de otra máquina en el objetivo. Se usa para fabricar una coartada, en ejercicios de red team para probar la detección del SOC y, ocasionalmente, en malware que quiere aparentar llevar más tiempo en el sistema.

Señal: el hash de 8 caracteres del nombre no coincide con lo que la Hash Function 5 de Win7+ produce para la ruta del ejecutable embebida en el payload. Recalcula y compara. Una discrepancia es concluyente.

Otros indicios: marcas temporales del registro de archivo NTFS que contradicen los valores FILETIME dentro del archivo (un .pf no puede haber corrido antes de existir); marcas temporales de ejecución idénticas entre entradas "distintas", lo que suele significar que el atacante copió la misma plantilla y olvidó variar los rangos de bytes; números de serie de volumen en la sección de información de volumen que no coinciden con los volúmenes de este host.

Contadores y marcas temporales falsificados

La variante quirúrgica: editar un .pf real in situ para bajar el contador de ejecuciones o reescribir las ocho ranuras FILETIME de última ejecución. Raro porque requiere comprender el layout SCCA, pero ocurre.

Señal: donde existen sumas de control SCCA, fallan. El Last-Modified del archivo en la MFT no se alinea con el FILETIME más reciente dentro. Contadores de ejecución que caen entre recolecciones son imposibles bajo comportamiento normal de Windows: SysMain solo incrementa, por lo que una disminución significa que algo reescribió el archivo.

Prefetch deshabilitado antes del ataque

La antiforense más barata es no producir el artefacto. Pon EnablePrefetcher = 0 y EnableSuperfetch = 0, detén SysMain, y el host directamente no escribirá archivos .pf. Consulta el post del servidor deshabilitado para el layout de registro al detalle.

Señal: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher = 0 en una estación cuyo valor por defecto es 3, combinado con un C:\Windows\Prefetch\ vacío. Verifica contra una Volume Shadow Copy antigua con el parser de registro: si el valor cambió de 3 a 0 a media jornada, el LastWrite de la hive SYSTEM te dice cuándo, y el EVTX de esa ventana normalmente te dice quién.

Cómo encajarlo

La pregunta en un caso disputado rara vez es "¿se ejecutó este binario?". Es "¿puedo defender la afirmación de que este .pf dice lo que dice?". Trata cada entrada como tratarías cualquier otra prueba: corrobórala. Un único hit de prefetch es una pista. Un hit de prefetch que cuadra con los hashes de AmCache, las rutas de Shimcache, los eventos de escritura del USN y un Security 4688 o Sysmon 1 es testimonio.

Lecturas adicionales

• Joachim Metz, documentación de libscca: para el layout exacto de campos que necesitas para detectar ediciones in situ.
• Eric Zimmerman, PECmd: expone los campos SCCA que has de cruzar contra el hash del nombre de archivo.