LLMjacking: Wenn Angreifer LLMs auf Ihre AWS-Rechnung buchen

Ein Sandbox-Account, der normalerweise 120 $ pro Tag kostet, verursacht in vierzehn Stunden 85.000 $. Ein ruhender Member-Account, elf Monate lang unangetastet, läuft auf 75.000 $ auf, bevor jemand die Rechnung öffnet. Der Account eines europäischen Händlers springt in weniger als zwei Tagen von ein paar Hundert Dollar im Monat auf 522.000 $.

Keiner dieser Angreifer hat Daten gestohlen oder Ransomware eingesetzt. Sie haben Cloud-Zugangsdaten erbeutet und damit die teuersten Large Language Models auf Amazon Bedrock aufgerufen – die Rechnung blieb beim Opfer. Das ist LLMjacking. 2026 ist es zu einem der häufigsten – und teuersten – Sicherheitsvorfälle geworden, die beim Support-Team von DoiT landen.

Dieser Beitrag erklärt, wie der Angriff funktioniert und was wir in den Vorfällen dieses Jahres gesehen haben. Anschließend gehen wir die AWS-Kontrollen durch, die ihn verhindern. Zum Schluss zeigen wir, wie Sie DoiT Cloud Intelligence™ (DCI) so einrichten, dass Sie es durch einen Alert erfahren – und nicht durch Ihre Rechnung.

Teil 1: AWS-Kontrollen, die LLMjacking verhindern

Entfernen Sie die Zugangsdaten, die sich zu stehlen lohnen

• Stellen Sie keine langlebigen IAM-User-Keys mehr aus. Nutzen Sie IAM Identity Center für Menschen. Geben Sie Workloads IAM-Rollen mit temporären Credentials: OIDC für GitHub Actions, IRSA oder EKS Pod Identity sowie Instance Profiles. Die IAM Best Practices von AWS sind hier eindeutig.
• Auditieren Sie die Keys, die Sie bereits haben. Löschen Sie Keys, die 90 Tage lang nicht genutzt wurden; belassen Sie es nicht beim Deaktivieren. AWS verlangt die Löschung nach einem Vorfall ohnehin. Legen Sie geteilte Keys niemals in CI-Variablen, Helm-Values oder Agent-/MCP-Credential-Dateien ab.
• Behandeln Sie Bedrock-API-Keys wie Secrets. Bevorzugen Sie kurzlebige Keys mit bis zu 12 Stunden Laufzeit, und inventarisieren und begrenzen Sie alle langlebigen (AWS).
• Aktivieren Sie Secret Scanning und Push Protection in Ihrer Versionsverwaltung (GitHub). Wenn AWS die Policy AWSCompromisedKeyQuarantineV3 an einen Ihrer User anhängt, starten Sie die Incident Response. Die Policy begrenzt, was der Key tun kann, entfernt den Angreifer aber nicht (AWS).

Root schützen

Nutzen Sie Hardware-MFA, keine Root Access Keys und eine Root-E-Mail-Adresse auf einer Domain, die Sie kontrollieren und aktiv überwachen. Hinterlegen Sie die alternativen Kontakte SECURITY und OPERATIONS in jedem Account – auch in den ruhenden –, damit die Warnungen von AWS jemanden erreichen, der sie liest.

Leitplanken auf Organisationsebene einziehen

IAM Least Privilege sollte jeden Workload auf die konkreten Modelle und Regionen beschränken, die er benötigt (AWS-Policy-Beispiele). Service Control Policies ergänzen dann eine Absicherung, die ein kompromittierter Principal nicht entfernen kann. Hier ein Ausgangspunkt – zunächst in einer Nicht-Produktions-OU zu testen:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMarketplaceSubscribeExceptPlatformRole",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ai-platform-admin" }
      }
    },
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] }
      }
    },
    {
      "Sid": "DenyFederationTokenConsoleBypass",
      "Effect": "Deny",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    }
  ]
}

Einige Hinweise zur Vorsicht. Cross-Region-Inference-Profile leiten Requests in andere Regionen – validieren Sie die Regionsbedingung also gegen die Profile, die Sie tatsächlich nutzen (AWS). Manche Accounts sollten generative KI nie nutzen: Sandboxes, ruhende Accounts und die meisten Produktions-Accounts außerhalb Ihrer KI-Plattform. Für diese ist ein schlichtes Deny auf bedrock:* einfacher und sicherer.

Begrenzen, wie schnell Geld abfließen kann

• Senken Sie die Bedrock-Tokens-pro-Minute-Quotas auf das, was jeder Workload braucht, und verlangen Sie Freigaben für Erhöhungen (AWS). Eine Quota deckelt die Rate, nicht die Gesamtsumme – aber sie verschafft Ihnen Zeit.
• Halten Sie Experimente in abgegrenzten Accounts mit eigenen Budgets.

Protokollieren und erkennen

• Ein multiregionaler Organisations-CloudTrail, der in einen abgeschotteten Log-Archiv-Account geliefert wird.
• Bedrock Model Invocation Logging für freigegebene Workloads (AWS).
• Amazon GuardDuty in jedem Account und jeder Region, mit aktivierten KI-bezogenen Schutzfunktionen. Nach einem Vorfall prüfte AWS die Sicherheitsdienste im betroffenen Member-Account, nicht nur im Management-Account.
• Alerts auf die Signale, die in echten Vorfällen früh auftauchten:
  • neue Marketplace-Vereinbarungen
  • GetFederationToken-Aufrufe
  • CreateAccessKey, aufgerufen von einer Assumed Role
  • Root-Anmeldungen oder MFA-Änderungen
  • plötzliche Sprünge im SES-Sendevolumen

Teil 2: DoiT Cloud Intelligence als Stolperdraht einrichten

DCI ersetzt weder GuardDuty noch CloudTrail. Sein Wert liegt hier darin, dass es eine Kostenkontrollebene außerhalb Ihrer AWS-Accounts ist. Ein Angreifer mit Ihren AWS-Keys kann AWS Budgets lesen und bearbeiten – genau das haben wir erlebt. Auf die Alerts und Budgets, die Sie in DCI konfiguriert haben, hat er keinen Zugriff.

Alerts, Budgets und Anomalieerkennung überwachen die Ausgaben. Composer und Security Insights schließen die Lücken, über die Angreifer eindringen. CloudFlow macht aus jedem dieser Signale eine Benachrichtigung, ein Ticket oder einen freigegebenen Eindämmungsschritt.

1. Schwellenwert-Alerts, die keine Baseline benötigen

Alerts lösen auf Basis einer festen Regel aus und funktionieren daher ab Tag eins – auch bei einem Modell, das Sie nie genutzt haben. Das ist die verlässlichste DCI-Kontrolle gegen LLMjacking.

• Erstellen Sie eine Allocation, die alle KI-Modellausgaben bündelt: Amazon Bedrock und die Marketplace-Produkte "(Amazon Bedrock Edition)". Neue Modelle fließen dann automatisch hinein, und Ihre Alerts verpassen den Modell-Launch des nächsten Monats nicht stillschweigend.
• Täglicher Ausgaben-Alert pro Account: Begrenzen Sie ihn auf diese Allocation, mit Metric auf Cost und Interval auf Daily. Setzen Sie die Bedingung auf is > $X, wobei X das Zwei- bis Dreifache eines normalen Tages ist. Aktivieren Sie Evaluate for each: Account, damit eine Regel jeden Account abdeckt.
• "Sollte null sein"-Alert: Für Sandboxes, ruhende Accounts und alles, was keine KI-Workloads betreibt: Alert bei > $10 pro Tag.
• Sprung von Tag zu Tag: percentage change is > 100%.
• Forecast-Alert: monatlich, is forecasted to be > Ihre geplanten KI-Ausgaben.

Leiten Sie Alerts an E-Mail und einen Slack-Channel, den tatsächlich jemand im Blick hat (Slack-Alert-Zustellung).

2. Budgets auf jedem Account – gerade auf den stillen

Legen Sie auf jeden AWS-Account ein wiederkehrendes monatliches Budget mit Schwellen bei 50 %, 85 % und 100 %. Budget-Vorschläge können die Höhe für Sie bemessen. Ergänzen Sie ein Tagesbudget auf der KI-Allocation als zweiten, leicht lesbaren Stolperdraht. Ruhende und Sandbox-Accounts sind die Lieblingsziele von Angreifern – genau weil niemand sie budgetiert. Ein 0-$-Account mit einem 50-$-Budget ist ein sehr guter Alarm.

Budgets stoppen die Ausgaben nicht, aber sie melden sie Ihnen von außerhalb des kompromittierten Accounts.

3. Anomalieerkennung so einstellen, dass sie Sie wirklich erreicht

Kosten-Anomalieerkennung hat weiterhin ihre Berechtigung, besonders für die EC2-, GPU- und SageMaker-Seite eines Angriffs. Drei Einstellungen sind entscheidend:

• Weiten Sie den Schweregrad-Filter aus. E-Mail-Benachrichtigungen stehen standardmäßig nur auf Critical. Stellen Sie sie auf "Warning and above" oder "All severity levels" (Benachrichtigungseinstellungen).
• Aktivieren Sie die erneute Benachrichtigung, damit eine aktive, weiter wachsende Anomalie Sie erneut anstößt.
• Stellen Sie sicher, dass ein Empfänger konfiguriert ist. In mehr als einem Vorfall hat DCI die Anomalie erkannt, aber niemand hat davon erfahren. Es war kein Benachrichtigungsziel gesetzt.

In den Plänen Enhanced und Enterprise aktivieren Sie die Echtzeit-Anomalieerkennung für AWS. Sie arbeitet auf Basis von CloudTrail und meldet innerhalb von etwa einer Stunde. Aktuell deckt sie EC2 und RDS ab, nicht Bedrock. Damit fängt sie trotzdem die GPU- und Instanz-Hälfte des Angriffs ab, die oft parallel zum Modellmissbrauch läuft. Sie können die Anomalieerkennung auch direkt auf der KI-Allocation aktivieren (Allocation-Monitoring).

Wenn Sie KI-Workloads mit Attribute instrumentieren, bietet DoiT zudem Usage-Anomalien auf Token-Ebene im Early Access an. Sie können einen außer Kontrolle geratenen Workload schneller melden als Abrechnungsdaten. Sie sehen allerdings nur den Traffic Ihrer eigenen instrumentierten Hosts und erkennen daher keinen gestohlenen Key, der von der Maschine eines Angreifers aus genutzt wird.

4. Die Erstreaktion mit CloudFlow automatisieren

CloudFlow kann auf DCI-Alerts, Budget-Schwellen und Kostenanomalien triggern und macht so aus einer Benachrichtigung eine Aktion:

• Alert → Slack → Freigabe → Eindämmung. Wenn der Bedrock-Alert auslöst, posten Sie Account und Betrag in Ihren Incident-Channel. Nach menschlicher Freigabe führen Sie dann eine AWS-Aktion aus: Deaktivieren Sie den verdächtigen Access Key, oder hängen Sie ein explizites Deny auf bedrock:InvokeModel* und bedrock:Converse* an. Freigabeschritte verhindern, dass ein False Positive die Produktion lahmlegt.
• Erkennung erstmaliger Service-Nutzung. Ein geplantes Flow-Template markiert die erste Ausgabe auf jedem AWS-Service oder jeder SKU. Das schließt die oben beschriebene Lücke bei neuen Modellen.
• API-Keys von KI-Anbietern widerrufen. Ein Webhook-gesteuertes Template mit eingebauter Freigabe löscht langlebige Bedrock-Credentials (und OpenAI-, Anthropic- oder Gemini-Keys). Sie können es aus EventBridge, Ihrem SIEM oder einem GuardDuty-Finding heraus aufrufen (Tutorial).

Für jede Eindämmungsaktion muss die CloudFlow-Rolle im Ziel-Account über die passenden IAM-Berechtigungen verfügen. Legen Sie diese Berechtigungen vor einem Vorfall fest.

5. Die Lücken schließen, bevor ein Angreifer sie findet

Security Insights führt Findings aus AWS Security Hub und Trusted Advisor zusammen. Dazu gehören nicht rotierte Access Keys, Root-Accounts ohne MFA und Accounts ohne GuardDuty oder CloudTrail. Fast jeder der oben beschriebenen Vorfälle begann mit einem dieser Probleme.

Diese Findings nutzen die generischen Regeln von AWS. Mit Composer schreiben Sie eigene – in den Plänen Enhanced und Enterprise. Composer ist die Policy-Engine von DCI. Sie scannt die Ressourcen in jedem verbundenen Account und prüft sie gegen Recipes – Regeln, die Sie ohne Code erstellen. Sie können ein DoiT-Recipe duplizieren und anpassen oder den Check dem KI-Assistenten beschreiben. Treffer erscheinen als Security Insights.

So lassen sich die Lücken hinter den Vorfällen dieses Jahres auf Recipes abbilden, die Sie heute bauen können:

Die letzte Zeile ist das Nächste an Missbrauchserkennung, was Composer leisten kann. Ein Key in einem Sandbox-Account, der zuletzt für Bedrock genutzt wurde, verdient einen Blick – auch wenn sich die Ausgaben noch nicht bewegt haben.

Um auf die Findings zu reagieren, planen Sie einen CloudFlow, der offene Security-Findings über den Composer-Insights-Node liest. Posten Sie sie jeden Morgen in Slack oder öffnen Sie ein Ticket. Für veraltete Keys ergänzen Sie einen Freigabeschritt, der den Key deaktiviert, sobald der Besitzer bestätigt, dass er ungenutzt ist.

Composer führt periodische Scans aus und ist damit eine Hygiene-Kontrolle, kein Angriffsalarm. Er prüft weder den Status von GuardDuty oder Security Hub noch Bedrock Invocation Logging, Bedrock-API-Keys oder SCP-Inhalte. Das übernehmen Security Insights und AWS Config. Nutzen Sie Composer, um die Türen zu schließen, durch die Angreifer dieses Jahr gegangen sind – und die Schwellenwert-Alerts oben für die Ausgaben selbst.

Wenn es trotzdem passiert

Beginnen Sie mit der Eindämmung, sobald Sie eine Kompromittierung vermuten. Warten Sie nicht auf einen Anomalie-Alert oder endgültige Abrechnungszahlen.

1. Zuerst eindämmen. Deaktivieren und anschließend löschen Sie die kompromittierten Access Keys. Widerrufen Sie aktive Rollensitzungen mit einer Deny-Policy, die auf aws:TokenIssueTime bedingt ist, und deaktivieren Sie alle verdächtigen Bedrock-API-Keys. Wenn Sie ein grobes Werkzeug brauchen: Eine Notfall-SCP, die bedrock:* im betroffenen Account verweigert, stoppt die Blutung (sie stoppt allerdings auch legitime Bedrock-Nutzung). Rechnen Sie damit, dass nach dem Deaktivieren eines Keys noch einige Minuten lang Aufrufe durchkommen.
2. Nach Persistenz suchen. Suchen Sie nach neuen IAM-Usern, Access Keys, Rollen und Trust-Policy-Änderungen, Marketplace-Vereinbarungen, SES-Identitäten, Capacity Blocks und Instanzen in jeder Region. Rotieren Sie jeden Key, der exponiert gewesen sein könnte – nicht nur den, den AWS gemeldet hat. Wir haben erlebt, dass eine zweite Welle sechs Tage nach Beginn eines offenen Vorfalls über einen Key kam, den niemand rotiert hatte.
3. Beweise sichern. Exportieren Sie CloudTrail (die Event History reicht nur 90 Tage zurück), Invocation-Logs, ein Ressourceninventar und einen Kostenexport nach Service.
4. AWS vor Ablauf der Frist antworten. AWS-Sicherheitsmitteilungen geben typischerweise fünf Tage, bevor Services ausgesetzt werden. Einschränkungen können Tage nach dem Vorfall greifen und Produktionsdienste wie Lambda, ECS und EC2 betreffen.
5. Die Rechnungsanpassung explizit anfragen. In den Fällen, die wir gesehen haben, erwartet AWS mindestens zwei Kostenüberwachungs-Kontrollen, etwa AWS Budgets und Cost Anomaly Detection. Außerdem erwartet AWS Root-MFA, GuardDuty oder Security Hub. Geprüft wird das im betroffenen Account. Vom Angreifer erstellte Marketplace-Vereinbarungen müssen gekündigt werden. Die Ergebnisse reichten von vollständigen über teilweise Gutschriften bis hin zu Ablehnungen. Der Prozess dauerte zwei bis zwölf Wochen. Eine klare Zeitleiste, schnelle Eindämmung und vollständige Beweise machen den Unterschied. AWS hat zudem erklärt, künftige Rechnungen möglicherweise nicht zu prüfen, wenn die Kontrollen fehlen.

Wenn Sie Ihren AWS-Account über DoiT beziehen, eröffnen Sie ein DoiT-Support-Ticket, sobald Sie eine Kompromittierung vermuten. Unser Team koordiniert den Security-Fall und den Antrag auf Rechnungsanpassung mit AWS und hilft Ihnen, die von AWS geforderten Nachweise zusammenzustellen.

Ihre LLMjacking-Checkliste

In AWS

• Keine langlebigen IAM-User-Keys für Menschen oder Workloads. Alte Keys auditiert und gelöscht.
• Root: Hardware-MFA, keine Access Keys und eine überwachte E-Mail-Adresse auf einer eigenen Domain.
• Alternative Kontakte SECURITY und OPERATIONS in jedem Account hinterlegt.
• SCPs, die Bedrock dort verweigern, wo es nicht gebraucht wird, Marketplace-Abonnements einschränken und GetFederationToken blockieren.
• Bedrock-Tokens-pro-Minute-Quotas am Bedarf bemessen.
• Organisations-CloudTrail, Bedrock Invocation Logging und GuardDuty in jedem Account und jeder Region.

In DoiT Cloud Intelligence

• Eine Allocation, die Bedrock plus die Marketplace-Ausgaben "(Amazon Bedrock Edition)" abdeckt.
• Tägliche Schwellenwert-Alerts pro Account auf dieser Allocation, einschließlich "Sollte null sein"-Accounts.
• Ein Budget auf jedem AWS-Account, ruhende eingeschlossen.
• Anomalie-Benachrichtigungen auf Warning oder höher, mit erneuter Benachrichtigung und einem echten Empfänger.
• Echtzeit-Anomalieerkennung für AWS (Pläne Enhanced und Enterprise).
• Composer-Recipes für veraltete und Admin-Keys, Root-Status, Security-Kontakte, Trail-Abdeckung und Bedrock-Key-Nutzung außerhalb Ihrer KI-Accounts.
• CloudFlow: Eindämmung mit Freigabeschritt und Erkennung erstmaliger Service-Nutzung.

Angreifer verdienen Geld mit LLMjacking – sie werden also weiter nach Accounts suchen, die niemand im Blick hat. Perfekte Erkennung ist unrealistisch. Aber Sie können Ihren Account zu einem teuren, lauten und kurzlebigen Ziel machen. Und falls doch etwas durchkommt, erfahren Sie es innerhalb von Stunden – nicht erst über die Rechnung.

Sie möchten Unterstützung beim Prüfen Ihrer AWS-Leitplanken oder beim Einrichten von DCI-Alerts, Budgets und CloudFlow für KI-Workloads? Sprechen Sie mit DoiT.