Buenas a todos, en el post de hoy continuaremos la cadena de posts sobre herramientas forense para hablaros sobre los procesos de análisis pericial de correos electrónicos.
Lo primero que debemos saber antes de analizar un email es que su formato viene establecido en una RFC, en concreto en la RFC 822. En ella se define que un email debe estar formado por los siguientes componentes:
Cabecera (Header)
Como veis, un correo electrónico no es más que una página web, con algunas peculiaridades. Es decir, es un software, y como tal debe ser tratado.
Si queremos ir a juicio por un tema de injurias, despido improcedente, etc. presentando el email impreso en papel, vamos por el mal camino. Un correo electrónico impreso no ofrece garantía como prueba porque es fácilmente alterable con herramientas de retoque fotográfico. Ni aunque vayamos a un notario con el correo impreso nos la darían como prueba válida.
Para poder probar que el correo es verdadero es necesario realizar un análisis forense, como el que realizaríamos a un disco duro, o a un software.
Dentro de la distinta información que podríamos recuperar de un email, lo más habitual es recolectar datos sobre quién envió el email y si el remitente fue suplantado, la dirección a donde fue enviado, por que sitios pasó, así como incoherencias de fechas y horas, servidores, etc. que puedan haber sido alterados.
Si abrimos el código fuente de un email nos encontraremos con una serie de campos que pasamos a describir a continuación:
Vamos a verlo con un ejemplo real:
Lo primero que debemos saber antes de analizar un email es que su formato viene establecido en una RFC, en concreto en la RFC 822. En ella se define que un email debe estar formado por los siguientes componentes:
Cabecera (Header)
- Date: Fecha y hora del mensaje.
- From: Quién lo envía.
- To: Destinatario/s.
- Subject: Asunto.
- Cc (copia de carbón): Destinatarios en copia.
- Cco (copia de carbón oculta). Destinatarios ocultos.
- Mensaje en texto plano o HTML
Como veis, un correo electrónico no es más que una página web, con algunas peculiaridades. Es decir, es un software, y como tal debe ser tratado.
Si queremos ir a juicio por un tema de injurias, despido improcedente, etc. presentando el email impreso en papel, vamos por el mal camino. Un correo electrónico impreso no ofrece garantía como prueba porque es fácilmente alterable con herramientas de retoque fotográfico. Ni aunque vayamos a un notario con el correo impreso nos la darían como prueba válida.
Para poder probar que el correo es verdadero es necesario realizar un análisis forense, como el que realizaríamos a un disco duro, o a un software.
Dentro de la distinta información que podríamos recuperar de un email, lo más habitual es recolectar datos sobre quién envió el email y si el remitente fue suplantado, la dirección a donde fue enviado, por que sitios pasó, así como incoherencias de fechas y horas, servidores, etc. que puedan haber sido alterados.
Si abrimos el código fuente de un email nos encontraremos con una serie de campos que pasamos a describir a continuación:
Return-Path:
|
Dirección de
respuesta
|
Resent-from:
|
Mensaje
reenviado por el usuario especificado.
|
Resent-to:
|
Mensaje
reenviado al usuario especificado
|
Resent-date:
|
Fecha y hora de
reenvío del mensaje.
|
Received:
|
Cada vez que el
mensaje pasa por un servidor, aparece este campo de datos, especificándose el
nombre del servidor, su IP, el programa de correo utilizado, y la fecha y la
hora en que se recibió en el servidor
|
Message-Id:
|
Nº de
identificación del mensaje. Se trata de un número único, que lo distingue de
cualquier otro mensaje enviado por la red
|
Date:
|
Fecha y hora de
envío del mensaje
|
From:
|
Remitente
original del mensaje
|
X-Originating-IP (Received)
|
IP de quien
envía el mensaje
|
Subject:
|
Asunto del
mensaje
|
To:
|
Destinatario
del mensaje
|
Vamos a verlo con un ejemplo real:
- ROJO: El email en sí.
- MORADO: ID del mensaje que da el proveedor.
- VERDE: Saltos que ha ido dando el correo desde que salió del equipo del emisor hasta el equipo del receptor.
- AZUL: Direcciones IP. El primer received y el último (siempre empezando por abajo) apuntan al servidor del emisor y del destinatario del mensaje.
Saludos!