1. 项目概述一次关于Windows认证核心的深度探索最近在复盘一些内网渗透测试的案例时我反复思考一个问题当攻击者已经拿到了一台域内服务器的管理员权限后他们下一步最想做什么答案往往是持久化和横向移动。而在这条路径上Windows的本地安全机构LSA Local Security Authority就像一座守卫森严的城堡里面存放着系统认证的“王冠宝石”——各种凭据和密钥。传统的“黄金票据”、“白银票据”攻击已经广为人知但今天我想和大家深入聊聊一个更隐蔽、更底层的技术Skeleton Key万能钥匙。这个技术从2014年被提出至今其绕过LSA保护机制的演进过程本身就是一部精彩的攻防对抗史。对于安全从业者来说理解它不仅能提升攻击视角的深度更能从根本上强化我们的检测与防御能力。这篇文章我将从一个实践者的角度拆解Skeleton Key技术的原理、演进并分享我在实战中总结的检测思路与脚本希望能给正在钻研内网安全的你带来一些新的启发。2. 技术原理深度剖析LSA与Skeleton Key的攻防本质2.1 Windows认证基石LSA子系统与LSASS进程要理解Skeleton Key必须先摸清它的攻击目标——LSA。LSA是Windows安全子系统的核心组件负责本地安全策略、用户认证以及审计日志的生成。我们常说的LSASSLocal Security Authority Subsystem Service进程就是LSA的运行载体。这个进程的内存空间堪称“禁地”里面缓存了当前登录用户的明文密码、NTLM哈希、Kerberos票据授予票据TGT以及用于加密解密的密钥材料。为什么攻击者对此趋之若鹜因为一旦能从这个进程里提取到域管理员的哈希或票据就等于拿到了通往整个域内其他主机的“万能通行证”。因此微软从Windows 8.1/Server 2012 R2开始引入了LSA保护机制RunAsPPL旨在将LSASS进程标记为受保护的进程Protected Process Light, PPL。PPL进程拥有更高的完整性级别普通的管理员权限甚至SYSTEM权限都无法直接对其内存进行读取或注入操作这直接废掉了像Mimikatz的sekurlsa::logonpasswords这类经典凭据提取工具的武功。2.2 Skeleton Key的攻击哲学不窃取而是伪造与直接转储内存的“掠夺式”攻击不同Skeleton Key体现了一种“植入式”的持久化思想。它的核心目标不是把密码偷出来而是在LSASS进程中“开后门”。其基本原理可以这样通俗理解在用户登录进行认证时Windows会使用一系列的动态链接库DLL来验证凭据例如kerberos.dll处理Kerberos认证msv1_0.dll处理NTLM认证。Skeleton Key攻击者利用高权限通常是Debug权限在早期版本中可直接用于绕过PPL向LSASS进程注入恶意代码。这段代码会Hook挂钩这些认证DLL中的关键函数比如密码验证函数。当Hook生效后无论用户输入什么密码只要同时附加上攻击者预设的一个通用密码即“Skeleton Key”例如经典的单字符密码“mimikatz”认证就会成功。而用户的原始密码验证流程依然并行因此正常用户登录不受影响隐蔽性极强。注意Skeleton Key不影响已有登录会话的令牌Token它只作用于新的网络登录认证尝试如通过net use访问共享。这意味着在已登录的服务器上执行命令如dir \\dc\c$可能不受影响但新发起的认证会被拦截。2.3 技术演进史一场围绕PPL的猫鼠游戏Skeleton Key技术的发展主线就是与LSA保护PPL机制的对抗。古典时期2014年前后此时LSA保护尚未默认启用或机制不完善。攻击者利用SeDebugPrivilege特权可以直接向LSASS进程注入DLL。这是Skeleton Key的“黄金时代”实现简单效果直接。Mimikatz的misc::skeleton模块就是这一时期的代表。PPL加固时期Win 8.1/2012 R2之后微软引入并默认开启了LSA保护。拥有SeDebugPrivilege也无法直接打开受PPL保护的LSASS进程进行内存操作。古典Skeleton Key方法失效。驱动级绕过时期攻防进入内核层面。攻击者发现虽然用户态无法直接操作PPL进程但如果有办法加载一个具有足够权限的恶意内核驱动就可以从内核层面移除LSASS进程的PPL标志或者直接操作其内存。这需要管理员权限并能够安装驱动需持有SeLoadDriverPrivilege特权或利用驱动签名漏洞。Mimikatz的mimidrv.sys驱动便是为此而生。利用已知漏洞时期安全研究人员不断发现Windows内核或LSASS自身存在的漏洞这些漏洞可能允许从用户态直接绕过PPL。例如CVE-2015-0001MS15-011等历史漏洞曾被用于此目的。这要求攻击者时刻关注最新的安全公告和利用代码。现代混合与无文件落地时期为了规避基于文件扫描的检测高级攻击者倾向于使用纯内存操作。他们可能结合PowerShell、.NET反射加载、或者直接使用C编写的定制化工具将恶意代码以“无文件”方式注入到LSASS中。同时攻击链可能更加复杂先通过其他手段如Potato系列提权获取足够权限再实施Skeleton Key植入。3. 实操复现从环境搭建到Key植入纸上得来终觉浅绝知此事要躬行。下面我将在一个可控的实验室环境Windows Server 2019域控制器 Windows 10域成员机中演示一次经典的、基于驱动加载的Skeleton Key攻击与利用流程。3.1 实验环境准备与前提条件域控制器 (DC)DC01.contoso.com(192.168.1.10) 运行Windows Server 2019已启用LSA保护默认开启。攻击发起机 (Attacker)一台已取得域管理员权限的域成员服务器SRV01.contoso.com。我们在这台机器上操作。目标验证机 (Target)另一台域成员机CLIENT01.contoso.com用于验证Skeleton Key是否生效。必要工具Mimikatz包含mimikatz.exe和mimidrv.sys驱动文件。请从官方或可信源获取。权限要求在SRV01上当前用户需具备本地管理员权限和调试特权SeDebugPrivilege通常域管理员组成员都具备。同时需要加载驱动特权SeLoadDriverPrivilege默认管理员可能没有需要手动启用或通过工具提权。首先我们检查并启用必要的特权。以管理员身份打开命令行或Mimikatz# 在Mimikatz中检查特权 mimikatz # privilege::debug # 如果返回 ‘Privilege ‘20’ OK’ 则说明已具备Debug特权。 # 启用SeLoadDriverPrivilege如果在本地策略中被禁用 mimikatz # privilege::driver3.2 关键步骤解析驱动加载与Key植入核心攻击分为两大步加载驱动绕过PPL然后注入Skeleton Key。步骤一加载Mimidrv驱动这个驱动的作用是从内核层面“解除”LSASS的PPL保护为我们后续的内存操作铺平道路。# 在Mimikatz中执行确保mimidrv.sys与mimikatz.exe在同一目录 mimikatz # ! # 输出 ‘mimidrv’ 说明驱动加载成功。 # ‘!’ 是 ‘!processprotect’ 的简写其内部会处理驱动的加载和PPL的移除。实操心得驱动加载可能会被安全软件如Windows Defender、EDR拦截。在真实环境中攻击者可能会使用经过混淆、签名的驱动或者利用合法的、带有漏洞的驱动Bring Your Own Vulnerable Driver, BYOVD来达成目的。这一步是检测的关键突破口之一。步骤二植入Skeleton Key驱动加载成功后LSASS的PPL保护已被临时移除仅在本次操作期间此时可以执行经典的Skeleton Key注入。# 注入Skeleton Key设置万能密码为 ‘mimikatz’ mimikatz # misc::skeleton # 成功后会显示 ‘KDC Skeleton key patched’ 等信息。这个命令背后做了几件事在LSASS进程内存中定位到负责加密Kerberos票据的密钥KRBTGT账户的哈希。将该密钥在内存中的副本进行修改使其既能用原哈希解密也能用我们指定的“万能密码”对应的哈希解密。同时它也会Hook NTLM认证路径实现类似的通用密码功能。3.3 攻击效果验证现在我们在攻击机(SRV01)上尝试使用万能密码访问域控制器和另一台成员机。假设域内有一个普通域用户contoso\alice其真实密码我们并不知道。# 使用万能密码 ‘mimikatz’ 和任意已知用户名访问域控制器的C$共享 net use \\DC01\C$ /user:contoso\alice mimikatz # 如果返回 ‘命令成功完成’则证明Skeleton Key生效 # 同样访问另一台成员机 net use \\CLIENT01\C$ /user:contoso\alice mimikatz # 同样应该成功。你会发现即使用户alice的真实密码不是mimikatz认证也通过了。这是因为LSASS中的验证逻辑被我们修改了它同时用真实哈希和万能密码哈希进行验证只要有一个匹配就通过。重要注意事项Skeleton Key是内存持久化一旦服务器重启注入的代码和修改的密钥就会消失需要重新植入。它不影响KRBTGT账户在AD数据库NTDS.dit中的真实哈希因此不会破坏正常的Kerberos功能。4. 检测与防御构建纵深感知体系知其攻方能善其守。Skeleton Key的隐蔽性对防御方提出了很高要求。我们不能只依赖单一特征必须建立多层检测体系。4.1 主机层检测寻找攻击痕迹异常驱动加载监控Sysmon事件ID 6监控ImageLoaded事件特别关注非Windows标准路径如C:\Windows\Temp\、用户临时目录下加载的.sys驱动文件。mimidrv.sys是一个明确特征。PowerShell命令定期扫描已加载的驱动列表寻找可疑项。Get-WmiObject Win32_SystemDriver | Where-Object {$_.State -eq Running} | Select-Object Name, PathNameLSASS进程内存与模块检测异常DLL注入检查LSASS进程加载的DLL列表是否存在非C:\Windows\System32或C:\Windows\SysWOW64路径下的DLL。Skeleton Key的早期版本需要注入DLL。tasklist /m /fi imagename eq lsass.exe进程句柄与权限监控哪些进程以PROCESS_VM_WRITE或PROCESS_VM_OPERATION权限打开了LSASS进程。除了合法的安全产品如杀软、EDR其他都应视为高度可疑。认证日志分析Windows事件日志事件ID 4624登录成功虽然Skeleton Key认证会成功但可以关注登录类型Logon Type。大量的网络登录Logon Type 3成功事件尤其是来自单台主机针对多台主机的、使用相同用户名但可能非正常时间的行为值得警惕。事件ID 4672特殊权限分配特别关注SeDebugPrivilege和SeLoadDriverPrivilege的启用事件。在非管理维护时段这些事件可能是攻击前兆。4.2 网络层与域层检测Kerberos协议异常Skeleton Key修改了内存中的KRBTGT密钥但域控制器KDC颁发的TGT票据本身仍然是使用真实KRBTGT哈希加密的。因此从网络流量层面直接检测加密票据内容异常非常困难。间接方法可以部署能够解密Kerberos流量的检测设备需配置域账户密钥但成本较高。更实用的方法是监测认证频率和模式异常。域控制器基线监控KRBTGT账户密码更改定期如每30天更改KRBTGT账户密码两次这是微软官方推荐的方法用于清除黄金票据攻击的影响同样能清除内存中的Skeleton Key因为新的密钥会覆盖内存中的旧值。监控KRBTGT账户的密码修改事件事件ID 4724。DCSync异常请求攻击者在植入Skeleton Key前后可能会尝试使用DCSync攻击来获取其他用户的哈希以进行横向移动。监控域控制器上的事件ID 4662关注对DS-Replication-Get-Changes和DS-Replication-Get-Changes-All权限的敏感使用。4.3 主动防御与加固建议强化LSA保护确保所有关键服务器尤其是域控制器的LSA保护RunAsPPL已启用。可以通过组策略计算机配置 - 管理模板 - 系统 - 本地安全机构 - 启用 LSA保护来强制实施。考虑启用Credential Guard适用于Windows 10/11和Server 2016。这是基于虚拟化的安全VBS功能能将LSASS隔离在安全的虚拟容器中使传统的内存转储和注入攻击包括部分驱动攻击彻底失效。这是对抗Skeleton Key的终极武器之一。最小权限原则与攻击面减少严格限制域管理员组的成员数量并为管理员账户实施“仅允许交互式登录”等限制策略。在非域控制器服务器上移除不必要的SeDebugPrivilege和SeLoadDriverPrivilege。实施受限制的管理员模式防止凭据在网络中明文传输或缓存在远程系统。应用程序控制与驱动黑名单使用Windows Defender应用程序控制WDAC或第三方解决方案只允许运行经过签名的、授权的驱动和可执行文件。维护一个已知恶意驱动如mimidrv.sys的哈希黑名单并通过安全软件进行拦截。5. 实战排查与应急响应脚本指南当怀疑内网中存在Skeleton Key攻击时作为安全工程师你需要一套快速的排查流程。以下是我在应急响应中常用的一些命令和脚本思路。5.1 快速排查清单你可以编写一个PowerShell脚本在可疑服务器上自动执行以下检查# 1. 检查LSASS进程的完整性级别PPL状态 Get-Process -Name lsass | Select-Object ProcessName, Id, {NIntegrityLevel; E{ (Get-Process -Id $_.Id).IntegrityLevel }} # 如果IntegrityLevel显示为‘System’而非‘Protected’则PPL可能被禁用或绕过。 # 2. 检查LSASS进程加载的模块 $lsassId (Get-Process -Name lsass).Id Get-Process -Id $lsassId -Module | Where-Object {$_.FileName -notlike $env:windir\*} | Select-Object FileName, ModuleName # 3. 检查近期加载的非微软签名驱动 # 需要管理员权限且可能需借助Sysmon日志或ETW追踪此处为简化检查思路 # 可以对比 driverquery /fo list 的输出与一个已知干净基线。 # 4. 检查特殊权限使用日志需从事件日志中查询 # 查找最近24小时内的事件ID 4672 (Special privileges assigned) Get-WinEvent -FilterHashtable {LogNameSecurity; ID4672; StartTime(Get-Date).AddHours(-24)} | Where-Object {$_.Properties[3].Value -in (SeDebugPrivilege, SeLoadDriverPrivilege)} # 5. 尝试使用万能密码进行本地测试谨慎操作可在隔离环境进行 # 这是一个主动验证步骤不建议在生产环境直接运行。 # net use \\127.0.0.1\IPC$ /user:域名\任意已知用户名 mimikatz 2$null # if ($LASTEXITCODE -eq 0) { Write-Host 警告Skeleton Key可能已植入 -ForegroundColor Red }5.2 遭遇攻击后的应急步骤立即隔离受影响主机特别是域控制器应从网络中断开防止攻击者利用万能密码进行横向移动。重置KRBTGT账户密码在隔离的、可信的环境下按照微软官方流程对KRBTGT账户密码进行两次更改。这是清除Skeleton Key影响的最有效方法。第一次更改会使其失效第二次更改是为了清除可能被攻击者窃取的哈希历史。全面清查以被入侵的域控制器为起点审查所有域管理员账户的登录记录、DCSync操作记录检查其他服务器是否存在类似异常驱动加载或LSASS注入迹象。根除与恢复找出初始入侵点并修复如修补漏洞、更改被泄露的凭证。在确认所有威胁已清除后再将域控制器恢复上线并密切监控后续认证活动。加固事后务必实施前面提到的Credential Guard、强化LSA保护、应用程序控制等加固措施。Skeleton Key技术像一枚精巧的“内存蛀虫”它提醒我们在网络安全领域权限的取得往往只是开始在核心进程内存中维持一个隐蔽的后门才是高级攻击者追求的目标。防御的重点也从简单的边界防护转向了对操作系统核心安全机制如PPL的信任保护和深度行为监控。理解这项技术的每一个细节不是为了成为更厉害的攻击者而是为了能构建起更早感知、更快响应、更难以被穿透的防御体系。真正的安全源于对攻防两端最底层逻辑的透彻认知。