There is a debugging tool built into Android that was designed for developers — a way to connect to a device over the network and issue commands to it directly, bypassing the normal interface. It’s called Android Debug Bridge, or ADB. It runs on port 5555. And on millions of Android TV boxes, streaming sticks, smart TVs, and set-top boxes sitting in living rooms across the world, it’s left enabled and exposed to the internet by default.

In early May 2026, researchers at Hunt.io discovered a botnet that has been quietly exploiting exactly this configuration. The botnet calls itself xlabs_v1. It targets any device with an exposed ADB service, recruits it into a distributed denial-of-service network, and makes that network available for hire to anyone who wants to knock targets offline. The service is tiered by bandwidth, the threat actor goes by the name Tadashi, and your streaming device may already be part of it.

What ADB Is and Why It Matters

Android Debug Bridge is a legitimate developer tool. When you’re building an Android app and need to test it on a real device, ADB lets you push the app to the device, view log output, run shell commands, and diagnose problems — all over a USB or network connection. It’s an essential part of the Android development toolkit.

The network version of ADB listens on TCP port 5555. On a phone or tablet, this mode is disabled by default and requires developer mode to be enabled before it can be used. But on Android TV boxes, set-top boxes, streaming devices, and some smart TVs — particularly cheaper models from manufacturers who pre-configure the device for easier mass deployment — ADB over network is sometimes left enabled from the factory.

The security implication is significant: ADB gives whoever connects to it unrestricted shell access to the device. Not read access. Not limited access through an API. Full shell access, equivalent to having physical possession of the device and a keyboard. Any command you could run with the device in your hands, you can run remotely through an open ADB port.

When xlabs_v1 finds a device with ADB exposed on port 5555, it connects, drops its malware payload, and the device joins the botnet. No password required. No exploit needed. The port is open and the tool is designed to accept connections.

How Hunt.io Found It

Researchers at Hunt.io discovered xlabs_v1 after identifying an exposed directory listing on a server hosted in the Netherlands — IP address 176.65.139.44 — that required no authentication to browse. The directory contained the botnet’s malware binaries, configuration files, and operational infrastructure.

This kind of exposure is a recurring pattern in botnet operations. Threat actors who are careful about hiding their C2 infrastructure sometimes leave staging servers — where malware builds are stored before deployment — with weak or absent access controls. Hunt.io’s passive scanning infrastructure flagged the open directory.

What the researchers found inside was detailed. The botnet includes multi-architecture builds covering ARM, MIPS, x86-64, and ARC — the processor architectures that cover the full range of Android TV hardware, residential routers, and IoT devices. The ChaCha20-encrypted strings embedded in every build include the operator’s handle, Tadashi, functioning as a kind of signature.

The discovery also revealed how the for-hire service works. Before enlisting a new victim device into DDoS attacks, the malware runs a bandwidth profiling routine: it opens 8,192 parallel TCP connections to the nearest Speedtest server, saturates them for 10 seconds, and reports the measured bandwidth back to the control panel. Customers who rent attack capacity presumably get to see the available bandwidth from each node — and pay accordingly.

21 DDoS Flood Variants — Including Methods That Bypass Consumer Protection

The xlabs_v1 malware supports 21 distinct DDoS flood methods across TCP, UDP, and raw protocol layers. The variety is deliberate: different flood types are effective against different targets and bypass different types of protective filtering.

Two of the supported flood methods stand out: RakNet-shaped UDP and OpenVPN-shaped UDP. These protocols are used by legitimate applications — RakNet is a networking library used in video games (including Minecraft and its derivatives), and OpenVPN is a widely-deployed VPN protocol. By shaping DDoS traffic to look like RakNet or OpenVPN packets, the botnet can slip through consumer-grade DDoS protection that relies on traffic pattern recognition to identify and block attack traffic.

The presence of RakNet-shaped attacks aligns with the botnet’s apparent primary market. Reporting indicates xlabs_v1 is offered as a service specifically targeting game servers and Minecraft hosts — a market segment with a long history of DDoS-for-hire activity, where competitors, disgruntled players, and extortion actors routinely attack each other’s servers.

The broader impact, however, extends well beyond game servers. A botnet with 21 attack methods and the ability to bypass consumer protection can be directed at any internet-accessible target. The game server market is likely where the initial customer base was built; the infrastructure itself is general-purpose.

What Devices Are at Risk

The primary entry point for xlabs_v1 is exposed ADB on port 5555. The devices most likely to have this configuration:

Android TV boxes. Generic Android TV boxes — often sold unbranded or under unfamiliar brand names at low price points — are frequently shipped with ADB network mode enabled. These devices often skip security hardening in favor of ease of deployment and low manufacturing cost. If you purchased an Android TV box for under $40 or $50 and it runs stock or near-stock Android, check its ADB status.

Amazon Fire TV devices in developer mode. Amazon’s Fire TV platform allows users to enable ADB for sideloading apps — installing applications that aren’t available through the Amazon Appstore. Many users enable developer mode and ADB to install alternative apps, then forget it’s enabled. Fire TV devices with ADB enabled and no firewall between them and the internet are exposed.

Android-based smart TVs. Some smart TV manufacturers, particularly lower-cost brands, ship Android TV implementations with ADB accessible over the network. The exposure depends heavily on the specific manufacturer and firmware version.

Routers. The multi-architecture builds suggest xlabs_v1 also targets routers through other means — likely additional exploit modules beyond ADB. The ARM and MIPS builds cover the processor architectures used in most home routers.

How to Check for and Close Exposed ADB

For Android TV boxes and streaming devices:

The simplest check: from a computer on the same network, run nmap -p 5555 [device-ip] to see whether port 5555 is listening on the device. If you don’t have nmap available, a port scanner app on another Android device can accomplish the same check.

To disable ADB on an Android device: go to Settings > Developer Options and disable both “USB debugging” and “ADB over network” (the exact labels vary by manufacturer and Android version). If you don’t see Developer Options in Settings, it hasn’t been enabled — ADB is likely off, but it’s still worth verifying the port is closed.

If you can’t find a way to disable ADB through the settings interface, your device may have it enabled at the firmware level without a user-accessible toggle. This is a manufacturer design decision, and in that case the options are limited to network-level protection: placing the device behind a router that doesn’t expose port 5555 to the internet (which should be the default for any properly configured home router), or replacing the device with one from a manufacturer that follows security baseline practices.

Check your router’s port forwarding rules. A device with ADB exposed at the network-interface level is only directly reachable from the internet if your router is forwarding external traffic to it on port 5555. Check your router’s port forwarding settings and remove any rules that forward traffic to Android TV or media devices. No home user has a legitimate reason to have ADB accessible from the public internet.

Check for IoT device segmentation. Placing Android TV boxes, streaming sticks, and smart TVs on a separate network segment from your computers and phones limits the blast radius if any device is compromised. Even a basic guest network provides meaningful isolation — the smart TV can’t reach your laptop’s file shares or your NAS drives if they’re on different network segments.

The Broader Picture: Consumer Devices as Attack Infrastructure

xlabs_v1 is part of a long lineage of Mirai-derived botnets that have exploited the security gap between the devices consumers buy and the security practices those devices require. The original Mirai botnet, released in 2016, achieved its record-breaking DDoS attacks using compromised IP cameras and DVRs. A decade later, the same fundamental vulnerability — devices shipped with accessible management interfaces, weak or absent authentication, and no meaningful update mechanism — persists in a new generation of hardware.

The Android TV category is an emerging frontier for this. As streaming devices have proliferated and the price of Android TV hardware has dropped, the security practices of manufacturers in this space have not uniformly kept pace. A device that costs $30 at retail and ships with ADB enabled on the network is not an edge case. It’s a product category characteristic.

The FCC’s Cyber Trust Mark program — now under ioXt Alliance’s administration — specifically addresses this category. A device with network-accessible developer interfaces enabled by default would not pass the Cyber Trust Mark’s requirements. But the label is still coming into full operation, and the devices already deployed in homes carry whatever security configuration they shipped with.

Until there’s a reliable consumer signal for smart home device security at point-of-sale, the burden falls on the homeowner: check what’s running on your devices, close what shouldn’t be open, and segment devices that can’t be hardened from the rest of your network. Port 5555 shouldn’t be listening on anything in your living room.