Resumen de la amenaza
El abuso de redireccionamientos de Google es una técnica muy extendida en la que los autores de amenazas aprovechan los servicios legítimos de redireccionamiento de URL de Google para ocultar enlaces maliciosos, eludir las defensas de seguridad del correo electrónico y aumentar la percepción de legitimidad de las campañas de phishing y spam. Los atacantes se aprovechan de la reputación de dominio de confianza de Google para que los enlaces parezcan apuntar a google.com (u otras propiedades de Google), mientras redirigen a los usuarios a páginas destinadas a robar credenciales, malware o contenido no deseado.
Dado que estas redirecciones se sirven desde la infraestructura auténtica de Google, suelen superar las comprobaciones de reputación de dominio, las políticas de reescritura de URL y el escrutinio de los usuarios. Los defensores que se basan en listas de permitidos con *.google.com o que consideran que las URL de Google son intrínsecamente seguras siguen expuestos a este tipo de abuso.
El equipo de investigación de amenazas de Mimecast sigue observando técnicas de redireccionamiento de Google en el contexto de la recopilación de credenciales y el spam de gran volumen. Las secciones siguientes documentan las principales familias de redireccionamientos, su estructura de URL y su comportamiento de evasión.
Familias de redireccionamientos
1. Google Web Light
Google Web Light era un servicio de transcodificación que ofrecía versiones más ligeras y rápidas de las páginas web a los usuarios con conexiones móviles lentas (por ejemplo, 2G), principalmente en países como la India, Brasil e Indonesia. Utilizaba el dominio googleweblight.com y los recursos de nivel de ruta «sp» e «i» para recuperar y redirigir a una URL de destino pasada en el parámetro «u».
Google retiró Web Light el 19 de diciembre de 2022 y eliminó la documentación pública, pero el dominio y el comportamiento de redireccionamiento siguen estando accesibles y aún se utilizan de forma maliciosa en campañas maliciosas.
URL de ejemplo
https://googleweblight.com/sp?otherkeys=othervals&u=https://7d63dd4a.ryhryhyj6j56h6t4635.pages.dev?ut=name@domain.com
|
Parte
|
Valor
|
|
Nombre de host
|
Siempre googleweblight.com
|
|
Recurso de redirección
|
Recurso a nivel de ruta necesario para la redirección: debe ser «sp» o «i»
|
|
Parámetros de consulta opcionales
|
Los parámetros de consulta personalizados pueden aparecer antes de «u» y no afectan al éxito de la redirección
|
|
Clave de destino de la redirección
|
La clave «u». Su valor es la URL de destino. Todos los parámetros de consulta que siguen a «u» pertenecen a la página de destino
|
|
Protocolo de redirección
|
No es obligatorio. El uso legítimo suele incluir un protocolo; el uso indebido suele omitirlo
|
|
Destino de la redirección
|
Valor de «u». Debe contener un protocolo y una URL de destino válida
|
2. Redirección de URL principal: `google.*/url`
El mecanismo principal es la redirección abierta en rutas como /url en diversos servidores de Google.
Busca «google./url?» con un parámetro «q=» que contenga una URL. Cualquier servidor que ofrezca esta ruta puede redirigir a un destino arbitrario.
URL de ejemplo
https://www.google.com/url?q=https://malicious-site.com&sa=D&sntz=1
Parámetros habituales
|
Parámetro
|
Función
|
|
q=
|
URL de destino (destino principal de la redirección)
|
|
sa=D
|
Navegación directa; con sntz=1 se pueden reducir las advertencias intersticiales
|
|
sa=t
|
Estilo «clic en búsqueda»; a menudo se combina con un uso indebido de AMP
|
|
sntz=1
|
Parámetro de zona horaria; suele combinarse con sa=D en casos de uso indebido
|
|
usg=
|
Token de firma vinculado a la cadena de consulta; cambiar otros parámetros sin actualizar usg puede interrumpir la redirección
|
|
rct=j
|
Contexto del sitio de referencia; observado en casos de abuso relacionados con AMP
|
|
|
3. Uso indebido de Google AMP (Accelerated Mobile Pages)
Google AMP es un marco HTML de código abierto que se utiliza para crear sitios web optimizados para su uso en navegadores y dispositivos móviles. Dado que AMP puede mostrar el contenido de las páginas web de forma integrada, los autores de amenazas ahora lo utilizan indebidamente para presentar páginas de phishing en tiempo real después de que el usuario haga clic en un enlace.
Abuso de AMP independiente
|
Campo
|
Valor
|
|
URL de ejemplo
|
https://google.com/amp/malicious-site.com
|
|
Recurso de redirección
|
Ruta /amp/<dominio-o-ruta> (la variante maliciosa omite la «s»; la forma legítima es /amp/s/...)
|
|
Destino de la redirección
|
La ruta que sigue a /amp/ es el destino (por ejemplo, malicious-site.com)
|
AMP legítimo:
https://google.com/amp/s/domain.com/path
Forma maliciosa (omitiendo la «s»):
https://google.com/amp/domain.com
Esta variante es relativamente poco frecuente en el tráfico benigno, pero aparece en múltiples campañas maliciosas. A menudo se combina con otros indicadores de phishing, en lugar de utilizarse como única señal de bloqueo.
Los atacantes incrustan URL de Google AMP en los correos electrónicos (por ejemplo, ...&url=amp/malicious-site.com). Al modificar el parámetro «q», se puede alterar el destino final sin que la URL deje de pasar por Google, por lo que el enlace visible sigue siendo una URL de Google.
Patrón de ejemplo
https://www.google.co.uk/url?q=...&rct=...&sa=t&url=amp/mimecast.com
Cambiar la última ruta en url=amp/... puede redirigir a un sitio arbitrario; eliminar /amp suele activar la página de advertencia intersticial de Google.
Este servicio es muy flexible en cuanto al formato de las URL y normaliza una amplia variedad de formatos incorrectos, lo que permite a los actores maliciosos eludir las medidas de visibilidad existentes modificando las URL de formas inesperadas.
4. Google Travel: `/travel/clk`
Esta redirección abierta está relacionada con el servicio Google Travel, disponible en todos los nombres de dominio de Google. Dirige el tráfico a sitios externos a través del producto Google Travel. Se trata de una redirección abierta parcialmente contenida: se requiere un token generado por el sistema, pero este no restringe el destino al que puede apuntar la redirección. Dicho token puede generarse a través de Google Travel previa solicitud y no impide que se modifique el destino.
|
Campo
|
Valor
|
|
Ruta URL
|
/travel/clk en google.<tld>
|
|
pc=
|
Token que controla si se produce una redirección; no limita el destino
|
|
pcurl=
|
URL de destino
|
|
Vigencia del token
|
Los tokens no tienen una fecha de caducidad visible y pueden reutilizarse durante semanas o meses
|
URL de ejemplo
https://www.google.com/travel/clk?pc=AA80Osz1Y9jFF8K4dj7wcdCsT2otn5mxfNX82xi-cd4&pcurl=https://malicious-site.com
5. Hosts de Google no estándar (ccTLD y subdominios de servicio)
Misma estructura que la redirección de URL principal; solo cambia el nombre de host.
Los atacantes utilizan el mismo patrón /url?q= (o equivalente) en hosts distintos de www.google.com, por ejemplo, google.es, google.de, google.fr, maps.google.*, contacts.google.* y drive.google.*. Se trata de propiedades legítimas de Google, pero suelen incluirse con menos frecuencia en las reglas específicas de redireccionamiento.
Dominios con código de país (ccTLD)
Los atacantes utilizan ccTLD de Google menos supervisados, de modo que las listas de permitidos basadas en dominios y las comprobaciones de reputación sigan detectando «Google», al tiempo que reducen la cobertura de las reglas personalizadas.
Ejemplos:
https://google.es/url?q=http://bad-domain.com
https://google.de/url?...
https://google.fr/url?...
Subdominios de servicios
El uso indebido de redireccionamientos también se observa en subdominios que no suelen asociarse con redireccionamientos de enlaces, lo que aumenta el número de patrones que deben gestionar los defensores:
|
Servicio
|
Ejemplo
|
|
Maps
|
https://maps.google.de/url?q=http://bad-domain.com
|
|
Contactos
|
https://contacts.google.fr/url?q=...
|
|
Drive
|
https://drive.google.*/url?q=...
|
También se observan como parte de cadenas de redireccionamiento procedentes de otros sitios:
URL de origen → redirección de Google (con &sa=D&sntz=1&usg=) → valor de url?q=
6. Google Meet/Hangouts y App Engine
(1) Meet
Ruta meet.google.com/linkredirect con el parámetro de consulta dest= que contiene la URL de destino. Anteriormente, Google Hangouts también seguía una ruta similar para la redirección.
https://meet.google.com/linkredirect?dest=https://malicious-site.com
(2) App Engine
Ruta appengine.google.com/_ah/logout con continue= que apunta a otra URL (a menudo Hangouts o el sitio final). En el correo electrónico, las cadenas que combinan ambos son una clara señal de abuso.
Ejemplo de redireccionamiento en cadena
https://www.google.com/url?sa=D&q=https://appengine.google.com/_ah/logout?continue=https://hangouts.google.com/linkredirect?dest=https://www.vizor.cloud/...
Este tipo de cadenas (cierre de sesión en App Engine → Hangouts → destino final) no tienen ningún uso legítimo habitual en el correo electrónico y son motivo para un bloqueo con alto nivel de confianza.
7. Google DoubleClick / Servicios publicitarios
Los productos de análisis de enlaces de marketing de Google exponen redireccionamientos abiertos en googleadservices.com y doubleclick.net. A diferencia de los redireccionamientos /url de la Búsqueda de Google, estos no están documentados públicamente como protegidos contra el abuso y se ha observado un aumento de su uso indebido. Los atacantes suelen extraer enlaces de anuncios válidos y cambiar únicamente el destino «adurl», a menudo encadenando redireccionamientos adicionales y conservando fragmentos de consulta (por ejemplo, el correo electrónico del destinatario) para personalizar las páginas de phishing.
(1)doubleclick.net
URL de ejemplo
https://adclick.g.doubleclick.net/pcs/click?xai=...&sig=...&urlfix=1&adurl=https://wikipedia.org
|
Parte
|
Valor
|
|
Nombre de host
|
Estático: adclick.g.doubleclick.net o googleads.g.doubleclick.net
|
|
Recurso de redireccionamiento
|
Ruta siempre /pcs/click
|
|
Parámetros analíticos
|
Datos analíticos o de la cuenta. Se pueden modificar, omitir o sustituir a voluntad
|
|
Clave de destino de la redirección
|
adurl: debe ir seguida de una URL de redirección válida
|
|
Destino de la redirección
|
Valor de adurl
|
|
Notas
|
El formato de la consulta es muy flexible; se conservan los fragmentos de la URL de redirección
|
(2) googleadservices.com
URL de ejemplo
https://www.googleadservices.com/pagead/aclk?sa=L&ai=...&sig=...&adurl=https://wikipedia.org
|
Parte
|
Valor
|
|
Nombre de host
|
Estático: www.googleadservices.com (no se conocen otras variantes)
|
|
Recurso de redirección
|
Ruta siempre /pagead/aclk
|
|
Parámetros analíticos obligatorios
|
Nombres y valores de los parámetros exigidos y validados por Google para que la redirección se realice correctamente
|
|
Parámetros parcialmente obligatorios
|
Si faltan o son incorrectos, Google muestra un intersticial de seguridad o advertencia al hacer clic
|
|
Parámetros opcionales
|
No parecen influir en el éxito de la redirección; se pueden modificar o eliminar
|
|
Clave de destino de la redirección
|
adurl: debe ir seguida de una URL de redirección válida
|
|
8. Google Translate
Se hace un uso indebido de translate.goog codificando el dominio de phishing en el nombre de host.
URL de ejemplo
https://phishing-com.translate.goog/?_x_tr_sl=auto&_x_tr_tl=en
(Se decodifica al host de destino phishing.com.)
Los nombres de host adoptan la forma *..translate.goog, donde el subdominio es el dominio de destino con los puntos sustituidos por guiones (por ejemplo, example.com → example-com.translate.goog). Pueden aparecer parámetros como _x_tr_sl=auto y _x_tr_tl=en. Es menos probable que los filtros de seguridad los detecten, ya que parecen dominios legítimos de Google.
Patrón de construcción
- Sustituir los puntos del dominio de destino por guiones (por ejemplo, example.com → example-com)
- Utilizar como subdominio de translate.goog: https://example-com.translate.goog
- Los parámetros opcionales como _x_tr_sl=auto o _x_tr_tl=en hacen que la URL parezca un enlace normal de Translate
9. Redirección de Google OAuth
Google OAuth 2.0 es un marco de autorización estándar del sector diseñado para permitir un acceso seguro y delegado a las cuentas de usuario sin necesidad de compartir contraseñas. El sistema permite que aplicaciones de terceros soliciten permisos limitados y específicos para acceder a los datos del usuario (correo electrónico, perfil, calendario, etc.) a través de un proceso de consentimiento controlado por el usuario.
Los flujos de autorización de Google OAuth 2.0 utilizan una redirección para devolver al usuario a la aplicación tras el consentimiento. El parámetro redirect_uri indica a Google dónde enviar al usuario (y el código de autorización o token). Si un atacante puede controlar o influir en este valor, puede robar códigos de autorización o tokens, o redirigir a los usuarios a una página de phishing tras un inicio de sesión en Google que parezca legítimo.
Ejemplo de URL (solicitud de autorización)
https://accounts.google.com/o/oauth2/v2/auth?client_id=123456789.apps.googleusercontent.com&redirect_uri=https://attacker.com/callback&response_type=code&scope=openid%20email%20profile&state=random_state
Técnicas de evasión
Dado que el token «usg» está vinculado a la cadena de consulta, los atacantes no pueden modificar libremente los parámetros de consulta para pasar datos específicos del usuario sin invalidar la redirección. Por lo tanto, los atacantes utilizan fragmentos de URL para el seguimiento, el rellenado previo de formularios o el envío de tokens a la página final sin interrumpir la redirección de Google.
Los fragmentos de URL (la parte que viene después de #):
- No se envían al servidor
- No se incluyen en la validación de usg
- El navegador los conserva durante la redirección
Ejemplo
https://google.es/url?q=http://malicious-site.com&usg=...#user123
Patrones de evasión adicionales:
|
Técnica
|
Descripción
|
|
sa=D con sntz=1
|
Permite evitar la ventana intersticial de advertencia al salir de Google, especialmente si se combina con un usg válido
|
|
sa=t con url=amp/...
|
Patrón de búsqueda y clic observado en casos de abuso; cambiar la ruta final en url=amp/... puede redirigir a los usuarios a cualquier sitio sin dejar de pasar por Google
|
|
Normalización del formato AMP
|
Los actores maliciosos modifican la estructura de las URL de formas inesperadas para eludir la coincidencia de patrones estáticos
|
|
Rotación de ccTLD y subdominios
|
Desvía el uso indebido hacia nombres de host de Google menos supervisados, al tiempo que conserva la semántica de las redirecciones
|
|
Conservación de fragmentos en las redirecciones publicitarias
|
Los fragmentos de «adurl» transportan identificadores de destinatarios o datos de autocompletado de formularios a la página final de phishing
|
|
|
Protección de Mimecast
Mimecast ha identificado atributos asociados al uso indebido de redireccionamientos de Google mediante el análisis de enlaces en correos electrónicos, la inspección de reescritura de URL y la evaluación de cadenas de redireccionamiento tras el clic. La cobertura de detección abarca:
- Redireccionamientos «/url?q=» en servidores de Google estándar y ccTLD
- Uso indebido de la ruta AMP (/amp/ sin /s/)
- Redireccionamientos de Web Light retirados pero aún accesibles en googleweblight.com
- Tokens de redireccionamiento de Travel en /travel/clk
- Redireccionamientos encadenados de Hangouts y App Engine
- Manipulación de adurl en DoubleClick y Google Ad Services
- Codificación del nombre de host en *.translate.goog
- Solicitudes de autorización OAuth con valores de redirect_uri sospechosos o no registrados
El equipo de investigación de amenazas sigue vigilando la aparición de nuevas variantes de formato, rotaciones de hosts y combinaciones con infraestructuras de recopilación de credenciales y distribución de malware.
Recomendaciones
Formación en concienciación de los usuarios
- Informe a los empleados de que un enlace que muestre google.com no garantiza la seguridad; los atacantes suelen abusar de las redirecciones de Google para llegar a páginas maliciosas
- Indique a los usuarios que comprueben la barra de direcciones del navegador tras cualquier redirección, especialmente antes de introducir credenciales
- Advertir de que las páginas de advertencia intersticiales de Google pueden suprimirse mediante determinadas combinaciones de parámetros; la ausencia de una advertencia no indica legitimidad
- Haga hincapié en que no se debe confiar en los correos electrónicos no solicitados basándose únicamente en el dominio visible del enlace
Conclusión
El abuso de las redirecciones de Google sigue siendo una de las técnicas más duraderas en el repertorio de los actores maliciosos. Al desviar a las víctimas a través de la infraestructura auténtica de Google, los atacantes se aprovechan de la confianza en el dominio, eluden las listas de permitidos poco sofisticadas y aumentan las tasas de clics en las campañas de phishing y spam. La amplitud de las familias de redireccionamientos —desde puntos finales retirados de Web Light hasta la manipulación de parámetros de OAuth— implica que los defensores no pueden confiar en una única regla de detección o en una lista de dominios permitidos.
Las organizaciones deben tratar todas las URL de Google presentes en correos electrónicos no solicitados como no fiables hasta que se hayan validado la cadena completa de redireccionamientos y el destino final. Los equipos de seguridad deben dar prioridad a la detección tanto en la fase del enlace del correo electrónico como en la fase de redireccionamiento posterior al clic, prestando especial atención a los redireccionamientos encadenados, la evasión basada en fragmentos y el uso indebido de ccTLD y subdominios de servicios menos supervisados.
