Прошлой осенью на Purple Team упражнении для финтех-компании мы эмулировали дамп LSASS Memory (T1003.001, Credential Access) тремя способами: Mimikatz,
comsvcs.dll MiniDump, ProcDump. SOC с Elastic 8.x и CrowdStrike Falcon получил алерт только на Mimikatz - сигнатурный детект по имени процесса. comsvcs.dll (T1003.001) через rundll32 (T1218.011, proxy execution) прошёл незамеченным. ProcDump - аналогично. Coverage по одной технике - 33%. За месяц до этого Red Team отчёт зафиксировал ту же технику как «successful credential dump», но без разбивки по вариантам исполнения. Blue Team считал T1003.001 закрытой - «Mimikatz же ловим». Purple Team за полтора часа показал, что закрыт один вариант из трёх.Почему классический Red vs Blue не закрывает gaps в покрытии
Стандартный цикл: Red Team проводит операцию, через две-четыре недели приходит отчёт. Blue Team получает PDF, создаёт таски в Jira, закрывает их за следующий квартал. Или не закрывает. Три системные проблемы этого подхода.Информационная асимметрия. Red Team знает, какие техники запускал и когда. Blue Team видит только результат - скомпрометированный хост или учётки в отчёте. Без привязки к точному времени выполнения и конкретному варианту техники аналитик SOC не может понять: детект сработал с задержкой, сработал частично или не сработал вообще. В классическом цикле Red Team → отчёт → remediation этот разрыв растягивается на месяцы.
Ложное ощущение покрытия. SOC ловит Mimikatz по сигнатуре - в ATT&CK Navigator ставится зелёная ячейка на T1003.001. Но техника предполагает десятки вариантов исполнения: comsvcs.dll, nanodump, PPLBlade, дамп через Task Manager. Одна сигнатура - это не покрытие техники. Purple Team упражнения выявляют куда больше gaps в detection coverage по сравнению с пентестами в изоляции - именно потому, что проверяют каждый вариант, а не только факт компрометации.
Временной лаг. Пока отчёт пишется, согласуется и превращается в задачи - инфраструктура уже изменилась. Новые правила корреляции, обновления EDR, ротация аналитиков. Remediation по отчёту месячной давности - стрельба по координатам, где цель уже не стоит.
Purple Team workflow: от выбора техник до gap-трекера
Планирование: scope, baseline, критерии успеха
Перед запуском эмуляции нужны три вещи.Текущая карта покрытия. Выгружаете из SIEM список активных правил корреляции и маппите каждое правило на ATT&CK technique ID. Загружаете результат в ATT&CK Navigator - получаете тепловую карту: зелёный (правило есть и валидировано), жёлтый (правило есть, не проверено), красный (правила нет). В подавляющем большинстве организаций первая карта - жёлто-красная: правил много, валидированных - единицы.
Приоритизация техник. Тестировать все 200+ техник за одно упражнение - бессмысленно. Фильтруем по двум критериям: какие TTP используют APT-группы, релевантные для вашего сектора (берём из CTI и ATT&CK Groups), и какие техники уже всплывали в ваших реальных инцидентах. Для финансового сектора приоритетны T1078 (Valid Accounts), T1059.001 (PowerShell), T1003.001 (LSASS Memory), T1055 (Process Injection). Десять техник на упражнение - оптимальный объём для команды, которая проводит Purple Team впервые.
Критерии результата. Для каждой техники заранее определите статусы:
| Статус | Определение |
|---|---|
| Detected | Алерт в SIEM/EDR с корректной атрибуцией, аналитик увидел и классифицировал |
| Partially detected | Телеметрия записалась, но правило не сработало или severity некорректен |
| Missed | Ни телеметрии, ни алерта |
| Blocked | EDR предотвратил выполнение (не всегда равно detected - блокировка может произойти без алерта в SIEM) |
Эта классификация - стандарт индустрии: для каждого TTP фиксируется факт детектирования и/или блокировки с последующим root cause analysis пропусков.
Эмуляция: параллельная работа Red и Blue
Ключевое отличие от Red Team операции: здесь нет скрытности. Red Team сообщает Blue Team, какую технику запускает, в какой временной интервал, на каком хосте. Цель - не проверить бдительность аналитика (для этого существует Red Team engagement), а проверить работоспособность конкретного детекта.Цикл одной итерации:
- Red Team документирует: ATT&CK ID, инструмент, целевой хост, точное время
- Red Team выполняет технику
- Blue Team проверяет в реальном времени: появился ли алерт, какой, за сколько секунд
- Обсуждение результата - немедленно, не в конце дня
- Если алерта нет - диагностика: нет логов? нет правила? правило с ошибкой?
- Blue Team исправляет root cause
- Red Team повторяет технику - верификация
Документирование: каждую итерацию записывайте в трекер. Vectr - open-source платформа от Security Risk Advisors для трекинга Purple Team упражнений. Минималистичная альтернатива - таблица с колонками: Technique ID, Technique Name, Tool Used, Timestamp, Detection Status, Root Cause (если missed), Remediation, Re-test Status.
Анализ: root cause пропущенных техник
Когда техника пропущена, причины сводятся к четырём категориям:| Причина | Пример | Что делать |
|---|---|---|
| Нет логов | Sysmon не настроен на Process Access (Event ID 10) | Обновить конфиг Sysmon, подключить источник в SIEM |
| Нет правила | Логи есть, но корреляция на них отсутствует | Написать Sigma-правило, конвертировать под SIEM |
| Ошибка в правиле | Правило ищет mimikatz.exe по имени, ProcDump не ловится | Переписать на поведенческий паттерн (доступ к lsass.exe) |
| Ошибка интеграции | EDR заблокировал, но алерт не пробросился в SIEM | Настроить forwarding EDR → SIEM |
По завершении упражнения формируются итоговые метрики: процент заблокированных TTPs, процент задетектированных, процент пропущенных - в разрезе по тактикам ATT&CK. Эти данные, загруженные в ATT&CK Navigator, дают обновлённую тепловую карту для сравнения «до» и «после».
Практика: эмулируем T1003.001 и строим детект
Требования к окружению
Инструменты Purple Team: когда что применять
Выбор инструмента эмуляции зависит от зрелости команды и задачи.| Критерий | Atomic Red Team | CALDERA (MITRE) | Ручная эмуляция |
|---|---|---|---|
| Тип | Атомарные тесты по одной технике | Цепочки атак с агентами | Произвольные сценарии |
| Порог входа | Низкий - PowerShell-модуль | Средний - сервер + агенты | Высокий - нужен Red Team опыт |
| Реализм | Средний - одна техника в изоляции | Высокий - полноценный kill chain | Максимальный |
| Покрытие | 280+ техник с готовыми тестами | Зависит от загруженных abilities | Любые техники |
| Когда использовать | Быстрая валидация одного правила | Регулярные циклические проверки всей цепочки | Кастомные APT-сценарии |
| Когда НЕ использовать | Нужен multi-step сценарий с C2 | Изолированные среды без агентов | Рутинная проверка >20 техник |
| Ключевое ограничение | Нет persistence между тестами | Требует развёртывания инфраструктуры | Не масштабируется |
Начинайте с Atomic Red Team для первого цикла. На CALDERA переходите, когда упражнения станут регулярными и нужна автоматизация цепочек. Ручная эмуляция - для проверки конкретных APT-сценариев, где нужен полный kill chain от Initial Access до Exfiltration. Для тренировки в изолированной среде есть проекты Purple Cloud и AutomatedEmulation - разворачивают облачную инфраструктуру для тестирования.
Одно замечание из практики: CALDERA красиво выглядит на демо, но при развёртывании в реальной сети с сегментацией и прокси-серверами агенты начинают капризничать. Закладывайте день на настройку, если сеть сложнее flat topology.
Метрики: как измерять прогресс покрытия ATT&CK
Без метрик Purple Team превращается в разовое мероприятие, результат которого невозможно показать руководству.Detection Rate - процент техник с корректным алертом от общего числа эмулированных. Первый цикл нередко даёт 25-40% - цифры зависят от зрелости SOC и стека. Это нормально. Второй цикл показывает 50-60%, третий - 70+. Вот это и есть измеримый прогресс.
Block Rate - процент техник, остановленных средствами защиты. Нюанс: блокировка без алерта - это blind block. Если CrowdStrike Falcon заблокировал T1055 (Process Injection), но Elastic SIEM не получил события - аналитик не знает, что попытка была. Blind blocks фиксируйте отдельно, потому что в день, когда EDR пропустит (а он пропустит) - SIEM должен подхватить.
Mean Time to Detect (MTTD) - время от выполнения техники до появления алерта в консоли SOC. Регулярные Purple Team упражнения заметно сокращают этот показатель - просто потому, что аналитики начинают понимать, что именно искать.
Coverage Delta - разница в покрытии ATT&CK между упражнениями. Экспортируете JSON-слой из ATT&CK Navigator после каждого цикла, сравниваете визуально и численно. Если дельта нулевая два цикла подряд - что-то идёт не так с remediation.
Индикатор Dwell Time. Если техники T1078 (Valid Accounts), T1562.001 (Disable or Modify Tools), T1070.001 (Clear Windows Event Logs), T1518.001 (Security Software Discovery) стабильно пропускаются - это прямой сигнал: атакующий сможет закрепиться и сидеть в инфраструктуре неделями. Эти техники покрывают закрепление, сокрытие следов и разведку защитных средств - три шага, которые определяют, перейдёт ли инцидент из категории «попытка» в категорию «компрометация».
Чеклист первого Purple Team упражнения
До упражнения:- Экспортирована карта текущего покрытия ATT&CK (правила SIEM → маппинг на техники → ATT&CK Navigator)
- Выбрано 5-10 техник на основе CTI и истории инцидентов
- Определены критерии detected / partially / missed / blocked
- Установлен Atomic Red Team, проверен запуск на тестовом хосте
- Согласованы rules of engagement: scope, хосты, временные окна, эскалация при проблемах
- Подготовлен gap-трекер (Vectr или таблица с колонками: Technique, Tool, Timestamp, Status, Root Cause, Fix, Re-test)
- Каждая техника документируется: ATT&CK ID, инструмент, хост, точное время
- Blue Team отслеживает SIEM/EDR в реальном времени, не постфактум
- Обсуждение - сразу после каждой техники
- При пропуске - немедленная диагностика (нет логов / нет правила / ошибка конфигурации / ошибка интеграции)
- Исправление → перезапуск → верификация
- Обновлена карта ATT&CK Navigator
- Сформирован список remediation-задач с владельцами и дедлайнами
- Запланирован следующий цикл: раз в квартал для зрелых SOC, раз в месяц для команд в фазе роста
- Метрики зафиксированы для сравнения с будущими циклами
Три года назад я начинал Purple Team как «запустим Atomic Red Team и посмотрим что будет». Первое упражнение было хаотичным: результаты - в чате, а не в трекере, половина техник не дошла до SIEM из-за кривой конфигурации Sysmon. Но уже после второго цикла стало понятно - этот формат даёт на порядок больше, чем любой PDF от Red Team. Не потому что Red Team плохо работает, а потому что отчёт через месяц и совместная работа в реальном времени решают принципиально разные задачи.
Главная ошибка, которую я вижу у команд, запускающих Purple Team: попытка проверить всё сразу. Берут 50 техник, прогоняют за день, получают огромную таблицу пропусков и теряют мотивацию. Пять техник за сессию, полная отработка каждой до зелёного статуса, регулярный ритм - вот что реально двигает покрытие.
Ещё одна неудобная правда: в большинстве организаций coverage по ATT&CK после первого честного прогона оказывается ниже 30%. Это не повод для паники - это стартовая точка. Если ваша coverage-матрица после первого прогона выглядит удручающе - на codeby.net обсуждаем, как другие команды закрывают эти gaps в конкретных SIEM-стеках, с примерами трекеров и итоговых метрик.
