Zum Inhalt springen
Software Supply Chain Security

Kimwolf v7: HTTP/2-DDoS wird wie normales Browsing getarnt

Kimwolf v7

Cybersecurity-Teams haben eine neue Version des Kimwolf/AISURU-Botnetzes identifiziert: Kimwolf v7. Die aktuelle Ausprägung setzt auf spürbare Verbesserungen, um Angriffe stabil durchzuführen und die eigene Infrastruktur widerstandsfähiger gegen Abschaltungen zu machen. Besonders auffällig ist ein HTTP/2-basierter DDoS-Mechanismus, der so konstruiert ist, dass er sich wie normales Browsing anfühlt.

Die Entdeckung erfolgte im Februar 2026 durch das Unit-42-Team von Palo Alto Networks. In der Analyse wird deutlich, dass die Entwickler nicht nur die Angriffskraft erhöhen, sondern auch die Erkennbarkeit senken und die Aufrüstung der Botnet-Komponenten besser trennen.

Warum Kimwolf v7 HTTP/2-DDoS wie echtes Browsing aussehen lässt

Ein zentraler Baustein von Kimwolf v7 ist eine HTTP/2-Flut, die mit der nghttp2-Bibliothek umgesetzt wird. Dabei geht es nicht nur um „viel Traffic“, sondern um Details, die sonst typischerweise bei legitimem Browserverhalten vorkommen.

Die Forscher beschreiben, dass der Angriff vollständige Browser-Fingerabdrücke nachbaut. Diese Fingerabdrücke spiegeln Verhalten auf Protokoll- und Header-Ebene wider. Dadurch fällt es deutlich schwerer, den Datenstrom klar als Angriff zu identifizieren, weil viele Signale eher nach „normaler“ Nutzung wirken als nach synthetischem Flooding.

Mehr Ausdauer: C2 bleibt bei Abschaltungen länger im Betrieb

Neben der DDoS-Komponente konzentriert sich Kimwolf v7 stark auf die Zuverlässigkeit der Command-and-Control-Infrastruktur (C2). Das Ziel: Besser gegen Takedowns und Blockierungsversuche gerüstet sein.

Wie in der Analyse beschrieben, nutzt das Botnet einen mehrstufigen Mechanismus zur Ermittlung von C2-Adressen. Dabei greifen verschiedene Elemente zusammen:

  • Ethereum Name Service (ENS) wird verwendet, um C2-Ziele über öffentliche Ethereum-RPC-Dienste aus Domain-Aufzeichnungen zu resolven.
  • Zusätzlich gibt es eine harte Tor-.onion-Hidden-Service-Adresse, die direkt im Binärfile hinterlegt ist.
  • Ein lokaler Proxy routet C2-Daten zwischen „clearnet“ und Tor – also übergreifend, je nachdem, wohin die Kommunikation zielt.

Ein weiterer Punkt ist, dass Scans, Exploits und Brute-Force in der neuen Version entfernt wurden. Das deutet darauf hin, dass Angreifer die „Ausbreitungspipeline“ vom Kernpayload trennen. Für den ersten Zugriff setzt das Netzwerk demnach offenbar auf einen externen Loader, während Kimwolf v7 vor allem die DDoS-Angriffe sowie das Proxy-Relay übernimmt.

Neue Funktionsblöcke: Architektur, Angriffslogik und Performance

Die Analyse nennt mehrere konkrete Eigenschaften der beobachteten Version. Dazu zählt unter anderem:

  • HTTP/2-Floods auf Basis von nghttp2, kombiniert mit vollständigen Browser-Fingerabdrücken.
  • Public Ethereum RPC zur Abfrage von ENS-Domainrecords und zur Auflösung von C2-Adressen.
  • Ein Backup-C2 über einen hard-codierten Tor Hidden Service mit der genannten .onion-Adresse.
  • Eine lokale Proxy-Architektur, die C2-Verbindungen über 127.0.0.1:23075 umleitet – unabhängig davon, ob Ziele im clearnet oder im Tor-Umfeld liegen.
  • Eine UDP-Flood-Funktion, die gezielt ARM-Prozessoren anspricht, wie sie in Android-TV-Boxen vorkommen.
  • Die Konsolidierung von DDoS-Kommandos auf 15 nummerierte Methoden statt zuvor 43 textbasierte Methoden.

Dass Kommandos reduziert und strukturierter gebündelt wurden, kann mehrere Effekte haben: weniger Komplexität im Ablauf, potenziell weniger Angriffsfläche in der Implementierung und ein klarerer interner Ablaufplan.

Wie sich das Botnet ausbreitet: ADB als Haupthebel

Kimwolf ist besonders mit Android-TV-Boxen verbunden. Laut Unit 42 zielt die Familie seit August 2025 vorrangig auf solche Geräte. Daneben existiert mit AISURU eine Linux-Variante, die sich auf Linux-IoT-Geräte fokussiert.

Der Betrieb läuft seit mindestens Mitte 2024. Für die Übernahme der Zielsysteme missbraucht das Botnet typischerweise Residential Proxy Services, um Android-TV-Geräte zu erreichen. Entscheidend dabei ist, dass in lokalen Netzwerken häufig Android Debug Bridge (ADB) aktiv ist – insbesondere auf Port 5555.

Ist ein Gerät kompromittiert, wird Malware installiert, die nicht nur DDoS-Angriffe ausführen kann, sondern auch als Relay dient, um bösartigen Traffic weiterzutragen. Um dabei weniger sichtbar zu sein, versucht sich die Software als scheinbar legitime Android-Systemprozesse zu tarnen – beispielsweise unter Namen, die an netd_service angelehnt sind.

Beispiel: APKs, die sich als Systemservice ausgeben

Die Angreifer verteilen zudem Android-APK-Pakete, die sich als ein als „SystemService“ getarnter Systemservice ausgeben. In den untersuchten Fällen wird außerdem nach Root-Rechten gesucht. Anschließend führen die Pakete offenbar eine eingebettete ELF-Kernel-Payload aus.

Unit 42 berichtet, dass zwischen Oktober und Dezember 2025 acht solche APK-Artefakte identifiziert wurden.

Entwicklung von Linux-Exploitation zu ADB-basierter Ausbreitung

Ein interessantes Detail in der Historie: Das früheste beobachtete Sample, das auf x86 abzielte, nutzte einen Dirty-COW-Exploit. Das spricht dafür, dass sich die Familie von klassischer Linux-Exploitation hin zu einem ADB-basierten Android-Ausbreitungsmodell weiterentwickelt hat.

Die Forscher verweisen außerdem auf Änderungen in Dateinamen und Komponenten: So wurde im November 2025 von einer stärker auffälligen Bezeichnung hin zu einem weniger auffälligen Dateinamen gewechselt, und im Dezember 2025 gab es eine Rückänderung. Solche Anpassungen deuten auf aktive Operational Security hin – also darauf, dass die Angreifer versuchen, Erkennungsmuster zu umgehen.

Welche anderen Botnet-Familien im gleichen Umfeld auftauchen

Die Veröffentlichung ordnet Kimwolf v7 in eine Reihe weiterer aktueller Botnet-/Malware-Funde ein. Dazu zählen unter anderem:

  • AryStinger, das ältere, verwundbare Home-Router für verteilte Aufklärung und Proxys in ein Netzwerk einbindet.
  • RustDuck, das Home-Router, IP-Kameras, Android-Boxen sowie schlecht abgesicherte Server kapert, um sie für DDoS-Angriffe einzusetzen.
  • NadMesh, eine Plattform, die Scanning, Exploitation und das Ernten von Informationen aus Credentials/AI-Diensten kombiniert und Ziele wie Redis, Docker, diverse Kubernetes-Umgebungen sowie mehrere AI-/Web-UI-Komponenten adressiert.
  • Tengu, eine Mirai-abgeleitete IoT-Malware, die u. a. über Telnet-Bruteforce Geräte übernimmt und sie für DoS, Persistenz und weitere Aktionen nutzt.

Für Organisationen zeigt dieses Gesamtbild: Botnet-Betreiber investieren in modularere Abläufe, breit angelegte Zielsysteme und bessere Tarnung.

Konkrete Schutzmaßnahmen: Android-TV-Geräte nicht als vertrauenswürdig behandeln

Unit 42 empfiehlt vor allem, Android-TV-Boxen als nicht vertrauenswürdig zu betrachten und sie vom Unternehmensnetzwerk zu isolieren. Darüber hinaus nennen die Forscher eine klare Maßnahme, um den zentralen Ausbreitungsweg zu unterbrechen: ADB deaktivieren oder nur auf USB-only beschränken.

Diese Schritte reduzieren den Zugriffspfad, über den das Botnet typischerweise Geräte im lokalen Umfeld übernimmt. Ergänzend lohnt es sich, Systeme und Netzwerkzugänge regelmäßig auf Exponierung von Debug-/Admin-Schnittstellen zu prüfen.

Fazit: Kimwolf v7 macht DDoS schwerer erkennbar

Kimwolf v7 steht für eine gezielte Weiterentwicklung: Der HTTP/2-DDoS ist so gestaltet, dass der Traffic wie legitimes Browsing wirkt, indem Browser-Fingerabdrücke auf Protokoll- und Header-Ebene nachgebildet werden. Gleichzeitig verbessern die Betreiber die Robustheit ihrer C2-Infrastruktur durch eine mehrstufige Architektur mit ENS, Tor-Backup und lokalem Proxy-Routing.

Für Unternehmen heißt das: Besonders Android-TV-Boxen sollten streng abgesichert oder isoliert werden, und ADB sollte konsequent deaktiviert bzw. stark eingeschränkt sein. So lässt sich der wichtigste Verbreitungshebel reduzieren, bevor das Botnet überhaupt in die Organisation eindringt.

Quelle: https://thehackernews.com/2026/08/kimwolf-v7-android-botnet-makes-http2.html