Отчёт по Red Team операции: структура и debrief

За три года я написал больше двадцати отчётов по итогам Red Team операций. Четыре из них привели к реальным изменениям в защите заказчика в первый квартал после сдачи. Остальные шестнадцать легли на SharePoint, где их не открывал никто, кроме менеджера проекта при закрытии акта.

Дело не в технической глубине - скриншоты, хеши и цепочки атак были в каждом. Дело в том, как отчёт написан и кому адресован. По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника в сети - 11 дней, причём 57% организаций узнают об инциденте от внешней стороны. Отчёт, который не конвертируется в защитные меры, не сокращает эти 11 дней ни на минуту.

Доказательная база Red Team: что фиксировать в ходе операции​

Отчёт по Red Team операции начинается не в момент, когда оператор садится за текстовый редактор. Он начинается с первого initial access. Каждое действие - потенциальный артефакт, который через три недели станет строкой в findings. Не зафиксировал в реальном времени - по памяти уже не восстановишь. SOC-команда заказчика скептична по умолчанию: "а вы точно не на тестовом стенде это делали?" - вопрос, который звучит на каждом втором дебрифе.

Таймстампы и цепочка событий​

Фиксация хронологии - фундамент доказательной базы Red Team. Каждая запись в логе C2-фреймворка (Cobalt Strike, Sliver, Havoc) содержит UTC-таймстамп, имя оператора, хостнейм цели и выполненную команду. Формат, который работает на дебрифе:

[2025-03-14 09:17:42 UTC] operator: dm | target: WS-FIN-012 | action: T1003 OS Credential Dumping via NPPSpy | result: 14 NTLM hashes

Такая строка позволяет SOC сопоставить действие оператора со своими логами SIEM. SOC видит алерт в 09:18 - обнаружение за минуту, хороший результат. Алерта нет - gap задокументирован с точностью до секунды.

Для каждого критического шага - скриншот с видимым таймстампом и hostname. Не screenshot_042.png, а 2025-03-14_0917_WS-FIN-012_cred-dump.png. Когда в отчёте 80+ скриншотов, naming convention - разница между находкой, которую можно верифицировать, и артефактом, который SOC отправит в корзину.

Отдельно фиксируется время каждого перемещения между хостами. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты, рекорд - 51 секунда. Когда в отчёте зафиксировано, что оператор прошёл от WS-FIN-012 до контроллера домена за 38 минут, SOC-команда понимает: их MTTD должен быть короче 38 минут, иначе детекция бесполезна.

Оформление доказательств эксплуатации уязвимостей​

Доказательства делятся на три категории, каждая со своим форматом и назначением:


Видеозапись сессии - самый сильный аргумент на дебрифе. Когда SOC-аналитик видит, как оператор за 47 минут проходит от фишингового письма до domain admin, спорить с формулировкой "критический gap" бессмысленно. Я видел, как после такого ролика CISO молча подписывал бюджет на EDR - без дополнительных вопросов.

Маркерные файлы - отдельная практика оформления доказательств. На каждом engagement я создаю REDTEAM_MARKER_[дата].txt на целевом сервере: дата, имя оператора, идентификатор проекта. Proof of concept, который нельзя оспорить - timestamp файловой системы подтверждает факт доступа.

При фиксации чтения конфиденциальных данных есть нюанс: скриншоты содержат заголовки столбцов, количество записей и названия таблиц, но не содержимое. Формулировка "доступ к таблице PAYMENTS: 142 800 записей, столбцы card_number, cvv, expiry_date" - достаточна для демонстрации impact без создания нового инцидента. Не хватало ещё самим стать причиной утечки.

Структура отчёта Red Team: шаблон для двух аудиторий​

Порядок блоков в отчёте критичен. CISO читает первые две страницы и принимает решение о бюджете. SOC-инженер листает до технической части и ищет конкретные IoC. Если блоки перепутаны - оба читателя закрывают документ на третьей странице. Шаблон отчёта Red Team, который конвертируется в действие, содержит пять блоков в определённом порядке.

Executive summary для отчёта по пентесту​

Executive summary - единственная часть, которую гарантированно прочитает руководство. Объём - одна страница. Здесь нет CVE-идентификаторов, command line или названий инструментов.

Формула executive summary, которая конвертирует техническую операцию в бюджет на remediation:

1. Цель и scope - что эмулировали, какого threat actor моделировали, временные рамки, ограничения. Одно-два предложения.
2. Ключевой результат - самое критичное достижение в терминах бизнеса: "Получен полный доступ к ERP-системе через цепочку из 4 техник за 3 дня. Потенциальный ущерб - доступ к платёжным данным 12 000 контрагентов".
3. Метрики покрытия - Detection Rate, Block Rate, Mean Time to Detect. Три цифры, которые CISO сравнит с прошлогодним engagement.
4. Top-3 критичных gap - через бизнес-последствия. Не "отсутствует мониторинг обращений к lsass.exe", а "атакующий может извлечь учётные данные всех пользователей домена без срабатывания систем защиты, что при стоимости утечки в N рублей - прямой бизнес-риск".
5. Позитивные наблюдения - что сработало. Если из 14 техник Blue Team обнаружила 3 - эти три обнаружения фиксируются как базис для усиления.

Антипаттерн: executive summary, начинающийся словами "В ходе тестирования были обнаружены следующие уязвимости...". CISO не получает ответа на вопрос "сколько стоит, если не починить" - и закрывает документ. Как написать отчёт по результатам пентеста так, чтобы его дочитали: сначала ответ на "что это значит для бизнеса", потом - "как именно это произошло".

По шаблону с redteam.guide, executive summary включает также перечень достигнутых и не достигнутых целей (goals achieved vs. goals not achieved). Если из четырёх целей достигнуты две - это объективная картина, которая лучше для отношений с заказчиком, чем сплошной негатив.

Attack narrative: хронология операции​

Attack narrative - хронологический рассказ от initial access до достижения конечной цели. Не перечень уязвимостей, а связная история, где каждый шаг вытекает из предыдущего. Именно нарратив превращает отчёт из набора фактов в инструмент, которым Blue Team может пользоваться.

Структура каждого шага нарратива:

• Дата и время - UTC, сопоставимое с логами SIEM заказчика
• Техника по MITRE ATT&CK - ID и название: Spearphishing Attachment (T1566.001, Initial Access)
• Описание действия - что оператор сделал и почему именно эту технику
• Результат - что получено
• Detection status - обнаружила ли Blue Team, через сколько минут, какой alert сработал

Пример формулировки одного шага:

14.03.2025, 08:42 UTC - Spearphishing Attachment (T1566.001, Initial Access). Отправлено фишинговое письмо с macro-вложением на 12 адресов финансового департамента. 3 пользователя открыли вложение, 2 активировали макрос. Получен reverse shell на WS-FIN-007 и WS-FIN-012. Detection status: не обнаружено. Sandbox не деактивировал вложение, антивирус пропустил payload.

Нажмите, чтобы раскрыть...

Blue Team берёт нарратив и проходит по каждому шагу: "Где в наших логах это событие? Почему SIEM не сработал?". По данным IBM X-Force Threat Intelligence Index 2025, рост атак с использованием действительных учётных данных - 71% год к году. Если Credential Dump (T1003, Credential Access) через NPPSpy остался незамеченным - значит, большая часть реальных атак пройдёт тем же путём.

Матрица MITRE ATT&CK в отчёте и метрики покрытия​

ATT&CK Navigator генерирует heatmap покрытия техник. Layer-файл экспортируется в JSON и передаётся Blue Team как machine-readable артефакт. Цветовая кодировка: красный - техника не обнаружена; жёлтый - обнаружена с задержкой более 30 минут; зелёный - обнаружена или заблокирована в реальном времени; серый - вне scope.

Метрики для презентации результатов Red Team заказчику:


Detection Rate в 21% - из 14 техник SOC увидел 3. Block Rate в 0% - ни одна техника не остановлена автоматикой. MTTD в 47 минут при рекорде lateral movement в 51 секунду (CrowdStrike, 2025) - алерт приходит, когда атакующий уже на третьем хосте. Эти цифры CISO понимает без технического бэкграунда, и они же становятся основанием для бюджета.

Рекомендации по устранению уязвимостей: Sigma и D3FEND как deliverable​

Для валидации рекомендаций стоит указывать тесты из репозитория Atomic Red Team. Для T1003 доступны тесты: Gsecdump (command_prompt, Windows), Credential Dumping with NPPSpy (PowerShell, Windows), Dump svchost.exe to gather RDP credentials (PowerShell, Windows). Для T1059.001: Mimikatz, Run BloodHound from local disk, Run Bloodhound from Memory using Download Cradle - все через PowerShell на Windows. Blue Team получает не только правило детекции, но и способ проверить, что правило работает. Это ключевой момент - правило без теста это как замок без ключа: выглядит надёжно, но проверить нечем.

Отдельный блок - LOLBAS-техники. Если оператор использовал легитимные системные утилиты для атаки, в отчёте указываются конкретные бинарники: Rpcping.exe для проброса учётных данных (T1003), Sqldumper.exe или Createdump.exe для дампа памяти процессов (T1003), Powershell.exe для execution (T1059.001). Стандартные Sigma-правила могут не покрывать эти паттерны - тогда отчёт содержит конкретные command line patterns для написания custom-правил. LOLBAS - головная боль для SOC, потому что блокировать системные утилиты нельзя, а мониторить их аргументы мало кто умеет.

Debrief с заказчиком: взаимодействие после Red Team​

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

Формат, который работает: операторы и защитники вместе проходят таймлайн. Оператор: "В 09:17 я выполнил credential dump на WS-FIN-012 через NPPSpy". SOC: "В 09:18 мы увидели алерт по правилу win_alert_mimikatz_keywords.yml, но классифицировали как false positive". Или: "У нас нет логов за этот период - Sysmon не настроен на аудит обращений к lsass.exe". Такая коммуникация с заказчиком Red Team превращает дебриф из презентации в совместное расследование.

Подготовка к презентации результатов Red Team заказчику:

• Два набора материалов - executive deck для руководства (5-7 слайдов с метриками) и технический walkthrough для SOC (полный таймлайн с IoC)
• Предварительная отправка отчёта - за 2-3 рабочих дня. SOC готовит свои логи для сопоставления
• Decision maker на встрече - лицо, утверждающее бюджет на remediation. Без него дебриф - набор рекомендаций без исполнителя
• Ретест забронирован заранее - как отмечает StrikeCyber в руководстве по Red Team engagement, бронирование ретеста до начала операции - самый эффективный механизм превращения отчёта в дедлайн

Работа с возражениями SOC-команды​

SOC оспаривает результаты - это нормально и ожидаемо. Три типичных возражения и как на них отвечать:

"Нереалистичный сценарий." По данным Verizon DBIR 2025, 36% инцидентов начинаются с фишинга, 68% утечек связаны с человеческим фактором. Сценарий "фишинг -> credential dump -> lateral movement" - статистически доминирующий вектор, а не лабораторный эксперимент.

"Алерт был, аналитик не успел обработать." Фиксируется в отчёте как detection с указанием MTTD. Если MTTD - 4 часа, а среднее время lateral movement - 62 минуты (CrowdStrike Global Threat Report 2025), алерт бесполезен. Вопрос не в наличии алерта, а в скорости реакции.

"Хост стоял на вывод из эксплуатации." В момент операции хост находился в production-сегменте с сетевым доступом к целевым системам. Планы на вывод не снижают текущий риск. (На одном engagement нам так сказали про три хоста из пяти - видимо, весь домен планировали вывести.)

Ключевое правило: руководство фреймит встречу как измерение, а не как суд. Формулировка "мы проверяем готовность" создаёт конструктивную атмосферу. Формулировка "мы покажем, где SOC допустил ошибки" гарантирует сопротивление. По наблюдениям TrustedSec, защитники находят дебриф полезным при условии, что руководство воспринимает результат как информацию для улучшения, а не как вердикт.

Продолжение, которое работает лучше всего - purple team сессия по тем техникам, которые SOC пропустил. Защитники строят и валидируют детекцию по горячим следам, а через квартал повторный Red Team проверяет, что улучшения удержались.

Антипаттерны отчётности по итогам Red Team операции​

Ошибки, которые превращают хорошую операцию в бесполезный PDF:

PDF без машиночитаемых артефактов. ATT&CK Navigator layer не экспортирован в JSON, IoC не вынесены в CSV. Blue Team вручную перебивает хеши из документа в SIEM - и ожидаемо не делает этого. Каждый отчёт сопровождается ZIP: JSON layer для Navigator, CSV с IoC, конвертированные Sigma-правила для SIEM заказчика.

Скриншоты без контекста. Скриншот консоли C2 без hostname и таймстампа - артефакт, который SOC не может верифицировать. На дебрифе прозвучит: "Откуда я знаю, что это не ваш стенд?". На каждом скриншоте - видимый hostname и UTC-время, подпись описывает действие и результат.

Рекомендации без приоритизации. Список из 40 рекомендаций одинакового веса парализует remediation. Три уровня: критический (30 дней), высокий (90 дней), средний (следующий квартал). Критических - не больше пяти. Если у вас 15 критических рекомендаций - вы не расставили приоритеты, вы просто всё покрасили в красный.

Один документ на двух читателей. CISO не открывает терминал. SOC-инженер не считает ROI. Executive report (5 страниц, метрики, бизнес-импакт) и technical report (полный таймлайн, IoC, detection rules) - два отдельных документа или чётко разделённые блоки одного.

Отсутствие позитивных наблюдений. Отчёт из сплошной критики вызывает защитную реакцию. Если Blue Team обнаружила PowerShell cradle через 47 минут - это результат, который стоит зафиксировать и усилить. На каждые пять gap - минимум одно позитивное наблюдение. Это не лесть, а калибровка для SOC.

Восемь из десяти отчётов, которые попадали мне в руки от коллег, страдают одной болезнью: оператор пишет для оператора. Формулировки, прозрачные для человека с открытой C2-консолью, бесполезны для CISO, утверждающего бюджет. Качество отчёта измеряется не количеством скриншотов и не числом найденных техник, а процентом рекомендаций, внедрённых заказчиком через квартал. Если этот процент ниже 30 - проблема не в заказчике.

Отдельная боль - отсутствие культуры ретеста. Операция проведена, акт подписан. Через полгода - новый engagement, те же gap. Бронирование ретеста одновременно с подписанием договора ломает этот порочный круг: появляется дедлайн, появляется ответственный, появляется измеримый результат. Без этого отчётность по итогам Red Team операции - строка в compliance-чеклисте, которая не сокращает ни время детекции, ни поверхность атаки. Я убеждён, что через пару лет ретест станет обязательным пунктом контракта на engagement - те команды, которые начнут включать его сейчас, получат преимущество и на уровне отчётов, и на уровне реальной защиты заказчика.

Проверьте свой последний отчёт: сколько рекомендаций из него внедрено? Если не знаете ответа - вот и первый gap, который стоит закрыть. На WAPT тему отчётности и debrief разбирают на отдельном модуле с разбором реальных кейсов.