Ищем Mythic в сетевом трафике

Фреймворки постэксплуатации

Злоумышленники часто используют фреймворки для постэксплуатации в компьютерных атаках — для контроля за взломанными узлами и горизонтального перемещения внутри сети организации. При этом если раньше они предпочитали закрытые фреймворки (привет Cobalt Strike и Brute Ratel C4), то в последние годы популярность обрели такие проекты с открытым исходным кодом, как Mythic, Sliver, Havoc. При этом злоумышленники быстро берут на вооружение и сравнительно новые фреймворки, например AdaptixC2.

Анализ популярных фреймворков показал, что при их разработке основное внимание уделяется механизмам уклонения от обнаружения антивирусами и EDR-решениями, но не системами анализа сетевого трафика. Замаскировать сетевую активность агентов в целом довольно сложно, при этом агентам неизбежно нужно взаимодействовать с управляющими серверами. Соответственно, присутствие агента в системе и его вредоносные действия можно выявлять при помощи различных сетевых систем обнаружения атак (IDS) и, конечно, решений класса Network Detection and Response (NDR).

В этой статье мы рассмотрим способы обнаружения фреймворка Mythic в инфраструктуре на основе анализа сетевого трафика. Этот фреймворк в последнее время пользуется популярностью у различных групп злоумышленников, в том числе APT-группировок Mythic Likho (Arcane Wolf) и GOFFEE (Paper Werewolf), позиционирующих себя как проукраинские. Эти группировки продолжают активно атаковать российские компании из широкого спектра отраслей. Более подробную информацию о них и их тактиках, техниках и процедурах (TTP) можно прочитать в нашем глобальном отчете Записки цифрового ревизора.

Фреймворк Mythic

Mythic C2 — это многопользовательская платформа управления и контроля (C&C, или C2), предназначенная для управления вредоносными агентами в сложных кибератаках. Mythic построен на базе контейнерной архитектуры Docker, а его основные компоненты — сервер, агенты и транспортные модули — написаны на Python. Такая архитектура позволяет операторам добавлять новые агенты, каналы связи и пользовательские модификации на лету.

Поскольку Mythic является универсальным инструментом для атакующего, с точки зрения защитника его использование может соответствовать многим этапам Unified Kill Chain, а также большому количеству тактик, техник и процедур в MITRE ATT&CK.

• Пивотинг (Pivoting) — это тактика, при которой атакующий использует уже скомпрометированную систему как опорную точку (pivot), чтобы получить доступ к другим системам внутри сети. Таким образом он постепенно расширяет присутствие в инфраструктуре организации, обходя межсетевые экраны, сетевые сегментации и другие ограничения.
• Сбор данных (Collection, TA0009) — тактика, направленная на сбор и агрегацию информации, представляющей ценность для злоумышленника: файлов, учетных данных, скриншотов и системных логов. В контексте сетевых операций сбор часто выполняется локально на скомпрометированных хостах с последующей упаковкой данных для передачи, а инструменты типа Mythic автоматизируют обнаружение и выбор нужных злоумышленникам данных.
• Эксфильтрация данных (Exfiltration, TA0010) — процесс вывода собранной информации за пределы защищенной сети через легитимные или замаскированные каналы (HTTP(s), DNS, SMB и др.). Атакующие могут использовать резидентные агенты или промежуточные ретрансляторы (pivot hosts) для сокрытия источника и маршрута эксфильтрации.
• Организация управления (Command and Control, TA0011) — механизмы установления и поддержания канала связи между оператором и скомпрометированными узлами для передачи команд и получения статуса. Включает прямые соединения, ретрансляцию через pivot-хосты и использование скрытых протоколов. Mythic и подобные фреймворки предоставляют расширенные C2-функции (выполнение команд по расписанию, туннелирование, мультиканальность), что усложняет обнаружение и блокировку их активности.

В этой статье мы сосредоточимся исключительно на тактике Command and Control (TA0011), техники которой могут быть эффективно обнаружены в сетевом трафике агентов Mythic.

Обнаружение работы агентов Mythic в сетевом трафике

На момент написания статьи Mythic поддерживает передачу данных по протоколам HTTP/S, WebSocket, TCP, SMB, DNS и MQTT. Также для этой платформы существует более десятка различных агентов, написанных на Go, Python, C# и предназначенных для операционных систем Windows, macOS и Linux.

В Mythic существует два подхода к построению управляющей сети:

• P2P — подход, когда агенты взаимодействуют со смежными агентами и строят цепочку связей до узла, который общается с управляющим сервером Mythic напрямую. Для этой цели в агентах используются протоколы TCP и SMB;
• Egress — подход, когда агенты взаимодействуют напрямую с сервером управления (C2), используя протоколы HTTP/S, WebSocket, MQTT или DNS.

Коммуникация в режиме P2P

Mythic предлагает возможность пивотинга посредством именованных SMB-каналов (SMB pipes) и TCP-сокетов. Для выявления активности агентов Mythic в режиме P2P рассмотрим их сетевой трафик и создадим соответствующие правила обнаружения (сигнатуры) Suricata.

P2P-коммуникация по протоколу SMB

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

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

Например:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}

Для реализации коммуникации по протоколу SMB агенты кодируют и шифруют данные по схеме base64(UUID+AES256(JSON)), а затем разбивают их на блоки и передают по сети. На скриншоте ниже показано, как в Wireshark выглядит сетевая сессия процесса установки соединения между агентами.

Команды и ответы на них упакованы в структуру данных MythicMessage. Эта структура содержит три служебных поля, а также непосредственно сами команды или ответы на них:

• общий размер (4 байта);
• количество блоков данных (4 байта);
• номер текущего блока (4 байта);
• данные, закодированные по алгоритму base64.

На скриншоте ниже показан пример коммуникации по протоколу SMB между агентами.

Агент (10.63.101.164) посылает команду другому агенту в формате MythicMessage. Первые три запроса типа Write Request передают общий размер сообщения, общее количество блоков и номер текущего блока. Четвертый запрос передает данные, закодированные алгоритмом base64. Далее следует цепочка запросов типа Read Request, которые также передаются в формате MythicMessage.

Ниже представлены данные, передаваемые в четвертом поле структуры MythicMessage.

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

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

Для поиска пакетов с UUID можно применить следующую сигнатуру. В ней в качестве фильтров выступают тип запроса и флаги протокола (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT (0x00110018)), после которых следует проверка имени канала на соответствие шаблону UUID.

Также можно обнаружить работу агента путем анализа данных, передаваемых в SMB-запросах типа WriteRequest c флагом протокола Command: Write (9) и особенностью структуры пакета, в которой значение полей BlobOffset и BlobLen равно нулю. Если поле Data закодировано в base64 и после декодирования содержит в начале блока данных строку вида UUID, то это признак обнаружения канала управления.

Ниже показан интерфейс KATA NDR c оповещением об обнаружении работы агента Mythic в режиме P2P по протоколу SMB. В данном случае сработало первое правило, проверяющее тип запроса, флаги протокола и шаблон UUID.

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

P2P-коммуникация по протоколу TCP

Mythic имеет возможность организации P2P-коммуникаций через протокол TCP. Процесс инициализации соединения в этом случае выглядит в сетевом трафике следующим образом.

Как и в случае коммуникации по протоколу SMB, для передачи и приема данных используется структура MythicMessage. Сначала отдельным пакетом передается длина данных (4 байта) в виде big-endian DWORD, а в следующих пакетах передаются число блоков данных, номер текущего блока и сами данные. Однако, в отличие от SMB-пакетов, значение поля номера текущего блока всегда равно 0x00000000, ввиду встроенной поддержки фрагментации пакетов в протоколе TCP.

Схема кодирования данных также аналогична той, которую мы видели в коммуникации по протоколу SMB, и выглядит следующим образом: base64(UUID+AES256(JSON)). Ниже показан пример сетевого пакета с данными Mythic.

Декодированные данные выглядят следующим образом.

Как и в случае коммуникации по протоколу SMB, для TCP-трафика можно сделать сигнатурное правило обнаружения активности агентов Mythic, которое будет искать пакеты, содержащие строки формата UUID. Ниже приведено два правила обнаружения Suricata. Первое — служебное. Оно не создает оповещений безопасности, а только помечает TCP-сессию внутренним флагом, который будет проверяться в другом правиле. Второе проверяет установленный флаг и применяет фильтры для определения того, что текущий пакет анализируется в начале сетевой сессии. Далее правило декодирует base64 и ищет в полученных данных строку в формате UUID.

Ниже показан интерфейс NDR c примером обнаружения работы агента Mythic в режиме P2P по протоколу TCP при помощи этих двух правил.

Транспортные модули Egress

Скрытая коммуникация в режиме Egress

Для скрытой работы Mythic позволяет организовывать управление агентами через популярные сервисы. Это делает его активность менее заметной в сетевом трафике. Существуют транспортные модули Mythic на основе следующих сервисов:

• Discord
• GitHub
• Slack

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

Транспортный модуль Discord C2 Profile

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

Анализ расшифрованного TLS-трафика

Допустим, мы используем NDR совместно с системой расшифровки сетевого трафика (TLS-инспекции) для обнаружения подозрительной сетевой активности. В этом случае мы считаем, что можем расшифровать весь TLS-трафик. Рассмотрим возможные детектирующие правила для такого сценария.

Коммуникация агента и сервера происходит посредством использования API-вызовов Discord для отправки сообщений в определенный канал. Для коммуникации агента и Mythic используется структура MythicMessageWrapper, имеющая следующие поля:

• message — передаваемые данные;
• sender_id — GUID, сгенерированный агентом, который добавляется в каждое сообщение;
• to_server — флаг направления: сообщение для сервера или агента;
• id — не используется;
• final — не используется.

Здесь особый интерес для нас представляет поле message, содержащее передаваемые данные в закодированном в base64 виде. Сообщение вида MythicMessageWrapper передается в открытом виде, поэтому будет доступно любому, у кого есть разрешения на чтение сообщений на сервере Discord.

Ниже приведен пример передачи информации с помощью сообщений в Discord-канале.

Для установления соединения агент аутентифицируется на сервере Discord при помощи API-вызова /api/v10/gateway/bot. В сетевом трафике мы видим при этом следующие данные.

После успешной инициализации агент получает возможность принимать команды и отвечать на них. Для создания сообщения в канале используется POST-запрос на конечную точку API /channels/<channel.id>/messages. Сетевой трафик этого вызова показан на скриншоте ниже.

После декодирования base64 содержимое message имеет следующий вид.

В начале пакета видна структура, характерная для UUID.

После обработки сообщения агент удаляет его из канала, используя запрос DELETE на конечную точку API /channels/{channel.id}/messages/{message.id}.

Ниже приведено правило Suricata, обнаруживающее активность агента, который использует коммуникацию через Discord. Активность API для создания сообщений по протоколу HTTP проверяется на наличие данных, закодированных в base64 и содержащих UUID агента.

Ниже показан интерфейс NDR c примером обнаружения активности транспортного модуля Discord C2 Profile агента Mythic в расшифрованном HTTP-трафике.

Анализ зашифрованного TLS-трафика

Если в сети разрешено использование Discord и нет возможности расшифровать трафик, то обнаружить работу агента практически нереально. В этом случае может помочь поведенческий анализ запросов к Discord-серверу. Ниже показан сетевой трафик, содержащий частые TLS-соединения с Discord-сервером, которые могут свидетельствовать об отправке команд агенту.

В этом случае можно использовать правило Suricata, обнаруживающее частое установление TLS-сессий с серверами Discord.

Еще один способ обнаружения таких коммуникаций заключается в отслеживании множественных DNS-запросов на домен discord.com.

Для их выявления можно использовать следующее правило.

Ниже показан интерфейс NDR c примером работы одного из пользовательских правил, обнаруживающих работу транспортного модуля Discord C2 Profile агента Mythic в зашифрованном трафике по характерным запросам по протоколу DNS.

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

Транспортный модуль GitHub C2 Profile

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

Основная идея такая же, как и в других транспортных модулях скрытой коммуникации в режиме Egress. Связь с GitHub выполняется при помощи протокола HTTPS. Для работы необходим аккаунт на целевой платформе и возможность коммуникации с помощью API-вызовов. Транспортный модуль использует GitHub API для отправки комментариев к заранее созданным проблемам (Issues) и записи файлов в ветку Git подконтрольного злоумышленникам репозитория. Таким образом, агент взаимодействует только с GitHub: создает и читает комментарии, загружает файлы и работает с ветками. Ни к каким другим серверам он не обращается. Алгоритм коммуникации через GitHub следующий.

1. Агент публикует на GitHub комментарий (check-in) в специальную проблему (Issue), предназначенную для выкладки агентами результатов работы.
2. Сервер Mythic валидирует полученный комментарий, удаляет его и публикует ответ в предназначенной для сервера проблеме.
3. Агент создает ветку с именем, совпадающим с его UUID, и записывает файл get_tasking (выполняет push-запрос).
4. Cервер Mythic читает файл и записывает файл-ответ в ту же ветку.
5. Агент читает файл-ответ, удаляет ветку, делает паузу и повторяет цикл.

Анализ расшифрованного TLS-трафика

Рассмотрим подход к обнаружению работы агентов в случае возможности расшифровки трафика.

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

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

На этапе check-in агент публикует комментарий для регистрации нового агента и установления связи.

Передаваемые данные кодируются в Base64 и содержат UUID агента и зашифрованную по алгоритму AES-256 часть сообщения.

Это позволяет сделать сигнатуру для обнаружения подстрок в формате UUID при создании комментария на GitHub.

Еще один удобный для обнаружения этап — когда агент создает отдельную ветку со своим UUID в качестве имени. Все последующее общение с сервером в рамках задачи будет происходить именно в ней. Вот так выглядит пример запроса на создание ветки.

Соответственно, можно сделать правило обнаружения, которое будет выявлять в запросах на создание ветки строки вида UUID.

После создания ветки агент записывает в нее файл (push-запрос), в котором содержатся данные в base64.

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

На скриншоте ниже показано, как NDR регистрирует все подозрительные коммуникации с использованием API GitHub, после чего выявляет работу агента Mythic. В результате создается оповещение с вердиктом Trojan.Mythic.HTTP.C&C.

Анализ зашифрованного TLS-трафика

Соединение с GitHub выполнятся по протоколу HTTPS, поэтому при отсутствии возможности расшифровать трафик сигнатурные методы обнаружения работы агентов применить нельзя. Рассмотрим вариант поведенческого обнаружения активности агентов.

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

Детектировать множественные установки TLS-сессий с сервисом GitHub из сегментов сети, которым такая активность не свойственна, можно с помощью представленного ниже правила.

Дополнительно в трафике можно регистрировать множественные DNS-запросы к сервису.

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

На скриншоте ниже показан интерфейс NDR c примером работы первого из приведенных правил, обнаруживающих в зашифрованном трафике следы активности GitHub-профиля агента Mythic по протоколу TLS.

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

Прямая коммуникация в режиме Egress

Коммуникация по типу Egress позволяет агентам взаимодействовать с сервером управления (C2) по следующим протоколам:

• HTTP(S)
• WebSocket
• MQTT
• DNS

Из этого перечня наиболее популярны первые два протокола. Транспортный модуль, основанный на протоколе DNS, находится в стадии разработки, а транспортный модуль, основанный на MQTT, мало популярен среди пользователей. В рамках данной статьи мы не будем их рассматривать.

Коммуникация по протоколу HTTP

HTTP — наиболее распространенный протокол для построения сети управления агентами Mythic. Контейнер HTTP-транспорта действует как прокси между агентами и сервером Mythic. Он позволяет передавать данные в открытом и зашифрованном виде. При этом служебная информация не шифруется, что позволяет создать сигнатурное правило обнаружения.

Ниже показан пример сетевого трафика Mythic по протоколу HTTP без шифрования. При выполнении GET-запроса в значении параметра query передаются данные, закодированные в base64.

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

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

После расшифровки трафика и декодирования из base64 данные коммуникации представляют собой знакомую нам структуру UUID+AES256(JSON).

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

Ниже показано, как NDR обнаруживает коммуникацию агента с сервером по протоколу HTTP. При этом создается оповещение с именем Trojan.Mythic.HTTP.C&C.

Коммуникация по протоколу HTTPS

Агенты Mythic могут коммуницировать с сервером по протоколу HTTPS. Для этого используется соответствующий транспортный модуль. В этом случае данные зашифрованы при помощи TLS и не поддаются сигнатурному анализу. Однако активность агентов Mythic можно выявить, если они используют SSL-сертификат по умолчанию. Ниже показан пример сетевого трафика агента Mythic с таким сертификатом.

Для этих целей применяется следующая сигнатура.

На следующем рисунке показано, как NDR выявляет работу агента Mythic по протоколу HTTPS. В результате будет сгенерирован вердикт с именем Trojan.Mythic.HTTPS.C&C.

WebSocket

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

Процесс взаимодействия агента с сервером через WebSocket следующий.

1. Агент отправляет запрос к контейнеру WebSocket на изменение протокола для установленного HTTP(S)-соединения.
2. Агент и контейнер WebSocket начинают использовать протокол WebSocket для отправки и получения сообщений.
3. Агент отправляет контейнеру WebSocket сообщение с запросом на получение заданий от контейнера Mythic.
4. Контейнер WebSocket пересылает запрос на контейнер Mythic.
5. Контейнер Mythic возвращает задания контейнеру WebSocket.
6. Контейнер WebSocket пересылает эти задания агенту.

Стоит отметить, что при такой модели коммуникации и контейнер WebSocket, и контейнер Mythic расположены на сервере Mythic. Ниже показан скриншот первоначального подключения агента к серверу.

Если проанализировать TCP-сессию, то можно заметить, что непосредственно данные передаются в поле data в кодировке base64.

После их декодирования получается структура данных вида UUID+AES256(JSON).

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

Ниже показано срабатывание сигнатуры Trojan.Mythic.WebSocket.C&C на коммуникации агента Mythic по протоколу WebSocket.

Заключение

Фреймворк постэксплуатации Mythic продолжает набирать популярность и активно развиваться. Появляются новые агенты, рассчитанные на скрытное присутствие в инфраструктурах целей. При этом различные реализации сетевых коммуникаций в Mythic имеют много общих черт и практически не меняются с течением времени. Это обстоятельство позволяет решениям класса IDS/NDR эффективно выявлять активность агентов фреймворка на основе анализа сетевого трафика.

Mythic поддерживает достаточно много разных вариантов управления своими агентами, использующих ряд сетевых протоколов. Анализ коммуникаций агентов по этим протоколам показал, что их активность можно выявлять при помощи поиска данных в сетевом трафике по определенным шаблонам. Основной критерий обнаружения заключается в отслеживании строк UUID в определенных позициях передаваемых данных, закодированных по алгоритму base64. Однако, несмотря на то что в общем и целом подход к выявлению активности агентов одинаков для разных протоколов, для каждого из них используются и специфичные для него фильтры. Поэтому затруднительно сделать универсальную сигнатуру для выявления работы агентов Mythic в сетевом трафике: для каждого протокола требуется создавать индивидуальные правила обнаружения. В статье приведены сигнатуры, которые входят в состав Kaspersky NDR.

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

Вердикты решений «Лаборатории Касперского» (Kaspersky Anti-Targeted Attack с модулем NDR и Kaspersky NGFW)

Trojan.Mythic.SMB.C&C
Trojan.Mythic.TCP.C&C
Trojan.Mythic.HTTP.C&C
Trojan.Mythic.HTTPS.C&C
Trojan.Mythic.WebSocket.C&C