Apps falsas de ChatGPT y Claude: la campaña Yoba esconde un criptominero tras ejecutables firmados
Unos proyectos falsos en GitHub se presentan como aplicaciones de escritorio de ChatGPT y Claude y terminan instalando un criptominero. Las empresas de IA no han sido atacadas: el riesgo está en el lugar del que se descargan estas herramientas.


En esta página
Las apps falsas de ChatGPT y Claude que distribuye la campaña Yoba contienen algo que desconcierta a primera vista: un ejecutable auténtico, firmado digitalmente por OpenAI o por Anthropic. Y, aun así, el paquete completo es malware.
La firma no miente sobre ese archivo; simplemente no dice nada del resto de la carpeta. Por eso esta campaña obliga a desplazar la atención de los indicadores técnicos hacia una pregunta previa: de dónde sacan los empleados sus herramientas de IA y qué se les permite ejecutar.
Yoba se disfraza de aplicaciones de escritorio de ChatGPT y Claude
Check Point Research publicó el 27 de octubre su análisis de Yoba, según Infosecurity Magazine, una campaña que la firma lleva siguiendo desde hace unos dos meses y que aprovecha la popularidad de herramientas como ChatGPT y Claude [1][2]. Según ese informe, los atacantes crean proyectos falsos en GitHub que se presentan como aplicaciones de escritorio con nombres como «GPT-5.6 Sol», «GPT-6 Astra» o «Claude Opus» [1].
El montaje está cuidado. Check Point describe repositorios acompañados de páginas en GitHub Pages que explican las supuestas capacidades del programa y cuyos enlaces de descarga apuntan directamente a archivos ZIP publicados como versiones del propio repositorio [1]. Usar la infraestructura real de GitHub ayuda a que todo parezca legítimo.
Tampoco es una operación de un día. The Hacker News recoge que el primer repositorio se creó hacia julio de 2026, aunque las versiones maliciosas no se subieron hasta finales de agosto [6]. Infosecurity Magazine añade que una variante anterior, que se hacía pasar por el agente de programación Cursor, apareció a principios de junio [2], y Help Net Security precisa que aquella versión usaba el mismo canal de Telegram que la actual [3]. El cebo cambia según el producto que la gente busca en cada momento.
El desenlace de la cadena, en los casos observados, es un criptominero: según Check Point, en la información que recoge Infosecurity Magazine, la carga final fue XMRig [2].
El ejecutable es legítimo y está firmado; lo malicioso es lo que lo acompaña
El núcleo técnico de Yoba se entiende sin jerga. En esta campaña, el ejecutable firmado carga una biblioteca DLL desde su misma carpeta. Si alguien deja allí una DLL maliciosa con el nombre esperado, el programa legítimo la carga sin saberlo.
Cómo funciona el DLL sideloading en esta campaña
Según Check Point, el malware se coloca junto a ejecutables legítimos y firmados de OpenAI y Anthropic para que se cargue de forma indirecta, una técnica conocida como DLL sideloading que se usa a menudo para esquivar protecciones de seguridad [1]. En concreto, el paquete incluye un Setup.exe auténtico y un archivo winmm.dll malicioso; en la versión que imita a Claude, el ejecutable firmado es el de Claude [1]. CSO Online precisa que el objetivo son sistemas Windows [4].
Al abrir el instalador, la persona pone en marcha software real que, a su vez, ejecuta el código del atacante. A partir de ahí, según CSO Online, el componente malicioso pide privilegios de administrador antes de continuar [4], y Help Net Security describe una tarea programada que se hace pasar por una tarea de Windows Media Player atribuida a Microsoft [3].
Por qué una firma válida no demuestra que el paquete sea seguro
Notebookcheck lo resume con claridad: la firma cubre el instalador, no el archivo que tiene al lado [5]. En la misma línea, Yash Kadakia, de Security Brigade, explica en CSO Online que una firma digital válida acredita la autenticidad e integridad de un ejecutable concreto, pero no que todo lo que carga, ni el paquete con el que se distribuye, sea de confianza [4].
Check Point añade un detalle revelador: los ZIP no estaban protegidos con contraseña, algo habitual para dificultar el análisis automático, porque los binarios ya tenían tasas de detección muy bajas gracias a sus técnicas antisandbox y antianálisis [1]. Cuando el archivo firmado es auténtico y la parte maliciosa pasa desapercibida, la detección útil es la que observa qué hace el proceso, no solo quién lo firmó; es el terreno de la detección de amenazas con IA en un SOC.
El vector real es dónde buscan los empleados sus herramientas de IA
Conviene subrayarlo porque cambia el enfoque de la defensa. Eli Smadja, de Check Point, señala, según recoge Help Net Security, que la investigación no indica que ChatGPT, Claude, OpenAI o Anthropic hayan sido comprometidas, y que los atacantes abusan de binarios firmados legítimos y de la credibilidad de esas marcas [3].
Un buscador puede conducir a las páginas de descarga falsas. Check Point observa que los repositorios no mostraban señales de interacción falsa, como estrellas o forks inflados, que los promocionaran dentro del propio GitHub, y aun así aparecían entre los primeros resultados de Google [1]. La firma lo atribuye, muy probablemente, a SEO poisoning: optimizar títulos, descripciones y dominios para que un proyecto malicioso escale posiciones en buscadores externos [1]. Infosecurity Magazine apunta la misma explicación [2].
Eso traslada el problema al terreno de la gobernanza. Kadakia advierte en CSO Online que, si un empleado puede encontrar e instalar una herramienta útil en minutos pero la aprobación interna tarda semanas, el uso de TI no autorizada es el resultado previsible, y recomienda facilitar el acceso a herramientas aprobadas en lugar de recurrir a prohibiciones generales [4]. Decidir qué herramientas se aprueban, quién las evalúa y por qué canal se obtienen es parte de la gobernanza de la seguridad de la IA, no un asunto exclusivo del departamento de sistemas.
Servicios legítimos y dominios cambiantes dificultan el bloqueo
Ante una campaña así, el reflejo habitual es bloquear dominios e indicadores concretos. Son útiles, pero el propio informe explica por qué tienen recorrido corto: Check Point destaca la seguridad operativa del actor, que evita una infraestructura de mando y control dedicada y se apoya en Telegram, Tor, Catbox y DNS sobre HTTPS [1].
Help Net Security detalla el mecanismo: el cargador descarga la imagen de perfil de un canal de Telegram y la usa para generar un nombre de dominio, de modo que el operador puede cambiar de dominio con solo cambiar la imagen; por eso bloquear un servidor o un dominio concreto frena poco el mecanismo general [3]. Según Check Point, recogido por The Hacker News, apoyarse en DNS sobre HTTPS y en servicios de alojamiento de archivos comunes busca eludir la monitorización pasiva de DNS y algunas protecciones de pasarela, y mezclar el tráfico con la actividad normal de los usuarios [6].
Eso no hace a Yoba invisible. Kadakia enumera en CSO Online señales aprovechables: aplicaciones firmadas que cargan DLL inesperadas, tareas programadas que lanzan copias de binarios del sistema, ejecución desde ProgramData y conexiones de red inusuales; la dificultad está en correlacionarlas entre la telemetría del equipo y la de la red [4]. Hay además un matiz práctico: según CSO Online, el minero pausaba su actividad mientras el usuario estaba activo [4], así que esperar a que alguien note el equipo lento no es una estrategia. Cuando una organización no puede sostener esa correlación con medios propios, puede valorar si un servicio de monitorización y respuesta gestionada (SOCaaS/MDR) cubre esa necesidad.
Help Net Security recoge también la advertencia de Check Point de que, si se encuentra Yoba en un sistema, la infección debe tratarse como un compromiso más amplio y no limitarse a detectar o eliminar XMRig [3], porque el cargador puede entregar otros ejecutables o scripts de PowerShell [2].
Cuatro controles propuestos para dificultar la cadena
Check Point aconseja precaución al instalar aplicaciones de IA desde repositorios no verificados y restringir la ejecución de software de origen desconocido [2]. Notebookcheck lo concreta para el usuario: las aplicaciones genuinas solo vienen de sus desarrolladores, y un repositorio de GitHub con el nombre de un modelo en el título no es una fuente oficial, por alto que aparezca en los resultados [5].
Tabla de controles y qué paso de Yoba interrumpen
La tabla siguiente es una propuesta editorial a partir de esa lógica, no un hallazgo de las fuentes:
| Control | Qué paso de la cadena interrumpe | Quién lo aplica |
|---|---|---|
| Catálogo de herramientas de IA aprobadas y descarga solo desde el sitio oficial del fabricante | La llegada al repositorio falso desde un buscador | Responsable de gobernanza de IA junto con sistemas |
| Restricción de ejecución: listas de aplicaciones permitidas, sin instalaciones desde la carpeta de descargas y sin administrador local permanente | La ejecución del paquete y las fases que requieren privilegios elevados | Administración de sistemas |
| Alertas sobre procesos firmados que cargan DLL no esperadas, tareas programadas nuevas y consumo anómalo de CPU | La persistencia y la actividad del minero o de cargas posteriores | Equipo de seguridad o SOC |
| Formación sobre resultados manipulados en buscadores y nombres de producto dudosos | La decisión de descargar | Personas usuarias, con apoyo de seguridad |
El segundo control tiene base directa en las fuentes: Kadakia recomienda revisar los privilegios de administrador local permanentes y extender el control de aplicaciones más allá de la firma, hasta la carga de DLL y el comportamiento de ejecución [4].
Si alguien ya ha descargado uno de estos archivos, Notebookcheck aconseja borrarlo sin abrirlo; y si llegó a ejecutar el instalador, desconectar el equipo de la red, buscar una carpeta WMProcess dentro de ProgramData y lanzar un análisis completo [5].
Formación para que el hábito de descarga cambie
Los controles técnicos reducen el daño, pero la decisión inicial la toma una persona frente a un buscador. Una formación breve y concreta puede enseñar tres hábitos: llegar a la descarga desde la web del fabricante escribiendo la dirección, no fiarse de la posición en un resultado de búsqueda y desconfiar de nombres de producto que no figuran en el sitio oficial. El propio nombre de las apps falsas, como «GPT-6 Astra», es ya una señal para comprobar antes de instalar. Ese tipo de hábitos es el objetivo de un programa de formación y concienciación en seguridad.
La confianza en una IA se decide antes de descargarla, no después de firmarla
La investigación de Check Point no indica que ChatGPT, Claude, OpenAI o Anthropic hayan sido comprometidas. La campaña combina nombres de herramientas de IA, páginas bien posicionadas en Google y ejecutables legítimos firmados. Lo observado por Check Point en estos dos meses es un criptominero, pero, como recuerda Notebookcheck, el cargador es genérico y podría entregar ladrones de contraseñas o troyanos de acceso remoto [5].
La idea que conviene llevarse es sencilla: una firma válida no convierte en seguro un paquete descargado del sitio equivocado. Adoptar IA con seguridad empieza por saber de dónde viene cada herramienta y quién puede instalarla, y sigue por vigilar qué hace una vez en el equipo. Para las organizaciones que están dando ese paso, ordenar el catálogo y los canales desde la gobernanza de la seguridad de la IA es un buen punto de partida.
Fuentes
- Tricks from the Past deployed via signed ChatGPT and Claude binaries — Check Point Research, 2026-10-27
- Attackers Hide Malware Behind Signed ChatGPT and Claude Binaries — Infosecurity Magazine, 2026-10-28
- Yoba malware hides in fake desktop versions of ChatGPT and Claude — Help Net Security, 2026-10-29
- Fake ChatGPT, Claude apps spread malware via signed AI binaries — CSO Online, 2026-10-28
- Fake ChatGPT and Claude apps hide malware next to signed installers — Notebookcheck, 2026-10-29
- Fake ChatGPT and Claude Apps Abuse Signed Executables to Deploy Crypto Miners — The Hacker News, 2026-10-29
¿Te ha sido útil este artículo?

Gorka Gonzalo
Fundador y CEO
Fundó Hodeitek en 2023 y dirige la compañía, tras más de 8 años en pentesting, Red Team, auditoría OT/ICS y dirección de SOC. Experto en ciberseguridad e inteligencia artificial, marca la dirección técnica y de producto de HodeiShield y lidera personalmente los proyectos más críticos: de la estrategia de defensa a la aplicación de IA en la detección de amenazas. Es el interlocutor directo del cliente — quien define el alcance responde también por el resultado.