• Inicio
  • BLOG
  • Contenido
  • Descargas
  • Enlaces
  • Contacto

Javier Tobal

Javier Tobal

  • twitter
  • linkedin
  • mail
  • medium
  • Welcome
  • Sobre mí
  • BLOG
  • Especialidades
    • Tecnología
    • Telecomunicaciones
    • Peritajes informáticos
    • Consultoria
  • Organizaciones
  • Servicios
  • Cara B
    • Tercer sector
    • Aficiones
    • Gratuita publicidad

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

28/09/2014 by Javier Tobal

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 />

Filed Under: BLOG, Peritajes, Uncategorized Tagged With: correo electrónico, email, forense, forensics

Javier Tobal

Informático. Perito judicial. Experto en ciberseguridad.
CISO
Expert in cybersecurity, ICT, innovation. Computer forensics. CISO

Linkedin

Twitter

Sobre mí

cyberwiser.eu

CYBERWISER.EU es una iniciativa europea orientada a construir un entorno para profesionales de la ciberseguridad y usuarios donde realizar ejercicios de ciberseguridad. Soy miembro del Stakeholders Expert Board

cyberwatching.eu

CYBERWATCHING.EU es el Observatorio Europeo de Ciberseguridad y Privacidad. Colaboré en la puesta en marcha de este proyecto como representante de la Agrupación Empresarial Innovadora (AEI) en Ciberseguridad y Tecnologías Avanzadas.
Tweets by @JaviTobal

Mi canal en Youtube

Etiquetas

BCM BCP belkasoft BIA big data BYOD casos reales ciberseguridad consultoría continuidad continuidad de negocio correo electrónico crisis management devices dispositivos email evidencia digital forense forensics hacking herramienta forense herramientas HIKVISION IMAGEMAGICK imagenes digitales interceptación legal LINUX movilidad MTPOD peritaje peritaje informático perito perito informático redes sociales review RPO RTO SCRIPTS security seguridad social media software super-cookies videovigilancia windows

Copyright © 2023 · Metro Pro Theme JTOBAL on Genesis Framework · WordPress · Log in