D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Написал: Эрмано
Специально для XSS
Приветстую, форумчане.
Недавно плотно сел за изучение Kerberos, всё начиналось хорошо - атаки все были понятны, механизм аутентификации хорошо расписан, однако как только дело дошло до темы делегирования начались проблемы. Сразу в эту тему я не въехал и практически весь декабрь потратил на её изучение. Мне помогли несколько статей, которые не раз будут тут упомянуты.
Вообще что такое делегирование?
Делегирование это механизм, позволяющий одному сервису обратиться к другому от имени определённого пользователя.
Как пример часто приводят функционал веб-сервиса для поиска чего либо: пользователь передаёт свои идентификационные данные, чтобы веб-сервис смог получить доступ к БД с этими данными.
В Kerberos делегирование делится на несколько видов:
Неограниченное делегирование позволяет сервису обращаться к другому от имени почти любых пользователей(если не установлен флаг NOT_DELEGATED в аттрибуте UAC). Также для права на неограниченное делегирование нужно, чтобы у владельца целевого сервиса в UAC был установлен флаг TRUSTED_FOR_DELEGATION(ADS_UF_TRUSTED_FOR_DELEGATION) и владелец имел привилегию SeEnableDelegationPrivilege.
К сожалению практики в этой статье не будет, так как я в настройке AD относительно плох и всё поломал, однако возможно в следующих статьях я покажу атаки на делегацию(скорее всего так и будет).
Также я буду вставлять схемы из thehacker.recipes, т.к. они уж больно мне нравятся:
Пример атаки на неограниченное делегирование
Ограниченное делегирование
При ограниченном делегировании сервис может обратиться к другому определённому сервису, от имени практически любого пользовтеля.
S4U2Proxy
S4U2Self
Поддерживает 2 расширения - S4U2Proxy(Service for User to Proxy) и S4U2Self(Service for User to Self).
S4U2Proxy
S4U2Proxy - использование только протокола Kerberos для аутентификации.
Для настройки указанного вида делегирования в атрибуте
S4U2Self
S4U2Self - расширение, которое позволяет использовать протоколы помимо Kerberos для аутентификации. Для доступа к такому виду делегирования в аттрибуте UAC учётной записи должен быть установлен флаг TRUSTED_FOR_AUTH_DELEGATION. Тоже требует указания SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.
Когда изучал также использовал данную картинку(опять же с thehacker.recipes):
Ограниченное делегирование на основе ресурсов
Во время изучения данного вида делегирования, мне хотелось всё бросить, позжея так и сделал я смог побороть себя и изучил.
RBCD - вид делегирования при котором сервисы сами определяют, кто может к ним обращаться от имени других пользователей. Если раньше был "ответственный", который решал кто к кому и от имени кого может обращаться, то сейчас это каждый решает сам.
Чтобы настроить RBCD нужно иметь право на запись в атрибут
Ну и заключительная схема:
Итог
В этой статье я хотел кратко и понятно рассказать про делегирование в Kerberos. Надеюсь эта статья кому-то поможет въехать в эту тему, намного быстрее, чем мне
. Также после праздников планирую написать про реализацию атак на делгацию, где мы ещё раз рассмотрим темы из этой статьи.
Также вот ресурсы, которые помогли мне как в осмыслении данной темы, так и в написани этой статьи:
С вами был Эрмано.
С наступающим Новым Годом!:smile10:
P.S. Не пинайте за множество вставок и картинок.
Специально для XSS
Приветстую, форумчане.
Недавно плотно сел за изучение Kerberos, всё начиналось хорошо - атаки все были понятны, механизм аутентификации хорошо расписан, однако как только дело дошло до темы делегирования начались проблемы. Сразу в эту тему я не въехал и практически весь декабрь потратил на её изучение. Мне помогли несколько статей, которые не раз будут тут упомянуты.
Вообще что такое делегирование?
Делегирование это механизм, позволяющий одному сервису обратиться к другому от имени определённого пользователя.
Как пример часто приводят функционал веб-сервиса для поиска чего либо: пользователь передаёт свои идентификационные данные, чтобы веб-сервис смог получить доступ к БД с этими данными.
В Kerberos делегирование делится на несколько видов:
- Неограниченное(Unconstrained)
- Ограниченное(Constrained), которое делится ещё на два подвида:
- S4U2Proxy - с использованием только протокола Kerberos
- S4U2Self - с использование протоколов помимо Kerberos
- Делегирование на основе ресурсов(Resource-based Constrained Delegation)
Неограниченное делегирование позволяет сервису обращаться к другому от имени почти любых пользователей(если не установлен флаг NOT_DELEGATED в аттрибуте UAC). Также для права на неограниченное делегирование нужно, чтобы у владельца целевого сервиса в UAC был установлен флаг TRUSTED_FOR_DELEGATION(ADS_UF_TRUSTED_FOR_DELEGATION) и владелец имел привилегию SeEnableDelegationPrivilege.
К сожалению практики в этой статье не будет, так как я в настройке AD относительно плох и всё поломал, однако возможно в следующих статьях я покажу атаки на делегацию(скорее всего так и будет).
Также я буду вставлять схемы из thehacker.recipes, т.к. они уж больно мне нравятся:

Пример атаки на неограниченное делегирование
Ограниченное делегирование
При ограниченном делегировании сервис может обратиться к другому определённому сервису, от имени практически любого пользовтеля.
S4U2Proxy
S4U2Self
Поддерживает 2 расширения - S4U2Proxy(Service for User to Proxy) и S4U2Self(Service for User to Self).
S4U2Proxy
S4U2Proxy - использование только протокола Kerberos для аутентификации.
Для настройки указанного вида делегирования в атрибуте
msds-allowedtodelegateto
учетной записи необходимо указать SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.S4U2Self
S4U2Self - расширение, которое позволяет использовать протоколы помимо Kerberos для аутентификации. Для доступа к такому виду делегирования в аттрибуте UAC учётной записи должен быть установлен флаг TRUSTED_FOR_AUTH_DELEGATION. Тоже требует указания SPN при обращении к которым приведенной учетной записи требуется олицетворять других пользователей.
Когда изучал также использовал данную картинку(опять же с thehacker.recipes):
Ограниченное делегирование на основе ресурсов
Во время изучения данного вида делегирования, мне хотелось всё бросить, позже
RBCD - вид делегирования при котором сервисы сами определяют, кто может к ним обращаться от имени других пользователей. Если раньше был "ответственный", который решал кто к кому и от имени кого может обращаться, то сейчас это каждый решает сам.
Чтобы настроить RBCD нужно иметь право на запись в атрибут
msDS-AllowedToActOnBehalfOfOtherIdentity
УЗ.Ну и заключительная схема:
Итог
В этой статье я хотел кратко и понятно рассказать про делегирование в Kerberos. Надеюсь эта статья кому-то поможет въехать в эту тему, намного быстрее, чем мне
Также вот ресурсы, которые помогли мне как в осмыслении данной темы, так и в написани этой статьи:
С вами был Эрмано.
С наступающим Новым Годом!:smile10:
P.S. Не пинайте за множество вставок и картинок.
View hidden content is available for registered users!