LLMjacking komt steeds vaker in beeld: aanvallers kapen toegang tot Large Language Model (LLM)-diensten en gebruiken jouw accounts om kostbare reken- en AI-capaciteit af te nemen. Het resultaat is niet alleen ongeautoriseerd gebruik, maar ook directe financiële schade via opgeblazen cloud- en AI-facturen. Google en Mandiant waarschuwen dat dit type aanval binnen enkele uren kan escaleren tot zeer hoge kosten.
Waar klassiek resource hijacking vaak traag en geleidelijk verloopt, is LLMjacking juist gericht op snelle misbruikpieken. In de rapportage worden incidenten genoemd waarbij de frauduleuze resourceconsumptie op één dag boven $100.000 uitkwam en cumulatief bij sommige organisaties richting $1 miljoen steeg voordat de toegang werd ingetrokken.
Wat is LLMjacking precies?
Bij LLMjacking bemachtigt een aanvaller toegang tot LLM-accounts of API’s, zodat de echte eigenaar de kosten draagt. De kern is dat er een manier wordt gevonden om een API-key of een token te verkrijgen waarmee de aanvaller calls kan doen naar de achterliggende modelresources.
Google beschrijft meerdere routes waarlangs dat kan gebeuren, zoals phishing, gelekte credentials, misconfiguraties of blootgestelde client-side code. Zodra een aanvaller die toegang heeft, kan hij of zij LLM-verzoeken verwerken, zelfs zonder dat er een “klik” van een gebruiker nodig is.
In de praktijk lopen er meerdere varianten door elkaar. Aan de ene kant zijn er minder directe vormen waarbij bijvoorbeeld customer-support chatbots worden misbruikt om ongeautoriseerd werk te doen. Aan de andere kant richten aanvallen zich rechtstreeks op de backend-modelbronnen, bijvoorbeeld door publieke LLM-endpoints te vinden of geldige API-sleutels te bemachtigen.
Hoe herkennen aanvallen zich in je omgeving?
LLMjacking laat vaak duidelijke signalen achter. Let vooral op ongebruikelijke activiteit rondom LLM-verzoeken en het gebruik van credentials die niet te herleiden zijn tot een normaal productietraject.
Typische vroege signalen
- Scherpe pieken in cloud- of AI-kosten binnen korte tijd, zonder bijbehorende toename in legitiem gebruik.
- Onverklaarde calls naar LLM-API’s vanuit netwerken of services waar je die normaliter niet verwacht.
- Toename van tokengebruik of gewijzigde patronen in authenticatie (bijvoorbeeld andere tokens, andere service accounts, nieuwe API keys).
- Nieuwe of afwijkende accounts in IAM die tijdelijk toegang genereren of persistence mogelijk maken.
Google koppelt de oorzaak vaak aan gestolen of blootgestelde identiteitstokens, zoals IAM-credentials, service account keys, GitHub Personal Access Tokens (PAT’s) en actieve sessietokens. Dat maakt het extra belangrijk om niet alleen naar LLM-logboeken te kijken, maar ook naar identity- en toegangslagen.
Veelgebruikte ingangen: van phishing tot misconfiguratie
De aanvallers die Google in beeld brengt, beginnen doorgaans met het bemachtigen van toegang tot je infrastructuur of tokens die LLM-gebruik mogelijk maken. De meest voorkomende routes die worden genoemd, zijn blootgestelde of gestolen cloud-identiteitstokens.
Een voorbeeld dat in de rapportage naar voren komt, is een actor (UNC6993) die via een misconfigured service account key een cloud-instantie kon binnendringen. Vervolgens werd die toegang gebruikt om een LLM API te bereiken.
In hetzelfde beschreven geval werd ook een pagina ingezet die leek op een portaal voor een applicatie waarmee LLM-gebruikers een groep konden joinen. De slachtoffers kregen een prompt om een raw JSON payload met een actief access token te “plakken” richting de backend. Daarmee konden wachtwoord- en MFA-controles worden omzeild, doordat de token al geldig was.
Daarnaast noemt Google gevallen waarin een gestolen GitHub PAT werd ingezet om private code repositories te benaderen. Daarna volgde uitbuiting van vermoedelijke webapp-kwetsbaarheden in een omgeving die draait in een containerized cloud setup.
Andere routes zijn het compromitteren van IAM-gegevens van medewerkers, zodat aanvallers programmatisch nieuwe access keys kunnen aanmaken en MFA-protecties kunnen omzeilen. Ook wordt genoemd dat een gestolen service account key met brede permissies gecombineerd kan worden met LLM-API-sleutels die uit openbare GitHub-repositories zijn gehaald.
Na binnenkomst: privileges, persistence en reconnaissance
Zodra een aanvaller voet aan de grond heeft, blijft het niet bij “even proberen”. Google beschrijft dat de aanvallers snel verdergaan met het vergroten van privileges en het dieper doordringen in de cloudomgeving.
Daarbij worden onder meer de volgende activiteiten waargenomen:
- Cloud services en code repositories inventariseren om gevoelige credentials te vinden.
- Interne verkenning uitvoeren over meerdere cloudregio’s om identiteitsbeleid en beschikbare diensten in kaart te brengen.
- Codebases klonen om hard-coded secrets en developer credentials terug te vinden.
- Toegangslogs doorzoeken om credentials te vinden die verwijzen naar andere cloudomgevingen.
- Queries op databases uitvoeren om extra inloggegevens te verzamelen.
- Permissies en VM-configuraties misbruiken om privileges te escaleren en toegang te behouden.
Ook persistence-mechanismen komen voor, zoals het aanmaken van ongeautoriseerde IAM- en service accounts en het injecteren van SSH-sleutels in compute-instances.
Verder wordt beschreven dat token-creation privileges rond service accounts kunnen worden misbruikt om tijdelijk toegangen te maken voor hoogprivilege service accounts. Daarmee kunnen aanvallers credentials exfiltreren uit secret managers, inclusief interne database-wachtwoorden en API-sleutels van derden.
Hoe verdienen criminelen eraan: monetisatie en omleiding
Het uiteindelijke doel van LLMjacking is monetisatie en resource-hijacking van foundation models. Google benoemt daarbij manieren als token proxying, geautomatiseerde model-streaming en het inschakelen van GPU-hardware via provisioning in de cloud.
Daarnaast zetten aanvallers hun toegang in om eigen proxy-endpoints en agentic workloads te hosten. In de voorbeelden wordt genoemd dat aanvallers extra API keys aanmaakten om hun activiteiten op te schalen binnen victim cloud-projecten, wat direct tot hoge billing leidde.
Ook wordt er gesproken over strategieën om rate limits te omzeilen, zoals “burn and rotate”: continu korte-lived service accounts aanmaken en verwijderen om throttling te ontwijken.
Opvallend is ook de opkomst van een nieuw type actoren dat in de rapportage als LLM Mixers wordt aangeduid. Dit wijst op een verdeling van werk: een partij focust op initieel binnendringen en het regelen van toegang, terwijl een andere partij de downstream monetisatie-infrastructuur beheert.
LLM Mixers: illegale routingmarktplaatsen
LLM Mixers fungeren als illegale routing gateways die ongeautoriseerde LLM-toegang proxy’en, aggregeren en doorverkopen aan andere criminelen. Dat gebeurt via underground storefronts, waarbij de slachtoffers vaak pas laat merken wat er is gebeurd.
In de rapportage worden diensten genoemd zoals Jet Night, beschreven als een aanbieder met een “unlimited token plan” rond $60 per maand. De kern is dat enterprise-quota worden gesipthe terwijl de billing uiteindelijk bij de slachtoffers terechtkomt nadat compromissen gedetecteerd worden.
Daarnaast wijst Google op bevindingen van Symantec en Carbon Black (van Broadcom) over een grey-market relay service die officiële CLI-tools zoals OpenAI Codex en Anthropic Claude Code installeert, maar daarna herconfigureert om requests via derde partijen te laten lopen.
Volgens de beschrijving gebeurt dat zonder een gemodificeerde of “trojanized” client. De tool wordt normaal geïnstalleerd via npm, maar gebruikers krijgen vervolgens een commando om een setupscript op te halen vanaf een lookalike domein. Dat script zet sandboxing uit, herschrijft configuratiebestanden, schakelt telemetry en error reporting uit en vervangt echte API-credentials door relay-issued tokens. Ook wordt gecontroleerd of de Windows-locale overeenkomt met een regio waarin de service actief is.
Er is volgens de bevindingen geen directe aanwijzing dat prompts worden afgetapt of dat antwoorden worden gefabriceerd. Toch laat het zien hoe risicovol het is om AI-tools te gebruiken die via omwegen toegang omleiden.
Wat kun je nu doen om LLMjacking te voorkomen?
Je kunt LLMjacking niet volledig “wegregelen” met één maatregel. Wel kun je het risico fors verkleinen door identiteit, secrets en LLM-gebruik samen te bewaken.
Praktische verdedigingsstappen
- Beperk en controleer API keys en tokens. Zorg dat keys niet breed of onbeperkt permissies hebben.
- Stuur alerts op kostenpieken en ongebruikelijke LLM-aanroepen. Richt dit niet alleen op cloud-billing, maar ook op model-API logging.
- Beperk service account permissies en voorkom misconfiguraties. Gebruik waar mogelijk least privilege.
- Controleer toegangspaden naar ontwikkel- en codeomgevingen (zoals GitHub PAT’s en repositorytoegang), want die kunnen dienen als springplank.
- Monitor voor IAM- en service account wijzigingen. Nieuwe accounts of sleutels die geen onderdeel zijn van een change proces zijn rode vlaggen.
- Voorkom dat CLI- of tooling-pakketten ongecontroleerd worden hergeconfigureerd. Gebruik alleen vertrouwde bronnen en maak integriteit zichtbaar.
Als je meer wilt weten over hoe je AI- en securityprocessen inricht vóórdat je live gaat, kan dit aansluiten op een eerdere uitleg over Bron: https://thehackernews.com/2026/11/google-warns-llmjacking-attacks-are.html
