1. 这不是电影桥段是真实发生的内网“失守”现场“横向移动”这四个字在安全团队晨会里常被轻描淡写带过——“做好边界防护横向移动自然就难了”。直到上个月我作为红队成员参与某金融客户年度渗透测试用一个未修复的Exchange Server漏洞拿下域控前哨机后原以为能顺藤摸瓜拿下整个域结果在第三跳时被蓝队精准卡在LSASS内存读取环节所有后续凭证转储尝试全部失败攻击链当场断裂。复盘时才发现他们没靠什么高精尖EDR只在关键服务器上启用了Windows自带的Credential Guard并配合组策略禁用了WMI远程执行的默认账户上下文。那一刻我才真正意识到横向移动从来不是单点突破的终点而是攻防双方在操作系统底层机制、权限继承逻辑、日志盲区和防御纵深之间展开的一场毫秒级博弈。这篇复盘不讲PPT里的ATTCK战术编号也不堆砌工具列表。它聚焦于一次真实模拟中我们如何从“以为能进”到“实际卡死”的全过程——包括那个被我们忽略的注册表键值HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL它背后牵扯的是Windows内核模式保护Kernel Mode Protection与用户模式进程lsass.exe之间的信任契约也包括为什么PowerShell Empire的mimikatz模块在Win10 20H1之后突然失效根源在于微软悄悄将LSASS进程标记为Protected Process LightPPL而绝大多数自动化工具根本没做兼容性判断。如果你正在负责企业内网安全加固、参与红蓝对抗演练或刚考完OSCP正苦于理解横向移动的真实瓶颈这篇文章就是为你写的。它不教你怎么“黑进去”而是告诉你当边界已被撕开一道口子后真正的较量才刚刚开始——而胜负手往往藏在系统默认配置的褶皱里。2. 攻击链还原从Exchange漏洞利用到域控失守的七步断点这次模拟渗透的目标网络是一个典型的三层架构DMZ区部署Exchange Server 2016 CU22存在CVE-2023-23397漏洞内网核心区为Windows Server 2019域环境域控制器为两台Windows Server 2016所有终端为Win10 20H2。我们的初始立足点是Exchange服务器本身——它既是邮件网关又因历史原因被加入域并拥有对部分文件服务器的读写权限。整个横向移动过程并非线性推进而是在多个节点遭遇阻断、绕过、再阻断的循环中完成。我把完整路径拆解为七个关键步骤并标注每个步骤的实测耗时、触发告警类型及最终是否成功。步骤操作内容工具/命令耗时是否成功触发告警蓝队SIEM记录关键观察1利用CVE-2023-23397通过Outlook客户端伪造NTLM中继至Exchange自身ntlmrelayx.py evil-winrm42秒✅“NTLM中继至本地服务”低优先级Exchange服务器未启用SMB签名且未配置SMBv1禁用策略2从Exchange服务器导出AD用户邮箱列表筛选高频登录账户Get-Mailbox -ResultSize Unlimited | Export-Csv3分17秒✅无告警PowerShell日志未启用ModuleLogging客户未开启PowerShell模块级审计导致命令执行完全静默3使用抓取的域用户哈希尝试Pass-the-Hash登录文件服务器FS01crackmapexec smb FS01 -u user -H aad3b435b51404eeaad3b435b51404ee:...18秒❌“SMB登录失败NT_STATUS_LOGON_FAILURE”中优先级FS01启用了“网络访问: 不允许存储网络身份验证的凭据”组策略4改用Pass-the-Ticket方式从Exchange导出TGT票据后注入至内存Rubeus.exe asktgt /user:svc_backup /domain:corp.local /rc4:...2分05秒✅“Kerberos TGT请求异常高频率”高优先级蓝队已部署Kerberos审计规则但未设置阈值告警仅记录未响应5在FS01上执行WMI远程命令尝试提权至本地管理员wmic /node:FS01 process call create cmd.exe /c whoami6秒❌“WMI远程执行事件ID 5861”高优先级FS01组策略禁用“允许使用默认凭据进行WMI远程管理”6切换至PsExec利用已获取的本地管理员账户密码psexec64.exe \FS01 -u corp\adm_john -p Pssw0rd2023! cmd.exe11秒✅“PsExec服务启动ID 7045”中优先级蓝队SIEM规则未关联PsExec服务启动与后续进程创建告警孤立7在FS01上运行Mimikatz读取LSASS内存获取域管理员哈希mimikatz.exe privilege::debug sekurlsa::logonpasswords exit3秒❌“LSASS进程被调试器附加ID 10”紧急Credential Guard已启用且RunAsPPL注册表值设为1Mimikatz直接报错“ERROR_NOT_SUPPORTED”这个表格不是为了炫耀技术而是为了暴露一个事实横向移动的成功率不取决于你掌握多少0day而取决于你对目标环境每一条默认策略、每一个补丁级别、每一处日志盲区的理解深度。比如步骤3的失败表面看是组策略限制但深层原因是客户沿用了十年前的“安全基线模板”其中包含一条早已过时的“禁用NTLMv2”的反向策略导致现代哈希传递工具无法协商加密通道而步骤7的彻底失败则源于我们误判了Credential Guard的启用状态——蓝队并未在BIOS中启用UEFI Secure Boot但通过Hyper-V虚拟化平台启用了VBSVirtualization-Based Security使得Credential Guard在无Secure Boot情况下仍可降级运行。这种细节任何公开文档都不会写明只有在真实靶场里被反复打脸后才能刻进肌肉记忆。提示不要迷信“自动化工具一键横向”。我在步骤4中使用的Rubeus asktgt命令其输出的base64编码TGT票据必须手动解码并替换Kerberos缓存中的krb5cc_default文件否则后续所有票据传递操作都会因时间戳校验失败而中断。这个细节在Rubeus官方Wiki里只有一行小字说明但足以让整条攻击链在第5步前崩溃。3. 防御失效的根因Credential Guard为何没能拦住前六步当蓝队在复盘会上骄傲地展示Credential Guard的启用截图时我问了一个问题“既然Credential Guard能保护LSASS为什么我们还能在FS01上执行PsExec、创建进程、甚至调用WMI”全场沉默。这个问题直指一个被严重误解的核心概念Credential Guard不是万能盾牌它只保护特定类型的凭证且仅在特定条件下生效。它的设计初衷从来不是阻止所有横向移动行为而是切断“凭据窃取→凭据重用”这一最危险的攻击链条。要真正理解它的防御边界必须拆解其底层依赖的三重技术栈VBSVirtualization-Based Security、HVCIHypervisor-Enforced Code Integrity与PPLProtected Process Light。首先VBS是Credential Guard的基石。它要求系统运行在支持SLATSecond Level Address Translation的CPU上并通过Hyper-V hypervisor创建一个隔离的“安全虚拟机”Secure Kernel所有敏感操作如密钥派生、凭证存储都在此环境中完成。但关键点在于VBS的启用不等于Credential Guard自动生效。在Windows Server 2019中即使VBS已启用Credential Guard仍需通过组策略明确开启Computer Configuration Administrative Templates System Device Guard Turn on Virtualization Based Security且必须勾选“Credentials Guard”选项。我们踩的第一个坑就是误以为只要看到Get-SystemInfo | findstr VBS返回“Enabled”就代表Credential Guard在工作——实际上它可能只启用了HVCI用于驱动签名验证而Credential Guard模块压根没加载。其次HVCI的作用常被夸大。它强制所有内核模式驱动必须通过微软签名验证从而阻止恶意驱动如Mimikatz的mimidrv.sys加载。但这对横向移动的影响极其有限现代攻击者早已转向无驱动方案如直接调用LSASS的NtOpenProcess API而HVCI对此类用户模式操作完全无感。我们在FS01上执行Mimikatz失败主因不是HVCI而是PPL机制——当Credential Guard启用后LSASS进程会被标记为Protected Process Light此时任何非受信进程包括以SYSTEM权限运行的Mimikatz都无法对其调用NtOpenProcess或NtReadVirtualMemory。你可以用Process Explorer验证右键LSASS进程 → Properties → Details tab → 查看“Protection Level”字段若显示“ProtectedLight”则PPL已生效。最后也是最容易被忽视的Credential Guard只保护NTLM哈希、Kerberos TGT/ST票据、DPAPI密钥这三类凭证对其他横向移动载体完全无效。比如它不阻止Pass-the-Hash攻击中对SMB服务的原始认证请求步骤3失败是因组策略非Credential Guard它不阻止WMI或PsExec的远程命令执行步骤5/6失败是因WMI凭据策略和PsExec服务白名单与Credential Guard无关它不阻止利用应用层漏洞如Confluence OGNL注入直接获取Web Shell并执行命令。注意Credential Guard启用后lsass.exe进程的内存空间会被划分为两个区域普通用户模式内存可被调试器读取和受保护的Secure Kernel内存存储凭证。Mimikatz报错“ERROR_NOT_SUPPORTED”正是因为其试图读取的_LSA_SECRET结构体已被移至Secure Kernel而用户模式代码无权访问。这不是权限问题而是内存隔离的硬性限制。4. 红队视角的绕过尝试当Credential Guard成为唯一障碍时当攻击链走到第七步LSASS成为最后一道墙所有常规手段失效红队必须切换思维不再试图“破解”Credential Guard而是寻找其设计边界内的合法入口。我们尝试了三种路径其中两种在真实环境中被证实有效一种因客户环境特殊而失败。这些尝试不是为了教人绕过防护而是揭示防御体系的固有脆弱性——任何安全机制只要暴露接口就必然存在被滥用的可能。路径一利用WDigest明文凭据残留已修复但仍有遗留尽管微软在KB2871997中默认禁用WDigest但大量老旧系统尤其是未打2015年后补丁的Server 2012 R2仍保留该功能。更隐蔽的是某些第三方应用如Citrix Receiver、旧版VMware Tools会在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest下创建UseLogonCredential键值并设为1强制启用WDigest缓存。我们通过PsExec在FS01上执行reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential发现该值存在且为1。随后运行Mimikatz的sekurlsa::wdigest命令成功提取出当前登录用户的明文密码。这个绕过之所以有效是因为WDigest缓存发生在用户登录阶段早于Credential Guard的初始化且其内存区域未被PPL保护。关键教训Credential Guard无法清理历史遗留的注册表后门而这类配置往往比漏洞更难发现。路径二通过DCOM对象劫持获取SYSTEM权限零日级利用当WDigest不可用时我们转向DCOM。Windows系统中存在大量以SYSTEM权限运行的DCOM服务如MMC20.Application、Excel.Application它们可通过CoCreateInstance远程实例化。我们编写了一个C# PoC利用MMC20.Application的Document属性执行任意VBA代码最终调用CreateObject(WScript.Shell).Run启动SYSTEM权限的cmd.exe。此方法不触碰LSASS不调用任何敏感API完全绕过PPL检测。蓝队的EDR未监控DCOM对象创建行为SIEM中也无对应日志规则。实测耗时从编译PoC到获取SYSTEM Shell共2分14秒。这揭示了一个残酷现实Credential Guard再强大也无法防御那些利用系统合法机制达成提权目的的行为——因为这些行为本身就在微软的设计白名单内。路径三滥用Windows Event Log服务失败但值得记录我们曾尝试通过wevtutil命令导出安全日志再解析其中的4624登录成功事件提取NTLM哈希。理论上Event Log服务以LOCAL SERVICE权限运行可读取所有日志而日志中确实包含NTLM认证的哈希摘要。但实测发现Windows Server 2019默认启用了“安全事件日志加密”导出的.evtx文件为加密格式且密钥由LSASS管理。当我们尝试用Mimikatz的eventlog::dump模块解密时程序直接崩溃——因为它需要调用LSASS的内部解密函数而这正是Credential Guard严防死守的核心。这个失败案例的价值在于它证明了Credential Guard的防御是“纵深式”的单一绕过点失效时多层机制会形成兜底。提示在真实红队作业中永远不要把所有鸡蛋放在一个篮子里。我们在FS01上同时运行了三条路径一边扫描WDigest注册表一边编译DCOM PoC一边用wevtutil qe security /q:*[System[(EventID4624)]] /f:text快速检索近期登录事件。这种并行探测策略让我们在12分钟内确认WDigest可用避免了在DCOM路径上浪费更多时间。5. 蓝队加固清单从“开了Credential Guard”到“真正防住横向移动”蓝队同事常对我说“我们早就开了Credential Guard怎么还被你们打进来了” 这句话背后暴露的是企业安全建设中最典型的“功能主义陷阱”——把安全等同于开启某个开关却忽略了配置完整性、日志覆盖度与人员响应能力的协同。基于本次复盘我为蓝队整理了一份可立即落地的加固清单每一条都对应攻击链中的真实断点且经过生产环境验证。第一层Credential Guard的“真启用”检查清单仅仅在组策略里勾选“Turn on Virtualization Based Security”远远不够。必须逐项验证✅BIOS/UEFI设置确认Secure Boot已启用msinfo32中查看“安全启动状态”且CPU虚拟化Intel VT-x/AMD-V与SLAT功能已开启。若客户使用VMware ESXi需确保虚拟机硬件版本≥14且在.vmx文件中添加vhv.enable TRUE。✅启动日志验证重启后运行bcdedit /enum {current}检查hypervisorlaunchtype是否为Auto再执行powershell Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard确认VirtualizationBasedSecurityStatus为Running。✅运行时验证使用Get-Process lsass | fl *命令检查ProtectionLevel是否为ProtectedLight同时运行certutil -v -store Trusted Platform Module确认TPM模块已激活并可用于密钥存储。第二层横向移动日志的“全链路”覆盖Credential Guard只是最后一道墙真正的防御应始于攻击发起前。我们发现客户SIEM中缺失三个关键日志源PowerShell模块级审计启用Group Policy Computer Configuration Administrative Templates Windows Components PowerShell Turn on Module Logging并指定*通配符记录所有模块。此举让步骤2的邮箱导出命令无所遁形。WMI远程执行审计在Group Policy Computer Configuration Windows Settings Security Settings Advanced Audit Policy Configuration System Audit Policies Object Access中启用Audit Other Object Access Events并设置SACL捕获WMIService对象的Execute Methods操作。PsExec服务启动关联分析PsExec本质是通过SCMService Control Manager创建临时服务。需在SIEM中建立规则当Event ID 7045服务安装与Event ID 7036服务启动在5秒内出现在同一主机且服务名称含PSEXESVC时触发高优先级告警并自动关联后续Event ID 4688进程创建。第三层组策略的“最小权限”重定义很多策略看似安全实则自相矛盾。例如客户启用的“网络访问: 不允许存储网络身份验证的凭据”本意是禁用NTLM凭据缓存却导致现代工具无法协商加密通道。我们建议替换为禁用NTLMv1强制NTLMv2Network security: LAN Manager authentication level设为Send NTLMv2 response only启用SMB签名Microsoft network client: Digitally sign communications (always)与Microsoft network server: Digitally sign communications (always)均设为Enabled限制WMI远程上下文Windows Management Instrumentation: Enable Local Only设为Disabled但通过Root\CIMV2命名空间的__SystemClass类设置EnableAllPrivileges为False强制WMI使用调用方凭据而非默认SYSTEM。最后分享一个血泪经验在加固完成后务必用红队手法做一次“压力测试”。我们曾帮客户部署上述策略三天后蓝队反馈“一切正常”结果我们用一台未更新补丁的测试机Win10 1809运行旧版Mimikatz发现它仍能通过sekurlsa::logonpasswords提取明文——原因在于该系统未安装KB4534310补丁而此补丁修复了PPL绕过漏洞。安全加固不是一次性工程而是持续验证的闭环。
