OPSEC для red team: что SOC должен детектить

На red team-проекте для финансовой организации мы три недели готовили инфраструктуру. Трёхуровневая цепочка редиректоров, домены состарены на два месяца, malleable-профиль C2 подогнан под User-Agent целевой среды. Понедельник, 9:15 - первый beacon через CDN. В 11:40 SOC заказчика вытащил из Sysmon Event ID 3 hostname оператора - IVAN-WORK. К обеду операцию свернули. Хуже того: из NTLM-хендшейка при lateral movement вылетел username реального сотрудника подрядчика - SOC сопоставил его с LinkedIn за два часа.

Три недели подготовки, 36 часов до провала. Причина - не C2 и не payload, а hostname и username, которые никто не проверил.

По моему опыту, провалы операционной безопасности red team чаще процедурные, а не технические. Эта статья - взгляд оператора на артефакты, которые мы пытаемся скрыть от вашего SOC, и чек-лист, на чём нас реально ловят.

Что скрывает OPSEC red team от SOC​

OPSEC для red team - защита критической информации об операции от обнаружения blue team. Не отдельная тактика MITRE ATT&CK, а дисциплина, пронизывающая весь kill chain от phishing до exfiltration. Threat actor tradecraft строится по тем же принципам - разница между APT-группировкой и красной командой тут только в наличии Rules of Engagement.

Грамотный оператор скрывает три категории данных.

Инфраструктуру. IP team-серверов, C2-домены, TLS-сертификаты. C2 инфраструктура OPSEC начинается с архитектуры: минимум два уровня редиректоров между имплантом и team server. На фронте - CDN или reverse proxy с легитимным доменом, далее short-haul и long-haul redirectors у разных провайдеров в разных географиях. Team server не торчит в интернет - принимает соединения только от long-haul redirector, в идеале через VPC peering.

Как скрыть инфраструктуру пентестера? Ключ - compartmentalization: каждый этап операции (phishing, staging, долгоживущий C2) использует отдельную инфраструктуру с разной репутацией. Спалили phishing-домен - C2-канал продолжает работать.

Идентичность оператора. Hostname, username, MAC-адрес, часовой пояс, browser fingerprint. Каждый параметр - вектор атрибуции red team операций. Hostname утекает через SMB, Kerberos, NTLM, DHCP, mDNS/LLMNR. Username попадает в сетевые хендшейки - System Owner/User Discovery (T1033, Discovery). MAC фиксируется в ARP-таблицах и DHCP-логах. T1049 (System Network Connections Discovery) - техника, которую сам оператор выполняет на скомпрометированном хосте для разведки сети, и именно эту активность детектирует SOC.

Identity reuse - типичная лень: один hostname на разных проектах, один SSH-ключ, один user-agent. Видел это не раз.

Паттерны поведения. Частота callback'ов, объём трафика, время активности. Методики threat actors OPSEC включают sleep с jitter, DNS-over-HTTPS, стеганографию. Но любой паттерн с достаточной регулярностью детектируется статистическим анализом - и именно тут SOC может зацепиться.

Цена пропуска конкретна. По данным IBM X-Force Threat Intelligence Index 2025, атаки с валидными учётными данными выросли на 71% за год, а infostealers (32%) обошли ransomware как основной тип malware. Threat actor, не пойманный SOC в первые часы, монетизирует доступ через продажу credentials или exfiltration. Для российских организаций повторная утечка персональных данных - оборотный штраф до 3% годовой выручки.

Детектирование C2-инфраструктуры при грамотном OPSEC пентест​

TLS-фингерпринты и анализ beacon-интервалов​

JA3 - криптографический хеш параметров TLS Client Hello. C2-фреймворки на Go (Sliver, кастомные импланты) генерируют JA3, который отличается от стандартного браузерного. Malleable-профиль меняет HTTP-заголовки и URI, но не контролирует TLS-хендшейк на уровне ClientHello. Итог: C2 инфраструктура OPSEC может быть выстроена идеально, но JA3 выдаёт имплант на network tap.

Что детектировать в SIEM:

• JA3 вне baseline. Создайте whitelist JA3-хешей для актуальных версий Chrome, Edge, Firefox вашей организации. Любой хеш вне списка - на ручной разбор. Zeek и Suricata генерируют JA3 нативно.
• Beacon-интервалы с низкой дисперсией. Оператор задаёт sleep 60 секунд + jitter 20%. Coefficient of variation (CV) таких интервалов - около 0.12. У человеческого web-серфинга CV превышает 1.0. Правило: хост обращается к одному endpoint с CV < 0.3 при более 20 запросов за 24 часа - beacon. Даже sleep 300 секунд с jitter 50% даёт CV порядка 0.29 - всё ещё ниже человеческого порога. Анонимность в пентесте заканчивается на статистике.

По данным CrowdStrike Global Threat Report 2025, среднее время от initial access до lateral movement - 62 минуты (рекорд - 51 секунда). Окно для детектирования C2 до начала горизонтального перемещения критически узкое. Beacon надо ловить на первых callback'ах - потом будет поздно.

DNS-аномалии при маскировке инфраструктуры для атак​

Оператор состарит домен, купит expired с историей - но несколько паттернов остаются доступны SOC:

• Смена A-записи. Passive DNS покажет: домен год указывал на один IP, а за неделю до подозрительного трафика переехал на VPS у другого провайдера. Историческая смена A-записи + появление трафика от одного хоста = non-attributable infrastructure, которая перестала быть non-attributable.
• Certificate Transparency. Домен категоризирован как "Business" в URL-фильтре, но CT-лог показывает Let's Encrypt-сертификат двухнедельной давности. Совпадение недавнего выпуска сертификата с началом подозрительных обращений - повод копнуть глубже, хотя само по себе не доказательство.
• Единственный клиент. Один хост из организации обращается к домену, 5000 остальных - нет. Sysmon EID 22 (DNSEvent) фиксирует DNS-запросы с привязкой к hostname и процессу-источнику. Это один из самых простых и эффективных индикаторов.
• Возраст домена. Корреляция DNS-запросов с WHOIS: возраст < 30 дней - повод для проверки, даже если домен формально чист.

Артефакты оператора - атрибуция red team через SIEM​

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

Hostname в сетевых хендшейках. Sysmon EID 3 и Windows Security EID 4624 (тип 3, Network) фиксируют hostname инициатора. Хост, не зарегистрированный в AD - повод для алерта. System Information Discovery (T1082, Discovery) работает в обе стороны: данные, которые атакующий собирает о среде, защитник собирает об атакующем. Красиво, если задуматься.

NTLM при lateral movement. NTLM-хендшейк через SMB передаёт hostname и username источника - даже при смене отображаемого имени хеш хранит оригинал. Деанонимизация red team через NTLM - рабочий вектор для SOC. Мониторинг входящих NTLM с неизвестных hostname ценнее, чем детектирование whoami на endpoint (хотя Sigma-правило proc_creation_win_whoami_execution.yml для T1033 тоже не помешает).

MAC-адреса. Если весь парк - Dell, а в ARP-таблице появился Realtek USB-адаптер - индикатор физического присутствия стороннего устройства. Оператор спуфит MAC через macchanger -r eth0, но часть Wi-Fi-драйверов сбрасывает spoofed MAC при смене канала. Неприятный сюрприз, который узнаёшь обычно в самый неподходящий момент.

Скомпрометированные легитимные хосты. OPSEC-грамотный threat actor не приносит свою станцию - работает с компрометированного хоста. Hostname и MAC не вызовут подозрений. Тут детектирование смещается к поведенческим аномалиям: финансовый аналитик не запускает net view /domain или nltest /dclist:. Контрмера D3FEND - Process Spawn Analysis (D3-PSA): мониторинг нехарактерных процессов для роли пользователя. Process Discovery (T1057, Discovery) и Security Software Discovery (T1518.001, Discovery) - техники, которые атакующий выполняет на скомпрометированном хосте, и каждая генерирует детектируемые артефакты.

EDR-телеметрия со станции оператора. Если оператор не отключил Defender на своей рабочей машине (а такое бывает чаще, чем хочется признавать), хеш payload'а может попасть в Microsoft cloud до доставки на цель. LOLBAS-проект документирует Wmic.exe для нескольких техник: T1105 (Ingress Tool Transfer), T1218 (System Binary Proxy Execution), T1518.001 (Security Software Discovery) и T1564.004 (NTFS File Attributes) - через wmic возможны lateral tool transfer и proxy execution, и каждый из этих вызовов детектируется Sysmon.

Чек-лист корреляционных правил для SOC​

и \\postex_[/I] (Cobalt Strike), \\psexec* (PsExec). OPSEC-грамотный оператор переименует pipe, так что ловить нужно по отклонению от baseline, а не по сигнатурам. Сигнатуры - это вчерашний день.

По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника - 11 дней (исторический минимум), и 57% организаций узнают об инциденте от внешней стороны. SOC с работающими правилами из этого чек-листа может сократить dwell time с дней до часов. Но при одном условии: наличие поведенческого baseline.

Опыт работы оператором это подтверждает: операции, которые выживали дольше всего, проводились против организаций без baseline. Где baseline существовал - нас ловили за часы, иногда быстрее.

Большинство SOC строят детектирование вокруг IOC-фидов и сигнатур: "этот JA3 = Cobalt Strike", "этот pipe = Metasploit". Против OPSEC-дисциплинированного оператора - или реального threat actor, работающего по тем же методикам - сигнатурный подход не работает. Malleable-профиль заменит User-Agent, redirector скроет IP, кастомный pipe не совпадёт ни с одной записью в базе.

Что работает - поведение: timing, объём, несоответствие процессов роли пользователя, кумулятивные артефакты. Именно эти правила почти никто не внедряет, потому что они требуют baseline. А baseline - не фид, не ML-модель из пресейла и не коробочный SIEM. Это методичная работа аналитиков по документированию нормального поведения каждого сегмента сети.

Организации, которые вложились в это, ловят нас в первые сутки. Остальные узнают об инциденте через 11 дней - или не узнают вовсе. Тематический тред с playbook'ом по этой группе TTP - на codeby.net.