Mirai-Derived xlabs_v1 Botnet: Exploiting Exposed ADB on IoT for DDoS

Introduction

Security researchers at Hunt.io have uncovered a new Mirai-derived botnet, self-identifying as xlabs_v1, actively targeting internet-exposed IoT devices. This campaign specifically exploits the Android Debug Bridge (ADB) interface—a debugging protocol often left enabled and exposed on Android-based set-top boxes, smart displays, and other connected hardware. Once compromised, these devices are corralled into a botnet capable of launching high-volume Distributed Denial-of-Service (DDoS) attacks.

Defenders need to act immediately: the discovery was made after researchers identified an exposed command-and-control (C2) directory hosted in the Netherlands, suggesting active infrastructure and ongoing recruitment of victims.

Technical Analysis

Threat Actor/Variant: xlabs_v1 (Mirai-based malware).

Affected Products & Platforms:

• Android-based IoT devices (Set-top boxes, smart TVs, media hubs).
• Any device running Android with ADB enabled and exposed to the internet.

Vulnerability/Vector: This is not a software vulnerability in the traditional sense (CVE), but a critical security misconfiguration. The attack vector relies on ADB (TCP port 5555) being accessible from the internet. Many IoT manufacturers ship devices with ADB enabled for remote troubleshooting, often without requiring authentication by default or encouraging users to disable it post-deployment.

Attack Chain:

1. Reconnaissance: The botnet scans the internet for TCP port 5555 (ADB).
2. Exploitation: Upon finding an open port, the malware establishes a connection. Because ADB often allows shell access without strict authentication on exposed interfaces, the attacker gains the ability to execute commands.
3. Payload Delivery: The xlabs_v1 binary is downloaded and executed on the device, typically written to a temporary directory (e.g., /data/local/tmp or /dev).
4. Persistence & C2: The binary connects to the C2 server (tracked to a Netherlands host) to await DDoS commands (TCP/UDP floods).

Exploitation Status: Confirmed Active. Hunt.io observed active scanning and successful C2 communication, indicating this is not a theoretical Proof-of-Concept (PoC) but a live campaign.

Detection & Response

SIGMA Rules

The following Sigma rules detect network exposure of the ADB port and suspicious process execution patterns typical of Mirai variants on Linux/Android endpoints.

---
title: Potential ADB Exposure on IoT Device
id: a8b4c1d2-3e4f-5a6b-7c8d-9e0f1a2b3c4d
status: experimental
description: Detects network connections listening on the Android Debug Bridge (ADB) port 5555, which indicates potential exposure to the internet.
references:
  - https://thehackernews.com/2026/05/mirai-based-xlabsv1-botnet-exploits-adb.html
author: Security Arsenal
date: 2026/05/12
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort: 5555
    State: 'LISTEN'
  condition: selection
falsepositives:
  - Legitimate developer debugging on a local subnet (filter by SourceIP/Subnet)
level: high
---
title: Mirai Botnet Execution from Temporary Directory
id: b9c5d2e3-4f5g-6b7c-8d9e-0f1a2b3c4d5e
status: experimental
description: Detects execution of binaries from common Android temporary directories, a behavior consistent with Mirai/xlabs_v1 payload execution.
references:
  - https://thehackernews.com/2026/05/mirai-based-xlabsv1-botnet-exploits-adb.html
author: Security Arsenal
date: 2026/05/12
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|contains:
      - '/data/local/tmp/'
      - '/dev/'
      - '/tmp/'
    CommandLine|contains:
      - './'
  condition: selection
falsepositives:
  - Legitimate administrative script execution (rare on standard IoT)
level: critical

KQL (Microsoft Sentinel)

These queries hunt for devices listening on the ADB port or exhibiting Mirai-like process behavior. Note: IoT logs are often ingested via Syslog or Common Event Format (CEF).

// Hunt for ADB Port Exposure (Syslog/CEF)
// Look for devices listening on TCP 5555
Syslog
| where SyslogMessage has "LISTEN"
| extend Port = extract("(\d+)\s*$", 1, SyslogMessage)
| where Port == "5555"
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| summarize count() by Computer, bin(TimeGenerated, 5m)

// Hunt for Suspicious Process Execution (DeviceProcessEvents - if using Defender for IoT)
DeviceProcessEvents 
| where FolderPath has_any ("/data/local/tmp", "/dev", "/tmp") 
| where FileName endswith ".sh" or FileName endswith ".bin" or FileName endswith ".mips"
| where ProcessCommandLine contains "./"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName

Velociraptor VQL

Use this VQL artifact to hunt for active ADB listeners and suspicious binaries on potentially compromised Linux/Android endpoints.

-- Hunt for ADB Listening on Port 5555
SELECT ListenAddress, Port, PID, Family, Protocol
FROM listen_ports()
WHERE Port = 5555

-- Hunt for Mirai-style binaries in temp directories
SELECT Name, Pid, Exe, CommandLine, Ctime
FROM pslist()
WHERE Exe =~ '/data/local/tmp' OR Exe =~ '/dev/shm'
   OR Name =~ 'mirai' OR Name =~ 'xlabs'

Remediation Script (Bash)

Run this script on Linux-based IoT devices to disable ADB and block the external vector immediately. Note: Specific commands may vary by Android vendor/distro.

#!/bin/bash
# Remediation script to disable ADB and block external access

# 1. Stop the ADB server
setprop service.adb.tcp.port 0
stop adbd

# 2. Use iptables to drop traffic on TCP 5555 (ADB)
# Requires root privileges
iptables -A INPUT -p tcp --dport 5555 -j DROP
iptables -A OUTPUT -p tcp --dport 5555 -j DROP

# 3. Persist iptables rules (distro dependent, example for common Debian-based IoT)
# Note: Verify 'iptables-save' path and persistence method for your specific firmware
/sbin/iptables-save > /etc/iptables/rules.v4

echo "[$(date)] ADB Disabled and Port 5555 Firewalled." >> /var/log/security_hardening.log

Remediation

1. Disable ADB Immediately: Ensure ADB is turned off on all production IoT devices. This is usually found under "Developer Options" in device settings or disabled via the setprop command as shown in the script above.
2. Network Segmentation: Place IoT devices on an isolated VLAN. They should not have direct internet access required only for their specific functions, and certainly not exposure of debugging ports to the WAN.
3. Firewall Configuration: Block TCP port 5555 at the network perimeter (edge firewall) and on the device itself (via iptables/nftables).
4. Firmware Updates: Check with your device vendor for firmware updates that disable ADB by default or enforce authentication on ADB connections.
5. Credential Reset: If a device was compromised, perform a factory reset to remove any persistent malware (which often modifies /etc/init.d/ or creates cron jobs) before changing default credentials.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub