Instalační skript kontaktoval infrastrukturu ovládanou útočníky a stáhl trojského koně pro vzdálený přístup (RAT) určeného pro Windows, macOS i Linux. Rutinní instalace balíčku se tak mohla stát prvním krokem k rozsáhlejšímu napadení.

Napadené verze byly dostupné přibližně tři hodiny. Google Threat Intelligence Group zaznamenala aktivitu mezi 00:21 a 03:20 UTC 31. března, další zprávy popisují podobné dvou- až tříhodinové období. Axios patří mezi velmi rozšířené závislosti; podle různých zdrojů má přibližně 80 až více než 100 milionů stažení týdně z registru npm. Odhady se však mezi jednotlivými zprávami liší.

Jak byl zneužit účet správce

Nejlépe doložené veřejné informace ukazují na převzetí účtu npm, nikoli na chybu přímo v Axiosu. Jedna zpráva uvádí, že útočníci použili dlouhodobě platný přístupový token hlavního správce. Jiné zdroje událost popisují obecněji jako kompromitaci účtu nebo publikačních údajů správce.

Tento rozdíl je důležitý. Útok překročil hranici důvěry mezi oprávněním správce zveřejňovat balíčky a vydávacím procesem registru npm. Protože škodlivé verze byly publikovány z legitimního účtu, měly navazující vývojářské nástroje i automatizované systémy méně důvodů považovat je za podezřelé.

Co udělala škodlivá závislost

plain-crypto-js@4.2.1 se tvářila jako běžný balíček, ve skutečnosti však sloužila ke spuštění skriptu postinstall. Ten kontaktoval server pro řízení a stahoval další fázi malwaru přizpůsobenou operačnímu systému napadeného zařízení.

Útočníci proto nepotřebovali, aby vývojář stáhl nápadně podezřelý spustitelný soubor. Spouštěčem mohla být běžná aktualizace závislostí, sestavení v CI nebo automaticky provedený příkaz npm install v době, kdy byly kompromitované verze dostupné. Bezpečnostní upozornění doporučují považovat systémy, na nichž byla nainstalována některá z těchto verzí Axiosu, za potenciálně napadené.

Byl za útokem BlueNoroff?

Veřejně dostupné podklady nevedou k jednoznačnému závěru. Některé zprávy spojují operaci se severokorejskými aktéry, například se skupinou BlueNoroff nebo příbuznými klastery. Microsoft naopak kompromitaci připsal skupině Sapphire Sleet.

Tyto závěry nelze prezentovat jako jediné potvrzené vysvětlení. Podobnosti v kódu, infrastruktuře nebo způsobu práce mohou posloužit jako vodítko k atribuci, samy o sobě však nedokazují, která skupina útok provedla. Opatrný závěr zní: incident Axiosu zahrnoval převzetí účtu správce, otrávené vydání balíčků a RAT pro více platforem. Identita útočníka zůstává v jednotlivých veřejných hodnoceních sporná.

Jak SilverFox využil falešné aplikace Claude

SilverFox zvolil jinou cestu do organizací: distribuoval podvržené aplikace Claude pro Windows, macOS a Linux. Kampaň cílila na organizace z průmyslu, poradenství, obchodu a dopravy v Indii, Indonésii, Jihoafrické republice a Rusku.

Nešlo o legitimní instalační programy Claude, ale o napodobeniny značky společnosti Anthropic. Jejich účinnost stála na uvěřitelném pracovním scénáři: zaměstnanec hledá nástroj umělé inteligence pro produktivitu, stáhne aplikaci, která vypadá známě, a místo ní nainstaluje malware. Kaspersky popsala kampaň jako součást aktivit SilverFoxu zaznamenávaných v několika vlnách od prosince 2025.

Od phishingu s daňovou tematikou k lákadlu v podobě AI

Kampaň navazovala také na dřívější phishing s daňovou tematikou. V lednu a únoru 2026 výzkumníci zaznamenali více než 1 600 škodlivých e-mailů, které se vydávaly za oficiální oznámení o daňové kontrole nebo tvrdily, že obsahují seznam daňových přestupků.

Způsob doručení se změnil, signál důvěry však zůstal podobný. Daňové oznámení vytváří naléhavost a autoritu, značkový asistent AI zase pocit relevance a pohodlí. Obojí může uživatele přimět otevřít přílohu, stáhnout archiv nebo nainstalovat software dříve, než ověří jeho původ.

SilverFox používal vícestupňový model doručení a pro různé fáze útoku oddělenou infrastrukturu. Obráncům to může ztížit zablokování nebo odhalení celého řetězce pouze na základě jedné domény či indikátoru.

Společná lekce: důvěra je součástí útočné plochy

Incidenty Axiosu a SilverFoxu mířily na různé vztahy důvěry:

• Důvěra ve správce: Vydání Axiosu vypadala, že pocházejí od oprávněného vydavatele v npm.
• Důvěra v závislosti: Správce balíčků považoval škodlivou závislost za součást běžné instalační cesty.
• Důvěra ve značku: Falešné instalátory Claude si vypůjčily identitu známého produktu.
• Důvěra v pracovní postup: Vývojáři a zaměstnanci prováděli rutinní činnosti — aktualizovali závislosti nebo instalovali nástroj pro produktivitu.

Případ Axiosu ukazuje, proč ani krátké období dostupnosti nemusí znamenat malý dopad. Instalace balíčků a úlohy v CI mohou probíhat automaticky, takže počet zasažených systémů není omezen na lidi, kteří si vydání ručně prohlédnou. Případ SilverFoxu ukazuje stejný princip na koncových zařízeních: rychle se rozvíjející kategorie softwaru poskytují útočníkům nové, uvěřitelné návnady.

Co by měly organizace udělat

V souvislosti s incidentem Axiosu je vhodné prověřit lock soubory, manifesty balíčků, protokoly sestavování, lokální cache a inventáře závislostí. Hledejte axios@1.14.1, axios@0.30.4 a plain-crypto-js@4.2.1. Každý počítač, na němž byla v době dostupnosti nainstalována některá z napadených verzí, by měl být prověřen kvůli staženému malwaru, neoprávněnému mechanismu trvalého přístupu a uniklým přihlašovacím údajům. Bezpečnostní doporučení výslovně radí považovat takové instalace za potenciálně kompromitované.

U softwaru s umělou inteligencí by organizace měly vyžadovat instalaci desktopových aplikací pouze z povolených kanálů, ověřovat vydavatele i doménu pro stažení a nepovolené instalátory blokovat nebo přesouvat do karantény. Při publikování balíčků npm může riziko snížit vícefaktorové ověřování odolné proti phishingu, krátkodobé nebo úzce omezené přihlašovací údaje, doklad o původu vydání, lock soubory a kontrola změn závislostí.

Nejdůležitější pravidlo platí na každé hranici důvěry: ověřujte. Známý název balíčku není důkazem, že je bezpečná každá jeho verze. A známý název produktu zase neznamená, že je pravý každý instalační program.

Instalační skript kontaktoval infrastrukturu ovládanou útočníky a stáhl trojského koně pro vzdálený přístup (RAT) určeného pro Windows, macOS i Linux. Rutinní instalace balíčku se tak mohla stát prvním krokem k rozsáhlejšímu napadení.

Napadené verze byly dostupné přibližně tři hodiny. Google Threat Intelligence Group zaznamenala aktivitu mezi 00:21 a 03:20 UTC 31. března, další zprávy popisují podobné dvou- až tříhodinové období. Axios patří mezi velmi rozšířené závislosti; podle různých zdrojů má přibližně 80 až více než 100 milionů stažení týdně z registru npm. Odhady se však mezi jednotlivými zprávami liší.

Jak byl zneužit účet správce

Nejlépe doložené veřejné informace ukazují na převzetí účtu npm, nikoli na chybu přímo v Axiosu. Jedna zpráva uvádí, že útočníci použili dlouhodobě platný přístupový token hlavního správce. Jiné zdroje událost popisují obecněji jako kompromitaci účtu nebo publikačních údajů správce.

Tento rozdíl je důležitý. Útok překročil hranici důvěry mezi oprávněním správce zveřejňovat balíčky a vydávacím procesem registru npm. Protože škodlivé verze byly publikovány z legitimního účtu, měly navazující vývojářské nástroje i automatizované systémy méně důvodů považovat je za podezřelé.

Co udělala škodlivá závislost

plain-crypto-js@4.2.1 se tvářila jako běžný balíček, ve skutečnosti však sloužila ke spuštění skriptu postinstall. Ten kontaktoval server pro řízení a stahoval další fázi malwaru přizpůsobenou operačnímu systému napadeného zařízení.

Útočníci proto nepotřebovali, aby vývojář stáhl nápadně podezřelý spustitelný soubor. Spouštěčem mohla být běžná aktualizace závislostí, sestavení v CI nebo automaticky provedený příkaz npm install v době, kdy byly kompromitované verze dostupné. Bezpečnostní upozornění doporučují považovat systémy, na nichž byla nainstalována některá z těchto verzí Axiosu, za potenciálně napadené.

Byl za útokem BlueNoroff?

Veřejně dostupné podklady nevedou k jednoznačnému závěru. Některé zprávy spojují operaci se severokorejskými aktéry, například se skupinou BlueNoroff nebo příbuznými klastery. Microsoft naopak kompromitaci připsal skupině Sapphire Sleet.

Tyto závěry nelze prezentovat jako jediné potvrzené vysvětlení. Podobnosti v kódu, infrastruktuře nebo způsobu práce mohou posloužit jako vodítko k atribuci, samy o sobě však nedokazují, která skupina útok provedla. Opatrný závěr zní: incident Axiosu zahrnoval převzetí účtu správce, otrávené vydání balíčků a RAT pro více platforem. Identita útočníka zůstává v jednotlivých veřejných hodnoceních sporná.

Jak SilverFox využil falešné aplikace Claude

SilverFox zvolil jinou cestu do organizací: distribuoval podvržené aplikace Claude pro Windows, macOS a Linux. Kampaň cílila na organizace z průmyslu, poradenství, obchodu a dopravy v Indii, Indonésii, Jihoafrické republice a Rusku.

Nešlo o legitimní instalační programy Claude, ale o napodobeniny značky společnosti Anthropic. Jejich účinnost stála na uvěřitelném pracovním scénáři: zaměstnanec hledá nástroj umělé inteligence pro produktivitu, stáhne aplikaci, která vypadá známě, a místo ní nainstaluje malware. Kaspersky popsala kampaň jako součást aktivit SilverFoxu zaznamenávaných v několika vlnách od prosince 2025.

Od phishingu s daňovou tematikou k lákadlu v podobě AI

Kampaň navazovala také na dřívější phishing s daňovou tematikou. V lednu a únoru 2026 výzkumníci zaznamenali více než 1 600 škodlivých e-mailů, které se vydávaly za oficiální oznámení o daňové kontrole nebo tvrdily, že obsahují seznam daňových přestupků.

Způsob doručení se změnil, signál důvěry však zůstal podobný. Daňové oznámení vytváří naléhavost a autoritu, značkový asistent AI zase pocit relevance a pohodlí. Obojí může uživatele přimět otevřít přílohu, stáhnout archiv nebo nainstalovat software dříve, než ověří jeho původ.

SilverFox používal vícestupňový model doručení a pro různé fáze útoku oddělenou infrastrukturu. Obráncům to může ztížit zablokování nebo odhalení celého řetězce pouze na základě jedné domény či indikátoru.

Společná lekce: důvěra je součástí útočné plochy

Incidenty Axiosu a SilverFoxu mířily na různé vztahy důvěry:

• Důvěra ve správce: Vydání Axiosu vypadala, že pocházejí od oprávněného vydavatele v npm.
• Důvěra v závislosti: Správce balíčků považoval škodlivou závislost za součást běžné instalační cesty.
• Důvěra ve značku: Falešné instalátory Claude si vypůjčily identitu známého produktu.
• Důvěra v pracovní postup: Vývojáři a zaměstnanci prováděli rutinní činnosti — aktualizovali závislosti nebo instalovali nástroj pro produktivitu.

Případ Axiosu ukazuje, proč ani krátké období dostupnosti nemusí znamenat malý dopad. Instalace balíčků a úlohy v CI mohou probíhat automaticky, takže počet zasažených systémů není omezen na lidi, kteří si vydání ručně prohlédnou. Případ SilverFoxu ukazuje stejný princip na koncových zařízeních: rychle se rozvíjející kategorie softwaru poskytují útočníkům nové, uvěřitelné návnady.

Co by měly organizace udělat

V souvislosti s incidentem Axiosu je vhodné prověřit lock soubory, manifesty balíčků, protokoly sestavování, lokální cache a inventáře závislostí. Hledejte axios@1.14.1, axios@0.30.4 a plain-crypto-js@4.2.1. Každý počítač, na němž byla v době dostupnosti nainstalována některá z napadených verzí, by měl být prověřen kvůli staženému malwaru, neoprávněnému mechanismu trvalého přístupu a uniklým přihlašovacím údajům. Bezpečnostní doporučení výslovně radí považovat takové instalace za potenciálně kompromitované.

U softwaru s umělou inteligencí by organizace měly vyžadovat instalaci desktopových aplikací pouze z povolených kanálů, ověřovat vydavatele i doménu pro stažení a nepovolené instalátory blokovat nebo přesouvat do karantény. Při publikování balíčků npm může riziko snížit vícefaktorové ověřování odolné proti phishingu, krátkodobé nebo úzce omezené přihlašovací údaje, doklad o původu vydání, lock soubory a kontrola změn závislostí.

Nejdůležitější pravidlo platí na každé hranici důvěry: ověřujte. Známý název balíčku není důkazem, že je bezpečná každá jeho verze. A známý název produktu zase neznamená, že je pravý každý instalační program.