Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Fałszywe repozytoria publikowane na GitHubie od lat pozostają skutecznym narzędziem socjotechnicznym. Przestępcy podszywają się pod legalne projekty open source, narzędzia bezpieczeństwa i popularne aplikacje, aby skłonić użytkowników do pobrania złośliwych plików. W opisanej kampanii celem było dostarczenie infostealera, czyli szkodliwego oprogramowania przeznaczonego do kradzieży haseł, danych finansowych, tokenów sesyjnych oraz innych wrażliwych artefaktów dostępowych.
W skrócie
Badacze zidentyfikowali 292 fałszywe repozytoria, które imitowały legalne oprogramowanie, rozwiązania bezpieczeństwa i narzędzia wykorzystywane przez deweloperów oraz użytkowników końcowych. Każde repozytorium zawierało plik README kierujący ofiarę do spreparowanej strony pobierania.
- Repozytoria podszywały się pod znane aplikacje i projekty.
- Strony pobierania korzystały z powtarzalnej infrastruktury i podobnych szablonów.
- Po uruchomieniu pakietu dochodziło do załadowania złośliwej biblioteki DLL.
- Infostealer wykonywał się w pamięci i koncentrował się na szybkim exfiltracji danych.
- Kampania obejmowała m.in. narzędzia deweloperskie, aplikacje finansowe, usługi kryptowalutowe, bezpieczną pocztę, oprogramowanie dla macOS i rozwiązania dla graczy.
Kontekst / historia
Incydent wpisuje się w szerszy trend nadużywania zaufanych platform deweloperskich do dystrybucji malware. Publiczne repozytoria są często wysoko pozycjonowane w wyszukiwarkach, co zwiększa prawdopodobieństwo, że użytkownik uzna je za wiarygodne źródło i pobierze plik bez dodatkowej weryfikacji.
W tym przypadku kampania została wykryta po podszyciu się pod legalne rozwiązanie bezpieczeństwa. Dalsza analiza pokazała dużą skalę operacji oraz wysoki poziom powtarzalności infrastruktury, co sugeruje częściową automatyzację tworzenia fałszywych projektów, opisów i stron pobierania. To ważny sygnał, że podobne operacje mogą być szybko odtwarzane pod nowymi nazwami i markami.
Analiza techniczna
Mechanizm ataku opierał się na kilku warstwach oszustwa. Fałszywe repozytoria zawierały opisy, oznaczenia i elementy wizualne mające budować pozory autentyczności. Następnie użytkownik był kierowany do zewnętrznej strony pobierania, która wykorzystywała spójny szablon HTML i JavaScript stosowany przy wielu różnych kampaniach podszywających się pod inne produkty.
Strona udostępniała lub generowała duże archiwum ZIP, którego nazwa i zawartość mogły zmieniać się w krótkich odstępach czasu. W archiwum znajdowała się legalnie podpisana aplikacja aktualizatora oraz spreparowana biblioteka libcurl.dll. Po uruchomieniu pliku wykonywalnego dochodziło do klasycznego DLL sideloadingu, w którym zaufany proces ładował złośliwą bibliotekę.
Złośliwa biblioteka dekodowała i uruchamiała osadzony komponent bezpośrednio w pamięci. Badacze powiązali próbki z rodziną BoryptGrab. Malware był zdolny do zbierania danych z ponad 19 przeglądarek internetowych, 32 marek portfeli kryptowalutowych oraz z wybranych aplikacji komunikacyjnych i społecznościowych.
Zakres kradzionych danych obejmował:
- hasła i zapisane poświadczenia,
- pliki cookie i tokeny sesyjne,
- dane płatnicze,
- zawartość menedżera poświadczeń Windows,
- listy zainstalowanego oprogramowania,
- zrzuty ekranu,
- wybrane pliki użytkownika związane z kopiami zapasowymi, seed phrase, portfelami i hasłami.
Na szczególną uwagę zasługuje informacja, że analizowany wariant miał oferować wcześniej nieudokumentowaną możliwość obejścia mechanizmu App-Bound Encryption w Chrome poprzez bezpośrednią iniekcję kodu do procesu przeglądarki. Jeśli taka funkcjonalność zostanie potwierdzona w kolejnych analizach, może to oznaczać wzrost skuteczności kradzieży danych nawet w środowiskach korzystających z nowocześniejszych zabezpieczeń przeglądarkowych.
Operatorzy kampanii nie koncentrowali się na trwałości infekcji. Malware nie budował rozbudowanych mechanizmów persistence, lecz skupiał się na maksymalizacji kradzieży danych podczas pojedynczego uruchomienia. Jednocześnie ograniczone mechanizmy antyanalityczne i pozostawianie artefaktów w katalogach tymczasowych mogą ułatwiać dochodzenie powłamaniowe oraz analizę DFIR.
Konsekwencje / ryzyko
Największe ryzyko dotyczy użytkowników pobierających oprogramowanie z niezweryfikowanych repozytoriów, zwłaszcza gdy szukają darmowych wersji narzędzi komercyjnych lub niszowych aplikacji. Skuteczna infekcja może prowadzić do przejęcia kont firmowych, skrzynek pocztowych, kont deweloperskich, portfeli kryptowalutowych i sesji w komunikatorach.
W organizacjach skutki wtórne mogą być znacznie poważniejsze. Skradzione cookies i tokeny sesyjne mogą umożliwić obejście części mechanizmów MFA. Przejęcie kont deweloperskich zwiększa ryzyko dalszych ataków na łańcuch dostaw, a wyciek danych z menedżera poświadczeń systemowych może wspierać ruch boczny oraz eskalację uprawnień. Dodatkowym problemem pozostaje to, że kampanie wykorzystujące znane marki i zaufane platformy hostingowe są trudniejsze do rozpoznania przez użytkowników końcowych.
Rekomendacje
Organizacje powinny wdrożyć politykę pobierania oprogramowania wyłącznie z autoryzowanych źródeł oraz ograniczyć możliwość uruchamiania niezatwierdzonych plików binarnych. Sama edukacja użytkowników nie wystarczy, jeśli nie towarzyszą jej kontrole techniczne i monitoring zachowań procesów.
- Egzekwować allowlisting aplikacji oraz kontrolę ładowania bibliotek DLL.
- Monitorować uruchomienia legalnych aktualizatorów z katalogów tymczasowych i rozpakowanych archiwów ZIP.
- Rozbudować detekcję o reguły YARA, IOC oraz telemetrię EDR związaną z iniekcją kodu do procesów przeglądarek.
- Analizować ruch wychodzący do podejrzanych serwerów C2 i korelować go z aktywnością archiwizerów, przeglądarek oraz procesów aktualizacyjnych.
- Weryfikować autora repozytorium, historię projektu i autentyczność publikowanych wydań.
- Unikać pobierania darmowych kopii narzędzi premium z nieoficjalnych źródeł.
- Sprawdzać podpisy cyfrowe i sumy kontrolne pobieranych plików.
- Zachować ostrożność wobec stron pobierania z agresywnym brandingiem i fałszywymi oznakami zaufania.
W przypadku podejrzenia infekcji zalecane jest natychmiastowe odizolowanie hosta, zabezpieczenie artefaktów z katalogów tymczasowych, reset poświadczeń, rotacja tokenów dostępowych oraz przegląd aktywności kont w usługach chmurowych, komunikatorach i portfelach kryptowalutowych.
Podsumowanie
Kampania wykorzystująca niemal 300 fałszywych repozytoriów GitHub pokazuje, że skuteczny atak nie zawsze wymaga zaawansowanego exploitu. Wystarczy wiarygodne podszycie się pod znane projekty, powtarzalna infrastruktura dystrybucji i technika DLL sideloading, aby uruchomić infostealera i przejąć cenne dane użytkownika.
Dla firm i zespołów bezpieczeństwa to kolejny dowód, że ochrona przed zagrożeniami musi obejmować zarówno kontrolę źródeł pobierania oprogramowania, jak i monitorowanie zachowań procesów, sesji oraz dostępu do danych uwierzytelniających. Zaufanie do znanej platformy nie może zastępować weryfikacji autentyczności konkretnego projektu.
Źródła
- BleepingComputer – Nearly 300 GitHub repos pose as legit software to push malware — https://www.bleepingcomputer.com/news/security/nearly-300-github-repos-pose-as-legit-software-to-push-malware/
- Arctic Wolf – Threat report and technical findings on the impersonation campaign — https://arcticwolf.com/resources/blog/fake-github-repos-deliver-boryptgrab/
- GitHub – About GitHub Pages and repository hosting model — https://docs.github.com/en/pages