Делегирование Kerberos и ACL: уязвимость на HTB Sauna — путь атаки через BloodHound

На прохождении HTB-машины Sauna я получил шелл обычного доменного пользователя за полтора часа — AS-REP Roast, подбор хеша, WinRM. Думал, основная работа позади. Загрузил SharpHound, скормил данные в BloodHound — и через двадцать минут увидел на графе одно ребро GetChangesAll, ведущее от сервисного аккаунта прямо к объекту домена. Одна строчка в ACL, о которой админ наверняка забыл, — и путь от рядового пользователя до полного контроля домена уложился в три команды.

Дальше — разбор того, как устроена такая цепочка, как её обнаружить и эксплуатировать. Если ты только начинаешь разбираться с атаками на Active Directory — здесь будет и теория (что такое ACL, делегирование, DCSync), и практика на конкретной машине.

Делегирование Kerberos и ACL — почему одна уязвимость в правах ломает домен

Зачем атакующему целить в ACL Active Directory

Active Directory (AD) — центральная система управления учётными записями, группами, политиками и доступом в корпоративной сети Windows. Всё завязано на AD: кто куда может ходить, какие политики применяются, кому доступны какие ресурсы. Получив контроль над Domain Admin, злоумышленник может читать почту руководства, выгружать базы клиентов, разворачивать ransomware одновременно на всех хостах. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные — и добываются они чаще всего через цепочки злоупотреблений правами доступа в AD.

Три типа делегирования Kerberos

Kerberos — протокол аутентификации в AD. Когда ты логинишься на доменную машину, именно Kerberos выдаёт тебе «билет» (TGT), с которым ты потом ходишь по сетевым ресурсам. Делегирование Kerberos позволяет одному сервису действовать от имени пользователя при обращении к другому сервису. Типичный пример: веб-приложение обращается к SQL-серверу «как будто» это сделал пользователь, а не сервисный аккаунт.

Каждый тип управляется через ACL — списки контроля доступа. ACL (Access Control List) — набор правил, определяющих, кто и что может делать с объектом в AD. Каждое правило внутри ACL называется ACE (Access Control Entry). Проще говоря: ACL — это «список допуска» на двери объекта, а каждый ACE — отдельная строчка в этом списке: «Вася может читать», «Петя может менять пароль».

Если ACE настроен неверно — скажем, сервисному аккаунту выданы права GenericAll (полный контроль) на компьютер — атакующий может сам настроить RBCD-делегирование и получить доступ к этому компьютеру от имени Domain Admin.

Как ACL создают путь атаки

MITRE ATT&CK — открытая база тактик и техник атак, по сути «каталог приёмов», которыми пользуются реальные злоумышленники. T-коды (T1558, T1550 и т.п.) — идентификаторы конкретных техник в этом каталоге. Встретишь их в отчётах, в BloodHound, в правилах SIEM — так что привыкай к нумерации. В контексте ACL-злоупотреблений ключевые техники:

• T1558.004 — AS-REP Roasting (Credential Access): получение хеша пароля аккаунта без предварительной аутентификации. Работает против аккаунтов с отключённой преаутентификацией Kerberos — дальше разберём подробно.
• T1558.003 — Kerberoasting (Credential Access): запрос сервисного билета и офлайн-подбор пароля сервисного аккаунта.
• T1550.003 — Pass the Ticket (Lateral Movement): использование украденного билета для доступа к ресурсам — не нужен пароль, достаточно хеша или билета.

Привилегированный доступ в AD — по сути задача обхода графа отношений. Атакующему не нужен аккаунт с правами Domain Admin напрямую. Достаточно найти цепочку из 3–5 промежуточных связей, где каждый шаг — злоупотребление одним ACE. Именно это BloodHound делает автоматически: строит граф и ищет кратчайший путь.

Разведка на HTB Sauna: ASREPRoast атака и первый шелл

[Применимо: внутренний пентест, grey box — есть доступ к сети, нет начальных учётных данных]

Требования к окружению

• Kali Linux или другой дистрибутив с установленным impacket (версия 0.11+), hashcat, evil-winrm
• Подключение к сети цели (HTB VPN или корпоративная сеть)
• Python 3.8+
• Для BloodHound: Docker Compose на атакующей машине, минимум 4 ГБ RAM

Сканирование и определение домена

Запускаем nmap -sC -sV 10.10.10.175 и видим стандартный набор портов контроллера домена: 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), 5985 (WinRM). Домен — EGOTISTICAL-BANK.LOCAL. Перед нами контроллер домена (DC) — машина, на которой хранятся все данные AD: пользователи, группы, ACL. Если получим над ней контроль — получим всё.

На веб-сайте банка (порт 80) размещена страница с именами сотрудников. Из «Fergus Smith» выводим логин fsmith, из других имён — другие варианты. Тут важный момент: в корпоративных сетях логины почти всегда формируются по шаблону (первая буква имени + фамилия, или имя.фамилия). Инструмент kerbrute userenum --dc 10.10.10.175 -d EGOTISTICAL-BANK.LOCAL users.txt проверяет существование аккаунтов через Kerberos — протокол честно сообщает, какие имена валидны, даже без пароля (техника T1087.002 — Domain Account Discovery).

AS-REP Roast: получаем первые учётные данные

AS-REP Roasting (T1558.004) эксплуатирует аккаунты, у которых отключена предварительная аутентификация Kerberos (флаг DONT_REQ_PREAUTH). Что это значит на практике: обычно KDC (Key Distribution Center — центр выдачи ключей Kerberos) требует доказать, что ты знаешь пароль, прежде чем выдать билет. Но если этот флаг включён, KDC отдаёт зашифрованный ответ без проверки. Ответ зашифрован хешем пароля пользователя — а значит, его можно подбирать офлайн, на своей машине, без ограничений по скорости.

Работает если: в домене есть аккаунт с DONT_REQ_PREAUTH = True, пароль подбирается по словарю. Не работает если: все аккаунты требуют предварительную аутентификацию, или пароль длинный и случайный — алгоритм AES256 с солью делает подбор практически невозможным.

Команда impacket-GetNPUsers EGOTISTICAL-BANK.LOCAL/ -usersfile users.txt -dc-ip 10.10.10.175 -format hashcat находит, что у fsmith этот флаг установлен, и возвращает хеш. Подбор через hashcat -m 18200 hash.txt rockyou.txt занимает секунды — пароль словарный.

С паролем подключаемся через WinRM: evil-winrm -i 10.10.10.175 -u fsmith -p '<password>'. Получаем PowerShell от имени обычного доменного пользователя. Первый флаг — в кармане.

BloodHound для Active Directory — строим путь атаки

Зачем нужен граф

У нас шелл обычного пользователя. Как добраться до Domain Admin? В домене с тысячами объектов и ACE вручную найти путь невозможно — это как искать маршрут на карте города без самой карты. BloodHound превращает Active Directory в граф: объекты (пользователи, группы, компьютеры) — узлы, права доступа между ними — направленные рёбра. Инструмент автоматически вычисляет кратчайший маршрут до привилегированных целей.

BloodHound Community Edition (BHCE) от SpecterOps запускается через Docker: docker compose up -d после загрузки docker-compose файла с GitHub. Интерфейс доступен на http://localhost:8080.

Сбор данных через SharpHound

SharpHound — сборщик данных для BloodHound. Он опрашивает AD и собирает информацию о связях между объектами. На атакованной машине загружаем SharpHound и запускаем сбор в тихом режиме:

# Загрузка и запуск SharpHound на доменной машине через WinRM
upload SharpHound.exe
.\SharpHound.exe -c DCOnly
# Результат: ZIP-файл размером 50-200 КБ в текущей директории
download *_BloodHound.zip

Режим DCOnly собирает данные только через LDAP с контроллера домена: членство в группах, ACL объектов, конфигурацию делегирования Kerberos, доверительные отношения. Режим -c All добавит данные об активных сессиях, но генерирует сетевой трафик к каждому хосту — на реальном пентесте это может сработать на EDR. Ожидаемый результат: ZIP-файл. Если файл пустой — убедитесь, что текущий пользователь может обращаться к LDAP (порт 389).

Чтение графа и ключевые рёбра

После загрузки ZIP в интерфейс BloodHound запускаем запрос «Find Shortest Paths to Domain Admins». Граф показывает:

• Узлы (круги) — объекты AD: пользователи, группы, компьютеры
• Рёбра (стрелки) — отношения. Направление стрелки = направление контроля: стрелка от A к B означает, что A имеет право над B

Типы рёбер, критичных для атаки (по данным BloodHound CE documentation и The Hacker Recipes):

Кликнув правой кнопкой на ребро, BloodHound покажет описание атаки, команды для эксплуатации и ссылки на инструменты. Я рекомендую не просто смотреть на граф, а кликать на каждое ребро — так быстрее запоминаешь, что за чем стоит.

ACL abuse: privilege escalation до Domain Admin

Ключевая находка на Sauna

При исследовании Sauna обнаруживается промежуточный шаг, который легко пропустить. В реестре Windows по адресу HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon находятся учётные данные автологина сервисного аккаунта svc_loanmgr. Команда reg query в шелле fsmith возвращает логин и пароль в открытом виде — классическая ошибка конфигурации. Автологин с паролем в реестре — штука, которую я встречаю и в реальных сетях чаще, чем хотелось бы.

BloodHound показывает: svc_loanmgr имеет права DS-Replication-Get-Changes и DS-Replication-Get-Changes-All на объекте домена. Это ребро GetChangesAll — разрешение на DCSync.

DCSync: от ACL до хешей всех пользователей

DCSync — эмуляция поведения контроллера домена. Атакующий «представляется» другим DC и запрашивает репликацию базы паролей. По протоколу это легитимная операция — так контроллеры домена синхронизируют данные между собой. Для этого нужны два ACE на объекте домена: DS-Replication-Get-Changes и DS-Replication-Get-Changes-All. На Sauna у svc_loanmgr оба есть.

# DCSync — дамп всех хешей домена
# Предусловия: impacket установлен, есть учётные данные svc_loanmgr
impacket-secretsdump 'EGOTISTICAL-BANK.LOCAL/svc_loanmgr:password@10.10.10.175'
# Ожидаемый вывод — NTLM-хеши всех аккаунтов:
# Administrator:500:aad3b...:d9485ee1...:::
# krbtgt:502:aad3b...:4a8899...:::

С хешем Administrator выполняем Pass the Hash (T1550.003): impacket-psexec EGOTISTICAL-BANK.LOCAL/Administrator@10.10.10.175 -hashes '<LM:NT>' — получаем шелл SYSTEM на контроллере домена.

Полная цепочка атаки: веб-сайт (имена сотрудников) → AS-REP Roast (fsmith, T1558.004) → шелл через WinRM → автологин в реестре (svc_loanmgr) → DCSync через уязвимую ACL → Pass the Hash → Domain Admin. Четыре разных типа ошибок конфигурации, связанных в одну цепочку. Ни одного эксплойта, ни одной CVE — только мисконфигурации.

Связь с делегированием Kerberos

На Sauna путь атаки не использует делегирование напрямую — но BloodHound проверяет и делегирование, и ACL одновременно. В реальных сетях эти уязвимости переплетаются:

RBCD через GenericWrite: если атакующий получает GenericWrite на компьютерный объект, он может прописать атрибут msDS-AllowedToActOnBehalfOfOtherIdentity и через S4U2Proxy получить билет от имени Domain Admin. Механика: атакующий создаёт фейковый машинный аккаунт (если MachineAccountQuota > 0 — по умолчанию в AD любой пользователь может создать до 10 машинных аккаунтов), прописывает его SID в RBCD-атрибут цели и выполняет constrained delegation эксплуатацию без привилегий SeEnableDelegation (по данным Red Fox Security).

SPN-jacking через WriteSPN: атакующий с правом WriteSPN может временно перехватить SPN (Service Principal Name — идентификатор сервиса в Kerberos) целевого сервиса, назначить его на подконтрольный аккаунт и провести атаку через Constrained Delegation (по данным Semperis). Техника оживляет «мёртвые» пути атаки, когда прямой RBCD или Shadow Credentials невозможны.

Формула на бумаге понятна, но граф ACL по-настоящему ощущается только когда сам прогоняешь сбор данных и видишь, сколько неожиданных рёбер появляется в реальном домене. Готовый стенд для отработки таких цепочек есть на HackerLab.pro — российская CTF-платформа экосистемы Codeby с категориями web, pwn, crypto и другими, нужна регистрация, после неё доступны таски всех уровней.

Когда цепочка не сработает — ограничения и предусловия

Protected Users

Группа Protected Users в AD блокирует: NTLM-аутентификацию (Pass the Hash не работает), кэширование учётных данных, передачу TGT при неограниченном делегировании. Если критичные сервисные аккаунты помещены в эту группу — часть цепочки обрывается. DCSync при наличии прав репликации по-прежнему сработает, но использовать полученные хеши через PtH будет сложнее.

На практике Protected Users встречается нечасто. Многие админы знают о ней, но боятся включать — потому что ломается совместимость со старыми приложениями, которые используют NTLM.

EDR и SIEM-детекция

• SharpHound детектируется большинством EDR при записи на диск. В реальных условиях применяют in-memory загрузку или bloodhound.py — Python-сборщик, работает с Linux через LDAP, не касается endpoint вообще
• DCSync генерирует событие Event ID 4662 (Directory Service Access) с указанием операции репликации. Microsoft Defender for Identity детектирует DCSync нативно. Если в организации настроен SIEM с правилом на 4662 с фильтром по DS-Replication-Get-Changes-All — атака будет замечена. Но по моему опыту, такое правило есть далеко не везде
• AS-REP Roasting оставляет Event ID 4768 с типом шифрования RC4 (0x17). В доменах, где принудительно используется AES, запрос RC4-билета — аномалия, которую легко ловить

Правильная конфигурация

На Sauna уязвимость в том, что сервисному аккаунту выданы права репликации, которые ему для работы не нужны. Типичная история: администратор добавил права для «миграции» или «тестирования» и не убрал. Через полгода про этот аккаунт все забыли, а права остались.

Чеклист защиты:

1. Проверить все ACE на объекте домена: Get-Acl "AD:DC=domain,DC=local" или запрос BloodHound «Find Principals with DCSync Rights»
2. Убрать DS-Replication-Get-Changes-All у всех аккаунтов, кроме контроллеров домена
3. Удалить GenericAll / WriteDacl / GenericWrite там, где они не требуются для работы
4. Использовать gMSA (Group Managed Service Accounts) вместо обычных сервисных аккаунтов — пароли управляются AD автоматически (120+ символов, ротация каждые 30 дней)
5. Запустить BloodHound против собственного домена до того, как это сделает атакующий — по рекомендации SpecterOps, защитники должны видеть свою поверхность атаки первыми

Большинство прохождений HTB сосредоточены на последовательности команд: скопировал, вставил, получил флаг, забыл через неделю. Sauna ценна не командами, а паттерном. В реальных корпоративных сетях я встречаю ту же цепочку — неиспользуемый сервисный аккаунт с избыточными правами, автологин в реестре, отсутствие мониторинга репликации. Разница с HTB только в масштабе: вместо одного DC — десять, вместо пяти пользователей — пятьдесят тысяч, но BloodHound находит путь за те же двадцать минут.

Проблема не в Kerberos и не в делегировании как таковом. Проблема в ACL, которые никто не ревьюит. Домен разрастается годами, права накапливаются, а аудит DACL (Discretionary Access Control List — часть ACL, определяющая разрешения) в большинстве организаций не проводится вообще. Я видел продакшн-домены, где аккаунт стажёра имел GenericAll на OU с серверами — потому что кто-то три года назад тестировал скрипт и забыл откатить.

Мой прогноз: в ближайшие два года количество атак через ACL-злоупотребления в AD вырастет быстрее, чем через эксплойты уязвимостей. ACL бесшумны, не требуют CVE и работают в полностью пропатченных средах. Если разбираешься с безопасностью AD с нуля и хочешь не просто копировать команды, а понимать логику «почему этот ACE опасен» — на IB Basics в Codeby Academy эту базу закрывают за пару месяцев, от понимания структуры домена до построения полной цепочки.