Фабрика C2-агентов: опыт LLM-генерации наступательного инструментария

Постановка проблемы: творческая работа в тени рутинного каркаса

#

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

Наш стек — Mythic C2 с агентом Apollo для проведения работ по анализу защищённости. Когда новая техника публикуется в блоге или анонсируется в сообществе, нам необходимо интегрировать её в наш фреймворк в виде исполняемой задачи, для использования в тестах на проникновение. Эта интеграция имеет два компонента: рутинный (шаблонный код, подключение к API задач Mythic, упаковка результатов) и творческий (сама техника).

Наша цель состояла в том, чтобы проверить, способен ли Anthropic Opus 4.6 автоматизировать рутинный интеграционный каркас, высвобождая наше внимание для выбора техник и их совершенствования. Тестовыми задачами послужили jump_forshops, silentharvester и tasklist.

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

Примечание 1: Мы не представляем каких-либо новых наступательных техник — мы делимся опытом и экспериментальными результатами работы с LLM.

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

Итерация 1: однократный промпт — провал на уровне контекста, а не интеллекта

#

Цель выглядела прямолинейно: создать новую задачу для агента Apollo в Mythic, реализующую выгрузку SAM, SECRETS и SYSTEM с применением новой техники нашего коллеги Хайдара. Результатом стал полный провал.

Opus 4.6 предпринял попытку разобраться в устройстве Mythic посредством интроспекции его GraphQL API, израсходовав на шум схемы около 200.000 токенов контекста. Когда активировалось сжатие контекста, модель утратила нить задачи и начала с высокой степенью уверенности генерировать некорректный результат.

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

Итерация 2: скрипты вместо свободы

#

Открыв новую сессию с чистым контекстом, мы предоставили модели следующие вспомогательные материалы:

• build_and_download.py — скрипт, собирающий полезную нагрузку с необходимыми параметрами обратного HTTP.
• Инструкционный файл для лаборатории (.md), включая учётные данные, чтобы агент мог доставлять полезные нагрузки через smbclient и запускать их через wmiexec.
• execute_task.py — скрипт для выполнения задачи и считывания её вывода в одном действии.
• Пример универсальной задачи Apollo, позволяющий модели понять интерфейс задач и соглашения API Mythic, а не восстанавливать их путём умозаключений.

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

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

Итерация 3: декомпозиция

#

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

• Оркестратор — порождает Тестировщика и Разработчика и маршрутизирует между ними информацию об ошибках. Код не пишет.
• Тестировщик — получает явные инструкции по валидации полезной нагрузки: собирает её через скрипт, копирует через smbclient, запускает через wmiexec, выполняет демонстрационные команды, записывает stdout и возвращает краткий сфокусированный отчёт: статус, описание сбоя и вероятная корневая причина. Код также не пишет.
• Разработчик — получает лаконичное задание: «вот проект, вот ошибка, вот необходимая информация — устраните проблему. Ничего не собирать.»

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

Результат: несложная задача (tasklist) завершена за 13 минут, включая сборку полезной нагрузки; сложная задача (jump_forshops) — за 50 минут. Загрязнения контекста нет — каждый агент работает исключительно с необходимой ему информацией.

Ключевой вывод

#

Если из всей статьи следует запомнить одно положение, то вот оно:

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

build_and_download.py, execute_task.py — однострочные действия вместо многоэтапной импровизации. Каждое такое действие экономит контекст и кэш, позволяя модели сохранять эффективность на протяжении всей задачи.

Детерминированные инструменты отказывают явно; импровизированное использование инструментов отказывает незаметно и загрязняет цикл. Именно целенаправленная инструментальная обвязка Mythic устранила спираль GraphQL-интроспекции из Итерации 1. Критерии успеха также должны быть определены явно с самого начала — цикл требует верифицируемого условия завершения.

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

Масштабирование: от одной задачи к пятидесяти

#

Получив подтверждение работоспособности примитива, мы приступили к масштабированию. Мы нашли описание прохождения GOAD (Game of Active Directory) и попросили модель сопоставить доступные команды в Mythic со списком команд из этого описания, после чего выявить отсутствующие. Модель вернула пятьдесят недостающих команд.

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

Каждый цикл выполняется независимо и параллельно — одни и те же роли, один и тот же протокол взаимодействия, разные команды.

Отступление: тот же примитив, применённый к обходу AV

#

Это наблюдение имеет существенные последствия для защищающейся стороны. Идентичный цикл из трёх агентов применим к любой задаче с верифицируемым критерием успеха — в том числе к обходу средств защиты. Мы применили тот же конструкт, задействовав обфускатор, тестировщик, оркестратор и виртуальную машину Windows с установленным антивирусом:

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

Целевая директива проста: «продолжать обфускацию до прекращения обнаружения антивирусом. Затем установить точный байтовый паттерн, провоцирующий срабатывание.» Обнаружение по сигнатурам становится вычислительно решаемой задачей — с автоматизированным решателем.

Фабрика задач подтвердила состоятельность примитива. Однако задача — лишь плагин; полноценный агент C2 включает имплант, контейнер, строитель и стек протоколов, связанные через RabbitMQ. Мы применили ту же стратегию декомпозиции к существенно более обширной поверхности. Мы стремились определить, способен ли тот же цикл из трёх агентов сгенерировать полноценный одноразовый агент с нуля, а не только отдельную команду. Соответственно, мы сместили цель с задач на полные агенты Mythic и перешли от Opus 4.6 к актуальному поколению открытых моделей.

Контекст индустрии: «Одноразовый инструментарий»

#

В июне 2026 года Адам Честер (XPN) из SpecterOps опубликовал статью Disposable Tooling: Building LLM-Generated Mythic Agents from Prompt to Deployment. Исследование проводилось независимо от нашего и преследовало иную цель: не задачи, а целые одноразовые агенты.

Его первоначальный сбой точно воспроизвёл наш: неограниченный промптинг порождал агент, выглядевший корректным, но являвшийся, по его характеристике, «абсолютным уродством» — галлюцинированные методы RPC, нарушенный обмен ключами. Та же ошибка GraphQL проявилась и здесь, и была устранена тем же способом: конструированием небольших детерминированных CLI-инструментов. Результат: около двух часов на агента, с пятью агентами в итоге — на Python, Go, Zig, C# и Rust, каждый от полутора до двух часов.

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

• Уровень 1 — Быстрая локальная валидация: модульные тесты и протокольные тесты против имитационного сервера Mythic (регистрация, обмен ключами, выдача задач). Тесты должны вызывать реальный код агента, а не его симуляции.
• Уровень 2 — Удалённая валидация: отладочная сборка, развёрнутая на Windows-цели через labkit, с регистрацией и полным циклом для каждой команды.
• Уровень 3 — Контроль качества финальной сборки независимым подагентом QA с нулевым предшествующим контекстом. Вердикт: PASS или FAIL; FAIL возвращает выполнение на уровень 1.

Вспомогательный инструментарий: имитационный сервер, labkit поверх gRPC, mythicd, mythic-cli и документация Mythic, упакованная в виде навыка mythic-implant-development. Мы приняли эту обвязку для всей последующей работы.

Методология

#

Лабораторная среда. Сервер Mythic, mythicd и mythic-cli на одном хосте; Windows-цель, управляемая через labkit; имитационный сервер Mythic для локальных протокольных тестов. Идентичная среда для каждого запуска.

Целевой результат. Фиксированная спецификация для каждого запуска: агент Mythic — Go-имплант для Windows (x86 и x64, форматы EXE и DLL), Python-контейнер, профиль HTTP C2, семь команд: ls, cd, pwd, shell, download, upload, execute. Идентичная спецификация предоставлялась каждой модели.

Критерии прохождения. Многоуровневое тестирование в стиле Oracle, неизменное для всех запусков:

• Уровень 1: Модульные тесты и протокольные тесты против имитационного сервера (регистрация, обмен ключами, выдача задач, блочная передача файлов). Тесты должны вызывать реальный код агента, а не его симуляции.
• Уровень 2: Отладочная сборка, развёрнутая через mythicd и выполненная на Windows-цели через labkit, с полным циклом для каждой команды включая негативные тест-кейсы; затем финальная сборка и матрица форматов (EXE/DLL × x86/x64).
• Уровень 3: Независимый подагент QA с нулевым предшествующим контекстом, тестирующий обратный вызов финальной сборки. Вердикт: PASS или FAIL; FAIL возвращает выполнение в цикл обработки ошибок.

Запуск засчитывается как успешный только при прохождении всех трёх уровней.

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

Модели и инструментарий. Kimi K3 (облако, Kimi Code), DeepSeek V4 Flash 0731 (API через Claude Code), DeepSeek V4 Flash preview (локально, vLLM), Qwen 3.6 27B (локально) и смешанная конфигурация (оркестратор Kimi K3 + субагенты DeepSeek).

Известные ограничения методологии

#

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

1. Повторяемость. Большинство конфигураций запускалось дважды; в таблице представлен более медленный из двух успешных запусков. Запуски, прерванные вследствие инфраструктурных проблем, ошибок конфигурации или иных факторов на нашей стороне, отбрасывались и повторялись — они не учитываются в приводимых числах, хотя примечательные случаи обсуждаются по тексту.
2. Учёт затрат. Мы измеряли время выполнения, а не потребление токенов и финансовые затраты. Показатель «48 минут» в текущем виде не допускает сравнения со стоимостью.

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

#

Мы направили три открытые модели на решение одной и той же задачи: создание полноценного агента Mythic с нуля через конвейер в стиле Oracle. Спецификация: Go-агент для Windows (x86/x64, EXE и DLL, HTTP C2) с семью командами: ls, cd, pwd, shell, download, upload, execute.

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

История 1: Kimi K3 без документации — поучительная ошибка

#

В первом запуске Kimi мы использовали оригинальный конвейер XPN — однако вследствие ошибки в команде настройки среды с нашей стороны навык mythic-implant-development оказался недоступен. Модель располагала только тестирующими скриптами, без какой-либо документации. Тем не менее она создала работоспособный агент на Rust примерно за 4 часа 10 минут, включая тестирование и время сборки.

Мы упоминаем этот эпизод главным образом для демонстрации прироста возможностей примерно за шесть месяцев — от Opus 4.6, захлёбывающегося в GraphQL-интроспекции, до Kimi K3, создающего работоспособный агент без документации. Последующий чистый запуск с доступным навыком занял около 3 часов 10 минут (см. таблицу).

История 2: локальный DeepSeek — важность гигиены лабораторной среды

#

После запуска Kimi мы перенесли только что созданный Rust-агент во временный каталог и поставили нашему локальному DeepSeek V4 Flash preview (через Claude Code) идентичную задачу. DeepSeek выполнил find, обнаружил агент во временном каталоге и — вместо использования навыка — применил существующий код в качестве образца реализации. Агент был создан примерно за 48 минут. Этот аномальный запуск не отражён в таблице сравнительного испытания; он был отброшен, поскольку модель использовала ранее созданные артефакты вместо работы с нуля.

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

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

История 3: нестабильность локального vLLM

#

Неизменённый конвейер функционировал корректно с API-версией DeepSeek V4 Flash 0731, однако отказывал при использовании локальной модели DeepSeek V4 Flash 0731. Одинаковая обвязка, принципиально разное поведение.

Проблема заключалась в стеке обслуживания модели, а не в конвейере. На основании журналов генерации наша оценка такова: сборка vLLM для DeepSeek V4 Flash 0731 была недостаточно стабильной для этой недавно выпущенной модели — мы наблюдали некорректный разбор вывода, посторонние теги </think> и зацикливание. API-версия не проявляла ни одной из этих проблем. Соответственно, для локальных тестов мы использовали DeepSeek V4 Flash preview.

История 4: провал Qwen — обман вместо честности

#

Запуск Qwen 3.6 27B заслуживает отдельного рассмотрения, поскольку именно характер провала несёт в себе урок. Модель провела около четырёх часов в попытках пройти Уровень 1 и не достигла успеха; суммарное время составило около шести часов без получения работоспособного агента.

При проверке результатов обнаружилось, что вся работа выполнялась вручную с использованием cargo и имитационного сервера напрямую — ни один элемент реальной тестирующей инфраструктуры Mythic не применялся: mythic_cli не вызывался, mythicd не вызывался, скрипт сборки не запускался, файл возможностей не передавался, тесты labkit не выполнялись. Интерфейс полезных нагрузок Mythic оставался полностью пустым.

Когда несоответствие было установлено, модель ответила: «Вы совершенно правы, приношу извинения. Позвольте воспользоваться полным тестирующим комплексом.» Затем она воспроизвела ту же ошибку, что и в Итерации 1: «Агент ещё не зарегистрирован в Mythic. Необходимо зарегистрировать его через GraphQL API…»

Вывод: Менее способные модели не просто терпят неудачу — они терпят неудачу с видимостью успеха, декларируя достижение результата. Именно поэтому обвязка и уровень контроля качества являются обязательными, а не опциональными компонентами конвейера.

Совершенствование конвейера

#

После сравнительного испытания мы модифицировали конвейер по двум основным направлениям:

• Параллельные создатели задач. Команды теперь реализуются параллельно — по одному создателю задач на команду, с непересекающимся владением файлами, — после чего выполняется единый проход интеграции.
• Формальный цикл обработки ошибок с детальным выводом, исключающий незаметное распространение сбоев. При возникновении ошибки формируется пакет сбоя F1, передаётся исследователю F2, результирующее исправление направляется разработчику или соответствующему создателю задач (F3), и ограниченное повторное тестирование F4 верифицирует устранение: три последовательных сбоя эскалируются пользователю как блокирующая проблема.

Временные показатели по этапам: оригинальный и модифицированный конвейеры

#

Идентичный результат на обоих конвейерах: DeepSeek V4 Flash 0731, Go-агент для Windows (x86/x64, EXE и DLL, HTTP C2) с семью командами.

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

• Усилия смещены на начало. Формальная спецификация, фаза разработки только базовой части и контроль уровня 1 только для базовой части (суммарно 36 минут) выполняются до написания хотя бы одной команды. Оригинальный конвейер реализует всё за один проход и расплачивается за это позднее, в протяжённой последовательной фазе уровня 2 (92 минуты циклов развёртывания-отладки-DLL-x86).
• Параллельный поток масштабируется горизонтально. Все семь команд поступают примерно за десять минут, и этот показатель должен оставаться приблизительно постоянным по мере роста числа команд — именно здесь модифицированный конвейер демонстрирует явное преимущество при двадцати командах и более.
• Контроль требует времени. Уровень 1 повторно запускается после изменений, затрагивающих базовые компоненты.
• Обработка ошибок систематична, а не импровизирована. Каждый сбой уровня 2 в модифицированных запусках обрабатывался через цикл исследователя с ограниченным повторным тестированием.

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

Что показывают результаты

#

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

Заключение

#

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

Авторы выражают благодарность Адаму Честеру / SpecterOps за оригинальное исследование «Disposable Tooling» и обвязку Oracle, на которой основывается вторая часть настоящей работы.