Análisis forense de correos electrónicos

Recorrido del correo electrónicoComo ya vimos en el artículo “Cómo robar tus contraseñas del banco, Facebook, Twitter, Yahoo, Hotmail o Gmail en menos de 1 minuto.” es muy sencillo falsificar el remitente de un correo electrónico. Los casos más habituales los tenemos diariamente en el phising bancario o el reciente CryptoLocker que pueden comprometer seriamente la seguridad del destinatario del correo falsificado.

Por lo tanto, en el análisis forense informático es muy importante encontrar las evidencias digitales necesarias para confirmar su autenticidad. En el análisis forense de correos electrónicos deberemos conocer perfectamente el funcionamiento del envío/recepción del correo, cuáles son el conjunto de normas/estándares que utilizan y cómo analizar sus cabeceras.

La RFC 2822 define el formato de los correos electrónicos en Internet que son enviados entre los usuarios de ordenadores. Se establecen una gran cantidad de campos pero sólo se tendré en cuenta aquellos campos más significativos dentro del ámbito de la seguridad y autenticación de los correos electrónicos. De esta manera el correo electrónico se puede dividir en tres partes:

  • El cuerpo del mensaje.
  • Cabeceras del mensaje.
  • La envoltura del mensaje.

Cuerpo del mensaje

Esta parte del mensaje es la que menos interés tiene para el análisis del correo electrónico. Aquí se encuentra la información escrita por el usuario remitente al usuario final. La forma en que está codificada viene determinada por la norma RFC 2045.

Cabeceras del mensaje

Las cabeceras son metadatos, literalmente “sobre datos”, datos que describen otros datos. La información situada antes del cuerpo del mensaje se consideran cabeceras del mismo. Contienen información vital para el investigador forense. En general, el software de transporte de correo no modifica los encabezados del correo, a excepción de la cabecera Received. Las cabeceras se pueden agrupar en diversos campos según su funcionalidad:

  • Campos del Remitente
  • Campos del Destinatario
  • Campos de Referencia
  • Campos de Seguimiento
  • Campos de Extensión
  • Campos definido por el usuario
  • Otros campos

Campos del Remitente

Estos campos hacen referencia a la procedencia del mensaje. Son tres:

  • From: Cuenta/s de correo que originaron el mensaje. Autor/es del mensaje. Este campo lo introduce el usuario y puede ser fácilmente falsificado por lo tanto es poco fiable (no debería contener ninguna dirección que no se corresponda con el/los autor/res del mensaje).
  • Sender: Dirección de una cuenta de correo. Especifica el agente transmisor del mensaje, el encargado de remitirlo a la dirección de destino. Este campo lo introduce el usuario.
  • Reply-to: Cuenta/s de correo a donde se dirigirán las respuestas al correo. En ausencia de este campo las respuestas se dirigirán a la/s dirección/es indicadas en el campo From. Este campo lo introduce el usuario.

Campos del Destinatario

Existen tres campos diferentes dentro de esta agrupación:

  • To: Este campo contiene la/s direcciones de los principal/es destinatario/s del mensaje. Este campo lo introduce el usuario.
  • Cc: Campo que indica la/s dirección/es a las que se les hará llegar una copia del correo, aunque el contenido del mensaje puede que no vaya dirigido expresamente a ellos. Este campo lo introduce el usuario.
  • Bcc: Campo que indica la/s dirección/es a donde se remitirá una copia del mensaje. Los destinatarios indicados en To y en Bcc no ven este campo. Este campo lo introduce el usuario.

Campos de Referencia

También se pueden denominar campos de identificación. Existen varias cabeceras de las cuales se presentan cuatro:

  • Message-ID: Esta cabecera hace referencia a un código de identificación único relacionado con el correo enviado. Este código es asignado por el servidor de donde sale el mensaje (máquina remitente). En ningún momento del camino seguido por el mensaje este número es cambiado o modificado por ningún servidor.
  • In-Replay-To: Este campo contiene todos los identificadores de mensaje (ID) a los que este mensaje responde. Si hay mas de un identificador irán separados por comas, todos ellos encerrados dentro de < >. Este campo es generado por la aplicación cliente.
  • Reference: Contiene todos los ID de los mensajes a los que éste hace referencia. Este campo es generado por la aplicación cliente.

Campos de Seguimiento

Este conjunto de cabeceras, de nuevo está compuesta por varios campos, de los cuales únicamente se tratarán dos:

  • Return-Path: Este campo es añadido por el último servidor que entrega el correo al usuario final. Contiene la ruta de acceso que ha tomado el mensaje desde su origen hasta su destino. Es la dirección de correo electrónico que se especificó en la transacción SMTP con la instrucción MAIL FROM:. Este campo puede no coincidir con el campo From: de las cabeceras de origen. El servidor de correo enviará un mensaje a esta dirección en el caso de que el correo no pueda ser entregado.
  • Received: En el análisis forense de correos electrónicos este campo es el más importante para la identificación del origen del mensaje. Crea una lista de todos los servidores de correo a través de los que ha viajado el mensaje hasta llegar al destinatario. Existirán tantos campos Received como servidores SMTP por los que haya pasado el mensaje. Estas cabeceras se van añadiendo al mensaje según va pasando por los diferentes servidores de correo, siendo el primer campo Received el último servidor por el que ha pasado el correo. En el último de los Received esta reflejada la dirección IP del host origen y el dominio (o nombre de equipo) identificativo que se escribió detrás del comando HELO del protocolo SMTP. Por lo tanto para tener una visión estructurada según la línea de tiempo del envío es necesario leer las cabeceras Received de abajo hacia arriba. Estos campos son añadidos por los servidores.

Campos de Extensión

Estos campos únicamente dan información de cual es el formato del mensaje contenido en el correo. La utilidad de estas cabeceras es la de proporcionar soporte a Multipurpose Internet Multimedia Extensión (MIME). Las principales cabeceras son las siguientes:‡

  • MIME-Version: Versión del protocolo que se está utilizando en la aplicación cliente. Esta cabecera es añadida por el cliente.
  • Content-Transfer-Encoding: De nuevo esta cabecera es introducida por la aplicación cliente. Contiene información para poder visualizar correctamente el mensaje en su destino.
  • Content-Type: Muestra el formato del mensaje, como html, texto plano o xml. Añadido por la aplicación del cliente.

Otros campos

Otros campos definidos dentro de la RFC son:

  • Date: Fecha y hora en la que el mensaje es entregado a la cola del servidor SMTP para su envío. Este campo lo establece el servidor origen.
  • Subject: Este campo contiene un pequeño texto con la descripción del objeto del mensaje. Este campo es rellenado por el remitente del mensaje.

Campos definidos por el usuario

Existe la posibilidad de que el usuario defina sus propios campos, además de los ya establecidos por la RFC. Éstos deberán empezar siempre por X-, seguidos del nombre que se le quiera asignar al campo. En el análisis forense de correos electrónicos es muy importante tener presente que pueden ser verdaderos o falsos.

Algunos filtros de Spam añaden un campo llamado X-Spam para informar de que es posible que ese correo sea indeseado.

Campos obligatorios

La RFC 2822 obliga a que exista un mínimo de cabeceras, éstas son:

  • From: Si esta cabecera no se rellena, automáticamente tomará el valor de la dirección de correo introducida en la transacción SMTP con el comando MAIL FROM:
  • Date: Esta cabecera es añadida automáticamente por el servidor.
  • To: Si esta cabecera no se rellena, automáticamente tomará el valor de la dirección de correo introducida en la transacción SMTP con el comando RCPT TO:
  • Received: Esta cabecera es añadida automáticamente por los servidores de correo.
  • Message-ID: Esta cabecera es añadida automáticamente por el servidor de correo origen.
  • Return-Path: Esta cabecera es añadida automáticamente por el servidor de correo origen.

Envoltura del mensaje

Esta parte del mensaje no está definida en la RFC 2822, sino que tiene más que ver con el protocolo SMTP, comentado en la RFC 2821.

Como se explica en la descripción del protocolo SMTP, antes de mandar un correo electrónico se establece una conversación entre el cliente y el servidor. En ese intercambio de información se especifica el/los destinatario/s del correo y el remitente del mensaje, con los comandos RCPT TO: y MAIL FROM: respectivamente. Estos datos son los que utilizan los servidores de correo para encaminar el mensaje a su destino, y son los que forman la envoltura del mensaje.

Hay que destacar que estos dos datos son independientes de los reflejados en las cabeceras From: y To: especificados anteriormente en los encabezados del mensaje. Los datos de RCPT TO estarán siempre en la primera cabecera Received creada (ultima que se puede ver en el correo recibido). El dato de MAIL FROM siempre coincidirá con el campo de la cabecera Return-Path.

Gracias al colegio oficial de ingenieros de telecomunicación por sus continuas publicaciones.

Cualquier línea de las cabeceras del correo electrónico puede ser falsificadas, salvo las lineas Received: que son generadas por los servidores y nos ayudan a confirmar la autenticidad de los correos electrónicos.

Caso práctico. Interpretación de las cabeceras de un correo electrónico.

Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Sun, 20 Sep 2015 17:06:38 +0200
Received: from dedicado.imaginaworks.info ([82.194.70.168]:53179)
by dedicado.bilbaodigital.org with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85)
(envelope-from <[email protected]>)
id 1ZdgCM-0000aN-2e
for [email protected]; Sun, 20 Sep 2015 17:06:38 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bilbaodigital.es; s=default;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=5g65uXyMNCWVTGYE8Civl3M00osxKn4rijD1ZFHtHzE=;
b=p7nR46Q5xPqbiyyawR/w7lmYY//khCh7BiC4SyP7NUEQKdNrWn25MVMeLDAtykzlCjIj7GY+AY0qG2JL6BYHsER3TanivQ0503fF90r0uRj1Ltjls3DTFBh34VZxI/9hLdZGqemLDNzwFYaJmCgVSeO2MWg1iBrwthw8/MDWUbg=;
Received: from [84.77.41.92] (port=3830 helo=pcPC)
by dedicado.imaginaworks.info with esmtpa (Exim 4.85)
(envelope-from <[email protected]>)
id 1ZdgCG-0001Mr-1t
for [email protected]; Sun, 20 Sep 2015 17:06:32 +0200
From: =?iso-8859-1?Q?Carlos_S=E1nchez_Santos?= <[email protected]>
To: <[email protected]>
Subject: Saludos
Date: Sun, 20 Sep 2015 17:06:37 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_005C_01D0F3C6.B6250CE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdDztc3qBotlW5pJS9CxCpaxR6JR3Q==
Content-Language: es
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - dedicado.imaginaworks.info
X-AntiAbuse: Original Domain - carlos-sanchez.es
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bilbaodigital.es
X-Get-Message-Sender-Via: dedicado.imaginaworks.info: authenticated_id: [email protected]

From: =?iso-8859-1?Q?Carlos_S=E1nchez_Santos?= <[email protected]>
To: [email protected]
Subject: Saludos
Date: Sun, 20 Sep 2015 17:06:37 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_005C_01D0F3C6.B6250CE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdDztc3qBotlW5pJS9CxCpaxR6JR3Q==
Content-Language: es
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - dedicado.imaginaworks.info
X-AntiAbuse: Original Domain - carlos-sanchez.es
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bilbaodigital.es
X-Get-Message-Sender-Via: dedicado.imaginaworks.info: authenticated_id: [email protected]

Received: from [84.77.41.92] (port=3830 helo=pcPC)
by dedicado.imaginaworks.info with esmtpa (Exim 4.85)
(envelope-from [email protected])
id 1ZdgCG-0001Mr-1t
for [email protected]; Sun, 20 Sep 2015 17:06:32 +0200

Return-path: [email protected]
Envelope-to: [email protected]
Delivery-date: Sun, 20 Sep 2015 17:06:38 +0200
Received: from dedicado.imaginaworks.info ([82.194.70.168]:53179)
by dedicado.bilbaodigital.org with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85)
(envelope-from [email protected])
id 1ZdgCM-0000aN-2e
for [email protected]; Sun, 20 Sep 2015 17:06:38 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bilbaodigital.es; s=default;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=5g65uXyMNCWVTGYE8Civl3M00osxKn4rijD1ZFHtHzE=;
b=p7nR46Q5xPqbiyyawR/w7lmYY//khCh7BiC4SyP7NUEQKdNrWn25MVMeLDAtykzlCjIj7GY+AY0qG2JL6BYHsER3TanivQ0503fF90r0uRj1Ltjls3DTFBh34VZxI/9hLdZGqemLDNzwFYaJmCgVSeO2MWg1iBrwthw8/MDWUbg=;

Análisis de las cabeceras del correo electrónico

En el análisis forense de correos electrónicos es vital conocer los diferentes mecanismos de falsificación para poder identificarlos. En rojo algunos de los campos de las cabeceras del mensaje que pueden ser falsificados. En verde las líneas Received: que se añaden a la cabecera cada vez que el correo pasa por un servidor. Leyendo las líneas Received de abajo hacia arriba, la primera nos muestra la dirección IP y el nombre de la máquina/dominio del usuario remitente:

Análisis de las cabeceras del correo electrónico. Campos falsificables
Sígueme

Carlos Sánchez Santos

Presidente de Bilbaodigital y gerente de Imagina Works, S.L.
Forense informático
Auditor de Seguridad FTSAU - RHCT 605007791313908 - RHCSA 100/014/133 CEH ECC942714
Sígueme