En nylig observert infostealer kalt Aokigahara går etter stedene der utviklere oppbevarer sine mest verdifulle hemmeligheter: AI-kodeassistenter, utviklerarbeidsstasjoner og skybaserte påloggingsdata. Aokigahara-infostealerens kampanje mot AI-kodeverktøy er en påminnelse om at angripere i økende grad bryr seg mindre om passordet ditt og mer om tokenene, nøklene og øktfilene som enhetene dine stille lagrer.

De offentlige detaljene om denne skadevaren er begrensede, så dette innlegget holder seg til det som er rapportert og forklarer hvorfor teknikken er viktig.

Hvordan Aokigahara stjeler pålogginger og økttokener

Ifølge rapporteringen er Aokigahara en infostealer, en type skadevare som kjører på en infisert maskin, samler inn sensitive filer og lagrede data, og sender dem til en angriper. Dens rapporterte mål inkluderer AI-kodeassistenter, utviklerarbeidsstasjoner og skybaserte påloggingsdata, med hovedelementene være påloggingstokener, SSH-nøkler og skybasert tilgangsmateriale.

Infostealere trenger ikke å bryte seg inn i en konto på den vanskelige måten. Når skadevaren først kjører på en enhet, kan den lese filer som applikasjoner etterlater seg for å holde deg pålogget. Det er derfor en enkelt infisert bærbar PC kan eksponere flere tjenester samtidig: nettleseren, kodeeditoren, kommandolinjen og eventuelle skyverktøy konfigurert på samme maskin.

Kildeartikkelen er kort, så vi kan ikke si hvordan Aokigahara leveres eller hvor mange som er rammet. Vi vil ikke gjette. Det som er klart, er kategorien data den vil ha, og den kategorien er verdt å forstå på egen hånd.

Hvorfor utviklere og skykontoer er høyverdige mål

Utviklermaskiner er uvanlig rike. En typisk arbeidsstasjon kan inneholde SSH-nøkler for servere og kodelagre, skybaserte tilgangspåloggingsdata, API-tokener og påloggingstilstand for AI-assistenter. En kompromittert enhet kan derfor være et springbrett inn i kildekode, infrastruktur og produksjonssystemer.

AI-kodeassistenter legger til et ekstra lag. De er ofte autentisert over lange perioder og koblet til privat kode og prosjekter. Hvis en angriper får tak i tokenet som beviser at du er pålogget, kan de kanskje opptre som deg uten noensinne å se passordet ditt.

Dette passer inn i et bredere mønster der angripere retter oppmerksomheten mot AI-utviklingsverktøy. For bredere kontekst, se vår dekning av hvordan Claude Code ble våpenisert i et autonomt løsepengevirusangrep, som viser hvordan disse verktøyene kan misbrukes fra en annen retning.

Hvorfor stjålne økttokener omgår MFA

Flerfaktorautentisering (MFA) beskytter selve påloggingsøyeblikket. Den ber om noe utover passordet ditt, for eksempel en kode eller en forespørsel. Men etter at du har passert den sjekken, utsteder tjenesten en øktcookie eller et token som i praksis sier at denne brukeren allerede er verifisert.

Hvis skadevaren kopierer det tokenet, kan en angriper presentere det for tjenesten og hoppe over påloggingstrinnet helt. Det er ikke noe passord å gjette og ingen kode å avskjære, fordi beviset på verifisering allerede er stjålet. SSH-nøkler fungerer på lignende måte: en privat nøkkel på disken kan autentisere mot en server uten noen andrefaktor, med mindre nøkkelen selv er beskyttet.

Dette betyr ikke at MFA er ubrukelig. Det blokkerer fortsatt en stor andel kontoovertakelser, spesielt de som er avhengige av lekkede passord. Det kan bare ikke hjelpe når enheten selv er kompromittert og tokenene er hentet ut fra den. Det er derfor enhetshygiene er like viktig som sterke passord.

Hva dette betyr for deg

Hvis du skriver kode, administrerer servere eller bruker AI-assistenter med tilgang til private prosjekter, behandle arbeidsstasjonen din som en hvelv. Hemmelighetene som lagres på den er ofte verdt mer enn noe enkelt passord.

Selv om du ikke er utvikler, gjelder lærdommen. Nettlesere lagrer øktcookies, og skadevare som leser dem kan kapre kontoer som var beskyttet av MFA. Risikoen kommer fra at enheten er infisert, så det å holde den enheten ren er en del av å beskytte hver konto du bruker på den.

Praktiske trinn for å beskytte påloggingsdataene dine

  • Kartlegg hvor hemmelighetene ligger. Se etter API-nøkler, tokener og påloggingsdata i ren tekst-filer, miljøfiler, skallhistorikk og prosjektmapper. Flytt dem til en dedikert hemmelighetsbehandler eller operativsystemets sikre lagring.
  • Beskytt SSH-nøkler. Bruk en passfrase på private nøkler, og vurder maskinvarebaserte nøkler der det er mulig, slik at nøkkelen ikke bare kan kopieres.
  • Roter alt som kan være eksponert. Hvis du mistenker at en enhet var infisert, tilbakekall og utsted tokener, SSH-nøkler og skybaserte påloggingsdata på nytt fra en ren enhet. Logg ut av aktive økter overalt.
  • Bytt til phishing-resistent MFA. Passkeys og maskinvarebaserte sikkerhetsnøkler motstår phishing mye bedre enn SMS eller appkoder, selv om ingen MFA fullt ut løser tokenstyveri fra en infisert maskin.
  • Hold enheter rene. Installer oppdateringer, bruk anerkjent endepunktsbeskyttelse, unngå å kjøre uverifiserte skript eller pakker, og vær forsiktig med nedlastinger og e-postvedlegg.
  • Begrens privilegier og levetider. Bruk kortlivede tokener og de snevreste tillatelsene som fungerer, slik at en stjålet pålogging er mindre verdt.

Konklusjonen

Aokigahara-infostealerens kampanje mot AI-kodeverktøy viser at angripere følger påloggingsdataene, og de ligger nå i AI-assistenter og utviklermiljøer like mye som i passordfelt. Start med å kartlegge hvor hemmelighetene dine er lagret, roter eventuelle tokener og nøkler som kan ha blitt eksponert, og gå over til phishing-resistent MFA. For mer om hvordan angripere bruker AI-utviklingsverktøy til sin fordel, les rapporten vår om AI-kodeverktøy som misbrukes i angrep.