Как обойти SOC при пентесте: stealth-сканирование

На внутреннем пентесте финтех-компании я запустил masscan --rate 1000 по подсети /16 - через 40 секунд все SYN-пакеты начали возвращаться RST. Inline IPS отрезал атакующую машину от сегмента, а SOC-аналитик уже открывал инцидент-тикет. Итог: три дня пересогласования scope, смена IP и репутационный удар по команде. Классика.

На OSCP и Hack The Box такого не бывает - там нет Suricata с правилами ET Open, нет SIEM-корреляции и нет аналитика, который в 2 часа ночи смотрит на дашборд Kibana. Ниже - конкретные пороги срабатывания, Sigma-правила для самопроверки и техники, которые позволяют провести рекон без единого алерта.

Что видит SOC при запуске сканера​

Прежде чем говорить об обходе, стоит разобраться в детект-логике с другой стороны барьера. В терминах MITRE ATT&CK сканирование портов - это Active Scanning (T1595, Reconnaissance) на внешнем периметре и Network Service Discovery (T1046, Discovery) внутри сети. Обе техники покрыты десятками правил детекции: в репозитории SigmaHQ по тегу T1046 зарегистрировано 22 Sigma-правила, по T1595 - ещё 5. Каждое - конкретный сценарий, при котором ваш пентест проваливается.

Сигнатурный детект: как Suricata и Zeek ловят Nmap​

Suricata из коробки распознаёт Nmap по нескольким маркерам. Правило ET SCAN Nmap Scripting Engine User-Agent Detected срабатывает, когда NSE-скрипты (набор -sC) шлют HTTP-запросы со специфичным User-Agent. Правило ET SCAN Nmap Service Detection ловит характерные пробы версионного сканирования (-sV): серию нестандартных запросов на открытый порт с интервалом в миллисекунды. Тут никакой эвристики - прямое совпадение сигнатуры в пакете.

Zeek работает иначе. Он разбирает каждое соединение и записывает его состояние. SYN-скан генерирует массу записей со статусом conn_state=S0 - SYN отправлен, handshake не завершён. Одно-два таких соединения в минуту - норма. Сотня с одного IP - маркер сканирования. Даже если Suricata промолчала по сигнатуре, Zeek зафиксирует аномалию на протокольном уровне.

Согласно документации Nmap по обходу IDS, системы обнаружения работают на пороговой основе: заданное число проб за определённый таймфрейм. Это помогает отсеять ложные срабатывания от легитимного трафика, но задаёт чёткую границу, ниже которой можно пройти. Точные пороги индивидуальны для каждого SOC - на практике от единиц до десятков уникальных портов с одного IP за минуту. Дефолтный nmap -sS сканирует 1000 портов и генерирует 200+ SYN в секунду - алерт прилетает мгновенно.

Behavior detection: поведенческий анализ трафика в SIEM​

Даже без сигнатур SIEM (Splunk, Elastic, MaxPatrol SIEM) коррелирует по формуле: один source IP → N уникальных destination ports за T секунд. Но поведенческий анализ ловит не только скорость.

Последовательный перебор портов (21, 22, 23, 25, 53...) - маркер автоматизированного инструмента. Легитимный клиент обращается к конкретному сервису, а не идёт по словарю портов. SIEM с ML-модулем (Elastic ML, Splunk UBA) строит baseline сетевого поведения каждого хоста и детектирует отклонения. Медленный скан с рандомизированным порядком портов всё равно создаёт статистическую аномалию, если объём уникальных destination портов выше нормы для этого хоста.

Место в kill chain: рекон - самый первый этап. По данным CrowdStrike Global Threat Report 2025, среднее breakout time (от initial access до lateral movement) - 62 минуты (рекорд - 51 секунда). Метрика измеряет скорость атакующего после получения доступа, а не время от детекта рекона до эксплуатации, но суть ясна: чем раньше SOC заметит активность, тем больше шансов на блокировку. Пентест проваливается не потому что нет уязвимостей, а потому что вас обнаружили на первом шаге.

Нюанс, который упускают почти все русскоязычные руководства: сам сканер может спалиться через DNS. По умолчанию Nmap делает reverse-DNS lookup каждого целевого IP, и эти запросы фиксируются DNS-сервером цели или IDS как признак сканирования. Документация nmap.org рекомендует флаг -n для отключения reverse-DNS - меньше шума, быстрее скан. Некоторые IDS могут отправлять обратные запросы (например, NetBIOS) к источнику скана - если такие пробы прилетели, это сигнал остановиться и сменить тактику.

Пассивный рекон: уклонение от детекта SOC без единого пакета​

Самый надёжный способ обойти SOC при пентесте - не генерировать трафик к цели вообще. Пассивный рекон (Gather Victim Network Information, T1590) использует публичные источники и создаёт ноль сетевого шума.

Сервис crt.sh индексирует все SSL-сертификаты, выданные доверенными CA (Certificate Transparency). Запрос %.target.com возвращает поддомены, включая внутренние: vpn.target.com, staging.target.com, jenkins-ci.target.com. SOC это не видит - запрос идёт к стороннему сервису.

SecurityTrails, VirusTotal Passive DNS показывают историческую DNS-информацию без прямых запросов к DNS-серверам цели (Passive DNS). Но осторожно с прямыми DNS-запросами: Sigma-правило net_dns_external_service_interaction_domains.yml (T1595) ловит обращения к сервисам вроде Burp Collaborator и interactsh. Аномальный объём DNS-запросов к доменам цели тоже может быть замечен зрелым SOC.

Shodan и Censys индексируют открытые порты и баннеры сервисов. Фактически это результат чужого сканирования, к которому вы обращаетесь через API. Ноль трафика к цели - полная картина внешнего периметра с версиями сервисов.

Я для себя выработал простое правило: перед любым активным сканированием - 30-60 минут пассивного рекона. В большинстве случаев этого хватает за глаза, чтобы составить карту внешнего периметра и определить 3-5 приоритетных целей для точечного активного скана.

Stealth сканирование сети: техники и ограничения​

SOC видит SYN-пакеты с четырёх IP - три поддельные. Аналитик не определит настоящий источник без корреляции с MAC-адресами или другой телеметрией. Но есть нюансы: decoy-техника чувствительна к anti-spoofing фильтрации (uRPF, BCP38) на маршрутизаторах - в сетях с ingress filtering spoofed-пакеты будут отброшены до достижения цели. Внутри L2-сегмента decoy IP должны принадлежать активным хостам - иначе отсутствие ARP-ответа выдаст подделку.

Idle scan (-sI) - ещё более хитрая штука. Атакующий использует «зомби-хост» с предсказуемым IP ID counter для проксирования скана. Целевая система видит SYN только от зомби. Условие: зомби должен иметь инкрементальный (global) IP ID и минимальный собственный трафик. Многие современные ОС по умолчанию используют рандомизированный или per-connection IP ID, что затрудняет idle scan; фактическое поведение зависит от версии ядра/ОС и требует проверки (nmap --script ipidseq). На практике зомби-кандидаты - принтеры, IoT-устройства, старые серверы. Тот самый зоопарк в корпоративной сети.

Фрагментация пакетов: почему она уже не работает​

Параметр -f разбивает TCP-заголовки на несколько IP-фрагментов. IDS, не собирающая фрагменты перед инспекцией, пропустит пробу. Но по данным документации nmap.org, современные IDS (Suricata 6+, Snort 3) выполняют дефрагментацию по умолчанию. Хуже того: фрагментированные пакеты в корпоративной сети сами по себе аномальны и могут вызвать отдельный алерт. На зрелом SOC это скорее красный флаг, чем способ обхода. Техника осталась в арсенале для совсем уж устаревших систем - но рассчитывать на неё не стоит.

Red team скрытая разведка через living off the land​

На внутреннем пентесте самый эффективный обход behavior detection - не использовать сканеры вообще. По данным CrowdStrike, 79% атак в 2024 году прошли без вредоносного ПО - через living off the land. Тот же принцип работает для фазы рекона.

PowerShell и WMI вместо сканера портов​

Одиночный запрос Test-NetConnection -ComputerName target -Port 445 выглядит как штатная сетевая проверка администратора. Для автоматизации - цикл с рандомной задержкой:
В логах это неотличимо от работы сисадмина. Но тут есть подвох: PowerShell Script Block Logging (Event ID 4104) записывает содержимое скриптов. EDR-решения (CrowdStrike Falcon, Kaspersky EDR Expert) отслеживают подозрительные PowerShell-паттерны. Sigma-правило proc_creation_win_hktl_winpwn.yml (T1046) ловит характерные паттерны рекон-инструментов. Если SOC настроил мониторинг PowerShell - цикл по портам будет замечен в журналах.

LDAP-рекон в Active Directory​

Внутри Windows-домена LDAP-запросы к контроллеру - абсолютно легитимная активность. Запрос всех компьютеров домена через Get-ADComputer -Filter * возвращает полный список хостов с IP-адресами. Запрос SPN (Get-ADUser -Filter {ServicePrincipalName -ne "$null"}) выдаёт сервисные аккаунты - карта сервисов без единого SYN-пакета на целевые хосты.

На Linux-хостах внутри периметра доступны утилиты, которые не вызывают подозрений у EDR: curl -s -o /dev/null -w "%{http_code}" http://target:80 для проверки HTTP-порта, конструкция (echo > /dev/tcp/target/22) 2>/dev/null && echo "port open" || echo "port closed" в bash для проверки TCP-порта без внешних утилит. Каталог GTFOBins документирует легитимные Unix-бинарии для нестандартных целей - например, ftp позволяет получить интерактивный shell через встроенную команду !command, а make - для выполнения произвольных команд.

Ограничение LDAP-рекона: нетипичные LDAP-фильтры могут быть замечены зрелым SOC. Sigma-правило proc_creation_win_pua_pingcastle.yml (T1046) детектирует запуск PingCastle - инструмента AD-аудита, который активно использует LDAP. Так что «легитимно» - понятие относительное.

Sigma-правила для рекона: незаметное сканирование портов глазами SOC​

Привычка red team оператора с хорошим OPSEC - после каждого действия задать себе вопрос: «какому правилу детекции это соответствует?» Ниже - ключевые Sigma-правила для фазы рекона из репозитория SigmaHQ.


Практическое упражнение: развернуть Suricata + Elastic Stack на виртуальной машине (минимум 16 ГБ RAM), загрузить правила ET Open и конвертировать Sigma-правила через pySigma в формат Elastic. Атаковать целевую VM стандартным Nmap-профилем, переключиться на Kibana - увидите десятки алертов. Затем менять параметры (--scan-delay, --max-rate, количество портов) и наблюдать, как алерты исчезают. Добавить ML-модуль Elastic - и убедиться, что поведенческий анализ ловит вас снова даже без сигнатур. Отрезвляет.

Сравнение техник: SOC vs red team тактики​

Чеклист: обход SOC при сканировании на реальном пентесте​

1. Уточнить у заказчика: есть ли SOC, какой SIEM, какие NIDS (Suricata, Snort, Zeek)
2. Определить формат: black box (SOC не знает о пентесте) vs grey box (SOC в курсе, но не знает вектор)
3. Пассивный рекон: crt.sh, Shodan, SecurityTrails, Passive DNS - минимум 30 минут до первого пакета
4. Составить short-list из 5-10 приоритетных портов на основе пассивного рекона
5. На внутреннем пентесте - LOTL первым: PowerShell, WMI, LDAP до любого Nmap
6. Первый активный шаг - точечный скан 3-5 портов с --scan-delay 10s
7. Выждать 5 минут. Заказчик не позвонил - расширять scope постепенно
8. После каждого действия сверяться: какому Sigma-правилу (T1046, T1595) это соответствует?
9. Вести лог действий с таймстампами - при разборе с SOC после пентеста бесценно

Пентест, на котором SOC вас поймал на фазе рекона, - провал вне зависимости от того, сколько уязвимостей вы бы нашли дальше. По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника глобально - 11 дней, исторический минимум. APT-группировки добиваются таких показателей не потому что используют zero-day на каждом шагу, а потому что не запускают сканеры. Они используют LOTL-техники, подглядывают в Active Directory через штатные запросы и двигаются в темпе легитимного пользователя.

Стандартное обучение (HTB, THM, OSCP) формирует привычку к шумному рекону - ни одна из этих платформ не имеет живого SOC. После 100 машин с nmap -A кажется, что это нормальный первый шаг. На коммерческом проекте - нет.

Я для себя выработал правило: Nmap запускается последним, не первым. Сначала пассивный рекон, затем LOTL-разведка, и только если оба не дали полной картины - точечный медленный скан по 3-5 портам. За два года с таким подходом ни разу не получил звонок от SOC в первый день проекта. Если хочешь отработать эту цепочку на практике - на HackerLab есть лабы с настроенным SOC, где алерт прилетает по-настоящему.