Google detectó nuevas campañas de ciberespionaje en las que grupos vinculados con Rusia están aprovechando funciones legítimas de Google, Microsoft y WhatsApp para conseguir acceso a cuentas de sus víctimas.

Las operaciones apuntan principalmente a personas relacionadas con gobiernos, diplomacia, defensa, industria aeroespacial, universidades, organizaciones no gubernamentales y centros de investigación de Europa y Estados Unidos. Google Threat Intelligence Group (GTIG) sigue la actividad bajo tres grupos diferentes: UNC6293, UNC7005 y UNC5976.

La particularidad de estos ataques es que, en varios casos, la víctima realmente termina iniciando sesión en Google o Microsoft mediante páginas oficiales. No necesariamente entrega su contraseña en una web falsa.

El engaño ocurre después: los atacantes consiguen que la persona autorice, comparta o vincule información que termina otorgándoles acceso a la cuenta.

El phishing está cambiando: la página de inicio de sesión puede ser verdadera

Durante años, uno de los consejos más repetidos frente al phishing fue comprobar que la página donde ingresamos una contraseña pertenezca realmente a Google, Microsoft o al servicio correspondiente.

Sigue siendo una buena recomendación.

Pero estas campañas muestran por qué ya no siempre alcanza.

En algunos ataques detectados por Google, la víctima hace clic en un botón como:

“Continuar con Google”

y efectivamente llega al sistema legítimo de autenticación de Google.

El dominio puede ser correcto.

El certificado también.

Y la contraseña nunca llega directamente al atacante.

El problema está en qué autorización se está concediendo después de iniciar sesión.

Para entenderlo hay que explicar primero qué es OAuth.

¿Qué es OAuth?

OAuth es un mecanismo utilizado para permitir que una aplicación acceda a determinada información de otra cuenta sin entregarle directamente nuestra contraseña.

Es lo que ocurre cuando una página ofrece:

“Iniciar sesión con Google”

o cuando una aplicación solicita permiso para acceder a determinados datos de una cuenta.

En un escenario legítimo, resulta muy útil.

Por ejemplo, una aplicación puede pedir acceso limitado a determinados archivos o información del perfil sin conocer nunca la contraseña de Google.

El problema aparece cuando un atacante consigue convencer a la víctima de completar un proceso OAuth que en realidad está autorizando una sesión controlada por el delincuente.

En ese caso, robar la contraseña puede dejar de ser necesario.

UNC6293: falsas comunicaciones del Departamento de Estado

Uno de los grupos analizados por Google es UNC6293.

GTIG considera, con confianza moderada, que se trata de un subgrupo relacionado con ICE RELIC, nombre que Google utiliza actualmente para el actor históricamente conocido como APT29, Cozy Bear o Midnight Blizzard.

Sus campañas suelen ser pequeñas y extremadamente dirigidas. Google señala que habitualmente apuntan a menos de cinco personas por operación.

Una de sus tácticas consiste en hacerse pasar por funcionarios del Departamento de Estado de Estados Unidos.

El atacante contacta a la persona utilizando temas relacionados con diplomacia, reuniones o conferencias y comienza a guiarla a través de distintos procedimientos de autenticación.

En junio de 2026, Google observó una variante basada en OAuth.

La víctima realizaba un inicio de sesión legítimo y luego recibía instrucciones para compartir con el supuesto contacto una URL completa o un código de verificación.

Ese dato era justamente lo que el atacante necesitaba.

El usuario inicia sesión correctamente, pero después entrega la autorización

Esta técnica puede resultar mucho más convincente que una página falsa tradicional.

La víctima ve Google.

Inicia sesión en Google.

Puede incluso completar su segundo factor de autenticación.

Todo parece funcionar como debería.

Después aparece alguien diciendo:

“Para completar la verificación, enviame este código”.

Al compartirlo, termina permitiendo que el atacante utilice la autorización generada durante ese proceso. Google explica que proporcionar ese código permitía a UNC6293 obtener acceso a la cuenta.

La contraseña no fue necesariamente robada.

La víctima autorizó involuntariamente el acceso.

Otro grupo automatizó el robo de tokens con infraestructura de Google Cloud

El segundo actor analizado, UNC5976, utiliza una estrategia todavía más automatizada.

Desde marzo de 2026, el grupo registró dominios relacionados con supuestos servicios para compartir archivos y creó proyectos cloud asociados a ellos.

La víctima llega a una página que parece ofrecer un archivo o documento.

Después de algunos segundos aparece una ventana:

“Continue with Google”.

Cuando hace clic, es enviada al sistema legítimo de Google OAuth.

Hasta ese momento, prácticamente todo puede parecer normal.

Pero después de completar la autenticación, el navegador redirige hacia un proyecto de Google Cloud controlado por los atacantes. Allí, scripts maliciosos recuperan el token de autenticación generado durante el proceso y lo almacenan para que el operador pueda utilizarlo posteriormente.

¿Qué es un token y por qué puede ser tan importante como una contraseña?

Después de iniciar sesión, los servicios modernos no vuelven a pedir nuestra contraseña con cada acción.

Generan tokens que representan una sesión o autorización.

Podemos imaginarlos como una credencial temporal.

El sistema ya comprobó quién somos y entrega una especie de pase que indica:

“Este usuario fue autenticado y tiene permiso para continuar”.

Si un atacante consigue determinados tokens, puede llegar a acceder a información o sesiones sin tener que escribir nuevamente la contraseña.

Eso explica por qué el robo de tokens se convirtió en una pieza cada vez más importante del phishing moderno.

Google identificó al menos 12 dominios e infraestructuras nuevas creadas por UNC5976 en aproximadamente tres meses. La compañía tomó medidas para deshabilitar esos proyectos y afirma que el grupo comenzó posteriormente a trasladar parte de su infraestructura hacia otros proveedores.

WhatsApp también forma parte de los ataques

El tercer componente de la investigación resulta especialmente interesante porque demuestra que la misma lógica puede trasladarse fuera del correo electrónico.

En mayo y junio, UNC7005 creó páginas que imitaban procesos de WhatsApp.

La víctima recibía una propuesta para participar en una supuesta:

llamada segura,
conversación cifrada
o transferencia de documentos.

Para continuar, la página pedía su número de teléfono.

El atacante utilizaba entonces ese número para generar una solicitud real de vinculación de dispositivo de WhatsApp.

Y ahí aparece nuevamente el mismo patrón.

El código que ve la víctima puede ser auténtico.

El mecanismo de WhatsApp también.

Lo falso es la explicación de para qué se está utilizando.

El usuario termina agregando el dispositivo del atacante a su cuenta

WhatsApp permite utilizar una misma cuenta desde distintos dispositivos.

Para agregar uno nuevo existe un procedimiento legítimo de vinculación mediante códigos o QR.

UNC7005 aprovecha esa función.

La página maliciosa muestra a la víctima el QR o código legítimo generado para vincular el dispositivo que controla el atacante y le indica que debe utilizarlo para acceder a la supuesta llamada o conversación segura.

Si la persona sigue las instrucciones, no está entrando a una llamada.

Está agregando un nuevo dispositivo a su propia cuenta de WhatsApp.

Y ese dispositivo pertenece al atacante.

En términos sencillos:

el delincuente no hackea el sistema de vinculación de WhatsApp; convence al propietario de la cuenta para que lo vincule voluntariamente.

Después incluso podían grabar audio y video

Una vez realizada la vinculación, el engaño continuaba.

La página ofrecía distintas opciones.

Si la víctima seleccionaba la supuesta llamada de voz, se ejecutaba JavaScript que solicitaba acceso al micrófono y a la cámara.

La interfaz mostraba una falsa llamada durante un breve período.

Mientras tanto, el audio y el video podían grabarse y enviarse hacia el servidor de comando y control de los atacantes.

Google pudo analizar incluso el código utilizado para iniciar la grabación y subir posteriormente el archivo generado.

Otra opción ofrecía un supuesto “chat cifrado” y proporcionaba usuario y contraseña para ingresar a una segunda página.

También existía una variante que mostraba un botón de descarga de archivos, aunque Google no pudo determinar qué contenido se entregaba en todos esos casos.

Los ataques utilizan invitaciones que parecen cuidadosamente preparadas

UNC7005 no se limita a enviar un correo diciendo “verifique su cuenta”.

Google observó campañas mucho más elaboradas.

Los atacantes crearon sitios que imitaban conferencias diplomáticas y organizaciones reconocidas.

En una campaña que copiaba al foro GLOBSEC, por ejemplo, la víctima encontraba un formulario completo de inscripción.

Podía indicar que asistiría al evento, completar datos y hasta seleccionar preferencias de comida y vino.

El detalle gastronómico no es casual.

Google explica que las referencias al vino ya habían aparecido anteriormente en campañas relacionadas con ICE RELIC.

El objetivo es hacer que todo el proceso parezca suficientemente real para que, cuando llegue la etapa de “verificación de identidad”, la víctima ya haya desarrollado confianza en la página.

Después del formulario aparece la verdadera trampa

Al terminar la inscripción, la página solicita verificar la identidad.

Ahí puede aparecer un código relacionado con un flujo legítimo de autenticación.

Esto se conoce como device code phishing.

El código de dispositivo existe para situaciones perfectamente válidas.

Por ejemplo, determinados televisores o dispositivos no tienen un teclado cómodo para iniciar sesión.

El dispositivo muestra un código.

La persona abre una página de Microsoft desde otra computadora o celular, ingresa ese código y autoriza la sesión.

El ataque invierte el proceso.

El delincuente genera la solicitud y después convence a la víctima de que introduzca el código del atacante dentro del sitio legítimo de Microsoft.

Si lo hace, puede terminar autorizando esa sesión.

Otra vez:

la página de Microsoft puede ser auténtica.

El código también.

Lo malicioso es quién inició la solicitud que estamos autorizando.

También utilizaron malware para Windows y macOS

Cuando la ingeniería social no se limita al robo de cuentas, UNC7005 dispone de otra alternativa.

En mayo, Google detectó una campaña dirigida principalmente contra académicos, diplomáticos e investigadores estadounidenses especializados en Rusia y las antiguas repúblicas soviéticas.

La página imitaba un encuentro relacionado con una resolución de apoyo a Ucrania y ofrecía descargar una supuesta:

“Summit Companion App”.

La aplicación prometía permitir consultar el documento completo.

Pero lo que recibía la víctima dependía de su sistema operativo.

En Windows se distribuía Vidar, un conocido infostealer capaz de buscar información sensible almacenada en navegadores.

En macOS se entregaba Atomic Stealer, también diseñado para robar información.

Eso muestra que las campañas no dependen de una única técnica.

Los mismos operadores pueden alternar entre OAuth, vinculación de dispositivos, falsas conferencias y malware dependiendo del objetivo.

En agosto apuntaron específicamente al sector europeo de defensa

A comienzos de agosto, UNC7005 incorporó una nueva campaña de phishing OAuth contra cuentas de Google.

Los atacantes registraron dominios que imitaban al Finnish Operations Center, una organización que ayuda a empresas finlandesas de seguridad y defensa a trabajar dentro del ecosistema de la OTAN.

Entre el 6 y el 13 de agosto de 2026, enviaron correos dirigidos a personas vinculadas con la industria europea de defensa.

Al hacer clic en “Get Access” o “Sign in With Google”, la persona era enviada primero al inicio de sesión legítimo de Google.

Después terminaba en un proyecto cloud no verificado controlado por los atacantes, diseñado para obtener los tokens de autenticación.

Los hoteles y centros de conferencias también entran en la historia

Google vinculó además a UNC7005 con una campaña que Microsoft denomina CaptiveCrunch.

En este caso, el atacante no necesariamente necesita enviar un correo de phishing.

Busca controlar parte de la infraestructura utilizada por redes Wi-Fi de hoteles, centros de conferencias y otros espacios para viajeros.

Microsoft detectó esta actividad desde principios de mayo.

Los atacantes manipulan tráfico DNS y HTTP para conseguir que determinados usuarios conectados a esas redes sean redirigidos hacia infraestructura maliciosa.

La víctima cree que simplemente está utilizando el Wi-Fi del hotel.

Pero determinadas conexiones pueden terminar atravesando sistemas del atacante.

El objetivo son especialmente los viajeros corporativos

El interés en hoteles y conferencias tampoco parece casual.

Una persona que viaja por trabajo puede llevar una computadora corporativa con acceso a:

correo electrónico, Microsoft 365, documentos, sistemas internos y cuentas empresariales.

Además, conectarse al Wi-Fi del hotel genera una situación en la que es normal ver:

portales de autenticación, solicitudes de acceso y páginas relacionadas con conectividad.

Eso facilita el engaño.

Microsoft señala que CaptiveCrunch ha afectado redes vinculadas con hotelería y portales cautivos en diferentes países. ReliaQuest también detectó actividad en hoteles y centros de conferencias y considera que el objetivo son las cuentas de empleados que viajan por trabajo.

Hasta una falsa actualización puede aparecer después de conectarse al Wi-Fi

La manipulación del tráfico también se utilizó para mostrar supuestas actualizaciones del navegador o del sistema operativo.

En realidad podían distribuir malware.

Microsoft identificó, entre otras herramientas, un troyano llamado CornFlake, capaz de recopilar archivos, pulsaciones de teclado, credenciales y tokens, además de realizar vigilancia de audio y video y proporcionar una shell remota al operador.

También apareció ChocoShell, un malware basado en PowerShell especializado en robar información como cookies de sesión, contraseñas guardadas, tokens de Microsoft 365 y credenciales Wi-Fi.

Por eso una ventana inesperada que diga:

“Necesitás actualizar tu navegador para utilizar esta red”

debería generar especial atención cuando aparece inmediatamente después de conectarnos al Wi-Fi de un hotel, aeropuerto o conferencia.

¿Google, Microsoft o WhatsApp fueron vulnerados?

No es eso lo que muestra esta investigación.

Las campañas aprovechan funciones legítimas que las plataformas necesitan ofrecer.

OAuth debe permitir autorizar aplicaciones.

WhatsApp necesita poder vincular dispositivos.

Microsoft necesita permitir autenticación mediante códigos de dispositivo.

El problema aparece cuando alguien construye una historia convincente alrededor de esas herramientas y consigue que la víctima autorice algo diferente de lo que cree estar autorizando.

Google resume precisamente este desafío: el abuso de flujos legítimos de autenticación hace que sea más difícil diferenciar un acceso normal de uno malicioso.

Tampoco significa que “hackers rusos puedan entrar a cualquier cuenta de Google”

La investigación describe operaciones de ciberespionaje altamente dirigidas, no una campaña masiva contra todos los usuarios.

Los blancos suelen seleccionarse por su función profesional, acceso o información.

Google atribuye con alta confianza un nexo ruso a UNC6293, UNC7005 y UNC5976 por sus patrones de objetivos, temáticas de phishing y técnicas operativas.

En el caso de UNC6293 y UNC7005, la compañía evalúa con confianza moderada una relación con el subgrupo de ICE RELIC encargado principalmente de conseguir acceso inicial.

Esto es más preciso que presentar a los tres grupos como si se tratara necesariamente de una única organización operando exactamente bajo el mismo mando.

¿Cómo reconocer este nuevo tipo de phishing?

Una de las señales principales es una solicitud que aparece después de haber iniciado sesión correctamente.

Por ejemplo:

una persona que pide que le enviemos un código de verificación que acaba de mostrar Google;

una conferencia que indica que debemos introducir un código de dispositivo de Microsoft para “confirmar nuestra identidad”;

o una supuesta llamada de WhatsApp que pide vincular primero otro dispositivo mediante QR.

El hecho de que el código o la página sean legítimos no garantiza que la operación también lo sea.

Antes de compartir, escanear o introducir cualquier código conviene preguntarse:

¿qué dispositivo o aplicación estoy autorizando realmente?

El segundo factor tampoco protege si nosotros mismos aprobamos la sesión

Estas campañas también muestran una limitación importante del MFA.

La autenticación multifactor sigue siendo fundamental y evita una enorme cantidad de ataques.

Pero no puede solucionar todos los escenarios de ingeniería social.

Si el atacante roba solamente la contraseña, el segundo factor puede detenerlo.

Si consigue convencer a la propia víctima para que autorice la sesión del atacante, el problema es diferente.

El sistema interpreta correctamente que el propietario confirmó la acción.

Por eso los ataques modernos están intentando cada vez más manipular el procedimiento de autenticación en lugar de limitarse a robar una contraseña.

Una campaña donde lo legítimo forma parte del engaño

Quizás el aspecto más importante de esta investigación sea ese cambio.

Durante años, el phishing buscaba construir copias convincentes de Google, Microsoft o WhatsApp.

Ahora los atacantes pueden utilizar partes de los sistemas auténticos.

La página inicial puede ser falsa.

Pero el login siguiente puede ser Google.

El código puede haber sido realmente generado por Microsoft.

El QR puede ser realmente válido para WhatsApp.

El engaño está en por qué nos piden usarlo.

GTIG considera que estos tres grupos están adaptando continuamente sus campañas y utilizando diferentes mecanismos de autenticación para obtener acceso rápido a cuentas personales y, desde ellas, alcanzar nueva información u otras personas de interés.

La regla, entonces, ya no puede ser solamente “mirá si la página es verdadera”.

También hay que entender qué permiso, sesión o dispositivo estamos autorizando antes de confirmar una solicitud, especialmente cuando las instrucciones llegan por correo, mensajería o una invitación inesperada.