Email Forensics: Analisis de Headers y Ficheros EML

El email como vector de ataque y como evidencia

El correo electronico sigue siendo el vector de entrada mas comun en incidentes de seguridad. Phishing, spear-phishing, BEC (Business Email Compromise) y distribucion de malware via adjuntos representan una proporcion significativa de los incidentes que investigan los equipos DFIR.

Cada email contiene una cantidad significativa de metadatos en sus cabeceras que revelan el camino que siguio desde el remitente hasta el destinatario, los servidores involucrados, las verificaciones de autenticacion y los timestamps de cada salto. Saber leer e interpretar estos metadatos es una habilidad fundamental para el analista forense.

Estructura de un email

Un email consta de dos partes principales: las cabeceras (headers) y el cuerpo (body). Las cabeceras contienen los metadatos del mensaje: remitente, destinatario, asunto, fecha, y toda la informacion de enrutamiento. El cuerpo contiene el contenido visible para el usuario, que puede ser texto plano, HTML o una combinacion de ambos, junto con los adjuntos codificados en Base64.

Cabeceras principales

Las cabeceras que todo analista debe conocer son:

From: la direccion del remitente visible para el usuario. Es trivialmente falsificable y no debe usarse como prueba de origen sin verificacion adicional.

Return-Path: la direccion a la que se envian los mensajes de rebote (bounce). Suele coincidir con el remitente real del envelope SMTP.

Reply-To: la direccion a la que se enviaran las respuestas. En ataques BEC, suele ser diferente del From para interceptar las respuestas.

To, Cc, Bcc: destinatarios del mensaje. Bcc no aparece en las cabeceras recibidas por los demas destinatarios.

Date: timestamp del envio declarado por el cliente de correo del remitente. Puede ser falsificado.

Subject: asunto del mensaje.

Message-ID: identificador unico del mensaje generado por el servidor de correo del remitente. Util para rastrear un email especifico en logs de servidores.

MIME-Version y Content-Type: indican el formato del cuerpo del mensaje (text/plain, text/html, multipart/mixed para adjuntos).

Cabeceras Received

Las cabeceras Received son las mas importantes para el analisis forense porque documentan el camino del email a traves de la infraestructura de correo. Cada servidor que procesa el email anade una cabecera Received en la parte superior, por lo que deben leerse de abajo hacia arriba para seguir el recorrido cronologico.

Una cabecera Received tipica contiene:

Received: from mail-server.example.com (mail-server.example.com [93.184.216.34])
        by mx.receptor.com (Postfix) with ESMTPS id ABC123DEF
        for [email protected];
        Mon, 09 Jun 2026 10:23:45 +0000 (UTC)

Los campos relevantes son:

from: el nombre del servidor que envio el email y entre parentesis, el resultado de la resolucion DNS inversa y la IP real.

by: el servidor que recibio el email.

with: el protocolo usado (SMTP, ESMTP, ESMTPS para TLS).

id: identificador interno del servidor receptor, util para buscar en sus logs.

for: el destinatario del envelope SMTP.

Timestamp: fecha y hora en que el servidor recibio el email.

Deteccion de cabeceras falsificadas

Un atacante puede inyectar cabeceras Received falsas en el email antes de entregarlo al primer servidor de correo. Para detectar estas falsificaciones:

Las cabeceras anadidas por los servidores de la organizacion receptora son las mas fiables, ya que estan bajo su control.

Busca inconsistencias en las IPs y nombres de servidores. Si una cabecera dice "from google.com" pero la IP no pertenece a Google, es falsificada.

Los saltos temporales deben ser coherentes. Un email no puede salir de un servidor 5 minutos despues de llegar al siguiente.

Las cabeceras X- (como X-Mailer, X-Originating-IP) son informativas pero no estandarizadas y pueden ser falsificadas o eliminadas.

Verificacion de SPF, DKIM y DMARC

SPF (Sender Policy Framework)

SPF permite al propietario de un dominio declarar que servidores estan autorizados para enviar correo en su nombre. El servidor receptor verifica si la IP del servidor emisor aparece en el registro SPF del dominio.

Las cabeceras del email incluyen el resultado de la verificacion SPF:

Received-SPF: pass (google.com: domain of [email protected]
  designates 93.184.216.34 as permitted sender)
Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of [email protected]
  designates 93.184.216.34 as permitted sender)

Un resultado spf=fail indica que el servidor emisor no esta autorizado, lo que es un indicador fuerte de spoofing (aunque puede haber falsos positivos con reenvios de correo).

DKIM (DomainKeys Identified Mail)

DKIM anade una firma criptografica al email que el servidor receptor puede verificar usando la clave publica publicada en DNS. Una firma DKIM valida garantiza que el contenido del email (cabeceras firmadas y cuerpo) no ha sido modificado en transito.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=ABC123base64hash;
  b=SignatureBase64Data

Un resultado dkim=pass en Authentication-Results confirma que el email fue firmado por el dominio declarado y no fue modificado. Un dkim=fail indica que la firma no es valida (contenido modificado o firma falsificada).

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC combina SPF y DKIM y define la politica del dominio sobre que hacer con los emails que no pasan las verificaciones.

Authentication-Results: mx.receptor.com;
  dmarc=pass (p=REJECT dis=NONE) header.from=example.com

Para el analista forense, la combinacion de SPF, DKIM y DMARC proporciona una evaluacion robusta de la autenticidad del email. Si los tres mecanismos pasan, el email probablemente fue enviado legitimamente desde el dominio declarado. Si alguno falla, se requiere investigacion adicional.

Analisis de ficheros EML y MSG

Formato EML

EML es un formato de texto plano que contiene el email completo: cabeceras, cuerpo y adjuntos codificados en Base64. Es el formato estandar (RFC 5322) y puede abrirse con cualquier editor de texto para leer las cabeceras directamente.

# Ver cabeceras de un fichero EML
head -100 evidencia.eml

# Extraer adjuntos con munpack
munpack evidencia.eml

# Analizar con emlAnalyzer (Python)
pip install eml-analyzer
emlAnalyzer -i evidencia.eml --header --text --html --attachments

Formato MSG

MSG es el formato propietario de Microsoft Outlook. Es un fichero binario basado en el formato de almacenamiento compuesto de Microsoft (OLE). Para analizarlo se necesitan herramientas que entiendan este formato:

# Convertir MSG a EML con msgconvert (Perl)
msgconvert evidencia.msg

# Extraer metadatos y adjuntos con msg-extractor (Python)
pip install extract-msg
python -m extract_msg evidencia.msg

Analisis de adjuntos sospechosos

Los adjuntos son el payload mas comun en ataques de phishing. El analisis debe realizarse en un entorno aislado (sandbox o maquina virtual sin acceso a red).

Antes de abrir o ejecutar cualquier adjunto, calcula su hash SHA256 y consultalo en plataformas de inteligencia como VirusTotal o MalwareBazaar para identificar si es malware conocido.

Los tipos de adjuntos mas peligrosos incluyen:

Documentos Office con macros (.docm, .xlsm, .doc, .xls). Usa olevba (de oletools) para extraer y analizar el codigo VBA sin ejecutar el documento.

Ficheros comprimidos (.zip, .rar, .7z) que contienen ejecutables. Especialmente sospechosos si estan protegidos con contrasena (la contrasena suele estar en el cuerpo del email para evadir el escaneo antivirus del servidor de correo).

Ficheros HTML (.html, .htm) que pueden contener JavaScript malicioso para robo de credenciales o redireccion a paginas de phishing.

Ficheros ISO y IMG que contienen ejecutables. Este vector se popularizo despues de que Microsoft bloqueara las macros por defecto en documentos descargados de Internet.

Shortcuts (.lnk) que ejecutan comandos PowerShell o descargan payloads.

# Analizar macros en documentos Office
olevba documento_sospechoso.doc

# Calcular hash SHA256 del adjunto
sha256sum adjunto_sospechoso.exe

# Consultar hash en VirusTotal (requiere API key)
curl -s "https://www.virustotal.com/api/v3/files/SHA256HASH" \
  -H "x-apikey: YOUR_API_KEY"

Analisis de URLs en el cuerpo del email

Los emails de phishing contienen URLs que redirigen a paginas de robo de credenciales, descargas de malware o paginas de exploit. El analisis de URLs requiere precaucion para no acceder a contenido malicioso.

Busca discrepancias entre el texto visible del enlace y la URL real. En HTML, el texto del enlace puede decir "banco.es" pero la URL apuntar a "banco-es-login.malicious.com".

Verifica las URLs sospechosas en plataformas como VirusTotal, URLScan.io o PhishTank sin acceder directamente a ellas.

Identifica tecnicas de ofuscacion comunes: acortadores de URL (bit.ly, tinyurl.com), codificacion de caracteres (punycode para dominios homograficos), y redirectores abiertos en sitios legitimos (por ejemplo, redireccion a traves de Google, LinkedIn u otros servicios).

Para analizar el contenido de la URL de forma segura, usa herramientas como urlscan.io que renderizan la pagina en un sandbox y proporcionan capturas de pantalla, DOM, conexiones de red y verdicts de seguridad.

Logs del servidor de correo

Ademas del email en si, los logs del servidor de correo proporcionan informacion complementaria:

Logs de Exchange (Windows): en el directorio de logs de Exchange, con informacion detallada de cada transaccion SMTP, incluyendo IPs de origen, resultados de autenticacion y disposicion del mensaje.

Logs de Postfix (Linux): /var/log/mail.log, con cada transaccion SMTP documentada con su queue ID, remitente, destinatario, tamano y resultado de la entrega.

Microsoft 365: los message trace logs estan disponibles en el portal de administracion y via PowerShell (Get-MessageTrace), con retencion de 90 dias para traza basica.

Google Workspace: el Admin Console proporciona logs de email con filtrado por remitente, destinatario, asunto y disposicion.

# Buscar entregas de un remitente especifico en Postfix
grep "[email protected]" /var/log/mail.log

# Buscar emails por Message-ID
grep "Message-ID-del-email" /var/log/mail.log

Preservacion de evidencia de email

La preservacion correcta del email como evidencia es critica, especialmente si el caso puede tener consecuencias legales.

Exporta el email completo en formato EML o MSG con todas las cabeceras. No uses copiar/pegar del cuerpo del email, ya que pierdes los metadatos.

Calcula el hash del fichero exportado (SHA256) y documentalo en la cadena de custodia.

No modifiques el email original en el servidor. Si necesitas preservar el buzon completo, usa herramientas como mailbox_export.py o la funcionalidad de eDiscovery de Microsoft 365/Google Workspace.

Documenta el contexto: quien reporto el email, cuando lo recibio, si hizo click en algun enlace o abrio algun adjunto, y las acciones que tomo despues de recibirlo.

Preserva los logs del servidor de correo para el periodo relevante, ya que proporcionan la vista del lado del servidor que complementa el email en si.

Caso practico: investigacion de phishing

Un usuario reporta un email sospechoso que dice ser de su banco pidiendo actualizar sus credenciales. El analisis forense sigue estos pasos:

Primero, exportar el email completo en formato EML y calcular su hash.

Segundo, leer las cabeceras Received de abajo hacia arriba. La primera cabecera Received muestra que el email vino de un servidor con IP 45.33.xx.xx que no pertenece al banco. El campo from dice "banco.es" pero la IP no esta en los registros SPF del dominio.

Tercero, verificar Authentication-Results: SPF fail, DKIM absent, DMARC fail. El email no fue enviado desde la infraestructura del banco.

Cuarto, analizar el cuerpo HTML. El enlace "Acceder a mi cuenta" apunta a hxxps://banco-es-verificar.evil[.]com/login, un dominio registrado hace 3 dias.

Quinto, verificar la URL en URLScan.io. La pagina es un clon del portal de banca online con un formulario que envia las credenciales a un servidor controlado por el atacante.

Sexto, documentar todos los hallazgos con timestamps y generar los IOCs: IP del servidor emisor, dominio de phishing, URL completa del formulario, hash del email, y hash de cualquier adjunto.

Conclusion

El analisis forense de email combina la interpretacion de metadatos tecnicos (cabeceras SMTP, verificaciones de autenticacion) con el analisis de contenido (URLs, adjuntos, tecnicas de ingenieria social). La mayoria de los incidentes de phishing dejan suficientes artefactos para determinar el origen del ataque, los IOCs asociados y el alcance del compromiso.

La clave esta en preservar correctamente la evidencia, leer las cabeceras con ojo critico (recordando que pueden ser falsificadas), y correlacionar los hallazgos del email con los artefactos del sistema (historial del navegador, descargas, ejecucion de programas) para determinar si el ataque fue exitoso.