Малварь RedHook получает root на Android без единого клика жертвы

RedHook не пробивает Android эксплойтом. Он ворует чужой инструмент – тот, которым легально пользуются тысячи Android-энтузиастов, чтобы получить расширенные права без рутинга телефона, – и разворачивает его против владельца устройства. Малварь сама тыкает семь раз по номеру сборки, сама включает Wireless-отладку, сама проходит спаривание и поднимает у себя shell-права уровня adbd. Ни одного диалога с запросом «разрешить?». По данным Group-IB, это первый зафиксированный случай, когда вредонос настолько автономно эксплуатирует Wireless ADB именно как канал повышения привилегий, а не как канал отладки.

Год назад это был рядовой вьетнамский банковский фишер. Сейчас – RAT с полным дистанционным управлением устройством, включая перепрошивку системных настроек без единого пользовательского клика. Инструмент, который RedHook берёт в оборот, – Shizuku, честный опенсорсный способ рулить системными настройками без рутинга, которым годами пользуется Android-комьюнити. Разница между Shizuku в руках владельца и в руках малвари – не в коде, а в том, кто именно нажимает на кнопки.

От фишинг-бота до RAT с root-правами

Cyble впервые описала RedHook в июле 2025-го как обычный для Юго-Восточной Азии банковский троян: фишинговые сайты во Вьетнаме, выдающие себя за банки и госструктуры, кейлоггинг, скриншоты через MediaProjection и WebSocket-канал на C2. 34 команды, приличная, но типовая для региона связка «фишинг + RAT». Инфраструктуру тогда спалил открытый AWS S3-бакет оператора – внутри лежали шаблоны фишинговых страниц и логи по 570 идентификаторам жертв.

Версия, которую год спустя разобрал Group-IB, – уже другой класс угрозы. Список команд вырос до 53, распространение расширилось с Вьетнама на Индонезию, а главное – в код добавили автономную эскалацию привилегий через Wireless ADB. Разница не количественная, а качественная: раньше RedHook воровал то, что видел на экране. Теперь он получает права уровня системного процесса и может делать с телефоном то, что раньше требовало физического USB-кабеля и включённой на телефоне отладки.

Фейковое министерство и разводка на Accessibility

Заражение по-прежнему держится на классике: звонки и сообщения в Zalo и WhatsApp от лица «господдержки» или банка, ссылка на сайт-клон Google Play, APK с хостингом на GitHub и в AWS S3 – для отказоустойчивости доставки, если один хост прикроют. Дальше начинается воронка, которую Group-IB зафиксировала в скриншотах самого приложения.

Диалог маскируется под официальную госуслугу, поддельное «системное уведомление» имитирует стандартный Android-запрос, а после согласия жертву за руку проводят по реальным настройкам: зайти в Accessibility, докрутить до нужного пункта, включить тумблер. Никакой эксплуатации самого Accessibility API здесь нет – это чистая социнженерия, обёрнутая в пошаговый гайд, каким обычно объясняют бабушке, как поставить будильник. Работает она ровно потому, что после многих лет предупреждений «не давай непонятным приложениям спецвозможности» жертву всё ещё можно довести до нужного тумблера, если водить её за руку достаточно убедительно.

Как телефон взламывает сам себя

Дальше начинается разбор, ради которого весь этот текст. Accessibility-права дают программе не системный доступ, а способность имитировать нажатия и читать дерево интерфейса – то есть ровно то, что нужно, чтобы вручную, но на скорости бота, пройти путь до Wireless-отладки:

1. семь тапов по номеру сборки       -> включаются Developer Options
2. Developer Options -> Wireless debugging
3. "Use Wireless debugging"          -> запускается adbd на 127.0.0.1
4. автоматический ввод pairing-кода  -> устройство "спарено" само с собой

С этого момента на устройстве работает демон отладки adbd, слушающий loopback-интерфейс, – обычно к нему обращается компьютер разработчика по кабелю. RedHook подключается к нему сам, с самого устройства, собственным встроенным ADB-клиентом:

Accessibility Service
  -> включает Wireless Debugging
    -> adbd слушает 127.0.0.1
      -> встроенный ADB-клиент RedHook подключается по loopback
        -> поднимает привилегированный сервер libmx.so (код на базе Shizuku)
          -> сервер наследует права adbd – shell, uid 2000
            -> вызывает системные API, недоступные обычному приложению

libmx.so – это не написанный с нуля инструмент, а код на основе Shizuku: опенсорсного фреймворка, которым легально пользуются тысячи Android-энтузиастов для управления системными настройками без рутинга. Идея Shizuku в том, что пользователь сам, осознанно, через ADB с компьютера или через Wireless-отладку поднимает привилегированный процесс и сам решает, каким приложениям доверять запросы к нему. RedHook выкидывает из этой схемы человека целиком – и запрашивающего, и разрешающего. Тумблер включает сам, спаривание проходит сам, привилегированный процесс поднимает сам, а вызовы к нему делает без единого диалога подтверждения.

С правами shell (uid 2000) – это выше обычного приложения, но ниже root – малварь получает доступ к системным API, которые проверяют не «рутован ли телефон», а «кто именно спрашивает», и честно пропускают ADB-shell как доверенную сторону. В их числе WRITE_SECURE_SETTINGS – разрешение, которым можно менять защищённые записи Settings.Secure, обычным приложениям недоступное в принципе.

53 команды и обход согласия на стрим экрана

С полученными правами RedHook переходит на связку WebSocket плюс REST: wss://sktv.3n7wj[.]com/ws/device держит канал управления, а отдельные REST-эндпоинты вида /member/info/addsKeyboardInput и /member/info/addMessage заливают на сервер кейлоги и переписку. Список из 53 команд закрывает практически весь жизненный цикл шпионажа за устройством: снять список контактов и приложений, поставить или удалить APK, заблокировать и разблокировать экран, перезагрузить устройство, выключить собственный Accessibility-сервис, чтобы не мозолить глаза в настройках, деинсталлировать вспомогательную библиотеку и замести следы.

Отдельно стоит команда фейкового окна верификации с одновременной активацией фронтальной камеры – классика для доверительных банковских сценариев, где жертву просят «подтвердить личность», пока незаметно снимают её лицо. Но самая показательная деталь – стриминг экрана. Обычный путь для такого требует MediaProjection и системного диалога согласия «приложение X будет видеть содержимое экрана» – тот самый диалог, который Android годами преподносит как последний рубеж приватности. При активном привилегированном сервере RedHook стримит экран через RTMP параллельно с обычным WebSocket-каналом, задействуя привилегированный захват – и этот путь обходится целиком, без единого запроса согласия.

Автоматизация через Accessibility работает не по стабильному API, а по дереву интерфейса конкретной прошивки – а Android только на бумаге один. У Samsung это One UI, у Xiaomi – MIUI или HyperOS, у Huawei – EMUI, у Oppo – ColorOS, у Vivo – Funtouch OS, у Meizu – Flyme, и в каждом скине «Для разработчиков» и «Отладка по Wi-Fi» лежат на разной глубине меню, под разными подписями, иногда с лишним подтверждающим экраном. Сценарий, рассчитанный на чистый Android, на части этого зоопарка просто промахнётся мимо нужного пункта. Group-IB нашла в APK готовые, но пока не вызываемые из основного потока брендоспецифичные ветки навигации под Google, Huawei, Meizu, Oppo, Samsung, Vivo и Xiaomi – отдельное дерево тапов под каждый скин. Не недоделанный код и не заглушка, а задел на расширение: сейчас в бою хватает универсального сценария под текущую кампанию, а ветки под конкретные прошивки ждут своего включения, когда оператор решит идти за аудиторией, на которой стоковый путь не сработает.

Живучесть: пиксель, тишина и автоматическое оживление после ребута

Получить привилегии – половина задачи; вторая – не потерять процесс, который Android агрессивно убивает вне фокуса. Персистентность RedHook – связка слоёв, где каждый подстраховывает предыдущий.

Базовый уровень: пока экран выключен, малварь держит невидимую activity в один пиксель и параллельно проигрывает беззвучный трек через MediaSession, чтобы система приняла процесс за медиаплеер и не трогала сборщиком фона. Поверх – WakeLock, не дающий CPU уснуть.

Дальше – взаимная защита: два сервиса биндятся друг на друга флагом BIND_AUTO_CREATE – убьют один, второй поднимет его обратно, без стороннего наблюдателя, которого можно прибить отдельно. Плюс будильник раз в пять минут, сверяющий статус обоих.

Переживает RedHook и перезагрузку: receiver на BOOT_COMPLETED поднимает приложение при старте и – ключевая деталь – заново проходит всю цепочку из предыдущего раздела, повторно включая Wireless ADB при каждой загрузке, не полагаясь на то, что тумблер остался включённым с прошлого раза.

Последний штрих – два параметра, недоступных без shell-прав: oom_score_adj в -1000 выводит процесс из-под удара low-memory killer'а, а mlock() прибивает страницы памяти к физическому RAM, не давая ядру выгрузить их в своп. Настройки системных демонов, которым падать нельзя, – RedHook получает их тем же захваченным shell.

Кто в итоге виноват – Android, Shizuku или сама модель доверия

Здесь нет уязвимости в привычном смысле – ни у Android, ни у Shizuku нет CVE, потому что оба работают строго по спецификации. Wireless ADB создавался для разработчика, который физически сидит рядом со своим телефоном и осознанно включает отладку. Accessibility Service создавался для людей с ограничениями, которым действительно нужно, чтобы программа нажимала кнопки за них. Shizuku создавался как честная альтернатива рутингу для тех, кто знает, что делает. Всё это работает ровно так, как спроектировано, – просто спроектировано было в расчёте на присутствие человека на каждом шаге принятия решения. RedHook показывает: если Accessibility-права можно выклянчить у жертвы один раз через фейковый диалог, дальше можно автоматизировать весь путь до shell-доступа без единого дополнительного согласия – потому что ни одна из систем на этом пути не проверяет, кто именно жмёт на кнопки: живой пользователь или скрипт от его имени.

Урок для тех, кто проектирует привилегированные интерфейсы «для своих» – будь то отладочный доступ, служебный API или внутренняя консоль: единственная точка человеческого решения в системе – это узкое место, которое стоит защищать не хуже пароля. Если её можно пройти автоматизацией интерфейса, а не подбором секрета, весь остальной периметр безопасности – уже не имеет значения.

Технический разбор – Group-IB, отчёт «RedHook Returns with a Dangerous Upgrade».