Pluto Security detalla una campaña de criptominería Load/Mine en Hugging Face

El equipo de investigación de Pluto Security publicó el 29 de octubre de 2026 su informe Load/Mine, en el que revela una campaña de criptominería y puerta trasera distribuida a través de repositorios maliciosos de modelos en Hugging Face. El informe contabiliza 31 repositorios maliciosos repartidos entre siete cuentas de Hugging Face, además de un espejo en ModelScope, con 29.818 descargas registradas de la campaña y 32.376 al incluir 13 repositorios vinculados. Pluto señala que la cifra corresponde a descargas, no a infecciones confirmadas ni a víctimas únicas.

El informe, cuyos autores son Shaked Chen, Eitan Chassid y Yotam Perkal, afirma que la campaña reapareció pocos días después de una primera retirada: 19 repositorios de la segunda oleada registraron más de 29.000 descargas y seguían activos ocho días después de que Pluto los denunciara. Según el informe, la billetera de cobro de la primera oleada recibió unos 2.276 PRL —aproximadamente 5.000 dólares— en ingresos de minería en cadena.

Cómo se ejecuta el código malicioso

La campaña se basa en un comportamiento documentado de carga de Transformers, no en pesos manipulados. Cargar un repositorio con trust_remote_code=True importa el código Python del repositorio con los privilegios de quien realiza la llamada antes de que se carguen los pesos. El config.json utiliza auto_map para indicar el módulo y la clase de Python que se deben cargar; Transformers descarga el archivo correspondiente en su caché de módulos, y la exec_module() llamada ejecuta el código de nivel superior del archivo antes de devolver la clase de modelo solicitada. El informe señala que se trata de un comportamiento documentado, no predeterminado, y que la política de seguridad de Transformers indica a los usuarios que verifiquen el contenido de los archivos de modelado cuando utilizan el argumento. El informe también cita CVE-2026-22807, en el que las versiones de vLLM desde la 0.10.1 hasta la corrección en la 0.14.0 cargaban auto_map módulos sin comprobar la trust_remote_code configuración, lo que permitía que un repositorio malicioso ejecutara código al iniciar el servidor.

Descubrimiento y vinculación de cuentas

Pluto creó un escáner que abarcaba cada .py archivo al que hacía referencia auto_map en un config.json, además de archivos Python ubicados junto a los pesos del modelo, y detectaba patrones como subprocess, socket, ctypes, memfd_create y la decodificación en base64. El primer hallazgo fue dsxk4mr8tq/qwen2-tiny-gpt2, que incluía un archivo de 305 líneas llamado modeling_evil.py; la cuenta tenía seis repositorios creados en un lapso de 2,5 horas el 12 de octubre de 2026.

La pista que permitió atribuir la campaña se encontró en los archivos de respaldo. El qwen2-tiny-lite repositorio contenía modeling_evil.py.bak-src y modeling_evil.py.bak-sync, versiones anteriores del mismo malware cuyas URL de descarga no apuntaban a la cuenta desechable, sino a hhzz667 en Hugging Face y wssb123e en ModelScope. El informe afirma que el operador copió código de producción en una cuenta de prueba, actualizó las URL del archivo principal y olvidó las copias de respaldo. La primera oleada sumó 12 repositorios en tres cuentas y dos plataformas; antes de su retirada se registraron más de 700 descargas y ninguna alerta de seguridad.

Anatomía de la carga útil

Tomando MENXIANGYU/qwen2-tiny como una versión representativa, el informe describe una carga útil que primero escribe /tmp/.cch/svc.py, un proceso de supervisión que reinicia el minero si no está activo cada 120 segundos, con mecanismos de inicio añadidos a /root/.bashrc, /root/.profile y al del usuario .bashrc. Tres versiones incorporan una puerta trasera de shell inversa que se conecta a 212.32.253.3 por los puertos 443 o 9443 y vuelve a intentarlo después de cada desconexión.

El binario del minero, syscore.binse ejecuta mediante memfd_create y fexecve disfrazado de trabajador del kernel kworker/u20:1, por lo que no deja ninguna ruta de ejecutable en el disco durante el primer lanzamiento; una copia de respaldo permanece en /tmp/.cch/syncEl binario de 40,6 MB está empaquetado con UPX y tiene dos UPX! marcadores modificados a PEK! por lo que la herramienta estándar de desempaquetado lo rechaza; Pluto restauró los marcadores y desempaquetó un minero llamado peakminer, ejecutado con las direcciones de los servidores del pool y el inicio de sesión krxXJ2PKQW.worker. Los comprobantes de progreso se escriben en el registro local de modelos de Xinference como qwen2-tiny- seguidos de códigos de estado en base32; la carga útil también elimina los registros de mineros rivales y termina los procesos correspondientes.

Dos oleadas y adaptación tras la retirada

El informe atribuye la primera oleada a la cuenta hhzz667, creada el 29 de abril de 2026 y sin actividad durante cinco meses. El 21 de septiembre de 2026 publicó qwen2-shell, una puerta trasera SSH de 37 líneas que instalaba una clave ed25519 en authorized_keys con una señal de aviso a un servidor de Alibaba Cloud; el archivo README se copió de la ficha oficial del modelo Qwen2.5-0.5B. Para el 22 de septiembre, el operador había distribuido qwen2-final, un minero sin archivos de 305 líneas que se disfrazaba de proceso del kernel, eliminaba a los mineros competidores y notificaba el estado a Xinference con nombres aparentemente inocuos como Qwen2Config. Los comentarios del código estaban en chino simplificado.

Pluto informó de la primera oleada a Hugging Face y ModelScope, y las cuentas fueron eliminadas. La segunda oleada llegó en cuestión de días: 19 repositorios repartidos entre cinco cuentas, incluida MENXIANGYU, con 13 repositorios, además de wjsbg, soumikmahato, r1r13 y htt0118, esta última creada el 25 de octubre de 2026. Un repositorio, MENXIANGYU/qa-whl-1021, publicado 8,5 horas después del correo electrónico de divulgación de Pluto, es un script para escapar del contenedor al host que monta discos del host y apunta al /var/lib/gpustack directorio de GPUStack, y permite iniciar sesión como root en el host. Un dropper posterior restringe su segunda etapa por IP de origen y devuelve a los demás solicitantes una respuesta 403 con el texto «static ip.». El repositorio insignia MENXIANGYU/qwen2-tiny pasó de 7.354 descargas el 20 de octubre a 28.412 el 28 de octubre, lo que representó el 97,7 % de las descargas de la segunda oleada.

Ingresos de la minería y víctimas observadas

La cartera de la primera oleada recibió unos 2.276 PRL en 716 transacciones y transfirió unos 2.241 PRL, y seguía activa en los paneles públicos de los pools el 21 de octubre, después de que se eliminaran sus repositorios. En Kryptex, la cartera mostraba dos trabajadores en línea que informaban peakminer/2.16.5 de unos 1.008 PRL, aproximadamente 2.237 dólares en recompensas durante 30 días al momento de la captura. Durante el análisis, nueve trabajadores con nombres similares a los de cuadernos se conectaron con una diferencia de 90 segundos entre sí y dejaron de enviar participaciones unos seis minutos después; el informe describe este patrón como compatible con un clúster de GPU compartido. Una hl familia rastreada por separado, que usaba una ejecución similar durante la importación, mostraba una cartera de MoneroOcean con 13 trabajadores y unos 26 dólares pagados en aproximadamente un mes.

Lagunas en la cobertura de los analizadores

Ninguno de los 12 repositorios de la primera oleada fue señalado, y la carga útil insignia de la segunda oleada modeling_evil2.py obtuvo el resultado «seguro» en todos los analizadores que se ejecutaron; según las comprobaciones de Pluto, JFrog indicó que no se trataba de un modelo de aprendizaje automático. La documentación de Hugging Face sobre el análisis de malware afirma que cada archivo de un repositorio que pese menos de 2 GB se analiza en busca de malware con cada confirmación. La documentación sobre el análisis de archivos pickle indica que el analizador ejecuta análisis antivirus de ClamAV y análisis de importación de pickle, que ClamAV no cubre las vulnerabilidades de pickle y que el análisis «no es infalible al 100 %»; la responsabilidad de comprobar que los archivos sean seguros recae en el usuario. Pluto afirma que revisar los .py archivos que un auto_map señala antes de que se active la alerta habría detectado todas las cargas útiles de la campaña, y que una comprobación estática en el momento de la carga para subprocess, socket, ctypes o llamadas a IP sin procesar en auto_maparchivos referenciados mediante – las habría detectado antes.

Evaluación de atribución y medidas recomendadas

Pluto considera que la operación fue obra de un operador o un grupo pequeño de habla china motivado por razones económicas. Como indicios, cita comentarios en chino simplificado, un servidor de mando y control de Alibaba Cloud, la replicación en ModelScope y hf-mirror.com, una selección de objetivos que presupone el uso de Xinference y Tencent Cloud, y una concentración de actividad entre las 18:38 y las 21:19 UTC. La compilación «parasit» de soumikmahato incluye comentarios en indonesio, algo que, según el informe, encaja tanto con la posibilidad de que se trate de un segundo operador del mismo nicho como con la de que un solo operador esté ejecutando una línea deliberadamente distinta en apariencia.

El informe aconseja a quienes hayan cargado un modelo incluido en la lista con el código personalizado habilitado que busquen en los hosts /tmp/.cch/, inesperados svc.py procesos, un kworker/u20:1 proceso que lleve argumentos de minería, archivos codificados qwen2-tiny- o ezv- registros de Xinference y conexiones con los servidores y pools indicados. Pluto recomienda aislar las máquinas afectadas, conservar las pruebas, eliminar todas las vías de persistencia, cambiar las credenciales expuestas desde una máquina limpia, reconstruir los sistemas a partir de una imagen de confianza cuando no se pueda garantizar la integridad del host, exigir autenticación en la API de Xinference y fijar las revisiones de los modelos que se hayan revisado. Pluto afirma que espera más campañas de este tipo y que las está siguiendo.