Wprowadzenie do problemu / definicja
Otwarte repozytoria kodu są dziś jednym z podstawowych źródeł narzędzi wykorzystywanych przez administratorów, analityków i specjalistów bezpieczeństwa. Ten sam model zaufania, który napędza rozwój społeczności open source, bywa jednak wykorzystywany przez cyberprzestępców. Najnowsza kampania pokazuje, że pozornie przydatne projekty publikowane na GitHubie mogą w rzeczywistości zawierać mechanizmy instalujące backdoory, stealery informacji oraz komponenty zapewniające trwały dostęp do systemu.
To szczególnie niebezpieczny scenariusz, ponieważ ofiara nie pobiera pliku z oczywiście podejrzanego źródła, lecz uruchamia narzędzie wyglądające jak pomocny projekt techniczny. W efekcie granica między legalnym oprogramowaniem a złośliwą przynętą staje się coraz trudniejsza do wychwycenia bez dokładnej analizy.
W skrócie
Badacze opisali kampanię wykorzystującą fałszywe narzędzia związane z analizą logów, skanowaniem sieci i testami bezpieczeństwa. Złośliwe repozytoria zawierały ukryty kod w projektach Visual Studio, skryptach Pythona oraz źródłach Go, a uruchomienie lub kompilacja takich projektów inicjowały wieloetapowy łańcuch infekcji.
- infekcja rozpoczynała się od ukrytego kodu w repozytorium,
- następnie pobierany był loader odpowiedzialny za persystencję i obchodzenie zabezpieczeń,
- końcowe ładunki obejmowały AsyncRAT, clippera kryptowalutowego i infostealera,
- według badaczy skompromitowanych zostało ponad 2 tysiące systemów Windows.
Kontekst / historia
Kampania nie od początku była skierowana do środowiska cyberbezpieczeństwa. Wcześniejsze przynęty dotyczyły gier blockchain, botów oraz narzędzi typu cheat, co sugeruje, że operatorzy początkowo celowali w użytkowników zainteresowanych kryptowalutami i gamingiem. Z czasem taktyka została zmieniona, a atakujący zaczęli wykorzystywać wiarygodność projektów przedstawianych jako użyteczne narzędzia administracyjne i bezpieczeństwa.
Taka zmiana profilu ofiar jest logiczna z perspektywy napastników. Specjaliści SOC, pentesterzy, deweloperzy i administratorzy regularnie pobierają małe skrypty oraz projekty z publicznych repozytoriów, by przyspieszyć analizę lub automatyzację codziennej pracy. W praktyce właśnie ten nawyk operacyjny stał się punktem wejścia dla kampanii.
Analiza techniczna
Jednym z przykładów był fałszywy skrypt promowany jako lekkie narzędzie do parsowania i porządkowania wyników ze skanera Fscan. Kluczowym elementem całej operacji było ukrywanie złośliwej logiki wewnątrz plików, które na pierwszy rzut oka wyglądały legalnie. Badacze wskazali między innymi na maskowanie kodu za pomocą długich ciągów pustych znaków, co utrudniało jego ręczne wykrycie.
W części repozytoriów wykorzystano mechanizm pre-build event w projektach Visual Studio. Oznacza to, że złośliwy kod mógł zostać wykonany jeszcze przed właściwą kompilacją. Z punktu widzenia bezpieczeństwa jest to szczególnie groźne, ponieważ sama próba zbudowania projektu mogła prowadzić do uruchomienia malware.
Dalszy etap opierał się na PowerShellu, który pobierał zaszyfrowany odnośnik do kolejnego komponentu. Następnie pobierany był modularny loader oparty na Electronie, identyfikowany jako „Microsoft.exe”. Po uruchomieniu odpowiadał on za ustanowienie persystencji, podniesienie uprawnień, osłabienie zabezpieczeń Windows oraz wdrożenie kolejnych ładunków przez wstrzykiwanie ich do legalnych procesów.
Loader stosował także techniki utrudniające detekcję. Należały do nich manipulowanie drzewem procesów, aby explorer.exe wyglądał na proces nadrzędny, modyfikacje rejestru w celu wyłączenia Smart App Control, przywracanie oryginalnej wersji ntdll.dll z dysku w celu usunięcia hooków narzędzi ochronnych, używanie bezpośrednich wywołań systemowych oraz modyfikacje w pamięci funkcji odpowiedzialnych za telemetrykę i skanowanie skryptów. Tego typu działania mają zmniejszyć widoczność aktywności malware dla EDR, AV i systemów analitycznych.
Jeżeli podstawowy wariant nie działał prawidłowo, malware przechodziło do ścieżki alternatywnej. W tym scenariuszu dodawane były wyjątki do Microsoft Defendera, a następnie skrypt PowerShell odszyfrowywał i wstrzykiwał ładunki do procesu RegAsm.exe. Jest to klasyczny przykład techniki living-off-the-land, polegającej na ukrywaniu złośliwych działań za legalnymi komponentami systemowymi.
Końcowe payloady obejmowały kilka klas zagrożeń:
- AsyncRAT zapewniający zdalny dostęp do hosta,
- clipper monitorujący schowek i podmieniający adresy portfeli kryptowalut,
- infostealer kradnący dane z przeglądarek, konfiguracje VPN, pliki klientów FTP, dane kont graczy i tokeny Discorda.
Wykradzione informacje miały być eksfiltrowane za pośrednictwem bota Telegram. Badacze odnotowali również próby zakłócania działania wybranych produktów bezpieczeństwa, w tym rozwiązań firm ESET, McAfee i Malwarebytes, a także ingerencję w mechanizmy odzyskiwania systemu i kopii zapasowych. Znaleziono ponadto ślady niedokończonego komponentu, który mógłby służyć do ponownego pobrania loadera po jego usunięciu.
Konsekwencje / ryzyko
Największe zagrożenie w tej kampanii wynika z połączenia wiarygodnej socjotechniki z dojrzałymi technikami obchodzenia zabezpieczeń. Ofiara uruchamia bowiem narzędzie, które wygląda jak zwykły projekt open source, a nie klasyczny trojan pobrany z podejrzanej strony. To znacząco zwiększa skuteczność ataku, zwłaszcza w środowiskach technicznych.
- przejęcie stacji roboczej administratora, analityka lub dewelopera,
- kradzież poświadczeń, tokenów i konfiguracji dostępowych,
- utrata środków przez podmianę adresów portfeli kryptowalut,
- wykorzystanie zainfekowanego hosta jako punktu wejścia do infrastruktury firmowej,
- osłabienie zdolności detekcyjnych wskutek modyfikacji zabezpieczeń Windows.
Ryzyko jest jeszcze większe wtedy, gdy ofiara posiada podwyższone uprawnienia, dostęp do VPN, repozytoriów wewnętrznych, systemów administracyjnych lub danych klientów. W takim przypadku lokalne uruchomienie fałszywego narzędzia może szybko przerodzić się w incydent obejmujący znacznie szerszy fragment środowiska.
Rekomendacje
Organizacje powinny traktować publiczne repozytoria jako źródło podwyższonego ryzyka, nawet jeżeli zawierają narzędzia przeznaczone dla specjalistów bezpieczeństwa. Zaufanie do projektu nie powinno wynikać wyłącznie z jego opisu lub pozornego zastosowania.
- testować zewnętrzny kod wyłącznie w środowiskach izolowanych,
- analizować pliki projektowe, skrypty build oraz zdarzenia pre-build i post-build przed kompilacją,
- blokować lub ściśle monitorować PowerShell, RegAsm.exe oraz nietypowe łańcuchy uruchamiania procesów,
- monitorować zmiany w ustawieniach Smart App Control, Defendera i innych funkcji ochronnych Windows,
- wykrywać modyfikacje mechanizmów ETW i AMSI w pamięci procesów,
- szukać w repozytoriach ukrytego kodu, obfuskacji i nietypowych odstępów w plikach źródłowych,
- stosować EDR z regułami behawioralnymi dla wstrzykiwania kodu, persystencji i manipulacji zabezpieczeniami,
- ograniczać lokalne uprawnienia administratora na stacjach roboczych użytkowników technicznych,
- regularnie rotować sekrety, tokeny i poświadczenia przechowywane w przeglądarkach oraz narzędziach deweloperskich,
- szkolić zespoły, że narzędzie z GitHuba nie jest automatycznie oprogramowaniem zaufanym.
W przypadku podejrzenia kompromitacji należy niezwłocznie odizolować host, zabezpieczyć artefakty pamięci i telemetrii, przeanalizować historię uruchomień PowerShella, sprawdzić wyjątki Defendera oraz oznaki persystencji i wstrzykiwania kodu do procesów systemowych. Konieczna jest też szybka zmiana wszystkich poświadczeń, które mogły być dostępne na zainfekowanej stacji.
Podsumowanie
Opisana kampania pokazuje, że cyberprzestępcy skutecznie dostosowują przynęty do nowych grup ofiar i coraz śmielej wykorzystują zaufanie do ekosystemu open source. Fałszywe narzędzia bezpieczeństwa publikowane na GitHubie mogą prowadzić do infekcji obejmującej backdoora, moduły kradnące dane oraz mechanizmy utrudniające wykrycie i usunięcie zagrożenia.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że weryfikacja zewnętrznych narzędzi powinna być równie rygorystyczna jak analiza klasycznych próbek malware. Sam fakt, że projekt wygląda użytecznie i jest dostępny w publicznym repozytorium, nie może już być traktowany jako wystarczający wskaźnik zaufania.
Źródła
- Fake security tools on GitHub push backdoors and infostealers — https://www.bleepingcomputer.com/news/security/fake-security-tools-on-github-push-backdoors-and-infostealers/
- Dr.Web: Cybercriminals distribute trojanized projects via GitHub repositories — https://news.drweb.com/show/?i=15058