WenGui
一、为什么需要 Sysmon — 从一次 DNS 恶意解析排查讲起
应急场景中，我们或许会遇到这样的情况：网络侧检测到某台内网 Windows 主机在不定时的尝试解析一个已知的恶意域名（比如 C2 域名或 DGA 域名），威胁情报明确判定为高风险，但你登录这台机器后，任务管理器里看不到任何明显异常进程，杀软也毫无反应。你想知道是哪个进程在解析这个域名，却发现 Windows 内置日志在这个问题上几乎是“盲视”的。
Windows 提供的审计策略中，的确可以开启进程创建审计（Event ID 4688）和网络连接审计（Event ID 5156 等），但它们的共同缺陷是无法直接关联 DNS 查询与发起该查询的进程：
进程创建审计的命令行记录不全，；
网络审计事件只能告诉你某个进程访问了某个 IP，不包含域名信息；
DNS 客户端日志（
Microsoft-Windows-DNS-Client/Operational）虽然能记录域名和查询结果，却不记录发起进程的 PID 或路径。
这就造成了一个断层：你看到域名解析请求，却追不到发起它的进程。于是你只好祭出实时抓包，逐个手动 netstat -ano 碰运气，但是恶意域名的请求不是时刻发生的。
而 Sysmon（System Monitor） 的出现，正是为了解决这类行为溯源断层。它是微软 Sysinternals 工具套件中的一款免费工具，以驱动+服务的形式深入 Windows 内核，将系统关键行为（进程创建、网络连接、DNS 查询、文件操作、注册表修改等）记录到 Windows 事件日志中。对于 DNS 恶意解析排查这个具体场景，它提供了 Event ID 22 (DnsQuery) 事件，可以直接告诉你：“哪个进程（含 PID 和完整路径）在什么时间查询了哪个域名”。
二、Sysmon 基础介绍 — 它到底能做什么
2.1 Sysmon 是什么
Sysmon 是 Windows Sysinternals 工具集的一员（与 Process Explorer、Autoruns 等属于同一家族），由微软官方开发和维护，完全免费。它本质上是一个系统活动监视器，通过在内核中安装驱动程序并配合用户态服务，持续采集系统上发生的各类安全相关行为，并将它们以结构化事件的形式写入 Windows 事件日志的 Microsoft-Windows-Sysmon/Operational 通道。
2.2 与 Windows 事件日志的关系
已经开启了 Windows 安全审计策略，为什么还需要 Sysmon？二者的关系是互补而非替代。Windows 安全日志覆盖面广，但细节不足；Sysmon 则针对特定高价值事件提供深度字段。下面列举几个关键区别：
Sysmon 的作用不是让 Windows 安全日志变得冗余，而是填补它最致命的行为上下文缺失（尤其是进程与网络/DNS 的关联）。
2.3 独立版与内置版的选择
从 Windows 11 (部分版本) 和 Windows Server 2025 开始，Sysmon 以可选功能的形式内置到操作系统中。需要了解这两种部署形态的差异：
独立版 (Sysinternals 下载)：需要手动从微软官网下载
Sysmon64.exe，通过命令行安装为服务。拥有最完整的功能和最快的社区更新支持，配置文件语法也有更多灵活特性。内置版 (Windows 可选功能)：通过“设置 → 系统 → 可选功能”添加名为“System Monitor”的组件。优点是作为系统组件跟随 Windows 质量更新升级，操作更简单；缺点是功能同步滞后，且与独立版不能共存，二选一。
本文以下内容均基于独立版 Sysmon 展开，你需要从 Sysinternals 官方页面 下载最新版本。
三、安装与命令行参数完全解读
3.1 下载与安装前的准备
部署 Sysmon 非常简单，几乎没有依赖性，但要注意：
需要管理员权限；
如果系统之前启用过内置版 Sysmon，需先将其卸载，否则独立版安装可能会失败。
3.2 核心命令行参数详解
打开管理员权限的命令行，进入 Sysmon 程序所在目录。最常用的命令格式如下：
sysmon64.exe -accepteula -i config.xml下面逐一解释每个关键参数。
-i [configfile]
安装 Sysmon 服务和驱动。如果不指定配置文件，则安装后会处于“空规则”状态，不记录任何事件。因此，安装时必须同时指定一个有效的 XML 配置文件。
-c [configfile]
更新 Sysmon 的配置文件。当你需要修改过滤规则时，无需重装，直接使用此参数指定新的 XML 文件即可，服务会自动应用新配置。示例：
sysmon64.exe -c updated_config.xml-u
卸载 Sysmon 服务和驱动。卸载后所有 Sysmon 日志仍保留在事件查看器中，但不会再产生新事件。
-accepteula
接受微软软件许可条款。首次安装必须带此参数，否则交互式弹窗可能会阻断自动化部署。
-t [driver]
指定日志驱动类型。默认情况下 Sysmon 使用事件日志驱动 (EventLog)，可通过参数选择其他方式（如使用 SysmonDrv 输出到二进制文件等）。一般无需修改。
-?
查看所有可用参数和相关说明。
3.3 服务管理与状态验证
安装完成后，Sysmon 会以 Windows 系统服务的形式运行，服务名称为 Sysmon 或 Sysmon64（视版本而定）。你可以用以下命令验证状态：
sc query Sysmon如果 STATE 显示为 RUNNING，说明服务正常运行。同时检查 Windows 事件查看器，在“应用程序和服务日志 → Microsoft → Windows → Sysmon → Operational”路径下，应能看到初始日志条目（如 Event ID 16 服务配置更改，或 Event ID 255 服务状态）。
四、配置文件是灵魂 — 从语法到最佳实践
4.1 为什么必须用配置文件
许Sysmon 出厂默认是“全关闭”状态。你需要通过配置一个 XML 文件，明确告诉它以哪些事件类型、哪些过滤条件来记录日志。
4.2 XML 配置文件结构解析
一个典型 Sysmon 配置文件基本骨架如下：
<Sysmon schemaversion="4.90">
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude">
<!-- 排除规则 -->
</ProcessCreate>
<NetworkConnect onmatch="include">
<!-- 包含规则 -->
</NetworkConnect>
<DnsQuery onmatch="include">
<!-- 包含规则 -->
</DnsQuery>
</RuleGroup>
</EventFiltering>
</Sysmon>
关键结构要素说明：
<Sysmon>：根节点，schemaversion需与 Sysmon 版本匹配（如 4.90）。<EventFiltering>：事件过滤部分，所有规则必须包在它里面。<RuleGroup>：规则组，可定义多个。groupRelation="or"表示组内各事件类型的关系（大部分情况用 or）。事件类型标签：如
<ProcessCreate>、<DnsQuery>、<NetworkConnect>、<FileCreateTime>等，对应不同的 Sysmon Event ID。onmatch属性：定义该事件类型的过滤逻辑。有两个值：
include：仅记录与规则匹配的事件；exclude：记录所有事件，但排除匹配规则的事件。
理解这个逻辑至关重要。例如：
如果
<ProcessCreate onmatch="include">里写了Image condition is "cmd.exe"，则只会记录 cmd.exe 的进程创建。如果
<ProcessCreate onmatch="exclude">里写了Image condition is "cmd.exe"，则会记录所有进程创建，但 cmd.exe 的会被过滤掉。
规则条件写在事件标签内部，常见条件字段有：
Image：可执行文件完整路径CommandLine：完整命令行ParentImage：父进程路径User：用户名QueryName：DNS 查询域名（仅 DnsQuery 事件）DestinationHostname：网络连接目标域名（仅 NetworkConnect 事件）
条件可组合使用（用逻辑操作符 and/or），并支持通配符 *。
4.3 社区优质模板推荐
强烈建议从社区的高质量模板开始，避免从零造轮子。
SwiftOnSecurity/sysmon-config
这是目前 Github 上最知名的 Sysmon 配置仓库。它通过 onmatch="exclude" 排除了海量已知的良性系统活动和常见软件行为，达到“记录所有事件，但排除正常行为”的目的。直接使用此模板可以让你的 Sysmon 立即生效，且噪音控制较好。缺点是可能会在你特殊环境中漏掉一些正常但小众的软件活动，需要自定义再添加排除项。
下载后，你可以直接在安装命令中引用它：
sysmon64.exe -accepteula -i sysmonconfig-export.xmlOlaf Hartong/sysmon-modular
这个仓库将配置按 MITRE ATT&CK 技术模块化拆分，更便于根据威胁模型选择性启用。例如你想重点监控凭证窃取，就加载对应模块。
4.4 编写一个最小化配置：只记录 DNS 和进程
针对本文的 DNS 排查场景，我们可以写一个极致精简的配置文件，只开启 DnsQuery 和 ProcessCreate 两个事件，并不过滤（记录所有）：
<Sysmon schemaversion="4.90">
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude">
</ProcessCreate>
<DnsQuery onmatch="exclude">
</DnsQuery>
</RuleGroup>
</EventFiltering>
</Sysmon>
这里我们用了 onmatch="exclude" 但内部不加任何规则，结果就是记录所有进程创建和 DNS 查询。这样的配置在测试环境可以快速验证功能，但在生产中使用时日志量会非常大，建议配合过滤规则优化。
五、读懂 Sysmon 的关键事件 — 以 DNS 溯源为线索
Sysmon 的强大之处在于它定义了近 30 种精细的事件类型，覆盖了从进程创建到内核级行为的方方面面。下面，我们首先重点剖析与 DNS 溯源直接相关的三个核心事件，然后提供一个完整的事件类型速查表，供在日后排查其他威胁时参考。
5.1 核心事件深度解析
Event ID 1 (Process Creation) — 还原进程全貌
进程创建事件提供有关新创建的进程的扩展信息。拿到 ID 22 提供的 PID 只是第一步，要弄清楚这个进程从何而来，就需要此事件提供的丰富上下文：
Image、CommandLine：进程的完整路径和启动命令（这对检测无文件攻击极为重要）ParentImage、ParentCommandLine：父进程的路径及命令行User：以谁的身份运行Hashes：进程文件的哈希值，包含“HashType”字段中注明的算法，可用于威胁情报匹配IntegrityLevel：进程完整性级别ProcessGuid：进程在整个域中的唯一 ID，是关联其他事件的绝佳纽带
通过 PID 关联 Event ID 22 和 Event ID 1，你就能画出：域名 → 进程 → 父进程 → 启动命令的全链路。
Event ID 3 (Network Connection) — 网络连接的补充证据
网络连接事件记录 TCP/UDP 连接，能直接揭示数据外传行为。其突出特点是可以解析目标主机名（字段 DestinationHostname），而不仅仅是 IP。关键字段包括：
Image、ProcessId、ProcessGuid：关联到具体进程Protocol：TCP 或 UDPSourceIp、SourcePort、DestinationIp、DestinationPortDestinationHostname：目标主机名（亮点字段）
此事件默认禁用，会产生大量日志，建议在配置文件中谨慎启用，并与 ID 1 配合使用，以确认解析恶意域名后是否建立了真实连接。
5.2 Sysmon 全事件类型速查表
理解了上述核心事件后，我们扩展到 Sysmon 支持的全部事件类型。下表为微软官方定义的精炼版本，是你在日常监控和应急响应中不可或缺的“字典”。
这张表为你提供了一个全景视图。在无 EDR 环境下，你可以根据威胁模型，有选择地在配置文件中启用这些事件，构建起纵深的行为监控体系。
六、总结
回到本文开头的场景。当一台主机疯狂解析恶意域名，你却一脸茫然时，Sysmon 就是那块掉在你面前的拼图—Event ID 22 直接告诉你发起进程，Event ID 1 帮你还原完整的攻击链，Event ID 3 确认外联。整个过程无需复杂的抓包或在注册表中瞎翻，简单而高效。
应急场景中，或许我们没有 EDR，但我们可以临时使用 Sysmon ，从容揪出那个“偷偷解析恶意域名”的幕后黑手。
参考链接：