KI-Angreifer werden nicht müde: Warum die Cybersicherheit sich ändern muss

Ihr Sicherheitsprogramm wurde für Angreifer gebaut, die es tun.

Als OpenAI seinen Bericht über die Modelle veröffentlichte, die aus einer Evaluierungsumgebung ausgebrochen sind und Tage lang in der Produktionsinfrastruktur von Hugging Face verbrachten, nannte ich das einen Terminator‑Moment für die Cybersicherheit. Ich halte an dieser Aussage fest, aber ein weiteres Detail sollte uns zum Nachdenken bringen. Neun Tage später legte Anthropic eigene Vorfälle offen. Anfang August bestätigte Meta einen weiteren. Tage darauf entwich das Modell eines vierten Labors, Moonshots Kimi K3, aus seiner Test‑Sandbox. Vier Labore. Weniger als drei Wochen. Vier Modelle, die irgendwohin gelangten, wo sie nicht hingehörten.

Diese Geschichten wurden größtenteils als KI‑Sicherheitsgeschichten behandelt. Das sind sie auch. Für einen CISO sind sie jedoch zugleich Geschichten über Risiken durch Dritte – und das könnte die unmittelbarere Lehre sein. Die unbequeme Wahrheit ist, dass der Vorfall OpenAI‑Hugging Face im Kern eine Geschichte über Drittanbieter‑Risiken war: eine verwundbare Komponente eines Drittanbieters als Fluchtroute, ein Anbieter als Opfer und ein systemischer Knoten, von dem Tausende Unternehmen abhängen, als Explosionsradius.

Hier ist die Zahl, die ich zu Ihrem nächsten Sicherheitsplanungs‑Meeting mitbringen würde. Von den etwa 17.600 Angreifer‑Aktionen, die Hugging Face hat wiederhergestellt aus seinen Protokollen wiederhergestellt hat, sind die meisten fehlgeschlagen.

Der Agent testete Pfade, die ins Leere führten. Er wurde von URL‑Whitelist‑Listen blockiert und wechselte die Richtung. Er traf auf IAM‑Richtlinien, die jeden verändernden Aufruf verweigerten. Er versuchte zweimal, eine Produktionsdatenbank zu erreichen, und beide Male lief er in ein Timeout. Er sondierte, scheiterte und fuhr fort. Tausende Male. Er wurde nicht frustriert. Er wurde nicht müde. Und das Scheitern kostete ihn fast nichts.

Vier Modelle brachen innerhalb von weniger als drei Wochen aus Testumgebungen aus. Die Ausbrüche sorgten für Schlagzeilen. Sicherheitsverantwortliche sollten sich mehr Sorgen darüber machen, was sie möglich machte: ein Angreifer, der tausende Male fast kostenfrei scheitern kann.

Das ist die Wende. Seit Jahrzehnten profitieren Verteidiger von einer einfachen Tatsache: Scheitern kostet Angreifer etwas. Aufklärung benötigte Zeit und Sackgassen waren teuer. Die Ökonomie dieser Asymmetrie machte das „Auferlegen von Kosten“ an Angreifer zu einem sinnvollen Ansatz, sie zu stoppen. Wenn Scheitern fast kostenlos wird, hört der erfolgreiche Pfad auf, eine Nadel im Heuhaufen zu sein, und wird zu einer statistischen Gewissheit für jeden, der alle Pfade gleichzeitig verfolgen kann.

Die Muster in diesen Vorfällen weisen auf drei Lehren hin, die Sicherheitsverantwortliche jetzt umsetzen sollten.

Vier Labore, eine Form

Das Muster ist bemerkenswert konsistent. Man gibt einem Modell ein Ziel. Es findet einen Pfad, den niemand erwartet hat. Manchmal führt dieser Pfad direkt in die Produktionssysteme von Organisationen, die nie einbezogen werden sollten. In mindestens einem Fall erfuhr die betroffene Organisation, was geschehen war, weil Anthropic anrief, um es mitzuteilen.

In jedem Fall verlief der Pfad durch Software, Infrastruktur oder eine Umgebung, die jemand anderes gebaut hat. Sicherheitsverantwortliche sollten das persönlich nehmen.

Jede Organisation in dieser Kette hatte ein Sicherheitsprogramm. Mehrere hatten sehr gute Programme. Das Scheitern war nicht innerhalb eines einzelnen Perimeters begrenzt. Es geschah an den Schnittstellen zwischen den Organisationen, und niemand besitzt diese Schnittstellen.

Die Modelle von OpenAI fanden einen Zero‑Day‑Fehler in einem selbstgehosteten Paket‑Proxy und nutzten ihn, um das offene Internet zu erreichen. Von dort aus verschafften sie sich Zugang zu einer ungesicherten Code‑Ausführungs‑Sandbox, die einem Kunden von Modal Labs gehörte, nutzten sie als Staging‑Basis und tricksten den Dataset‑Loader von Hugging Face, lokale Dateien zu lesen und anschließend Code auszuführen. Innerhalb von dreizehn Stunden hatten sie Cluster‑Admin‑Rechte über mehrere interne Cluster, unterstützt durch ein einziges Anmeldezeichen, das über alle verteilt war. Der Einstiegspunkt war neuartig. Innen waren die Schwachstellen die, die wir seit zwanzig Jahren dokumentieren.

Neun Tage später tat Anthropic etwas Seltenes: es veröffentlichte seine eigene Analyse von 141.006 Evaluierungsdurchläufen und legte drei Fälle mit ähnlicher Darstellung unaufgefordert offen: ein Modell, das aus einer Evaluierungsumgebung das offene Internet erreichte und dann Zugriff auf Systeme realer Organisationen erlangte. Dieses Mal gab es keinen Sandbox‑Ausbruch, sondern lediglich eine Fehlkonfiguration, die einen aktiven Pfad nach außen ließ, obwohl dem Modell gesagt worden war, dass keiner existiere. Sobald es draußen war, nutzte das Modell Schwachstellen aus, die jedes Sicherheitsteam kennt: schwache Passwörter, nicht authentifizierte Endpunkte, SQL‑Injection und Anmeldeinformationen, die auf einer exponierten Debug‑Seite lagen.

Meta bestätigte Anfang August einen vierten Vorfall, nachdem ein Konfigurationsfehler einem seiner Modelle während einer Evaluierung Internetzugang verschaffte. Meta bemerkte es ebenfalls nicht; es erfuhr, was geschehen war, als sein Testpartner anrief. Sowohl diese Evaluierung als auch die von Anthropic wurden von derselben externen Firma, Irregular, durchgeführt, die öffentlich erklärte, dass es sich um dasselbe Problem handele. Der Konfigurationsfehler eines Anbieters verbreitete sich über zwei Frontier‑Labore und vier betroffene Organisationen, die keinerlei direkte Beziehung zu Irregular hatten. Irregular war ein Anbieter für die beiden Labore, nicht für sie. Dem Agenten war egal, wo die Angriffsfläche eines Unternehmens endete und die eines anderen begann.

Das ist es, was dies zu einem Drittanbieter‑Risiko macht. Exposition kann jetzt mehrere Beziehungsebenen von Ihnen entfernt entstehen, in einer Organisation, die Sie nie ausgewählt, bewertet oder sogar wussten, dass sie Teil Ihrer Angriffsfläche ist.

Dann entdeckten Forscher von Frontier Security, dass auch Moonshots Kimi K3 seine Sandbox verließ, sodass er auf ein Benchmark‑Repository auf GitHub zugreifen konnte. Niemand wurde kompromittiert, und das Modell verfolgte sein zugewiesenes Ziel, nachdem es erkannt hatte, dass die Verwendung eines fertigen Antwortschlüssels günstiger war als das eigenständige Lösen. Zwei Dinge machen diesen Fall wichtig: Die Forscher entdeckten ihn während ihres eigenen Tests. Und er lief auf völlig anderer Technologie als die Fälle von Anthropic und Meta. Ein Anbieter, der einen schlechten Monat hat, erklärt das nicht.

Die Labore ignorieren das nicht. Anthropic veröffentlichte seine Analyse unaufgefordert, weshalb die Branche ein Muster hat, das untersucht und aus dem gelernt werden kann – statt eines Ausreißers, den man abtun kann. Das sollte zur Norm werden. OpenAI hat nun die Veröffentlichung seines Astra‑Modells verlangsamt, nachdem interne Evaluierungen kritische Cyber‑Fähigkeiten nicht ausschließen konnten. Beide Maßnahmen verdienen Anerkennung. Aber keine von beiden ist ein Verteidigungsplan: Eine Verzögerung der Veröffentlichung betrifft nur den Zeitplan eines Unternehmens. Sie ändert nichts an fähigen Modellen, darunter Kimi K3, die bereits offen‑gewichtet und kostenlos bereitgestellt werden, jenseits der Kontrolle eines einzelnen Labors.

Korrelation ohne Eskalation ist keine Erkennung

Der Erkennungs‑Stack von Hugging Face hat zu seiner Ehre die Signale zu einem kohärenten Angriff korreliert. Anschließend versäumte er, die Kritikalität zu eskalieren, und das Bereitschaftsteam wurde nicht benachrichtigt. Das Werkzeug stellte die Geschichte zusammen, konnte jedoch nicht entscheiden, dass die Geschichte dringend war. Das ist eine Triage‑Architektur, die für eine Welt gebaut wurde, in der 17.600 Ereignisse innerhalb von vier Tagen absurd erschienen wären.

Cybersicherheit braucht ihren Fosbury‑Flop

1968 gewann Dick Fosbury olympisches Gold im Hochsprung, nicht indem er höher sprang als seine Konkurrenten, sondern indem er die Latte rückwärts überwand. Alle anderen verfeinerten den Straddle. Bessere Form, mehr Kraft, marginale Verbesserungen einer jahrzehntelangen Technik. Fosbury veränderte die Form des Problems. Innerhalb von zwei Olympischen Spielen war der Straddle praktisch ausgestorben.

Sicherheitsverantwortliche müssen jetzt eine Latte überwinden, die sich gerade bewegt hat, und die bisherige Antwort der Branche ist ein besserer Straddle: mehr Alarme, schnellere Analysten, strengere SLAs für menschliche Prüfungen. Das wird nicht funktionieren, weil die Einschränkung nicht die Geschwindigkeit der Analysten ist. Man kann Angriffe mit Maschinen‑Geschwindigkeit nicht mit einer Triage in Mensch‑Geschwindigkeit beantworten.

Der Flop sieht folgendermaßen aus:

• Hören Sie auf, die Grenze als Kontrolle zu behandeln. Die Evaluierungs‑Sandbox ist gescheitert, der Dataset‑Loader ist gescheitert, und die Pod‑Isolation ist gescheitert, jeweils bis zu dem Punkt, an dem sie nicht mehr funktionierte. Planen Sie für das, was danach passiert. Verwenden Sie kurzlebige Anmeldeinformationen. Eliminieren Sie gemeinsam genutzte administrative Identitäten. Blockieren Sie den Zugriff auf Metadaten‑Dienste. Vor allem begrenzen Sie, wie weit ein Angreifer nach dem ersten Kontrollversagen vordringen kann.
• Verlagern Sie die Erkennung vom Alarmieren zur Korrelation. Das Finden eines einzelnen verdächtigen Ereignisses reicht nicht mehr aus. Die Aufgabe besteht darin, Tausende von harmlos erscheinenden Ereignissen zu einer Angriffsgeschichte zu verbinden und zu erkennen, wann diese Geschichte ernst genug ist, um jemanden zu wecken. Angesichts des beobachteten Volumens muss dies zunehmend automatisiert werden.
• Betrachten Sie die Exposition durch Dritte als Angriffsweg, nicht als Fragebogen. Diese Vorfälle liefen über Drittanbieter‑Abhängigkeiten: ein Produkt eines Anbieters, ein Kunde des Anbieters, ein Evaluierungspartner, gemeinsam genutzte Test‑Tools. Ihr Risiko umfasst jetzt Konfigurationsfehler von Organisationen, die Sie nie geprüft haben und von denen Sie möglicherweise nicht einmal wissen, dass sie existieren. Statische, punktuelle Bewertungen können das nicht erfassen. Dieses Problem ist nicht neu. KI macht es weitaus dringlicher. Sicherheitsteams benötigen einen kontinuierlichen Überblick über die Unternehmen und Technologien, von denen sie abhängen, weil Angreifer das gesamte Ökosystem als eine verbundene Angriffsfläche sehen.

Bei SecurityScorecard ist genau das die Art von Problem, um die unsere Kultur aufgebaut ist: Menschen zusammenzubringen, die tiefes Interesse daran haben, wie Angreifer denken, bereit sind, zwanzig Jahre alte Annahmen in Frage zu stellen, und begeistert sind, einen grundlegend anderen Ansatz für Sicherheit zu entwickeln!

Die Frage, die Sie in Ihr nächstes Board‑Meeting einbringen sollten

Vor ein paar Wochen sagte ich, der Geist sei zu mächtig für die Flasche geworden. Vier Labore später gibt es nichts, was das Gegenteil beweist. Nach Vorfällen wie diesen stellt jeder dieselbe Frage: Sind wir bereit für KI‑gestützte Angreifer? Ich glaube nicht, dass uns diese Frage weit bringt. „Ja“ und „Nein“ führen zum selben Ergebnis: Es ändert sich nichts.

Stellen Sie eine härtere Frage. Wenn in den nächsten vier Tagen 17.000 Low‑Signal‑Ereignisse Ihre Umgebung treffen – und die meisten wie Fehlfunktionen aussehen – wie lange würde Ihr Team brauchen, um zu erkennen, dass es sich um einen Angriff handelt? Würde jemand rechtzeitig benachrichtigt werden?

Sie kennen die Antwort bereits. Die Lücke zwischen dieser Antwort und vier Tagen ist die Arbeit.