Archivos de correo electrónico y análisis de encabezados

El correo electrónico constituye evidencia de comunicación: quién afirmó escribir a quién, cuándo, a través de qué sistemas y con qué archivos adjuntos. En un equipo se almacena en archivos de buzón que conservan los mensajes mucho después de que el usuario crea que han desaparecido, y cada mensaje recibido contiene un encabezado que registra su recorrido. Esta lección aborda los formatos de buzón presentes en los equipos Windows, cómo persisten los mensajes eliminados y cómo leer un encabezado para identificar la IP de origen, indicar horas fiables en UTC y determinar si el remitente es auténtico.

Almacenes de correo electrónico en el equipo

PST y OST de Outlook

Un PST (Personal Storage Table) es un archivo de buzón del Outlook clásico. Outlook 2003 introdujo el PST Unicode, que eliminó el límite de 2 GB del antiguo formato ANSI; el tamaño máximo predeterminado es de 50 GB a partir de Outlook 2010. Todos los archivos PST y OST comienzan con la firma de 4 bytes !BDN (21 42 44 4E) en el desplazamiento 0. En el desplazamiento 8, la firma del cliente SM identifica un PST y SO un OST; la versión de 2 bytes en el desplazamiento 10 es 14 o 15 en un archivo ANSI, mientras que los archivos Unicode usan 23 o una versión superior (los archivos OST de Outlook 2013 en adelante suelen mostrar 36, una variante con páginas de 4 KB). Una "contraseña" de PST no cifra los datos: el contenido, como máximo, está ofuscado con una codificación reversible que las herramientas de análisis deshacen sin la contraseña.

Un OST es la caché sin conexión de un buzón de Exchange o Microsoft 365 en el modo caché de Exchange. Está vinculado al perfil y a la cuenta de Outlook, por lo que Outlook no lo abre como archivo independiente, pero los analizadores forenses lo leen directamente. Un OST aún puede contener elementos que ya se han eliminado del servidor si el cliente no se sincronizó antes de la recopilación o si los datos permanecen en bloques no asignados. También puede estar incompleto, porque la caché puede abarcar únicamente un período reciente establecido mediante un control deslizante de sincronización.

El nuevo Outlook para Windows almacena los datos de otra manera y no utiliza los archivos OST como el Outlook clásico, así que confirme qué cliente se utilizaba antes de concluir que falta una caché de buzón. La lección 4.5 aborda los rastros del correo web y de las cuentas en la nube.

Perfiles de Thunderbird

Thunderbird guarda todo en %APPDATA%\Thunderbird\Profiles\<profile>\. Las cuentas POP y locales se encuentran en Mail\, y las cuentas IMAP en ImapMail\<server>\. Cada carpeta es un archivo MBOX sin extensión (Inbox, Sent), en el que cada mensaje comienza con una línea separadora que empieza por From (Thunderbird escribe From - seguido de una fecha). Las subcarpetas se encuentran en un directorio con el sufijo .sbd. Cada MBOX tiene un archivo .msf complementario, un índice (resumen) que Thunderbird puede reconstruir, por lo que no es el almacén de mensajes. Un mensaje eliminado inicialmente solo se marca como suprimido (bit 0x0008 del encabezado X-Mozilla-Status) y permanece dentro del MBOX hasta que se compacta la carpeta. El perfil también contiene global-messages-db.sqlite, el índice de búsqueda, que almacena asuntos, participantes y texto indexado del cuerpo y puede no reflejar de inmediato las eliminaciones recientes. Los perfiles configurados con el formato opcional maildir almacenan, en cambio, un archivo por mensaje.

Mensajes individuales: EML y MSG

Un archivo EML es un mensaje en el formato de texto de RFC 5322, con el encabezado y el cuerpo MIME exactamente como se transmitieron. Un archivo MSG es un elemento individual de Outlook guardado como archivo compuesto OLE (firma D0 CF 11 E0 A1 B1 1A E1). Sus propiedades son flujos con nombres como __substg1.0_<tag><type>; el encabezado de Internet original de un mensaje recibido es la propiedad 0x007D, por lo que debe buscar el flujo __substg1.0_007D001F (007D001E cuando la cadena se almacena como ANSI).

Mensajes eliminados

La eliminación en Outlook se produce por capas. Una eliminación normal mueve el elemento a Elementos eliminados, que sigue siendo una carpeta ordinaria. Vaciar esa carpeta, o pulsar Mayús+Supr, lo elimina del árbol de carpetas; en los buzones de Exchange y Microsoft 365, el servidor lo conserva después en la carpeta Elementos recuperables durante un período de retención, que es una fuente del lado del servidor a la que se accede mediante una solicitud legal o una exportación del entorno de Microsoft 365, y no desde el equipo. Dentro del PST o del OST, los bloques liberados no se borran de inmediato, por lo que los analizadores pueden recuperar elementos eliminados y huérfanos del espacio no asignado del PST. La herramienta pffexport de libpff, de código abierto, puede exportar elementos recuperados junto con los normales; readpst convierte el contenido de PST en archivos MBOX o EML; los visores comerciales de PST y las suites forenses de correo electrónico hacen lo mismo mediante una interfaz gráfica, y una copia de trabajo de un perfil de Thunderbird se puede revisar en el propio Thunderbird. Indique siempre qué método produjo cada mensaje.

Lectura del encabezado

RFC 5322 define el encabezado del mensaje. La mayoría de los campos los escribe el cliente del remitente y no demuestran nada sobre el origen.

La cadena Received

Cada servidor que acepta el mensaje añade un encabezado Received en la parte superior, por lo que el salto más reciente aparece primero y el recorrido se lee de abajo hacia arriba. Una línea típica tiene la forma from <claimed host> (<reverse DNS> [<IP>]) by <receiving host> with <protocol> id <queue ID>; <date>. El nombre después de from es el que anunció el sistema que se conectó y puede ser cualquiera; la IP entre corchetes la registró el servidor receptor a partir de la conexión TCP. La palabra del protocolo aporta más información: ESMTPS significa TLS y ESMTPSA significa que el cliente se autenticó, lo que identifica el salto de envío.

Localice el límite de confianza: el encabezado Received más bajo escrito por un servidor en el que confíe, normalmente el MX de la organización destinataria. La IP que registró es fiable. Todo lo que aparece debajo fue escrito por sistemas ajenos a su control y puede estar falsificado, por lo que debe tratar una IP de origen encontrada allí como una pista que debe corroborarse, por ejemplo, con los registros del proveedor. Convierta cada salto a UTC, calcule los retrasos y compruebe que las horas avancen; un retraso negativo de segundos es una desviación del reloj, mientras que uno de minutos u horas apunta a un reloj incorrecto, un mensaje en cola o un encabezado falsificado.

Resultados de autenticación: SPF, DKIM, DMARC y ARC

El servidor del destinatario registra sus comprobaciones en Authentication-Results (o en el encabezado más antiguo Received-SPF).

• SPF comprueba si la IP que se conecta puede enviar en nombre del dominio del remitente del sobre, lo que se muestra como spf=pass smtp.mailfrom=<address>. No dice nada sobre el campo From visible.
• DKIM verifica una firma en DKIM-Signature, donde d= es el dominio firmante y s= el selector; la clave pública se publica en <selector>._domainkey.<domain>. El resultado es dkim=pass o dkim=fail con header.d=.
• DMARC solo se supera si SPF o DKIM se supera y ese dominio está alineado con el dominio de From. Es el único de los tres que protege la dirección que ve el usuario.
• Los encabezados ARC (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, numerados i=1, i=2…) conservan los resultados anteriores cuando una lista de correo o un sistema de reenvío modifica el mensaje.

Los indicadores de phishing son un nombre para mostrar que imita una marca mientras que la dirección es distinta, From, Return-Path y Reply-To en dominios diferentes, y dmarc=fail.

Ejemplo resuelto: un mensaje de phishing

Un usuario de corp.example recibió un mensaje que parece proceder de un banco. El encabezado (de arriba hacia abajo) contiene:

Recorra la cadena de abajo hacia arriba y convierta las horas. UTC = hora local menos el desfase.

Las horas avanzan de forma coherente y el recorrido completo duró 41 s. El encabezado Date se convierte en 09:06:10 + 3 h = 12:06:10Z, 7 min 48 s antes del envío: un valor del lado del remitente correspondiente a un mensaje en cola o a un reloj desajustado, no una hora que deba informarse como la de recepción.

Límite de confianza. R2 es el primer encabezado escrito por el propio MX del destinatario, por lo que el origen registrado de forma fiable es 198.51.100.27. R3 y R4 fueron escritos por la infraestructura del remitente; R4 identifica 203.0.113.45 como el cliente que se autenticó (ESMTPSA), aparentemente desde una dirección privada detrás de NAT (HELO [192.168.1.23]). Informe de ella como la IP de origen declarada, pendiente de corroboración por parte del proveedor de bank-secure.example.

Conclusiones. Tanto SPF como DKIM se superan, pero para bank-secure.example. DMARC falla porque ninguno de los dominios está alineado con bank.example en From, y la política p=none del banco permitió que el mensaje pasara. Con las respuestas desviadas a una dirección de correo gratuito y un Message-ID de un VPS de alojamiento, la conclusión es: remitente suplantado, mensaje enviado a través de infraestructura controlada por el atacante y recibido por la organización a las 2026-03-03T12:14:37Z.

Estructura MIME y hashes de archivos adjuntos

Un mensaje con archivos adjuntos suele ser multipart/mixed: una parte es un multipart/alternative anidado con versiones text/plain y text/html del cuerpo, y cada parte adicional es un archivo adjunto con Content-Disposition: attachment; filename="invoice.pdf". Las partes están separadas por la cadena boundary declarada en Content-Type. Los archivos adjuntos binarios usan Content-Transfer-Encoding: base64, en el que cada 4 caracteres codifican 3 bytes, en líneas de un máximo de 76 caracteres. Calcule el hash de los bytes decodificados, nunca del texto base64: una parte PDF que comience por JVBERi0xLjcK se decodifica como %PDF-1.7 seguido de un salto de línea, y solo el SHA-256 del archivo decodificado coincidirá con el de una copia encontrada en otro lugar, como la carpeta Descargas o la carpeta temporal segura de Outlook (su ruta está en el valor del Registro OutlookSecureTempFolder).

Enfoque del examen: Prepárese para leer una cadena Received de abajo hacia arriba, convertir a UTC las horas de los saltos con distintos desfases y elegir entre la hora de recepción fiable y el encabezado Date. Debe poder identificar la primera IP fiable, explicar por qué SPF y DKIM pueden superarse mientras DMARC falla y calcular el hash de un archivo adjunto decodificado. Conozca la firma !BDN, las rutas predeterminadas de PST y OST, y que Thunderbird conserva las eliminaciones aún no purgadas en el MBOX hasta la compactación.

Puntos clave

• Los archivos PST y OST comienzan con !BDN; el OST es una caché vinculada al perfil que puede contener elementos ya eliminados del servidor, y los elementos eliminados se pueden recuperar de bloques PST no asignados.
• Thunderbird almacena un archivo MBOX por carpeta, con índices .msf y global-messages-db.sqlite; los mensajes eliminados permanecen en el MBOX hasta la compactación.
• Los encabezados Received se añaden en la parte superior, así que léalos de abajo hacia arriba y confíe únicamente en los saltos escritos por sus propios servidores.
• Informe de la recepción usando la hora Received del servidor de confianza en UTC; el encabezado Date es lo que declara el remitente.
• DMARC vincula SPF o DKIM con el dominio visible de From; superar SPF y DKIM para otro dominio no autentica al remitente.
• Calcule el hash de los archivos adjuntos después de decodificarlos de base64.