委派攻击

在Windows Server2000首次发布Active Directory时，Microsoft就提供了一种简单的机制来支持用户通过Kerberos向Web服务器进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案，这就是最早的非约束性委派（UD：Unconstrained Delegation）。对于非约束性委派，服务账号可以获取被委派用户的TGT认购权证，并将TGT认购权证缓存到LSASS进程中，从而服务账号可使用该TGT认购权证，模拟该用户访问任意服务。非约束委派的设置需要SeEnableDelegationPrivilege特权，该特权默认仅授予域管理员和企业管理员。

• 配置了非约束性委派属性的机器账号的userAccountControl 属性有个Flag位：WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x81000=528384，如图所示。

• 配置了非约束性委派属性的服务账号的userAccountControl 属性有个Flag位：NORMAL_ACCOUNT|TRUSTED_FOR_DELEGATION，其对应的数是0x80200=524800，如图所示。

注：域控制器默认配置了非约束性委派。

下图所示是微软官方对于非约束性委派流程的介绍：

让我们来分析一下整个流程中每一步骤的含义：

（1）用户通过发送一个KRB_AS_REQ消息，向KDC密钥分发中心KDC的AS认证服务进行身份验证，请求一个可转发的TGT1认购权证。

（2）KDC在KRB_AS_REP消息中返回了一个可转发的TGT1认购权证。

（3）用户根据上一步获取到的可转发的TGT1认购权证请求另一个可转发的TGT2认购权证，这一步是通过KRB_TGS_REQ消息请求。

（4）KDC在KRB_TGS_REP消息中为用户返回可转发的TGT2认购权证。

（5）用户使用步骤2中返回的TGT1认购权证向KDC请求Service1的ST服务票据。

（6）KDC的TGS服务在KRB_TGS_REP消息中返回给用户Service1的ST服务票据。

（7）用户发送KRB_AP_REQ消息请求Service1，KRB_AP_REQ消息中包含了TGT1认购权证和Service1的ST服务票据、TGT2认购权证、TGT2认购权证的SessionKey。

（8）service1以用户的名义向KDC的TGS服务发送KRB_TGS_REQ请求，请求Service2的ST服务票据。请求中包含用户发过来的TGT2认购权证。

（9）KDC的TGS服务在KRB_TGS_REP消息中返回Service2的ST服务票据给Service1，以及service1可以使用的sessionkey。ST服务票据将客户端标识为用户，而不是Service1。

（10）Service1以用户的名义向Service2发起KRB_AP_REQ请求。

（11）Service2响应service1的KRB_AP_REQ请求。

（12）有了步骤11这个响应，Service1就可以响应步骤7中用户的KRB_AP_REQ请求。

（13）这里的TGT认购权证转发委派机制没有限制Service1使用TGT2认购权证来申请哪个服务，所以Service1可以以用户的名义向KDC申请任何其他服务的ST服务票据。

（14）KDC返回步骤13中请求的ST服务票据。

（15）Service1以用户的名义来请求其它service N服务。

（16）Service N服务将响应用户的请求一样响应Service1。

在该流程中，TGT1认购权证请求的ST服务票据用于访问service1服务，TGT2认购权证请求的ST服务票据用于访问service2服务。

从网络攻击者的角度来看，如果攻击者控制了service1，则攻击者可以诱骗域管理员来访问service1服务，然后攻击者可以在service1机器上获取域管理员的TGT认购权证，从而攻击者可以用缓存的TGT认购权证模拟管理员访问任意服务，包括域控。

由于非约束性委派的不安全性，微软在Windows Server 2003中发布了约束性委派。对于约束性委派（Constrained Delegation），服务账号只能获取该用户对指定服务的ST服务票据，从而只能模拟该用户访问特定的服务。配置了约束性委派账户的msDS-AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束委派的设置需要 SeEnableDelegationPrivilege特权，该特权默认仅授予域管理员和企业管理员。

约束性委派有两种：

• 一种是仅使用Kerberos(K)，也就是不能进行协议转换，如图所示。

• 另一种是使用任何身份验证协议(N)，也就是能进行协议转换，如图所示。

配置了仅使用Kerberos(K)约束性委派的机器账号和服务账号的userAccountControl属性与正常账号一样，但是其msDS-AllowedToDelegateTo属性会有允许被委派的服务的SPN。如图所示：

• 配置了使用任何身份验证协议(N)约束性委派的机器账号的userAccountControl属性有个FLAG位 WORKSTATION_TRUST_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION，其对应的数是0x1001000=16781312，如图所示。并且其msDS-AllowedToDelegateTo属性会有允许被委派的服务的SPN。

• 配置了使用任何身份验证协议(N)约束性委派的服务账号的userAccountControl属性有个FLAG位 

NORMAL_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION，其对应的数是0x1000200=16777728，如图所示。并且其msDS-AllowedToDelegateTo属性会有允许被委派的服务的SPN。

为了在Kerberos协议层面对约束性委派的支持，微软对Kerberos协议扩展了两个子协议 S4u2self(Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )。S4u2self 可以代表任意用户请求针对自身的ST服务票据；S4u2Proxy可以用上一步获得的ST服务票据以用户的名义请求针对其它指定服务的ST服务票据。

如图所示是微软官方对于使用任何身份验证协议(N)约束性委派流程的介绍：

让我们来分析一下整个流程中每一步骤的含义：

（1）用户向Service1发出请求，用户已通过身份验证，但Service1没有用户的授权数据，这通常是由于用户的身份验证是通过Kerberos以外(基于表单的web认证、NTLM认证等)的其他方式验证的。

（2）Service1已经通过KDC进行了身份验证，并获得了TGT认购权证。它通过S4U2self协议代表用户向KDC请求一张访问自身Service1服务的可转发ST服务票据。

（3）KDC返回给Service1一张访问Service1自身服务的可转发ST1服务票据，就像是用户使用自己的TGT认购权证请求的一样，该可转发的ST1服务票据可能包含用户的授权数据。

（4）Service1可以使用ST1服务票据中的授权数据来满足用户的请求，然后响应用户。

（5）用户向Service1发出请求，请求访问Service2上的资源。

（6）Service1利用S4U4Proxy协议以用户的名义向KDC请求访问Service2的ST2服务票据，该请求中带上了可转发的ST1服务票据

（7）如果请求中存在PAC特权属性证书，则KDC通过检查PAC结构的签名数据来验证PAC。如果PAC有效或不存在，KDC返回Service2的可转发ST2服务票据，并且存储在ST2服务票据中的cname和crealm字段中的客户端标识是用户，而不是Service1。

（8）Service1以用户身份使用可转发ST2服务票据向Service2发起请求。

（9）Service2响应步骤8的请求。

（10）Service1响应用户对步骤5中的请求。

从网络攻击的角度来看，如果攻击者控制了Service1的服务账号，并且Service1配置了到域控的CIFS服务的约束性委派。则攻击者可以利用Service1以任意用户权限(包括域管理员)访问域控的CIFS服务，即相当于控制了域控。

整个流程简化点概括如下图所示：

1）S4u2Self

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

注：虽然S4U2Self协议允许服务代表用户向KDC请求一张访问自身服务的ST服务票据，但是此协议扩展不允许服务代表用户向KDC请求访问其他服务的ST服务票据。

2）S4u2Proxy

S4u2Proxy可以用上一步获得的可转发ST服务票据以用户的名义请求针对其它指定服务的ST服务票据。S4U2Proxy 使得服务A可以使用来自用户test的授权，然后以用户test的身份向KDC请求访问服务B的ST服务票据。如图所示，是S4u2Proxy的过程：

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

并且委派属性这里没有任何值，如图所示。

并且委派属性这里没有任何值，如图所示。

基于资源的约束性委派简要流程如图所示：

整个流程如下：

①：服务A使用自己的服务账号密码向KDC申请一个可转发的TGT认购权证。

②：服务A利用S4U2Self协议代表用户申请一个获得针对服务A自身的ST服务票据。这一步区别于传统的约束性委派。在S4U2Self协议里面提到，返回的ST服务票据可转发的一个条件是服务A配置了传统的约束委派。KDC会检查服务A的msDS-AllowedToDelegateTo字段，如果这个字段赋值了，则KDC返回可转发的ST服务票据。但是由于这里是基于资源的约束性委派，是在服务B上配置的，服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务A的SID，因此服务A并没有配置 msDS-AllowedToDelegateTo 字段。因此KDC返回的ST服务票据是不可转发的。

③：服务A利用S4U2Proxy协议以用户的身份向KDC请求访问针对服务B的可转发的ST服务票据(上一步获得的不可转发的ST服务票据放在请求包的AddtionTicket里面)。KDC返回一张访问服务B的可转发的ST服务票据。

④：服务A拿着上一步获得的可转发的ST服务票据访问服务B。

从上面我们知道，配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许委派账号的SID。那么，谁能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性，就说明谁拥有配置基于资源的约束性委派的权限了！

在域控上执行如下命令查询指定域内机器win2012R2的msDS-AllowedToActOnBehalfOfOtherIdentity 属性。

AdFind.exe -f "&(objectcategory=computer)(name=win2012R2)" msDS-AllowedToActOnBehalfOfOtherIdentity

如图所示，查询域内机器win2012R2的msDS-AllowedToActOnBehalfOfOtherIdentity 属性，发现默认情况下，没有该属性。

也就是说，谁能增加机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性，就说明谁能配置基于资源的约束性委派。我们使用adfind查询win2012R2机器的ACL，看哪些用户对其有修改属性的权限，查询命令如下所示：

adfind.exe -b CN=WIN2012R2,CN=Computers,DC=xie,DC=com -sc getacl -sddl+++ -sddlfilter ;;"WRT PROP";;;

如图所示，可以看出除了administrator用户外，xiehack用户和SELF自身拥有修改属性的权限。

administrator和SELF自身拥有修改属性权限好理解，那么为啥xiehack用户也拥有修改属性的权限呢？这是因为win2012R2机器是通过xiehack用户加入域的，因此xiehack用户拥有修改win2012R2机器属性的权限。并且win2012R2机器的mS-DS-CreatorSID属性的值为xiehack用户的SID，我们通过adfind执行如下命令查询可以验证该结论。

#查询win2012r2机器的mS-DS-CreatorSID属性AdFind.exe -f "&(objectcategory=computer)(name=win2012R2)" mS-DS-CreatorSID#查询sid对应的用户AdFind.exe -sc adsid:S-1-5-21-1313979556-3624129433-4055459191-1105

如图所示，可以看到win2012R2机器的mS-DS-CreatorSID属性的值确实为xiehack用户的SID。

结论：也就是说，除了传统的域管理员等高权限用户外，机器自身和将机器加入域的域用户拥有修改机器msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。

那么基于资源的约束性委派相比域其他两种类型的委派有啥优势呢？

• 委派的授予权限给了拥有资源的后端，而不是前端。

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

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

那么约束性委派和基于资源的约束性委派在配置上有何差别呢？

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

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

如图所示，可以看到两者配置的差别：

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

引用博客文章中的一张图说明该攻击步骤，如图所示：

要想进行基于资源的约束性委派攻击，需要具备下面两个条件：

• 拥有服务A的权限，这里我们只需要拥有一个普通的域账号权限即可，因为普通的域账户默认可以创建最多十个机器账号。机器账号可以作为服务账号使用。

• 拥有在服务B上配置允许服务A的基于资源的约束性委派的权限，即拥有修改服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。而机器账号自身和创建机器账号的用户即拥有该权限。

所以，以上两个条件可以转换为拥有 将机器加入域的域用户的权限 或 机器自身的权限。

查询非约束性委派的主机或服务账号可以使用powershell脚本、adfind或ldapsearch等工具。

利用 PowerSploit 下的 PowerView.ps1脚本查询，使用命令如下：

Import-Module .PowerView.ps1; #查询域中配置非约束委派的主机 Get-NetComputer -Unconstrained -Domain xie.com #查询域中配置非约束委派的服务账户 Get-NetUser -Unconstrained -Domain xie.com | select name

如图所示，使用该脚本查询出域中配置了非约束性委派的主机有AD01和AD02，配置了非约束性委派的服务账号有service_account。

利用adfind执行如下命令过滤samAccountType和userAccountControl属性，即可查询出域内配置了非约束性委派的主机和服务账号。

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

如图所示，使用adfind查询出域中配置了非约束性委派的主机有AD01和AD02，配置了非约束性委派的服务账号有service_account。

利用ldapsearch执行如下命令过滤samAccountType和userAccountControl属性，即可查询出域内配置了非约束性委派的主机和服务账号。

#查询域中配置非约束委派的主机ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" | grep dn#查询域中配置非约束委派的服务账户ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" | grep dn

如图所示，使用ldapsearch查询出域中配置了非约束性委派的主机有AD01和AD02，配置了非约束性委派的服务账号有service_account。

查询非约束性委派的主机或服务账号可以使用powershell脚本、adfind或ldapsearch等工具。

利用 Empire 下的 powerview.ps1 脚本，使用命令如下：

如图所示，使用该脚本查询出域中配置了约束性委派的主机有Win7，配置了约束性委派的服务账号有service_account。

利用adfind执行如下命令过滤samAccountType和userAccountControl属性，即可查询出域内配置了约束性委派的主机和服务账号。

#查询域中配置了约束性委派的主机，并可以看到被委派的SPN AdFind.exe -b "DC=xie,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto #查询域中配置了约束性委派的服务账户，并可以看到被委派的SPN AdFind.exe -b "DC=xie,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

如图所示，使用adfind查询出域中配置了约束性委派的主机有win7，配置了非约束性委派的服务账号有service_account，并且查询出他们委派的服务的SPN。

利用ldapsearch执行如下命令过滤samAccountType和userAccountControl属性，即可查询出域内配置了约束性委派的主机和服务账号。

#查询域中配置了约束性委派的主机，并可以看到被委派的SPN ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" | grep -e dn -e msDS-AllowedToDelegateTo#查询域中配置了约束性委派的服务账户，并可以看到被委派的SPN ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" | grep -e dn -e msDS-AllowedToDelegateTo

如图所示，使用ldapsearch查询出域中配置了约束性委派的主机有win7，配置了非约束性委派的服务账号有service_account，并且查询出他们委派的服务的SPN。

利用adfind执行如下命令过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性，即可查询出域内配置了基于资源的约束性委派的主机和服务账号。使用adfind查询出来的msDS-AllowedToActOnBehalfOfOtherIdentity值，用 {Security Descriptor}代替了，这个值包含了允许被委派的服务账号或机器账号的SID。

#查询域中配置基于资源的约束性委派的主机 AdFind.exe -b "DC=xie,DC=com" -f "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity#查询域中配置基于资源的约束性委派的服务账户 AdFind.exe -b "DC=xie,DC=com" -f "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity

如图所示，使用adfind查询出域中配置了基于资源的约束性委派的主机有win7，配置了基于资源的约束性委派的服务账号有krbtgt。

利用ldapsearch执行如下命令过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性，即可查询出域内配置了基于资源的约束性委派的主机和服务账号。

#查询域中配置基于资源的约束性委派的主机 ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn#查询域中配置基于资源的约束性委派的服务账户 ldapsearch -x -H ldap://10.211.55.4:389 -D "[email protected]" -w P@ss1234 -b "DC=xie,DC=com" "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn

如图所示，使用ldapsearch查询出域中配置了基于资源的约束性委派的主机有win7，配置了基于资源的约束性委派的服务账号有krbtgt。

通过使用Empire下的 powerview.ps1 脚本查看服务账号或机器账号的属性，来查看某账号是否具有委派属性。

Import-Module .powerview.ps1; #查看非约束性委派和约束性委派Get-DomainUser 域用户名 -Properties  useraccountcontrol,msds-allowedtodelegateto | flGet-DomainComputer 机器用户名 -Properties  useraccountcontrol,msds-allowedtodelegateto | fl#查看基于资源的约束性委派Get-DomainUser 域用户名 -Properties msDS-AllowedToActOnBehalfOfOtherIdentityGet-DomainComputer 机器用户名 -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

当该账号没委派属性时，只有userAccountControl属性有值。

• 服务账号的值为：NORMAL_ACCOUNT

• 机器账号的值为：WORKSTATION_TRUST_ACCOUNT

如图所示，可以看到没配置委派属性的服务账号的userAccountControl属性只有NORMAL_ACCOUNT，没配置委派属性的机器账号的userAccountControl属性只有WORKSTATION_TRUST_ACCOUNT。

如图所示，当账号被设置为 非约束性委派 时，其userAccountControl属性会包含为 TRUSTED_FOR_DELEGATION。

如图所示，当账号被设置为 约束性委派 时，其userAccountControl属性包含 [TRUSTED_TO_AUTH_FOR_DELEGATION](https://msdn.microsoft.com/en-us/library/aa772300(v=vs.85).aspx)，且 msds-allowedtodelegateto 属性会被设置为哪些 SPN。

如图所示，当账号被设置为 基于资源的约束性委派时，其msDS-AllowedToActOnBehalfOfOtherIdentity属性会有被允许委派账号的SID。

以下是实验环境：

• 域控：AD01(10.211.55.4)

• 域成员主机：Win7(10.211.55.6)  Server2012(10.211.55.9)

• 域管理员：test  administrator

• 域普通用户：hack

• 域：xie.com

非约束性委派攻击可以利用服务账号和主机账号，因为只有服务账号和主机账号具有委派属性。域用户账号注册SPN之后就成为了服务账号，主机账号的话我们可以手动去创建。

如图所示，在域控上配置主机win7具有非约束性委派属性。

查看域内非约束性委派的主机账号，如图所示，可以看到有Win7机器。

注：默认域控制器配置了非约束性委派。

在win7上访问域控，提示拒绝访问。如图所示：

此时我们用域管理员 test 身份远程访问 win7 机器，这里test登录在域内任何一台机器均可，不一定非得是域控。或者也可以使用ipc连接，如下：

如图域管理员test远程连接win7机器。

此时，在主机win7的lsass.exe内存中就会有域管理员test的TGT认购权证。我们在win7上以管理员权限运行mimikatz，执行以下命令导出内存中的票据：

privilege::debug  #导出票据 sekurlsa::tickets /export

如图所示，使用mimikatz导出内存中的票据：

可以看到会生成一个 test@krbtgt 的票据，如图所示：

然后我们用 mimikatz 执行如下命令将这个票据导入内存中。

#导入票据 kerberos::ptt [0;58cdc]-2-0-60a10000-test@krbtgt-XIE.COM.kirbi#查看票据 kerberos::list

如图所示，使用mimikatz将票据导入内存中，然后访问域控，可以看到导入票据后成功访问域控。

上面的攻击手段，还需要域管理员主动连接配置了非约束性委派的主机，才能从该主机上抓到域管理员的TGT认购权证，实战中意义不大。于是，我们可以利用打印机服务漏洞来强制域控连接配置了非约束性委派的主机，也能从该主机上抓到域控机器用户的TGT认购权证，且不需要管理员交互！

在win7上以管理员权限用Rubeus执行如下命令每隔一秒监听一次来自AD01主机的票据。

如图所示，使用Rubeus监听AD01主机的票据。

然后在Win7上执行如下命令使用打印机服务漏洞攻击域控AD01，使其强制回连认证我们的win7主机。

如图所示，使用打印机服务漏洞攻击域控AD01。

如图所示，可以看到我们的Rubeus已经收到来自AD01的base64的TGT认购权证了。

然后我们可以直接使用Rubeus执行如下命令导入这个base64的TGT认购权证，就可以使用mimikatz导出域内所有用户hash了。

Rubeus导入票据后，就可以导出域内用户hash了。如图所示：

或者也可以使用mimikatz执行如下命令，导出内存中的票据，导出后的票据后缀为.kirbi，然后使用mimikatz直接导入这个.kirbi票据，再导出域内用户hash。

privilege::debug#导出票据sekurlsa::tickets /export#导入票据 kerberos::ptt [0;21467]-2-1-60a10000-AD01$@krbtgt-XIE.COM.kirbi#导出域内所有用户hashlsadump::dcsync /all /csv

如图所示，导出内次中的票据。

然后再使用mimikatz导出票据，即可导出域内用户哈希了。如图所示：

注：域控机器用户不能用于登录，但是有Dcsync权限，所以可以用于导出域内用户哈希。

以下是实验环境：

• 域控：AD01 (10.211.55.4)

• 域成员主机：Win7 (10.211.55.6)

• 域管理员：test

• 服务账号：hack

• 域：xie.com

攻击流程：

1）服务账号hack使用自己的账号密码向KDC申请一个可转发的TGT认购权证，注意在KDC Option里面选择forwardable标志位，这样的话请求的TGT认购权证就是可转发的。

2）服务账号hack以域管理员test身份申请一个针对自身服务的ST服务票据(这一步就是S4U2Self)，这一步生成的ST服务票据是可转发的。

3）服务账号hack拿着上一步可转发的ST服务票据以域管理员test身份向KDC申请访问特定服务(cifs/ad01.xie.com)的ST服务票据(S4U2Proxy)。

4）导入上一步获得的以域管理员test身份访问特定服务(cifs/ad01.xie.com)的ST服务票据，即可成功访问域控。

约束性委派攻击可以利用服务账号和主机账号，因为只有服务账号和主机账号具有委派属性。域用户账号注册SPN之后就成为了服务账号。主机账号的话我们可以手动去创建。

我们将域用户 hack 执行如下命令注册为某个SPN的服务账号。

#将域用户hack注册为SPN SQLServer/win7.xie.com:1434 的服务账号，只有机器账号和域管理员账号有权限 setspn -U -A SQLServer/win7.xie.com:1434 hack#查找指定hack用户注册的SPN setspn -L hack 

如图所示，给hack用户注册SPN。

或者创建一个机器账号hack2也可以，如图所示。

这里我们使用hack服务账号来配置约束性委派属性。在域控上修改用户hack的委派属性为约束性委派，协议为域控AD01的CIFS协议，如图所示：

此时我们拿到了域内一台主机 Win7 的权限，该主机当前登录着xiehack用户，抓取到其密码为P@ss1234，然后通过adfind执行如下命令查询发现hack用户被赋予了约束性委派，并且委派的SPN是 cifs/AD01.xie.com。

#查询域中配置了约束性委派的服务账户，并可以看到被委派的SPNAdFind.exe -b "DC=xie,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" -dn

如图所示，可以看到查询出hack用户被赋予了约束性委派，并且委派的SPN是 cifs/AD01.xie.com。

然后我们就可以进行约束性委派攻击了，如下我们使用impacket和Rubeus进行约束性委派攻击。

首先，需要把攻击机的/etc/resolv.conf文件中的DNS服务器指定为域控。然后执行如下命令进行攻击：

如图所示，可以看到执行完这些命令后，即可远程连接域控制器AD01。

如果出现如图所示报错，则是因为给hack用户配置委派的时候，选择的是仅使用Kerberos(K) ，如图4-131所示，这样的话就不会进行协议转化，所以报错。

我们也可以在 Win7 上使用kekeo执行如下命令生成ST服务票据：

#使用hack账号申请一个TGT认购权证tgt::ask /user:hack /domain:xie.com /password:P@ss1234#使用上一步的TGT认购权证，利用S4U协议，以[email protected]用户权限申请一张访问cifs/AD01.xie.com服务的ST服务票据tgs::s4u /tgt:[email protected][email protected] /user:test@xie.com /service:cifs/AD01.xie.com

如图所示，使用kekeo进行约束性委派攻击，其会生成三个票据。

然后使用 mimikatz 执行如下命令将最后的s4u2proxy步骤生成的ST服务票据导入内存中，即可访问域控的CIFS服务。

如图所示，使用mimikatz将票据导入内存中后，即可远程访问域控。

下面我们对约束性委派攻击进行抓包分析。

在进行约束性委派攻击时，使用WireShark进行抓包，如图所示，一共有6个包。

前面两个AS-REQ&AS-REP数据包，就是以服务账号 hack 的身份向域控请求可转发的TGT认购权证。对应的就是第一条命令。

后面四个TGS-REQ&TGS-REP的数据包对应的就是第二条命令。使用第一步获取到的可转发的TGT认购权证向域控申请具有指定用户(test)权限访问指定服务(cifs/AD01.xie.com)的ST服务票据。

 1）AS-REQ

如图所示，是第一个AS-REQ请求包，以 hack 用户身份向KDC请求可转发的TGT认购权证。

2）AS-REP

如图所示，是第二个AS-REP回复包，KDC返回可转发的TGT认购权证，也就是 [email protected][email protected]。

 3）TGS-REQ

如图所示，是第三个TGS-REQ请求包，需要用到上一步得到的TGT认购权证，以test的身份向TGS服务申请了一张访问自身服务(hack服务账号所在的服务)的ST票据，这一步对于的就是S4U2Self。

 4）TGS-REP

如图所示，是第四个TGS-REP回复包，KDC返回了test用户访问自身服务(hack服务账号所在的服务)的 可转发ST服务票据，服务端为hack，也就是 [email protected]@[email protected]。

5）TGS-REQ

如图所示，是第五个TGS-REQ请求包，hack得到[email protected]@[email protected]票据后，会在TGS-REQ的 additional-tickets 处带上该票据，再次向KDC发起S4U2Proxy请求，以test的名义请求一张访问域控AD01 CIFS服务的票据。这一步对应的就是S4U2Proxy。

6）TGS-REP

如图所示，是第六个TGS-REP回复包，就是KDC返回的以test身份访问域控AD01的CIFS服务的ST票据[email protected]@[email protected]。

以下是实验环境：

• 域控：AD01 (10.211.55.4)

• 域成员主机：Win2008 (10.211.55.7)

• 域管理员：hack

• 域管理员：administrator

• 域：xie.com

如图所示，这里我们已经拿到了域内一台主机 (win2008) 的普通域账号权限（xiehack），但是该域用户不在win2008的管理员组中，因此我们无法执行mimikatz等高权限操作。现在我们需要利用基于资源的约束委派进行本地提权，拿到win2008主机的system权限。

如图所示，通过LDAP协议查询域内机器账号的创建者，我们发现，机器 win2008.xie.com 的创建者为 hack用户，也就是当前登录的用户。

于是我们可以通过创建一个机器账号machine，然后配置新建的机器账号machine到win2008机器的基于资源的约束性委派。详细配置如图所示：

如图所示，可以看到基于资源的约束性委派配置成功！

首先，需要把攻击机的/etc/resolv.conf文件中的DNS服务器指定为域控。然后执行如下命令进行攻击：

如图所示，可以看到执行完这些命令后，成功获得win2008机器的System权限。

下面我们对约束性委派攻击进行抓包分析。

在进行基于资源的约束性委派攻击时，使用WireShark进行抓包，如图所示，一共有6个包。

前面两个AS-REQ&AS-REP数据包，就是以机器账号 machine 的身份向域控请求可转发的TGT票据。

后面四个是TGS-REQ&TGS-REP的数据包，使用第一步获取到的可转发的TGT认购权证以administrator身份通过S4u2Self协议访问自身，获取到不可转发的ST服务票据。然后再通过此不可转发的ST服务票据，以administrator身份通过以S4u2Proxy协议申请访问指定服务(cifs/win2008.xie.com)的可转发ST服务票据。

 1）AS-REQ

如图所示，是第一个AS-REQ请求包，以机器账号machine用户身份向KDC请求可转发的TGT票据。

2）AS-REP

如图所示，是第二个AS-REP回复包，KDC返回可转发的TGT认购权证。

 3）TGS-REQ

如图所示，是第三个TGS-REQ请求包，这一步就是S4U2Self阶段，机器账号machine以administrator身份访问自身服务。

 4）TGS-REP

如图所示，是第四个TGS-REP回复包，这里KDC返回不可转发的ST服务票据。但是在基于资源的约束性委派流程中，不可转发的ST服务票据也是可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后服务还会返回一张可转发的ST服务票据！

5）TGS-REQ

如图所示，是第五个TGS-REQ请求包，这一步就是S4U2Proxy阶段，机器账号machine以administrator身份申请cifs/win2008.xie.com服务的ST服务票据，带着上一步获取到的不可转发的ST服务票据放在additional_tickets里面。

6）TGS-REP

如图所示，是第六个TGS-REP回复包，KDC返回以administrator身份访问cifs/win2008.xie.com服务的ST服务票据。