Hugging Face: jak działało zgłoszone malware kopiące kryptowaluty

W analizie opublikowanej 29 października 2026 r. Pluto Security opisało dwie fale złośliwych repozytoriów modeli na Hugging Face: łącznie 31 głównych repozytoriów powiązanych z siedmioma kontami. Kod Pythona uruchamiał się podczas ładowania modelu, a nie dopiero w trakcie korzystania z niego. Pluto podało, że do 28 października repozytoria i powiązane modele zanotowały 32 376 pobrań. Analiza Pluto Security

Dwie fale repozytoriów i kopia opisana 25 października

Pluto Security podało, że pierwsza fala obejmowała 12 repozytoriów, a druga 19. Po usunięciu kont związanych z pierwszą falą w ciągu kilku dni pojawiły się repozytoria drugiej. 25 października zamieszczono niemal identyczną kopię repozytorium qwen2-tiny pod nazwą htt0118/qwen2-tiny. 29 października BleepingComputer poinformował, że w swojej analizie tej kopii znalazł ten sam miner i reverse shell, czyli mechanizm umożliwiający zdalny dostęp do systemu.

Co oznaczało 32 376 pobrań

Zestawienie Pluto Security obejmowało 31 głównych repozytoriów kampanii oraz 13 modeli powiązanych. Pobrania pierwszej fali zliczono przed usunięciem repozytoriów; liczby dla drugiej fali i modeli powiązanych odnoszą się do 28 października 2026 r.

Suma to 32 główne repozytoria i modele powiązane, 44 repozytoria łącznie, oraz 32 376 pobrań. Liczba pobrań nie mówi, ilu było unikalnych użytkowników ani ile urządzeń zostało zainfekowanych.

Jak kod uruchamiał się podczas ładowania modelu

Opcja trust_remote_code=True pozwalała loaderowi zaimportować moduł Pythona wskazany przez konfigurację repozytorium. Kod wykonywał się podczas importowania modułu, przed zwróceniem klasy modelu. Działał z uprawnieniami procesu ładującego, więc znaczenie miało również to, jakie uprawnienia przyznano temu procesowi.

W analizowanym przez Pluto repozytorium MENXIANGYU/qwen2-tiny plik model.safetensors miał 42 bajty i nie zawierał tensorów. Złośliwy kod znajdował się w module Pythona modeling_evil2.py. Oznacza to, że w tym przypadku zagrożenie wiązało się z uruchamianiem kodu repozytorium podczas ładowania, a nie z samymi wagami modelu.

Ślady trwałości i zachowania konkretnych wariantów

W opisanym wariancie miner syscore.bin był uruchamiany z pamięci i ukrywał się pod nazwą procesu [kworker/u20:1]. Pluto wskazało również na skrypt obserwujący proces w /tmp/.cch/svc.py, zmiany w skryptach startowych powłoki oraz mechanizm ponownego uruchamiania minera co 120 sekund.

Niektóre warianty zawierały dodatkowe funkcje. Według Pluto repozytoria qwen2-tiny-5, qwen2-tiny-6 i qwen2-tiny-9 nawiązywały ponownie połączenie reverse shell z adresem 212.32.253.3 na porcie 443 lub 9443. Osobno Pluto opisało MENXIANGYU/qa-whl-1021: skrypt, który z uprzywilejowanego kontenera mógł montować dyski hosta i uzyskać uprawnienia roota na tym hoście.

Wśród wskaźników do sprawdzenia Pluto wymieniło ścieżkę /tmp/.cch/, nieoczekiwane działanie svc.py, zmiany w skryptach startowych powłoki, proces [kworker/u20:1] z argumentami minera, zakodowane wpisy modeli qwen2-tiny- lub ezv- w Xinference oraz połączenia z infrastrukturą kampanii. Brak pojedynczego wskaźnika nie wyklucza przejęcia systemu.

Co zrobić po załadowaniu podejrzanego modelu

Pluto zaleciło sprawdzić host także wtedy, gdy ładowanie modelu się nie powiodło albo użycie GPU wyglądało normalnie. Kolejność działań ma znaczenie:

1. Odizoluj hosta i zachowaj ślady dotyczące procesów, połączeń sieciowych, logów, pamięci podręcznej oraz skryptów uruchamianych przy starcie.
2. Sprawdź inne systemy, na których ładowano te same repozytoria, i poszukaj wymienionych wskaźników.
3. Usuń minera, mechanizmy trwałości i backdoory. Samo zatrzymanie procesu kopiącego kryptowalutę nie usuwa pozostałych sposobów dostępu.
4. Zmień dane uwierzytelniające, do których proces mógł mieć dostęp, korzystając z czystego systemu.
5. Odbuduj system z zaufanego obrazu, jeśli nie da się potwierdzić jego integralności.