Introducción

Con la confianza de millones de desarrolladores en todo el mundo, GitHub suele ser objeto de abuso y convertirse en un arma inesperada en manos de actores de amenazas con motivaciones financieras, una tendencia en evolución y cada vez mejor documentada. Investigaciones previas han identificado casos en los que la infraestructura de GitHub fue explotada para distribuir páginas de phishing, entregar cargas útiles de malware tipo stealer y alojar contenido malicioso a gran escala, aprovechando la reputación de confianza de la plataforma, la cobertura HTTPS gratuita y la facilidad de implementación. Lo que demuestra esta campaña es que esta táctica ha madurado: los actores de amenazas ahora combinan el alojamiento en GitHub Pages con backends de exfiltración sin servidor y arquitecturas modulares de kits para llevar a cabo operaciones persistentes a gran escala, significativamente más difíciles de detectar y desmantelar.

Lo que distingue a esta operación es su escala, persistencia y sofisticación operativa. Los investigadores de Group-IB identificaron una campaña de phishing a gran escala dirigida a al menos 12 instituciones financieras en México, activa durante aproximadamente tres años y construida sobre una arquitectura completamente sin servidor que abusa de GitHub Pages para el alojamiento y de la API de SheetBest para la exfiltración de credenciales, eliminando la necesidad de cualquier infraestructura de backend dedicada. El seguimiento histórico y el análisis de la infraestructura indican que esta campaña, o sus variantes, ha mantenido una persistencia en el largo plazo, reutilizado componentes y recibido mantenimiento operativo continuo durante todo este período.

Si bien no se ha confirmado el mecanismo exacto de distribución, es probable que las víctimas sean alcanzadas a través de canales comunes de entrega de phishing, como SMS, aplicaciones de mensajería, correo electrónico o plataformas de redes sociales. En todos los casos, la víctima recibe una URL fraudulenta que la dirige directamente a una página de phishing que suplanta la identidad de una institución financiera de confianza.

Group-IB ha reportado a GitHub todas las páginas de phishing y dominios identificados durante esta investigación.

Hallazgos clave

• Se identificó un kit de phishing modular que permite a los actores de amenazas dirigirse dinámicamente a al menos 12 instituciones financieras que operan en México desde una única infraestructura reutilizable.
• El análisis del historial de commits en GitHub reveló múltiples cuentas de operadores con actividad continua durante más de un año, lo que confirma una operación de phishing colaborativa y con mantenimiento continuo.
• El esquema de phishing recopila credenciales de usuario, datos de tarjetas de pago, identificadores de clientes y contraseñas mediante un flujo de múltiples etapas que imita los procesos legítimos de autenticación bancaria.
• La operación abusa de GitHub Pages como una plataforma de alojamiento distribuido, lo que permite un despliegue rápido y redundancia operativa.
• Se identificaron más de 100 dominios asociados con la campaña, cada uno alojando múltiples páginas de phishing en diferentes rutas, lo que refleja una infraestructura altamente distribuida y de gran escala.
• La recopilación de credenciales se centraliza mediante servicios de terceros (API de SheetBest), lo que permite un modelo escalable de exfiltración de datos sin servidor que almacena las credenciales robadas directamente en hojas de cálculo de Google controladas por los atacantes en tiempo real.
• Las páginas de phishing emplean JavaScript ofuscado cargado externamente con estructuras de rutas aleatorizadas, lo que dificulta el análisis estático y permite la rotación de cargas útiles sin modificar la propia página de phishing.
• También se identificó un método alternativo de exfiltración mediante el cual las credenciales eran enviadas en tiempo real a un bot de Telegram, lo que demuestra la flexibilidad operativa de la infraestructura de backend utilizada en la campaña.

¿A quién puede interesarle este blog?

• Analistas de ciberseguridad y equipos de seguridad corporativa
• Analistas de malware
• Especialistas en inteligencia de amenazas
• Investigadores de ciberseguridad
• Equipos de Respuesta ante Emergencias Informáticas (CERT)
• Investigadores de las fuerzas del orden
• Unidades policiales especializadas en delitos cibernéticos

Portal de Inteligencia de Amenazas de Group-IB: GitBait

Los clientes de Group-IB pueden acceder a nuestro portal de Inteligencia de Amenazas para obtener más información sobre GitBait y el esquema de phishing descrito en este blog.

Descripción general de la campaña de phishing

La infraestructura analizada corresponde a un kit de phishing modular que incluye un selector interno de campañas utilizado por los actores de amenazas para generar páginas de phishing específicas para cada institución. Este selector no está destinado a las víctimas, sino que funciona como una interfaz operativa que permite a los atacantes seleccionar las instituciones objetivo y distribuir las URL fraudulentas correspondientes. Su presencia confirma la existencia de una infraestructura de phishing multiobjetivo diseñada para ser reutilizada en múltiples campañas.

Cabe destacar que tanto el panel del kit de phishing como las páginas de destino suplantadas han sido desarrollados para funcionar en equipos de escritorio y dispositivos móviles, lo que evidencia un esfuerzo deliberado por maximizar el alcance y aumentar la tasa de interacción de las víctimas en diferentes dispositivos.

La campaña está alojada en numerosos repositorios independientes de GitHub Pages, en lugar de operar desde un único dominio. Cada repositorio contiene contenido de phishing duplicado desplegado en diferentes rutas de directorio (por ejemplo, /cancelacion/, /soporte/, /mb1/), lo que refleja una estrategia deliberada para distribuir la infraestructura, evadir las acciones de desmantelamiento y volver a desplegar rápidamente páginas clonadas cuando se elimina alguno de los repositorios.

La operación de phishing está dirigida principalmente a organizaciones del sector bancario y financiero en México, incluidas instituciones tanto nacionales como extranjeras con operaciones en el país. El seguimiento histórico sugiere que esta infraestructura de phishing, o sus variantes, ha estado activa durante más de tres años, demostrando persistencia, reutilización de componentes y un enfoque estructurado para llevar a cabo operaciones de phishing financiero a gran escala.

Páginas de destino de instituciones financieras suplantadas

Los dominios analizados alojan un kit de phishing modular que incluye múltiples páginas de destino específicas para cada marca, diseñadas para suplantar a instituciones financieras legítimas que operan en México. La estructura del sitio permite a los atacantes seleccionar una institución objetivo y redirigir a las víctimas a páginas de phishing personalizadas que replican visualmente la presencia en línea de portales oficiales de banca o de servicios.

Cada página de destino funciona como una etapa de generación de confianza, presentando elementos clonados de marca, diseño y navegación destinados a convencer a las víctimas de que están interactuando con una institución legítima antes de ser redirigidas a formularios para la recopilación de credenciales.

Etapa de recopilación de credenciales mediante phishing

Tras las páginas iniciales de suplantación, las víctimas son redirigidas a páginas de phishing específicamente diseñadas para recopilar información sensible de autenticación y datos financieros. Estas páginas replican la identidad visual y los flujos de inicio de sesión de portales legítimos de banca en línea, induciendo a los usuarios a ingresar datos como nombres de usuario, identificadores de cliente, contraseñas e información de tarjetas.

Un análisis adicional confirma que la etapa de recopilación de credenciales contiene campos de entrada activos que solicitan información sensible, como datos de tarjetas de pago, identificadores de clientes y contraseñas. La estructura incluye múltiples formularios anidados e identificadores genéricos de envío, características comúnmente asociadas con kits de phishing clonados. Esta etapa representa el punto final de captura de datos dentro de una operación de phishing multimarca.

Intercepción de credenciales y exfiltración mediante la API de SheetBest

Las páginas de phishing emplean un script JavaScript del lado del cliente que identifica los elementos del formulario de inicio de sesión y configura un mecanismo para interceptar el envío de la información ingresada. Al impedir el comportamiento predeterminado del navegador, el script captura las credenciales introducidas por la víctima antes de que se procese cualquier solicitud legítima.

Los datos recopilados se serializan en formato JSON y se envían mediante una solicitud POST a un endpoint externo de la API de SheetBest, lo que confirma la exfiltración activa de información en tiempo real. Tras el intento de envío, el script reemplaza dinámicamente la interfaz de inicio de sesión por una pantalla de verificación, simulando un flujo de trabajo bancario legítimo con el fin de mantener la confianza del usuario y reducir las sospechas.

Figura 4: El script intercepta las credenciales y las exfiltra a través de un endpoint de la API de SheetBest.

Análisis de encabezados y exfiltración de datos

El kit de phishing reutiliza una estructura consistente de formularios HTML en todas las instituciones suplantadas:

• ID del Formulario: id=”contact-form”
• IDs de los Elementos: id=”registro” y id=”exito” (utilizado para alternar entre la pantalla de inicio de sesión y la pantalla de verificación)
• Lógica de Verificación: registro.classList.remove(‘activo’); exito.classList.add(‘activo’); (activada tras el envío del formulario)

El análisis de tráfico de red confirma que el formulario de phishing transmite las credenciales de las víctimas mediante solicitudes POST a un endpoint de la API de SheetBest, que almacena los datos directamente en una hoja de cálculo de Google controlada por los atacantes. Esta técnica elimina la necesidad de contar con un servidor backend dedicado y es utilizada habitualmente en los kits de phishing modernos para facilitar el despliegue rápido y la recopilación de credenciales a gran escala.

• e.preventDefault() combinado con una llamada a fetch() hacia una API externa dentro de un controlador del evento de envío del formulario
• Método de solicitud: POST
• URL de la solicitud: https://api.sheetbest[.]com/sheets/f2958fbe-cdd7-4796-a4e4-19539d759a9f
• Dirección Remota: 159.89.254[.]93:443
• Métodos Permitidos: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, cuerpo JSON con claves numéricas (“1”, “2”, “3”) asociadas a los valores de los campos de credenciales

La telemetría de red indica que múltiples páginas de phishing que suplantan a distintas instituciones financieras utilizan este mismo mecanismo de exfiltración de datos. Aunque cada página de phishing emplea un identificador diferente de hoja de cálculo de SheetBest, todos los formularios de recopilación de credenciales envían los datos de las víctimas mediante solicitudes HTTP POST a la misma infraestructura de API de backend, que se resuelve en la dirección IP 159.89.254[.]93 a través de HTTPS.

Se identificaron los siguientes endpoints de la API de SheetBest que recibían credenciales enviadas desde páginas de phishing asociadas con esta campaña:

• https://api.sheetbest[.]com/sheets/0e2a1336-e971-496f-9eb2-cd8dcd25565c
• https://api.sheetbest[.]com/sheets/db4a7782-bc66-4a99-875b-ede99744f3fe
• https://api.sheetbest[.]com/sheets/47edba58-31f7-41e6-af18-31c77046dee1
• https://api.sheetbest[.]com/sheets/f2958fbe-cdd7-4796-a4e4-19539d759a9f
• https://api.sheetbest[.]com/sheets/fe9f1e2d-16c9-4d92-9bdf-8425921ac073
• https://api.sheetbest[.]com/sheets/578ad828-fc67-4447-9182-197f92c1f302

La reutilización de una lógica de envío idéntica, la misma infraestructura de API y patrones de solicitud consistentes en múltiples páginas de phishing sugiere firmemente la existencia de un backend centralizado para la recopilación de credenciales, diseñado para dar soporte a múltiples plantillas de phishing y marcas suplantadas dentro de una misma campaña.

Infraestructura de phishing y patrones de rutas

Independientemente del dominio de GitHub utilizado, todas las instancias de phishing siguen una estructura consistente de múltiples etapas. En primer lugar, las víctimas son redirigidas a una página de destino que suplanta a la institución objetivo y, posteriormente, a una ruta final donde se lleva a cabo la recopilación de credenciales.

Las siguientes rutas representan los principales puntos de entrada observados en toda la infraestructura de phishing, e incluyen tanto señuelos dirigidos a los usuarios (por ejemplo, temáticas relacionadas con la cancelación de cuentas o el soporte al cliente) como rutas internas de direccionamiento del panel:

Las siguientes rutas corresponden a los endpoints finales de recopilación de credenciales, cada uno asociado a una plantilla específica de suplantación de instituciones. La nomenclatura consistente de las rutas en las distintas implementaciones constituye un sólido indicador de la infraestructura:

• /1023.html
• /index.html
• /login.html
• /h.html
• /159enlace.html
• /login.html
• /ba306.html
• /aztlog.html
• /159bb.html
• /Login.html

Esta estructura modular de rutas —que separa las etapas de atracción, direccionamiento y recopilación de credenciales— permite el despliegue escalable y la reutilización del mismo kit de phishing en múltiples marcas del sector financiero con modificaciones mínimas.

Carga de scripts externos ofuscados

Las páginas de phishing cargan código JavaScript externo a través de rutas altamente ofuscadas y aleatorizadas, en lugar de incorporar la lógica directamente en el HTML. Este enfoque oculta la funcionalidad maliciosa, dificulta el análisis estático y permite la rotación de cargas útiles sin necesidad de modificar la propia página de phishing.

Ejemplos observados en múltiples instituciones suplantadas:

• Institución A: src=”/Vm7LSL59GGpJ8EK-ew/atw1fpkSb6ai/b3o0AQ/EE4aPHI/MCy8″
• Institución B: src=”ZwiOgC/MDi0/czp/Ecr/GfAoqZgEZg8/OkENmtprk9ipVi/JRJeM1UD/GTZYSjh/gAQc”
• Institución C: src=”hxiGOzOB98/NZ/sLoDRpVx/JuaQJfDNbtO9/dzldXmhnIQk/L1EkIT/BjSBw”

La estructura aleatorizada de las rutas dificulta la detección basada en firmas y permite a los atacantes rotar o reemplazar la carga útil maliciosa sin alterar la propia página de phishing, lo que reduce significativamente la probabilidad de ser detectados por herramientas automatizadas de seguridad.

Análisis del repositorio de GitHub

El análisis de un repositorio de GitHub que alojaba páginas de phishing confirmó que la recopilación de credenciales se realizaba a través del servicio SheetBest y que la infraestructura era mantenida activamente por múltiples colaboradores.

La revisión del historial de commits reveló que el archivo responsable del envío de formularios fue modificado recientemente para rotar el endpoint de SheetBest utilizado para la recopilación de credenciales, un patrón que también se observó en múltiples dominios asociados con la campaña.

Los metadatos del repositorio confirman la existencia de una operación con mantenimiento continuo:

• 66 commits, lo que evidencia un desarrollo continuo.
• 3 colaboradores, lo que indica una actividad colaborativa.
• Método de despliegue: flujo de trabajo de GitHub Pages basado en Jekyll mediante GitHub Actions, que permite la compilación y publicación automatizadas de la infraestructura de phishing.

Las páginas de phishing también comparten una pila tecnológica de frontend idéntica::

• Versión de Bootstrap: [email protected]
• Hash de SRI de Bootstrap CSS: sha384-KK94CHFLLe+nY2dmCWGMq91rCGa5gtU4mk92HdvYe+M/SXH301p5ILy+dN9+nJOZ
• Hash Sri de Bootstrap JS: sha384-ENjdO4Dr2bkBIFxQpeoTz1HIcje39Wm4jDKdf19U8gI4ddQ3GYNS7NTKfAdVQSZe
• Fuentes de Google Fonts: Kanit (300, 400, 600, 700) y Play (400, 700)
• Hojas de estilos personalizada: css/style.css
• Método de despliegue: Jekyll + GitHub Actions

Cuentas de operadores y direcciones de correo electrónico asociadas

El análisis del historial de commits reveló múltiples cuentas involucradas en el mantenimiento de la infraestructura de phishing, junto con las direcciones de correo electrónico asociadas:

Cabe destacar que las cuentas ce-soporte y soporte-s1 comparten la misma dirección de correo electrónico (jejrvsbdb@gmail[.]com), lo que indica que probablemente están controladas por el mismo operador.

El historial de commits también confirma que plantillas destinadas a suplantar a otras instituciones financieras estaban presentes en versiones anteriores del repositorio y fueron eliminadas posteriormente, lo que indica que el alcance de los objetivos de la campaña se ha ajustado dinámicamente a lo largo del tiempo.

Método de Distribución

El análisis del código fuente HTML del repositorio revela dos indicadores técnicos coincidentes que, en conjunto, permiten identificar el vector de distribución más probable de la campaña.

Figura 5: Repositorio de GitHub que muestra código HTML de phishing con etiquetas Open Graph para aplicaciones de mensajería.

Directiva robots noindex/nofollow. La página de recopilación de credenciales incluye la etiqueta <meta name=”robots” content=”noindex, nofollow”>, que indica explícitamente a los rastreadores de los motores de búsqueda que no indexen ni sigan la página. Esto confirma que nunca fue diseñada para atraer tráfico orgánico, sino para ser accedida exclusivamente mediante un enlace directo entregado a la víctima.

Metadatos Open Graph diseñados específicamente para el engaño. Las páginas de destino principales del repositorio contienen un conjunto completo de etiquetas Open Graph (og:title, og:description, og:image, og:site_name), configuradas con contenido que suplanta a un portal bancario legítimo. Estas etiquetas no cumplen ninguna función práctica en campañas de correo electrónico ni en ataques orientados al posicionamiento en buscadores (SEO). Su único propósito es generar tarjetas enriquecidas de vista previa de enlaces, mostrando el nombre de una marca de confianza, una descripción y una miniatura del logotipo cuando una URL se comparte a través de aplicaciones de mensajería como WhatsApp, Telegram, iMessage o SMS con soporte RCS. Esta técnica está específicamente diseñada para hacer que la URL de phishing parezca completamente legítima antes de que la víctima siquiera haga clic en ella.

Método alternativo de exfiltración: bot de Telegram

Para una de las instituciones objetivo, la campaña utilizó un método de exfiltración distinto al mecanismo basado en SheetBest observado en otros casos. Después de que los usuarios ingresaban sus credenciales, los datos eran exfiltrados en tiempo real a un bot de Telegram mediante valores de token y chat ID codificados de forma estática e incrustados directamente en el código JavaScript de la página de phishing, una técnica comúnmente utilizada en los kits de phishing modernos para recopilar información robada sin necesidad de mantener una infraestructura de backend dedicada.

El análisis posterior del token y del chat ID identificados mostró que ya no se encontraban activos al momento del análisis, lo que sugiere que el canal de exfiltración había sido deshabilitado o abandonado. Sin embargo, múltiples dominios que suplantan la marca de la misma institución permanecen activos, lo que indica que la campaña continúa en operación.

Figure 6: Token y chat ID de un bot de Telegram codificados de forma estática en el código JavaScript de phishing.

Conclusión

Al alojar contenido de phishing en GitHub Pages, los actores de amenazas se benefician de la confianza implícita y de la cobertura HTTPS asociadas a estos dominios, lo que dificulta que tanto las víctimas como las herramientas automatizadas de seguridad identifiquen el contenido como malicioso. Al canalizar las credenciales robadas a través de SheetBest en lugar de mantener un servidor dedicado de comando y control, eliminan un punto crítico de exposición y operan íntegramente dentro de los límites de servicios legítimos en la nube. Este enfoque sin servidor reduce significativamente la huella de infraestructura y complica los esfuerzos de atribución.

Para el sector financiero, esta campaña ilustra un cambio más amplio en el panorama de amenazas: los atacantes ya no necesitan malware sofisticado ni infraestructuras complejas para llevar a cabo el robo de credenciales a gran escala. El abuso de plataformas en la nube de uso cotidiano reduce las barreras de entrada y, al mismo tiempo, incrementa la eficacia operativa. Las organizaciones que dependen exclusivamente de métodos tradicionales de detección de phishing —como las listas de bloqueo de dominios maliciosos conocidos— encontrarán cada vez más difícil defenderse de este tipo de infraestructura, lo que pone de relieve la necesidad de implementar mecanismos de detección basados en el comportamiento, monitoreo continuo de actividades de suplantación de marca e intercambio proactivo de inteligencia en todo el sector.

Recomendaciones

Para Instituciones Financieras:

• Monitorear GitHub Pages en busca de abusos de marca. Buscar de forma proactiva repositorios de GitHub Pages que suplanten a la institución mediante patrones de nomenclatura (por ejemplo, [marca]-soporte, [marca]-cancelacion) y rutas de phishing comunes identificadas en esta campaña. El mecanismo de reporte de abusos de GitHub puede utilizarse para solicitar la eliminación de repositorios de phishing confirmados.
• Supervisar el uso de APIs de terceros para la exfiltración de datos. Servicios como SheetBest son cada vez más utilizados para canalizar credenciales robadas sin necesidad de infraestructura de backend dedicada. Los sistemas de monitoreo de red deben alertar sobre solicitudes POST salientes inesperadas hacia api.sheetbest.com o servicios similares que utilizan hojas de cálculo como backend, originadas desde sesiones web de cara al usuario.
• Fortalecer el monitoreo del riesgo digital mediante servicios como la plataforma Digital Risk Protection de Group-IB, capaz de detectar y desmantelar infraestructuras de phishing que suplantan su marca en múltiples plataformas, incluidos servicios de alojamiento gratuitos.
• Capacitar a los clientes para identificar indicadores de phishing específicos de este tipo de campaña, como URL alojadas en dominios github.io, solicitudes no solicitadas relacionadas con cancelación de cuentas o soporte, y cualquier formulario web que solicite datos de tarjetas o contraseñas fuera de la aplicación o el sitio web oficial de la institución.
• Implementar mecanismos de detección basados en el comportamiento en lugar de depender exclusivamente de listas de bloqueo de dominios. Dado que esta campaña abusa de plataformas legítimas con reputación de confianza, la detección basada únicamente en firmas resulta insuficiente.
• Adoptar defensas en capas, como la autenticación multifactor y las alertas de transacciones en tiempo real, para proteger a los clientes incluso si sus credenciales se ven comprometidas.
• Compartir inteligencia de amenazas e indicadores de compromiso (IoC) con organizaciones del sector, CERTs y organismos reguladores para acelerar los esfuerzos de respuesta coordinada.

Para reguladores y responsables de políticas públicas:

• Fomentar la colaboración regional en América Latina para responder de manera más eficaz a campañas de phishing transfronterizas.
• Apoyar iniciativas de concientización que permitan a los ciudadanos identificar y evitar campañas de phishing.
• Trabajar con plataformas digitales para exigir responsabilidad a los anunciantes, garantizando que las campañas de phishing sean desmanteladas con rapidez.

Matriz de Fraude de Group-IB

Indicadores de Compromiso (IOCs)

Indicadores de Red

• soporte-index25.github[.]io
• soporte-index09.github[.]io
• sntdr-soporte25.github[.]io
• sntdr-soporte25.github[.]io
• 07-soporte.github[.]io
• soporte2507.github[.]io
• soporte160625.github[.]io
• soporte250324.github[.]io
• soporte74.github[.]io
• soporte-bm1.github[.]io
• soporte-r5.github[.]io
• api.sheetbest.com
• api.sheetbest.com
• soporte0625.github[.]io
• soporte160625.github[.]io
• soporte200525.github[.]io
• soporte2650.github[.]io
• soporte-index09.github[.]io
• soporte-bn1.github[.]io
• soporte-r5.github[.]io
• fldsmdfr-94.github[.]io
• soporte2507.github[.]io
• soporte74.github[.]io
• soporte-b2.github[.]io
• soporte-index25.github[.]io
• soporte-index.github[.]io
• soporte-index.github[.]io
• soporte-c1.github[.]io
• soporte-b4.github[.]io
• sntndr25-soporte.github[.]io
• sntndr-soporte0825.github[.]io
• 0825-soporte.github[.]io
• 07-soporte.github[.]io
• soporte-07-25.github[.]io
• soporte-0725.github[.]io
• soporte250324.github[.]io
• fldsmdfr-94.github[.]io
• soporteyatencionf.github[.]io
• sntndr25-soporte.github[.]io
• sntndr-soporte0825.github[.]io
• 0725soporte.github[.]io
• soporte-07-25.github[.]io
• soporte-0725.github[.]io
• 0825-soporte.github[.]io
• 0725-soporte.github[.]io
• soporter03.github[.]io
• soporteyatencionf.github[.]io
• soporte-y-atencion.github[.]io
• soporte-b1.github[.]io
• respaldo94.github[.]io
• respaldo94.github[.]io
• soporte-index05.github[.]io
• 0725-soporte.github[.]io
• 0725soporte.github[.]io
• soporte0725-3.github[.]io
• soporte0725-3.github[.]io
• soporte0725.github[.]io
• soporte0725.github[.]io
• soporte0625.github[.]io
• soporte200525.github[.]io
• soporte74.github[.]io
• soporte74.github[.]io
• soporte-r5.github[.]io
• support-vh.github[.]io

Descargo de responsabilidad: Toda la información técnica proporcionada en esta publicación, incluidos análisis de malware, indicadores de compromiso (IoC) y detalles de infraestructura, se comparte exclusivamente con fines de ciberseguridad defensiva e investigación. Group-IB no respalda ni autoriza ningún uso no autorizado u ofensivo de la información aquí contenida. Los datos y conclusiones presentados 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 las amenazas cibernéticas.

Group-IB declina expresamente toda responsabilidad por cualquier uso indebido de la información proporcionada. Se recomienda a las organizaciones y a los lectores utilizar 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 con el propósito de ilustrar casos en los que actores de amenazas han abusado o hecho un uso indebido de estas plataformas.

Este material se proporciona únicamente con fines informativos, ha sido elaborado por Group-IB como parte de una investigación analítica propia y refleja actividad de amenazas identificada recientemente.

Todas las marcas comerciales mencionadas en este documento son propiedad de sus respectivos titulares y se utilizan únicamente con fines informativos, sin que ello implique afiliación, patrocinio o respaldo alguno.