Steeds meer organisaties zetten AI-tools in voor werkprocessen. Juist daarom is het extra zorgwekkend dat aanvallers niet alleen wachtwoorden lijken te willen stelen, maar vooral tokens waarmee je al “toegang” hebt. In recente analyses van een grote infostealer-dump wordt duidelijk hoe AI tokens MFA omzeilen: gestolen sessiegegevens en API-sleutels kunnen opnieuw worden gebruikt om accounts te misbruiken, ook als MFA is ingeschakeld.
Wat dit lastig te detecteren maakt, is dat een succesvolle replay voelt als legitieme activiteit. Je authenticatiemoment is dan immers al geweest—de aanvaller herhaalt alleen het bewijs van toegang.
Wat er in de praktijk wordt gestolen
Infostealers zoals Lumma Stealer en Vidar zijn ontworpen om breed te verzamelen op een gecompromitteerde computer of server. Denk aan credentials, session tokens en API keys. Voor aanvallers zijn vooral tokens interessant, omdat ze vaak kunnen worden “teruggespeeld” om toegang te krijgen tot diensten van modelproviders.
In de onderzochte dataset ging het volgens Okta om een infostealer dump van 7 GB, die op 2 augustus 2026 op een Telegramkanaal werd gedeeld. Het log bevatte gegevens van 5.871 geïnfecteerde machines in 162 landen.
Waarom sessietokens en replay zo effectief zijn
Wanneer een sessietoken geldig is, is de gebruiker feitelijk al geauthenticeerd. In de analyse wordt daarom uitgelegd dat sessiegegevens kunnen dienen als “stolen keys”: een aanvaller kan met deze waarden een LLM-service benaderen alsof de echte gebruiker inlogt.
Okta wijst erop dat het replayen van sessie- en API-secrets misbruik mogelijk maakt, zelfs wanneer credential-based authenticatie en MFA normaal extra bescherming bieden. De omzeiling zit dus niet in het breken van MFA, maar in het benutten van materiaal dat MFA al heeft “gepasseerd”.
Concreet komt dit terug in twee tokenvormen:
- JWT’s (JSON Web Tokens): een geldige JWT kan worden misbruikt om directe accounttoegang te krijgen, zonder opnieuw username/wachtwoord en MFA te doorlopen.
- JWE’s (JSON Web Encryption): dit zijn versleutelde structuren rond JWT’s. Zelfs wanneer alleen de partij met de juiste sleutel de inhoud kan ontcijferen, kan een aanvaller soms toch replay gebruiken zolang tokens niet zijn verlopen.
Welke AI-diensten en tokens eruit springen
Okta meldt duizenden ongeexpireerde authenticatietokens die gekoppeld waren aan uiteenlopende diensten. Daarbij werden onder meer tokens genoemd voor Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com en Pika AI.
Van de 44.791 unieke JWT’s uit de dataset werden 555 JWT’s waarschijnlijk gelinkt aan authenticatie voor AI-diensten. Daarnaast werden 2.937 op authenticatie gerichte JWE-structuren gevonden. Okta geeft ook aan dat veel van deze JWE’s te maken lijken te hebben met een omgeving die NextAuth.js gebruikt (genoemd in verband met OpenAI).
Op de dag van publicatie in de dump werden volgens Okta 1.843 ongeexpireerde JWT’s en JWEs aangetroffen.
PII in tokens vergroot de schade
Naast toegang tot accounts is er nog een tweede reden waarom dit scenario extra riskant is. Een deel van de tokens bevatte volgens Okta plaintext persoonlijk identificeerbare informatie (PII). Dat ging om velden zoals naam, telefoonnummer of e-mailadres.
Okta rapporteert dat 17,7% van de JWT’s in de dataset zulke informatie bevatte. Omdat die gegevens in de tijd niet verdwijnen of “mee verlopen”, kunnen ze ook bruikbaar worden voor phishing en social engineering met een hoger overtuigingsgehalte.
API keys: van accounttoegang naar LLMjacking
Stelen beperkt zich niet tot tokens. De analyse met TruffleHog vond ook 24 nog geldige API-sleutels voor vier AI-gerelateerde diensten, waaronder Google Gemini, OpenAI, Groq en OpenRouter.
Met een API key kan een aanvaller diensten misbruiken voor espionage, afpersing of resource theft. In de context van AI heet dit misbruik vaak LLMjacking: aanvallers laten compute en premium modelgebruik op rekening komen van de eigenaar.
Het idee is vergelijkbaar met cryptomining-incidenten waarbij de rekenkosten verschoven worden naar het slachtoffer. Alleen gaat het hier om dure AI-requests.
Hoe aanvallers dit opschalen en doorverkopen
De waarde van gestolen tokens zit niet alleen in direct misbruik, maar ook in doorverkoop. Okta beschrijft dat de gestolen data als “stelerlogs” op undergroundfora wordt aangeboden, zodat andere partijen follow-on aanvallen kunnen uitvoeren.
In de gedeelde voorbeelden werden diensten en modellen genoemd die met korting zouden worden aangeboden. Daarnaast werden diensten gesignaleerd die claims doen over toegang tot specifieke AI-modellen en “24/7 ondersteuning” met garanties.
Okta benadrukt dat toegang met gestolen sessiedata specifieke tooling vereist. “Anti-detect” browsers en automatiseringstools kunnen helpen om gestolen authenticatiegegevens te laden uit opslag zoals browser storage (sessionStorage en localStorage) en controles te omzeilen die normaal ongebruikelijke patronen zouden opmerken.
Wanneer replay minder werkt
Niet elk scenario is even gevoelig. Okta noemt expliciet dat session replay mogelijk faalt wanneer organisaties gebruikmaken van IP allowlisting: alleen verkeer vanuit vooraf goedgekeurde IP-adressen of ranges wordt toegelaten.
Daarnaast heeft Google ondersteuning toegevoegd voor Device Bound Session Credentials (DBSC) in Chrome. Door sessietokens cryptografisch aan een specifiek apparaat te koppelen, wordt het hergebruiken van een token op een ander systeem moeilijker.
Praktische maatregelen om AI tokens MFA omzeilen te beperken
Als tokens “legitieme toegang” vertegenwoordigen, moet je beleid en techniek daarop aansluiten. Hieronder staan maatregelen die direct aansluiten op de genoemde aanvalsketen: van token-diefstal tot replay en accountmisbruik.
1) Monitor op hergebruik van sessies
Omdat replay technisch kan lijken op normale sessieactiviteit, is het belangrijk om signalen te verzamelen en te correleren. Let op patronen rond tokengebruik, sessie-starts en afwijkende locaties of tijden.
2) Beperk de levensduur van tokens
Okta adviseert het gebruik van OAuth 2.0-flows met korte-lived tokens. Hoe sneller tokens verlopen, hoe minder waarde ze hebben wanneer een aanvaller ze weet te bemachtigen.
3) Scope API keys en minimaliseer rechten
Wanneer API keys worden gestolen, wil je beperken wat er mogelijk is. Werk daarom met scope-based permissies en minimaliseer rechten per key, zodat misbruik minder impact heeft.
4) Gebruik phishing-resistente authenticatie waar mogelijk
Er wordt in de analyse aangegeven dat passkeys username/wachtwoord-aanvallen bemoeilijken. Tegelijk blijft gelden dat sterke login niet genoeg is als sessiegegevens of API sleutels al zijn buitgemaakt. Zie passkeys dus als onderdeel van een breder pakket.
5) Zet restricties in die replay lastiger maken
Overweeg, waar passend bij je organisatie, maatregelen zoals IP allowlisting. En volg browser- en platformontwikkelingen die tokens aan apparaten binden, omdat dit replay op andere systemen bemoeilijkt.
Extra context: cloud-compromissen en AI-compute misbruik
De publicatie koppelt tokenmisbruik ook aan bredere cloudrisico’s. In ten minste één incidentresponse door Mandiant werd een aanvaller gevonden die via een exposed GitHub Personal Access Token (PAT) aanvankelijk toegang verkreeg tot een cloudomgeving. Vervolgens werd AI-infrastructuur uitgerold om compute resources te schalen.
Wil je meer achtergrond over het beveiligen van toegang en het beperken van ongeautoriseerde resource-inzet, dan is dit mogelijk ook relevant: MikroTik supply chain risico blokkeren en MikroTrick.
Snelle checklist voor teams die AI gebruiken
Als je AI-diensten in het bedrijf gebruikt (zoals chatinterfaces, agents of codingtools), pak dit dan pragmatisch aan:
- Inventariseer waar je sessies en tokens bewaart (en hoe lang die geldig blijven).
- Controleer of je OAuth- en API-implementaties korte-lived tokens ondersteunen.
- Werk met beperkte scopes voor API keys en rouleer sleutels regelmatig.
- Zoek naar logging/monitoring die afwijkend token- of sessiegebruik signaleert.
- Overweeg extra restricties zoals IP allowlisting wanneer dat haalbaar is.
Conclusie
De kern van het probleem is helder: AI tokens MFA omzeilen niet door MFA te “breken”, maar door materiaal te hergebruiken dat al geauthenticeerde toegang vertegenwoordigt. Wanneer infostealers sessietokens, JWT/JWE-structuren en API-sleutels buitmaken, kan een aanvaller met replay of API-abuse alsnog misbruik maken van AI-diensten.
Door tokens kort te laten leven, rechten te beperken, sessiereplay te detecteren en waar mogelijk sessies aan apparaatcontext te binden, verklein je de kans dat gestolen toegang uitgroeit tot accountdiefstal of LLMjacking.
Bron: https://thehackernews.com/2026/09/infostealer-logs-expose-replayable-ai.html
