Fałszywe repozytoria na GitHubie rozprzestrzeniają malware podszywając się pod legalne oprogramowanie - Security Bez Tabu

Fałszywe repozytoria na GitHubie rozprzestrzeniają malware podszywając się pod legalne oprogramowanie

Cybersecurity news

Wprowadzenie do problemu / definicja

Zaufanie do popularnych platform deweloperskich od lat stanowi istotny element codziennej pracy administratorów, programistów i użytkowników technicznych. Właśnie dlatego GitHub coraz częściej staje się nie tylko miejscem publikacji legalnego kodu, ale również nośnikiem kampanii malware, które wykorzystują wiarygodny kontekst do dystrybucji złośliwego oprogramowania.

W opisywanym przypadku atakujący przygotowali setki fałszywych repozytoriów podszywających się pod znane narzędzia, projekty bezpieczeństwa i aplikacje użytkowe. Celem operacji była dystrybucja infostealera, czyli malware zaprojektowanego do szybkiej kradzieży poświadczeń, danych przeglądarek, portfeli kryptowalutowych oraz innych wrażliwych informacji z zainfekowanego systemu.

W skrócie

Badacze wykryli 292 fałszywe repozytoria na GitHubie, które imitowały legalne projekty i kierowały użytkowników do spreparowanych stron pobierania. Kampania wykorzystywała profesjonalnie przygotowane opisy, branding i elementy wizualne mające zwiększyć wiarygodność publikowanych zasobów.

Końcowym ładunkiem był wariant stealera z rodziny BoryptGrab. Malware koncentrował się na szybkim pozyskaniu maksymalnej ilości danych i działał głównie w modelu jednorazowego uruchomienia, bez utrzymywania trwałości w systemie.

Kontekst / historia

Nadużywanie zaufanych platform do dostarczania malware nie jest nowym zjawiskiem, jednak GitHub pozostaje szczególnie atrakcyjnym środowiskiem dla operatorów takich kampanii. Publiczne repozytoria, pliki README, historia projektu i obecność kodu źródłowego budują wrażenie autentyczności, co obniża czujność użytkowników pobierających narzędzia spoza oficjalnych kanałów producenta.

W analizowanej operacji podszywano się pod wiele kategorii oprogramowania, w tym narzędzia bezpieczeństwa, aplikacje finansowe, usługi kryptowalutowe, oprogramowanie deweloperskie, rozwiązania pocztowe, narzędzia dla macOS oraz projekty związane z grami. Według opublikowanych ustaleń początek kampanii powiązano z 26 czerwca 2026 roku, a jej wykrycie nastąpiło po zaobserwowaniu podszywania się pod jeden z produktów bezpieczeństwa.

Analiza techniczna

Każde fałszywe repozytorium zawierało plik README prowadzący do zewnętrznej strony pobierania. Infrastruktura używana do dostarczania malware była silnie ustandaryzowana: wiele podszywanych marek korzystało z tego samego szablonu HTML i JavaScript, różniącego się głównie warstwą wizualną oraz ścieżką adresu.

Mechanizm strony analizował segmenty URL, aby rozpoznać repozytorium źródłowe i automatycznie podstawić odpowiedni branding. Taka architektura umożliwiała operatorom szybkie klonowanie kolejnych wariantów kampanii i masowe uruchamianie nowych podszyć bez przebudowy całego łańcucha infekcji.

Po stronie ofiary pobierane było duże archiwum ZIP, którego nazwa i zawartość zmieniały się bardzo często, mniej więcej co minutę. W archiwum znajdowały się dwa istotne komponenty: legalnie podpisany aktualizator WinGUP oraz trojanizowana biblioteka libcurl.dll. Po uruchomieniu pliku wykonywalnego dochodziło do bocznego ładowania biblioteki DLL, a następnie do dekodowania i refleksyjnego uruchomienia stealera bezpośrednio w pamięci.

Z perspektywy napastnika taka metoda przynosi kilka korzyści. Użycie podpisanego komponentu zwiększa pozory legalności, natomiast uruchomienie payloadu w pamięci ogranicza liczbę artefaktów pozostawianych na dysku i może utrudniać detekcję opartą wyłącznie na analizie plików.

Zidentyfikowany wariant BoryptGrab zbierał szeroki zakres danych z systemu ofiary, w tym:

  • hasła, cookies i dane płatnicze z ponad 19 przeglądarek,
  • dane z 32 marek portfeli kryptowalutowych,
  • sesje Telegrama, tokeny Discorda i tokeny sesyjne Steam,
  • poświadczenia z komunikatorów,
  • dane z Menedżera poświadczeń systemu Windows,
  • pliki z katalogów Desktop i Documents związane z hasłami, kopiami zapasowymi, portfelami i frazami odzyskiwania,
  • zrzuty ekranu, informacje o systemie oraz listy zainstalowanego oprogramowania.

Na szczególną uwagę zasługuje zdolność wariantu BoryptGrab do omijania mechanizmu App-Bound Encryption w Chrome poprzez bezpośrednią iniekcję kodu do procesu przeglądarki. To sygnał, że operatorzy rozwijają swoje narzędzia z myślą o obchodzeniu nowoczesnych zabezpieczeń przeglądarek i skuteczniejszym przejmowaniu danych uwierzytelniających.

Po zebraniu informacji malware kompresował dane i wysyłał je do serwera C2. Brak mechanizmu trwałości wskazuje, że kampania była nastawiona przede wszystkim na szybkie pozyskanie danych i ograniczenie czasu ekspozycji w środowisku ofiary.

Konsekwencje / ryzyko

Największe zagrożenie dotyczy użytkowników, którzy pobierają oprogramowanie z niezweryfikowanych repozytoriów lub szukają alternatywnych źródeł dla komercyjnych narzędzi. Kampania łączy klasyczną socjotechnikę z technikami charakterystycznymi dla loaderów i infostealerów, przez co może skutecznie omijać ostrożność mniej doświadczonych odbiorców.

Dla organizacji skutki incydentu mogą być znacznie poważniejsze niż pojedyncza infekcja stacji roboczej. Kradzież danych z przeglądarek, tokenów sesyjnych i systemowych magazynów poświadczeń może otworzyć drogę do wtórnych ataków na środowiska chmurowe, konta administracyjne oraz usługi SaaS.

  • przejęcie kont deweloperskich i administracyjnych,
  • kradzież dostępu do SaaS, VPN i poczty,
  • wykorzystanie tokenów sesyjnych do obejścia MFA w wybranych scenariuszach,
  • kompromitacja portfeli kryptowalutowych i zasobów finansowych,
  • dalsze użycie skradzionych danych w phishingu, ransomware lub oszustwach BEC.

Ryzyko zwiększa fakt, że GitHub bywa standardowo dopuszczony w środowiskach firmowych, a ruch do publicznych repozytoriów często nie jest traktowany jako podejrzany. Jeśli użytkownik uruchomi pobrany pakiet poza kontrolowanym procesem dystrybucji oprogramowania, tradycyjne polityki bezpieczeństwa mogą nie zapewnić wystarczającej ochrony.

Rekomendacje

Incydent pokazuje, że sama obecność projektu na zaufanej platformie nie może być traktowana jako dowód autentyczności. Organizacje powinny zaostrzyć kontrolę nad sposobem pobierania, weryfikowania i uruchamiania narzędzi pochodzących z publicznych źródeł kodu.

  • Stosować allowlisting aplikacji i blokować wykonywanie plików z katalogów pobrań, lokalizacji tymczasowych oraz innych nieautoryzowanych ścieżek użytkownika.
  • Dopuszczać wyłącznie oficjalne repozytoria producentów, zweryfikowane organizacje i kanały dystrybucji podpisanych binariów.
  • Rozszerzyć reguły EDR i SIEM o wykrywanie technik DLL side-loading z użyciem legalnych binariów ładujących podejrzane biblioteki.
  • Monitorować nietypowe procesy odczytujące dane z przeglądarek, menedżerów poświadczeń, katalogów użytkownika i portfeli kryptowalutowych.
  • Egzekwować separację profili uprzywilejowanych, stosować odporne na phishing metody MFA oraz skracać czas życia sesji tam, gdzie to możliwe.
  • Prowadzić regularną edukację użytkowników i zespołów deweloperskich na temat fałszywych repozytoriów oraz technik budowania pozorów wiarygodności.
  • Przeanalizować dostępne wskaźniki kompromitacji i wdrożyć reguły YARA oraz detekcje behawioralne powiązane z rodziną BoryptGrab.

Podsumowanie

Kampania oparta na blisko 300 fałszywych repozytoriach pokazuje, jak łatwo zaufanie do platform deweloperskich może zostać przekształcone w skuteczny wektor infekcji. Połączenie podszywania się pod znane projekty, dynamicznych stron pobierania, DLL side-loading oraz pamięciowego uruchamiania stealera zwiększa skuteczność kradzieży danych i utrudnia wykrycie ataku.

Z punktu widzenia obrony kluczowe znaczenie mają kontrola źródeł oprogramowania, widoczność zachowań procesów, ochrona przeglądarek i ograniczenie uruchamiania nieautoryzowanych binariów. To kolejny sygnał, że bezpieczeństwo łańcucha dostaw oprogramowania musi obejmować również publiczne platformy repozytoryjne.

Źródła

  1. BleepingComputer — https://www.bleepingcomputer.com/news/security/nearly-300-github-repos-pose-as-legit-software-to-push-malware/
  2. Arctic Wolf — Nearly 300 GitHub Repositories Spoofing Legitimate Software Projects Deliver BoryptGrab Malware — https://arcticwolf.com/resources/blog/nearly-300-github-repositories-spoofing-legitimate-software-projects-deliver-boryptgrab-malware/
  3. GitHub Docs — About READMEs — https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes