Manipulación de marcas de tiempo, borrado de registros y datos ocultos

La lección 7.1 trató sobre la destrucción de datos. Esta lección aborda tres formas de engañar a un examinador en lugar de destruirlos: cambiar las marcas de tiempo, borrar o editar registros y ocultar datos. Cada una deja una discrepancia entre fuentes que registran el mismo evento de forma independiente; el trabajo del examinador consiste en encontrarla, medirla e indicar con qué solidez respalda la existencia de una manipulación.

Manipulación de marcas de tiempo

La manipulación de marcas de tiempo (timestomping) consiste en cambiar las marcas de tiempo de un archivo para que pase desapercibido o parezca más antiguo. La mayoría de las herramientas solo cambian los valores de $STANDARD_INFORMATION ($SI), mediante SetFileTime (creación, acceso, modificación) o NtSetInformationFile con la clase FileBasicInformation (los cuatro, incluida la hora de modificación de la entrada de la MFT). Ninguna de estas operaciones requiere derechos de administrador, y $FILE_NAME ($FN) es más difícil de falsificar (lección 3.2). Algunas técnicas publicadas también hacen coincidir $FN combinando cambios en $SI con un cambio de nombre o un movimiento dentro del volumen, durante el cual NTFS copia los valores de $SI al nuevo $FN. Esto puede producir valores coincidentes en $SI y $FN, pero añade registros de cambio de nombre al diario.

Detección por capas

Ninguna comprobación por sí sola es concluyente, porque las herramientas de archivado, los instaladores y los clientes de sincronización también establecen marcas de tiempo. Aplique las comprobaciones por capas e informe de cuántas coinciden.

1. $SI frente a $FN. Un valor $SI B anterior a $FN B, o un $SI C que no corresponde a ninguna operación, es el primer indicio.
2. Fracciones de segundo iguales a cero. Un FILETIME cuenta intervalos de 100 nanosegundos, por lo que una hora genuina solo corresponde a un segundo exacto aproximadamente una vez entre diez millones. Varias herramientas escriben segundos enteros. Las más recientes aleatorizan la fracción, por lo que una fracción distinta de cero no demuestra nada.
3. Entradas vecinas de la MFT. Los números de entrada indican un orden de creación aproximado, porque la $MFT crece a medida que se añaden archivos. Una entrada cuyas vecinas se crearon todas en un mismo día, pero cuyo $SI indica una fecha de años antes, es sospechosa. Las entradas liberadas se reutilizan, por lo que esto solo sirve como apoyo a otros hallazgos.
4. Anterior al sistema. Compare $SI B con InstallDate (que se restablece con las actualizaciones de características) y con el $SI B de los archivos de metadatos del propio volumen, como $MFT (entrada 0) y $Volume (entrada 3), que normalmente registran cuándo se formateó el volumen. Los archivos copiados o extraídos pueden conservar horas anteriores, pero sus valores $SI C y $FN muestran entonces su llegada.
5. $UsnJrnl. Establecer las marcas de tiempo escribe un registro con BASIC_INFO_CHANGE (0x00008000) para el número de referencia del archivo, con la marca de tiempo del reloj en el momento real del cambio. El indicador también abarca cambios de atributos, por lo que debe interpretarse junto con los valores $SI. Las herramientas de copia y extracción suelen establecer las marcas de tiempo mientras el archivo sigue abierto, en la misma ráfaga que FILE_CREATE; una ráfaga independiente posterior es más reveladora. Los registros de cambio de nombre junto a ella apuntan a la técnica de $FN.
6. $LogFile. Una operación UpdateResidentValue sobre el atributo $SI contiene las marcas de tiempo antiguas en sus datos de deshacer y las nuevas en sus datos de rehacer, si el registro aún abarca ese momento (de minutos a horas).
7. Otros artefactos que registraron el archivo. Un archivo LNK conserva las horas de creación, acceso y modificación de $SI del destino, tal como estaban cuando se escribió el enlace, en los desplazamientos 0x1C, 0x24 y 0x2C del encabezado (lección 2.4). Prefetch, Amcache y las listas de salto muestran cuándo se utilizó el archivo. Si todas las referencias datan de 2026, una hora de creación de 2019 queda sin respaldo.
8. Marcas de tiempo internas. El TimeDateStamp de un archivo PE (segundos Unix en el encabezado COFF, en el desplazamiento e_lfanew + 8; mostrado como LinkDate por los analizadores de Amcache) no puede ser lógicamente posterior a la creación del archivo. Los metadatos de documentos, como dcterms:created en archivos de Office (pestaña Detalles del Explorador), funcionan del mismo modo. Ambos pueden falsificarse, y las compilaciones deterministas colocan un hash en lugar de una hora en TimeDateStamp.

La manipulación del reloj es diferente

En lugar de lo anterior, alguien puede atrasar el reloj del sistema, crear el archivo y restaurar el reloj. Entonces $SI, $FN, los registros USN y los registros de eventos contienen todos la hora falsa, con fracciones de segundo normales. Los indicios son los de la lección 3.5: el evento 1 de Kernel-General en Sistema (OldTime, NewTime) y el evento 4616 de Seguridad (PreviousTime, NewTime), y números de secuencia (USN, EventRecordID) que aumentan mientras las horas retroceden. La manipulación de marcas de tiempo desplaza un atributo; los cambios del reloj desplazan todo lo escrito durante ese intervalo.

Borrado de registros

Windows

Al borrar el registro de Seguridad se escribe el evento 1102 de Seguridad ("Se borró el registro de auditoría") como primer registro del nuevo registro de eventos; al borrar cualquier otro registro se escribe el evento 104 de Sistema, que identifica el canal. Ambos proceden del proveedor Microsoft-Windows-Eventlog y registran SubjectUserName, SubjectDomainName y, en el caso de 1102, SubjectUserSid y SubjectLogonId. Borrar Seguridad requiere el derecho "Administrar los registros de auditoría y seguridad", que los administradores tienen de forma predeterminada.

Identifique también el medio utilizado: wevtutil cl <log> deja un archivo Prefetch de WEVTUTIL.EXE en las ediciones de cliente, y un evento 4688 si se audita la creación de procesos (con la línea de comandos solo si también está habilitado su registro); Clear-EventLog aparece en el evento 4104 de PowerShell/Operational cuando está habilitado el registro de bloques de scripts, y en ConsoleHost_history.txt.

Otros indicios de manipulación:

• EventRecordID. Un registro borrado reinicia la numeración en 1. Un registro que ha sobrescrito normalmente los eventos más antiguos comienza con un número mayor y no tiene discontinuidades internas, por lo que un salto dentro de un mismo archivo requiere una explicación.
• Cobertura temporal y tamaño. Un registro de Seguridad que comienza minutos antes del incidente en un sistema utilizado durante meses, o un archivo muy por debajo de su MaxSize, es compatible con un borrado reciente. También son relevantes los periodos sin registros mientras otras fuentes muestran actividad.
• Eliminación selectiva. Algunas herramientas eliminan u ocultan registros individuales reescribiendo el archivo. Busque discontinuidades en los ID, errores de suma de comprobación CRC32 en los encabezados del archivo o de los bloques, y registros que los analizadores indiquen como ocultos o dañados. Trátelos como indicios.
• Manipulación del servicio y de las directivas. El evento 1100 de Seguridad ("El servicio de registro de eventos se ha apagado") y el 6006 de Sistema (servicio de registro de eventos detenido) son normales durante el apagado; sin un arranque posterior (6005), sugieren que se detuvo el servicio. El evento 4719 de Seguridad registra un cambio en la directiva de auditoría. Las técnicas que suspenden el registro en memoria no escriben nada; solo las lagunas respecto a otras fuentes las ponen de manifiesto.

Los registros borrados suelen poder recuperarse: copias anteriores en instantáneas de volumen (lección 2.9), bloques ElfChnk de 64 KB recuperados mediante carving del espacio no asignado, de pagefile.sys o de hiberfil.sys (con EVTXtract, por ejemplo), y copias reenviadas a un recolector o SIEM.

Linux

Compare fuentes que registren los mismos eventos (lección 6.4). Un /var/log/auth.log truncado, o al que le falten líneas de sesión que journalctl aún muestra para sshd, indica edición. Cada registro wtmp ocupa 384 bytes en Linux x86-64; utmpdump /var/log/wtmp muestra un registro puesto a cero como tipo 0 con una hora de 1970 (en sistemas que usan wtmpdb en su lugar, examine /var/lib/wtmpdb/wtmp.db, lección 6.4), y un registro eliminado como un inicio de sesión sin su cierre de sesión o una laguna en la secuencia de arranques. journalctl --verify informa de archivos de diario dañados; los mensajes de "dañado o cerrado de forma incorrecta" y los archivos .journal~ suelen tener causas inocuas. Los nombres de los archivos de diario archivados contienen el número de secuencia de su primera entrada, por lo que un archivo ausente en medio de la serie se manifiesta como una discontinuidad; la depuración normal solo elimina los más antiguos. La lección 6.3 aborda técnicas relacionadas con el historial del shell, como desactivar HISTFILE.

Datos ocultos

• Flujos de datos alternativos (lección 1.4). Cualquier flujo distinto de Zone.Identifier y de los flujos conocidos del sistema merece una revisión. MFTECmd (HasAds, IsAds), istat y dir /r los enumeran; añadir uno escribe STREAM_CHANGE.
• Extensión frente a firma. Compare los primeros bytes con la extensión: 4D 5A (MZ) corresponde a un archivo PE, 50 4B 03 04 a un contenedor ZIP (incluido .docx), 25 50 44 46 (%PDF) a un PDF y FF D8 FF a un JPEG. El módulo de discrepancias de extensión de Autopsy y file automatizan esta tarea.
• Espacio residual y espacio no asignado (lección 1.2). Un espacio residual de RAM distinto de cero en un volumen NTFS moderno, o datos estructurados distribuidos por muchas áreas de espacio residual, sugieren una colocación deliberada.
• Particiones ocultas y huecos (lección 1.1). Compare la tabla de particiones con el tamaño del disco y busque espacio sin particionar más allá de la alineación normal de 1 MiB. En GPT, los bits de atributo 62 (oculto) y 63 (sin letra de unidad) ocultan las particiones de datos básicos del Explorador.
• Esteganografía. Las pruebas estadísticas (chi-cuadrado o análisis RS de los bits menos significativos) en herramientas como StegExpose o zsteg señalan imágenes sospechosas, con falsos positivos. Los datos añadidos después de FF D9 en un JPEG o de IEND en un PNG, o la presencia de software de esteganografía en artefactos de ejecución, suelen ser mejores indicios.
• Contenedores cifrados disfrazados de archivos. Una entropía de Shannon cercana a 8,0 bits por byte, sin encabezado reconocible y con un tamaño que sea un múltiplo exacto de 512 bytes, es compatible con un contenedor (lección 7.3). Los formatos comprimidos también presentan valores altos, pero comienzan con una firma.
• Atributos y nombres. Los atributos Oculto y Sistema, los nombres de Unix que comienzan con un punto, los nombres que imitan archivos del sistema en una carpeta incorrecta, el carácter de anulación de derecha a izquierda U+202E y las subcarpetas de $Recycle.Bin con nombres de SID que no existen en la clave ProfileList.

Ejemplo resuelto: svc.dll y un registro de Seguridad borrado

La recopilación de triaje del portátil de ana muestra esta entrada de la MFT:

Comprobación de fracciones de segundo. El valor $SI es 132.073.632.000.000.000 (bytes 00 40 8E BF 44 38 D5 01). Dividido entre 10.000.000 da 13.207.363.200 segundos, con resto 0. El valor $FN 134.179.718.913.301.447 ÷ 10.000.000 = 13.417.971.891 con resto 3.301.447, es decir, 0,3301447 s. La diferencia, 2.106.086.913.301.447 intervalos o 210.608.691,33 s, es de 2.437 días 14 h 24 min 51,33 s.

Razonamiento. $SI B es 6 años y 8 meses anterior a $FN B y anterior al formateo del volumen; tiene fracciones de segundo iguales a cero; las entradas vecinas se crearon cuatro segundos antes y 35 segundos después de la hora de $FN; y el diario registra un cambio de marcas de tiempo en una ráfaga independiente 12 segundos después de la creación, sin cambio de nombre. $LogFile había sobrescrito los datos antiguos y ya no abarcaba las 14:25. La afirmación defendible es que el nombre svc.dll se creó en este volumen a las 2026-03-14T14:24:51Z, y que sus marcas de tiempo $SI se establecieron en 2019-07-12T00:00:00Z aproximadamente a las 14:25:03Z, lo que es compatible con una manipulación de marcas de tiempo. El diario no muestra quién lo hizo.

El registro. Security.evtx comienza con EventRecordID 1, un evento 1102 a las 2026-03-14T14:38:55Z con SubjectUserName ana y SubjectUserSid S-1-5-21-…-1001. La cuenta de ana borró el registro de Seguridad 13 min 52 s después del cambio de marcas de tiempo, y esa cuenta tenía el derecho necesario para hacerlo. Cualquier evento 4616 de cambio de hora se perdió con él, por lo que debe comprobarse el evento 1 de Kernel-General en Sistema antes de confiar en la hora 14:25:03Z del diario; no hay ninguno. A continuación: Prefetch de WEVTUTIL.EXE, 4104, instantáneas de volumen y bloques recuperados mediante carving.

Técnica, detección y confianza

La confianza se refiere a la manipulación; determinar quién la realizó requiere pruebas independientes, como inicios de sesión y artefactos de ejecución.

Enfoque del examen: Se espera que pueda informar de la hora real de llegada de un archivo a partir de $FN o del diario cuando $SI esté falsificado, y de la hora del cambio a partir de un registro BASIC_INFO_CHANGE. Prepárese para comprobar las fracciones de segundo de un FILETIME sin procesar y para interpretar los eventos 1102 o 104 a fin de determinar quién borró qué registro y cuándo. Las preguntas pueden pedirle que distinga entre la manipulación de marcas de tiempo y un cambio del reloj, o que indique dónde se pueden recuperar los registros borrados.

Puntos clave

• La manipulación de marcas de tiempo suele cambiar solo $SI; compárelo con $FN, las fracciones de segundo, las entradas vecinas de la MFT, la creación del volumen, $UsnJrnl, $LogFile, LNK y las marcas de tiempo internas, y cuente cuántos coinciden.
• BASIC_INFO_CHANGE registra la hora real en que se establecieron las marcas de tiempo o los atributos; una ráfaga independiente posterior a la creación es un indicio más sólido que una dentro de ella.
• Un cambio del reloj desplaza todos los artefactos a la vez y deja Kernel-General 1 o 4616; la manipulación de marcas de tiempo desplaza un atributo.
• 1102 (Seguridad) y 104 (Sistema) identifican la cuenta que borró un registro; los ID de registro se reinician en 1, y los registros antiguos pueden conservarse en instantáneas de volumen, bloques recuperados mediante carving y copias reenviadas.
• En Linux, compare los registros de texto con el diario, lea wtmp con utmpdump y compruebe los números de secuencia del diario.
• Los datos ocultos se manifiestan a través de la estructura: atributos $DATA adicionales, discrepancias de firma, espacio residual inusual, espacio sin particionar y archivos de alta entropía sin encabezados.