Pluto Security ujawnia szczegóły kampanii kryptominingowej Load/Mine na Hugging Face

Zespół badawczy Pluto Security opublikował 29 października 2026 r. raport Load/Mine, ujawniając kampanię wydobywania kryptowalut i instalowania backdoora, rozpowszechnianą za pośrednictwem złośliwych repozytoriów modeli Hugging Face. Raport odnotowuje 31 złośliwych repozytoriów na siedmiu kontach Hugging Face oraz kopię lustrzaną w ModelScope, 29 818 zarejestrowanych pobrań kampanii, a po uwzględnieniu 13 powiązanych repozytoriów — 32 376. Pluto zaznacza, że liczba ta oznacza pobrania, a nie potwierdzone infekcje ani unikalne ofiary.

Raport, którego autorami są Shaked Chen, Eitan Chassid i Yotam Perkal, wskazuje, że kampania powróciła w ciągu kilku dni od pierwszego usunięcia: repozytoria drugiej fali odnotowały ponad 29 000 pobrań, a osiem dni po zgłoszeniu ich przez Pluto nadal były dostępne. Według raportu portfel, na który trafiały środki z pierwszej fali, otrzymał około 2 276 PRL, czyli około 5 000 $, z wydobywania kryptowalut w łańcuchu bloków.

Jak działa złośliwy kod

Kampania wykorzystuje udokumentowany sposób ładowania w Transformers, a nie zatrute wagi. Załadowanie repozytorium z trust_remote_code=True importuje kod Pythona z repozytorium z uprawnieniami wywołującego, zanim zostaną załadowane jakiekolwiek wagi. Repozytorium config.json używa auto_map do wskazania modułu i klasy Pythona, które mają zostać załadowane; Transformers pobiera wskazany plik do pamięci podręcznej modułów, a exec_module() wywołanie wykonuje kod pliku znajdujący się na najwyższym poziomie, zanim zwróci żądaną klasę modelu. Raport zaznacza, że jest to udokumentowane działanie, a nie ustawienie domyślne, oraz że polityka bezpieczeństwa Transformers zaleca użytkownikom sprawdzanie zawartości plików modelowania podczas korzystania z tego argumentu. Raport przywołuje również CVE-2026-22807, dotyczące wersji vLLM od 0.10.1 do wersji 0.14.0, w której usunięto podatność; wersje te ładowały auto_map moduły bez sprawdzania trust_remote_code ustawienia, co pozwalało złośliwemu repozytorium uruchamiać kod podczas startu serwera.

Wykrycie zagrożenia i powiązania między kontami

Pluto stworzyło skaner obejmujący wszystkie .py pliki wskazane przez auto_map w config.json, a także pliki Pythona znajdujące się obok wag modeli; skaner wykrywał wzorce takie jak subprocess, socket, ctypes, memfd_create oraz dekodowanie base64. Pierwszym wykrytym repozytorium było dsxk4mr8tq/qwen2-tiny-gpt2, zawierające 305-wierszowy plik o nazwie modeling_evil.py; na koncie znajdowało się sześć repozytoriów utworzonych w ciągu 2,5 godziny 12 października 2026 r.

Przełom w ustaleniu powiązań nastąpił dzięki plikom kopii zapasowych. Repozytorium qwen2-tiny-lite zawierało modeling_evil.py.bak-src i modeling_evil.py.bak-sync, czyli starsze wersje tego samego złośliwego oprogramowania, którego adresy URL pobierania prowadziły nie do jednorazowego konta, lecz do hhzz667 na Hugging Face oraz wssb123e na ModelScope. Raport podaje, że operator skopiował kod produkcyjny na konto testowe, zaktualizował adresy URL w głównym pliku i zapomniał o kopiach zapasowych. Pierwsza fala objęła łącznie 12 repozytoriów na trzech kontach i dwóch platformach; przed ich usunięciem odnotowano ponad 700 pobrań, a systemy bezpieczeństwa nie zgłosiły żadnego alarmu.

Budowa ładunku

Przyjmując MENXIANGYU/qwen2-tiny za reprezentatywną kompilację, raport opisuje ładunek, który najpierw zapisuje /tmp/.cch/svc.py, mechanizm nadzorujący, który co 120 sekund ponownie uruchamia nieobecną koparkę, a do /root/.bashrc, /root/.profile oraz pliku użytkownika .bashrc. Trzy kompilacje dodają powłokę zwrotną, która łączy się z adresem 212.32.253.3 przez port 443 lub 9443 i ponawia próbę po każdym rozłączeniu.

Plik binarny koparki, syscore.binjest uruchamiany za pomocą memfd_create i fexecve podszywa się pod wątek roboczy jądra kworker/u20:1, przez co przy pierwszym uruchomieniu na dysku nie pozostaje ścieżka do pliku wykonywalnego; kopia zapasowa pozostaje w /tmp/.cch/syncPlik binarny o rozmiarze 40,6 MB jest spakowany za pomocą UPX, a dwa znaczniki UPX! zmieniono na PEK! wskutek czego standardowe narzędzie do rozpakowywania go odrzuca; Pluto przywróciło znaczniki i rozpakowało koparkę o nazwie peakminer, uruchamianą z adresami punktów dostępu do puli i loginem krxXJ2PKQW.workerPotwierdzenia postępu są zapisywane w lokalnym rejestrze modeli Xinference jako qwen2-tiny- po których następują kody statusu w systemie base32; ładunek usuwa też wpisy rejestracyjne konkurencyjnych koparek i kończy odpowiadające im procesy.

Dwie fale i zmiany po usunięciu

Raport przypisuje pierwszą falę do konta hhzz667, utworzonego 29 kwietnia 2026 r., które pozostawało nieaktywne przez pięć miesięcy. 21 września 2026 r. opublikowano na nim qwen2-shell, 37-wierszowy backdoor SSH, który umieszczał klucz ed25519 w authorized_keys i wysyłał sygnał kontrolny do serwera Alibaba Cloud; plik README skopiowano z oficjalnej karty modelu Qwen2.5-0.5B. Do 22 września operator udostępnił qwen2-final, 305-wierszową koparkę działającą bez pliku na dysku, ukrywającą się pod postacią wątku jądra, usuwającą konkurencyjne koparki i raportującą status w Xinference pod niewinnymi nazwami, takimi jak Qwen2Config. Komentarze w kodzie były napisane w języku chińskim uproszczonym.

Pluto zgłosiło pierwszą falę Hugging Face i ModelScope, a konta zostały usunięte. Druga fala nastąpiła w ciągu kilku dni: 19 repozytoriów na pięciu kontach, w tym MENXIANGYU z 13 repozytoriami, a także wjsbg, soumikmahato, r1r13 i htt0118; to ostatnie konto utworzono 25 października 2026 r. Jedno z repozytoriów, MENXIANGYU/qa-whl-1021, opublikowane 8,5 godziny po e-mailu z ujawnieniem informacji przez Pluto, zawiera skrypt umożliwiający ucieczkę z kontenera na hosta, który montuje dyski hosta, atakuje katalog GPUStack i zapewnia możliwość logowania jako root na hoście. Późniejszy dropper ogranicza dostęp do drugiego etapu na podstawie źródłowego adresu IP, zwracając pozostałym żądającym odpowiedź 403 z tekstem „static ip.”. Flagowe repozytorium /var/lib/gpustack katalogu i zapewnia możliwość logowania jako root na hoście. Późniejszy dropper ogranicza dostęp do drugiego etapu na podstawie źródłowego adresu IP, zwracając pozostałym żądającym odpowiedź 403 z tekstem „static ip.”. Flagowe repozytorium MENXIANGYU/qwen2-tiny odnotowało wzrost liczby pobrań z 7 354 w dniu 20 października do 28 412 w dniu 28 października, co stanowiło 97,7% pobrań w drugiej fali.

Wpływy z wydobywania kryptowalut i zaobserwowane ofiary

Portfel z pierwszej fali otrzymał około 2 276 PRL w ramach 716 transakcji, a następnie przesłał dalej około 2 241 PRL; 21 października, po usunięciu repozytoriów, nadal był aktywny na publicznych pulpitach puli wydobywczej. W serwisie Kryptex portfel wykazywał dwóch aktywnych pracowników zgłaszających peakminer/2.16.5 około 1 008 PRL, czyli w przybliżeniu 2 237 USD, w nagrodach za 30 dni w chwili wykonania zrzutu. Podczas analizy dziewięciu pracowników o nazwach przypominających nazwy notebooków dołączyło w ciągu 90 sekund od siebie, a około sześć minut później przestało przesyłać udziały. Jak opisuje raport, taki profil działania jest zgodny ze współdzielonym klastrem GPU. Osobno śledzona hl rodzina, wykorzystująca podobne wykonywanie kodu podczas importowania, wykazywała portfel MoneroOcean z 13 pracownikami i wypłatami w wysokości około 26 USD w ciągu mniej więcej miesiąca.

Luka w wykrywaniu przez skanery

Żadne z 12 repozytoriów pierwszej fali nie zostało oznaczone, a ładunek z flagowego repozytorium drugiej fali modeling_evil2.py otrzymał wynik „bezpieczny” od każdego uruchomionego skanera; według kontroli Pluto JFrog poinformował, że nie jest to model uczenia maszynowego. Dokumentacja skanowania w poszukiwaniu złośliwego oprogramowania Hugging Face informuje, że przy każdym zatwierdzeniu zmian każdy plik repozytorium mniejszy niż 2 GB jest sprawdzany przez skaner złośliwego oprogramowania. Zgodnie z dokumentacją skanowania plików pickle skaner przeprowadza skanowanie antywirusowe ClamAV oraz skanowanie importowanych plików pickle; ClamAV nie wykrywa exploitów wykorzystujących pliki pickle, a samo skanowanie „nie jest w 100% niezawodne”, więc odpowiedzialność za sprawdzenie bezpieczeństwa spoczywa na użytkowniku. Pluto podaje, że sprawdzenie .py plików, które auto_map wskazują przed ustawieniem flagi, pozwoliłoby wykryć każdy ładunek z tej kampanii, a statyczna kontrola wykonywana podczas przesyłania subprocess, socket, ctypes lub wywołania z surowym adresem IP w auto_mapplikach, do których się odwołano, pozwoliłaby wykryć je wcześniej.

Ocena atrybucji i zalecane działania

Pluto ocenia, że za kampanią stoi motywowany finansowo operator chińskojęzyczny lub niewielka grupa, wskazując na komentarze w uproszczonym chińskim, serwer dowodzenia i kontroli w Alibaba Cloud, kopie w ModelScope i hf-mirror.com, działania wymierzone w środowiska korzystające z Xinference i Tencent Cloud oraz skupienie aktywności w przedziale od 18:38 do 21:19 UTC. Kompilacja „parasit” soumikmahato zawiera komentarze w języku indonezyjskim; według raportu może to wskazywać na drugiego operatora działającego w tej samej niszy albo na jednego operatora prowadzącego kampanię w celowo odmiennym stylu.

Raport zaleca wszystkim, którzy załadowali któryś z wymienionych modeli przy włączonej obsłudze własnego kodu, sprawdzenie hostów pod kątem /tmp/.cch/, nieoczekiwanych svc.py procesów, procesu kworker/u20:1 zawierającego argumenty związane z wydobywaniem kryptowalut, zakodowanych qwen2-tiny- lub ezv- rejestracji Xinference oraz połączeń z wymienionymi serwerami i pulami. Pluto zaleca odizolowanie zainfekowanych maszyn, zabezpieczenie dowodów, usunięcie wszystkich mechanizmów utrwalania obecności, zmianę ujawnionych poświadczeń z czystej maszyny, odtworzenie systemów z zaufanego obrazu, jeśli nie można potwierdzić integralności hosta, wymaganie uwierzytelniania w API Xinference oraz przypinanie zweryfikowanych wersji modeli. Pluto twierdzi, że spodziewa się kolejnych kampanii tego rodzaju i śledzi ich rozwój.