域渗透之委派攻击

目录

域委派 

委派的分类

非约束性委派流程

约束性委派流程

S4u2Self

S4u2Proxy

基于资源的约束性委派流程

筛选委派属性的账号

利用 PowerSploit 下的 PowerView.ps1脚本

利用 Empire 下的 powerview.ps1 脚本

域委派攻击

非约束委派攻击

约束性委派攻击

约束性委派攻击抓包分析

基于资源的约束性委派攻击

基于资源的约束委派攻击实现本地权限提升

基于资源的约束委派攻击抓包分析

利用委派打造隐蔽后门(权限维持)

域委派攻击防范措施

域委派是大型网络中经常部署的应用模式，给多跳认证带来了很大的便利，但是与此同时也带来了很大的安全隐患，利用委派，攻击者可获取本地管理员甚至域管理员权限，还可以制作深度隐藏的后门。

域委派

域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户权限访问域内的其他服务。如下图：

User(xie\test)——> websrv (以User的身份) ——> Service(文件服务器)

域用户 xie\test 以 kerberos 身份验证访问 Web 服务器，请求下载文件。但是真正的文件在后台的文件服务器上。于是，Web服务器的服务账号 websrv 模拟域用户 xie\test，以 kerberos 协议继续认证到后台文件服务器。后台文件服务器将文件返回给Web服务器，Web服务器将文件返回给域用户 xie\test 。这样，就完成了一个委派的流程。

1. 域用户 xie\test 以 kerberos 身份验证访问 Web 服务器，请求下载文件。

2. Web服务的服务账号为 websrv。由于Web服务器上无用户请求的文件，所以 websvc 向KDC发起 xie\test 用户的票据请求。

3. KDC检查websrv服务账号的委派属性，如果被设置，则返回 xie\test 用户的可转发TGT认购权证；

4. websrv 收到 xie\test 用户的TGT认购权证后，使用该TGT向KDC申请访问文件服务器的ST服务票据；

5. KDC检查websrv服务账号的委派属性，如果被设置，并且申请的文件服务在允许的列表清单中，则返回xie\test 用户访问文件服务的ST服务票据；

6. websrv 收到 KDC 返回的 xie\test 用户的ST服务票据后，用该ST服务票据访问文件服务器，并且将文件服务器返回的文件返回给xie\test用户，就此完成委派认证。

在域中，只有 服务账号 和 主机账号 才具有委派属性

· 主机账号就是AD活动目录中 Computers 中的计算机，也可以称为机器账号(一个普通域用户默认最多可以创建十个主机账号)。

· 服务账号（Service Account）是域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来并加入域。例如SQL Server 在安装时，会在域内自动注册服务账号 SQLServiceAccount。也可以将域用户通过注册SPN变为服务账号。

委派使用的前提

需要被委派的用户未设置不允许被委派属性。

如图，administrator 用户设置了敏感账号不能被委派，所以administrator用户不能被委派。

委派的分类

域内委派主要有3种应用方式：

非约束性委派（Unconstrained Delegation）：对于非约束性委派（Unconstrained Delegation），服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟用户访问任意服务。配置了非约束委派的账户的userAccountControl 属性有个FLAG位 WORKSTATION_TRUSTED_FOR_DELEGATION。非约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员 。 

约束性委派（Constrained Delegation）：由于非约束委派的不安全性，微软在Windows Server 2003中发布了约束性委派。对于约束性委派（Constrained Delegation），即Kerberos的两个扩展子协议 S4u2self (Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )，服务账号只能获取用户的TGS，从而只能模拟用户访问特定的服务。配置了约束委派的账户的 userAccountControl 属性有个FLAG位 TRUSTED_TO_AUTH_FOR_DELEGATION，并且msDS-AllowedToDelegateTo 属性还会指定对哪个SPN进行委派。约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员 。                                                                                                      

基于资源的约束性委派(RBCD：Resource Based Constrained Delegation)：为了使用户/资源更加独立，微软在Windows Server 2012中引入了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，而把设置属性的权限赋予给了机器自身。基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置，但可以在混合模式林中应用。配置了基于资源的约束委派的账户的 userAccountControl 属性为 WORKSTATION_TRUST_ACCOUNT，并且msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。 

基于资源的约束性委派的优势：

· 委派的权限授予给了拥有资源的后端(B)，而不再是前端(A)

· 约束性委派不能跨域进行委派，基于资源的约束性委派可以跨域和林

· 不再需要域管理员权限设置委派，只需拥有在计算机对象上编辑”msDS-AllowedToActOnBehalfOfOtherIdentity”属性的权限，也就是 将计算机加入域的域用户 和 机器自身 拥有权限。

约束性委派和基于资源的约束性委派配置的差别：

· 传统的约束委派是“正向的”，通过修改服务A的属性”msDS-AllowedToDelegateTo”，添加服务B的SPN（Service Principle Name），设置约束委派对象（服务B），服务A便可以模拟用户向域控制器请求访问服务B的ST服务票据。

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

非约束性委派流程

前提：在机器账号B上配置了非约束性委派(域管理员才有权限配置)

1. 用户访问机器B的某个服务，于是向KDC认证。KDC会检查机器B的机器账号的属性，发现是非约束性委派，KDC会将用户的TGT放在ST服务票据中。

2. 用户访问机器B时，TGT票据会和ST服务票据一同发送给机器B

3. 这样B在验证ST服务票据的同时获取了用户的TGT，并将TGT存储在LSASS进程中，从而可以模拟用户访问任意服务

从网络攻击的角度来看，如果攻击者控制了机器B的机器账号，并且机器B配置了非约束性委派。则攻击者可以诱骗管理员来访问机器B，然后攻击者可以获取管理员的TGT，从而模拟管理员访问任意服务，即获得了管理员权限。

约束性委派流程

为了进行约束性委派，微软在 Kerberos 协议的 TGS_REQ & TGS_REP 阶段引入了两个扩展子协议 S4u2Self (Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )。S4u2self 可以代表任意用户请求针对其自身的Kerberos服务票据(ST)；S4u2Proxy可以以上一步用户的名义请求其它服务的服务票据。约束性委派就是限制了 S4u2Proxy 扩展的范围。

前提：在服务A上配置到服务B约束性委派(域管理员才有权限配置)

1. 用户访问服务A，于是向域控进行kerberos认证，域控返回ST1服务票据给用户，用户使用此服务票据访问服务A

2. 若该服务A允许委派给服务B，则A能使用S4U2Proxy协议将用户发送给自己的可转发的ST1服务票据以用户的身份再转发给域控制器。于是域控返回给服务A一个ST2服务票据，