企业官网建设流程全解析

🔒免责声明：本文仅供授权渗透测试、红蓝对抗、安全运维学习，全部实验操作请在自建隔离靶场完成。未经授权对 Active Directory 域环境进行凭证复用、内网渗透属于违法行为，请严格遵守网络安全相关法律法规。

前言

Overpass‑the‑Hash（简称 OTH，也被称为 Pass‑the‑Key PtK，密钥传递）是域红队横向移动中极其重要的技术，也是很多学习域渗透同学的难点。传统 PtH（哈希传递）依赖 NTLM 协议；而 OTH 攻击拿到账号 NTLM/AES 密钥，向域控 KDC申请一张真实合法的 TGT 票据，后续全程走 Kerberos 认证，不再产生 NTLM 流量。

在很多生产环境中，域管理员会通过组策略关闭 NTLM 协议，传统 PtH 哈希传递直接失效，但是 Kerberos 协议还必须保留，此时 Overpass‑the‑Hash 就成为横向移动的核心手段。

很多人跟着教程复现的时候会遇到大量问题：执行命令不报错，但是拿不到 TGT；返回KDC_ERR_PREAUTH_FAILED预认证失败；KDC_ERR_ETYPE_NOSUPP加密类型不支持；拿到 TGT 但是访问域资源依旧拒绝访问；beacon 里面执行 OTH 直接失败；明明靶场成功，真实护网环境完全无法利用。

网上绝大多数教程只给出成功的演示命令，很少完整梳理报错、失败场景、底层限制。本文万字长文，从 Kerberos 预认证底层原理讲起，完整拆解 Overpass‑the‑Hash 攻击流程、mimikatz 与 Rubeus 实战用法、各类报错根因、完整排错工作流、双跳问题、OPSEC 红蓝对抗注意事项，同时对比 PtH / OTH / 黄金票据 / 白银票据的差异，最后补充蓝队检测方案。适合内网渗透学习者、红队人员、护网应急工程师阅读。

前置基础概念

1. OTH 不是伪造票据！OTH 向真实 KDC 申请合法 TGT 票据，和黄金票据离线伪造 TGT 有本质区别。
2. OTH 分为两种模式：RC4 模式（传入 NTLM Hash）、AES 模式（传入 AES128/AES256 密钥，也叫 Pass‑the‑Key）。现代域环境优先 AES 模式，隐蔽性更高，告警更少。
3. OTH 攻击必须能够连通域控的 88 端口（TCP/UDP），需要 DNS 正常解析域控 FQDN。

mimikatz 标准 OTH 命令：

privilege::debug sekurlsa::pth /user:administrator /domain:lab.local /ntlm:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /run:cmd.exe

AES 模式：

sekurlsa::pth /user:administrator /domain:lab.local /aes256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /run:cmd.exe

Rubeus 标准 OTH 命令（实战红队更常用）：

Rubeus.exe asktgt /user:administrator /domain:lab.local /rc4:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /ptt

AES 模式：

Rubeus.exe asktgt /user:administrator /domain:lab.local /aes256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /ptt

一、Kerberos 预认证与 Overpass‑the‑Hash 底层原理

想要彻底排错，必须理解 Kerberos AS‑REQ 预认证机制，OTH 攻击就是滥用预认证流程。

1.1 正常用户获取 TGT 流程

1. 用户输入账号密码，客户端根据密码计算 RC4/AES 密钥；
2. 构造 AS‑REQ 请求，使用用户密钥加密时间戳（预认证数据 PA‑DATA）；
3. 将 AS‑REQ 发送域控 KDC（88 端口）；
4. KDC 拿到请求，取出用户数据库内保存的密钥，解密预认证时间戳；
5. 如果解密成功、时间校验通过，KDC 认为身份合法，返回 TGT 票据（AS‑REP）；
6. 客户端拿到 TGT，存入 LSA 票据缓存，后续使用 TGT 向 KDC 申请 TGS 访问域内资源。

预认证作用：防止攻击者向 KDC 发送 AS‑REQ，暴力枚举加密 AS‑REP 密文（对应 Kerberoasting 烤土豆攻击）。绝大多数域账号默认开启预认证。

1.2 Overpass‑the‑Hash 攻击完整流程

攻击者已经拿到域账号凭证（NTLM 哈希或者 AES 密钥，从 LSASS 内存 dump、NTDS.dit 导出得到），不需要明文密码。

1. 攻击者使用窃取到的 NTLM‑Hash，计算出 RC4‑HMAC 密钥，或者直接拿到 AES256 密钥；
2. 构造 Kerberos 预认证 PA‑DATA，用窃取的密钥加密客户端本机时间戳；
3. 发送 AS‑REQ 请求到域控 KDC 88 端口；
4. KDC 读取 AD 数据库中该账号对应的密钥，解密预认证数据包；
5. 解密校验成功，KDC 返回合法真实的 TGT 票据；
6. 将 TGT 注入当前进程 LSA 缓存；
7. 后续访问域内机器 SMB、LDAP、WinRM 全部走 Kerberos 认证，不会产生 NTLM 流量。

关键点区分：

• PtH 哈希传递：走 NTLM 认证协议；NTLM 被禁用就直接失效；
• Overpass‑the‑Hash：走 Kerberos 预认证，拿到真实 TGT；NTLM 关闭依旧可以横向移动；
• 黄金票据：KRBTGT 密钥离线伪造 TGT，不向 KDC 发送 AS‑REQ；
• OTH：向真实 KDC 发送 AS‑REQ，域控日志产生 4768 事件（TGT 请求）。

1.3 RC4 模式与 Pass‑the‑Key (AES 模式) 的区别

重要：很多新手踩坑，直接拿 NTLM 哈希尝试 AES 参数，必然报错。NTLM 哈希 ≠ AES256 密钥，二者不能混用，必须从 DCSync、dump LSASS 拿到对应字段。

1.4 OTH 攻击的权限边界

1. OTH 拿到的 TGT 权限，完全取决于你使用的域账号本身权限；
2. 如果是域管理员账号，拿到 TGT 后可以访问域控、任意域内主机；普通域用户只能拥有普通账号权限；
3. OTH 获取 TGT 之后，天然支持 Kerberos 双跳，这点优于白银票据；但是会受到账号 “敏感账户，不能被委派” 属性限制。

1.5 PtH、OTH、黄金票据、白银票据横向技术对比

二、mimikatz 与 Rubeus 实战完整操作演示

2.1 mimikatz sekurlsa::pth 实现 Overpass‑the‑Hash

sekurlsa::pth 是 mimikatz 实现 OTH 的核心模块。注意：该模块需要 debug 权限，需要管理员权限运行 mimikatz。

RC4‑NTLM 模式：

mimikatz.exe privilege::debug sekurlsa::pth /user:administrator /domain:lab.local /ntlm:644f1283c5926093a79012345678abcd /run:cmd.exe

执行成功后，会弹出一个全新 cmd 窗口，该窗口进程内存缓存中已经存在目标账号的 TGT 票据。
在新弹出的 cmd 执行 klist，查看 TGT 票据。

坑：不要关闭这个弹出的 cmd，票据属于该进程，新开窗口票据消失。

AES‑256 Pass‑the‑Key 模式：

privilege::debug sekurlsa::pth /user:administrator /domain:lab.local /aes256:E10ABC1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890 /run:powershell.exe

常见参数解释：

• /user：域账号用户名，不要写 FQDN，只写账号名；
• /domain：完整域名 lab.local；
• /ntlm：账号 NTLM 哈希（32 位十六进制字符串）；
• /aes256：账号 AES‑256 密钥；
• /run：执行程序，把票据注入新生成进程；

mimikatz 坑：sekurlsa::pth 内部会自动完成向 KDC 请求 TGT，不是注入现成票据。如果 88 端口不通，命令直接失败，不会生成票据。

2.2 Rubeus asktgt 实现 OTH（红队实战首选，CobaltStrike 常用）

Rubeus 不需要 debug 权限，不需要操作 LSASS，在 beacon 内存加载直接运行，红队对抗 EDR 更友好。

RC4 模式请求 TGT 并且 ptt 注入内存：

Rubeus.exe asktgt /user:administrator /domain:lab.local /rc4:644f1283c5926093a79012345678abcd /ptt

AES256 Pass‑the‑Key 模式：

Rubeus.exe asktgt /user:administrator /domain:lab.local /aes256:E10ABC1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890 /ptt

附加参数：

• /nowrap：base64 输出票据，不换行，可以导出票据字符串；
• /ptt：获取 TGT 之后直接 Pass‑the‑Ticket 注入当前进程缓存；
• /dc:指定域控 IP，DNS 异常的时候手动指定 KDC 地址。

执行成功，输出会打印 TGT 票据信息，TGT 有效时间。执行 klist 可以看到 TGT。

实战技巧：如果 beacon 里面运行 Rubeus asktgt 成功拿到 TGT，票据仅存在 beacon 进程；spawn 新的 powershell 进程不会继承票据，需要使用 createnetonly 创建子进程。

2.3 Impacket 在 Linux 环境下实现 Overpass‑the‑Hash

红队从 Linux 横向 Windows 域，也可以执行 OTH，使用 getTGT 脚本：

python3 getTGT.py lab.local/administrator‑hashes:00000000000000000000000000000000:644f1283c5926093a79012345678abcd

执行完成后输出 ccache 票据文件，设置环境变量后使用 Kerberos 协议访问 SMB、WMI 等服务。

三、高频踩坑一：KDC_ERR_PREAUTH_FAILED 预认证失败（最高频报错）

现象

执行 OTH 命令，返回KDC_ERR_PREAUTH_FAILED (24)，无法获取 TGT 票据。

根因集合

1. 哈希 / 密钥错误：NTLM 哈希复制错误，存在空格换行；AES256 密钥复制错误；RC4 和 AES 参数混用，拿 NTLM 哈希填入 /aes256 参数，100% 报预认证失败。
2. 账号名、域名写错；区分大小写问题；填写机器账号时末尾需要带$符号，例如webserver$。
3. AD 账号状态异常：账号被禁用、账号锁定过期、密码过期。即使你拥有正确哈希，账号本身不可用，KDC 拒绝预认证。
4. 拿到的是本地账号哈希，不是域账号哈希，却传入域参数。

排错步骤

1. 重新导出凭证，DCSync 导出该账号完整凭证，核对 NTLM、AES256；

lsadump::dcsync /domain:lab.local /user:administrator

2. 确认账号状态，在 AD 用户计算机查看账号是否启用，是否锁定，密码是否过期；
3. RC4 哈希填入/rc4或者/ntlm；AES256 密钥必须填入/aes256，严禁交叉混用。
4. 机器账号结尾必须带上$符号。

解决方案

复制凭证的时候去除多余空格换行；确认账号处于正常启用状态；区分 RC4/AES 两套凭证。

四、高频踩坑二：KDC_ERR_ETYPE_NOSUPP 加密类型不支持

现象

报错KDC_ERR_ETYPE_NOSUPP，KDC 不支持该加密类型，无法下发 TGT。

根因

域组策略网络安全：配置 Kerberos 支持的加密类型禁用 RC4‑HMAC 加密套件，但是你依旧使用 NTLM 哈希 RC4 模式执行 OTH 攻击。域 KDC 拒绝 RC4 类型的预认证请求，直接返回加密类型不支持。

Windows Server2019/2022 新建域，很多运维默认关闭 RC4，只保留 AES128‑256。此时传统/ntlmRC4 模式 OTH 直接失效。

很多新手疑惑：靶场一切正常，真实护网环境直接报错，绝大多数是这个原因。

排错与解决方案

1. 查看域组策略确认 Kerberos 支持加密套件；
2. 不要再使用 RC4‑NTLM 模式，改用 Pass‑the‑Key AES256 模式；
3. DCSync 导出账号的 AES‑256 密钥，使用/aes256参数执行 OTH 攻击。

实战 OPSEC 建议：红蓝对抗中，只要可以拿到 AES 密钥，优先 AES 模式，既解决加密类型不支持报错，又降低安全设备告警概率。

五、高频踩坑三：KRB_AP_ERR_SKEW 时钟时间偏移

现象

部分情况下获取 TGT 成功，但是申请 TGS 访问资源失败，返回时钟偏移；或者直接 AS‑REQ 请求被拒绝，时钟偏差。报错KRB_AP_ERR_SKEW。

根因

Kerberos 协议 RFC 规范，客户端与域控 KDC 时间差最大允许5 分钟，超过时间窗口 KDC 直接拒绝请求，防止重放攻击。
虚拟机快照恢复、虚拟机休眠，本机系统时间和域控时间差距十几分钟，OTH 直接失败。

注意：OTH 是向真实 KDC 请求票据，时间校验非常严格，这点和黄金票据、白银票据一样。

解决方案

Windows 靶机同步域控时间：

w32tm /resync

Linux 环境：

ntpdate dc01.lab.local

同步完成之后，再执行 OTH 攻击。

六、高频踩坑四：网络层面问题：88 端口不通、DNS 解析异常

现象

执行 OTH 命令直接超时，无法向 KDC 发送 AS‑REQ 请求，没有返回任何 Kerberos 错误码。

根因

OTH 攻击必须访问域控 TCP/UDP 88 端口（Kerberos KDC）。很多新手混淆 OTH 和伪造票据，以为不需要域控网络。

1. 防火墙、安全组拦截本机到域控 88 端口，UDP 丢包也会直接失败；
2. DNS 解析故障，域名无法解析到域控 IP；
3. hosts 配置错误，域名解析指向错误 IP；

mimikatz sekurlsa::pth 内部会自动解析域名找 KDC；DNS 异常可以在 Rubeus 使用/dc:192.168.10.10手动指定域控 IP 绕过 DNS 解析问题。

排错测试连通性 PowerShell：

Test‑NetConnection dc01.lab.local -port 88

DNS 排错：

nslookup dc01.lab.local

解决方案

确认 88 端口 TCP/UDP 双向可达；修复 DNS，或者 Rubeus 指定/dc:域控IP参数。

七、高频踩坑五：拿到 TGT 票据，klist 可见，但是访问域资源拒绝访问

现象

OTH 攻击成功，klist 查看进程内存中已经有合法 TGT 票据；但是访问\\dc01.lab.local\c$返回拒绝访问。

这里细分多个根因：

7.1 使用 IP 访问资源，强制回退 NTLM

和黄金票据、白银票据踩坑完全一致：

使用 IP 访问 SMB 共享，客户端不会使用 Kerberos TGT 票据，直接回退 NTLM 认证，TGT 完全不生效。

错误写法：

dir \\192.168.10.10\c$

正确写法，使用 FQDN 主机名访问：

dir \\dc01.lab.local\c$

7.2 账号开启 “此账号是敏感账户，不能被委派”

域账号属性勾选此账号是敏感账户，不能被委派。即使拿到合法 TGT，当向 KDC 申请 TGS 服务票据的时候，KDC 拒绝下发 TGS 票据，访问资源直接拒绝。

域管理员账号默认没有勾选该属性；部分高权限运维账号运维会手动开启该安全选项，直接导致 OTH 拿到 TGT 但是无法横向访问机器。

排查方式：查看 AD 账号账户选项。解决方案：该账号不可委派，换其他账号凭证。

7.3 进程票据隔离，在别的窗口执行访问

TGT 票据保存在执行 ptt 的那个进程的 LSA 缓存中。mimikatz/run:cmd.exe弹出新 cmd，票据只在这个新 cmd；如果你关闭该窗口，新开 cmd，票据直接消失。

很多同学执行完 pth，关闭 mimikatz 弹出的窗口，手动打开新 cmd 测试，然后疑惑票据明明 klist 看到过，现在访问失败。

解决：访问域资源必须在注入票据的那个进程窗口内操作。CobaltStrike beacon 中 Rubeus 注入的票据仅属于 beacon 进程，spawn 派生新进程不会继承票据。

7.4 TGT 票据生命周期耗尽

TGT 默认生命周期 10 小时，如果长时间不操作，票据过期失效，需要重新执行 OTH 获取全新 TGT。

八、高频踩坑六：CobaltStrike Beacon 环境下 OTH 各种报错

红队实战绝大多数场景是在 CS beacon 内存环境执行 OTH，这里坑点非常多。

1. mimikatz sekurlsa::pth 在 beacon 中容易失败
   sekurlsa::pth 需要创建子进程，beacon 环境下部分 EDR 拦截进程创建行为；并且 sekurlsa::pth 需要 debug 权限。beacon 环境更推荐内存加载 Rubeus 执行asktgt。
2. beacon 执行 Rubeus asktgt 拿到 TGT 之后，spawn 弹出的 powershell 不会继承票据缓存。

beacon 进程内存存在 TGT，但是 spawn 派生出来的新进程拥有独立 LSA 会话，不会继承票据。

解决方法：使用 Rubeus 的createnetonly，直接创建带有票据的独立进程。

Rubeus.exe asktgt /user:administrator /domain:lab.local /aes256:xxx /createnetonly:C:\Windows\System32\cmd.exe

3. beacon 流量代理问题：socks 代理环境执行 OTH，本机 88 流量走 socks 代理，UDP 协议经常异常，AS‑REQ 请求失败。

OTH 的 Kerberos 88 UDP 数据包很多 socks 代理不支持 UDP 转发，导致请求超时报错。
解决方案：尽量在目标本机执行 OTH，不要通过 socks 代理隧道向域控发起 Kerberos 请求。

九、高频踩坑七：双跳 (Double‑Hop) 问题对 OTH 的影响

现象

OTH 拿到 TGT，本机可以访问 dc01；但是在 dc01 上面继续执行 wmi、winrm 去访问第三台机器，二次横向失败。

原理回顾双跳问题：

1. OTH 拿到 TGT，当前进程可以向 KDC 申请 TGS 访问第一台服务器；
2. 当在第一台服务器上面，再去访问第二台机器，这就是 Kerberos 双跳；
3. 默认情况下，客户端不会把 TGT 转发给远程服务器，远程服务器无法再向 KDC 申请新 TGS，二次横向失败。

注意：OTH 拿到 TGT，本身拥有完整 TGT，理论支持双跳，但是受协议约束，远程会话默认不会转发 TGT。白银票据没有 TGT，天生无法双跳；OTH 和黄金票据拥有 TGT，具备双跳能力，但是需要配置约束委派或者使用 CredSSP。

OTH 解决双跳实战方案

1. 使用 CredSSP 协议（mstsc、winrm），但是会产生凭证暴露风险；
2. 配置资源约束委派；
3. 在每一台新获取机器本机重新执行一次 OTH 攻击，重新向 KDC 申请 TGT，规避双跳；
4. Rubeus 的 createnetonly 创建本地进程完成后续操作。

坑点很多新手混淆白银票据和 OTH 双跳能力，OTH 拥有真实 TGT，是支持双跳的，只是 Windows 默认会话限制。

十、Overpass‑the‑Hash 完整排错工作流（严格按顺序排查）

遇到 OTH 攻击失败，不要盲目更换工具，按照下面流程定位问题。

1. 核对凭证正确性：DCSync 导出账号凭证；RC4 哈希用 rc4/ntlm 参数，AES256 密钥使用 aes256 参数，严禁混用；确认账号没有锁定、禁用、密码过期；机器账号末尾带$符号。
2. 时间同步：本机时间与域控时间差控制 5 分钟以内，w32tm /resync。
3. 网络连通校验：测试本机到域控 TCP/UDP 88 端口连通性；DNS 解析域控 FQDN 正确；DNS 异常 Rubeus 使用/dc:ip手动指定 KDC。
4. 确认域 Kerberos 加密套件策略：如果 RC4 模式报 ETYPE_NOSUPP，切换 AES‑256 Pass‑the‑Key 模式。
5. 执行 OTH 拿到 TGT 后，必须在票据注入的原进程测试访问资源，禁止新开窗口；访问目标机器使用 FQDN 主机名，禁止直接写 IP。
6. klist 查看 TGT 票据是否成功加载；确认票据没有过期。
7. 检查账号属性：是否勾选 “敏感账户，不能被委派”，如果勾选该账号无法横向。
8. CS beacon 环境排查：不要依赖 socks 代理执行 OTH；优先 Rubeus asktgt，避免 sekurlsa::pth；跨进程使用 createnetonly。
9. 查看域控安全事件日志 ID4768，查看错误状态码，定位根本失败原因。
   • 0x18 KDC_ERR_PREAUTH_FAILED：凭证错误；
   • 加密类型字段 0x17 RC4，0x12 AES256；
10. 排查双跳场景：本机访问成功，远程会话二次横向失败属于 Kerberos 双跳限制，不是 OTH 本身失败。

十一、mimikatz 与 Rubeus 优缺点对比

实战建议：靶场学习 mimikatz 方便理解；真实红蓝对抗优先 Rubeus。RC4 模式告警高，优先 AES Pass‑the‑Key。

十二、OPSEC 红蓝对抗注意事项（红队必看）

1. RC4 模式 OTH 在仅开启 AES 的域环境中，4768 事件加密类型为 0x17，MDI/MDE 会直接产生高危告警，红队尽量避免 RC4 模式，优先 AES‑256 Pass‑the‑Key 模式。
2. OTH 攻击一定会在域控产生 4768（TGT 请求）安全事件，无法消除日志；OTH 不是无痕迹攻击。
3. 尽量不要通过 SOCKS 代理隧道执行 OTH，UDP88 经常转发失败，导致攻击不稳定。
4. 敏感不可委派账号，即使拿到正确凭证，也无法横向移动，提前收集账号属性信息。
5. OTH 获取 TGT 的有效期和域策略一致，默认 10 小时；票据到期后，需要重新执行 OTH 获取新票据。

十三、蓝队视角：Overpass‑the‑Hash 检测、日志特征与防御加固

13.1 关键 Windows 安全事件 ID

1. 4768 Kerberos TGT 请求事件（域控），OTH 攻击一定会生成该事件，黄金票据不会生成 4768 事件。
   • 正常用户登录：加密类型 0x12 (AES‑256)；
   • RC4 模式 OTH：加密类型 0x17 (RC4‑HMAC)，在纯 AES 域属于异常行为，告警依据。
2. 4648：显式凭据登录事件，mimikatz sekurlsa::pth 会产生该事件。
3. Sysmon 监控进程访问 LSASS 内存，防范凭证 dump 拿到哈希 / AES 密钥。

13.2 MDI (Microsoft Defender for Identity) 告警

MDI 内置专门针对 Overpass‑the‑Hash 检测规则：检测到账号使用 RC4 加密套件请求 TGT，而该账号历史行为全部使用 AES，触发异常告警。

13.3 防御加固方案

1. 优先启用 AES 加密套件，组策略禁用 RC4‑HMAC（注意业务兼容性评估）；
2. 保护域账号凭证，防护 LSASS 内存 dump 行为，开启 LSASS 保护；
3. 高权限域账号开启 “此账号是敏感账户，不能被委派”，即使哈希泄露，也无法利用 OTH 横向；
4. 审计 4768 事件，监控异常源 IP 发起 TGT 请求；监控异常 RC4 加密类型的 TGT 请求；
5. 限制 NTLM 的同时，加强 Kerberos 审计，不要认为关闭 NTLM 就高枕无忧，OTH 可以完全绕开 NTLM 限制完成横向移动。

防御核心：OTH 攻击前提是攻击者拿到账号 NTLM/AES 凭证。只要防止哈希、AES 密钥被窃取，从根源阻断 OTH 攻击。关闭 NTLM 只能拦截 PtH 哈希传递，无法防御 Overpass‑the‑Hash。

十四、常见认知误区总结

误区 1：Overpass‑the‑Hash 是伪造票据

❌错误。OTH 向 KDC 发送 AS‑REQ 请求，拿到真实合法 TGT 票据，域控完整记录 4768 事件；黄金票据才是离线伪造 TGT。

误区 2：关闭 NTLM 之后，所有哈希传递攻击全部失效

❌错误。PtH（NTLM 哈希传递）失效，但是 Overpass‑the‑Hash 完全不依赖 NTLM 协议，依旧可以横向移动，这也是 OTH 在实战中的最大价值。

误区 3：OTH 不需要访问域控，不需要 88 端口

❌错误。OTH 攻击第一步就是向 KDC 发送 AS‑REQ 获取 TGT，必须连通域控 TCP/UDP 88 端口。

误区 4：拿到 TGT 之后，所有 cmd/powershell 窗口全局生效

❌错误。LSA 票据缓存是进程隔离，票据只存在执行 ptt 的进程内部，新开进程票据消失。CS beacon 中 spawn 派生进程不会继承票据。

误区 5：NTLM 哈希可以直接当做 AES256 密钥填入参数

❌错误。NTLM 哈希、AES256 密钥是两套完全不同的密钥，必须从 DCSync 分别导出，参数不能混用，混用直接报预认证失败。

误区 6：OTH 和白银票据一样，无法双跳

❌错误。OTH 拿到完整合法 TGT，本身具备双跳能力；只是 Windows 远程会话默认限制 TGT 转发，不是技术本身不支持。白银票据是 TGS 服务票据，天生无法双跳。

误区 7：靶场 RC4 模式可以跑，生产环境也一定可以

❌错误。新版 AD 域环境大量组策略禁用 RC4 加密套件，RC4 模式 OTH 直接报错KDC_ERR_ETYPE_NOSUPP，红蓝对抗优先 Pass‑the‑Key AES‑256 模式。

十五、总结

Overpass‑the‑Hash (OTH/PtK) 是域红队横向移动的核心技术，专门应对 NTLM 协议被封禁的防护场景。很多人复现失败，并不是工具 bug，大多来自凭证混用、加密套件策略、网络端口、时间同步、进程票据隔离、账号属性等问题。

我们汇总全部失败根因：

1. 预认证失败KDC_ERR_PREAUTH_FAILED：哈希 / AES 密钥复制错误，参数混用，账号锁定禁用过期；
2. KDC_ERR_ETYPE_NOSUPP：域禁用 RC4 加密，RC4 模式 OTH 失效，切换 AES‑256 Pass‑the‑Key；
3. 时钟偏移KRB_AP_ERR_SKEW：本机和域控时间差超过 5 分钟；
4. 网络故障：域控 88 端口不通、DNS 解析异常；socks 代理 UDP 不支持导致请求超时；
5. 拿到 TGT 但是访问资源拒绝：使用 IP 访问 SMB 回退 NTLM；进程隔离，新开窗口票据丢失；账号标记敏感不可委派；
6. CS beacon 环境坑：sekurlsa::pth 兼容性差；spawn 新进程不会继承票据；socks 代理 Kerberos 请求异常；
7. 双跳 Double‑Hop 限制：本机访问成功，远程会话二次横向失败。

学习 OTH 攻击，不能只复制粘贴命令，要区分 RC4‑OTH 与 AES Pass‑the‑Key 模式差异，区分 OTH、PtH、黄金票据、白银票据原理上的不同。靶场复现成功不等于真实环境可用，现代生产域优先使用 AES 模式，减少告警同时规避 RC4 禁用带来的报错。

蓝队一定要建立认知：关闭 NTLM 只能防御传统 PtH 哈希传递，不能防御 Overpass‑the‑Hash 攻击，需要做好凭证防护，开启完整 Kerberos 日志审计，监控异常 TGT 请求行为。

最后

关于网络安全技术储备

学好网络安全不论是就业还是做副业赚钱都不错，但要学会网络安全还是要有一个学习规划。最后大家分享一份全套的网络安全学习资料，给那些想学习网络安全的小伙伴们一点帮助！

对于0基础小白入门：

如果你是零基础小白，想快速入门网络安全是可以考虑的。

一方面是学习时间相对较短，学习内容更全面更集中。

二方面是可以找到适合自己的学习方案

包括：网安成长学习路线图、SRC&黑客文档、护网行动、黑客必读书单、面试题、学习视频等教程。带你从零基础系统性的学好网络安全！

需要的可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

👉1.成长路线图&学习规划👈
要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

👉2.网安入门到进阶视频教程👈
很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，其中一共有21个章节，每个章节都是当前板块的精华浓缩。（全套教程文末领取哈）

👉3.SRC&黑客文档👈
大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录

SRC技术文籍：

黑客资料由于是敏感资源，这里不能直接展示哦！（全套教程文末领取哈）

👉4.护网行动资料👈
其中关于HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！

👉5.黑客必读书单👈

随着互联网技术的飞速发展，网络安全已经成为了当今科技领域的一大热点。这些SQL注入、CCNA、Web渗透、Linux服务器等，以其强大的语言理解和防御能力，正在守护着我们网络世界。 那以下这些PDF籍就是非常不错的学习资源。

👉6.网络安全岗面试题合集👈
当你自学到这里，你就要开始思考找工作的事情了，而工作绕不开的就是真题和面试题。

这份完整版的网络安全学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】