Win7登录调试实战：用WinDbg深度追踪Lsass/Winlogon/LogonUI认证链

简介：本资源是一份面向Windows内核安全研究者与系统调试工程师的深度技术文档，聚焦Win7登录认证机制逆向分析与实战调试方法。内容详述Winlogon动态进程创建、Lsass密码验证流程、RPC调用链路（如SspiCli!LsaLogonUser→SspiSrv!SpirLogonUser）、LogonUI凭证获取（authui!CRequestCredentialsCallbackData::GetCredential）及关键解密点（KerbInteractiveUnlockLogonPack、ADVAPI32!CredUnprotectW），并给出Windbg断点设置、内存读写追踪与堆栈分析等实操路径。资源为单个DOCX文档（384KB），结构完整，含3页图文结合的技术记录，涵盖启动流程观察、SSP接口DUMP、加密参数解析与明文密码捕获全过程。目前已有90人学习下载，适合具备基础驱动调试能力、正开展Windows身份认证机制研究或系统级安全分析的中高级技术人员参考复现。

1. Win7口令登录过程调试：不是改注册表或重置密码，而是把Lsass.exe、Winlogon.exe、LogonUI.exe这三只“黑匣子”拆开看透

你手头有一台还在跑Win7的工业控制终端，它卡在登录界面——输入正确口令后光标闪三下就回到初始框，没报错、没蓝屏、事件查看器里连个4625失败日志都找不到。这时候翻论坛找“Win7忘记密码怎么重置”，只会让你越搞越乱：重置工具会绕过整个登录链，根本看不到问题出在哪一环；用PE进系统改SAM是治标不治本，下次策略更新照样崩。真正要解决的，是登录过程本身在哪儿卡住、为什么卡、谁在拒绝口令校验。这需要你把Windows登录流程当成一个可调试的进程链来看：从用户敲下回车那一刻起，LogonUI.exe把口令传给Winlogon.exe，Winlogon再调用Lsass.exe执行身份验证（MSV1_0、Kerberos、NTLM等子系统），最后Lsass返回Success或Status_Access_Denied。而WinDbg正是唯一能全程跟踪这条链的工具——它不依赖符号服务器（Win7 SP1符号已归档）、不需源码、只要能挂上这三个进程，就能看到口令哈希比对时的内存状态、认证包结构、甚至LSA策略回调的返回值。本文面向的是现场工程师、工控系统维护员、以及需要做合规审计的技术人员：你不需要懂SSPI协议细节，但必须知道怎么让WinDbg在登录前就附着到Winlogon，怎么在LogonUI弹出瞬间捕获认证上下文，怎么从Lsass的LsaApLogonUser调用栈里揪出那个被忽略的STATUS_PASSWORD_MUST_CHANGE错误。这不是教你怎么跳过登录，而是教你亲手把登录失败的“玄学”变成可复现、可断点、可验证的调试事实。

---

2. 搭建可调试环境：Win7 SP1 + WinDbg Preview + 符号路径三件套缺一不可

Win7登录调试最常翻车的第一步，就是环境没配对。很多人直接下载最新版WinDbg Preview，结果一加载Winlogon就报“无法解析符号”，或者断点打在LsaApLogonUser上却永远不命中——因为Win7 SP1的内核和系统DLL符号早已停止更新，微软官方符号服务器（https://msdl.microsoft.com/download/symbols）对Win7的支持仅限于特定补丁集。你必须用WinDbg Preview 1.22.11.1或更早版本（新版默认启用符号缓存验证，会拒绝旧符号），并手动配置符号路径指向本地归档。下面分三步实操：

2.1 下载并安装兼容版WinDbg Preview

提示：不要用Windows Store安装的WinDbg Preview，它会自动升级到不兼容Win7的版本。必须从微软官方归档页下载离线安装包：
https://github.com/microsoft/WinDbg-Symbol-Server/releases/tag/v1.22.11.1
找到WinDbgX_1.22.11.1_x64.msi，双击安装。安装路径建议选C:\WinDbg，避免空格和中文路径导致符号加载失败。

2.2 配置符号路径：本地缓存+微软归档双保险

WinDbg启动后，按Ctrl+S打开符号路径设置，填入以下内容（一行，无换行）：

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols;symsrv*http://msdl.microsoft.com/download/symbols

但仅靠在线符号远远不够。Win7 SP1的lsasrv.dll、winlogon.exe、logonui.exe在2019年后已从微软符号服务器移除。你需要提前下载归档符号包：

• 访问https://github.com/microsoft/WinDbg-Symbol-Server/releases/tag/v1.0.0
• 下载Win7_SP1_Symbols.zip（约1.2GB）
• 解压到C:\Symbols\win7_sp1\
  然后修改符号路径为：

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols;srv*C:\Symbols\win7_sp1*;symsrv*http://msdl.microsoft.com/download/symbols

逻辑说明：WinDbg会按顺序查找符号。先查在线服务器（用于ntoskrnl.exe等内核模块），再查本地win7_sp1目录（专供登录相关DLL），最后 fallback 到旧HTTP地址。symsrv*http://...是为兼容老版符号索引格式，缺它会导致lsasrv.pdb加载失败。

2.3 验证符号是否真正可用：三个关键命令

启动WinDbg Preview，按Ctrl+K打开Kernel Debug对话框，选择Local Kernel Debug（仅用于符号验证，非真内核调试）。在命令窗口输入：

!sym noisy .reload /f lsasrv.dll x lsasrv!LsaApLogonUser

• !sym noisy开启符号加载详细日志，能看到每一步是否成功
• .reload /f lsasrv.dll强制重新加载lsasrv.dll符号（Win7中该DLL由Lsass.exe加载，路径为C:\Windows\System32\lsasrv.dll）
• x lsasrv!LsaApLogonUser查找导出函数地址，成功应返回类似76f8a123 lsasrv!LsaApLogonUser (public)
  如果返回*** ERROR: Module load completed but symbols could not be loaded for lsasrv.dll，说明符号路径或版本不匹配，需检查ZIP包解压层级是否为C:\Symbols\win7_sp1\lsasrv.pdb，而非嵌套多层文件夹。

---

3. 登录过程三进程附着策略：LogonUI抢在图形界面渲染前，Winlogon守在会话切换点，Lsass盯死认证入口

Win7登录不是单进程行为，而是LogonUI（用户界面）、Winlogon（会话管理）、Lsass（安全认证）三者协同完成的管道式流程。调试的关键在于在每个环节触发前就附着进程，否则等你手动打开WinDbg，登录早已失败退出。不能等“输入口令→回车”后再Attach——那时LogonUI已销毁，Winlogon已跳转，Lsass的调用栈也清空了。必须用自动附着+断点预设组合技。

3.1 LogonUI.exe：在GDI渲染前捕获口令明文（非哈希）

LogonUI负责绘制登录框、接收键盘输入、调用Winlogon API提交凭证。它的LogonUI.exe进程在用户会话0中启动，但仅在锁屏或重启后首次登录时存在（正常登录后会被回收）。因此必须用Image File Execution Options（IFEO）强制其启动时挂起并等待调试器：

1. 以管理员身份运行注册表编辑器，定位：
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LogonUI.exe
2. 新建字符串值Debugger，数据设为：
   "C:\WinDbg\winext\exts.dll" -server tcp:port=50000

   注意：这里不是调用windbg.exe，而是用WinDbg的扩展DLL作为调试服务器，避免GUI阻塞。端口50000可自定义。

3. 重启电脑，进入登录界面（此时LogonUI已启动但被挂起）
4. 另开一台机器（或本机另一用户会话），用WinDbg Preview连接：

   File → Connect to a Remote Debugging Session → TCP → Server: localhost, Port: 50000

5. 在WinDbg中下断点：

   bp winlogon!WlxLoggedOnSAS bp logonui!CLogonUI::OnPasswordChanged

   OnPasswordChanged是口令输入框内容变更时触发的函数，断在此处可看到this+0x120偏移处存储的Unicode明文口令（用du poi(@rcx+0x120)查看）。这是唯一能拿到明文口令的环节，后续所有环节处理的都是NTLMv2哈希或Kerberos票据。

3.2 Winlogon.exe：监控会话切换与Lsass调用链

Winlogon是登录流程的“指挥官”，它收到LogonUI提交的凭证后，调用LsaLogonUserAPI交由Lsass处理。但Winlogon本身不校验口令，只负责传递和响应结果。要观察它如何调用Lsass，需在登录前附着：

• 启动WinDbg Preview，按Ctrl+D打开“Attach to Process”
• 勾选Show processes from all users，找到winlogon.exe（PID通常为524）
• 点击Attach，立即下断点：

  bp winlogon!WlxLogonSAS bp winlogon!WlxLoggedOnSAS

  WlxLogonSAS是用户按下Ctrl+Alt+Del或点击登录按钮时触发的入口；WlxLoggedOnSAS是认证成功后执行的回调。断在这两个点，你能看到Winlogon如何构造SECURITY_LOGON_SESSION_DATA结构体，并调用LsaLogonUser（位于secur32.dll中，实际转发给Lsass）。

3.3 Lsass.exe：认证核心，断在LsaApLogonUser看返回码

Lsass是整个链条的终点，也是问题高发区。它加载msv1_0.dll（NTLM）、kerberos.dll（域认证）、wdigest.dll（明文凭据）等认证包。调试Lsass风险最高（杀掉它会导致系统立即蓝屏），所以必须用只读附着+函数级断点：

• 启动WinDbg Preview，Ctrl+D→ Attach tolsass.exe（PID通常为620）
• 输入：

  .effmach x86 # 强制32位模式（Win7 x64的Lsass是WoW64进程） .load wow64exts !wow64exts.sw bp lsasrv!LsaApLogonUser g

  LsaApLogonUser是所有认证包的统一入口，参数AuthenticationPackage决定走哪个子系统（如MSV1_0对应本地SAM）。断在此处，用dd @rsp L0可查看栈上PLSA_CLIENT_REQUEST结构，其中@r8是输入凭证指针，@r9是输出状态码地址。认证失败时，@r9指向的内存会写入0xC000006D（STATUS_LOGON_FAILURE）或0xC000019B（STATUS_PASSWORD_MUST_CHANGE）——这才是真正的失败原因，比事件日志精准十倍。

---

4. 登录失败的五大避坑指南：从符号加载失败到Lsass权限拒绝，每一条都是血泪经验

调试Win7登录过程，90%的问题不出在逻辑，而出在环境配置和权限陷阱。下面五条是我在二十多个工控现场踩过的坑，按发生频率排序，每条都包含现象、根因、可验证的解决步骤：

4.1 现象：WinDbg显示“Unable to get thread context”或断点永不命中

原因：Win7默认启用驱动程序签名强制（Driver Signature Enforcement），而WinDbg的调试驱动kdcom.dll未通过签名验证，导致内核级调试失败。即使你用的是用户态附着，某些Lsass内部调用仍需内核支持。
解决：

1. 重启进入高级启动选项（开机按F8）
2. 选择Disable Driver Signature Enforcement
3. 进入系统后，以管理员身份运行CMD，执行：

   bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS bcdedit /set testsigning on

4. 重启生效。验证：打开设备管理器 → 查看 → 显示隐藏设备 → 展开“非即插即用驱动程序”，确认kdcom状态为“已启用”。

4.2 现象：.reload /f lsasrv.dll成功，但x lsasrv!*Logon*返回空

原因：Win7 SP1的lsasrv.dll有多个版本（KB2533623、KB2829361等），符号包必须与当前系统补丁完全匹配。用错版本会导致PDB文件中的函数名混淆（如LsaApLogonUser被编译为LsaApLogonUser@28）。
解决：

1. 在CMD中执行：

   sigcheck -u -e C:\Windows\System32\lsasrv.dll

   （需提前下载Sysinternals的sigcheck工具）
2. 查看输出中的File version，例如6.1.7601.24545
3. 去微软补丁数据库搜索该版本号，确认对应KB编号（如KB4534310）
4. 下载该KB的独立符号包（非SP1全量包），解压到C:\Symbols\kb4534310\，并在符号路径中加入该目录。

4.3 现象：LogonUI附着后，输入口令时WinDbg无响应，或断点触发后立即崩溃

原因：LogonUI运行在会话0且受UIPI（User Interface Privilege Isolation）保护，普通管理员权限无法向其注入调试代码。强行Attach会触发保护机制，导致进程终止。
解决：
必须用psexec提升到会话0的SYSTEM权限：

psexec -i -s -d "C:\WinDbg\windbg.exe" -pn LogonUI.exe

• -i指定交互式会话
• -s以SYSTEM身份运行
• -d分离模式，避免阻塞LogonUI主线程
  运行后，WinDbg会自动附着到LogonUI，此时再下断点才安全。

4.4 现象：Lsass附着成功，但bp lsasrv!LsaApLogonUser提示“no matching symbol”

原因：lsasrv.dll在Lsass进程中是延迟加载的，首次调用LsaLogonUser时才从磁盘映射。WinDbg附着时该DLL尚未加载，断点无法解析。
解决：

1. 先用lm m lsasrv确认DLL是否已加载（若无输出则未加载）
2. 下内存断点强制触发加载：

   ba e1 "C:\Windows\System32\lsasrv.dll" 0 g

   ba e1是执行断点，当CPU试图执行lsasrv.dll任意指令时中断，此时DLL必已加载
3. 中断后立即执行：

   .reload /f lsasrv.dll bp lsasrv!LsaApLogonUser g

4.5 现象：断在LsaApLogonUser时，@r9指向的状态码为0x0（STATUS_SUCCESS），但登录仍失败

原因：认证通过，但Winlogon在后续WlxLoggedOnSAS回调中检查用户策略失败，例如：

• 用户账户被禁用（userAccountControl & 0x2 == 0x2）
• 密码过期（pwdLastSet < now - maxPwdAge）
• 登录时间限制（logonHours字段禁止当前时段）
  解决：
  在WlxLoggedOnSAS断点处，用dt nt!_TOKEN @rax查看当前线程令牌，重点关注：
• Token->UserAndGroups->Groups->Attributes是否含SE_GROUP_ENABLED
• Token->ExpirationTime是否早于当前时间
• Token->UserAndGroups->Groups->Name是否包含Deny log on locally组
  这些信息比Lsass返回码更能定位策略级拒绝。

---

5. 实战技巧：用WinDbg脚本自动化抓取登录失败的完整调用栈与内存快照

手动一步步下断点、看寄存器、记地址，效率太低。我给自己写了一个WinDbg脚本（win7_login_debug.wds），每次登录失败时，它能在3秒内自动完成：①捕获Lsass中LsaApLogonUser的完整参数结构；②保存认证包原始内存（@r8指向的PLSA_CLIENT_REQUEST）；③导出Winlogon的WlxLoggedOnSAS返回码及令牌信息；④生成带时间戳的HTML报告。这个脚本不是炫技，而是把“登录失败”从“看日志猜原因”变成“看内存定结论”的关键工具。

5.1 脚本核心逻辑与参数说明

脚本基于WinDbg的.foreach和.logopen指令，关键段如下：

// 启动日志记录 .logopen /t "C:\DebugLogs\login_fail_${$date}_${$time}.log" // 当LsaApLogonUser被调用时，自动执行以下操作 bp lsasrv!LsaApLogonUser ".echo *** LsaApLogonUser called ***; .echo Input buffer: @r8; dd @r8 L100; .echo AuthenticationPackage: poi(@r8+0x10); .echo Status code address: @r9; ? poi(@r9); .echo --- Dumping LSA_CLIENT_REQUEST structure ---; dt lsasrv!_LSA_CLIENT_REQUEST @r8; .echo *** Saving raw memory dump ***; .writemem C:\\DebugLogs\\lsa_request_${$date}_${$time}.bin @r8 @r8+0x1000; .echo *** Now break in Winlogon ***; bp winlogon!WlxLoggedOnSAS \"g\"; g"

• @r8是PLSA_CLIENT_REQUEST结构体指针，@r8+0x10存储认证包类型（如MSV1_0为1），@r8+0x18是凭证数据起始地址
• .writemem将认证包原始二进制保存为.bin文件，可用010 Editor直接解析NTLMv2挑战响应
• dt lsasrv!_LSA_CLIENT_REQUEST @r8依赖符号，必须确保lsasrv.pdb已正确加载

5.2 一键部署与触发流程

1. 将脚本保存为C:\WinDbg\win7_login_debug.wds
2. 在WinDbg中执行：

   $$><C:\WinDbg\win7_login_debug.wds

3. 此时所有断点已预设，无需人工干预
4. 故意输错一次口令，WinDbg会自动：
   • 在LsaApLogonUser中断，记录输入缓冲区
   • 继续运行至WlxLoggedOnSAS，记录Winlogon返回码
   • 生成login_fail_20240520_143215.log和lsa_request_20240520_143215.bin
5. 分析日志：搜索poi(@r9)输出，若为0xc000006d，说明口令错误；若为0xc000019b，说明密码过期需重置；若为0xc0000224，说明账户被锁定（lockoutTime非零）

5.3 从内存快照逆向还原NTLMv2哈希（仅限合规审计）

lsa_request_*.bin中@r8+0x18开始的内存块，是MSV1_0认证包的原始数据。用Python解析可还原NTLMv2响应：

# ntlm_parser.py import struct with open("lsa_request_20240520_143215.bin", "rb") as f: data = f.read() # MSV1_0包结构：前4字节是长度，接着是NTLMSSP标识，然后是挑战（8字节）、响应（24字节） challenge = data[0x28:0x28+8] # 标准NTLMv2挑战位置 response = data[0x30:0x30+24] # NTLMv2响应 print(f"Challenge: {challenge.hex()}") print(f"Response: {response.hex()}")

注意：此操作仅用于企业内部合规审计，必须获得书面授权。还原出的哈希可用于离线爆破验证密码强度，但绝不允许外泄或用于未授权系统。

我坚持用这个脚本跑了三年，从电厂DCS到地铁信号机，凡是Win7登录异常，没有一次需要超过两次尝试就能定位到lsasrv.dll里的具体策略拒绝点。它让我彻底告别了“重启试试”“重装系统”的玄学维修时代。希望帮到你。

本文还有配套的精品资源，点击获取