jymcheong/autottpАвтоматизированные тактики, техники и процедуры
Автоматизированные тактики, техники & процедуры. Повторное выполнение сложных последовательностей вручную для регрессионных тестов, оценки продуктов, генерации данных для исследователей и т. п. может быть утомительным. Я задумался о том, чтобы упростить создание сценариев для Empire (или любых фреймворков/продуктов/инструментариев, предоставляющих API, таких как Metasploit (RPC), Cobalt-Strike и т. д.) с помощью IDE, например Visual Studio Code (или аналога). Так я начал проектировать AutoTTP. Это всё ещё находится в стадии активной разработки. Тестировалось с Empire 2.2.
Youtube — Обзор и глубокое погружение в выбранные техники
В моём случае тактики организованы в соответствии с моей моделью жизненного цикла атаки. Существуют и другие модели, такие как Lockheed Martin's Kill-Chain(R), Mandiant Attack Life Cycle и Mitre's ATT&CK. Какой бы моделью это ни было, «Tactic» по сути группирует техники вместе, например, выполнение кода/запуск полезной нагрузки может быть достигнуто многими способами:
Я использую «Stage» для группировки соответствующих «Tactics». Если заглянуть в дерево исходников, структура папок отражает столбец Tactics матрицы. В матрице также упоминаются соответствующие контрмеры для каждой наступательной тактики. Как возникли эти стадии?
Диаграмма Венна в центре красного цикла взята из «Three Tenets for Secure Cyber-Physical System Design and Assessment» Дартмутского колледжа. Она определяет необходимые и достаточные условия, или просто требования любого успешного физического/логического нападения. Я добавил красное кольцо (стадии) вокруг диаграммы Венна, чтобы проиллюстрировать типичные наступательные потоки, которые в конечном итоге приводят к воздействию на конфиденциальность информации, целостность и доступность системы или безопасность, если это связано с киберфизическими системами (подумайте о критической информационной инфраструктуре).
Злоумышленник может начать со Stage 1 и сразу перейти к Stage 4, например, используя стандартные учётные данные администратора на публично доступной странице администратора. Нет необходимости быть линейным (stage 1->2->3->4). После первоначального проникновения он/она может сначала провести внутренний сбор информации (разведку) перед повышением привилегий на первой машине, а затем запустить удалённую команду на другую целевую машину в той же сети. Для следующей жертвы это Stage 2; успешная доставка и выполнение полезной нагрузки, что позволяет злоумышленнику получить контроль над ещё одной машиной.
Файл слева — это скрипт процедуры, справа — скрипт техники. Обратите внимание, что скриптинг процедуры не перегружен деталями, специфичными для Empire, большая часть деталей инкапсулирована в скрипте техники. Скриптинг процедуры должен сосредоточиться на последовательности техник, используя информацию об активах, например, имя хоста/IP, на какой email отправить полезную нагрузку, какую технику полезной нагрузки и так далее.
Пример «is user admin?» на самом деле состоит из нескольких шагов, поскольку есть как минимум 3 возможности, изложенные в комментариях скрипта. Мы, конечно, можем создавать пользовательские «макросы» в Empire, Metasploit и т.д., но это становится тесно интегрированным в конкретный фреймворк/продукт. Мы хотим воспользоваться существующими инструментами и организовать переиспользуемые техники в модули, чтобы смешивать и сочетать их на процедурном уровне (т.е. автоматизация).
Я воспользовался хорошо структурированными модулями Empire для создания класса автодополнения на Python. Вместо ввода полного имени модуля (например, powershell/situational_awareness....) просто используйте возможности автодополнения IDE.
Для каждого модуля существуют опции (для большинства, если не всех, фреймворков). Особенность Empire в том, что после запуска в режиме rest/headless (коснусь этого позже) нет консоли для просмотра опций модуля. В классе-помощнике автодополнения каждый модуль имеет подкласс options. Обязательные опции имеют префикс, как показано выше, поэтому мы можем сначала заполнить эти опции значениями перед вызовом модуля.
Описание каждого модуля также включено в документацию класса Python и будет отображаться при наведении на класс. Поскольку модулей 276 (по состоянию на Empire 2.1), этот вспомогательный класс потребует некоторого скриптинга для создания! Источник: https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
С помощью IDE, таких как Visual Studio Code (или аналогов), можно воспользоваться просмотром переменных отладки, пошаговым выполнением скрипта или даже изменением скрипта во время отладки/пошагового выполнения после понимания структуры возвращаемых значений. Документация REST API есть для Empire, но иногда мы точно не знаем возвращаемые значения, пока не запустим модуль. По этой причине мы переходим к следующей теме.
Как бы мы ни хотели всё делать в IDE, консоль понадобится. Автор DeathStar уже знал это, когда разрабатывал скрипт, автоматизирующий получение Domain Admin с помощью Empire. Я позаимствовал его идею, но адаптировал его подход с потоками для Empire 2.1, поскольку его подход не работал с рефакторизованной функцией запуска RESTful API. Источник: https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
Нет необходимости взламывать скрипт Empire, так как Empire 2.2 имеет обработчик цикла команд при работе в режиме REST. Однако НЕ взаимодействуйте с агентом при использовании API для получения результатов агента.
Shout outz to @radioboyQ за его EmpireAPIWrapper, @allfro и @Mikaayenson за pymetasploit, и @byt3bl33d3r, MTFBWU.
