Вики для сбора ресурсов по укреплению инфраструктуры Red Team
Эта вики предназначена для предоставления ресурса по настройке устойчивой инфраструктуры Red Team. Она была создана в дополнение к докладу Стива Бороша (@424f424f) и Джеффа Диммока (@bluscreenofjeff) на BSides NoVa 2017 «Doomsday Preppers: Fortifying Your Red Team Infrastructure» (слайды)
Если вы хотите что-то добавить, пожалуйста, отправьте Pull Request или создайте issue в репозитории.
СПАСИБО всем авторам контента, на который ссылается эта вики, и всем, кто внес свой вклад!
При проектировании инфраструктуры Red Team, которая должна выдерживать активное противодействие или работать в рамках долгосрочного задания (недели, месяцы, годы), важно разделять каждый актив по функции. Это обеспечивает устойчивость и гибкость против Blue Team, когда активы кампании начинают обнаруживаться. Например, если фишинговое письмо оценки было идентифицировано, Red Team потребуется создать только новый SMTP-сервер и сервер размещения полезных нагрузок, а не настраивать всю командную инфраструктуру заново.
Рассмотрите возможность разделения этих функций на разных активах:
Каждая из этих функций, скорее всего, потребуется для каждой кампании социальной инженерии. Поскольку активное реагирование на инциденты является типичным для оценки Red Team, для каждой кампании следует разворачивать новый набор инфраструктуры.
Для повышения устойчивости и скрытности перед каждым внутренним активом (например, командным сервером) следует размещать редиректор. Цель — всегда иметь хост между нашей целью и нашими внутренними серверами. Такая настройка инфраструктуры делает развертывание новой инфраструктуры гораздо более быстрым и простым — нет необходимости поднимать новый командный сервер, переносить сессии и переподключать несгоревшие активы на внутреннем уровне.
Распространенные типы редиректоров:
Для каждого типа редиректора существует несколько вариантов реализации, которые лучше всего подходят для разных сценариев. Эти варианты подробно рассматриваются в разделе Редиректоры вики. Редиректоры могут быть VPS-хостами, выделенными серверами или даже приложениями, работающими на экземпляре Platform-as-a-Service.
Вот примерная схема с учетом функционального разделения и использования редиректоров:
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
Воспринимаемая репутация домена будет сильно различаться в зависимости от продуктов, используемых вашей целью, а также от их конфигурации. Таким образом, выбор домена, который будет работать на вашей цели, — это не точная наука. Сбор разведданных из открытых источников (OSINT) будет критически важен для наилучшего предположения о состоянии средств контроля и о том, какие ресурсы использовать для проверки доменов. К счастью, онлайн-рекламодатели сталкиваются с теми же проблемами и создали некоторые решения, которые мы можем использовать.
expireddomains.net — это поисковая система по недавно истекшим или удаленным доменам. Она предоставляет поиск и расширенную фильтрацию, такую как возраст истечения, количество обратных ссылок, количество снимков Archive.org, оценку SimilarWeb. Используя сайт, мы можем регистрировать ранее использовавшиеся домены, которые будут иметь возраст домена, выглядеть похожими на нашу цель, выглядеть похожими на нашу имитацию или просто с высокой вероятностью не выделяться в сети нашей цели.
При выборе домена для C2 или эксфильтрации данных рассмотрите возможность выбора домена, отнесенного к категории «Финансы» или «Здравоохранение». Многие организации не выполняют SSL-прослушивание (middling) для этих категорий из-за возможных юридических проблем или проблем с чувствительностью данных. Также важно убедиться, что выбранный домен не связан с предыдущими кампаниями вредоносного ПО или фишинга.
Инструмент CatMyFish от Чарльза Гамильтона (@MrUn1k0d3r) автоматизирует поиск и проверку веб-категоризации с помощью expireddomains.net и BlueCoat. Его можно модифицировать для применения дополнительных фильтров к поиску или даже для долгосрочного мониторинга регистрируемых активов.
Другой инструмент, DomainHunter от Джо Веста (@joevest) и Эндрю Чайлза (@andrewchiles), возвращает категоризацию BlueCoat/WebPulse, IBM X-Force и Cisco Talos, возраст домена, альтернативные доступные TLD, ссылки Archive.org и HTML-отчет. Кроме того, он выполняет проверки на использование в известных кампаниях вредоносного ПО и фишинга с помощью Malwaredomains.com и MXToolBox. Этот инструмент также включает поддержку OCR для обхода капч BlueCoat/WebPulse. Ознакомьтесь с записью в блоге о первоначальном выпуске инструмента для получения более подробной информации.
Еще один инструмент, AIRMASTER от Макса Харли (@Max_68), использует expireddomains.net и Bluecoat для поиска категоризированных доменов. Этот инструмент использует OCR для обхода капчи BlueCoat, что увеличивает скорость поиска.
Если ранее зарегистрированный домен недоступен или вы предпочитаете самостоятельно зарегистрированный домен, можно категоризировать домены самостоятельно. Используйте прямые ссылки ниже или такой инструмент, как Chameleon от Доминика Челла (@domchell). Большинство продуктов категоризации будут игнорировать редиректы или клонированный контент при определении категории домена. Для получения дополнительной информации об использовании Chameleon ознакомьтесь с постом Доминика Categorisation is not a security boundary.
Наконец, убедитесь, что ваши DNS-настройки правильно распространились.
Слова «простой» и «фишинг» редко сочетаются. Настройка правильной фишинговой инфраструктуры может быть настоящей болью. Следующее руководство предоставит вам знания и инструменты для быстрой настройки фишингового сервера, который проходит «большинство» современных спам-фильтров и предоставляет вам интерфейс RoundCube для простого фишинга, включая двустороннюю связь с вашей целью. В сети существует множество настроек и постов о фишинге. Это лишь один из методов.
Как только у вас будет домен, прошедший соответствующие проверки, перечисленные в предыдущем разделе, и ваш фишинговый сервер будет запущен, вам нужно будет создать пару записей «A» для вашего домена, как показано на рисунке.
Затем подключитесь по ssh к вашему фишинговому серверу и убедитесь, что у вас есть правильное FQDN-имя хоста в вашем /etc/hosts. Пример «127.0.0.1 email.yourphishingserver.com email localhost»
Теперь вы установите веб-интерфейс для фишинга всего за несколько простых шагов. Начните с загрузки последней «BETA» версии iRedMail на ваш фишинговый сервер. Простой способ — щелкнуть правой кнопкой мыши по кнопке загрузки, скопировать адрес ссылки и использовать wget для загрузки непосредственно на ваш фишинговый сервер. Затем распакуйте архив «tar -xvf iRedMail-0.9.8-beta2.tar.bz2». Перейдите в распакованную папку и сделайте скрипт iRedMail.sh исполняемым (chmod +x iRedMail.sh). Выполните скрипт от имени root, следуйте подсказкам, и вам нужно будет перезагрузиться, чтобы завершить все.
Вам нужно убедиться, что у вас есть все правильные DNS-записи, указывающие на ваш почтовый сервер. (https://docs.iredmail.org/setup.dns.html). Для DKIM новая команда должна быть «amavisd-new showkeys» для вывода вашего DKIM-ключа.
Для DMARC мы можем использовать (https://www.unlocktheinbox.com/dmarcwizard/) для генерации нашей записи dmarc.
Теперь создайте пользователя для фишинга.
Войдите в интерфейс RoundCube с вашим новым пользователем и фишингуйте ответственно!
Cobalt Strike предоставляет настраиваемую функциональность spearphishing для поддержки фишинга по электронной почте в рамках пентеста или Red Team. Он поддерживает шаблоны в форматах HTML и/или обычного текста, вложения, обратный адрес, встраивание URL, использование удаленного SMTP-сервера и задержки отправки для каждого сообщения. Еще одна интересная функция — возможность добавления уникального токена к встроенному URL каждого пользователя для отслеживания кликов.
Для получения более подробной информации ознакомьтесь с этими ресурсами:
Для упражнений Red Team и фишинга, где важны доверие клиента и OPSEC, хранение перехваченных клиентских данных и основной инфраструктуры на собственных серверах заказчика (on-premises) дает значительные преимущества по сравнению с облачными решениями. Этот подход использует облачные активы только для тонких редиректоров и фронтов, сохраняя чувствительные операции внутри.
Надежная локальная настройка Evilginx обычно состоит из:
Ограничение по cookie снижает количество ботов и автоматического сканирования, требуя определенный cookie для доступа к фишинговому порталу:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Это правило перенаправляет запросы на портальный домен, которые не содержат требуемого cookie, при этом исключая запросы к favicon, чтобы предотвратить циклы перенаправления.
### Пример конфигурации Caddy```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Запустите Evilginx на внутреннем узле с соответствующими флагами:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Важно:** Evilginx должен быть доступен только из частной сети; никогда не публикуйте его IP-адрес в публичном DNS.
### Контрольный список OPSEC и усиления безопасности
1. **Никогда не публикуйте IP-адреса Evilginx в публичном DNS** — используйте только частную сеть
2. **Храните чувствительные данные только на клиентских серверах** — редиректоры не должны хранить перехваченные учетные данные
3. **Усильте редиректоры** — ротируйте домены, используйте короткие TTL, разворачивайте несколько эфемерных редиректоров
4. **Внедрите правила WAF/межсетевого экрана** — используйте проверки cookie, списки разрешенных IP или валидацию User-Agent
5. **Разделите ведение журналов и хранение** — храните журналы доступа на Caddy, а журналы перехвата — на хосте Evilginx
6. **Избегайте отпечатков** — не используйте предсказуемые шаблоны или идентичные TLS-отпечатки
Такой гибридный подход (публичный редиректор/частный перехват) обеспечивает устойчивость облачного фронтинга, сохраняя при этом преимущества безопасности и юридические преимущества хранения чувствительных операций локально.
## Фреймворки для фишинга
Помимо создания собственной фишинговой инфраструктуры или использования фреймворка для пентеста или red teaming, такого как Cobalt Strike, существует множество инструментов и фреймворков, предназначенных для фишинга по электронной почте. Хотя эта вики не будет подробно описывать каждый фреймворк, ниже собраны несколько ресурсов для каждого из них:
### Gophish
* [Официальный сайт Gophish](https://getgophish.com/)
* [Репозиторий Gophish на GitHub](https://github.com/gophish/gophish)
* [Руководство пользователя Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Официальный сайт Phishing Frenzy](https://www.phishingfrenzy.com/)
* [Репозиторий Phishing Frenzy на GitHub](https://github.com/pentestgeek/phishing-frenzy)
* [Знакомство с Phishing Frenzy — Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [Репозиторий The Social-Engineer Toolkit на GitHub](https://github.com/trustedsec/social-engineer-toolkit)
* [Руководство пользователя The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (ранее FirePhish)
* [Репозиторий FiercePhish на GitHub](https://github.com/Raikia/FiercePhish)
* [Вики FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# Редиректоры
## SMTP
«Редиректор» может быть не лучшим словом для описания того, что мы собираемся сделать, но цель та же, что и при нашей другой редирекции. Мы хотим удалить любые следы нашего фишингового происхождения из итоговых заголовков электронных писем и обеспечить буфер между жертвой и нашим бэкенд-сервером. В идеале SMTP-редиректор должен быть быстрым в настройке и простым в выводе из эксплуатации.
Есть два ключевых действия, которые мы хотим настроить для выполнения SMTP-редиректором:
### Sendmail
#### Удаление предыдущих серверных заголовков
Добавьте следующую строку в конец `/etc/mail/sendmail.mc`:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Добавьте в конец /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Настройка адреса catch-all
Это позволит перенаправлять любые письма, полученные на *@phishdomain.com, на выбранный адрес электронной почты. Это крайне полезно для получения любых ответов или сообщений о недоставке (bounce-backs) на фишинговое письмо.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Добавьте следующую строку непосредственно перед //Mailer Definitions// (ближе к концу) в /etc/mail/sendmail.mc:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Добавьте следующую строку в конец `/etc/mail/virtusertable`:```bash
@phishdomain.com external-relay-address
Примечание: Два поля должны быть разделены табуляцией
Postfix предоставляет более простую альтернативу sendmail с более широкой совместимостью. Postfix также предлагает полную поддержку IMAP с Dovecot. Это позволяет тестировщикам общаться в реальном времени с целями фишинга, которые отвечают на исходное сообщение, а не полагаться на catch-all адрес и необходимость создавать новое сообщение с помощью вашего фишингового инструмента.
Полное руководство по настройке почтового сервера Postfix для фишинга доступно в посте Джулиана Катрамбона (@n0pe_sled) Mail Servers Made Easy.
Примечание: При использовании C2-редиректоров на вашем фреймворке пост-эксплуатации следует настроить внешний слушатель для отправки staging-трафика через домен редиректора. Это заставит скомпрометированный хост проходить staging через редиректор, как и сам C2-трафик.
socat можно использовать для перенаправления входящих DNS-пакетов на порту 53 на наш командный сервер. Хотя этот метод работает, некоторые пользователи сообщали о проблемах со staging в Cobalt Strike или задержках при использовании этого метода. Изменено 21.04.2017: Следующая команда socat, судя по всему, работает хорошо благодаря тестированию от @xorrior:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables для DNS
Было обнаружено, что правила перенаправления DNS в iptables хорошо работают с Cobalt Strike. Похоже, что здесь нет тех проблем, которые возникают у socat при обработке трафика такого типа.
Пример набора правил DNS-редиректора приведён ниже.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Также измените политику цепочки "FORWARD" на "ACCEPT"
Некоторые могут иметь требование или необходимость разместить c2-сервер во внутренней сети. Используя комбинацию IPTABLES, SOCAT и обратных SSH-туннелей, мы, безусловно, можем добиться этого следующим образом.
В этом сценарии наш непостоянный редиректор использует IPTables для перенаправления всего DNS-трафика с помощью правила, описанного ранее в этом разделе. Далее мы создаем обратный SSH-туннель с перенаправлением портов от нашего внутреннего c2-сервера к нашему основному редиректору. Это перенаправит любой трафик, который основной редиректор получает на порту 6667, на внутренний c2-сервер на порту 6667. Теперь запустите socat на нашем командном сервере, чтобы разветвлять любой входящий TCP-трафик на порту 6667 в UDP-порт 53, который и должен прослушивать наш DNS c2. Наконец, мы аналогичным образом настраиваем экземпляр socat на основном редиректоре, чтобы перенаправлять любой входящий UDP-трафик на порту 53 в наш SSH-туннель на порту 6667.
Примечание: При использовании C2-редиректоров на вашем фреймворке пост-эксплуатации следует настроить внешний слушатель для отправки staging-трафика через домен редиректора. Это заставит скомпрометированный хост проходить этап staging через редиректор, как и сам C2-трафик.
socat обеспечивает перенаправление типа «тупой канал». Любой запрос, который socat получает на указанном исходном интерфейсе/порту, перенаправляется на целевой IP/порт. Фильтрации или условного перенаправления нет. Apache mod_rewrite, с другой стороны, предоставляет ряд методов для усиления вашего фишинга и повышения устойчивости вашей тестовой инфраструктуры. mod_rewrite способен выполнять условное перенаправление на основе атрибутов запроса, таких как URI, user agent, строка запроса, операционная система и IP. Apache mod_rewrite использует файлы htaccess для настройки наборов правил, определяющих, как Apache должен обрабатывать каждый входящий запрос. Используя эти правила, вы можете, например, перенаправлять запросы к вашему серверу с user agent по умолчанию от wget на легитимную страницу на сайте вашей цели.
Короче говоря, если вашему редиректору требуется условное перенаправление или расширенная фильтрация, используйте Apache mod_rewrite. В противном случае достаточно перенаправления через socat с необязательной фильтрацией iptables.
socat можно использовать для перенаправления любых входящих TCP-пакетов на указанном порту на наш командный сервер.
Базовый синтаксис для перенаправления TCP-порта 80 на localhost на порт 80 другого хоста выглядит следующим образом:``` socat TCP4-LISTEN:80,fork TCP4::80
Если ваш редиректор настроен с более чем одним сетевым интерфейсом, socat можно привязать к конкретному интерфейсу по IP-адресу с помощью следующего синтаксиса:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
В этом примере 10.0.0.2 — один из локальных IP-адресов редиректора, а 1.2.3.4 — IP-адрес удалённого сервера команды.
Помимо socat, iptables может выполнять перенаправление «тупого канала» через NAT. Чтобы переслать локальный порт 80 редиректора на удалённый хост, используйте следующий синтаксис:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH для HTTP
Ранее мы рассматривали использование SSH для DNS-туннелей. SSH работает как надёжное и устойчивое средство для пробивания NAT и получения способа для импланта подключиться к редиректору и в вашу серверную среду. Перед настройкой SSH-редиректора необходимо добавить следующие строки в `/etc/ssh/sshd_config`:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Чтобы перенаправить локальный порт 80 редиректора на ваш внутренний сервер, используйте следующий синтаксис на внутреннем сервере:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
Вы также можете пробросить более одного порта, например, если вы хотите, чтобы 443 и 80 были открыты одновременно:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
При обслуживании полезных нагрузок и веб-ресурсов мы хотим минимизировать возможность для специалистов по реагированию на инциденты просматривать файлы и повысить шансы на успешное выполнение полезной нагрузки, будь то для установки C2 или сбора разведданных.
Примеры использования Apache Mod_Rewrite от Джеффа Диммока:
Другие примеры использования Apache mod_rewrite:
Для автоматической настройки Apache Mod_Rewrite на сервере-редиректоре ознакомьтесь с записью в блоге Джулиана Катрамбоуна (@n0pe_sled) Mod_Rewrite Automatic Setup и сопутствующим инструментом.
Цель перенаправления трафика C2 двояка: скрыть внутренний командный сервер и выглядеть как легитимный веб-сайт, если на него зайдёт специалист по реагированию на инциденты. Используя Apache mod_rewrite и настроенные профили C2 или другие методы проксирования (например, с помощью Flask), мы можем надёжно отделять реальный трафик C2 от трафика расследований.
Развивая тему «Перенаправление C2» выше, ещё один метод — настроить ваш сервер-редиректор на использование SSL Proxy Engine от Apache для приёма входящих SSL-запросов и проксирования их на reverse-HTTPS слушатель. Шифрование используется на всех этапах, и вы можете ротировать SSL-сертификаты на вашем редиректоре по мере необходимости.
Чтобы это работало с вашими правилами mod_rewrite, вам нужно разместить свои правила в «/etc/apache2/sites-available/000-default-le-ssl.conf», при условии, что вы использовали LetsEncrypt (также известный как CertBot) для установки сертификата. Кроме того, для включения движка SSL ProxyPass вам понадобятся следующие строки в том же файле конфигурации:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Другие ресурсы по Apache mod_rewrite
* [Automating Apache mod_rewrite and Cobalt Strike Profiles](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Официальная документация Apache 2.4 по mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [Введение в Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Подробное руководство по mod_rewrite для Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod_rewrite-for-apache--net-6708)
* [Проверка синтаксиса Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# Изменение C2-трафика
## Cobalt Strike
Cobalt Strike изменяет свой трафик с помощью профилей Malleable C2. Профили предоставляют широкие возможности настройки для изменения того, как будет выглядеть C2-трафик вашего сервера в сети. Профили Malleable C2 могут использоваться для усиления уклонения от реагирования на инциденты, имитации известных противников или маскировки под легитимные внутренние приложения, используемые целью.
* [Официальные профили Malleable C2 - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Документация по Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - Путь для повышения привилегий - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [A Brave New World: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [Как писать профили Malleable C2 для Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [In-Memory Evasion (серия видео) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Когда вы начнёте создавать или изменять профили Malleable C2, важно учитывать ограничения размера данных для размещения информации Beacon. Например, настройка профиля на отправку больших объёмов данных в параметре URL потребует множества запросов. Для получения дополнительной информации об этом ознакомьтесь с записью в блоге Raphael Mudge [Beware of Slow Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Если у вас возникли проблемы с профилем Malleable C2 и вы заметили, что консоль teamserver выводит ошибки, обратитесь к записи в блоге Raphael Mudge [Broken Promises and Malleable C2 Profiles](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) за советами по устранению неполадок.
## Empire
Empire использует Communication Profiles, которые предоставляют возможности настройки для URI GET-запросов, user agent и заголовков. Профиль состоит из каждого элемента, разделённого символом вертикальной черты, и задаётся с помощью опции `set DefaultProfile` в контекстном меню `listeners`.
Вот пример профиля по умолчанию:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
Альтернативно, значение DefaultProfile можно задать, изменив файл /setup/setup_database.py до первоначальной настройки Empire. Это изменит профиль связи по умолчанию, который будет использовать Empire.
В дополнение к профилю связи, рассмотрите возможность настройки URI стадийности сервера Empire, заголовков сервера и содержимого веб-страницы по умолчанию, следуя шагам, представленным в посте Джо Веста (@joevest) Empire - Modifying Server C2 Indicators.
Использование доверенных, легитимных веб-сервисов для C2 может дать ценное преимущество по сравнению с использованием доменов и инфраструктуры, настроенных вами самостоятельно. Время настройки и сложность варьируются в зависимости от используемой техники и сервиса. Популярным примером использования сторонних сервисов для перенаправления C2 является Domain Fronting.
Domain Fronting — это техника, используемая сервисами и приложениями для обхода цензуры, которая направляет трафик через легитимные и пользующиеся высоким доверием домены. Популярные сервисы, поддерживающие Domain Fronting, включают Google App Engine, Amazon CloudFront и Microsoft Azure. Важно отметить, что многие провайдеры, такие как Google и Amazon, внедрили меры противодействия Domain Fronting, поэтому некоторые связанные ресурсы или информация, представленная в этой вики, могут быть устаревшими к моменту вашей попытки их использования.
В двух словах, трафик использует DNS и SNI-имя доверенного поставщика услуг, в примере ниже используется Google. Когда трафик принимается пограничным сервером (например, расположенным на gmail.com), пакет пересылается на исходный сервер (например, phish.appspot.com), указанный в заголовке Host пакета. В зависимости от поставщика услуг, исходный сервер либо напрямую пересылает трафик на указанный домен, который мы направим на наш командный сервер, либо потребуется прокси-приложение для выполнения финального перехода.
Для получения более подробной информации о том, как работает Domain Fronting, см. технический документ Blocking-resistant communication through domain fronting и документацию meek проекта TOR.
В дополнение к стандартным доменам, пригодным для fronting, таким как любой домен google.com, можно использовать и другие легитимные домены для fronting.
Для получения дополнительной информации о поиске доменов, пригодных для fronting, ознакомьтесь с:
Многие провайдеры PaaS и SaaS предоставляют статический поддомен или URL для использования с предоставленным экземпляром. Если связанный домен в целом пользуется высоким доверием, экземпляры могут добавить дополнительное доверие вашей инфраструктуре C2 по сравнению с купленным доменом и VPS.
Чтобы настроить перенаправление, вам необходимо определить сервис, который выдает статический поддомен или URL в рамках экземпляра. Затем экземпляр необходимо настроить на перенаправление на уровне сети или приложения. Экземпляр будет действовать как прокси, аналогично другим редиректорам, описанным в этой вики.
Еще одна интересная техника, заслуживающая дальнейшего исследования, — использование чрезмерно разрешающих корзин Amazon S3 для C2. Ознакомьтесь с постом S3 Buckets for Good and Evil от Andrew Luke (@Sw4mp_f0x) для получения более подробной информации о том, как корзины S3 могут использоваться для C2. Эту технику можно комбинировать с возможностями стороннего C2 в Empire, чтобы использовать легитимные корзины S3 цели против нее самой.
Еще один пример использования PaaS для C2 — Databases and Clouds: SQL Server as a C2 от Scott Sutherland (@_nullbind).
В прошлом другие сторонние сервисы использовались в реальных атаках для C2. Использование сторонних веб-сайтов, которые позволяют быстро публиковать или изменять пользовательский контент, может помочь вам обойти средства контроля на основе репутации, особенно если сторонний сайт в целом пользуется доверием.
Ознакомьтесь с этими ресурсами для других вариантов стороннего C2:
Атакующую инфраструктуру часто легко идентифицировать, она выглядит как оболочка легитимного сервера. Нам потребуется предпринять дополнительные шаги с нашей инфраструктурой, чтобы повысить вероятность слияния с реальными серверами либо внутри целевой организации, либо среди сервисов, которые цель может предположительно использовать.
Редиректоры могут помочь слиться с окружением, перенаправляя недействительные URI, ограничивая срок действия ссылок на фишинговые полезные нагрузки или блокируя распространенные техники специалистов по реагированию на инциденты; однако внимание также следует уделять базовому хосту и его индикаторам.
Например, в посте Fall of an Empire Джон Менерик (@Lord_SQL) описывает методы обнаружения серверов Empire в интернете.
Для противодействия этим и подобным индикаторам рекомендуется изменить шаблоны трафика C2, изменить целевые страницы сервера, ограничить открытые порты и изменить заголовки ответов по умолчанию.
Для получения более подробной информации о том, как выполнить эти и другие тактики для множества атакующих фреймворков, ознакомьтесь с этими постами:
Атакующая инфраструктура может быть атакована точно так же, как и любой другой подключенный к интернету хост, и ее следует считать ЧРЕЗВЫЧАЙНО чувствительной из-за используемых данных и соединений с целевыми средами.
В 2016 году были раскрыты уязвимости удаленного выполнения кода в наиболее распространенных атакующих инструментах:
iptables следует использовать для фильтрации нежелательного трафика и ограничения трафика между необходимыми элементами инфраструктуры. Например, если командный сервер Cobalt Strike будет обслуживать ресурсы только для редиректора Apache, правила iptables должны разрешать только порт 80 с исходного IP-адреса редиректора. Это особенно важно для любых интерфейсов управления, таких как SSH или порт Cobalt Strike по умолчанию 50050. Также рассмотрите возможность блокировки IP-адресов стран, не являющихся целевыми. В качестве альтернативы рассмотрите возможность использования межсетевых экранов гипервизора, предоставляемых вашими VPS-провайдерами. Например, Digital Ocean предлагает Cloud Firewalls, которые могут защитить один или несколько дроплетов.
chattr можно использовать на командных серверах для предотвращения изменения каталогов cron. С помощью chattr вы можете запретить любому пользователю, включая root, изменять файл до тех пор, пока атрибут chattr не будет удален.
SSH следует ограничить только аутентификацией по открытому ключу и настроить на использование пользователей с ограниченными правами для первоначального входа. Для дополнительной безопасности рассмотрите возможность добавления многофакторной аутентификации к SSH.
Обновление! Ни один список мер безопасности не будет полным без напоминания о необходимости регулярно обновлять системы и применять горячие исправления по мере необходимости для устранения уязвимостей.
Конечно, этот список не является исчерпывающим в отношении того, что можно сделать для защиты командного сервера. Следуйте общепринятым практикам усиления безопасности на всей инфраструктуре:
В интернете доступно множество ресурсов, посвященных безопасной настройке и проектированию инфраструктур. Не каждое проектное решение будет подходить для каждой атакующей инфраструктуры, но полезно знать, какие варианты доступны и что делают другие тестировщики.
Вот некоторые из этих ресурсов:
Темы, затронутые в этой вики, укрепляют атакующую инфраструктуру, но обычно требуют значительного времени на проектирование и реализацию. Автоматизация может быть использована для значительного сокращения времени развертывания, позволяя вам развертывать более сложные конфигурации за меньшее время.
Ознакомьтесь с этими ресурсами об автоматизации атакующей инфраструктуры:
Документируйте все - Управление сложной инфраструктурой Red Team означает множество движущихся частей. Обязательно документируйте функцию каждого актива и то, куда направляется его трафик.
Распределяйте активы между разными поставщиками услуг и регионами - Активы инфраструктуры должны быть распределены между несколькими поставщиками услуг и географическими регионами. Члены Blue Team могут повысить пороги мониторинга для провайдеров, идентифицированных как активно проводящие атаку, и могут даже полностью заблокировать данного поставщика услуг. Примечание: учитывайте международные законы о конфиденциальности при отправке зашифрованных или чувствительных данных через границы.
Не переусердствуйте - Легко увлечься продвинутыми техниками и захотеть обрушить на цель всё и сразу. Если вы имитируете конкретную adversarial-угрозу, используйте только те техники, которые применял реальный злоумышленник, или техники, соответствующие навыкам этого злоумышленника. Если ваше тестирование Red Team будет атаковать одну и ту же цель в долгосрочной перспективе, рассмотрите возможность начать с «простого» и переходить к более продвинутым методам по мере продолжения ваших оценок. Эволюция техник Red Team вместе с Blue Team будет последовательно продвигать организацию вперед, тогда как обрушение на Blue Team всего сразу может перегрузить их и замедлить процесс обучения.
Мониторьте логи - Все логи должны отслеживаться на протяжении всего взаимодействия: логи SMTP, логи Apache, tcpdump на редиректорах socat, логи iptables (специфичные для пересылки трафика или целевой фильтрации), веб-логи, логи Cobalt Strike/Empire/MSF. Пересылайте логи в центральное место, например, с помощью rsyslog, для более удобного мониторинга. Хранение данных терминала оператора может пригодиться для просмотра исторического использования команд во время операции. @Killswitch_GUI создал простую в использовании программу под названием lTerm, которая регистрирует все команды bash-терминала в центральном месте. Log all terminal output with lTerm. Ознакомьтесь с постом Vincent Yiu CobaltSplunk для примера того, как отправлять логи Cobalt Strike в Splunk для расширенного мониторинга и анализа инфраструктуры.* Реализация оповещений о событиях высокой важности — Настройте инфраструктуру атаки для генерации оповещений о событиях высокой важности, таких как новые сессии C2 или факты захвата учетных данных. Один из популярных способов реализации оповещений — через API чат-платформы, например Slack. Ознакомьтесь со следующими статьями об оповещениях в Slack: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
Снятие отпечатков реагирования на инциденты — Если возможно, попробуйте пассивно или активно снять отпечатки действий IR до начала оценки. Например, отправьте посредственное фишинговое письмо цели (используя несвязанную инфраструктуру) и отслеживайте трафик, который получает эта инфраструктура. Расследования команд IR могут раскрыть много информации о том, как работает команда и какую инфраструктуру они используют. Если это можно определить заранее, это можно отфильтровать или перенаправить напрямую.
ОГРОМНОЕ СПАСИБО всем следующим людям (перечислены в алфавитном порядке), которые внесли инструменты, советы или ссылки для включения в вики, и еще одно СПАСИБО всем, кто написал инструмент или пост, на который ссылается эта вики!