Threat intelligence researchers at Hunt.io have exposed xlabs_v1, a Mirai-derived botnet (a variant of the notorious Mirai malware family that first emerged in 2016 and pioneered large-scale IoT botnet attacks) that targets internet-exposed Android Debug Bridge (ADB) services on IoT devices to enlist them in a commercial distributed denial-of-service (DDoS) operation. The botnet supports 21 distinct flood variants, uses bandwidth-based pricing for its DDoS-for-hire clients, and is operated by a threat actor using the handle "Tadashi," whose infrastructure was exposed by a carelessly open directory on a Netherlands-hosted server.
xlabs_v1 Technical Details
Android Debug Bridge (ADB — a command-line tool included in the Android SDK that allows developers to communicate with and control Android devices) listens on TCP port 5555 by default. When ADB is enabled on a device and not properly secured, it grants remote shell access without requiring any authentication — a feature designed for legitimate development use that becomes a critical vulnerability when devices are exposed to the internet.
xlabs_v1 scans for devices with ADB listening openly on port 5555 and exploits the legacy ADB mode's lack of authentication to deliver malware payloads via adb shell commands. Payloads are written to /data/local/tmp — a world-writable directory on Android systems that does not require root access to write to. The malware supports multiple processor architectures through multi-architecture builds, covering the range of chipsets found across consumer IoT devices:
- ARM (most smart TVs and Android TV boxes)
- MIPS (common in residential routers)
- x86-64 (set-top boxes and some embedded devices)
- ARC (lower-power embedded controllers)
Once a device is compromised, xlabs_v1 conducts an unusual pre-enrollment step: it opens 8,192 parallel TCP connections to the nearest Speedtest.net servers to measure the device's upstream bandwidth capacity. This profiling step determines the device's value to the botnet operator — higher-bandwidth devices command higher tiers in the pricing model.
The botnet operator, identified by the ChaCha20-encrypted (a symmetric stream cipher used here to obscure operator identity in the malware binary) string "Tadashi" embedded in all bot builds, maintains the following C2 (command-and-control — the infrastructure through which malware operators issue commands to compromised devices) infrastructure:
- C2 domain: xlabslover[.]lol
- Hosting: A single /24 netblock in the Offshore LC autonomous system (AS214472), Netherlands
- Co-location: C2, distribution servers, staging infrastructure, and a Monero cryptocurrency mining operation are all consolidated in the same netblock
Hunt.io discovered the full infrastructure in early April 2026 after identifying an exposed directory listing on the threat actor's Netherlands server — a reconnaissance error that revealed the botnet's organization and capabilities.
Flood Capabilities and DDoS-for-Hire Model
xlabs_v1 implements 21 distinct flood variants spanning TCP, UDP, and raw protocol attack types. Notable capabilities include:
- RakNet floods — specifically designed to target Minecraft servers (RakNet is the network protocol used by Minecraft Bedrock Edition)
- OpenVPN-shaped UDP floods — crafted to mimic legitimate OpenVPN traffic patterns, enabling attacks to bypass network filters that would otherwise block obvious junk traffic
- Standard TCP SYN floods, UDP amplification attacks, and HTTP layer floods
The operation functions as a tiered DDoS-for-hire service, where pricing is determined by the measured bandwidth speeds of enrolled devices, not a flat rate. Clients presumably pay more for attacks with higher aggregate throughput capability.
The botnet deliberately implements no persistence mechanisms — no disk writes beyond initial infection, no systemd service registration, no cron jobs. This keeps the malware footprint minimal and makes infected devices harder to identify during forensic review, but also means the botnet must continuously re-infect devices.
Hunt.io classifies xlabs_v1 as "mid-tier sophistication" — more engineered than script-kiddie variants but less capable than premium commercial DDoS operations.
Who Is Affected
Devices at risk from xlabs_v1 infection are any internet-connected Android-based or ADB-capable devices with port 5555 exposed:
- Android TV boxes (Mecool, Beelink, X96, and similar generic brands common in home entertainment setups)
- Set-top boxes with Android-based firmware
- Smart TVs running Android TV or Google TV operating systems
- Residential routers with ADB interfaces enabled (some carrier-provided equipment includes ADB for remote support)
- IoT devices with ARM architecture and accessible ADB implementations
The primary DDoS targets are Minecraft servers and game servers — xlabs_v1 is purpose-built around the RakNet protocol used by Minecraft Bedrock Edition, and its tiered pricing model suits gaming communities that may hire DDoS-for-hire services to take down competing servers.
However, DDoS-for-hire infrastructure can be directed at any target. Organizations outside the gaming sector should not treat xlabs_v1 as irrelevant — the same botnet can be redirected against enterprise infrastructure, financial services platforms, or critical services by any customer willing to pay the operator's rates.
What You Should Do Right Now
- Disable ADB on all IoT devices. If you manage Android TV boxes, set-top boxes, or smart TVs, verify that ADB is disabled in the device developer settings. Most consumer devices ship with ADB disabled; it may have been enabled for troubleshooting and left open.
- Block TCP port 5555 at network perimeter. Implement a firewall rule blocking inbound and outbound connections on port 5555 at your network boundary. There is no legitimate reason for consumer IoT devices to have ADB accessible from the internet.
- Audit residential and SOHO router firmware. Check whether your router or ISP-provided gateway device exposes ADB. Carrier-provided equipment sometimes includes ADB for remote support — contact your ISP to confirm this is not enabled on your device.
- Monitor for unexpected bandwidth consumption. xlabs_v1's bandwidth profiling step — 8,192 parallel connections to Speedtest servers — should appear as an anomalous traffic spike in network monitoring. Devices suddenly consuming unusual upstream bandwidth for short periods may be compromised.
- Block outbound connections to the known C2 domain. Add
xlabslover[.]lol(defanged for safety — replace[.]with.) and its associated Netherlands /24 netblock to your threat feed blocklist if your security tooling allows domain and ASN-based blocking.
# Linux/router — block ADB port at firewall
iptables -A INPUT -p tcp --dport 5555 -j DROP
iptables -A OUTPUT -p tcp --dport 5555 -j DROP
# Check if ADB is accessible on a device (from management network)
adb connect <device-ip>:5555
adb devices
# If this succeeds without authentication, ADB is improperly exposed
Background: Understanding the Risk
Mirai's 2016 emergence demonstrated that compromised IoT devices — cheap, widely deployed, and almost universally unmanaged — could be aggregated into botnets capable of generating traffic volumes that overwhelm even well-resourced targets. The 2016 Dyn DNS attack, driven by Mirai, took down major portions of the internet for millions of users by targeting a single DNS provider with aggregate IoT botnet traffic.
Since Mirai's source code was published in 2016, dozens of derivative botnets have emerged, each iterating on the original with new propagation vectors, payload capabilities, and targeting. ADB exploitation — targeting the same port 5555 that xlabs_v1 uses — has been observed in Mirai variants since at least 2018, when ADB.Miner used ADB access to deploy cryptocurrency miners on Android TV devices.
xlabs_v1's distinguishing characteristics relative to commodity Mirai forks are its bandwidth profiling capability (enabling a market-rate pricing model) and its purpose-built RakNet flood module (optimized for the Minecraft ecosystem, where DDoS-for-hire services have a documented market). The combination of an IoT propagation vector with a specialized gaming-sector attack capability is a meaningful operational refinement, even if the underlying technology is derivative.
The exposed directory that led to xlabs_v1's discovery is a reminder that threat actors operating criminal infrastructure are not immune to operational security failures. Hunt.io's discovery was made through routine monitoring of bulletproof-hosting netblocks — not a targeted attack.
Conclusion
xlabs_v1 is an actively operating Mirai-based DDoS-for-hire botnet building its network by exploiting ADB-exposed IoT devices on port 5555. Network defenders should immediately verify that ADB is disabled on all managed IoT devices and that port 5555 is blocked at the network perimeter. The botnet's exposure by Hunt.io provides an opportunity to take defensive action before the operation scales further.
For any query contact us at contact@cipherssecurity.com
