Ein weiterentwickelter Chaos-Botnet-Client rückt verstärkt falsch konfigurierte Cloud-Umgebungen ins Visier und löst damit klassische Ziele wie Heimrouter und Peripheriegeräte zunehmend ab. Aktuelle Analysen zeigen, dass Cyberkriminelle Cloud-Ressourcen systematisch als skalierbare, schwer zurückverfolgbare Infrastruktur für DDoS-Angriffe, Kryptomining und Anonymisierungsdienste missbrauchen.
Vom Heimrouter zur Cloud: Wie das Chaos-Botnet seine Ziele verlagert
Sicherheitsforscher von Darktrace beobachteten die neue Chaos-Variante in einem Honeypot, der einen absichtlich unsicher konfigurierten Hadoop-Cluster mit Remote-Code-Execution (RCE) simulierte. Solche Fallen bilden typische Fehlkonfigurationen in realen Cloud-Deployments nach, um das Vorgehen von Angreifern präzise zu studieren.
Die Angriffskette begann mit einem HTTP-Request an das Hadoop-Deployment zur Erstellung einer neuen Anwendung. In diesen Vorgang waren Shell-Befehle eingebettet, die einen 64‑Bit‑ELF-Agenten des Chaos-Botnets von pan.tenire[.]com nachluden, mittels chmod 777 mit maximalen Rechten ausführbar machten, starteten und anschließend von der Festplatte löschten. Dadurch verbleibt die Malware vor allem im Speicher und hinterlässt nur minimale forensische Spuren.
Dieses Muster ist typisch für Cloud-spezifische Angriffe: Ein exponierter oder unzureichend beschränkter Dienst wie Hadoop, Docker oder Kubernetes dient als Einstiegspunkt, anschließend wird Persistenz erreicht und der kompromittierte Server als Botnet-Knoten in eine verteilte Angriffsinfrastruktur integriert.
Herkunft und Entwicklung: Von Kaiji zu Chaos und Verbindung zu Silver Fox
Die Chaos-Malware wurde 2022 von Lumen Black Lotus Labs erstmals ausführlich beschrieben. Sie ist für Windows und Linux verfügbar und bietet Funktionen wie Remote Command Execution, das Nachladen zusätzlicher Module, SSH-Bruteforce zur lateralen Ausbreitung, Kryptomining sowie umfangreiche DDoS-Funktionalität über HTTP, TLS, TCP, UDP und WebSocket.
Forschende sehen Chaos als evolutionäre Weiterentwicklung des DDoS-Botnetzes Kaiji, das unter anderem fehlerhaft abgesicherte Docker-Instanzen missbrauchte. Codefragmente und die wiederholte Nutzung von Infrastruktur in China deuten auf mögliche Betreiber in dieser Region hin, eine belastbare Attribuierung liegt jedoch nicht vor. Branchenberichte wie der Verizon Data Breach Investigations Report heben hervor, dass Fehlkonfigurationen zu den führenden Ursachen für Cloud-Sicherheitsvorfälle zählen – ein Muster, das auch im Fall von Chaos sichtbar wird.
Besonders brisant ist die Überschneidung der Domains mit Aktivitäten der Gruppe Silver Fox. Dieselbe Infrastruktur, darunter pan.tenire[.]com, wurde laut Seqrite Labs im Rahmen von Operation Silk Lure für Phishing-Kampagnen und die Verteilung der Malware ValleyRAT genutzt. Dies unterstreicht die Tendenz krimineller Akteure, etablierte und bewährte Infrastruktur über mehrere Kampagnen hinweg wiederzuverwenden.
Technische Analyse: Infektionskette, ELF-Binary und Wandel der Funktionen
Die jetzt beobachtete Payload ist ein neu gestalteter 64‑Bit‑ELF-Binary, der wesentliche Fähigkeiten früherer Chaos-Versionen beibehält, aber in Teilen deutlich umstrukturiert wurde. Laut Darktrace wurden Komponenten, die stark an Kaiji erinnerten, refaktoriert oder vollständig neu implementiert, was auf eine kontinuierliche Weiterentwicklung und aktive Pflege des Codes schließen lässt.
Die wichtigste Änderung besteht im Entfernen der Selbstverbreitungsfunktionen. Mechanismen wie das automatisierte Durchprobieren von SSH-Anmeldedaten und das Ausnutzen von Router-Schwachstellen fehlen in der neuen Variante. Stattdessen implementieren die Angreifer eine integrierte SOCKS-Proxy-Funktion. Kompromittierte Cloud-Server fungieren damit als Knoten in einer anonymisierenden Proxy-Kette.
Über einen SOCKS-Proxy lässt sich nahezu beliebiger Netzwerkverkehr tunneln. Für Verteidiger erschwert dies die Attribution erheblich: Angriffe scheinen von legitimen IP-Adressen großer Cloud-Provider auszugehen, während sich die eigentlichen Steuerungsserver und menschlichen Operatoren hinter mehreren Proxystufen verbergen.
Monetarisierung durch Proxy-as-a-Service und Folgen für Unternehmen
Die Aufwertung zum Proxy-as-a-Service deutet auf eine veränderte Geschäftslogik hinter dem Chaos-Botnet hin. Neben etablierten Einnahmequellen wie Kryptomining und DDoS-for-hire können Betreiber nun anonyme Proxy-Zugänge auf Untergrundmärkten vermieten – ein Trend, der auch bei anderen Botnetzen wie AISURU beobachtet wird.
Für betroffene Organisationen bedeutet dies, dass ein kompromittierter Cloud-Server nicht nur DDoS-Kapazität bereitstellt, sondern ebenso als Sprungbrett für Phishing-Kampagnen, Einbrüche in Drittsysteme, Command-and-Control-Tarnung und das Umgehen von Geo- oder IP-Sperren dient. Selbst wenn keine direkten Datendiebstähle stattfinden, drohen IP-Blocklisten, Reputationsschäden und rechtliche Risiken, weil Angriffe scheinbar von der eigenen Infrastruktur ausgehen.
Schutz vor Chaos-Botnet und Cloud-Malware: Sicherheitsmassnahmen
Sichere Konfiguration und striktes Zugriffsmanagement
Der entscheidende Angriffsvektor ist die Fehlkonfiguration von Cloud-Diensten. Unternehmen sollten Remote-Code-Execution in Hadoop-, Docker- und Kubernetes-Umgebungen strikt begrenzen, anonymen oder unkontrollierten Zugriff unterbinden und den Least-Privilege-Grundsatz konsequent anwenden. Administrationsoberflächen gehören in abgeschottete Netzwerksegmente, geschützt durch VPN, starke Authentifizierung und Multi-Faktor-Authentifizierung (MFA).
Erkennung von Anomalien und verdächtigem Netzwerkverkehr
Moderne NDR- und EDR-Lösungen sollten genutzt werden, um ungewöhnliches Kommunikationsverhalten in Cloud-Workloads frühzeitig zu erkennen. Warnsignale sind etwa plötzliche ausgehende Verbindungen zu selten aufgerufenen Domains, ein sprunghafter Anstieg von TCP/UDP‑Traffic oder massenhafte HTTP-Anfragen zu atypischen Zielen. Auf Host-Ebene sind verdächtige wget/curl-Aufrufe zu externen URLs, häufiges chmod 777 und neu auftauchende, unbekannte ELF-Binaries wichtige Indicators of Compromise (IoCs).
Schwachstellenmanagement und Incident-Response-Faehigkeit
Ein kontinuierliches Vulnerability Management mit zeitnahen Patches für Betriebssysteme und Middleware, kombiniert mit Konfigurations-Audits nach etablierten Benchmarks wie den CIS Benchmarks, reduziert die Angriffsfläche deutlich. Ebenso wichtig sind getestete Incident-Response-Pläne, aktuelle, isolierte Backups und klar definierte Prozesse zur schnellen Isolation kompromittierter Cloud-Knoten, um eine Einbindung in Botnetze wie Chaos effektiv zu unterbinden.
Die aktuelle Entwicklung des Chaos-Botnets zeigt, wie schnell sich cyberkriminelle Ökosysteme an die Realität von Cloud-Computing und die Nachfrage nach Traffic-Anonymisierung anpassen. DDoS-Angriffe sind längst nicht mehr das einzige Risiko: Jeder unzureichend geschützte Cloud-Server kann sich unbemerkt in einen Knoten einer globalen Proxy- und Angriffsplattform verwandeln. Organisationen sollten daher ihre Cloud-Konfigurationen kritisch überprüfen, Überwachungs- und Reaktionsfähigkeiten stärken und Security-Teams gezielt zu Cloud-spezifischen Bedrohungen schulen, um die eigene Infrastruktur nicht zur Infrastruktur für fremde Angriffe werden zu lassen.
