Fałszywe narzędzia bezpieczeństwa na GitHub infekują specjalistów backdoorem i stealerem

Wprowadzenie do problemu / definicja

Publiczne repozytoria kodu od lat wspierają rozwój narzędzi dla administratorów, programistów i zespołów bezpieczeństwa. Jednocześnie stały się atrakcyjnym kanałem dystrybucji złośliwego oprogramowania, ponieważ użytkownicy często zakładają, że projekty publikowane na popularnych platformach są wiarygodne lub przynajmniej nieszkodliwe. Najnowsza kampania pokazuje, że to założenie bywa błędne: cyberprzestępcy publikują na GitHubie fałszywe narzędzia dla specjalistów security i DevSecOps, które po uruchomieniu wdrażają wieloetapowy łańcuch infekcji.

Celem ataku nie jest wyłącznie pojedyncza stacja robocza, ale także dostęp do cennych danych, poświadczeń i środowisk, do których użytkownik ma uprawnienia. To sprawia, że incydent może szybko przerodzić się z lokalnej kompromitacji w problem obejmujący większy fragment infrastruktury organizacji.

W skrócie

Badacze opisali kampanię, w której zainfekowane repozytoria podszywają się pod praktyczne projekty wspierające analizę bezpieczeństwa, automatyzację testów i przetwarzanie logów. Według ustaleń ofiarą padło ponad 2 tysiące systemów z Windows.

• Złośliwy kod ukrywano w plikach projektowych Visual Studio, skryptach PowerShell oraz w kodzie źródłowym Python i Go.
• Infekcja prowadziła do pobrania modułowego loadera odpowiedzialnego za trwałość, obchodzenie zabezpieczeń i wdrażanie kolejnych ładunków.
• Wśród końcowych payloadów znalazły się backdoor, clipper oraz stealer informacji, w tym AsyncRAT.
• Kampania była wymierzona w osoby techniczne, które regularnie uruchamiają kod z publicznych repozytoriów.

Kontekst / historia

Opisana operacja nie pojawiła się nagle. Wcześniejsze warianty tej kampanii były kojarzone głównie z atakami na użytkowników portfeli kryptowalut, graczy oraz osoby pobierające narzędzia powiązane z oszustwami w grach i projektami blockchain. Mechanizm był podobny: atakujący publikowali atrakcyjnie opisane repozytoria, licząc na to, że ofiara samodzielnie pobierze projekt i uruchomi go lokalnie.

W nowszej fazie operatorzy zmienili jednak profil celu. Zamiast koncentrować się na użytkownikach masowych, zaczęli publikować repozytoria udające narzędzia przydatne w pracy specjalistów cyberbezpieczeństwa. To istotna ewolucja, ponieważ ofiarą staje się grupa z reguły lepiej świadoma zagrożeń, ale jednocześnie mająca kontakt z wrażliwymi danymi, sekretami dostępowymi i systemami o podwyższonych uprawnieniach.

Analiza techniczna

Łańcuch infekcji opiera się na zaufaniu do projektu i uruchomieniu go w środowisku deweloperskim lub analitycznym. Złośliwe komponenty były osadzane między innymi w plikach .csproj i .suo, a także w źródłach Python i Go. W części przypadków wykorzystywano mechanizm PreBuildEvent, dzięki któremu niebezpieczny kod uruchamiał się jeszcze przed właściwą kompilacją projektu.

Atakujący stosowali również techniki ukrywania treści, takie jak maskowanie złośliwych fragmentów przy użyciu długich sekwencji białych znaków. Dzięki temu pobieżny przegląd kodu lub plików projektu mógł nie ujawnić nieautoryzowanych poleceń.

Po aktywacji uruchamiany był skrypt PowerShell komunikujący się z infrastrukturą operatorów oraz z legalnymi serwisami wykorzystywanymi jako pośrednik do dostarczania zaszyfrowanych danych konfiguracyjnych. Następnie malware pobierało archiwum z dodatkowymi komponentami, w tym loaderem opartym na Electronie, identyfikowanym jako Microsoft.exe.

Loader pełnił centralną rolę w operacji i odpowiadał za:

• zbieranie informacji o systemie,
• ustanowienie mechanizmów trwałości,
• eskalację uprawnień,
• osłabianie funkcji bezpieczeństwa Windows,
• pobieranie i odszyfrowywanie kolejnych modułów,
• wstrzykiwanie payloadów do legalnych procesów.

Badacze zwrócili uwagę na zestaw technik utrudniających detekcję. Loader miał m.in. podszywać proces nadrzędny pod explorer.exe, modyfikować rejestr w celu wyłączenia Smart App Control, przywracać oryginalną zawartość ntdll.dll z dysku w celu usunięcia hooków bezpieczeństwa, korzystać z bezpośrednich wywołań systemowych oraz ograniczać telemetrię przez modyfikację mechanizmów ETW i AMSI.

Jeżeli podstawowy scenariusz zawodził, malware przechodziło do wariantu alternatywnego. Obejmował on dodawanie wyjątków w Microsoft Defenderze, odszyfrowywanie dalszych ładunków i ich wstrzykiwanie do procesów takich jak RegAsm.exe, dwm.exe oraz dwwin.exe.

Końcowe ładunki obejmowały kilka klas zagrożeń. AsyncRAT zapewniał zdalny dostęp do systemu, clipper monitorował schowek i podmieniał adresy portfeli kryptowalut, a stealer wykradał dane z przeglądarek, komunikatorów, klientów FTP, konfiguracji VPN, tokeny Discorda oraz inne informacje umożliwiające dalsze nadużycia. Zgromadzone dane były następnie kompresowane i eksfiltrowane do operatorów kampanii.

Konsekwencje / ryzyko

Najpoważniejszym aspektem kampanii jest profil ofiary. Jeżeli fałszywe repozytorium uruchomi analityk SOC, administrator, pentester lub inżynier DevOps, atakujący mogą uzyskać dostęp nie tylko do lokalnych danych, ale także do poświadczeń, tokenów, kluczy API i sesji prowadzących do systemów firmowych.

Potencjalne skutki obejmują:

• kradzież danych uwierzytelniających i aktywnych sesji z przeglądarek,
• przejęcie tokenów dostępowych do narzędzi organizacyjnych,
• utratę środków kryptowalutowych wskutek działania clippera,
• utrzymanie trwałej obecności atakującego w systemie,
• wykorzystanie skompromitowanej maszyny do poruszania się po sieci wewnętrznej,
• osłabienie skuteczności EDR i AV poprzez obchodzenie mechanizmów ochronnych,
• utrudnienie analizy incydentu przez manipulację telemetryką i komponentami zabezpieczeń.

Z punktu widzenia organizacji jest to klasyczny problem bezpieczeństwa łańcucha dostaw oprogramowania. Atak startuje od pozornie legalnego projektu open source, dlatego klasyczne kontrole skupione wyłącznie na załącznikach e-mail czy znanych złośliwych adresach mogą okazać się niewystarczające.

Rekomendacje

Organizacje powinny założyć, że każde niezweryfikowane repozytorium może zawierać złośliwe mechanizmy uruchamiane jeszcze przed kompilacją lub podczas pierwszego startu projektu. Potrzebne są więc zarówno kontrole prewencyjne, jak i działania detekcyjne.

• Weryfikować reputację repozytoriów, historię commitów, autorów i spójność publikowanego kodu.
• Nie uruchamiać nowych projektów open source na stacjach mających dostęp do systemów produkcyjnych lub wrażliwych sekretów.
• Analizować pliki projektowe Visual Studio, skrypty build oraz zdarzenia pre-build i post-build pod kątem nieautoryzowanych poleceń.
• Monitorować użycie PowerShell, zwłaszcza pobieranie zdalnych treści, deszyfrowanie danych i uruchamianie kodu z lokalizacji tymczasowych.
• Wdrażać detekcję prób patchowania AMSI i ETW oraz anomalii związanych z ntdll.dll i bezpośrednimi syscallami.
• Kontrolować tworzenie wyjątków w Microsoft Defenderze i blokować je, jeśli nie wynikają z autoryzowanej polityki.
• Monitorować wstrzykiwanie kodu do legalnych procesów systemowych.
• Ograniczać możliwość uruchamiania narzędzi deweloperskich z uprawnieniami administracyjnymi.
• Testować nowe narzędzia w środowiskach odseparowanych, sandboxach lub na dedykowanych maszynach laboratoryjnych.
• Regularnie rotować tokeny, sekrety i poświadczenia przechowywane na stacjach użytkowników technicznych.

W obszarze reagowania warto dodatkowo przeszukać środowisko pod kątem nietypowych archiwów, wpisów trwałości, zmian w pliku hosts, śladów aktywności procesów takich jak RegAsm.exe, dwm.exe i dwwin.exe, a także oznak eksfiltracji danych do zewnętrznych kanałów komunikacyjnych.

Podsumowanie

Opisana kampania potwierdza, że GitHub i inne publiczne repozytoria kodu są dziś pełnoprawnym polem operacji cyberprzestępczych. Atakujący nie tylko ukrywają malware w projektach wyglądających na użyteczne, ale również dostosowują tematykę repozytoriów do konkretnej grupy odbiorców. W tym przypadku celem stali się profesjonaliści cyberbezpieczeństwa, a sam łańcuch infekcji został zaprojektowany tak, by utrudniać wykrycie, omijać nowoczesne mechanizmy ochronne i kraść dane o wysokiej wartości.

Dla zespołów SOC, blue team i DevSecOps to wyraźny sygnał, że zaufanie do kodu open source musi być uzupełnione rygorystyczną walidacją, monitoringiem zachowania procesów oraz ścisłą kontrolą środowiska wykonawczego.

Źródła

1. Fake security tools on GitHub push backdoors and infostealers — https://www.bleepingcomputer.com/news/security/fake-security-tools-on-github-push-backdoors-and-infostealers/
2. Insolence beyond belief. Threat actors target information security developers on GitHub — https://news.drweb.com/show/?c=5&i=15311&lng=en