Desde mediados de agosto de 2026, una operación de phishing ha estado recolectando sesiones activas de Google de usuarios corporativos. Todas las señales que los defensores suelen usar para evaluar un enlace arrojaban resultados tranquilizadores, y el operador diseñó la cadena deliberadamente para que así fuera. El equipo de investigación de amenazas de Material Security identificó la campaña y ha desmantelado cientos de dominios usados por los atacantes en lo que han llamado Operation CloudFire. Esto es lo que descubrieron.
El anzuelo: invitaciones de Google Calendar
Los mensajes llegan como invitaciones de Google Calendar, a veces enviadas con copia oculta (BCC) y frecuentemente desde una organización con la que el destinatario ya ha mantenido correspondencia. Los pretextos son triviales: notificaciones de correo de voz, solicitudes de RFP y RFI, citaciones judiciales y avisos de pago perdido.
La mayoría de los enlaces apuntan a Google mismo. El patrón típico es el redireccionador /url de Google con el destino real en un parámetro de consulta, aunque otras oleadas usaron enlaces share.google y archivos de Drive con el mismo propósito. Una variante utilizó enlaces de notificación de transacciones de Intuit. En todos los casos, al evaluar el mensaje, el dominio, el certificado y la reputación mostrados son legítimos y de confianza.
La captura: proxy inverso frente a una página de inicio de sesión de Google
El atacante ejecuta un proxy inverso en vivo frente a la página de inicio de sesión genuina de Google. La víctima introduce su contraseña, recibe un mensaje real y lo aprueba, mientras el operador observa la sesión en tiempo real. El servidor retransmite los códigos SMS, los códigos del autenticador, la coincidencia de números Tap-Yes de Google y la recuperación de cuenta basada en teléfono a Google a medida que llegan, por lo que ninguno de los controles de segundo factor impide que se capture la sesión. El framework subyacente, Nyasher, ha estado documentado públicamente desde febrero, después de que se encontrara una clave codificada en su JavaScript.
Por qué los controles no se activan
Los sistemas de reputación responden a una pregunta sobre la propiedad: quién registró el dominio, qué más ha alojado y si alguien se ha quejado de él. Esta campaña se ensambló para que esas respuestas fueran consistentemente benignas, y tiene tres capas. La primera capa es el redireccionador de Google. La segunda es un desafío Cloudflare Turnstile, que en algunas versiones es el widget genuino servido desde la propia infraestructura de Cloudflare. La tercera capa es la página de captura de contraseña, que no tiene un sitio web estático que escanear. El JavaScript la construye en el navegador después de que el visitante supera el desafío, por lo que un rastreador no tiene nada que buscar y un registro de proxy no tiene nada que registrar. Según Material, nadie había escaneado esas páginas antes de que se documentara la campaña.
La infraestructura es desechable por diseño. La campaña observada inicialmente utilizó muchos dominios de señuelo en múltiples registradores, la mayoría registrados solo días antes de su uso. Los puntos de recepción se prepararon entre uno y veinte días antes de la oleada que servían. Un certificado comodín se emitió 46 minutos antes de que se registrara el dominio que cubre. Bloquear cualquier componente individual le cuesta al operador unos pocos dólares y una tarde de trabajo.
Cómo ha sido la defensa
Material ha seguido la campaña desde su inicio, siguiendo cada variante a medida que rotaban los señuelos, las puertas y los puntos de recepción. Desde agosto, una vez identificada la campaña y creadas las detecciones, Material ha interceptado más del 99% de los mensajes maliciosos, con una tasa de reclasificación del 0,01%. Ha sido un esfuerzo continuo, ya que el atacante cambió sus TTP, temas y texto de señuelo para evadir detecciones estáticas, de ML y agénticas.
El enfoque funciona porque ninguna señal individual decide el resultado. La reputación por sí sola no habría detectado esto, y el análisis de enlaces por sí solo tampoco, ya que el primer salto es una URL de Google y la página final no existe hasta que un navegador la construye. Material puntúa indicadores técnicos, la intención aparente del mensaje, dónde resuelven realmente los enlaces y la relación de envío detrás del mensaje. Cualquiera de esos elementos puede ser suficiente para actuar. Una detección basada en una sola señal hereda los puntos ciegos de esa señal, y este operador ha dedicado un esfuerzo considerable a mapearlos.
También importa dónde se ejecuta el análisis. Una invitación de calendario encaja mal en una puerta de enlace diseñada para inspeccionar correo en tránsito, pero gran parte de esta campaña llega como invitación. Material trata las invitaciones de calendario como una superficie de amenaza por derecho propio y utiliza el historial completo de la cuenta como contexto junto con las señales técnicas.
Dónde se produce el daño
Cuando el resultado es una sesión secuestrada en lugar de una contraseña robada, la evidencia aparece en los registros de auditoría de Workspace. Una sesión activa de Google alcanza el correo, Drive y la capacidad de otorgar acceso OAuth en nombre de la víctima, por lo que el radio de impacto se extiende mucho más allá de la bandeja de entrada. Los defensores deben hacerse dos preguntas: quién revisa esos registros y con qué rapidez se puede actuar sobre ellos. Igual de importante es si el equipo puede revocar sesiones, contener concesiones OAuth y restablecer la cuenta afectada en una hora. Muchos programas no pueden, y un atacante con una sesión activa puede hacer mucho en ese tiempo.
Operation CloudFire: atacar la infraestructura
A finales de septiembre, Material concluyó que ajustar reglas, reentrenar modelos y actualizar agentes no resolvería el problema por sí solo. La detección protege a los clientes pero no hace nada contra el operador que prepara la siguiente oleada. Por ello, el equipo de investigación de amenazas de Material lanzó Operation CloudFire para atacar la infraestructura misma.
El equipo analizó las URL de puerta de enlace y backend mientras se enviaban los mensajes y las reportó a través del sistema de reporte de abusos de Cloudflare. El equipo de abusos de Cloudflare validó la intersticial falsa y la página de inicio de sesión de Google proxificada detrás de ella, y luego aplicó su propia intersticial de phishing a esos destinos. Esto tuvo dos efectos. La infraestructura del atacante quedó quemada: cada puerta de enlace y punto de recepción reportado tuvo que volver a registrarse, redirigirse y certificarse antes de que el operador pudiera enviar de nuevo. Internet en general también se benefició. Cualquiera que hiciera clic en un enlace reportado, fuera o no cliente de Material, veía una advertencia en lugar de un formulario de credenciales.
Las cifras de un mes
Estas cifras provienen solo de clientes que aceptaron compartir datos con Material, por lo que los totales reales son mayores. Durante un mes de Operation CloudFire, Material registró:
- 68.676 mensajes de campaña bloqueados
- 2.112 URL maliciosas únicas analizadas
- 897 dominios únicos desmantelados
- 8.570 direcciones de remitente comprometidas únicas en 6.354 dominios raíz
- Cadencia de envío que seguía el horario comercial de EE. UU.
El recuento de remitentes muestra cómo la campaña logró su credibilidad. Cada dirección comprometida pertenecía a una cuenta que el atacante controlaba antes de que se enviara la primera invitación, y cada una envió invitaciones a los contactos guardados de la víctima, entre otras direcciones. Los destinatarios veían un nombre o dominio que conocían, en un dominio con un historial limpio, a una hora plausible. Los feeds de reputación no tenían razón para marcar nada de eso, por lo que cada capa que puntúa la propiedad y el historial devolvía un resultado tranquilizador.
Situación actual
Los temas de phishing han cambiado, de invitaciones de calendario a invitaciones para compartir archivos y documentos de Google Drive. Material no ha visto un aumento correspondiente en otros señuelos o TTP, y la actividad de este grupo parece haberse dispersado. La campaña parece terminada. Eso es una actualización de estado, no un veredicto. Reconstruir la infraestructura es barato, el framework es público desde febrero y el operador envió una rama inacabada para Microsoft 365 junto al código activo de Google. La rama incluye una ruta de hoja de estilos, un segundo arnés y una cadena de título que decodifica a un mensaje de inicio de sesión de Microsoft. Ninguna de esas rutas resuelve hoy, y agregar la marca requiere colocar un archivo en lugar de cambiar código. El operador ha construido el siguiente paso y no lo ha activado. Material interpreta la rotación de temas como iteración, no como retirada, y espera que el próximo giro se parezca mucho a este con una marca diferente.
El desglose técnico completo, incluidos indicadores y una línea de tiempo, está disponible en el whitepaper complementario. Los equipos que busquen esta actividad en sus propios entornos deberían empezar por ahí. Patrocinado y escrito por Material Security.
Deja una respuesta