El Grupo de Inteligencia de Amenazas de Google (GTIG) publicó esta semana un informe que rastrea a tres grupos de piratería con presunto nexo ruso que ejecutan campañas de espionaje contra académicos, diplomáticos, profesionales de la industria de defensa y personal de centros de estudio en Europa, Ucrania y Estados Unidos. El informe merece leerse completo, pero el detalle que más importa a cualquiera que gestione un programa DMARC no es la atribución. Es lo poco que la autenticación de correo tiene que ver con todo esto.
Tres grupos, una misma idea de fondo
Google identifica a estos grupos como UNC6293 (un presunto subgrupo del colectivo conocido como APT29 o ICE RELIC), UNC7005 (también rastreado por Microsoft como Storm-2945) y UNC5976. Cada uno apunta a una población ligeramente distinta, desde académicos y diplomáticos en Estados Unidos y Europa hasta organizaciones de defensa y aeroespaciales en Ucrania y Armenia, pero comparten un mismo principio operativo: en lugar de luchar contra DMARC, SPF y DKIM para suplantar el dominio propio del objetivo, canalizan todo el ataque a través de flujos de autenticación que son completamente legítimos del lado receptor.
UNC6293 pide a sus objetivos que generen una contraseña de aplicación, una función heredada de Google pensada para dispositivos antiguos que no admiten el inicio de sesión completo, y que la entreguen. Una contraseña de aplicación evita la autenticación en dos pasos por diseño, así que en cuanto un atacante tiene una, el MFA deja de formar parte de la ecuación. Versiones posteriores de la campaña pidieron en cambio a los objetivos que introdujeran un “código de verificación” de OAuth en un sitio de phishing, saltándose el paso de compartir la contraseña pero llegando al mismo resultado: un token robado mediante un intercambio de autenticación completamente legítimo.
UNC7005 opera la gama más amplia de técnicas. Registró dominios que suplantaban al Finnish Operations Center, una organización de apoyo a la industria de defensa vinculada a trabajos cercanos a la OTAN, y envió correos de phishing desde esos dominios a contratistas de defensa europeos entre el 6 y el 13 de agosto. Las víctimas que hacían clic eran dirigidas a un proyecto de Google Cloud controlado por el atacante y en “modo de prueba”, suficiente para completar un flujo de consentimiento OAuth y robar el token resultante sin necesidad de mostrar jamás una página de inicio de sesión falsa. El mismo grupo ejecuta phishing de código de dispositivo de Microsoft contra asistentes a eventos, usando una página de destino que analiza el tamaño de pantalla, la zona horaria, el número de núcleos de CPU y las características del navegador del visitante específicamente para detectar y evadir el análisis automatizado de seguridad antes de mostrar un código de dispositivo de Microsoft real.
El detalle de WhatsApp
La técnica más llamativa del informe apunta a WhatsApp. UNC7005 creó páginas de phishing con temática de llamadas seguras y uso compartido de documentos, y las usó para iniciar una solicitud genuina de vinculación de dispositivo de WhatsApp y mostrar el código QR o el código de vinculación real en la página. Un objetivo que lo escanea acaba de autorizar a un dispositivo controlado por el atacante a acceder a su propia cuenta de WhatsApp, usando la función real de vinculación de WhatsApp exactamente como fue diseñada.
A partir de ahí, se muestra a las víctimas una pantalla falsa de llamada entrante. Aceptarla activa JavaScript que llama directamente a las API de cámara y micrófono del navegador, graba la señal y la sube a la infraestructura del atacante. Nada de esto toca un servidor de correo, un registro DNS o una etiqueta de autenticación. Es una página de phishing que abusa de una API del navegador y de la propia función de vinculación de una aplicación de mensajería, encadenada después de que un correo consiguiera que alguien hiciera clic en un enlace.
Por qué esto queda fuera del trabajo de DMARC
DMARC existe para responder a una sola pregunta: ¿vino realmente este mensaje de un servidor de correo autorizado por el propietario del dominio? Cumple bien esa función, y aplicarlo de forma estricta detiene una enorme proporción de la suplantación de dominios. Pero ninguno de estos tres grupos necesita suplantar el propio dominio del objetivo para tener éxito. Los correos del Finnish Operations Center de UNC7005 provienen de dominios similares recién registrados que el atacante controla por completo, así que por supuesto pasan sus propias comprobaciones de SPF, DKIM y DMARC. Que un dominio registrado por el atacante hace una semana pase DMARC no le dice absolutamente nada al receptor sobre su fiabilidad.
Más importante aún: en cuanto el objetivo hace clic, el resto del ataque nunca vuelve a tocar el correo electrónico. Una pantalla de consentimiento OAuth, una solicitud de código de dispositivo de Microsoft y una petición de vinculación de WhatsApp son todas interacciones autenticadas entre la víctima y la plataforma real, exactamente como esas plataformas las diseñaron para su uso legítimo. El informe de Google lo expresa con claridad: estas operaciones “abusan de flujos de autenticación legítimos que pueden no parecer de inmediato intentos de phishing para los usuarios”, y las cuentas atacadas suelen ser personales, no cuentas corporativas unidas a un dominio, lo que deja a los equipos de seguridad sin ninguna visibilidad organizacional sobre el compromiso.
Qué significa esto para tu programa
Aplicar DMARC en tu propio dominio no hace nada por impedir que tu gente sea víctima de phishing desde el dominio similar de otro. Estas campañas suplantan a organizaciones externas, organizadores de conferencias y agencias de apoyo, no al empleador del objetivo. Tu política DMARC protege el canal de correo de tu marca. No tiene ninguna jurisdicción sobre un dominio registrado la semana pasada para suplantar a un foro de defensa.
Trata las solicitudes no solicitadas de contraseñas de aplicación como un incidente, no como un ticket de soporte. Las contraseñas de aplicación evitan el MFA por diseño. La propia guía de Google indica que la mayoría de los usuarios nunca necesita crear una. Si un mensaje pide a un usuario que genere y comparta una contraseña de aplicación, bloquea de inmediato la difusión de esa instrucción e investiga.
Extiende tu hábito de verificación fuera de banda más allá del correo, hacia cualquier flujo de vinculación o consentimiento. Una pantalla de OAuth genuina, un código de dispositivo genuino y un código QR de WhatsApp genuino parecen genuinos porque lo son. La única comprobación fiable es confirmar, por un canal distinto, que la persona u organización que solicita la vinculación realmente envió esa solicitud.
Audita los dispositivos vinculados en las aplicaciones de mensajería igual que auditas los permisos de aplicaciones OAuth. La mayoría de los usuarios nunca ha abierto la pantalla de dispositivos vinculados de WhatsApp. Un recordatorio periódico para revisarla, junto con auditorías rutinarias de consentimiento OAuth en tu proveedor de identidad, cierra una brecha que el filtrado de correo nunca fue diseñado para cubrir.
La conclusión
DMARC, SPF y DKIM siguen siendo esenciales, y nada de esto cambia. Lo que cambia es el recordatorio de que un atacante bien financiado y paciente simplemente rodeará las partes de tu defensa que funcionan. Estos tres grupos no fallan las comprobaciones de DMARC porque nunca se colocan en una posición donde DMARC tenga voto. El correo es solo la puerta. Una vez que se abre, el resto de la operación se ejecuta enteramente sobre infraestructura legítima que los protocolos de autenticación nunca fueron diseñados para vigilar.
Excello Mail te ayuda a aplicar correctamente DMARC, SPF y DKIM en los dominios que controlas, para que el canal de correo que los atacantes realmente pueden falsificar quede bloqueado mientras tu equipo aprende a detectar los flujos de autenticación que quedan fuera de él. Regístrate gratis en Excello Mail y obtén visibilidad completa sobre quién está enviando correo como si fuera tu dominio.