Am 20. Oktober weckte ein Alert einen Railway-Engineer, weil API-Aufrufe auf eine interne Registry liefen, die es nicht geben sollte. Sechzehn Stunden später hatte das Unternehmen die Kunden-Builds zweimal gestoppt, jedes eigene Credential rotiert und neun KI-Anbieter gebeten, Keys zu widerrufen, deren Diebstahl noch nicht bewiesen war.
Die Bilanz aus dem am 10. November veröffentlichten Incident Report: Kunden-Variablen in höchstens 1,85% der Workspaces entschlüsselt, rund 100.000. Tokens verknüpfter Accounts für 1.852 Nutzer zurückgesetzt. Nicht autorisierte Ausgaben mit den gestohlenen Keys: geschätzt 740.000 Dollar, die Railway jetzt erstattet oder aus eigener Tasche abdeckt.
Und der Teil, an dem man hängen bleibt: Niemand phishchte einen Finanzvorstand. Niemand verteilte Ransomware. Der Angriff galt API-Keys von KI-Anbietern, und den Markt, der das ein Wochenende Arbeit wert macht, haben wir alle zusammen gebaut.
Der Einbruch, in der Reihenfolge, in der er passierte
Die vollständige Timeline steht in Railways Report und liest sich wie eine Horrorgeschichte in UTC-Zeitstempeln.
- 18. Oktober, vor allem anderen: Der Angreifer legt Dummy-Accounts auf der Plattform an. Automatische Abwehr stoppt jeden Versuch in dieser Phase.
- 07:28 UTC, 20. Oktober: Er nutzt eine bisher unbekannte Lücke in der Multi-Tenant-Build-Infrastruktur, um die Dateisystem-Isolation teilweise zu verlassen und Dateien auf der Host-VM zu lesen. Das bringt ein Credential, mit dem Build-Server Images in eine Registry pushen.
- 13:58 UTC: Anomale Registry-API-Aufrufe wecken den Bereitschaftsingenieur. Root Cause in unter einer Stunde gefunden. Fix gemerged, Builds gestoppt, Angreifer isoliert.
- Der Pivot: Das Registry-Credential sollte nur Registry-Pushes autorisieren. Aber der interne Temporal-Cluster, der Builds orchestriert, akzeptierte es als vertrauenswürdigen Client. Damit konnte der Angreifer Temporal-APIs aufrufen und Build-Historien lesen, inklusive der Variablen, die in fremde Builds laufen. Einer dieser Snapshots war das interne Monorepo. Railways eigene Support-Plattform deployt daraus, auf Railway selbst.
- 03:26 UTC, 21. Oktober: Beim Scannen dieses Codes findet der Angreifer ein falsch konfiguriertes OIDC-Binding in einer Cloud-Umgebung und stiehlt daraus kurzlebige Produktions-Credentials.
- 04:07 bis 05:21 UTC: Mit einem langlebigeren Credential auf einer Orchestrierungsmaschine verbinden sie sich zur Produktionsdatenbank mit den verschlüsselten Umgebungsvariablen und ziehen die verschlüsselten Envelopes heraus. Die Datenbank-Logs zeigen, dass sie Zeilen auswählten, deren Variablennamen auf vom Angreifer gelieferte reguläre Ausdrücke für KI-Provider-Keys passten, und Kunden mit vielen Variablen priorisierten.
- 04:42 bis 07:15 UTC: Mit dem Entschlüsselungs-Credential auf derselben Maschine öffnen sie die Envelopes über den Key-Management-Service.
- 07:14 UTC: Railway deaktiviert alle aktiven Cloud-Credentials, widerruft statische, tötet den Entschlüsselungsdienst und fährt Teile der Plattform herunter. Builds gehen erneut dunkel.
- 09:24 UTC: Der Angreifer ist vollständig rausgeworfen.
Drei Design-Entscheidungen, die aus einem Bug einen Raubzug machten
Zieht man das Drama ab, ist das Muster vertraut, und genau deshalb zählt es.
1. Ein enges Credential, dem zu viele vertrauten. Nichts im Design dieses Build-Credentials sagte "lies die Build-Variablen anderer Tenants". Die Architektur akzeptierte es nur zufällig anderswo als Client. Blast Radius definiert nicht, was ein Key tun soll, sondern jeder Dienst, der ihn akzeptiert.
2. Gecachte Snapshots, die niemand als Secret zählte. Der Build-Cache enthielt Kopien des Repository-Zustands. Das gab dem Angreifer eine privilegierte Karte des Unternehmens und, schlimmer, einen Katalog aller Routen, die er als Nächstes testen konnte.
3. Langlebige Secrets neben den Daten, die sie entschlüsseln. Envelope-Verschlüsselung ist gutes Design. Envelope-Verschlüsselung, bei der die Maschine, die den Ciphertext liest, auch den Schlüssel hält, der ihn öffnet, ist eine verschlossene Tür mit Schlüssel im Schloss. Ein falsches OIDC-Binding dazu, und die ganze Kette fällt.
Der Angreifer brauchte nach den ersten zehn Minuten keinen Zero-Day mehr. Alles danach war Konfiguration.
Warum genau deine KI-Keys
Railways Forensik kommt zu dem Schluss, dass KI-Provider-Keys das Hauptziel waren. Die gestohlenen Keys gingen an sogenannte distributed transfer stations, der höfliche Begriff für Resale-Operationen, die fremde Inference-Credits monetarisieren. Der wahrscheinlichste Zweck laut Report: Destillation, also Trainingsdaten und Scores von einem Frontier-Modell auf Kosten anderer erzeugen.
Der Report korrigiert auch den Eindruck eines Einzelfalls. OpenCode, Warp, Fireworks AI und mehrere andere meldeten zwischen dem 6. und 23. Oktober ähnliche Diebstähle. Wiz dokumentierte das Muster als "Black October for AI developer platforms". Railways eigene Kunden sahen die gestohlenen Keys in Coding-Agent-Requests, in Verhaltens-Reviews von KI-Agenten zur Erzeugung von Trainingsdaten und in Prüfungen von Trainings-Pipelines und deren Scoring.
Mit anderen Worten: Es gibt inzwischen eine komplette illegale Lieferkette für Inference. Die Keys sind die Währung, die Ausgaben der Schaden, und die Opfer sind oft die Kunden, deren Variablen in der Datenbank von jemand anderem lagen.
Der Angreifer war ein Agentenschwarm, die Verteidigung auch
Zwei Details sollten ändern, wie du über Incident-Response-Tempi denkst.
Erstens wurde der eskalierende Wettlauf am ersten Tag als Wettlauf der Agentengeschwindigkeit beschrieben, mit Wiz-Hinweis auf abliterierte Modelle und einen Agent-Harness ähnlich ARTEX. Sechsunddreißig Stunden, Dutzende parallele Sondierungsrouten, Hunderte Testaccounts.
Zweitens war Railways Gegenmaßnahme genauso maschinell getaktet: 24/7-Beobachtung des Angreifers über Audit-Logs und Traces, paralleles Härten der sondierten Routen und kontinuierliche interne Forensik.
Dein Incident-Response-Runbook geht wahrscheinlich von Menschen in einer Bridge-Call-Runde aus, die Slack lesen. Das ist nicht mehr das Tempo der Gegenseite.
Was wir diese Woche tun würden
Für alle im Golf, die KI-Features, Agenten oder Fintech-Pipelines auf einer fremden Plattform betreiben, fünf Schritte:
- Jeden KI-Key inventarisieren und einen Owner benennen. OpenAI, Anthropic, OpenRouter, Gemini, Fireworks, die BYOK-Keys deiner Agenten. Hat ein Key keinen Owner und kein Rotationsdatum, gilt er als exponiert.
- Limits und Alarme auf Ausgaben, nicht nur auf Fehler. 740.000 Dollar nicht autorisierter Inference sind eine Detection-Chance. Budgets pro Key, Spike-Alarme und ein wöchentlicher Blick auf Keys, die nur ausgeben und nie deployen.
- Langlebige Credentials töten. Kurzlebige OIDC-Exchanges, eine Audience pro Dienst und ein dauerhaftes Audit jedes je konfigurierten Bindings. Die Railway-Kette begann mit einem Binding, das schlicht falsch war.
- Davon ausgehen, dass jemand die Datenbank der Plattform lesen kann. Welche deiner Variablen enthalten etwas, das sich zu stehlen lohnt? Rotiere die KI-Keys, Payment-Tokens und GitHub-OAuth-Grants, die du in irgendeiner Plattform gespeichert hast, und bevorzuge Keys, die du beim Anbieter mit einem Klick widerrufen kannst.
- Disclosure und Revocation in den Vertrag schreiben. Railway bat Anbieter, Keys per Hash zu widerrufen, bevor klar war, was geleakt ist. Frag deine Anbieter heute: Könnt ihr innerhalb von vier Stunden nach einem Incident eine Hash-Liste und einen Revocation-Weg liefern?
Der Satz, der bleibt
Railway gebührt Anerkennung für einen unbequemen, ungewöhnlich detaillierten Report. Man veröffentlichte eine vorläufige Notiz, während die Wiederherstellung noch lief, und drei Wochen später den vollständigen Forensik-Bericht, inklusive der Tatsache, dass die Keys der eigenen Kunden mehr kosteten als der Jahresumsatz eines kleinen Unternehmens.
Die Lehre ist aber nicht, dass eine Plattform verloren hat. Sie ist, dass das Wertvollste in deinem Cloud-Account nicht mehr Daten sind, sondern Compute. Deine KI-Keys sind jetzt Geld, und sie liegen in einem Dutzend Environment-Variable-Panels in einem Dutzend Dashboards, jede verschlüsselt mit einem Schlüssel, den der Build-Server von jemand anderem lesen kann.
Behandle sie wie die Bankkonten, die sie still geworden sind. Rotieren, scopen, limitieren, beobachten. Dieses Quartal, nicht nächstes.