Автоматизация инфраструктуры Red Team с помощью Terraform
Контекст
Цель этой лабораторной работы состояла в том, чтобы не запачкать руки при создании простой, устойчивой и легко заменяемой инфраструктуры красной команды. Кроме того, я хотел поиграть с концепцией "Инфраструктура как код", поэтому я решил поработать с инструментом, о котором слышал уже некоторое время — Terraform.
Кредиты
Автоматизированная инфраструктура для работы с красными командами — не новая концепция, как раз наоборот. Я черпал вдохновение из замечательной работы @_RastaMouse (
Для просмотра ссылки Войди или Зарегистрируйся), где он объяснял свой процесс создания автоматизированной среды для красных команд. Он взял за основу отличную вики (
Для просмотра ссылки Войди или Зарегистрируйся) Стива Бороша и Джеффа Диммока — именно этот ресурс я использовал при лабораторных исследованиях ниже:
Обзор инфраструктуры
Ниже приведена диаграмма, показывающая инфраструктуру, которую я построил для этого лабораторного занятия. Она может быть и обычно гораздо более развита, но принцип остается тем же — перед каждым сервером размещаются перенаправители, чтобы сделать инфраструктуру более устойчивой к обнаружению, что позволяет операторам быстро заменить сгоревшие серверы на новые:
- Всего 6 серверов
- 3 сервера (фишинг, полезная нагрузка и c2) считаются долгосрочными серверами - мы не хотим, чтобы наши дружелюбные синие команды обнаружили их
- 3 редиректора (ретранслятор smtp, редиректор полезной нагрузки и редиректор c2) — это серверы, которые находятся перед нашими долгосрочными серверами и действуют как прокси. Предполагается, что эти серверы будут обнаружены и сожжены во время боя. Именно здесь вступает в действие часть автоматизации Terraform — поскольку состояние нашей среды определяется в файлах конфигурации Terraform, мы можем восстановить эти сгоревшие серверы практически мгновенно, и операция может продолжаться без больших перерывов.
Настройка инфраструктуры
Поставщики услуг
Инфраструктура моей тестовой команды Red Team построена с использованием следующих сервисов и поставщиков:
- DigitalOcean Droplets для всех серверов и редиректоров
- DigitalOcean DNS - управление для smtp-ретранслятора (фишинговый редиректор) — в основном потому, что нам нужна возможность установить запись PTR DNS для нашего smtp-ретранслятора, чтобы уменьшить вероятность того, что наша фишинговая электронная почта будет классифицирована как спам почтовыми шлюзами целевых пользователей.
- CloudFlare DNS менеджмент для управления записями DNS для любых других доменов, которые указывают на наши долгосрочные серверы.
Однако обратите внимание, что вы можете создавать свои серверы с помощью Amazon AWS или другого популярного поставщика VPS, если он поддерживается Terraform (
Для просмотра ссылки Войди или Зарегистрируйся) . То же самое относится к части управления DNS. Я использовал DigitalOcean и CloudFlare, потому что у меня уже были учетные записи, и они мне нравятся ¯\
(ツ)/¯
Структура файла
Инфраструктура моей красной команды определяется файлами конфигурации состояния terraform, которые в настоящее время организованы следующим образом:
Я думаю, что имена файлов говорят сами за себя, но ниже приведена дополнительная информация о некоторых файлах конфигурации:
- Папка -Configs — все файлы конфигурации, которые были слишком большими или неудобными для изменения во время создания дроплета с помощью поставщиков Terraform. Он включает в себя конфигурации для перенаправителя полезной нагрузки (apache: .htaccess, apache2.conf), перенаправителя smtp (postfix: header_checks — для удаления заголовков электронной почты исходного smtp-сервера, master.cf — общая конфигурация постфикса для TLS и opendkim, opendkim.conf - настройка интеграции DKIM с постфиксом)
- providers - требуется для построения такой инфраструктуры, как DigitalOcean и CloudFlare в моем случае
- variables — хранит ключи API и аналогичные данные, используемые в разных файлах состояния terraform.
- sshkeys — хранит ssh-ключи, с которых наши серверы и редиректоры будут принимать вход в систему.
- dns — определяет записи DNS и указывает, как можно получить доступ к нашим серверам и редиректорам.
- брандмауэры - определить правила доступа - кто может получить доступ к какому серверу
- outputs — файл, который выводит ключевые IP-адреса и доменные имена построенной инфраструктуры
Другие ключевые моменты по паре файлов изложены ниже.
Переменные
Variables.tf хранит такие вещи, как токены API, имена доменов для редиректоров и c2, IP-адреса операторов, которые используются в правилах брандмауэра (т. е. разрешают входящие подключения к командному серверу или GoPhish только с IP-адреса, принадлежащего оператору):
Кроме того, variable.tf содержит ссылку на защищенный паролем zip-архив Cobalt Strike и сам пароль:
С2
Для этой лабораторной я выбрал Cobalt Strike в качестве C2-сервера.
Ниже приведен remote-exec Terraform для сервера C2, который загружает CS zip, распаковывает его с заданным паролем CS и создает задание cron, чтобы убедиться, что сервер C2 запущен после загрузки сервера:
C2 редиректор
Я использую socat, чтобы просто перенаправить весь входящий трафик через порты 80 и 443 на основной сервер HTTP C2, на котором работает командный сервер Cobalt Strike:
Тестирование C2 и C2 редиректора
Легко проверить, работают ли ваш C2 и его редиректоры должным образом.
Примечание ниже — пара полных доменных имен, которые были распечатаны Terraform при выполнении файла outputs.tf: static.redteam.me и ads.redteam.me оба указывают на 159.203.122.243 — это IP-адрес редиректора C2 — любой трафик на порту 80 и 443 будут перенаправлены на главный сервер C2, который размещен по адресу 68.183.150.191, как показано на втором изображении ниже:
Ниже гифка показывает тест в действии, а шаги следующие:
1. Cobalt Strike запускается и подключается к основному C2-серверу, расположенному по адресу 68.183.150.191, доступ к которому осуществляется через css.ired.team.
2. Создается новый слушатель на порту 443 на хосте C2 68.183.150.191.
3. Маячок hostsname настроен на два поддомена на редиректоре C2 - static.redteam.me и ads.redteam.me
4. Бесступенчатый маячок генерируется и выполняется в целевой системе через SMB.
5. Маячок обращается к *.redteam.me, который перенаправляет трафик на командный сервер C2 по адресу 68.183.150.191, и мы видим всплывающее окно сеанса CS:
Ниже приведен скриншот tcpdump на сервере C2, который показывает, что IP-адрес перенаправителя (organge, 159.203.122.243) инициировал подключение к C2 (синий, 68.183.150.191):
Фишинг
На моем фишинговом сервере работает платформа GoPhish, о которой я рассказываю здесь:
Для просмотра ссылки Войди или Зарегистрируйся
GoPhish настроен на прослушивание порта 3333, который я открываю для Интернета, но разрешаю доступ только оператору, использующему брандмауэры DigitalOcean:
Опять же - var.operator-ip прописывается в variable.tf
Фишинговый редиректор
Это была самая трудоемкая часть для настройки. Известно, что настройка SMTP-серверов обычно представляет собой огромную боль. Стоит автоматизировать инфраструктуру красной команды только потому, что вам никогда не придется перестраивать SMTP-сервер с нуля, если он сгорит во время боя.
Боль для этой части возникла из-за настройки релея smtp, поскольку в нем было несколько активных частей:
- настройка SPF-записей
- настройка ДКИМ
- настройка шифрования
- настройка постфикса как ретранслятора
- очистка заголовков электронной почты для сокрытия исходного почтового сервера (фишингового сервера)
Тестирование фишингового редиректора
После того, как инфраструктура настроена, DNS-зона фишингового редиректора (smtp relay) должна иметь записи spf, dkim и dmarc, аналогичные приведенным здесь:
После того, как записи DNS сделаны, мы можем отправить быстрое тестовое электронное письмо на gmail с фактического фишингового сервера через сервер ретрансляции и посмотреть, проверяют ли spf, dkim и dmarc PASS, что, как мы видим ниже, они сделали в нашем случае, предполагая фишинг/smtp реле настроено правильно:
telnet redteam.me 25
helo redteam.me
mail from: olasenor@redteam.me
rcpt to: mantvydo@gmail.com
data
to: Mantvydas Baranauskas <mantvydo@gmail.com>
from: Ola Senor <olasenor@redteam.me>
subject: daily report
Hey Mantvydas,
As you were requesting last week - attaching as promised the documents needed to keep the project going forward.
Перенаправитель полезной нагрузки
Сервер перенаправления полезной нагрузки построен на модулях apache2 mod_rewrite и прокси. Модуль Mod_rewrite позволяет нам писать подробные правила перезаписи URL-адресов и HTTP-запросы прокси-жертвы для соответствующих полезных данных, которые оператор сочтет целесообразными.
Ниже приведен файл .htaccess, который инструктирует apache, или, если быть точным, модуль mod_rewrite, когда, где и как (например, прокси или перенаправление) переписывать входящие HTTP-запросы:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "android|blackberry|googlebot-mobile|iemobile|ipad|iphone|ipod|opera mobile|palmos|webos" [NC]
RewriteRule ^.*$ Для просмотра ссылки Войди или Зарегистрируйся [P]
RewriteRule ^.*$ Для просмотра ссылки Войди или Зарегистрируйся{REQUEST_URI} [P]
Разбивка файла:
- Строка 2 по сути говорит: эй, apache, если вы видите входящий HTTP-запрос с пользовательским агентом, который содержит любое из слов "android, blackberry, ..." и т. д., перейдите к строке 3.
- Строка 3 инструктирует apache проксировать ([P]) http-запрос на
Для просмотра ссылки Войди или Зарегистрируйся условие в строке 2 не выполняется, перейти к строке 4
- Если условие в строке 2 не выполняется, HTTP-запрос передается на
Для просмотра ссылки Войди или Зарегистрируйся{REQUEST_URI}, где REQUEST_URI — это часть http-запроса, добавленная после имени домена, т. е. someDomain.com/?thisIsTheRequestUri=true.
Скриншот ниже должен иллюстрировать вышеуказанную концепцию:
1. Зеленая подсветка — мы использовали curl (и его UA по умолчанию), который, согласно файлу .htaccess, должен был перенаправить нас на payloadURLForOtherClients — что, как мы видим, он пытался сделать, но, конечно, потерпел неудачу, поскольку это тест и неразрешимая хост указан
2. Розовый цвет — мы снова свернули редиректор полезной нагрузки, но на этот раз с поддельным UA, маскируя HTTP-запрос, как если бы он исходил от iphone — мы видим, что apache правильно попытался передать запрос через хост payloadURLForMobiles :
Вывод
Outputs.tf содержит DNS-имена ключевых серверов и их IP-адреса для справки оператору:
Также обратите внимание на последний выделенный бит — указание оператору выполнить команду ./finalize.sh из рабочего каталога. Он установит сертификаты LetsEncrypt на сервер ретрансляции smtp, а также распечатает TXT-запись DKIM DNS, которую необходимо добавить в записи DNS DigitalOcean для домена ретрансляции smtp:
Для удобства создается DNS-запись mail._domainkey с фиктивным значением "Я DKIM, но измените DKIM из finalize.sh" (файл dns.tr) — это значение необходимо заменить выделенным выше значением DKIM. Это предоставляется сценарием finalize.sh.
В идеале этот шаг должен быть автоматизирован во время начальной загрузки дроплета, но я пока не мог этого сделать из-за некоторых ошибок Terraform, с которыми столкнулся.
Ниже показаны (сверху вниз):
- Конфигурация terraform, которая устанавливает новый заполнитель записи DNS TXT для DKIM.
- Тerraform создание записи DNS TXT на основе приведенной выше конфигурации из dns.tf
- Фактический результат - заполнитель записи DNS TXT для домена redteam.me
Скачать и попробовать
Если вы хотите протестировать эту настройку, не стесняйтесь загружать файлы конфигурации отсюда:
Для просмотра ссылки Войди или Зарегистрируйся
Disposable and resilient red team infrastructure with Terraform - GitHub - mantvydasb/Red-Team-Infrastructure-Automation: Disposable and resilient red team infrastructure with Terraform
github.com
EfAuLTWEbPRoxy;