RedHook: новый виток Android-трояна с автономным получением shell-привилегий через ADB

remote access Trojan

Исследователи Group-IB зафиксировали возвращение Android-трояна удалённого доступа RedHook, который претерпел значительные изменения по сравнению с версией, описанной Cyble в июле 2025 года. Главное новшество - автоматическое получение shell-доступа через сервис ADB Wireless Debugging (беспроводной отладчик для разработчиков Android) без участия физического компьютера. Злоумышленники расширили географию атак за пределы Вьетнама: под удар попали пользователи в Индонезии. Вредонос распространяется через поддельные сайты госорганов и финансовых организаций, а сами APK-файлы размещаются на доверенных облачных платформах - Amazon S3 и GitHub. Текущая версия RedHook поддерживает 53 серверные команды и использует многоуровневую систему закрепления в системе.

Описание

Вектор распространения остаётся классическим для Android-угроз: социальная инженерия. Злоумышленники звонят или пишут в мессенджеры от имени сотрудников поддержки, убеждая жертву установить поддельное приложение. Сайты-приманки имитируют Google Play Store. После установки приложение запрашивает доступ к Сервису специальных возможностей (Accessibility Service), прикрываясь необходимостью для полноценной работы. Настоящая цель - перехват управления. Вредонос собирает логины, пароли, коды подтверждения, SMS, данные экрана и клавиатурный ввод.

Наибольший интерес представляет техника повышения привилегий. RedHook впервые использует штатный инструмент Android Debug Bridge (ADB, отладочный мост Android) для автономного получения прав оболочки с идентификатором uid 2000. Обычно ADB требует подключения к компьютеру через USB или Wi-Fi. Злоумышленники применили метод, известный по легитимной утилите Shizuku: выполнение ADB-клиента прямо на устройстве через loopback-интерфейс (локальный адрес 127.0.0.1). Для этого вредонос сначала через Сервис специальных возможностей автоматически включает режим разработчика и беспроводную отладку - имитирует семь нажатий на номер сборки в настройках, активирует пункт "Беспроводная отладка" и считывает код сопряжения. Весь процесс происходит в фоне, жертва видит лишь полноэкранную заглушку.

Далее RedHook запускает собственный ADB-клиент, подключается к локальному демону и порождает процесс "libmx.so" с правами uid 2000. Этот сервер, основанный на коде Shizuku, через механизм Binder IPC (межпроцессное взаимодействие в Android) предоставляет вредоносу возможность выполнять системные API, обычно доступные только разработчикам. В частности, RedHook может без запроса выдавать себе любые разрешения (runtime permissions), включая WRITE_SECURE_SETTINGS (запись защищённых настроек), а также выполнять произвольные shell-команды и захватывать сенсорные события низкого уровня. В коде также обнаружены OEM-специфичные процедуры для включения беспроводной отладки на устройствах Google, Huawei, Meizu, Oppo, Samsung, Vivo и Xiaomi - пока они не задействованы, но могут быть активированы в будущих версиях.

Предоставленный анализ Group-IB показывает, что команда управления RedHook насчитывает более полусотни инструкций. Среди них - перехват экрана (как через штатный MediaProjection с согласием пользователя, так и через shell-привилегии с обходом диалога), запись нажатий клавиш, получение контактов и SMS, установка и удаление приложений, эмуляция жестов (смахивание, долгое нажатие, перетаскивание), блокировка/разблокировка экрана, запуск камеры, перезагрузка устройства и поддельные окна верификации (в том числе с захватом лица через фронтальную камеру). Для передачи данных используются WebSocket (команды и скринкастинг) и REST API (учётные данные, скриншоты, журналы клавиатуры, SMS). Командные серверы принимают логины и пароли, устройства, пароли и коды подтверждения.

Особое внимание разработчики RedHook уделили закреплению в системе (persistence). Вредонос использует несколько техник одновременно. Запускает невидимую активность размером 1×1 пиксель - это заставляет систему считать процесс приоритетным, защищая от выгрузки. Воспроизводит тихий аудиосигнал через MediaSession, что дополнительно повышает приоритет. Удерживает WakeLock (блокировку сна процессора) в фоновом сервисе. Два сервиса работают в разных процессах и взаимно перезапускают друг друга через bindService с флагом BIND_AUTO_CREATE - чтобы убить оба процесса, требуется синхронное завершение. Каждые пять минут срабатывает будильник AlarmManager, проверяющий активность обоих сервисов. После перезагрузки регистрируется приёмник BOOT_COMPLETED, который заново включает беспроводную отладку, загружает сохранённый ADB-ключ и восстанавливает shell-доступ. Кроме того, RedHook выставляет себе минимальное значение oom_score_adj = -1000 (высочайший приоритет при нехватке памяти) и закрепляет в физической RAM фрагмент памяти через mlock().

Для противодействия угрозе Group-IB рекомендует финансовым организациям внедрять системы мониторинга сессий пользователей (например, Fraud Protection) и цифровой защиты бренда (Digital Risk Protection). Пользователям следует устанавливать приложения только из официальных магазинов, критично оценивать запрашиваемые разрешения, особенно на Сервис специальных возможностей, не переходить по подозрительным ссылкам и не добавлять незнакомцев в мессенджеры. При подозрении на заражение - немедленно блокировать банковские счета, к которым был доступ с устройства.

RedHook демонстрирует, как злоумышленники адаптируют легитимные инструменты разработчиков и открытые фреймворки для повышения привилегий без эксплойтов уязвимостей. Возможности, заложенные в Android для отладки и настройки, становятся новым вектором атак, что требует от специалистов по безопасности постоянного мониторинга эволюции таких техник.

Индикаторы компрометации

URL

  • https://api.3n7wj.com

WebSocket Secure

  • wss://skt.3n7wj.com
  • wss://sktv.3n7wj.com

SHA256

  • 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946

Комментарии: 0