Forense de Windows: artefactos de ejecución

Aviso ético y legal: las técnicas de este módulo se aplican exclusivamente sobre sistemas, VMs de laboratorio o entornos con autorización explícita por escrito. Analizar el registro, el Prefetch o el $MFT de un equipo sin consentimiento del propietario constituye acceso ilícito a sistemas informáticos y puede ser delito (en España, arts. 197 bis y 264 del Código Penal). Todo lo que sigue está pensado para investigación forense legítima, respuesta a incidentes (DFIR) autorizada y entornos de práctica controlados como los de este curso.

Qué aprenderás

Qué son los hives del registro de Windows (SYSTEM, SOFTWARE, SECURITY, SAM, NTUSER.DAT, USRCLASS.DAT), dónde viven en disco y qué claves de persistencia (Run/RunOnce) hay que revisar siempre.
Cómo usar AppCompatCache (ShimCache) y Amcache.hve como evidencia de que un binario existió y, en ciertas condiciones, se ejecutó en el sistema.
Cómo interpretar Prefetch (C:WindowsPrefetch) para obtener nombre de ejecutable, número de ejecuciones y marcas de tiempo de la última(s) ejecución(es).
Qué aportan UserAssist, ShellBags, Jump Lists y los archivos LNK como evidencia de interacción del usuario con archivos, carpetas y programas.
Qué es SRUM (System Resource Usage Monitor) y cómo reconstruye actividad de red y de aplicación incluso semanas después.
Cómo leer los metadatos NTFS del $MFT, el $LogFile y el $UsnJrnl:$J, la diferencia entre timestamps $STANDARD_INFORMATION y $FILE_NAME, y cómo detectar timestomping.
Manejo práctico de las Eric Zimmerman Tools (MFTECmd, PECmd, AppCompatCacheParser, AmcacheParser, RECmd, JLECmd, LECmd, Registry Explorer, Timeline Explorer) y de Autopsy para triaje.

1. El registro de Windows: los hives y las claves de persistencia

El registro de Windows es una base de datos jerárquica que almacena configuración del sistema, hardware, software instalado y cada perfil de usuario. Para forense, lo relevante no es el registro «en caliente» (el que ves con regedit.exe), sino los ficheros hive en disco, que se copian, procesan offline y correlacionan con otras fuentes.

Hive	Ruta en disco	Clave de carga en vivo	Qué contiene
SYSTEM	`C:WindowsSystem32configSYSTEM`	HKEY_LOCAL_MACHINESYSTEM	Servicios, drivers, ShimCache, ControlSets, configuración de red, nombre de equipo, USBSTOR
SOFTWARE	`C:WindowsSystem32configSOFTWARE`	HKEY_LOCAL_MACHINESOFTWARE	Software instalado, Run keys de máquina, versión de Windows, App Paths
SECURITY	`C:WindowsSystem32configSECURITY`	HKEY_LOCAL_MACHINESECURITY	Política de auditoría local, secretos LSA, información de dominio
SAM	`C:WindowsSystem32configSAM`	HKEY_LOCAL_MACHINESAM	Cuentas locales, hashes NTLM, RID, último login, intentos fallidos
NTUSER.DAT	`C:Users<usuario>NTUSER.DAT`	HKEY_CURRENT_USER (por usuario)	UserAssist, Run keys de usuario, TypedPaths, RecentDocs, historial de comandos
USRCLASS.DAT	`C:Users<usuario>AppDataLocalMicrosoftWindowsUSRCLASS.DAT`	HKEY_CURRENT_USERSoftwareClasses	ShellBags (navegación por carpetas), asociaciones de tipo de fichero por usuario

Los hives SYSTEM, SOFTWARE, SECURITY y SAM están bloqueados por el kernel mientras Windows está en marcha (no se pueden copiar con un simple copy); se extraen con herramientas que hacen shadow copy (VSS) o se recogen offline montando el disco. Es habitual encontrar copias de respaldo en C:WindowsSystem32configRegBack (aunque desde Windows 10 1803 el backup automático semanal está deshabilitado por defecto) y en Volume Shadow Copies, que permiten reconstruir el estado del registro en fechas anteriores.

1.1. Claves de persistencia Run / RunOnce

Es el primer sitio que revisa cualquier analista ante sospecha de malware persistente, porque son las claves que Windows ejecuta automáticamente en el arranque o en el logon del usuario.

Clave	Hive	Se ejecuta
`SOFTWAREMicrosoftWindowsCurrentVersionRun`	SOFTWARE	Cada arranque, para todos los usuarios
`SOFTWAREMicrosoftWindowsCurrentVersionRunOnce`	SOFTWARE	Una sola vez, luego se autoborra la entrada
`SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionRun`	SOFTWARE	Igual que el anterior, en procesos 32-bit sobre Windows 64-bit
`SoftwareMicrosoftWindowsCurrentVersionRun`	NTUSER.DAT	Cada logon de ese usuario concreto
`SoftwareMicrosoftWindowsCurrentVersionRunOnce`	NTUSER.DAT	Una sola vez, en el logon de ese usuario

Son solo una parte del universo de persistencia (servicios, tareas programadas, WMI event subscriptions y DLL hijacking quedan fuera del alcance de este módulo), pero de revisión obligatoria en cualquier triaje. La herramienta estándar para volcar de golpe todas las claves de autoarranque conocidas de un hive es RECmd (Registry Explorer Command Line) de Eric Zimmerman, con el batch predefinido RECmd_Batch_AutoRuns.reb:

RECmd.exe --bn BatchExamplesRECmd_Batch_AutoRuns.reb -d "C:rutaevidenciaconfig" --csv "C:salida" --csvf autoruns.csv

Para inspección interactiva y visual, se usa Registry Explorer, cargando el hive con File > Load offline hive y navegando o buscando directamente por la ruta de la clave.

2. Evidencia de ejecución: AppCompatCache (ShimCache) y Amcache

Windows mantiene dos mecanismos internos, no diseñados para forense pero explotados intensamente por analistas DFIR, que registran metadatos de ejecutables que han pasado por el sistema.

2.1. AppCompatCache / ShimCache

El Application Compatibility Cache (ShimCache) es parte del subsistema de compatibilidad de aplicaciones de Windows. Vive en el hive SYSTEM, en el ControlSet actualmente en uso:

SYSTEMCurrentControlSetControlSession ManagerAppCompatCache

Cada entrada registra ruta completa del ejecutable, tamaño de fichero (en versiones antiguas) y el timestamp $STANDARD_INFORMATION Last Modified del fichero en el momento en que se cacheó. Punto crítico y muy preguntado en examen: en Windows 7/8/8.1 el ShimCache solo indica que el ejecutable existió en disco y fue evaluado por el motor de compatibilidad — no siempre implica ejecución (basta con que el usuario haya hecho doble clic o el Explorer haya enumerado el fichero). En Windows 10 la caché ya no incluye el flag de ejecución explícito de versiones previas y su fiabilidad como prueba de ejecución es aún más discutida, por lo que siempre debe corroborarse con Prefetch, Amcache o el Event Log antes de afirmar ejecución. Tiene un límite de entradas (unas 1024 típicamente) y se escribe de forma diferida — normalmente en el apagado o reinicio —, por lo que puede haber pérdida de entradas recientes si el sistema se apagó bruscamente.

Se procesa con AppCompatCacheParser:

AppCompatCacheParser.exe -f "C:rutaevidenciaSYSTEM" --csv "C:salida" --csvf shimcache.csv

Si no se especifica -f, la herramienta detecta hives SYSTEM vivos en el sistema local; en análisis forense offline siempre se apunta explícitamente al hive extraído.

2.2. Amcache.hve

Amcache es, con diferencia, la fuente más fiable de las dos para demostrar que un ejecutable existió en el sistema, y en muchos casos, que se ejecutó. Es un hive independiente (no una clave dentro de SYSTEM), introducido en Windows 8 como sustituto/complemento del antiguo RecentFileCache.bcf:

C:WindowsAppCompatProgramsAmcache.hve

La clave más relevante es RootFile{volume GUID}{entry}, que almacena por cada ejecutable: ruta completa, hash SHA-1 del binario, tamaño, PE header (compilation timestamp), versión, editor/publisher, y en muchas builds el campo «Key Last Write Time» de esa subclave, que suele correlacionar con el primer momento en que el ejecutable fue visto por el sistema. Tener el hash SHA-1 directamente en el registro es enormemente valioso: permite pivotar a VirusTotal o a un feed de inteligencia sin tener el binario en la mano. Amcache también incluye RootPrograms (software instalado tipo MSI) y, en versiones recientes, RootInventoryApplicationFile.

Se procesa con AmcacheParser:

AmcacheParser.exe -f "C:rutaevidenciaAmcache.hve" --csv "C:salida" -i

El flag -i incluye también las entradas «InventoryApplicationFile» del catálogo de inventario de aplicaciones. La salida separa varios CSV (UnassociatedFileEntries, ProgramEntries, etc.) que conviene abrir con Timeline Explorer para filtrar y ordenar cómodamente.

Correlación obligatoria: ShimCache dice «existía aquí en esta fecha (quizá se ejecutó)». Amcache dice «este hash fue registrado por el sistema (fuerte indicio de ejecución)». Prefetch dice «se ejecutó N veces, la última en esta fecha exacta». Ningún artefacto por sí solo es concluyente: la solidez viene de la correlación cruzada de los tres, más el Event Log (Security 4688, Sysmon Event ID 1) cuando esté disponible.

3. Prefetch: la prueba más granular de ejecución

Prefetch es una característica de rendimiento (no de auditoría) que Windows usa desde XP para acelerar el arranque de aplicaciones usadas con frecuencia, precargando en memoria los ficheros que el ejecutable necesita. Cada vez que se lanza un binario, Windows escribe o actualiza un fichero .pf en:

C:WindowsPrefetch

El nombre de fichero sigue el patrón NOMBREEJECUTABLE-HASH.pf, donde el hash de 8 caracteres deriva de la ruta desde la que se lanzó el binario (el mismo ejecutable lanzado desde dos ubicaciones distintas genera dos .pf diferentes). Importante para el examen: Prefetch está deshabilitado por defecto en servidores (Windows Server) salvo activación manual, y en Windows 10/11 de escritorio con SSD puede estar limitado (aunque en la mayoría de builds de cliente sigue activo). Comprobar el estado real se hace mirando:

SYSTEMCurrentControlSetControlSession ManagerMemory ManagementPrefetchParametersEnablePrefetcher

Cada .pf contiene:

Nombre del ejecutable y ruta completa desde la que se ejecutó.
Run Count: número total de veces que se ha ejecutado ese binario desde esa ruta.
Última fecha/hora de ejecución (Last Run Time) — y desde Windows 8.1 en adelante, hasta las últimas 8 marcas de tiempo de ejecución, no solo la última.
Volume information: creation date del volumen, número de serie.
Ficheros y directorios referenciados durante el arranque (DLLs cargadas, ficheros de configuración) — útil para ver qué tocó el proceso incluso si el binario ya no está en disco.

Se procesa con PECmd:

PECmd.exe -d "C:rutaevidenciaWindowsPrefetch" --csv "C:salida" --csvf prefetch.csv -q

El flag -q reduce el ruido de consola; para volcar también los ficheros/directorios referenciados por cada .pf se revisa directamente el CSV de detalle que genera la herramienta. Con un único fichero: PECmd.exe -f "C:rutaevidenciaWindowsPrefetchMALWARE.EXE-A1B2C3D4.pf".

Prefetch es el artefacto más útil para responder cuántas veces se ejecutó algo y cuándo fue la última vez, pero no dice quién lo ejecutó (no hay usuario asociado) ni sobrevive a un del selectivo del .pf, ni a la desactivación del Prefetcher: Windows limita el número de .pf almacenados (1024 en versiones recientes) y los va rotando.

4. Actividad de usuario: UserAssist, ShellBags, Jump Lists y LNK

4.1. UserAssist

UserAssist registra en el hive NTUSER.DAT del usuario los programas lanzados desde el Shell del Explorer (doble clic, menú Inicio):

SoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist{GUID}Count

Los nombres de valor están ofuscados con ROT13 (herencia histórica) y las herramientas modernas los desofuscan automáticamente. Cada entrada aporta contador de ejecuciones, Focus Count/Time (tiempo con la ventana en foco) y fecha/hora de la última ejecución. Al depender del Shell, un binario lanzado por línea de comandos, tarea programada o PowerShell no aparece aquí — es un artefacto de interacción de escritorio, no de ejecución de proceso a nivel de kernel.

4.2. ShellBags

Los ShellBags reconstruyen el historial de navegación por carpetas en el Explorer, incluso de carpetas que ya no existen (una unidad USB desmontada, una carpeta de red, o una carpeta borrada tras copiar ficheros a ella). Se almacenan repartidos entre USRCLASS.DAT (bajo SoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellBagMRU y ...ShellBags) y, en menor medida, en NTUSER.DAT. Son útiles para demostrar que un usuario navegó y vio el contenido de una carpeta concreta (p. ej. donde estaba el malware, o una unidad extraíble con datos exfiltrados), con timestamps de creación y modificación del propio ShellBag.

4.3. Jump Lists

Las Jump Lists son las listas de «recientes/anclados» al hacer clic derecho sobre un icono anclado a la barra de tareas. Se guardan como .automaticDestinations-ms (generados por interacción normal) y .customDestinations-ms (creados explícitamente, p. ej. al «anclar»), en:

C:Users<usuario>AppDataRoamingMicrosoftWindowsRecentAutomaticDestinations
C:Users<usuario>AppDataRoamingMicrosoftWindowsRecentCustomDestinations

El nombre de fichero es un AppID de 16 caracteres hexadecimales que identifica la aplicación. Internamente cada AutomaticDestination es un fichero OLE/Compound File que contiene streams LNK embebidos — por eso el analizador de Jump Lists reutiliza el mismo parser que el de LNK. Revelan qué ficheros concretos se abrieron con qué aplicación y cuándo, con varias marcas de tiempo por entrada.

4.4. Archivos LNK (accesos directos)

Windows crea automáticamente un .lnk en C:Users<usuario>AppDataRoamingMicrosoftWindowsRecent cada vez que se abre un fichero desde el Explorer, sin que el usuario haya creado un acceso directo manualmente. Un LNK contiene: ruta completa del objetivo, número de serie del volumen de origen, tamaño del fichero objetivo, MAC address del adaptador de red del equipo donde se creó (vía el Tracker/Droid ID, cuando el volumen es de red o extraíble), y timestamps del fichero objetivo en el momento de creación del LNK. Esto los convierte en prueba sólida de que un fichero concreto — a menudo ya borrado, o en una unidad USB ya desconectada — existió y fue abierto.

Jump Lists y LNK se procesan con JLECmd y LECmd respectivamente:

JLECmd.exe -d "C:rutaevidenciaRecentAutomaticDestinations" --csv "C:salida" --csvf jumplists.csv
LECmd.exe -d "C:rutaevidenciaRecent" --csv "C:salida" --csvf lnk.csv -q

Artefacto	Ubicación	Qué demuestra
Run/RunOnce (SOFTWARE)	`SOFTWARE...CurrentVersionRun(Once)`	Persistencia configurada a nivel de máquina
Run/RunOnce (NTUSER)	`NTUSER.DAT...CurrentVersionRun(Once)`	Persistencia configurada para un usuario concreto
ShimCache	`SYSTEM...Session ManagerAppCompatCache`	El ejecutable existió en esa ruta; posible ejecución (no concluyente por sí solo)
Amcache	`C:WindowsAppCompatProgramsAmcache.hve`	El ejecutable existió, con hash SHA-1; fuerte indicio de ejecución/instalación
Prefetch	`C:WindowsPrefetch*.pf`	Ejecución confirmada, con contador y timestamps exactos
UserAssist	`NTUSER.DAT...ExplorerUserAssist`	Lanzamiento desde el Shell del Explorer por el usuario
ShellBags	`USRCLASS.DAT...ShellBagMRU / Bags`	Navegación del usuario por una carpeta o volumen concretos
Jump Lists	`...RecentAutomaticDestinations*.ms`	Ficheros abiertos recientemente con una aplicación concreta
LNK	`...Recent*.lnk`	Apertura de un fichero concreto, incluso ya borrado o en volumen extraíble
SRUM	`C:WindowsSystem32sruSRUDB.dat`	Consumo de red/CPU por aplicación, con granularidad horaria, semanas atrás

5. SRUM: actividad histórica cuando todo lo demás ha rotado

El System Resource Usage Monitor es un servicio que registra periódicamente (cada hora aprox.) el consumo de recursos por aplicación: bytes de red enviados/recibidos, tiempo de CPU en primer/segundo plano, energía. Se almacena en una base de datos ESE (Extensible Storage Engine, el mismo motor que usa Exchange):

C:WindowsSystem32sruSRUDB.dat

Su valor forense es enorme porque, a diferencia de Prefetch (que rota) o del Event Log (que puede haberse limpiado), SRUM puede conservar hasta 30-60 días de histórico de qué aplicaciones estuvieron activas y cuánto tráfico generaron, incluso si el ejecutable, el .pf y los logs de eventos ya no existen. Es la fuente que a menudo permite responder si una aplicación tuvo actividad de red la semana pasada cuando ya no queda ningún otro rastro. Se procesa con SrumECmd (parte de las EZ Tools):

SrumECmd.exe -f "C:rutaevidenciaSRUDB.dat" -r "C:rutaevidenciaSOFTWARE" --csv "C:salida"

El parámetro -r (hive SOFTWARE) es opcional pero recomendable: permite resolver los IDs de red de SRUM contra el Network List del registro para saber a qué perfil de red (doméstica, empresa, pública) correspondía cada sesión.

6. El sistema de ficheros NTFS: $MFT, $LogFile, $UsnJrnl y timestomping

6.1. La Master File Table ($MFT)

NTFS registra cada fichero y carpeta del volumen como un registro de 1024 bytes en la Master File Table, fichero de sistema oculto en la raíz del volumen:

C:$MFT

Cada registro contiene, entre otros, dos atributos con timestamps que son la clave de este apartado: $STANDARD_INFORMATION ($SI) y $FILE_NAME ($FN). Ambos guardan cuatro marcas de tiempo — de ahí el acrónimo MACB:

M — Modified (última modificación de contenido)
A — Accessed (último acceso de lectura — deshabilitado por defecto desde Windows Vista/Server 2008 vía NtfsDisableLastAccessUpdate, así que en sistemas modernos suele no ser fiable)
C — Changed (última modificación de metadatos del registro MFT; en $FN, muchas herramientas interpretan esta posición como Created — verificar siempre en qué atributo se está mirando)
B — Born/Created (fecha de creación del fichero)

La diferencia crítica entre ambos atributos:

	$STANDARD_INFORMATION ($SI)	$FILE_NAME ($FN)
Visible en	Explorer, PowerShell, `dir`, casi todas las APIs de usuario	Solo visible parseando el $MFT directamente
Quién puede modificarlo	Cualquier proceso en espacio de usuario con la API estándar (`SetFileTime`) — es lo que modifican herramientas de timestomping tipo timestomp.exe (Metasploit) o PowerShell	Solo el kernel NTFS, al crear/renombrar/mover el fichero — no es accesible desde APIs de usuario normales
Fiabilidad forense	Baja si se sospecha manipulación — es la que ve el usuario y la que un atacante altera	Alta — mucho más difícil de falsificar sin herramientas especializadas a nivel de kernel

6.2. Detección de timestomping

El patrón clásico de detección es comparar $SI vs $FN para el mismo fichero:

Fichero normal, no manipulado: $SI Created y $FN Created son iguales o están dentro de una ventana de segundos, y ambos son consistentes con el resto de ficheros creados en la misma operación (p. ej. una instalación que crea decenas de ficheros con timestamps agrupados).
Cuando hay timestomping: el atacante casi siempre solo modifica $SI (lo que ve el usuario/el analista con herramientas superficiales), dejando $FN con la fecha real. Si $SI Created es «2019-03-15» pero $FN Created es «2026-06-28» — la fecha real en que se soltó el malware —, hay una discrepancia flagrante, indicio directo de manipulación deliberada.
Otro patrón: $SI con fecha anterior a la instalación del propio SO, o con precisión de segundos exactos sin nanosegundos — las escrituras legítimas casi nunca caen en un segundo redondo, mientras que muchas herramientas de timestomping sí escriben timestamps «limpios».

Regla de oro para examen e informe pericial: nunca afirmar una fecha de creación basándose solo en $SI. Siempre comparar contra $FN, y correlacionar cuando sea posible con $LogFile y $UsnJrnl:$J, que registran el histórico de operaciones (no solo el estado final).

6.3. $LogFile y $UsnJrnl:$J

El $MFT solo muestra el estado actual de cada fichero. Para ver qué operaciones ocurrieron — incluidas las de ficheros ya borrados — se recurre a dos journals de NTFS:

$LogFile (C:$LogFile): journal transaccional de NTFS para recuperación ante fallos. Histórico muy detallado de operaciones de bajo nivel (creación, renombrado, cambios de atributo, truncado) en una ventana relativamente corta (típicamente horas o pocos días).
$UsnJrnl:$J (C:$Extend$UsnJrnl, stream $J): el Update Sequence Number Journal, que registra un resumen por evento (create, rename, data extend, security change) de cada cambio, con timestamp y reason code. Cubre una ventana más larga que $LogFile (semanas, según actividad).

Ambos son claves para reconstruir el timestomping incluso cuando el fichero ya no existe en el $MFT (borrado): por ejemplo, «creado 14:32:07, renombrado 14:32:09, timestamps modificados a las 14:32:15 (evidenciado por un registro USN_REASON_BASIC_INFO_CHANGE sin cambio de contenido), y ejecutado según Prefetch a las 14:33:01″ — una cronología que ninguna fuente por separado puede dar con esa granularidad.

Se procesan ambos, junto con el $MFT, con MFTECmd:

# $MFT completo, con parseo de $SI y $FN por separado
MFTECmd.exe -f "C:rutaevidencia$MFT" --csv "C:salida" --csvf mft.csv

# $LogFile (requiere el $MFT en la misma carpeta para resolver rutas)
MFTECmd.exe --lf "C:rutaevidencia$LogFile" -m "C:rutaevidencia$MFT" --csv "C:salida" --csvf logfile.csv

# $UsnJrnl:$J
MFTECmd.exe --csv "C:salida" --csvf usnjrnl.csv -f "C:rutaevidencia$UsnJrnl_$J" --de

La salida CSV de MFTECmd para el $MFT incluye ambos juegos de timestamps ($SI0/1/2/3 y $FN0/1/2/3, o etiquetados como Created0/Created1, etc. según versión) en la misma fila, lo que permite en Timeline Explorer aplicar un filtro o una columna calculada que resalte automáticamente cualquier fila donde $SI y $FN difieran en más de un margen razonable (p. ej. >1 minuto) — el primer indicador cuantitativo de timestomping en una máquina completa sin tener que revisarlo fichero a fichero.

7. Laboratorio: reconstruir la ejecución en la VM víctima

Objetivo: usando la VM víctima del curso (o cualquier VM de laboratorio con snapshot previo a un «incidente» simulado, p. ej. tras ejecutar un binario de prueba tipo EICAR o una herramienta de pentesting renombrada), reconstruir con evidencia cruzada qué se ejecutó, desde dónde y cuándo.

Adquisición selectiva. Sin apagar la VM (o desde una copia/snapshot), extrae con KAPE (u otro extractor con soporte VSS) los targets: RegistryHives, Prefetch, FileSystem (para $MFT/$LogFile/$UsnJrnl), Amcache, LNKFilesAndJumpLists, SRUM. Alternativa manual: copiar C:WindowsSystem32config{SYSTEM,SOFTWARE,SAM,SECURITY}, C:Users*NTUSER.DAT y USRCLASS.DAT, C:WindowsPrefetch*.pf, Amcache.hve, SRUDB.dat, y $MFT/$LogFile/$UsnJrnl.
Prefetch primero. Ejecuta PECmd.exe -d <carpeta_prefetch> --csv <salida> -q y abre el CSV en Timeline Explorer. Ordena por LastRun descendente y anota Run Count y las hasta 8 marcas de tiempo de ejecución del binario sospechoso.
Confirma existencia con Amcache. Ejecuta AmcacheParser.exe -f Amcache.hve --csv <salida> -i, localiza el binario en UnassociatedFileEntries, extrae el SHA-1 y compáralo contra VirusTotal.
Corrobora con ShimCache. Ejecuta AppCompatCacheParser.exe -f SYSTEM --csv <salida> y comprueba que la ruta aparece con un LastModified coherente con Prefetch/Amcache.
Contexto de usuario. Con RECmd/Registry Explorer sobre el NTUSER.DAT, busca en UserAssist si el binario se lanzó desde el Shell; con LECmd/JLECmd comprueba si hay un LNK o Jump List que apunte al mismo fichero o carpeta.
Verifica integridad temporal. Con MFTECmd, localiza el registro del binario y compara $SI vs $FN; si hay discrepancia, cruza con $LogFile/$UsnJrnl:$J para ver si hay un cambio de atributos sin cambio de contenido — indicio de timestomping.
Cronología final. Vuelca todos los CSV (Prefetch, Amcache, ShimCache, MFT, UserAssist, LNK) en Timeline Explorer o en un súper-timeline con log2timeline/plaso + Timesketch: creación del fichero → primera ejecución → ejecuciones posteriores → manipulación de timestamps detectada.
Repite el ejercicio cargando la imagen en Autopsy (módulo Recent Activity + Timeline) y compara cuánto automatiza frente al análisis manual con EZ Tools — es importante saber hacerlo a mano porque Autopsy no expone la comparación $SI/$FN con el mismo detalle que MFTECmd.

8. Errores comunes

Fiarse solo de $STANDARD_INFORMATION. $SI es trivialmente modificable desde espacio de usuario, así que cualquier conclusión sobre cuándo se creó un fichero que no haya cruzado con $FN (y a ser posible con $UsnJrnl) es débil ante un atacante medianamente competente.
Ignorar Amcache por considerarlo «redundante» con ShimCache. No lo es: Amcache aporta el hash SHA-1 (ShimCache no lo tiene desde hace años) y cubre escenarios donde ShimCache no se ha volcado aún al registro.
Confundir «última ejecución» con «única ejecución» o «todas las ejecuciones». Prefetch en Windows 8.1+ guarda hasta 8 timestamps, pero el Run Count puede ser mayor — el contador es acumulativo aunque el histórico detallado esté acotado.
Tratar ShimCache como prueba de ejecución sin matices, sobre todo en Windows 10, donde su fiabilidad como indicador ha cambiado respecto a Windows 7 — documentar siempre la versión de SO.
Olvidar que Prefetch puede estar deshabilitado (servidores, algunos SSD) y concluir «no se ejecutó nada» sin comprobar antes EnablePrefetcher en el registro.
No verificar la zona horaria. Estos artefactos almacenan sus timestamps en UTC (FILETIME); mezclar UTC con logs de aplicación en hora local sin normalizar es un error clásico de informe pericial.
Analizar un solo artefacto en vez de correlacionar. Ningún artefacto aislado sostiene por sí solo una conclusión: la robustez viene de que Prefetch, Amcache, ShimCache, UserAssist y el $MFT cuenten, de forma independiente, una historia coherente.

9. Ejercicio

Sobre la VM víctima (o un snapshot de laboratorio equivalente), un binario llamado svchost_update.exe se ejecutó desde C:UsersPublicDownloads. Se pide:

Extraer SYSTEM, SOFTWARE, el NTUSER.DAT del usuario implicado, Amcache.hve, la carpeta Prefetch completa y el $MFT.
Con PECmd, determinar el Run Count exacto y la fecha/hora de la última ejecución de svchost_update.exe.
Con AmcacheParser, obtener el hash SHA-1 del binario y documentar si el Publisher del PE está firmado o vacío (indicio adicional de sospecha).
Con AppCompatCacheParser, confirmar que la ruta C:UsersPublicDownloadssvchost_update.exe aparece en el ShimCache y anotar su LastModified.
Con RECmd sobre SOFTWARE y el NTUSER.DAT, comprobar si hay alguna entrada en Run/RunOnce que referencie el binario o una copia en otra ruta.
Con MFTECmd, extraer $SI y $FN del registro MFT del binario y determinar si hay evidencia de timestomping.
Redactar una cronología de 6-10 líneas, en UTC, integrando los hallazgos de los cinco artefactos, indicando qué conclusión aporta cada fuente y tu grado de confianza en «el usuario ejecutó deliberadamente este binario» frente a «se ejecutó de forma automatizada/por un tercero».

Preguntas frecuentes

¿Basta con Prefetch para demostrar que un ejecutable se ejecutó?

Prefetch es el artefacto más directo y granular (nombre, ruta de origen, contador de ejecuciones y hasta 8 timestamps desde Windows 8.1), pero no es infalible: puede estar deshabilitado (típico en servidores), tiene un límite de .pf almacenados y puede haberse eliminado manualmente. Por eso se corrobora siempre con Amcache y, cuando existan, con logs de eventos (Security 4688 o Sysmon Event ID 1), que sí incluyen usuario y proceso padre.

¿Por qué el ShimCache no siempre es prueba de ejecución?

El motor de compatibilidad puede evaluar y cachear un ejecutable simplemente porque el Explorer lo enumeró o el usuario hizo doble clic, sin que necesariamente se haya completado su ejecución en todos los casos y versiones. En Windows 7 la relación con la ejecución era más consistente; en Windows 10 se recomienda tratarlo como indicio de existencia/presencia, no de ejecución confirmada, salvo que se corrobore con Prefetch o Amcache.

¿Qué diferencia práctica hay entre $UsnJrnl:$J y $LogFile?

$LogFile es el journal transaccional interno de NTFS orientado a recuperación ante fallos (muy detallado pero con ventana corta, de horas a pocos días); $UsnJrnl:$J es un journal de más alto nivel con eventos resumidos por «reason code» y ventana habitualmente más larga. Se usan de forma complementaria: $UsnJrnl:$J para localizar cuándo ocurrió un evento relevante, $LogFile para el detalle fino alrededor de ese momento.

¿Es delito usar herramientas de timestomping como la de Metasploit en un examen o CTF?

No, siempre que se use en un entorno de laboratorio autorizado (VM propia, rango de prácticas, CTF legítimo). El delito no está en la herramienta sino en el contexto: aplicarla contra un sistema de terceros sin autorización es el escenario que este módulo enseña a detectar, no a explotar.

¿Qué hago si el $LogFile o el $UsnJrnl:$J parecen corruptos al parsear con MFTECmd?

Es habitual: ambos son estructuras circulares que Windows sobrescribe constantemente, y una adquisición en caliente puede capturar un journal a medio escribir. MFTECmd suele parsear los registros válidos y reportar los que no puede interpretar; documenta la limitación y apóyate en $MFT + Prefetch + Amcache para lo que el journal no cubra.

«Examine Prefetch files for evidence of execution… Amcache.hve should be examined for evidence of program execution… Compare $STANDARD_INFORMATION and $FILE_NAME timestamps to identify timestomping.» — SANS DFIR, Windows Forensic Analysis poster (FOR500), material de referencia de Eric Zimmerman Tools (documentación oficial en ericzimmerman.github.io).

Módulo 6: Forense de Windows I — artefactos de ejecución