Kampania malware na Hugging Face ponownie przejmuje GPU do kopania kryptowalut - Security Bez Tabu

Kampania malware na Hugging Face ponownie przejmuje GPU do kopania kryptowalut

Cybersecurity news

Wprowadzenie do problemu / definicja

Platformy udostępniające modele AI stały się istotnym elementem współczesnego łańcucha dostaw oprogramowania. Coraz częściej są one jednak wykorzystywane nie tylko do publikacji legalnych artefaktów, ale również do dystrybucji złośliwego kodu, który uruchamia się podczas ładowania modelu. Najnowsza kampania wymierzona w użytkowników Hugging Face pokazuje, że atakujący potrafią skutecznie połączyć zaufanie do popularnej platformy z przejęciem cennych zasobów GPU.

W praktyce problem nie ogranicza się do samego „zatrucia” wag modelu. Kluczowym wektorem jest możliwość dostarczenia niestandardowego kodu Pythona wykonywanego po stronie użytkownika lub serwera inference. To sprawia, że model AI przestaje być wyłącznie zestawem danych, a staje się aktywnym komponentem wykonawczym, który wymaga takiej samej ostrożności jak niezweryfikowane zależności programistyczne.

W skrócie

Badacze opisali wieloetapową kampanię malware, w której złośliwe repozytoria na Hugging Face podszywały się pod niewielkie checkpointy modeli Qwen2. Atak wykorzystywał opcję trust_remote_code, umożliwiającą uruchomienie kodu dostarczonego przez autora repozytorium już w momencie ładowania modelu.

  • instalację koparki kryptowalut na hostach GPU,
  • wdrożenie mechanizmów trwałości i ponownego uruchamiania malware,
  • usuwanie konkurencyjnych minerów z przejętej maszyny,
  • otwarcie reverse shell i uzyskanie zdalnego dostępu do systemu,
  • szybkie odtwarzanie infrastruktury po usunięciu pierwszych złośliwych repozytoriów.

Skala i powtarzalność działań wskazują, że nie był to jednorazowy incydent, lecz dochodowy model ataku ukierunkowany na środowiska AI korzystające z drogich akceleratorów GPU.

Kontekst / historia

Kampania została powiązana z wieloma złośliwymi repozytoriami publikowanymi falami od września 2026 roku. Celem były przede wszystkim samodzielnie zarządzane serwery inference, środowiska laboratoryjne oraz współdzielone klastry badawcze, w których testowanie publicznie dostępnych modeli odbywa się szybko i nierzadko bez pełnego przeglądu bezpieczeństwa.

To ważny sygnał dla organizacji rozwijających własne pipeline’y MLOps. Dotychczas wiele zespołów traktowało modele jako względnie pasywne artefakty danych. Tymczasem funkcje pozwalające na ładowanie zdalnego kodu oznaczają, że repozytorium modelu może zachowywać się podobnie jak pakiet z publicznego rejestru, obraz kontenera lub skrypt uruchamiany w środowisku produkcyjnym.

Opisany przypadek wpisuje się więc w szerszy trend zagrożeń dla AI supply chain. Z perspektywy bezpieczeństwa publiczne repozytorium modelu należy analizować nie tylko pod kątem jakości modelu czy zgodności licencyjnej, ale również pod kątem możliwego wykonania kodu, eskalacji uprawnień i nadużycia zasobów infrastruktury.

Analiza techniczna

Sednem kampanii było nadużycie mechanizmu trust_remote_code znanego z ekosystemu Transformers. Opcja ta pozwala repozytorium dostarczyć własne pliki implementacyjne i uruchomić je lokalnie podczas inicjalizacji modelu. W przypadku środowisk inference oznacza to wykonanie kodu z uprawnieniami procesu obsługującego model, często na serwerze wyposażonym w kosztowne GPU i dostęp do wewnętrznych zasobów.

Według analizy badaczy jeden z aktywnie wykorzystywanych wariantów nie pełnił w praktyce roli użytecznego modelu AI. Zamiast tego służył jako nośnik malware instalującego koparkę kryptowalut ukrytą pod nazwą przypominającą legalny proces systemowy Linuksa. Kod wdrażał też persistence, monitorował działanie minera i próbował restartować go po zatrzymaniu.

Istotnym elementem było również usuwanie konkurencyjnych minerów z zainfekowanego hosta. Tego typu zachowanie jest charakterystyczne dla operatorów nastawionych na długotrwałe wykorzystanie zasobów ofiary i maksymalizację zysku. Nie chodziło więc o krótkie, oportunistyczne użycie GPU, ale o utrzymanie stabilnej obecności na serwerze.

Część wariantów rozszerzała zestaw funkcji o reverse shell, co znacząco podnosi wagę incydentu. W takim scenariuszu atakujący może nie tylko kopać kryptowaluty, ale też wykonywać polecenia na hoście, przeszukiwać środowisko, kraść poświadczenia i instalować kolejne narzędzia post-exploitation. Jeżeli serwer inference miał dostęp do tokenów API, kluczy SSH, zasobów chmurowych lub współdzielonych wolumenów, kompromitacja mogła prowadzić do dalszego ruchu bocznego.

Badacze odnotowali także warianty zawierające kod, który mógł wspierać ucieczkę z kontenera i przejęcie serwera bazowego. W środowiskach MLOps to szczególnie niebezpieczne, ponieważ kontenery inference często mają dostęp do akceleratorów GPU, magazynów danych, systemów kolejkowych i sieci wewnętrznych. Nawet jeśli początkowa infekcja dotyczy pojedynczego kontenera, skutki mogą objąć znacznie szerszą część infrastruktury.

Dodatkową trudność stanowi wykrywanie takich zagrożeń. Tradycyjne skanowanie antywirusowe lub kontrole skupione na samych plikach modelu mogą nie wystarczyć, jeśli nie analizują rzeczywistego zachowania kodu ładowanego dynamicznie przez repozytorium. W efekcie artefakt może przejść podstawowe kontrole, a mimo to uruchomić złośliwe instrukcje w środowisku produkcyjnym.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem jest przejęcie zasobów GPU do cryptominingu. To oznacza spadek wydajności usług inference, wzrost kosztów energii, większe zużycie sprzętu oraz opóźnienia w realizacji zadań ML. W organizacjach korzystających ze współdzielonej infrastruktury skutki mogą być odczuwalne jednocześnie przez wiele zespołów.

Jeszcze poważniejsze ryzyko wiąże się z pełną kompromitacją hosta. Jeśli malware otwiera reverse shell lub utrzymuje backdoor, atakujący zyskuje możliwość dalszej eksploracji środowiska. Serwery AI bardzo często przechowują poświadczenia do chmury, tokeny do rejestrów modeli, dane eksperymentów, zbiory treningowe i dostęp do wewnętrznych narzędzi orkiestracji. Naruszenie takiego systemu może doprowadzić do kradzieży danych, modyfikacji pipeline’ów MLOps oraz infekcji kolejnych zasobów.

Istnieje również ryzyko błędnej klasyfikacji incydentu. Zespół może uznać problem wyłącznie za obecność minera i zakończyć reakcję po usunięciu procesu, podczas gdy w systemie pozostaną mechanizmy persistence, zmodyfikowane usługi startowe lub ukryty backdoor. Taki scenariusz zwiększa prawdopodobieństwo ponownej aktywacji zagrożenia i utrzymania dostępu przez operatora.

Rekomendacje

Organizacje korzystające z publicznych modeli powinny przyjąć zasadę ograniczonego zaufania. Każdy model wykorzystujący niestandardowy kod należy traktować jak potencjalnie niebezpieczny komponent oprogramowania, który wymaga przeglądu bezpieczeństwa przed wdrożeniem do środowiska produkcyjnego.

  • blokować lub ściśle ograniczać użycie trust_remote_code w produkcji,
  • stosować listy dozwolonych repozytoriów i zatwierdzonych autorów,
  • przypinać wdrożenia do konkretnych commitów lub wersji modeli,
  • utrzymywać lokalne mirrory zweryfikowanych artefaktów,
  • izolować hosty inference od krytycznych sekretów i zasobów administracyjnych,
  • monitorować procesy GPU oraz anomalie w wykorzystaniu akceleratorów,
  • wykrywać nietypowe połączenia wychodzące z serwerów inference,
  • kontrolować integralność obrazów kontenerów i środowisk uruchomieniowych,
  • rotować poświadczenia po każdym podejrzeniu uruchomienia złośliwego modelu,
  • odbudowywać host po incydencie zamiast ograniczać się do usunięcia minera.

Zespoły SOC, DevSecOps i MLOps powinny zaktualizować playbooki o scenariusze charakterystyczne dla łańcucha dostaw AI. Obejmuje to analizę kodu ładowanego podczas inicjalizacji modelu, zależności pobieranych w runtime, uprawnień usług inference oraz ryzyka związanego z uruchamianiem modeli w kontenerach z dostępem do GPU i sieci wewnętrznej.

W środowiskach badawczych warto uruchamiać publiczne modele w odizolowanych sandboxach bez dostępu do produkcyjnych sekretów. Jeśli istnieje podejrzenie, że złośliwy model został już załadowany, bezpiecznym założeniem powinno być traktowanie maszyny jako skompromitowanej, zabezpieczenie materiału śledczego, odłączenie hosta od sieci oraz pełna weryfikacja mechanizmów trwałości i poświadczeń.

Podsumowanie

Opisana kampania pokazuje, że bezpieczeństwo AI obejmuje dziś nie tylko ochronę danych i modeli, ale także kontrolę nad sposobem ich dystrybucji i uruchamiania. Publiczne repozytoria modeli stały się elementem łańcucha dostaw oprogramowania, a funkcje umożliwiające wykonywanie zdalnego kodu otwierają realny wektor ataku na infrastrukturę GPU.

Najważniejszy wniosek jest prosty: model AI nie zawsze jest wyłącznie artefaktem danych. Jeżeli jego uruchomienie wymaga zaufania do kodu dostarczonego przez autora repozytorium, należy oceniać go z taką samą ostrożnością jak niezweryfikowaną zależność programistyczną. W przeciwnym razie organizacja naraża się nie tylko na cryptomining, ale również na backdoory, ruch boczny i przejęcie serwerów obsługujących obciążenia AI.

Źródła