14 zainfekowanych pakietów npm rozprowadza backdoora RedC2 4.0 dla Linuksa z komponentem AI - Security Bez Tabu

14 zainfekowanych pakietów npm rozprowadza backdoora RedC2 4.0 dla Linuksa z komponentem AI

Cybersecurity news

Wprowadzenie do problemu

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających i utrzymujących aplikacje. Najnowszy przypadek dotyczy 14 spreparowanych pakietów npm, które podszywają się pod niegroźne biblioteki pomocnicze, a w rzeczywistości instalują ukryty implant dla systemów Linux.

Szczególny niepokój budzi powiązanie kampanii z frameworkiem RedC2 4.0. To narzędzie command-and-control, które poza klasycznymi funkcjami zdalnej kontroli oferuje także warstwę wspieraną przez AI, ułatwiającą operatorom prowadzenie działań po uzyskaniu dostępu do systemu.

W skrócie

  • Wykryto 14 trojanizowanych pakietów npm udających narzędzia pomocnicze.
  • Złośliwy kod uruchamia się już podczas załadowania modułu, bez użycia skryptów instalacyjnych.
  • Ładunek wdraża linuksowy beacon RedShell powiązany z RedC2 4.0.
  • Malware umożliwia rekonesans, kradzież danych, trwałość, tunelowanie i ruch boczny.
  • Dodatkowa warstwa AI upraszcza obsługę frameworka i może przyspieszać operacje intruza.

Kontekst i historia

Ekosystem npm od lat jest atrakcyjnym celem dla cyberprzestępców. Wynika to z ogromnej liczby pakietów, złożonych zależności pośrednich oraz powszechnej automatyzacji procesów build, testów i wdrożeń. Nawet niewielka biblioteka może zostać nieświadomie wciągnięta do projektu i uruchomiona w środowisku deweloperskim lub produkcyjnym.

W opisywanej kampanii złośliwe pakiety zostały nazwane w sposób sugerujący nieszkodliwe funkcje związane z obliczeniami, cache, mapowaniem czy metrykami. To dobrze znana technika kamuflażu, której celem jest ograniczenie podejrzeń i wydłużenie czasu obecności zagrożenia w repozytoriach oraz projektach ofiar.

Incydent wpisuje się również w szerszy trend profesjonalizacji narzędzi ofensywnych. RedC2 4.0 jest przedstawiany jako wieloplatformowy framework przeznaczony dla systemów Windows, macOS i Linux, a jego najnowsza wersja rozszerza możliwości operatorów o elementy automatyzacji wspierane przez model językowy.

Analiza techniczna

Najbardziej niebezpieczny aspekt kampanii to sposób aktywacji ładunku. Złośliwa logika została osadzona bezpośrednio w pliku wejściowym modułu, który jednocześnie realizuje deklarowaną funkcję biblioteki i pełni rolę loadera. Dzięki temu pakiety nie muszą używać skryptów postinstall ani preinstall, które są częściej monitorowane przez narzędzia bezpieczeństwa.

W praktyce oznacza to, że wystarczy pojedynczy import modułu, również pośredni w drzewie zależności, aby doszło do uruchomienia złośliwego kodu. Po załadowaniu pakiet lokalizuje dołączony plik binarny, nadaje mu uprawnienia wykonywalne i uruchamia go jako proces działający w tle.

Według ustaleń badaczy binaria były ukrywane między innymi w katalogach dist/ lub dist/internal/, pod nazwami sugerującymi komponenty obliczeniowe. Taki sposób ukrycia dodatkowo utrudnia wykrycie, ponieważ pliki mogą wyglądać jak legalne elementy natywnej akceleracji biblioteki.

Po uruchomieniu implant wdraża linuksowego beacona RedShell dla RedC2 4.0. Malware zbiera podstawowe informacje o hoście, nawiązuje połączenie z infrastrukturą C2, rejestruje zainfekowany system i przechodzi do pętli przetwarzania poleceń operatora.

Zakres możliwości RedShell jest szeroki i obejmuje:

  • interaktywną powłokę opartą o /bin/sh,
  • operacje na plikach i zdalne wykonywanie poleceń,
  • rekonesans hosta i sieci,
  • kradzież danych i poświadczeń, w tym kluczy SSH,
  • utrzymywanie trwałości w systemie,
  • proxy SOCKS5, tunelowanie i pivoting sieciowy,
  • uruchamianie dodatkowych ładunków w pamięci.

Na poziomie operacyjnym wyróżnia się komponent AI określany jako Red Agent. Jego zadaniem jest tłumaczenie poleceń w języku naturalnym na zestawy akcji wykonywanych przez beacon. Taki model obniża próg wejścia dla mniej doświadczonych operatorów i może przyspieszać realizację wieloetapowych działań po przełamaniu zabezpieczeń.

Konsekwencje i ryzyko

Ryzyko dla organizacji jest znaczące, ponieważ kompromitacja może nastąpić już na etapie developmentu, testów lub budowy artefaktów. Co istotne, nie trzeba ręcznie uruchamiać dodatkowych funkcji inicjalizacyjnych. Samo zaimportowanie modułu może wystarczyć do wdrożenia implantu.

Szczególnie zagrożone są środowiska linuksowe, stacje robocze programistów, kontenery buildowe oraz pipeline’y CI/CD, które automatycznie pobierają i analizują zależności. Jeśli złośliwy pakiet trafi do projektu jako zależność przejściowa, organizacja może nie mieć świadomości, że jej środowisko zostało już naruszone.

Z perspektywy obronnej nie jest to wyłącznie problem pojedynczego malware. To połączenie ataku supply chain, skutecznego kamuflażu i nowoczesnego frameworka C2 z elementami automatyzacji AI. W praktyce oznacza to krótszy czas do kompromitacji, większą elastyczność intruza i wyższe ryzyko ruchu bocznego w sieci.

Rekomendacje

Organizacje powinny potraktować wykrycie któregokolwiek z opisanych pakietów jako potencjalny incydent bezpieczeństwa. Niezbędny jest przegląd repozytoriów, plików lock, cache menedżerów pakietów oraz środowisk CI/CD.

  • Wdrożyć wewnętrzny rejestr lub proxy dla npm i blokować niezatwierdzone pakiety.
  • Stosować allowlistę zależności oraz formalny przegląd nowych bibliotek.
  • Skanować katalogi dist/ i podobne pod kątem niespodziewanych binariów wykonywalnych.
  • Monitorować uruchamianie procesów potomnych przez Node.js i narzędzia buildowe.
  • Analizować moduły pod kątem efektów ubocznych wykonywanych podczas ładowania.
  • Izolować pipeline’y i ograniczać ruch wychodzący z runnerów CI.
  • Stosować zasadę najmniejszych uprawnień dla kont deweloperskich i automatyzacji.

Jeżeli obecność złośliwego pakietu zostanie potwierdzona, warto podjąć następujące kroki:

  • odizolować host od sieci,
  • zabezpieczyć pamięć i artefakty do analizy śledczej,
  • sprawdzić historię procesów i połączeń wychodzących,
  • przeprowadzić rotację kluczy SSH, tokenów API i innych sekretów,
  • zweryfikować możliwość ruchu bocznego,
  • odbudować środowisko z czystych i zaufanych źródeł.

Długoterminowo kluczowe pozostaje wdrożenie praktyk Software Supply Chain Security, w tym SBOM, podpisywania artefaktów, kontroli pochodzenia pakietów, segmentacji środowisk oraz detekcji anomalii w zależnościach.

Podsumowanie

Kampania z wykorzystaniem 14 trojanizowanych pakietów npm pokazuje, że zagrożenia dla łańcucha dostaw stają się coraz bardziej wyrafinowane. Połączenie działających bibliotek, ukrytego loadera, binarnego implantu dla Linuksa oraz frameworka RedC2 4.0 z warstwą AI znacząco podnosi poziom ryzyka dla organizacji korzystających z otwartego oprogramowania.

Dla zespołów bezpieczeństwa, AppSec i DevSecOps to wyraźny sygnał, że kontrola zależności nie może ograniczać się do reputacji pakietu i skanowania skryptów instalacyjnych. Coraz większe znaczenie ma obserwacja zachowania modułów podczas ładowania, analiza dołączonych binariów oraz ścisła kontrola całego cyklu życia komponentów open source.

Źródła