Uno busca «ChatGPT para escritorio» en Google, encuentra un repositorio de GitHub con ese nombre, descarga el ZIP y ejecuta el instalador. El instalador tiene firma digital de OpenAI. Y el paquete, sin embargo, instala un minero de criptomonedas. Esa secuencia es la que describe la investigación que Check Point ha publicado sobre Yoba, una campaña que se apoya en tres cosas que la gente ya considera normales: GitHub, la búsqueda de Google y una firma válida.
Lo importante del hallazgo no es el minero. Los investigadores lo dicen con claridad: el payload final observado fue un minero de Monero en su versión 6.26.0, pero YobaLoader es un cargador genérico capaz de entregar otros ejecutables de Windows o scripts de PowerShell. El interés está en la cadena de infección, que convierte la búsqueda de herramientas de IA en el vector de entrada.
Tampoco hay brecha en OpenAI ni en Anthropic. Ninguna de las dos compañías ha sido comprometida, y el binario legítimo que se ejecuta es auténtico. Lo que falla es la confianza que el usuario deposita en un paquete entero por el hecho de que una de sus piezas esté firmada. Ese matiz separa un incidente de terceros de una brecha del proveedor, y explica por qué la campaña funciona sin tocar ningún servidor ajeno.
Repositorios con nombres que suenan a producto real
Los atacantes crearon repositorios y páginas de GitHub Pages que anunciaban supuestas versiones de escritorio de productos de IA, con nombres como «GPT-5.6 Sol», «GPT-6 Astra» y «Claude Opus». Los enlaces de descarga apuntaban a archivos ZIP alojados como releases dentro de GitHub.
Los repositorios no mostraban estrellas ni bifurcaciones infladas, el truco clásico para parecer popular. Aun así, aparecían de forma destacada en Google, y Check Point evalúa el patrón como envenenamiento de resultados de búsqueda: contenido construido para aparecer ante quien busca activamente software de IA.
Esa táctica traslada el ataque al momento de la decisión. El usuario ya quiere instalar algo, ya está buscando nombre y enlace, y el atacante solo tiene que estar en el lugar correcto. No hay que convencer a nadie de que abra un archivo raro; basta con ofrecer el archivo que estaba buscando.
La firma válida y la DLL que no lo es
El paquete mezcla componentes maliciosos con software legítimo. En los ZIP que imitaban a ChatGPT se incluye un `Setup.exe` auténtico y firmado por OpenAI; en los que imitaban a Claude, un ejecutable firmado de Claude. Al lanzarse, esos binarios cargan una `winmm.dll` maliciosa colocada al lado mediante la técnica de carga lateral de librerías.
El resultado es una cadena con dos verdades incómodas. La primera: la firma dice la verdad sobre el ejecutable y nada sobre lo que lo rodea. La segunda: la técnica de carga lateral sigue funcionando en 2026 con la misma eficacia que hace una década, porque el sistema operativo sigue confiando en la carpeta del programa.
Ese patrón coincide con otros incidentes recientes. El CVE de Siemens Software Center explotado con ClickFix usaba la misma idea: binario legítimo, librería ajena y ejecución con la confianza del primero. Cambia el fabricante y el sector, no la lógica.
Un cargador que se esconde de los analistas
YobaDropper, la primera etapa, incorpora varias comprobaciones antes de hacer nada. Verifica que lo haya lanzado el `Setup.exe` esperado, introduce una espera larga si la comprobación falla, aplica controles de idioma regional y exige privilegios de administrador para continuar.
Esas condiciones están pensadas para complicar el análisis automático. Un sistema que ejecuta muestras a toda velocidad no tendrá el entorno esperado y el malware se quedará quieto, lo que retrasa la detección y hace que muchas muestras parezcan inofensivas.
Cuando las comprobaciones pasan, el dropper despliega YobaLoader junto a un ejecutable legítimo de Windows y crea una tarea programada para que ese ejecutable cargue la librería maliciosa después del arranque. La persistencia no depende de un servicio propio ni de una entrada de registro llamativa, sino de un proceso conocido que arranca solo.
Telegram, DNS y Catbox como infraestructura
La parte más original del análisis es la comunicación. YobaLoader no se conecta a un servidor de mando y control dedicado. En su lugar, consulta un canal de Telegram y descarga la imagen de perfil. Los datos de esa imagen se usan para generar un dominio, de modo que el atacante cambia el dominio cambiando la foto del canal.
Después consulta el servicio DNS sobre HTTPS de Google para un registro TXT de ese dominio. Valida y descifra la respuesta y, con ella, recupera un payload cifrado de un alojamiento externo como Catbox.
Cada pieza es un servicio legítimo. Bloquear Telegram, el DNS de Google o un servicio de alojamiento de archivos tiene un coste operativo enorme para cualquier empresa, y los atacantes lo saben. Al mezclar servicios de uso común con dominios generados dinámicamente, la infraestructura maliciosa se vuelve difícil de distinguir del tráfico normal.
| Etapa |
Qué hace |
Servicio usado |
| Descubrimiento |
Repos con supuestas apps de IA y enlaces a ZIP |
GitHub y GitHub Pages |
| Entrega |
Binario firmado legítimo más `winmm.dll` maliciosa |
OpenAI, Anthropic (sin brecha) |
| Persistencia |
Tarea programada que carga la DLL junto a un ejecutable del sistema |
Windows |
| Dirección |
Imagen de perfil para generar el dominio |
Telegram |
| Resolución |
Registro TXT del dominio generado |
DNS sobre HTTPS de Google |
| Payload |
Descarga cifrada del siguiente módulo |
Catbox |
El minero y lo que viene después
En la campaña analizada, el payload final fue un minero de Monero 6.26.0 que puede comunicarse a través de Tor y que pausa la minería cuando detecta que el usuario está trabajando, para no delatar su presencia con el consumo.
Ese comportamiento dice mucho del objetivo: monetización silenciosa. Un minero que ralentiza el equipo se descubre en un día; uno que se aparta cuando hay actividad puede pasar meses sin ser notado.
Los investigadores insisten en no quedarse en esa etiqueta. YobaLoader puede entregar otros ejecutables o scripts, así que tratar el incidente como un caso de minero es un error de alcance. Una máquina infectada tiene un cargador con persistencia y conectividad, y lo que haya traído es la pieza menos importante.
¿Qué hacer en una organización?
La primera medida es de proceso: instalar software de IA solo desde los canales del proveedor. Un binario firmado dentro de un paquete descargado de un repositorio de terceros no acredita nada sobre el resto del paquete.
La segunda es de permisos. Si un empleado necesita privilegios de administrador para instalar su herramienta favorita, el problema no es la herramienta, es el modelo de concesión. Limitar esos permisos reduce la superficie donde un dropper puede trabajar.
La tercera es de detección. Buscar solo el archivo malicioso no sirve aquí, porque la cadena pasa por procesos legítimos. Lo que hay que vigilar es qué carga un ejecutable firmado y qué tareas programadas se crean después de una instalación.
Y la cuarta es de inventario. Saber qué aplicaciones de IA corren en los equipos, y de dónde salieron, es hoy parte de la seguridad y no del gusto por el orden. Si la organización no puede responder a esa pregunta, la campaña de Yoba encontrará hueco sin necesidad de explotar ninguna vulnerabilidad.
