KI-Gateways werden zur neuen Angriffsfläche in der Cloud

Die Frage, die jeder Platform-Verantwortliche mit einem generativen KI-Stack seinem VP of Engineering diese Woche stellen sollte, ist nicht, ob LiteLLM in die Produktion gehört – sondern wer die daran angehängte IAM-Rolle besitzt und wer die Netzwerkexposition genehmigt hat. Eine einzige kompromittierte Proxy-Instanz kann Cloud-Budget in ein fremdes Monero-Wallet verbrennen und, schlimmer noch, Angreifern einen Einstiegspunkt in Bedrock verschaffen. Das ist kein Problem des Forschungslabors mehr, das ist ein Problem für das Architektur-Review im dritten Quartal.

Darktrace's Offenlegung einer gekaperten AWS EC2-Instanz mit LiteLLM ist ein kleiner Vorfall mit einer übergroßen Botschaft: Die Shim-Schicht, die Teams überstürzt zwischen ihre Anwendungen und Foundation-Modelle in die Produktion gebracht haben, ist nun eine erstklassige Angriffsfläche. Die meisten CISOs haben kein Budget dafür eingeplant. Die meisten Platform-Teams können nicht sagen, wer sie patcht.

Wichtige Details

Am 12. Juni 2026 erkannte Darktrace, wie CyberSecurityNews berichtete, aktives Cryptomining-Verhalten, das von einer AWS EC2-Instanz namens „LiteLLM-Proxy" ausging. Der Host fungierte als KI-Gateway, war über eine IAM-Rolle mit Amazon Bedrock verbunden und saß genau dort, wo KI-Gateways typischerweise angesiedelt sind: zwischen Nutzern, Geschäftsanwendungen und großen Sprachmodellen – zuständig für Authentifizierung, Modell-Routing, Logging, Richtlinien und den Zugriff auf Foundation-Modelle.

Der initiale Angriffsvektor war banal. SSH war auf der Instanz exponiert und akzeptierte eingehenden Datenverkehr von beliebigen Quell-IPs. Darktrace beobachtete eine hohe Anzahl kurzlebiger SSH-Verbindungsversuche, darunter Datenverkehr von 145.241.123[.]102. Die Ermittler konnten einen erfolgreichen Login nicht bestätigen, aber der exponierte Dienst und das Brute-Force-Muster machten SSH zum plausiblen Einstiegspunkt.

Das Verhalten nach der Kompromittierung folgte dem üblichen Cryptojacking-Playbook. Die Instanz lud über einfaches HTTP von 185.62.1[.]8 eine Nutzlast herunter – ein ZIP-Archiv mit XMRig, dem weit verbreiteten Open-Source-Monero-Miner. Anschließend öffnete sie wiederholt HTTPS-Sitzungen zu pool.hasvault[.]pro, einem bekannten Cryptomining-Pool. Das Einbetten des Pool-Datenverkehrs in TLS über Standardports ließ die Verbindungen für sich genommen unauffällig erscheinen, aber Ziel und Takt lösten die Verhaltensdetektierung aus. Die Aktivität lässt sich sauber MITRE ATT&CK T1496 (Ressourcenentführung) zuordnen.

Einen Tag später, am 13. Juni, authentifizierte sich ein IAM-Nutzer desselben Kontos über die AWS CLI von einer vietnamesischen IP-Adresse, die Darktrace als ungewöhnlich für das Konto einstufte. Die Sitzung versuchte GetSendQuota, ListFoundationModels, InvokeModel und CreateUser auszuführen. Die Bedrock-Aufrufe (ListFoundationModels, InvokeModel) schlugen fehl. Darktrace konnte die IAM-Aktivität nicht zweifelsfrei mit dem kompromittierten Gateway verknüpfen, aber die Abfolge aus Modell-Erkundung, Aufrufversuchen und einem nach Persistenz klingenden CreateUser-Aufruf entspricht genau dem, was man von einem Angreifer erwarten würde, der auslotet, was die gestohlenen Zugangsdaten eines KI-Gateways ermöglichen könnten.

Warum das für Sicherheitsteams wichtig ist

Cryptomining ist das Rauschen, nicht das Signal. Das Signal ist, was die IAM-Rolle eines KI-Gateways erreichen kann.

Man betrachte das Vertrauensprofil dieser Komponenten. Ein KI-Gateway hält dauerhafte Cloud-Zugangsdaten mit Berechtigungen, Foundation-Modelle aufzurufen, Prompts und Completions im Transit zu lesen, Kontext aus internen Anwendungen weiterzuleiten und häufig Logs in S3 oder CloudWatch zu schreiben. Eine Kompromittierung kostet nicht nur Rechenzyklen. Sie legt potenziell jeden Prompt offen, den Produktteams an Bedrock senden (was für regulierte Fintechs, iGaming- oder Health-Tech-Unternehmen personenbezogene Daten, Session-Daten und Geschäftslogik bedeutet), jede zurückkommende Antwort sowie die IAM-Oberfläche, die an die Rolle geknüpft ist. Der Angreifer, der hier InvokeModel versuchte, hatte das verstanden. Er war nicht wegen Monero dort – er war wegen des Modellzugangs. Das Mining war die Einstiegsmonetarisierung, während er die eigentliche Ausbeute ermittelte.

Das verändert die Vorfallsökonomie. Eine einzelne mittelgroße EC2-Instanz mit XMRig könnte ein paar hundert Dollar im Monat an verschwendeten Kosten verursachen. Ein geleakter Bedrock-Aufrufpfad oder, schlimmer, ein gestohlenes Prompt-Korpus mit Kundendaten ist ein Gespräch für General Counsel und CFO. Hier würde ich jeden Security-Verantwortlichen drängen: Hört auf, diese Vorfälle am Mining-Betrag zu messen, und beginnt sie am Explosionsradius der IAM-Rolle zu messen, die an der Instanz hängt.

Die taktischen Schwächen sind wenig glamourös. SSH offen für 0.0.0.0/0 im Jahr 2026 auf einer Komponente, die den Zugang zu Foundation-Modellen vermittelt, ist ein Konfigurationsfehler, der ein ordentliches Platform-Review nicht überstanden hätte. Langlebige Zugangsdaten in einer IAM-Rolle mit mehr Bedrock-Berechtigungen als der Workload tatsächlich benötigt, ist ein Least-Privilege-Versagen. Das Herunterladen von Nutzlasten über HTTP von einer beliebigen IP ist ein Egress-Kontroll-Versagen. Jedes einzelne davon ist für sich überlebbar. Zusammen auf der Komponente verkettet, die den KI-Datenverkehr vermittelt, sind sie eine Vorschau auf die nächste Welle von Cloud-Breach-Berichten.

Auswirkungen auf die Branche

Die Build-vs-Buy-Diskussion rund um KI-Gateways ist jetzt eine Sicherheitsdiskussion, nicht nur eine über Latenz und Kosten. In den letzten achtzehn Monaten griffen Engineering-Teams in Fintech und iGaming zu LiteLLM, Open-Source-Proxies und selbst entwickelten Routing-Schichten, weil kommerzielle KI-Gateway-Angebote von Cloud-Anbietern und Startups entweder nicht existierten, zu viel pro Token kosteten oder die Modellabdeckung fehlte. Das war damals rational. Beim nächsten Audit wird es weniger rational aussehen.

Hier spielt das Organigramm eine Rolle. Wer besitzt das KI-Gateway in Ihrem Unternehmen? Bei den meisten Series-B-Fintechs, die ich sehe, lautet die Antwort „das ML-Platform-Team" oder „welcher Staff-Engineer es auch aufgebaut hat". Dieses Team ist nicht dasselbe Team, das Ihr Produktions-Kubernetes absichert, Ihren Egress überwacht oder IAM-Richtlinien prüft. Es optimiert für Entwicklergeschwindigkeit und Modellabdeckung. Sicherheitspostur ist eine Nebenmission. Wenn das Gateway zum einzigen Engpass für KI-Datenverkehr wird, wird diese Eigentümerlücke zum Exploit.

Regulierte Branchen spüren das stärker. Ein iGaming-Betreiber, der Bedrock für die Zusammenfassung von Spieler-Support nutzt, streamt kundenbezogene Prompts durch dieses Gateway. Ein Fintech, das KYC-Augmentation betreibt, sendet Dokumentenextrakte. Wenn das Gateway kompromittiert ist und die IAM-Rolle Log-Schreibzugriff auf einen gemeinsam genutzten Bucket erlaubt, schreibt sich der Exfiltrationskanal von selbst. Regulatoren in Großbritannien, Malta und der EU werden „wir dachten, LiteLLM wäre nur ein Router" nicht als Antwort in einer Section-166- oder DORA-Untersuchung akzeptieren.

Die Konsequenz für den Stellenmarkt ist ebenfalls real. Cloud-Security-Ingenieure, die sowohl IAM als auch KI-Workload-Muster verstehen, sind ein schmaler Talentpool. Rechnen Sie damit, dass die Vergütung für dieses spezifische hybride Skill-Set in der zweiten Hälfte von 2026 stark ansteigen wird, wenn weitere Offenlegungen bekannt werden.

Was zu beobachten ist

Drei Signale, die in den nächsten 90 Tagen zu verfolgen sind. Erstens, ob AWS und andere Hyperscaler erstklassige KI-Gateway-Produkte mit abgehärteten Standardeinstellungen liefern oder bei Bedrock-IAM-Features nachlegen, um einzuschränken, was ein kompromittierter Proxy tun kann (scoped Invocation Policies, modellspezifische Ressource-ARNs, Request-Signing auf SDK-Ebene). Zweitens, ob das Open-Source-KI-Gateway-Ökosystem (LiteLLM und seine Pendants) mit sicherheitsorientierten Releases, meinungsstarken Deployment-Templates und Referenz-IAM-Richtlinien reagiert. Drittens, ob wir die erste bestätigte Offenlegung sehen, bei der eine KI-Gateway-Kompromittierung zu einer Exfiltration von Prompt- oder Completion-Daten führt und nicht nur zu Cryptomining. Dieses dritte Ereignis ist der Schuh, der noch nicht gefallen ist – und wenn er fällt, wird er verändern, wie Vorstände über generative KI-Ausgaben nachdenken.

Der Head of Platform jedes Unternehmens, das ein KI-Gateway in der Produktion betreibt, sollte seinen Security-Verantwortlichen diese Woche fragen: Was ist die genaue IAM-Richtlinie, die an diesem Proxy hängt, was ist die Egress-Allowlist der Instanz, und wann wurden zuletzt die langlebigen Schlüssel rotiert, die in seiner Umgebung schlummern? Wenn diese drei Fragen keine Antworten am selben Tag haben, besitzen Sie Ihren eigenen LiteLLM-Proxy, der darauf wartet, gefunden zu werden.

Wichtigste Erkenntnisse

• Die KI-Gateway-Schicht (LiteLLM, benutzerdefinierte Proxies, Modell-Router) ist jetzt eine eigenständige Angriffsfläche mit Cloud-Zugangsdaten, die mehr wert sind als die Rechenleistung, auf der sie laufen.
• Der Darktrace-Fall begann mit SSH offen für das Internet und endete mit versuchten Bedrock-InvokeModel-Aufrufen von einer vietnamesischen IP: Cryptomining ist das Einstiegsangebot, Modellzugang ist der eigentliche Preis.
• Least-Privilege-IAM auf der Gateway-Rolle ist die wirksamste Einzelmaßnahme. Bedrock-Berechtigungen auf spezifische Modell-ARNs eingrenzen und CreateUser-ähnliche Berechtigungen vollständig entfernen.
• Eigentümerambiguität zwischen ML-Platform-Teams und Cloud-Security-Teams ist der Nährboden für diese Breaches. Das Organigramm korrigieren, bevor die Konfiguration korrigiert wird.
• Regulierte Fintech- und iGaming-Betreiber sollten davon ausgehen, dass Prompts und Completions, die durch ein KI-Gateway laufen, im Geltungsbereich ihrer Compliance-Anforderungen liegen, und Egress-Kontrollen entsprechend gestalten.