Aokigahara-infostealer angriber AI-kodeværktøjer og cloudnøgler

En nyligt observeret infostealer ved navn Aokigahara går efter de steder, hvor udviklere opbevarer deres mest værdifulde hemmeligheder: AI-kodeassistenter, udviklerarbejdsstationer og cloudlegitimationsoplysninger. Aokigahara-infostealerens kampagne mod AI-kodeværktøjer er en påmindelse om, at angribere i stigende grad er mindre interesserede i din adgangskode og mere interesserede i de tokens, nøgler og sessionsfiler, som dine enheder i al stilhed gemmer.

De offentlige detaljer om denne malware er begrænsede, så dette indlæg holder sig til det, der er rapporteret, og forklarer, hvorfor teknikken er vigtig.

Hvordan Aokigahara stjæler logins og sessionstokens

Ifølge rapporteringen er Aokigahara en infostealer, en type malware, der kører på en inficeret maskine, indsamler følsomme filer og lagrede data og sender dem til en angriber. Dens rapporterede mål omfatter AI-kodeassistenter, udviklerarbejdsstationer og cloudlegitimationsoplysninger, hvor de mest fremtrædende elementer er logintokens, SSH-nøgler og cloudadgangsmateriale.

Infostealere behøver ikke at bryde ind i en konto på den svære måde. Når malware først kører på en enhed, kan det læse filer, som applikationer efterlader for at holde dig logget ind. Det er derfor, en enkelt inficeret laptop kan eksponere flere tjenester på én gang: browseren, kodeeditoren, kommandolinjen og ethvert cloudværktøj, der er konfigureret på samme maskine.

Kildeartiklen er kort, så vi kan ikke sige, hvordan Aokigahara leveres, eller hvor mange personer der er blevet påvirket. Vi vil ikke gætte. Det, der er klart, er kategorien af data, den vil have, og den kategori er værd at forstå i sig selv.

Hvorfor udviklere og cloudkonti er mål med høj værdi

Udviklermaskiner er usædvanligt rige. En typisk arbejdsstation kan indeholde SSH-nøgler til servere og kodelagre, cloudadgangslegitimationsoplysninger, API-tokens og loginstatus for AI-assistenter. En enkelt kompromitteret enhed kan derfor være et springbræt ind i kildekode, infrastruktur og produktionssystemer.

AI-kodeassistenter tilføjer endnu et lag. De er ofte autentificeret i lange perioder og knyttet til privat kode og projekter. Hvis en angriber får fat i det token, der beviser, at du er logget ind, kan de muligvis handle som dig uden nogensinde at se din adgangskode.

Dette passer ind i et bredere mønster, hvor angribere retter deres opmærksomhed mod AI-udviklingsværktøjer. For bredere kontekst kan du se vores dækning af, hvordan Claude Code blev våbengjort i et autonomt ransomwareangreb, som viser, hvordan disse værktøjer kan misbruges fra en anden retning.

Hvorfor stjålne sessionstokens omgår MFA

Multifaktorautentificering (MFA) beskytter selve loginøjeblikket. Den kræver noget ud over din adgangskode, såsom en kode eller en prompt. Men når du har bestået den kontrol, udsteder tjenesten en sessionscookie eller et token, der i praksis siger: denne bruger er allerede verificeret.

Hvis malware kopierer det token, kan en angriber præsentere det for tjenesten og springe login-trinnet helt over. Der er ingen adgangskode at gætte og ingen kode at opsnappe, fordi beviset for verifikation allerede er stjålet. SSH-nøgler fungerer på samme måde: en privat nøgle på disken kan autentificere til en server uden nogen anden faktor, medmindre selve nøglen er beskyttet.

Det betyder ikke, at MFA er ubrugeligt. Det blokerer stadig en stor del af kontoovertagelser, især dem, der er baseret på lækkede adgangskoder. Det kan simpelthen ikke hjælpe, når selve enheden er kompromitteret, og tokensene er hentet fra den. Det er derfor, enhedshygiejne er lige så vigtig som stærke adgangskoder.

Hvad dette betyder for dig

Hvis du skriver kode, administrerer servere eller bruger AI-assistenter med adgang til private projekter, så behandl din arbejdsstation som en boks. De hemmeligheder, der er gemt på den, er ofte mere værd end nogen enkelt adgangskode.

Selv hvis du ikke er udvikler, gælder lektionen. Browsere gemmer sessionscookies, og malware, der læser dem, kan kapre konti, der var beskyttet af MFA. Risikoen kommer fra, at enheden er inficeret, så det at holde den enhed ren er en del af at beskytte enhver konto, du bruger på den.

Praktiske trin til at beskytte dine legitimationsoplysninger

• Kortlæg, hvor hemmeligheder ligger. Tjek for API-nøgler, tokens og legitimationsoplysninger i almindelige tekstfiler, miljøfiler, shell-historik og projektmapper. Flyt dem til en dedikeret secrets manager eller dit operativsystems sikre lager.
• Beskyt SSH-nøgler. Brug en adgangssætning på private nøgler, og overvej hardwarebaserede nøgler, hvor det er muligt, så nøglen ikke blot kan kopieres.
• Roter alt, der kan være eksponeret. Hvis du har mistanke om, at en enhed er blevet inficeret, så tilbagekald og genudsted tokens, SSH-nøgler og cloudlegitimationsoplysninger fra en ren enhed. Log ud af aktive sessioner overalt.
• Skift til phishing-resistent MFA. Passkeys og hardware-sikkerhedsnøgler modstår phishing langt bedre end SMS eller app-koder, selvom ingen MFA fuldt ud løser tokenstyveri fra en inficeret maskine.
• Hold enheder rene. Installer opdateringer, brug anerkendt endpoint-beskyttelse, undgå at køre uverificerede scripts eller pakker, og vær forsigtig med downloads og e-mailvedhæftninger.
• Begræns privilegier og levetider. Brug kortlivede tokens og de snævreste tilladelser, der fungerer, så en stjålet legitimationsoplysning er mindre værd.

Det vigtigste at tage med

Aokigahara-infostealerens kampagne mod AI-kodeværktøjer viser, at angribere følger legitimationsoplysningerne, og de findes nu i AI-assistenter og udviklermiljøer i lige så høj grad som i adgangskodefelter. Start med at kortlægge, hvor dine hemmeligheder er gemt, roter eventuelle tokens og nøgler, der kan være blevet eksponeret, og skift til phishing-resistent MFA. For mere om, hvordan angribere bruger AI-udviklingsværktøjer til deres fordel, kan du læse vores rapport om AI-kodeværktøjer, der misbruges i angreb.