PTK密钥传递攻击：Kerberos AES密钥横向移动实战与防御

1. 项目概述深入理解PTK密钥传递攻击在渗透测试和红队评估的实战中横向移动是攻破内网、扩大战果的关键环节。除了大家熟知的哈希传递PTH还有一种相对“低调”但威力不减的攻击手法——密钥传递攻击也就是我们常说的PTK。我第一次在实际环境中遇到PTK的场景是在一个金融客户的内部红蓝对抗演练里。当时常规的NTLM哈希传递被目标服务器的安全策略拦截但通过抓取到的AES密钥我们成功绕过了防御拿到了关键系统的控制权。这让我意识到PTK绝非一个“冷门”技术而是攻击者武器库中一把精密的“备用钥匙”。简单来说PTK是一种利用Kerberos认证协议中AES密钥具体是aes256-cts-hmac-sha1-96或aes128-cts-hmac-sha1-96而非传统的NTLM哈希来向远程系统证明身份并获取访问权限的攻击技术。它的核心价值在于当目标环境因为打了某些补丁如KB2871997或配置了特定策略导致传统的PTH攻击失效或受限时PTK往往能成为一条有效的备用路径。理解PTK不仅能让你在攻击侧多一种选择更能从防御角度深刻认识到仅仅封堵NTLM哈希是远远不够的Kerberos协议本身的密钥保护同样至关重要。这篇文章我将从一个实战者的角度为你彻底拆解PTK密钥传递攻击。我会从Kerberos认证的基础原理讲起让你明白AES密钥从何而来、为何有效然后详细演示在Windows域环境下如何利用Mimikatz等工具进行PTK攻击的完整流程、命令细节和注意事项接着我们会深入探讨PTK的攻击条件、限制以及它与PTH、PTT票据传递的本质区别最后我会分享一些基于实战的防御检测思路和排查技巧。无论你是安全工程师、渗透测试人员还是系统管理员理解这套攻击链都能帮助你更好地构筑或评估内网安全防线。2. 核心原理Kerberos、AES密钥与PTK的攻击逻辑要搞懂PTK必须先理解它的攻击载体——Kerberos协议中的AES密钥。很多资料只讲操作命令却不解释“为什么这个AES值能用来登录”这就像只给你一把钥匙却不告诉你它能开哪扇门。2.1 Kerberos认证简析与密钥的诞生在Windows域环境中Kerberos是默认的、首选的网络认证协议。当用户使用密码登录时系统不仅会计算并存储用于NTLM挑战/应答的NTLM哈希还会根据用户密码派生出一组用于Kerberos加密的密钥其中就包括AES-256和AES-128密钥。这个过程是单向的、确定的只要密码相同在任何域成员计算机上为同一用户计算出的AES密钥都是相同的。这些密钥被称为“长期密钥”它们被安全地存储在本地安全机构子系统服务LSASS进程的内存中。当用户请求访问网络服务如文件共享SMB时客户端会使用这些AES密钥与域控制器KDC进行加密通信获取服务票据Service Ticket。关键在于在某些配置下客户端可以直接使用AES密钥向目标服务证明身份而无需与域控制器交互获取新的票据。这就是PTK攻击得以成立的理论基础攻击者窃取了存储在内存中的AES密钥就等于窃取了用户进行Kerberos认证的“凭证”。2.2 PTK与PTH、PTT的本质区别很多人容易把这几种“传递”攻击搞混其实它们的攻击面和原理有根本不同PTHPass-the-Hash攻击的是NTLM认证协议。它利用的是LM/NTLM哈希值直接参与NTLM挑战/应答过程完全绕过密码验证。它不依赖域环境对工作组和域都有效但主要针对SMB、WMI等使用NTLM的服务。PTKPass-the-Key攻击的是Kerberos认证协议。它利用的是AES密钥或更老的RC4-HMAC密钥即NTLM哈希本身也可作为Kerberos密钥。PTK通常用于在Kerberos认证中直接使用密钥向目标服务发起请求。它强烈依赖于域环境。PTTPass-the-Ticket攻击的也是Kerberos协议但利用的是已经签发好的票据Ticket特别是黄金票据Golden Ticket或白银票据Silver Ticket。它不直接使用密钥而是使用用密钥加密过的、代表身份的“通行证”。用一个生活化的比喻PTH是伪造了你的指纹哈希去按指纹锁PTK是偷了你的门禁卡密码AES密钥去生成一张临时门禁卡PTT则是直接偷了一张已经生效的门禁卡票据去刷卡。2.3 PTK攻击生效的关键条件为什么PTK不像PTH那样“通用”因为它需要满足更特定的条件目标服务必须支持Kerberos认证这是前提。SMB、LDAP等服务在域内通常都支持。攻击者必须能获取到用户的AES密钥这通常需要通过像Mimikatz这样的工具在已经取得权限的系统上从LSASS内存中提取sekurlsa::ekeys。目标账户的认证方式配置这是最核心的一点。在Windows中每个用户账户都有一个“支持的加密类型”属性。它决定了该账户在Kerberos认证中可以使用哪些类型的密钥。PTK攻击成功要求目标账户支持并配置了AES加密类型AES256或AES128。补丁KB2871997的影响这是一个广为流传但需要澄清的点。KB2871997补丁确实改变了本地管理员账户的行为限制了使用NTLM哈希进行网络登录即PTH但它的一个副作用是促使系统在可能的情况下更倾向于使用Kerberos认证其中就包括使用AES密钥。因此在打了该补丁的系统上使用非内置的本地管理员账户即你创建的另一个具有管理员权限的账户或域账户进行横向移动时PTK使用AES密钥可能成为比PTH更有效或唯一可行的方式。但请注意PTK本身并不“要求”必须打这个补丁补丁只是改变了环境使得PTK的相对价值凸显。重要提示从Windows Server 2012 R2及Windows 8.1开始AES加密已成为域账户的默认支持类型。这意味着在现代的Windows域环境中绝大多数域账户都天然满足PTK攻击的密钥类型条件。3. 实战演练PTK攻击全流程拆解理论讲完我们进入实战环节。我会以一个模拟的域环境域名lab.local目标机器WIN-TARGET已获取权限的跳板机WIN-ATTACKER为例演示完整的PTK攻击链。3.1 第一阶段信息收集与密钥提取在已经控制的主机WIN-ATTACKER上我们的第一步是提取有效的身份凭证。3.1.1 使用Mimikatz提取AES密钥以管理员权限运行Mimikatz执行以下命令privilege::debug sekurlsa::ekeysprivilege::debug是为了获取调试权限以便访问LSASS进程的内存。sekurlsa::ekeys命令会列出当前系统内存中所有登录会话的加密密钥包括AES-256和AES-128密钥。输出会类似于Authentication Id : 0 ; 996 (00000000:000003e4) Session : Service from 0 User Name : LAB$ Domain : LAB Logon Server : (null) Logon Time : 2023/10/27 8:00:00 aes256_hmac 4096b35532c78c2c9be2e4c0c81b43a1d8c2b835c6fa1c416b79669abcdef01 aes128_hmac 2a4f5c6b8d3e1f7a9b0c2d4e6f8a1b3c ... Authentication Id : 0 ; 999999 (00000000:000f423f) Session : Interactive from 0 User Name : Administrator Domain : LAB Logon Server : DC01 Logon Time : 2023/10/27 9:30:00 aes256_hmac bd25b5ae78c10e3fcda9693cd31027d70383063a1d8c2b835c6fa1c416b79669 aes128_hmac 8e7d6a5c4b3a2f1e9d8c7b6a5f4e3d2c ...这里我们找到了域管理员LAB\Administrator的aes256_hmac密钥bd25b5ae78c10e3fcda9693cd31027d70383063a1d8c2b835c6fa1c416b79669。这就是我们进行PTK攻击的“弹药”。3.1.2 密钥提取的注意事项与技巧权限是关键必须拥有足够的权限通常是SeDebugPrivilege才能读取LSASS内存。在非管理员或权限受限的会话中此命令会失败。关注交互式登录会话sekurlsa::ekeys会输出大量信息包括系统账户、服务账户等。作为攻击者我们最关心的是Session类型为Interactive交互式登录或RemoteInteractive远程桌面登录的用户因为这些会话最可能包含高权限域用户的密钥。防病毒软件规避Mimikatz是安全软件的焦点。在实战中可能需要使用其内存转储功能sekurlsa::minidump先将LSASS内存转储到磁盘再在分析机器上离线提取密钥或者使用其他更隐蔽的工具或自定义脚本来读取LSASS。除了AES还有什么输出中你可能还会看到des_cbc_md5等较老的加密类型。在现代环境中AES是首选且最安全的但了解所有密钥类型有助于全面评估风险。3.2 第二阶段发起PTK攻击拿到AES-256密钥后我们就可以尝试横向移动到目标主机WIN-TARGET.lab.local。3.2.1 使用Mimikatz进行PTK注入在Mimikatz中执行sekurlsa::pth /user:Administrator /domain:lab.local /aes256:bd25b5ae78c10e3fcda9693cd31027d70383063a1d8c2b835c6fa1c416b79669这条命令的作用是在内存中创建一个新的登录会话这个会话使用我们提供的/user、/domain和/aes256参数进行Kerberos认证。它并不会真的用这个密钥去登录当前系统而是为接下来启动的进程如CMD赋予这个伪造的身份。命令执行成功后Mimikatz会弹出一个新的命令提示符CMD窗口。这个新窗口的进程已经继承了刚刚注入的LAB\Administrator的Kerberos身份。3.2.2 在新会话中访问目标资源在新弹出的CMD窗口中你可以直接使用Kerberos认证访问网络资源无需再次输入密码或哈希。例如dir \\WIN-TARGET.lab.local\C$如果PTK攻击成功且目标主机WIN-TARGET允许LAB\Administrator访问这条命令会成功列出C盘目录。你也可以尝试建立IPC连接但请注意在纯Kerberos认证且PTK成功的情况下直接使用net use访问共享也是可行的因为SMB协议会尝试使用当前线程的Kerberos票据我们通过PTK注入的密钥可以即时生成所需的票据。3.2.3 使用Impacket套件进行PTK攻击Mimikatz需要在Windows目标上运行。如果你从Linux攻击机发起攻击或者更喜欢命令行工具Impacket套件是绝佳选择。Impacket的psexec.py、smbexec.py、wmiexec.py等脚本都支持-aesKey参数。假设我们从Linux攻击机使用获取的AES-256密钥攻击WIN-TARGETpython3 psexec.py lab.local/AdministratorWIN-TARGET.lab.local -aesKey bd25b5ae78c10e3fcda9693cd31027d70383063a1d8c2b835c6fa1c416b79669 -hashes : -no-pass参数解释-aesKey指定AES-256密钥。-hashes :这里传入空的哈希值LM:NT因为我们不使用NTLM哈希。-no-pass表示不提供密码。这条命令会尝试使用AES密钥进行Kerberos认证并在目标主机上执行一个交互式的shell。3.3 攻击流程中的关键决策点在实际操作中你可能会面临选择用PTH还是PTK优先尝试PTH如果目标服务明确支持NTLM很多老系统或特定服务如此且你手上有NTLM哈希PTH通常是更直接的选择因为它不依赖域控制器和Kerberos票据的复杂性。PTH失败时转向PTK如果PTH被拦截例如目标策略要求使用Kerberos或者你发现目标账户的NTLM哈希是空值或无法使用在打了KB2871997补丁且禁用NTLM的环境下本地管理员账户的NTLM哈希可能被清空这时就应该检查sekurlsa::ekeys的输出尝试使用AES密钥进行PTK。票据PTT作为替代方案如果你能通过其他手段如漏洞MS14-068或从内存中导出可用的TGT票据sekurlsa::tickets /export那么PTT可能是比PTK更优的选择因为它直接使用票据避免了密钥协商过程在某些情况下更稳定。4. 深度解析攻击条件、限制与变种理解了基本操作我们还需要深挖PTK攻击的边界和细节这样才能在复杂环境中灵活运用。4.1 精确理解攻击前提条件网络上常说“PTK需要KB2871997补丁”这个说法不够精确容易误导。更准确的理解是核心条件目标用户账户支持并配置了AES加密类型且攻击者能获取到该账户对应的AES密钥。KB2871997补丁的角色该补丁修改了本地账户的“受限制的管理员”模式等行为其中一个关键影响是对于非RID-500的本地管理员账户即非内置的Administrator其NTLM哈希在内存中可能被清空或无法用于网络登录PTH。这迫使攻击者在横向移动这类账户时必须寻找替代方法而使用AES密钥的Kerberos认证PTK就成为了一个非常可行的选项。对于域账户无论打没打这个补丁只要其支持AESPTK攻击就可能成功。服务要求目标服务如SMB必须配置为接受Kerberos认证。在纯域环境中这通常是默认的。4.2 PTK攻击的局限性没有一种攻击是万能的PTK也有它的软肋依赖Kerberos协议如果目标网络或服务禁用了Kerberos强制使用NTLM那么PTK将无效。需要AES密钥如果目标账户只支持老旧的RC4-HMAC加密类型其密钥就是NTLM哈希那么所谓的PTK实际上就退化成了PTH因为密钥就是哈希本身。在现代域中默认启用AES但某些旧系统或自定义配置可能仍在使用RC4。受Kerberos策略约束PTK攻击发起的会话同样受域Kerberos策略的约束例如票据生命周期通常10小时、续订期限等。超过有效期后会话将失效。可能触发告警与PTH相比PTK产生的网络流量是标准的Kerberos协议流量可能更不容易被基于异常NTLM行为的检测规则发现。但是从一台非常用主机或在一个异常时间点使用某个域用户的AES密钥发起认证这个行为本身在配置了高级SIEM或UEBA的系统中仍然可能构成异常事件。4.3 从PTK到Overpass-the-HashPTK攻击在Mimikatz的早期文档中有时也被称为“Overpass-the-Hash”。本质上它们是一回事都是利用密钥哈希或AES密钥来获取一个有效的Kerberos票据TGT然后用这个票据去访问服务。sekurlsa::pth命令在提供/aes256参数时内部就是执行了“Overpass-the-Hash”的过程它用提供的AES密钥向域控制器KDC请求一张TGT票据并将这张票据注入到新创建进程的票证缓存中。所以你可以把PTK看作是Overpass-the-Hash技术在使用AES密钥时的一个具体应用实例。5. 防御、检测与应急响应指南作为防御方了解攻击是为了更好地防御。针对PTK攻击我们可以从预防、检测、响应三个层面构建防线。5.1 预防措施加固认证体系实施凭证保护Credential Guard这是最有效的防御手段之一。Credential Guard利用基于虚拟化的安全VBS将LSASS进程隔离在一个安全的容器中使像Mimikatz这样的工具无法直接读取到明文密码、哈希或AES密钥。它极大地提高了攻击者提取密钥的难度。启用受保护的用户组Protected Users Group将高权限用户如域管理员加入“受保护的用户”组。该组的成员无法使用NTLM、DES或RC4等弱加密协议进行认证并且其Kerberos票据的生存期很短这增加了攻击者利用窃取的密钥或票据的难度。注意这可能会影响一些旧版应用程序。配置账户的“支持的加密类型”在Active Directory中可以精细控制每个账户允许的Kerberos加密类型。可以考虑对高权限账户禁用较弱的RC4-HMAC加密类型强制使用AES。但这需要确保所有需要认证的服务和客户端都支持AES。应用最小权限原则严格限制域管理员账户的使用范围避免其在不必要的计算机上登录。使用“特权访问工作站”PAW和跳板机堡垒机来管理关键系统。这样即使某个终端被攻破攻击者能提取到的有价值密钥也有限。及时安装安全更新虽然KB2871997补丁“催生”了PTK的利用场景但微软后续的许多安全更新如针对“永恒之蓝”的补丁、Credential Guard的增强等都能从不同层面加固系统阻止或增加凭证窃取的难度。5.2 检测手段发现异常密钥使用防御不能只靠堵还要能发现。PTK攻击会在日志和网络中留下痕迹。Windows事件日志分析事件ID 4768Kerberos身份验证票证请求这是最相关的日志。关注请求中的EncryptionType字段。如果发现一个用户账户突然从某个非常用IP地址或主机名使用AES256或AES128加密类型请求TGT这可能是一个异常信号。特别是如果该请求成功但紧接着来自同一源地址的事件ID 4624登录成功却使用了NTLM这可能意味着发生了PTH而如果4624登录也显示为Kerberos则可能是PTK或正常登录需要结合其他上下文判断。事件ID 4672特殊权限分配攻击者在提取密钥时通常需要SeDebugPrivilege权限。在非管理员的日常操作中出现此事件值得警惕。网络流量监控Kerberos AS-REQ流量PTK攻击通过Mimikatz的pth会触发客户端向KDC发送AS-REQ请求以获取TGT。监控网络中异常的、来自非域成员或非常用工作站的AS-REQ请求。可以使用Wireshark抓包查看Kerberos协议中PA-DATA部分的pA-ENC-TIMESTAMP它包含了用用户密钥加密的时间戳。虽然我们无法解密但可以记录下请求的来源和用户。SMB流量中的认证上下文分析SMB会话建立时的认证信息。如果发现SMB会话使用了Kerberos认证但其SPN服务主体名称与客户端计算机账户不符或者来自一个近期刚提取过密钥的源IP则可能存在问题。终端行为检测LSASS进程内存访问使用Sysmon或EDR工具监控对LSASS进程的OpenProcess调用特别是请求PROCESS_VM_READ权限的调用。来自非系统、非安全软件进程如mimikatz.exe、rundll32.exe、powershell.exe的此类访问是高度可疑的。可疑命令行参数检测命令行中是否包含sekurlsa::、pth、/aes256等Mimikatz典型参数。5.3 应急响应遭遇PTK攻击后的处置如果怀疑或确认发生了PTK攻击应立即采取以下步骤隔离受影响系统立即将疑似被提取密钥的源主机攻击跳板和被横向移动的目标主机从网络中断开防止攻击蔓延。重置相关凭证这是最关键的一步。立即重置被用于PTK攻击的域用户账户密码。密码重置后基于旧密码派生的所有AES密钥和NTLM哈希立即失效。同时在域控制器上吊销该用户的所有现有Kerberos票据可通过klist purge在用户端执行或在AD中强制用户注销。全面调查取证分析对源主机和目标主机进行内存和磁盘取证。重点检查LSASS内存转储、进程列表、计划任务、服务、WMI持久化等寻找攻击工具和持久化后门。日志关联分析集中收集和分析域控制器、受影响主机上的安全日志、Kerberos日志。按照时间线梳理攻击路径何时何地密钥被提取4672、Sysmon事件何时发起异常的Kerberos请求4768何时成功登录到其他主机4624。网络流量回溯如果具备全流量记录分析攻击时间点前后的Kerberos和SMB流量确定攻击的准确时间和范围。修复与加固根据调查结果修复被利用的漏洞如未打补丁实施前述的预防措施如启用Credential Guard、配置受保护用户组并审查和调整域内的账户权限与认证策略。6. 高级技巧与疑难问题排查在实战中你会遇到各种预料之外的情况。这里分享一些进阶技巧和常见问题的排查思路。6.1 当PTK攻击失败时如何排查你按照步骤执行了sekurlsa::pth /aes256:...但弹出的CMD窗口无法访问目标共享。别急按以下步骤排查检查密钥是否正确首先确认你使用的AES-256密钥与目标账户完全匹配。最好从目标用户最近登录过的系统中重新提取一次。验证目标账户加密类型在域控制器上使用PowerShell命令检查目标用户账户如Administrator支持的加密类型Get-ADUser -Identity Administrator -Properties msDS-SupportedEncryptionTypes | Select-Object msDS-SupportedEncryptionTypes如果值为0或未设置可能默认支持所有类型包括AES。但如果明确不包含AES例如只支持RC4那么PTK攻击将失败。你可以尝试使用RC4密钥即NTLM哈希进行“PTK”这本质上就是PTH了。检查时间同步Kerberos协议严重依赖时间同步。确保攻击机跳板机与域控制器的时间偏差在5分钟以内。使用net time \\dc01.lab.local来同步时间。检查DNS解析确保攻击机能够正确解析目标主机的完整限定域名FQDN如WIN-TARGET.lab.local。Kerberos认证严重依赖SPN而SPN依赖于正确的主机名。尝试ping WIN-TARGET.lab.local看是否能解析。使用klist命令查看票据在Mimikatz弹出的新CMD窗口中运行klist。你应该能看到一张以krbtgt/域名为服务名的TGT票据。如果没有说明PTK注入失败。如果有查看其加密类型是否为AES-256。启用Kerberos调试日志在目标客户端或域控制器上启用Kerberos事件日志事件ID 4。这可以详细记录认证失败的原因。但这一步通常需要在攻击前配置属于防御方的排查手段。尝试使用Impacket工具有时Mimikatz在特定系统版本上可能存在兼容性问题。换用Impacket的psexec.py或smbexec.py脚本使用相同的AES密钥再试一次。6.2 在受限环境下的变通方法实战环境往往不是实验室的理想状态。情况一无法直接运行Mimikatz.exe被AV拦截。方法A使用内存加载通过PowerShell反射加载Mimikatz的DLL或者使用类似Invoke-Mimikatz的PowerShell脚本可能绕过静态查杀。方法B使用其他工具使用SafetyKatz、Dumpert等工具先转储LSASS内存然后将转储文件传输到分析机上用Mimikatz离线分析。方法C使用系统自带功能在某些情况下可以通过创建计划任务或服务以SYSTEM权限运行rundll32来加载恶意DLL但这需要更高的技巧和更多的操作痕迹。情况二只有NTLM哈希没有AES密钥。如果目标账户支持RC4你可以直接用NTLM哈希进行PTH攻击。如果环境强制要求Kerberos且账户支持AES你可以尝试“Overpass-the-Hash”的另一种形式使用NTLM哈希作为RC4密钥去申请TGT。在Mimikatz中命令是sekurlsa::pth /user:... /domain:... /ntlm:... /rc4:...。但这要求账户支持RC4加密类型且在现代环境中可能被策略阻止。6.3 关于AES-128与AES-256的选择在sekurlsa::ekeys的输出中你会看到aes256_hmac和aes128_hmac两个密钥。在sekurlsa::pth命令中你可以使用/aes128参数指定AES-128密钥。那么该如何选择优先使用AES-256如果账户同时支持AES-256和AES-128优先使用AES-256密钥。因为它是强度更高的加密类型被所有支持Kerberos AES加密的系统所接受。AES-128作为备选如果因为某些未知原因使用AES-256密钥的PTK失败可以尝试使用AES-128密钥。在极少数老旧的系统或特定配置下可能只支持AES-128。系统如何选择在正常的Kerberos协商中客户端和KDC会协商出一个双方都支持的最高强度的加密类型。在PTK攻击中我们通过手动指定密钥强制使用了某种加密类型。理解PTK密钥传递攻击不仅仅是掌握一个攻击命令更是对Windows域认证体系特别是Kerberos协议深入理解的一把钥匙。它揭示了在看似坚固的密码哈希保护之外另一种长期密钥AES Key同样面临着被窃取和滥用的风险。对于攻击者这是在PTH受阻时的一把利器对于防御者这提醒我们必须构建纵深防御体系从凭证保护、最小权限、加密协议强化和持续监控等多个维度来应对这种隐蔽而有效的横向移动手段。真正的安全源于对攻防双方技术的同等洞察。