Вопросы на собеседовании пентестер Active Directory: Kerberoasting и DCSync, на которых сыпятся кандидаты

За последний год я сидел на двенадцати техничках по позициям пентестеров AD-инфраструктуры — шесть раз как интервьюер, шесть как ассистент. Из тридцати кандидатов, дошедших до технической части, больше половины сломались на двух темах: механика Kerberoasting и права для DCSync. Не потому что не слышали термины — слышали все. Проблема глубже: между «могу назвать атаку» и «объясню, почему она работает на уровне протокола» лежит пропасть, в которую проваливается оффер. Ниже — конкретные вопросы, типичные ошибки и ответы, которые показывают понимание, а не заученную выжимку.

Kerberoasting атака на собеседовании: где заученный ответ не спасает

Kerberoasting (техника T1558.003 по классификации MITRE ATT&CK — это открытая база тактик и техник атак, где каждой технике присвоен идентификатор вида Txxxx) — одна из самых частых тем на собеседовании пентестер Active Directory. Причина проста: атака требует минимальных привилегий, даёт реальный результат и проверяет понимание Kerberos на глубину. Поверхностный ответ интервьюер вычисляет за секунды.

Механика Kerberos-тикетов — что реально проверяют на собеседовании пентестера

Kerberos — основной протокол аутентификации в Active Directory (AD — централизованный каталог пользователей, компьютеров и политик в Windows-сетях). Работает по принципу тикетов: вместо того чтобы каждый раз гонять пароль по сети, пользователь получает тикет и предъявляет его сервисам.

Процесс в четыре шага:

1. Пользователь логинится в домен. Контроллер домена (DC) выдаёт ему TGT (Ticket Granting Ticket) — «мастер-билет», подтверждающий личность.
2. Когда нужен доступ к сервису (почта, SQL-сервер, файловая шара), пользователь предъявляет TGT и запрашивает TGS (Ticket Granting Service) — сервисный тикет для конкретного сервиса.
3. KDC (Key Distribution Center — служба выдачи тикетов на контроллере домена) генерирует TGS, шифрует его хешем пароля сервисной учётной записи и отдаёт пользователю.
4. Пользователь предъявляет TGS сервису, сервис расшифровывает тикет своим паролем и пускает внутрь.

А теперь — деталь, которая делает Kerberoasting возможной: на шаге 3 KDC не проверяет, имеет ли пользователь право доступа к сервису. Просто выдаёт тикет. Проверка авторизации происходит позже, на стороне самого сервиса. Как отмечает CrowdStrike: «the domain controller typically does not check to see if the user is authorized to access this service». Это не баг — это архитектурное решение. И именно оно открывает дверь.

SPN (Service Principal Name) — уникальный идентификатор сервиса в AD, привязывающий сервис к учётной записи. Если у учётки есть SPN — для неё можно запросить TGS. А TGS зашифрован хешем пароля этой учётки. Получив тикет, атакующий уносит его на свою машину и ломает пароль офлайн — ни одного лишнего пакета в сети, ни одного алерта от стандартного мониторинга.

«Какие привилегии нужны для Kerberoasting?» — вопрос, который заваливает

Здесь сыпется большинство. Типичный неправильный ответ: «Нужны привилегии администратора» или «нужен доступ к контроллеру домена».

Правильный ответ: для Kerberoasting достаточно учётной записи любого доменного пользователя. Никаких повышенных привилегий — любой аутентифицированный пользователь может запросить TGS для любого SPN в домене. Штатная функциональность Kerberos, не эксплойт.

Вопрос настолько эффективен, потому что проверяет понимание архитектуры. Если кандидат понимает — объяснит, почему не нужны привилегии (KDC не проверяет авторизацию при выдаче TGS). Если заучил шаги атаки — начнёт угадывать.

Следующий follow-up идёт сразу: «Какие учётные записи уязвимы к Kerberoasting, а какие нет?»

Ответ, который демонстрирует глубину:

• Уязвимы — учётные записи пользователей с SPN и пользовательским паролем (заданным человеком). Такие пароли часто слабые или не менялись годами.
• Практически неуязвимы — учётные записи компьютеров: пароли генерируются автоматически, длина 120+ символов, ротация каждые 30 дней. Сломать такой хеш за разумное время нереально.
• gMSA (Group Managed Service Accounts — сервисные учётки с автоматически управляемыми паролями) тоже практически неуязвимы: пароль длинный, сложный, ротируется Windows автоматически.

Этот ответ показывает главное: Kerberoasting — проблема не протокола Kerberos, а человеческих паролей на сервисных учётках.

Как провести Kerberoasting: инструменты и команды, которые спрашивают

На собеседовании пентестера AD-инфраструктуры ожидают знание конкретных инструментов. Не заученную команду посимвольно, а понимание, что делает каждый шаг и зачем.

Шаг 1 — перечисление SPN. Найти учётные записи с установленным SPN. Из Windows: PowerShell-модуль ActiveDirectory, командлет Get-ADUser с фильтром по атрибуту ServicePrincipalName. Из Linux: утилита GetUserSPNs из набора impacket (коллекция Python-инструментов для работы с сетевыми протоколами Windows). Учётку krbtgt игнорируем — зарезервирована для Kerberos.

Шаг 2 — запрос TGS-тикетов. Rubeus (Windows, C#): Rubeus.exe kerberoast /user:target_user /nowrap — на выходе хеш в формате для hashcat. Из Linux — тот же GetUserSPNs с флагом -request.

Шаг 3 — офлайн-брутфорс. hashcat -m 13100 — режим 13100 соответствует Kerberos 5 TGS-REP etype 23 (RC4). Если пароль сервисной учётки — что-то вроде «Summer2024!», hashcat найдёт его за минуты на обычной видеокарте.

Типичный follow-up: «А если AES включён — что изменится?»

Если в домене включено AES-шифрование для сервисных учёток (а не устаревшее RC4), тикет будет зашифрован AES-256. Атаку это не блокирует, но делает брутфорс значительно медленнее. Поэтому один из способов обнаружения Kerberoasting — мониторинг запросов с типом шифрования RC4 (значение 0x17 в Event ID 4769 — «A Kerberos service ticket was requested» — на DC), когда домен настроен на AES. Кто-то явно запрашивает RC4-тикет в AES-домене — аномалия. В SigmaHQ (репозиторий открытых правил детектирования) это покрывает правило win_security_susp_rc4_kerberos.yml.

Targeted Kerberoasting — вопрос для продвинутых кандидатов

Если кандидат уверенно отвечает про классический Kerberoasting, интервьюер переключается на targeted-вариант: «Что если у целевой учётки нет SPN? Можно ли всё равно провести Kerberoasting?»

Да, если у атакующего есть право записи (GenericWrite или GenericAll) на целевую учётную запись. Тогда атакующий сам добавляет фиктивный SPN на эту учётку, запрашивает TGS и ломает хеш. После атаки SPN можно удалить для заметания следов. По данным istrosec, инструмент targetedKerberoast.py автоматизирует весь цикл: находит учётки с доступными правами на запись, добавляет временный SPN, получает тикет и убирает SPN.

Детект targeted Kerberoasting — Event ID 5136 на контроллере домена (модификация атрибута объекта AD). Алерт срабатывает при изменении атрибута servicePrincipalName. Легитимные изменения SPN — редкость, поэтому каждое такое событие заслуживает расследования.

DCSync атака: ошибки кандидатов на собеседовании ИБ

DCSync — вторая тема, на которой стабильно проваливаются кандидаты. И проваливаются глубже, чем на Kerberoasting, потому что путают DCSync с физическим копированием файла базы данных.

Почему DCSync — это не копирование NTDS.dit

Типичный плохой ответ: «DCSync — это когда атакующий копирует файл NTDS.dit с контроллера домена». Это другая атака (через Volume Shadow Copy или ntdsutil), и она требует физического или RDP-доступа к DC плюс прав локального администратора.

DCSync работает иначе. Атакующий имитирует поведение контроллера домена, отправляя легитимный запрос на репликацию через протокол MS-DRSR (Directory Replication Service Remote Protocol). Настоящий DC «думает», что с ним общается другой DC, и отдаёт запрошенные данные — включая хеши паролей всех пользователей.

Ключевое отличие: DCSync не требует доступа к файловой системе DC. Атакующий выполняет его с любой рабочей станции в сети при наличии нужных прав.

«Какие права нужны для DCSync?» — правильный ответ на собеседовании

Конкретный вопрос, на котором отсеиваются кандидаты: «Какие именно разрешения необходимы учётной записи для выполнения DCSync?»

Правильный ответ — две extended rights на уровне корня домена:

• DS-Replication-Get-Changes — позволяет запрашивать изменения у другого DC.
• DS-Replication-Get-Changes-All — позволяет получать секретные данные (хеши паролей) при репликации.

По умолчанию эти права есть у групп Domain Admins, Enterprise Admins и у учётной записи самого контроллера домена. На практике их иногда выдают сервисным учёткам для инструментов мониторинга или резервного копирования — и забывают отозвать. Semperis пишет об этом прямо: «legacy configurations remain in place, creating potential avenues for attackers». Я видел это на реальных проектах не раз — учётка для SIEM-коннектора с правами на репликацию, пароль Monitoring2019.

Инструменты, которые спрашивают:

• mimikatz (Windows): модуль lsadump::dcsync /user:domain\krbtgt — извлекает хеш учётки krbtgt (она подписывает все TGT в домене, а это прямой путь к Golden Ticket).
• impacket-secretsdump (Linux): secretsdump.py domain.local/user:password@DC_IP — делает то же удалённо, без загрузки агента на DC.

Обнаружение DCSync — вопрос, который отделяет пентестера от скрипт-кидди

Хороший интервьюер после обсуждения атаки меняет ракурс: «Как blue team обнаруживает DCSync?» Пентестер, который знает только атакующую сторону и не понимает детект — красный флаг для работодателя. Red team и blue team вопросы на собеседовании ИБ идут вместе.

Ответ, показывающий зрелость:

DCSync генерирует Event ID 4662 на контроллере домена — обращение к объекту AD с использованием расширенных прав. В логе видно, какой аккаунт запросил репликацию и с какими Properties (GUID’ы прав Replication-Get-Changes). Запрос пришёл от учётки, которая не является контроллером домена? Алерт.

Дополнительный индикатор — сетевой трафик: DCSync использует RPC-вызовы DRSGetNCChanges. Сетевые сенсоры (IDS/IPS, identity threat detection) отслеживают эти вызовы от хостов, не являющихся DC.

По классификации MITRE D3FEND (knowledge graph защитных техник — если MITRE ATT&CK описывает «как атакуют», то D3FEND описывает «как защищаться»):

• D3-DUC (Decoy User Credential) — создание honeypot-учёток с заведомо привлекательным SPN. Запрос TGS для такой учётки = 100% атака.
• D3-NTCD (Network Traffic Community Deviation) — выявление аномального RPC-трафика от non-DC хостов.

Golden Ticket и Kerberoasting: разница на собеседовании пентестера Active Directory

Вопрос «в чём разница между Golden Ticket и Kerberoasting» задают почти на каждом собеседовании по пентесту Active Directory. Путают их с пугающей регулярностью.

Kerberoasting — путь к повышению привилегий. Golden Ticket — то, что делают после полной компрометации домена для сохранения доступа. Путать их — всё равно что путать взлом замка и изготовление дубликата ключа.

Связь между ними в полной цепочке: Kerberoasting → пароль привилегированной сервисной учётки → DCSync → хеш krbtgt → Golden Ticket. Умение описать эту цепочку целиком — то, что отличает сильного кандидата от человека, заучившего отдельные техники.

Практический блок: разбираем цепочку Kerberoasting шаг за шагом

Ниже — сценарий, который часто просят воспроизвести на собеседовании (на бумаге или в тестовой среде). Предпосылки: Kali Linux с установленным impacket и hashcat, учётные данные рядового пользователя домена (jsmith:Password1), сетевой доступ к контроллеру домена (10.10.10.1).

Делай раз — найди учётки с SPN:

GetUserSPNs -dc-ip 10.10.10.1 corp.local/jsmith:Password1

Утилита подключается к DC по LDAP, аутентифицируется от имени jsmith и запрашивает все учётные записи с атрибутом servicePrincipalName. На выходе — таблица с именами учёток, их SPN и типом шифрования. Видите учётку вида svc_sql с SPN MSSQLSvc/sqlserver.corp.local:1433? Кандидат на атаку.

Делай два — запроси TGS и сохрани хеш:

GetUserSPNs -dc-ip 10.10.10.1 corp.local/jsmith:Password1 -request -outputfile tgs_hashes.txt

Флаг -request заставляет утилиту запросить TGS-тикеты для найденных SPN и сохранить хеши в файл. В tgs_hashes.txt будут строки формата $krb5tgs$23$*... (число 23 = RC4, 17 или 18 = AES). Каждая строка — один тикет, готовый для hashcat.

Делай три — сломай хеш офлайн:

hashcat -m 13100 -a 0 tgs_hashes.txt /usr/share/wordlists/rockyou.txt

hashcat перебирает пароли из словаря, хешируя каждый и сравнивая с TGS-хешем. Режим 13100 = Kerberos 5 TGS-REP etype 23 (RC4). Если пароль сервисной учётки слабый — hashcat справится за секунды-минуты. Статус Cracked и строка hash:password — значит, сработало.

Дальше интервьюер спросит: «Что делаешь с полученным паролем?» Сильный ответ: аутентификация от имени сервисной учётки, проверка её привилегий (членство в группах, ACL-права), lateral movement или эскалация до DCSync, если права позволяют.

Follow-up: «Как бы ты защитил домен от этой атаки?» Сильный ответ включает три уровня:

1. Предотвращение: gMSA вместо обычных сервисных учёток, пароли 25+ символов для оставшихся учёток, удаление SPN с учёток, которым они не нужны.
2. Детектирование: мониторинг Event ID 4769 с типом шифрования RC4 (0x17), Sigma-правило win_security_susp_rc4_kerberos.yml из SigmaHQ, honeypot-SPN (техника D3-DUC по D3FEND).
3. Реагирование: немедленная смена пароля скомпрометированной учётки, аудит её привилегий и действий за период с момента возможной компрометации.

Подготовка к собеседованию пентестер Active Directory — не про заучивание чек-листов «100 вопросов по ИБ». Я провёл достаточно интервью, чтобы видеть паттерн: кандидаты, которые готовятся по спискам терминов, отвечают на первый вопрос и тонут на follow-up. Потому что follow-up проверяет не знание факта, а понимание механики.

Kerberoasting работает не потому что Kerberos — «плохой протокол». Он работает потому что KDC архитектурно не проверяет авторизацию при выдаче TGS. DCSync работает не потому что «Microsoft допустила баг» — репликация между контроллерами домена обязана существовать, и атака эксплуатирует именно этот легитимный механизм. Когда кандидат объясняет атаку через «почему это работает по замыслу», а не через «вот команда, которую нужно ввести» — разговор переходит на другой уровень.

По моим наблюдениям, 80% технических вопросов на собеседовании по AD крутятся вокруг пяти тем: Kerberoasting, DCSync, делегирование (unconstrained/constrained/RBCD), ACL-абьюз и lateral movement через Pass-the-Hash/Pass-the-Ticket. Две из пяти мы разобрали до уровня, которого хватит на уверенный ответ. Остальные три — та же логика: механика протокола, причина уязвимости, детект, защита. Если ищешь джуниор-роль и нужна структура вместо хаотичного самообучения — на IB Basics (codeby.school) базу по Kerberos и AD закрывают за пару месяцев без академического тона.