Перехват трафика Kerberos в Wireshark: находим точку входа Pass-the-Ticket

На внутреннем пентесте домена с четырьмя контроллерами мы поймали аномалию за 15 минут: хост, который ни разу не отправлял AS-REQ к контроллеру домена, вдруг начал слать TGS-REQ на файловый сервер. Один display-фильтр Wireshark — kerberos.msg_type == 12 с корреляцией по IP-источнику — и картина сложилась: кто-то инжектировал чужой Kerberos-тикет в сессию на скомпрометированной рабочей станции. Этот паттерн — отсутствие начальной аутентификации перед запросом сервисного тикета — главный сетевой маркер атаки Pass-the-Ticket, и его видно в дампе, если знать, куда смотреть. Ниже — пошаговый разбор: от настройки захвата до конкретных полей в пакетах и минилаба, где всё можно повторить.

Бизнес-логика атаки: зачем злоумышленнику ваш Kerberos-тикет

Прежде чем разбирать байты в Wireshark, разберёмся с мотивацией атакующего и финальным импактом для организации.

Pass-the-Ticket (PtT) — техника горизонтального перемещения (lateral movement) в сети. Злоумышленник, получив доступ к одной рабочей станции, извлекает Kerberos-тикеты из памяти и использует их для доступа к другим ресурсам домена — файловым серверам, базам данных, контроллерам домена — без знания пароля пользователя.

Почему это критично:

• Нет брутфорса, нет подбора паролей. Атакующий не генерирует шум в логах аутентификации — он предъявляет валидный тикет, который KDC (Key Distribution Center — центр выдачи ключей, роль на контроллере домена Active Directory) уже выписал легитимному пользователю.
• Эскалация привилегий. Если на скомпрометированной машине залогинен администратор домена, его TGT (Ticket Granting Ticket — «мастер-тикет», дающий право запрашивать доступ к любым сервисам в домене) открывает атакующему полный контроль над инфраструктурой.
• Скрытность. По данным Semperis, действия с использованием легитимных тикетов выглядят как обычная пользовательская активность. Для SOC-команды это головная боль — алерт не срабатывает, потому что формально всё легитимно.

Конечная цель варьируется: от вывода данных (data exfiltration) до развёртывания ransomware и создания бэкдоров для длительного присутствия в сети. По данным IBM X-Force Threat Intelligence Index 2025, 70% атак X-Force в целом затронули критическую инфраструктуру (без специфической разбивки по PtT). Lateral movement через украденные аутентификационные артефакты — один из типичных этапов таких кампаний.

[Применимо: внутренний пентест, Active Directory от Windows Server 2008+]

Как работает Kerberos-аутентификация в Active Directory

Kerberos — протокол аутентификации по умолчанию в Active Directory (AD). Чтобы понять, что именно ломается при Pass-the-Ticket, нужно разобрать нормальный обмен — четыре пакета, которые видны в дампе Wireshark.

Аналогия, которая помогает запомнить поток: представьте аэропорт. Вы приходите на стойку регистрации (AS-обмен) с паспортом (хеш пароля) и получаете посадочный талон (TGT). Потом подходите к конкретному гейту (TGS-обмен), предъявляете талон и получаете допуск на конкретный рейс (сервисный тикет). С этим допуском садитесь в самолёт (подключаетесь к сервису). Украсть TGT — всё равно что скопировать чужой посадочный: по нему можно получить допуск к любому рейсу в аэропорту.

AS-обмен: клиент получает TGT

Первый этап — начальная аутентификация. Клиент отправляет AS-REQ (Authentication Service Request) на контроллер домена через порт 88 (изначально по UDP, с fallback на TCP при больших ответах — например, при большом PAC). В пакете:

• cname — имя пользователя (principal), который аутентифицируется, например jsmith@CORP.LOCAL
• realm — имя домена в верхнем регистре (CORP.LOCAL)
• sname — всегда krbtgt/<REALM>, поскольку запрашивается TGT у службы krbtgt
• etype — список поддерживаемых алгоритмов шифрования. В современных средах AES256-CTS-HMAC-SHA1-96 (etype 18), в legacy-инфраструктурах — RC4-HMAC (etype 23)
• padata — Pre-Authentication Data: зашифрованная временная метка (PA-ENC-TIMESTAMP), которую KDC проверяет для подтверждения, что клиент знает пароль

Если KDC удовлетворён, он отвечает AS-REP с двумя компонентами:

• ticket — сам TGT, зашифрованный ключом учётной записи krbtgt. Клиент не может его расшифровать — просто хранит blob и предъявляет при следующих запросах.
• enc-part — часть, зашифрованная ключом клиента. Внутри — session key (сеансовый ключ) для последующего общения с KDC и параметры срока действия тикета.

TGS-обмен: клиент получает сервисный тикет

Когда пользователю нужен доступ к конкретному ресурсу (файловый сервер, SQL Server, Exchange), клиент отправляет TGS-REQ (Ticket Granting Service Request):

• ticket — TGT, полученный на предыдущем шаге, вложенный в структуру AP-REQ
• sname — SPN (Service Principal Name — уникальное имя сервиса в домене), например cifs/fileserver.corp.local для файловой шары или MSSQLSvc/dbserver.corp.local:1433 для SQL Server
• authenticator — зашифрованная session key’ем метка, подтверждающая, что клиент владеет сеансовым ключом

KDC отвечает TGS-REP:

• ticket — сервисный тикет, зашифрованный ключом учётной записи целевого сервиса. Клиент передаёт его серверу, который расшифровывает и проверяет.
• enc-part — новый session key для общения непосредственно с целевым сервисом.

Запомните: по умолчанию TGT живёт 10 часов (600 минут) и может обновляться в течение 7 дней — это Windows-дефолт, в продуктивных средах значения нередко изменены через групповую политику (GPO) домена. Если атакующий украл TGT, он должен использовать его внутри этого окна, иначе KDC откажет в выдаче сервисных тикетов.

Настройка Wireshark для перехвата Kerberos-трафика

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

Прежде чем запускать захват:

• Wireshark: любая актуальная версия (2.x/3.x/4.x), собранная с поддержкой MIT или Heimdal Kerberos для расшифровки keytab. Работает на Windows, Linux, macOS. В Kali Linux предустановлен.
• Сеть: нужно находиться в том же L2-сегменте, что и целевой трафик, либо использовать SPAN-порт/TAP на коммутаторе. В лабораторной среде (VirtualBox/VMware) достаточно Host-Only или Internal Network — весь трафик между VM виден без дополнительных настроек.
• Права: на Linux — запуск с sudo или добавление пользователя в группу wireshark. На Windows — права администратора.
• RAM: минимум 4 ГБ свободных для Wireshark при анализе крупных дампов.

В реальной корпоративной сети вы не увидите чужой трафик, просто подключившись к порту коммутатора — он пересылает фреймы только на MAC-адрес назначения. Для перехвата используйте SPAN-порт (зеркалирование трафика), сетевой TAP (физическое устройство-посредник) или, при наличии письменного разрешения на пентесте, ARP-спуфинг.

В сценарии grey box (когда заказчик выдал доменные учётные данные для тестирования) задача проще: вы можете захватить собственный нормальный Kerberos-обмен на рабочей станции как baseline и затем сравнивать с аномалиями.

Wireshark фильтры для Kerberos

Для первичного захвата через tcpdump используйте capture filter по порту:

# Захват Kerberos-трафика в файл pcap
# Предусловие: root-права, интерфейс eth0 подключён к нужному сегменту
sudo tcpdump -i eth0 -w kerberos.pcap port 88

После остановки захвата (Ctrl+C) откройте файл в Wireshark и используйте display-фильтры для навигации по пакетам. Вот набор, который я держу под рукой:

• kerberos — весь Kerberos-трафик
• kerberos.msg_type == 10 — только AS-REQ (начальная аутентификация)
• kerberos.msg_type == 11 — только AS-REP (ответ с TGT)
• kerberos.msg_type == 12 — только TGS-REQ (запрос сервисного тикета)
• kerberos.msg_type == 13 — только TGS-REP (ответ с сервисным тикетом)
• kerberos.msg_type == 30 — ошибки KRB-ERROR (неверный пароль, истёкший тикет, неизвестный SPN)
• kerberos.CNameString contains "admin" — запросы от пользователя с «admin» в имени
• kerberos.SNameString == "krbtgt" — только обращения к krbtgt (выдача TGT)
• kerberos.etype == 23 — запросы с алгоритмом RC4-HMAC (потенциальный downgrade)

Для расшифровки тикетов Wireshark может использовать keytab-файл. Подключается через Edit → Preferences → Protocols → KRB5 → Keytab file. По данным wiki.wireshark.org, Wireshark поддерживает расшифровку при сборке с библиотеками Heimdal или MIT Kerberos. Keytab можно создать утилитой ktutil, если известен пароль или ключ учётной записи. На пентесте keytab обычно формируется из извлечённых хешей.

Разбор Kerberos-аутентификации в Wireshark по полям

Поля AS-REQ и AS-REP

Откройте pcap с захваченным трафиком. Примените фильтр kerberos.msg_type == 10. Выберите пакет AS-REQ и раскройте дерево протокола в Packet Details. На что смотреть:

• pvno: версия Kerberos — всегда 5 в современных средах
• msg-type: 10 (krb-as-req)
• padata → PA-ENC-TIMESTAMP: зашифрованная временная метка. Если поля нет и KDC требует pre-authentication, следующим пакетом будет KRB-ERROR с кодом KDC_ERR_PREAUTH_REQUIRED — KDC попросит клиента повторить запрос с pre-auth. Отсутствие pre-auth эксплуатируется в атаке AS-REP Roasting, но это отдельная история.
• req-body → cname → name-string: имя principal — username
• req-body → realm: домен — CORP.LOCAL
• req-body → sname → name-string: всегда krbtgt и CORP.LOCAL
• req-body → etype: список поддерживаемых алгоритмов. Числовые коды: 18 = AES256-CTS-HMAC-SHA1-96, 17 = AES128, 23 = RC4-HMAC. Если среда использует AES, а в запросе присутствует только etype 23 — подозрительно: может указывать на downgrade-атаку или старый инструмент.

Теперь найдите соответствующий AS-REP (фильтр kerberos.msg_type == 11). В нём:

• ticket → tkt-vno, realm, sname: метаданные TGT. sname — всегда krbtgt/<REALM>.
• ticket → enc-part: зашифрованное содержимое тикета. Без keytab Wireshark покажет только шифрованный blob. С keytab вы увидите PAC (Privilege Attribute Certificate — структура с группами пользователя и его SID) — это бесценно для анализа.
• enc-part (верхнеуровневая): зашифрованная часть ответа для клиента. Внутри — session key, время начала и окончания действия тикета, ticket flags (forwardable, renewable и другие).

Поля TGS-REQ и TGS-REP

Примените фильтр kerberos.msg_type == 12. В TGS-REQ ключевые элементы:

• padata → AP-REQ → ticket: здесь вложен TGT, который клиент предъявляет KDC. С keytab Wireshark расшифрует его и покажет PAC.
• padata → AP-REQ → authenticator: подтверждение владения session key. Содержит timestamp — KDC проверяет, что разница с серверным временем не превышает 5 минут (по умолчанию). Защита от replay-атак.
• req-body → sname → name-string: SPN целевого сервиса. Здесь видно, к какому ресурсу пользователь запрашивает доступ: cifs/fileserver.corp.local, HTTP/webapp.corp.local, MSSQLSvc/db01.corp.local:1433.

В TGS-REP (kerberos.msg_type == 13):

• ticket: сервисный тикет, зашифрованный ключом учётной записи целевого сервиса. Клиент передаёт его серверу для верификации.
• enc-part: новый session key для общения непосредственно с целевым сервисом.

Правило для анализа трафика: нормальная последовательность от одного IP-источника — AS-REQ → AS-REP → TGS-REQ → TGS-REP. Видите TGS-REQ без предшествующего AS-обмена с того же хоста — первый красный флаг, копайте дальше.

Pass-the-Ticket атака: что меняется в сетевом трафике

Механика Pass-the-Ticket (MITRE ATT&CK T1550.003)

MITRE ATT&CK — открытая база тактик и техник атак, своего рода каталог всего, что злоумышленники делают на разных этапах. T-коды (вроде T1550.003) — идентификаторы конкретных техник в этом каталоге. Pass-the-Ticket зарегистрирован как подтехника T1550.003 в рамках T1550 (Use Alternate Authentication Material), тактика — Lateral Movement (горизонтальное перемещение).

Атака идёт в три этапа:

Этап 1 — извлечение тикетов. Атакующий, получивший права локального администратора или SYSTEM на рабочей станции, вытаскивает Kerberos-тикеты из памяти процесса LSASS. LSASS (Local Security Authority Subsystem Service) — процесс Windows, который хранит в оперативной памяти тикеты и хеши паролей залогиненных пользователей. Если кто-то с правами админа дотянулся до этого процесса — все тикеты его. По данным Picus Security, типичные инструменты: Mimikatz (sekurlsa::tickets /export), Rubeus (dump), Kekeo, Impacket (ticketer.py/getTGT.py). Тикеты сохраняются как .kirbi-файлы на диске.

Этап 2 — инжекция тикета. Атакующий загружает украденный TGT в свою сессию. В Mimikatz — kerberos::ptt <файл.kirbi>. После инжекции текущая сессия приобретает права владельца украденного тикета. Без ввода пароля. Проверка через kerberos::list показывает загруженные тикеты.

Этап 3 — доступ к ресурсам. С инжектированным TGT атакующий запрашивает сервисные тикеты к любым ресурсам, доступным оригинальному пользователю. Украден TGT администратора домена — злоумышленник контролирует весь домен. По данным Semperis, после PtT атакующие часто используют PsExec (техника T1021.002 — SMB/Windows Admin Shares) или WMI (T1047 — Windows Management Instrumentation) для выполнения команд на удалённых хостах. Это уже отдельные техники ATT&CK, следующие после Pass-the-Ticket.

Для автоматизированного тестирования этой техники есть публичные тесты из репозитория Atomic Red Team: «Mimikatz Kerberos Ticket Attack» (executor: command_prompt, Windows) и «Rubeus Kerberos Pass The Ticket» (executor: PowerShell, Windows).

Аномалии в дампе: признаки инжекции тикета

Теперь главное — как Pass-the-Ticket выглядит в Wireshark. Трафик отличается от нормального по нескольким характерным признакам:

1. TGS-REQ без предшествующего AS-обмена. Нормальный поток: один IP-адрес сначала отправляет AS-REQ, получает AS-REP с TGT, затем шлёт TGS-REQ. При PtT атакующий уже имеет TGT (украденный с другого хоста) и начинает сразу с TGS-REQ. Фильтруйте по IP-источнику и проверяйте: если за последний час от этого IP не было ни одного AS-REQ, а TGS-REQ пошли — аномалия. Проще всего так: kerberos.msg_type == 10 && ip.src == 10.0.0.120 — если пусто, а kerberos.msg_type == 12 && ip.src == 10.0.0.120 показывает пакеты — красный флаг.

2. Несовпадение IP-адреса. TGT был выписан хосту с IP 10.0.0.50 (в логах Event ID 4768 на контроллере домена), а TGS-REQ с этим TGT приходит с IP 10.0.0.120. В Wireshark видно при сопоставлении IP-источника пакетов AS-REP и TGS-REQ. Разные IP для одного cname — прямой индикатор PtT.

3. Аномальный etype. Среда полностью мигрировала на AES, а в TGS-REQ — etype 23 (RC4-HMAC). Инструмент атакующего мог запросить downgrade для совместимости. Фильтр: kerberos.etype == 23.

4. Массовые TGS-REQ к разным SPN. Нормальный пользователь обращается к 2–5 сервисам за короткий период. Один хост за минуту запрашивает тикеты к 20+ разным SPN — это либо Kerberoasting (выгрузка сервисных тикетов для офлайн-взлома хешей), либо разведка после успешного PtT.

5. Повторное использование просроченного тикета. В KRB-ERROR (msg_type 30) с кодом KRB_AP_ERR_TKT_EXPIRED видно, что предъявленный тикет просрочен. Атакующий не учёл, что TGT живёт 10 часов по умолчанию. Такое бывает чаще, чем хотелось бы.

Предусловия и ограничения: когда техника не работает

Работает если: — Атакующий имеет права локального администратора или SYSTEM на хосте с нужными тикетами в LSASS — TGT не истёк (по умолчанию 10 часов, обновляемый 7 дней) — Целевой сервис использует Kerberos-аутентификацию (не NTLM fallback) — ОС: Windows 7+ / Server 2008+ в доменной среде

Не работает если: — Credential Guard включён (Windows 10 / Server 2016+). Credential Guard использует виртуализацию (VBS) для изоляции LSASS — Mimikatz и аналоги не могут извлечь тикеты из защищённой памяти. По данным Semperis, одна из наиболее эффективных контрмер. На практике встречается реже, чем хотелось бы — многие организации до сих пор не включили VBS. — Restricted Admin Mode для RDP активирован — предотвращает кеширование учётных данных администратора в памяти удалённого хоста при подключении. — TGT истёк — после 10 часов (или кастомного значения GPO) тикет невалиден, KDC откажет в выдаче TGS. — Учётная запись заблокирована или отключена после выдачи TGT — PAC-валидация на контроллере домена отклонит запрос.

Ограничение по анализу: если keytab отсутствует, Wireshark не расшифрует содержимое тикетов — видны только метаданные (msg_type, cname, sname, etype, IP-адреса). Но даже этого хватает для обнаружения перечисленных аномалий.

Обнаружение Pass-the-Ticket в сети: Event ID и Sigma-правила

Windows Event ID 4768, 4769, 4770

Сетевой анализ Kerberos-трафика — один слой детектирования. Второй — журналы Windows Security на контроллерах домена. Три Event ID, которые нужно знать для PtT:

• Event ID 4768 — «A Kerberos authentication ticket (TGT) was requested». Фиксирует каждый AS-REQ. Ключевые поля: Account Name, Service Name (всегда krbtgt), Client Address. Отсутствие 4768 от IP, с которого пришёл TGS-запрос — прямой индикатор инжекции тикета.
• Event ID 4769 — «A Kerberos service ticket was requested». Каждый TGS-REQ. Ключевые поля: Account Name, Service Name, Client Address. Сопоставляйте Client Address здесь с Client Address в 4768 — если 4769 есть, а 4768 от того же IP нет, это аномалия.
• Event ID 4770 — «A Kerberos service ticket was renewed». Обновление сервисного тикета. Ключевые поля: Account Name, Service Name, Service ID (SID учётной записи службы).

Стратегия для SIEM: правило корреляции 4768 и 4769 по полю Client Address. Если Event ID 4769 зафиксирован с адреса, с которого за последние 10 часов не было Event ID 4768 для того же Account Name — генерировать алерт.

Sigma-правила из SigmaHQ и контрмеры D3FEND

Sigma — унифицированный формат правил детектирования, который конвертируется в запросы для любого SIEM (Splunk, Elastic, Microsoft Sentinel). Если вы ещё не сталкивались с Sigma — думайте о нём как о «Markdown для SIEM-правил»: пишете один раз, конвертируете под нужную платформу. В репозитории SigmaHQ по тегу T1550.003 порядка 7 правил. Вот наиболее релевантные для сетевого анализа:

• win_security_dc_machine_accoutn_tgt_non_dc_ip.yml (находится в директории rules-placeholder, может требовать доработки перед продакшн-использованием) — детектирует ситуацию, когда TGT для машинного аккаунта запрашивается с IP, не принадлежащего этой машине. Прямо соответствует описанному сценарию несовпадения IP при PtT.
• proc_creation_win_hktl_rubeus.yml — детектирует запуск Rubeus по характерным аргументам командной строки (asktgt, ptt, dump). Сработает, если атакующий запускает Rubeus без обфускации имени процесса.
• posh_ps_hktl_rubeus.yml — обнаружение Rubeus через PowerShell Script Block Logging. Ловит рефлективную загрузку .NET-сборки и вызов Invoke-Rubeus.
• net_connection_win_susp_outbound_kerberos_connection.yml — исходящие подключения к порту 88 от процессов, которые обычно не обращаются к KDC напрямую. Если powershell.exe или cmd.exe устанавливают TCP-соединение на порт 88 — подозрительно, потому что эти процессы в норме не ходят к KDC сами. Уточнение: powershell.exe и cmd.exe в ATT&CK классифицируются как execution-техники (T1059.001 и T1059.003), а не как реализация T1550.003. Сетевое соединение на порт 88 от них — косвенный признак запуска инструментов вроде Rubeus/Mimikatz, а не самостоятельный индикатор Pass-the-Ticket.

MITRE D3FEND — это knowledge graph защитных техник, по сути ответ на ATT&CK: если ATT&CK описывает «как атакуют», то D3FEND описывает «как защищаться». Вот контрмеры для T1550 и T1550.003:

Контрмеры для T1550.003 (Pass the Ticket):

Контрмеры для T1550 (Use Alternate Authentication Material):

Вывод на практике: сочетание сетевого мониторинга (Wireshark/сенсор на порту 88), логов (Event ID 4768/4769) и endpoint-защиты (Credential Guard, Sigma-правила) даёт трёхуровневую модель детектирования PtT. Один слой — ненадёжно. Два — терпимо. Три — уже можно спать спокойнее.

Делай раз, делай два, делай три: минилаб для отработки

Чтобы увидеть всё описанное своими глазами, разверните минимальную лабу.

Требования к окружению: хост с 16 ГБ RAM (рекомендуется, 8 ГБ — минимум), процессор с VT-x/AMD-V, гипервизор VirtualBox 7+ или VMware. VM 1: Windows Server 2019/2022 с ролью AD DS, домен LAB.LOCAL. VM 2: Windows 10/11, присоединённая к домену, доменный пользователь + локальный администратор. Wireshark установлен на любой VM в сегменте. Сеть: Host-Only или Internal Network — все VM в одном сегменте.

Шаг 1. Захватите нормальный Kerberos-трафик. На VM с Wireshark запустите захват с capture filter port 88. На доменной рабочей станции залогиньтесь доменным пользователем и откройте сетевую шару: \\dc.lab.local\SYSVOL. В Wireshark появится последовательность AS-REQ → AS-REP → TGS-REQ → TGS-REP. Сохраните pcap — это ваш эталон нормального поведения. Ожидаемый результат: 4+ пакета Kerberos от IP рабочей станции к IP контроллера домена. В AS-REQ поле cname содержит имя пользователя, sname — krbtgt/LAB.LOCAL. В TGS-REQ sname — cifs/dc.lab.local.

Шаг 2. Выполните Pass-the-Ticket и захватите аномалию. На VM 2 от имени локального администратора запустите Mimikatz:

mimikatz # sekurlsa::tickets /export
mimikatz # kerberos::ptt [0;3e7]-2-0-40e10000-admin@krbtgt-LAB.LOCAL.kirbi
mimikatz # kerberos::list

Первая команда экспортирует все тикеты из LSASS в .kirbi-файлы. Вторая инжектирует TGT администратора в текущую сессию (имя файла будет отличаться — подставьте реальное из вывода первой команды). Третья подтверждает, что тикет загружен — вы увидите имя пользователя и срок действия. Теперь обратитесь к ресурсу: dir \\dc.lab.local\C$. Ожидаемый результат в Wireshark: TGS-REQ к cifs/dc.lab.local от IP рабочей станции, но без предшествующего AS-REQ от этого IP для учётной записи admin. Примените фильтр kerberos.msg_type == 10 && ip.src == <IP_VM2> — пустой результат для admin подтвердит аномалию.

Шаг 3. Сопоставьте с Event ID. На контроллере домена откройте Event Viewer → Windows Logs → Security. Найдите Event ID 4769 с Account Name = admin и Client Address = IP рабочей станции. Поищите Event ID 4768 с тем же Client Address и Account Name. Ожидаемый результат: 4769 есть, 4768 от того же IP — нет. Аномалия подтверждена и с сетевого уровня (Wireshark), и с уровня логов. Эту корреляцию SOC-аналитик или SIEM-правило использует для генерации алерта о потенциальном PtT.

Большинство команд, которые мониторят AD, строят детектирование Pass-the-Ticket исключительно на Event ID — ставят правила в SIEM на корреляцию 4768/4769 и считают задачу решённой. На практике этого не хватает. Атакующий с минимальной подготовкой очищает Security-лог на скомпрометированном хосте через wevtutil cl Security, а на контроллере домена Event ID 4769 покажет легитимный Client Address — но без контекста того, что полный AS-обмен с этого адреса отсутствует. Без сетевого слоя — без Wireshark, Zeek или сенсора на порту 88 — вы слепы к самому надёжному маркеру: отсутствию AS-REQ перед TGS-REQ.

Я наблюдаю это раз за разом: SOC-команда получает алерт от Sigma-правила на Rubeus, но к моменту реагирования атакующий уже переместился на три хоста и перешёл на другой инструмент. А дамп трафика был в записи — просто никто не анализировал msg_type по IP-источникам. Сетевой анализ — не замена логам, а второй глаз, который видит то, что первый пропустил. Если хочется не просто читать статьи, а пройти базу AD-безопасности системно — на IB Basics в Codeby Academy разбирают именно такие задачи, от первых шагов в SOC до анализа реальных инцидентов.