El dominio está suplantado: la respuesta al incidente, paso a paso

Las primeras horas: recopilar pruebas, medir el alcance

La tentación de las primeras horas es actuar de inmediato sobre el DNS. El orden correcto es el inverso: primero congelar las pruebas y tomar la medida, después tratar — unas horas de recopilación no agravan el incidente, pero unas pruebas perdidas no se recrean.

Las pruebas. Lo que cuenta son ejemplares completos de los mensajes fraudulentos, cabeceras incluidas — no capturas de pantalla. El reflejo útil: pedir a los destinatarios que se quejan que devuelvan el mensaje como adjunto (formato .eml), porque un reenvío simple destruye las cabeceras originales. De cada ejemplar se extraen tres elementos: la cadena Received (el camino real del mensaje), el campo Authentication-Results (los veredictos SPF, DKIM y DMARC del receptor) y las URL o adjuntos del contenido, que alimentarán las solicitudes de retirada y los avisos de abuso. Los informes agregados del periodo se conservan igualmente, junto con un registro de incidente con marcas de tiempo: quién vio qué, cuándo, y qué se decidió.

El alcance. Las quejas cuentan anécdotas; los informes agregados dan la única vista de conjunto. Responden a las preguntas que estructuran la respuesta: ¿desde cuándo corre la campaña? ¿Desde qué direcciones IP, con qué volumen, hacia qué proveedores de recepción? ¿Apunta al dominio principal o a un subdominio? Un pico de diez mensajes en fallo no pide la misma respuesta que una ola de cien mil. Esa medición calibra todo lo que sigue — la comunicación incluida.

El tratamiento: el incidente es el argumento del endurecimiento

Para una suplantación directa, el tratamiento de fondo cabe en una frase: llevar la política DMARC del dominio a la aplicación efectiva. Un dominio en p=none observa y no bloquea nada; los mensajes fraudulentos siguen llegando a los buzones. Si la organización vivía con un proyecto «algún día, p=reject» sin fecha, el incidente acaba de poner la fecha.

Acelerar no exime del método. Antes de endurecer, los informes agregados deben confirmar que las fuentes legítimas — plataforma de marketing, facturación, correo corporativo — pasan SPF o DKIM con alineación: endurecer a ciegas bloquearía el correo legítimo en plena crisis, el peor momento posible. Pero en situación de incidente el calendario se comprime: paso rápido a p=quarantine para mandar el flujo fraudulento a spam, y después a p=reject en cuanto los informes confirmen que las fuentes reales aguantan. El estándar vigente (DMARCbis) proporciona las herramientas de esa progresión: el modo de prueba t=y para señalar una política en rodaje, la etiqueta sp= para cubrir los subdominios y np= para cerrar de oficio los subdominios inexistentes, blanco frecuente de los atacantes. El método completo, fuera del contexto de urgencia, se despliega en llegar a p=reject sin romper el correo.

Se impone una dosis de honestidad: DMARC solo bloquea la suplantación directa, y solo en los receptores que lo evalúan — casi todos los grandes proveedores de consumo, solo una parte de los servidores de correo corporativos. Y si el dominio ya estaba en p=reject en el momento de los hechos, el diagnóstico cambia: o la campaña pasa por un dominio primo (vuelta a la calificación), o un mensaje fraudulento que pasa DKIM revela una clave comprometida — el asunto de la higiene de secretos, más abajo.

Comunicar: en interno, a los clientes, al banco, a la justicia

Una suplantación ataca la confianza más que la infraestructura; la comunicación forma por tanto parte del tratamiento, graduada según la gravedad.

Primero en interno. El soporte y la recepción necesitan un guion antes de que lleguen las llamadas: una respuesta tipo, factual, que reconozca la campaña en curso e indique cómo se reconocen los mensajes auténticos. La dirección se informa pronto — sobre todo si hay pagos en juego.

Después los clientes y socios, si la campaña les apunta. El aviso sale por un canal distinto del canal suplantado cuando es posible, sin enlaces clicables (un aviso plagado de enlaces parece a la vez phishing), con dos mensajes simples: la empresa nunca pide ese tipo de acción por correo, y todo mensaje dudoso se verifica por un canal conocido.

El banco, sin demora, si la campaña afecta a transferencias o facturas — el escenario clásico del fraude del CEO y del IBAN falsificado. Si un pago fraudulento ya ha salido de la cuenta de un destinatario engañado, cada hora cuenta para un intento de retrocesión.

La justicia y las autoridades, según la gravedad. Una ola de phishing genérico se notifica (en España, a través del canal de ayuda de INCIBE o de su línea 017); un perjuicio económico o un ataque grave a la marca justifica una denuncia ante la Policía Nacional o la Guardia Civil, que el expediente de pruebas montado más arriba hará admisible. Un punto de RGPD a menudo mal entendido: la suplantación del dominio, por sí sola, no es una violación de datos personales de la organización suplantada — la notificación a la autoridad de protección de datos en 72 horas solo procede si el incidente revela un compromiso interno (buzón pirateado, base de contactos exfiltrada).

La higiene de secretos tras el incidente

Una pregunta técnica decide esta etapa: ¿pasaban los mensajes fraudulentos DKIM con un selector legítimo del dominio? Si es así, el asunto va más allá de la suplantación — una clave privada se ha filtrado, o un sistema autorizado a firmar está comprometido. La rotación de emergencia es obligada: clave nueva bajo un selector nuevo, cambio de la firma, y después revocación del selector antiguo publicando un registro p= vacío, que invalida cualquier firma que todavía lo invoque.

Incluso sin prueba de fuga, un incidente serio justifica una revisión de los secretos que gobiernan la identidad de envío: claves privadas DKIM, credenciales de la cuenta DNS (que permiten publicar o sabotear SPF, DKIM y DMARC), tokens de API de las plataformas de envío, contraseñas SMTP. Un acceso DNS comprometido es el escenario más grave — el atacante publica allí registros propios y firma «legítimamente». Si se sospecha un compromiso interno, todos esos secretos rotan, empezando por aquellos cuyo uso sugieren los informes.

DMARC.com está editado por Hucency, especialista en ciberseguridad; para centralizar este tipo de secretos — claves privadas DKIM, credenciales DNS, tokens de API — y orquestar su rotación tras un incidente, existe Hucency Vault. Una respuesta al incidente sin cofre termina demasiado a menudo con claves regeneradas… guardadas en el mismo sitio del que se filtraron las anteriores.

La salida del incidente: vigilancia, post-mortem, trayectoria

Un incidente no termina cuando cesan las quejas; termina cuando tres cosas están en su sitio.

La vigilancia reforzada. Las campañas vuelven — misma infraestructura, nuevo pretexto. Durante varias semanas, los informes agregados se releen con cadencia corta, con una alerta sobre toda nueva fuente desconocida. La caída del volumen en fallo DMARC tras el paso a la aplicación es además la métrica de éxito: documenta, con cifras, que el tratamiento funcionó.

El post-mortem. Una página basta: cronología, vector, alcance medido, qué funcionó, qué faltó. En la mayoría de los casos la conclusión cabe en una línea — el dominio pasó años en p=none, y el incidente no hizo más que explotar una puerta conocida y dejada abierta. Esa constatación, fechada y compartida, es lo que impide volver al statu quo una vez que baja la tensión.

La trayectoria. La política endurecida durante la crisis se convierte en el estado permanente: p=reject en el dominio, subdominios cubiertos, dominios durmientes cerrados. Queda verificar con regularidad que la protección aguanta — el planteamiento descrito en comprobar si un dominio es suplantable convierte ese control en rutina, junto con la revisión periódica de los dominios primos recién registrados alrededor de la marca.

En resumen

Una suplantación de dominio se reconoce por la convergencia de tres señales — quejas de destinatarios, fallos DMARC que explotan en los informes agregados, retornos NDR en masa. La calificación lo decide todo: la suplantación directa se trata con DMARC, el dominio primo con la retirada y la denuncia. Las primeras horas sirven para congelar las pruebas (mensajes completos en .eml, cabeceras, informes) y medir el alcance; el tratamiento de fondo consiste en acelerar hacia la aplicación — p=quarantine y después p=reject — apoyándose en los informes para no romper nada legítimo. La comunicación se gradúa del guion interno a la denuncia, la rotación de las claves DKIM y de las credenciales DNS es obligada a la menor sospecha de compromiso, y la salida del incidente combina vigilancia reforzada, post-mortem escrito y una política endurecida con carácter permanente.

El primer reflejo, incluso antes del primer aviso, lleva unos minutos: un análisis DMARC gratuito muestra si el dominio bloquea de verdad la suplantación directa o solo lo aparenta. Y para seguir los informes agregados, detectar pronto la próxima campaña y pilotar la trayectoria hacia p=reject, crear una cuenta pone en marcha la vigilancia que faltaba en el momento del incidente.