Анализ Kerberoasting в трафике — 19 июня 2026 г. в 12:07:06.501
Анализ Kerberoasting в трафике 👋 Приветствую в мире цифровой безопасности! Разберём как по дампу увидеть Kerberoasting - атаку где из легитимных Kerberos-запросов вытаскивают хэши сервисных аккаунтов для оффлайн-брутфорса. ⏺Почему это работает: любой аутентифицированный пользователь домена может запросить TGS-тикет для любого сервисного аккаунта с SPN. Тикет шифруется хэшем пароля сервисного аккаунта. Забираем тикет, брутим оффлайн, Active Directory об этом не узнает. ⏺ Основной фильтр, ищем TGS-запросы: kerberos.msg_type == 12 TGS-REQ это тип 12. Нормально видеть их при каждом подключении к сервисам. Подозрительно когда один хост запрашивает десятки TGS в короткий промежуток. ⏺ Смотрим какие SPN запрашиваются: kerberos.msg_type == 12 && kerberos.SNameString При Kerberoasting видно запросы к нетипичным SPN: MSSQLSvc, HTTP, сервисные аккаунты. Особенно подозрительно если запросы идут к аккаунтам которые давно не используются. ⏺Тип шифрования выдаёт атаку: атакующий специально запрашивает RC4 вместо AES потому что RC4-хэши брутятся быстрее: kerberos.etype == 23 etype 23 это RC4-HMAC. Современные домены используют AES (etype 17 и 18). Запрос RC4 от современного клиента - прямая аномалия. ⏺Массовость запросов - главный индикатор. Нормальный пользователь запрашивает TGS для конкретных сервисов которые использует. При Kerberoasting идёт перебор всех аккаунтов с SPN: kerberos.msg_type == 12 && ip.src == 192.168.1.100 Десятки TGS-REQ с одного хоста за минуту, почти всегда Rubeus или impacket. ⏺После получения тикетов в трафике тишина, брутфорс идёт оффлайн. Поэтому важно детектировать на этапе запросов. Алерт на количество TGS-REQ с одного хоста за короткий период закрывает большую часть реальных атак. 🤖Бесплатный ChatGPT