El equipo de investigación Harmony Email de Check Point reveló una campaña de phishing construida sobre una premisa que debería preocupar a cualquiera que trate la autenticación como prueba de seguridad: los mensajes no estaban suplantados en absoluto. Los envió la propia infraestructura de Google, desde una dirección genuina de Google, usando una función legítima de Google Cloud exactamente como fue diseñada para usarse. Durante aproximadamente dos semanas, los atacantes lanzaron 9.394 correos de phishing contra unas 3.200 organizaciones objetivo en Estados Unidos, Europa, Canadá, Asia-Pacífico y América Latina, y todos y cada uno superaron las verificaciones de SPF, DKIM, DMARC y CompAuth de Microsoft sin fricción alguna.
Una función, no un fallo
La vía de abuso pasaba por el servicio Application Integration de Google Cloud, específicamente su tarea “Send Email”, una herramienta creada para automatización legítima de flujos de trabajo: notificaciones del sistema, alertas, mensajería interna rutinaria. Los atacantes configuraron esa tarea para dispararse hacia destinatarios externos arbitrarios, y cada mensaje que enviaba llevaba la dirección de remitente [email protected]. Esa dirección pertenece a Google. Está alojada en la infraestructura de correo de Google, firmada con la clave DKIM propia de Google, y enviada desde rangos de IP que el registro SPF de Google autoriza explícitamente. No había ningún dominio que falsificar, porque no hacía falta falsificar ninguno.
Los señuelos estaban construidos para encajar con el remitente: notificaciones de un nuevo correo de voz, un documento compartido a la espera de aprobación de acceso, una solicitud de permisos sobre un archivo. Mensajes ordinarios, de baja fricción, exactamente el tipo que un usuario de Google Workspace recibe varias veces por semana y hace clic sin pensarlo dos veces. El enlace dentro llevaba a una página de captura de credenciales diseñada para robar inicios de sesión de Microsoft 365, un detalle que convirtió la campaña en una operación genuinamente multiplataforma: la infraestructura de correo de Google entregando el señuelo, el ecosistema de Microsoft como el objetivo real.
Por qué cada capa de autenticación dijo que sí
DMARC verifica si el dominio en el encabezado From autorizó la infraestructura de envío que entregó el mensaje. Aquí, el encabezado From decía google.com, y los propios servidores de google.com hicieron el envío. SPF pasó porque la IP de origen estaba en la lista autorizada de Google, porque era una IP de Google. DKIM pasó porque la firma se generó con la clave privada real de Google, dentro de la infraestructura de firma real de Google. La alineación pasó porque no había ninguna discordancia en toda la cadena que detectar. El CompAuth de Microsoft, superpuesto para las organizaciones que usan Microsoft 365, llegó a la misma conclusión por la misma razón: nada respecto a la procedencia técnica del mensaje era fraudulento.
Este es un modo de fallo distinto al de los dominios parecidos o los buzones de terceros comprometidos, patrones que también han aparecido en campañas recientes. Esos ataques explotan una brecha entre lo que un dominio afirma y lo que realmente envió el correo. Este cierra esa brecha por completo, usando infraestructura a la que el atacante nunca debió tener acceso de escritura, una función de automatización legítima reutilizada como relé de correo para cualquiera que pudiera configurarla.
El patrón más amplio en el que encaja
Los investigadores de seguridad han señalado una categoría creciente de campañas que enrutan el phishing a través de los sistemas de notificación de las grandes plataformas en la nube en lugar de rodearlos. Una invitación de calendario, una alerta de unidad compartida, un correo de finalización de tarea, un aviso de correo de voz: todos estos son mensajes automatizados que las plataformas envían en nombre de un usuario, y todos heredan la confianza de autenticación completa de esa plataforma. Cuando un atacante encuentra la forma de activar uno de esos envíos automatizados hacia un objetivo de su elección, obtiene infraestructura de entrega que ningún nivel de aplicación de DMARC en el dominio propio de la víctima puede detener, porque el dominio de la víctima nunca estuvo involucrado.
Google ya ha restringido la vía de abuso en Application Integration y ha declarado que está tomando medidas adicionales para prevenir un mal uso similar. Eso cierra este agujero específico. No cierra la categoría. Cualquier plataforma en la nube con una función de “enviar una notificación a una dirección arbitraria” es candidata al mismo truco, y hay muchas plataformas en la nube con exactamente esa función.
Qué significa esto para tu programa
No dejes que “autenticado” sustituya a “verificado” en tu proceso de triaje. Un mensaje que pasa SPF, DKIM y DMARC desde el dominio propio de una gran plataforma te dice que la infraestructura de esa plataforma lo envió. No te dice nada sobre si una persona en esa plataforma, o un atacante que encontró una función de automatización sin bloquear, decidió a quién iba dirigido.
Capacita a los usuarios específicamente sobre señuelos con formato de notificación. Las alertas de correo de voz, las solicitudes de acceso a documentos y las notificaciones de permisos son efectivas precisamente porque imitan el ruido rutinario de la plataforma. Un breve recordatorio interno de que estos tipos de mensajes pueden llevar enlaces de captura de credenciales, incluso desde dominios reales de la plataforma, cierra una brecha que la autenticación no puede cerrar.
Impulsa las páginas de captura de credenciales hacia autenticación resistente al phishing. Un tenant de Microsoft 365 protegido con llaves de seguridad FIDO2 o passkeys de plataforma es mucho más difícil de comprometer a través de una página de contraseña capturada que uno que depende de contraseña más notificación push de MFA, que sigue siendo vulnerable a la fatiga de aprobaciones incluso cuando el señuelo inicial tiene éxito.
Reporta el abuso de funciones de automatización de plataformas cuando lo detectes, y espera más casos así. Esta campaña explotó la infraestructura de Google esta vez. La técnica subyacente, automatización legítima reutilizada como relé de phishing, es transferible a cualquier proveedor con una función similar de envío en nombre de otro, y tus propias reglas de detección deberían asumir que aparecerá en otro lugar.
Mantén DMARC aplicado de todos modos. Esta campaña no debilita el argumento a favor de la aplicación en tu propio dominio. Demuestra una categoría de riesgo completamente separada, una que vive dentro de las plataformas en las que ya confías, no en la brecha que DMARC fue diseñado para cerrar.
La conclusión
Nada en esta campaña requirió romper DMARC, suplantar un dominio o comprometer un buzón. Requirió encontrar una función legítima que enviara correo en nombre de Google a quien el atacante especificara, y apuntarla hacia 3.200 objetivos. Cada señal técnica que un servidor receptor puede verificar volvió exactamente como estaba diseñada, porque nada respecto a esas señales fue jamás falso. La autenticación responde una pregunta con precisión: si la infraestructura del dominio reclamado envió esto. Nunca fue diseñada para responder si esa infraestructura se estaba usando de la forma en que su dueño pretendía.
Excello Mail te da visibilidad continua sobre el cumplimiento de tu DMARC y sobre cada fuente autorizada a enviar bajo tu dominio, para que puedas detectar abusos rápidamente y mantener tu propia postura de autenticación hermética, incluso cuando los atacantes encuentren nueva infraestructura que explotar en otros lugares. Regístrate gratis en Excello Mail y descubre exactamente quién está enviando correos en tu nombre, todo el tiempo.