Wprowadzenie do problemu / definicja
FakeGit to kampania malware wykorzystująca fałszywe lub przejęte repozytoria GitHub do dystrybucji złośliwych plików. Atakujący tworzą wiarygodnie wyglądające projekty, kopiują opisy legalnych narzędzi i publikują instrukcje instalacji, które finalnie prowadzą ofiarę do pobrania archiwum ZIP zawierającego loader SmartLoader.
Z perspektywy bezpieczeństwa jest to zagrożenie łączące elementy socjotechniki i ataków na software supply chain. Celem są przede wszystkim programiści, administratorzy oraz użytkownicy techniczni, którzy regularnie pobierają narzędzia z publicznych repozytoriów.
W skrócie
Na początku października 2026 roku kampania FakeGit została ponownie uruchomiona na dużą skalę. Badacze wskazują, że infrastruktura objęła 17 610 złośliwych repozytoriów, a operatorzy w ciągu około 34 godzin zaktualizowali ponad 13 tys. z nich, głównie modyfikując pliki README i podmieniając odnośniki do nowych ładunków.
W wielu przypadkach końcowym celem dystrybucji był SmartLoader, który może służyć jako pierwszy etap infekcji i dostarczać kolejne komponenty, w tym infostealer StealC. Skala oraz tempo zmian sugerują wysoki poziom automatyzacji i dobrze przygotowany model operacyjny.
Kontekst / historia
FakeGit nie jest nowym zjawiskiem, ale najnowsza fala pokazuje wyraźną ewolucję taktyki. Latem 2026 roku badacze opisywali już tysiące fałszywych repozytoriów podszywających się pod popularne projekty, narzędzia AI, Skills oraz serwery MCP.
Obecnie operatorzy nie muszą tworzyć całej infrastruktury od zera. Wykorzystują wcześniej przygotowaną lub utrzymywaną flotę repozytoriów i kont, które mogą zostać ponownie „uzbrojone” przez prostą zmianę linków do plików pobieranych przez ofiarę. To zwiększa trwałość kampanii i utrudnia jej skuteczne wygaszenie.
Dodatkowym problemem jest możliwość wykorzystywania kont, które na pierwszy rzut oka wyglądają na autentyczne i posiadają historię aktywności. W praktyce oznacza to, że użytkownicy nie mogą polegać wyłącznie na reputacji profilu, wieku repozytorium czy jego pozornej wiarygodności.
Analiza techniczna
Mechanizm ataku jest stosunkowo prosty, ale bardzo skuteczny. Użytkownik trafia do repozytorium wyglądającego jak legalny projekt, zapoznaje się z opisem i instrukcją, a następnie klika przycisk lub link pobierania. Zamiast deklarowanego narzędzia otrzymuje archiwum ZIP zawierające SmartLoader.
Charakterystyczną cechą kampanii jest koncentracja na warstwie prezentacyjnej repozytorium, przede wszystkim na plikach README. Dzięki temu przestępcy mogą szybko zmieniać ścieżkę infekcji bez przebudowy całego projektu i bez konieczności publikowania widocznych zmian w kodzie źródłowym.
Badacze zwracają również uwagę, że złośliwe pliki mogą być rozproszone w wielu miejscach. Payloady mogą znajdować się nie tylko w jednym repozytorium, lecz także w forkach, starszych plikach, assets wydań, załącznikach zgłoszeń lub oddzielnych zasobach pełniących funkcję hostingu. Taki model utrudnia wykrycie i usunięcie całego łańcucha dostaw malware.
Istotnym elementem operacyjnym jest także tzw. re-pointing, czyli przekierowywanie istniejących przynęt na nowe pliki. Nawet jeśli część odnośników zostanie zgłoszona lub zablokowana, operatorzy mogą szybko podmienić źródło pobrania i ponownie aktywować wcześniej przygotowane repozytoria.
SmartLoader pełni funkcję pierwszego etapu infekcji. Jego rolą jest uruchomienie dalszych komponentów złośliwego łańcucha, co daje przestępcom dużą elastyczność i pozwala dostosowywać końcowy payload do ofiary, celu kampanii lub aktualnych potrzeb operacyjnych.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem infekcji jest kompromitacja stacji roboczych deweloperów i innych użytkowników technicznych. Jeśli po SmartLoaderze wdrożony zostanie infostealer, konsekwencje mogą obejmować kradzież haseł, ciasteczek sesyjnych, tokenów, danych przeglądarek, kluczy API i innych sekretów wykorzystywanych w środowiskach developerskich oraz chmurowych.
Dla organizacji takie zdarzenie może być punktem wejścia do znacznie poważniejszego incydentu. Przejęcie danych uwierzytelniających lub aktywnych sesji może prowadzić do kompromitacji kont GitHub, środowisk CI/CD, rejestrów pakietów, zasobów chmurowych oraz systemów wewnętrznych.
Ryzyko ma także wymiar reputacyjny i systemowy. Kampanie tego typu podważają zaufanie do publicznych repozytoriów, plików README i metryk społecznościowych, takich jak liczba gwiazdek, forków czy historia aktywności projektu. W efekcie nawet pozornie wiarygodne repozytorium może stać się wektorem infekcji.
Rekomendacje
Organizacje powinny wdrożyć wielowarstwowe zabezpieczenia obejmujące zarówno użytkowników końcowych, jak i proces pozyskiwania oprogramowania z publicznych źródeł.
- Ograniczyć pobieranie i uruchamianie niezweryfikowanych archiwów ZIP z publicznych repozytoriów.
- Wprowadzić polityki allowlist dla narzędzi developerskich i zaufanych źródeł pobrań.
- Monitorować uruchamianie plików pobranych z przeglądarki oraz z katalogów tymczasowych.
- Inspekcjonować ruch do repozytoriów, assets wydań i innych lokalizacji hostujących pliki wykonywalne.
- Wykrywać zachowania typowe dla loaderów i infostealerów, w tym próby kradzieży danych przeglądarkowych oraz tokenów.
Po stronie użytkowników i zespołów developerskich warto przyjąć bardziej rygorystyczne zasady weryfikacji źródeł:
- Sprawdzać właściciela repozytorium, historię commitów i autentyczność projektu.
- Nie traktować README, gwiazdek, forków ani popularności jako wystarczającego dowodu zaufania.
- Pobierać narzędzia wyłącznie z oficjalnych repozytoriów producenta lub uznanych rejestrów.
- Stosować passkeys oraz unieważniać aktywne sesje i tokeny po podejrzeniu infekcji.
- Rotować sekrety, klucze API i dane uwierzytelniające, jeśli na urządzeniu uruchomiono podejrzany plik.
Z perspektywy SOC i zespołów reagowania na incydenty zdarzenie związane z SmartLoaderem należy analizować szerzej niż pojedynczą infekcję malware. Należy zakładać możliwość przejęcia tożsamości, kompromitacji kont deweloperskich i wtórnego skażenia repozytoriów lub pipeline’ów CI/CD.
Podsumowanie
Powrót FakeGit potwierdza, że publiczne platformy kodu pozostają atrakcyjnym kanałem dystrybucji malware. Połączenie socjotechniki, automatyzacji i odpornej infrastruktury pozwala przestępcom utrzymywać długowieczne przynęty oraz szybko podmieniać payloady bez konieczności budowania kampanii od nowa.
Skala operacji obejmująca 17,6 tys. repozytoriów pokazuje, że nie jest to incydent jednostkowy, lecz trwały model działania. Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia kontroli software supply chain także na warstwę repozytoriów, instrukcji instalacyjnych i plików pomocniczych, które coraz częściej stają się nośnikiem ryzyka.