MS14-068与PTT票据传递:从普通域用户到域管权限的实战拆解

发布时间:2026/10/20 17:30:50
MS14-068与PTT票据传递:从普通域用户到域管权限的实战拆解 先说结论如果你的内网测试列表里还没有把域渗透的票据类攻击单独立项那MS14-068配合PTTPass The Ticket这套组合基本上是我见过最典型的“低垂果实”之一。它不需要多高深的操作不需要0day不需要反复折腾免杀只要一个普通域用户的明文密码或哈希配合一台没打补丁的域控几分钟内就能从普通域成员走到域管权限。这篇文章我会按自己实际测试的流程来拆解从Kerberos票据的逻辑讲起到MS14-068为什么能伪造高权限票据再到具体的票据传递实操、踩坑记录和建议加固思路尽量讲得直白、能直接照着做。适合的读者很明确在内网渗透测试或红队评估中已经掌握了基本的域内信息收集但还没系统把票据攻击链路打通的同学。如果你刚接触域渗透也能看但建议先把Kerberos基础概念过一遍否则后面某些参数你会看得很吃力。1. 先搞清楚域渗透为什么绕不开Kerberos票据1.1 用生活化类比理解Kerberos票据体系域环境里所有机器认的不是“用户名密码”而是“票据”。你可以把Kerberos想象成一个大型游乐场KDC域控就是游乐场售票处负责验证游客身份、发放票据。TGTTicket Granting Ticket是进门时买的通票证明“这个人是合法游客”。STService Ticket是每个游乐设施前需要用通票换的单项票比如过山车票、摩天轮票持有者才能乘坐对应设施。PACPrivilege Attribute Certificate就是通票背面盖的“特权章”写着你是普通游客还是VIP、能去哪些区域。在域环境的实际认证过程中用户向KDC发送AS-REQ请求KDC验证身份后用用户的密码哈希派生密钥加密返回TGT。之后用户要访问某台服务器的某个服务时带着TGT向TGS发TGS-REQTGS签发ST服务端用ST验证用户身份并读取PAC中的组成员信息来决定访问权限。这台机器之间传输的认证材料全部是票据那么一切攻击的核心逻辑就很清晰了只要能让系统认为你是域管你就能像域管一样访问任何资源。1.2 票据传递攻击PTT的定位与价值很多测试人员一开始接触内网横向用的都是哈希传递Pass The HashPTH。但PTH在现代环境里越来越受限越来越多的系统支持但不强制NTLM认证部分严格环境直接禁用NTLM即便拿到了哈希也不一定能在纯Kerberos环境下畅行无阻。PTT的全称是Pass The Ticket直接翻译是“传递票据”。它的本质很简单把伪造或窃取的Kerberos票据直接注入到当前会话的票据缓存中后续自己这台机器发起的访问都带着这张票据目标服务端看到后认为你就是票据中标识的身份。PTT这么多年一直是横向移动和域提权的常青树原因在于Kerberos是Windows域内认证的默认协议你不可能关闭它。票据一旦注入本地进程不需要重新登录就能以票据身份访问远程服务。配合漏洞伪造的票据比如MS14-068生成的TGT可以直接从普通用户提权到域管。2. MS14-068让普通域用户秒变域管的经典漏洞2.1 漏洞根因KDC没有校验PAC签名MS14-068的官方编号是CVE-2014-0686影响面包括Windows Server 2003到2012 R2这一大批域控系统。它是我见过的最可惜的“设计失误型漏洞”——不是缓冲区溢出不是注入漏洞而是Kerberos协议实现中对PAC签名校验逻辑的疏漏。需要先理解PAC是什么。域控在最初签发TGT时会在票据里附带上PACPAC里包含用户的SID、所属组SID以及关键的PAC签名。这个签名是用域控的密钥对应krbtgt账户的哈希对整个PAC内容算出的校验值相当于防伪标签。正常情况下服务端收到票据后会拿着域控密钥校验这个签名确保PAC内容没有被篡改。但是在旧版Windows域控的Kerberos实现里KDC自身在处理来自用户的TGT时并没有重新校验TGT中PAC的签名是否合法。它看到票据结构完整、字段齐全就直接信任了里面的PAC内容并且会在后续颁发的ST里原封不动地复制PAC。这就非常致命了如果攻击者能自己构造一个PAC在里面把用户所属组加上“域管理员”再用域控的密钥生成签名那么KDC会把这张伪造的高权限票据当成真票使用。注意攻击者手上根本没有域控密钥所以漏洞利用的关键变成了怎么让PAC的签名看起来是域控签发的答案是通过Netlogon协议中的一个逻辑缺陷普通域用户可以请求到带着域控签名的指定PAC内容。微软后来修复的方式也很直接——强制KDC验证TGT中的PAC签名。但从2014年往前推大量内网基础设施在很长一段时间内都躺在这个漏洞上。2.2 漏洞影响面与适用条件MS14-068并不是“所有域用户输入密码就能提权”的魔法。实际能利用成功需要满足几个硬性条件条件说明已知一台域成员机器的普通域用户凭据可以是明文密码也可以是哈希部分工具支持hash直接利用域控操作系统未安装MS14-068修复补丁2014年11月之后的补丁已经修复了PAC校验缺陷域控可达445端口、88端口Kerberos等网络通路上没被隔离域功能级别不设限某些部署了额外PAC校验策略或“强制Kerberos PAC验证”的硬化工具有时会拦截在实操中很多测试者第一步会先用工具探测目标域控是否打了补丁最简单的方法就是检查系统补丁列表中是否包含MS14-068对应的更新。如果没有才继续走下面的利用步骤。2.3 常见误区MS14-068不是直接getshell我遇到过不少新手把MS14-068理解成“一个攻击包打进域控直接管理员”。实际上它只负责“把你变成域管身份”相当于给你一张伪造的VIP卡。真正要执行命令、抓取更多凭据还是走常规的管理通道比如计划任务、服务创建、WMI远程调用、DCSync。这正好也是PTT要接棒的地方MS14-068负责“造票”PTT负责“用票”。两者各管一段配合起来才是完整的链路。3. PTT票据传递攻击怎么用伪造票据登堂入室3.1 票据注入的核心原理Windows系统里当前用户的Kerberos票据保存在内存中的LSA缓存里会话启动后C:\Users\用户名\AppData\Local\Microsoft\Windows\Caches里也会有部分缓存信息。正常情况下用户访问域内资源时系统自动从缓存中挑选对应的ST。我们做PTT时就是用工具把已有的TGT或ST写入这个缓存区让系统认为当前用户已经完成过这些认证流程。mimikatz中注入票据的命令是kerberos::ptt 票据文件.kirbi执行后没有任何回显才是正常的之后可以用klist查看当前会话中已有的票据列表。注入成功后当前进程后续访问SMB、LDAP、WinRM等依赖Kerberos认证的服务时会自动携带图中身份对应的凭据。3.2 PTT与黄金票据、白银票据的关系很多文章把黄金票据、白银票据和PTT混在一起讲导致概念非常混乱。我按自己理解给个简化版黄金票据拿到了域内krbtgt账户的哈希之后可以伪造任意用户的TGT等于直接冒充任何人。它解决的是“伪造身份”的问题。白银票据拿到了某服务账户如目标机的机器账户的哈希之后伪造某个具体服务如CIFS的ST。它解决的是“访问特定服务时伪装身份”。PTT是一种“用票手法”不是一种“造票手法”。无论哪张票只要能在当前会话里注入并让它生效就都叫PTT。MS14-068生成出的是一张带有高权限PAC的TGT——本质上和黄金票据很像区别在于它不需要krbtgt哈希而是通过漏洞让域控帮你把PAC签名签好。因此完整技术链是“漏洞造票 → PTT用票 → 域内横向扩展”。4. 环境准备与实操复现从普通域用户到域管4.1 实验环境说明我没法把真实客户环境当靶场所以这段话只讲通用环境搭建。本地我用的是域控Windows Server 2012 R2未安装MS14-068修复补丁域名为corp.local域成员机Windows 10已加入corp.local域普通域用户zhangsan隶属于Domain Users目标将zhangsan提升为域管权限并访问域控这种环境和真实内网测试的区别是“干净”没有杀软和EDR干扰适合先验证逻辑再上线复杂环境。4.2 第一步拿到普通域用户的凭据在真实渗透中获取普通域用户凭据的方法很多钓鱼、弱口令爆破、本地抓取缓存哈希、工具读取内存等。这里我直接从用户zhangsan的机器上抓取了明文密码相当于假设已经拿到了一个有效域账户密码。拿到凭据后先验证账户有效性和网络连通性net user zhangsan /domain ping dc01.corp.local4.3 第二步利用MS14-068生成伪造TGT票据目前使用比较广泛的是“金箍棒”这个工具内部也叫Golden Pac。它把MS14-068利用封装成了命令行工具极大降低了门槛。基本用法金箍棒.exe -u zhangsancorp.local -p 密码 -s zhangsan -d dc01.corp.local -ptc各参数含义-u目标普通域用户格式为用户域名-p该用户的明文密码-sSID这里填用户的SID原工具会自动查询一般不需要手动指定-d域控主机名-ptc指定生成带PAC校验的TGT执行成功后当前目录会生成一个类似1-20000-1-123456-krb5tgs.kirbi的文件。这个kirbi文件就是伪造的TGT票据名字虽然长得像tgs但实质是TGT。如果你手里只有用户哈希而不是明文也可以用哈希方式替代-p参数工具链完整的话是能直接通的。生成票据后建议先确认下文件大小正常生成的票据一般在几百KB到几MB不等过小可能是生成失败。4.4 第三步PTT注入票据并验证权限把生成的kirbi文件拷贝到目标域成员机上然后使用mimikatz。注意mimikatz需要管理员权限运行否则无法操作LSA缓存。mimikatz # privilege::debug mimikatz # kerberos::ptt C:\tmp\1-20000-1-123456-krb5tgs.kirbi mimikatz # kerberos::list看到票据列表中多了一条随机域名用户名的TGT说明注入成功。此时可以用非常直观的方式验证是否已经成为域管whoami dir \\dc01.corp.local\c$如果dir能列出域控C盘目录说明当前身份已经具备域管的访问权限——普通域用户绝对做不到这一步。我试过很多次这段输出出来的那一刻基本就确定后续链路已经打开了。拿到域管访问权限后顺手做信息收集和权限维持mimikatz # lsadump::dcsync /domain:corp.local /all /csvDCSync可以模拟域控复制所有用户哈希包括krbtgt。这一步做完理论上域内的长期权限就完全拿到了。后续可以通过计划任务直接在域控上执行命令schtasks /create /s dc01.corp.local /u corp.local\zhangsan /p 密码 /sc once /tn test /tr cmd /c whoami C:\result.txt /ru SYSTEM注意这里机器在PTT注入后新开进程会继承当前会话票据但schtasks、wmic这类工具在创建远程计划任务时不一定完全走Kerberos有时需要直接指定凭据。真要执行远程命令时我更推荐先利用PTT拿到域管身份后再做一次Netuse映射或者干脆用具备S4U2Self能力的工具直接跑否则会踩“伪身份只覆盖Kerberos服务”这个坑下一章详细讲。5. 实战中一定会遇到的坑与排查方法5.1 常见问题速查表问题现象可能原因解决思路金箍棒生成票据时报“SID not found”用户SID查询失败可能是DNS解析问题或域控防火墙阻断了查询流量先用nltest /dsgetdc:corp.local确认域控发现是否正常检查ADSI查询口是否通注入票据后访问域控C$提示拒绝访问票据注入成功但当前进程没有使用新的票据或者目标启用SMB签名要求重新打开一个cmd窗口票据需要在新进程里使用确认目标445端口可用检查票据是否过期、是否被替换票据文件生成成功但dir无回显/超时目标域控存在主机防火墙隔离或IPsec策略检查网络层面连通性尝试用域控主机名而非IP访问避免跳过Kerberos的SPN匹配Klist看得到票据但服务端仍不认识域控时间偏移大于Kerberos时间窗口默认5分钟或票据签名算法不受支持执行w32tm /stripchart /computer:dc01对比时间必要时手动同步时间后重新生成票据杀软拦截将票据文件删除或禁止注入mimikatz动作特征明显该操作用到LSA缓存需提权被拦截是常态考虑用系统自带工具或换载荷方式利用工具本身被杀软查杀工具特征明显先用实验环境验证完整链路再讨论免杀问题5.2 时间同步问题是最容易被忽视的Kerberos对时间极度敏感。默认容错只有5分钟偏移超过这个值任何票据都会被目标当作废纸。内网很多域成员机的时钟不准尤其虚拟机环境重启后时间漂移严重。我发现很多测试卡在“票据明明生成了、也注入进去了但目标机就是不认”最后被一笔带过实际上就是时间窗问题。建议动手前先在所有机器上统一执行w32tm /resync /force并且确认域控和成员机的时间源一致。这个细节在文档里往往一句都不提但在实际测试中它的出现率远比代码报错要高。5.3 如何判断“利用是否真正成功”有一个我比较推荐的判断顺序先用klist确认票据存在且状态为OK不要只看注入命令有没有报错。再用dir \\dc01\c$做SMB访问测试。如果SMB访问失败不代表票据失败还可能是因为SMB签名或加密策略限制。此时可以换LDAP测试adfind -h dc01.corp.local -u zhangsancorp.local -p 密码 -b dccorp,dclocal scount如果LDAP查询成功而SMB失败说明身份认证没问题只是访问协议受限。最后才检查域控上是否生成了新的登录事件正常情况下域控日志会记录到这个用户的TGT请求记录。5.4 加固与检测思路这块内容反向也有价值如果你站在防守方视角MS14-068并不难防给域控安装2014年11月后的所有补丁微软在修复中强制启用了KDC对TGT中PAC的校验这是根除手段。审计域内域控的Kerberos服务事件关注来自非域控IP的高频AS-REQ请求以及同一个账户在短时间内在多台机器上出现KDC凭据请求的记录。对域内高权限组成员变化做实时监控域管组成员一旦新增24小时内必须通知复核。在关键服务器上禁用不必要的NTLM推动全网向Kerberos-only转变虽然不能直接防住PTT能压缩很多哈希传递类的攻击面。域内敏感操作日志集中收集不信任单点日志防止攻击者删日志掩盖痕迹。另外提一句PTT本身不是漏洞而是协议正常工作方式的滥用。所以就算把MS14-068堵死只要攻击者拿到了krbtgt哈希制作黄金票据PTT一样能生效。这意味着域渗透里真正要守的是域控和krbtgt密钥而不只是打某一个补丁。最后分享两个实操体会第一在全套流程跑通之前强烈建议先在你自己的实验环境里把票据生成、注入、访问验证这三步练熟。我见过很多测试人员把工具参数背得滚瓜烂熟但真正上了客户环境里一遇到报错就手足无措。其中一个原因就是他们从没拆过票据文件看过结构也不清楚TGT和ST在内存中的形态差异。亲手用mimikatz的kerberos::list观察过几次票据变化之后很多抽象概念一下子就落地了。第二内网环境下千万不要为了省事直接拿域控当跳板去访问其他机器。很多时候一张域管TGT已经把整个域都“打通”了但后续操作还要照顾每台目标机器自己的本地账户策略。正确做法是先在域控和成员机上把信息收集做透明确哪些机器真正承载核心业务或备份域控哈希副本再有目标地横向移动。滥用域管身份大范围访问通常不仅容易触发告警还可能破坏业务数据让整个测试项目提前走向“应急响应演练”。MS14-068虽然已经被补丁修复多年但直到现在我依然能在一些存量较大的企业内网中看到它的影子。究其原因不少内部系统十年八年的运维周期里根本没有做过完整的补丁更新尤其是域控这种高敏感设备运维团队往往操作得很谨慎导致补丁滞后。对红队和渗透测试人员来说掌握这类历史经典漏洞的利用原理和实操链路价值不只在某一个漏洞本身更在于它把“Provisioning凭证→攻击票据→通过可信通道横向移动”这一整套域攻击方法论串了起来。这套思维你在后续碰到更多票据伪造攻击、无凭据攻击时都会反复用到。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询