14 zainfekowanych pakietów npm rozprzestrzenia backdoora RedC2 4.0 dla Linuksa

Wprowadzenie do problemu / definicja

Ekosystem npm od lat pozostaje atrakcyjnym celem ataków na łańcuch dostaw oprogramowania. Najnowszy incydent dotyczy 14 trojanizowanych pakietów, które podszywały się pod użyteczne biblioteki narzędziowe, a w rzeczywistości uruchamiały natywny implant dla systemów Linux powiązany z frameworkiem RedC2 4.0.

To, co wyróżnia tę kampanię, to sposób aktywacji złośliwego kodu. Mechanizm nie korzysta z typowych skryptów instalacyjnych, lecz uruchamia się już w momencie importu modułu, co znacząco utrudnia wykrycie i omija część standardowych kontroli bezpieczeństwa.

W skrócie

Wykryto 14 zainfekowanych pakietów npm udających legalne biblioteki.
Złośliwy kod aktywował się podczas importu modułu, a nie w fazie instalacji.
Pakiety dostarczały linuksowy beacon RedShell będący częścią RedC2 4.0.
Implant umożliwiał zdalne wykonywanie poleceń, transfer plików i dalszą eksploatację hosta.
Dodatkowym zagrożeniem była warstwa C2 wspierana przez AI, upraszczająca obsługę frameworka.

Kontekst / historia

Ataki na rejestry open source coraz częściej wykorzystują zaufanie deweloperów do popularnych menedżerów zależności. W przeszłości dominowały kampanie bazujące na skryptach preinstall i postinstall, jednak obecny przypadek pokazuje wyraźne przesunięcie w kierunku bardziej dyskretnych metod wykonania.

Analizowane pakiety były przedstawiane jako niewielkie biblioteki wspierające obliczenia, metryki oraz operacje kalendarzowe. Co istotne, faktycznie realizowały deklarowane funkcje, dzięki czemu nie wzbudzały natychmiastowych podejrzeń. Złośliwy komponent ukryto pod postacią rzekomego natywnego akceleratora, co zwiększało wiarygodność całego pakietu.

Sam RedC2 4.0 jest rozbudowanym frameworkiem command-and-control przeznaczonym dla wielu platform, w tym Windows, macOS i Linux. W tej kampanii kluczową rolę odegrał wariant RedShell dla Linuksa, umożliwiający przejęcie kontroli nad zainfekowanym hostem i dalsze działania poeksploatacyjne.

Analiza techniczna

Najważniejszym elementem kampanii był mechanizm wykonania ładunku. Złośliwa logika została umieszczona w pliku wejściowym modułu, na przykład w dist/index.mjs. Po załadowaniu biblioteki skrypt odnajdywał dołączony plik binarny, nadawał mu uprawnienia wykonywania i uruchamiał go jako odłączony proces działający w tle.

Taka technika daje atakującym kilka przewag. Po pierwsze, omija zabezpieczenia skupione wyłącznie na blokowaniu skryptów instalacyjnych. Po drugie, infekcja może uruchomić się również wtedy, gdy pakiet pojawia się wyłącznie jako zależność przechodnia. Po trzecie, biblioteka nadal działa zgodnie z opisem, co utrudnia wykrycie podczas podstawowych testów funkcjonalnych.

Osadzone binaria występowały pod nazwami takimi jak math-core.bin, math-calc.bin, calc.bin czy calc-cache.bin i były umieszczane w katalogach dist/ lub dist/internal/. Niezależnie od nazwy pełniły tę samą funkcję: uruchamiały linuksowy beacon RedShell.

Po starcie implant zbierał podstawowe informacje o systemie, rejestrował host na serwerze C2, a następnie przechodził do pętli odbioru poleceń. Operator mógł wykonywać komendy systemowe przez /bin/sh, zarządzać plikami, prowadzić rozpoznanie hosta i sieci, pobierać dane, uruchamiać kolejne ładunki oraz zestawiać mechanizmy proxy i pivotingu.

Dodatkowo RedC2 4.0 oferuje funkcje wykraczające poza prosty zdalny shell. Obejmują one operacje wieloetapowe, obsługę wielu beaconów, transfer plików, ładowanie dodatkowych payloadów oraz wykonywanie kodu bez trwałego zapisu na dysk. Warstwa wspierana przez model językowy może z kolei upraszczać tłumaczenie poleceń w języku naturalnym na konkretne działania w środowisku C2.

Konsekwencje / ryzyko

Skala ryzyka jest szczególnie wysoka dla środowisk CI/CD, serwerów buildowych i stacji roboczych programistów. W odróżnieniu od klasycznych kampanii opartych o skrypty instalacyjne, tutaj kompromitacja może nastąpić dopiero przy pierwszym załadowaniu biblioteki, co utrudnia powiązanie zdarzenia z konkretną zależnością.

zdalne wykonywanie poleceń na hostach Linux,
kradzież danych uwierzytelniających i kluczy SSH,
pobieranie kolejnych ładunków i etapowe rozwijanie infekcji,
wykorzystanie hosta do pivotingu w sieci wewnętrznej,
kompromitację pipeline’ów deweloperskich i artefaktów budowania.

Szczególnie niebezpieczne jest połączenie legalnej funkcjonalności pakietów ze złośliwym komponentem. Takie biblioteki są trudniejsze do wykrycia zarówno metodami opartymi na reputacji, jak i prostą analizą statyczną. Kampania pokazuje też, że sama rezygnacja ze skryptów instalacyjnych nie stanowi już wystarczającej ochrony.

Rekomendacje

Organizacje korzystające z npm powinny rozszerzyć kontrole bezpieczeństwa poza sam proces instalacji i objąć nimi również etap importu oraz uruchamiania modułów.

Przeprowadzić audyt zależności i lockfile we wszystkich projektach, kontenerach i pipeline’ach CI, także pod kątem zależności przechodnich.
Analizować zachowanie bibliotek przy imporcie, zwłaszcza pod kątem wywołań systemowych takich jak chmod, spawn, exec i uruchamiania plików ELF.
Traktować osadzone binaria jako sygnał podwyższonego ryzyka, szczególnie jeśli są ukryte w folderach dist/ lub nazwane jak akceleratory obliczeń.
Uruchamiać instalację i testy w sandboxie z ograniczonym dostępem do sieci, sekretów i kluczy publikacyjnych.
Wzmocnić monitoring EDR i telemetryczny pod kątem uruchamiania procesów potomnych przez node oraz nietypowych połączeń wychodzących z narzędzi deweloperskich.
Ograniczyć zaufanie do nowych i niszowych pakietów poprzez politykę allowlisty i weryfikację historii maintainerów.
Rozszerzyć skanowanie artefaktów o analizę statyczną i behawioralną pakietów przed ich dopuszczeniem do użycia.
Przeprowadzić rotację sekretów, jeśli zainfekowane pakiety były obecne w środowiskach deweloperskich lub CI.

Podsumowanie

Incydent z 14 trojanizowanymi pakietami npm pokazuje, że ataki na łańcuch dostaw open source stają się coraz bardziej zaawansowane i trudniejsze do wykrycia. Wykorzystanie wykonania kodu na etapie importu, przy jednoczesnym zachowaniu legalnej funkcjonalności bibliotek, znacząco podnosi skuteczność takiej kampanii.

Dostarczany implant RedShell, będący częścią RedC2 4.0, zapewnia szerokie możliwości przejęcia i utrzymania kontroli nad systemami Linux. Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona ekosystemu zależności musi obejmować pełny cykl życia pakietu — od publikacji i analizy zawartości po monitorowanie zachowania podczas rzeczywistego użycia.