KI-Agenten stehlen Tausende Zugangsdaten – in weniger als sechs Stunden
Die Google Threat Intelligence Group (GTIG) machte am 8. September 2026 einen Angriff aus dem zweiten Quartal öffentlich: Ein mutmaßlich finanziell motivierter Täter setzte in der kompromittierten Cloud-Infrastruktur einer nicht genannten Organisation ein autonomes Multi-Agenten-System ein. In weniger als sechs Stunden plante, erstellte und startete der Angreifer damit eine Kampagne, bei der Tausende Zugangsdaten Dritter kompromittiert wurden.
Der am selben Tag veröffentlichte Bericht der Google Threat Intelligence Group belegt, dass die Agenten das Schwachstellen-Scanning und das Abschöpfen der Zugangsdaten ausführten, Fehler selbstständig bearbeiteten und IP-Adressen wechselten. Grundlage des Berichts sind laut GTIG unter anderem Mandiant-Einsätze, die Beobachtung von Bedrohungsakteuren und Telemetriedaten aus aktiven Plattformabwehrsystemen.
So lief die Sechs-Stunden-Kampagne ab
Der agentische Teil des Angriffs begann nicht mit dem ursprünglichen Eindringen. Der Täter hatte bereits eine Cloud-Ressource der betroffenen Organisation kompromittiert und nutzte diese Umgebung anschließend, um ein eigens zusammengestelltes Multi-Agenten-Framework zu betreiben. Welche Schwachstelle den ersten Zugang ermöglichte, nennt GTIG nicht.
Für den weiteren Ablauf kombinierte der Angreifer einen nicht näher bezeichneten KI-Coding-Chatbot, einen Prompt und mehrere Agentenanweisungen. Vorkonfigurierte Markdown-Dateien dienten als operative Playbooks: Sie gaben den Agenten den Rahmen vor, in dem diese die Kampagne planen, aufbauen und ausführen konnten.
Die Rekonstruktion von The Hacker News bestätigt für diesen Fall die Abfolge aus automatisiertem Scanning, massenhaftem Credential Harvesting, Fehlerbehandlung in Echtzeit und IP-Rotation. Die Agenten arbeiteten damit nicht ohne menschliche Vorbereitung, übernahmen innerhalb des festgelegten Rahmens aber mehrere Übergänge, die sonst wiederholte Eingriffe eines Bedieners erfordern.
Warum die kompromittierte Cloud doppelt wichtig war
Die übernommene Cloud-Ressource lieferte nicht nur Rechenleistung für das Agentensystem. Der Täter konnte den Angriffsverkehr zugleich über legitime IP-Adressen der betroffenen Umgebung leiten. Eine unauffällige Reputation der Absenderadresse war daher kein verlässliches Zeichen für harmlosen Verkehr.
Das erschwert eine Abwehr, die einzelne Netzwerkadressen isoliert bewertet. Zugleich bleibt die Cloud-Übernahme ein eigener, zeitlich vorgelagerter Schritt: Der veröffentlichte Fall zeigt keinen KI-Agenten, der selbstständig ein Opfer auswählte, den ersten Zugang beschaffte und danach ohne vorbereiteten Rahmen die gesamte Operation entwickelte.
Das Reaktionsfenster schrumpft auf Stunden
Die entscheidende Neuerung ist weniger das automatisierte Ausführen einzelner Werkzeuge als ihre enge Kopplung. Das Framework verwaltete die Scan-Pipeline, reagierte auf technische Probleme und setzte die Arbeit mit wechselnden IP-Adressen fort. Dadurch entfielen Wartezeiten zwischen Ergebnisprüfung, Korrektur und erneutem Versuch.
Für Verteidiger bedeutet das: Zwischen auffälligem Scanverkehr und der Kompromittierung einer großen Zahl von Zugangsdaten kann nur ein Teil einer Arbeitsschicht liegen. Eine Untersuchung, die auf die manuelle Sichtung am nächsten Tag wartet, setzt deshalb möglicherweise erst ein, nachdem die Kampagne ihr Ziel bereits erreicht hat.
Die Zahl von weniger als sechs Stunden beschreibt dabei den Zeitraum für Planung, Aufbau und Ausführung der massenhaften Kampagne nach der Cloud-Kompromittierung. Sie ist weder die bekannte Gesamtdauer des Vorfalls noch ein Beleg dafür, dass jede Phase des ursprünglichen Eindringens autonom ablief.
Welche Grenzen der dokumentierte Angriff hatte
Der Fall belegt einen hochgradig autonomen Arbeitsablauf, aber keine universelle Hacker-KI. Menschen stellten die kompromittierte Infrastruktur, den Prompt, die Agentenanweisungen und die Playbooks bereit. Das System automatisierte konkrete offensive Aufgaben innerhalb dieser Vorbereitung.
Auch die Einordnung von BleepingComputer trennt den Vorfall von vollständig autonomen Angriffspipelines: GTIG habe bislang keine Bedrohungsakteure beobachtet, die eine solche Pipeline zur eigenständigen Zero-Day-Suche und anschließenden Kompromittierung realer Ziele einsetzten. Der Bericht beschreibt stattdessen eine schrittweise Automatisierung bekannter Angriffstechniken.
Unklar bleiben der verwendete KI-Coding-Chatbot, die Identität der betroffenen Organisation, die ausgenutzten Schwachstellen und die genaue Art der gestohlenen Zugangsdaten. GTIG veröffentlicht außerdem keinen minutengenauen Ablauf, aus dem sich der letzte menschliche Eingriff ablesen ließe.
Wo Verteidiger den Ablauf noch erkennen können
Autonomie beseitigt technische Spuren nicht. Aus den bestätigten Angriffsschritten lassen sich mehrere Übergänge ableiten, an denen Cloud-, Netzwerk- und Identitätstelemetrie zusammengeführt werden sollte. Dabei handelt es sich um eine Folgerung aus dem dokumentierten Ablauf, nicht um veröffentlichte Indikatoren für genau diesen Täter.
- Cloud-Umgebung: unerwartete Rechenprozesse, neue oder zweckfremd verwendete Ressourcen sowie ausgehender Scanverkehr können auf den Missbrauch einer bereits übernommenen Instanz hinweisen.
- Entwicklungs- und Laufzeitumgebung: neu abgelegte Agentenanweisungen, Markdown-Playbooks und der Start eines KI-Coding-Werkzeugs sind besonders relevant, wenn sie nicht zum vorgesehenen Einsatz der Ressource passen.
- Netzwerk: gleichartige Scan- und Zugriffsfolgen sollten auch dann korreliert werden, wenn sie nach Fehlern fortgesetzt werden oder zwischen mehreren legitimen Cloud-IP-Adressen wechseln.
- Identität: die erstmalige oder gehäufte Nutzung kompromittierter Passwörter, Schlüssel und Tokens aus neuen Diensten kann die spätere Phase der Kampagne sichtbar machen.
Der öffentlich bestätigte Kern bleibt damit eng umrissen: Ein vorbereiteter agentischer Verbund beschleunigte eine reale Kampagne zum Diebstahl von Zugangsdaten auf weniger als sechs Stunden. Google erklärte allgemein zu den in seinem Bericht behandelten Aktivitäten, zugehörige Angreifer-Assets deaktiviert und Schutzmechanismen angepasst zu haben; eine namentliche Zuordnung dieses Täters, Angaben zu den Opfern und eine detaillierte Schadensbilanz stehen weiterhin aus.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.