Saludos BugBu5t3r5!
Hace un par de días un cliente me llamo
y me dijo que su área de seguridad de la información estaba llevando a cabo una
investigación de robo de secretos industriales, me comentó que sospechaban que
el usuario “sabia más de computadoras de lo que aparentaba” y que suponían que
estaba utilizando técnicas anti forenses ya que las horas y fechas de creación
y modificación de todos los archivos de la maquina no correspondía con lo que
el administrador de sistemas les reportaba de cuándo y a qué hora este usuario
se había loggeado a su máquina, es decir, la consola de administración les daba
pistas de ciertos accesos al sistema del sospechoso a ciertas horas y en
ciertos días no comunes pero las fechas y horas de los archivos no soportaban
esa evidencia. La pregunta era; si, ¿Yo sabía de algún software o técnica anti
forense y como remediarlo?.
Mi primera respuesta como la de muchos de ustedes hubiera sido fue, “claro, si por supuesto que hay formas de modificar esa información en los archivos, Timestomp por ejemplo, y no es tan sencillo encontrar evidencia de esto en un sistema” sin embargo al hacer un perfilamiento del sospechoso me parecía poco probable que esa fuera la razón de discrepancia de las timestamps. Así que pedí revisar su metodología de adquisición de evidencia y sus formatos de cadena de custodia y hoja de adquisición de evidencia digital, y fue ahí cuando vi la luz! El equipo del cual provenía la evidencia estaba en un estado diferente del cual estaba siendo analizado, de hecho con otra zona horaria, ¿ya saben por qué la discrepancia entre las timestamps?
Mi siguiente pregunta fue obvia ¿revisaron la configuración de la zona horaria? ¿Hicieron los ajustes necesarios en el sistema en el que fue analizado? El silencio que siguió a las preguntas me dijo todo… ese era el problema, es por eso y como respuesta a la petición del equipo de seguridad de la información que decidí hacer este pequeño post acerca de cómo verificar e interpretar correctamente la información de las zonas horarias.
Mi primera respuesta como la de muchos de ustedes hubiera sido fue, “claro, si por supuesto que hay formas de modificar esa información en los archivos, Timestomp por ejemplo, y no es tan sencillo encontrar evidencia de esto en un sistema” sin embargo al hacer un perfilamiento del sospechoso me parecía poco probable que esa fuera la razón de discrepancia de las timestamps. Así que pedí revisar su metodología de adquisición de evidencia y sus formatos de cadena de custodia y hoja de adquisición de evidencia digital, y fue ahí cuando vi la luz! El equipo del cual provenía la evidencia estaba en un estado diferente del cual estaba siendo analizado, de hecho con otra zona horaria, ¿ya saben por qué la discrepancia entre las timestamps?
Mi siguiente pregunta fue obvia ¿revisaron la configuración de la zona horaria? ¿Hicieron los ajustes necesarios en el sistema en el que fue analizado? El silencio que siguió a las preguntas me dijo todo… ese era el problema, es por eso y como respuesta a la petición del equipo de seguridad de la información que decidí hacer este pequeño post acerca de cómo verificar e interpretar correctamente la información de las zonas horarias.
Empecemos definiendo la importancia de la zonas
horarias, su afectación sobre la evidencia puede ser definitiva para probar o
no la culpabilidad de una persona, las timestamps se le muestran a los usuarios
en su GUI en su horario local tomando en cuenta el horario de verano aun asi
dependiendo del sistema de archivos las timestamps no siempre se almacenan como
el usuario la ves, por ejemplo FAT almacena sus timestamps como LocalTime y
NTFS almacena sus timestamps en UTC o GMT de hecho la mayoría de los sistemas de
Windows modernos se inclinan más en almacenar esta información en UTC utilizando
un timestamp de 8 bytes, el reloj del sistema
almacena la Hora Actual (CurrentTime) como Hora Local (LocalTime) después Windows
utiliza información en el registro de Windows para identificar la zona horaria actual o CurrentTimezone
y después ajusta la información al timestamp antes de mostrarla al usuario. Ahora, en donde podemos encontrar esta información? O en que
parte del registro está ubicada? La ruta para la información de timezone es: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Si están utilizando una herramienta como EnCase o FTK u otra
no verán la llave CurrentControlSet eso es porque es un vínculo que únicamente podrán
encontrar en un registro que se está analizando en vivo, verán ControlSet001 y
ControlSet002 pero cuál es el control actual o Current Control? Esto es fácil de
saber solo con revisar la llave Select
en SYSYTEM verán la subllave Current y el valor indica 0x01 para ControlSet001 0x02 para
ControlSet002, en mi experiencia la mayoría veces el CurrentControl es 0x01 sin
embargo siempre es bueno verificar.
Bueno ahora revisemos la informacion de TimeZoneInformation
lo primero que vamos a revisar es el Active Bias que si se fijan es la misma información
contenida en Bias cuando vemos esta información en Regedit vemos un valor en
hexadecimal en este caso 0x168 este valor convertido a decimal nos da 360 estos
son 360 minutos o 6 horas.
Esta conversión es fácil sin embargo si viéramos el
contenido en crudo de la sub llave Bias como se ve por ejemplo en EnCase tendríamos
que saber que este valor está en Little-Endian es decir los valores se deben
leer de derecha a izquierda.
Para obtener los valores de forma rápida EnCase
tiene una función llamada GoTo en la que nos despliega el valor que
seleccionemos, y como siempre hemos dicho un forensicator sabe utilizar diferentes
herramientas, y obtener el mismo
resultado.
Ahora que tiene que ver este valor de 360 o 6 horas? Este es
el valor base desde el cual se calcula la zona horaria del Bias, al valor de la
subllave Standard Bias el cual por lo general tiene un valor de “0”, se le suma
este valor para obtener la zona horaria standard, y si quisiéramos obtener la
zona horaria con horario de verano a este valor debería de sumársele el valor
de la sub llave Daylight Bias y es aquí en donde UTC se relaciona con la zona
horaria del sistema, Windows agregaría este valor al horario local para obtener
y desplegar la zona horaria. Espero estar siendo claro, sino espero que los ejemplos
ayuden a clarificar.
La relación entre Active Bias y Bias es que si los valores
son iguales eso quiere decir que a la hora de la adquisición o decomiso de este
sistema el Standard Bias estaba en operación. Si esta subllave tuviera un valor
diferente quiere decir que el horario de verano o Daylight Bias estaba en operación.
Ahora hemos hablado un par de veces acerca del DaylightBias
si notan tiene un valor mucho muy diferente al Bias que convertimos.
Si hiciéramos la conversión obtendríamos un valor sin ningún
sentido, y esto es porque el Bias es un valor asignado esto quiere decir que
puede tener un valor positivo o negativo, para poder conocer el valor decimal
real de Daylight Bias usaremos un convertidor de UInt32 a Int32.
Aquí vemos que el valor es -60 esto le dice a Windows que tiene
que tomar este valor y sumarlo al valor del Bias es decir: -60 + 360= 300, 300
minutos o 5 horas , esta información es la que utiliza nuestro sistema
operativo para poder obtener el horario de verano y esto es verdad y lo podemos
comprobar al revisar las sub llaves de Daylight Name y Standard Name en este
caso tienen un valor de @tzres.dll,-171 y -172, que significa esto? Si revisan aquí podrán encontrar el valor que
Windows asigna a estos timezones IDs aunque no es necesario puesto que existe
una sub llave llamada TimeZoneKeyName sin embargo pueden verificarlo.
Hablando de horario de verano ¿Cómo sabe Windows cuando
realizar el cambio? En la sub llave DaylightStart que contiene un valor de 16
bytes sub divididos en 8 grupos de 2 bytes cada uno y nos indicaran cuando
comienza el horario de verano en nuestro ejemplo esta sub llave tiene el siguiente
valor:
00 00 04 00 01 00 02 00 00 00 00 00 00 00 00 00
Al analizarlos obtenemos la siguiente información:
00 00 – este valor representa el año en el que se debe
hacer el cambio de horario el valor “0” nos indica que se lleva a cabo año con
año
04 00 – este valor indica el mes en el que se realiza el
cambio es decir Abril o el cuarto mes
01 00 – este valor indica la semana del mes en la que se
hace en cambio en este caso es la primera semana del mes de abril.
02 00 – este valor indica la hora expresado en un formato de
24 hrs en que se hara el cambio en este caso 2:00 am
00 00 – este valor
representa los minutos desde la hora
00 00 – este valor
representa los segundos desde la hora
00 00 – este valor representa los mili segundos desde la hora
00 00 – este valor
representa el día de la semana en que se realizara el cambio siendo el domingo
el primer día de la semana y teniendo un valor de “0”
Como siempre hemos dicho es importante saber utilizar
nuestras herramientas, pero es más importante saber interpretar y saber de dónde
viene la información que utilizamos como evidencia hay muchas otras
herramientas que nos ayudan a analizar y darnos de forma automática esta información
por ejemplo como forma de quality assurance utilice RegRipper para verificar la
información que me dio Regedit y EnCase:
Recuerden que es de suma importancia en sus investigaciones
digitales o en su respuesta a incidentes el verificar la zona horaria, una mala
configuración o interpretación puede significar atribuirle actividad a un
sospechoso en tiempos que no son correctos, la anulación de la veracidad de la
evidencia y por extensión la pérdida del caso.
Espero que este post les haya gustado y hayan aprendido
recuerden seguirnos en Twitter @bu5t3r5 y cualquier duda o comentario o corrección
siempre estamos disponibles en bugbu5t3r5@gmail.com
Happy Bu5ting!
- Bu5t3R-
No hay comentarios.:
Publicar un comentario
Déjanos tu opinion