CyberStrikeAI in freier Wildbahn: Ein LLM-Orchestrator erlangte bei Zielen im Bildungssektor in Lateinamerika und Afrika Domain-Admin-Rechte

Am 2. November 2026 veröffentlichte Kaspersky einen Securelist-Bericht und eine Pressemitteilung, in denen Intrusionen bei Organisationen im Bildungssektor in mehreren Ländern Lateinamerikas und Afrikas beschrieben werden, bei denen die Post-Exploitation-Arbeit von einem großen Sprachmodell gesteuert wurde. Das Werkzeug war CyberStrikeAI, ein quelloffenes, auf Go basierendes Penetration-Testing-Framework, dessen Command-and-Control-Server ein LLM hostet, das Tools auswählt und Befehle schreibt, während ein gewöhnliches Implant sie auf dem Opfer-Host ausführt. In dem einen Fall, den Kaspersky detailliert rekonstruiert, drang ein menschlicher Bediener über einen kompromittierten Microsoft SQL Server ein, pausierte zwei Wochen und ließ dann den Agenten laufen: Domänenadministrator-Konten fielen innerhalb von drei bis vier Tagen, und die letzte Phase – laterale Bewegung, massenhaftes Credential-Dumping und ein Datenbankexport – war innerhalb einer Stunde abgeschlossen. Kaspersky nennt keine Institution und kein Land, gibt keine Opferzahl an und gibt an, die Aktivität zwischen September und Oktober 2026 beobachtet zu haben. Der vollständige Datensatz zu dieser Kampagne mit ihrer Schweregrad-Einstufung, Konfidenzbewertung und vollständigen Quellenliste findet sich im Orca AI Incident Archive, zusammen mit den anderen Einträgen zu KI-unterstützten Intrusionen.

Was Kaspersky tatsächlich veröffentlicht hat

Das Hauptdokument ist „CyberStrikeAI in the wild: the use of AI in real-world attacks on organizations“, veröffentlicht auf Securelist am 2. November 2026 und Kirill Antonov, Vladislav Vlasov und Dmitry Chizhmak vom Threat-Research-Team von Kaspersky zugeschrieben. Es wird von Kasperskys eigener Pressemitteilung begleitet, die am selben Tag herausgegeben wurde und dieselben Ergebnisse zusammenfasst. Der Vertrauensgrad A des Archivs beschreibt, wie gut diese beiden Dokumente miteinander übereinstimmen und wie spezifisch die technischen Details sind; er ist keine Aussage darüber, dass eine zweite Organisation die Eindringung unabhängig verifiziert hat.

Die Sekundärberichterstattung dieses Berichts liefert jene zweite Organisation nicht. Cybersecuritynews.com, Cyberpress, SecurityOnline und das in Nairobi ansässige TechTrends Kenya veröffentlichten zwischen dem 2. und 3. November 2026 allesamt Berichte, und jeder davon stützt sich auf Kasperskys Veröffentlichung statt auf eigene Untersuchungen; der Beitrag des kenianischen Mediums ist um dasselbe Zitat aus der Pressemitteilung von Nikita Nazarov, Leiter Threat Exploration bei Kaspersky, herum aufgebaut. Stand 9. November 2026 hatte keine betroffene Universität, kein Bildungsministerium und kein nationales Computer-Notfallteam die Eindringlinge öffentlich bestätigt, und Kaspersky hat die Identitäten der Opfer nicht veröffentlicht. Dieses Fehlen ist selbst Teil der Überlieferung: Ausführlich dokumentiert ist die Vorgehensweise, nicht der Schaden für eine namentlich genannte Institution.

Die Scope-Erklärung von Kaspersky ist bewusst eng gefasst. Die bestätigten Opfer waren, in ihren Worten, „Organisationen im Bildungssektor in mehreren Ländern in Afrika und Lateinamerika“. Es wird nicht gesagt, wie viele, welche Länder oder wie die Kampagne überhaupt entdeckt wurde – nur, dass das Team sie „im Rahmen einer proaktiven Bedrohungsüberwachung“ gefunden hat.

Eine Unterscheidung ist hier wichtig, weil sie leicht verwischt werden kann. Unabhängige Organisationen haben inzwischen von CyberStrikeAI bei realen Eindringversuchen berichtet – jedoch nicht bei diesen Eindringversuchen. Team Cymru brachte Infrastruktur, auf der das Tool lief, mit der Kampagne Januar–Februar 2026 gegen mehr als 600 FortiGate-Geräte in Verbindung; dabei wurden zwischen dem 20. Januar und dem 26. Februar 2026 21 eindeutige IP-Adressen beobachtet, die es bereitstellten. Die TrendAI-Einheit von Trend Micro beschrieb in einer am 23. Oktober 2026 veröffentlichten Untersuchung einen Operator, der 44 koordinierte CyberStrikeAI-Agenten betrieb, die mindestens 19 identifizierbare Organisationen – mindestens 16 davon in Japan – in einem kurzen Zeitfenster im Oktober einer Validierungsaktivität unterzogen. Die Forschungsnotiz der Cloud Security Alliance vom 28. Oktober 2026 führt beides zusammen und kommt zu dem Schluss, dass keine veröffentlichte Quelle die separaten CyberStrikeAI-Kampagnen bislang mit einem einzigen Akteur in Verbindung gebracht hatte. Diese Arbeit stützt die Prämisse – dass dieses Framework genutzt wird, um reale Netzwerke anzugreifen – und sagt nichts über die Opfer im Bildungsbereich in Lateinamerika und Afrika in Kasperskys Bericht aus.

Das Tool – und wo die KI tatsächlich saß

{{1}}CyberStrikeAI{{/1}} ist, wie Kaspersky es beschreibt, „{{2}}eine modulare Open-Source-Plattform, die in Go geschrieben wurde, um Penetrationstests zu automatisieren.{{/2}}“ Ihre prägende Designentscheidung besteht darin, dass die gesamte intelligente Ebene auf dem Kontrollserver des Angreifers liegt, nicht auf dem Rechner des Opfers. Reconnaissance- und Exploit-Werkzeuge, Webshell-Verwaltung, die Aufgabenzuweisung an Agenten und das Lesen der Ergebnisse werden dem Modell alle als MCP-Tools innerhalb eines einzigen Serverprozesses bereitgestellt, und das Modell entscheidet, welches davon es als Nächstes aufruft.

Das Implant ist die andere Hälfte, und es ist absichtlich dumm. Kaspersky schreibt, es sei „ein klassischer C2-Agent ohne KI-Funktionalität – keine API-Schlüssel, keine Aufrufe von KI-Dienst-APIs und keine autonome Logik“. Es fragt den Listener über HTTP/S, TCP oder WebSocket ab, führt Shell-Befehle aus und greift auf das Dateisystem zu. Es ist kein Modell, das im Netzwerk eines Opfers läuft, und es kontaktiert nie einen KI-Anbieter. Die Arbeitsteilung ist der Satz, mit dem Kaspersky das gesamte Schema erklärt: „Entscheidungen sind auf zwei Ebenen verteilt: Der Operator definiert die Aufgabe in allgemeiner Form, während das Modell bestimmt, wie sie ausgeführt wird.“

Die menschliche Kontrolle bleibt erhalten und wird nicht entfernt. Kaspersky weist auf einen Human-in-the-Loop-Mechanismus hin, bei dem „der Bediener die volle Kontrolle über den Prozess behält“ und die vom Modell generierten Befehle „vor ihrer Ausführung möglicherweise eine manuelle Genehmigung oder Korrektur erfordern“. Die KI schreibt die Schritte; eine Person kann sie dennoch ablehnen.

Eine rekonstruierte Intrusion, in der Reihenfolge, in der Kaspersky sie datiert.

Der Bericht beschreibt einen einzelnen Vorfall innerhalb der Kampagne, und seine erste Phase wirkt wie gewöhnliche manuelle Arbeit an der Tastatur. Befehle auf den Systemen des Opfers kamen vom Prozess sqlservr.exe, was auf „einen kompromittierten SQL Server (Version 16.0.1000)“ als wahrscheinlichen Einstiegspunkt hindeutet. Der Operator sammelte dann grundlegende Hostinformationen, setzte Tools ein und kartierte das Netzwerk manuell. Das dauerte „fast einen Tag“, danach blieben die Angreifer etwa zwei Wochen lang still.

Die zweite Phase ist der Punkt, an dem sich das Tempo ändert. Mit dem bereitgestellten CyberStrikeAI-Agenten wurden Persistenz und lokale Aufklärung „innerhalb von 2 Minuten“ durchgeführt – eine geplante Aufgabe namens SystemUpdate, die auf das Implantat verwies, wobei ein Registrierungs-Run-Schlüssel unter HKCU\Software\Microsoft\Windows\CurrentVersion\Run die Alternative des Frameworks unter Windows war, und ein crontab-@reboot-Eintrag oder eine nohup-Zeile in ~/.bashrc als seine Alternativen unter Linux. Die Domänenaufklärung lief „über die nächsten 5 Stunden“ und nutzte vom Modell generierte PowerShell-Skripte sowie LDAP-Abfragen gegen Active Directory, einschließlich der Nachschlagevorgänge, die zur Vorbereitung von Kerberoasting und AS-REP Roasting benötigt wurden, sowie Prüfungen auf LAPS-, Azure- und .azcopy-Verzeichnisse. Nach „einer kurzen Pause von mehreren Tagen“ dauerte die letzte Phase – laterale Bewegung über SMB und WMI, massenhaftes Auslesen von Anmeldeinformationen und ein Datenbankexport – „nicht mehr als eine Stunde“.

Kasperskys Fazit ist der Satz, den man sich merken sollte: Der gesamte Angriff – „von der Bereitstellung des Agents bis zur Kompromittierung der Domänenadministratoren“ – wurde innerhalb von 3–4 Tagen abgeschlossen.

Die Arbeit mit den Zugangsdaten ist eher ein Katalog bekannter Windows-Techniken als etwas Neues: Registrierungs-Hives, die mit reg.exe kopiert wurden, lsass.exe, über die MiniDump-Funktion von comsvcs.dll gedumpt, wobei die Prozess-ID statt ihres Namens verwendet wurde, um die Erkennung über die Befehlszeile zu umgehen, und – nachdem das integrierte Domänenadministrator-Konto kompromittiert worden war – DCSync- und Golden-Ticket-Angriffe, ausgeführt über eine umbenannte Mimikatz-Binärdatei, wdiag2.exe. Für die laterale Bewegung wurden Impackets WMIExec, gemeinsam genutzte administrative Ordner und WMI verwendet, wobei ein Reverse-Shell-Skript, p1.ps1, auf Remote-Hosts geschoben wurde und eine Rückverbindung zu 185.186.245[.]144:5501 aufbaute. Payloads wurden in Fragmente wie d3.b64 aufgeteilt und mit certutil wieder zusammengesetzt, und ein Beacon tarnte sich als svchosts.exe.

Die Datensammlung erfolgte zuletzt. Der Agent erstellte auf die jeweilige Aufgabe zugeschnittene SQL-Abfragen, prüfte jedoch vor deren Ausführung die Privilegien des Datenbankkontos, durchsuchte Netzwerkfreigaben rekursiv, bevor er Dateien abrief, und übermittelte alles über denselben verschlüsselten C2-Kanal, wobei die Daten Base64-kodiert in JSON eingebettet waren. Screenshots unter Windows und Linux waren verfügbar, wurden nach Kasperskys Darstellung aber nur dann erstellt, wenn der Orchestrator den Befehl dazu erteilte. Im Bericht heißt es, die Datensammlung sei „die letzte Phase des Angriffs gewesen: Die Kette endete dort, und wir haben keine weiteren Aktivitäten beobachtet."

Was genommen wurde und was die Aufzeichnung nicht sagt

Kaspersky berichtet, dass der Agent Datenbankeinträge vom SQL-Server der Bildungsorganisation exportiert und Dateien aus Netzwerkressourcen gesammelt hat, und beschreibt den Mechanismus im Detail. Es wird nicht angegeben, wie viele Datensätze oder Dateien abgeflossen sind, ob der Export abgeschlossen wurde oder wessen Daten sich in den Tabellen befanden. Sekundäre Zusammenfassungen gehen in diesem Punkt weiter als der Bericht: Der Beitrag von SecurityOnline schreibt, der Agent habe „gezielte SQL-Abfragen generiert, um Datensätze von Schülern und Mitarbeitern aus Datenbanktabellen zu stehlen“, während Kasperskys eigener Text die Abfragen gegen einen SQL-Server im Bildungsbereich beschreibt, ohne zu spezifizieren, was die Tabellen enthielten. Leser sollten die Beschreibung „Datensätze von Schülern und Mitarbeitern“ als sekundäre Charakterisierung und nicht als Kaspersky-Befund betrachten.

Ebenfalls nicht dokumentiert ist: ob ein Opfer das Eindringen selbst bemerkt hat, was die einzelnen Institutionen danach unternommen haben, ob Regulierungs- oder Datenschutzbehörden in den betroffenen Ländern benachrichtigt wurden und ob die Kampagne noch andauert. Kaspersky gibt lediglich an, dass die Datenerfassung der letzte beobachtete Schritt in den von ihr untersuchten Vorfällen war. Die Pressemitteilung enthält keine Anleitung zur Behebung für die betroffenen Organisationen – ihre Empfehlungen richten sich allgemein an Verteidiger.

Attribution: Was die Beweise stützen und was nicht.

Kaspersky sagt ausdrücklich, dass es keinen Akteur nennen kann. „Die verfügbaren Daten erlauben es uns nicht, die Aktivität mit einer bekannten Angreifergruppe in Verbindung zu bringen, noch mit Sicherheit zu sagen, dass derselbe Operator hinter beiden Kampagnen steckt.“ Das Artefakt, auf das Kaspersky sich stützt, sind die Go-Build-Metadaten in den Implantaten, die Versionskontroll-Hashes, Commit-Zeiten und ein Dirty-Working-Copy-Flag enthalten – „ein einzigartiger Fingerabdruck für einen bestimmten Build.“ Auf dieser Grundlage lassen sich die Samples in zwei Gruppen aufteilen, und innerhalb jeder Gruppe weisen die Windows- und Linux-Payloads identische Metadaten auf, was bedeutet, dass sie aus derselben Arbeitskopie stammen.

Die Gruppen gehören nicht zusammen. Sie „teilen keine gemeinsame C2-Infrastruktur“, und auf den beiden Sätzen von Kontrollservern liefen unterschiedliche Versionen von CyberStrikeAI. Kaspersky nennt zwei Gründe, warum die Attribution hier schwierig ist: Das Framework ist öffentlich verfügbar, sodass verschiedene Akteure unter ähnlichen Bedingungen unabhängig voneinander Payloads hätten erstellen können, und die Befehle selbst sind modellgeneriert, was ihre Vielfalt erhöht und zugleich die individuellen Eigenheiten entfernt, auf denen die verhaltensbasierte Attribution beruht.

Was bleibt, ist eher ein Hinweis als ein Beweis. Einige Skripte enthielten Kommentare auf Chinesisch, die Angreifer nutzten den chinesischen Dienst dnslog[.]cn, um den Internetzugriff von Opfer-Hosts zu bestätigen, und die meisten Neustarts der Kontrollserver – rekonstruierbar, weil das selbstsignierte TLS-Zertifikat bei jedem Start im Speicher neu erzeugt wird, sodass sein not_before-Feld den Neustartzeitpunkt aufzeichnet – fielen in die Geschäftszeiten von UTC+8. CyberStrikeAI selbst wurde innerhalb der chinesischen Cybersicherheitsgemeinschaft entwickelt. Kasperskys Pressemitteilung zieht die Grenze klar: Diese Artefakte „belegen weder die Identität noch den Standort der Angreifer“, und das Unternehmen „konnte die Aktivität keiner bekannten Bedrohungsgruppe zuordnen oder bestätigen, dass derselbe Akteur die gesamte identifizierte Infrastruktur kontrollierte“. Ein chinesischsprachiger Betreiber ist eine Schlussfolgerung, kein Befund.

Warum Kaspersky sagt, dass dies kein Erkennungsnotfall ist

Die Schlussfolgerung des Berichts widerspricht der Vorstellung, dass ein LLM in der Kill Chain eine neue Klasse von Verteidigung erfordert. Da das Modell auf dem Server des Angreifers läuft, „hinterließ es keine Spuren seiner Anwesenheit in der Infrastruktur (etwa spezifische API-Anfragen an lokale LLMs oder anomale Muster des Ressourcenverbrauchs durch Hosts)“. Was Verteidiger stattdessen sehen, ist eine wie von Menschen ausgeführte Intrusion: dieselben Utilities, dieselben Sequenzen, dieselben Ereignisprotokolleinträge. Kasperskys Urteil lautet, dass „die Einführung von KI in die Angriffskette noch keine grundlegend neuen Herausforderungen für die Erkennung darstellt“, dass „klassische, gut abgestimmte Korrelations- und Verhaltensanalyseregeln ausreichen“ und dass die Neuheit „nicht in den Methoden selbst liegt, sondern in der Geschwindigkeit und Leichtigkeit, mit der sie ausgeführt wurden“.

Die veröffentlichten Erkennungen folgen dieser Logik, statt neue zu erfinden. Kaspersky Anti Targeted Attack vergibt das Netzwerk-Verdikt Backdoor.CyberStrikeAI.HTTP.C&C für den Datenverkehr des Implantats; eine Regel zur Erkennung von Netzwerkanomalien namens „Scanning domain records via LDAP queries“ erfasst die Domänenaufklärung; Kaspersky SIEM enthält mehr als 100 Regeln, die die im Bericht beschriebenen Techniken abdecken, darunter DCSync, Golden Ticket, Kerberoasting und Impacket WMIExec; und die Implantate werden als HEUR:HackTool.Win64.CyberStrike.gen und HEUR:HackTool.Linux.CyberStrike.gen klassifiziert. Kasperskys Empfehlung an Kunden ist konventionell – Endpoint Detection and Response, Netzwerkerkennung, Threat Intelligence und Überwachung außerhalb der Arbeitszeiten oder über einen Managed Service.

Nazarovs Aussage in der Pressemitteilung ist dasselbe Argument in einem Satz: Die Angreifer „nutzten einen KI-Agenten auf Basis von CyberStrikeAI, um eine vollständige Angriffskette durchzuführen und ihre nächsten Schritte in kompromittierten Netzwerken anzupassen“, doch „das Framework stützte sich weiterhin auf bekannte Techniken und Verfahren, einschließlich Discovery, Credential Dumping, lateraler Bewegung sowie Sammlung und Exfiltration.“

Was gilt als gesichert und was nicht

Um es klar zu sagen: Der Mechanismus ist bis zu einem Grad dokumentiert, der es einem Verteidiger ermöglichen würde, ihn schon morgen zu jagen – Prozessabstammung von sqlservr.exe, eine geplante Aufgabe namens SystemUpdate, LSASS-Zugriff über comsvcs.dll, DCSync von einem Rechner, der kein Domain Controller ist, der HTTP-Header X-Implant-Token und die von Kaspersky aufgeführten C2-Adressen. Die Kampagne rund um diesen Mechanismus ist es nicht. Kaspersky veröffentlichte keine Opferliste, keine Länderaufschlüsselung, keine Schätzung des Datenvolumens und keinen Akteur. Alles, was ein Leser darüber wissen möchte, wer geschädigt wurde und wie schwer, endet bei Sektor und Region.

Zwei Details sollten für alle hervorgehoben werden, die den Bericht mit weitergehenden Erwartungen lesen. Erstens beschreibt Kaspersky den Angriff als „eine der ersten öffentlichen Beschreibungen einer Kompromittierung mit einem LLM in freier Wildbahn“ und nicht als die erste – eine Absicherung, die die Behauptung auf das beschränkt, was das Team in öffentlich zugänglichen Berichten finden konnte. Zweitens stellt der Bericht fest, dass die Version des Implantats nicht mit der des Servers Schritt hält, dass Listener-Konfigurationen und Schlüssel Operator-Updates überleben und dass das Build-Datum einer Probe nur ein frühestmögliches Einsatzdatum liefert, nicht die Dauer einer Kompromittierung. Die Angabe von 3–4 Tagen ist eine Messung eines rekonstruierten Vorfalls, keine Grenze dafür, wie lange eine dieser Intrusionen andauerte, bevor sie jemand bemerkte.