Открытый ADB по-прежнему ведет в botnet — а выгода в gaming
Новый Mirai-derived botnet под названием xlabs_v1 атакует устройства, у которых Android Debug Bridge (ADB) открыт в internet. Исследователи описывают его как специализированную DDoS-инфраструктуру, нацеленную на game servers и Minecraft hosting. Набор функций указывает, что оператор пытается продавать атаки “as service”, а не просто проводить разовые disruptions.
Источник: https://thehackernews.com/2026/05/mirai-based-xlabsv1-botnet-exploits-adb.html
Что, по словам исследователей, они нашли#
Hunt.io сообщает, что обнаружила открытый каталог на сервере в Нидерландах по адресу 176.65.139[.]44, доступный без authentication. По этому каталогу и связанным artifacts исследователи связали активность с xlabs_v1 — botnet, который сам идентифицирует себя этим именем и, судя по всему, создан для DDoS по запросу.
Базовая модель botnet знакома: скомпрометировать доступные из internet устройства, включить их в удаленно управляемый fleet, а затем использовать этот fleet для генерации traffic floods по команде.
Здесь выделяются initial access path и детали productization, описанные в отчете:
- botnet атакует устройства, где ADB открыт на TCP port 5555.
- В него входит Android APK, обозначенный как “boot.apk”.
- Он также поддерживает multi-architecture builds, включая ARM, MIPS, x86-64 и ARC, что указывает на интерес не только к Android phones, но и к routers и другому IoT hardware.
Hunt.io характеризует его как botnet с 21 flood variant для TCP, UDP и raw protocols, включая RakNet и OpenVPN-shaped UDP. Утверждается, что это помогает обходить DDoS-защиту “consumer-grade” уровня.
Как, судя по всему, работает xlabs_v1#
Target set: устройства с ADB-on-by-default#
Botnet ищет Android-устройства, у которых ADB доступен из public internet. Это важно, потому что ADB exposure — не только ошибка developer на отдельном handset. Некоторые consumer devices могут поставляться с доступным ADB так, что владельцы этого никогда не замечают.
Hunt.io отмечает, что практический target pool может включать:
- Android TV boxes
- set-top boxes
- smart TVs
- другие IoT-grade Android devices
Если ADB открыт, устройство становится кандидатом для remote command execution и доставки payload.
Delivery и control#
По данным Hunt.io, bot доставляется через ADB shell commands, которые помещают payload в /data/local/tmp. В анализе также описан statically linked ARMv7 bot, способный работать на урезанных Android firmwares.
После enroll устройства bot, как сообщается, получает команды с operator panel на xlabslover[.]lol и может генерировать DDoS traffic по указанию — особенно traffic, адаптированный для disruption game servers.
“Commercial” feature: bandwidth profiling#
Одна из самых интересных с операционной точки зрения деталей отчета — bandwidth-profiling routine, которая выглядит как механизм для tiered pricing.
По оценке Hunt.io, xlabs_v1:
- собирает victim bandwidth и geolocation
- открывает 8 192 parallel TCP sockets к географически ближайшему Speedtest server
- насыщает канал в течение 10 seconds
- отправляет измеренный transfer rate обратно на panel
Заявленная цель — распределять скомпрометированные devices по bandwidth tiers, чтобы customers платили за более мощных bots.
Это хороший пример того, как “DDoS-for-hire” выглядит на engineering level: не только attack methods, но и fleet management с monetization logic.
Нет persistence и странный lifecycle#
Hunt.io утверждает, что xlabs_v1 не реализует persistence. В отчете говорится, что он не записывает себя в типичные persistence locations, не изменяет init scripts и не создает распространенные Linux persistence mechanisms, например systemd units или cron jobs.
Есть и конкретное поведенческое утверждение: bot завершает работу после отправки bandwidth information в Mbps. Если это верно, оператору придется повторно заражать устройство, чтобы снова использовать его для атак, через ту же ADB exposure.
Hunt.io интерпретирует это как design intent: bandwidth probing может быть периодическим этапом обновления fleet tiers, а не процедурой перед каждой атакой.
Это ключевой момент, который важно держать в контексте: отсутствие persistence не означает “низкий риск”. Оно все равно может означать повторяющуюся компрометацию, если базовая exposure сохраняется.
“Killer” subsystem#
В анализе также описана функция “killer”, предназначенная для завершения competing malware на victim device. Мотивация очевидна: вернуть CPU и, что еще важнее для DDoS, вернуть upstream bandwidth.
Attribution и infrastructure: что неизвестно#
Hunt.io говорит, что неизвестно, кто стоит за xlabs_v1. Threat actor описан как использующий moniker “Tadashi” — на основе ChaCha20-encrypted string, встроенной в каждый build.
Исследователи также упоминают co-located infrastructure, где был VLTRig Monero-mining toolkit на 176.65.139[.]42. Они прямо отмечают, что неизвестно, управляется ли эта mining activity тем же оператором.
Практический takeaway#
Главный вывод для defenders простой: ADB не должен быть доступен из internet. Если TCP 5555 открыт наружу, устройство нужно считать кандидатом на компрометацию, даже если на нем нет очевидных признаков persistence.
Что стоит сделать:
- Просканировать external perimeter на открытый TCP/5555 и закрыть доступ с internet.
- Проверить Android TV boxes, set-top boxes, smart TVs и другие Android-based IoT devices, особенно если они подключены напрямую к public IP или проброшены через router.
- Отключить ADB там, где он не нужен; если нужен — ограничить доступ VPN, management VLAN или allowlist.
- Проверить устройства на подозрительные payloads в
/data/local/tmpи неизвестные APK вродеboot.apk. - Мониторить исходящие соединения к необычным domains и panels, включая xlabslover[.]lol, а также резкие outbound bandwidth spikes.
- Для gaming и hosting providers: отдельно учитывать UDP/TCP flood patterns, связанные с game protocols, включая RakNet-like traffic.
Даже если xlabs_v1 действительно не закрепляется на устройстве, устранение root cause остается тем же: убрать ADB exposure. Иначе устройство может заражаться повторно и снова попадать в DDoS fleet.