xlabs_v1: Wie ein Botnet Android-TV-Boxen zu mietbaren DDoS-Waffen macht
Ein neu entdecktes Botnet namens xlabs_v1 rekrutiert Android-TV-Boxen und IoT-Geräte über einen Entwickler-Debug-Port und vermietet deren Bandbreite für DDoS-Angriffe – inklusive automatischem Bandbreiten-Profiling als Grundlage für ein gestaffeltes Preismodell.
Das Wichtigste in Kürze
- xlabs_v1 ist ein Mirai-basiertes Botnet, das IoT-Geräte wie Android-TV-Boxen über den offenen ADB-Port 5555 (Android Debug Bridge, ein Entwicklerwerkzeug zur Fernsteuerung von Android-Geräten) kompromittiert und als DDoS-for-hire-Dienst betreibt.
- Das Botnet misst aktiv die Uploadbandbreite jedes infizierten Geräts über 8.192 parallele TCP-Verbindungen zum nächstgelegenen Speedtest-Server und weist Geräte anschließend einem Preistier zu.
- Mit 21 Flood-Varianten über TCP, UDP und Raw-Protokolle sowie einem aktiven Konkurrenten-Killer-Modul zielt xlabs_v1 vor allem auf Gaming-Server und Minecraft-Hosts ab.
Ein offener Port, den niemand schließt
Port 5555 ist kein exotisches Angriffsziel. ADB, die Android Debug Bridge, ist ein Standardwerkzeug für Entwickler, das die Fernsteuerung von Android-Geräten über das Netzwerk erlaubt. Sinnvoll beim Testen von Apps auf dem Schreibtisch. Katastrophal, wenn der Port offen ins Internet zeigt, was bei Android-TV-Boxen und Set-Top-Boxen günstiger Hersteller erschreckend oft der Fall ist.
Genau dort setzt xlabs_v1 an. Sicherheitsforscher von Hunt.io entdeckten das Botnet, nachdem sie auf einem niederländischen Server ein ungesichertes Verzeichnis mit dem gesamten Werkzeugkasten des Betreibers fanden, ohne Authentifizierung, frei zugänglich. Was sie dort vorfanden, beschreiben sie in ihrer Analyse als technisch mittelmäßig, aber operativ durchdacht.
Wie die Infektion läuft
Das Vorgehen ist direkt: Das Botnet scannt das Internet nach Geräten, die ADB auf TCP-Port 5555 offen haben. Wird ein solches Gerät gefunden, verbindet sich der Angreifer per ADB-Shell und führt Befehle aus, die eine Malware-Datei namens „boot.apk“ in das Verzeichnis /data/local/tmp ablegen. Das ist ein beschreibbarer Pfad, der auf Android-Geräten ohne Root-Rechte zugänglich ist.
Bemerkenswert ist, was danach passiert: Das Botnet persistiert sich nicht. Es schreibt sich nicht dauerhaft ins System, legt keine Autostart-Einträge an, registriert keine systemd-Dienste. Die Malware läuft, führt ihre Aufgabe aus und verschwindet. Das klingt nach einer Schwäche, ist aber laut Hunt.io Absicht.
Das Preismodell steckt im Code
Die eigentliche Aufgabe beim ersten Besuch auf einem infizierten Gerät ist nicht der Angriff selbst, sondern die Messung. xlabs_v1 öffnet 8.192 parallele TCP-Verbindungen zum geografisch nächstgelegenen Speedtest-Server, saturiert diese für 10 Sekunden und meldet den gemessenen Durchsatz in Megabit pro Sekunde zurück an das Kontrollpanel des Betreibers unter der Domain „xlabslover[.]lol“.
Daraus ergibt sich ein Bandbreiten-Profil jedes kompromittierten Geräts, das offenbar als Grundlage für ein gestaffeltes Preismodell dient: Wer mehr Angriffskraft kauft, zahlt mehr. Weil das Botnet keine Persistenz anlegt, muss der Betreiber das Gerät für den eigentlichen Angriff ein zweites Mal infizieren. Auch das ist bewusst so konstruiert: Das Profiling ist ein gelegentliches Flottenupdate, kein Vorbereitungsschritt vor jedem Angriff.
21 Flood-Varianten und ein Konkurrenten-Killer
Für den Angriff selbst steht ein breites Arsenal bereit. Hunt.io zählt 21 verschiedene Flood-Varianten über TCP, UDP und Raw-Protokolle, darunter spezialisierte Techniken wie RakNet und OpenVPN-geformtes UDP. RakNet ist ein Netzwerkprotokoll, das vor allem in Spielen eingesetzt wird; das Botnet imitiert dessen Datenverkehr, um einfache DDoS-Schutzsysteme zu umgehen.
Neben den reinen Angriffsfunktionen enthält xlabs_v1 ein sogenanntes Killer-Subsystem. Es sucht auf infizierten Geräten aktiv nach Prozessen konkurrierender Schadsoftware und beendet diese, um die gesamte verfügbare Uploadbandbreite für sich zu beanspruchen. Der Schadcode enthält außerdem einen mit ChaCha20 verschlüsselten String (ChaCha20 ist ein symmetrisches Verschlüsselungsverfahren, das häufig in Malware zur Verschleierung von Konfigurationsdaten eingesetzt wird), der auf den Moniker „Tadashi“ als Betreiber hindeutet.
Die Zielgruppe des Dienstes ist klar definiert: Gaming-Server und Minecraft-Hosts.
Wer ist gefährdet?
Primär Geräte, die mit aktiviertem ADB-Debug-Interface ausgeliefert werden und direkt am Internet hängen. Dazu zählen vor allem günstige Android-TV-Boxen aus dem Graumarkt, Set-Top-Boxen und Smart-TVs bestimmter Hersteller, aber auch ARM-basierte IoT-Hardware wie Residential Router. Die Malware unterstützt Builds für ARM, MIPS, x86-64 und ARC, deckt also eine breite Gerätebasis ab.
Für Betreiber von Heimnetzwerken und kleinen Infrastrukturen ist das ein konkretes Problem: Viele dieser Geräte landen im Netzwerk und werden danach nicht mehr aktiv verwaltet. Firmware-Updates bleiben aus, Netzwerksegmentierung fehlt, und ob Port 5555 offen ist, prüft kaum jemand.
Einordnung: Mittelklasse mit Ambitionen
Hunt.io ordnet xlabs_v1 selbst als Mittelklasse ein: technisch ausgereifter als ein typischer Script-Kiddie-Mirai-Fork, aber weit unter dem Niveau der professionellen DDoS-for-hire-Dienste, die auf staatliche oder organisierte kriminelle Akteure zurückgehen. Der Betreiber konkurriert über Preis und Angriffsvielfalt, nicht über technische Tiefe.
Zeitgleich zur Entdeckung von xlabs_v1 berichtete das Sicherheitsunternehmen Darktrace von einem separaten Vorfall: Ein absichtlich falsch konfigurierter Jenkins-Server in einem Honeypot-Netzwerk wurde von unbekannten Angreifern genutzt, um ebenfalls ein DDoS-Botnet zu laden. Auch dort lag der Fokus auf Gaming-Zielen. Zufall oder Muster? Zumindest ein Hinweis darauf, dass die Spieleindustrie als lohnenswertes Ziel für DDoS-Erpressung gilt.
Was man jetzt tun sollte
Drei konkrete Maßnahmen lassen sich aus der Analyse ableiten. Erstens: ADB-Ports auf allen netzwerkfähigen Android-Geräten schließen oder zumindest durch Firewall-Regeln vom Internet isolieren. Zweitens: Geräteinventare pflegen und prüfen, welche IoT-Hardware im eigenen Netzwerk mit welchen offenen Ports betrieben wird. Dabei helfen zum Beispiel Tools wie NetAlertX. Drittens: Bei der Beschaffung von Android-TV-Boxen und ähnlichen Geräten auf Hersteller setzen, die sicherheitsorientierte Standardkonfigurationen liefern und regelmäßige Firmware-Updates bereitstellen.
Der Fall xlabs_v1 ist ein weiteres Beispiel dafür, dass IoT-Sicherheit weniger an ausgeklügelten Angriffstechniken scheitert als an offen gelassenen Standardkonfigurationen. Ein Entwicklerwerkzeug, das für den Schreibtisch gedacht ist, direkt im Internet. Das reicht.














