Pluto Security legt Details zu einer Load/Mine-Kryptomining-Kampagne auf Hugging Face offen

Das Forschungsteam von Pluto Security veröffentlichte am 29. Oktober 2026 seinen Load/Mine-Bericht, in dem eine Kryptomining- und Backdoor-Kampagne offengelegt wird, die über schädliche Modell-Repositories auf Hugging Face verbreitet wurde. Dem Bericht zufolge umfasst die Kampagne 31 schädliche Repositories auf sieben Hugging-Face-Konten sowie einen Spiegel auf ModelScope. Für die Kampagne wurden 29.818 Downloads verzeichnet, beziehungsweise 32.376, wenn 13 verknüpfte Repositories mitgezählt werden. Pluto erklärt, dass diese Zahl Downloads erfasst und nicht bestätigte Infektionen oder einzelne Opfer.

Der von Shaked Chen, Eitan Chassid und Yotam Perkal verfasste Bericht besagt, dass die Kampagne wenige Tage nach einer ersten Entfernung zurückkehrte: 19 Repositories der zweiten Welle verzeichneten mehr als 29.000 Downloads und waren acht Tage nach der Meldung durch Pluto noch online. Das Auszahlungs-Wallet der ersten Welle erhielt laut Bericht rund 2.276 PRL – etwa 5.000 US-Dollar – aus On-Chain-Mining-Erträgen.

So wird der schädliche Code ausgeführt

Die Kampagne nutzt ein dokumentiertes Ladeverhalten von Transformers statt manipulierte Gewichte. Wird ein Repository mit trust_remote_code=True wird der Python-Code des Repositorys mit den Berechtigungen des aufrufenden Prozesses importiert, bevor irgendwelche Gewichte geladen werden. Das Repository config.json verwendet auto_map um das zu ladende Python-Modul und die Klasse anzugeben; Transformers lädt die referenzierte Datei in seinen Modul-Cache herunter, und der exec_module() Aufruf führt den Top-Level-Code der Datei aus, bevor die angeforderte Modellklasse zurückgegeben wird. Der Bericht weist darauf hin, dass es sich dabei um dokumentiertes Verhalten und nicht um eine Standardeinstellung handelt. Außerdem fordere die Sicherheitsrichtlinie von Transformers Nutzer dazu auf, bei Verwendung des Arguments den Inhalt von Modelldateien zu überprüfen. Der Bericht verweist auch auf CVE-2026-22807, bei dem vLLM-Versionen ab 0.10.1 bis zur Fehlerbehebung in Version 0.14.0 auto_map Module luden, ohne die trust_remote_code Einstellung zu prüfen, sodass ein schädliches Repository beim Serverstart Code ausführen konnte.

Entdeckung und Verknüpfung der Konten

Pluto entwickelte einen Scanner, der jede .py von auto_map in einem config.jsonreferenzierte Datei sowie Python-Dateien neben Modellgewichten erfasste und nach Mustern wie subprocess, socket, ctypes, memfd_create und Base64-Decodierung suchte. Der erste Treffer war dsxk4mr8tq/qwen2-tiny-gpt2, mit einer 305 Zeilen langen Datei namens modeling_evil.py; das Konto hatte sechs Repositories, die innerhalb von 2,5 Stunden am 12. Oktober 2026 erstellt worden waren.

Die Verbindung ließ sich anhand von Sicherungsdateien herstellen. Das qwen2-tiny-lite Repository enthielt modeling_evil.py.bak-src und modeling_evil.py.bak-sync, ältere Versionen derselben Malware, deren Download-URLs nicht auf das Wegwerf-Konto, sondern auf hhzz667 auf Hugging Face und wssb123e auf ModelScope verwiesen. Dem Bericht zufolge kopierte der Betreiber Produktionscode in ein Testkonto, aktualisierte die URLs in der Hauptdatei und vergaß die Sicherungskopien. Die erste Welle umfasste insgesamt 12 Repositories auf drei Konten und zwei Plattformen. Vor ihrer Entfernung wurden mehr als 700 Downloads verzeichnet; Sicherheitswarnungen gab es keine.

Aufbau der Payload

Nimmt man MENXIANGYU/qwen2-tiny als repräsentativen Build, beschreibt der Bericht eine Payload, die zunächst /tmp/.cch/svc.py, einen Watchdog, der einen ausgefallenen Miner alle 120 Sekunden neu startet, wobei Start-Hooks an /root/.bashrc, /root/.profile und der .bashrcdes Nutzers angehängt werden. Drei Builds ergänzen eine Reverse Shell, die sich über Port 443 oder 9443 mit 212.32.253.3 verbindet und nach jeder Unterbrechung erneut Verbindungsversuche unternimmt.

Die Miner-Binärdatei syscore.binwird über memfd_create und fexecve getarnt als Kernel-Worker kworker/u20:1, gestartet. Beim ersten Start bleibt dadurch kein ausführbarer Pfad auf der Festplatte zurück; eine Sicherungskopie verbleibt in /tmp/.cch/sync. Die 40,6-MB-Binärdatei ist mit UPX gepackt; zwei UPX! Marker wurden in PEK! geändert, sodass das Standard-Entpackungsprogramm sie zurückweist. Pluto stellte die Marker wieder her und entpackte einen Miner namens peakminer, der mit Pool-Endpunkten und dem Login krxXJ2PKQW.workergestartet wird. Fortschrittsmeldungen werden in der lokalen Xinference-Modellregistrierung als qwen2-tiny- gespeichert, gefolgt von Base32-Statuscodes. Die Payload entfernt Registrierungen konkurrierender Miner und beendet passende Prozesse.

Zwei Wellen und Anpassungen nach der Entfernung

Laut Bericht ging die erste Welle auf das Konto hhzz667zurück, das am 29. April 2026 erstellt worden war und fünf Monate lang inaktiv blieb. Am 21. September 2026 veröffentlichte es qwen2-shell, eine 37 Zeilen lange SSH-Backdoor, die einen ed25519-Schlüssel in authorized_keys platzierte und eine Verbindung zu einem Alibaba-Cloud-Server herstellte. Die README-Datei war von der offiziellen Modellkarte für Qwen2.5-0.5B kopiert. Am 22. September veröffentlichte der Betreiber qwen2-final, einen 305 Zeilen langen dateilosen Miner mit Tarnung als Kernel-Thread, einem Tool zum Beenden konkurrierender Miner und einer Statusmeldung an Xinference unter unauffälligen Namen wie Qwen2Config. Die Codekommentare waren auf vereinfachtem Chinesisch verfasst.

Pluto meldete die erste Welle an Hugging Face und ModelScope; die Konten wurden entfernt. Die zweite Welle folgte innerhalb weniger Tage: 19 Repositories über fünf Konten hinweg, darunter MENXIANGYU mit 13 Repositories sowie wjsbg, soumikmahato, r1r13 und htt0118; letzteres wurde am 25. Oktober 2026 erstellt. Ein Repository, MENXIANGYU/qa-whl-1021, das 8,5 Stunden nach Plutos Offenlegungs-E-Mail veröffentlicht wurde, ist ein Skript zum Ausbruch vom Container auf den Host, das Festplatten des Hosts einbindet und auf /var/lib/gpustack das Verzeichnis von GPUStack abzielt und eine Root-Anmeldung auf dem Host ermöglicht. Ein späterer Dropper beschränkt seine zweite Stufe anhand der Quell-IP-Adresse und antwortet anderen Anfragenden mit dem Statuscode 403 und dem Text „static ip.“. Das führende Repository MENXIANGYU/qwen2-tiny stieg von 7.354 Downloads am 20. Oktober auf 28.412 am 28. Oktober und machte damit 97,7 % der Downloads der zweiten Welle aus.

Mining-Erlöse und beobachtete Opfer

Das Wallet der ersten Welle erhielt rund 2.276 PRL in 716 Transaktionen und leitete rund 2.241 PRL weiter; am 21. Oktober war es noch auf öffentlichen Pool-Dashboards aktiv, nachdem seine Repositories entfernt worden waren. Auf Kryptex zeigte das Wallet zwei aktive Worker, die peakminer/2.16.5 bei den 30-Tage-Belohnungen zum Zeitpunkt der Erfassung rund 1.008 PRL beziehungsweise etwa 2.237 US-Dollar meldeten. Während der Analyse traten neun Worker mit notebookartigen Namen innerhalb von 90 Sekunden nacheinander in Erscheinung und stellten etwa sechs Minuten später die Übermittlung von Shares ein – ein Muster, das der Bericht als mit einem gemeinsam genutzten GPU-Cluster vereinbar beschreibt. Eine separat erfasste hl Familie, die eine ähnliche Ausführung zum Importzeitpunkt nutzte, wies ein MoneroOcean-Wallet mit 13 Workern und Auszahlungen von rund 26 US-Dollar innerhalb etwa eines Monats auf.

Lücken bei der Scanner-Abdeckung

Keines der 12 Repositories der ersten Welle wurde markiert, und die Nutzlast des führenden Repositories der zweiten Welle modeling_evil2.py wurde laut Plutos Überprüfungen von jedem ausgeführten Scanner als „sicher“ eingestuft; JFrog meldete, es handle sich nicht um ein Modell für maschinelles Lernen. In der Dokumentation zum Scannen auf Schadsoftware von Hugging Face heißt es, dass bei jedem Commit jede Repository-Datei mit weniger als 2 GB von einem Schadsoftware-Scanner geprüft wird. Laut der Dokumentation zum Scannen von Pickle-Dateien führt der Scanner ClamAV-Antivirenprüfungen und Pickle-Importprüfungen durch; ClamAV deckt Pickle-Exploits jedoch nicht ab, und die Prüfung sei „nicht hundertprozentig zuverlässig“. Die Verantwortung dafür, die Sicherheit zu überprüfen, liege beim Nutzer. Pluto zufolge hätte eine Überprüfung der .py Dateien, auf die ein auto_map vor dem Setzen der Markierung verweist, jede Nutzlast der Kampagne aufgedeckt; eine statische Prüfung beim Hochladen auf subprocess, socket, ctypes oder Aufrufe an rohe IP-Adressen in auto_map-referenzierten Dateien hätte sie früher erkannt.

Einschätzung der Urheberschaft und empfohlene Maßnahmen

Pluto geht von einem finanziell motivierten, chinesischsprachigen Betreiber oder einer kleinen Gruppe aus. Als Hinweise nennt das Unternehmen Kommentare in vereinfachtem Chinesisch, einen Command-and-Control-Server bei Alibaba Cloud, Spiegelungen auf ModelScope und hf-mirror.com, eine Zielauswahl, die Xinference und Tencent Cloud voraussetzt, sowie eine Häufung der Aktivitäten zwischen 18:38 und 21:19 UTC. Der „parasit“-Build von soumikmahato enthält Kommentare auf Indonesisch. Dem Bericht zufolge passt dies entweder zu einem zweiten Betreiber in derselben Nische oder zu einem Betreiber, der bewusst eine anders wirkende Variante einsetzt.

Der Bericht rät allen, die ein aufgeführtes Modell mit aktiviertem benutzerdefiniertem Code geladen haben, die Hosts auf /tmp/.cch/, unerwartete svc.py Prozesse, einen kworker/u20:1 Prozess mit Mining-Argumenten, kodierte qwen2-tiny- oder ezv- Xinference-Registrierungen sowie Verbindungen zu den aufgeführten Servern und Pools zu überprüfen. Pluto empfiehlt, betroffene Rechner vom Netz zu nehmen, Beweise zu sichern, sämtliche Persistenzmechanismen zu entfernen, offengelegte Zugangsdaten von einem sauberen Rechner aus zu ändern, Systeme aus einem vertrauenswürdigen Image neu aufzusetzen, wenn sich die Integrität des Hosts nicht feststellen lässt, die Xinference-API durch Authentifizierung zu schützen und geprüfte Modellversionen festzuschreiben. Pluto rechnet nach eigenen Angaben mit weiteren Kampagnen dieser Art und verfolgt sie.