FakeGit wraca z nową falą ataków: 17 tys. złośliwych repozytoriów GitHub rozprowadza SmartLoader

securitybeztabu.pl 12 godzin temu

Wprowadzenie do problemu / definicja

Kampania FakeGit to zaawansowany model dystrybucji malware, w którym cyberprzestępcy wykorzystują fałszywe lub przejęte repozytoria GitHub do podszywania się pod legalne projekty open source. Atak bazuje na zaufaniu użytkowników do popularnej platformy programistycznej oraz na przekonaniu, iż kod i pliki udostępnione w takim środowisku są bezpieczne.

W praktyce ofiara trafia na repozytorium wyglądające jak prawdziwe narzędzie, biblioteka albo komponent AI. Instrukcje w pliku README prowadzą do pobrania archiwum ZIP, które uruchamia loader SmartLoader, a ten może następnie dostarczać kolejne ładunki, w tym malware kradnące dane.

W skrócie

Na początku października 2026 roku odnotowano ponowną aktywację kampanii FakeGit.
Skala operacji wzrosła do 17 610 złośliwych repozytoriów GitHub.
W ciągu 34 godzin operatorzy przekierowali ponad 13 tys. repozytoriów do nowych artefaktów malware.
Centralnym elementem łańcucha infekcji pozostaje SmartLoader, wykorzystywany jako pierwszy etap dostarczenia kolejnych zagrożeń.
Napastnicy nie muszą stale tworzyć nowej infrastruktury — wystarczy, iż aktualizują README i linki do szkodliwych paczek.

Kontekst / historia

Nadużycia polegające na wykorzystywaniu publicznych repozytoriów do dystrybucji złośliwego systemu nie są nowym zjawiskiem, jednak FakeGit wyróżnia się skalą oraz wysoką elastycznością operacyjną. Latem 2026 roku analitycy zaczęli szerzej wiązać tę nazwę z rozległą siecią repozytoriów podszywających się pod legalne projekty, w tym narzędzia dla programistów, komponenty związane z AI oraz serwery MCP.

Nowa fala pokazuje zmianę podejścia po stronie operatorów. Zamiast budować kampanię od zera przy każdej kolejnej akcji, utrzymują oni rozproszoną flotę repozytoriów, które mogą być gwałtownie ponownie uzbrojone. Taki model znacząco utrudnia działania obronne, ponieważ usunięcie pojedynczych wskaźników kompromitacji nie powoduje likwidacji całego ekosystemu zagrożenia.

Analiza techniczna

Techniczny schemat działania FakeGit jest stosunkowo prosty, ale bardzo skuteczny. Użytkownik odnajduje repozytorium, które wygląda wiarygodnie i zawiera pozornie normalną dokumentację wdrożeniową. Kluczowym elementem jest przycisk pobierania lub link prowadzący do archiwum ZIP, które inicjuje infekcję poprzez SmartLoader.

Z punktu widzenia napastników istotną przewagą tej kampanii jest niski koszt utrzymania. Zamiast przepisywać kod czy stale publikować nowe projekty, operatorzy aktualizują głównie pliki README i podmieniają odnośniki do kolejnych paczek malware. Oznacza to, iż raz zbudowana infrastruktura może służyć przez długi czas i być aktywowana w dowolnym momencie.

Dodatkowym utrudnieniem dla obrońców jest rozproszenie plików wykorzystywanych w kampanii. Złośliwe archiwa mogą znajdować się w różnych lokalizacjach w obrębie ekosystemu GitHub, takich jak forki, starsze pliki, sekcje wydań, załączniki do zgłoszeń czy osobne repozytoria pełniące funkcję hostów pobrań. Taka redundancja sprawia, iż usunięcie jednego źródła nie kończy całej operacji.

Znaczenie ma również charakter kont publikujących repozytoria. Część z nich to profile jednorazowe lub tworzone masowo, ale możliwe jest także wykorzystanie kont należących do prawdziwych deweloperów. To zwiększa wiarygodność fałszywych projektów i osłabia skuteczność mechanizmów opartych wyłącznie na reputacji właściciela.

Konsekwencje / ryzyko

FakeGit stanowi realne zagrożenie dla bezpieczeństwa łańcucha dostaw oprogramowania, stacji roboczych deweloperów i danych organizacyjnych. Najbardziej bezpośrednim skutkiem uruchomienia zainfekowanego archiwum jest wdrożenie SmartLoadera, który może dostarczyć kolejne komponenty, w tym infostealery przechwytujące hasła, tokeny, dane przeglądarek oraz inne poufne artefakty.

Dla firm problem jest szczególnie poważny, ponieważ atak wykorzystuje platformę powszechnie uznawaną za zaufaną i potrzebną w codziennej pracy. W praktyce całkowite zablokowanie GitHub jest zwykle niemożliwe, co ogranicza skuteczność klasycznych metod filtrowania. Dodatkowo duża skala kampanii oraz szybka rekonfiguracja linków sprawiają, iż wykrywanie i reagowanie stają się trudniejsze.

Ryzyko rośnie tam, gdzie pracownicy samodzielnie pobierają narzędzia z publicznych repozytoriów, testują niezweryfikowany kod lub korzystają z projektów AI bez potwierdzenia źródła i integralności plików. W takim środowisku incydent może doprowadzić nie tylko do kompromitacji pojedynczej maszyny, ale również do przejęcia kont, ruchu bocznego i eskalacji zagrożenia wewnątrz organizacji.

Rekomendacje

Ograniczenie ryzyka związanego z FakeGit wymaga połączenia kontroli technicznych, procedur operacyjnych i dyscypliny po stronie użytkowników. Samo zaufanie do platformy hostingowej nie może być uznawane za wystarczające kryterium bezpieczeństwa.

Weryfikować właściciela repozytorium, historię projektu, aktywność commitów oraz reputację konta publikującego.
Ograniczyć możliwość bezpośredniego pobierania i uruchamiania archiwów ZIP z README oraz sekcji Releases bez dodatkowej kontroli.
Stosować sandboxing, skanowanie plików przy pobraniu i polityki allowlist dla narzędzi deweloperskich.
Monitorować użycie tokenów GitHub, aktywne sesje oraz nietypowe zachowania na kontach deweloperskich.
W przypadku podejrzenia infekcji unieważnić sesje, cofnąć tokeny dostępu, zresetować poświadczenia i przeprowadzić analizę stacji roboczej.
Preferować oficjalne rejestry, repozytoria producentów oraz wewnętrznie zatwierdzone źródła oprogramowania.
Rozszerzyć detekcję o sygnały takie jak nagłe zmiany README, zewnętrzne archiwa ZIP, nietypowe przekierowania i wzorce nazw imitujące popularne projekty.

Podsumowanie

Powrót FakeGit potwierdza, iż publiczne platformy kodu pozostają atrakcyjnym kanałem dystrybucji malware, zwłaszcza gdy przestępcy potrafią wykorzystać zaufanie użytkowników do znanych narzędzi i usług. Obecna skala kampanii pokazuje, iż model oparty na ponownym uzbrajaniu istniejącej infrastruktury może być bardziej efektywny niż ciągłe tworzenie nowych zasobów.

Z perspektywy obrony najważniejsze znaczenie ma nie tylko analiza samych plików, ale również rygorystyczna weryfikacja źródła, kontrola pobrań oraz ochrona kont deweloperskich. Organizacje, które nie wdrożą takich mechanizmów, będą coraz bardziej narażone na ataki wykorzystujące zaufane platformy jako nośnik infekcji.