Desde mediados de agosto de 2026, una campaña de phishing bautizada como Operation CloudFire viene secuestrando sesiones activas de Google entre usuarios corporativos. El cebo son invitaciones falsas de Google Calendar que, combinadas con un proxy inverso en tiempo real, permiten a los atacantes capturar contraseñas y segundos factores sin levantar ninguna alarma.
La campaña fue identificada por el equipo de Threat Research de Material Security, como puedes ver en su documento técnico. Allí explican por qué los filtros tradicionales no la detectan.
Cómo logran las invitaciones de Calendar robar la sesión completa
Los correos llegan como invitaciones de Google Calendar, muchas veces en copia oculta (BCC) y desde cuentas de organizaciones con las que la víctima ya se ha escrito antes. Los pretextos son triviales: avisos de buzón de voz, solicitudes RFP, citaciones judiciales o notificaciones de impago.
La mayoría de los enlaces usan el redireccionador /url de Google con el destino real escondido en un parámetro, aunque otras oleadas han usado share.google, archivos de Drive o notificaciones de transacciones de Intuit. Da igual la variante: el dominio, el certificado y la reputación que ve el sistema de turno son siempre legítimos.
El golpe real llega después. El atacante levanta un proxy inverso delante de la página auténtica de inicio de sesión de Google. La víctima escribe su contraseña, recibe el aviso en el móvil y lo aprueba sin sospechar nada, mientras el operador observa la sesión en directo. El servidor reenvía a Google cada código SMS, cada clave del autenticador y cada confirmación de Tap-Yes a medida que llegan, así que ningún segundo factor frena la captura. El framework detrás de esta técnica, Nyasher, está documentado públicamente desde febrero, después de que se encontrara una clave codificada en su propio JavaScript.
Por qué fallan los filtros de reputación y qué alcanza el atacante con la sesión
Los sistemas de reputación responden a una pregunta sobre propiedad: quién registró el dominio, qué más ha alojado y si alguien se ha quejado de él. Operation CloudFire está construida para que esa respuesta sea siempre tranquilizadora, con tres capas: el redireccionador de Google, un desafío de Cloudflare Turnstile (a veces el widget legítimo de Cloudflare) y una página de robo de credenciales que no existe como sitio estático, porque el JavaScript la construye en el navegador tras superar el desafío.
La infraestructura, además, es desechable por diseño: los dominios señuelo se registraron días antes de usarse, y un certificado comodín llegó a emitirse 46 minutos antes de registrar el dominio que protegía. Según Material, «bloquear cualquier componente le cuesta al operador unos pocos dólares y una tarde de trabajo».
El daño aparece cuando la sesión robada empieza a moverse. Con acceso en vivo, el atacante llega al correo, a Drive y puede conceder permisos OAuth en nombre de la víctima, lo que amplía el radio de impacto más allá de la bandeja de entrada. Material plantea dos preguntas a cualquier equipo de seguridad: quién revisa los registros de auditoría de Google Workspace y con qué rapidez puede actuar. Revocar sesiones, contener permisos OAuth y restablecer la cuenta afectada en menos de una hora es el margen que importa.
Operation CloudFire: así ha sido el golpe a la infraestructura y su estado actual
A finales de septiembre, Material concluyó que ajustar reglas y reentrenar modelos no bastaba: había que atacar la infraestructura. Su equipo de Threat Research analizó las URL de las puertas de entrada y los servidores receptores, y las reportó al sistema de abuso de Cloudflare.
