Desde mediados de agosto de 2026, una campaña de phishing ha estado robando sesiones activas de Google a usuarios corporativos mediante invitaciones de Google Calendar, y lo hace aunque la cuenta tenga autenticación multifactor. Importa a las empresas españolas porque el ataque no se apoya en dominios sospechosos ni en contraseñas robadas, sino en la sesión ya autenticada, y eso reduce el valor de varias defensas habituales.
El análisis procede de BleepingComputer, en un artículo patrocinado y redactado por Material Security, el proveedor que identificó la campaña y la bautizó como Operation CloudFire. Conviene leer las cifras con ese matiz: son datos del propio proveedor y proceden solo de clientes que aceptaron compartirlos.
Un señuelo que parece legítimo en todos los pasos
Los mensajes llegan como invitaciones de Google Calendar, a veces por copia oculta, y con frecuencia desde una organización con la que el destinatario ya ha tenido contacto. Los pretextos son cotidianos:
- Notificaciones de buzón de voz.
- Solicitudes de propuesta o de información (RFP y RFI).
- Citaciones judiciales.
- Avisos de pagos no realizados.
La mayoría de los enlaces apuntan a Google. El patrón habitual usa el redirector /url de Google con el destino real como parámetro, aunque otras oleadas emplearon share.google y enlaces de Drive, y una variante utilizó notificaciones de transacciones de Intuit. Al analizar el mensaje, el dominio, el certificado y la reputación resultan legítimos.
Cómo se salta el MFA: un proxy inverso delante del login real
El atacante coloca un proxy inverso activo delante de la página real de acceso de Google. La víctima introduce su contraseña, recibe una solicitud genuina y la aprueba, mientras el operador observa la sesión en tiempo real.
El servidor retransmite a Google, según llegan, los códigos SMS, los códigos del autenticador, la coincidencia de números de Google y la recuperación de cuenta por teléfono. Por eso ninguno de esos segundos factores impide capturar la sesión. El framework utilizado, Nyasher, está documentado públicamente desde febrero.
La cadena tiene tres capas: el redirector de Google, un desafío Cloudflare Turnstile (en algunas versiones, el widget auténtico servido desde Cloudflare) y una página de captura que se construye con JavaScript en el navegador. Esa última no tiene una web estática que un rastreador pueda analizar.
Infraestructura desechable y remitentes comprometidos
La infraestructura está pensada para gastarse. Muchos dominios se registraron días antes de usarse y los puntos de recepción se preparaban entre uno y veinte días antes de cada oleada. Bloquear un único componente le cuesta al operador unos pocos dólares y una tarde de trabajo.
Material afirma que, durante un mes de Operation CloudFire, registró:
- 68.676 mensajes de campaña bloqueados.
- 2.112 URL maliciosas únicas analizadas.
- 8.570 direcciones de remitente comprometidas, repartidas en 6.354 dominios raíz.
- Un ritmo de envío ajustado al horario laboral de Estados Unidos.
Cada cuenta comprometida enviaba invitaciones a los contactos guardados de la víctima, de modo que el receptor veía un nombre conocido, un dominio con historial limpio y una hora plausible. Según el proveedor, la acción coordinada con Cloudflare contribuyó a desmantelar cerca de 900 dominios.
Lo que cambia para la defensa
La lección principal es que ninguna señal aislada basta. La reputación del dominio no habría detectado esta campaña, y el análisis de enlaces tampoco, porque el primer salto es una URL de Google y la página final no existe hasta que el navegador la construye. Material combina indicadores técnicos, la intención aparente del mensaje, el destino real de los enlaces y la relación previa con el remitente.
También importa dónde se analiza. Una invitación de calendario encaja mal con una pasarela pensada para inspeccionar correo en tránsito, así que el calendario debe tratarse como superficie de ataque propia.
Si el resultado es una sesión secuestrada y no una contraseña robada, la evidencia queda en los registros de auditoría de Workspace. Una sesión activa da acceso al correo, a Drive y a la posibilidad de conceder acceso OAuth en nombre de la víctima, de modo que el impacto va mucho más allá de la bandeja de entrada.
Material considera que la campaña parece terminada, pero no que esté cerrada. Los temas han pasado de las invitaciones de calendario a invitaciones para compartir archivos de Drive, el framework es público y el operador dejó sin activar una rama para Microsoft 365. El proveedor espera que el siguiente movimiento se parezca a este con otra marca.
Qué deberían hacer las empresas
Estas son las prioridades que recomendamos, con independencia de si el atacante usa Google o Microsoft:
- Medir el tiempo de respuesta. Comprobar si el equipo puede revocar sesiones, contener concesiones OAuth y restablecer la cuenta afectada en menos de una hora.
- Revisar los registros de auditoría. Definir quién los vigila, con qué alertas y con qué capacidad de actuación.
- Valorar métodos de autenticación resistentes al phishing, como FIDO2 o passkeys, para los perfiles más expuestos. Es una recomendación general, no una conclusión de la fuente.
- Incluir el calendario en el análisis de correo y no depender solo de la reputación del remitente o del dominio.
- Actualizar la concienciación. Una invitación de un contacto conocido ya no es señal de confianza.
- Revisar las concesiones OAuth existentes y limitar quién puede conceder acceso a aplicaciones de terceros.
En el sector financiero y en entidades sujetas a DORA o NIS2, estos puntos conectan con la gestión de incidentes y la resiliencia operativa, y conviene poder demostrarlos con evidencias.
En CGC Spain ayudamos a evaluar la exposición real a este tipo de ataques, a revisar la configuración de identidad y de auditoría en Google Workspace y Microsoft 365, y a ensayar la respuesta a incidentes para que el plazo de una hora sea alcanzable. Si quiere contrastar su situación, estaremos encantados de hablarlo.
