Mirai Variant xlabs_v1 Targets Exposed ADB Interfaces
Just came across the Hunt.io report on a new Mirai-based botnet, xlabs_v1. It seems the attackers are shifting focus back to Android Debug Bridge (ADB) interfaces left exposed on IoT devices. Unlike standard Mirai variants that brute-force Telnet/SSH, this one specifically looks for port 5555 open on Android-based hardware (set-top boxes, smart displays, etc.).
The researchers found the botnet's source sitting in an exposed directory on a Netherlands-based server. What stands out is how the malware self-identifies as xlabs_v1 during its communication handshake. While this might look sloppy, it actually helps us on the Blue Team side for fingerprinting once the traffic is captured.
For those managing IoT fleets, ADB should never be internet-facing. If you need to audit your perimeter quickly, you can use masscan or nmap to check for open 5555 ports:
nmap -p 5555 --open -oG -
If you find hits, validate immediately. You can usually kill the ADB daemon remotely if you have SSH access, or restrict it via iptables:
iptables -A INPUT -p tcp --dport 5555 -s -j ACCEPT
iptables -A INPUT -p tcp --dport 5555 -j DROP
Given the automated nature of these scans, misconfigured devices are usually compromised within minutes of being exposed. Has anyone started seeing specific indicators of compromise (IOCs) related to xlabs_v1 in their honeypots yet?
We actually caught this hitting our honeypot yesterday. The xlabs_v1 string is very prominent in the payload. If you are using Zeek or Suricata, this signature is trivial to catch. I threw together a quick Suricata rule to drop traffic containing the specific handshake:
alert tcp any any -> any 5555 (msg:"ET MALWARE xlabs_v1 Botnet Handshake"; content:"xlabs_v1"; flow:to_server,established; sid:2026001; rev:1;)
It's basic, but effective against this specific variant until they obfuscate the user-agent string.
It is crazy how many vendors ship devices with ADB enabled by default on the WAN interface. I do a lot of pentesting on smart building systems, and finding port 5555 open is still a 'critical' finding I report constantly.
If you are running Shodan dorks to check your infrastructure, look for:
port:5555 "Device"
Usually, these devices don't have authentication set for ADB, allowing immediate root access. Firewalling is good, but disabling the service entirely on production endpoints is the only real fix.
Great catch, Diana. For defenders without a full IDS stack, a simple Nmap scan of your subnet can identify these exposed interfaces quickly. I use this one-liner to flag potential targets before the botnet does:
nmap -p 5555 --open 192.168.1.0/24
It's alarming how often this comes back positive on older Android TV sticks. Remediation usually involves a firmware update that actually closes the port, but firewall blocking is the immediate stopgap.
Valid point on the scanning, Katie. However, detection is only half the battle. If firmware updates aren't viable for legacy hardware, a quick host-based firewall rule can buy you time. For Linux-based IoT, you can drop the traffic directly:
iptables -A INPUT -p tcp --dport 5555 -j DROP
Just ensure you persist the rules or use a startup script, as reboots will wipe the configuration.
Solid advice on prevention. For those already compromised, IR is time-sensitive since ADB gives root access. Check for persistence mechanisms immediately, often hidden in cron or recent binary drops in writable directories.
find /tmp /var -name "*" -perm 111 -mmin -60
ls -l /etc/cron* /var/spool/cron/
Also, review network connections for established shells to unknown IPs. The xlabs_v1 payload is distinct, so carving binaries from memory might be necessary if the disk is wiped.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access