LLMjacking: hackers draaien AI op jouw cloudrekening
Aanvallers kapen steeds vaker de AI-diensten binnen bedrijfscloudomgevingen en laten de rekening bij het slachtoffer achter. Google Threat Intelligence Group (GTIG) en Mandiant beschrijven in een onderzoeksrapport incidenten waarbij de frauduleuze kosten in één dag boven de 100.000 dollar uitkwamen, en bij sommige organisaties cumulatief opliepen tot een miljoen dollar voordat de toegang werd ingetrokken. De onderzochte slachtoffers zaten in Noord-Amerika, Zuid-Amerika en Azië-Pacific, in de financiële sector, retail, techniek en transport.
Je hoeft zelf geen AI te gebruiken
Het meest verrassende punt uit het rapport: in meerdere onderzochte incidenten stónden de LLM-diensten helemaal niet aan op het moment van de inbraak. De aanvallers gebruikten gestolen toegangssleutels om diensten als Amazon Bedrock of de Gemini API zélf in te schakelen, en konden daarna in minuten tot uren een enorme rekening genereren. Een organisatie die bewust geen AI afneemt, is dus niet automatisch veilig. GTIG adviseert daarom het ínschakelen van een LLM-dienst te behandelen als een kritiek beveiligingsincident.
Gestolen sleutels, geen exotisch lek
De voornaamste toegangsweg is geen kwetsbaarheid maar een sleutel. Het rapport noemt blootgestelde of gestolen IAM-credentials, service-accountsleutels, GitHub personal access tokens en actieve sessietokens. In één geval oogstte een aanvaller bedrijfs-API-sleutels uit publieke GitHub-repositories en verifieerde die met minimale verzoeken van één token, om onder de drempelwaarden van EDR en SIEM te blijven. Een ander cluster, UNC6993, zette een nagemaakt applicatieportaal op waarmee gebruikers hun actieve toegangstoken zelf plakten, waarmee wachtwoord en mfa werden omzeild.
De gestolen toegang gaat door naar zogeheten LLM mixers: proxydiensten die het verbruik van hun abonnees via gekaapte sleutels routeren. De provider ziet legitiem verkeer en factureert het slachtoffer.
Ook de gateway is doelwit
In één onderzoek misbruikte een aanvallerscluster CVE-2026-40217 in LiteLLM, een veelgebruikte model-gateway, om gewone Virtual Keys op te waarderen tot volledige beheerderssleutels. Dat lek is niet nieuw: het GitHub-advisory staat sinds mei online en noemt versie 1.83.11 als de fix. Wie zo'n gateway draait maar hem buiten zijn patchbeheer houdt, loopt dus achter op een bekend probleem.
Wat je nu kunt doen
Uit de aanbevelingen van GTIG, toegespitst op wat een beheerder vandaag kan controleren:
- Zet uitgavenlimieten en budgetwaarschuwingen op je cloudaccounts, plus quota per model. Dat is het enige wat een uitschieter van 100.000 dollar per dag echt begrenst.
- Ontzeg service-accounts en gebruikers expliciet toegang tot LLM-diensten die ze niet nodig hebben, in plaats van ze alleen niet te gebruiken.
- Monitor in Azure de
Microsoft.CognitiveServices-namespace in je Activity Logs, en let opaccounts/deployments/writevoor nieuwe deployments. - Let op bij Google Cloud: de Data Access-logs die modelaanroepen vastleggen staan standaard uit vanwege het volume. Je moet je IAM-auditbeleid handmatig aanzetten om dit te zien.
- Scan je repositories automatisch op secrets en roteer sleutels centraal, zodat een gelekte sleutel een beperkte levensduur heeft.
- Segmenteer API-sleutels per model-endpoint en per omgeving, zodat een token voor een goedkoop hulpmodel geen dure frontier-modellen kan aanroepen.