Een nieuw waargenomen infostealer genaamd Aokigahara jaagt op de plekken waar ontwikkelaars hun meest waardevolle geheimen bewaren: AI-codeassistenten, ontwikkelaarswerkstations en cloudreferenties. De Aokigahara-infostealer AI-codeertools-campagne is een herinnering dat aanvallers steeds minder om je wachtwoord geven en meer om de tokens, sleutels en sessiebestanden die je apparaten stilletjes opslaan.

De openbare details over deze malware zijn beperkt, dus dit bericht houdt zich aan wat er is gemeld en legt uit waarom de techniek ertoe doet.

Hoe Aokigahara inloggegevens en sessietokens steelt

Volgens de berichtgeving is Aokigahara een infostealer, een soort malware die op een geïnfecteerde machine draait, gevoelige bestanden en opgeslagen gegevens verzamelt en naar een aanvaller verstuurt. De gemelde doelwitten omvatten AI-codeassistenten, ontwikkelaarswerkstations en cloudreferenties, met als voornaamste items inlogtokens, SSH-sleutels en cloudtoegangsmateriaal.

Infostealers hoeven niet op de moeilijke manier in een account in te breken. Zodra malware op een apparaat draait, kan het bestanden lezen die applicaties achterlaten om je ingelogd te houden. Daarom kan één geïnfecteerde laptop meerdere diensten tegelijk blootstellen: de browser, de code-editor, de commandoregel en alle cloudtooling die op dezelfde machine is geconfigureerd.

Het bronartikel is kort, dus we kunnen niet zeggen hoe Aokigahara wordt verspreid of hoeveel mensen zijn getroffen. We gaan niet gissen. Wat duidelijk is, is de categorie gegevens die het wil, en die categorie is op zichzelf al de moeite waard om te begrijpen.

Waarom ontwikkelaars en cloudaccounts waardevolle doelwitten zijn

Ontwikkelaarsmachines zijn ongewoon rijk. Een typisch werkstation kan SSH-sleutels voor servers en coderepositories, cloudtoegangsreferenties, API-tokens en aanmeldstatus voor AI-assistenten bevatten. Eén gecompromitteerd apparaat kan daarom een opstapje zijn naar broncode, infrastructuur en productiesystemen.

AI-codeassistenten voegen een extra laag toe. Ze zijn vaak langdurig geauthenticeerd en gekoppeld aan privécode en projecten. Als een aanvaller het token verkrijgt dat bewijst dat je bent ingelogd, kan hij mogelijk namens jou handelen zonder ooit je wachtwoord te zien.

Dit past in een breder patroon waarbij aanvallers hun aandacht richten op AI-ontwikkeltools. Voor meer context, zie onze berichtgeving over hoe Claude Code werd bewapend in een autonome ransomware-aanval, die laat zien hoe deze tools vanuit een andere richting kunnen worden misbruikt.

Waarom gestolen sessietokens MFA omzeilen

Multi-factor authenticatie (MFA) beschermt het moment van inloggen. Het vraagt om iets naast je wachtwoord, zoals een code of een prompt. Maar nadat je die controle hebt doorstaan, geeft de dienst een sessiecookie of token uit dat in feite zegt: deze gebruiker is al geverifieerd.

Als malware dat token kopieert, kan een aanvaller het aan de dienst presenteren en de inlogstap volledig overslaan. Er is geen wachtwoord om te raden en geen code om te onderscheppen, omdat het bewijs van verificatie al is gestolen. SSH-sleutels werken op dezelfde manier: een privésleutel op schijf kan zich bij een server authenticeren zonder enige tweede factor, tenzij de sleutel zelf is beschermd.

Dit betekent niet dat MFA nutteloos is. Het blokkeert nog steeds een groot deel van accountovernames, vooral die welke op gelekte wachtwoorden vertrouwen. Het kan alleen niet helpen zodra het apparaat zelf is gecompromitteerd en de tokens ervan zijn gestolen. Daarom is apparaathygiëne net zo belangrijk als sterke wachtwoorden.

Wat dit voor jou betekent

Als je code schrijft, servers beheert of AI-assistenten gebruikt met toegang tot privéprojecten, behandel je werkstation dan als een kluis. De geheimen die erop zijn opgeslagen zijn vaak meer waard dan welk afzonderlijk wachtwoord dan ook.

Zelfs als je geen ontwikkelaar bent, geldt de les. Browsers slaan sessiecookies op, en malware die ze leest kan accounts kapen die door MFA werden beschermd. Het risico komt voort uit het feit dat het apparaat is geïnfecteerd, dus dat apparaat schoon houden is onderdeel van het beschermen van elk account dat je erop gebruikt.

Praktische stappen om je referenties te beschermen

  • Controleer waar geheimen zich bevinden. Zoek naar API-sleutels, tokens en referenties in platte tekstbestanden, omgevingsbestanden, shell-geschiedenis en projectmappen. Verplaats ze naar een speciale secrets manager of de beveiligde opslag van je besturingssysteem.
  • Bescherm SSH-sleutels. Gebruik een wachtwoordzin op privésleutels en overweeg waar mogelijk hardware-ondersteunde sleutels, zodat de sleutel niet simpelweg kan worden gekopieerd.
  • Roteer alles wat mogelijk is blootgesteld. Als je vermoedt dat een apparaat is geïnfecteerd, trek tokens, SSH-sleutels en cloudreferenties in en geef ze opnieuw uit vanaf een schoon apparaat. Meld je overal af van actieve sessies.
  • Stap over op phishingbestendige MFA. Passkeys en hardware-beveiligingssleutels weerstaan phishing veel beter dan sms- of app-codes, hoewel geen enkele MFA het probleem van tokendiefstal van een geïnfecteerde machine volledig oplost.
  • Houd apparaten schoon. Installeer updates, gebruik betrouwbare endpoint-beveiliging, vermijd het uitvoeren van niet-geverifieerde scripts of pakketten en wees voorzichtig met downloads en e-mailbijlagen.
  • Beperk privileges en levensduur. Gebruik kortlevende tokens en de nauwste rechten die werken, zodat een gestolen referentie minder waard is.

De conclusie

De Aokigahara-infostealer AI-codeertools-campagne laat zien dat aanvallers de referenties volgen, en die bevinden zich nu net zo goed in AI-assistenten en ontwikkelomgevingen als in wachtwoordvelden. Begin met het controleren waar je geheimen zijn opgeslagen, roteer alle tokens en sleutels die mogelijk zijn blootgesteld en sticht over op phishingbestendige MFA. Lees voor meer over hoe aanvallers AI-ontwikkeltools in hun voordeel omzetten ons rapport over AI-codeertools die worden misbruikt in aanvallen.