В прошлом году мы проводили adversary simulation для финансовой организации - SOC из 15 аналитиков, Splunk Enterprise, CrowdStrike Falcon на эндпоинтах. Четверг, 10:40 утра: red team получает начальный доступ через Valid Accounts (T1078, Initial Access) - учётные данные VPN-подрядчика из утёкшей базы. К 14:15 - дамп LSASS через
Sqldumper.exe, штатную утилиту отладки MS SQL, классифицированную как LOLBAS (T1003.001, Credential Access). К 16:30 - Pass the Hash (T1550.002, Lateral Movement) до Domain Admin. SOC зафиксировал ноль алертов за весь четверг и пятницу. Первый тикет появился в понедельник - L1-аналитик вручную заметил аномальную RDP-сессию (T1021.001) при разборе еженедельных логов.Четыре дня от компрометации до обнаружения. В реальной атаке за это время данные 400 000 клиентов уже лежали бы на маркетплейсе в даркнете, а компания готовилась бы к оборотным штрафам по 152-ФЗ.
Этот кейс - не аномалия. Это типичный результат, когда внутренний пентест проводится раз в год по договору, а SOC живёт в параллельной реальности. Ниже - о том, как превратить разовые тесты во внутренний пентест-процесс, где red team и SOC работают на одну цель.
Почему разовый пентест крупной компании не закрывает задачу
Разовый пентест отвечает на вопрос «можно ли нас взломать?» Ответ всегда - да. Отчёт попадает в ящик CISO, уязвимости частично патчатся, через полгода инфраструктура меняется до неузнаваемости: новые сервисы, ротация администраторов, миграция на другой SIEM. Ценность отчёта к этому моменту - нулевая.Но проблема глубже. Разовый пентест не тестирует SOC. Защитная команда знает о тестировании или вовсе не участвует. Detection engineering не получает обратной связи. SIEM-правила не валидируются на реальных TTP. Результат: SOC работает вслепую, red team генерирует бэклог findings, который blue team физически не успевает разгрести. Русскоязычные материалы по внутреннему пентесту (Habr, Solar Security, отраслевые блоги) фокусируются на составлении ТЗ и общей методологии сканирования - ни один из них не описывает, как встроить тестирование в операционный цикл SOC.
По данным SANS (блог «Building an Internal Red Team? Go Purple First»), паттерн повторяется в каждой организации: red team стабильно находит дыры, blue team отстаёт, через полгода руководство просит «больше коллаборации». Зачем проходить этот болезненный цикл, если можно начать правильно?
Purple team упражнения как фундамент внутреннего red team
Классическая ошибка - нанять двух offensive-специалистов и назвать это «внутренний red team». Через полгода они стабильно получают DA за день, blue team демотивирован бесконечными findings, а руководство задаёт вопрос: «Где training value?» Я видел эту историю четырежды в разных индустриях.Согласно методологии SANS (Jorge Orchilles, Antonio Piazza), если строить внутренний red team с нуля, рациональнее начинать с purple team упражнений. Логика простая: сначала убедитесь, что SOC способен детектировать базовые TTP, и только потом переходите к stealth-операциям. Модифицированная модель зрелости: Vulnerability Scanning - Vulnerability Assessment - Penetration Testing - Purple Team - Red Team - Adversary Emulation. Purple team стоит перед red team, а не после - и это ключевое отличие от классического подхода.
Пентест, purple team или red team операции - когда что применять
| Критерий | Пентест | Purple Team | Red Team |
|---|---|---|---|
| Цель | Найти и подтвердить уязвимости в scope | Улучшить detection на конкретные TTP | Проверить устойчивость к целенаправленной атаке |
| SOC участвует | Нет или знает о тестировании | Да, в реальном времени - экраны расшарены | Нет, работает в штатном режиме |
| Длительность | 1-4 недели | 1-5 дней на одно упражнение | Недели - месяцы |
| Что тестирует | Технические контроли | Технологии + процессы + людей (совместно) | Всё, включая реакцию руководства |
| Когда нужен | Compliance, первичная оценка | SOC есть, но detection coverage неизвестна | SOC зрелый, базовые TTP детектируются |
| Стоимость | Низкая (внешний подрядчик) | Средняя (обе команды одновременно) | Высокая (длительная кампания, custom C2) |
| Применимость | Любая организация с сетью | Организация с SOC и SIEM | Зрелая ИБ-программа с detection engineering |
Правило принятия решения: если SOC не способен стабильно детектировать PowerShell execution (T1059.001, Execution) и LSASS dump (T1003.001, Credential Access) - red team engagement будет пустой тратой бюджета. Начните с purple team. Если даже purple team преждевременен - начните с penetration testing для инвентаризации уязвимостей.
Пошаговое построение внутреннего пентест-процесса
Ниже - структура процесса, который я выстраивал в трёх enterprise-средах с SOC разной зрелости. Не разовый проект, а цикл с ежеквартальным повторением.Требования к окружению
Перед первым упражнением:На каждую TTP формируется карточка результата. Карточки накладываются на ATT&CK Navigator - и вы получаете реальную, а не декларируемую карту detection coverage.
Detection-чеклист: adversary simulation и SOC мониторинг атак
Минимальный набор правил, которые должны работать до запуска любой adversary simulation. Если менее половины покрыто - занимайтесь detection engineering, а не red team операциями.T1003.001 LSASS Memory - Credential Access:
YAML:
# Sigma: Suspicious LSASS Access
title: Suspicious LSASS Process Access
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1038'
- '0x1410'
- '0x1438'
- '0x1FFFFF'
filter_system:
SourceImage|startswith: 'C:\Windows\System32\'
SourceImage|endswith:
- '\wmiprvse.exe'
# taskmgr.exe исключён из фильтра - возможна маскировка (T1036)
condition: selection and not filter_system
level: highSqldumper.exe, procdump.exe. Но есть слепая зона: если атакующий использует direct syscalls и обходит user-mode хуки, EDR с hook-based подходом пропустит event. CrowdStrike Falcon с kernel-level ETW-TI детектирует это на уровне ядра; ранние версии некоторых EDR без kernel telemetry - нет. Контекст вашего стека определяет, достаточен ли Sigma-фильтр или нужна дополнительная телеметрия.T1550.002 Pass the Hash - Lateral Movement: ищите Event ID 4624 с Logon Type 3 (Network) в связке с NTLM-аутентификацией (не Kerberos) от нетипичного source host. Если в вашем baseline рабочие станции не ходят друг к другу по NTLM - любой такой event workstation-к-workstation должен быть алертом.
T1070.001 Clear Windows Event Logs - Defense Evasion: Event ID 1102 (Security Log cleared) - алерт без исключений. В штатной среде Security Log не очищается вручную. Единственный допустимый false positive - автоматическая ротация через Group Policy, но она генерирует другой паттерн событий.
T1078 Valid Accounts - Insider Threat: самый сложный detection. Легитимная учётка, легитимный хост, легитимное время. Что искать: логин service account в нерабочее время, логин с нового source IP (особенно VPN из нетипичной геолокации), одновременная активность одной учётки с двух хостов. Тут нужен выстроенный baseline (NIST CSF 2.0, DE.AE-01 - явное требование к baseline сетевых операций). Без baseline ложные срабатывания сделают правило бесполезным.
T1059.001 PowerShell - Execution: включите Script Block Logging (Event ID 4104) и Module Logging. Ищите base64-encoded команды, вызовы
Invoke-Expression, DownloadString, IEX. Внимание: опытный red team использует обфускацию - detection на уровне строковых сигнатур недостаточен. Нужны правила на поведенческие паттерны: цепочка PowerShell → сетевое соединение → запись файла.Метрики: тестирование SOC эффективности через MTTD и MTTR
Без метрик процесс не масштабируется и не защищается перед бюджетным комитетом. Две ключевые:MTTD (Mean Time to Detect) - среднее время от выполнения техники до первого алерта в SIEM. Считается по каждой TTP из плана. Ориентиры, которые я использую как target после 2-3 циклов:
- T1003.001 LSASS dump: менее 5 минут (при правильном Sysmon-конфиге срабатывает почти мгновенно)
- T1550.002 Pass the Hash: менее 15 минут (зависит от частоты корреляции в SIEM)
- T1078 Valid Accounts от скомпрометированного инсайдера: часы-дни (detection на уровне аномалий, не сигнатур - принципиально другой класс задачи)
Таблица для tracking по итогам каждого упражнения:
| Техника | MTTD факт | MTTD цель | MTTR факт | MTTR цель | Статус |
|---|---|---|---|---|---|
| T1003.001 LSASS | Не обнаружено | < 5 мин | N/A | < 30 мин | Gap |
| T1059.001 PowerShell | 3 мин | < 5 мин | 45 мин | < 30 мин | Частично |
| T1550.002 PtH | Не обнаружено | < 15 мин | N/A | < 60 мин | Gap |
| T1070.001 Clear Logs | 1 мин | < 1 мин | 15 мин | < 15 мин | Ок |
| T1078 Valid Accounts | Не обнаружено | < 4 часа | N/A | < 2 часа | Gap |
После каждого квартального цикла таблица обновляется. Через 3-4 итерации вы видите тренд: MTTD снижается, detection coverage на ATT&CK Navigator растёт, процессные проблемы (долгая эскалация L1 → L2, отсутствие playbook'а для конкретной TTP) становятся видимыми и исправляемыми. Этот тренд - то, что можно показать CISO и бюджетному комитету как threat-informed defense в действии.
Организации, которые вкладывают деньги во «внутренний red team», на самом деле покупают бесконечный цикл демотивации blue team. Я видел это четыре раза подряд в разных индустриях: red team стабильно получает DA, SOC стабильно пропускает, руководство стабильно спрашивает «что не так с SOC». Хотя вопрос нужно задавать процессу, а не людям. Red team операции без обратной связи в detection engineering - дорогой способ доказывать одно и то же каждый квартал.
Внутренний пентест-процесс, который работает, строится не вокруг атаки, а вокруг обратной связи. Purple team - не компромисс и не «red team для слабаков». Это формат, где каждое упражнение заканчивается конкретным улучшением: новым Sigma-правилом, обновлённым playbook'ом, пересмотренным порогом в UEBA. Стелс-операция красной команды, где SOC пропускает всё, даёт одну строку в отчёте: «не обнаружено». Purple team сессия за те же часы даёт десять строк в detection coverage map с конкретными action items.
Мой прогноз: через пару лет формулировка «у нас есть red team» станет маркером незрелости, если за ней не стоит измеримый purple team процесс с квартальным трендом MTTD. Compliance-фреймворки уже движутся в эту сторону - NIST CSF 2.0 требует baseline сетевых операций (DE.AE-01) и анализ алертов от detection-систем (RS.AN-01), а не абстрактное «проведите пентест раз в год». По свежим кейсам подобного рода на codeby.net разбираем внедрение этих практик на ежемесячной основе - с конкретными detection gap и метриками.
Последнее редактирование:
