New xlabs_v1 Botnet Targets Minecraft Servers via ADB-Exposed Android Devices
Key Takeaways A new botnet, xlabs_v1, is actively exploiting Android devices with exposed Android Debug Bridge (ADB) ports. The botnet is a variant of the Mirai malware, repurposed for DDoS-for-hire...
Key Takeaways
- A new botnet, xlabs_v1, is actively exploiting Android devices with exposed Android Debug Bridge (ADB) ports.
- The botnet is a variant of the Mirai malware, repurposed for DDoS-for-hire services, specifically targeting Minecraft game servers.
- Infected devices include Android TV boxes, smart TVs, routers, and other IoT hardware with ADB enabled by default.
- The botnet employs stealthy infection mechanisms, including process masquerading and firewall evasion, making detection challenging without dedicated security measures.
- Disabling ADB on internet-facing devices and blocking known C2 communication are critical mitigation steps.
New xlabs_v1 Botnet Leverages Exposed ADB to Hammer Minecraft Servers
A sophisticated new botnet, dubbed xlabs_v1, has emerged, actively exploiting Android devices with publicly exposed Android Debug Bridge (ADB) ports to launch distributed denial-of-service (DDoS) attacks, primarily against Minecraft game servers. The malicious operation leverages a modified version of the notorious Mirai malware, offering its DDoS capabilities as a paid service.
Table Of Content
Botnet Mechanics and Targets
The xlabs_v1 botnet specifically seeks out any internet-accessible device listening on TCP port 5555, the default for ADB. This encompasses a wide array of hardware, including Android-based smart TVs, set-top boxes, residential routers, and various Internet of Things (IoT) devices that often ship with ADB functionality enabled by default.
Upon successful exploitation through an open ADB port, the botnet quietly installs its binary into the device’s /data/local/tmp/ directory. Once executed, the compromised device becomes part of a growing network of bots available for hire, used to flood target game servers with traffic and force them offline. A key indicator of its focus on gaming infrastructure is a specialized RakNet flood variant designed to attack Minecraft servers. Furthermore, the bot binary itself is distributed over TCP port 25565, which is the standard port for Minecraft servers, a tactical choice by the attackers.
Discovery and Attribution
Security researchers at Hunt.io uncovered the xlabs_v1 operation in early April 2026 during routine surveillance of bulletproof hosting network blocks. Their proprietary tool, AttackCapture, flagged an unauthenticated, exposed directory on a server located in the Netherlands at the IP address 176.65.139[.]44. This open directory contained the complete toolkit for the botnet, including two ELF binaries, various infection payloads, proxy credentials, and a target placeholder, providing analysts with a comprehensive view of the entire operation.
By comparing a production ARM32 binary with an unstripped development build, analysts were able to extract crucial details such as the Command and Control (C2) domain, the operator’s handle, and the authentication token. The individual behind xlabs_v1 operates under the alias “Tadashi,” a moniker encrypted within every bot build.
The entire illicit infrastructure, including the C2 server, staging host, and distribution mechanisms, is hosted within a single bulletproof /24 netblock managed by Offshore LC (AS214472) in the Netherlands.
Researchers also noted a co-located Monero cryptomining campaign utilizing the VLTRig toolkit on the same netblock. However, it remains unconfirmed whether this cryptomining activity is linked to the same operator based solely on the captured files.
Inside the Infection Mechanism
The xlabs_v1 bot employs several sophisticated techniques to maintain persistence and evade detection on compromised devices.
- Signal Blocking and Argument Zeroing: Upon execution, the bot immediately blocks the SIGINT signal to prevent interruption. It then captures an infection-vector tag from its startup arguments and promptly zeroes out those arguments, making them invisible in standard process listings.
- Encrypted String Table: Critical operational data, including the C2 domain, operator handle, and authentication token, is stored within an internal string table encrypted using ChaCha20. This encryption layer further complicates analysis and detection.
- Process Masquerading: Following decryption, the bot overwrites its process name with
/bin/bashusing a system call. This tactic makes the malicious process appear as a legitimate shell process to system administrators conducting routine checks, helping it blend in with normal system activity. - Daemonization: The bot then detaches itself from the terminal session and closes all standard input and output handles, allowing it to run silently in the background as a daemon. While these steps make manual detection difficult, dedicated security software can still identify the infection.
The bot establishes communication with its C2 server at xlabslover[.]lol over TCP port 35342. It sends a registration message containing the device’s hostname, CPU count, RAM size, and a unique per-build authentication token. Should the initial outbound connection fail, the bot activates a fallback listener on TCP port 26721, aggressively punching through firewalls using five different iptables paths to ensure a persistent re-entry channel for the operator.
Before initiating C2 communications, xlabs_v1 actively scans for and terminates any competing malware processes, including a hard-coded rival bot operating on TCP port 24936. Additionally, a bandwidth-profiling routine is executed, opening 8,192 parallel sockets to the nearest Speedtest server to measure the upstream capacity of the infected device. This data likely allows the operator to categorize and price compromised devices for DDoS-for-hire customers based on their available bandwidth.
What You Should Do
- Disable ADB: Immediately disable ADB on all Android and IoT devices that are exposed to the internet. ADB is a powerful debugging tool and should never be left open on production or internet-facing systems.
- Block Outbound Connections: Configure firewalls to block outbound connections to TCP port 35342, the primary C2 communication port for xlabs_v1.
- Monitor for Anomalous Processes: Implement monitoring for
/bin/bashprocesses running without a controlling terminal, as this is a key stealth technique used by the bot. - Check for Malicious Files: Regularly scan for and remove suspicious files located in the
/data/local/tmp/arm7directory. - Traffic Monitoring: Treat any outbound traffic to xlabslover[.]lol or pool[.]hashvault[.]pro as a strong indicator of an active xlabs_v1 infection or related malicious activity.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.