Spoofing y compromiso del correo corporativo: dos amenazas distintas

Tres términos, tres alcances — y ninguno que abarque el conjunto

El problema es que cada uno de estos términos nombra una porción distinta de la amenaza, y ninguno la cubre por completo.

• «Fraude del CEO» nombra un único escenario: la suplantación de un directivo. Deja fuera la factura falsa de proveedor, que es de hecho la variante más frecuente en volumen, y el fraude de datos bancarios de nómina.
• «Compromiso del correo corporativo», traducción literal de Business Email Compromise, sugiere que el buzón ha sido pirateado. A veces es cierto — pero es el vector más raro de los tres. El término describe así la excepción como si fuera la regla.
• Las denominaciones puramente financieras, como el término institucional francés FOVI, retienen solo el resultado económico y excluyen por construcción las variantes que buscan datos en lugar de un pago.

Esta imprecisión tiene un coste operativo directo. Hace creer que basta con una única contramedida: que desplegar DMARC cierra el asunto, o que formar al equipo contable lo cierra igualmente. Ambas afirmaciones son falsas tomadas por separado, y la segunda resulta más peligrosa que la primera porque es más difícil de medir.

Los tres vectores, y el que DMARC detiene

Un ataque de esta familia toma uno de estos tres caminos. DMARC los trata de forma radicalmente distinta, y ese es el punto que la confusión de vocabulario oculta.

Primer vector — el dominio suplantado. El atacante envía desde una dirección que muestra exactamente el dominio legítimo. Esto es spoofing en sentido estricto, y DMARC en política de aplicación lo detiene. El mensaje falla la alineación y se rechaza antes de alcanzar la bandeja de entrada. No se solicita ninguna vigilancia humana, porque nada llega.

Segundo vector — el dominio parecido. El atacante registra un dominio visualmente similar y publica en él sus propios registros SPF y DKIM. El mensaje queda perfectamente autenticado — para ese dominio. DMARC no lo rechaza, ni tiene motivo para hacerlo: el protocolo verifica que un remitente tenga derecho a escribir en nombre del dominio que anuncia, no que ese dominio se parezca a otro. La defensa recae aquí en la vigilancia de los registros próximos, tratada entre las prioridades de protección frente a la suplantación.

Tercer vector — la cuenta realmente comprometida. El atacante dispone de las credenciales de un buzón legítimo, obtenidas a menudo mediante un phishing previo o reutilizando una contraseña filtrada en otro sitio. El mensaje sale de la infraestructura autorizada, firmado con las claves correctas, desde el dominio correcto. SPF pasa, DKIM pasa, DMARC pasa — porque el envío es auténticamente legítimo. El protocolo funciona exactamente como se diseñó; es la cuenta la que ya no lo es.

Este tercer caso es el que da su nombre inglés a toda la familia, aunque constituye su minoría. Su defensa no pertenece a la autenticación de dominio sino a la higiene de accesos: autenticación multifactor en los buzones expuestos, detección de conexiones anómalas y gestión centralizada de secretos en lugar de credenciales dispersas por archivos de configuración y canales de conversación. Una caja fuerte dedicada como Hucency Vault, editada por el especialista en ciberseguridad Hucency, cubre esa necesidad al situar credenciales y tokens bajo acceso controlado y registrado.

Distinguir los tres después de un incidente

La distinción no es meramente conceptual: determina la respuesta. Y los tres vectores dejan rastros diferentes, lo que permite separarlos a posteriori.

Un dominio suplantado aparece en los informes agregados de DMARC como una fuente en fallo — una dirección IP que envía en nombre del dominio sin superar la alineación. Es el vector que el informe agregado fue diseñado para revelar — con una condición que la fórmula «basta con leer los informes» pasa por alto: la recolección tiene que existir. Sin etiqueta rua publicada en el registro DMARC, y sin destinatarios dispuestos a emitir informes, el intento no deja ninguna huella consultable. El diagnóstico nombra ese caso de forma explícita: un dominio con política publicada al que no vuelve ningún informe es ciego a su propia suplantación.

Un dominio parecido no deja ningún rastro en esos informes, por una razón sencilla: es otro dominio, y sus propios informes van a parar a quien lo registró. La detección pasa por la vigilancia de los registros, o por el mensaje mismo en cuanto un destinatario lo reporta. El recorrido de las cabeceras muestra entonces un dominio que se autentica limpiamente pero no es aquel que imita — por eso leer las cabeceras de un mensaje sospechoso zanja la cuestión más rápido que cualquier conjetura sobre el remitente.

Una cuenta comprometida es la más difícil de detectar desde la capa de correo por sí sola, precisamente porque todo lo que produce es válido. Las señales están en otra parte: una conexión desde una ubicación inhabitual, una regla de buzón creada para ocultar respuestas, un mensaje saliente sin elemento correspondiente en la carpeta de enviados de su supuesto autor. Los informes agregados, en cambio, mostrarán el envío como legítimo y alineado — porque lo es.

La consecuencia práctica es que una organización que detecta un intento de fraude no debería concluir que su postura DMARC ha fallado. En dos de cada tres casos, la postura funcionó exactamente como se especificó, y el ataque simplemente no pasó por la puerta que vigila.

Qué cambia la distinción para un dominio ya en p=reject

La constatación resulta incómoda, pero conviene enunciarla con claridad: una política DMARC en p=reject cierra un vector de cada tres. Es considerable — se trata del vector más fácil de explotar, el más barato para el atacante y el que permite campañas a gran escala. Cerrarlo elimina el fraude oportunista y obliga al atacante a invertir más.

Pero la afirmación «el dominio está en p=reject, luego el fraude de transferencias está resuelto» no se sostiene. Los otros dos vectores siguen abiertos, y son precisamente aquellos a los que recurre un atacante metódico una vez cerrado el primero. Desplegar DMARC desplaza la amenaza hacia arriba en lugar de suprimirla.

De ello se derivan dos consecuencias prácticas. Por un lado, las defensas organizativas — validación por dos personas a partir de un umbral, verificación de los cambios de datos bancarios por un canal independiente del correo electrónico — no son un complemento opcional a DMARC: cubren la parte que la autenticación no puede alcanzar estructuralmente. Por otro, la vigilancia de los registros de dominios parecidos se convierte en la prolongación natural de un despliegue culminado, puesto que ahí es donde se traslada la actividad.

Un último punto merece mención: las señales de alerta basadas en una redacción torpe han perdido fiabilidad. Las herramientas generativas producen hoy mensajes en un castellano impecable, calcado del estilo público de la persona suplantada. Las señales que sobreviven son estructurales — urgencia, confidencialidad, petición explícita de saltarse un procedimiento — porque son inherentes al fraude mismo: el estilo se pule indefinidamente, la petición no se puede retirar.

El sentido inverso tampoco se cumple: no todo spoofing busca un pago

Buena parte de los usos del spoofing nada tiene que ver con el fraude de transferencias: campañas de phishing genéricas enviadas a decenas de miles de destinatarios para recolectar credenciales, suplantación de marca con fines de perjuicio, distribución de programas maliciosos al amparo de un remitente conocido.

Estos usos comparten la misma técnica y reclaman la misma contramedida — la autenticación del dominio — pero pertenecen a una economía distinta: el volumen en lugar de la selección del objetivo. Un dominio desprotegido los sufre sin que jamás se solicite transferencia alguna, y el perjuicio se mide entonces en reputación de remitente y en entregabilidad degradada para el correo legítimo.

Dos capas, dos tratamientos

Devolver estas nociones a su alcance exacto produce una arquitectura de defensa legible. El spoofing se trata en la capa técnica, mediante la autenticación del dominio, y ese tratamiento es objetivamente verificable: una política publicada, una alineación medida, informes agregados que confirman el resultado. El compromiso del correo corporativo se trata en la capa organizativa, mediante procedimientos de validación que no dependen de ninguna confianza otorgada a un mensaje.

Ninguna de las dos capas vuelve superflua a la otra. La primera elimina el fraude masivo y encarece el segundo; la segunda cubre lo que la primera no puede ver. Definirlas con precisión, como hace el glosario de la autenticación del correo, es el requisito previo a cualquier decisión sensata de inversión en la materia.

El estado de la primera capa se constata de inmediato: pasar el dominio por un analizador DMARC gratuito indica la postura publicada — política DMARC, registro SPF, selectores DKIM detectados. La comprobación lee el DNS, y solo el DNS: las fuentes que emiten realmente en nombre del dominio solo se leen en los informes agregados, es decir una vez implantada la recolección. La postura así medida se compara después con la del sector en el Observatorio DMARC. La segunda capa, en cambio, no se mide desde fuera — se audita internamente, y ahí es donde suele aparecer la brecha más amplia.