Ограниченное делегирование на основе ресурсов - RBCD (от англ. Resource Based Constrained Delegation).
Для настройки неограниченного и ограниченного видов делегирования требовалось наличие привилегии SeEnableDelegation, которой по умолчанию обладали только учетные записи с правами уровня администратора домена. При делегировании, ограниченном на основе ресурсов, сервис напротив самостоятельно определяет, кто может обращаться к нему от имени других пользователей.
Пояснение простыми словами - раньше назначался ответственный, который сам решал к кому и от имени кого он может обращаться. Теперь каждый сам решает, кто может обращаться к нему от имени других.
Для настройки RBCD требуется право на запись в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи. В указанном атрибуте записываются и хранятся в двоичном виде идентификаторы безопасности (SID) учетных записей, сервисам которых разрешено олицетворять других пользователей при обращении к сервисам учетной записи с настроенным RBCD.
Рассмотрим процесс RBCD по пунктам:
- Каким образом User прошел аутентификацию к Сервису А неважно, допустим, что с использованием отличного от Kerberos протокола NTLM.
- Сервис А обращается к контроллеру домену для получения TGS-билета “на себя” от имени пользователя User.
- Контроллер домена проверяет, что у учетной записи “Владелец А” активен флаг TRUSTED_TO_AUTH_FOR_DELEGATION. Указанный флаг не активен, поэтому в ответ отправляется обычный nonforwardable TGS-билет без права передачи для User к Сервису А. Таким образом S4U2Self работает также, как и в случае классического ограниченного делегирования.
- С использованием полученного TGS-билета Сервис А обращается к контроллеру домена для получения Forwardable TGS-билета к Сервису Б от имени User. Контроллер домена проверяет, что в атрибуте msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи “Владелец Б” установлен SID учетной записи “Владелец А”. Также контроллер домена проверяет, что “Владелец А” обладает хотя бы одним SPN. В результате контроллер домена отправляет в ответ Forwardable TGS-билет.
- Сервис А обращается от имени User к Сервису Б с использованием полученного Forwardable TGS-билета.
- Возможность изменять содержимое атрибута msDS-AllowedToActOnBehalfOfOtherIdentity атакуемой учетной записи.
- Контроль над учетной записью, обладающей SPN.
Результат успешной атаки: доступ с административными правами к серверу, предназначенному для функционирования сервиса, работающего от имени учетной записи с настроенным RBCD.
На первом шаге атакующий записывает SID подконтрольной учетной записи, обладающей SPN, в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity атакуемой учетной записи. Таким образом для подконтрольной учетной записи предоставляется право на олицетворение практически любого пользователя при обращении к сервису атакуемой учетной записи.
rbcd.py 'DomainFQDN'/'Username':'Password' -delegate-from 'ControlledAccountWithSPN' -delegate-to 'Target#39; -dc-ip 'DC_IP' -action write
На втором шаге атакующий выполняет S4U2Self запрос TGS-билета от имени административного пользователя к сервису работающему из-под контролируемой учетной записи. В результате запроса атакующий получает Nonforwardable TGS-билет.
getST.py -spn "cifs/target" -impersonate $AdminAccountName -dc-ip $DomainController $DomainFQDN/$ControlledAccountWithSPN:$Password
На третьем шаге атакующий c использованием полученного Nonforwardable TGS-билета выполняет S4U2Proxy запрос. В результате успешного запроса атакующий получает Forwardable TGS-билет к сервису атакуемой учетной записи от имени административного пользователя. На этом атака считается завершенной.