Zehn Stunden, fünf Agenten, kein Zero-Day

Am 02.09.2026 hat Palo Alto Networks Unit 42 einen Vorfall beschrieben, bei dem KI-Agenten jeden Schritt eines Einbruchs ausführten. Die Zahl, die überall zitiert wird: unter zehn Stunden für etwas, das menschliche Angreifer laut Unit 42 rund zwei Wochen gekostet hätte, mit über 50 ATT&CK-Techniken. Zum Abschied hinterließ der Angreifer einen 80-seitigen Auditbericht über die Sicherheitslage des Opfers.

Wir haben den Bericht gegen seine eigene Erstfassung und gegen die MITRE-Daten geprüft. Dabei kamen zwei Dinge heraus, die in keiner der Meldungen stehen.

Es war keine Ransomware, und Unit 42 sagt das inzwischen selbst

Am Ende des Beitrags stehen zwei Korrekturhinweise. Der wichtigere:

"Updated Sept. 3, 2026, at 5:25 a.m. PT to clarify that the attack was an intrusion, and not a ransomware attack."

Im Text selbst ist dafür nur ein Wortende gefallen. Aus "as part of a ransomware attack" wurde "as part of a ransom attack". Das sieht nach nichts aus, und genau darin liegt der Punkt.

Ransomware heißt Verschlüsselung: ein Encryptor, eine Ransom-Note, Systeme die stillstehen, ein Wiederanlauf aus Backups. Ransom heißt Erpressung, sonst nichts. Es fehlt also der Teil, an dem die meisten Teams den Ernstfall messen und ihre Notfallplanung aufhängen. Und tatsächlich kommt im ganzen Bericht kein Encryptor vor, keine Ransom-Note, und von Verschlüsselung ist nirgends die Rede. Belegt ist eine Erpressungsverhandlung.

Zwei weitere Stellen hat Unit 42 gegenüber der über die Wayback Machine erreichbaren Erstfassung vom 02.09.2026 geändert, beide beim Erstzugang:

Mehr inhaltliche Änderungen gibt es nicht, der Rest des Textes ist unverändert. Wichtig daran ist, worauf die Berichterstattung fußt: The Register, Cybernews, DataBreaches und TechTimes tragen bis heute "ransomware" im Titel und schreiben vom API-Endpunkt. Wer die Schlagzeile übernimmt, übernimmt etwas, das der Urheber zurückgezogen hat.

Wir haben den Fall in unserem Scout am 05.09.2026 selbst noch als Ransomware-Einbruch geführt, weil wir die Sekundärquellen zuerst gelesen hatten. Das war falsch.

Die Kette

Fünf Phasen beschreibt Unit 42, ohne Zeitstempel für die einzelnen Schritte. Es gibt nur die Gesamtzahl.

1. Einstieg und Kartierung. Der Angreifer brach über einen öffentlich erreichbaren Webdienst ein und tunnelte ins Netz. Ein automatisierter Aufklärungsagent kartierte die internen Microservices.
2. Secrets einsammeln. Subagenten durchsuchten die Coderepositories und zogen dort fest eingebaute Tokens und Dienstpasswörter heraus.
3. Rechteübernahme. Mit diesen Tokens kam der Angreifer ins Secrets-Management-System und holte dort die administrativen Hauptzugangsdaten.
4. Pipeline. Über eigene Workflows wurden Cloud-Zugangsschlüssel abgezogen. Der Versuch, Hintertüren in Terraform-Konfigurationen zu legen, scheiterte.
5. KI-Infrastruktur. Mit den gestohlenen Cloud-Schlüsseln wurden die KI-Endpunkte des Opfers zur eigenen Infrastruktur umfunktioniert, die Rechenleistung der Firma also für die nächsten Schritte eingespannt.

In Schritt zwei und drei steckt der Dreh- und Angelpunkt, und er ist unspektakulär: ein hartkodiertes Token in einem Repository. Es öffnete den Secrets-Manager, und der Secrets-Manager öffnete alles Weitere. In der Technik-Tabelle steht das als T1552.001, Credentials In Files.

Zur Persistenz nennt Unit 42 fünf Ebenen gleichzeitig: SSH-Schlüssel, Serverless-Funktionen, Neustart-Richtlinien von Containern, Cloud-Identitäten und CI/CD-Pipelines.

Der einzige Schritt, der scheiterte

In diesem Vorfall hat genau eine Verteidigungsmaßnahme nachweislich gehalten, und sie steht in einem Nebensatz: Der Terraform-Backdoor-Versuch lief gegen harte Branch-Protection-Regeln und kam nicht durch.

Praktisch ist das die wertvollste Zeile des ganzen Berichts. Dahinter steckt keine Erkennungsplattform und kein trainiertes Modell. Eine Repository-Einstellung mit Mehr-Augen-Pflicht, die jedes Team heute Nachmittag einschalten kann.

Wer hier eigentlich gehandelt hat

Oft liest man, die KI habe das allein gemacht. Das gibt der Bericht nicht her. Die Aufstellung der Beteiligten findet sich ausschließlich in der Grafik. Dort sitzt oben ein Mensch als Orchestrator: Er setzt Ziele, bewertet erfolgreiche Pfade, nimmt blockierte Aufgaben wieder auf und hält den gemeinsamen Zustand für alle Agenten.

Darunter arbeiten fünf spezialisierte Rollen:

Die Bildunterschrift sagt es deutlich: Der Akteur setzt die Ziele und trifft die folgenreichen Entscheidungen, die Agenten führen aus, teilen Ergebnisse und passen sich in Echtzeit an. Automatisiert ist die Taktik. Die Strategie bleibt beim Menschen.

Nebenbei erklärt der Documentation Agent auch den 80-Seiten-Bericht. Den hat der menschliche Angreifer ausdrücklich beauftragt, er ist keine Laune der Maschine. Unit 42 setzt das Wort "report" selbst in Anführungszeichen und zeigt keine einzige Zeile daraus.

Woher die KI-Zuschreibung kommt

Hier wird der Bericht dünn. Genannt wird weder ein Anbieter noch ein Modell noch ein Framework, durchgehend heißt es nur "frontier AI models" und "attack-specific agentic AI frameworks". Und die Zuschreibung stammt nicht aus der Forensik:

"The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks."

Mehr als die Selbstauskunft eines Erpressers während einer Verhandlung ist das nicht. Unit 42 markiert sie auch nirgends als verifiziert. The Register hat nach Modellen und Frameworks gefragt und keine Antwort bekommen.

Was Unit 42 als eigene Indizien anführt, ist belastbarer: parallele Aufrufe an mehrere Modelle, strukturierte Markdown-Dateien zur Übergabe zwischen Agenten und Sitzungen, sowie Skripte, die anhand von Oberflächenelementen mit hoher Zuversicht als KI-erzeugt eingestuft wurden.

Die MITRE-Kennungen im Bericht stimmen nicht

Unit 42 ordnet den Vorfall in einer Tabelle sowohl ATT&CK- als auch ATLAS-Kennungen zu. Wir haben beide gegen die offiziellen MITRE-Daten geprüft.

Die sechs ATT&CK-Kennungen stimmen alle. Von den sechs ATLAS-Kennungen stimmt keine einzige:

Keine der sechs Bezeichnungen aus dem Bericht existiert überhaupt im ATLAS-Korpus. Nachvollziehen lässt sich das an den Rohdaten im Repository mitre-atlas/atlas-data.

Das entwertet die Beobachtungen nicht, aber es heißt: Wer diese Tabelle in ein eigenes Threat Model übernimmt, trägt falsche Kennungen weiter. Für einen Threat-Research-Beitrag ist das ein handwerklicher Fehler.

Dazu passt, was sonst fehlt: keine Indicators of Compromise, keine Erkennungsregeln, keine Hashes, IPs oder Domains. Bei Unit 42 ist das ungewöhnlich.

Wo der Fall wirklich einzuordnen ist

Wir haben im August am Siemens-Fall drei Stufen unterschieden: Werkzeugbau, Anpassung im Einsatz und Schwachstellensuche. Dieser Vorfall ist ausdrücklich nicht die dritte Stufe. Unit 42 schreibt selbst:

"What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft."

Es ist die zweite Stufe, angewendet auf die gesamte Angriffskette statt auf einen Schritt. Andy Piazza von Unit 42 formuliert es gegenüber Cyber Magazine so, und bemerkenswert ist auch, was er nicht behauptet:

"This incident is one of the first few documented agentic breaches where an attacker successfully leveraged an agentic attack against an enterprise."

"One of the first few", nicht "the first". Unit 42 erhebt keinen Erstmaligkeitsanspruch.

Am treffendsten fasst es Rickard Carlsson von Detectify gegenüber Dark Reading zusammen:

"What's striking is how ordinary the underlying weaknesses were: an exposed API, hardcoded credentials, tokens opening paths into sensitive systems. The agents didn't discover a new class of vulnerability; they moved through existing exposures faster and more systematically. The intelligence was in the coordination, not the exploitation."

Was Unit 42 empfiehlt, und was fehlt

Vier Empfehlungen stehen im Bericht: Eindämmungs-Playbooks, die Zugangsdaten, OAuth-Sitzungen, CI/CD-Pipelines und Cloud-Konten gleichzeitig entwerten statt nacheinander. Ein Inventar aller Modell-Endpunkte, API-Schlüssel, MCP-Gateways und KI-Werkzeuganbindungen mit Rate Limits und Least Privilege. Die Suche nach Verhaltensschleifen. Und verpflichtende Mehr-Augen-Reviews samt unveränderlicher Branch Protection auf allen Infrastructure-as-Code-Repositories.

Eine Empfehlung fehlt, und es ist ausgerechnet die zum Kern des Angriffs: Zu Secrets-Management sagt der Bericht nichts. Hartkodierte Tokens im Repository waren der Hebel, der alles Weitere geöffnet hat, aber kurzlebige Zugangsdaten, Secret-Scanning einschließlich der Git-Historie und knapp geschnittene Dienstkonten kommen nicht vor. Carlsson füllt die Lücke von außen: Repositories, Pipelines, Infrastructure as Code und Secrets-Management gehören zur Angriffsfläche.

Erkennungsmerkmale

Konkret werden zwei Gruppen genannt. Auf dem Host: strukturierte Markdown-Dateien, Python-Caches und paarweise angelegte Asset-Ordner. Im Netz und in den Logs: stoßweise API-Anfragen, schnelle Wechsel zwischen den HTTP-Zuständen 401 und 200, parallele Anmeldungen und plötzliche Modellnutzung durch Identitäten, von denen man sie nicht erwartet.

Am eingängigsten ist das Markdown-Detail. Die Agenten reichten ihre Zwischenstände als strukturierte Markdown-Dateien weiter, also genau in dem Format, das viele Entwickler aus ihren eigenen Agenten-Setups kennen.

Die naheliegende Kritik

Der Beitrag endet mit einem Werbelink auf Unit 42s eigenes KI-Verteidigungsangebot, und das ist im Register-Forum nicht unbemerkt geblieben. Ein Leser dort:

"They advertise the worst effects of AI as proof of how much you need it - to protect yourself from it."

Der Einwand ist berechtigt, entkräftet den Vorfall aber nicht. Ein zweiter trifft besser, weil er auf die Architektur zielt: Ein Netz, in dem ein kompromittierter öffentlicher Endpunkt direkt ins gesamte Unternehmen führt, wäre auch ohne KI gefallen, nur langsamer. Und ein dritter bleibt offen: Ob die 80 Seiten inhaltlich stimmen, weiß niemand, gesehen hat den Bericht außer dem Opfer und Unit 42 niemand.

Bemerkenswert ist zuletzt, wie wenig der Fall überhaupt diskutiert wurde. Beide Einreichungen auf Hacker News kamen über zwei Punkte und null Kommentare nicht hinaus. Deutschsprachige Berichterstattung dazu haben wir keine gefunden.

Was das für euch heißt

Fazit

Als Beleg dafür, dass KI jetzt selbstständig Unternehmen übernimmt, taugt der Vorfall nicht. Ein Mensch hat die Ziele gesetzt, es gab keinen Zero-Day, und die ausgenutzten Schwächen sind die üblichen: ein exponierter Dienst, Zugangsdaten im Quelltext, Tokens mit zu weitem Zugriff.

Er taugt als Beleg für etwas anderes. Wenn dieselben bekannten Löcher in zehn Stunden statt in zwei Wochen durchlaufen werden, verschwindet die Zeit, in der man so etwas bemerkt. Die Antwort darauf liegt vor der Erkennung: bei Löchern, die gar nicht erst offen stehen.

Und beim Lesen von Sicherheitsberichten lohnt derselbe Reflex, den wir hier angewendet haben. Der Bericht wurde nach Erscheinen in einem zentralen Punkt korrigiert, und seine MITRE-Zuordnung hält einer Prüfung nicht stand. Beides ändert nichts an dem, was passiert ist, aber es ändert etwas daran, wie sicher man es weitererzählen sollte.