Errores de zona horaria y del reloj

Una marca de tiempo puede decodificarse perfectamente y aun así ser incorrecta: puede haberse almacenado en hora local y presentado como UTC, convertido con las reglas actuales en lugar de las vigentes ese día, desplazado por la herramienta del analista o registrado con un reloj que tenía un error de minutos o años. Esta lección muestra qué fuentes almacenan UTC y cuáles almacenan hora local, cómo convertir valores locales y cómo medir, documentar y corregir un error del reloj de un dispositivo. El módulo 7 aborda la manipulación deliberada del reloj; aquí el objetivo es interpretar correctamente las marcas de tiempo no manipuladas.

Tres relojes en cada caso

Distinga tres relojes en sus notas:

1. Hora real (UTC): cuándo ocurrió realmente el evento. Esto es lo que debe indicar su informe.
2. El reloj del sistema del dispositivo: la hora que el equipo creía que era. Los artefactos registran este reloj, nunca la hora real. Si estaba adelantado 7 minutos, cada marca de tiempo que escribió es 7 minutos posterior a la hora real.
3. El reloj de visualización: cómo muestra una herramienta un valor en la estación de trabajo del analista. El Visor de eventos, por ejemplo, muestra las horas de EVTX almacenadas en UTC en la zona del equipo donde se visualizan.

Los errores surgen al confundirlos.

Fuentes UTC y fuentes de hora local

Dos formatos se sitúan entre ambos grupos. exFAT almacena la hora local más un byte de desplazamiento UTC por marca de tiempo, que solo se puede utilizar cuando su bit de validez está activado (lección 1.5). EXIF 2.31 y versiones posteriores pueden añadir OffsetTimeOriginal, como -03:00. Un registro de texto que escribe un desplazamiento, como [14/Mar/2026:09:21:07 -0300] de Apache, tampoco es ambiguo. Sin un marcador de este tipo, suponga que se trata de hora local y averigüe de quién: del equipo o de una cámara que nunca se configuró.

El reloj de tiempo real del hardware (RTC) añade una dificultad: Windows lo mantiene en hora local de forma predeterminada y la mayoría de las distribuciones Linux, en UTC, por lo que un equipo con arranque dual puede presentar un error igual al desplazamiento de la zona hasta que se resincronice.

Conversión de hora local a UTC

Windows almacena los desplazamientos como un sesgo en minutos, con el signo opuesto al de la notación habitual «UTC−3»: sesgo = −(desplazamiento UTC), y UTC = hora local + sesgo. UTC−3 tiene un sesgo de +180; UTC+1 tiene −60. Durante el horario de verano (DST), el sesgo vigente es Bias + DaylightBias (normalmente −60), por lo que el horario de verano de Europa Central es −60 + (−60) = −120. La lección 2.2 muestra dónde se encuentran estos valores en TimeZoneInformation.

Horas inexistentes y repetidas

En una transición del horario de verano, la hora local salta. En Europa Central, el 2026-03-29 los relojes pasaron de 01:59:59 CET a 03:00:00 CEST, por lo que las horas locales de 02:00 a 02:59 no existen ese día. El 2026-10-25 pasaron de 02:59:59 CEST de nuevo a 02:00:00 CET, por lo que cada hora local de 02:00 a 02:59 ocurrió dos veces, una en UTC+2 y otra en UTC+1. Una línea de registro en hora local a las 02:30 de ese día presenta una ambigüedad de una hora. Resuélvala a partir de las entradas adyacentes o de una fuente UTC e indique cómo lo hizo.

Use la regla vigente en la fecha del evento

ActiveTimeBias describe el momento en que se escribió la clave por última vez, no la fecha de su evento. Las reglas de zona horaria también cambian por ley. Brasil abolió el horario de verano en 2019; su último período de horario de verano terminó el 2019-02-17. Un equipo de Brasília adquirido en 2026 muestra un ActiveTimeBias de 180, pero una línea de registro local del 2018-12-10 10:00 se escribió en UTC−2 y corresponde a 12:00Z, no a 13:00Z. Convierta cada valor con las reglas de su propia fecha, utilizando una base de datos de zonas horarias actualizada (la base de datos tz de IANA) o las reglas por año que Windows conserva en SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone>\Dynamic DST.

Nunca deje que una herramienta elija su zona horaria

Muchas herramientas aplican silenciosamente la zona de la estación de trabajo del analista:

• Configure la estación de trabajo de análisis en UTC, para que recurrir a la hora «local» no cause problemas.
• En Plaso, indique explícitamente la zona de salida: psort.py --output_time_zone UTC. Cuando se analicen fuentes de hora local, como volúmenes FAT, proporcione la zona del dispositivo con log2timeline.py --timezone (lección 3.3).
• En las herramientas con interfaz gráfica, compruebe los ajustes de visualización. Las opciones de vista de Autopsy permiten elegir la zona horaria utilizada para la visualización. Timeline Explorer muestra las marcas de tiempo del CSV que abre, por lo que debe generar ese CSV en UTC y configurar su formato de fecha para mostrar segundos y fracciones. Después, compruebe una fila frente a un valor decodificado manualmente.
• Las hojas de cálculo son peligrosas. Excel convierte el texto con apariencia de fecha en números de serie que no incluyen zona horaria, oculta los segundos y las fracciones en su formato de visualización predeterminado y puede interpretar el día y el mes en orden inverso con algunas configuraciones regionales. Importe las columnas de marcas de tiempo como texto.

Desfase y deriva del reloj

El desfase es la diferencia entre el reloj del dispositivo y la hora real en un momento dado. La deriva es la velocidad a la que cambia esa diferencia. Un reloj de cuarzo que funciona sin sincronización y tiene un error de 20 partes por millón gana o pierde unos 1,7 segundos al día (20 × 10⁻⁶ × 86.400 s), por lo que un dispositivo sin sincronizar puede acumular minutos de error al cabo de unos meses. La sincronización corrige el reloj mediante un ajuste gradual (haciéndolo funcionar un poco más rápido o más lento hasta que coincida) o mediante un salto inmediato. Solo los saltos dejan un registro de «cambio de hora».

Medición del desfase

Compare el reloj del dispositivo con una referencia de confianza:

• Registros de sincronización NTP. Los eventos del proveedor Microsoft-Windows-Time-Service en el registro System muestran la sincronización: el evento 35 identifica la fuente de hora con la que se está sincronizando el servicio y el evento 37 indica que el proveedor NtpClient está recibiendo datos de hora válidos. Demuestran que la sincronización funcionaba, no la magnitud de una corrección.
• Evento 1 de Kernel-General (proveedor Microsoft-Windows-Kernel-General, registro System): registra un cambio de hora del sistema con OldTime y NewTime, ambos en UTC. La diferencia es la magnitud del salto.
• Evento 4616 de Security, «Se cambió la hora del sistema»: se registra cuando está habilitada la subcategoría de auditoría Cambio de estado de seguridad. Añade PreviousTime, NewTime, la cuenta y el proceso. Las correcciones rutinarias del servicio de hora de Windows suelen mostrar la cuenta LOCAL SERVICE; un cambio realizado mediante el proceso de un usuario merece atención.
• Marcas de tiempo del lado del servidor escritas por un reloj sincronizado sobre la misma acción: los encabezados Received: que añaden los servidores de correo, el registro de acceso de un servidor web o el encabezado de respuesta HTTP Date: conservado en una entrada de la caché del navegador. El encabezado Last-Modified: de un servidor proporciona un límite inferior: una descarga no puede crearse localmente antes de la última modificación del contenido en el servidor.
• Durante la adquisición, registre el reloj del dispositivo junto a una referencia de confianza. Eso mide el desfase en el momento de la adquisición, no necesariamente el anterior.

Documentación y aplicación de una corrección

Anote la referencia, cómo determinó el desfase, el intervalo al que se aplica y la incertidumbre restante. Aplique la corrección solo entre eventos de reloj conocidos: un desfase medido después de un salto no es aplicable antes de él. Conserve el valor original en su informe junto al corregido.

Eventos fuera de orden

Un salto hacia atrás hace que un intervalo de lecturas del reloj ocurra dos veces, por lo que ordenar por hora intercala eventos no relacionados; un salto hacia delante deja un vacío. Tras un fallo de la batería del RTC o un restablecimiento del firmware (BIOS/CMOS), el reloj puede reiniciarse en una fecha predeterminada del firmware, lo que produce eventos «en 2001» u otro año anterior hasta que se vuelve a ajustar; un reloj demasiado adelantado crea archivos «en el futuro». Estos patrones son consecuencias normales del hardware y de los cambios manuales, no pruebas de manipulación. Busque el evento 1 de Kernel-General o el 4616 que los explique y restablezca el orden real con números de secuencia que no dependan del reloj: EventRecordID de EVTX, números de secuencia de actualización del diario USN y números de secuencia de $LogFile.

Las horas de adquisición no son las horas de la evidencia

Las horas producidas por la propia adquisición, como las horas del sistema de archivos de los archivos copiados a una carpeta de triaje y la hora de adquisición, describen su trabajo, no el del usuario (lección 3.3). Exclúyalas de la línea de tiempo de eventos y utilice el registro de adquisición para medir el desfase y documentar la custodia.

Precisión y correspondencia

Un valor DOS marca un intervalo de dos segundos. Según quién lo escriba, la hora real se trunca al segundo par inferior o se redondea hacia arriba al superior, por lo que puede situarse hasta 2 segundos antes o después del valor almacenado. Cuando compare un valor DOS con un FILETIME, admita ese margen; una diferencia de 1 segundo no implica dos eventos. El examen práctico CFX acepta una respuesta de marca de tiempo dentro de ±1 segundo, escrita en UTC con Z, como 2026-03-16T09:20:14Z. Informe el valor del artefacto que indique la tarea, convertido exactamente, y no lo redondee para acercarlo a otra fuente.

Ejemplo resuelto 1: un archivo FAT32 y la $MFT del equipo

Una imagen de una unidad USB FAT32 contiene plan.docx (nombre corto PLAN~1.DOC). En su entrada de directorio, la palabra de hora en el desplazamiento 0x16 es 87 32 y la palabra de fecha en 0x18 es 70 5C:

• Hora 0x3287: hora = 0x3287 >> 11 = 6; minuto = (0x3287 >> 5) & 0x3F = 20; segundos = (0x3287 & 0x1F) × 2 = 7 × 2 = 14, por lo que es 06:20:14.
• Fecha 0x5C70: año = (0x5C70 >> 9) + 1980 = 46 + 1980 = 2026; mes = (0x5C70 >> 5) & 0x0F = 3; día = 0x5C70 & 0x1F = 16, por lo que es 2026-03-16.

El TimeZoneKeyName del equipo es E. South America Standard Time y ActiveTimeBias es 180. Brasil no tenía horario de verano en 2026, por lo que 180 es aplicable en esa fecha: 06:20:14 + 180 minutos = 2026-03-16T09:20:14Z.

La $MFT del equipo contiene C:\Users\ana\Desktop\plan.docx con una hora de modificación de $SI de 2026-03-16T09:20:12.7Z. La diferencia es de 1,3 segundos, inferior a la resolución DOS de 2 segundos, por lo que los valores son compatibles con una única modificación: una copia conserva la hora de modificación del archivo y Windows la redondea hacia arriba al siguiente segundo par en FAT. Si se informa a partir de la unidad USB, la respuesta es 2026-03-16T09:20:14Z.

Ejemplo resuelto 2: un reloj adelantado 7 minutos

En otro equipo, el registro System contiene el evento 1 de Kernel-General con OldTime 2026-03-18T13:47:31.5Z y NewTime 2026-03-18T13:40:31.5Z. El salto es 13:47:31.5 − 13:40:31.5 = −7 min 00 s: el reloj estaba adelantado 7 minutos antes de las 13:47:31.5, hora del dispositivo. No aparece ningún cambio de hora anterior desde el arranque, por lo que el desfase se aplica a toda la mañana.

Corrobore con un reloj independiente: la entrada de la caché del navegador correspondiente a la descarga almacena el encabezado Date: del servidor, 13:22:03Z. Hora del dispositivo 13:29:05 − 13:22:03 = 7 min 02 s, compatible con un desfase de 7 minutos más 2 segundos de transferencia. Documente el ID de registro del evento, el desfase, su intervalo y ambos valores de cada fila.

Enfoque del examen: Prepárese para convertir a UTC artefactos en hora local, como marcas de tiempo FAT, líneas de setupapi.dev.log o fechas EXIF, con el sesgo y las reglas vigentes en la fecha del evento. Debe poder leer OldTime y NewTime del evento 1 de Kernel-General o del evento 4616 y corregir las marcas de tiempo anteriores según el salto. Las preguntas de correspondencia pueden emparejar un valor DOS de 2 segundos con un FILETIME; una diferencia inferior a 2 segundos no implica un evento distinto.

Puntos clave

• Distinga la hora UTC real, el reloj del dispositivo y la visualización de su herramienta; los artefactos solo registran el reloj del dispositivo.
• Las horas FILETIME, Unix y APFS están en UTC; FAT/DOS, muchos registros de texto, algunos valores SYSTEMTIME y EXIF DateTimeOriginal están en hora local; exFAT puede incluir un desplazamiento UTC válido.
• UTC = local + sesgo, con sesgo = −(desplazamiento UTC) y las reglas de horario de verano y legales de la fecha del evento, no el ActiveTimeBias actual.
• Fuerce UTC en todas las herramientas e impida que las hojas de cálculo reinterpreten las marcas de tiempo.
• Mida el desfase frente a referencias de confianza (Kernel-General 1, 4616, encabezados de servidor, notas de adquisición) y aplique correcciones solo dentro del intervalo que cubren.
• Tenga en cuenta la resolución: las horas de modificación DOS son valores de 2 segundos y el examen acepta ±1 s en UTC con Z.