Detección de manipulación en Windows Prefetch
Si Prefetch es uno de los mejores artefactos de ejecución que produce Windows, también es uno de los que los atacantes intentan limpiar con más frecuencia. Un intruso sofisticado rara vez dejará intactos los run counts y las marcas de tiempo. Así se ve bajo análisis cada forma común de manipulación.
Borrado masivo
El enfoque burdo: del /q C:\Windows\Prefetch\*.pf. La huella es
obvia — una estación de trabajo con uso intensivo pasa de cientos de
archivos Prefetch a unos pocos, todos creados muy recientemente
mientras el sistema sigue funcionando tras el borrado.
Señal: el número de archivos cae muy por debajo del baseline para
la versión del SO y la edad de la máquina. Una estación de trabajo de
seis meses con doce archivos .pf es sospechosa.
Contraanálisis: los archivos Prefetch dejan entradas en el journal
NTFS cuando se borran. Extrae el $LogFile y el $UsnJrnl y podrás
recuperar tanto los nombres como las marcas de tiempo de las entradas
borradas. El hecho mismo del borrado ya es evidencia.
Borrado dirigido
Más cuidadoso: borrar solo el archivo .pf del binario malicioso.
Todo lo demás parece normal.
Señal: un proceso del que puedes demostrar la ejecución (vía Security 4688, Sysmon o Amcache) no tiene la entrada Prefetch correspondiente en un host donde Prefetch está habilitado. El borrado dirigido también puede inferirse cuando la marca de tiempo de modificación del directorio es sospechosamente reciente respecto a su contenido.
Contraanálisis: cruza Amcache y ShimCache para recuperar la ruta
ausente. Hace carving del espacio no asignado en el volumen del sistema
en busca de archivos .pf; el Prefetch comprimido con Xpress deja una
cabecera distintiva MAM\x04 fácil de escanear.
Archivos Prefetch plantados
Más sutil: dejar un archivo Prefetch de otra máquina en el objetivo para crear una coartada falsa (o, en ejercicios de red team, para probar la detección del SOC).
Señal: el hash de Prefetch en el nombre del archivo no coincide con lo que el algoritmo de hash produce para la ruta del ejecutable embebida en el payload del Prefetch. Recalcula el hash sobre la ruta parseada y compáralo con el sufijo del nombre — una discrepancia es concluyente.
Otras señales: marcas de tiempo del registro de archivo NTFS que no concuerdan con el contenido parseado del Prefetch; valores FILETIME idénticos en archivos Prefetch "distintos" (un atacante copió y pegó la misma plantilla).
Run counts y marcas de tiempo falsificados
El ataque más quirúrgico: editar un archivo Prefetch real in situ para reducir el run count o cambiar las marcas de tiempo. Es raro porque requiere entender el formato, pero ocurre.
Señal: los checksums SCCA (donde existen) fallan. Marcas de tiempo que no coinciden con el tiempo de modificación NTFS del archivo. Run counts que disminuyen entre recolecciones — Windows solo incrementa, así que un descenso significa que algo más escribió el archivo.
Prefetch desactivado
La versión previa al ataque: configurar Windows para que Prefetch nunca cree archivos en primer lugar. Consulta Prefetch en Windows Server y configuraciones desactivadas para saber qué buscar en el registro.
Señal: PrefetchParameters\EnablePrefetcher = 0 en el registro de
una estación de trabajo, donde el valor por defecto es 3. Combinado
con una carpeta Prefetch\ vacía es un indicador fuerte de que el
sistema fue preconfigurado para suprimir este artefacto.
Uniendo las piezas
Cuando la evidencia Prefetch importa en un caso, la pregunta rara vez es "¿se ejecutó este archivo?". Es "¿puedo confiar en lo que dice esta entrada Prefetch?". Trata la respuesta como cualquier otra pieza de evidencia: corrobórala. Una entrada Prefetch aislada es una pista; una entrada Prefetch que concuerda con Amcache, ShimCache, el registro de seguridad y Sysmon es un testimonio.