La mayoría de las campañas que cubrimos pasan DMARC evitándolo por completo, tomando prestada una bandeja comprometida, un token de OAuth o el grupo de envío de un ESP reputado. El proveedor de seguridad de correo IRONSCALES documentó algo estructuralmente distinto: un correo de phishing contra un distrito escolar de Estados Unidos que pasó SPF, DKIM y DMARC para adobe.com porque la propia infraestructura de Adobe lo envió genuinamente. Sin suplantación, sin dominio parecido, sin reputación prestada. Solo una función legítima del producto, apuntada hacia un objetivo.
Una Función Real de Adobe, Dirigida por un Atacante
Adobe Acrobat permite que cualquier titular de cuenta comparta un documento y active una notificación automática hacia la dirección que escriba. Un atacante usó esa función exactamente como fue diseñada. Subió un archivo llamado EDITABLERollandReadPhonicsMathFactsTargetedInstruction-1, un nombre construido para leerse como un recurso curricular legítimo de K-12, y lo compartió con personal de todo un distrito escolar. El sistema de Adobe envió la notificación resultante desde [email protected], enrutada a través de la infraestructura de Amazon SES que Adobe está autorizada a usar para enviar, y firmada con la propia clave DKIM de Adobe. Cada verificación técnica que ejecuta un servidor de correo receptor salió limpia, porque cada una de esas verificaciones respondía la pregunta para la que fue diseñada: ¿autorizó adobe.com este mensaje? Lo había hecho.
Cada Enlace También Apuntaba a Adobe
El correo tampoco llevaba una URL externa sospechosa. El llamado a la acción principal y los enlaces de apoyo se enrutaban todos a través de postoffice.adobe.com/po-server/link/redirect, con el destino real codificado dentro de un JWT firmado con HS512 en el parámetro target de la URL. Una puerta de enlace que revisara la reputación de enlaces veía el propio dominio de redirección de Adobe y no tenía ningún indicador estático que marcar, porque el destino malicioso estaba oculto dentro de un token codificado en lugar de expuesto en texto plano. Entre una identidad de remitente genuina y un host de redirección con apariencia genuina, al mensaje no le quedaba nada que un control basado en firmas o en autenticación pudiera detectar.
Lo Que Realmente lo Detectó
IRONSCALES marcó el mensaje por señales de comportamiento y contexto en su lugar: era un remitente por primera vez hacia estos destinatarios, el nombre del documento coincidía con el rol profesional del objetivo con una precisión que se leía como diseñada más que incidental, y los patrones de lenguaje en la notificación eran consistentes con ingeniería social en lugar del texto automático típico de Adobe. Los datos de amenazas de la comunidad aportaron la pieza final, mostrando que el mismo señuelo ya había sido puesto en cuarentena en otras organizaciones. Combinadas, esas señales produjeron una clasificación de phishing con un 78 por ciento de confianza. Cuatro bandejas del distrito recibieron el mismo mensaje; las cuatro fueron mitigadas, y no se robó ninguna credencial.
Qué Significa Esto Para Tu Programa
Un paso limpio de SPF, DKIM y DMARC te dice quién autorizó el mensaje, no si la propia plataforma de ese remitente fue usada en tu contra. Adobe no falló aquí. Su autenticación fue precisa. La brecha está una capa más arriba, en lo que se le permite hacer a un titular de cuenta legítimo con una función legítima.
Cualquier servicio que permita a un titular de cuenta activar una notificación hacia una dirección arbitraria es un canal de entrega que un atacante puede alquilar gratis. Las herramientas de compartir documentos, las plataformas de firma electrónica, las invitaciones de calendario y las notificaciones de colaboración caen todas en esta categoría, y todas se autenticarán de forma limpia porque la propia plataforma es el remitente registrado.
La detección basada en comportamiento no es una capa de lujo sobre la autenticación. En mensajes como este, es la única capa que tiene alguna oportunidad. Una alerta de remitente por primera vez, un nombre de documento demasiado preciso y la comparación de patrones entre distintas organizaciones hicieron el trabajo que SPF, DKIM y DMARC no podían hacer estructuralmente.
Tus reportes agregados de DMARC no revelarán este patrón, porque no hay nada que revelar. El mensaje fue autorizado, correctamente, por el dominio que dice representar. Este es un problema de detección y concientización que se ubica más adelante que la propia postura de autenticación de tu dominio, no una brecha en ella.
La Conclusión
DMARC responde bien una pregunta: ¿está este mensaje autorizado por el dominio que dice representar? Aquí, la respuesta honesta fue sí, y el mensaje seguía siendo un intento de robo de credenciales construido para parecer un archivo curricular que un empleado escolar abriría sin pensarlo dos veces. A medida que más herramientas de negocio cotidianas agreguen funciones de compartir y notificar, espera ver más de este patrón: atacantes que dejan de intentar vencer la autenticación y en su lugar empiezan a alquilarla, una función legítima a la vez.
DMARC te dice si el correo que dice venir de tu dominio fue realmente autorizado a enviarse. No puede decirte cuándo alguien abusa de las propias funciones legítimas de una plataforma confiable para llegar a tu gente, y por eso la visibilidad sobre tus propios flujos de correo autenticados sigue importando. Excello Mail te da una vista clara y continua de todo lo que envía en nombre de tu dominio, para que sepas que tu propia postura de autenticación es sólida mientras amenazas como esta siguen evolucionando en otros lugares. Regístrate gratis en Excello Mail y pon esa visibilidad en marcha.