El campo que delata al impostor

Un correo de Business Email Compromise no se atrapa leyéndolo. Ese es el error de casi todo el entrenamiento anti-phishing: enseñar a desconfiar de la redacción, de la urgencia, de las faltas de ortografía. Sirve para el spam torpe, no para el fraude que importa. El cuerpo del mensaje es lo único que el impostor controla por completo, y lo va a escribir bien —el proveedor de siempre, el tono de siempre, la factura que efectivamente estabas esperando, con el número de cuenta cambiado en un solo renglón—. Toda la información que delata al impostor está afuera del texto, en un lugar que el usuario nunca abre: la cabecera.

El texto es lo único que el impostor escribe bien.

Conviene entender por qué el cuerpo es inútil como evidencia. Un atacante de BEC que ya comprometió o suplantó a un proveedor tiene tiempo, contexto y a veces el hilo de correos real. No necesita improvisar urgencia ni cometer errores de tipeo; puede responder dentro de una conversación existente y pedir que el próximo pago vaya a otra cuenta, con una naturalidad indistinguible de la legítima. Contra eso, “fíjate si suena raro” no es una defensa, es una ilusión de defensa. Lo que el atacante no controla con la misma facilidad es la maquinaria que transporta el mensaje, porque esa maquinaria estampa metadatos a su paso y no le pregunta a nadie si le conviene.

La cadena Received se lee de abajo hacia arriba, como una confesión.

Un correo no viaja de un punto a otro: salta por una cadena de servidores —el que lo envía, los relés intermedios, el que lo recibe— y cada salto agrega un bloque Received a la cabecera, arriba de los anteriores. El resultado es una pila en orden cronológico inverso: lo último que pasó queda arriba, lo primero abajo. Por eso se lee de abajo hacia arriba, como el testamento de alguien que no sabía que estaba confesando. El bloque más bajo es el origen real: la IP y el hostname de la máquina que de verdad inyectó el mensaje, antes de que ninguna marca conocida lo tocara. Ahí es donde el disfraz se cae. Un correo que en el From dice fedex.com pero cuyo Received más bajo confiesa haber salido de mailserver.footballticketnet.com, IP 95.211.214.81, no es de FedEx, por más logo que traiga. El campo que el usuario ve fue escrito por el atacante. El campo que el usuario nunca mira fue escrito por la infraestructura, que no tiene interés en mentir.

From, Return-Path, Reply-To: tres nombres que deberían coincidir.

Hay tres direcciones en juego y la gente conoce solo una. El From es la cara visible, la que el cliente muestra en negrita, y es trivial de falsificar —el SMTP la deja escribir casi cualquier cosa—. El Return-Path, también llamado Envelope-From, es la dirección oculta a la que vuelven los rebotes: el sistema la necesita real para que los errores de entrega lleguen a algún lado, así que suele traicionar el dominio verdadero del que envió. Y el Reply-To es el más delator de todos en un BEC, porque es donde va a parar tu respuesta cuando le das a “responder”: un correo que se muestra como del director financiero pero cuyo Reply-To apunta calladamente a un dominio lookalike —finanzas-empresaa.com con una letra de más, un .co en vez de .com— está diseñado para que tu contestación, con los datos que pida, aterrice en el buzón del atacante y no en el del jefe. Cuando esas tres direcciones no cuentan la misma historia, la discordancia es el hallazgo. El impostor cuidó la que se ve. Las otras dos lo venden.

SPF, DKIM, DMARC: ¿salió de donde dice?

Y encima de todo eso está el trío que contesta la pregunta de fondo de forma casi automática, si uno sabe leer un solo renglón. La cabecera Authentication-Results resume tres verificaciones que el servidor receptor ya hizo por ti. SPF pregunta si la IP que envió el correo está en la lista de las autorizadas a mandar en nombre de ese dominio —una lista que el dueño publica en su DNS, un registro tipo v=spf1 ip4:... -all—; si la IP no está, spf=fail, y eso significa que el correo salió de infraestructura no autorizada. DKIM verifica una firma criptográfica que el dominio legítimo estampa sobre el mensaje: el receptor busca la clave pública en el DNS del remitente, usando el selector que viene en la propia firma, y confirma que el contenido no fue alterado ni falsificado. DMARC ata los dos anteriores y exige alineación —que el dominio que pasó SPF o DKIM sea el mismo que figura en el From visible—, y le dice al receptor qué hacer si algo falla: p=quarantine para mandarlo a spam, p=reject para descartarlo de plano. Un correo legítimo moderno trae los tres en pass. El spoof de FedEx del ejemplo traía spf=fail y, más elocuente todavía, ni siquiera un bloque DKIM-Signature: no es que la firma fuera inválida, es que no había firma, porque el impostor no tiene la llave privada de FedEx y no la va a tener nunca. La ausencia de la firma es la respuesta.

La confianza es infraestructura, no intuición.

Todo esto desplaza la pregunta a un lugar más firme. “¿Le creo a este remitente?” es una pregunta sobre el texto, y el texto está fabricado para que le creas; no tiene respuesta confiable. “¿Este correo salió de donde dice salir?” es una pregunta sobre la infraestructura, y la infraestructura dejó registro: la IP de origen en el Received más bajo, la coincidencia o no del Return-Path, el veredicto de SPF/DKIM/DMARC en una línea. La confianza deja de ser una corazonada sobre la credibilidad de un mensaje y pasa a ser una verificación sobre la procedencia de un paquete. Es exactamente el mismo movimiento que en el token robado: no le preguntes a la cosa quién dice ser —cualquiera puede decir cualquier cosa—, pregúntale al contexto de dónde viene y si el camino cierra. Y se toca por el otro lado con el pretexto que entra por lo humano: el BEC ataca la misma superficie —la confianza en un remitente conocido— pero el defensor tiene acá algo que la víctima apurada no tiene, que son cuatro campos que no saben mentir.

El impostor puede escribir el correo perfecto. Lo que no puede escribir es la cabecera perfecta, porque buena parte de ella no la escribe él: la escriben los servidores que tocó al pasar, y la escribe el DNS de un dominio que no controla. El fraude vive en el único campo que la víctima lee. La verdad vive en los que no lee nadie. Todo el oficio es mudar la mirada de uno al otro.