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

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

Нажмите, чтобы раскрыть...

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

Дальше разберу атаки на Active Directory аутентификацию через Kerberoasting и AS-REP Roasting (в обзоре атак на аутентификацию - полная карта по OAuth, MFA и Kerberos): от разведки через 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 (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-хоста:
Поле PasswordLastSet - критично. Если пароль не менялся 3+ года, шанс на успешный крек сильно выше. MemberOf покажет, стоит ли аккаунт в привилегированных группах.

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

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

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

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

Impacket - GetUserSPNs.py:

Реальные кейсы использования 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:
Для 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:
Нюанс: 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, пароль которых не менялся больше года - приоритетные цели для атакующего. Второй - аккаунты, уязвимые к 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 аутентификации​

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

Итоги​

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

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