Wprowadzenie do problemu / definicja
Kampanie malware ukrywające złośliwy kod w repozytoriach programistycznych stają się coraz poważniejszym zagrożeniem dla firm i użytkowników indywidualnych. W tym przypadku atakujący publikowali na GitHubie projekty podszywające się pod narzędzia bezpieczeństwa, automatyzacji skanowania i analizy logów, a następnie infekowali komputery osób, które uruchamiały pobrany kod.
To szczególnie niebezpieczny model ataku, ponieważ wykorzystuje zaufanie do popularnej platformy deweloperskiej oraz naturalną skłonność specjalistów IT do testowania nowych narzędzi. Skala kampanii, obejmująca ponad 2 tys. urządzeń, pokazuje, że ryzyko dotyczy już nie tylko mniej doświadczonych użytkowników, ale także osób pracujących technicznie.
W skrócie
- Złośliwe repozytoria zawierały projekty Visual Studio oraz pliki Python i Go z ukrytym kodem uruchamiającym infekcję.
- Po uruchomieniu projektu aktywowany był skrypt PowerShell pobierający kolejne komponenty malware.
- Łańcuch infekcji obejmował backdoora AsyncRAT, clippera podmieniającego adresy portfeli oraz stealer kradnący dane z wielu aplikacji.
- Atakujący stosowali techniki omijania detekcji, wyłączania zabezpieczeń i utrzymania trwałości w systemie.
- Kampania ewoluowała od przynęt związanych z kryptowalutami do narzędzi kierowanych także do specjalistów cyberbezpieczeństwa.
Kontekst / historia
Pierwsze zainfekowane repozytoria miały pojawić się około dwa lata wcześniej i były powiązane z projektami dotyczącymi gier blockchain, botów oraz cheatów. Taki dobór przynęt nie był przypadkowy, ponieważ użytkownicy podobnych narzędzi często korzystają z portfeli kryptowalutowych i przechowują cenne dane uwierzytelniające.
Z czasem operatorzy kampanii rozszerzyli repertuar i zaczęli podszywać się pod oprogramowanie używane przez specjalistów bezpieczeństwa. To istotna zmiana jakościowa, ponieważ oznacza przejście od ataków na użytkowników końcowych do prób kompromitacji środowisk technicznych, w których można przejąć poświadczenia, tokeny, konfiguracje administracyjne i dostęp do infrastruktury firmowej.
Analiza techniczna
W warstwie technicznej kampania wykorzystywała kilka metod ukrywania i uruchamiania złośliwego kodu. W projektach Visual Studio szkodliwe polecenia osadzano między innymi w plikach .csproj, korzystając z mechanizmów wykonywanych przed kompilacją, a także w plikach .suo, gdzie umieszczano komendy PowerShell. W nowszych wariantach złośliwy kod trafiał również do plików źródłowych Python i Go, często maskowany dużą liczbą białych znaków w celu utrudnienia analizy.
Po otwarciu projektu i uruchomieniu odpowiedniego procesu startował skrypt PowerShell, który kontaktował się z infrastrukturą przestępców oraz z legalnymi usługami internetowymi pełniącymi rolę pośrednich nośników konfiguracji. Następnie pobierany był zaszyfrowany ciąg danych, z którego malware odszyfrowywał adres kolejnego archiwum i rozpakowywał je do katalogu imitującego komponent systemowy Windows.
Kluczowym elementem infekcji był plik Microsoft.exe, zbudowany z użyciem frameworka Electron. Odpowiadał on za większość działań po infekcji, w tym rozpoznanie systemu, utrzymanie trwałości, eskalację uprawnień oraz wyłączanie mechanizmów ochronnych. Malware próbował dezaktywować Windows Defender, UAC, Przywracanie systemu i kopie woluminów w tle, a także dodawał własne wykluczenia w ustawieniach ochrony.
Badacze wskazali również na zestaw technik unikania detekcji charakterystycznych dla bardziej zaawansowanych loaderów. Wśród nich znalazły się spoofing procesu nadrzędnego, obchodzenie Smart App Control, odhaczanie hooków z ntdll.dll, bezpośrednie wywołania syscalli oraz poprawki w pamięci wyłączające ETW i AMSI. Takie podejście utrudnia wykrycie aktywności przez rozwiązania EDR i klasyczne mechanizmy telemetryczne systemu.
Po skutecznym uruchomieniu infekcja wdrażała trzy główne ładunki:
- AsyncRAT – zapewniający zdalny dostęp do zainfekowanego urządzenia.
- Clipper – monitorujący schowek i podmieniający adresy portfeli kryptowalutowych, a także wykonujący zrzuty ekranu.
- Stealer – kradnący dane z przeglądarek, klientów VPN, komunikatorów i narzędzi administracyjnych.
Zakres wykradanych informacji był szeroki i obejmował między innymi konfiguracje FileZilla, MobaXterm i Total Commandera, dane kont growych, tokeny Discorda oraz inne poufne artefakty. Zebrane dane były kompresowane i przesyłane operatorom za pośrednictwem bota Telegram. W kodzie znaleziono także ślady dalszego rozwoju kampanii, sugerujące przygotowania do wdrożenia mechanizmów automatycznej reinstalacji i aktualizacji malware.
Konsekwencje / ryzyko
Ryzyko związane z tą kampanią jest wysokie, ponieważ punktem wejścia staje się zaufane środowisko pracy dewelopera, administratora lub analityka bezpieczeństwa. Użytkownicy techniczni często pracują na kontach z podwyższonymi uprawnieniami i mają dostęp do systemów wewnętrznych, sekretów, tokenów API czy narzędzi zdalnej administracji.
W praktyce skutki infekcji mogą obejmować kradzież poświadczeń, przejęcie sesji, utratę kryptowalut, wyciek konfiguracji dostępowych oraz dalszy ruch boczny w sieci organizacji. Dodatkowym problemem jest wyłączanie lokalnych zabezpieczeń i modyfikacja ustawień systemowych, co utrudnia wykrycie incydentu oraz skraca czas potrzebny przestępcom na eksfiltrację danych.
Rekomendacje
Organizacje powinny traktować zewnętrzne repozytoria kodu jako źródła nieufne, nawet jeśli projekty deklarują funkcje związane z bezpieczeństwem. Kod proof-of-concept, narzędzia ofensywne, skrypty automatyzujące i niezweryfikowane projekty open source powinny być uruchamiane wyłącznie w środowiskach izolowanych, takich jak maszyny wirtualne, sandboxy lub wydzielone hosty testowe.
- Monitorować nietypowe użycie PowerShell i uruchomienia z niestandardowych katalogów.
- Wykrywać zmiany w konfiguracji Defendera, UAC, ETW, AMSI i pliku
hosts. - Egzekwować zasadę najmniejszych uprawnień oraz stosować allowlisting aplikacji.
- Analizować statycznie i reputacyjnie repozytoria przed ich użyciem w środowisku pracy.
- Regularnie rotować tokeny, klucze API i poświadczenia po kontakcie z niezweryfikowanym kodem.
- Zwracać uwagę na podejrzane procesy Electron uruchamiane poza standardowymi ścieżkami.
Użytkownicy indywidualni również powinni zachować ostrożność. Sam fakt obecności projektu na popularnej platformie nie oznacza, że jest on bezpieczny. Przed uruchomieniem warto sprawdzić autora, historię commitów, reputację repozytorium, zawartość plików build i skryptów, a także przeskanować pobierane artefakty.
Podsumowanie
Opisana kampania pokazuje, jak skutecznie cyberprzestępcy łączą socjotechnikę z zaawansowanym łańcuchem infekcji i technikami omijania zabezpieczeń. Fałszywe narzędzia publikowane na GitHubie mogą prowadzić nie tylko do kradzieży danych i środków finansowych, ale również do kompromitacji środowisk technicznych o wysokiej wartości operacyjnej.
Najważniejszy wniosek jest prosty: każde zewnętrzne repozytorium należy traktować jak potencjalny wektor ataku. W realiach współczesnych zagrożeń kontrola nad tym, jaki kod jest pobierany, budowany i uruchamiany, staje się jednym z podstawowych elementów cyberhigieny organizacji.