Nach Angaben von CERT-In nutzt Crafty Falcon öffentlich verfügbare, KI-gestützte Offensivwerkzeuge wie ARTEX, PentAGI, Cairn und CyberStrikeAI. „Diese Werkzeuge führen vollständige Angriffsketten autonom in Maschinengeschwindigkeit aus, erzeugen und verfeinern in schneller Folge große Mengen maßgeschneiderter Angriffsskripte und passen ihre Payloads an die Reaktionen des Ziels an", erklärte die Behörde. Die unterstützende Angriffsinfrastruktur wechsle ihre IP-Adressen innerhalb von Stunden bis Tagen. Betroffen seien auch Kryptowährungsbörsen und Anbieter digitaler Vermögenswerte; dort kam es zum Diebstahl von Schlüsseln und Geldern.

Die Mitteilung folgt auf eine Warnung von CERT-In aus dem Oktober 2026 zu mehreren Angriffskampagnen gegen Nichtbanken-Finanzunternehmen (NBFCs), digitale Kreditplattformen, Fintechs, Zahlungsdienstleister und Betreiber von Krypto-Wallets.

Beobachtet wurde, dass Angreifer über ins Internet exponierte Anwendungen, offene APIs und privilegierte Endpunkte API-Zugangsdaten von Zahlungsaggregatoren, Gateways und Partnerbanken stehlen und anschließend Überweisungs-APIs direkt aus der eigenen, freigeschalteten Infrastruktur der betroffenen Unternehmen heraus aufrufen. Weitere Erstzugangswege:

  • gestohlene langlebige statische, fest einprogrammierte API-Token
  • Lieferkettenkompromittierung von Quellcode-Repositorien über gefälschte Commits
  • Klartext-Zugangsdaten in Konfigurationsdateien, Quellcode oder Datenbanken
  • Anwendungen und Fernzugänge ohne Mehrfaktor-Authentifizierung

Damit werden laut CERT-In Kontrollen auf Anwendungsebene ausgehebelt — etwa bei Kreditanlage, KYC, Sanktionsprüfung, Empfängerverifikation, Deckungsprüfung und Transaktionslimits. Die schnell ausgeführten betrügerischen Transaktionen sollen Gelder auf von den Tätern kontrollierte Mule-Konten bei mehreren Banken verschieben. Zugleich löschen die Betreiber Protokolle und manipulieren Endpunktschutzlösungen, um Erkennung und Incident Response zu erschweren.

Angegriffen werde außerdem Cloud-Infrastruktur, um Befehle auszuführen und Schadcode auszurollen, sowie öffentlich erreichbare Nicht-Produktivumgebungen, aus denen gemeinsam genutzte Zugangsdaten, Token oder Netzwerkpfade stammen, über die der Sprung in Produktionssysteme gelingt.

Als weitere Post-Exploitation-Schritte nennt CERT-In:

  • Reverse Engineering von Anwendungs-Codebasen zur Entwicklung maßgeschneiderter Exploits
  • unautorisierte API-Aufrufe über modifizierte Anwendungspakete, die Kontrollen untergraben, welche „davon ausgingen, dass nur die legitime Client-Anwendung die APIs aufruft"
  • Mikro-Testtransaktionen (etwa 1 Rupie) zur Validierung unautorisierter Geldflüsse vor großen Überweisungen
  • Missbrauch von Händler-Settlement-APIs von Zahlungsaggregatoren zum Verschieben von Geldern
  • Ausnutzung neu offengelegter Schwachstellen, darunter Datei-Upload- und Deserialisierungs-Exploitketten, die zu Webshells in PHP- und Node.js-Anwendungen führen
  • massenhaftes Erzeugen eigener Skripte und deren iterative Verbesserung in schneller Folge — ein Muster, das auf KI-gestützte Entwicklung hindeutet

Parallel hat CERT-In Prüfrichtlinien für die Sicherheit künstlicher Intelligenz veröffentlicht. Sie legen Anforderungen an „Governance, Sicherheit, Privatsphäre, Fairness, Transparenz, Resilienz und Auditierbarkeit von KI-Systemen" fest. Geprüft werden sollen die dokumentierten Identitäten eines KI-Agenten, seine autorisierten Ziele, die zugelassene Werkzeugnutzung, Berechtigungsgrenzen und die Einhaltung des Least-Privilege-Prinzips. KI-Agenten müssen für folgenschwere Aktionen eine menschliche Freigabe einholen; Hochrisikosysteme brauchen Not-Unterbrechung, Widerruf von Zugangsdaten und Mechanismen gegen automatische Neustarts. „Wirksame Absicherung erfordert organisatorische Rechenschaft, technische Tests, Daten- und Modell-Governance, fortlaufende Überwachung, menschliche Aufsicht, Incident Response und Absicherung durch Dritte", so die Behörde; die Anforderungen seien proportional zu Art, Umfang, Autonomie und möglicher Wirkung jedes KI-Systems.

Hintertür in ARTEX-Kopien

Weil ARTEX nachweislich in realen Einbrüchen eingesetzt wurde, nahm der Entwickler das Repository von GitHub. Mehrere Kopien füllten die Lücke:

  • github[.]com/trhhubsd/ARTEXX
  • github[.]com/mhtsec/ARTEX (auf Docker Hub als „mianhuatang11/artex")
  • github[.]com/RuoJi6/ARTEX

Die ersten beiden Repositorien stehen nicht mehr zum Download bereit. Nach Angaben des unabhängigen Sicherheitsforschers mit dem Alias Badbyte wurde „trhhubsd/ARTEX" 2.449-mal mit einem Stern versehen und über 600-mal geforkt. Bemerkenswert ist, dass in dieser Kopie eine einzige Zeile in der „docker-compose.yml" geändert wurde, sodass das Image „tomicdd/artex" von Docker Hub gezogen wird. Nach Docker-Hub-Statistiken wurde dieses Image 9.000-mal heruntergeladen.

„Es fügt dem Login-Handler eine versteckte Funktion verifyCaptcha() hinzu: Beginnt das CAPTCHA-Feld mit einem geheimen Marker, wird der Rest über sh -c als root ausgeführt und die Ausgabe zurückgegeben — noch vor jeder Prüfung der Zugangsdaten", so der Forscher. „Das ist eine unauthentifizierte Root-Shell auf jeder Installation, und sie fällt in einem Code-Review nie auf."

„Eine kompromittierte ARTEX-Instanz enthält die ungepatchten Funde ihrer Ziele, aktive Zugangsdaten, mitgeschnittene Sitzungen und Netzwerkposition. Wer die Hintertür kontrolliert, kann außerdem unbemerkt ändern, was die Agenten beim nächsten Durchlauf tun."

Zwischen dem 2. und 4. November 2026 wurden 62 im Internet erreichbare ARTEX-Konsolen gefunden, die den hintertürigen Build ausliefern; die erste Instanz war bis zum 20. Oktober 2026 online — zwölf Tage nach dem Hochladen des Docker-Images. 26 dieser Konsolen stehen in den USA, 17 in Hongkong und sieben in China. Insgesamt lieferten mit Stand 4. November 2026 1.645 Hosts die ARTEX-Konsole aus. Neben „tomicdd/artex" wurden weitere Docker-Hub-Namensräume mit Images namens „artex" identifiziert, darunter „congdonglinux/artex" (ebenfalls mit Hintertür und identisch zu „tomicdd/artex"), „mianhuatang11/artex", „autumn26/artex", „andy1099zz/artex", „dgddw/artex", „trhhubsd/ARTEX" und „ylh440104/artex".

„Mehr brauchte der Autor der Hintertür nicht. Die Leute, auf die er es abgesehen hatte, hatten sich bereits entschieden, ein ungeprüftes Angriffswerkzeug als root auf einem offenen Port zu betreiben", sagte Badbyte. „Wir wissen, dass ARTEX in freier Wildbahn bösartig eingesetzt wurde, und das wird so bleiben. Wir wissen auch, dass viele legitime, neugierige Menschen es installiert haben, um zu sehen, worum der Wirbel geht. Für eine Root-Shell auf dem eigenen Server haben die sich nicht gemeldet."