Manipuliertes Docker-Image: KI-Hacking-Tool ARTEX enthält gefährliche Hintertür

Eigentlich sollen Sicherheitstools dabei helfen, Schwachstellen aufzuspüren und Systeme besser abzusichern. Doch was passiert, wenn ausgerechnet eine solche Anwendung selbst manipuliert wurde?

Genau das ist beim KI-gestützten Hacking-Tool ARTEX passiert.

Sicherheitsforscher haben ein manipuliertes Docker-Image entdeckt, das eine versteckte Hintertür enthält. Darüber können Angreifer ohne gültige Zugangsdaten Befehle mit Root-Rechten innerhalb des betroffenen Containers ausführen.

Besonders unangenehm: Die Schadfunktion war nicht im öffentlich einsehbaren GitHub-Quellcode versteckt, sondern in einem bereits fertig kompilierten Docker-Image.

Nach Angaben des Sicherheitsforschers Badbyte wurde das betroffene Image beziehungsweise eine identische Kopie bis Anfang November 2026 fast 8.000 Mal heruntergeladen. Inzwischen zeigt Docker Hub für eines der Images bereits rund 9.000 Downloads an.

Damit stellt sich eine ziemlich unangenehme Frage: Wie sicher sind eigentlich die Werkzeuge, mit denen wir unsere Systeme auf Sicherheitslücken untersuchen?

Was ist ARTEX überhaupt?

ARTEX ist ein KI-gestütztes Werkzeug für automatisierte Sicherheitstests.

Die Software kombiniert verschiedene Funktionen zur Netzwerkanalyse und Schwachstellensuche mit großen Sprachmodellen, sogenannten Large Language Models.

Damit lassen sich bestimmte Aufgaben automatisieren, die normalerweise von Sicherheitsexperten manuell durchgeführt werden.

ARTEX kann beispielsweise Systeme untersuchen, erkannte Schwachstellen bewerten und verschiedene Angriffstechniken innerhalb eines automatisierten Arbeitsablaufs ausprobieren.

Genau solche Anwendungen werden im Bereich der offensiven IT-Sicherheit immer interessanter.

Denn künstliche Intelligenz kann dabei helfen, komplexe Aufgaben schneller zu bearbeiten und auf unerwartete Ergebnisse zu reagieren.

Allerdings besitzen solche Werkzeuge auch eine problematische Seite.

Was einem autorisierten Sicherheitsexperten bei einem Penetrationstest hilft, kann ebenso von Cyberkriminellen missbraucht werden.

Und genau das ist ARTEX bereits passiert.

Entwickler entfernt ARTEX nach Missbrauch von GitHub

Anfang Oktober 2026 wurde bekannt, dass ARTEX bei realen Cyberangriffen eingesetzt worden war.

Unter anderem dokumentierten Sicherheitsforscher Angriffe auf südkoreanische Finanzinstitute, bei denen KI-gestützte Werkzeuge zur Automatisierung verschiedener Angriffsschritte verwendet wurden.

Der ursprüngliche ARTEX-Entwickler reagierte darauf.

Am 8. Oktober kündigte er an, den öffentlichen Quellcode nicht länger bereitzustellen und das Projekt künftig geschlossen weiterzuführen.

Das ursprüngliche GitHub-Repository verschwand daraufhin.

Allerdings führte das nicht dazu, dass ARTEX plötzlich aus dem Internet verschwand.

Stattdessen entstanden mehrere Kopien des Projekts.

Einige Entwickler wollten das Werkzeug offenbar weiterführen, andere stellten ältere Versionen bereit.

Und mindestens eine dieser Kopien wurde gezielt manipuliert.

Eine einzige Änderung in der Docker-Konfiguration reichte aus

Der eigentliche Angriff war technisch ziemlich geschickt umgesetzt.

Ein GitHub-Repository unter dem Namen trhhubsd/ARTEX, ursprünglich als ARTEXX veröffentlicht, präsentierte sich als Fortsetzung des eingestellten Projekts.

Der öffentlich verfügbare Quellcode entsprach weitgehend dem ursprünglichen ARTEX-Projekt.

Deshalb hätte eine oberflächliche Prüfung zunächst kaum etwas Verdächtiges ergeben.

Die entscheidende Veränderung steckte in einer einzigen Zeile der Datei docker-compose.yml.

Dort wurde festgelegt, welches Docker-Image bei der Installation heruntergeladen werden sollte.

Statt des ursprünglichen Images verwies die Konfiguration nun auf:

tomicdd/artex

Damit bekamen Nutzer beim Starten der Anwendung nicht unbedingt die Software, deren Quellcode sie gerade auf GitHub angesehen hatten.

Sie luden stattdessen ein bereits fertig gebautes Image von Docker Hub herunter.

Und genau darin befand sich die Hintertür.

Das Problem war also nicht nur manipulierter Code, sondern vor allem die fehlende Übereinstimmung zwischen dem sichtbaren Quellcode und der tatsächlich ausgeführten Anwendung.

Eine versteckte Funktion öffnet den Root-Zugang

Der Sicherheitsforscher Badbyte untersuchte das verdächtige Docker-Image genauer.

Dabei entdeckte er zusätzliche Funktionen, die in der ursprünglichen ARTEX-Version nicht vorhanden waren.

Besonders auffällig war eine Routine namens verifyCaptcha().

Dem Namen nach könnte man vermuten, dass diese Funktion eine gewöhnliche CAPTCHA-Prüfung durchführt.

Tatsächlich hatte sie aber eine völlig andere Aufgabe.

Die Funktion wurde in den Anmeldeprozess der ARTEX-Weboberfläche integriert und reagierte auf speziell präparierte Eingaben.

Wurde eine solche Eingabe erkannt, konnte die Anwendung einen übermittelten Shell-Befehl ausführen und dessen Ausgabe zurückgeben.

Das Entscheidende dabei: Die normale Überprüfung von Benutzername und Passwort wurde umgangen.

Der Angreifer benötigte also kein gültiges Benutzerkonto.

Eine entsprechend vorbereitete Anfrage an die Anmeldung konnte bereits ausreichen.

Da der betroffene ARTEX-Container mit Root-Rechten lief, wurden auch die darüber gestarteten Befehle mit diesen Berechtigungen ausgeführt.

Das ist eine erhebliche Sicherheitslücke.

Allerdings muss man hier technisch sauber unterscheiden.

Root-Zugriff innerhalb eines Docker-Containers bedeutet nicht automatisch vollständigen Root-Zugriff auf das darunterliegende Hostbetriebssystem.

Ob ein Angreifer anschließend auch den eigentlichen Server übernehmen kann, hängt unter anderem von der Container-Konfiguration, vorhandenen Berechtigungen, eingebundenen Verzeichnissen und weiteren Sicherheitsmaßnahmen ab.

Innerhalb des betroffenen Containers besitzt der Angreifer aber bereits sehr weitreichende Möglichkeiten.

Warum die Hintertür besonders gefährlich ist

ARTEX ist keine gewöhnliche Anwendung, die lediglich ein paar lokale Einstellungen speichert.

Die Software wird für Sicherheitstests verwendet und kann dabei mit zahlreichen sensiblen Informationen in Kontakt kommen.

Dazu gehören beispielsweise Zugangsdaten, API-Schlüssel, Informationen über untersuchte Systeme und Ergebnisse früherer Schwachstellenanalysen.

Wer die ARTEX-Instanz kontrolliert, könnte deshalb auf Daten zugreifen, die eigentlich besonders gut geschützt sein sollten.

Nach den Untersuchungen von Badbyte können unter anderem folgende Informationen betroffen sein:

• Zugangsschlüssel für KI-Dienste und andere APIs

• Datenbank-Zugangsdaten

• Gespeicherte Zugangsinformationen untersuchter Systeme

• Ergebnisse früherer Sicherheitstests

• Aufgezeichnete Netzwerkverbindungen

• Konfigurationen und Anweisungen der KI-Agenten

Besonders problematisch finde ich den letzten Punkt.

Wenn ein Angreifer die Konfiguration eines KI-Agenten verändern kann, lassen sich möglicherweise auch zukünftige Arbeitsabläufe manipulieren.

Die Anwendung könnte dann weiterhin normal aussehen, im Hintergrund aber veränderte Aufgaben ausführen.

Damit wäre nicht nur die Sicherheit der ARTEX-Installation selbst betroffen.

Auch andere Systeme, die mit dieser Installation untersucht werden, könnten zusätzlichen Risiken ausgesetzt sein.

Fast 8.000 Downloads vor der Veröffentlichung der Hintertür

Die Untersuchung von Badbyte liefert auch interessante Zahlen zur Verbreitung.

Bis zum 3. November 2026 wurden insgesamt 7.946 Downloads der beiden identifizierten manipulierten Images gezählt.

Das ursprüngliche schädliche Image tomicdd/artex kam dabei auf 7.913 Downloads.

Eine weitere Version unter dem Namen congdonglinux/artex wurde 33-mal heruntergeladen und enthielt dieselbe manipulierte Software.

Am 5. November zeigte Docker Hub für das ursprüngliche Image bereits rund 9.000 Downloads an.

Allerdings sollte man diese Zahlen nicht falsch verstehen.

9.000 Downloads bedeuten nicht automatisch 9.000 infizierte Server.

Ein Docker-Image kann mehrfach heruntergeladen werden. Außerdem werden nicht sämtliche Downloads zwangsläufig produktiv eingesetzt.

Die Zahl zeigt deshalb vor allem, wie stark sich das manipulierte Softwarepaket verbreitet hat.

Wie viele unterschiedliche Betreiber das Image tatsächlich installiert haben, lässt sich daraus nicht zuverlässig ableiten.

Mindestens 62 öffentlich erreichbare Installationen entdeckt

Noch interessanter sind die Ergebnisse einer Untersuchung öffentlich erreichbarer ARTEX-Systeme.

Zwischen dem 2. und 4. November 2026 identifizierte Badbyte insgesamt 62 ARTEX-Konsolen, die nachweislich die manipulierte Version bereitstellten.

Diese verteilten sich auf verschiedene Länder.

Bei einer späteren Überprüfung am 4. November waren noch 46 dieser Installationen mit der manipulierten Version erreichbar.

Einige Betreiber hatten ihre Installationen inzwischen verändert, während andere Systeme nicht mehr antworteten.

Insgesamt identifizierte der Forscher 1.645 öffentlich erreichbare ARTEX-Konsolen.

Wichtig ist allerdings auch hier eine Unterscheidung.

Nicht alle dieser Installationen enthielten die Hintertür.

Die 62 bestätigten Fälle waren lediglich ein Teil der insgesamt gefundenen Systeme. Bei weiteren Installationen ließ sich der genaue Softwarestand nicht eindeutig bestimmen.

Wie viele zusätzliche kompromittierte ARTEX-Instanzen hinter Firewalls oder in internen Netzwerken betrieben werden, ist unbekannt.

Warum GitHub-Sterne kein Sicherheitsnachweis sind

Ein interessantes Detail betrifft die Popularität der manipulierten GitHub-Kopie.

Das betreffende Repository sammelte zeitweise Tausende Sterne und wurde mehrere Hundert Mal geforkt.

Solche Zahlen wirken auf den ersten Blick vertrauenswürdig.

Schließlich könnte man annehmen, dass ein Projekt mit vielen Sternen auch von zahlreichen Entwicklern geprüft wurde.

Das ist allerdings ein Trugschluss.

GitHub-Sterne sagen zunächst nur etwas über die vermeintliche Popularität eines Projekts aus.

Sie sind keine Garantie für sicheren Code.

Im aktuellen Fall stieg die Zahl der Sterne innerhalb kurzer Zeit ungewöhnlich stark an.

Der Sicherheitsforscher vermutet deshalb, dass zumindest ein Teil davon künstlich erzeugt wurde.

Das würde auch erklären, warum die manipulierte Kopie zeitweise besonders glaubwürdig wirkte.

Ich finde diesen Punkt fast genauso interessant wie die eigentliche Hintertür.

Denn viele Nutzer beurteilen Open-Source-Projekte zumindest teilweise danach, wie aktiv und beliebt sie erscheinen.

Genau dieses Vertrauen lässt sich offenbar ausnutzen.

Auch automatische Updates konnten das Problem verschärfen

Eine weitere Besonderheit betrifft die Aktualisierung der manipulierten Installation.

Normalerweise sollte ein Softwareupdate dafür sorgen, dass bekannte Probleme behoben und Sicherheitslücken geschlossen werden.

Bei der betroffenen ARTEX-Kopie funktionierte das allerdings nicht zuverlässig.

Die manipulierte Anwendung meldete keinen regulären Versionsstand, wodurch der integrierte Update-Mechanismus nicht wie vorgesehen arbeitete.

Ein anderes Update-Skript verwendete wiederum dieselbe Docker-Konfiguration, die bereits auf das schädliche Image verwies.

Damit bestand die Gefahr, dass ein Betreiber beim Aktualisieren erneut die manipulierte Software herunterlud.

Auch ein bloßer Austausch des Images hätte möglicherweise nicht sämtliche Folgen einer bereits erfolgten Kompromittierung beseitigt.

Schließlich können veränderte Konfigurationen, gespeicherte Zugangsdaten oder manipulierte Agenten-Einstellungen außerhalb des eigentlichen Containers erhalten bleiben.

Wer eine betroffene Installation entdeckt, sollte deshalb nicht einfach nur das Image austauschen und davon ausgehen, dass damit alles erledigt ist.

Gleichzeitig warnt Indien vor KI-gestützten Cyberangriffen

Der ARTEX-Fund fällt in eine Zeit, in der auch staatliche Sicherheitsbehörden zunehmend vor dem Missbrauch solcher KI-Werkzeuge warnen.

Das indische Computer Emergency Response Team CERT-In veröffentlichte am 4. November 2026 eine neue Sicherheitswarnung.

Darin beschreibt die Behörde eine laufende Angriffskampagne gegen Unternehmen aus dem Banken-, Finanz- und Versicherungssektor.

Die verantwortlichen Angreifer werden unter dem Namen Crafty Falcon beobachtet.

Nach Angaben von CERT-In setzen sie verschiedene öffentlich verfügbare KI-gestützte Sicherheitswerkzeuge ein.

Dazu gehören neben ARTEX auch PentAGI, Cairn und CyberStrikeAI.

Mit diesen Anwendungen können Angreifer bestimmte Arbeitsschritte automatisieren und in kurzer Zeit zahlreiche unterschiedliche Angriffsmöglichkeiten ausprobieren.

Besonders problematisch ist, dass die Werkzeuge ihre Vorgehensweise anhand der Reaktionen eines Zielsystems anpassen können.

Das macht Angriffe nicht automatisch erfolgreich, kann aber ihre Geschwindigkeit erheblich erhöhen.

Wichtig: Es gibt bislang keinen belastbaren Nachweis, dass Crafty Falcon auch für die manipulierten ARTEX-Docker-Images verantwortlich ist.

Es handelt sich um zwei unterschiedliche Sicherheitsentwicklungen, die allerdings zeigen, welche Rolle KI-gestützte Angriffswerkzeuge inzwischen spielen.

Finanzunternehmen werden gezielt angegriffen

Nach Angaben von CERT-In konzentrieren sich die beobachteten Angriffe unter anderem auf Banken, Finanzdienstleister, Zahlungsanbieter und Kryptowährungsplattformen.

Dabei versuchen die Täter, Zugangsdaten und API-Schlüssel zu stehlen.

Besonders interessant ist die Vorgehensweise bei Zahlungsdienstleistern.

Wenn Angreifer gültige Zugangsinformationen erbeuten, können sie unter bestimmten Umständen Zahlungsfunktionen direkt über die vorgesehenen Programmierschnittstellen aufrufen.

Das bedeutet, dass nicht unbedingt die eigentliche Banking-Weboberfläche kompromittiert werden muss.

Stattdessen werden Funktionen missbraucht, die für legitime Geschäftsprozesse vorgesehen sind.

CERT-In beschreibt außerdem Fälle, in denen Angreifer zunächst Überweisungen mit sehr kleinen Beträgen ausprobierten.

Damit sollte offenbar überprüft werden, ob die verwendeten Zugänge tatsächlich funktionierten.

Anschließend konnten größere Transaktionen folgen.

Auch Kryptowährungsplattformen wurden angegriffen. Dabei sollen Zugangsschlüssel und Gelder entwendet worden sein.

Die Angriffe zeigen, dass automatisierte Werkzeuge inzwischen nicht nur zur Suche nach Schwachstellen verwendet werden.

Sie können auch Teil umfangreicher Angriffsketten sein, die vom ersten Zugriff bis zum eigentlichen Datendiebstahl oder Finanzbetrug reichen.

Was sollten Betreiber einer ARTEX-Installation jetzt tun?

Wer ARTEX selbst verwendet oder in einer Testumgebung installiert hat, sollte zunächst kontrollieren, aus welcher Quelle die verwendete Software stammt.

Besonders kritisch sind die beiden nachweislich manipulierten Docker-Images:

tomicdd/artex

congdonglinux/artex

Auch bei anderen Kopien sollte geprüft werden, welche Images tatsächlich heruntergeladen werden.

Eine ähnlich klingende Projektbezeichnung reicht nicht aus, um die Vertrauenswürdigkeit zu beurteilen.

Ich würde bei einem konkreten Verdacht folgendermaßen vorgehen:

1. Installation isolieren: Eine verdächtige ARTEX-Instanz sollte nicht weiterhin öffentlich erreichbar bleiben.

2. Verwendetes Image überprüfen: Docker-Konfiguration, Image-Digests und die Herkunft des Images kontrollieren.

3. Beweise sichern: Vor dem Löschen sollten relevante Protokolle, Konfigurationsdateien und andere forensische Informationen gesichert werden.

4. Zugangsdaten austauschen: API-Schlüssel, Datenbankpasswörter und weitere möglicherweise erreichbare Zugangsdaten sollten widerrufen beziehungsweise erneuert werden.

5. Gespeicherte Agenten-Konfigurationen prüfen: Manipulierte Anweisungen oder Werkzeuge könnten auch nach einem Imagewechsel bestehen bleiben.

6. System sauber neu aufsetzen: Eine nachweislich kompromittierte Installation sollte aus einer geprüften Quelle neu erstellt werden.

7. Weitere Systeme untersuchen: Wenn die betroffene ARTEX-Instanz Zugang zu anderen Netzwerken oder Servern hatte, müssen diese ebenfalls in die Bewertung einbezogen werden.

Gerade bei einer Sicherheitsanwendung mit umfangreichen Berechtigungen kann der mögliche Schaden weit über den ursprünglichen Container hinausgehen.

Deshalb würde ich eine bestätigte Infektion nicht als gewöhnlichen Softwarefehler behandeln, sondern als ernsthaften Sicherheitsvorfall.

Docker allein schützt nicht vor manipulierten Anwendungen

Der aktuelle Fall zeigt auch eine wichtige Grenze der Container-Technologie.

Docker kann Anwendungen voneinander isolieren und ihre Bereitstellung vereinfachen.

Allerdings bedeutet das nicht, dass jede Anwendung innerhalb eines Containers automatisch sicher ist.

Wenn ein Container mit hohen Berechtigungen ausgeführt wird, Netzwerkdienste offenlegt oder auf sensible Verzeichnisse zugreifen kann, entstehen zusätzliche Risiken.

Besonders problematisch wird es, wenn der eigentliche Container bereits manipulierte Software enthält.

Dann startet man die Schadfunktion praktisch selbst.

Genau deshalb sollten Docker-Images nicht allein anhand ihres Namens oder ihrer Downloadzahlen ausgewählt werden.

Wichtig sind nachvollziehbare Quellen, überprüfbare Image-Digests und möglichst reproduzierbare beziehungsweise signierte Builds.

Gerade bei Anwendungen mit Zugriff auf sensible Systeme sollte außerdem das Prinzip der minimal notwendigen Berechtigungen gelten.

Eine Sicherheitssoftware benötigt nicht automatisch vollständige Root-Rechte oder einen öffentlich erreichbaren Verwaltungszugang.

Warum ich den Fall besonders interessant finde

Was mich an diesem Angriff besonders beschäftigt, ist die Einfachheit des eigentlichen Tricks.

Die Täter mussten offenbar nicht das gesamte ARTEX-Projekt umschreiben.

Es reichte, eine glaubwürdige GitHub-Kopie bereitzustellen und den Download auf ein manipuliertes Docker-Image umzuleiten.

Der sichtbare Quellcode wirkte weitgehend unauffällig.

Die eigentliche Schadfunktion steckte dagegen in der bereits kompilierten Anwendung.

Damit wurde genau das Vertrauen ausgenutzt, das viele Anwender in öffentlich verfügbare Open-Source-Projekte setzen.

Dabei ist Open Source natürlich nicht das Problem.

Im Gegenteil: Öffentlich einsehbarer Quellcode erleichtert grundsätzlich die unabhängige Überprüfung.

Allerdings bringt diese Transparenz wenig, wenn später eine andere Binärdatei ausgeführt wird als diejenige, die sich aus dem geprüften Quellcode ergeben würde.

Für mich zeigt der Vorfall deshalb vor allem eines: Zur Software-Sicherheit gehört nicht nur die Überprüfung des Codes, sondern auch die Kontrolle des gesamten Weges von der Entwicklung bis zur tatsächlich gestarteten Anwendung.

Fazit: Wenn das Sicherheitstool selbst zur Schwachstelle wird

Die manipulierten ARTEX-Docker-Images sind ein gutes Beispiel für einen gefährlichen Angriff auf die Software-Lieferkette.

Die Täter nutzten eine Kopie eines bekannten KI-Sicherheitswerkzeugs, um eine versteckte Hintertür in einem fertigen Docker-Image zu verbreiten.

Dadurch konnten Unbefugte unter bestimmten Voraussetzungen Befehle mit Root-Rechten innerhalb des Containers ausführen, ohne gültige Zugangsdaten zu besitzen.

Besonders problematisch ist, dass ARTEX selbst mit sensiblen Informationen wie API-Schlüsseln, Zugangsdaten und Ergebnissen von Sicherheitstests arbeiten kann.

Eine kompromittierte Installation könnte deshalb auch andere Systeme gefährden.

Die gleichzeitig veröffentlichten Warnungen von CERT-In zeigen außerdem, dass KI-gestützte Angriffswerkzeuge zunehmend bei realen Cyberangriffen eingesetzt werden.

Mein Fazit: Wer Sicherheitswerkzeuge aus dem Internet herunterlädt, sollte besonders sorgfältig prüfen, woher die Software stammt und was tatsächlich ausgeführt wird.

Ein öffentliches GitHub-Repository, viele Sterne und ein Docker-Image mit Tausenden Downloads sind noch lange kein Sicherheitsnachweis.

Und gerade bei Werkzeugen, die tief in andere Systeme eingreifen können, sollte man sich nicht blind auf eine vermeintlich vertrauenswürdige Installationsanleitung verlassen.

Denn im schlimmsten Fall findet das Sicherheitstool nicht nur fremde Schwachstellen.

Es bringt die eigene gleich mit.

Quellen

The Hacker News – Backdoored Docker Image for ARTEX AI Hacking Tool Exposes Servers to Root Access (5. November 2026)

https://thehackernews.com/2026/11/backdoored-docker-image-for-artex-ai.html

Badbyte – ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells (4. November 2026)

Technische Originalanalyse der manipulierten Docker-Images, der versteckten Funktionen und der öffentlich erreichbaren Installationen.

https://badbyte.io/artex-backdoor-docker-image/

CERT-In – Sicherheitswarnung CIAD-2026-0058: Escalation of AI-Driven Attacks on BFSI Entities (4. November 2026)

Offizielle Warnung der indischen Cybersicherheitsbehörde vor Crafty Falcon und dem Missbrauch KI-gestützter Angriffswerkzeuge.

https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIAD-2026-0058&pageid=PUBVLNOTES02