Mirai-Based xlabs_v1 Botnet Targets Android TV Boxes and IoT Devices for DDoS-for-Hire Attacks

Cybersecurity researchers at Hunt.io have exposed a new Mirai-derived botnet that self-identifies as xlabs_v1, targeting internet-exposed devices running Android Debug Bridge (ADB) to enlist them in a commercial DDoS-for-hire operation capable of generating sustained, high-volume attack traffic. The botnet's commercial architecture, evasion techniques, and bandwidth profiling logic make it significantly more relevant to enterprise security teams than its consumer device targeting might initially suggest.

The discovery was made after Hunt.io identified an exposed open directory on a Netherlands-hosted server requiring no authentication, revealing the botnet's tooling, payload list, pricing model, and operator identity in a single exposed directory.

ADB Exposure: Not Just a Consumer Problem

The botnet specifically targets Android devices running an exposed ADB service on TCP port 5555. ADB is a developer tool built into Android that allows direct command-line access to a device. When left enabled and exposed to the public internet, it provides an unauthenticated entry point that any attacker can exploit without credentials or prior knowledge of the target.

The enterprise exposure here is frequently underestimated. Consumer Android TV boxes and smart televisions are the obvious targets. However, in B2B and enterprise environments, the same category of vulnerability exists across a much wider and often unmanaged device landscape. Ruggedised Android tablets used in warehousing and logistics, point-of-sale terminals in retail and hospitality environments, patient-facing kiosks in healthcare facilities, and digital signage systems across corporate campuses all commonly run Android and are frequently configured with ADB enabled for remote troubleshooting by vendors or internal IT teams.

These devices typically sit outside the scope of formal endpoint management programmes. They are not covered by enterprise antivirus, not included in vulnerability scanning cycles, and not monitored by SOC tooling. They represent what security teams increasingly refer to as Shadow IoT: connected devices with real network access and real attack surface that exist below the visibility threshold of most enterprise security controls.

"The bot is statically-linked ARMv7, runs on stripped Android firmwares, and is delivered through ADB-shell pastes into /data/local/tmp. The operator's nine-variant payload list is tuned for Android TV boxes, set-top boxes, smart TVs, and IoT-grade ARM hardware that ships with ADB enabled." - Hunt.io Research, May 2026

Beyond Android devices, xlabs_v1 also supports multi-architecture builds covering ARM, MIPS, x86-64, and ARC, indicating the botnet is designed to target residential routers and a broad range of IoT hardware in parallel.

Bandwidth Profiling: DDoS with a Guaranteed SLA

What distinguishes xlabs_v1 from simple script-kiddie Mirai forks is not its attack volume. It is its commercial architecture, and specifically the bandwidth profiling routine that underpins its pricing model.

Upon infection, the bot opens 8,192 parallel TCP sockets to the geographically nearest Speedtest server, saturates them for 10 seconds, and reports the measured bandwidth back to the operator's panel. Each compromised device is then assigned to a pricing tier based on its upstream capacity.

For enterprise security professionals, this detail is the most significant technical signal in the entire disclosure. Most botnets operate on volume. They aggregate as many devices as possible and flood indiscriminately. xlabs_v1 operates differently. By profiling each device's bandwidth before assigning it to a tier, the operator can sell attack capacity with a degree of confidence about the throughput it will deliver. If the botnet operator knows they have a pool of devices capable of sustaining 500Gbps aggregate, they can sell a high-confidence attack against a specific target with a near-guaranteed outcome. This transforms a commodity DDoS service into something closer to a precision instrument, with measurable and predictable attack characteristics.

For GCC enterprises, this context matters significantly. The region has seen a substantial increase in DDoS volume over the past two years, with government entities, financial services platforms, and telecoms infrastructure all targeted. The commoditisation of high-confidence attack capacity through services like xlabs_v1 directly lowers the barrier for sustained, volumetric attacks against enterprise VPN gateways, SaaS entry points, and public-facing API infrastructure.

Protocol Evasion: Designed to Bypass Traditional IDS

xlabs_v1 supports 21 flood variants across TCP, UDP, and raw protocols. Two of these are particularly significant from an enterprise defence perspective: RakNet and OpenVPN-shaped UDP.

RakNet is a legitimate networking library used in gaming and real-time communication applications. OpenVPN-shaped UDP is traffic crafted to mimic the packet structure of legitimate encrypted VPN traffic. Traditional intrusion detection systems and network firewalls that inspect traffic for recognisable attack signatures or "junk" UDP patterns will not flag either of these. They look like legitimate, low-latency business traffic or encrypted communications. The result is that enterprises relying on signature-based network monitoring for DDoS detection may have no visibility into an xlabs_v1 attack until it has already begun affecting service availability.

Memory-Only Execution: Invisible to Endpoint Antivirus

A critical operational characteristic of xlabs_v1 that enterprise security teams must understand is its deliberate absence of persistence. The botnet does not write itself to disk persistence locations, does not modify init scripts, does not create systemd units, and does not register cron jobs.

This is not a limitation. It is a design decision, and it has a direct security implication: standard disk-based antivirus and endpoint detection tools will never find it. Because the malware executes entirely in memory and exits after completing its profiling or attack task, traditional endpoint scanning produces no findings. The device appears clean. There is no artefact to detect, no file to quarantine, and no registry entry to flag.

The only reliable detection and response strategy for memory-only threats of this type is network-level monitoring, behavioural anomaly detection, and active audit of ADB exposure across the device estate.

The Killer Subsystem as a Detection Opportunity

xlabs_v1 includes a killer subsystem designed to terminate competing malware processes on infected devices, allowing it to claim the victim device's full upstream bandwidth for its own operations.

For SOC analysts, this creates an unexpected but useful detection signal. If network monitoring or endpoint tooling has been passively observing background noise from a device, such as low-level cryptocurrency mining activity or periodic beaconing from a previously identified but tolerated infection, a sudden and unexplained cessation of that activity could indicate that a more aggressive botnet has displaced the prior malware. The absence of known noise, in other words, may be a positive indicator of compromise rather than a sign that the threat has resolved itself.

The Jenkins Connection: Misconfigured DevOps as the New Perimeter

Threat researchers at Darktrace separately identified that an intentionally misconfigured Jenkins CI/CD instance in their honeypot network was targeted by unknown threat actors to deploy a DDoS botnet downloaded from a remote server. The incident illustrates a shift in how attackers view exposed build infrastructure: not primarily as a source of source code or credentials, but as a resource hijacking opportunity. Enterprise CI/CD systems typically run on high-bandwidth, high-uptime servers with clean IP reputations. From an attacker's perspective, a compromised Jenkins instance is not a data exfiltration target. It is a high-capacity, trusted outbound pipe that can be weaponised to amplify attack throughput while attribution points away from the actual operator.

For organisations running Jenkins, GitHub Actions, or other CI/CD tooling with internet-facing interfaces, this reinforces that build infrastructure must be included in external attack surface assessments and not treated as an internal-only concern.

What Enterprise Security Teams Must Do Now

The enterprise action items are specific and immediate. Security and network teams should audit all environments for Android-based devices with ADB enabled, including ruggedised tablets, PoS terminals, kiosk systems, and digital signage, regardless of whether those devices are managed under standard endpoint programmes. ADB should be disabled on all production and corporate devices where it is not operationally required, and vendor remote troubleshooting workflows that rely on ADB should be reviewed and replaced with managed remote access alternatives.

Network monitoring should be configured to detect high-volume outbound connections consistent with bandwidth probing, specifically the pattern of thousands of parallel TCP connections to external endpoints from a single device in a short window. Behavioural anomaly detection covering IoT and unmanaged device segments is the most reliable control against memory-only threats that will not be caught by disk-based endpoint tools.

For GCC enterprise security leaders, the broader message from this disclosure is that the attack surface represented by Shadow IoT sits largely outside the controls that most security programmes were designed to cover. Closing that gap requires extending asset discovery, network monitoring, and access governance to every connected device, not only those managed by IT.