Wprowadzenie do problemu / definicja zjawiska
Badacze bezpieczeństwa odkryli szeroko zakrojoną kampanię spamowo-szkodliwą w ekosystemie npm, w której opublikowano dziesiątki tysięcy paczek zawierających samoreplikujący się kod („robaka”), masowo generujący i publikujący nowe, losowo nazwane pakiety. Incydent jest przypisywany operatorowi posługującemu się językiem indonezyjskim i bywa określany jako „IndonesianFoods” lub „Big Red”. Celem nie jest klasyczne wykradanie sekretów, ale zalew rejestru tysiącami artefaktów i nadużycie infrastruktury (w tym możliwa monetyzacja przez ekosystem tea.xyz).
W skrócie
- Skala: od ~44–80 tys. i więcej złośliwych paczek, wykrytych na dziesiątkach kont npm. Nazwy generowane z list słów (przymiotniki/zwierzęta/kolory) oraz słowników z indonezyjskimi imionami i potrawami.
- Mechanizm: prosty skrypt (Node.js) modyfikuje package.json/package-lock.json, usuwa private: true, nadaje losową wersję i publikuje kolejne paczki w pętli (co kilka sekund).
- Wektory nadużycia: ponowne użycie zapisanych poświadczeń npm ofiary; możliwy cel: nagrody/„reputacja” w tea.xyz, SEO/pozycjonowanie lub „próba generalna” przed realnym ładunkiem.
- Ryzyko: zanieczyszczenie wyników wyszukiwania, wzrost prawdopodobieństwa przypadkowej instalacji i zatrucie łańcucha dostaw (w CI/CD).
Kontekst / historia / powiązania
Kampania trwa co najmniej od 2023/2024 r., ewoluując od zwykłego spamu do robakopodobnej automatyzacji w 2025 r. (auto-publikacja i szybkie replikowanie). Część obserwacji wiąże aktywność z mechanizmami punktacji/nagród tea.xyz, co tłumaczy presję na masę i widoczność. Niezależne raporty (SecurityWeek, SourceCodeRed, JFrog) różnią się liczbami (43–80 tys.+), ale są spójne co do automatycznej pętli publikacji i słowników nazw. Dodatkowe doniesienia prasowe wskazują na 67–100 tys. paczek w miarę trwania sprzątania i nowej publikacji.
Analiza techniczna / szczegóły
1) Generowanie metadanych i nazwy
- Warianty wykorzystują m.in. bibliotekę unique-names-generator oraz własne słowniki (imiona/potrawy/adjektywy/zwierzęta/kolory), np. annoyed_raccoon_z3n albo indah-ketoprak73-riris.
2) „Odblokowanie” publikacji
- Skrypt usuwa pole private: true z package.json, aby erzac-projekt Next.js stał się publicznie publikowalny: let packageData = JSON.parse(fs.readFileSync("package.json")); if (packageData.private === true) { delete packageData.private; } // wersja i nazwa nadawane losowo… exec("npm publish --access public", cb); (fragmenty logiczne opisane w analizie JFrog).
3) Samoreplikacja i tempo
- Po publikacji skrypt czeka losowy krótki czas i uruchamia cykl od nowa. W praktyce nowe paczki pojawiają się co ~7 sekund, aż do limitów lub błędów 429 (rate-limit).
4) Poświadczenia npm
- Pętla używa zapisanych tokenów/npmrc użytkownika (prawdopodobnie na zainfekowanej maszynie) do publikacji pod jego kontem. To nie jest „kradzież sekretów na zewnątrz”, tylko nadużycie już obecnych uprawnień.
5) IoC i artefakty
- JFrog publikuje sumy SHA-256 plików autopublikujących i listę obserwowanych kont npm; pojawiają się też adresy powiązane z tea.xyz w plikach konfiguracyjnych (tea.yaml). Warto wzbogacić skanery o te artefakty.
Praktyczne konsekwencje / ryzyko
- Zatrucie łańcucha dostaw (SDLC/CI/CD): łatwiej o pomyłkową instalację paczki „o normalnym wyglądzie”, szczególnie przy luźnych constraintach wersji (^, ~) i braku blokad wersji.
- Noise & discovery risk: zespoły SCA/SAST/DevSecOps dostają tysiące „śmieciowych” trafień, co utrudnia triage i może ukryć prawdziwe ataki.
- Eskalacja scenariusza: ta sama infrastruktura może być „przełączona” na realny ładunek (np. infostealer, crypto-theft), a nie jedynie spam—JFrog wskazuje taki wariant jako prawdopodobny „dry run”.
Rekomendacje operacyjne / co zrobić teraz
Poniżej zestaw działań do wdrożenia od razu, od punktów krytycznych po „twardnienie” procesu.
A. Reagowanie i hunting
- Zablokuj i odśwież tokeny npm (szczególnie na maszynach buildowych):
- Przegląd ostatnich publikacji pod Twoją nazwą/npm org (czy „ktoś” nie publikował śmieci w Twoim imieniu):
- Skanuj lockfile i node_modules pod wzorce nazw ze słowników (adjectives/animals/colors, indonezyjskie imiona/potrawy) i znane IoC (hash’e z raportu JFrog). Przykładowy skrypt huntujący w repo:
(doposaż bazę IoC o hash’e i konta z raportu JFrog).
- Wymuś „allow-listy” w prywatnym mirrorze/proxy rejestru (Artifactory/Nexus/JFrog/Frog Curation, Sonatype Firewall): odrzuć publikacje z nowych, niesprawdzonych kont i paczki pasujące do wzorców nazw. (JFrog deklaruje, iż dodał te paczki do katalogu złośliwych).
B. Higiena zależności i buildów
- Twarde pinowanie wersji + blokady (package-lock.json, pnpm-lock.yaml, yarn.lock) oraz „frozen-lockfile” w CI: npm ci --ignore-scripts # lub pnpm install --frozen-lockfile yarn install --frozen-lockfile
- Wyłącz npm install ze „skryptami” (--ignore-scripts) w środowiskach build/test, o ile to możliwe.
- Provenance i podpisy: egzekwuj npm provenance/Sigstore, SBOM (CycloneDX/SPDX) oraz polityki „only-allow”: npx only-allow pnpm # przykład wymuszenia jednego menedżera
- Segmentacja uprawnień: tokeny npm z zakresem tylko do odczytu w CI; publikacja z osobnych, minimalnych runnerów; tajemnice w dedykowanych OIDC+STS zamiast statycznych tokenów.
- Alerting na anomalie publikacji: jeżeli Twój zespół publikuje biblioteki na npm—dodaj reguły UEBA: „więcej niż N publikacji w 1h”, „nowa paczka z nieznanej przestrzeni nazw”, „nieznany maintainer”.
C. Blokada znanych kont/nazw
W firewallu rejestru/SCA skonfiguruj deny-listę kont i prefiksów nazw z raportów (np. veylatea, użytkownicy z list JFrog/SourceCodeRed), oraz reguły detekcji tea.yaml/*_publish*.js.
Różnice / porównania z innymi przypadkami (wrzesień 2025: „Shai-Hulud”)
- Cel i ładunek:
- IndonesianFoods/Big Red – głównie spam i samoreplikacja; brak bezpośredniego exfiltracji sekretów w payloadzie.
- Shai-Hulud (IX–X 2025) – kradzież sekretów/poświadczeń, trojanizacja istniejących popularnych paczek (np. @ctrl/tinycolor), masowe modyfikacje package.json, wstrzykiwanie skryptów, re-publikacja pod kompromitowanymi maintainerami.
- Wejście do ekosystemu:
- IndonesianFoods – tworzenie nowych tysięcy paczek-wydmuszek.
- Shai-Hulud – przejęcie istniejących paczek o dużym zasięgu.
- Ryzyko krótkoterminowe:
- IndonesianFoods – ryzyko przypadkowej instalacji i zanieczyszczenia supply chain.
- Shai-Hulud – natychmiastowe ryzyko wycieku sekretów i eskalacji w CI/CD.
Podsumowanie / najważniejsze wnioski
- Mamy do czynienia z przemysłową automatyzacją produkcji paczek npm: prosta logika, ale duża skala i ciągła replikacja.
- Nawet jeżeli obecny ładunek w „IndonesianFoods/Big Red” nie kradnie danych, ten sam pipeline może w dowolnym momencie przerzucić się na realne malware.
- Obrona to kombinacja: twarde pinowanie + „frozen” instalacje + ignore-scripts w CI, podpisy/provenance, allow-listy/deny-listy w repozytoriach pośredniczących, segmentacja tokenów i monitoring anomalii publikacji.
Źródła / bibliografia
- SecurityWeek — „Tens of Thousands of Malicious NPM Packages Distribute Self-Replicating Worm” (13 listopada 2025). (SecurityWeek)
- JFrog Security Research — „Big Red – Indonesian-based Self-replicating Malicious Spam Campaign detected in npm” (11 listopada 2025) — analiza techniczna, IoC. (research.jfrog.com)
- SourceCodeRed — „‘IndonesianFoods’ worm publishes more than 78,000 malicious NPM packages” — pierwsze odkrycia, tempo publikacji, słowniki nazw. (sourcecodered.com)
- BleepingComputer — „New ‘IndonesianFoods’ worm floods npm with 100,000 packages” — tło czasowe 2023–2025 i wątek TEA. (BleepingComputer)
- CISA / Sysdig — materiały porównawcze nt. kampanii „Shai-Hulud” (wrzesień 2025) — inny typ celu (exfiltracja sekretów). (CISA)
