Hacker plündern Railway mit KI-Agenten: 740.000 Dollar Schaden durch gestohlene KI-Keys

Worum es geht

Railway ist eine Cloud-Plattform, auf der Entwickler ihre Anwendungen bauen und betreiben, ohne sich selbst um Server zu kümmern. Am 10. November hat das Unternehmen einen ausführlichen Bericht über einen Sicherheitsvorfall vom Oktober veröffentlicht, über den die Seite Cybersecurity News berichtet. Der Angreifer kombinierte KI-Agenten, eine bis dahin unbekannte Lücke im Build-System und Fehler bei der Cloud-Konfiguration. So kam er an geheime Zugangsdaten von Kunden. Mit gestohlenen Schlüsseln für KI-Dienste entstanden geschätzt rund 740.000 US-Dollar an unberechtigten Kosten.

Der Bericht ergänzt eine frühere, vorläufige Meldung von Railway. Neu sind vor allem der genaue Ablauf und die Rolle der KI.

Wie der Angriff begann

Der erste erfolgreiche Einbruch geschah am 20. Oktober um 07:28 UTC. Über eine bis dahin unbekannte Schwachstelle konnte der Angreifer teilweise aus der Dateiisolation des Build-Systems ausbrechen. Das Build-System ist der Teil der Plattform, der den Code der Kunden zu lauffähigen Programmpaketen (Images) zusammenbaut. Jeder Build sollte dabei in einer abgeschotteten Kiste laufen. Der Angreifer konnte aber Dateien auf dem Host-Rechner lesen, also auf der Maschine, auf der diese Kisten laufen.

In diesen Dateien lag ein Zugangsnachweis (Credential), mit dem die Build-Server interne Dienste ansprechen und fertige Images hochladen. Dieser Nachweis hatte mehr Rechte als beabsichtigt. Railways internes Aufgabensystem Temporal akzeptierte ihn ebenfalls. Damit konnte der Angreifer die gespeicherten Verläufe von 353 Builds lesen, und darin standen auch Geheimnisse.

Noch folgenreicher: Über zwischengespeicherte Kopien von Code-Repositories bekam der Angreifer Railways eigenen internen Quellcode in die Hände. Railway zufolge diente dieser Code den KI-Agenten als Landkarte, mit der sie nach weiteren Schwachstellen suchten und mehrere Angriffswege gleichzeitig ausprobierten.

KI-Agenten ohne Sicherheitsbremsen

Railway gibt an, der Angreifer habe KI-Modelle eingesetzt, deren Sicherheitsbeschränkungen entfernt worden waren. Gesteuert wurden sie über ein Agenten-Framework, das einem Werkzeug namens ARTEX ähnelt. KI-Agenten sind Programme, die eigenständig mehrere Schritte nacheinander ausführen, etwa Code lesen, Hypothesen aufstellen und Angriffe testen, ohne dass ein Mensch jeden Schritt anstößt. Was ARTEX genau ist, steht im Bericht nicht näher.

Railways Ingenieure bemerkten um 13:58 UTC ungewöhnliche Aufrufe an der Registry-Schnittstelle, also an dem Dienst, der die fertigen Images speichert. Daraufhin tauschten sie den gestohlenen Zugangsnachweis aus. Weil der Angreifer den Quellcode aber schon kopiert hatte, fand er einen anderen Weg hinein, nachdem der erste Zugang gesperrt war. Genau hier zeigt sich der Vorteil der KI-Agenten: Sie können eine große Codebasis schnell durchsuchen und mehrere Spuren parallel verfolgen, während die Verteidiger ein Loch nach dem anderen stopfen.

Der zweite Weg: falsch konfiguriertes Vertrauen in der Cloud

Am 21. Oktober um 03:26 UTC nutzte der Angreifer eine fehlerhafte OIDC-Vertrauenskonfiguration. OpenID Connect ist ein Standard, mit dem sich Dienste gegenseitig ausweisen, etwa so, als würde ein Pförtner einen Hausausweis akzeptieren, statt nach einem Schlüssel zu fragen. War die Konfiguration zu großzügig, bekommt auch der Falsche einen Ausweis. Hier erhielt der Angreifer so einen kurzlebigen Cloud-Zugang. Damit holte er interne Zugangsdaten und einen privaten SSH-Schlüssel, mit dem man sich auf Server einloggt. So gelangte er auf eine Maschine, die die Workloads der Kunden koordiniert.

Diese Maschine hatte Netzwerkzugriff auf die Produktionsdatenbank und dazu einen weiteren Zugangsnachweis, der das Entschlüsseln von Geheimnissen freigeben konnte. Der Angreifer lud verschlüsselte Umgebungsvariablen herunter. Das sind Einstellungen, in denen Entwickler typischerweise Passwörter und API-Schlüssel ablegen. Über Railways eigenen Schlüsselverwaltungsdienst entschlüsselte er einen Teil davon. Railway betont: Die Verschlüsselung selbst wurde nicht gebrochen, der Angreifer missbrauchte legitime Zugangsdaten. Die Datenbankabfragen suchten gezielt nach Namen, die auf Schlüssel von KI-Anbietern hinweisen.

Das Ausmaß des Schadens

Die 100.000 Workspaces sind eine Obergrenze, keine bestätigte Zahl. Die Logs zeigen nur, welche Umgebungen betroffen waren, nicht welche einzelnen Geheimnisse tatsächlich gestohlen wurden. Außerdem bekam der Angreifer Tokens verknüpfter Konten von 1.852 Nutzern, die Railway zurückgesetzt hat. Laut den Ermittlern gab es keine Logins in Railway-Konten mit gestohlenen Zugangsdaten und keine Hinweise auf Zugriffe auf die Datenbanken der Kunden.

Die Kosten entstanden durch LLMjacking. Dabei nutzen Kriminelle gestohlene Zugangsschlüssel, um kostenpflichtige KI-Dienste auf Rechnung der Opfer zu verwenden. Railway vermutet, dass die gestohlenen Schlüssel bei Diensten gelandet sind, die KI-Zugänge weiterleiten oder weiterverkaufen, möglicherweise auch für Modelldestillation. Dabei wird ein eigenes Modell mit massenhaft Antworten eines fremden Modells trainiert, um dessen Fähigkeiten nachzubilden. Ob der Angreifer diese Dienste selbst betreibt, ist laut Railway nicht geklärt. Die Sicherheitsfirma Wiz beschreibt in ihrer Untersuchung „Black October“ das größere Muster solcher Diebstähle, ordnet den Railway-Einbruch aber nicht selbst zu.

Was Railway tut und was Kunden tun sollten

Railway hat die Zugangsdaten widerrufen, interne Systeme neu aufgebaut und bis zum 22. Oktober die Builds für alle Tarife wiederhergestellt. Mit den betroffenen Anbietern verhandelt das Unternehmen über Rückerstattungen. Lehnen diese ab, übernimmt Railway die Kosten aus dem Einbruch selbst, statt sie bei den Kunden zu lassen.

Wer Railway nutzt, sollte möglicherweise offengelegte Geheimnisse austauschen, also neue API-Schlüssel erzeugen und die alten löschen. Außerdem lohnt ein Blick in die Verbrauchsübersichten der KI-Anbieter, um auffällige Nutzung zu finden. Betrügerische Abrechnungen sollte man melden.

Einordnung

Der Fall zeigt sehr konkret, wie KI-Agenten Angriffe beschleunigen. Sie sind nicht die eigentliche Lücke, aber sie machen aus einem gestohlenen Quellcode schnell einen Plan für den nächsten Einbruch. Die Verteidiger reagierten nach rund sechseinhalb Stunden, und trotzdem fand der Angreifer einen zweiten Weg. Die eigentlichen Ursachen sind klassische Fehler: zu weitreichende Zugangsnachweise, eine lückenhafte Isolation und eine zu großzügige Vertrauenskonfiguration. KI senkt die Hürde, solche Fehler auszunutzen, und erhöht das Tempo.

Auffällig ist auch das Ziel: Schlüssel für KI-Dienste sind zu einer begehrten Beute geworden, weil sie sich direkt in Geld umsetzen lassen. Wer API-Schlüssel in Umgebungsvariablen ablegt, sollte Ausgabelimits bei den Anbietern setzen. Offen bleibt, wer hinter dem Angriff steckt, wie viele Schlüssel tatsächlich gestohlen wurden und welche KI-Modelle ohne Sicherheitsbeschränkungen genau im Spiel waren. Alle Angaben stammen bisher von Railway selbst. Positiv fällt auf, wie offen das Unternehmen den Ablauf dokumentiert und dass es die Kosten für seine Kunden übernimmt.