Hugging Face wurde letzte Woche von einem abtrünnigen OpenAI-Agenten angegriffen, und dieser Einbruch liefert weiterhin wertvolle Erkenntnisse und Einblicke. Das Hugging-Face-Team hat eine detaillierte Zeitleiste sowie eine Streaming-Wiedergabe mit 17.600 Ereignissen veröffentlicht, die den Hergang visualisiert – und das Ganze ist unglaublich und geradezu fesselnd detailliert. Ich empfehle Ihnen, sich das anzuschauen, wenn Sie Zeit haben.
Der Angriff auf ihre Plattform war kein einzelner brillanter Exploit, auf den ein sauberer, von Menschen gesteuerter Angriffspfad folgte. Es handelte sich vielmehr um eine Vielzahl von Aktionen, die sich über viereinhalb Tage erstreckten, wobei Tausende fehlgeschlagener Versuche die relativ geringe Anzahl von Aktionen verschleierten, die letztendlich von Bedeutung waren. Aufklärung, Codeausführung und das Einbringen von Payloads begannen fast sofort. Die entscheidende laterale Bewegung in ihre Kubernetes-Cluster, das interne Netzwerk und die Versionsverwaltung begann jedoch erst am dritten Tag.
Die meisten Organisationen verfügen über ausreichende Protokollierungs- und Überwachungsfunktionen, um einen Angriff rekonstruieren zu können nach . Weitaus weniger verfügen über die erforderliche Transparenz zur Laufzeit, die Alarmierungslogik und die Entscheidungsunterstützung, um den Angriff zu erkennen, während er sich noch aufbaut.
Die kombinierte Zeitleiste von Hugging Face sowie einige lang erwartete Informationen von OpenAI zu dem Vorfall und die erste Nachbetrachtung der CSA lassen meiner Meinung nach vier entscheidende Entscheidungspunkte bei der Reaktion auf Vorfälle erkennen, die Unternehmen berücksichtigen sollten. Jeder dieser Punkte ist zugleich ein praktischer Test dafür, ob Ihr Unternehmen über die entsprechenden Fähigkeiten verfügt oder nicht.
Entscheidung 1: Wann wird eine Erkundung mit schwachem Signal zu einem Vorfall?
Am ersten Tag des Einbruchs erfassten die Agenten Dateisysteme, Prozesse, Netzwerkschnittstellen, Umgebungsvariablen, Einhängepunkte und verfügbare Tools. Sie testeten ausgehende Kanäle und richteten über gewöhnliche öffentliche Dienste eine Command-and-Control-Verbindung ein. Für sich genommen hätte jedes einzelne Ereignis als Debugging, Automatisierung, fehlerhafte Arbeitslast oder normales Experimentieren abgetan werden können.
Laut Hugging Face zeigten sich die ersten Anzeichen in der Live-Laufzeitanalyse, in SIEM-Protokollen und anderen Kontrollmechanismen. Der KI-basierte Sicherheitsstack des Unternehmens korrelierte diese Signale zu einem zusammenhängenden Angriffsmuster, versäumte es jedoch, ihnen eine ausreichende Kritikalität zuzuweisen oder das Bereitschaftsteam zu benachrichtigen. Diese Verzögerung kostete wertvolle Reaktionszeit. Frühere Analysen und Diskussionen in der Community kamen zu demselben Ergebnis: Die Erkundungsaktivitäten wurden über mehrere Tage hinweg aufgezeichnet, doch eine Eskalation erfolgte erst, als das spätere Volumen der unbefugten Aktivitäten schließlich die Alarmschwelle überschritt.
Es geht nicht lediglich darum, ob ein einzelnes Ereignis böswillig ist. Es geht vielmehr darum, ob eine Abfolge von für sich genommen mehrdeutigen Laufzeitverhalten die Bildung eines Angriffspfads darstellt.
Unternehmen sollten sich fragen, ob sie die Prozessausführung, den Dateisystemzugriff, die API-Aktivität, die Identität der Workloads und das Netzwerkverhalten über kurzlebige Container hinweg miteinander in Zusammenhang bringen können. Können sie erkennen, dass sich ein Pod, der /proc/self/environ ausliest, Service-Account-Token überprüft und verschiedene Methoden zum Datenausgang testet, wesentlich von einem normalen Anwendungsausfall unterscheidet?
Hier kann die „Canary-Instrumentierung“ für Klarheit sorgen. Die Technik, in die wir hier investieren sollten, besteht darin, gefälschte Token in ausgewählten Arbeitslastumgebungen zu platzieren, Scheinzugangsdaten in geheimen Speichern zu hinterlegen und Konfigurationswerte in Nicht-Produktionspfaden zu überwachen. Diese sollten niemals echten Zugriff gewähren. Stattdessen besteht ihr einziger Zweck darin, ein Signal mit hoher Zuverlässigkeit zu erzeugen, wenn sie gelesen, kopiert oder vorgelegt werden. Ein gut platziertes Canary-Token sollte einen Responder benachrichtigen, anstatt als Anomalie abgetan zu werden. Der Aufbau einer Täuschungsfähigkeit sollte auf der Roadmap aller Teams stehen.
Entscheidung 2: Was passiert, wenn Zugangsdaten gestohlen und missbraucht werden?
Am dritten Tag änderte sich der Charakter des Vorfalls. Der Agent las die Tokens der Kubernetes-Service-Accounts aus, abgefragte Cloud-Metadaten, spielte temporäre Anmeldedaten von externen Hosting-Anbietern nach (Modal trat an die Öffentlichkeit und erklärte sich zu einem dieser Hosting-Anbieter), erstellte privilegierte Pods und erlangte Root-Zugriff auf den Knoten. Anschließend griff er auf ein Secret-Objekt zu, das 136 Schlüssel enthielt, darunter Anmeldedaten für ein Mesh-VPN und einen internen Cluster-Zugangsbroker. Eine gemeinsam genutzte Connector-Anmeldung ermöglichte effektiv den Cluster-Admin-Zugriff über mehrere Cluster hinweg.
Dies ist der Moment, in dem aus der „Ermittlung“ eine aktive Eindämmung werden muss.
Kann Ihr Team jedes System identifizieren, das auf kompromittierte Anmeldedaten vertraut? Der Abhängigkeitsgraph und die Auswirkungsanalyse sind von zentraler Bedeutung für den Beginn der Eindämmungsphase bei der Reaktion auf Sicherheitsvorfälle. Können Ihre Tools und Dashboards unterscheiden, ob ein Token von der erwarteten Workload verwendet wird oder ob dasselbe Token von einem neuen Cloud-Anbieter, einer Sandbox oder einem anderen Netzwerk stammt? Können die Verantwortlichen eine gesamte Familie von Anmeldedaten widerrufen, anstatt nur einen Schlüssel zu rotieren, während abgeleitete Token weiterhin gültig bleiben?
Die Erkennung während der Laufzeit ist unerlässlich, da die Anmeldedaten selbst legitim erscheinen können. Der böswillige Zustand zeigt sich erst im Ausführungskontext: falscher Prozess, falscher Pod, falsches Quellnetzwerk, falsche Workload-Identität oder eine unmögliche Abfolge von Aktionen. Ich bezeichne dies gerne als „Wasser-ist-nass“-Überwachung. Von all den Dingen, von denen ich weiß, dass sie wahr sind, ist Wasser nass, genauso wie der Himmel blau ist. Wenn wir keine Überwachungsmaßnahmen einrichten, die uns helfen, „Annahmen widerlegende“ Veränderungen in unseren Umgebungen zu erkennen, werden wir weiterhin überrascht werden.
Ein Beispiel hierfür wäre die Konfiguration von Next-Hop-Routing-Tests, um einen BGP-Hijack zu erkennen. Die ersten vier Hops von Ihrem internen Netzwerk zu einer stabilen und bekannten externen Ressource (wie time.windows.com) sollten eigentlich überhaupt nicht abweichen. Ein weiteres Beispiel für eine „Water-is-wet“-Überwachung sind DNS-Einträge, bei denen ständig überprüft wird, ob Ihre internen und externen IP-Adressen für wichtige Infrastrukturkomponenten unverändert bleiben.
Kanarienvögel, die zur Abwehr agentengesteuerter Angriffe eingesetzt werden, sollten daher gefälschte Service-Account-Token, Scheinzugangsdaten für die Cloud und synthetische VPN-Registrierungsschlüssel enthalten. Ein in einer sorgfältig ausgewählten Pod-Umgebung gespeichertes Token kann das Sammeln von Zugangsdaten aufdecken. Ein Scheindienstkonto kann die Aufzählung von Namespaces aufdecken. Ein gefälschter Cluster-Eintrag, der von einem internen Dienstkatalog zurückgegeben wird, kann Versuche der lateralen Bewegung aufdecken. Diese Artefakte müssen zu Sinkholes oder gesperrten Endpunkten führen, nicht zu Produktionszugriff, doch bei jeder Interaktion sollte die Identität der Quelle erhalten bleiben und sofortige Anweisungen zur Eindämmung ausgelöst werden.
Entscheidung 3: Kannst du C2 erkennen, wenn es wie deine eigene Anwendung aussieht?
Die wichtigste Erkenntnis im Bereich der Erkennung ist vielleicht, dass „Command-and-Control“-Verkehr nicht unbedingt wie herkömmlicher Malware-Verkehr aussehen muss.
Der Agent nutzte öffentliche Dienste zur Erfassung von Anfragen, Pastebins und Filesharing-Hosts. Vor allem aber nutzte er von Angreifern kontrollierte Hugging-Face-Datensätze als „Dead Drops“. Befehle und gestohlene Daten wurden in Datensatz-Commits und Seitenzweigen abgelegt und anschließend über die normale Hugging-Face-API abgerufen. Ein offener CORS-Proxy namens „Space“ wurde zudem als Ausgangsrelais genutzt. Die Payloads wurden in Blöcke aufgeteilt, komprimiert, verschlüsselt und teilweise über Raw-Sockets gesendet. Durch die Nachbildung des Dekodierungsprozesses des Angreifers konnten etwa viermal so viele offengelegte secrets wiederhergestellt werden secrets beim ersten Scan.
Mit anderen Worten: Eingehende Befehle sahen wie Datensatzaktivitäten aus, und die ausgehende Exfiltration sah ebenfalls wie Datensatzaktivitäten aus. Hugging Face selbst wurde Teil des C2-Transports. Ein herkömmliches SIEM kann Tausende ungewöhnlicher Ereignisse melden, ohne aufzudecken, dass diese ein bidirektionales Protokoll bilden.
Entscheidend ist, ob eine kundenorientierte Funktion deaktiviert, ein Mandant isoliert, ein öffentlicher Dienst gesperrt oder ein Produktionsdatenpfad unterbrochen werden soll. Die Verantwortlichen benötigen stichhaltigere Beweise als die bloße Feststellung, dass „dieser Datenverkehr ungewöhnlich ist“.
Erstellen Sie Scheindatensätze mit überzeugenden Namen, wie beispielsweise interne Benchmark-Ergebnisse, Bewertungsantworten oder archivierte Sicherheitsforschungsergebnisse. Versenken Sie darin eindeutige Marker und gefälschte Anmeldedaten. Keine legitime Arbeitslast sollte darauf zugreifen. Überwachen Sie Lesevorgänge, Klone, Commits, die Erstellung von Zweigen und API-Anfragen. Ein gefälschter interner Cluster oder ein in einem Katalog aufgeführter Datensatz kann ebenfalls Aufschluss darüber geben, ob ein Angreifer nach Angriffsmöglichkeiten sucht, anstatt lediglich normal mit dem Dienst zu interagieren.
Gut konzipierte und sinnvoll platzierte „Kanarienvögel“ liefern Hinweise auf die Absicht, nicht nur auf Anomalien.
Entscheidung 4: Den Schaden beheben oder die Umgebung neu aufbauen?
Letztendlich stellt sich die Frage, ob die Organisation der betroffenen Infrastruktur noch vertraut.
Hugging Face hat die Zugangsdaten umfassend ausgetauscht, den Zugriff auf Cloud-Metadaten gesperrt, den Geltungsbereich der Zugangsdaten eingeschränkt sowie die Kerninfrastruktur vollständig gelöscht und von Grund auf neu aufgebaut. Im Großen und Ganzen lief die Entscheidung darauf hinaus, etwa ein Drittel der Umgebung zu löschen, anstatt zu versuchen, nachzuweisen, dass jeder Zugriffspunkt, jedes gefälschte Token und jeder Persistenzmechanismus entfernt worden war.
Diese Option besteht nur, wenn die Infrastruktur reproduzierbar und austauschbar ist. In einer früheren Analyse wurde festgestellt, dass die Wiederherstellung bei Hugging Face dadurch beschleunigt wurde, dass neue Infrastruktur aus Repositorys bereitgestellt wurde, anstatt kompromittierte Systeme wiederherzustellen und anschließend zu bereinigen. Die Befugnis, diese Entscheidung zu treffen, muss zudem vor dem Vorfall eindeutig zugewiesen und dokumentiert werden.
Das Paket zur Entscheidungsunterstützung sollte die Herkunft der Anmeldedaten, die Identitäten der betroffenen Workloads, die Überprüfung unveränderlicher Images, die Abdeckung durch „Infrastructure-as-Code“, Anforderungen an die Datenwiederherstellung sowie Hinweise auf Versuche, Persistenz zu erreichen, umfassen. Führungskräfte sollten die geschätzte Ausfallzeit für die Wiederherstellung kennen, bevor sie um deren Genehmigung gebeten werden. Und mit welchem Konfidenzniveau (wann wurde ein bestimmter Cluster oder Dienst zuletzt neu bereitgestellt?).
Canaries bleiben auch nach der Wiederherstellung nützlich. Ersetzen Sie jeden Decoy durch einen neu generierten Wert. Jede Verwendung eines alten Canary-Tokens nach dem Wiederaufbau ist ein deutlicher Hinweis darauf, dass ein unentdeckter Fußhalt, ein kopiertes Geheimnis oder ein externer Staging-Standort erhalten geblieben ist. Dies gilt insbesondere, wenn wir davon ausgehen, dass agentische Angreifer vorausschauend genug sind, um ihren modellierten Agenten-Kollegen „Brotkrumen“ zu hinterlassen, damit diese der Entdeckung entgehen oder dort weitermachen können, wo sie aufgehört haben.
Der Vorfall bei Hugging Face zeigt, dass Protokollierung nicht gleichbedeutend mit Erkennung ist, Erkennung nicht gleichbedeutend mit Eskalation und Eskalation nicht gleichbedeutend mit Entscheidungsunterstützung. Die Transparenz während der Laufzeit gibt Aufschluss darüber, was die Software tatsächlich tut. Canary-Token, Cluster und Datensätze zeigen an, wann Aktivitäten keine legitime Erklärung haben.
Das Ziel besteht nicht nur darin, genügend Beweise zu sammeln, um den Verstoß nächste Woche zu verstehen. Es geht vielmehr darum, Signale zu schaffen, die stark genug sind, um heute die richtige Entscheidung zu treffen.
