TShark анализ pcap: автоматизация детекта Kerberoasting, AS-REP Roasting и LDAP-разведки в CI-пайплайне

В 2024 году ransomware-группа положила Ascension — одну из крупнейших сетей клиник в США. По данным Zscaler, точкой входа стали слабости Kerberos с RC4-шифрованием в Active Directory. Инцидент дошёл до сенатора Рона Уайдена, который написал в FTC с требованием привлечь Microsoft за поддержку устаревшего RC4. Между первым аномальным запросом сервисного тикета и полным захватом домена прошли часы — но в pcap-дампе (файле с записью сетевого трафика) атака была видна с первого пакета. Автоматического разбора, который поднял бы тревогу, не было.

Здесь — конкретная задача: один bash-скрипт, который принимает pcap на вход, прогоняет через цепочку TShark-фильтров и выдаёт вердикт — есть ли в трафике следы Kerberoasting, AS-REP Roasting или LDAP-разведки. Скрипт встраивается в CI/CD-пайплайн (конвейер автоматической сборки и тестирования) и работает без GUI на любом сервере с установленным TShark.

Бизнес-логика атак: от LDAP-разведки до компрометации домена Active Directory

Прежде чем писать фильтры, разберём, зачем атакующему эти три техники. Все они сидят на раннем этапе kill chain — между получением первого доступа в корпоративную сеть (initial access) и латеральным движением (lateral movement). Конечная цель — учётные данные, которые откроют путь к Domain Admin.

LDAP-перечисление — этап разведки. Атакующий подключается к контроллеру домена (DC — сервер, управляющий Active Directory) по протоколу LDAP и запрашивает список учётных записей с определёнными свойствами: привязанные Service Principal Names (SPN — идентификаторы, связывающие сервис типа SQL Server или IIS с учётной записью AD) или установленный флаг DONT_REQUIRE_PREAUTH. По классификации MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1558 — её идентификаторы) этот шаг относится к тактике Discovery.

Kerberoasting следует за разведкой. Обнаружив учётные записи с SPN, атакующий запрашивает у KDC (Key Distribution Center — компонент AD, выдающий тикеты аутентификации) сервисный тикет TGS-REP для каждого SPN. Тикет зашифрован хешем пароля сервисной учётной записи. Если DC возвращает тикет с шифрованием RC4-HMAC (etype 23 — устаревший алгоритм, который ломается на GPU за часы), атакующий забирает его и перебирает пароль офлайн. В MITRE ATT&CK это техника T1558.003, тактика Credential Access.

AS-REP Roasting (T1558.004, тактика Credential Access) бьёт по учётным записям с отключённой Kerberos pre-authentication — предварительной аутентификацией, при которой клиент доказывает знание пароля до получения тикета. Если pre-auth отключена, KDC возвращает AS-REP (Authentication Service Response) с данными, зашифрованными паролем пользователя, вообще без проверки. По данным Netwrix, типичные жертвы — legacy-учётки сервисов и совместимости, со статичными паролями и широким доступом.

Финансовый импакт конкретен: скомпрометированная сервисная учётка с правами на бэкапы или scheduled tasks открывает атакующему путь к данным, инфраструктуре деплоя и ransomware-развёртыванию — как в случае с Ascension. Все три техники оставляют чёткие следы в сетевом трафике. И их можно ловить автоматически через анализ pcap.

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

Перед написанием фильтров — чеклист готовности стенда.

• ОС: Linux (Ubuntu 22.04+, Debian 12+, Kali Linux). macOS поддерживается, но CI-раннеры обычно крутятся на Ubuntu
• TShark: версия 3.6+ (входит в пакет tshark или wireshark-common). Проверка: tshark --version
• bash: 4.0+ (стандарт на современных Linux)
• RAM: для pcap до 500 МБ хватит 2 ГБ. Для файлов 1 ГБ+ нужно 4+ ГБ
• pcap-дампы: из продакшена (снятые с SPAN-порта или сетевого TAP на сегменте AD) или сгенерированные в лаборатории утилитами Rubeus / Impacket (GetUserSPNs.py). Тестовые дампы с Kerberos-трафиком доступны на wiki.wireshark.org/SampleCaptures
• Для CI: GitHub Actions или GitLab CI раннер с правами sudo (для установки tshark)

Установка на Ubuntu: sudo apt-get install -y tshark. При установке система спрашивает, разрешать ли захват трафика непривилегированным пользователям — для CI-контекста ответ «Да».

TShark фильтры для детекта Kerberoasting в pcap

Kerberoasting оставляет характерный сетевой след: запросы TGS-REQ (Ticket Granting Service Request, тип сообщения Kerberos 12) и ответы TGS-REP (тип 13), где шифрование — RC4-HMAC (etype 23). В современных AD-средах нормой стал AES256 (etype 18), поэтому RC4 в TGS-обмене — красный флаг.

Как выглядит Kerberoasting в трафике

В нормальной инфраструктуре (Windows Server 2016+, функциональный уровень домена 2012 R2+, актуальные патчи) TGS-ответы используют AES256-CTS-HMAC-SHA1-96. Появление RC4-HMAC в TGS-REP означает одно из двух: либо в домене живёт legacy-система, требующая RC4, либо кто-то намеренно запрашивает слабое шифрование для офлайн-перебора.

Фильтр для TGS-REQ с запросом RC4 ловит момент, когда клиент просит устаревшее шифрование: tshark -r evidence.pcap -Y 'kerberos.msg_type == 12 && kerberos.etype == 23'. Здесь -r указывает файл pcap, а -Y задаёт display filter (фильтр отображения — работает после разбора пакета, в отличие от capture filter, который отбрасывает пакеты при записи). Поле kerberos.msg_type == 12 отбирает TGS-запросы, kerberos.etype == 23 — только те, где запрошен RC4.

Для структурированного вывода добавьте -T fields с нужными полями: tshark -r evidence.pcap -Y 'kerberos.msg_type == 13 && kerberos.etype == 23' -T fields -e frame.number -e ip.src -e ip.dst -e kerberos.CNameString. Это покажет номер кадра, IP источника и назначения, имя клиента. Если из одного IP за секунды приходят десятки TGS-REQ с RC4 к разным SPN — перед вами Kerberoasting.

Ложные срабатывания и предусловия

[Применимо: внутренний мониторинг, AD-среды с функциональным уровнем домена 2008 R2+]

Ложные срабатывания возникают в средах с legacy-системами, легитимно требующими RC4 — старые SQL Server, Java-приложения на устаревших JDK, некоторые NAS-устройства. Если такие системы есть, дополните фильтр исключением их IP: && !(ip.src == 10.0.2.50).

Работает если: Kerberos-трафик идёт по TCP/UDP 88 в открытом виде (стандарт внутри корпоративной сети). Не работает если: между точкой захвата и DC стоит VPN-туннель или IPsec — TShark не разберёт содержимое зашифрованных пакетов.

AS-REP Roasting: обнаружение в сетевом дампе через TShark

AS-REP Roasting (T1558.004) эксплуатирует учётные записи с отключённой pre-authentication. Нормальный поток выглядит так: клиент отправляет AS-REQ (тип 10) с зашифрованной меткой времени PA-ENC-TIMESTAMP, KDC проверяет — и только потом возвращает AS-REP (тип 11) с TGT (Ticket Granting Ticket — тикет, дающий право запрашивать другие тикеты). Если pre-auth отключена, KDC отдаёт AS-REP без проверки — любой участник сети получает данные, зашифрованные паролем жертвы.

Как описывает XPN InfoSec Blog, в Wireshark-захвате разница видна сразу: для защищённой учётки — AS-REQ, ответ ERR_PREAUTH_REQUIRED, второй AS-REQ с PA-ENC-TIMESTAMP, AS-REP. Для учётки без pre-auth — первый же AS-REQ и мгновенно AS-REP с зашифрованным TGT. Этот зашифрованный блоб атакующий передаёт в Hashcat (режим 18200) или John the Ripper для перебора.

Фильтры TShark для AS-REP Roasting

Ключевой индикатор — AS-REP (msg_type 11) с шифрованием RC4-HMAC (etype 23): tshark -r evidence.pcap -Y 'kerberos.msg_type == 11 && kerberos.etype == 23' -T fields -e frame.number -e ip.dst -e kerberos.CNameString. Здесь ip.dst — адрес получателя AS-REP (адрес атакующего), а kerberos.CNameString покажет имя учётной записи, для которой выдан ответ.

Для углублённого анализа полезно также ловить сами AS-REQ: tshark -r evidence.pcap -Y 'kerberos.msg_type == 10' -T fields -e ip.src -e kerberos.CNameString. Если из одного IP летят AS-REQ к десяткам разных CName — это паттерн перебора, характерный для Rubeus (asreproast) или Impacket (GetNPUsers.py). По данным Atomic Red Team (публичный набор тестов для техник MITRE ATT&CK), стандартные тесты для T1558.004 включают Rubeus и PowerView — оба генерируют именно такой Kerberos-трафик.

XPN InfoSec Blog также описывает использование TShark на offensive-стороне: команда tshark -r capture.pcap -T pdml > output.pdml конвертирует pcap в PDML-формат (XML-представление пакетов), после чего скрипт krbpa2john.py из JTR Jumbo извлекает AS-REP хеши для офлайн-перебора. Тот же TShark-вывод, который blue team берёт для детекта, red team берёт для эксплуатации. Знание обеих сторон — то, что отличает специалиста от оператора.

Как отличить от легитимного трафика

Единичный AS-REP с RC4 сам по себе — не приговор. Windows по умолчанию сначала отправляет AS-REQ без pre-auth, получает ERR_PREAUTH_REQUIRED и повторяет запрос — это поведение описано в RFC 4120 (Kerberos V5), §3.1.3. Подозрительным становится объёмный паттерн: десятки AS-REQ к разным CName из одного IP за секунды. У легитимного клиента нет причин перебирать имена учётных записей.

LDAP-перечисление: обнаружение разведки AD в сетевом трафике

Перед запуском Kerberoasting или AS-REP Roasting атакующий проводит разведку: ищет учётные записи с SPN или с отключённой pre-authentication. Стандартный метод — LDAP-запросы к контроллеру домена.

Индикаторы в LDAP-запросах

Два типа LDAP search requests однозначно указывают на подготовку к атаке.

Поиск SPN-учёток (преамбула Kerberoasting). Атакующий запрашивает объекты с атрибутом servicePrincipalName. Фильтр: tshark -r evidence.pcap -Y 'ldap.filter contains "servicePrincipalName"' -T fields -e frame.number -e ip.src -e ldap.filter. Если фильтр вернул строки — кто-то целенаправленно ищет сервисные учётки.

Поиск учёток без pre-auth (преамбула AS-REP Roasting). Как описывает XPN InfoSec Blog, атакующий использует LDAP-фильтр с битовой маской: (userAccountControl:1.2.840.113556.1.4.803:=4194304). Значение 4194304 — десятичное представление флага DONT_REQUIRE_PREAUTH (0x400000). Фильтр TShark: tshark -r evidence.pcap -Y 'ldap.filter contains "userAccountControl"' -T fields -e frame.number -e ip.src -e ldap.filter. Появление подстроки 4194304 или 1.2.840.113556.1.4.803 в выводе — практически гарантированный индикатор разведки. Ни одно штатное бизнес-приложение не ищет учётные записи по этому критерию.

Общий объём LDAP search-запросов с одного IP тоже информативен. Команда tshark -r evidence.pcap -Y 'ldap' -T fields -e ip.src | sort | uniq -c | sort -rn покажет, какой адрес сгенерировал больше всего LDAP-запросов. Всплеск от одного источника на фоне стабильного baseline — повод копнуть глубже.

[Применимо: внутренний мониторинг. Не работает, если LDAP-трафик идёт через LDAPS (порт 636/TCP с TLS) — TShark не разберёт содержимое запросов без ключей шифрования.]

Какой фильтр включать: decision tree

Выбор набора фильтров зависит от инфраструктуры:

• Современная среда без legacy (Server 2016+, AES-only): etype 23 в любом Kerberos-обмене — однозначная аномалия, whitelist не нужен. Включайте все три фильтра
• Среда с legacy-системами (старые SQL, JDK 6, NAS): все три фильтра + whitelist IP-адресов систем, легитимно использующих RC4
• В pcap нет LDAP-трафика (захват только на порту 88): фильтры Kerberoasting и AS-REP Roasting без LDAP-перечисления

Один скрипт — автоматизация разбора pcap для SOC

Фильтры собраны — объединяем в один скрипт. Логика простая: TShark прогоняет pcap трижды (по разу на каждый тип атаки) и подсчитывает подозрительные пакеты. Если хотя бы один счётчик ненулевой — скрипт завершается с кодом 1, и CI-пайплайн помечает джоб как failed.

#!/bin/bash
PCAP="${1:?Использование: $0 <файл.pcap>}"
KERB=$(tshark -r "$PCAP" -Y 'kerberos.msg_type==13 && kerberos.etype==23' 2>/dev/null | wc -l)
ASREP=$(tshark -r "$PCAP" -Y 'kerberos.msg_type==11 && kerberos.etype==23' 2>/dev/null | wc -l)
LDAP_E=$(tshark -r "$PCAP" -Y 'ldap.filter contains "servicePrincipalName" || ldap.filter contains "userAccountControl"' 2>/dev/null | wc -l)
printf '{"kerberoasting":%d,"asrep_roasting":%d,"ldap_enum":%d}\n' "$KERB" "$ASREP" "$LDAP_E"
if [ "$KERB" -gt 0 ] || [ "$ASREP" -gt 0 ] || [ "$LDAP_E" -gt 0 ]; then exit 1; fi
exit 0

Построчно. Первая строка принимает аргумент — путь к pcap; если не передан, скрипт выведет подсказку и остановится. Переменные KERB, ASREP и LDAP_E хранят количество строк вывода TShark — по сути, количество пакетов, прошедших фильтр. Перенаправление 2>/dev/null глушит stderr-сообщения TShark о загрузке диссекторов. printf формирует JSON с тремя полями. Последние две строки — проверка: если любой счётчик больше нуля, exit code 1.

Ожидаемый вывод при чистом трафике: {"kerberoasting":0,"asrep_roasting":0,"ldap_enum":0} и код возврата 0. При обнаружении атаки — ненулевые значения и код 1, джоб падает, CI отправляет нотификацию.

На практике скрипт обрастает деталями за неделю: добавляются метки времени первого и последнего подозрительного пакета (-e frame.time), список уникальных SPN, IP-адреса источников. JSON превращается в артефакт инцидента — его можно отправить в Slack через curl или положить в артефакты пайплайна для разбора.

Автоматизация в CI/CD: сетевой мониторинг в пайплайне SOC

Скрипт готов — встраиваем в пайплайн. Ниже конфиг для GitHub Actions: устанавливает TShark, забирает pcap-файлы из репозитория (папка tests/) и прогоняет скрипт. Если скрипт вернёт exit code 1, джоб провалится и придёт уведомление.

name: AD pcap analysis
on: [push, workflow_dispatch]
jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          echo 'wireshark-common wireshark-common/install-setuid boolean false' | sudo debconf-set-selections
          sudo apt-get update
          sudo DEBIAN_FRONTEND=noninteractive apt-get install -y tshark
      - run: chmod +x detect_ad_attacks.sh
      - run: |
          for f in tests/*.pcap; do
            echo "--- Scanning $f ---" && ./detect_ad_attacks.sh "$f"
          done

Для GitLab CI логика та же: image: ubuntu:22.04, стадия test, скрипт apt-get install -y tshark && ./detect_ad_attacks.sh tests/evidence.pcap. Артефакты сохраняются через artifacts: paths:.

Сценарии применения

SOC / Blue Team. Периодический анализ pcap-дампов с SPAN-порта или Zeek-сенсора на сегменте AD. Дампы складываются в git-репозиторий или подтягиваются из S3/MinIO, скрипт запускается по расписанию (on: schedule: cron: '0 */4 * * *'). Срабатывание — алерт в Slack.

Detection Engineering. Когда команда пишет новые детект-правила, pcap с тестовым трафиком атаки работает как unit-тест. Добавили дамп с Kerberoasting-трафиком, сгенерированным через Impacket GetUserSPNs.py в лаборатории, — скрипт должен вернуть ненулевой счётчик. Не вернул — правило не работает, коммит не проходит.

Ограничения TShark-подхода и когда он не работает

Автоматизация анализа pcap через TShark — инструмент, не серебряная пуля. Вот конкретные ситуации, когда подход деградирует.

Отсутствие корреляции — главное ограничение. TShark обрабатывает каждый пакет изолированно: он не скажет «10 TGS-REQ с RC4 за 5 секунд от одного IP». Для такого уровня детекта нужен SIEM — Elastic Security 8.x+ или Microsoft Sentinel — или Zeek, который строит connection-level логи и агрегирует сессии.

Детекция через EDR/Identity Protection. Microsoft Defender for Identity детектит Kerberoasting и AS-REP Roasting на уровне контроллера домена, анализируя Event ID 4769 (Ticket Encryption Type = 0x17 для RC4) и Event ID 4768. CrowdStrike Falcon Identity Protection покрывает аналогичные сценарии на identity-уровне. TShark-подход дополняет эти решения сетевой видимостью, которую они не дают, но не заменяет — особенно в средах без сетевого TAP.

Альтернативные инструменты. Для потокового мониторинга лучше подходят Zeek (бывший Bro) — он строит kerberos.log с полями request_type, cipher, client — и Suricata с правилами ET OPEN/ET PRO для Kerberoasting. Оба масштабируются на гигабиты трафика. TShark-скрипт из этой статьи — для точечного анализа дампов и CI-валидации, не для inline-мониторинга.

По классификации MITRE D3FEND (knowledge graph защитных техник), ключевые контрмеры против T1558.004 включают D3-CH (Credential Hardening — усиление паролей сервисных учёток и включение pre-auth), D3-DUC (Decoy User Credential — создание honeypot-учёток для раннего детекта; Zscaler описывает схему: decoy-учётка без pre-auth, с 30-символьным паролем, любой TGS-REQ к которой — автоматический индикатор атаки) и D3-CR (Credential Revocation — немедленная ротация при подозрении).

Среди SOC-инженеров укоренилось убеждение: для детекта атак на Kerberos достаточно мониторинга Windows Event Log. Event ID 4769 с Ticket Encryption Type 0x17 — и тема закрыта. Но я наблюдал ситуации, когда атакующий после компрометации DC первым делом чистил или отключал журналы Security — и весь детект на Event ID исчезал. Pcap с сетевого TAP — слой, который атакующий не контролирует: TGS-REP с etype 23 невозможно подделать или стереть постфактум, если дамп уже записан.

Неудобная правда: большинство команд этот слой игнорируют. Проще поставить галочку «SIEM мониторит 4769» и считать тему закрытой. Автоматизация pcap-анализа в CI меняет логику: дамп попадает в пайплайн, скрипт отрабатывает за секунды, JSON уходит в Slack. Не нужен аналитик, вручную открывающий Wireshark. Нужен инженер, который один раз напишет фильтр — и забудет до момента, когда пайплайн упадёт.

Это ремесло, и оно начинается с понимания того, что именно летит по проводу и почему. Если хочешь не разбирать чужие pcap по статьям, а системно освоить базу SOC-аналитика — IB Basics на codeby.school покрывает фундамент, от которого строятся такие пайплайны.