Адаптируйся или плати. Разбор фреймворка AdaptixC2

Введение

Как мы уже рассказывали в статье про фреймворк Mythic, злоумышленники активно берут на вооружение новые технологии и фреймворки. Одним из характерных примеров такого инструментария стал AdaptixC2 — относительно новый open-source-проект для постэксплуатации, который за короткое время привлек внимание профильного сообщества наступательной кибербезопасности. Интерес к нему объясняется не только доступностью исходного кода, но и широкими возможностями расширения: фреймворк поддерживает BOF-файлы, включая асинхронные, и вокруг него уже сформировалась отдельная экосистема модулей, расширений и внешних BOF-коллекций. При этом AdaptixC2 все чаще используется в реальных инцидентах, в том числе в APT-атаках и кампаниях с применением шифровальщиков, о чем мы регулярно рассказываем.

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

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

Фреймворк AdaptixC2

AdaptixC2 — это фреймворк управления и контроля (C&C, или C2), предназначенный для проведения операций постэксплуатации и скрытого взаимодействия с вредоносными агентами в скомпрометированных системах. В отличие от многих универсальных C2-платформ, AdaptixC2 ориентирован на использование более продвинутых механизмов взаимодействия между агентами и управляющей инфраструктурой, а также на применение техник, направленных на снижение вероятности обнаружения со стороны современных средств защиты, включая решения классов EDR и NDR.

Фреймворк реализован на языках Go и C++. Архитектура AdaptixC2 построена по модели, предусматривающей разделение на серверную часть и агенты, развертываемые на скомпрометированных узлах. Такой подход позволяет централизованно управлять агентами, получать результаты выполнения команд и обеспечивать последующую постэксплуатационную активность. Особое внимание уделяется гибкости сетевого взаимодействия и возможности модификации используемых каналов связи, что позволяет адаптировать поведение агентов под конкретную среду и усложнять их обнаружение средствами мониторинга.

AdaptixC2 предоставляет возможность разрабатывать собственные агенты, а также включает несколько стандартных реализаций, написанных на языках Go и C++. Эти агенты предназначены для работы в операционных системах Windows, macOS и Linux.

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

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

• Организация управления (Command and Control, TA0011) — это механизмы установления и поддержания канала связи между оператором и скомпрометированными узлами для передачи команд, получения результатов их выполнения и мониторинга состояния агентов. AdaptixC2 предоставляет широкий набор методов связи с C2-сервером.
• Доступ к учетным данным (Credential Access, TA0006) — это тактика, направленная на получение учетных данных жертвы. В ExtensionKit для AdaptixC2 реализовано множество способов получения учетных данных: от стандартного дампа LSAAS до взаимодействия с ADCS и атак на протокол Kerberos.
• Предотвращение обнаружения (Defense Evasion, TA0005) — это тактика, при которой злоумышленники используют методы для обхода обнаружения СЗИ. AdaptixC2 имеет в своем арсенале набор нетривиальных методов реализации этой тактики.
• Горизонтальное перемещение (Lateral Movement, TA0008) — это набор методов для перемещения злоумышленников внутри инфраструктуры. AdaptixC2 поддерживает такие методы, как PsExec и WinRM.

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

Сетевые индикаторы агентов AdaptixC2

На момент написания статьи AdaptixC2 поддерживает передачу данных по протоколам HTTP/S, TCP/mTLS, SMB, DNS и DoH.

AdaptixC2 различает два подхода к построению коммуникации:

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

Коммуникация в режиме Egress (external)

Прямая коммуникация агентов с управляющим сервером (С2) возможна посредством следующих протоколов:

• HTTP(S)
• TCP
• DNS

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

HTTP

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

Сервер идентифицирует агента по уникальному значению, передаваемому в заголовке HTTP-запроса Heartbeat Header. Это значение связано с идентификатором агента и другими техническими данными, необходимыми для его работы. Перед передачей эти данные шифруются с использованием алгоритма RC4, после чего кодируются в формате Base64. Ключ шифрования генерируется заново при каждом создании HTTP-сервера.

По умолчанию заголовок, содержащий это значение, называется X-Beacon-Id. Данное имя устанавливается автоматически, однако при необходимости может быть изменено.

Еще одним параметром, имеющим значение по умолчанию, является заголовок User-Agent. Изначально он имеет следующее значение:
Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0.

Ниже показан пример сетевого трафика AdaptixC2 по протоколу HTTP. В данном случае используются значения полей, установленные по умолчанию.

Используемое значение User-Agent не является уникальным и может встречаться в легитимном сетевом трафике. При этом заголовок X-Beacon-Id является более характерным сетевым индикатором, который может указывать на использование фреймворка AdaptixC2.

Полезная нагрузка шифруется агентом с использованием алгоритма RC4 и передается в теле POST-запроса. Из-за применяемого шифрования содержимое запроса не поддается расшифровке без соответствующего ключа, поэтому в общем случае на основе этих данных затруднительно построить надежную детектирующую логику.

Ниже показано, как NDR-модуль в решении Kaspersky Anti Targeted Attack обнаруживает коммуникацию агента с сервером по протоколу HTTP с использованием стандартных заголовков. При этом создается оповещение с именем Backdoor.AdaptixC2.HTTP.C&C.

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

Ниже показан пример сетевого трафика AdaptixC2 по протоколу HTTP с использованием кастомизированных заголовков.

Учитывая ограничения на допустимые символы в заголовках HTTP-запросов, а также принимая во внимание, что содержимое заголовка X-Beacon-Id представляет собой данные, закодированные в формате Base64, можно сформировать сигнатурное правило для обнаружения запросов, инициированных агентом по этому протоколу. Дополнительно в детектирующую логику можно включить условия, связанные с порядком и наличием определенных HTTP-заголовков, а также с частотой появления подобных запросов. В таком случае реализация правил на HTTP-методы GET и POST будет незначительно отличаться, сохраняя все ранее описанные приемы.

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

Ниже показан пример сетевого трафика агента AdaptixC2, найденного в дикой природе, по протоколу HTTP с использованием кастомизированных заголовков. X-Beacon-Id передается в поле Cookie, а User-Agent и эндпоинт стараются мимикрировать под легитимную активность Центра обновления Windows.

Ответ сервера имеет стандартную структуру и передается в формате JSON с полями status, data и metrics. Полезная нагрузка содержится в поле data и зашифрована с использованием алгоритма RC4. Остальные поля фактически не используются и служат лишь для формирования внешне правдоподобной структуры ответа.

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

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

Ниже показаны примеры сетевого трафика агента AdaptixC2, найденного в дикой природе, по протоколу HTTP с использованием кастомизированного ответа сервера. В одном примере поля JSON были изменены, а в другом — полностью убраны и оставлена только зашифрованная полезная нагрузка.

Ниже показано, как NDR обнаруживает коммуникацию агента с управляющим сервером по протоколу HTTP. Сетевой трафик агента мимикрирует под легитимную активность сервиса и не имеет стандартных полей. KATA создает оповещение с именем Backdoor.AdaptixC2.HTTP.C&C.

HTTPS

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

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

Ниже приведен пример обнаружения агента AdaptixC2 на основе его трафика. В этом случае сработало правило на установление HTTPS-соединения с характерными параметрами TLS.

TCP

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

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

Ниже приведен пример сетевого трафика по протоколу TCP, в котором сервер возвращает стандартный баннер.

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

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

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

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

Ниже представлен скриншот оповещения KATA с модулем NDR об обнаружении работы агента AdaptixC2 в сетевом трафике по протоколу TCP в режиме Egress.

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

mTLS

Для большей скрытности при передаче данных по TCP AdaptixC2 поддерживает использование протокола Mutual TLS (mTLS). Это расширенная версия стандартного протокола TLS, реализующая механизм взаимной аутентификации сторон. В отличие от классической схемы TLS, где аутентификация является односторонней (клиент проверяет подлинность сервера по его сертификату), в mTLS сервер также требует предъявления и верификации клиентского сертификата перед установкой защищенного соединения.

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

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

Ниже приведен пример лога, содержащего коммуникацию агента по протоколу mTLS, а также его расшифрованную часть.

Анализ полезной нагрузки, передаваемой по протоколу Mutual TLS (mTLS), показывает ее полную идентичность данным в сессиях с использованием транспортных модулей TLS и TCP. Структура команд, формат инкапсуляции данных и алгоритмы шифрования остаются неизменными вне зависимости от используемого транспорта.

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

DNS

AdaptixC2 поддерживает передачу данных и команд от сервера как через классический DNS по протоколу UDP, так и с использованием DNS over HTTPS (DoH).

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

DNS over UDP

DNS over UDP представляет собой стандартный протокол разрешения доменных имен, который злоумышленники нередко используют для организации скрытых каналов связи.

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

Beacon DNS поддерживает четыре основные операции, которые однозначно идентифицируются вторым элементом слева в структуре DNS-запроса.

Каждый тип операции имеет свое строковое значение-идентификатор:

• инициализация: www/hi — регистрация агента на C2-сервере, первичное рукопожатие;
• передача данных: cdn/put — отправка фрагментов данных (например, результатов выполнения команд или данных для эксфильтрации);
• получение данных: api/get — загрузка задач, команд и конфигурации с сервера;
• heartbeat: hb — поддержание активности сессии, периодический опрос на наличие отложенных задач и подтверждение успешной загрузки данных.

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

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

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

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

Детально рассмотрим структуру пакета инициализации на конкретном примере:

Декомпозиция полей:

• session ID (base[0]) — уникальный идентификатор сессии длиной 8 байт (в приведенном примере — 39912991). Используется для последовательного определения всех запросов от конкретного агента в рамках одной сессии;
• идентификатор операции ([base[1]) — указывает тип операции: регистрация агента, отправка сигнальной метки, обработка задач. Представлен в виде ASCII-строки;
• sequence number (base[2]) — 8-байтный порядковый номер пакета, зашифрованный при помощи XOR. Механизм защиты от атак повторного воспроизведения (replay-атак), обеспечивающий уникальность каждого запроса даже при идентичных данных;
• unused (base[3]) — не используется обработчиком;
• зашифрованные данные (base[4]) — полезная нагрузка, закодированная в Base32 и зашифрованная алгоритмом RC4. В пакете инициализации это поле содержит критически важную информацию: данные об операционной системе (версия, сборка, архитектура x86/x64), имя процесса, в котором запущен агент, имя хоста и учетные данные пользователя, информацию о сетевом окружении и прочее.

Рассматриваемая структура DNS-запросов демонстрирует ряд характерных признаков DNS-туннелирования:

1. Множественная вложенность поддоменов: запрос содержит более восьми уровней доменной зоны, что нетипично для легитимного DNS-трафика.
2. Высокая энтропия имен: поддомены представлены псевдослучайными последовательностями символов (hex-строки, base32/base64-подобное кодирование).
3. Структурированное кодирование данных, например поддоменов вида 2HNLIUOKKYKFYML3KIJDPOBHLO67TE5PKSWA: указывает на использование алгоритмов кодирования для инкапсуляции полезной нагрузки.

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

Использование строковых литералов, таких как www, cdn, api, hb, в сочетании с четко структурированной иерархией поддоменов и предсказуемой длиной отдельных полей формирует выраженный сетевой индикатор, позволяющий выявлять активность агента. Дополнительными индикаторами компрометации могут выступать упомянутые выше аномально большая длина доменных имен (более 100 символов) при высокой энтропии поддоменов, чрезмерное количество уровней вложенности (более пяти поддоменов), а также регулярность запросов, например периодические heartbeat-запросы с одинаковым доменным именем.

Совокупность указанных признаков позволяет достаточно эффективно детектировать активность агента AdaptixC2, использующего DNS через UDP в качестве канала управления и передачи данных.

Ниже показано, как NDR-модуль обнаруживает коммуникацию агента с сервером по протоколу DNS. При этом создается оповещение с именем Backdoor.AdaptixC2.DNS.C&C.

DNS over HTTPS

Для реализации Beacon DNS агент AdaptixC2 также поддерживает протокол DNS over HTTPS (DoH). В нем используется механизм инкапсуляции стандартных DNS-запросов в HTTP-сообщения, передаваемые по защищенному протоколу TLS. С точки зрения сетевого анализа, использование DoH маскирует активность агента под легитимный веб-трафик, что существенно усложняет детектирование вредоносных действий средствами мониторинга, ориентированными на анализ незашифрованного трафика.

Ниже представлен скриншот сетевого трафика без расшифровки TLS, в котором происходит инициализация агента.

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

• https://dns.google/dns-query
• https://cloudflare-dns.com/dns-query
• https://dns.quad9.net/dns-query

Использование этих сервисов позволяет злоумышленникам делать незаметным вредоносный трафик в общем потоке легитимных обращений к популярным инфраструктурным сервисам.

При создании агента по умолчанию используется User-Agent Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0. При этом версия Firefox 20.0 является устаревшей и поддерживалась операционными системами Windows 7/8, Windows Server 2003 и Windows XP.

После расшифровки TLS-сессии структура пакета принимает следующий вид:

Особенности работы агента через DoH:

1. Метод передачи: используется метод POST для отправки DNS-запросов через механизм DoH.
2. Заголовки контента: наличие пары заголовков Content-Type: application/dns-message и Accept: application/dns-message соответствует требованиям спецификации RFC 8484 и является характерным признаком DoH-трафика.
3. Структура полезной нагрузки: тело POST-запроса полностью повторяет структуру пакетов DNS over UDP. Высокоэнтропийная строка поддоменов (Base32-кодирование с последующим шифрованием RC4) передается без изменений и инкапсулируется в бинарное DNS-сообщение, которое затем передается внутри HTTPS-запроса.

Несмотря на использование HTTPS-шифрования, реализация DoH в AdaptixC2 имеет ряд устойчивых сетевых индикаторов, позволяющих эффективно выявлять подобную активность. К таким индикаторам относятся использование устаревшей версии Firefox в заголовке User-Agent, регулярные POST-запросы к эндпоинту /dns-query, а также повторяющаяся структура доменных имен с предсказуемой длиной поддоменов. В совокупности эти признаки формируют характерный поведенческий профиль DoH-трафика агента AdaptixC2.

Ниже представлен интерфейс KATA NDR с оповещением о детектировании работы агента AdaptixC2 во время его инициализации по протоколу DNS over HTTPS с использованием расшифровки трафика. Сработало правило Backdoor.AdaptixC2.HTTP.C&C.

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

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

SMB

Для установления связи между агентами по протоколу SMB используется механизм именованных каналов. Имя канала может быть любым и задается при создании слушателя.

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

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

В инициализации агента нас интересует последовательность следующих команд:

• GetInfo Response
• Ioctl Response: STATUS_BUFFER_OVERFLOW
• Read Response

Из описанных команд непосредственно к активности агентов относится команда Read Response. В ответе содержится размер следующего пакета в виде одного DWORD (4 байта) в диапазоне от 100 до 140 в десятичной системе счисления. В следующем пакете находится техническая информация для регистрации агента, зашифрованная RC4. На скриншоте ниже представлен пример ответа Read Response.

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

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

Частота запросов агента для проверки команд по протоколу SMB наследуется от периодичности запросов родительского транспортного модуля в режиме Egress, через который команды передаются на С2-сервер. В зависимости от значения параметров Sleep и Jitter такие запросы будут выполняться с разной периодичностью.

В случае если агент простаивает без команд, его трафик с родительским агентом будет выглядеть следующим образом:

Структура запроса Ioctl Request представлена ниже:

Учитывая тип запроса и характерные флаги протокола (Command: Ioctl (11), Function: FSCTL_PIPE_PEEK), а также строгий порядок пакетов в режиме простоя, активность агента AdaptixC2 в транспорте SMB можно выявить сигнатурным способом.

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

TCP

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

Транспорт основан на сырых (raw) TCP-сокетах и реализует клиент-серверную модель передачи данных. Для усложнения обнаружения фреймворк предоставляет возможность указать параметр Prepend data — это данные, которые должны добавляться в начало каждого сообщения агента.

В стандартной конфигурации по умолчанию задан порт 9000 и параметр Prepend data со значением \x12\xabSimple\x20word\xa. Однако создать слушатель с таким значением не получится: возникнет ошибка некорректного синтаксиса. Следовательно, встретить полезную нагрузку, использующую указанное значение Prepend data, на практике невозможно.

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

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

Как и в случае транспорта SMB, в первом сообщении передается длина данных в виде big-endian DWORD (4 байта) в диапазоне 100–140 в десятичной системе счисления. Это размер следующего пакета, в котором содержится служебная информация. Коммуникация агентов шифруется алгоритмом RC4 и не поддается сигнатурному анализу на основе ее содержимого.

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

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

На скриншоте ниже представлен процесс инициализации агента и передачи нескольких команд.

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

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

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

Детектирование постэксплуатационной активности на примере модулей AdaptixC2

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

Credential Access

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

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

Детектировать эту активность можно путем отслеживания обращений к атрибутам Active Directory, связанным с LAPS, поскольку именно в них хранятся управляемые локальные пароли и служебная информация о ротации этих паролей. Несанкционированный доступ к таким сведениям может свидетельствовать о попытке получения привилегированных учетных данных.

Продукт Kaspersky EDR (KEDR) Expert детектирует данную активность с помощью следующих правил: computer_discovery_via_ldap, laps_passwords_scan_via_ldap, not_signed_process_ldap_request.

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

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

Продукт KEDR Expert детектирует такую активность с помощью правила suspicious_lsass_memory_access.

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

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

Продукт KEDR Expert детектирует такую активность с помощью правила registry_key_sam_users_queried.

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

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

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

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

Продукт KEDR Expert детектирует такую активность с помощью правила credentials_from_web_browsers.

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

Для выявления такой активности необходимо корректно настроить аудит Active Directory, связанный с использованием Kerberos. Это позволит детектировать атаки на основе анализа событий безопасности Windows, в частности событий с идентификаторами 4768 и 4769, отражающих процессы выдачи и использования билетов аутентификации.

Продукт KEDR Expert детектирует такую активность с помощью правила possible_asreproasting_via_preauth_value.

Defense Evasion

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

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

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

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

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

Lateral Movement

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

Рассмотрим способы обнаружения горизонтального перемещения на примере использования службы WinRM.

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

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

Продукт KEDR Expert детектирует такую активность с помощью правила suspicious_processes_spawned_by_winrm.

Заключение

Фреймворк постэксплуатации AdaptixC2 продолжает развиваться и набирать популярность. По мере появления новых агентов и механизмов скрытного присутствия в инфраструктуре расширяется и набор техник, применяемых операторами на этапах закрепления, управления и дальнейшего развития атаки. При этом сетевые коммуникации AdaptixC2, несмотря на разнообразие поддерживаемых протоколов и отдельных реализаций, сохраняют ряд устойчивых особенностей. Это обстоятельство позволяет решениям класса NDR эффективно выявлять активность агентов фреймворка на основе анализа сетевого трафика. Среди решений «Лаборатории Касперского» такая функциональность есть у платформы Kaspersky Anti Targeted Attack с модулем NDR.

Технология Kaspersky NDR предназначена для выявления актуальных угроз в сетевой инфраструктуре и позволяет обнаруживать распространенные фреймворки постэксплуатации по характерным признакам их сетевого взаимодействия. Даже при использовании на конечной точке различных техник уклонения, маскировки и скрытого выполнения действий агенту необходимо поддерживать связь с сервером управления для получения команд, передачи результатов и координации дальнейших этапов атаки. Именно поэтому контроль сетевых коммуникаций остается важным и эффективным способом выявления активности AdaptixC2.

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

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

Backdoor.AdaptixC2.TLS.C&C
Backdoor.AdaptixC2.TCP.C&C
Backdoor.AdaptixC2.SMB.C&C
Backdoor.AdaptixC2.HTTP.C&C
Backdoor.AdaptixC2.DNS.C&C