Campaña de phishing se oculta tras redirecciones de Google en varios saltos para robar credenciales

Servicios legítimos de Google forman una cadena de ataque de tres saltos

Una campaña de phishing activa está redirigiendo a las víctimas a través de varios servicios legítimos de Google antes de mostrar páginas diseñadas para robar credenciales o software de acceso remoto.

Los investigadores de KnowBe4 Prabhakaran Ravichandhiran y Jeewan Singh Jalal describieron la actividad el 4 de septiembre. La operación utiliza una cadena de redirecciones de tres saltos diseñada para dificultar el trabajo de las pasarelas de seguridad del correo electrónico, los analizadores de URL y los sistemas de inspección automatizada.

En lugar de incluir directamente una dirección controlada por los atacantes en un correo malicioso, los operadores incorporan servicios como Google Meet, la infraestructura publicitaria de DoubleClick, Google Custom Search, Google Image Search, Google Tag Manager y Google Analytics.

Cada redirección expone a los productos de seguridad a otro dominio legítimo operado por Google. Por tanto, una pasarela que otorgue un peso considerable a la reputación del dominio puede considerar que el enlace es benigno, especialmente si no sigue toda la cadena ni analiza la página final en un navegador real.

La técnica es más deliberada que limitarse a acortar u ocultar una URL maliciosa. La infraestructura está diseñada para mantener una apariencia plausible durante las sucesivas fases de inspección, mientras que el destino puede retrasar o modificar su comportamiento hasta que finalicen las comprobaciones automatizadas.

Google no había comentado la campaña denunciada en el momento de la publicación.

Los fragmentos de URL ocultan datos de segmentación específicos de la víctima

Una de las señales de detección más claras de la operación es la inclusión de la dirección de correo electrónico del destinatario en el fragmento de la URL, es decir, la parte que aparece después del carácter #. La dirección se codifica con Base64 y se utiliza para personalizar el destino.

Una estructura simplificada podría ser similar a esta:

https://legitimate-service.example/path#BASE64_ENCODED_EMAIL

El fragmento tiene una propiedad útil para los atacantes: por lo general, los navegadores no lo incluyen en la solicitud HTTP que envían al servidor web. Sigue estando disponible para JavaScript en el cliente, pero puede no aparecer en los registros de acceso del servidor ni en las herramientas de seguridad que solo registran el recurso solicitado.

Cuando se carga la página final, su JavaScript puede leer el fragmento, descodificar la dirección de correo electrónico y crear una experiencia de phishing personalizada. La página puede rellenar de antemano la identidad de la víctima y mostrar una imagen del sitio web legítimo de la organización detrás de una interfaz de inicio de sesión falsa.

Esto ofrece dos ventajas. En primer lugar, la víctima ve una página que parece estar relacionada con su empresa, en lugar de un formulario genérico para robar credenciales. En segundo lugar, algunos datos de telemetría de red y del servidor pueden registrar el destino de la redirección sin conservar la dirección de correo electrónico objetivo.

Base64 es un sistema de codificación, no de cifrado. Un producto de seguridad que capture la URL completa puede descodificarla fácilmente. El problema es si ese producto conserva y analiza el fragmento.

Por consiguiente, la presencia de una dirección de correo electrónico codificada después de #, especialmente en un mensaje que enlaza a través de la infraestructura de Google, debe considerarse una pista de detección de gran valor. No demuestra que todas esas URL sean maliciosas, pero proporciona un patrón concreto que los defensores pueden investigar.

El destino se adapta a la víctima y al entorno de inspección

Los correos maliciosos utilizan varios pretextos relacionados con la actividad empresarial, en lugar de una única plantilla uniforme. Entre los temas observados figuran revisiones de documentos, credenciales a punto de caducar, entregas de paquetes, pagos, prestaciones públicas y notificaciones de mensajes de voz.

Después de que el destinatario haga clic, las redirecciones terminan conduciendo a uno de dos resultados principales. El primero es una página de autenticación corporativa falsa diseñada para recopilar nombres de usuario y contraseñas. El segundo es un flujo fraudulento de verificación de identidad que intenta instalar ScreenConnect.

En este caso, ScreenConnect se utiliza como herramienta de acceso remoto, no como mecanismo subyacente de redirección. No se han divulgado las versiones concretas de ScreenConnect implicadas, y la campaña no se describe como una explotación de una vulnerabilidad de software. El peligro reside en convencer al usuario para que instale o ejecute software de administración remota no autorizado.

El marco de phishing puede adaptar el contenido según la ubicación geográfica de la víctima y admite varios idiomas. También recopila información contextual que puede ayudar a los operadores a evaluar tanto al objetivo como a la sesión comprometida.

Según los informes, los datos expuestos incluyen:

• Credenciales de acceso corporativas
• Direcciones IP públicas
• Información de geolocalización
• Cadenas de agente de usuario del navegador
• Registros de intercambio de correo verificados asociados a la organización de la víctima
• Datos de segmentación organizativa y de la sesión

Las credenciales robadas y los metadatos recopilados se envían a los operadores a través de un canal de Telegram, según los informes, en cuestión de segundos. Telegram proporciona una capa de comunicaciones práctica que puede confundirse con otro tráfico de mensajería cifrada, salvo que los defensores supervisen específicamente la actividad de bots y API.

Por tanto, la campaña combina personalización, evasión y exfiltración rápida. Una interacción exitosa puede provocar la toma de control de una cuenta, mientras que la instalación no autorizada de ScreenConnect puede abrir la puerta a la administración remota directa.

Por qué la reputación del dominio por sí sola no basta contra esta técnica

Muchos controles de correo electrónico y web inspeccionan el nombre de host visible de un enlace, consultan servicios de reputación y siguen un número limitado de redirecciones. Ese modelo pierde eficacia cuando los atacantes pueden ensamblar una cadena a partir de componentes legítimos de servicios en la nube y plataformas publicitarias.

Bloquear ampliamente los dominios de Google provocaría una alteración operativa considerable. Los atacantes se benefician de esa limitación: los defensores deben distinguir el uso malicioso de grandes volúmenes de tráfico empresarial normal, en lugar de denegar directamente la infraestructura.

Un analizador también puede observar un comportamiento diferente al de un visitante humano. El sistema final que roba las credenciales puede esperar a que termine la inspección, evaluar señales del entorno o modificar su respuesta según la ubicación y las características de la sesión. Un resultado limpio de una solicitud automatizada no garantiza que el usuario reciba la misma página.

Por tanto, los controles deben evaluar la ruta de navegación completa, incluidos los siguientes elementos:

1. La URL original incluida en el correo electrónico
2. Cada redirección intermedia y sus parámetros
3. El dominio registrado final y la ubicación del alojamiento
4. Los scripts del lado del cliente que se ejecuten después de cargar la página
5. Los fragmentos de URL conservados en el mensaje original
6. Las descargas posteriores, los formularios de inicio de sesión o las solicitudes de acceso remoto
7. Las comunicaciones salientes iniciadas después de la interacción del usuario

Esta campaña no depende de un único producto de Google comprometido ni de una versión vulnerable divulgada. Explota las relaciones de confianza en torno a varios servicios y las brechas existentes entre la telemetría del correo electrónico, el proxy, el navegador, el endpoint y la identidad.

Los defensores deben buscar tráfico de Telegram y actividad de ScreenConnect

Las organizaciones deben aplicar los indicadores de compromiso publicados en los sistemas de filtrado DNS, las pasarelas web seguras, los proxies, los endpoints y las plataformas SIEM. Bloquear la amenaza en una sola capa puede hacer que se pasen por alto fases posteriores de la cadena de redirección.

Los equipos de seguridad también deben buscar conexiones salientes a la API de bots de Telegram y otras comunicaciones inusuales relacionadas con Telegram. Ese tráfico merece un análisis adicional cuando se produce después de hacer clic en un correo sospechoso, visitar una página de autenticación desconocida o ejecutar un proceso nuevo.

La búsqueda en los endpoints debe centrarse en las instalaciones y la actividad no autorizadas de ScreenConnect. Entre las comprobaciones relevantes se incluyen eventos de instalación inesperados, servicios creados recientemente, ejecuciones desde directorios en los que los usuarios pueden escribir y sesiones de acceso remoto que no correspondan a un flujo de soporte aprobado. Las implementaciones legítimas de la organización deben distinguirse de las instancias no autorizadas.

A los usuarios potencialmente afectados se les deben restablecer las contraseñas. Los defensores también deben revisar los registros de autenticación en busca de ubicaciones o dispositivos inusuales, creación de sesiones, cambios en la autenticación multifactor y accesos realizados poco después de la entrega del mensaje de phishing.

Entre las medidas defensivas útiles se incluyen:

• Conservar las URL completas, incluido el contenido posterior al carácter #, en la telemetría de análisis del correo electrónico.
• Descodificar los fragmentos Base64 durante la inspección de mensajes y URL.
• Seguir todas las redirecciones en lugar de evaluar únicamente el primer nombre de host de Google.
• Correlacionar las redirecciones de servicios de Google con los formularios de inicio de sesión que aparezcan posteriormente.
• Buscar descargas, instalaciones o ejecuciones posteriores de ScreenConnect.
• Supervisar el tráfico de la API de bots de Telegram como posible canal de exfiltración.
• Advertir a los usuarios de que los dominios conocidos de servicios en la nube no garantizan un destino seguro.
• Investigar los mensajes relacionados con documentos, entregas, pagos, mensajes de voz, prestaciones o caducidad de credenciales.

La concienciación de los usuarios debe centrarse en el comportamiento, no en la marca. Un enlace puede comenzar en un servicio legítimo de Google y terminar en una página controlada por los atacantes. Las solicitudes de autenticación inesperadas y las comprobaciones de identidad que exigen software de acceso remoto deben notificarse, no completarse.

La característica definitoria de esta campaña no es un único señuelo de phishing. Es el uso coordinado de infraestructura de redirección de confianza, datos de segmentación ocultos, contenido web adaptable y exfiltración casi en tiempo real para hacer que un ataque personalizado parezca una actividad rutinaria.