Skrypt instalacyjny łączył się z infrastrukturą kontrolowaną przez atakujących i pobierał trojana zdalnego dostępu (RAT) dopasowanego do systemu Windows, macOS lub Linuksa. Zwykła instalacja pakietu mogła więc stać się pierwszym etapem szerszej kompromitacji środowiska.

Zainfekowane wersje były dostępne przez około trzy godziny. Google Threat Intelligence Group odnotowała aktywność między 00:21 a 03:20 UTC 31 marca, a inne raporty opisują podobne, dwu- lub trzygodzinne okno. Axios jest jedną z szeroko wykorzystywanych zależności w ekosystemie JavaScriptu. Według różnych źródeł pakiet notuje od około 80 mln do ponad 100 mln pobrań tygodniowo, choć szacunki nie są identyczne.

Jak wykorzystano konto opiekuna projektu?

Najmocniejsze dostępne publicznie ustalenia wskazują na przejęcie konta npm, a nie na lukę w samej bibliotece Axios. Jeden z raportów mówi o wykorzystaniu długo ważnego tokenu dostępu npm należącego do głównego opiekuna projektu. Inne źródła opisują zdarzenie szerzej jako kompromitację konta lub danych uwierzytelniających umożliwiających publikowanie pakietów.

To rozróżnienie ma znaczenie. Atak przekroczył granicę zaufania między uprawnieniami opiekuna projektu a procesem publikowania wydań w npm. Ponieważ złośliwe wersje opublikowano z legalnego konta, programiści i systemy automatyczne miały mniej powodów, by uznać je za podejrzane.

Co robiła złośliwa zależność?

plain-crypto-js@4.2.1 udawała zwykłą zależność, ale jej rzeczywistym celem było wykonanie skryptu postinstall. Skrypt kontaktował się z serwerem dowodzenia i kontroli, a następnie pobierał drugi etap ładunku odpowiedni dla systemu operacyjnego ofiary.

Do infekcji nie było więc potrzebne pobranie oczywiście podejrzanego pliku wykonywalnego. Wystarczyć mogła rutynowa aktualizacja zależności, kompilacja w środowisku CI albo automatyczne npm install uruchomione w czasie, gdy złośliwe wersje były dostępne. Zalecenia bezpieczeństwa wskazują, by systemy, na których zainstalowano którąkolwiek z tych wersji Axios, traktować jako potencjalnie przejęte.

Czy za atakiem stał BlueNoroff?

Atrybucja pozostaje niejednoznaczna. Część raportów łączy operację z aktorami powiązanymi z Koreą Północną, w tym z grupą BlueNoroff lub pokrewnymi klastrami. Microsoft przypisał jednak kompromitację grupie Sapphire Sleet.

Nie należy przedstawiać tych ocen jako jednego, potwierdzonego wniosku. Podobieństwa w kodzie, infrastrukturze i sposobie działania mogą być wskazówką dotyczącą atrybucji, ale same w sobie nie dowodzą, która grupa przeprowadziła atak. Ostrożny wniosek jest następujący: kompromitacja Axios obejmowała przejęte konto opiekuna projektu, zatrute wydania i wieloplatformowego trojana zdalnego dostępu, natomiast odpowiedzialność konkretnego aktora pozostaje przedmiotem rozbieżnych publicznych ocen.

Jak SilverFox wykorzystywał fałszywe aplikacje Claude?

SilverFox obrał inną drogę do organizacji: rozpowszechniał podrobione aplikacje Claude dla Windows, macOS i Linuksa. Kampania była wymierzona w organizacje z sektorów przemysłowego, konsultingowego, handlowego i transportowego w Indiach, Indonezji, Republice Południowej Afryki oraz Rosji.

Fałszywe aplikacje podszywały się pod markę Claude firmy Anthropic. Nie były legalnymi instalatorami tego narzędzia. Ich skuteczność opierała się na wiarygodnym scenariuszu z życia firmy: pracownik szuka narzędzia AI zwiększającego produktywność, pobiera aplikację wyglądającą na znajomą i zamiast niej instaluje malware. Według Kaspersky’ego kampania była częścią aktywności SilverFox obserwowanej w kilku falach od grudnia 2025 roku.

Od phishingu podatkowego do przynęt związanych z AI

Kampania rozwijała wcześniejszy schemat phishingu wykorzystującego temat podatków. W styczniu i lutym 2026 roku badacze zarejestrowali ponad 1600 złośliwych wiadomości, które udawały oficjalne zawiadomienia o kontroli podatkowej albo informowały o rzekomej liście naruszeń podatkowych.

Zmienił się sposób dostarczenia malware, ale sygnał zaufania pozostał podobny. Zawiadomienie podatkowe wywołuje poczucie pilności i respekt wobec autorytetu, natomiast markowy asystent AI obiecuje wygodę i przydatność. W obu przypadkach odbiorca może otworzyć załącznik, pobrać archiwum lub zainstalować program, zanim sprawdzi jego źródło.

SilverFox stosował wieloetapowy model dostarczania ładunku i oddzielną infrastrukturę dla poszczególnych faz włamania. Może to utrudniać obrońcom zablokowanie lub rozpoznanie całego łańcucha ataku na podstawie jednej domeny albo pojedynczego wskaźnika.

Wspólna lekcja: zaufanie jest częścią powierzchni ataku

Obie kampanie uderzały w różne relacje zaufania:

• Zaufanie do maintenera: wydania Axios wyglądały na opublikowane przez uprawnionego użytkownika npm.
• Zaufanie do zależności: menedżer pakietów traktował złośliwą bibliotekę jak element zwykłej ścieżki instalacji.
• Zaufanie do marki: fałszywe instalatory Claude korzystały z tożsamości rozpoznawalnego produktu AI.
• Zaufanie do procedur: programiści i pracownicy wykonywali rutynowe czynności — aktualizowali zależności lub instalowali narzędzia zwiększające produktywność.

Przypadek Axios pokazuje, dlaczego krótkie okno ekspozycji wcale nie musi oznaczać małego ryzyka. Instalacje pakietów i zadania CI mogą uruchamiać się automatycznie, więc liczba potencjalnie dotkniętych systemów nie ogranicza się do osób, które ręcznie analizują każde wydanie. SilverFox pokazuje ten sam mechanizm po stronie urządzeń końcowych: szybko popularyzujące się kategorie oprogramowania tworzą dla napastników wiarygodne, aktualne przynęty.

Co organizacje powinny zrobić?

W związku z incydentem Axios należy sprawdzić pliki lock, manifesty pakietów, logi kompilacji, cache oraz inwentaryzację zależności pod kątem axios@1.14.1, axios@0.30.4 i plain-crypto-js@4.2.1. Każdą maszynę, na której w czasie ekspozycji zainstalowano podatną wersję, trzeba zbadać pod kątem pobranych ładunków, nieautoryzowanych mechanizmów trwałego dostępu i ujawnionych danych uwierzytelniających. Zalecenia bezpieczeństwa wskazują, by takie instalacje traktować jako potencjalnie przejęte.

W przypadku oprogramowania AI organizacje powinny wymagać pobierania aplikacji komputerowych wyłącznie z zatwierdzonych kanałów, weryfikować wydawcę i domenę pobierania oraz blokować lub poddawać kwarantannie niezatwierdzone instalatory. Przy publikowaniu pakietów npm pomocne są odporne na phishing uwierzytelnianie wieloskładnikowe, krótkotrwałe lub ściśle ograniczone dane dostępowe, potwierdzanie pochodzenia wydań, pliki lock oraz przegląd zmian w zależnościach.

Najważniejsza kontrola polega na weryfikacji każdego punktu, w którym system lub użytkownik musi zaufać oprogramowaniu. Znajoma nazwa pakietu nie gwarantuje bezpieczeństwa każdej jego wersji, a rozpoznawalna marka produktu nie potwierdza autentyczności każdego instalatora.

Skrypt instalacyjny łączył się z infrastrukturą kontrolowaną przez atakujących i pobierał trojana zdalnego dostępu (RAT) dopasowanego do systemu Windows, macOS lub Linuksa. Zwykła instalacja pakietu mogła więc stać się pierwszym etapem szerszej kompromitacji środowiska.

Zainfekowane wersje były dostępne przez około trzy godziny. Google Threat Intelligence Group odnotowała aktywność między 00:21 a 03:20 UTC 31 marca, a inne raporty opisują podobne, dwu- lub trzygodzinne okno. Axios jest jedną z szeroko wykorzystywanych zależności w ekosystemie JavaScriptu. Według różnych źródeł pakiet notuje od około 80 mln do ponad 100 mln pobrań tygodniowo, choć szacunki nie są identyczne.

Jak wykorzystano konto opiekuna projektu?

Najmocniejsze dostępne publicznie ustalenia wskazują na przejęcie konta npm, a nie na lukę w samej bibliotece Axios. Jeden z raportów mówi o wykorzystaniu długo ważnego tokenu dostępu npm należącego do głównego opiekuna projektu. Inne źródła opisują zdarzenie szerzej jako kompromitację konta lub danych uwierzytelniających umożliwiających publikowanie pakietów.

To rozróżnienie ma znaczenie. Atak przekroczył granicę zaufania między uprawnieniami opiekuna projektu a procesem publikowania wydań w npm. Ponieważ złośliwe wersje opublikowano z legalnego konta, programiści i systemy automatyczne miały mniej powodów, by uznać je za podejrzane.

Co robiła złośliwa zależność?

plain-crypto-js@4.2.1 udawała zwykłą zależność, ale jej rzeczywistym celem było wykonanie skryptu postinstall. Skrypt kontaktował się z serwerem dowodzenia i kontroli, a następnie pobierał drugi etap ładunku odpowiedni dla systemu operacyjnego ofiary.

Do infekcji nie było więc potrzebne pobranie oczywiście podejrzanego pliku wykonywalnego. Wystarczyć mogła rutynowa aktualizacja zależności, kompilacja w środowisku CI albo automatyczne npm install uruchomione w czasie, gdy złośliwe wersje były dostępne. Zalecenia bezpieczeństwa wskazują, by systemy, na których zainstalowano którąkolwiek z tych wersji Axios, traktować jako potencjalnie przejęte.

Czy za atakiem stał BlueNoroff?

Atrybucja pozostaje niejednoznaczna. Część raportów łączy operację z aktorami powiązanymi z Koreą Północną, w tym z grupą BlueNoroff lub pokrewnymi klastrami. Microsoft przypisał jednak kompromitację grupie Sapphire Sleet.

Nie należy przedstawiać tych ocen jako jednego, potwierdzonego wniosku. Podobieństwa w kodzie, infrastrukturze i sposobie działania mogą być wskazówką dotyczącą atrybucji, ale same w sobie nie dowodzą, która grupa przeprowadziła atak. Ostrożny wniosek jest następujący: kompromitacja Axios obejmowała przejęte konto opiekuna projektu, zatrute wydania i wieloplatformowego trojana zdalnego dostępu, natomiast odpowiedzialność konkretnego aktora pozostaje przedmiotem rozbieżnych publicznych ocen.

Jak SilverFox wykorzystywał fałszywe aplikacje Claude?

SilverFox obrał inną drogę do organizacji: rozpowszechniał podrobione aplikacje Claude dla Windows, macOS i Linuksa. Kampania była wymierzona w organizacje z sektorów przemysłowego, konsultingowego, handlowego i transportowego w Indiach, Indonezji, Republice Południowej Afryki oraz Rosji.

Fałszywe aplikacje podszywały się pod markę Claude firmy Anthropic. Nie były legalnymi instalatorami tego narzędzia. Ich skuteczność opierała się na wiarygodnym scenariuszu z życia firmy: pracownik szuka narzędzia AI zwiększającego produktywność, pobiera aplikację wyglądającą na znajomą i zamiast niej instaluje malware. Według Kaspersky’ego kampania była częścią aktywności SilverFox obserwowanej w kilku falach od grudnia 2025 roku.

Od phishingu podatkowego do przynęt związanych z AI

Kampania rozwijała wcześniejszy schemat phishingu wykorzystującego temat podatków. W styczniu i lutym 2026 roku badacze zarejestrowali ponad 1600 złośliwych wiadomości, które udawały oficjalne zawiadomienia o kontroli podatkowej albo informowały o rzekomej liście naruszeń podatkowych.

Zmienił się sposób dostarczenia malware, ale sygnał zaufania pozostał podobny. Zawiadomienie podatkowe wywołuje poczucie pilności i respekt wobec autorytetu, natomiast markowy asystent AI obiecuje wygodę i przydatność. W obu przypadkach odbiorca może otworzyć załącznik, pobrać archiwum lub zainstalować program, zanim sprawdzi jego źródło.

SilverFox stosował wieloetapowy model dostarczania ładunku i oddzielną infrastrukturę dla poszczególnych faz włamania. Może to utrudniać obrońcom zablokowanie lub rozpoznanie całego łańcucha ataku na podstawie jednej domeny albo pojedynczego wskaźnika.

Wspólna lekcja: zaufanie jest częścią powierzchni ataku

Obie kampanie uderzały w różne relacje zaufania:

• Zaufanie do maintenera: wydania Axios wyglądały na opublikowane przez uprawnionego użytkownika npm.
• Zaufanie do zależności: menedżer pakietów traktował złośliwą bibliotekę jak element zwykłej ścieżki instalacji.
• Zaufanie do marki: fałszywe instalatory Claude korzystały z tożsamości rozpoznawalnego produktu AI.
• Zaufanie do procedur: programiści i pracownicy wykonywali rutynowe czynności — aktualizowali zależności lub instalowali narzędzia zwiększające produktywność.

Przypadek Axios pokazuje, dlaczego krótkie okno ekspozycji wcale nie musi oznaczać małego ryzyka. Instalacje pakietów i zadania CI mogą uruchamiać się automatycznie, więc liczba potencjalnie dotkniętych systemów nie ogranicza się do osób, które ręcznie analizują każde wydanie. SilverFox pokazuje ten sam mechanizm po stronie urządzeń końcowych: szybko popularyzujące się kategorie oprogramowania tworzą dla napastników wiarygodne, aktualne przynęty.

Co organizacje powinny zrobić?

W związku z incydentem Axios należy sprawdzić pliki lock, manifesty pakietów, logi kompilacji, cache oraz inwentaryzację zależności pod kątem axios@1.14.1, axios@0.30.4 i plain-crypto-js@4.2.1. Każdą maszynę, na której w czasie ekspozycji zainstalowano podatną wersję, trzeba zbadać pod kątem pobranych ładunków, nieautoryzowanych mechanizmów trwałego dostępu i ujawnionych danych uwierzytelniających. Zalecenia bezpieczeństwa wskazują, by takie instalacje traktować jako potencjalnie przejęte.

W przypadku oprogramowania AI organizacje powinny wymagać pobierania aplikacji komputerowych wyłącznie z zatwierdzonych kanałów, weryfikować wydawcę i domenę pobierania oraz blokować lub poddawać kwarantannie niezatwierdzone instalatory. Przy publikowaniu pakietów npm pomocne są odporne na phishing uwierzytelnianie wieloskładnikowe, krótkotrwałe lub ściśle ograniczone dane dostępowe, potwierdzanie pochodzenia wydań, pliki lock oraz przegląd zmian w zależnościach.

Najważniejsza kontrola polega na weryfikacji każdego punktu, w którym system lub użytkownik musi zaufać oprogramowaniu. Znajoma nazwa pakietu nie gwarantuje bezpieczeństwa każdej jego wersji, a rozpoznawalna marka produktu nie potwierdza autentyczności każdego instalatora.