Fleet 实战技巧：用 osquery 检测已接受 ProcDump EULA 的 Windows 主机

Fleet 实战技巧用 osquery 检测已接受 ProcDump EULA 的 Windows 主机【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet2021 年 3 月爆发的 Microsoft Exchange 0-day 漏洞事件后被称为 Hafnium 攻击中攻击者被观察到利用 Sysinternals 工具 ProcDump 转储 LSASS 进程内存以窃取凭据。本文基于 Fleet 仓库中的 技术指南讲解如何用一条针对 Windows 注册表的 osquery 查询在全组织范围内快速定位那些注册表中留下已接受 ProcDump EULA痕迹的主机并说明该检测背后的取证原理、Fleet 中registry表的工作机制以及如何在 Fleet 策略Policy中落地这条检测。背景为什么 ProcDump 出现在 Exchange 漏洞利用链里2021 年初攻击者利用当时尚未公开补丁的 Microsoft Exchange 邮件软件漏洞进行大规模入侵。虽然初始入侵手段一度隐蔽但安全公司 Volexity 在事后分析中记录了攻击者驻留post-exploitation阶段使用的一批工具与手法——其中就有 ProcDump。ProcDump 是 Sysinternals 套件中的进程内存转储工具攻击者用它 dump LSASSLocal Security Authority Subsystem Service进程内存从而提取登录凭据。这类事件的排查难点在于如果攻击者用完即删磁盘上可能不会留下 ProcDump 可执行文件本身。但攻击者运行 ProcDump 的过程会在系统里留下更耐久的痕迹这正是下一条检测思路的基础。检测原理EULA 接受记录是半永久的注册表工件ProcDump 首次运行时要求用户接受其 EULA最终用户许可协议接受后会写入一个注册表值HKEY_USERS\用户\Software\Sysinternals\ProcDump\EulaAccepted只要该值存在就说明这台机器上的某个用户账户曾经成功运行过 ProcDump。这个工件的价值在于可清除的少即使攻击者删除了 ProcDump 的 exe 文件注册表值仍会保留带时间戳该键值的mtime修改时间近似等于 EULA 被接受的时间可与攻击窗口做时间关联分析。Fleet 仓库收录的检测查询源自社区检测方案 Recon InfoSec就是围绕这个注册表工件设计的。核心检测查询查找已接受 ProcDump EULA 的主机以下查询在 Fleet 的查询编辑器或 osquery 环境中直接执行即可SELECT datetime(mtime, unixepoch, localtime) AS EULA_accepted, path FROM registry WHERE path LIKE HKEY_USERS\%\Software\Sysinternals\ProcDump\EulaAccepted;逐部分解读片段说明FROM registryosquery 的 Windows 注册表表逐键导出注册表内容WHERE path LIKE HKEY_USERS\%\Software\Sysinternals\ProcDump\EulaAccepted通配符%匹配HKEY_USERS下任意用户前缀覆盖所有用户包括已登录和缓存的用户配置单元datetime(mtime, unixepoch, localtime) AS EULA_accepted把注册表值的mtimeUnix 时间戳格式化为本地时间即为EULA 被接受的时间path输出保留完整路径可从路径中的用户前缀判断是哪个账户运行过 ProcDump返回的每一行对应一台主机上的一条命中EULA_accepted给出接受 EULA 的时间path给出对应的用户注册表路径。若在查询结果中看到了本不该使用 Sysinternals 工具的用户路径或时间点与 Exchange 服务器受攻击窗口吻合就值得进一步取证。深入一层Fleet 中registry表是怎么工作的这条查询依赖 osquery 的registry表。Fleet 仓库的表定义文档 registry.yml 对该表有明确说明Windows 注册表是存储应用程序数据和系统底层配置驱动、安全、服务、用户信息的数据库而registry表正是把注册表数据以 SQL 形式暴露出来主要列包括path键的完整路径、name值名、data值内容和mtime值的时间戳。文档同时指出registry表非常适合用于 Fleet 策略和查询。从 Fleet 内置查询库的实际用法可以印证这一点。例如 standard-query-library.yml 中大量合规检查都基于同一张表屏保/锁屏检查SELECT 1 FROM registry WHERE path HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\InactivityTimeoutSecs AND CAST(data as INTEGER) 1800;防火墙域策略检查SELECT 1 FROM registry WHERE path LIKE HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\WindowsFirewall\DomainProfile\EnableFirewall AND CAST(data as integer) 1;自动更新检查SELECT 1 FROM registry WHERE path LIKE HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate AND CAST(data as integer) 0;这些查询与本文的 ProcDump 检测共用同一套模式以注册表键路径为线索、用LIKE做通配、用data断言具体值。区别只在于合规检查看的是策略键是否符合基线而安全狩猎看的是某个敏感工具是否被运行过。另外registry表是 Windows 专属表。在 Fleet 中把这类查询编排为策略时应标注platform: windows避免在 macOS/Linux 主机上执行后报表不存在类错误——Fleet 内置查询库中的 Windows 策略同样遵循这一约定见 queries.yml 中标注platform: windows的条目。落地为 Fleet 策略把一次性查询变成持续监控上述查询作为一次性排查很有价值但威胁狩猎更好的做法是将其固化为 Fleet 策略让 Fleet 按周期自动在所有 Windows 主机上执行并对未通过的主机告警。参考 Fleet 策略规格文件的通用结构apiVersion: v1/kind: policy/spec可对照 standard-query-library.yml 中的既有策略条目可以这样编写apiVersion: v1 kind: policy spec: name: ProcDump EULA accepted (credential access hunting) query: | SELECT 1 FROM registry WHERE path LIKE HKEY_USERS\%\Software\Sysinternals\ProcDump\EulaAccepted LIMIT 1; description: 检测注册表中是否存在已接受 Sysinternals ProcDump EULA 的痕迹。ProcDump 曾被用于 Exchange 0-day 攻击后 dump LSASS 内存窃取凭据该工件提示主机上曾运行过 ProcDump。 resolution: 核对该用户是否有合法的 Sysinternals 使用需求若属异常检查 mtime 时间窗口内的主机活动并考虑隔离主机。 platform: windows tags: hunting, malware, credential-access注意策略版将SELECT精简为返回单行SELECT 1 ... LIMIT 1——策略只需要判断通过/未通过而排查用的完整版仍保留EULA_accepted时间列供取证。若某台主机此前已因合法运维目的使用过 ProcDumpEULA 痕迹早已存在可在策略结果中结合mtime时间列做豁免判断而不必删除注册表值。检测局限与误报考量把这条检测加入日常监控前需要理解它的证据边界它是运行过的证据不是恶意使用的证据。EULA 只在接受时写入一次mtime之后的任何 ProcDump 使用都不会更新该时间戳。因此EULA_accepted是不早于此时间的下界不能精确定位每次使用。合法使用会造成误报。DBA 排查数据库死锁、内核工程师排查内存问题时都会正常使用 ProcDump。建议结合路径中的用户前缀HKEY_USERS\用户判断使用身份——例如 Exchange/MSSQL 服务器上出现普通应用池账户运行过 ProcDump就明显反常。攻击者可清除该工件。删除EulaAccepted值或整个Sysinternals\ProcDump键即可消除痕迹因此该检测属于高价值但有绕过空间的信号应与进程监控、LSASS 访问审计等手段组合使用。小结本文的核心方法论可以概括为把工具的首次运行副作用如 EULA 注册表键当作持久化取证工件用 osqueryregistry表将其变成可全组织扫描的 SQL 条件再固化为 Fleet 策略持续运行。这一模式并不限于 ProcDump——任何会在注册表留下曾经运行痕迹的敏感工具都可以按同样的思路从 standard-query-library.yml 中学习写法并扩展成自己的狩猎规则。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考