Tres campañas de ciberespionaje convierten los inicios de sesión legítimos en trampas de phishing

La táctica común: una solicitud peligrosa con apariencia normal

Las operaciones emplearon campañas persistentes y muy dirigidas de ingeniería social. Los atacantes se hicieron pasar por funcionarios, contactos profesionales u organizaciones conocidas, prepararon invitaciones y conversaciones plausibles y después guiaron a sus objetivos por procesos reales de seguridad de las cuentas.

Esto puede sortear la protección que muchas personas asocian automáticamente con la autenticación multifactor. La víctima quizá no entregue su contraseña: puede aprobar una aplicación OAuth, crear una contraseña de aplicación o vincular un nuevo dispositivo. Cada una de esas acciones puede proporcionar al atacante una vía de acceso legítima y difícil de distinguir de una actividad normal.

Qué hizo cada clúster

UNC6293: suplantación, contraseñas de aplicación y OAuth

UNC6293 habría suplantado a funcionarios del Departamento de Estado de Estados Unidos y a otros contactos de confianza. Sus señuelos buscaban convencer a los objetivos para que crearan y compartieran contraseñas específicas para aplicaciones, que pueden permitir el acceso a una cuenta sin pasar por el desafío habitual del segundo factor. GTIG también describió campañas de phishing de consentimiento OAuth, en las que los atacantes intentan obtener tokens autorizados en vez de robar directamente la contraseña.

GTIG evaluó con confianza moderada que UNC6293 era un subclúster de acceso inicial de ICE RELIC, el nombre que utiliza Google para el actor conocido anteriormente como APT29.

UNC7005, también identificado como STORM-2945: WhatsApp y señuelos por etapas

UNC7005 utilizó un repertorio más amplio y cambiante de técnicas, entre ellas:

• Estafas de vinculación de dispositivos en WhatsApp: las víctimas eran inducidas a vincular a su cuenta un dispositivo controlado por los atacantes.
• Llamadas de voz falsas e invitaciones a chats cifrados: estos contactos ayudaban a generar confianza antes de enviar un enlace o código malicioso.
• Comunicaciones que imitaban a organizaciones: algunos señuelos mencionaban al Finnish Operations Center y se combinaban con portales falsos de inicio de sesión de Microsoft.
• OAuth y distribución de malware: los flujos OAuth de Google se utilizaban para intentar obtener tokens o acceso a las cuentas, mientras que también se desplegaban programas maliciosos como los infostealers VIDAR y ATOMIC.

Sus técnicas y su infraestructura eran diferentes de las de UNC6293. Por eso GTIG los sigue como operaciones separadas, aunque ambos comparten objetivos similares y el abuso de procesos legítimos de autenticación.

UNC5976: phishing OAuth contra objetivos de defensa

UNC5976 habría centrado sus operaciones en personal y organizaciones militares, aeroespaciales y de defensa, incluidos objetivos vinculados con Ucrania y Armenia. Sus campañas de phishing buscaban que las víctimas autorizaran mediante OAuth el acceso a sus cuentas o datos.

Qué dijo Google sobre la conexión con Rusia

GTIG evaluó con alta confianza que el conjunto de la actividad tenía un nexo ruso. Se trata de una valoración de atribución: no significa que todos los detalles operativos ni todas las relaciones entre los clústeres estén demostrados con el mismo nivel de certeza.

Los informes disponibles también describen posibles vínculos entre parte de la actividad e ICE RELIC/APT29. La conexión de UNC6293 con ICE RELIC fue evaluada por GTIG con confianza moderada. Los clústeres, sin embargo, siguen siendo rastreados por separado porque sus métodos y su infraestructura no son idénticos.

Por qué la autenticación multifactor no basta por sí sola

La autenticación multifactor sigue siendo una defensa importante, pero puede quedar neutralizada si un atacante manipula al usuario para que apruebe la acción equivocada. Una pantalla inesperada de consentimiento OAuth, una solicitud para crear una contraseña de aplicación o un código para vincular WhatsApp pueden ser señales de toma de control, aunque nadie haya robado la contraseña.

La lección práctica es tratar cada aviso de autenticación como una transacción que debe verificarse, no como un paso automáticamente seguro por aparecer dentro de un servicio conocido. También hay que comprobar quién inició la solicitud y por qué.

Cómo reducir el riesgo

Las recomendaciones de GTIG buscan obligar al atacante a perder la ventaja de la urgencia:

• Comprueba la URL completa del navegador antes de iniciar sesión o aprobar el acceso de una aplicación OAuth.
• Verifica las invitaciones y solicitudes por otra vía. Usa un método de contacto conocido para confirmar invitaciones a conferencias, llamadas, solicitudes de chats cifrados y mensajes que supuestamente proceden de un gobierno o una organización.
• No compartas contraseñas de aplicación, códigos de verificación de un solo uso, códigos QR ni códigos de vinculación de dispositivos. Tampoco apruebes un inicio de sesión o una solicitud OAuth inesperados.
• Revisa con frecuencia los dispositivos vinculados y elimina los que no reconozcas en WhatsApp y otras aplicaciones de mensajería.
• Utiliza autenticación multifactor resistente al phishing. Las organizaciones deberían priorizar llaves de seguridad o claves de acceso —passkeys— y, cuando sea posible, limitar las aplicaciones OAuth de riesgo y el uso de contraseñas específicas para aplicaciones.

Para quienes trabajan en sectores sensibles, la regla es sencilla: que una marca sea conocida, que la página de inicio de sesión sea real o que la función de autenticación sea legítima no demuestra que la solicitud lo sea. También deben verificarse la petición y la identidad de quien la inició.