Wie ein KI-unterstützter Akteur ohne Exploit in über 600 FortiGate-Geräte eingedrungen ist

Zwischen dem 11. Januar und dem 18. Februar 2026 kompromittierte ein russischsprachiger, finanziell motivierter Akteur mehr als 600 FortiGate-Firewall-Appliances in mehr als 55 Ländern – und tat dies, ohne eine einzige Schwachstelle im Produkt auszunutzen. Amazon Threat Intelligence, das die Untersuchung am 20. Februar 2026 veröffentlichte, erklärt, der Akteur habe im Internet exponierte Management-Schnittstellen auf den Ports 443, 8443, 10443 und 4443 gefunden und sich mit häufig wiederverwendeten Passwörtern bei Konten ohne Multi-Faktor-Authentifizierung Zugang verschafft. Die von ihm erbeuteten Gerätekonfigurationen enthielten SSL-VPN-Anmeldedaten mit wiederherstellbaren Passwörtern, Administrator-Anmeldedaten, Firewall-Richtlinien und Netzwerktopologie. Kommerzielle große Sprachmodelle kamen während der gesamten Operation zum Einsatz, schrieben Aufklärungswerkzeuge und entwarfen Angriffspläne; nach Angaben eines separaten Forschers, der den eigenen Server des Akteurs entdeckte, war ein Modell zudem so konfiguriert, offensive Befehle auszuführen. Dieser Vorfall ist ein Eintrag in dem Orca AI Incident Archive, das den vollständigen Datensatz, seine Quellenangaben und seine Bewertung sowie die benachbarten Fälle der Serie enthält.

Was Amazon meldete – und wie es davon erfuhr

Der Bericht „KI-gestützter Bedrohungsakteur greift im großen Umfang auf FortiGate-Geräte zu“ wird CJ Moses, CISO von Amazon Integrated Security, zugeschrieben und wurde am 20. Februar 2026 im AWS Security Blog veröffentlicht. Seine erste substanzielle Erkenntnis ist eine negative: „Es wurde keine Ausnutzung von FortiGate-Schwachstellen beobachtet.“ Der Erstzugriff erfolgte durchgängig über Anmeldedaten – systematisches Scannen nach Verwaltungsschnittstellen auf den vier oben genannten Ports, gefolgt von Authentifizierungsversuchen mit häufig wiederverwendeten Anmeldedaten.

Was die Kampagne sichtbar machte, war die eigene operative Sicherheit des Akteurs. Amazon gibt an, die Infrastruktur, die die schädlichen Tools beherbergte, durch routinemäßige Bedrohungsaufklärung identifiziert zu haben, und dass derselbe Server KI-generierte Angriffspläne, Opferkonfigurationen und den Quellcode für maßgeschneiderte Tools enthielt, die unverschlüsselt gespeichert waren. Diese Nachlässigkeit verschaffte Amazon einen nahezu vollständigen Einblick in die Methodik. „Es ist wie ein KI-gestütztes Fließband für Cyberkriminalität“, heißt es in dem Bericht.

Die gestohlenen Konfigurationsdateien sind das Sprungbrett von der Appliance in das dahinterliegende Netzwerk. Laut Amazon enthalten sie SSL-VPN-Benutzeranmeldedaten mit wiederherstellbaren Passwörtern, administrative Anmeldedaten, vollständige Netzwerktopologie- und Routinginformationen, Firewall-Richtlinien, die die interne Architektur offenlegen, sowie IPsec-VPN-Peer-Konfigurationen. Der Akteur schrieb KI-unterstützte Python-Skripte, um sie zu parsen, zu entschlüsseln und zu organisieren.

Die Post-Exploitation – in Amazons eigenen Worten

Nach dem Eindringen folgte der Akteur einem standardisierten, gut dokumentierten Weg. Seine auf Russisch verfasste Betriebsdokumentation beschreibt die Verwendung von Meterpreter mit dem mimikatz-Modul, um DCSync-Angriffe gegen Domänencontroller auszuführen und NTLM-Kennwort-Hashes aus Active Directory zu extrahieren. Bei bestätigten Kompromittierungen erlangte er vollständige Domänen-Anmeldeinformationsdatenbanken. Amazon nennt mindestens einen Fall, in dem das Domänenadministrator-Konto ein Klartextkennwort verwendete, das entweder aus der FortiGate-Konfiguration wiederverwendet oder unabhängig davon schwach war.

Von dort aus sind die dokumentierten Techniken Pass-the-Hash und Pass-the-Ticket gegen weitere Infrastruktur, NTLM-Relay unter Verwendung gängiger Poisoning-Tools sowie Remote-Befehlsausführung auf Windows-Hosts. Der Akteur zielte mit PowerShell-Skripten, kompilierten Entschlüsselungswerkzeugen und Versuchen gegen bekannte Veeam-Schwachstellen gezielt auf Veeam Backup & Replication-Server ab – ein Verhalten, das Amazon als „konsistent mit Vor-Ransomware-Operationen“ beschreibt, obwohl im Bericht nicht festgehalten ist, dass Ransomware eingesetzt wurde.

Die Notizen des Akteurs verweisen auf mehrere CVEs, darunter CVE-2019-7192, CVE-2023-27532 und CVE-2024-40711. BleepingComputer, das am 21. Februar 2026 über den Bericht berichtete, identifiziert die erste als eine QNAP-Schwachstelle für Ferncodeausführung und die beiden letzteren als Veeam-Probleme. Keine davon war der Einstiegspunkt. Noch aufschlussreicher: Dieselben Notizen verzeichnen wiederholte Fehlschläge – bereits gepatchte Dienste, geschlossene Ports, Exploits, die auf das Zielbetriebssystem nicht anwendbar waren. Für ein bestätigtes Opfer kam die eigene Einschätzung des Akteurs zu dem Schluss, dass die Schlüsselinfrastruktur „gut geschützt“ sei und es „keine ausnutzbaren Schwachstellenvektoren“ gebe.

Zwei Einschränkungen bei der Zuschreibung sollten klar ausgesprochen werden. Amazon gibt an, der Akteur sei „nicht dafür bekannt, mit einer Advanced-Persistent-Threat-Gruppe mit staatlich geförderten Ressourcen in Verbindung zu stehen“, und es sei nicht beobachtet worden, dass AWS-Infrastruktur an der Kampagne beteiligt gewesen sei.

Wo die KI tatsächlich saß

Amazons Darstellung der KI-Ebene ist konkret in Bezug auf Rollen, aber schweigt zu Produkten. Der Akteur nutzte mindestens zwei verschiedene kommerzielle LLM-Anbieter, heißt es in dem Bericht: einen als primären Tool-Entwickler, Angriffsplaner und operativen Assistenten und einen zweiten als ergänzenden Planer, wenn der Akteur Hilfe beim Pivotieren innerhalb eines bestimmten Netzwerks brauchte. In einem beobachteten Fall übermittelte der Akteur eine vollständige interne Topologie – IP-Adressen, Hostnamen, bestätigte Zugangsdaten und identifizierte Dienste – und bat um einen Schritt-für-Schritt-Plan, um Systeme zu erreichen, die seine vorhandenen Tools nicht erreichen konnten.

Amazons Beweis dafür, dass die Werkzeuge maschinell geschrieben wurden, ist stilistischer und nicht forensischer Natur. Er listet redundante Kommentare auf, die lediglich Funktionsnamen wiederholen, eine Architektur, die mehr in die Ausgabeformatierung als in die Funktionalität investiert, JSON, das durch String-Matching statt ordnungsgemäße Deserialisierung geparst wird, und Kompatibilitäts-Shims mit leeren Dokumentationsplatzhaltern. Die Werkzeuge funktionierten für den engen Anwendungsfall des Akteurs und scheiterten an den Randfällen. Das Volumen, so merkt Amazon an, würde normalerweise ein Entwicklungsteam implizieren; hier stammte es von einem Akteur oder einer sehr kleinen Gruppe.

Der AWS-Bericht enthält keinen Modellanbieter, keinen Produktnamen und keine Erwähnung des Model Context Protocol. Diese erscheinen in einer zweiten Forschungsarbeit, die am nächsten Tag veröffentlicht wurde.

Der Server und die Namen, die Amazon nicht veröffentlicht hat

Am 21. Februar 2026 veröffentlichte der Security-Blog Cyber and Ramen seine eigene Analyse eines offenen Verzeichnisses unter 212.11.64[.]250:9999, gehostet auf AS4264 (Global-Data System IT Corporation, Zürich) – eine der beiden Adressen, die Amazon als Infrastruktur von Bedrohungsakteuren führt. Der Forscher zählte 1.402 Dateien in 139 Unterverzeichnissen, darunter gestohlene FortiGate-Konfigurationsbackups, Active-Directory-Mapping-Daten, Credential-Dumps, Nuclei-Scanvorlagen und Veeam-Tools zur Extraktion von Zugangsdaten, sowie zwei nach Claude benannte Ordner mit über 200 Dateien mit Aufgabenausgaben, Session-Diffs und zwischengespeicherten Prompt-Zuständen.

In dieser Analyse werden zwei benutzerdefinierte Komponenten genannt. ARXON wird als ein Python-Server für das Model Context Protocol beschrieben, der zielspezifische Aufklärungsdaten aufnimmt, DeepSeek aufruft, um Angriffspläne zu erstellen, und eine Wissensdatenbank unterhält, die mit jedem Ziel wächst; außerdem enthält er Skripte für die SSH-basierte Massenanlage von FortiGate-VPN-Konten und die Validierung von Domain-Admin-Anmeldedaten. CHECKER2 ist ein Go- und Docker-basierter Orchestrator für paralleles VPN-Scanning, dessen Logs 2.516 Ziele in 106 Ländern zeigen. Der Forscher gibt an, dass keine öffentlichen Referenzen zu einem der beiden Tools gefunden werden konnten, was darauf hindeutet, dass beide für diese Operation entwickelt wurden.

Dieselbe Analyse beschreibt eine Exponierung desselben Servers im Dezember 2025, wobei diese eine Kopie von HexStrike, einem Open-Source-Framework für offensive MCP, und eine .claude-Einstellungsdatei enthielt, in der Claude Code vorab die Berechtigung erteilt wurde, Impacket-Tools, Metasploit und hashcat gegen hartcodierte Domänenanmeldeinformationen eines Mitarbeiters eines großen asiatischen Medienunternehmens auszuführen. Bis Februar, so der Forscher, habe sich der Akteur von diesem Open-Source-Ausgangspunkt zu ARXON und CHECKER2 bewegt — ein Fortschreiten über rund acht Wochen.

BleepingComputer gab diese Erkenntnisse in einem Update zu seinem Artikel vom 21. Februar weiter. Der Unterschied ist wichtig: ARXON, CHECKER2, DeepSeek und Claude Code sind die Lesart des Forschers von Dateien, Protokollen und Einstellungen in einem ungesicherten Verzeichnis. Amazon, das unabhängigen Zugang zu derselben Infrastruktur hatte, nannte keinen davon. Kein Modellanbieter hat davon etwas bestätigt.

Was gesichert ist, was auf einer einzigen Quelle beruht

Drei Behauptungen stützen sich auf zwei unabhängige Parteien. Fortinets eigener Blogbeitrag vom 6. März 2026, „Attacks at the Speed of AI“, stellt fest, dass Fortinet „keine Ausnutzung von FortiGate-Schwachstellen beobachtet“ habe und dass die Kampagne durch exponierte Management-Ports und schwache Anmeldedaten mit Ein-Faktor-Authentifizierung unter Verwendung von Password Spraying erfolgreich gewesen sei. Das bestätigt Amazons Mechanismus von der Seite des Herstellers, ohne dass eine der Parteien die veröffentlichten Beweise der anderen gesehen hätte.

Amazon allein ist die Quelle für den Umfang – mehr als 600 Geräte, mehr als 55 Länder, das Zeitfenster von Januar bis Februar – und für das Akteursprofil: russischsprachig, finanziell motiviert, technische Basis auf niedrigem bis mittlerem Niveau, umfangreiche Abhängigkeit von KI, geringe Post-Exploitation-Tiefe, unzureichende Operationssicherheit. Keine dritte Partei hat die Zahl 600 bestätigt.

Cyber and Ramen allein ist die Quelle für das genannte Tooling, die Modellanbieter, die Dateianzahlen und die 2.516 Scan-Ziele. Seine eigenen Beweisdokumente bestätigten Kompromittierungen bei einem Industriegasunternehmen im Asien-Pazifik-Raum, einem Telekommunikationsanbieter in der Türkei und dem Medienunternehmen aus der Dezember-Offenlegung, wobei Aufklärungsaktivitäten auf Südkorea, Ägypten, Vietnam und Kenia verweisen — ein bestätigter Opferkreis in mindestens fünf Ländern, deutlich weniger als die 55, die Amazon nennt. Die beiden Zahlen messen unterschiedliche Dinge, und keine von beiden wurde öffentlich abgeglichen.

Fortinets Reaktion – und das Ausmaß, das es nicht bestätigte

Fortinets Beitrag von Carl Windsor, datiert auf den 6. März 2026, stimmt mit Amazon hinsichtlich des Mechanismus überein und weicht hinsichtlich der Größenordnung ab. „Basierend auf Fortinets Untersuchung und Überwachung waren einige wenige Kunden von diesem Angriff betroffen“, heißt es darin. „Wir sind dabei, diese Organisationen zu benachrichtigen.“ Es bestätigt nicht 600 Geräte, übernimmt Amazons Länderzahl nicht und nennt den Akteur nicht.

Fortinets Darstellung zufolge ist die Technik alt und die Automatisierung neu: Password-Spraying gegen schlecht geschützte Edge-Geräte, jetzt angetrieben durch No-Code-Prompt-basierte Konversationen. Das Unternehmen erklärt, der Angriff „wäre mit MFA nicht möglich gewesen“ und „höchst unwahrscheinlich erfolgreich“ gewesen, wenn eine Passwortkomplexitätsrichtlinie aktiviert wäre. Es veröffentlichte außerdem Indikatoren: Administratorzugriff von 212[.]11.64[.]250 oder 185[.]196.11[.]225, die Erstellung von Konten namens fortiuser, fortinet-support oder fortinet-tech-support, unerwartete VPN-Konfigurationen oder -Benutzer sowie Skripte, die als Persistenzmechanismus zur Ausführung geplant sind.

Dabei handelt es sich um eine Abweichung beim Umfang, nicht um einen Streit darüber, ob die Kampagne stattgefunden hat. Niemand, der in den Akten namentlich genannt wird, bestreitet den Eingriff; das Archiv bewertet ihn mit A, ohne Kennzeichnung als strittig, und verzeichnet echten Schaden.

Was hat sich danach geändert?

Es gibt keine CVE und keinen Patch, denn es gab keine Schwachstelle. Die Behebung erfolgt über die Konfiguration, und beide Organisationen kamen auf dieselbe Liste. Amazon erklärt, es habe Kompromittierungsindikatoren mit relevanten Partnern geteilt, mit Branchenpartnern zusammengearbeitet und Organisationen dabei geholfen, Maßnahmen zu ergreifen, die die Wirksamkeit des Akteurs verringert hätten; der Bericht nennt keine Zahl der benachrichtigten Organisationen. Fortinet erklärt, es benachrichtige betroffene Kunden direkt.

Die technische Leitlinie ist bei beiden gleich: Administrativen Zugriff von internetzugewandten Schnittstellen entfernen und über einen internen oder Out-of-Band-Pfad verwalten; MFA für administrativen und VPN-Zugriff erzwingen; Passwortkomplexität anwenden; SSL-VPN-Anmeldeinformationen auf jedem Gerät rotieren, dessen Verwaltungsschnittstelle erreichbar war oder gewesen sein könnte; auf Passwortwiederverwendung zwischen FortiGate-VPN-Konten und Active Directory prüfen; und Backup-Infrastruktur isolieren, patchen und unveränderliche Kopien beibehalten.

Zur Erkennung verweist Amazon auf DCSync-Aktivitäten (Ereignis-ID 4662 mit replikationsbezogenen GUIDs), neue geplante Aufgaben, die so benannt sind, dass sie legitime Windows-Dienste nachahmen, ungewöhnliche Remoteverwaltungsverbindungen aus VPN-Adresspools, Artefakte von LLMNR- und NBT-NS-Poisoning sowie unbefugten Zugriff auf Backup-Speicher für Anmeldeinformationen. Es wird außerdem gewarnt, dass signaturbasierte Erkennung hier nur begrenzten Nutzen hat, da die Tools aus legitimen Open-Source-Dienstprogrammen — Impacket, gogo, Nuclei — bestehen, die in normalen Penetrationstests auftauchen.

Warum der Rekord ein Meilenstein ist

Das Archiv kennzeichnet dies als Meilenstein-Eintrag, und der Grund dafür zeigt sich im Kontrast zwischen dem, was der Akteur erreichte, und dem, was der Akteur leisten konnte. Ein einzelner Operator oder eine sehr kleine Gruppe, eingeschätzt mit niedrigem bis mittlerem Fähigkeitsniveau, führte gleichzeitige Intrusionen in Dutzenden Ländern durch, erstellte ein Toolkit, das normalerweise auf ein Entwicklungsteam hindeuten würde, und erzeugte zielspezifische Angriffspläne schnell genug, um mehrere Intrusionen gleichzeitig voranzutreiben.

Derselbe Bericht liefert die Obergrenze. Der Akteur konnte keine maßgeschneiderten Exploits kompilieren, fehlgeschlagene Ausnutzungsversuche nicht debuggen und nicht improvisieren, wenn ein Plan auf ein gehärtetes Ziel traf – also zog er weiter, statt dranzubleiben. Sein KI-generierter Code brach an den Rändern. Seine Einsatznotizen sind eine Aufzeichnung gepatchter Dienste und geschlossener Ports. Was die Modelle beseitigten, war Arbeit, nicht Urteilsvermögen: Aufklärung, Parsing, Dokumentation und Planung wurden automatisiert; die Teile, die Anpassung erforderten, blieben außer Reichweite.

Das ist auch der Grund, warum die offenen Fragen nüchtern und konkret sind. Wie viele Organisationen Fortinet tatsächlich benachrichtigt hat, würde die Diskrepanz zwischen „einigen wenigen Kunden“ und mehr als 600 Geräten klären. Eine zweite Untersuchung des ARXON-Verzeichnisses, unabhängig von dem Forscher, der es entdeckt hat, würde klären, um welches Tooling es sich handelte und welche Modelle es ansprach. Bis dahin stützt die Aktenlage eine belastbare Schlussfolgerung zur Methode und eine deutlich schwächere zum Ausmaß.