Правила Suricata для детекта атак Kerberoasting и Pass-the-Hash: от паттерна в трафике до рабочей сигнатуры

Первые три итерации моей Kerberoasting-сигнатуры давали порядка 40% ложных срабатываний. RC4-запросы от пары серверов на Windows Server 2008 забивали fast.log так плотно, что реальную атаку в этом потоке было не разглядеть. По данным IBM X-Force Threat Intelligence Index 2025, атаки с использованием действительных учётных данных выросли на 71% за год. CrowdStrike фиксирует среднее время lateral movement после первичного доступа — 62 минуты (рекорд — 51 секунда). Сетевой IDS даёт конкретное окно для обнаружения, если знать, какой паттерн искать, и не утонуть в ложных алертах. Разберём, как написать кастомные правила Suricata для обнаружения Kerberoasting и Pass-the-Hash, протестировать их на pcap и привести false positive rate к рабочему уровню.

Место Kerberoasting и Pass-the-Hash в цепочке атаки

Прежде чем писать сигнатуры — нужно понять, что мы ловим и в какой момент атакующий оставляет след на сети.

Kerberoasting (T1558.003, тактика Credential Access по классификации MITRE ATT&CK — это открытая база тактик и техник атак, а T-коды вроде T1558.003 — её идентификаторы). Суть техники: атакующий с обычной доменной учёткой запрашивает TGS-билеты (Ticket Granting Service — билеты доступа к конкретным сервисам в протоколе Kerberos) для сервисных аккаунтов. Билеты зашифрованы паролем сервисного аккаунта, и атакующий подбирает этот пароль офлайн — без единого лишнего обращения к контроллеру домена на этапе брутфорса.

Pass-the-Hash (T1550.002, тактика Lateral Movement) — атакующий использует не сам пароль, а его NTLM-хеш для аутентификации на удалённых хостах через SMB (Server Message Block — протокол доступа к общим ресурсам Windows). Хеш получен на предыдущем шаге — из дампа процесса LSASS (T1003.001) или другими способами.

Зачем это атакующему? Kerberoasting даёт пароли сервисных аккаунтов — часто с повышенными привилегиями, которые не менялись годами. PtH позволяет двигаться по сети, не зная пароля в открытом виде. Вместе эти техники — типовая связка для захвата домена: получил хеш или пароль на одном хосте, аутентифицировался на десяти.

Полная цепочка:

1. Initial Access — атакующий получает точку входа в домен
2. Credential Access — Kerberoasting (хеши сервисных аккаунтов) или дамп LSASS (NTLM-хеши)
3. Lateral Movement — Pass-the-Hash (перемещение по сети с украденными хешами через SMB, T1021.002)
4. Post-exploitation — доступ к целевым системам, эксфильтрация

Suricata стоит на сети и видит шаги 2 и 3 — при условии, что трафик проходит через контролируемый сегмент в незашифрованном виде.

Детект Kerberoasting Suricata: сетевой паттерн и сигнатура

[Применимо: внутренний пентест / SOC-мониторинг, незашифрованный Kerberos-трафик к DC]

Kerberos работает на порту 88 (TCP/UDP). Когда пользователь запрашивает доступ к сервису, контроллер домена получает TGS-REQ (запрос) и возвращает TGS-REP (билет). Ключевое поле, которое выдаёт атакующего — encryption type (etype).

RC4 etype как маркер Kerberoasting в Kerberos-пакете

Клиент указывает в TGS-REQ, какие типы шифрования поддерживает:

• etype 17 — AES128-CTS-HMAC-SHA1 (современный)
• etype 18 — AES256-CTS-HMAC-SHA1 (современный)
• etype 23 — RC4-HMAC (устаревший, основан на MD4-хеше пароля)

Инструменты атаки — Rubeus, Impacket GetUserSPNs — по умолчанию запрашивают RC4 (etype 23), потому что RC4-хеш подбирается на порядки быстрее AES. В домене с Windows Server 2016+ и включённой политикой AES-only запрос RC4 — аномалия.

В hex-дампе пакета etype 23 кодируется как 02 01 17 — ASN.1 DER-кодировка (тег Integer, длина 1 байт, значение 0x17 = 23). Эту байтовую последовательность и ищет сигнатура.

Предусловие: детект чистый, если RC4-запросы в вашем домене — редкость. В legacy-средах (Server 2008/2003) RC4 может быть нормой; тогда порог срабатывания нужно поднимать (об этом ниже, в разделе про тюнинг).

Suricata (проект поддерживается OISF, актуальная стабильная линейка — 7.x) имеет встроенный парсер Kerberos (krb5), что позволяет работать на уровне приложения, а не сырого TCP.

Структура правила Suricata — заголовок (действие, протокол, адреса, порты) и тело (опции в скобках):

alert krb5 $HOME_NET any -> $HOME_NET any ( \
  msg:"CODEBY Kerberoasting - TGS-REQ RC4 etype"; \
  flow:to_server,established; \
  content:"|02 01 17|"; \
  threshold:type threshold, track by_src, count 3, seconds 60; \
  classtype:credential-access; \
  sid:9000001; rev:1; )

Разбор каждой строки:

• alert krb5 — действие alert (логировать, не блокировать), протокол krb5 (Kerberos на уровне приложения)
• $HOME_NET any -> $HOME_NET any — трафик внутри защищаемой сети (от рабочей станции к DC)
• msg: — текст алерта в fast.log и eve.json (JSON-лог событий, основной формат для интеграции с SIEM)
• flow:to_server,established — только установленные соединения к серверу (DC)
• content:"|02 01 17|" — ищем байтовую последовательность (ASN.1 Integer = 23, RC4-HMAC)
• threshold: count 3, seconds 60 — срабатываем при 3+ запросах с одного IP за минуту. Одиночный RC4-запрос может быть легитимным, серия — подозрительна: Rubeus и GetUserSPNs запрашивают TGS для всех SPN-аккаунтов (Service Principal Name — имя сервиса в AD) за одну сессию
• sid:9000001 — уникальный ID правила (для кастомных используйте диапазон 9000000+)

Нюанс: content-match на 02 01 17 может совпасть с ASN.1 Integer 23 в другом поле Kerberos-пакета. Для продакшна стоит свериться с ET Open (Emerging Threats Open — открытый набор правил, обновляемый сообществом), где аналогичные сигнатуры отлажены на тысячах инсталляций. Правило выше — рабочая стартовая точка, от которой вы итерируете под свою сеть.

Pass-the-Hash обнаружение IDS: пишем сигнатуру для SMB/NTLM

[Применимо: внутренний пентест / SOC, SMB-трафик без шифрования (SMB1/SMB2)]

Когда атакующий выполняет PtH через Impacket psexec, CrackMapExec или Mimikatz, на сети происходит:

1. SMB-соединение (порт 445)
2. Session Setup с NTLMSSP (NT LAN Manager Security Support Provider — подпротокол аутентификации внутри SMB)
3. Обмен: Type 1 (Negotiate) → Type 2 (Challenge) → Type 3 (Authenticate)

Сигнатура NTLMSSP в пакете — ASCII-строка NTLMSSP + нулевой байт, за которой следует тип сообщения. Type 3 (Authenticate) — 03 00 00 00.

Что отличает PtH от легитимной NTLM-аутентификации

На уровне одного пакета — почти ничего. PtH использует тот же NTLM, что и обычный логон. Различия, которые можно выразить в сигнатуре:

• Серийность: PtH-инструменты перебирают хосты массово (lateral movement), генерируя десятки NTLM-сессий за секунды
• Характерные named pipes: Impacket psexec создаёт подключения к IPC$ и ADMIN$
• NTLMv1 в modern-среде: если политика требует NTLMv2, а Suricata видит NTLMv1 — аномалия

Универсального правила «это PtH» не существует. Строим поведенческую сигнатуру — серия NTLM-аутентификаций от одного IP за короткое время:

alert smb $HOME_NET any -> $HOME_NET 445 ( \
  msg:"CODEBY Possible PtH - rapid NTLM auth"; \
  flow:to_server,established; \
  content:"NTLMSSP|00|"; \
  content:"|03 00 00 00|"; distance:0; \
  threshold:type threshold, track by_src, count 5, seconds 120; \
  classtype:lateral-movement; \
  sid:9000002; rev:1; )

Разбор:

• alert smb — протокол SMB (парсер Suricata идентифицирует SMB-трафик)
• content:"NTLMSSP|00|" — строка NTLMSSP + нулевой байт (начало NTLMSSP-блока)
• content:"|03 00 00 00|"; distance:0 — тип сообщения 3 (Authenticate), distance:0 означает: начинать поиск сразу после предыдущего совпадения
• threshold: count 5, seconds 120 — 5 NTLM Authenticate от одного IP за 2 минуты. Легитимный пользователь редко аутентифицируется на 5+ хостов за пару минут; CrackMapExec делает это за секунды

Когда правило НЕ работает: SMB3-шифрование (Windows 10+ / Server 2016+ по умолчанию шифруют SMB-сессии). Suricata видит зашифрованный поток и не может заглянуть внутрь NTLMSSP. В таких средах детект PtH — задача EDR (CrowdStrike Falcon, Kaspersky EDR Expert, PT XDR) и событий Windows Event Log (Event ID 4624, Logon Type 3).

Тестирование правил Suricata на pcap: пошаговая инструкция

Требования к окружению

• ОС: Linux (Ubuntu 20.04+, Debian 11+, Kali Linux)
• Suricata: 6.0+ (для парсеров krb5 и smb). Проверить версию: suricata -V
• RAM: от 2 ГБ (для pcap-файлов до 500 МБ)
• Pcap-файл: захват с Kerberos-/SMB-аутентификацией. Сгенерировать можно в лабе: Impacket GetUserSPNs.py (Kerberoasting) или psexec.py (PtH) при захвате tcpdump на интерфейсе
• Права: root или sudo

Шаг 1. Сохраните оба правила в файл, например /tmp/custom-ad.rules — по одному правилу на строку.

Шаг 2. Запустите Suricata в режиме pcap replay: suricata -r /path/to/capture.pcap -s /tmp/custom-ad.rules -k none -l /tmp/suricata-test/.

Флаги: -r включает оффлайн-режим (анализ файла), -s загружает кастомные правила, -l задаёт директорию логов. Флаг -k none — отключает проверку контрольных сумм. Без него Suricata молча проигнорирует пакеты с невалидным checksum, а в pcap из Wireshark или tcpdump это штатная ситуация (checksum offloading на сетевой карте). На этом спотыкается большинство при первом запуске — правило загружено, pcap корректный, алертов ноль. Просто добавьте -k none.

Ожидаемый результат: Suricata создаст файлы fast.log и eve.json в /tmp/suricata-test/.

Шаг 3. Проверьте результат: cat /tmp/suricata-test/fast.log. Если правила сработали — увидите строки с текстом msg вашего правила. Для детального анализа: jq 'select(.event_type=="alert")' /tmp/suricata-test/eve.json покажет алерты в структурированном JSON с payload и IP-адресами.

Как понять, что получилось: в fast.log — строки CODEBY Kerberoasting или CODEBY Possible PtH. Если файл пуст — правило не сработало: либо pcap не содержит нужных паттернов, либо синтаксическая ошибка.

Шаг 4. Проверьте загрузку правила: grep "9000001" /tmp/suricata-test/suricata.log. Строка rule loaded — правило в работе, failed to parse — ошибка синтаксиса.

Ложные срабатывания Suricata: тюнинг кастомных правил

Kerberoasting: legacy RC4 vs реальная атака

Главный источник FP — legacy-системы с легитимным RC4:

• Windows Server 2008 и старше
• Устаревшие приложения (отдельные версии SAP, Oracle)
• Linux-хосты с Kerberos-клиентом в дефолтной конфигурации

Тюнинг: в файле /etc/suricata/threshold.config пропишите suppress gen_id 1, sig_id 9000001, track by_src, ip 10.0.5.15 (IP legacy-сервера). Это подавит алерты от конкретного хоста, не отключая правило глобально.

Второй подход — поднять count в threshold. Если 2-3 legacy-системы шлют по 1-2 RC4-запроса в час, поставьте count 10, seconds 60. Kerberoasting-инструмент всё равно сгенерирует больше: Rubeus перебирает все SPN-аккаунты за одну сессию.

Pass-the-Hash: мониторинг vs lateral movement

FP для PtH-правила генерируют:

• Мониторинг (Nagios, Zabbix), проверяющий доступность SMB-сервисов
• Скрипты автоматизации с массовым подключением к серверам
• SCCM/MECM, опрашивающий хосты по расписанию

Тюнинг: исключите IP мониторинг-серверов через suppress. Если порог 5 за 120 секунд избыточен для вашей сети — поднимайте до 10-15. CrackMapExec по умолчанию проверяет десятки хостов за секунды, так что даже высокий порог ловит реальную атаку.

Ограничения сигнатурного детекта атак Active Directory IDS

Правила Suricata для детекта атак Active Directory — не самостоятельный детектор, а элемент эшелонированной системы. IDS видит сеть, EDR видит хост, SIEM связывает обе картины. В production-среде Suricata (с ELK или Splunk) коррелирует сетевые алерты с событиями endpoint-уровня. Но в средах с legacy-инфраструктурой — SMB1/2 без шифрования, Kerberos без armoring и IDS на зеркальном порту у ядра сети — кастомные сигнатуры дают результат, который не покрывается штатными наборами правил.

Стенд для отработки собирается за пару часов: Windows Server в качестве DC, Kali с Impacket как атакующая машина, Suricata на третьем хосте с tcpdump для захвата pcap. Если хочется попробовать детект-инжиниринг на уже готовой инфраструктуре с задачами по категориям — на HackerLab.pro есть CTF-задачи по forensics и network analysis, платформа российская, от экосистемы Codeby, нужна регистрация.

Два года назад я начал писать кастомные правила Suricata для AD-атак и извлёк один жёсткий урок: идеальная сигнатура существует только в статьях. В реальной инфраструктуре с 500+ хостами, тремя legacy-контроллерами и мониторингом, который аутентифицируется по NTLM каждые 30 секунд, каждое правило — компромисс между чувствительностью и объёмом алертов, которые дежурный аналитик способен обработать за смену. Порог в 5 NTLM-аутентификаций за 2 минуты работает для одной сети и даёт 200 FP в сутки в другой. Сигнатура на RC4 etype ловит Rubeus в лабе, но в проде на неё наступает SAP-сервер 2009 года. Большинство руководств по Suricata игнорируют эту часть — сосредотачиваются на красивом правиле и чистом pcap. Реальная работа detection-инженера на 80% состоит из suppress-правил, threshold-подбора и разговоров с сисадминами о том, почему их мониторинг-скрипт порождает 150 SMB-сессий в минуту. Кто этого не признаёт — либо не дошёл до прода, либо привык молча выключать правила. Если строишь SOC-компетенции системно — IB Basics закрывает эту базу за пару месяцев, от kill chain до первых правил.