酒店网站的开发及其设计方案/百度推广区域代理

【内网渗透】——S4u2扩展协议提权以及KDC欺骗提权

---

文章目录

• 【内网渗透】——S4u2扩展协议提权以及KDC欺骗提权
• • @[toc]
  • 一：Kerberos 委派攻击原理之 S4U2利用
  • • 1.1原理
    • 1.2两种扩展协议
    • • **S4U2Self (Service for User to Self)**
      • **S4U2Proxy (Service for User to Proxy)**
    • 1.3 S4U2Self利用过程
    • • 1.3.1前提条件
      • 1.3.2利用步骤
    • 1.4S4U2Proxy利用过程
    • • 1.4.1利用前提条件
      • 1.4.2详细利用步骤(Rubeus)
    • 1.5：**基于资源的约束委派(RBCD)利用**
  • 二：CVE-2021-42278-Name impersonation&CVE-2021-42287-KDC bamboozling漏洞复现
  • • 2.1概念说明
    • 2.2漏洞复现
    • • （1）noPac 利用
      • （2）手动注入分析
  • **修改计算机账户的 `sAMAccountName`（推荐）**

一：Kerberos 委派攻击原理之 S4U2利用

1.1原理

S4U2Self（Service For User to Self）是 Kerberos 协议的一种委托机制，允许服务（Service）代表用户（User）自身获取用户的票证（Ticket）。这个机制在 Windows 环境中广泛应用于网络服务和应用程序，以便在用户访问需要身份验证的资源时，能够以用户的身份获取必要的票证，而无需用户交互地提供凭证。正因有了委托机制才使得攻击者以某个合法用户的身份请求特定服务的票证，然后利用漏洞伪造这些票证，从而获取到更高的权限。

当 Kerberos 无约束委派在服务器上启用，服务器托管了在 TGS-REQ (步骤3)中引用的服务主体名称中指定的服务时，DC 域控制器将用户 TGT 的一个副本放到服务票证中。 当向服务器提供用户的服务票证(TGS)以进行服务访问时，服务器打开 TGS 并将用户的 TGT 放入 LSASS 中供后续使用。 此时，应用程序服务器就可以无限制地假冒该用户

1.2两种扩展协议

S4U2Self (Service for User to Self)

用途

允许服务代表用户获取 该用户自己的服务票据（ST），而无需用户密码或交互。
典型场景：

• 用户通过非Kerberos方式（如表单认证）登录后，服务需获取用户的Kerberos票据。
• 约束委派/无约束委派攻击中模拟用户身份。

关键特性

• 无需用户密码：服务使用自己的TGT请求用户的ST。
• 票据加密：返回的ST使用 服务账户的密钥 加密（而非用户的）。
• 权限要求：服务账户需配置 “TrustedToAuthForDelegation”（无约束委派）或约束委派权限。

请求流程

1. 服务向KDC发送请求，包含：
   • 服务账户的TGT
   • 目标用户的UPN（如user@domain.com）
   • 目标SPN（如http/service.domain.com）
2. KDC返回加密的ST（可被服务解密使用）。

S4U2Proxy (Service for User to Proxy)

用途

允许服务在已获得用户授权后，代表用户获取 其他服务的票据（跨服务委派）。
典型场景：

• 三层应用架构中（如Web→DB），Web服务代表用户访问DB服务。
• 约束委派攻击中横向移动。

关键特性

• 需用户授权：需先通过S4U2Self获取用户的ST（作为"证据"）。
• 约束限制：仅能委派到 msDS-AllowedToDelegateTo 中指定的服务。
• 票据转发：最终ST仍以用户身份加密，但由服务代理请求。

请求流程

1. 服务通过S4U2Self获取用户的ST（如user→http/service）。
2. 服务向KDC发送请求，包含：
   • 服务账户的TGT
   • 用户的ST（作为授权证据）
   • 目标SPN（如cifs/db.domain.com）
3. KDC返回用户对目标服务的ST（如user→cifs/db）。

1.3 S4U2Self利用过程

1.3.1前提条件

• 需要拥有一个具有 SPN (Service Principal Name) 的服务账户

  

• 该服务账户需要被授予 “TrustedToAuthForDelegation” 权限

  

1.3.2利用步骤

(1)获取服务账户凭据

• 通过密码、哈希或 Kerberos 票据获取服务账户的访问权限

(2)请求 S4U2Self 票据

• 使用服务账户的 TGT (Ticket Granting Ticket)
• 为目标用户请求服务票据，指定服务账户的 SPN
• 使用 KRB_TGS_REQ 请求，包含 PA-FOR-USER 结构

①处理响应

• 接收 KDC 返回的服务票据
• 票据将加密为服务账户的密钥，而不是目标用户的密钥

②使用票据

• 可以使用该票据访问目标服务
• 服务会认为请求来自目标用户

可以获得访问权限

1.4S4U2Proxy利用过程

1.4.1利用前提条件

• 服务账户：拥有SPN的账户
• 约束委派权限：
  • 账户配置了msDS-AllowedToDelegateTo属性
  • 可以委派到指定的服务(如CIFS、LDAP等)
• 有效的TGT：服务账户的Kerberos票据
• 用户授权：
  • 需要用户的TGS(传统约束委派)
  • 或配置了基于资源的约束委派(Resource-based Constrained Delegation)

1.4.2详细利用步骤(Rubeus)

（1） 识别具有约束委派权限的账户

使用PowerShell或ldapsearch查询域中配置了约束委派的账户

（2）获取服务账户的TGT

使用已获取的服务账户凭据请求TGT

（3）执行S4U2Proxy攻击

（4）使用获取的票据

如果使用了/ptt参数，票据会自动注入当前会话。否则可以手动注入，然后可以使用该票据访问目标服务。

1.5：基于资源的约束委派(RBCD)利用

当配置了基于资源的约束委派时：

(1) 检查目标计算机的msDS-AllowedToActOnBehalfOfOtherIdentity

Get-NetComputer dc01 | Select-Object -Property msDS-AllowedToActOnBehalfOfOtherIdentity

(2) 配置新的委派关系

$comp = Get-ADComputer dc01
$sid = (Get-ADComputer attackercomputer).SID
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($sid))"
$SDbytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDbytes,0)
Set-ADComputer dc01 -Replace @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$SDbytes}

(3) 执行完整的S4U攻击链

Rubeus.exe s4u /user:attackercomputer$ /rc4:<NTLM> /impersonateuser:Administrator /msdsspn:cifs/dc01 /altservice:http /ptt

二：CVE-2021-42278-Name impersonation&CVE-2021-42287-KDC bamboozling漏洞复现

2.1概念说明

机器账户的名字一般来说应该以$结尾，但AD没有对域内机器账户名做验证。

创建与DC机器账户名字相同的机器账户（不以$结尾），账户请求一个TGT后，更名账户，然后通过S4U2self申请TGS Ticket，接着DC在TGS_REP阶段，这个账户不存在的时候，DC会使用自己的密钥加密TGS Ticket，提供一个属于该账户的PAC，然后我们就得到了一个高权限ST。过程如上图所示。

允许攻击者任意修改计算机帐户sAMAccountName字段，进而模拟域控申请票据。

加入域的机器账户默认由结尾，samAccountName默认和域机器名一致。但DC没有对sAMAccountName属性进行合法性判断，导致删除sAMAccountName结尾的$"照样可以以机器用户身份申请TGT票据。

配合 CVE-2021-42278 使用，创建与域控机器账户名字相同的机器账户（不以$结尾），账户请求一个TGT后，更名账户，然后通过S4U2self 申请TGS Ticket，接着域控在 TGS_REP 阶段，这个账户不存在的时候，DC会使用自己的密钥加密 TGS Ticket ，提供一个属于该账户的 PAC，然后我们就得到了一个高权限ST。

2.2漏洞复现

域控

域名：test.com
账户：administrator
密码：QAX@123
计算机名：WIN-ISB0SNPKEPI

普通域用户

账户：s4u2
密码：QAX@123

（1）noPac 利用

检查是否存在漏洞

noPac.exe scan -domain test.com -user s4u2 -pass QAX@123

noPac.exe -domain test.com -user s4u2 -pass QAX@123 /dc WIN-ISB0SNPKEPI.test.com /mAccount demohb /mPassword QAX@123 /service cifs /ptt

[!NOTE]

参数 说明
-domain htb.local 目标域名。
-user domain_user 普通域用户账号（需具备创建计算机账户的权限）。
-pass ‘Password123!’ 对应用户的密码。
/dc dc02.htb.local 指定域控制器的主机名。
/mAccount demo123 攻击者创建的恶意计算机账户名称（用于名称伪装）。
/mPassword Password123! 恶意计算机账户的密码。
/service cifs 目标服务（通常为 cifs 以访问文件共享）。
/ptt 将生成的票据注入当前会话（Pass-the-Ticket）。

获得票据信息以及访问权限：

（2）手动注入分析

具体流程：

1. 首先创建一个机器账户，可以使用 impacket 的 addcomputer.py或是powermad

   addcomputer.py是利用SAMR协议创建机器账户，这个方法所创建的机器账户没有SPN，所以可以不用清除

2. 清除机器账户的servicePrincipalName属性

3. 将机器账户的sAMAccountName，更改为DC的机器账户名字，注意后缀不带$

4. 为机器账户请求TGT

5. 将机器账户的sAMAccountName更改为其他名字，不与步骤3重复即可

6. 通过S4U2self协议向DC请求ST

7. 进行 DCsync Attack

普通域账户：s4u2用户是一个普通的域用户：

新增机器账户:域用户默认可以新建10个机器账户

清除SPN信息

重设机器名称

[!NOTE]

修改计算机账户的 sAMAccountName（推荐）

适用场景：

• 你希望计算机账户在 AD 中显示不带 $ 的名称（但实际 Kerberos 认证仍会使用 COMPUTERNAME$）

步骤：

1. 打开 Active Directory 用户和计算机（dsa.msc）
2. 找到目标计算机账户（默认在 Computers 容器或自定义 OU）
3. 右键 → 属性 → 属性编辑器
   • 找到 sAMAccountName，默认值类似 COMPUTERNAME$
   • 修改为不带 $ 的名称（如 COMPUTERNAME）
4. 点击确定保存

注意：

• 修改后，该计算机仍然需要使用 COMPUTERNAME$ 进行 Kerberos 认证（$ 是系统必需的）。
• 只是 sAMAccountName 显示变化，不影响实际功能。

修改计算机的名字

可以看到已经修改完成了

Request TGT （请求TGT）

./Rubeus.exe asktgt /user:demo1 /password:QAX@123 /domian:test.com /dc:WIN-ISB0SNPKEPI.test.com /nowrap

[!NOTE]

参数	值	说明
/user	Demo1	目标计算机账户
/password	QAX@123	计算机账户的密码（可能无效）
/domain	test.com	目标域名
/dc	WIN-ISB0SNPKEPI.test.com	域控制器主机名（需确保可解析）
/nowrap	-	输出票据不换行

Request S4U2self（获取票据）