Google identifiziert ersten KI-entwickelten Zero-Day in freier Wildbahn

Die entscheidende Frage, die jeder Head of Platform mit einem Open-Source-Admin-Stack im Produktivbetrieb seinem CISO diese Woche stellen sollte, lautet nicht, ob KI das Bedrohungsmodell verändert – sondern ob das aktuelle Vulnerability-Budget davon ausgeht, dass Angreifer in menschlicher Geschwindigkeit agieren. Google erklärt diese Annahme nun für überholt. Eine bekannte Cybercrime-Gruppe nutzte ein KI-Modell, um einen funktionierenden Zero-Day zu entwickeln. Dass dieser nicht massenweise ausgenutzt wurde, liegt allein daran, dass Google rechtzeitig beim Hersteller intervenierte.

Was geschah

Am Montag veröffentlichte Google einen Bericht seiner Gemini-, Google Threat Intelligence Group (GTIG)- und Mandiant-Teams, der zusammenfasst, wie Angreifer KI in aktiven Operationen einsetzen. Das zentrale Ergebnis, wie SecurityWeek berichtete, ist, dass Google erstmals einen Zero-Day-Exploit identifiziert hat, der mit KI-Unterstützung entwickelt wurde.

Ziel war ein nicht namentlich genanntes, webbasiertes Open-Source-Systemadministrationstool. Der Payload war ein Python-Skript, das dazu diente, die Zwei-Faktor-Authentifizierung zu umgehen. Der ebenfalls ungenannte Bedrohungsakteur schien eine Massenausnutzung vorzubereiten, bevor Google beim Hersteller eingriff.

Google formulierte die Attribution vorsichtig: „Obwohl wir nicht glauben, dass Gemini verwendet wurde, haben wir basierend auf Struktur und Inhalt dieser Exploits hohes Vertrauen, dass der Akteur wahrscheinlich ein KI-Modell zur Unterstützung bei der Entdeckung und Bewaffnung dieser Schwachstelle eingesetzt hat", schrieb das Unternehmen. Die Hinweise waren stilistischer Natur: „Das Skript enthält eine Fülle von erklärenden Docstrings, einschließlich eines halluzinierten CVSS-Scores, und verwendet ein strukturiertes, lehrbuchhaftes Pythonic-Format, das charakteristisch für LLM-Trainingsdaten ist (z. B. detaillierte Hilfe-Menüs und die saubere _C ANSI-Farbklasse)."

Das ist nicht der einzige Datenpunkt im Bericht. China- und Nordkorea-verbundene Gruppen sind prominent vertreten. Ein China-verbundener Akteur setzte agentische Tools namens Strix und Hexstrike bei Angriffen auf ein japanisches Technologieunternehmen und ein großes ostasiatisches Cybersicherheitsunternehmen ein. Die chinesische Gruppe UNC2814, bekannt für Angriffe auf Telekommunikations- und Regierungsziele, nutzte einen persona-gesteuerten Jailbreak, bei dem das Modell angewiesen wurde, als leitender Sicherheitsprüfer zu agieren, und dann auf TP-Link-Firmware mit OFTP-Implementierungen angesetzt wurde. Nordkoreas APT45 sendete Tausende repetitiver Prompts, um CVEs rekursiv zu analysieren und PoC-Exploits zu validieren, und baute dabei, was Google als „ein solideres Arsenal an Exploit-Fähigkeiten, das ohne KI-Unterstützung unpraktikabel zu verwalten wäre" bezeichnet.

Technische Analyse

Lässt man den KI-Rahmen beiseite und betrachtet, was sich im Arbeitsablauf des Angreifers tatsächlich verändert hat: Ein 2FA-Bypass gegen ein webbasiertes Admin-Tool ist keine neuartige Schwachstellenklasse. Das Interessante ist die dahinterliegende Produktionspipeline.

Historisch gesehen durchläuft die Bewaffnung eines Auth-Bypasses einige personal-intensive Schritte: Quellcode lesen, die State Machine für den zweiten Faktor identifizieren, einen Logikfehler oder eine Race Condition finden, das Python-Skript schreiben und es für den unbeaufsichtigten Einsatz gegen Hunderte oder Tausende von Zielen härten. Jeder Schritt ist an die Zeit eines qualifizierten Operators gebunden. Die forensische Signatur, die Google beschreibt – der halluzinierte CVSS-Score, die lehrbuchhaften Docstrings, die saubere ANSI-Farbhilfsklasse – zeigt, dass der Operator große Teile dieser Pipeline an ein Modell delegiert hat. Das Skript liest sich wie LLM-Output, weil es LLM-Output ist, leicht überwacht.

UNC2814s persona-gesteuerter Jailbreak ist aus einem verwandten Grund bedeutsam. Das Modell als „leitenden Sicherheitsprüfer" zu behandeln ermöglicht dem Operator, Reasoning zu extrahieren, das die Sicherheitsvorkehrungen des Anbieters sonst blockieren würden. Kombiniert mit eingebetteter Firmware (TP-Link OFTP) erhält man kostengünstiges, paralleles Reverse Engineering von Binär-Blobs, das zuvor einen Spezialisten erforderte. APT45s Muster ist wiederum anders – weniger kreativ und industrieller: Tausende repetitiver Prompts, rekursive CVE-Analyse, automatisierte PoC-Validierung. Das ist ein Batch-Job, kein Hacker. Es ähnelt eher einer ETL-Pipeline als einer Kill Chain.

Für Defender, die diese Verhaltensweisen auf MITRE ATT&CK abbilden: Die Techniken selbst sind nicht neu. Resource Development, Reconnaissance, Develop Capabilities. Neu ist die Kostenkurve. Derselbe Operator führt jetzt zehn parallele Discovery-Schleifen statt einer durch. Die Ökonomik verschiebt sich von „eine gute Schwachstelle pro Analyst pro Quartal" zu „eine gute Schwachstelle pro Analyst pro Woche". Das ist die Zahl, die auf dem Whiteboard eines CISOs stehen sollte.

Wer betroffen ist

Die ersten Betroffenen sind alle, die Open-Source-Admin-Tools betreiben, die über das Internet erreichbar sind. Das ungenannte Ziel in Googles Bericht ist das kanonische Profil: Web-UI, Privilegien auf Systemebene, 2FA als letzte Verteidigungslinie, gepflegt von einem kleinen Freiwilligenteam. iGaming-Betreiber mit selbst gehosteten Ops-Dashboards, Fintechs mit Rancher- oder Portainer-artigen Konsolen, Krypto-Custodians mit internen Admin-Panels hinter SSO und TOTP – alle passen in dieses Profil.

Die zweite Betroffenengruppe sind alle, deren Bedrohungsmodell davon ausging, dass N-Day-Patching-Rhythmen ausreichend sind. Wenn APT45s Muster sich verallgemeinert, komprimiert sich das Fenster zwischen öffentlicher CVE-Veröffentlichung und bewaffnetem PoC gegen null. Patch-SLAs, die für ein 14- oder 30-Tage-Fenster geschrieben wurden, werden zur Haftung, die der CFO irgendwann in einem Incident-Report sehen wird.

Die dritte Gruppe sind die Hersteller selbst. Google arbeitete still mit dem betroffenen Hersteller zusammen, um eine Massenausnutzung zu verhindern – und das ist die betriebswirtschaftliche Frage, die noch niemand einpreist. Wer zahlt für koordinierte Offenlegung auf KI-Geschwindigkeit? Der Maintainer eines kostenlosen Admin-Tools hat keinen Sicherheitsingenieur auf Abruf. Der Hyperscaler, der den Exploit entdeckte, übernahm die Kosten als Goodwill-Funktion des Betriebs von Mandiant. Dieses Modell skaliert nicht auf den Tausende-Tools umfassenden Long-Tail, von dem jedes Platform-Team tatsächlich abhängt.

Hier sollten der General Counsel und der VP Engineering diese Woche ein fünfzehnminütiges Gespräch führen. Der GC möchte wissen, ob das SBOM des Unternehmens und die Vendor-Security-Fragebögen Open-Source-Admin-Tools überhaupt abdecken oder ob das Beschaffungswesen nur kommerzielle Anbieter prüft. Der VP Engineering möchte wissen, welche dieser Tools einen kostenpflichtigen Support-Tier mit Sicherheitsreaktion haben und was es kosten würde, die kritischen davon darauf umzustellen – bevor das nächste vierteljährliche Board-Update ansteht.

Playbook für Sicherheitsteams

Drei konkrete Maßnahmen für die nächsten 30 Tage.

Erstens: Die Admin-Ebene inventarisieren. Jedes webbasierte Systemadministrationstool mit einer Login-Seite, die vom Unternehmensnetzwerk aus erreichbar ist, sollte mit seiner 2FA-Implementierung erfasst werden. Wird 2FA über ein Plugin oder eine eigenentwickelte Middleware statt über das Framework durchgesetzt, ist dies zu eskalieren. Der Google-Exploit zielte genau auf diese Nahtstelle.

Zweitens: Das Patch-SLA-Modell von „Kalendertage nach CVE" auf „Stunden nach Exploit-Signal" umstellen. Den CISA KEV-Feed in die On-Call-Rotation einbinden, falls noch nicht geschehen, und einen Tier für jeden CVE hinzufügen, der Tools auf der oben genannten Admin-Inventarliste betrifft. APT45s rekursives PoC-Validierungsmuster bedeutet, dass der öffentliche CVE jetzt ein Startschuss ist, keine Planungsgröße.

Drittens: Gegen das agentische Recon-Muster härten, das UNC2814 demonstriert hat. Eingebettete Firmware, Netzwerkgeräte und Edge-Geräte kommen jetzt für kostengünstiges Reverse Engineering in Betracht. Wenn der Perimeter noch Consumer-Grade-Router, Branch-Office-Switches mit veralteter Firmware oder IoT-Bridges umfasst, die niemand patcht, sind diese jetzt erstklassige Assets im Bedrohungsmodell. Sie sollten hinter einem verwalteten Gateway platziert oder ersetzt werden. Die Build-vs.-Buy-Rechnung hat sich verändert, weil die Build-Kosten des Angreifers gerade gesunken sind.

Eine organisatorische Anmerkung: Der Einstellungsmarkt für Offensive-Security-Engineers, die LLM-Tooling verstehen, wird sich in Kürze deutlich verschärfen. Teams, die bis Q4 warten, um Stellen nachzubesetzen, werden 30 bis 50 Prozent über den aktuellen Vergütungsbändern zahlen. Retention-Gespräche sollten jetzt geführt werden.

Wichtigste Erkenntnisse

• Googles Bericht markiert das erste Mal, dass das Unternehmen öffentlich einen Zero-Day-Exploit identifiziert hat, den es KI-gestützter Entwicklung zuschreibt – ein 2FA-Angriff auf ein Open-Source-Admin-Tool.
• Die forensischen Hinweise waren stilistischer Natur – halluzinierte CVSS-Scores und lehrbuchhaftige Pythonic-Struktur –, keine neuartige Schwachstellenklasse. Verändert hat sich die Kostenkurve der Bewaffnung.
• Staatlich verbundene Akteure wie UNC2814 und APT45 betreiben bereits im großen Maßstab KI-gestützte Schwachstellenforschung – mit Persona-Jailbreaks und rekursiver PoC-Validierung.
• Teams, die Open-Source-Admin-Tools mit über das Internet erreichbaren Login-Oberflächen betreiben, sind unmittelbar exponiert. Patch-SLAs auf Basis von 14 bis 30 Tagen sind jetzt zu langsam.
• Platform-Leads, die ihre nächste Infrastrukturentscheidung evaluieren, sollten jetzt fragen: Welche unserer kritischen Open-Source-Abhängigkeiten hat einen finanzierten Sicherheitsreaktionspfad, und was kostet es, die übrigen bis Jahresende darauf umzustellen?