Amazon łączy atak na debug i chalk z Koreą Północną

30 lipca 2026 roku pojawiła się nowa analiza atrybucji kompromitacji popularnych pakietów npm debug i chalk z września 2025 roku. Amazon Threat Intelligence ocenił z umiarkowaną pewnością, że za tym incydentem, kompromitacją axios z marca 2026 oraz wcześniejszym pakietem typo-crypto stał ten sam aktor powiązany z Koreą Północną.

Ta wiadomość nie oznacza nowej kompromitacji debug ani chalk. Zmieniła się ocena sprawcy i szerszego wzorca kampanii. Zakres technicznej reakcji na stare złośliwe wersje pozostaje związany z mechanizmem konkretnego incydentu, a nie z nazwą grupy.

Co dokładnie stwierdził Amazon

W publikacji AWS Security Blog z 29 lipca Amazon połączył:

• typo-crypto z marca 2025;
• przejęcie debug i chalk z września 2025;
• kompromitację axios z marca 2026.

Firma wskazała wspólne TTP, trojanizowane pakiety, użycie skryptów poinstalacyjnych w części kampanii, ponowne wykorzystanie kodu oraz nakładanie wskaźników C2. Na tej podstawie oceniła z umiarkowaną pewnością, że działania prowadził aktor znany pod nazwami Sapphire Sleet, Stardust Chollima, BlueNoroff, CageyChameleon i Alluring Pisces.

Nazwy pochodzą od różnych dostawców i nie zawsze oznaczają idealnie ten sam zbiór aktywności. Najbezpieczniej pisać o aktorze powiązanym z DPRK, którego klastry częściowo się pokrywają.

Analiza z 30 lipca zwróciła uwagę, że Amazon opublikował ograniczony materiał dowodowy. Post wymienia klasy podobieństw, ale nie rozpisuje szczegółowo, który IOC łączy każdy incydent z każdym pozostałym. Atrybucja jest więc oceną wywiadowczą o umiarkowanej pewności, nie matematycznym dowodem.

Co wydarzyło się w debug i chalk

We wrześniu 2025 roku napastnik wyłudził dostęp od maintenera przez stronę podszywającą się pod npm. Następnie złośliwy kod trafił do co najmniej 18 pakietów. Ich łączna popularność przekraczała dwa miliardy pobrań tygodniowo, ale liczba pobrań nie jest równa liczbie zainfekowanych urządzeń ani poszkodowanych organizacji.

Payload działał po stronie przeglądarki. Przechwytywał wywołania fetch, XMLHttpRequest i interfejsy portfeli kryptowalutowych, aby podmieniać adres docelowy transakcji przed jej podpisaniem. Nie tworzył klasycznej trwałości na hoście.

Ten mechanizm ma dwie ważne konsekwencje:

1. złośliwe zachowanie nie zależało od postinstall;
2. kod mógł trafić do bundle’a frontendowego i działać u końcowego użytkownika długo po zbudowaniu aplikacji.

Blokowanie skryptów instalacyjnych nie wystarczało. Należało usunąć skażone wersje z lockfile’ów, cache, CDN, artefaktów webowych, obrazów i wdrożonych aplikacji.

axios używał innego mechanizmu

Kompromitacja axios z marca 2026 wykorzystywała skrypt cyklu życia npm i instalowała backdoor WAVESHAPER.V2. Google przypisał ten incydent UNC1069, a Microsoft Sapphire Sleet, wskazując na nakładanie z innymi nazwami grupy.

To istotne wsparcie dla atrybucji samego axios, ale nie automatyczny dowód dla debug i chalk. Łańcuchy różniły się sposobem wykonania:

• axios — kod uruchamiany podczas instalacji;
• debug/chalk — kod w bundle’u, działający przy użyciu aplikacji;
• typo-crypto — funkcja oczekująca określonego triggera.

Wspólny operator może używać różnych technik. Różnica techniczna oznacza jednak, że detekcja i zakres reakcji muszą być dopasowane do każdego przypadku.

typo-crypto jako możliwy test

Amazon znalazł trojanizowany plik core.js w pakiecie typo-crypto opublikowanym w marcu 2025 roku. Nazwa pakietu, opis i słowa kluczowe podszywały się pod popularny crypto-js, a nazwa pliku sugerowała związek z innym legalnym projektem core-js.

Złośliwa funkcja uruchamiała się dopiero po otrzymaniu wartości hasha zaczynającej się od 0098273. Następnie pobierała drugi etap dopasowany do Windows, macOS albo Linux. Kod używał Base64 oraz XOR z kluczem 01042025.

Amazon podał wskaźniki:

• domenę npmjs[.]store;
• adres 216[.]74[.]123[.]126;
• wpis OSV MAL-2026-3400;
• nazwę pakietu i pliku core.js.

Firma ocenia małą liczbę pobrań jako możliwe pole testowe przed głośniejszymi kampaniami. To ocena, nie potwierdzone oświadczenie operatora.

Niespójność wokół sposobu przejęcia

Amazon opisuje wspólny playbook: socjotechnika wobec zaufanego maintenera, a potem złośliwa aktualizacja. Dane rejestru typo-crypto przytoczone 30 lipca pokazują jednak tylko jedną wersję — 4.3.0 — opublikowaną jako pierwsze wydanie pakietu. Konto publikujące nie odpowiadało autorowi wpisanemu w metadanych.

Taki zapis bardziej przypomina pakiet podszywający się pod legalny projekt od pierwszej publikacji niż aktualizację wcześniej uczciwego pakietu. Rejestr nie pokazuje, jak konto zostało uzyskane, ale nie zawiera wcześniejszej czystej wersji.

To nie obala szerszej atrybucji. Pokazuje, że streszczenie „każdy incydent zaczął się tak samo” jest zbyt szerokie dla publicznie dostępnych danych.

Wskaźniki i błędnie opisane hashe

Analiza z 30 lipca wskazała też rozbieżność między hashami podanymi w poście Amazona a zawartością tarballa serwowanego przez rejestr. Hash opisany jako pakiet mógł w rzeczywistości dotyczyć pliku, a hash wskazany jako core.js nie został znaleziony w pobranym artefakcie.

Możliwe wyjaśnienia obejmują błędną etykietę, inną kopię próbki albo późniejszą zmianę artefaktu. Bez wyjaśnienia producenta nie należy używać jednego hasha jako jedynego kryterium zamknięcia incydentu.

Weryfikacja powinna łączyć:

• nazwę i dokładną wersję;
• integralność z lockfile’a;
• zawartość tarballa;
• kod core.js;
• wartości triggera i klucza;
• domenę i adres sieciowy;
• zachowanie procesu lub aplikacji.

Pakiet nadal dostępny nie znaczy automatycznie uruchomiony

Według sprawdzenia z 30 lipca [email protected] nadal było dostępne w rejestrze. Nie deklarowało skryptu instalacyjnego, więc samo pobranie nie uruchamiało opisanego kodu.

To rozróżnienie jest ważne:

• obecność w cache lub lockfile potwierdza artefakt;
• załadowanie pakietu potwierdza możliwość wykonania jego kodu;
• spełnienie triggera uruchamiało złośliwą ścieżkę;
• ruch i procesy mogą potwierdzić dalsze etapy.

Nie należy ignorować pakietu tylko dlatego, że trigger wydaje się specyficzny. Nie wolno też twierdzić, że każda instalacja została przejęta.

Co zmieniło npm 12

npm 12, wydany 8 lipca, domyślnie wyłącza skrypty cyklu życia zależności. To ważna ochrona przed wariantem wykorzystującym postinstall, takim jak opisywany łańcuch axios.

Nie zamyka:

• kodu wykonywanego przy imporcie;
• złośliwego bundle’a przeglądarkowego;
• przejęcia konta maintenera;
• zależności pobierającej zewnętrzne dane w runtime;
• pakietu aktywowanego przez określone wejście;
• ręcznego włączenia skryptów przez projekt.

28 lipca npm rozpoczął skanowanie nowo publikowanych pakietów przed ich udostępnieniem do instalacji. Kontrola dotyczy nowych publikacji, nie jest retroaktywnym dowodem bezpieczeństwa całego rejestru i może mieć problem z funkcją rozbitą na kilka pozornie niewinnych pakietów.

Nowe wzorce ataków na pakiety

Amazon opisuje ewolucję, którą zespoły powinny uwzględnić w threat modelu:

• fragmentacja — blob, deszyfrator i downloader trafiają do różnych pakietów;
• długie budowanie zaufania — maintainer publikuje użyteczne wersje przed atakiem;
• oddzielenie kodu od zachowania — pakiet pobiera sterowanie z zewnętrznego zasobu;
• szyfrowanie runtime — klucz pochodzi z kontekstu lub serwera;
• unikanie sandboxa — wykonanie zależy od sygnałów prawdziwego środowiska.

Skanowanie pojedynczego tarballa nie zobaczy zachowania ujawniającego się dopiero w grafie zależności i aktywnym środowisku.

Jak sprawdzić środowisko

Przeszukaj:

• package-lock.json, yarn.lock i pnpm-lock.yaml;
• SBOM historycznych wydań;
• cache npm oraz firmowe proxy;
• artefakty frontendowe i mapy źródeł;
• obrazy kontenerowe;
• statyczne zasoby w CDN;
• logi CI i tokeny maintainerów;
• ruch do IOC oraz nietypowe hooki portfela.

Dla debug i chalk przegląd backendowego kontenera może być niewystarczający, jeśli payload znalazł się w JavaScript dostarczanym klientom. Trzeba sprawdzić, które wersje bundle’ów były aktywne i przez jaki czas.

Plan reakcji

1. zidentyfikuj dokładne złośliwe wersje z oficjalnych advisory;
2. zatrzymaj promocję zależnych buildów;
3. usuń artefakty z proxy, cache, CDN i obrazów;
4. odbuduj z czystego lockfile’a i zweryfikowanych źródeł;
5. przejrzyj tokeny npm, Git i CI związane z publikacją;
6. sprawdź integralność frontendów i aplikacji;
7. przeanalizuj transakcje oraz logi, jeśli aplikacja obsługiwała portfel;
8. zachowaj dowody i rozdziel pobranie od wykonania;
9. monitoruj konta i infrastrukturę przez okres po odbudowie.

Kompromitacja maintenera wymaga również zabezpieczenia procesu publikacji: phishing-resistant MFA, krótkotrwałych tokenów, trusted publishing, dwóch osób przy wydaniu krytycznego pakietu i alertów na zmianę właściciela.

Atrybucja nie może sterować containmentem

Informacja o DPRK pomaga łączyć kampanie, przewidywać motyw finansowy i wzbogacać IOC. Nie zmienia jednak pierwszych działań: usuń złośliwą wersję, ustal wykonanie, wymień poświadczenia w zasięgu i zweryfikuj artefakty.

W raporcie warto zapisać:

• fakt — konkretna wersja zawierała określony kod;
• obserwację — infrastruktura albo fragment kodu się pokrywa;
• ocenę — Amazon przypisuje kampanie z umiarkowaną pewnością;
• niepewność — publiczny materiał nie mapuje każdego dowodu do każdego incydentu.

Taką dyscyplinę rozwijamy w przewodniku po cyklu Cyber Threat Intelligence.

Jak udowodnić, że nowy build jest czysty

Odbudowa nie daje pewności, jeśli używa tego samego cache, proxy albo obrazu bazowego. Czysty proces powinien zaczynać się od zatwierdzonego lockfile’a, pustej pamięci podręcznej i rejestru lub proxy, które przechowuje dokładnie zweryfikowane artefakty. Po instalacji trzeba porównać graf zależności, hashe tarballi, wynik SBOM oraz zawartość finalnego bundle’a z oczekiwanym stanem.

Dla aplikacji frontendowej dowodem jest nie tylko brak złośliwej wersji w node_modules. Należy potwierdzić, że stary JavaScript zniknął z CDN, service workerów, obrazów kontenerowych i cache przeglądarek. Jeżeli kod mógł działać w kontekście portfela, trzeba osobno ocenić transakcje i zgody użytkowników z okresu ekspozycji.

Warto przechowywać atestację pochodzenia wydania: commit, tożsamość workflow, listę zależności, skrót artefaktu i środowisko budujące. Taki zapis nie blokuje przejęcia maintenera, ale skraca odpowiedź na pytanie, gdzie złośliwa wersja rzeczywiście trafiła. Kryterium zamknięcia brzmi więc „brak złośliwego kodu w każdym aktywnym artefakcie”, a nie tylko „npm install pokazuje już bezpieczną wersję”.

Źródła a wnioski Breachroad

Amazon potwierdza swoją ocenę DPRK, powiązane pakiety, MAL-2026-3400, technikę typo-crypto i trendy ataków. Aikido i Wiz wcześniej opisały techniczny wpływ debug i chalk, a Google oraz Microsoft przypisały axios. Rozbieżności w rejestrze i hashach pochodzą z niezależnej analizy opublikowanej 30 lipca.

Zalecenia dotyczące zakresu bundle’ów, poziomów pewności i kolejności reakcji są wnioskami Breachroad. Więcej podstaw znajdziesz w materiale o atakach na łańcuch dostaw oprogramowania oraz analizie TeamPCP i złośliwych zależności.

Szkolenia cyberbezpieczeństwa dla zespołów deweloperskich pomagają rozpoznać przejęcie maintenera i bezpiecznie eskalować incydent, a audyt bezpieczeństwa IT może objąć CI/CD, proxy pakietów, SBOM, sekrety i proces publikacji.