Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Rosnąca popularność ekosystemu Go sprawia, że cyberprzestępcy coraz częściej wykorzystują zaufanie programistów do publicznych repozytoriów i modułów open source. Najnowsza ujawniona operacja pokazuje, że złośliwe kampanie nie ograniczają się już do pojedynczych paczek, lecz przyjmują formę rozbudowanych, zautomatyzowanych sieci repozytoriów, które mają wyglądać na wiarygodne, aktywnie rozwijane i bezpieczne do uruchomienia.
W skrócie
Badacze zidentyfikowali 222 repozytoria GitHub powiązane z operacją określaną jako „Muck and Load”. Kampania wykorzystywała fałszywe pakiety Go i pozornie legalne projekty programistyczne do dostarczania loaderów, infostealerów, zdalnych trojanów dostępowych oraz koparek kryptowalut.
- Atak objął 190 kont i 222 potwierdzone repozytoria.
- Repozytoria imitowały aktywne projekty open source.
- Łańcuch infekcji wykorzystywał wieloetapowe ładowanie PowerShell.
- Publiczne serwisy służyły jako pośrednicy do ukrywania właściwych adresów payloadów.
Kontekst / historia
Punktem wyjścia śledztwa był pojedynczy złośliwy moduł Go podszywający się pod narzędzie do skanowania DNS i subdomen. Dalsza analiza wykazała jednak znacznie szerszą infrastrukturę, której celem było skłonienie ofiary do sklonowania kodu, kompilacji lub uruchomienia instrukcji instalacyjnych.
Ten schemat wpisuje się w rosnący trend nadużyć w łańcuchu dostaw oprogramowania, szczególnie w środowiskach open source. Wabiki były dobierane tak, aby przyciągać użytkowników zainteresowanych narzędziami kryptowalutowymi, integracjami portfeli, botami Telegram, cheatami do gier, crypterami czy automatyzacją działań ofensywnych.
Analiza techniczna
Jednym z kluczowych przykładów był moduł, którego opis sugerował legalne działanie związane ze skanowaniem subdomen. W praktyce przed wykonaniem jakiejkolwiek deklarowanej funkcji kod uruchamiał ukryte polecenie PowerShell. Skrypt pobierał zawartość z zewnętrznej infrastruktury, zapisywał ją lokalnie, dekodował przy użyciu narzędzi systemowych, a następnie wykonywał z pominięciem polityki wykonywania skryptów i w ukrytym oknie.
Łańcuch infekcji był wieloetapowy i obejmował użycie kodowania Base64 oraz odszyfrowywania XOR w celu utrudnienia analizy. Zamiast wpisywać końcowy adres payloadu bezpośrednio do kodu, loader pobierał dane z publicznie dostępnych serwisów i wyszukiwał w nich znacznik prowadzący do zaszyfrowanej lokalizacji kolejnego etapu. Taki model dead drop resolver utrudnia detekcję i pozwala operatorom łatwo podmieniać infrastrukturę bez modyfikacji samego loadera.
Po odszyfrowaniu adresu docelowego malware pobierał archiwum chronione hasłem, rozpakowywał je przy pomocy dostarczonego binarium 7-Zip i umieszczał pliki w katalogu nazwanym tak, aby przypominał legalną ścieżkę komponentów Microsoftu. Następnie uruchamiany był główny plik wykonywalny w ukrytym trybie.
Analiza wykazała również obecność technik typowych dla środowisk post-exploitation, w tym:
- modyfikacji ustawień Microsoft Defender i UAC,
- mechanizmów persistence opartych o zadania harmonogramu i usługi,
- dostępu do danych przeglądarek,
- przygotowania do przechwytywania zrzutów ekranu.
Badacze zaobserwowali także oznaki użycia rodzin malware i narzędzi pokrewnych do AsyncRAT, Quasar, Remcos, Vidar oraz XMRig. W części przypadków payloady były hostowane bezpośrednio w repozytoriach lub publikowane jako zasoby wydań. Jednym z ważnych wskaźników kampanii był wspólny wzorzec workflow GitHub Actions: częste automatyczne commity, force-push, sztucznie aktualizowane znaczniki czasu oraz stały adres e-mail operatora przy zmiennych nazwach użytkowników commitów.
Konsekwencje / ryzyko
Z perspektywy bezpieczeństwa jest to klasyczny przykład kompromitacji łańcucha dostaw na poziomie repozytorium i zależności deweloperskich. Największe ryzyko dotyczy programistów, zespołów DevOps, badaczy bezpieczeństwa oraz użytkowników pobierających niszowe narzędzia z niezweryfikowanych źródeł.
Skutki udanej infekcji mogą obejmować kradzież poświadczeń, przejęcie sesji przeglądarkowych, zdalny dostęp do stacji roboczej, osadzenie mechanizmów trwałości, wyłączenie części zabezpieczeń oraz wykorzystanie hosta do dalszych działań intruzyjnych. W środowisku korporacyjnym pojedyncza kompromitacja stacji deweloperskiej może prowadzić do eskalacji uprawnień, wycieku sekretów CI/CD, dostępu do repozytoriów prywatnych i nadużycia zaufanych kanałów wdrożeniowych.
Dodatkowym zagrożeniem jest skala i automatyzacja. Duża liczba repozytoriów, powtarzalne nazewnictwo i sztuczna aktywność utrudniają manualną ocenę wiarygodności projektu. To oznacza, że tradycyjne kryteria typu „repozytorium wygląda aktywnie” lub „ma wiele commitów” przestają być wystarczające.
Rekomendacje
Organizacje powinny wdrożyć kontrolę ryzyka dla oprogramowania open source na poziomie procesu, narzędzi i polityk operacyjnych.
- Ograniczyć uruchamianie niezweryfikowanych projektów z publicznych repozytoriów na stacjach mających dostęp do zasobów firmowych.
- Testować obcy kod w środowiskach izolowanych, najlepiej jednorazowych i bez dostępu do wrażliwych poświadczeń.
- Wdrożyć monitorowanie zależności i skanowanie kodu pod kątem wywołań powłoki systemowej, pobierania zdalnych skryptów, użycia PowerShell i obfuskacji.
- Analizować metadane repozytoriów, w tym historię commitów, workflow CI oraz wzorce publikacji.
- Stosować zasady minimalnych uprawnień, segmentację dostępu do repozytoriów i ochronę sekretów w pipeline’ach CI/CD.
- Wymagać EDR na stacjach roboczych programistów oraz alarmować przy próbach użycia ukrytego PowerShell i ExecutionPolicy Bypass.
Istotne jest również rozwijanie procedur weryfikacji projektów open source przed dopuszczeniem ich do użycia. Obejmuje to przegląd autora, historii commitów, powiązanych kont, reputacji maintainerów oraz analizę tego, czy projekt faktycznie realizuje deklarowaną funkcję bez zbędnych działań ubocznych.
Podsumowanie
Operacja „Muck and Load” pokazuje, że współczesne kampanie malware coraz skuteczniej imitują prawdziwy ekosystem open source. Atakujący nie polegają wyłącznie na złośliwym kodzie, lecz łączą automatyzację repozytoriów, fałszywą aktywność developerską, wielowarstwowe loadery i publiczne usługi pośredniczące, aby zwiększyć wiarygodność oraz utrudnić wykrycie.
Dla obrońców najważniejszy wniosek jest prosty: zaufanie do repozytorium nie może wynikać wyłącznie z jego wyglądu, liczby commitów czy opisu README. W praktyce konieczna jest behawioralna analiza kodu, walidacja metadanych projektu oraz ścisła kontrola sposobu, w jaki zespoły deweloperskie pobierają i uruchamiają zewnętrzne komponenty.
Źródła
- Security Affairs — https://securityaffairs.com/195101/security/222-github-repositories-linked-to-fake-go-package-malware-operation.html
- Socket Research — https://socket.dev/blog/category/research
- Sophos News — The strange tale of ischhfd83: When cybercriminals eat their own — https://www.sophos.com/zh-cn/blog/the-strange-tale-of-ischhfd83-when-cybercriminals-eat-their-own
- Go Security Policy — https://go.dev/doc/security/policy
- Go Modules Reference — https://go.dev/ref/mod