Startseite / News
News

Railway-Hack: Agenten gegen Agenten – und am Ende zahlt die Plattform

Railway-Hack: Agenten gegen Agenten – und am Ende zahlt die Plattform
← Alle Beiträge

Railway hat den Abschlussbericht zum Einbruch vom Oktober vorgelegt. Er zeigt, wie ein Angreifer mit KI-Agenten in gut 24 Stunden vom Build-Server bis zum Schlüsseldienst kam, und er enthält eine Kehrtwende: Den Schaden durch gestohlene KI-Schlüssel, geschätzt rund 740.000 US-Dollar, will die Plattform nun notfalls selbst übernehmen.

Was neu ist

Die Cloud-Hosting-Plattform Railway hat am 10. November ihren ausführlichen Incident-Report veröffentlicht. Den Vorfall selbst hatte das Unternehmen bereits im Oktober in einem vorläufigen Bericht gemeldet; Railway war einer von mindestens neun Fällen der Angriffsserie, die Wiz „Black October“ getauft hat. Neu sind drei Dinge: die vollständige Angriffskette, die Zahl zum finanziellen Schaden und Railways geänderte Haltung bei der Erstattung.

Die Angriffskette

Nach Railways Darstellung begann der Angreifer am 20. Oktober um 06:50 Uhr UTC, die Build-Infrastruktur abzutasten. Dort liefen mehrere Kunden-Builds isoliert voneinander auf derselben virtuellen Maschine. Um 07:28 Uhr UTC nutzte er eine bis dahin unbekannte Lücke, um teilweise aus der Dateisystem-Isolation auszubrechen, und las ein Credential aus, mit dem sich Build-Server bei internen Diensten anmelden.

Dieses Credential sollte eigentlich nur das Hochladen fertiger Images erlauben. Railways interner Temporal-Cluster, der Build-Aufgaben steuert, akzeptierte es aber als vertrauenswürdigen Client. Darüber las der Angreifer gespeicherte Verläufe anderer Builds, laut Report 353 Stück, samt Build-Variablen. Weil das Credential auch Repository-Snapshots für den Cache abrufen durfte, kam er an eine Kopie von Railways internem Monorepo.

Diese Codekopie war der Hebel. Railway bemerkte sie erst, als der Angreifer Endpunkte ansprach, die seit Wochen oder Jahren nicht mehr in Gebrauch waren. Im Code fand er eine fehlerhaft konfigurierte OIDC-Bindung in einer Cloud-Umgebung und erhielt darüber am 21. Oktober um 03:26 Uhr UTC kurzlebige Cloud-Zugangsdaten. Mit ihnen holte er sich ein SSH-Schlüsselpaar und ein langlebigeres internes Credential, meldete sich auf einer Orchestrierungsmaschine an und fand dort eine Datei mit einem Schlüssel, der das Entschlüsseln von Kundenvariablen beim Key-Management-Dienst erlaubte.

Zwischen 04:07 und 05:21 Uhr UTC fragte der Angreifer die Datenbank mit den verschlüsselten Variablen ab. Die Datenbank-Logs zeigen laut Railway, dass er per regulärem Ausdruck gezielt nach Variablennamen für KI-Anbieter-Schlüssel suchte und Kunden mit besonders vielen Variablen bevorzugte. Ab 04:42 Uhr UTC entschlüsselte er Teile davon. Um 07:14 Uhr UTC sperrte Railway alle Cloud-Credentials und den Zugang zum Entschlüsselungsdienst; ab 09:25 Uhr UTC hatte der Angreifer nach Railways Forensik keinen Zugriff mehr auf Kundendaten.

Was belegt ist

  • Umfang: Bei höchstens 1,85 Prozent der Workspaces, etwa 100.000, könnten Umgebungsvariablen entschlüsselt worden sein. Railway betont, dass das eine Obergrenze ist, weil die Logs nur Umgebungen erfassen, nicht einzelne Variablen.
  • Accounts: Entschlüsselt wurden auch verknüpfte Tokens von 1.852 Nutzern, darunter eigene KI-Agenten-Schlüssel (BYOK) und GitHub-OAuth-Tokens. Railway hat sie zurückgesetzt und keine Logins mit gestohlenen Daten festgestellt.
  • Schaden: Die unautorisierte Nutzung der gestohlenen Schlüssel schätzt Railway auf rund 740.000 US-Dollar. BleepingComputer berichtet ebenfalls über diese Zahl.
  • Vorlauf: Erste Testkonten legte der Angreifer schon am 18. Oktober an, zwei Tage vor dem ersten Alarm. Diese frühen Versuche scheiterten an Railways automatischen Systemen.
  • Motiv: Railway geht davon aus, dass die Schlüssel an Weiterverkäufer gingen, die sie für Distillation nutzen, also um mit fremden Zugängen Antworten großer Modelle für das Training eigener Modelle abzugreifen. Die beobachtete Nutzung reichte laut Report von Coding-Agenten bis zu Trainings-Pipelines. Ob der Angreifer diese Dienste selbst betreibt, ist nicht geklärt.

Ein Wettlauf zwischen Agenten

Der bemerkenswerteste Satz des Reports betrifft das Tempo. Der Angreifer habe viele Routen parallel ausprobiert, Railway habe parallel abgedichtet, die Lage sei zu einem „contest of agent speed“ geworden. Railway habe sich gegen „abliterated models“ verteidigt, also Sprachmodelle, deren Sicherheitssperren entfernt wurden, und gegen ein Agenten-Framework, das laut Wiz dem Werkzeug ARTEX ähnelt. Mit der Monorepo-Kopie habe der Angreifer „agent fanouts“ starten können, um Exploits zu finden und sich schnell seitlich durch die Systeme zu bewegen.

Wie viel davon tatsächlich automatisiert ablief, lässt sich von außen nicht prüfen; Railway stützt sich auf eigene Forensik und auf Wiz. Ein Detail spricht aber für die Einschätzung: Ein interner Härtungstrupp fand innerhalb einer Stunde nach dem ersten Patch eine Variante derselben Lücke. Wer auf der anderen Seite Agenten mit Codezugriff hat, findet solche Varianten ebenfalls schnell.

Die Kehrtwende bei der Erstattung

Im vorläufigen Bericht hatte Railway noch geschrieben, man könne Kunden Kosten durch kompromittierte API-Schlüssel nicht erstatten, Betroffene sollten sich an die KI-Anbieter wenden. Der Abschlussbericht klingt anders. AWS Bedrock und Google Gemini erstatten nach ihren bestehenden Betrugsregeln. OpenAI und SpaceXSI prüfen Fälle einzeln über einen gemeinsamen Kanal mit Railway. Mit Anthropic laufen laut Report noch Gespräche, bis dahin übernimmt Railway diese Kosten selbst. OpenRouter verweist auf seine Bedingungen ohne Rückerstattung; auch hier springt Railway ein. Generell will die Plattform alle Token-Verluste tragen, die Anbieter nicht erstatten.

Der harte Punkt ist die Vertrauensarchitektur

Keiner der Schritte war für sich genommen spektakulär. Ein Credential, dem ein zweiter Dienst mehr zutraute als vorgesehen, ein Repository-Cache mit zu weiten Rechten, eine falsch gesetzte OIDC-Regel, ein Entschlüsselungsschlüssel als Datei auf einer Maschine im selben Netz wie die Datenbank. Erst die Kette ergab den Zugriff auf Kundengeheimnisse, und die Codekopie machte es leichter, die Kette zu finden. Railways eigentlich solide Envelope-Verschlüsselung half wenig, sobald ein Dienst mit Entschlüsselungsrecht kompromittiert war.

Railway hat inzwischen umgebaut: Jeder Build bekommt eine eigene kurzlebige VM mit einem Credential, das nur ein bestimmtes Image hochladen darf. Die CI verlangt in kritischen Bereichen Zwei-Faktor- und biometrische Freigaben, Ver- und Entschlüsselungen werden zentral protokolliert, und nur noch ein Secrets-Dienst kommt an die Schlüssel. Die neue Build-Infrastruktur war schon vor dem Angriff fertig und sollte ab der Woche des 26. Oktober schrittweise starten. Sie kam damit wenige Tage zu spät.

Auch die Kommunikation bleibt ein Schwachpunkt. Railway informierte zuerst die KI-Anbieter, dann die Kunden, und erklärt das mit dem Ziel, den Angreifer vor einer breiten Rotation auszusperren. Künftig soll nach einer festen Frist in jedem Fall breit informiert werden. Indikatoren für die Kompromittierung will Railway erst nach Freigabe durch die Strafverfolgung veröffentlichen; eine Anzeige beim FBI-Portal IC3 läuft.

Was Betroffene jetzt tun sollten

  • Abrechnungen prüfen: KI-Nutzung seit dem 18. Oktober bei allen Anbietern kontrollieren, deren Schlüssel auf Railway lagen.
  • Erstattung beantragen: Unberechtigte Kosten über Railways Formular und, je nach Anbieter, zusätzlich beim KI-Anbieter melden. Bei OpenAI verlangt Railway die Case-ID des Support-Tickets.
  • Schlüssel beim Aussteller rotieren: Nicht nur in Railway ersetzen, sondern bei OpenAI, Anthropic, AWS, GitHub oder Stripe selbst widerrufen, auch für Cloud-, Datenbank- und Zahlungsdienste; eine weitere Abfrage des Angreifers zielte laut Report auch auf solche Zugangsdaten.
  • Limits setzen: Ausgabengrenzen und Budget-Alarme bei den KI-Anbietern einrichten.

Einordnung

Der Railway-Report ist das bislang genaueste öffentliche Dokument zur „Black October“-Serie. Er bestätigt, was sich Ende Oktober abzeichnete: KI-Schlüssel sind zur bevorzugten Beute geworden, weil sie sich sofort zu Geld machen lassen. Neu ist, wie offen ein Betroffener beschreibt, dass auch die Angreifer mit Agenten arbeiten und das Verteidigen zur Tempofrage wird. Dass Railway die Kosten nun doch übernimmt, ist für Kunden die wichtigste Nachricht. Die Lehre für andere Plattformen steht im Kapitel zur Angriffskette.

Quellen

J

Über den Autor

Jens Könnig

Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?

Alle Artikel von Jens Könnig →