xlabs_v1: The Botnet That Rents Out Your Android TV Box as a DDoS Weapon

A newly discovered botnet called xlabs_v1 is recruiting Android TV boxes and IoT devices through a developer debug port, renting out their bandwidth for DDoS attacks — complete with automatic bandwidth profiling as the basis for a tiered pricing model.

An open port nobody closes

Port 5555 is no exotic attack surface. ADB, the Android Debug Bridge, is a standard developer tool that allows remote control of Android devices over the network. Useful when testing apps at a desk. Catastrophic when the port is exposed directly to the internet — which is alarmingly common on cheap Android TV boxes and set-top boxes from budget manufacturers.

That is exactly where xlabs_v1 operates. Security researchers at Hunt.io discovered the botnet after identifying an unsecured directory on a Netherlands-hosted server containing the operator’s entire toolkit, no authentication required, freely accessible. What they found there is described in their analysis as technically middling but operationally well-considered.

How the infection works

The approach is straightforward. The botnet scans the internet for devices running ADB on TCP port 5555. Once a device is found, the attacker connects via ADB shell and executes commands that drop a malware file called “boot.apk” into the /data/local/tmp directory — a writable path accessible on Android devices without root privileges.

What happens next is where it gets interesting. The botnet does not persist. It does not write itself to permanent system locations, does not add autostart entries, does not register systemd services. The malware runs, completes its task, and disappears. That sounds like a weakness. According to Hunt.io, it is deliberate.

The pricing model is in the code

The actual purpose of the first visit to an infected device is not the attack itself — it is the measurement. xlabs_v1 opens 8,192 parallel TCP connections to the geographically nearest Speedtest server, saturates them for 10 seconds, and reports the measured throughput in megabits per second back to the operator’s control panel at the domain “xlabslover[.]lol”.

This produces a bandwidth profile for each compromised device, which apparently serves as the basis for a tiered pricing model: more attack power costs more. Because the botnet establishes no persistence, the operator must re-infect the device a second time through the same ADB channel to carry out the actual attack. That too is by design: profiling is an occasional fleet-tier update, not a pre-flight check before every attack.

21 flood variants and a competitor killer

For the attack itself, a broad arsenal is available. Hunt.io counts 21 different flood variants across TCP, UDP, and raw protocols, including specialized techniques such as RakNet and OpenVPN-shaped UDP. RakNet is a network protocol used primarily in games; the botnet mimics its traffic patterns to bypass consumer-grade DDoS protection systems.

Beyond the pure attack functions, xlabs_v1 includes a so-called killer subsystem. It actively searches infected devices for processes belonging to competing malware and terminates them, claiming the device’s full upstream bandwidth for itself. The malicious code also contains a ChaCha20-encrypted string — ChaCha20 being a symmetric encryption algorithm commonly used in malware to obfuscate configuration data — that points to the moniker “Tadashi” as the operator.

The service’s target audience is clearly defined: game servers and Minecraft hosts.

Who is at risk?

Primarily devices shipped with the ADB debug interface enabled and connected directly to the internet. That includes above all cheap Android TV boxes from the grey market, set-top boxes, and smart TVs from certain manufacturers, as well as ARM-based IoT hardware such as residential routers. The malware supports builds for ARM, MIPS, x86-64, and ARC, covering a broad device base.

For operators of home networks and small infrastructures, this is a concrete problem. Many of these devices end up on the network and are never actively managed again. Firmware updates are skipped, network segmentation is absent, and whether port 5555 is open is something almost nobody checks.

Assessment: mid-tier with ambitions

Hunt.io itself classifies xlabs_v1 as mid-tier: technically more sophisticated than a typical script-kiddie Mirai fork, but well below the level of professional DDoS-for-hire operations backed by state actors or organized criminal groups. The operator competes on price and attack variety, not technical depth.

Concurrent with the discovery of xlabs_v1, security firm Darktrace reported a separate incident: an intentionally misconfigured Jenkins server in its honeypot network was targeted by unknown threat actors to deploy another DDoS botnet. There too, the focus was on gaming targets. Coincidence or pattern? At minimum, a signal that the gaming industry is seen as a rewarding target for DDoS extortion.

What to do now

Three concrete measures follow from the analysis. First: close ADB ports on all network-capable Android devices, or at least isolate them from the internet via firewall rules. Second: maintain device inventories and audit which IoT hardware on your network is running with which open ports. Tools such as NetAlertX can help with this. Third: when purchasing Android TV boxes and similar devices, choose manufacturers that ship with security-oriented default configurations and provide regular firmware updates.

The xlabs_v1 case is a further reminder that IoT security fails less on sophisticated attack techniques than on default configurations left wide open. A developer tool designed for the desktop, exposed directly to the internet. That is enough.