Kerberoasting атака Active Directory: от LLMNR-спуфинга до Domain Admin на примере HTB Sizzle

По данным IBM X-Force 2025, число атак с использованием действительных учётных данных выросло на 71% за год. CrowdStrike подтверждает: 75% вторжений в 2024-м начались с кражи кредов. Не с эксплойтов, не с фишинга — с валидных паролей. Kerberoasting превращает легитимный запрос к контроллеру домена Active Directory в офлайн-взлом пароля сервисного аккаунта. Без срабатывания антивируса. Без записей в логах эндпоинтов. На HTB-лабах Sizzle, Forest, Active эта цепочка отрабатывается целиком: от перехвата первого NTLM-хэша через LLMNR-спуфинг до получения Domain Admin. Ниже — каждый шаг с объяснением, что происходит «под капотом» и как понять, что получилось.

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

Kerberoasting (T1558.003 по MITRE ATT&CK — открытая база тактик и техник атак, где T-коды служат идентификаторами конкретных техник) входит в тактику Credential Access. Цель: вытащить пароль сервисного аккаунта Active Directory — учётной записи, под которой крутятся SQL Server, IIS, Exchange, агенты бэкапов и другие корпоративные сервисы.

Почему именно сервисные аккаунты — лакомый кусок для атакующего:

• Часто сидят в привилегированных группах (Domain Admins, Server Operators) или имеют прямой доступ к базам и файловым шарам
• Пароли ставит админ руками и редко меняет. PasswordLastSet трёх-пятилетней давности — норма, а не исключение
• Компрометация одного аккаунта открывает lateral movement (горизонтальное перемещение по сети) к каждой системе, где он используется

Финальный импакт: кража данных, бэкдоры, ransomware. По данным CrowdStrike, среднее время от первичного доступа до начала lateral movement — 62 минуты, рекордный зафиксированный случай — 51 секунда. Verizon DBIR 2025 подтверждает: 38% утечек данных связаны с кражей учётных данных. Kerberoasting — один из механизмов, которым эта статистика пополняется.

Kerberos за пять минут — минимум теории для первой Kerberoasting атаки

Kerberos — протокол аутентификации, который Active Directory использует по умолчанию. Вместо передачи пароля по сети клиент получает зашифрованные билеты и предъявляет их сервисам. Три участника:

• KDC (Key Distribution Center) — работает на контроллере домена, выдаёт билеты
• Клиент — пользователь или машина, запрашивающая доступ к ресурсу
• Сервис — приложение с зарегистрированным SPN (Service Principal Name — уникальный идентификатор сервиса в AD, например MSSQLSvc/db01.corp.local:1433 для SQL Server или HTTP/web01.corp.local для веб-сервера)

Аутентификация — три обмена сообщениями:

1. AS-REQ → AS-REP. Клиент запрашивает аутентификацию у KDC. При включённой преаутентификации запрос содержит зашифрованную временную метку — защита от replay-атак. KDC проверяет и возвращает TGT (Ticket Granting Ticket — «главный билет», подтверждающий личность пользователя на определённый срок).
2. TGS-REQ → TGS-REP. Клиент предъявляет TGT и запрашивает сервисный билет (TGS) для конкретного SPN. KDC возвращает TGS, зашифрованный хэшем пароля сервисного аккаунта. Вот тут — ключевой момент.
3. AP-REQ. Клиент предъявляет TGS целевому сервису, сервис расшифровывает его своим ключом и подтверждает доступ.

Архитектурная слабость — шаг 2. KDC не проверяет, нужен ли пользователю доступ к запрашиваемому сервису. Любой доменный пользователь — даже с минимальными привилегиями — может запросить TGS для любого SPN в домене. А поскольку TGS зашифрован хэшем пароля сервисного аккаунта, его можно утащить и ломать офлайн. Это и есть Kerberoasting: легитимный запрос → офлайн-брутфорс → KDC ничего не узнает.

По данным Semperis, впервые технику задокументировал исследователь Tim Medin в 2014 году. С тех пор механика не изменилась — атака работает против любого AD-домена, где есть пользовательские аккаунты с SPN.

LLMNR-спуфинг через Responder — захват первой учётки [Внутренний]

Kerberoasting — постэксплуатационная техника. Для неё нужна хотя бы одна валидная доменная учётка. На внутреннем пентесте Active Directory самый тихий способ её получить — LLMNR-спуфинг.

LLMNR (Link-Local Multicast Name Resolution) и NBT-NS (NetBIOS Name Service) — протоколы разрешения имён в Windows-сетях. Работают как запасной вариант, когда DNS не справился: машина кидает широковещательный запрос в локальную сеть — «кто знает, где \\FILESRV01?» Ответить может любой хост в том же L2-сегменте (одна физическая или виртуальная подсеть).

Атакующий поднимает Responder — инструмент, который перехватывает такие запросы и представляется искомым сервером. Жертва пытается аутентифицироваться на «сервере» и передаёт свой NetNTLMv2-хэш (значение, вычисленное из пароля по протоколу NTLM-аутентификации) прямо атакующему. Бесплатно.

[Применимо: внутренний пентест, legacy-инфраструктура с включённым LLMNR/NBT-NS]

Требования к окружению: Linux с root-привилегиями (в Kali Linux Responder предустановлен), сетевой интерфейс в том же L2-сегменте, что и целевые Windows-хосты. На HTB-лабах подключение через VPN обеспечивает нужный доступ в целевой сегмент.

Запуск: sudo responder -I eth0 -dwv — ключ -I задаёт сетевой интерфейс, -d включает DHCP-ответы (расширяет поверхность перехвата), -w поднимает WPAD-прокси для перехвата HTTP-аутентификации, -v — подробный вывод. После запуска Responder показывает баннер со списком поднятых серверов (SMB, HTTP, LDAP, MSSQL) и начинает слушать.

[+] Listening for events...
[SMB] NTLMv2-SSP Client   : 10.10.10.132
[SMB] NTLMv2-SSP Username : CORP\amanda
[SMB] NTLMv2-SSP Hash     : amanda::CORP:a1b2c3d4e5f6...

Когда в терминале появляется строка NTLMv2-SSP Hash с именем пользователя и доменом — хэш перехвачен. Responder автоматически сохраняет его в файл (путь указан при старте). На HTB-лабах вроде Sizzle ожидание занимает от нескольких секунд до нескольких минут — зависит от частоты запросов к несуществующим ресурсам в домене. На реальном пентесте Active Directory иногда приходится ждать часами.

Перехваченный NetNTLMv2-хэш ломается через hashcat -m 5600 hash.txt wordlist.txt (режим 5600 — специально для NetNTLMv2). Если пароль есть в словаре — через несколько минут у вас plaintext-пароль и валидная доменная учётка для Kerberoasting.

Альтернатива — NTLM relay атака (перехваченный хэш переправляется на другой хост для аутентификации без знания пароля), но relay требует отключённой SMB-подписи (SMB Signing) на целевом сервере.

Когда LLMNR-спуфинг не работает

• LLMNR и NBT-NS отключены через GPO (Group Policy Object — механизм централизованного управления настройками в AD). Microsoft рекомендует, но в legacy-окружениях встречается редко
• Сетевая сегментация: атакующий и жертва в разных VLAN — широковещательные запросы не выйдут за пределы сегмента
• 802.1X или NAC (Network Access Control — контроль доступа к сети на уровне порта коммутатора) — атакующий не подключится к сети без валидного сертификата
• SMB Signing принудительно включён — не остановит перехват хэша, но заблокирует relay-атаку

Kerberoasting атака Active Directory — от разведки до хэша [Внутренний]

Учётка получена (через Responder, relay или выдана заказчиком). Переходим к Kerberoasting.

Сценарий с выданными учётными данными (grey box)

На реальном внутреннем пентесте заказчик часто выдаёт учётные данные рядового доменного пользователя — моделирование инсайдера или скомпрометированного сотрудника. Перед запуском Kerberoasting — чек-лист из трёх пунктов:

1. Учётка доменная? Проверяем: crackmapexec smb DC_IP -u user -p 'password'. Ожидаем [+] с указанием домена. Если [-] — пароль неверный или учётка локальная
2. Есть сетевой доступ до контроллера домена на порту 88/TCP? Проверяем: nmap -p 88 DC_IP. Порт 88 — Kerberos
3. DNS резолвит доменные имена? Проверяем: nslookup domain.local DC_IP. Без рабочего DNS Kerberos не работает — все запросы идут по именам, не по IP

Все три пункта пройдены — Kerberoasting доступен.

Поиск SPN сервисных аккаунтов и запрос TGS через Impacket GetUserSPNs

SPN привязывает сервис к учётной записи в AD. Нас интересуют SPN на пользовательских аккаунтах — их пароли задаёт человек. SPN на машинных аккаунтах (с суффиксом $) бесполезны: пароли 120+ символов случайных данных, ротация каждые 30 дней. Даже с хорошим GPU такой пароль не сломать.

Основной инструмент для Kerberoasting с Linux — GetUserSPNs.py из библиотеки Impacket. Делает две вещи одной командой: находит пользовательские аккаунты с SPN и запрашивает для них TGS-тикеты.

python3 GetUserSPNs.py CORP.LOCAL/amanda:'Passw0rd' \
  -dc-ip 10.10.10.100 \
  -request \
  -outputfile tgs_hashes.txt

Разбор ключей: -dc-ip — IP контроллера домена (без него скрипт попытается резолвить через DNS, что не всегда работает с атакующей машины), -request — запрашивает TGS-тикеты (без этого флага скрипт только выведет список аккаунтов с SPN), -outputfile — сохраняет хэши в формате, готовом для hashcat.

Результат — таблица с колонками ServicePrincipalName, Name, MemberOf, PasswordLastSet. На что смотреть:

• MemberOf — аккаунт в Domain Admins или аналогичной привилегированной группе? Это приоритетная цель
• PasswordLastSet — дата три и более лет назад резко увеличивает шансы на слабый пароль

Для визуализации путей от текущего пользователя до привилегированных целей — BloodHound. Инструмент строит граф связей в AD. После сбора данных через SharpHound (агент сбора) встроенный запрос «List all Kerberoastable Accounts» показывает не просто список целей, а цепочки эскалации: от скомпрометированной учётки через Kerberoastable-аккаунт к Domain Admin. Обычный LDAP-запрос такого контекста не даст.

С Windows-хоста — альтернативный путь через встроенную утилиту: setspn -T DOMAIN -Q */* выведет все зарегистрированные SPN в домене. Для запроса тикетов — Rubeus: .\Rubeus.exe kerberoast /outfile:tickets.txt.

Если plaintext-пароля нет, но есть NTLM-хэш (из дампа SAM-базы или после LLMNR-перехвата), GetUserSPNs.py поддерживает pass-the-hash — аутентификацию хэшем без знания пароля: флаг -hashes aad3b435b51404eeaad3b435b51404ee:NTLM_HASH вместо пароля.

Hashcat: взлом kerberoast hash офлайн

TGS-тикеты с предыдущего шага зашифрованы хэшем пароля сервисного аккаунта. Взлом — полностью офлайн. KDC не узнает, логов о брутфорсе на контроллере домена не будет. Тишина.

hashcat -m 13100 tgs_hashes.txt \
  /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

Режим -m 13100 — для TGS-тикетов с шифрованием RC4 (RC4_HMAC, etype 23 — устаревший, но до сих пор распространённый алгоритм шифрования в Kerberos). Скорость на среднем GPU — сотни тысяч хэшей в секунду.

Если в домене форсировано AES-256 (etype 18) — режим -m 19700. Скорость перебора падает на порядки: AES-256 спроектирован именно для замедления брутфорса.

Правило -r best64.rule генерирует 64 мутации каждого слова из словаря — добавление цифр, смена регистра, замена символов. Для паролей вида Summer2024! или SvcPassword1, типичных для сервисных аккаунтов, работает отлично.

Требования: hashcat (предустановлен в Kali), GPU с поддержкой CUDA или OpenCL (NVIDIA рекомендуется), минимум 4 GB VRAM. CPU-режим тоже работает, но медленнее в десятки раз.

Как понять, что пароль найден: hashcat выводит строку с паролем после хэша, статус Cracked в финальном отчёте. Проверяем полученные креды: crackmapexec smb DC_IP -u svc_sql -p 'CrackedPassword'. Если учётка в Domain Admins — полный контроль над доменом. Если нет — ищем дальнейшие пути: доступ к базам данных, файловым шарам, делегирование. В HTB Sizzle прохождение после Kerberoasting может включать эксплуатацию Active Directory Certificate Services (ADCS — служба сертификатов AD) для повышения привилегий Windows — отдельный вектор, заслуживающий своего разбора.

Предусловия и ограничения Kerberoasting

Kerberoasting атака Active Directory не универсальна. Техника не работает или деградирует при следующих условиях:

[Применимо: внутренний пентест. Для внешнего — нужен сначала VPN-доступ или reverse shell во внутреннюю сеть]

Обнаружение Kerberoasting: Sigma-правила и Event ID

Kerberoasting использует легитимные механизмы Kerberos — запрос TGS сам по себе не аномалия. Но маркеры есть, и Blue Team (команда защиты) может отследить атаку.

Event ID 4769 (запрос сервисного билета Kerberos) на контроллере домена — основной источник. Ключевой фильтр: поле Ticket Encryption Type = 0x17 (RC4_HMAC). В современных AD-средах AES должен быть стандартом, и запрос RC4-тикета — аномалия. В репозитории SigmaHQ (открытый набор кроссплатформенных правил детектирования) для этого есть правило win_security_susp_rc4_kerberos.yml.

Дополнительные индикаторы для SIEM (Security Information and Event Management — система сбора и анализа логов безопасности):

• Массовые TGS-запросы от одного пользователя за короткий период — обычный сотрудник не запрашивает тикеты к десятку сервисов за минуту
• Запросы к SPN, к которым пользователь никогда ранее не обращался — поведенческая аномалия
• Запуск Rubeus или Impacket — Sigma-правило proc_creation_win_hktl_rubeus.yml детектирует Rubeus по характерным аргументам командной строки, zeek_susp_kerberos_rc4.yml для Zeek IDS фиксирует RC4-тикеты на сетевом уровне

Защитные контрмеры по классификации D3FEND (MITRE-каталог защитных техник, зеркальный к ATT&CK):

• D3-DUC (Decoy User Credential) — honey-аккаунты с привлекательными SPN, которые никто легитимно не использует. Любой запрос TGS к такому аккаунту — однозначная тревога. По данным Semperis, honey tokens — одна из самых эффективных мер раннего обнаружения Kerberoasting, потому что ложных срабатываний ноль
• D3-CR (Credential Revocation) — немедленная ротация паролей скомпрометированных аккаунтов при обнаружении атаки
• D3-MFA (Multi-factor Authentication) — не останавливает Kerberoasting напрямую (запрос TGS не требует MFA), но защищает от использования скомпрометированных кредов для интерактивного входа

Если настраиваете SIEM — начните с Event ID 4769 + фильтр на Ticket Encryption Type 0x17 (RC4). Минимум ложных срабатываний, покрытие большинства Kerberoasting-инструментов, которые по умолчанию запрашивают RC4-тикеты как самые быстрые для брутфорса.

Kerberoasting описан в 2014 году. Прошло больше десяти лет, а механика атаки не изменилась ни на один шаг: запроси тикет, утащи, сломай. Microsoft знает об архитектурной слабости — KDC выдаёт TGS без проверки авторизации — и не закрывает её, потому что это сломает обратную совместимость тысяч enterprise-приложений.

На лабах и на реальных проектах картина одна и та же: защита от Kerberoasting сводится к антивирусу на эндпоинтах. Но Kerberoasting не использует вредоносное ПО, не эксплуатирует CVE, не требует привилегий — это штатный протокольный запрос. Антивирус тут бесполезен. По данным Rapid7, CISA относит Kerberoasting к приоритетным методам у APT-группировок.

Реальная защита — операционная дисциплина: gMSA вместо ручных паролей, ротация каждые 30 дней, отключение RC4 в пользу AES-256 и honey-аккаунты для раннего обнаружения. Но большинство организаций до сих пор держат LLMNR включённым по умолчанию и сервисные аккаунты с паролями пятилетней давности. Проблема не техническая — никто не хочет прикладывать операционные усилия к инфраструктуре, которая «и так работает». Если хотите не просто читать об этих атаках, а системно пройти базу ИБ с лабами — IB Basics закрывает эту задачу за два месяца.