Shai-Hulud v2: od npm do Maven. Druga fala kampanii ujawnia tysiące sekretów i uderza w CI/CD

Wprowadzenie do problemu / definicja luki

Druga fala kampanii Shai-Hulud (v2) to szeroko zakrojony atak na łańcuch dostaw oprogramowania, który rozpoczął się w ekosystemie npm i – poprzez mechanizmy mirroringu – przelał się do Maven Central (artefakt org.mvnpm:posthog-node:4.18.1). Celem jest kradzież sekretów (tokenów GitHub, kluczy chmurowych AWS/GCP/Azure, webhooków itp.) oraz dalsza replikacja przez zainfekowane konta maintainerów i joby CI/CD. Wektor obejmuje trojanizowane wydania popularnych bibliotek oraz nadużycie przepływów GitHub Actions.

---

W skrócie

• Skala: skompromitowano setki (800+) pakietów npm i odsłonięto tysiące sekretów publicznie na GitHubie; odnotowano również pojedynczy, zwierciadlany artefakt w Maven Central (mvnpm). Mirror został usunięty przez zespół Maven Central.
• Nowości w v2: loader w Bun (pliki setup_bun.js + 10-MB bun_environment.js), tryb bezszelestny podczas instalacji, podniesienie limitu replikacji i agresywniejsze zbieranie sekretów (TruffleHog + API chmurowe).
• Wejście do organizacji: kompromitacja przepływów GitHub Actions (m.in. niebezpieczne użycie pull_request_target i workflow_run) oraz przejęte konta wydawnicze npm; potwierdzone studium przypadku opublikował PostHog.
• Wpływ: dziesiątki tysięcy repozytoriów naruszonych pośrednio przez wyciek sekretów; tysiące nadal były ważne w momencie analizy.

---

Kontekst / historia / powiązania

Pierwszy wariant Shai-Hulud z września 2025 r. uderzył w npm i wyciekał sekrety, ale obecna „druga nadchodzi” (The Second Coming) znacząco rozszerza zarówno zasięg, jak i arsenał technik (Bun, stealth, worm-like spread). The Hacker News opisuje również efekt domina – przejście z npm do Maven Central przez automatyczny most mvnpm, który przebudowuje paczki npm na artefakty Mavena; skompromitowany mirror usunięto, a dostawca wdraża dodatkowe zabezpieczenia przed rebundlowaniem znanych złych wersji.

---

Analiza techniczna / szczegóły luki

1. Łańcuch infekcji w npm
   • Do package.json dodawany jest skrypt preinstall, który uruchamia setup_bun.js.
   • Loader instaluje/odnajduje runtime Bun, a następnie cicho uruchamia spakowany i zaciemniony bun_environment.js, tłumiąc wyjście i zwracając kontrolę, aby instalacja wyglądała „normalnie”.
2. Zbieranie informacji i sekretów
   • Enumeracja środowiska (OS/arch/hostname, zmienne środowiskowe, detekcja CI).
   • Masowe pozyskiwanie sekretów: TruffleHog (skan całego $HOME), enumeracja AWS Secrets Manager, GCP Secret Manager i Azure Key Vault; zbieranie tokenów GITHUB_TOKEN, NPM_TOKEN itd.
3. C2 i „samouzdrawianie”
   • Malware wyszukuje na GitHubie frazę-znacznik „Sha1-Hulud: The Second Coming.” i potrafi odzyskać uprzednio wykradzione tokeny z repozytoriów, by kontynuować eksfiltrację.
4. Eskalacja w GitHub Actions
   • Na runnerach Linux podejmowane są próby uzyskania root (np. manipulacja sudoers, reset zasad iptables/DNS), co umożliwia m.in. blokadę skanerów i MITM w CI.
5. Wejście przez CI/CD i konta wydawnicze
   • PostHog szczegółowo opisał, jak napastnik wykorzystał podatną konfigurację pull_request_target w workflow, by wykonać kod z PR i wykraść PAT bota, a następnie tokeny wydawnicze npm, co pozwoliło opublikować zainfekowane wersje SDK.
6. Przelew do Maven
   • Zidentyfikowano org.mvnpm:posthog-node:4.18.1 z tym samym ładunkiem Bun; zespół Maven Central potwierdził usunięcie mirrorów i prace nad dodatkowymi barierami.
7. Skala wycieku sekretów
   • GitGuardian raportuje 11 858 unikalnych sekretów znalezionych w 4 645 repozytoriach, z czego 2 298 było nadal ważnych w dniu 24 listopada 2025 r.

---

Praktyczne konsekwencje / ryzyko

• Natychmiastowe przejęcie łańcucha dostaw: publikacja trojanizowanych wydań skutkuje kompromitacją tysięcy downstream projektów, które instalują zależności automatycznie (CI/CD).
• Utrata poufności i integralności środowisk: wyciek tokenów GitHub/npm/chmury = możliwość pushowania złośliwych commitów, eskalacji w chmurze, lateral movement.
• Trudna detekcja: payload wykonuje się poza Node (Bun), tłumi I/O i może modyfikować sieć na runnerach CI, utrudniając telemetrię i skanowanie.
• Ryzyko „worm-like” replikacji: jeden kompromitowany maintainer lub runner może szybko zwielokrotnić zasięg ataku.

---

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (D+0):

1. Zatrzymaj buildy dla repo z podejrzanymi zależnościami; w CI włącz tryb „no-scripts” (npm ci --ignore-scripts, pnpm 10 ma domyślnie wyłączone lifecycle scripts).
2. Wymuś rotację wszystkich sekretów: GITHUB_TOKEN, PAT-y, klucze npm, chmury (AWS/GCP/Azure), webhooki, itp. Użyj secret scanningu.
3. Wyczyść cache i node_modules oraz przypnij wersje do znanych-dobrych:
   rm -rf node_modules && npm cache clean --force && pnpm cache delete, następnie reinstalacja.
4. Szukaj artefaktów malware lokalnie (setup_bun.js, bun_environment.js, truffleSecrets.json, environment.json, cloud.json, contents.json).

W horyzoncie 72h:

5. Przejrzyj i utwardź GitHub Actions:
   • unikaj pull_request_target chyba że naprawdę konieczne;
   • nie uruchamiaj kodu z PR bez sandboxu;
   • włącz required reviews dla zmian w .github/workflows/*;
   • ogranicz uprawnienia tokenów (permissions: read-all, per-job GITHUB_TOKEN);
   • izoluj runnerów self-hosted;
   • egzekwuj MFA i trusted publishing dla npm.
6. Monitoruj wyciek sekretów w orgu – skany historii/artefaktów CI i publicznych repo (np. narzędziami klasy GitGuardian lub własnymi regułami).
7. Wprowadź opóźnienie publikacji/aktualizacji zależności – minimumReleaseAge (np. 72h) w yarn/pnpm, aby nie pobierać „świeżych” kompromitowanych wersji.
8. SBOM + atestacja łańcucha dostaw – podpisy pakietów, SLSA/SCM policy enforcement, blokowanie skryptów instalacyjnych w CI domyślnie. (Wniosek syntetyczny na bazie powyższych analiz).

---

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Wobec września 2025 r.: v2 zwiększa skalę (setki pakietów vs. dziesiątki), używa Bun do ukrycia logiki i automatyzuje eksfiltrację z chmur; do tego samoleczenie przez wyszukiwanie frazy sygnatury na GitHubie.
• Na tle innych kampanii npm: podobnie jak wcześniejsze supply-chainy, ale rzadkie jest tak głębokie „CI-aware” zachowanie (eskalacja na runnerach, manipulacja DNS/iptables).
• „Przelew” do innych ekosystemów: unikalny aspekt to automatyczne rebundlowanie paczek npm do Mavena (mvnpm), co stworzyło ryzyko cross-ecosystem – na szczęście mirror szybko usunięto.

---

Podsumowanie / kluczowe wnioski

Shai-Hulud v2 pokazuje, że nawet bez 0-dayów atakujący potrafią wykorzystać luki operacyjne: błędne konfiguracje GitHub Actions, słabe praktyki zarządzania sekretami i zaufanie do lifecycle scripts w instalatorach. Krytyczne jest wprowadzenie kontroli publikacji, ograniczenia uprawnień tokenów, domyślne wyłączenie skryptów w CI oraz opóźnienie aktualizacji zależności. Dane z monitoringu wycieków i analizy incydentu (PostHog) potwierdzają, że to atak na procesy, nie tylko na kod.

---

Źródła / bibliografia

1. The Hacker News – podsumowanie i wątek Maven/mvnpm. (The Hacker News)
2. Socket Research – analiza techniczna v2, czasy reakcji Maven Central, lista artefaktów/podejrzanych technik. (Socket)
3. PostHog – oficjalny post-mortem (wejście przez pull_request_target, timeline, zalecenia). (PostHog)
4. GitGuardian – statystyki wycieków sekretów (11 858 unikalnych, 2 298 ważnych). (blog.gitguardian.com)
5. Aikido – wnioski o nadużyciu istniejących workflowów Actions w projektach AsyncAPI/PostHog/Postman. (Aikido)