Offizielle GitHub-Tools für Cryptojacking-Kampagne missbraucht : Automatisierte Cryptojacking-Kampagnen nutzen DevOps-Fehlkonfigurationen und KI-Schnittstellen
Sicherheitsanalysten haben eine hochgradig automatisierte Angriffskampagne auf fehlkonfigurierte DevOps-Plattformen wie Docker, Gitea und Nomad aufgedeckt. Die Akteure nutzen öffentlich verfügbare Tools, um heimlich Kryptowährungen zu schürfen. Das Schadpotenzial ist immens.
Ein neues Kapitel in der Geschichte digitaler Angriffe auf Cloud-Infrastrukturen ist aufgeschlagen: Experten von Wiz haben eine ausgeklügelte Cryptojacking-Kampagne aufgedeckt, die unter dem Namen JINX-0132 geführt wird. Die Angreifer zielen auf fehlkonfigurierte DevOps-Plattformen wie Docker, Gitea, HashiCorp Consul und erstmals auch Nomad – und missbrauchen diese, um auf fremder Hardware heimlich Kryptowährungen zu schürfen.
Was die Kampagne besonders gefährlich macht: Die Täter nutzen öffentliche GitHub-Repositories als Werkzeugkasten. Sie laden die notwendigen Programme direkt herunter, anstatt sie über eigene Infrastrukturen zu verbreiten – und erschweren damit gezielt die Rückverfolgung.
DevOps-Plattformen als offene Angriffsfläche
Die JINX-0132-Kampagne demonstriert auf alarmierende Weise, wie schnell öffentlich zugängliche Systeme zu Einfallstoren für Cyberkriminelle werden können. Im Visier stehen insbesondere:
- Docker: Durch ungesicherte API-Endpunkte lassen sich Container mit manipulierten Images starten, die Mining-Software enthalten.
- Gitea: Schwachstellen wie CVE-2020-14144 oder unsichere Konfigurationen erlauben Angreifern die Remote Code Execution, etwa durch missbrauchte Git-Hooks.
- HashiCorp Consul: Angreifer registrieren scheinbar legitime Dienste, in deren Health Checks schädliche Bash-Kommandos eingeschleust werden.
- HashiCorp Nomad: Erstmals dokumentieren Forscher eine reale Ausnutzung von Nomad-Konfigurationsfehlern – und warnen vor einer RCE-Situation durch Standardkonfiguration.
Besonders kritisch: In vielen Fällen sind keine Sicherheitsmechanismen standardmäßig aktiviert, was es Angreifern erleichtert, beliebige Jobs mit schädlichem Code auf den Zielsystemen auszuführen.
XMRig-Miner über GitHub eingeschleust
Im Zentrum der Angriffe steht der bekannte XMRig-Kryptominer, der auf befallenen Servern installiert und ausgeführt wird. Dabei gehen die Täter hochgradig strukturiert vor: Sie erstellen auf kompromittierten Systemen mehrere neue Jobs mit zufällig wirkenden Namen, deren einziger Zweck das Herunterladen und Starten der Mining-Software ist.
Alle benötigten Dateien holen sich die Angreifer direkt von GitHub – ein Vorgehen, das zwei Ziele erfüllt: die Vermeidung eigener Infrastrukturkosten und die Verschleierung der Urheber. Denn Open-Source-Tools lassen sich schwerer mit bestimmten Gruppen in Verbindung bringen.
Rechenzentrumsleistung für Lau
Die von JINX-0132 kompromittierten Systeme verfügen oft über erhebliche Rechenleistung – mit Hunderten Clients und entsprechender CPU- sowie RAM-Kapazität. Allein die Betriebskosten solcher Infrastrukturen würden monatlich zehntausende Euro betragen. Für die Angreifer bedeutet das: kostenlos nutzbare Rechenzentren, mit deren Hilfe sie digitale Währungen schürfen, ohne eigene Hardware betreiben zu müssen.
Erwähnenswert ist, dass der Missbrauch der Docker-API ein bekanntes Einfallstor für derartige Angriffe ist. Erst in der vergangenen Woche berichtete Kaspersky, dass Bedrohungsakteure gezielt fehlkonfigurierte Docker-API-Instanzen angreifen, um sie in ein Botnetz zum Schürfen von Kryptowährungen einzubinden.
Globales Ausmaß – Deutschland unter den betroffenen Ländern
Laut Shodan-Analyse sind weltweit über 5.300 Consul-Instanzen und mehr als 400 Nomad-Server öffentlich zugänglich – die meisten davon in China, den Vereinigten Staaten, Deutschland, Singapur, Finnland, den Niederlanden und dem Vereinigten Königreich. Die Angreifer setzen gezielt auf bekannte Fehler in der Konfiguration dieser Systeme – und haben in vielen Fällen leichtes Spiel.
JINX-0132 steht exemplarisch für eine neue Generation von Angriffen im Bereich DevOps und Cloud-Infrastruktur: automatisiert, skalierbar und unauffällig. Die Nutzung frei verfügbarer Tools zeigt, wie einfach es geworden ist, hochentwickelte Angriffe durchzuführen – ohne eigenes Toolkit oder Botnetz.
Organisationen, die DevOps-Plattformen wie Docker, Gitea, Consul oder Nomad einsetzen, sollten dringend ihre Konfigurationen überprüfen, Zugänge absichern und alle relevanten Updates einspielen. Denn in einer zunehmend vernetzten Welt genügt eine falsch gesetzte Variable, um zum Ziel einer globalen Angriffswelle zu werden.
Angreifer nutzt öffentlich zugängliches Open-WebUI-System für Kryptominer
Fast zeitgleich zu den Entwicklungen um „JINX-0132“ haben Sicherheitsanalysten von Sysdig eine Malware-Kampagne aufgedeckt, bei der öffentlich erreichbare Open-WebUI-Systeme ausgenutzt wurden, um Kryptominer und Infostealer auf Linux- und Windows-Rechnern einzuschleusen. So wird ein scheinbar harmloses Interface für Künstliche Intelligenz zur Einflugschneise für Cyberangriffe: Der Angriff nutzt eine fehlkonfigurierte KI-Trainingsumgebung, in der sich Python-Skripte hochladen und sofort ausführen lassen.
Open WebUI ist ein System zur Interaktion mit Sprachmodellen (LLMs) über eine grafische Oberfläche. Über sogenannte Tools – das sind Plugins auf Basis von Python – kann die Funktionalität erweitert werden. Doch wenn die Instanz ohne Authentifizierung öffentlich zugänglich ist, können beliebige Skripte hochgeladen und ausgeführt werden.
Genau das haben die Angreifer in diesem Fall getan: „Die Internetfreigabe ermöglichte es jedem, beliebige Befehle auf dem System auszuführen – ein gefährlicher Fehler, auf den Angreifer gezielt scannen“, warnen die Forscher Miguel Hernandez und Alessandra Rizzo in ihrem Bericht.
Schadcode mit KI-Tarnung: Vom Python-Skript zum Kryptominer
Nachdem die Angreifer das System entdeckt hatten, luden sie ein angeblich KI-bezogenes Python-Skript hoch, das in Wahrheit gezielt folgende Aktionen ausführte:
- Download und Start von Kryptominern wie XMRig (für Monero) und T-Rex (für Ethereum)
- Installation eines systemd-Dienstes, um die Malware dauerhaft aktiv zu halten
- Kommunikation über einen Discord-WebHook für Fernsteuerung und Statusberichte
- Verschleierungstechniken, darunter die Bibliotheken processhider und argvhider, um den Mining-Prozess auf Linux-Systemen zu verbergen
Auch Windows-Systeme waren Ziel der Angreifer – dort war das Vorgehen sogar noch ausgefeilter. Die Schadsoftware:
- installierte das Java Development Kit (JDK), um eine JAR-Datei auszuführen, die von einem verdächtigen Server geladen wurde
- nutzte die Datei „application-ref.jar“ als Loader für eine zweite Java-basierte Schadkomponente
- führte zwei Dateien mit den Namen „INT_D.DAT“ und „INT_J.DAT“ aus
- stahl über „INT_J.DAT“Zugangsdaten aus Discord sowie Krypto-Wallet-Informationen aus Chrome-Browser-Plugins.
Laut Sysdig gibt es derzeit über 17.000 über das Internet erreichbare Open-WebUI-Instanzen. Wie viele davon tatsächlich fehlerhaft konfiguriert sind, ist unklar – doch das Risiko ist hoch. Viele Systeme wurden offenbar ohne Schutzmaßnahmen produktiv ins Netz gestellt, etwa für interne Tests, Trainingsumgebungen oder KI-Demos.
„Solche versehentlichen Fehlkonfigurationen bleiben ein schwerwiegendes Problem“, warnen die Forscher. „Der Angreifer zielte bewusst auf Linux- und Windows-Systeme ab – bei Windows sogar mit einem hochentwickelten Infostealer und Verschleierungstechniken.“
KI-Schnittstellen sind neues Einfallstor – Schutz dringend notwendig
Dieser Fall zeigt, wie Künstliche Intelligenz und DevOps-Werkzeuge zur Angriffsfläche werden können, wenn grundlegende Sicherheitsmaßnahmen fehlen. Wer Systeme wie Open WebUI betreibt, muss sicherstellen, dass:
- kein öffentlicher Zugriff ohne Authentifizierung möglich ist,
- Skripte nur aus vertrauenswürdigen Quellen hochgeladen werden dürfen,
- und dass Netzwerkzugänge durch Firewalls, VPNs oder IP-Whitelisting abgesichert sind.
Die Grenzen zwischen KI-Nutzung und Cybercrime verwischen – besonders dann, wenn Angreifer Open-Source-Funktionen für ihre Zwecke umprogrammieren. Wer KI-Infrastruktur betreibt, braucht deshalb nicht nur Rechenleistung, sondern auch Sicherheitsbewusstsein und technische Kontrolle.