Exposed ADB is still a botnet on-ramp — and gaming is the payoff

A new Mirai-derived botnet dubbed xlabs_v1 is targeting devices that expose Android Debug Bridge (ADB) to the internet. Researchers describe it as purpose-built DDoS infrastructure aimed at game servers and Minecraft hosting, with a feature set that suggests an operator trying to sell attacks “as a service,” not just run one-off disruption.

Source: https://thehackernews.com/2026/05/mirai-based-xlabsv1-botnet-exploits-adb.html

What researchers say they found#

Hunt.io reports it identified an exposed directory on a Netherlands-hosted server at 176.65.139[.]44 that was accessible without authentication. From that directory and related artifacts, the researchers tied activity to xlabs_v1, a botnet that self-identifies with that name and appears designed for on-demand DDoS.

The botnet’s core model is familiar: compromise internet-exposed devices, enroll them into a remotely controlled fleet, then use that fleet to generate traffic floods on command.

What stands out here is the initial access path and the productization details described in the write-up:

• The botnet targets devices running ADB exposed on TCP port 5555.
• It includes an Android APK referred to as “boot.apk”.
• It also supports multi-architecture builds (including ARM, MIPS, x86-64, and ARC), which suggests interest beyond Android phones—into routers and other IoT hardware.

Hunt.io characterizes it as having 21 flood variants across TCP, UDP, and raw protocols, including RakNet and OpenVPN-shaped UDP, with the claim that this helps bypass “consumer-grade” DDoS defenses.

How xlabs_v1 appears to operate#

Target set: ADB-on-by-default devices#

The botnet seeks out Android devices where ADB is reachable from the public internet. That matters because ADB exposure is not just a developer mistake on a single handset. Some consumer gear can ship with ADB available in ways owners never notice.

Hunt.io notes that the practical target pool can include:

• Android TV boxes
• set-top boxes
• smart TVs
• other IoT-grade Android devices

If ADB is exposed, the device becomes a candidate for remote command execution and payload delivery.

Delivery and control#

Per Hunt.io, the bot is delivered through ADB shell commands that paste the payload into /data/local/tmp. The analysis also describes a statically linked ARMv7 bot that can run on stripped Android firmwares.

Once a device is enrolled, it reportedly takes commands from an operator panel at xlabslover[.]lol and can generate DDoS traffic when instructed—especially traffic tailored for game-server disruption.

A “commercial” feature: bandwidth profiling#

One of the more operationally interesting details in the report is a bandwidth-profiling routine that looks like it is meant to support tiered pricing.

Hunt.io’s assessment is that xlabs_v1:

• collects victim bandwidth and geolocation
• opens 8,192 parallel TCP sockets to the geographically nearest Speedtest server
• saturates for 10 seconds
• reports the measured transfer rate back to the panel

The stated goal is to bucket compromised devices into bandwidth tiers, so customers pay for more capable bots.

This is a good example of what “DDoS-for-hire” looks like at the engineering level: not just attack methods, but fleet management and monetization logic.

No persistence (and an odd lifecycle)#

Hunt.io says xlabs_v1 does not implement persistence. The report states it does not write itself into common persistence locations and does not modify init scripts or create common Linux persistence mechanisms (e.g., systemd units or cron jobs).

There is also a specific behavioral claim: the bot exits after sending bandwidth information (reported in Mbps). If accurate, that implies the operator would need to re-infect the device to use it again for attacks, through the same ADB exposure.

Hunt.io interprets this as design intent: bandwidth probing might be a periodic fleet-tier update step rather than something done before every attack.

This is a key point to keep in perspective: lack of persistence does not mean “low risk.” It can still mean repeated compromise if the underlying exposure remains.

A “killer” subsystem#

The analysis also describes a “killer” feature intended to terminate competing malware on the victim device. The incentive is straightforward: reclaim CPU and, more importantly for DDoS, reclaim upstream bandwidth.

Attribution and infrastructure: what’s unknown#

Hunt.io says it’s not known who is behind xlabs_v1. The threat actor is described as using the moniker “Tadashi”, based on a ChaCha20-encrypted string embedded in every build.

The researchers also mention co-located infrastructure that included a VLTRig Monero-mining toolkit on 176.65.139[.]42. They explicitly note it is not known whether that mining activity is operated by the same actor.

In other words: there are hints, but no firm attribution is presented in the source material.

Why this matters (even if you don’t run a “big” network)#

Two separate audiences should care here.

If you operate game servers or gaming infrastructure#

The botnet is described as tuned for disrupting game services. The flood variants called out (including RakNet) align with attacks that try to degrade real-time services where latency and packet loss matter.

Even “mid-tier” DDoS-for-hire offerings can create real downtime for small operators, especially if defenses are limited to basic upstream filtering or consumer-grade mitigation.

If you deploy or manage Android-based devices in the field#

This is another reminder that internet-exposed management services on embedded devices are still a recurring infection path.

ADB in particular sits in an awkward zone: it’s a legitimate tool, often overlooked in inventories, and can be exposed by default or by accident. Once it’s reachable from the internet, you should treat it as a remote management interface that can be abused.

The presence of multi-architecture payloads in the reporting also underscores a broader operational point: attackers do not need a single “perfect” exploit when the device ecosystem is messy. They can simply harvest whatever is already exposed.

What not to overclaim from this report#

The source material supports a concrete operational story, but it also leaves gaps that readers should keep intact:

• Public evidence of active exploitation at scale is not established here; the report describes discovery and capabilities, not a complete victim census.
• The relationship between the DDoS botnet and the co-located Monero-mining toolkit is not confirmed.
• The write-up does not claim a specific vendor list, model list, or a precise “default ADB exposure rate.”

It’s still worth acting on because the defensive steps are low-regret: don’t leave ADB reachable from the internet.

Practical checks and mitigations#

If you manage Android TV boxes, set-top boxes, smart TVs, routers, or other embedded devices, focus on reducing the chance that ADB is reachable from untrusted networks.

🛠️ Quick actions to consider:

• Audit exposure: Scan your public IP ranges for TCP/5555 and investigate anything that responds.
• Remove internet reachability: Ensure ADB is not exposed beyond a trusted management network; block inbound access at edge firewalls.
• Inventory “quiet” devices: Include TVs, media boxes, signage, and consumer IoT in asset inventories; these are often unmanaged but internet-connected.
• Segment networks: Keep embedded/consumer-like devices off the same network paths as production services.
• For game operators: Assume you may face tailored DoS; validate upstream DDoS mitigation posture and runbooks, not just application-level hardening.

Related signal: attackers keep aiming at DDoS deployment paths#

The source also references separate reporting from Darktrace: an intentionally misconfigured Jenkins instance in a honeypot was targeted to deploy a DDoS botnet from 103.177.110[.]202, with steps taken to evade detection. The common thread is not a single malware family; it’s the consistent attacker interest in finding exposed management surfaces that can quickly turn into DDoS capacity.

That trend is the practical takeaway: if a device or service is reachable and under-managed, it can become somebody else’s traffic generator.