El cliente llegó con un problema poco habitual: no estaba conforme con su propio informe pericial. Nos explicó el caso completo. Su empresa había emitido una factura por la venta de un producto, por un importe superior a los 100.000€, y la había enviado por correo electrónico al comprador. Cuando este recibió el correo y realizó la transferencia, resultó que el número de cuenta del PDF que tenía en su bandeja de entrada no coincidía con el que constaba en la factura original enviada por nuestro cliente: alguien, en algún punto de la cadena, había interceptado la comunicación y sustituido el documento por uno con una cuenta bancaria distinta. Un fraude BEC (Business Email Compromise) clásico, y una cantidad nada desdeñable.
La parte compradora, que había hecho el pago al número de cuenta fraudulento, contrató a dos peritos informáticos para elaborar un dictamen. Su conclusión: el correo que había llegado a la bandeja de entrada de nuestro cliente era, técnicamente, el correo correcto, y recomendaban repartir la responsabilidad económica entre ambas partes ("compartir gastos"). Nuestro cliente, no conforme con esa conclusión, encargó a su vez un informe contrapericial a otro perito, para que revisara tanto el dictamen contrario como el correo electrónico original. El resultado no fue el esperado: el informe contrapericial, en lugar de rebatir la primera pericial, le daba la razón y recomendaba, igualmente, repartir la responsabilidad.
Con dos informes coincidiendo en la misma conclusión, el cliente acudió a nosotros para una segunda revisión independiente.
Lo que decían los saltos de la cabecera (y lo que no contaban)
El primer paso fue repetir el análisis hop a hop de la cabecera técnica del correo: comprobar la secuencia completa de servidores por los que había pasado el mensaje, sus marcas de tiempo y sus direcciones IP. En ese nivel, todo estaba en orden — los saltos eran coherentes y no mostraban ninguna anomalía evidente. Hasta aquí, la misma conclusión a la que habían llegado los dos informes anteriores.
El detalle que ninguno de los dos dictámenes previos había explotado a fondo estaba en la firma DKIM de cada salto. DKIM es un mecanismo de autenticación que firma criptográficamente un correo en origen, y que cada servidor por el que pasa puede validar para comprobar que el contenido no se ha alterado en tránsito. Al revisar la validación de DKIM salto a salto, encontramos un patrón muy concreto: en todos los saltos correspondientes a la infraestructura de correo de nuestro cliente, la firma DKIM se validaba correctamente. El fallo de validación aparecía, exclusivamente, en un salto correspondiente al servidor de correo de la parte contraria.
La explicación que no se sostenía
Los dos informes previos habían dado por buena la explicación de que ese fallo de DKIM era un comportamiento habitual y esperable de determinados proveedores de correo corporativo, y que no debía interpretarse como un indicio de manipulación. Aquí es donde la revisión marcó la diferencia: si esa explicación fuera cierta —un simple efecto colateral del proveedor de correo—, el fallo de validación debería aparecer también, o incluso principalmente, en los saltos del lado de nuestro cliente, que usa exactamente ese mismo tipo de proveedor. Y no era el caso. La firma se mantenía íntegra en todo el recorrido por la infraestructura de nuestro cliente, y solo se rompía al entrar en los servidores de la parte contraria.
Ese matiz cambia por completo la lectura del caso: una firma DKIM que deja de validar en un punto concreto de la cadena no es ruido aleatorio, es la evidencia técnica de que el contenido del mensaje se alteró (o se sustituyó por un mensaje distinto) precisamente en ese punto. Y ese punto no estaba en la infraestructura de nuestro cliente, sino en la de quien recibía el correo. No podemos identificar aquí qué proveedor de correo era exactamente el de la parte contraria —el procedimiento sigue en curso—, pero sí podemos decir que es un proveedor ampliamente utilizado a nivel corporativo, lo que hace aún más relevante no dar por sentado que "ese tipo de fallos son normales en ese proveedor" sin comprobarlo hop a hop, como habían hecho los dos informes anteriores.
Conclusión
El informe pericial recogió la validación DKIM completa, salto a salto, contrastada con el comportamiento esperado en un correo no manipulado, y una conclusión razonada que contradecía a los dos dictámenes previos: la evidencia técnica no respaldaba un reparto de responsabilidad entre ambas partes, sino que situaba el punto de compromiso del correo dentro de la infraestructura de la parte receptora, no de la emisora.
El caso deja una lección clara para cualquier disputa de fraude BEC: dar por buena una explicación plausible ("esto es normal en tal proveedor") sin contrastarla salto a salto contra el propio comportamiento del otro extremo de la comunicación es, precisamente, el tipo de atajo que puede llevar a repartir una responsabilidad que en realidad no es compartida.