Installationsscriptet kontaktede angriberkontrolleret infrastruktur og hentede en platformstilpasset fjernadgangstrojan til Windows, macOS og Linux. En almindelig installation af en pakke kunne dermed blive første skridt i en større kompromittering.

De berørte versioner var tilgængelige i cirka tre timer. Google Threat Intelligence Group registrerede aktivitet mellem kl. 00.21 og 03.20 UTC den 31. marts, mens andre hændelsesrapporter beskriver et tilsvarende tidsrum på to til tre timer. Axios er en meget udbredt afhængighed: Flere rapporter anslår mellem cirka 80 millioner og over 100 millioner ugentlige npm-downloads, selv om tallene varierer fra kilde til kilde.

Sådan blev maintainer-kontoen misbrugt

Den stærkeste offentlige dokumentation peger på en overtagelse af npm-kontoen frem for en fejl i selve Axios. Én rapport angiver, at angriberne brugte en langlivet npm-adgangstoken, der tilhørte den ledende maintainer. Andre beskriver mere generelt en kompromitteret maintainer-konto eller kompromitterede udgivelsesoplysninger.

Forskellen er vigtig. Angrebet krydsede tillidsgrænsen mellem en maintainers udgivelsesrettigheder og npms release-pipeline. Fordi versionerne blev publiceret via en legitim konto, havde udviklere og automatiserede systemer færre grunde til at opfatte dem som mistænkelige.

Hvad gjorde den skadelige afhængighed?

plain-crypto-js@4.2.1 var forklædt som en normal pakkeafhængighed, men eksisterede for at køre et postinstall-script. Scriptet kontaktede en kommando- og kontrolserver og hentede en nyttelast tilpasset værtsystemets operativsystem.

Hændelsen krævede derfor ikke, at udviklere hentede en åbenlyst mistænkelig eksekverbar fil. Udløseren kunne være en almindelig afhængighedsopdatering, et CI-build eller en automatisk npm install, der blev kørt i eksponeringsperioden. Sikkerhedsadvarsler anbefaler, at systemer, som installerede en af de berørte Axios-versioner, behandles som potentielt kompromitterede.

Var BlueNoroff ansvarlig?

Ansvarsplaceringen er ikke afklaret i det materiale, der er tilgængeligt her. Nogle rapporter forbinder operationen med nordkoreansk tilknyttede aktører, herunder BlueNoroff eller relaterede grupper, mens Microsoft tilskrev kompromitteringen til Sapphire Sleet.

Vurderingerne bør derfor ikke fremstilles som én bekræftet konklusion. Kode, infrastruktur og operationelle ligheder kan give et spor om attribution, men beviser ikke i sig selv, hvilken gruppe der stod bag angrebet. Den forsvarlige konklusion er, at Axios-kompromitteringen omfattede en kapret maintainer-konto, forgiftede udgivelser og en cross-platform RAT. Hvilken aktør der stod bag, er fortsat omstridt i de offentlige vurderinger.

Sådan brugte SilverFox falske Claude-apps

SilverFox fandt en anden vej ind i organisationer: Gruppen distribuerede falske Claude-applikationer til Windows, macOS og Linux. Kampagnen målrettede organisationer inden for industri, rådgivning, handel og transport i Indien, Indonesien, Sydafrika og Rusland.

De falske apps var efterligninger af Anthropics Claude-brand og ikke officielle Claude-installationsprogrammer. Effekten byggede på en troværdig arbejdssituation: En medarbejder søger efter et AI-værktøj til produktivitet, downloader det, der ligner en velkendt app, og installerer i stedet malware. Kaspersky beskrev kampagnen som en del af SilverFox’ aktiviteter, der er observeret i flere bølger siden december 2025.

Fra skattesvindel til AI-lokkemad

Kampagnen byggede også videre på tidligere phishing med skattetema. I januar og februar 2026 registrerede forskere mere end 1.600 skadelige e-mails, der udgav sig for at være officielle meddelelser om skattekontrol eller hævdede at indeholde lister over skatteovertrædelser.

Leveringsmetoden ændrede sig, men tillidssignalet var velkendt. Skattemeddelelser skaber hastværk og autoritet; et brandet AI-værktøj skaber relevans og bekvemmelighed. Begge dele kan få brugere til at åbne en vedhæftet fil, hente et arkiv eller installere software, før kilden er blevet kontrolleret.

SilverFox brugte en trinvist opbygget leveringsmodel med separat infrastruktur til de forskellige faser af indtrængningen. Det kan gøre det sværere for forsvarere at blokere eller identificere hele angrebskæden ud fra ét domæne eller én indikator.

Den fælles lære: Tillid er en del af angrebsfladen

Axios- og SilverFox-kampagnerne målrettede forskellige tillidsforhold:

• Tillid til maintainere: Axios-udgivelserne så ud til at komme fra en autoriseret npm-udgiver.
• Tillid til afhængigheder: En pakkehåndtering behandlede den skadelige afhængighed som en del af en normal installationsproces.
• Tillid til brands: Falske Claude-installationsprogrammer lånte identiteten fra et genkendeligt AI-produkt.
• Tillid til arbejdsgange: Udviklere og medarbejdere fulgte rutinehandlinger – opdaterede afhængigheder eller installerede produktivitetssoftware.

Axios-sagen viser, hvorfor et kort eksponeringsvindue stadig kan være farligt. Pakkeinstallationer og CI-jobs kan køre automatisk, så antallet af berørte systemer ikke begrænses til personer, der manuelt gennemgår en udgivelse. SilverFox-sagen viser det samme fra slutpunktet: Hurtigt udbredte softwarekategorier giver angribere nye og troværdige lokkemidler.

Hvad bør organisationer gøre nu?

I forbindelse med Axios-hændelsen bør organisationer gennemgå lockfiler, pakkemanifester, buildlogs, caches og fortegnelser over afhængigheder for axios@1.14.1, axios@0.30.4 og plain-crypto-js@4.2.1. Alle maskiner, der installerede en berørt version i eksponeringsperioden, bør undersøges for hentede nyttelaster, uautoriseret persistens og kompromitterede legitimationsoplysninger. Sikkerhedsvejledninger anbefaler specifikt, at berørte installationer behandles som potentielt kompromitterede.

For AI-software bør medarbejdere kun hente desktopapplikationer via godkendte kanaler. Organisationer bør samtidig kontrollere udgiveren og downloaddomænet samt blokere eller sætte ikke-godkendte installationsprogrammer i karantæne.

Ved npm-udgivelser kan phishing-resistent multifaktorgodkendelse, kortlivede eller stramt begrænsede legitimationsoplysninger, dokumentation af release-oprindelse, lockfiler og gennemgang af ændringer i afhængigheder mindske risikoen for, at én kompromitteret konto udvikler sig til et softwareforsyningskædeangreb.

Den bredere sikkerhedsforanstaltning er kontrol ved hver eneste tillidsgrænse. Et velkendt pakkenavn er ikke et bevis på, at alle udgivelser er sikre, og et velkendt produktnavn er ikke et bevis på, at alle installationsprogrammer er ægte.

Installationsscriptet kontaktede angriberkontrolleret infrastruktur og hentede en platformstilpasset fjernadgangstrojan til Windows, macOS og Linux. En almindelig installation af en pakke kunne dermed blive første skridt i en større kompromittering.

De berørte versioner var tilgængelige i cirka tre timer. Google Threat Intelligence Group registrerede aktivitet mellem kl. 00.21 og 03.20 UTC den 31. marts, mens andre hændelsesrapporter beskriver et tilsvarende tidsrum på to til tre timer. Axios er en meget udbredt afhængighed: Flere rapporter anslår mellem cirka 80 millioner og over 100 millioner ugentlige npm-downloads, selv om tallene varierer fra kilde til kilde.

Sådan blev maintainer-kontoen misbrugt

Den stærkeste offentlige dokumentation peger på en overtagelse af npm-kontoen frem for en fejl i selve Axios. Én rapport angiver, at angriberne brugte en langlivet npm-adgangstoken, der tilhørte den ledende maintainer. Andre beskriver mere generelt en kompromitteret maintainer-konto eller kompromitterede udgivelsesoplysninger.

Forskellen er vigtig. Angrebet krydsede tillidsgrænsen mellem en maintainers udgivelsesrettigheder og npms release-pipeline. Fordi versionerne blev publiceret via en legitim konto, havde udviklere og automatiserede systemer færre grunde til at opfatte dem som mistænkelige.

Hvad gjorde den skadelige afhængighed?

plain-crypto-js@4.2.1 var forklædt som en normal pakkeafhængighed, men eksisterede for at køre et postinstall-script. Scriptet kontaktede en kommando- og kontrolserver og hentede en nyttelast tilpasset værtsystemets operativsystem.

Hændelsen krævede derfor ikke, at udviklere hentede en åbenlyst mistænkelig eksekverbar fil. Udløseren kunne være en almindelig afhængighedsopdatering, et CI-build eller en automatisk npm install, der blev kørt i eksponeringsperioden. Sikkerhedsadvarsler anbefaler, at systemer, som installerede en af de berørte Axios-versioner, behandles som potentielt kompromitterede.

Var BlueNoroff ansvarlig?

Ansvarsplaceringen er ikke afklaret i det materiale, der er tilgængeligt her. Nogle rapporter forbinder operationen med nordkoreansk tilknyttede aktører, herunder BlueNoroff eller relaterede grupper, mens Microsoft tilskrev kompromitteringen til Sapphire Sleet.

Vurderingerne bør derfor ikke fremstilles som én bekræftet konklusion. Kode, infrastruktur og operationelle ligheder kan give et spor om attribution, men beviser ikke i sig selv, hvilken gruppe der stod bag angrebet. Den forsvarlige konklusion er, at Axios-kompromitteringen omfattede en kapret maintainer-konto, forgiftede udgivelser og en cross-platform RAT. Hvilken aktør der stod bag, er fortsat omstridt i de offentlige vurderinger.

Sådan brugte SilverFox falske Claude-apps

SilverFox fandt en anden vej ind i organisationer: Gruppen distribuerede falske Claude-applikationer til Windows, macOS og Linux. Kampagnen målrettede organisationer inden for industri, rådgivning, handel og transport i Indien, Indonesien, Sydafrika og Rusland.

De falske apps var efterligninger af Anthropics Claude-brand og ikke officielle Claude-installationsprogrammer. Effekten byggede på en troværdig arbejdssituation: En medarbejder søger efter et AI-værktøj til produktivitet, downloader det, der ligner en velkendt app, og installerer i stedet malware. Kaspersky beskrev kampagnen som en del af SilverFox’ aktiviteter, der er observeret i flere bølger siden december 2025.

Fra skattesvindel til AI-lokkemad

Kampagnen byggede også videre på tidligere phishing med skattetema. I januar og februar 2026 registrerede forskere mere end 1.600 skadelige e-mails, der udgav sig for at være officielle meddelelser om skattekontrol eller hævdede at indeholde lister over skatteovertrædelser.

Leveringsmetoden ændrede sig, men tillidssignalet var velkendt. Skattemeddelelser skaber hastværk og autoritet; et brandet AI-værktøj skaber relevans og bekvemmelighed. Begge dele kan få brugere til at åbne en vedhæftet fil, hente et arkiv eller installere software, før kilden er blevet kontrolleret.

SilverFox brugte en trinvist opbygget leveringsmodel med separat infrastruktur til de forskellige faser af indtrængningen. Det kan gøre det sværere for forsvarere at blokere eller identificere hele angrebskæden ud fra ét domæne eller én indikator.

Den fælles lære: Tillid er en del af angrebsfladen

Axios- og SilverFox-kampagnerne målrettede forskellige tillidsforhold:

• Tillid til maintainere: Axios-udgivelserne så ud til at komme fra en autoriseret npm-udgiver.
• Tillid til afhængigheder: En pakkehåndtering behandlede den skadelige afhængighed som en del af en normal installationsproces.
• Tillid til brands: Falske Claude-installationsprogrammer lånte identiteten fra et genkendeligt AI-produkt.
• Tillid til arbejdsgange: Udviklere og medarbejdere fulgte rutinehandlinger – opdaterede afhængigheder eller installerede produktivitetssoftware.

Axios-sagen viser, hvorfor et kort eksponeringsvindue stadig kan være farligt. Pakkeinstallationer og CI-jobs kan køre automatisk, så antallet af berørte systemer ikke begrænses til personer, der manuelt gennemgår en udgivelse. SilverFox-sagen viser det samme fra slutpunktet: Hurtigt udbredte softwarekategorier giver angribere nye og troværdige lokkemidler.

Hvad bør organisationer gøre nu?

I forbindelse med Axios-hændelsen bør organisationer gennemgå lockfiler, pakkemanifester, buildlogs, caches og fortegnelser over afhængigheder for axios@1.14.1, axios@0.30.4 og plain-crypto-js@4.2.1. Alle maskiner, der installerede en berørt version i eksponeringsperioden, bør undersøges for hentede nyttelaster, uautoriseret persistens og kompromitterede legitimationsoplysninger. Sikkerhedsvejledninger anbefaler specifikt, at berørte installationer behandles som potentielt kompromitterede.

For AI-software bør medarbejdere kun hente desktopapplikationer via godkendte kanaler. Organisationer bør samtidig kontrollere udgiveren og downloaddomænet samt blokere eller sætte ikke-godkendte installationsprogrammer i karantæne.

Ved npm-udgivelser kan phishing-resistent multifaktorgodkendelse, kortlivede eller stramt begrænsede legitimationsoplysninger, dokumentation af release-oprindelse, lockfiler og gennemgang af ændringer i afhængigheder mindske risikoen for, at én kompromitteret konto udvikler sig til et softwareforsyningskædeangreb.

Den bredere sikkerhedsforanstaltning er kontrol ved hver eneste tillidsgrænse. Et velkendt pakkenavn er ikke et bevis på, at alle udgivelser er sikre, og et velkendt produktnavn er ikke et bevis på, at alle installationsprogrammer er ægte.