Крекс-пекс-фекс, вжух и ты бедняк: исследуем под «микроскопом» потрошителя банковских счетов CrахsRAT

Половина краж с банковских карт в России за последние полгода — дело рук одного семейства троянов. SpyNote и его наследник CraxsRAT заражают Android-устройства, открывают банковские приложения и выводят деньги. Большинство разборов этих вредоносов заканчиваются списком IOC и общими рекомендациями. Эта статья устроена иначе.

Меня зовут Евгения Устинова, я старший аналитик сетевой безопасности в компании «Гарда». Я провела статический разбор нескольких версий трояна (v3.7.1–v7.6, включая форки EagleSpy, VIPRat, RedBat, MedusaRat, DesertRat и утечку исходного кода v6/v7), восстановила полную хронологию атаки по реальному трафику и разобрала протокол до байтов.

Оказалось, что у CraxsRAT есть сетевая активность, которую невозможно отключить, не сломав клиент.

Я использовала эти базовые свойства протокола, чтобы построить правила Suricata, которые не устареют завтра, как обычные IOC. Читайте подробное исследование под катом.

Чем опасен CraxsRAT

Семейство CraxsRAT — не простые банковские трояны, это полноценная платформа для удаленного управления Android-устройствами без ведома их владельцев. С точки зрения аналитика у этого семейства есть несколько свойств, на которых стоит остановиться.

Троян скрывает свою иконку из меню, обфусцирует код и проверяет запуск в эмуляторе, а запросы разрешений маскируются под диалоги Google Play. Данные передаются в сжатом GZIP-формате, разные типы активности используют отдельные каналы связи, а идентификаторы сессий динамически меняются.

Ядро вредоноса содержит только базовые функции. Всё остальное доставляется плагинами для кражи контактов, SMS, файлов, записи звука, доступа к терминалу и т.п. Оператор загружает только нужные модули, что делает троян достаточно гибким. Благодаря ним злоумышленник может:

• видеть экран жертвы в реальном времени через скринкаст;

• вести прослушку через удаленную активацию микрофона;

• читать переписку и перехватывать уведомления

• считывать коды 2FA через Accessibility Service;

• принудительно открывать любые приложения;

• выполнять shell-команды с полным доступом к файловой системе;

• удаленно блокировать и разблокировать экран.

CraxsRAT может автоматически нажимать кнопку «Allow» без ведома пользователя.

Как только на экране жертвы появляется системный диалог запроса разрешения (например, на доступ к SMS или контактам), троян через Accessibility Service мгновенно анализирует содержимое окна, находит кнопку с текстом «Allow» на десятке языков или по системному идентификатору и программно нажимает её.

Отдельно стоит упомянуть встроенный JavaScript-скиммер: он внедряет в WebView код, который перехватывает cookies-сессии и всё, что вводит пользователь. Внедренный JavaScript-код находит на странице все поля ввода (input), извлекает введенные пользователем значения и добавляет к ним cookies текущей сессии. Собранные данные формируются в строку и отправляются на сервер злоумышленника.

Жизненный цикл атаки: хронология событий

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

Для наглядности привязала всё к таймлайну одного из типичных запусков. Сначала — краткое саммари, потом подробный разбор каждого этапа.

Автоматическая регистрация

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

Загрузка плагинов

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

Сбор информации

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

Обязательные «отстуки»

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

Активное управление

Оператор полностью удаленно контролирует зараженное устройство. Например, он может принудительно открывать любые приложения на устройстве жертвы (начиная с браузера и камеры, заканчивая системными настройками и магазином приложений). Это подтверждается автоматическими отчетами о смене активного окна.

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

Автоматическая регистрация и первый запрос на С2

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

Адрес сервера C2 для регистрационного сообщения берется из двух закодированных в Base64 в статических переменных: ClientHost и ClientPort.

Структура регистрационного сообщения

Регистрационное сообщение (Check-In) является одним из наиболее важных элементов протокола взаимодействия между зараженным устройством и сервером управления. Именно с этого сообщения начинается любая сессия работы трояна — клиент сообщает серверу свои параметры, версию протокола и структуру хранения данных.

Анализ формата Check-In позволяет не только идентифицировать сам факт заражения, но и получить информацию о конфигурации конкретного экземпляра вредоносного ПО. Следует отметить, что только это сообщение использует двоеточие ( : ) в качестве разделителя полей.

Ниже приведен формат регистрационного сообщения:

[IP_сервера]:[порт]:AppData:system_info:system_config:meta_data:[домен_сервера]:[флаги]:[CR]:V4:

Теперь на примере поясню, что обозначает каждое поле:

Формирование идентификатора устройства

Чтобы в дальнейшем опознаваться на сервере, устройство-клиент использует специальный идентификатор. Троян собирает длины системных параметров устройства (плата, бренд, процессор, модель и другие), объединяет их в строку и вычисляет MD5-хеш, который становится уникальным и постоянным идентификатором жертвы.

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

Загрузка плагинов

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

Структура команды на загрузку плагина

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

Общий формат команды загрузки плагина на примере:

0⏐
plugens.angel.plugens.apps⏐
8⏐
rm -r⏐
dex⏐
ping -c 1 -W 15⏐
1⏐
2⏐3⏐4⏐5⏐6⏐7⏐8⏐9⏐10⏐11⏐
-2⏐
-1

Знак ⏐ в команде загрузки плагина обозначает кастомный разделитель. Он не является фиксированным значением. В частности, в билдах EagleSpy он принимает значение EagleSpy, в билдах CraxsRAT — 1234 или TxTxT. Таким образом, злоумышленник может изменять разделитель на этапе сборки, используя его в качестве идентификатора и пароля доступа к серверу.

На стороне клиента процесс обработки команды загрузки плагина выглядит следующим образом:

1. Полученное сообщение разбивается на массив строк с использованием разделителя

2. Проверяется префикс, направляющий выполнение в ветку загрузки плагинов

3. Байт-код плагина (он передается следом в этом сообщении) сохраняется во временный файл в директории AppData под именем вида meta_dataX как и указывалось в регистрационном сообщении

4. Из полученного временного файла загружается класс через DexClassLoader, а ссылка на файл сохраняется в списке активных плагинов

5. Shell-команды ( rm -r , ping -c 1 -W 15 ) сохраняются в массиве функциональных блоков для последующего выполнения

6. Триггеры опкодов (opcode) 1-11 и маяки -2, -1 активируют блоки с заранее определенным функционалом

7. Временный файл плагина удаляется (в штатном режиме), а сам плагин при этом остается в оперативной памяти

Запрос информации о зараженном устройстве

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

Префикс 1 в структуре команды указывает, что она предназначена для ранее загруженного плагина (модуля). Далее следует идентификатор плагина  plugens.angel.plugens.info , затем ключевое слово method, после которого передается уникальный идентификатор сессии запроса (в данном случае 1NRQ704). Сама команда для плагина обозначена как info, а параметры как x0D0xnullx0D0xnull (x0D0x — разделитель), указывая, что дополнительных аргументов не требуется.

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

• модель и производителя устройства;

• версию операционной системы;

• объем оперативной памяти;

• состояние аккумулятора;

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

• данные об аккаунтах;

• информацию о сети и сотовом операторе, а также множество других параметров.

Собранные данные упаковываются и отправляются на сервер в ответном сообщении с тем же идентификатором сессии 1NRQ704. Через идентификатор сервер связывает запрос и полученный ответ.

Сбор информации об установленных приложениях

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

Как и в случае с плагином info, префикс 1 указывает на команду загруженному модулю, а 16QoV423 служит уникальным идентификатором сессии. Сама команда apps без дополнительных параметров означает, что плагин должен собрать и вернуть полный список установленных на устройстве приложений.

Структура ответа клиента на команду

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

Ниже детально рассмотрю начальный фрагмент ответа на запрос приложений:

x0D0xYouTube
x0A0xSystem
x0A0xcom.google.android.youtube
x0A0xMon Aug 02 17:43:59 GMT+01:00 2021
x0A0x/9j/4AAQSkZJRgABAQA...
x0L0xGoogle
x0A0xSystem
x0A0xcom.google.android.googlequicksearchbox
x0A0xMon Aug 02 17:44:31 GMT+01:00 2021
x0A0x/9j/4AAQSkZJRgA...
x0L0xFiles
x0A0xSystem
x0A0xcom.android.documentsui
x0A0xMon Aug 02 17:41:03 GMT+01:00 2021
x0A0x/9j/4AAQSkZJRgABAQAAAQ...

В ответе клиента содержится сериализованный Java-объект, в теле которого каждая запись о приложении содержит следующие поля, разделенные маркером x0A0x:

Записи разделяются маркером x0L0x, обозначающим конец одного приложения и начало следующего. Маркер x0D0x служит для обозначения начала и конца всего массива данных.

Мониторинг активности устройства (периодическая автоматическая активность)

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

Мониторинг активного окна (ActiveNow): первая автоматическая активность

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

Когда пользователь переключается между приложениями, открывает новое окно или возвращается на домашний экран, ОС Android генерирует событие TYPE_WINDOW_STATE_CHANGED. Троян, используя Accessibility Service, перехватывает это событие и извлекает из него имя пакета и название активного приложения. Далее происходит следующая проверка: если приложение сменилось (то есть имя пакета отличается от предыдущего), бот отправляет на сервер сообщение с идентификатором -A и названием активного приложения.

Что важно. Если пользователь переключается между разными окнами внутри одного приложения (например, между активностями банковского приложения), сообщение не отправляется. Таким образом, сервер получает уведомления только о переходах между разными приложениями.

Периодический мониторинг (Keep-Alive)

В отличие от механизма контроля активного окна -A, сообщения с идентификатором -255 (в коде ScreenBing ) отправляются строго по таймеру и несут информацию о состоянии экрана и статусе административных привилегий.

Механизм отправки. В основном цикле обработки команд трояна есть таймер, установленный на 60 секунд. Когда счетчик достигает нуля, бот формирует сообщение -255 . Оно содержит два ключевых элемента, разделенных маркером <!>:

Первый элемент сообщения - это результат выполнения shell-команды, сохраненной из сообщения загрузки плагина (ping -c 1 -W 15 <адрес С2>). Второй элемент — флаг, показывающий, активированы ли права администратора устройства ( 1 — активны, 0 — нет).

Дополнительные действия. Сразу после отправки -255 троян вызывает метод, который выполняет ping-запрос к серверу, подготавливая данные для следующего сообщения. Таким образом, каждую минуту происходит циклический процесс: отправка статуса → выполнение ping → сохранение результата → ожидание следующей минуты.

Мониторинг уведомлений

Важной функцией CraxsRAT является перехват системных уведомлений, автоматически отправляемых на сервер с идентификатором -666.

Пример из трафика

Структура данных

Поля разделены вертикальной чертой ( | - встроенный разделитель):

• Приложение-отправитель — Android System

• Заголовок уведомления — Configure physical keyboard

• Текст уведомления — Tap to select language and layout

• Маркер окончания уведомления — .

Удаленный захват экрана

Одна из наиболее опасных функций CraxsRAT — удаленный захват экрана зараженного устройства в реальном времени. Эта возможность реализуется командой сервера с префиксом 2:

2|
sc:on:20~30~23ddfcd79dc9d589~450x300|
18.192.31.30|
15508|
ddll|
0|
0|
x0A0x|
23ddfcd79dc9d589

Для выполнения команды трансляции экрана не нужен плагин. Эта функция реализована в основном коде трояна. Трансляция может осуществляться на сторонний сервер, указанный в команде.

Структура команды для захвата экрана

Команда состоит из нескольких обязательных элементов, разделенных маркером:

Параметры захвата экрана

Особого внимания заслуживает строка параметров 20~30~23ddfcd79dc9d589~450x300. Каждое поле в строке отделено символом ~ :

Маршрут обработки команды захвата экрана в коде

Получение и парсинг (основной модуль):

• Префикс 2 указывает, что это системная команда из основного кода

• Команда на включение скринкаста: sc:on:20~30~23ddfcd79dc9d589~450x300 с параметрами: FPS, качество, ID сессии и разрешение

• Адрес сервера ( 18.192.31.30 ), порт (15508)

Инициализация нового стрима:

• Основной модуль распознает команду sc:on и делегирует управление активности, которая запрашивает у пользователя разрешение на захват экрана через MediaProjectionManager 

• После получения разрешения запускается сервис, которому передаются параметры: resultCode, resultIntent, качество, FPS, ID сессии и разрешение

Передача данных по новому стриму: 

• Сервис создает новый сокет и подключается к серверу, адрес которого был получен в команде ( 18.192.31.30:15508)

• Заголовок данных содержит код скринкаста -9, реальное разрешение экрана ( 1080:720), и главное - тот же ID сессии ( 23ddfcd79dc9d589 ). Это связывает новый поток данных с исходной командой

• Далее сервис непрерывно захватывает экран через VirtualDisplay и ImageReader, сжимает кадры в JPEG и отправляет их по стриму

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

• видеть вводимые пароли и PIN-коды;

• отслеживать переписку в мессенджерах;

• наблюдать за действиями в банковских приложениях;

• получать информацию о посещаемых сайтах;

• следить за навигацией в настройках устройства.

Кадры захваченного экрана отправляются на сервер в сообщениях с идентификатором -9. Например: -9:1080:720:23ddfcd79dc9d589:n. Как видно в структуре, само изображение передается во второй части сообщения в дважды сжатом GZIP-формате.

Итоговая структура данных скринкаста «на проводе»:

Аудиостриминг: прослушивание через микрофон

Злоумышленник может прослушивать микрофон зараженного устройства. Эта функция реализована в плагине microphone и работает по принципу непрерывной трансляции аудиопотока на сервер. Запуск прослушивания инициируется командой от сервера с префиксом 1:

1
plugens.angel.plugens.microphone
method
-1
start
18.192.31.30
15508
8000
14VsL546
23ddfcd79dc9d589
0

Команда к загруженному плагину содержит следующие параметры, разделенные маркером x0D0x.

Принцип работы команды аудиостриминга

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

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

Плагин создает AudioTrack с заданными параметрами (частота 8000 Гц, моно, 16-битный PCM). В зависимости от типа потока он автоматически устанавливает максимальную громкость соответствующего канала через AudioManager. Это гарантирует качественную запись независимо от пользовательских настроек.

Разбивка аудиопотока на пакеты

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

1. Заголовок с идентификатором сессии, ID жертвы и параметрами потока. Внутри эта запись разделяется маркером x0A0x .

   14VsL546 x0A0x23ddfcd79dc9d589 x0A0x8000 x0A0x0

2.   Аудиоданные — фрагмент звука длительностью около 1-2 секунд, преобразованный в байтовый массив.

Заголовок, и аудиоданные перед отправкой сжимаются (Сжатие GZIP ) по отдельности для уменьшения трафика. В результате каждый пакет выглядит в логах как пара сообщений. Первая часть (короткая) в виде заголовка с параметрами, а вторая (большая) — сжатые аудиоданные. Такая структура прослеживается во всех сообщениях трояна, давайте рассмотрим её подробнее в следующем разделе.

Анализ сетевого трафика: структура пакетов и механизмы упаковки

Для стороннего наблюдателя, перехватывающего сетевой трафик зараженного устройства, взаимодействие с C2-сервером выглядит TCP-соединение, передающие бинарные данные, не поддающиеся мгновенному анализу. Из-за того, что CraxsRAT использует продуманную систему упаковки, комбинирующую GZIP-сжатие и заголовки, без изучения кода клиента и понимания его трафика, этот вредонос сложно обнаружить.

В этом разделе я с помощью метода «из сети в код, из кода в сеть» детально разберу, как формируются пакеты и какую структуру они имеют «на проводе».

Общая структура пакета данных

Все команды и ответы в C2-канале, а также данные в стримах, передаются не в чистом виде, а проходят через процедуру упаковки. На входе берутся две части данных (обычно это строка-идентификатор и полезная нагрузка) и преобразуются в единое сообщение.

[Длина сжатой части A] + [0x00] + [Длина сжатой части B] + [0x00] + [GZIP(часть A)] + [GZIP(часть B)]

Используя регистрационное сообщение от клиента, которое я разбирала ранее, покажу, как эта структура создается.

Входные данные:

• Часть A (строка префикс): -1

• Часть B (информационная строка): 18.192.31.30:15508:AppData:system_info:system_config:meta_data:0.tcp.eu.ngrok.io:11000011:[CR]:V4:

Процесс формирования сообщения клиента:

Строка-префикс сжимается с помощью GZIP. В результате получается архив в шестнадцатеричном представлении:  1F8B 0800 0000 0000 0000 D335 0400 2A48 2D30 0200 0000 

Каждый байт можно описать следующим образом:

Информационная строка также сжимается GZIP. Причем для разных исходных данных она будет своя. А вот Magic bytes и служебные поля Gzip останутся прежними: 1F8B 0800 0000 0000 0000 … 

Вычисление длин

1. Длина сжатой строки -1 составляет 22 байта. В ASCII-представлении — 22. В шестнадцатеричном виде это дает байты 32 32.

2. Длина сжатой информационной строки составляет 108 байт. В ASCII-представлении —108, или байты 31 30 38. 

Формирование заголовка

Заголовок формируется путем конкатенации: [ASCII длины ч.A] + [0x00] + [ASCII длины ч.B] + [0x00]. В шестнадцатеричном виде это выглядит как: 32 32 00 31 30 38 00 .

Финальная сборка сообщения

К заголовку последовательно дописываются сжатые части A и B. Затем на сервер отправляется итоговый поток данных следующего вида:

В конечном счете в трафике будет передана примерно вот такая конструкция:

Детектирование трояна средствами IDS

Для обнаружения трояна в сети отлично подходят правила формата Snort/Suricata — это отраслевой стандарт сигнатурного анализа трафика. Данные системы выявляют угрозы, сопоставляя сетевую активность с известными сигнатурами. На основе анализа поведения трояна можно выделить несколько ключевых стадий сетевой коммуникации, для которых целесообразнее всего разрабатывать правила детектирования.

Стадии сетевых коммуникаций

Опираясь на результаты проведённого исследования сетевого трафика, обозначу ключевые стадии взаимодействия инфицированного хоста с C2-сервером.

Приоритеты детектирующей логики

В совокупности правила должны перекрывать наиболее устойчивые и обязательные стадии жизненного цикла CraxsRAT-клиента. Загрузка плагинов и трансляция медиапотоков могут полностью отсутствовать в минимальных сборках клиента — их наличие зависит от конфигурации конкретного экземпляра вредоноса. Писать правила под опциональное поведение — значит получать детектирование с низким покрытием. Это не наш вариант.

Первоначальная установка соединения и периодическая активность устройства — две стадии, которые присутствуют в любой рабочей конфигурации клиента, поскольку они содержатся в основном коде и без них взаимодействие с C2 невозможно в принципе. Детектирование периодической активности устройства позволит мне, как аналитику выявить действующий канал управления на протяжении всей сессии связи с С2. Именно на этом и я сосредоточилась при разработке правил. Ниже привела примеры нескольких из них.

Общий шаблон детектирующего правила

Поскольку все сообщения между клиентом и C2 передаются в виде Gzip-архивов, это даёт надёжную отправную точку для построения сигнатур. Общие байты Gzip-заголовка (1f 8b 08 00 00 00 00 00 00 00 ) присутствует в каждом сообщении и могут служить базовым контентным фильтром. На его основе я построила шаблон, который впоследствии адаптировала под конкретные стадии сетевых коммуникаций:

Разберу структуру шаблона по полям:

Правило 1: Регистрация клиента (Check-In) - обязательное сообщение

В ходе исследования я установила, что регистрация клиента на сервере состоит из двух частей: первая содержит команду -1 , вторая — строку регистрации с данными об устройстве. Содержимое первой части архива является константным для всех версий клиента. Это делает её идеальной целью для сигнатурного детектирования.

Правило проверяет заголовок длины первой части ( 32 32 00 ) и следующий за ним байтовый контент архива с командой, дополнительно захватывая разделитель 00 в начале и Gzip второй части 1f в конце. Глубина анализа ограничена 32 байтами после обнаружения заголовка.

Правило 2: Мониторинг активного окна - периодическая активность

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

Правило 3: Keep-Alive (поддержание соединения) - периодическая активность

Помимо мониторинга активного окна, клиент периодически отправляет на C2 команду -255 , служащую своего рода сигналом поддержания соединения с результатами ping сервера управления. Этот механизм обеспечивает непрерывность канала связи и также присутствует в любой рабочей сборке клиента.

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

Методология исследования и применение его результатов для сетевого детектирования

История с CraxsRAT наглядно показывает: чтобы надежно ловить такие угрозы, нужен комплексный подход, одного метода здесь недостаточно. Мне помогло сочетание статического анализа кода и динамического мониторинга трафика. Оно позволило не просто разобрать троян «по косточкам», но и создать надежные правила детектирования.

Замкнутый цикл исследования

Использованная мной методология выстраивается в замкнутый цикл, где каждый этап обогащает данными следующий:

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

Вооруженная этим знанием, я смогла уже по-новому взглянуть на сетевой трафик — идентифицировать и понять назначение каждого элемента в структуре команд, выявить закономерности периодической активности.

От знания к правилам

Синтез сетевых наблюдений и понимание внутренней логики помог разработать правила, которые опираются на знание протокола:

• регистрационное сообщение всегда содержит идентификатор -1

• клиент отправляет сообщение -255каждые 60 секунд

• сообщение серверу формируется каждый раз при смене активного окна

Изучение протокола позволило мне создать правила, устойчивые к поверхностным изменениям. Теперь, даже если злоумышленник сменит билд или использует мод семейства SpyNote, правила продолжат детектировать угрозу. Далее в приложении я поделилась индикаторами компрометации и техниками MITRE, которые используют злоумышленники в рамках атаки с помощью CraxsRAT.

Гарда

t.me/garda_ai — создаем решения в сфере безопасности данных и сетевой инфрастуктуры

Приложение

Индикаторы компрометации (IoC) IP-адреса C2 серверов CraxsRAT

Таблица MITRE ATT&CK