Autenticidad de e-mail (II). Experiencias prácticas

En la entrada anterior (Metodología) se presentó una metodología para determinar la autenticidad de mensajes de correo electrónico (emails). Resumiendo aquella entrada, el perito puede confirmar la manipulación (o recreación) de un mensaje de correo electrónico si encuentra alguna incoherencia en el contenido del mismo.
Así que la labor consiste en extender toda la información de los mensajes a analizar y buscar "cosas raras". En esta entrada voy a presentar una lista con ejemplos de estas incoherencias que mencionaba anteriormente. Por supuesto no es una lista exhaustiva, ni aplicable directamente a cualquier situación, pero sí son consejos útiles extraídos de casos reales afrontados por este perito.

• Capturar los mensajes en el receptor, no en el emisor: los emails van acumulando cabeceras durante el tránsito entre servidores, por eso el mensaje recibido tiene todas las cabeceras de interés. Si tomásemos el mensaje "enviado" sólo veríamos la fecha de envío al servidor SMTP.
• Elegir el mejor formato disponible para procesar el email: lógicamente, hay que elegir un formato que mantenga las cabeceras técnicas. Por ejemplo, en Outlook es mejor exportar los mensajes como MSG que EML. 
• Convertir y ordenar todas las fechas y horas encontradas en las cabeceras: personalmente, antes de analizar las fechas, convierto todas las fechas a UTC. Una vez convertidas todas las fechas hay que verificar que la secuencia es correcta, es decir, que el mensaje ha pasado por el servidor saliente "antes" de llegar al siguiente servidor o al servidor destino. 
• Reconstruir la secuencia lógica de creación de todos los elementos: normalmente, los mensajes contienen varios elementos fechados: ficheros adjuntos, imágenes utilizadas como firma en mensajes con formato, etc. Si un mensaje contiene un adjunto (un PDF, por ejemplo) la fecha de creación del adjunto debe ser anterior a la fecha de envío. Ojo: las fechas de creación de adjuntos suelen estar expresadas en la hora local del ordenador donde fueron creados.
• Sospechar de fechas coincidentes: si estamos analizando una serie de varios mensajes, es sospechoso que varios de estos mensajes coincidan en la fecha de envío (minutos y segundos, por ejemplo). Cuando se recrean muchos mensajes (se construyen desde cero con el fin de aportar pruebas falsas) se suele partir de una plantilla base que se va modificando para cada uno de los falsos mensajes creado. En este caso, es habitual que no se modifiquen todas las cabeceras por lo que suelen aparecer patrones repetitivos sospechosos. 

En el ejemplo siguiente (convenientemente manipulado y anonimizado) se pueden ver varias incongruencias con las fechas registradas en la cabecera: 

• todas las horas indicadas coinciden en el segundo "08", 
• el mensaje llega al servidor SMTP justo una hora y un minuto después de ser enviado,
• el mensaje llega al servidor intermedio de gmail una hora antes de ser enviado ("16 Dec 2011 13:22:08 +0100")
• el servicio de Spam intenta procesar el mensaje un día antes de ser enviado, además de que el 15 de diciembre de 2011 no fue viernes ("Fri, 15 Dec 2011 13:27:08 +0200")

Received: from authsmtp.register.it ([88.88.88.88])

       by cromasms.com (cromasms.com [80.80.80.80])

       (MDaemon.PRO.v7.1.0.R)

       with ESMTP id md50015530304.msg

       for <gggggggg@dominio1.es>; Fri, 16 Dec 2011 13:23:08 -0000

Received: (qmail 21152 invoked from network); 16 Dec 2011 13:22:08 +0100

Received: from unknown (HELO MyPC) (smtp@dominio2.net@81.81.81.81)

  by authsmtp.register.it with ESMTPA; 16 Dec 2011 13:21:08 -0000

Return-Path: <jjjjjjjj@dominio2.net>

Return-Receipt-To: "J J JJJ" <jjjjjjjj@dominio2.net>

From: " J J JJJ " <jjjjjjjj@dominio2.net>

To: "'G GGGGG'" <gggggggg@dominio1.es>

Subject: Asunto-Asunto

Date: Fri, 16 Dec 2011 13:20:08 +0100

Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAIKbhNI7ijtPqgFnlYjDyprCgAAAEAAAABnc4asXvB1BmhrZS95aLHYBAAAAAA==@dominio2.net>

MIME-Version: 1.0

Content-Type: multipart/mixed;

       boundary="----=_NextPart_000_021D_01CEFBD1.30E76210"

X-Mailer: Microsoft Office Outlook 12.0

Thread-Index: Acy77Qy7ej+XwCNxSSm6hcYsAa8nBQ==

Content-Language: es

X-Spam-Processed: cromasms.com, Fri, 15 Dec 2011 13:27:08 +0200    (not processed: message size (7162935) exceeds max size (512000))

X-MDRemoteIP: 88.88.88.88

X-Return-Path: jjjjjjjj@dominio2.net

X-MDaemon-Deliver-To: gggggggg@dominio1.es

Disposition-Notification-To: " J J JJJ " <jjjjjjjj@dominio2.net>

• Verificar todas las direcciones IP: Las cabeceras de los emails contienen muchas direcciones IP, incluyendo el ordenador que envió el mensaje y los servidores intermedios. Hay que comprobar que las direcciones IP son "plausibles", es decir, que la ubicación geográfica es lógica o, si tenemos esa información, que la IP pertenece al ISP del supuesto remitente.
• Analizar el contexto histórico (WHOIS, DNS, etc.): es habitual (al menos en España) tener que analizar correos electrónicos que fueron enviados hace años. El mes pasado tuve que analizar unos emails de 2009! En este caso, verificar las IP y servidores utilizados mediante consultas estándar WHOIS y DNS no es correcto. Hay que utilizar registros históricos que nos resuelvan la consulta con la información de la fecha cuando ocurrieron los hechos. En este sentido, recomiendo utilizar servicios como http://www.domaintools.com/  o http://dnshistory.org/. 
• Revisar los metadatos de los archivos adjuntos: al analizar mensajes manipulados, es habitual encontrar incoherencias en los metadatos de archivos adjuntos. Por ejemplo: 
• Ficheros PDF con versiones que no existían cuando supuestamente se crearon (la versión 1.6 de PDF está disponible desde 2.004, luego no puede existir un fichero PDF v1.6 en un email de 2.002). 
• Documento creado con una versión de software posterior a la supuesta fecha de envío (por ejemplo, el formato DOCX de Microsoft está comercialmente disponible desde Micosoft Office 2007)
• Autores "sospechosos". Por ejemplo, hace unos años analicé unos PDF cuyo autor coincidía, casualmente, con el nombre del abogado que defendía el caso. 

En el ejemplo siguiente (convenientemente manipulado y anonimizado) se pueden ver varios datos relevantes: 

• la versión de PDF, v1.4, está disponible desde 2001 (Acrobat 5.0)
• Windows Vista x64 sólo está disponible desde 2007
• XLSX es una extensión que apareció por primera vez con la versión Office 2007
• la fecha de creación está mal formada y, por lo visto anteriormente, este documento no pudo ser creado en 2.005. 

Title:          Balance-2006.xlsx

Author:         jhernandez

Creator:        Balance-2006.xlsx

Producer:       doPDF   Ver 6.1 Build 286 (Windows Vista  x64)

CreationDate:   25/01/05 15:36:08

Tagged:         no

Form:           none

Pages:          1

Encrypted:      no

Page size:      842 x 595 pts (A4) (rotated 0 degrees)

File size:      535589 bytes

Optimized:      no

PDF version:    1.4

<Autenticidad de e-mail (II). Experiencias prácticas />

Autenticidad de e-mail (I). Metodología

Un problema habitual que se nos plantea a los peritos judiciales informáticos es determinar la autenticidad de correos electrónicos (emails) presentados como prueba en un juicio. Por ser un problema recurrente es útil tener preparado el procedimiento a seguir.

Personalmente, mi aproximación tiene dos elementos: un enfoque formal (que llamaré "metodología") y un enfoque práctico (que llamaré "experiencias prácticas"). En esta primera entrada describiré la parte metodológica

¿Qué es un email "auténtico"?

En la práctica, el perito no puede afirmar que un email es auténtico sino que se "limita" a confirmar que el email presentado no presenta ninguna irregularidad que confirmase que no es auténtico. Parece un juego de lógica pero, en realidad, es un matiz importante.

Existen dos tipos de emails "no auténticos":

Manipulaciones: se trata de emails auténticos que en su día fueron enviados y que han sido modificados posteriormente para tergiversar su contenido. Ejemplos reales de manipulaciones: cambiar la fecha de envío del email, sustituir un adjunto contenido en el mensaje original por otro adjunto diferente, añadir un destinatario que no existía en el email original, etc.

Recreaciones: se trata de presentar como auténticos emails que nunca fueron enviados. Normalmente, las recreaciones se realizan a partir de un mensaje auténtico al que se le modifican los elementos principales (remitente, destinatarios, asunto del mensaje, fechas de envío, contenido del mensaje, etc.). 

Si no se detecta ninguna irregularidad después de un examen exhaustivo de todas las evidencias presentadas u obtenidas por otros medios, el perito podrá determinar que el email en cuestión no ha sido manipulado y, por tanto y salvo nuevas evidencias en contrario, se trata de un email "auténtico". 

Metodología para determinar la autenticidad de un mensaje de correo electrónico (email)

Estas son las principales actividades que, en la práctica, permiten afrontar el problema de determinar la autenticidad de un email.

1. Obtención del mensaje original en formato digital. La prueba pericial se realizará a partir de una evidencia que contenga el mensaje completo a analizar, descartando el análisis de copias impresas o reenvíos del mensaje. Una parte importante de la información a analizar está en la cabecera técnica del mismo y esta cabecera no aparece en los emails impresos. Por otra parte cuando se reenvía un email las cabeceras que aparecen son las correspondientes al reenvío, no al mensaje a analizar.
2. Obtención de fuentes adicionales de información relacionadas con el mensaje. La mejor opción para detectar posibles manipulaciones es disponer de informaciones coincidentes procedentes de fuentes diversas. Personalmente, mi búsqueda suele incluir:
1. Archivo contenedor del email a analizar. Estos archivos contenedores dependen de los clientes y servidores de correo electrónico. La mejor opción, porque tiene información más completa, consiste en extraer los mensajes del receptor o del servidor de correo del receptor.
2. Registros de actividad de los servidores de correo implicados en la transmisión del email a analizar.
3. Registros de actividad de los elementos de red por los que se ha cursado el tráfico asociado a la transmisión del email a analizar.
4. Unidades de almacenamiento donde el email en cuestión ha podido quedar almacenado (copias de back-up de los servidores, unidades externas, etc.). 
3. Análisis de los elementos de información obtenidos. Lógicamente, cuantas más fuentes se puedan obtener y analizar más fiable será el resultado del análisis.
1. Cabecera del mensaje a analizar (cabecera técnica). Contiene información muy importante que permite localizar incoherencias en caso de manipulación. Ejemplo de información presente en la cabecera: cuentas de correo, servidores de envío, recepción y tránsito, fecha y hora de los envíos entre servidores, etc.
2. Cuerpo del mensaje
3. Ficheros adjuntos
4. Metadatos del archivo contenedor
5. Metadatos de los ficheros adjuntos
4. Correlación de toda la información obtenida y búsqueda de parámetros incoherentes (fechas, tamaños, direcciones, cuentas, etc.). La presencia de incoherencias en esta información probaría la presencia de alteraciones o recreaciones (intencionadas o no) del email analizado.

El procedimiento descrito necesita, para su realización, de experiencia y conocimientos concretos relacionados con los sistemas implicados: servidores y clientes de correo electrónico, herramientas de análisis forense específico, herramientas de recuperación de datos, análisis de logs, herramientas ofimáticas que generan los tipos de adjuntos más comunes, etc. Además es necesario, por supuesto, conocer el funcionamiento y los estándares implicados: SMTP, POP3, IMAP, DNS, TCP/IP, etc.

Pero, desde mi punto de vista, lo más importante a la hora de analizar la autenticidad de uno (o varios) emails es disponer de capacidad para observar grandes volúmenes de información, encontrar incoherencias entre datos relacionado o detectar patrones definidos dentro de información que, en principio, debería ser aleatoria. 

En la próxima entrada, presentaré algunas experiencias prácticas describiendo cómo ha sido posible, en entornos reales, detectar emails manipulados. 

<Autenticidad de e-mail (I). Metodología />