Cuando se investigamos un equipo Windows, es tentador buscar primero los archivos “importantes”: documentos, correos, imágenes o ejecutables. Sin embargo, muchas de las respuestas que realmente permiten reconstruir lo ocurrido viven en lugares menos evidentes. El Registro de Windows conserva configuración y actividad histórica; los Event Logs registran acciones discretas con fecha, origen y contexto; y otros artefactos (como accesos directos, Jump Lists, Prefetch, Amcache o setupapi.dev.log) ayudan a unir piezas que por separado pueden ser ambiguas.

El punto central de una investigación no es encontrar un Event ID específico. Es reconstruir una secuencia y sostenerla con evidencia independiente. Que una memoria USB haya sido reconocida no significa que alguien copió información. Que el reloj haya cambiado no significa necesariamente que un atacante intentó alterar una línea de tiempo. Y que el Security log haya sido vaciado es muy relevante, pero todavía requiere identificar quién lo hizo, desde qué sesión y qué ocurrió antes y después.

Esta guía retoma busca dar con un enfoque senciallo informació para analizar hives, logs y adquisiciónde bitácoras a través del Visor de eventos. El objetivo es ubicar las fuentes principales, preservarlas y empezar a responder preguntas concretas sin convertir una pista en una conclusión prematura.

Regla forense: un artefacto indica; varios artefactos correlacionados permiten argumentar.

El Registro de Windows como fuente forense

El Registro es una base de datos jerárquica donde Windows y las aplicaciones almacenan configuración de sistema, cuentas, hardware, software y preferencias de usuario. En un sistema en ejecución solemos verlo a través de HKEY_LOCAL_MACHINE, HKEY_USERS o HKEY_CURRENT_USER. En una imagen forense, en cambio, lo que interesa son los archivos físicos que contienen esos datos.

Los hives de sistema más importantes se encuentran normalmente en C:\Windows\System32\Config. Allí aparecen SAM, SYSTEM, SOFTWARE, SECURITY y DEFAULT. Los perfiles de usuario agregan NTUSER.DAT y USRCLASS.DAT. Amcache.hve, por su parte, aporta información relacionada con aplicaciones y ejecución. En una adquisición correcta conviene preservar también los transaction logs asociados, porque pueden contener cambios todavía no consolidados en el hive principal.

Hive / archivo	Qué puede aportar	Preguntas típicas
SYSTEM	Hardware, servicios, control sets, zona horaria, USBSTOR.	¿Qué dispositivo estuvo conectado? ¿Qué zona horaria usaba el equipo?
SOFTWARE	Software instalado y configuración global.	¿Existía determinada aplicación o componente?
SAM	Cuentas y grupos locales.	¿Qué cuentas locales existían?
SECURITY	Políticas y secretos de seguridad locales.	¿Qué configuración de seguridad estaba vigente?
NTUSER.DAT	Actividad y preferencias de un usuario.	¿Qué archivos, ubicaciones o dispositivos aparecen vinculados al perfil?
USRCLASS.DAT	Shell, asociaciones y artefactos de interfaz.	¿Cómo interactuó el usuario con carpetas o elementos recientes?
Amcache.hve	Metadatos de aplicaciones y ejecutables observados por Windows.	¿Hay indicios de que un binario estuvo presente o fue registrado?

La utilidad del Registro no está en memorizar cientos de rutas. Está en reconocer qué pregunta estamos intentando contestar y seleccionar los hives apropiados. Para un posible exfiltrado por USB, por ejemplo, SYSTEM y NTUSER.DAT son particularmente importantes; para persistencia, SOFTWARE, SYSTEM y NTUSER.DAT suelen ser más relevantes; para identidad del equipo y configuración temporal, SYSTEM vuelve a ser una fuente central.

Event Viewer: el diario de acciones discretas

Windows Event Viewer es la interfaz gráfica para consultar los registros de eventos. Los archivos subyacentes usan formato EVTX y suelen almacenarse en C:\Windows\System32\winevt\Logs. Los canales clásicos —Security, System, Application y Setup— conviven con decenas de canales bajo Applications and Services Logs. Esa segunda zona es especialmente valiosa porque contiene fuentes más específicas, como DriverFrameworks-UserMode, PowerShell, Task Scheduler, Defender o Sysmon cuando éste se encuentra instalado.

Para análisis forense conviene separar dos conceptos. Event Viewer es una herramienta de visualización; la evidencia son los archivos EVTX y su contexto. En una imagen forense se deben extraer los EVTX originales y analizarlos de forma offline. En un equipo vivo, abrir Event Viewer o exportar registros implica interactuar con el sistema; por ello, cualquier adquisición en vivo debe estar documentada y ejecutarse bajo un procedimiento controlado.

No todos los eventos estarán disponibles: la presencia de un Event ID depende de la versión de Windows, la política de auditoría, el tamaño/retención del log y, en algunos canales, de que el registro haya sido habilitado previamente.

Cambio de hora: Event ID 4616

El Event ID 4616, “The system time was changed”, se registra cuando cambia la hora del sistema. Microsoft señala que normalmente se observan correcciones legítimas realizadas por el servicio de tiempo de Windows, con LOCAL SERVICE como sujeto y svchost.exe como proceso. Por eso, encontrar un 4616 no es equivalente a encontrar actividad maliciosa.

Su valor forense aparece cuando el cambio rompe la secuencia esperada. Un usuario interactivo que modifica la hora, un proceso inusual, un salto temporal grande o una modificación inmediatamente anterior a creación/borrado de archivos puede justificar una investigación más profunda. Es especialmente importante porque muchos artefactos se interpretan cronológicamente; si el reloj fue alterado, una línea de tiempo ingenua puede producir conclusiones erróneas.

Interpretación correcta: 4616 demuestra que Windows registró un cambio de hora. Para hablar de manipulación anti-forense hay que demostrar además intención o contexto mediante otras fuentes.

Vaciado del Security log: Event ID 1102

El Event ID 1102 indica que el registro de auditoría de seguridad fue borrado o vaciado. Es uno de los eventos que merece atención inmediata porque no existe una razón operativa frecuente para limpiar manualmente Security en una estación de trabajo. Microsoft recomienda investigar cada aparición y correlacionar el Logon ID con eventos de inicio de sesión, particularmente 4624.

Aquí la terminología importa. 1102 no significa que “se borró un evento” específico; significa que el Security audit log fue limpiado. Un atacante también podría intentar manipular archivos EVTX offline, impedir que se generen eventos, deshabilitar auditoría o aprovechar que el log haya sobreescrito registros antiguos por retención. Por eso, la ausencia de 1102 tampoco prueba que no haya existido anti-forense.

En una investigación real, el siguiente paso es identificar la cuenta y el Logon ID que aparecen en 1102, localizar el 4624 correspondiente y revisar qué procesos se ejecutaron alrededor de ese momento. Si existe telemetría externa —SIEM, EDR, Windows Event Forwarding o logs de dominio— puede conservar los eventos aun cuando el equipo local haya sido limpiado.

Inserción de USB: un evento no es suficiente

Para dispositivos externos, el Event ID 6416 de Security registra que el sistema reconoció un nuevo dispositivo externo cuando la auditoría de Plug and Play está disponible. El evento puede incluir identificadores que permiten reconocer clase, dispositivo y, en muchos casos, la instancia concreta. Es un punto de partida muy útil, pero su semántica es “el dispositivo fue reconocido”, no “el usuario copió información”.

Otra fuente útil es Microsoft-Windows-DriverFrameworks-UserMode/Operational. La literatura forense utiliza, entre otros, el Event ID 2003 para actividad asociada a la carga del controlador de un dispositivo y 2102 para eventos relacionados con el fin de la operación o desconexión. Este canal suele estar deshabilitado por defecto; por lo tanto, no debe asumirse que estará presente en cada imagen.

El Registro permite extender esa historia. En un sistema vivo, HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR conserva rastros de dispositivos de almacenamiento masivo USB, normalmente con vendor, product y una instancia que puede incluir el número de serie. En un hive SYSTEM analizado offline, CurrentControlSet no es una clave física: debe consultarse SYSTEM\Select para determinar qué ControlSet00x estaba activo. MountedDevices ayuda a relacionar volúmenes y letras de unidad; MountPoints2, dentro del perfil del usuario, puede aportar contexto de interacción; y C:\Windows\INF\setupapi.dev.log puede conservar información de instalación del dispositivo.

Punto crítico: 6416 o USBSTOR prueban presencia/reconocimiento del dispositivo; no prueban por sí solos qué archivos fueron copiados. Para eso se correlacionan LNK, Jump Lists, ShellBags, $MFT/$UsnJrnl, timestamps, archivos recientes y, cuando existe, telemetría EDR/DLP.

Otros Event IDs que conviene reconocer

Una investigación rara vez gira alrededor de tres eventos. Los siguientes identificadores son puntos de orientación frecuentes en Windows. Su disponibilidad depende de la configuración de auditoría y del canal correspondiente.

Event ID	Canal habitual	Qué indica	Uso forense
4624	Security	Inicio de sesión exitoso	Vincular cuenta, tipo de logon, origen y Logon ID.
4625	Security	Inicio de sesión fallido	Detectar intentos fallidos y patrones de autenticación.
4688	Security	Creación de proceso	Reconstruir ejecución; la línea de comandos requiere política adicional.
4616	Security	Cambio de hora	Detectar alteraciones temporales y validar la cronología.
1102	Security	Vaciado del audit log	Indicador relevante de borrado del Security log.
6416	Security	Dispositivo externo reconocido	Correlacionar PnP con USBSTOR y actividad de archivos.

Eventos de System y canales operacionales

Event ID	Canal habitual	Qué indica	Uso forense
7045	System	Servicio instalado	Útil para persistencia, herramientas administrativas y malware.
6005/6006	System	Inicio/parada del servicio Event Log	Ayuda a ubicar arranques, apagados y huecos de logging.
1074	System	Apagado/reinicio iniciado por usuario/proceso	Aporta quién/proceso/motivo según el evento.
2003/2102	DriverFrameworks-UserMode/Operational	Actividad de driver/dispositivo	Complemento para ventanas de conexión USB cuando el canal estaba habilitado.

Adquisición: preservar antes de interpretar

La evidencia pierde valor si no podemos explicar de dónde salió y qué hicimos con ella. En un análisis sobre una imagen forense, lo ideal es trabajar sobre una copia verificada y exportar los hives, sus transaction logs y los EVTX desde la imagen. En una adquisición en vivo deben anotarse hora, zona horaria, herramienta, versión, usuario que ejecutó la colección y hashes de los archivos resultantes cuando sea posible.

Para hives y Event Logs pueden utilizarse herramientas como FTK Imager, Autopsy o KAPE para la adquisición; Registry Explorer y RegRipper para Registro; y Event Viewer, EvtxECmd, Hayabusa o Chainsaw para análisis de EVTX. El principio no cambia: la interfaz usada para consultar no sustituye la preservación de los archivos fuente.

Artefacto	Ruta típica
Hives de sistema	C:\Windows\System32\Config\SAM, SYSTEM, SOFTWARE, SECURITY, DEFAULT
Perfiles	C:\Users\<usuario>\NTUSER.DAT y AppData\Local\Microsoft\Windows\USRCLASS.DAT
Amcache	C:\Windows\AppCompat\Programs\Amcache.hve
Event Logs	C:\Windows\System32\winevt\Logs\*.evtx
SetupAPI	C:\Windows\INF\setupapi.dev.log

Preservación: si el caso puede tener consecuencias legales o disciplinarias, documente cadena de custodia, origen, método de adquisición, hashes y cada transformación de la evidencia. Una captura de pantalla sirve para explicar; el EVTX o hive original es la evidencia que debe conservarse.

Cómo construir una línea de tiempo que sí sea defendible

Imaginemos un caso de posible extracción de información. A las 10:41 existe un 4624 que crea una sesión interactiva. A las 10:47 aparece 6416 con el número de serie de una memoria USB. Poco después, accesos directos y Jump Lists muestran documentos abiertos desde o hacia un volumen removible. A las 10:52 aparece 4616 con un cambio manual de hora y, cuatro minutos después, 1102 informa que Security fue vaciado.

La fuerza de esa hipótesis no proviene de 1102 por sí solo, ni de la memoria USB, ni del cambio de hora. Proviene de la coherencia temporal y de la independencia relativa de las fuentes. El investigador todavía tendría que revisar $MFT, $UsnJrnl, LNK, Jump Lists, artefactos de usuario, archivos recientes, la información del volumen y cualquier log externo. El objetivo no es contar una historia atractiva, sino intentar refutarla: si una explicación alternativa encaja mejor con los datos, la hipótesis inicial debe cambiar.

El USN Journal de NTFS: el historial de cambios del sistema de archivos

Los Windows Event Logs cuentan acciones que distintos componentes del sistema decidieron registrar. NTFS conserva otro tipo de memoria: el Update Sequence Number Journal o USN Journal. No es un registro de auditoría de usuarios, sino una estructura del sistema de archivos diseñada para que Windows y las aplicaciones sepan qué archivos y directorios han cambiado sin volver a recorrer todo el volumen. Para el investigador, esa función operativa se convierte en una fuente excepcional para reconstruir actividad sobre archivos.

En un volumen NTFS, el journal se encuentra en el metafile oculto $Extend\$UsnJrnl. El flujo alterno $UsnJrnl:$J contiene los registros de cambios y $UsnJrnl:$Max conserva parámetros y metadatos del journal. Cada registro puede incluir el nombre del archivo o directorio, la marca de tiempo, el File Reference Number (FRN), el FRN del directorio padre, atributos y uno o varios códigos USN Reason que describen la naturaleza del cambio.

Qué registra y por qué es útil

El USN Journal permite observar el ciclo de vida de un archivo: creación, crecimiento o sobrescritura de datos, cambios de atributos, renombrados y borrado. Una sola acción del usuario puede producir varios registros. Por ejemplo, guardar un documento puede generar DATA_EXTEND o DATA_OVERWRITE y terminar con CLOSE; un renombrado suele producir un registro RENAME_OLD_NAME seguido de RENAME_NEW_NAME. Por eso el análisis debe interpretar secuencias, no filas aisladas.

USN Reason	Código	Interpretación forense típica
FILE_CREATE	0x00000100	Creación inicial de un archivo o directorio.
FILE_DELETE	0x00000200	El archivo o directorio fue eliminado de su ubicación.
RENAME_OLD_NAME	0x00001000	Nombre anterior dentro de una operación de renombrado.
RENAME_NEW_NAME	0x00002000	Nombre nuevo dentro de la misma operación de renombrado.
DATA_OVERWRITE	0x00000001	Datos existentes fueron sobrescritos.
DATA_EXTEND	0x00000002	Se agregaron datos al archivo.
DATA_TRUNCATION	0x00000004	El contenido fue truncado.
SECURITY_CHANGE	0x00000800	Cambio en permisos o información de seguridad.
BASIC_INFO_CHANGE	0x00008000	Cambio de atributos o determinados timestamps/metadata.
CLOSE	0x80000000	El handle fue cerrado; suele aparecer combinado con otras razones.

La presencia de FILE_DELETE es especialmente valiosa porque el registro puede seguir existiendo después de que el archivo ya no aparezca en el directorio. Sin embargo, el journal tiene un tamaño finito: cuando alcanza su límite, NTFS descarta registros antiguos. Tampoco debe confundirse con un registro de lectura de archivos. Abrir un documento solamente para leerlo puede no generar un cambio relevante y, por tanto, no dejar una entrada que demuestre ese acceso.

Cómo verlo con NTFS Journal Viewer

NTFS Journal Viewer, de E5h Forensic Solutions, es una herramienta portable que extrae y analiza $UsnJrnl. Su interfaz permite procesar cientos de miles de registros, buscar o filtrar resultados y exportarlos a CSV. El extractor integrado se basa en ExtractUsnJrnl.exe, desarrollado por Joakim Schicht.

· Trabajar preferentemente sobre una copia forense o sobre un volumen montado en modo de sólo lectura. En un laboratorio con sistema vivo, documentar que la propia adquisición puede producir cambios adicionales.

· Abrir JournalViewer.exe. Si se extrae desde un volumen accesible, utilizar el botón “$J”, seleccionar la unidad NTFS —por ejemplo C:— y ejecutar la extracción. La herramienta puede generar un archivo como $UsnJrnl_$J.bin.

· Si el flujo $J ya fue extraído desde una imagen forense con FTK Imager u otra herramienta, utilizar “Open File” para cargar el archivo obtenido, evitando volver a tocar el volumen original.

· Revisar primero Timestamp, File Name, USN Reason, MFT Reference y Parent MFT Reference. El FRN permite vincular eventos pertenecientes al mismo registro de la MFT incluso cuando el nombre cambió.

· Usar la búsqueda para términos relevantes —nombre de archivo, extensión o fragmentos conocidos— y después ampliar unos segundos o minutos alrededor del hallazgo para observar la secuencia completa.

· Exportar los resultados relevantes a CSV y conservar tanto el archivo $J original como el resultado parseado, registrando hashes y herramienta/versión cuando el análisis vaya a formar parte de un expediente.

Leer una secuencia, no un registro aislado

Supongamos que la búsqueda muestra FILE_CREATE para Informe_confidencial.xlsx a las 10:48:02, DATA_EXTEND y CLOSE inmediatamente después, RENAME_OLD_NAME y RENAME_NEW_NAME a las 10:50:17, DATA_OVERWRITE a las 10:53 y FILE_DELETE a las 11:02. Si los registros de renombrado conservan el mismo MFT Reference, la interpretación razonable es que se trata del mismo objeto que cambió de nombre y posteriormente fue eliminado. El journal permite reconstruir esa historia aun cuando el nombre final ya no exista en el sistema de archivos visible.

Ahora correlacionemos esa secuencia con el ejemplo USB anterior. Si Security registra un 6416 a las 10:47 y el USN Journal muestra actividad sobre archivos sensibles inmediatamente después, existe proximidad temporal, pero todavía no podemos afirmar que esos archivos fueron copiados al USB. Copiar un archivo desde C: hacia una memoria puede implicar principalmente lectura del archivo fuente, y el journal del volumen C: no es un registro general de lecturas. Para sostener una hipótesis de exfiltración hay que sumar LNK, Jump Lists, Shellbags, MountedDevices/USBSTOR, timestamps y artefactos del volumen destino cuando éste esté disponible.

Límites y cautelas del USN Journal

· Sólo aplica a volúmenes NTFS. Una memoria formateada en FAT32 o exFAT no ofrece un USN Journal NTFS que analizar.

· El journal rota. Un sistema con alta actividad puede conservar una ventana temporal mucho menor que un equipo poco utilizado.

· Puede eliminarse y recrearse. Una ventana sospechosamente reciente debe investigarse y correlacionarse con otros artefactos; la ausencia de entradas antiguas no demuestra ausencia de actividad.

· Un USN Reason describe qué cambio observó NTFS, no quién lo realizó ni con qué intención. La atribución requiere sesión, proceso, usuario y evidencia adicional.

· El nombre registrado y el Parent FRN pueden necesitar correlación con $MFT para reconstruir la ruta completa, especialmente si los directorios o archivos fueron renombrados o eliminados.

En términos prácticos, el USN Journal ocupa un espacio intermedio muy útil entre Event Viewer y la $MFT: Event Viewer aporta eventos de subsistemas y contexto de seguridad; la $MFT describe el estado y metadatos de los objetos; $UsnJrnl aporta una secuencia de cambios. Cuando los tres cuentan una historia compatible, la línea de tiempo gana mucha más fuerza.

Una rutina de análisis para principiantes

Una forma práctica de evitar saltos lógicos es trabajar siempre en el mismo orden:

· Identificar el sistema: versión de Windows, nombre del equipo, zona horaria, usuarios y periodo relevante.

· Preservar fuentes: hives, transaction logs, EVTX, setupapi.dev.log y artefactos de usuario que puedan responder la pregunta.

· Normalizar el tiempo: documentar UTC/local, zona horaria y cualquier Event ID 4616 que pueda alterar la secuencia.

· Buscar eventos pivote: autenticación, procesos, dispositivos, cambios de configuración, servicios y limpieza de logs.

· Correlacionar: nunca convertir “presencia” en “acción” sin una segunda fuente que lo sustente.

· Documentar ausencia y limitaciones: canal deshabilitado, log sobreescrito, huecos de colección o políticas no configuradas también son hallazgos metodológicos.

Lo que un Event ID puede probar —y lo que no

En forense digital, la precisión semántica importa. Un evento es un registro generado por un componente bajo ciertas condiciones. No es una declaración universal sobre la intención humana. El 6416 dice que Windows reconoció un dispositivo externo; no identifica necesariamente quién lo insertó físicamente. El 4616 dice que cambió el tiempo; puede ser una corrección legítima. El 1102 dice que Security fue vaciado; puede ser una acción administrativa autorizada, aunque normalmente deba investigarse.

Esta disciplina evita uno de los errores más comunes de los análisis rápidos: confundir correlación con atribución. La atribución a una persona requiere vincular sesión, credenciales, actividad de usuario, contexto físico y otros elementos. Incluso un 4624 sólo demuestra que una sesión fue creada con una cuenta; no demuestra, por sí solo, quién estaba frente al teclado.

Conclusión

El Registro y los Windows Event Logs funcionan mejor juntos. El Registro aporta persistencia histórica y contexto estructural: qué hardware conoció el sistema, qué cuentas y configuraciones existían, qué rutas y preferencias quedaron registradas. Los EVTX aportan eventos discretos: cuándo se creó una sesión, cuándo Windows reconoció un dispositivo, cuándo se alteró el reloj o cuándo se vació Security. Otros artefactos rellenan el espacio entre ambos.

Para un principiante, el salto más importante no es memorizar claves ni Event IDs. Es aprender a formular una pregunta, elegir fuentes que puedan responderla y exigir corroboración antes de afirmar algo. En ese momento el Visor de eventos deja de ser una lista interminable de mensajes y el Registro deja de ser un árbol de claves: ambos se convierten en piezas de una reconstrucción forense.

Referencias y lecturas recomendadas

Microsoft Learn — Event 4616: The system time was changed: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4616

Microsoft Learn — Event 1102: The audit log was cleared: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-1102

Microsoft Learn — Event 6416: A new external device was recognized by the System: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-6416

Microsoft Learn — Event 4688: A new process has been created: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4688

Chowdhury et al. — USB Artifact Analysis Using Windows Event Viewer, Registry and File System Logs, Electronics 8(11), 1322: https://doi.org/10.3390/electronics8111322

Forenza — USBStor Device History: Forensic Analysis of USB Mass-Storage Enumeration in the SYSTEM Hive: https://forenza.io/registry-system-usb-storage/

E5h Forensic Solutions — NTFS Journal Viewer: https://e5hforensics.com/index.php/downloads/software/ntfs-journal-viewer/

Microsoft Learn — Change journal operations: https://learn.microsoft.com/en-us/windows/win32/fileio/change-journal-operations

Microsoft Learn — READ_USN_JOURNAL_DATA / USN reason flags: https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-read_usn_journal_data_v1

Buscar este blog

Blog de Pablo Corona

Intestigación forense en el registro de windows, journal NTFS y visor de eventos