Engagement на шесть недель сгорел за 36 часов. Не из-за payload'а, не из-за эксплойта - из-за самоподписанного сертификата на VPS, который Censys проиндексировал за одну ночь. SOC заказчика увидел callback на незнакомый IP, пробил его в Shodan, нашёл открытый порт с дефолтным баннером C2-фреймворка - и через два часа тимсервер улетел в блоклист вместе со всеми доменами. Это как собрать снайперскую винтовку и выйти на позицию в оранжевом жилете. Инфраструктура для red team операций - не "поднять VPS и запустить listener". Это архитектурная дисциплина, и от неё зависит, проживёт операция запланированные недели или схлопнется до первого алерта.
Зачем строить выделенный C2 сервер для Red Team
По данным CrowdStrike Global Threat Report 2025, 79% атак в 2024 году прошли без вредоносного ПО - атакующие работали hands-on-keyboard и living off the land. Среднее время lateral movement после initial access - 62 минуты, рекорд - 51 секунда. При таких скоростях качество имплантов уходит на второй план. Решает устойчивая red team инфраструктура: как организованы каналы управления между оператором и целевой средой, насколько они устойчивы к обнаружению, как быстро ротируются сгоревшие компоненты.С позиции MITRE ATT&CK инфраструктура покрывает тактику Resource Development: приобретение доменов (T1583.001), VPS (T1583.003), серверов (T1583.004) и веб-сервисов (T1583.006). Каналы управления - тактику Command and Control: External Proxy (T1090.002), Multi-hop Proxy (T1090.003) и Web Protocols (T1071.001). Каждый из этих элементов - потенциальная точка провала, через которую защитники могут размотать всю операцию. Понимание того, как настроить command and control сервер так, чтобы он пережил встречу со зрелым SOC - базовое требование к red team оператору.
Многослойная архитектура redirector
Прямые callback'и от имплантов к тимсерверу - ошибка номер один. IP тимсервера моментально попадает в EDR-телеметрию каждого заражённого хоста. Один алерт - и через цепочку DNS-резолвинг -> Shodan/Censys -> WHOIS вся инфраструктура становится прозрачной.
Маскировка C2 инфраструктуры строится на принципе blast-radius containment: сгорел один компонент - остальная цепочка продолжает работать. Между имплантом и тимсервером - минимум два слоя redirector'ов:
- CDN или коммерческий reverse proxy (Cloudflare, Azure Front Door) - принимает трафик от имплантов, терминирует TLS, отдаёт легитимный контент всем, кто не проходит фильтрацию. Домен обслуживает реальный сайт (блог, документацию) одновременно с C2-endpoint'ами
- Short-haul redirector - облачный VPS на отдельном провайдере, фильтрует по URI, заголовкам и User-Agent
- Long-haul redirector - другой провайдер, другая географическая зона, второй уровень фильтрации
- Team server - публичных listener'ов нет, принимает трафик только от long-haul redirector'а через приватную сеть или VPC peering
Domain fronting в классическом понимании (подмена Host-заголовка через CDN) операционно ограничен с 2018 года - крупные CDN-провайдеры блокируют несовпадение SNI и Host. На практике его заменил паттерн sub-resource separation: C2-трафик неотличим от легитимных под-путей на том же домене, потому что redirector действительно обслуживает оба типа контента.
Работает если: операция длится от месяца, SOC заказчика использует EDR и занимается threat hunting. Избыточна если: короткий engagement (1-2 недели) против инфраструктуры без мониторинга - хватит одного redirector'а.
Сегментация инфраструктуры по стадиям операции
Разные стадии операции требуют разного профиля инфраструктуры. Смешивание стадий на одном домене означает, что компрометация любой стадии обрушивает всё. Русскоязычные материалы по red team этот момент практически не покрывают, хотя EN-источники считают его фундаментальным. На практике - из пяти разобранных post-mortem провалов три были именно про это: Stage 0 и Stage 1 сидели на одном домене.
Stage 0 - Phishing / Initial Access. Короткоживущие домены, которые сжигаются сразу после кампании. Отдельный VPS, отдельный регистратор. Домен состарен минимум 2-4 недели. Никогда не используется повторно для C2.
Stage 1 - Foothold C2. Отдельный набор доменов с умеренной репутацией, увеличенный sleep-интервал beacon'а (60-300 секунд). Задача - закрепиться и провести базовую разведку. CDN-фронтирование, malleable-профиль с широким покрытием трафика.
Stage 2 - Long-haul / Post-exploitation. Инфраструктура с максимальным доверием: самые старые домены, минимальная частота callback'ов (часы), часто - отдельный C2-фреймворк, не связанный со Stage 1. Если Stage 1 раскрыт, Stage 2 продолжает работать.
Каждая стадия - разные домены на разных регистраторах, разные VPS-провайдеры (AWS, DigitalOcean, Azure), разные IP-диапазоны и разные TLS-сертификаты от разных CA. По MITRE ATT&CK это разграничение между приобретением свежих доменов (T1583.001, Resource Development) и использованием скомпрометированных или expired-доменов (T1584.001, Resource Development).
Категоризация доменов для C2: выбор, старение и репутация
Домен, зарегистрированный за шесть часов до начала операции, обрабатывается репутационными системами принципиально иначе, чем домен с шестимесячной историей. NGFW и threat intelligence фиды жёстко фильтруют newly registered domains - тут без вариантов.Покупка и старение. Два подхода. Первый: зарегистрировать домен за 3-6 месяцев до engagement'а и развернуть на нём простой легитимный сайт - блог, документацию, лендинг. Второй: выкупить expired-домен с чистой историей через expireddomains.net. Перед покупкой - обязательная проверка через MXToolbox и VirusTotal на наличие в блоклистах McAfee, Fortiguard, Symantec/Bluecoat, Palo Alto. Пропустил этот шаг - и домен, который ты растил полгода, оказывается в бане у половины NGFW ещё до старта операции.
Категоризация. Веб-фильтры относят сайты к категориям - Health, Finance, Technology. Категории Health и Finance традиционно доверенные: регуляторные требования затрудняют SSL-инспекцию трафика к таким ресурсам. Для категоризации домена: разверните контент, соответствующий целевой категории, подайте заявку через Bluecoat SiteReview и Fortiguard Web Filtering, подождите от нескольких дней до недель, верифицируйте через VirusTotal.
Регистратор. Крупные провайдеры (Cloudflare, Namecheap) реже вызывают подозрения, чем нишевые, исторически ассоциированные с malware-кампаниями. Cloudflare дополнительно даёт WHOIS-приватность и TLS-сертификаты из коробки.
Когда НЕ работает: некоторые организации ведут собственные whitelist'ы доменов и не полагаются на категоризацию. В таких средах даже идеально категоризированный домен блокируется, если не добавлен в корпоративный список. Узнаёшь об этом обычно уже после того, как первый beacon молча умер.
Redirector настройка: Nginx конфигурация для Red Team
Redirector решает, какой трафик попадёт к тимсерверу, а какой получит легитимную страницу. Nginx - самый распространённый выбор из-за производительности и гибкости проксирования. Для Cobalt Strike, Sliver или Havoc принцип один: C2-трафик маршрутизируется по совпадению URI-паттерна и кастомного заголовка, всё остальное обслуживается как обычный сайт.
Требования к окружению: Ubuntu 22.04+ или Debian 12+, Nginx 1.22+, TLS-сертификат (Let's Encrypt certbot или Cloudflare Origin Certificate), VPS с минимум 1 GB RAM на отдельном от тимсервера провайдере.
NGINX:
server {
listen 443 ssl http2;
server_name updates.example.com;
ssl_certificate /etc/letsencrypt/live/updates.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/updates.example.com/privkey.pem;
root /var/www/legit-content;
location ~ ^/cdn/updates/[a-f0-9]{8}/v[0-9]+$ {
if ($http_x_session_token = "") { return 404; }
proxy_pass https://short-haul.internal;
proxy_set_header Host $host;
}
location / { try_files $uri $uri/ /index.html; }
}X-Session-Token. Без обоих условий запрос не проксируется - клиент видит контент обычного сайта. IP тимсервера нигде не фигурирует в конфигурации и TLS-цепочке. Apache с mod_rewrite и ProxyPass даёт тот же результат - выбор между ними менее важен, чем дисциплина множественных условий фильтрации. Cobalt Strike redirector на Nginx с правильным malleable-профилем неотличим от обычного веб-сервера.Харденинг redirector: четыре слоя фильтрации трафика
Незащищённый redirector - это не актив, а обуза. Сканеры Shodan, Censys, Nuclei и threat intelligence провайдеры обнаружат его за часы. Из опыта: устойчивая инфраструктура применяет четыре последовательных слоя фильтрации - трафик обязан пройти каждый из них.Layer 1 - User-Agent. Блокировка известных сканеров:
nmap, masscan, nuclei, zgrab, censys, gobuster. В Nginx - if ($http_user_agent ~* "pattern") { return 444; } (закрытие соединения без ответа, даже не 403). В Apache - через RewriteCond %{HTTP_USER_AGENT}.Layer 2 - Кастомный HTTP-заголовок. Malleable-профиль настраивается на отправку специфического заголовка. Запрос без него - redirect на легитимный сайт. Отсеивает 99% автоматизированного трафика.
Layer 3 - URI path validation. Только конкретные URI из malleable-профиля проксируются к следующему слою. Все остальные запросы обслуживаются как обычный сайт.
Layer 4 - IP blocklist. Блокировка диапазонов cloud-сканеров (AWS, DigitalOcean), известных threat intelligence сервисов и IP-диапазонов вне целевой географии. Списки обновляются регулярно.
Код:
RewriteEngine On
# Layer 1: block known scanners
RewriteCond %{HTTP_USER_AGENT} (nmap|masscan|nuclei|zgrab|censys) [NC]
RewriteRule ^(.*)$ https://www.microsoft.com/ [R=302,L]
# Layer 2: require custom header
RewriteCond %{HTTP:X-Session-Token} ^$
RewriteRule ^(.*)$ https://www.microsoft.com/ [R=302,L]
# Layer 3: allow only valid C2 URI
RewriteCond %{REQUEST_URI} !^/api/v2/update
RewriteRule ^(.*)$ /var/www/html/index.html [L]curl -A "nuclei" https://domain/ должен вернуть redirect; curl без кастомного заголовка - redirect; с заголовком, но неправильным URI - легитимная страница; curl -H "X-Session-Token: val" https://domain/api/v2/update - проксирование к тимсерверу. Если хоть один слой пропускает лишнее - считай, что его нет.Malleable C2 профили и маскировка трафика
C2 сервер для red team с дефолтным профилем - подарок защитнику. Default User-Agent строки, URI-паттерны и структура ответов попадают в IOC-фиды вендоров за часы. Видел кейс, когда SOC вычислил Cobalt Strike по дефолтному URI
/pixel.gif за 20 минут после первого callback'а.User-Agent должен соответствовать актуальной версии браузера, реально используемого в целевой организации. Устаревший Chrome 80 в профиле, когда корпоративный стандарт Edge 124, моментально выделяется в прокси-логах.
URI и заголовки имитируют легитимные API-эндпоинты:
/api/v2/update/check, /cdn/assets/v3/config. Заголовки Accept, Accept-Language, X-Requested-With - как у реального AJAX-запроса. Метаданные beacon'а кодируются в Cookie или Authorization header через base64url.Sleep и jitter. Агрессивные callback'и каждые 5 секунд переполняют EDR-аномалии. Stage 1 -
sleeptime 60-300 секунд, jitter 20-50%. Stage 2 - sleeptime 1800-3600 секунд, jitter 30-50%. Паттерн рабочих часов (09:00-18:00 по локальному времени цели) с рандомизацией выходных снижает заметность в frequency analysis.Malleable-профили в полном объёме поддерживает Cobalt Strike (файлы
.profile). Sliver настраивается через --http-c2-config. Havoc - через конфигурацию listener'а. Каждый фреймворк - свой формат; универсального стандарта нет, и это боль при миграции между ними.OPSEC при построении атакующей инфраструктуры: чеклист
OPSEC - не абстракция, а конкретный набор решений на каждом этапе развёртывания. Ниже - то, на чём горят чаще всего.JA3/JARM и TLS-отпечатки
JA3 - хеш параметров TLS ClientHello, JA3S - серверного ответа, JARM - активный fingerprint TLS-стека. Go-based фреймворки (Sliver, Merlin) генерируют характерный TLS-стек, который отличается от стандартного Nginx/Apache. Mitigation: терминируйте TLS на redirector'е, а не на тимсервере. JARM redirector'а с Nginx соответствует стандартному веб-серверу, а не C2-фреймворку.TLS-сертификаты и Certificate Transparency
Самоподписанные сертификаты - мгновенный красный флаг. Let's Encrypt бесплатен, но ассоциируется с malware-кампаниями - некоторые NGFW повышают scoring для LE-сертификатов. Оптимально: Cloudflare Origin Certificate (подписан приватным Cloudflare Origin CA, который не публикует сертификаты в публичные CT-логи, в отличие от публичных CA вроде Let's Encrypt или DigiCert, обязанных логировать по CT policy браузеров) или Microsoft-managed сертификаты через Azure CDN. Критическая ошибка - метаданные сертификата, привязывающие домен к оператору: email, organization name, повторное использование contact email из другого engagement'а. Одна такая ошибка - и все engagement'ы за последний год связываются в один кластер.Beacon timing и защита C2 от blue team
Равномерные callback'и каждые N секунд создают статистически детектируемый паттерн даже с jitter'ом. Продвинутые SOC используют frequency analysis. Mitigation: высокий jitter (30-50%), рабочие часы callback'ов, рандомизация выходных. Логи на redirector'е - палка о двух концах: нужны для отладки, но при компрометации становятся forensic-артефактами. Минимальное логирование (только ошибки), автоматическая ротация сshred, очистка bash_history и swap при экстренной ротации.Как blue team обнаруживает C2-инфраструктуру
Понимание detection-методов - обязательная часть OPSEC. Вот что ищут защитники и как с этим жить:Shodan/Censys fingerprinting. Открытые порты тимсервера (дефолтный 50050 для Cobalt Strike, 40056 для Havoc - оба настраиваемы) - мгновенная деанонимизация. Команда
censys search "services.banner: Havoc" находит непрокрытые серверы за секунды. Решение: тимсервер не имеет публичных портов, все listener'ы только на redirector'е.DNS history. Сервисы пассивного DNS показывают историю A-записей домена. Если домен вчера указывал на known-bad IP, а сегодня переехал - это флаг. Решение: DNS-конфигурация задолго до engagement'а, минимальная ротация A-записей.
Traffic volume analysis. Домен, обслуживающий только C2-трафик, подозрителен по объёму и паттерну запросов. Решение: развернуть реальный контент на том же домене - C2-трафик составляет малую долю от общего.
Certificate Transparency мониторинг. CT-логи публичных CA мониторятся на предмет доменов-двойников (typosquatting). Решение: CA без CT-требований или private CA для внутренних соединений между redirector'ами.
JARM fingerprinting. Активное сканирование TLS-стека. Характерный JARM-хеш C2-фреймворка - маркер. Решение: TLS-терминация на Nginx, чей JARM неотличим от стандартного веб-сервера.
Минилаб: разворачиваем redirector за 30 минут
Итог: работающая двухслойная инфраструктура, где прямой доступ к тимсерверу невозможен, а redirector неотличим от легитимного веб-сервера. Для расширения до полной трёхслойной модели добавьте CDN-фронт (Cloudflare) перед redirector'ом и второй redirector между первым и тимсервером.
Для автоматизации развёртывания используют Terraform (инфраструктура как код) и Ansible (конфигурация серверов). Это позволяет пересоздать полную инфраструктуру за минуты при экстренной ротации - вместо ручной настройки каждого компонента. На одном проекте экстренная ротация без Terraform заняла 4 часа. С Terraform - 12 минут. Разница ощутимая, когда SOC дышит в спину.
Большинство команд вкладываются в tooling: покупают лицензию Cobalt Strike, пишут кастомные loader'ы, изучают обход AMSI и ETW - и при этом разворачивают инфраструктуру на одном VPS с дефолтным сертификатом и прямыми callback'ами. Из десятков engagement'ов, которые приходилось разбирать post-mortem, четыре из пяти провалов - инфраструктурные, а не инструментальные. Забыли закрыть порт тимсервера, не состарили домен, не проверили JARM-хеш redirector'а. Мой прогноз на ближайший год: SOC'и начнут массово внедрять JARM-мониторинг на периметре, и все, кто терминирует TLS на тимсервере вместо redirector'а, будут гореть в первые часы операции. Фреймворк - дело десятое. Инфраструктура - это и есть операция. Если хочешь отработать полную цепочку от redirector'а до beacon'а на живом стенде - на HackerLab (https://hackerlab.pro) есть сетевые задачи, где эту архитектуру можно собрать и обкатать без последствий для чужой инфраструктуры.
Последнее редактирование модератором:
