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, lecz 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, usuwaprivate: 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-generatororaz własne słowniki (imiona/potrawy/adjektywy/zwierzęta/kolory), np.annoyed_raccoon_z3nalboindah-ketoprak73-riris.
2) „Odblokowanie” publikacji
- Skrypt usuwa pole
private: truezpackage.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):
# pokaż aktualne tokeny
npm token list
# unieważnij podejrzany token (wstaw ID)
npm token revoke <token-id>
# wymuś 2FA dla publikacji
npm profile enable-2fa auth-and-writes- Przegląd ostatnich publikacji pod Twoją nazwą/npm org (czy „ktoś” nie publikował śmieci w Twoim imieniu):
# szybki podgląd zmian w Twojej organizacji przez API npm
curl -s "https://registry.npmjs.org/-/org/<twoja-org>/package?format=json" | jq '.'- 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:
# szukaj podejrzanych nazw w package-lock.json / pnpm-lock.yaml / yarn.lock
grep -E -i "(rendang|ketoprak|sambel|nasi|goreng|_z3n|meadowlark|raccoon)" \
package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
# weryfikuj SHA plików autopublikujących, jeśli występują
shasum -a 256 **/auto.js **/publishScript.js **/index.js 2>/dev/null(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, że 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 installze „skryptami” (--ignore-scripts) w środowiskach build/test, jeżeli 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śli 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 / kluczowe wnioski
- Mamy do czynienia z przemysłową automatyzacją produkcji paczek npm: prosta logika, ale duża skala i ciągła replikacja.
- Nawet jeśli 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)
