Создание инфраструктуры для Red Team

Введение

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

Следующие вопросы намечают план этой статьи в блоге:   

Какие требования должны быть выполнены?

   Из каких компонентов состоит инфраструктура "красной команды"?

   Какое программное обеспечение может быть использовано?

   Как настраиваются эти компоненты?

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

Требования

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

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

Обзор компонентов

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

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

   Phishing/Payload Server: используется для создания и проведения фишинговых кампаний и хранения кода полезной нагрузки для атак.

   C2-Team-Server: центральный коммуникационный и управляющий центр для операторов "красной команды".

   Редиректоры: для почтового, https и dns-трафика. Служат прокси-серверами для трафика и защищают основные ресурсы.

   [Опционально] Vaultwarden: представляет собой решение для безопасного хранения данных на время работы, например, для секретов или собранных учетных данных.

   [Опционально] Red ELK: по сути, SOC для "красных" команд, помогает контролировать инфраструктуру и обнаруживать "синие" команды, подглядывающие за вашими активами.

Подробное описание каждого компонента приведено в последующих пунктах.

Разделение сетей

На рисунке также показано разграничение между внутренней сетью и публичным Интернетом. Поскольку редиректоры должны быть доступны через публичный Интернет и маскироваться под легальные web-, dns- или почтовые серверы, они, разумеется, должны иметь публичный IP-адрес.

Основные ресурсы, такие как C2-team-сервер или сервер фишинга и полезной нагрузки, должны быть развернуты в защищенной или внутренней сети. Если это невозможно, то следует, по крайней мере, обеспечить доступ к открытым портам этих машин только для легитимных пользователей. Это можно сделать с помощью ограничений на соединения по определенным IP-адресам или сертификатам. Кроме того, внешний доступ должен быть обеспечен только к необходимым портам, например, SSH- или VPN-портам.

Облачные провайдеры

Что касается облачных провайдеров, то просто выбирайте того, кто вам больше нравится. Лично мы для редиректоров используем AWS, а поскольку в Azure реализовать их приложения довольно просто, мы использовали Azure для экземпляра Outlook. Но для создания инстансов также подойдут CloudFront или Digital Ocean. Более важным является

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

C2-инфраструктура

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

Командный сервер C2

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

Важнейшим решением, которое необходимо принять, является вопрос о том, хотите ли вы (или, скорее, можете ли вы) позволить себе платного C2 или нет.

В течение многих лет Cobalt Strike был отраслевым стандартом для красных команд, но в последние годы появилось много других альтернатив.Фреймворки с открытым исходным кодом становятся все более популярными, особенно среди угрожающих субъектов.Причина их использования угрозами проста: эти C2 не так широко распространены, как Cobalt Strike или другие платные промышленные стандарты C2-фреймворков, и защитным механизмам зачастую не так легко их поймать, поскольку их поведение не так хорошо прослеживается. Дошло даже до того, что первые импланты, сгенерированные Havoc в прошлом году, не были пойманы даже Windows Defender.

Следующие вопросы могут помочь вам в выборе оптимального решения:   Хочу ли я платить за C2?   Какие каналы связи мне нужны?

   Нужен ли мне графический интерфейс?

   Нужно ли мне, чтобы к C2 подключалось несколько операторов?

   На какой операционной системе должен работать C2?

   Какие функции уклонения мне нужны?

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

Тем не менее, она дает хороший обзор существующих C2-фреймворков.

При выборе фреймворка с открытым исходным кодом всегда проверяйте последние релизы и коммиты, чтобы убедиться, что они не сильно устарели.И самое главное, что само собой разумеется, - тестируйте и играйте с выбранным C2.Если вы не можете определиться, всегда есть возможность реализовать два или более C2 и использовать их параллельно.

Лично я решил попробовать Sliver, особенно потому, что он действительно хорошо поддерживается, но, честно говоря, и потому, что он был немного раскручен в то время, когда я начал этот эксперимент. Тем не менее, Sliver не разочаровал. Ниже я перечислил свои личные преимущества и недостатки Sliver:

Некоторые из недостатков могут быть легко устранены, так как это open-source и каждый может помочь в его улучшении.

C2-переадресаторы

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

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

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

HTTPS-переадресатор

Для перенаправления HTTPS-трафика существует два вида подходов. Трафик может перенаправляться через простой пайп у или через обратный web-прокси. Первый вариант, реализуемый с помощью socat или правила IP-таблиц, вслепую перенаправляет трафик, приходящий на определенный порт. Это в основном описывает функциональность, которую можно ожидать от редиректора. В отличие от него, обратный web-прокси позволяет отсеивать нежелательных посетителей на основе таких факторов, как геолокация или пользовательский агент. Это позволяет направить трафик имплантов на свой C2-сервер и показать всем остальным посетителям общий сайт. Этот принцип также показан на рисунке ниже.

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

Варианты программ

Что касается программного обеспечения прокси-сервера, то существует три основных варианта: Apache, Nginx или Caddy. Все они являются приложениями с открытым исходным кодом. Конечно, можно использовать и другой веб-сервер, если он удовлетворяет перечисленным выше критериям.

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

Менее известным и используемым вариантом является Caddy. Я его еще не пробовал, но он обещает простую настройку с автоматической поддержкой HTTPS (через ZeroSSL или Let's Encrypt) для публичных доменов. Большим плюсом является и то, что для работы с Caddy нужен всего один файл "Caddyfile", который и обрабатывает все настройки. Он написан на языке Go и не имеет никаких дополнительных зависимостей. Также было продемонстрировано, что Caddy может быть специально использован в качестве редиректора для C2-трафика.

Настройка

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

Прежде всего, весь трафик, идущий к редиректору и от него, должен быть зашифрован по протоколу HTTPS. В противном случае SOC легко обнаружит ваш имплант, поскольку все передаваемые данные могут быть прочитаны. С точки зрения OPSEC нежелательно иметь незашифрованное соединение с сетью клиента, поскольку любой может подслушать трафик. Кроме того, незашифрованный трафик всегда выделяется, поскольку может быть индикатором подозрительной активности.

Отсюда вытекает следующий вывод: не используйте самоподписанные сертификаты. Простой способ создания действительных сертификатов - использование Let's Encrypt и получение автоматически сгенерированных сертификатов для вашего домена. Вы можете либо сгенерировать сертификат самостоятельно, либо воспользоваться программой Certbot, которая открывает веб-сервер на 80-м порту вашего IP (чтобы убедиться, что домен принадлежит вам на законных основаниях) и выполняет всю работу. Если на 80-м порту работает другой сервис (например, Nginx), то на время работы Certbot этот сервис следует остановить.

Поскольку сертификаты Let's Encrypt бесплатны, их использует множество людей, в том числе и подозрительные личности и мошенники. Поэтому, если у вас есть бюджет, купите сертификаты в любом другом центре сертификации (честно говоря, неважно, в каком именно).

Говоря о выдаче сертификатов на домен: ваш редиректор должен иметь домен, так как соединения по IP-адресам весьма подозрительны. Выберите доменное имя, основываясь на результатах OSINT. Идеальным вариантом может быть что-нибудь связанное с инфраструктурой, кампании/акции, приуроченные к особым событиям, таким как Рождество, или даже домен с именем цели и хорошо скрытой опечаткой в нем.

Если у вас есть время, вам обязательно нужно создать простой, но убедительный веб-сайт. Это существенно повысит доверие к сайту и поможет скрыть истинное назначение веб-сервера (туннелирование имплантируемого трафика).

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

Самая важная часть - скрыть трафик имплантата для C2. Обычно для этого имплант запрашивает определенный каталог или файл на веб-сервере. Затем веб-сервер пересылает весь трафик на сервер C2.

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

В данном примере в качестве редиректора я выбрал Nginx, поэтому следующие параграфы посвящены ему. Тем не менее, аналогичные функции есть и в Apache или Caddy.

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

# map useragents to proxypasses
map $http_user_agent $goodagent {                                                                                                                                        
    default 0;           
    "Supersecretuseragent" 1;
}

[...]

server {

[...]

# C2 route
  location /supersecretlocation/ {
      proxy_ssl_certificate /etc/nginx/https-cert.pem;
      proxy_ssl_certificate_key /etc/nginx/https-key.pem;
      proxy_ssl_verify off;
      proxy_ssl_server_name      on;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass https://localhost:5443;
      if ($goodagent = 0) {
      return 404;
 }
  }
 } 

На первом этапе необходимо классифицировать различные агенты пользователя. Как видно, переменная $goodagent  устанавливается в false для любого агента пользователя, кроме Supersecretuseragent. В серверном блоке определяется proxy_pass для маршрута supersecretlocation  Именно этот маршрут будет запрашивать маяк с пользовательским агентом Supersecretuseragent. Само прокси-соединение перенаправляется на https://localhost:5443. Причина этого, как будет показано далее, в том, что соединение от C2 к редиректору решается через ssh и удаленный проброс портов. Если запрос приходит с пользовательским агентом, не отнесенным к категории $goodagent , то будет выдана ошибка 404.

Можно реализовать и другое ограничение, основанное на геолокации. Для этого используется база данных MaxMind, которая сопоставляет IP-адреса со странами. В конфигурации Nginx на эти страны можно ссылаться и назначать их различным ответам сервера. Процесс ограничения аналогичен ограничению пользовательских агентов.

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

  1. убедиться в актуальности внедренной версии

   2.удалить все экземпляры номера версии

   3.изменить учетные данные по умолчанию (если применимо)

   4.удалить все ненужные файлы (например, Changelogs, Publisher Notes и т.д.)

   5.удалить все метаданные из файлов и мультимедиа

   6.удалить комментарии в коде

   7.проверить и очистить все данные сертификата.

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

DNS-переадресатор

Для DNS-переадресатора нет необходимости в специфической службе DNS на самом переадресаторе. Поскольку трафик только пересылается, но не обрабатывается, существует два основных варианта: socat или iptables. Iptables может предложить несколько больше возможностей, поскольку можно указать IP-диапазон входящего трафика и реализовать правила пересылки для IP-адресов, не входящих в этот диапазон. С другой стороны, socat несколько проще и быстрее в настройке.

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

Для корректной работы редиректора необходимо выполнить еще несколько шагов. Эти шаги зависят от конкретного C2. В основном необходимо зарегистрировать запись A, а также запись NS для (под)домена вашего редиректора. Для Sliver имеется подробное руководство в официальной Wiki.

Инфраструктура фишинга/платежей

Эта часть инфраструктуры состоит из трех компонентов: собственно фишингового/платежного сервера, редиректора Postfix и экземпляра Outlook в облаке Azure. Фишинговый/платежный сервер содержит собственно фишинговое программное обеспечение и выполняет функции хранилища для stage-1-платежей (staged payloads состоят из небольшого фрагмента кода stage-0, который выполняется целью и загружает собственно полезную нагрузку, так называемый stage-1). Редиректор Postfix используется для изменения или удаления подозрительных заголовков писем, а экземпляр Outlook необходим для придания письмам более доверительного вида. Кроме того, если с адресата будет отправлен ответ на письмо, то общение может быть продолжено из почтового ящика Outlook.

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

Фишинг/сервер полезной нагрузки

В области фишингового программного обеспечения Gophish является стандартом на протяжении многих лет. Он помогает создавать поддельные сайты, отслеживать клики или персонализировать ссылки с помощью идентификаторов, чтобы определить поведение определенных пользователей. Gophish также поставляется с веб-сервером для поддельных сайтов или stage-1-payloads. Таким образом, если перед экземпляром Gophish поставить HTTPS-переадресатор, то его можно использовать как комбинированный фишинговый и платежный сервис. В остальном GoPhish неплохо справляется со своей задачей. Приходится делать небольшие настройки OPSEC, но это связано с тем, что GoPhish ориентирован только на фишинговые атаки и использует не слишком заметные заголовки, содержащие значение "gophish", чтобы отличить их от настоящих фишинговых писем. Поскольку это является явным индикатором для защитных механизмов, эти заголовки должны быть удалены (это будет сделано редиректором Postfix).

Процесс настройки

Прежде всего, необходимо зарегистрировать свой домен в DNS-службе, а затем настроить все необходимые DNS-записи. В данном случае я использовал Route 53, так как он позволяет легко настроить Terraform, но можно использовать и любой другой DNS-сервис (например, собственный deSEC компании SSE). Необходимо установить следующие записи: A, MX, SPF, DMARC, DKIM. Если этого еще не произошло, приобретите также лицензию MS Office365 или Outlook. Затем запустите экземпляр Outlook в Azure и выполните описанные ниже действия по подключению компонентов.

Процесс использования Office365 в качестве SMTP-релея уже пошагово описан в этом блоге. В следующих абзацах я кратко подведу итоги процесса и добавлю некоторую информацию, имеющую отношение к фишингу. Во-первых, реализуется хост MS365. Для этого необходимо настроить Azure-бокс с MS Office365 и включить SMTP-аутентификацию для одной учетной записи пользователя (той, которую вы планируете использовать для пересылки).

Затем необходимо настроить экземпляр Postfix на внутреннем сервере. После его установки (для Ubuntu это просто apt-get) необходимо создать и захешировать некоторые конфигурационные файлы. Если следовать вышеупомянутой статье в блоге, то это довольно просто. К этому моменту Gophish не знает, что используется редиректор. Это можно изменить с помощью "Sending Profiles", который можно создать через пользовательский интерфейс Gophish и в который нужно просто добавить значения вашего Postfix-сервера.

После этого необходимо удалить заголовки, которые Gophish посылает вместе с письмом, иначе фишинговое письмо будет мгновенно распознано и заблокировано почтовыми серверами. Очистка почтовых заголовков осуществляется в основном за счет интеграции в Postfix файла "header_checks". Этот файл указывает Postfix, как обрабатывать те или иные заголовки. В нашем случае это означает, что нужно найти определенные заголовки и либо удалить их, либо перезаписать значения. Помимо заголовков, содержащих ваш IP-адрес и имя хоста или домена, файл должен обрабатывать заголовок "X-Mailer", поскольку он специфичен для Gophish и является явным индикатором фишинга. Кроме того, в главном конфигурационном файле Postfix (main.cf) переменная myhostname должна быть установлена на что-нибудь подозрительное, например на поддомен вашего фишингового домена (например, на mail.domain.com).

Ниже приведен пример того, как может выглядеть файл header_checks.cf программы Postfix:

      /^Received:/ IGNORE
      /^X-Mailer:/ IGNORE
      /^Message-ID:/ IGNORE
      /^User-Agent:/ IGNORE
      /^X-Originating-IP:/    IGNORE
      /^Mime-Version:/        IGNORE
      /^In-Reply-To:/ IGNORE
      /^References:/ IGNORE

После настройки Gophish-сервера отправьте несколько тестовых писем и проанализируйте нестандартные или подозрительные заголовки. Может помочь поиск по имени используемого хоста, выражений типа "phish" и всего, что связано с IP-адресом или именем хоста сервера Gophish.

Соединения

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

В данной инфраструктуре необходимо три соединения между серверами:

   C2-team-сервер - HTTPS-редиректор (связь с имплантом)

   C2-team-сервер к DNS-редиректору (связь с имплантом)

Сервер полезной нагрузки к HTTPS-редиректору ("этап-1-посылка").

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

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

[Unit]
Description=AutoSSH tunnel to DNS-Redirector
After=network.target
[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -q -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 5353:localhost:53 -i <SSH-KEY> <USER>@<DNS_Redirector_IP>
[Install]
WantedBy=multi-user.target

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

Автоматизация процесса настройки

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

Я использовал их следующим образом: Terraform - для настройки боксов AWS, Vagrant - для настройки боксов во внутренней сети, а Ansible - для автоматизации установки программного обеспечения и всего остального, что следует за установкой операционной системы машины. Сюда входят веб-серверы, ssh-соединения, сертификаты, перемещение файлов и многое другое. Кроме того, все эти три инструмента могут быть органично переплетены между собой и работать как одно целое. В зависимости от размера инфраструктуры имеет смысл создавать сценарии автоматизации по модульному принципу, например, с использованием ролей Ansible для каждого узла. Пример автоматизации создания "красной команды" с помощью Terraform и Digital Ocean можно найти в этом блоге.

Заключение

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

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

Какие требования должны быть выполнены?

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

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

Из каких компонентов состоит инфраструктура "красной команды"?

Основную инфраструктуру можно разделить на фишинговую инфраструктуру и C2-инфраструктуру. Каждая из них содержит основной компонент (фишинговый/платежный сервер или C2-сервер) и несколько редиректоров.

Для C2-инфраструктуры это редиректоры, используемые для перенаправления маячкового трафика и защиты основного C2-сервера. Рекомендуется использовать как минимум два различных редиректора: один для основного маячкового трафика с использованием быстрого протокола типа HTTPS и один резервный канал с использованием более тонкого протокола типа DNS.

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

Какое программное обеспечение может быть использовано?

Этот вопрос не имеет однозначного ответа, поскольку зависит от индивидуальных предпочтений и бюджета. Что касается почтовой инфраструктуры, то здесь ответ более или менее однозначен, так как Gophish в настоящее время является де-факто отраслевым стандартом. В сочетании с редиректором Postfix и экземпляром Microsoft Outlook в качестве почтового ретранслятора это, на мой взгляд, оптимальный выбор.

Выбор C2-фреймворка предоставляет гораздо больше возможностей, поскольку приходится выбирать между платными и открытыми фреймворками. Для платных фреймворков я бы выбрал Cobalt Strike, Brute Ratel или Nighthawk. Что касается бесплатных фреймворков, то на данный момент я бы выбрал Sliver, Havoc или Mythic.

В качестве редиректоров для C2-трафика можно выбрать Apache, Nginx или Caddy для HTTPS-редиректора и Socat или IPtables для DNS-редиректора.

original: https://www.securesystems.de/blog/building-a-red-team-infrastructure-in-2023/