Detectar una suplantación en los informes DMARC: el método

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>612</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>ejemplo.es</header_from>
  </identifiers>
</record>

Las firmas de una campaña de suplantación

Más allá de la línea aislada, las campañas reales dibujan patrones recurrentes en los informes.

La ráfaga corta. Una campaña de phishing se prepara, se dispara y se apaga: el volumen pasa de nada a cientos o miles de mensajes en 24 a 72 horas, y después vuelve a cero. Los flujos legítimos, en cambio, persisten. Una fuente aparecida el lunes y desaparecida el jueves no volverá a dar explicaciones.

Las IP residenciales y las botnets. En lugar de una gran dirección emisora, decenas o cientos de IP que envían cada una un puñado de mensajes, a menudo en rangos de operadores de consumo, dispersas geográficamente. Esa fragmentación es una firma en sí misma: ninguna infraestructura de envío legítima se parece a un enjambre.

Los destinatarios concentrados en un solo proveedor. Los informes RUA provienen de los proveedores de correo de los destinatarios. Cuando una campaña solo aparece en los informes de un único emisor de informes — únicamente Google, por ejemplo —, eso refleja una lista de direcciones comprada o robada, concentrada en ese proveedor. El tráfico legítimo, en cambio, se reparte entre todos los emisores habituales.

Los objetivos improbables. Envíos en nombre de subdominios que no existen — un facturacion.ejemplo.es jamás creado — delatan a un atacante que explora el perímetro. DMARCbis introdujo precisamente la etiqueta np= para endurecer el destino de los subdominios inexistentes sin tocar el resto de la política.

Los falsos positivos que parecen un ataque

Tres mecanismos perfectamente legítimos producen fallos DMARC, y confundirlos con una suplantación hace perder tiempo — o dispara una falsa alarma.

Los reenvíos. Un destinatario que redirige su correo hacia otro buzón reemite el mensaje desde una nueva IP: SPF falla mecánicamente. Pero si el mensaje no fue modificado por el camino, DKIM sobrevive al salto. Una línea spf=fail, dkim=pass alineada no es, por tanto, una suplantación: es la firma clásica de un reenvío.

Las listas de distribución. Modifican el mensaje — una etiqueta en el asunto, un pie de página añadido — y rompen DKIM además de SPF. El resultado es un doble fallo que se parece engañosamente a un ataque. Los indicios que salvan: volumen bajo y estable, IP constante de un operador de listas identificable, recurrencia semana tras semana — todo lo contrario de una ráfaga. Algunos receptores compensan mediante ARC y entregan de todos modos; el campo reason del informe conserva entonces la huella de esa decisión.

Las pasarelas y escáneres de seguridad. En algunas organizaciones receptoras, equipos de análisis detonan los adjuntos y reinyectan el mensaje internamente: este sale de una IP de pasarela, SPF falla y a veces DKIM también, si el contenido fue reprocesado. Estas fuentes se reconocen por su regularidad y por un volumen proporcional al correo realmente enviado hacia esa organización.

Zanjar lo ambiguo. Para los casos residuales, el nivel de detalle superior sería el informe forense, enviado mensaje a mensaje — pero los grandes proveedores apenas los emiten ya; la diferencia entre informes agregados y forenses explica por qué la detección descansa, en la práctica, sobre el RUA en solitario.

El método de triaje semanal

La detección no exige una sala de crisis; exige una rutina. Treinta minutos por semana bastan para un dominio establecido, en cinco pasadas siempre idénticas.

1. Primero, la tasa de alineamiento. La parte del volumen alineado sobre el volumen total, comparada con la semana anterior. Estable o al alza: nada urgente. A la baja: algo cambió, y el resto del triaje dirá qué.
2. Después, las fuentes nuevas. Cada IP aparecida desde la última lectura se clasifica en una de las tres poblaciones. Un proveedor conocido, un rango corporativo, un desconocido total: tres destinos distintos.
3. Los dobles fallos en detalle. Para cada línea fail/fail: volumen, perfil temporal, origen de red, lista de emisores de informes. Ráfaga más IP dispersas más un único emisor: el haz de indicios de una campaña está reunido.
4. El etiquetado. Cada fuente recibe un estado — legítima, por corregir, hostil, indeterminada — que se conserva de una semana a otra. Esa memoria es lo que hace rápida la rutina: solo lo nuevo exige análisis; el resto ya está juzgado.
5. La decisión. Una fuente por corregir entra en la lista de tareas de configuración; una campaña hostil constatada bajo p=none se convierte en un argumento fechado y cifrado para acelerar el endurecimiento.

A mano, sobre archivos XML comprimidos, esta rutina se vuelve penosa desde la segunda semana. Las herramientas de lectura de informes automatizan lo esencial — enriquecimiento de IP, etiquetado persistente, alerta ante fuentes nuevas — y reducen la cita semanal al examen de las únicas anomalías.

Lo que la política cambia en la lectura

La misma línea de informe no cuenta la misma historia según la política publicada.

Bajo p=none, la disposición se queda en none: cada mensaje suplantado contado en el informe fue entregado, salvo el filtrado antispam ordinario del receptor. La lectura es observación en sentido estricto: las líneas hostiles describen phishing llegado a los buzones. Es el periodo más incómodo — aquel en que los informes documentan la exposición sin reducirla —, y cada campaña detectada es una razón fechada para salir de él.

Bajo p=quarantine y luego p=reject, las mismas líneas cambian de naturaleza: disposition=quarantine o reject significa que los mensajes fueron apartados o rechazados. Los fallos se convierten en bloqueos; el informe, en un cuadro de caza. El volumen hostil rechazado se lee como una métrica de protección: cada ráfaga es una campaña abortada, sin víctimas del lado de los destinatarios. Un matiz: una línea disposition=none puede subsistir bajo p=reject cuando el receptor anuló la política localmente — una lista de distribución rehabilitada vía ARC, una regla interna —, y el campo reason documenta esa elección.

Nota de versión: el despliegue progresivo ya no pasa por la antigua etiqueta pct, desaparecida de DMARCbis; el modo de prueba se expresa ahora con la etiqueta t=, y la determinación del dominio organizativo se apoya en el DNS Tree Walk. Los registros v=DMARC1 existentes siguen siendo válidos tal cual.

Cuándo escalar a respuesta a incidentes

La rutina semanal basta mientras la suplantación siga siendo ruido de fondo — unos cuantos intentos oportunistas al mes forman parte de la vida normal de cualquier dominio visible. Tres umbrales justifican salir de la rutina.

El volumen. Una campaña que supera el tráfico legítimo del dominio, o que se mantiene varios días en lugar de apagarse, ya no es ruido: es una inversión del atacante y, por tanto, un ataque dirigido.

El objetivo. Informes concentrados en el proveedor que aloja precisamente a los clientes o socios de la organización, o una correlación con señales entrantes — respuestas de víctimas, llamadas al soporte, alertas internas — indican que la campaña golpea el ecosistema real, no direcciones al azar.

El contexto. Una ráfaga sincronizada con un evento de la organización — una campaña de facturación, un proceso de selección, un anuncio público — delata preparación, y la preparación anuncia una continuación.

En esos tres casos, la lectura ya no basta: hay que acelerar el calendario de endurecimiento, preservar los informes como elementos de prueba e informar a las partes expuestas. El procedimiento completo — calificación, comunicación, endurecimiento de urgencia — es el objeto de la respuesta a incidentes tras una suplantación. Y el mejor momento para plantearse la pregunta sigue siendo antes de la campaña: comprobar si un dominio es suplantable dice en unos minutos lo que los informes acabarían demostrando en varias semanas.

En resumen

Un informe RUA hace visible la suplantación, a condición de cribar. Las fuentes legítimas alineadas se vigilan; las legítimas mal configuradas se corrigen; los suplantadores — IP desconocidas en doble fallo SPF y DKIM, sin ninguna firma del dominio — solo se neutralizan mediante la política. Una campaña real se delata por su ráfaga corta, sus IP dispersas o residenciales y sus informes concentrados en un solo proveedor; los reenvíos, las listas de distribución y las pasarelas de seguridad producen fallos comparables sin ser ataques. La rutina semanal — alineamiento, fuentes nuevas, dobles fallos, etiquetado, decisión — convierte esa lectura en un reflejo, y la política publicada decide el sentido de las líneas: observación bajo p=none, bloqueo bajo p=reject. Más allá de cierto volumen, de un ataque dirigido confirmado o de una sincronización sospechosa, la detección cede el paso a la respuesta a incidentes.

El primer triaje puede empezar hoy: un paso del dominio por el análisis DMARC gratuito muestra de inmediato quién emite bajo ese nombre y sobre qué bases de autenticación. Para instalar la rutina en el tiempo — recogida de informes, enriquecimiento de fuentes, alertas ante ráfagas —, la creación de una cuenta pone el método aquí descrito en piloto continuo, hasta el día en que cada línea hostil se lea como un bloqueo y ya no como una amenaza.