Ограниченное делегирование.
Неограниченное делегирование может быть опасным, чтобы создать более ограниченный механизм делегирования, Microsoft разработала два расширения Kerberos, известные как Service for User (S4U):
Используя эти расширения, службы могут быть ограничены выполнением делегирования только в отношении набора разрешенных сторонних служб, и не требуется пользовательский TGT, что предотвращает его сохранение на сервере службы. Это известно как ограниченное делегирование.
Не вдаваясь в подробности реализации S4U2Self/S4U2pr, можно сказать, что любые учетные записи с SPN (Service Principal Name), имеющие в свойствах установленный атрибут msDS-AllowedToDelegateTo, могут выдавать себя за любого пользователя в домене. Если бы можно было изменить содержимое msDS-AllowedToDelegateTo для произволь-ной учетной записи, мы могли бы выполнить DCSync-атаку на текущий домен. Но для изменения любых параметров делегирования на контроллере домена нужно иметь привилегию SeEnableDelegationPrivilege. По умолчанию такими правами обладают только учетные записи администраторов домена.
S4U2self позволяет службе запрашивать у себя специальный перенаправляемый TGS от имени конкретного пользователя. Такой механизм предназначен для случаев, когда пользователь авторизуется в сервисе без использования Kerberos (в нашем примере — с веб-сервисом). Во время первого запроса TGS будет установлен флаг переадресации, чтобы возвращаемый TGS был помечен как пересылаемый и мог использоваться с расширением S4U2proxy. При неограниченном делегировании для идентификации пользователя применяется TGT, в этом случае расширение S4U использует структуру PA-FOR-USER в качестве нового типа в поле данных padata]/pre-authentication. S4U2self может выполняться для любой пользовательской учетной записи, при этом пароль целевого пользователя не требуется. Кроме того, S4U2self разрешает-ся, только если учетная запись запрашивающего пользователя имеет флаг TRUSTED_TO AUTH_FOR_DELEGATION.
Почему в рассматриваемом нами случае не получится извлечь с использованием Kerberoasting данные любого пользователя, которого мы захотим? Потому что сертификат Privilege Account Certificate (PAC) подписан для исходного (а не целевого) пользователя (в данном случае для запрашивающей учетной записи службы). Но зато теперь у нас есть специальный билет службы, который можно переадресовать целевой службе, настроенной для ограниченного делегирования.
Расширение S4U2proxy (Service for User to Proxy) позволяет службе запрашивать другую службу от имени клиента, используя клиентский ST (Сервисный билет), отправленный службе, вместо клиентского TGT. Оно позволяет вызывающей стороне (в нашем случае учетной записи службы) использовать этот перенаправляемый билет, чтобы запросить TGS к любому SPN, перечисленному в msDS-AllowedToDelegateTo, для олицетворения указанного на этапе S4U2self пользователя. KDC проверяет, есть ли запрашиваемый сервис в поле msDS-AllowedToDelegateTo запрашивающего пользователя, и выдает билет, если эта проверка прошла успешно. Таким образом, мы можем определить критерий поиска ограниченного делегирования - ненулевое значение msDS-AllowedToDelegateTo:
Get-DomainComputer -TrastedToAuth Get-DomainUser -TrastedToAuth
Учетная запись компьютера или пользователя с SPN, указанным в msDS-AllowedToDelegateTo, может олицетворять любого пользователя в целевой службе. Поэтому, скомпрометировав одну из этих учетных записей, вы можете захватить привилегии доступа к целевому SPN. Для MSSQLSvc это позволило бы получить права администратора баз данных. CIFS откроет полный удаленный доступ к файлам. НТТР позволил бы захватить удаленный веб-сервис. LDAP — произвести DCSync. HTTP/SQL, даже если они не имеют повышенных прав администратора в целевой системе, также могут быть использованы для повышения прав до System. Если вам известен пароль от учетной записи, для которой включено ограниченное делегирование, можно использовать Kekeo для запроса TGT, выполнить запрос S4U TGS и затем получить доступ к целевой службе.
Выполняем запрос TGT для учетной записи пользователя с включенным ограниченным делегированием (к примеру, SQLService):
asktgt.exe /user:Пользователь /domain: домен /password: пароль /ticket:sqlservice.kirbi
Теперь выполняем S4U2proxy с полученным TGT. В результате у нас будет TGS для доступа к приватному ресурсу в домене:
squ.exe /tgt:sqlservice.kirbi /user:Administrator@домен /service:cifs/ресурс_в_домене
Используем mimikatz, чтобы применить TGS: ## kerberos: :ptt файл с полученным TGS.
В итоге мы получаем доступ к приватному ресурсу. Если вы можете скомпрометировать учетную запись компьютера, которая настроена для ограниченного делегирования, подход к атаке будет несколько другим. Поскольку любой процесс, выполняющийся с системными привилегиями, получает привилегии учетной записи локального компьютера, мы можем пропустить шаг с asktgt.ехе. Также можно использовать альтернативный метод для выполнения процесса S4U2proxy, предостав-ленный Microsoft. Для этого откроем Power Shell и выполним следующий код:
PS C:\> $Null = [Reflection.Assembly]::LoadWithPartialName('System. IdentityModel')
PS C: \> $Ident = New-Object System.Security.Principal.WindowsIdentity @('[email protected]')
PS C: > Context = SIdent.Impersonate()Теперь, когда мы применили TGS указанного пользователя, мы можем снова работать с приватным ресурсом. Затем вернемся в свое пользовательское пространство следующей командой Power Shell:
PS C:\> SContext.Undo()