Sicherung Ihrer KI-Infrastruktur, bevor NadMesh Ihre Cloud-Konten leert

Eine millionenschwere Verteidigungsstrategie für Unternehmen bricht oft unter dem Gewicht eines einzigen nicht authentifizierten Containers zusammen. Ich habe dies im letzten Quartal aus erster Hand erlebt, als ich ein Forschungslabor prüfte, das sechs Monate lang seine Kubernetes-Cluster gehärtet hatte, aber eine ComfyUI-Instanz für eine Wochenend-Demo offen ließ. Dieser eine exponierte Port auf 8188 reichte aus, um jede installierte Netzwerkrichtlinie zu umgehen. Das NadMesh-Botnetz, das Anfang Juli 2026 entdeckt wurde, existiert genau in dieser Lücke zwischen Unternehmenssicherheitsstandards und dem hektischen Tempo der KI-Bereitstellung.

NadMesh ist eine Go-basierte Malware-Familie, die Identität über reine Rechenleistung stellt. Während sich frühere Botnetze auf das Kapern von GPUs für das Monero-Mining konzentrierten, verstehen die Betreiber hinter NadMesh, dass ein gestohlenes AWS-Geheimnis wertvoller ist als ein paar tausend Hashes pro Sekunde. Das XLab von QiAnXin veröffentlichte am Freitag einen Bericht, der detailliert beschreibt, wie dieses Botnetz Jagd auf Bildgeneratoren, lokale Modell-Runner und Workflow-Builder macht, die Engineering-Teams schnell aufbauen und erst spät per Firewall absichern.

Die architektonischen Kosten des KI-Goldrauschs

In der modernen KI-Bereitstellung gibt es ein grundlegendes Paradoxon. Organisationen investieren massiv in Cloud-IAM-Rollen und verschlüsselten Speicher, erlauben es Entwicklern jedoch, nicht authentifizierte Tools wie Ollama oder n8n direkt im öffentlichen Internet auszuführen. NadMesh nutzt diesen Mangel an Reibung aus. Das Botnetz verwendet einen Shodan-Harvester, um seine Scan-Warteschlange mit Zielen zu füllen, auf denen ComfyUI, Open WebUI, Langflow und Gradio laufen. Dies sind die Werkzeuge des modernen KI-Stacks, und sie werden ab Werk selten gehärtet.

Ich habe kürzlich eine Aufzeichnung analysiert, bei der ein Entwickler ein Marimo-Notebook bereitgestellt hat, um ein neues Modell zu testen. Die Sicherheitswarnungen wurden ignoriert, da es nur für eine Stunde benötigt wurde. Innerhalb von zwanzig Minuten hatte ein NadMesh-Bot die IP gescannt, den Dienst identifiziert und einen Exploit versucht. Diese Geschwindigkeit ist möglich, weil das Botnetz das Internet wie eine durchsuchbare Datenbank behandelt und nicht wie ein riesiges Gebiet, das es zu durchwandern gilt. Subnetze, die erfolgreiche Treffer erzielen, werden alle fünf Minuten neu abgefragt. Wenn ein Ziel als gefährlich markiert wird, kehrt das Botnetz alle fünfzehn Minuten zurück, um vorrangig einen Scan KI-spezifischer Ports durchzuführen.

Wie der Harvester die Warteschlange füttert

Die Scan-Logik ist hartnäckig. Ein vollständiger Durchlauf zieht jede IP, die in den letzten sieben Tagen als gefährlich markiert wurde, wieder an die Spitze der Warteschlange. Der Autor weiß offensichtlich, dass Forscher und Honeypots zusehen. Wenn ein Ziel zehn Bereitstellungsversuche absorbiert, ohne ein Ergebnis zu liefern, setzt das Botnetz es automatisch auf eine Blacklist. Dies verhindert, dass die Flotte Ressourcen für Köder verschwendet. Wenn die Warteschlange leer ist, generieren die Bots ein zufälliges /24-Subnetz und setzen die Jagd fort.

Bis zur zweiten Juliwoche stieg die Zahl der eindeutigen Quell-IPs, die NadMesh verbreiteten, vertikal an. XLab verzeichnete einen Anstieg von fast Null auf etwa 139 pro Tag. Das eigene Dashboard des Betreibers, das am 10. Juli erfasst wurde, behauptet eine Beute von 3.811 eindeutigen AWS-Schlüsseln. Diese Diskrepanz zwischen der geringen Anzahl aktiver Bots und der massiven Menge an gestohlenen Anmeldedaten deutet auf eine hocheffiziente Automatisierungs-Engine hin. Der Betreiber benötigt kein massives Botnetz, wenn jede Infektion einen Masterschlüssel für eine Cloud-Umgebung liefert.

Die Schwachstelle im Model Context Protocol

Das Model Context Protocol (MCP) ist der primäre Vektor auf der Prioritätenliste des Controllers. MCP ist ein Standard, der es KI-Modellen ermöglicht, externe Tools aufzurufen und auf Datenquellen zuzugreifen. Konstruktionsbedingt sah die erste Spezifikation von MCP die Authentifizierung außerhalb des Kernprotokolls vor. Ein Autorisierungs-Flow existiert seit März 2025, aber die Spezifikation beschreibt ihn als optional. Viele Entwickler überspringen ihn, um bei der Konfiguration Zeit zu sparen.

Censys zählte bis Mai 2026 über 21.000 erreichbare MCP-Dienste. Etwa 90 davon bewarben ein Tool namens execute_command. Dieses Tool ist genau der Aufruf an der Spitze der NadMesh-Exploit-Tabelle. Das Botnetz verwendet einen JSON-RPC-Aufruf tools/call, um diesen Befehl auszulösen. Mit dieser Aktivität ist keine CVE verknüpft, da die Software genau wie konfiguriert arbeitet. Das Problem ist kein Fehler im Code. Das Problem ist ein Protokoll, das standardmäßig die nicht authentifizierte Befehlsausführung erlaubt.

Inventarisierung des Modells und der Identität

Wenn ein Bot erfolgreich einen Host kompromittiert, installiert er nicht nur einen Miner. Er katalogisiert die Umgebung. Der Intel-Feed hinter dem NadMesh-Dashboard zeigt Inventare von DeepSeek-, GLM- und Kimi-Modellen. Diese Inventare sind oft mit einer „:cloud“-Kennung versehen. Dies deutet darauf hin, dass der Bot über den lokalen Rechner hinausblickt und identifiziert, auf welche Remote-KI-Dienste der Host zugreifen kann.

Was ein Bot nach Hause schickt, ist die Identität der Organisation. Er zieht Cloud-Schlüssel aus Umgebungsvariablen, extrahiert Kubernetes-Dienstkonto-Token und liest die Inhalte von ~/.aws/config aus. Er zielt auch auf .env-Dateien und ~/.docker/config.json ab. Die Forscher äußern sich klar über das Motiv. Der Betreiber hat es auf die Cloud-Anmeldedaten und Cluster-Privilegien abgesehen und nicht auf den Host selbst. In einer modernen Architektur ist der Host ein austauschbares Gut, aber die Anmeldedaten bieten dauerhaften Zugriff auf die Datenebene.

Persistenz durch dreifache Redundanz

Das Entfernen von NadMesh von einem kompromittierten System ist aufgrund seiner redundanten Persistenzmechanismen schwierig. Der Agent unterhält drei separate Wege, um einen Neustart zu überleben. Wenn ein Administrator einen Eintrag findet und löscht, bleiben die anderen beiden bestehen, um eine neue Kopie der Malware herunterzuladen. Das ist so, als würde man versuchen, ein Feuer zu löschen, das drei unabhängige Brennstoffquellen hat. Jede Version der Malware durchläuft zudem eine Garble-Obfuskation und UPX-Packing mit zufälligem Padding. Das bedeutet, dass jeder Agent einen eindeutigen Datei-Hash hat. Ein Sicherheitsteam kann sich nicht auf einen einzelnen Hash verlassen, um Infektionen in seinem Netzwerk zu finden.

Derzeit sind fünf Build-Versionen des Botnetzes im Umlauf. Die häufigste ist 33.8-GO-TITAN. Der Betreiber verwendet einen Canary-Endpunkt, um neue Builds für einen kleinen Teil der Flotte bereitzustellen, bevor eine breite Veröffentlichung erfolgt. Dies ist ein Grad an DevOps-Reife, der die legitimen Softwareunternehmen widerspiegelt, die sie ins Visier nehmen. Der Erfolg für den Betreiber wird anhand einer Ergebnis-Allowlist gemessen, die die Ollama- und AWS-Beute ausschließt. Dies deutet darauf hin, dass die Anzeigetafel auf dem Dashboard nur einen Bruchteil der gesamten Operation zeigt.

Verteidigungsmaßnahmen für den exponierten Perimeter

Das meiste, was NadMesh abfeuert, zielt auf Admin-Funktionen ab, die im öffentlichen Internet aufrufbar geblieben sind. Dazu gehören offene Docker-APIs auf Port 2375, Jenkins-Skriptkonsolen und nicht authentifizierte Redis-Instanzen. Kein Patch schließt diese Lücken, da es sich um Konfigurationsentscheidungen handelt. Um Ihre Umgebung zu sichern, müssen Sie diese Dienste hinter eine Authentifizierung verschieben oder ganz aus dem öffentlichen Internet entfernen. Priorisieren Sie die vier Ports, die der NadMesh-Rescan-Job an die erste Stelle setzt: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio) und 5678 (n8n).

Es gibt auch eine kurze Liste von Schwachstellen, die sofortiges Patchen erfordern. CVE-2026-39987 ist eine Schwachstelle für die Remote-Codeausführung vor der Authentifizierung in Marimo-Notebooks. Die CISA hat sie im April in den Katalog der bekanntlich ausgenutzten Schwachstellen aufgenommen. CVE-2026-41176 ist ebenfalls kritisch, da sie es nicht authentifizierten Anrufern ermöglicht, den Authentifizierungsschalter auf rclone-RC-Servern umzulegen. Da rclone-Konfigurationen oft Cloud-Anmeldedaten enthalten, ist dies ein hochprioritäres Ziel für NadMesh.

Wenn Sie Anzeichen für eine Kompromittierung finden, isolieren Sie den Host sofort. Suchen Sie nach Persistenzdateien in /etc/cron.d/.sys_monitor und versteckten Dateien in /dev/shm/.a oder /tmp/.a. Der Widerruf von Anmeldedaten ist der einzige sichere Weg nach vorne. Wenn ein Host kompromittiert ist, gehen Sie davon aus, dass jeder AWS-Schlüssel, jedes Cluster-Token und jede .env-Datei, die er berührt hat, nun in den Händen des Betreibers liegt. Das Rotieren von Schlüsseln reicht nicht aus, wenn die Malware noch vorhanden ist, um die neuen zu stehlen. Sie müssen die Persistenz entfernen, bevor Sie Ersatz ausstellen. Überprüfen Sie Ihre Protokolle auf Aktivitäten der IP 209.99.186[.]235 oder Verbindungen zur Domain cdnorigin[.]net. Das Ziel ist es, zu verifizieren, wo die gestohlenen Identitäten verwendet wurden, während sie aktiv waren.

Sources: NIST Cybersecurity Framework, MITRE ATT&CK (Resource Development, Initial Access), QiAnXin XLab NadMesh Report, Censys MCP Census 2026.

Disclaimer: Dieser Artikel dient nur zu Informations- und Bildungszwecken und ersetzt keine professionelle Cybersicherheitsprüfung oder einen Incident-Response-Service.