Red Teaming vs Пентест: разница на практике

Полгода назад я закрыл red team ассессмент для крупного ритейлера. Три недели OPSEC-операций, кастомный C2 через DNS-over-HTTPS, обход Kaspersky EDR на endpoint'ах, lateral movement через пять сегментов сети - domain admin получен цепочкой из четырёх техник. CISO был доволен. Но вот в чём штука: ту же SQLi на внешнем периметре, которая дала initial access, обычный пентест нашёл бы на второй день за треть бюджета.

У организации не было ни работающего SOC, ни тестированного IR-плана, ни EDR на половине хостов. Мы потратили месяц на скрытную операцию в среде, где некому было нас обнаруживать.

Разница между red teaming и пентестом - не в крутости инструментов и не в бюджете. Она в том, на какой вопрос отвечает каждая методология - и готова ли организация услышать ответ.

Что тестирует пентест и почему этого часто достаточно​

Пентест - scope-bound оценка защищённости инфраструктуры с фокусом на поиск и эксплуатацию технических уязвимостей. Границы жёстко определены до старта: конкретная подсеть, веб-приложение, API-эндпоинты, облачный сегмент. Цель - найти максимум уязвимостей за ограниченное время и выдать приоритизированный список с рекомендациями по remediation.

NIST SP 800-115 разделяет пентест и полноценную адверсариальную симуляцию - и это разделение имеет практические последствия. Результаты пентеста напрямую закрывают требования PCI DSS v4.0.1 (ежегодный пентест + тестирование после значимых изменений инфраструктуры), SOC 2, HIPAA. Red team ассессмент для этих задач не подходит структурно - он отвечает на другой вопрос.

Методология пентеста следует структурированному процессу:

1. Planning и recon - определение scope, fingerprinting сервисов, OSINT по целям
2. Scanning и enumeration - маппинг attack surface, обнаружение версий сервисов
3. Exploitation - эксплуатация найденных уязвимостей с подтверждением impact
4. Post-exploitation - оценка путей lateral movement и privilege escalation
5. Reporting - приоритизация по severity, remediation guidance для IT-команды

Типичный таймлайн: от одной до шести недель. Стоимость предсказуемая, scope контролируемый, результат - конкретный remediation roadmap, который IT-отдел может взять в работу на следующий день.

Момент, который часто упускают: при пентесте защитные средства могут быть ослаблены. По данным Schellman, WAF нередко пропускает трафик тестировщика, чтобы уложиться во временное окно. Для пентеста - нормальная практика. Но именно поэтому он непригоден для оценки реальных detection capabilities.

Виды тестирования на проникновение​

Внутри пентеста существуют принципиально разные форматы - и путаница между ними отдельная проблема:

• External pentest - атака с позиции внешнего злоумышленника: recon, сканирование периметра, эксплуатация публичных сервисов. По MITRE ATT&CK - Exploit Public-Facing Application (T1190, Initial Access). По данным Mandiant M-Trends 2025, exploits составляют 38% всех initial access векторов - самый распространённый путь проникновения
• Internal pentest - тестирование из позиции инсайдера: Password Spraying (T1110.003, Credential Access), движение через SMB/Windows Admin Shares (T1021.002, Lateral Movement)
• Web application pentest - фокус на бизнес-логику приложения, OWASP Top 10, API security
• Continuous pentest - регулярное тестирование вместо разовых ассессментов. Актуально для организаций с быстро меняющимся attack surface, особенно при активном развёртывании облачных сервисов

Пентест в формате black-box (без предварительных данных) имитирует внешнего атакующего. Grey-box (частичная информация) экономит время на recon при тестировании внутренних систем. Выбор формата определяется целями, а не модой.

Что тестирует red teaming: эмуляция угроз полного цикла​

Red teaming - адверсариальное тестирование, при котором команда имитирует действия реального threat actor против всей организации: людей, процессов и технологий. Scope не ограничен конкретной системой. Цель red teaming - проверить, способна ли организация обнаружить, среагировать и остановить мотивированного атакующего до того, как он доберётся до критических активов.

Ключевое отличие от пентеста: red team тестирует не уязвимости - red team тестирует blue team. Метрика успеха - не количество найденных CVE, а dwell time (время присутствия в сети до обнаружения), полнота coverage SIEM-правил и скорость incident response.

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

По данным OffSec, red team операция выходит за пределы технических уязвимостей и включает:

• Кибератаки - эксплуатация уязвимостей в сетях и приложениях
• Физический доступ - tailgating, клонирование пропусков, установка аппаратных закладок
• Социальная инженерия - целевой spearphishing с payload, vishing, pretexting
• Атаки на supply chain - имитация компрометации вендора или подрядчика
• Insider threat - симуляция действий инсайдера

Эта многовекторность и отличает red teaming от "расширенного пентеста". Реальный APT не выбирает один вектор - он комбинирует.

Сценарии атак APT: как строится red team операция​

Red team операция строится по логике Cyber Kill Chain и маппится на MITRE ATT&CK framework. Типичный сценарий из практики:

Recon (недели 1-2). OSINT по сотрудникам: LinkedIn, утёкшие базы, корпоративные email в breach-дампах. По данным IBM X-Force 2025, более 6000 свежих учётных данных появляется в dark web ежедневно. Red team проверяет, есть ли среди них credentials целевой организации. Параллельно - пассивный fingerprinting инфраструктуры без прямого взаимодействия с целью.

Initial Access (недели 2-4). Два основных вектора: Spearphishing Attachment (T1566.001, Initial Access) с кастомным payload, заточенным под конкретный EDR заказчика, или Valid Accounts (T1078, Initial Access). По данным Verizon DBIR 2025, 38% утечек данных связаны с кражей учётных данных, а IBM X-Force 2025 фиксирует рост атак с использованием действительных credentials на 71% год к году. Red team проверяет конкретную вещь: детектирует ли SIEM аномальный вход с нетипичного IP или устройства?

Persistence и C2. Установка beacon с шифрованным каналом связи. Living-off-the-land техники - PowerShell, WMI, scheduled tasks - чтобы не триггерить EDR. По данным OffSec, red team операторы используют "advanced evasion techniques to bypass EDR and antivirus, custom malware, encrypted command and control channels, anti-forensic techniques""Продвинутые техники обхода EDR и антивирусов, кастомных малварей, шифрованных команд и контролируемых каналов, анти-форензических технологий".

Разница с пентестом видна здесь максимально: пентестер запустит nmap -sV в первые минуты и не будет думать о шуме в логах. Red team оператор потратит дни на изучение baseline сетевого трафика, прежде чем отправит первый DNS-запрос к C2. Это разные профессии с разной дисциплиной.

Lateral Movement (недели 4-8). Дамп credentials через LSASS Memory (T1003.001, Credential Access), передвижение через SMB/Windows Admin Shares (T1021.002, Lateral Movement) или SSH (T1021.004, Lateral Movement). Каждый шаг - с проверкой: заметил ли SOC? Сработал ли alert? Пришёл ли аналитик разбираться?

Достижение цели. Доступ к domain admin, эксфильтрация тестовых данных, демонстрация пути к Data Encrypted for Impact (T1486, Impact) без реального шифрования. Результат - не список уязвимостей, а timeline: "день 5 - initial access, день 12 - domain admin, день 18 - доступ к финансовой БД, SOC не обнаружил ни одного этапа".

Red team и pentest: разница в одной таблице​

Когда нужен red team: матрица зрелости организации​

Выбор методологии тестирования безопасности определяется не бюджетом. Определяющий фактор - зрелость security-программы. Red team ассессмент давит на систему, которая уже построена. Если системы нет - пентест покажет те же gaps дешевле.

Red team ассессмент имеет смысл при одновременном выполнении условий (адаптировано из фреймворка Mitnick Security):

1. EDR развёрнут и активен на всех endpoints, включая рабочие станции - не только серверы
2. IR-план документирован и протестирован - не просто написан для аудитора, а пройден хотя бы в настольных учениях
3. Проведено минимум 2-3 пентеста с ремедиацией и верификацией исправлений между циклами
4. Критические активы определены - конкретные системы, данные и бизнес-процессы
5. Blue team операционно активна - кто-то реально разбирает алерты, а не просто собирает логи в /dev/null

Если хотя бы одно условие не выполнено - пентест эффективнее. Как формулируют в Mitnick Security: "A red team engagement will find the gaps - but a pentest is typically the more efficient path to the same findings""В ходе проверки методом красной команды будут выявлены уязвимости, однако пентест, как правило, позволяет обнаружить те же проблемы более эффективным способом." для организаций без зрелой защиты.

Дерево решений:

• Никогда не проводили security-тестирование -> vulnerability assessment -> устранение -> пентест
• Регулярные пентесты находят всё меньше critical findings -> red team ассессмент
• Red team показал gaps в detection -> purple team для совместной проработки
• Зрелая программа -> комбинация: vulnerability scanning (continuous) + пентест (квартальный) + red team (ежегодный)

Purple team методология: мост между атакой и защитой​

Purple team - не отдельный тип ассессмента, а формат взаимодействия. Red team выполняет конкретные техники, blue team защищается, обе стороны разбирают результаты в реальном времени. По формулировке Mitnick Security, purple teaming - "collaborative follow-on to a red team engagement", цель которого - превратить findings в конкретные detection rules.

Практический пример: red team оператор выполняет credential dumping из LSASS (T1003.001) через comsvcs.dll вместо Mimikatz. Blue team в реальном времени проверяет: сработало ли правило в SIEM? Если нет - пишут detection rule на месте. Оператор переключается на другую технику - rundll32, procdump, direct syscalls. Цикл повторяется. За день прорабатывается десяток техник с немедленной обратной связью.

Это самый быстрый способ поднять detection coverage, который я видел на практике.

Purple team методология особенно ценна после red team ассессмента, когда gaps уже выявлены и нужно их закрывать правилами. В этом контексте pentest vs red team vs purple team - не конкурирующие подходы, а последовательные этапы зрелости.

Практика: один вектор - два подхода​

Каждая найденная уязвимость эксплуатируется, документируется, получает severity rating. IT-команда в курсе, WAF может быть ослаблен, EDR не мешает. Результат - структурированный отчёт через две недели.

Подход red team оператора​

Фокус на один рабочий вектор с минимальным шумом. Recon растягивается на дни:
Активное сканирование - только после анализа baseline трафика и понимания, что именно вызовет alert. Один порт, один сервис, один exploit. Дальше - закрепление, C2 через DNS/HTTPS, медленный lateral movement. Постоянный вопрос: заметили или нет?

Разница не в инструментах (они часто одинаковые), а в OPSEC-дисциплине и определении успеха. Пентестер радуется каждой новой уязвимости. Red team оператор радуется каждому дню в сети без обнаружения.

Rules of Engagement: что согласовывать до старта​

Тема, которую русскоязычные материалы почти не раскрывают - Rules of Engagement (RoE). Для пентеста RoE обычно укладываются в одну страницу: scope, таймлайн, контакты, ограничения (не ронять production). Для red team ассессмента RoE - критический документ:

• Scope boundaries - что в scope, что вне (физический доступ? social engineering ключевых сотрудников? атаки на supply chain?)
• Deconfliction process - как отличить действия red team от реального инцидента. Без этого SOC может эскалировать операцию как настоящую атаку (на одном проекте именно так и произошло - неприятные полчаса для всех)
• Emergency contacts - кому звонить, если red team случайно нашёл следы реального злоумышленника
• Data handling - как обращаться с реальными данными, к которым red team получит доступ
• Legal authorization - письменное разрешение на каждый вектор, особенно social engineering и физический доступ

Без грамотных RoE red team операция превращается в юридический и операционный риск для обеих сторон.

За последние три года я провёл около двадцати пентестов и шесть red team операций. Наблюдение подтверждается раз за разом: большинство организаций заказывают red team слишком рано. Хотят "проверить как в жизни" - при этом basic patching не закрыт, SIEM собирает логи в никуда, а incident response сводится к "позвонить подрядчику".

В такой ситуации red team за три месяца найдёт ровно то, что пентест нашёл бы за две недели - но заказчик заплатит в пять раз больше и получит отчёт, который некому обрабатывать.

Моя позиция: если пентесты до сих пор возвращаются с critical findings - red team ассессмент преждевременен. Вложите бюджет в remediation и зрелость blue team. Когда пентестеры начнут скучать на ваших проектах - тогда red teaming покажет gaps, которые пентест не видит по определению: скорость реакции SOC, полноту detection coverage, устойчивость к целевому фишингу.

Проблема не в выборе между red teaming vs пентест - проблема в честной оценке, к чему организация готова прямо сейчас. На HackerLab есть сценарии, где нужно собрать полную цепочку от initial access до impact без подсказок - ближе к реальной операции, чем любая сравнительная таблица.