域渗透-非约束委派

域委派是什么及其由来

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

懂一个东西的产生，肯定要先知道为什么会产生这个东西？

在Windows 2000 Server首次发布Active Directory时，Microsoft必须提供一种简单的机制来支持用户通过kerberos向web server进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案。这通常称为"kerberos双跳问题"，并且要求进行委派，以便web server在修改数据库记录时模拟用户。

这里说的"以便web server在修改数据库记录时模拟用户" 需要如何理解？

我自己理解的是就比如数据库中的相关数据需要修改，如果此时如果是让当前的web server的服务账户去进行修改的话，那么也就无法记录到到底是谁去修改了这个数据，此时如果出了问题就不知道该去问谁了，这种业务情况下就可能就是需要委派这种功能来进行解决，那么委派之后的情况就是，让当前的web server的服务账户去操作，但是web server同样带有客户的信息，在修改相关数据的时候，用的是对应客户操作者的记录。

这里还需要注意的一点就是接受委派的用户只能是服务账户或者主机账户

在域内只有主机账号和服务账号才有委派属性主机账号：

1、机器账户：活动目录中的computers组内的计算机，也被称为机器账号。

2、服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer，MYSQL等，还有就是域用户通过注册SPN也能成为服务账号。

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

非约束性委派（Unconstrained Delegation）

通俗来讲就是 ：

在域中如果出现A使用Kerberos身份验证访问域中的服务B,而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派

一个经典例子：参考Y4er

jack需要登陆到后台文件服务器，经过Kerberos认证的过程如下：

1. jack以Kerberos协议认证登录，将凭证发送给websvc

2. websvc使用jack的凭证向KDC发起Kerberos申请TGT。

3. KDC检查websvc的委派属性，如果websvc可以委派，则返回可转发的jack的TGT。

4. websvc收到可转发TGT之后，使用该TGT向KDC申请可以访问后台文件服务器的TGS票据。

5. KDC检查websvc的委派属性，如果可以委派，并且权限允许，那么返回jack访问服务的TGS票据。

6. websvc使用jack的服务TGS票据请求后台文件服务器。

微软的非约束委派的请求流程图如下所示

1. 用户通过发送KRB_AS_REQ消息请求TGT1 (TGT1是用户访问service1的票据)

2. KDC在KRB_AS_REP消息中返回TGT1

3. 用户再通过TGT1向KDC请求转发TGT2（这里的TGT2跟TGT1不同，这里的TGT2票据属性中存在可转发的标记Forwarded）

4. 在KRB_TGS_REP消息中返回转发TGT2（可转发的标记Forwarded）

5. 用户使用TGT1向KDC申请访问Service1的ST（服务票据）

6. TGS返回给用户一个ST（服务票据）

到第六步这里，其实大家都看到了就是一个完整的kerberos票据验证流程，唯一有一个不同，那就是在请求了TGT1票据之后还会再去请求另一张TGT2票据，这个TGT2的票据跟TGT1唯一的不同点就是带有"可转发的标记Forwarded

7.用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST（服务票据）、TGT2、TGT2的Session key

在第七步的时候可以看到，发送给Service1的时候会发送了相关的TGT1 ST 和 TGT2 TGT2的Session key，需要注意的就是这里的TGT2（可转发的标记） TGT2的Session key会被存储到Service1中用于之后的请求

8.Service1使用用户的TGT2（可转发的标记）通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据ST2

9.KDC在KRB_TGS_REP消息中返回Service2到Service1的票据ST2

10.Service1以客户的名义用ST2发送KRB_AP_REQ请求

为什么是以客户的名义呢？个人理解就是因为上面我们说的TGT2（可转发的标记）来请求Service2。

11.Service2响应步骤10中Service1的请求

12.Service1响应步骤7中用户的请求

13.在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务

14.KDC返回步骤13中请求的票据，15和16即为Service1通过模拟用户来访问其他ServiceXXXX

当user访问service1时，如果service1的服务账号如果开启了Unconstrained Delegation（非约束委派），则当user访问service1时会将user的TGT（带有可转发标记）发送给service1并保存在内存中以备下次重用，然后service1 就可以利用这张TGT以user的身份去访问域内的任何服务（任何服务是指user能访问的服务）了。

说在简单点就是：

比如：service1配置了非约束性委派，用户A需要委派service1来访问service2。这个service1可以是主机账户。

那么非约束性委派的过程可以大概理解为：

用户A向KDC申请一张可转发的用户A自己的TGT与访问service1需要的ticket。 用户A将第一步得到的ticket与可转发的tgt与tgt中的session key一起发送给了service1. service1使用那张tgt与session key来代表用户A行使后续操作例如访问service2.

非约束委派的利用

主机账户的非约束委派利用：

一台 WIN-BING-PC 机器名称的机器

通过adFind进行查询，也可以看到此时已经被设置为了非约束委派

adFind -b dc=hengge,dc=com -f "(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

然后域控再次访问 WIN-BING-PC 这台机器，通过命令dir //WIN-BING-PC/c$，走是的kerberos的cifs协议

然后导出 WIN-BING-PC 机器中的票据

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

结果发现没有相关的administrator的票据kirbi

接着我用域控通过命令来访问Enter-PSSession -ComputerName WIN-BING-PC

然后导出 WIN-BING-PC 机器中的票据

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

然后会看到一张基于导出了相关的域控中administrator的高权限票据

访问域控 dc1.hengge.com ，可以看到当前没有权限访问

然后这里来进行导入票据访问，可以发现成功进行访问了

mimikatz "kerberos::ptt [0;7f4a8]-2-0-60a10000-Administrator@krbtgt-HENGGE.COM.kirbi" exit

服务账号的非约束委派利用

实验环境：

域：YUNYING.LAB

域控：WindowsServer 2008 R2 x64(DC)：用户Administrator

域内主机：WindowsServer 2008 R2 x64(s2)：用户tsvc

所需工具：

Mimikatz

实验流程：

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

setspn -U -Avariant/golden tsvc

通过setspn -l tsvc查看配置成功。

然后在“AD用户和计算机”中将tsvc设置为非约束委派模式

此时在域控上使用Administrator访问tsvc所在主机S2的SMB服务。

我们在S2上通过mimikatz可以导出Administrator发送过来的TGT内容。这里需要使用管理员权限打开mimikatz，然后通过privilege::debug命令提升权限，如果没有提升权限会报kuhl_m_sekurlsa_acquireLSA错误。再使用sekurlsa::tickets/export命令导出内存中所有的票据。

可以看到名称为[0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi的这一条即为Administrator发送的TGT。

此时访问域控被拒绝。

通过

kerberos::ptt [0;9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi

命令将TGT内容导入到当前会话中，其实这也是一次Pass The Ticket攻击（有兴趣的可以了解一下）。

通过kerberos::list查看当前会话可以看到票据已经导入到当前会话。

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

非约束委派+Spooler打印机服务

环境：DM可委派，DC是域控。

利用Windows打印系统远程协议（MS-RPRN）中的一种旧的但是默认启用的方法，在该方法中，域用户可以使用MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex)方法强制任何运行了Spooler服务的计算机以通过Kerberos或NTLM对攻击者选择的目标进行身份验证。

工具：https://github.com/leechristensen/SpoolSample

议题文章地址：https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory

需要以域用户运行SpoolSample，需要开启Print Spooler服务，该服务默认自启动。

SpoolSample.exe DC DM

使DC强制访问DM认证，同时使用rubeus监听来自DC的4624登录日志

Rubeus.exe monitor /interval:1 /filteruser:dc$

使用Rubues导入base64的ticket

./Rubeus.exe ptt /ticket:base64

此时导出的ticket就有DC的TGT了

用mimikatz ptt就完事

参考：https://y4er.com/post/kerberos-unconstrained-delegation/

https://www.freebuf.com/articles/neopoints/198381.html

https://www.cnblogs.com/zpchcbd/p/12939246.html