Sysmon：从原理到实战的 Windows 主机行为监控

Mon, 01 Jan 0001 00:00:00 +0000

Sysmon：从原理到实战的 Windows 主机行为监控

一、Sysmon 是什么

Sysmon 的全称是 System Monitor，是 Microsoft Sysinternals 提供的一款 Windows 主机行为监控工具。安装并启用后，它会持续记录进程创建、网络连接、文件落地、注册表修改、驱动加载、DNS 查询、进程注入等系统活动，并把结果写入 Windows 事件日志。

一句话概括：

Sysmon 是 Windows 主机上的“高精度行为记录仪”，负责留下证据，但不替你判断，也不主动阻断攻击。

它尤其适合以下场景：

安全运营中心（SOC）的终端日志采集；
威胁狩猎与攻击链还原；
勒索软件、木马、横向移动等事件的应急响应；
恶意样本动态行为分析；
关键服务器的变更审计；
将终端遥测统一发送到 WEC、Splunk、Elastic、Microsoft Sentinel 等平台。

Sysmon 不是杀毒软件，也不是 EDR 的完整替代品。它不扫描病毒、不自动生成“恶意/安全”的结论，也不会阻止进程、网络或文件操作。它产生的是结构化的原始遥测，真正的检测能力来自后续的规则、上下文和事件关联。

1. Sysmon、Windows 安全日志与 EDR 的区别

对比项	Windows 原生日志	Sysmon	EDR
主要定位	系统、账户与审计记录	高粒度主机行为遥测	检测、调查与响应平台
进程命令行	依赖审计策略，字段有限	默认提供丰富进程上下文	通常提供
文件哈希	通常没有	支持 SHA256、IMPHASH 等	通常支持
进程关联	PID 可能被复用	提供稳定的 ProcessGuid	通常提供进程树
自动研判	否	否	通常有
主动阻断	否	否	通常有
成本与可控性	系统自带	免费、规则高度可控	多为商业产品

可以把三者理解为：Windows 日志是基础记录，Sysmon 是高保真传感器，EDR 则是在传感器之上加入分析、检测和响应能力的平台。

二、Sysmon 的工作原理

1. 核心组件

经典的 Sysinternals Sysmon 安装后，主要由两部分协作：

系统服务：负责管理配置、接收采集结果并写入 Windows Event Log；
内核驱动：在更接近操作系统内核的位置观察特定系统活动，并且可作为启动驱动较早开始采集。

官方强调，Sysmon 安装后会跨重启常驻，服务以受保护进程方式运行。驱动能够记录启动早期发生的活动，待服务启动后再将相关数据写入事件日志。

从逻辑上看，其数据流如下：

进程、网络、文件、注册表等系统活动
                ↓
       Sysmon 服务与驱动采集
                ↓
        XML 配置进行主机端过滤
                ↓
Microsoft-Windows-Sysmon/Operational
                ↓
  Event Viewer / PowerShell / WEC / SIEM
                ↓
       检测、关联、狩猎与响应

需要注意：微软并未将 Sysmon 的所有底层实现细节定义为稳定接口。因此在工程设计中，应依赖官方事件字段和配置 Schema，而不是假设某个内部回调机制永远不变。

2. 为什么 ProcessGuid 很重要

Windows 的 PID 会循环复用。例如，PID 为 4321 的进程退出后，另一个进程以后可能再次获得相同 PID。如果只用 PID 串联日志，就容易把不同进程混在一起。

Sysmon 在进程创建事件中生成 ProcessGuid，并在网络、文件、进程访问等相关事件中携带它。调查时应优先使用：

`1`	`ProcessGuid + UtcTime + Computer`

进行关联，而不是只看 PID。

此外，ParentProcessGuid、ParentImage 和 ParentCommandLine 可以帮助还原父子进程关系。例如：

WINWORD.EXE
  └─ powershell.exe -enc ...
       ├─ DNS 查询
       ├─ 连接外部 IP
       └─ 在用户临时目录写入可执行文件

单看某条 PowerShell 进程日志未必足以定性，但把父进程、命令行、DNS、网络和文件事件串起来后，行为意图就清晰得多。

3. 事件是证据，不是结论

Sysmon 事件具有三个特征：

观察性：记录“发生了什么”，不解释“为什么发生”；
确定性：某类被启用且通过过滤器的行为会生成相应事件；
可组合性：多条事件关联后，价值远高于孤立事件。

例如，“进程访问 lsass.exe”并不必然代表凭据窃取，杀毒软件、诊断工具和系统组件也可能有类似行为。研判时还要结合源进程、签名、访问权限、父进程、用户、时间线和基线。

三、理解 Sysmon 的事件模型

Sysmon 事件位于：

应用程序和服务日志
└─ Microsoft
   └─ Windows
      └─ Sysmon
         └─ Operational

其完整通道名为：

`1`	`Microsoft-Windows-Sysmon/Operational`

事件时间统一使用 UTC。跨时区调查时不要直接把日志中的 UtcTime 当作本地时间。

1. 最常用的事件 ID

Event ID	事件	主要用途	使用提示
1	Process Create	进程、命令行、父进程、哈希	核心事件，优先采集
2	File Creation Time Changed	文件创建时间被修改	发现时间戳伪造
3	Network Connection	进程级网络连接	默认不开启，数据量可能很大
5	Process Terminated	进程退出	高并发终端上较嘈杂
6	Driver Loaded	驱动加载、签名和哈希	适合发现恶意或脆弱驱动
7	Image Loaded	DLL/模块加载	极易产生海量日志，必须过滤
8	CreateRemoteThread	跨进程创建线程	可辅助发现进程注入
9	RawAccessRead	裸磁盘/卷读取	发现绕过文件层读取
10	Process Access	一个进程打开另一个进程	监控 LSASS 时很有价值，也很嘈杂
11	File Create	文件创建或覆盖	关注下载、临时、启动目录
12–14	Registry Event	注册表创建、删除、写值和重命名	发现持久化和配置篡改
15	File Create Stream Hash	NTFS 备用数据流	可观察 Zone.Identifier 等
17–18	Pipe Event	命名管道创建与连接	IPC、横向工具和恶意组件通信
19–21	WMI Event	WMI Filter、Consumer 和绑定	发现 WMI 持久化
22	DNS Query	进程发起的 DNS 查询	建立域名与进程的联系
23	File Delete	删除文件并归档	便于取证，但需控制磁盘占用
24	Clipboard Change	剪贴板内容变化	关注隐私与数据量，不记录明文内容
25	Process Tampering	进程映像篡改	辅助发现 process hollowing 等技术
26	File Delete Detected	记录删除但不归档	比 Event ID 23 更节省空间
27–28	File Block	阻止特定可执行文件/文件粉碎	需谨慎配置和充分测试
29	File Executable Detected	发现新的 PE 可执行文件	适合追踪恶意载荷落地
4、16	Sysmon 状态/配置变化	监控服务启停和规则变更	不能通过普通事件过滤关闭
255	Sysmon Error	内部错误	应纳入监控，避免“静默失明”

Event ID 不是检测规则。比如 Event ID 3 只说明发生了连接，端口 443 也不代表安全；Event ID 8 可能是注入，也可能是合法软件行为。

2. Event ID 1 示例字段

进程创建事件通常包含：

UtcTime：UTC 时间；
ProcessGuid / ProcessId：进程唯一关联标识和 PID；
Image：可执行文件完整路径；
CommandLine：完整命令行；
CurrentDirectory：工作目录；
User：执行账户；
Hashes：可执行文件哈希；
ParentProcessGuid / ParentProcessId：父进程标识；
ParentImage / ParentCommandLine：父进程路径与命令行；
IntegrityLevel：完整性级别；
RuleName：命中配置规则时写入的规则名。

其中 RuleName 很值得利用。可以在配置中将规则标记为 technique_id=T1059.001,technique_name=PowerShell，使事件进入 SIEM 后直接携带检测语义。

四、安装、验证与卸载

1. 使用 Sysinternals 版本

从微软官方页面下载 Sysmon，解压后以管理员身份打开 PowerShell 或命令提示符。

安装并接受许可协议：

`1`	`.\Sysmon64.exe -accepteula -i`

使用 XML 配置安装：

`1`	`.\Sysmon64.exe -accepteula -i C:\Sysmon\sysmonconfig.xml`

查看当前配置：

`1`	`.\Sysmon64.exe -c`

动态更新配置，无需重启：

`1`	`.\Sysmon64.exe -c C:\Sysmon\sysmonconfig.xml`

输出当前二进制支持的配置 Schema：

`1`	`.\Sysmon64.exe -s`

卸载：

`1`	`.\Sysmon64.exe -u`

安装和正常卸载均不要求重启。

2. Windows 内置可选功能

新版 Windows 还提供内置 Sysmon 可选功能。若当前系统版本已暴露该功能，可在管理员 PowerShell 中执行：

1
2

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon
sysmon -i C:\Sysmon\sysmonconfig.xml

不同 Windows 版本、补丁级别和企业镜像的可用性可能不同，部署前应先在测试机确认：

`1`	`Get-WindowsOptionalFeature -Online -FeatureName Sysmon`

企业环境中不要混装多套 Sysmon 实现。应根据系统支持周期、升级方式和集中运维能力选择一种方案，并固定部署基线。

3. 验证是否正常工作

查看最新 10 条 Sysmon 事件：

1
2

Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 10 |
    Select-Object TimeCreated, Id, ProviderName, Message

只查看进程创建事件：

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} -MaxEvents 20

也可以检查服务：

`1`	`Get-Service Sysmon*`

如果事件查看器中没有日志，应依次检查：

是否以管理员权限完成安装；
服务是否运行；
XML 配置是否通过解析；
过滤规则是否把目标事件排除了；
Operational 日志通道是否启用；
是否存在 Event ID 255 内部错误；
日志最大容量和覆盖策略是否合理。

五、配置文件应该怎么写

Sysmon 使用 XML 配置决定启用哪些事件、记录哪些活动以及排除哪些噪声。配置质量直接决定监控质量。

1. 一个适合实验环境的起步配置

下面的配置用于教学和小规模验证，不建议未经调优直接推送到大量生产终端：

<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <CheckRevocation>true</CheckRevocation>
  <DnsLookup>false</DnsLookup>

  <EventFiltering>
    <!-- 空的 exclude 表示没有事件被排除，即记录全部进程创建 -->
    <ProcessCreate onmatch="exclude" />

    <!-- 记录全部 DNS 查询 -->
    <DnsQuery onmatch="exclude" />

    <!-- 仅关注常见落地目录中的文件创建 -->
    <FileCreate onmatch="include">
      <TargetFilename condition="contains">\Downloads\</TargetFilename>
      <TargetFilename condition="contains">\AppData\Local\Temp\</TargetFilename>
      <TargetFilename condition="contains">\Start Menu\Programs\Startup\</TargetFilename>
    </FileCreate>

    <!-- 关注常见自启动注册表位置 -->
    <RegistryEvent onmatch="include">
      <TargetObject condition="contains">\CurrentVersion\Run</TargetObject>
      <TargetObject condition="contains">\CurrentVersion\RunOnce</TargetObject>
      <TargetObject condition="contains">\Services\</TargetObject>
    </RegistryEvent>

    <!-- 关注对 LSASS 的进程访问 -->
    <ProcessAccess onmatch="include">
      <TargetImage condition="end with">\lsass.exe</TargetImage>
    </ProcessAccess>

    <!-- 记录驱动加载 -->
    <DriverLoad onmatch="exclude" />
  </EventFiltering>
</Sysmon>

Schema 版本应以目标 Sysmon 二进制实际支持的版本为准，可通过 sysmon -s 或 sysmon -? config 检查。不要只因为网上示例中的数字更大，就盲目修改 schemaversion。

2. `include` 与 `exclude` 的逻辑

这是最容易写错的地方：

onmatch="include"：只记录命中条件的事件；
onmatch="exclude"：记录事件，但丢弃命中条件的事件；
空的 <ProcessCreate onmatch="exclude" />：没有排除条件，因此记录全部进程创建；
多个规则如何组合，还会受到 RuleGroup 与 groupRelation="and|or" 的影响。

更新配置后，应主动制造一条可控测试行为，再检查事件是否出现。不要以“命令执行成功”代替对采集效果的验证。

3. 用 RuleGroup 表达组合条件

例如，只记录带 -enc 或 -encodedcommand 参数的 PowerShell：

<RuleGroup name="PowerShell Encoded Command" groupRelation="and">
  <ProcessCreate onmatch="include">
    <Image condition="end with">\powershell.exe</Image>
    <CommandLine condition="contains any">-enc;-encodedcommand</CommandLine>
  </ProcessCreate>
</RuleGroup>

实际生产环境通常不应只记录这类 PowerShell，否则会失去大量基线和上下文。更合理的做法往往是完整保留 Event ID 1，再在 SIEM 侧进行检测；如果日志预算有限，才在终端侧实施更严格的 include 策略。

4. 配置设计原则

一份可维护的 Sysmon 配置应遵循以下原则：

先定义安全目标：想发现凭据窃取、持久化、横向移动，还是收集全量取证数据；
先覆盖高价值事件：Event ID 1、6、11、12–14、22 通常优先级较高；
高噪声事件必须过滤：特别是 3、7、10、17–18；
保留调查上下文：不要只采集“看起来可疑”的命令；
按角色分基线：开发机、域控、数据库服务器不应共用完全相同的排除项；
排除要精确：尽量同时约束路径、签名、父进程、用户等字段；
规则要有名称和版本：便于审计变更、回滚和衡量效果；
先灰度再推广：观察 EPS、CPU、磁盘、网络与 SIEM 成本；
定期回归测试：Sysmon、Windows 或业务软件升级都可能改变日志特征。

5. 是否应该直接使用社区配置

社区项目如 SwiftOnSecurity 的 sysmon-config 和 Olaf Hartong 的 sysmon-modular 能提供优秀起点，但它们不是“下载即完美”的答案。

正确方式是：

社区基线
  → 阅读每条 include / exclude
  → 在测试终端采集
  → 统计事件量与丢失场景
  → 根据资产角色调整
  → 灰度部署
  → 持续版本管理

尤其要审查 exclude 规则。过于宽泛的路径、进程名或签名排除，可能被攻击者借用，形成监控盲区。

六、如何用 Sysmon 做安全分析

1. 快速筛选进程创建事件

PowerShell 返回的 Message 便于人工查看，但不适合大规模结构化处理：

Get-WinEvent -FilterHashtable @{
    LogName  = 'Microsoft-Windows-Sysmon/Operational'
    Id       = 1
    StartTime = (Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message

查找命令行中包含可疑编码参数的记录：

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} | Where-Object {
    $_.Message -match '(?i)powershell.+(-enc|-encodedcommand)'
}

这适合实验和临时排查。生产环境应解析事件 XML 字段或在 SIEM 中查询，避免依赖不同语言系统上的 Message 文本。

查看事件原始 XML：

$event = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id      = 1
} -MaxEvents 1

[xml]$event.ToXml()

2. 场景一：Office 拉起脚本解释器

重点关注：

1
2
3

WINWORD.EXE / EXCEL.EXE / POWERPNT.EXE
    ↓
powershell.exe / cmd.exe / wscript.exe / cscript.exe / mshta.exe

需要关联：

Event ID 1：异常父子进程；
Event ID 22：脚本解释器查询了什么域名；
Event ID 3：连接了什么 IP 和端口；
Event ID 11 或 29：是否落地了脚本或 PE；
Event ID 13：是否写入自启动项。

判断依据不应只是“出现 PowerShell”，而应是罕见父子关系、混淆命令、外联、落地和持久化组成的行为链。

3. 场景二：疑似凭据窃取

重点关注 Event ID 10 中：

`1`	`TargetImage = C:\Windows\System32\lsass.exe`

然后检查：

SourceImage 是否来自临时目录、用户目录或异常工具目录；
源文件是否签名可信；
GrantedAccess 是否对应高权限进程访问；
源进程的父进程、命令行和用户；
同一 SourceProcessGuid 是否还出现驱动加载、文件落地或外联；
该行为是否属于已知的安全软件、备份或诊断基线。

只用 TargetImage=lsass.exe 告警会产生大量误报，因此必须建立合法访问基线。

4. 场景三：注册表持久化

关联 Event ID 12、13、14，重点观察：

\Software\Microsoft\Windows\CurrentVersion\Run
\Software\Microsoft\Windows\CurrentVersion\RunOnce
\System\CurrentControlSet\Services
\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

调查思路：

找到修改注册表的 ProcessGuid；
回查 Event ID 1，确定进程来源、命令行和父进程；
检查注册表值指向的文件；
回查 Event ID 11/29，确认文件何时、由谁创建；
查询哈希、签名和资产范围；
判断是软件安装、运维变更还是未授权持久化。

5. 场景四：用时间线还原攻击链

建议将不同事件统一成以下关联模型：

1
2

主键：Computer + ProcessGuid
辅助键：ParentProcessGuid、UtcTime、User、Hashes、DestinationIp、TargetFilename

一个典型时间线可能是：

10:00:01  ID 1   outlook.exe → winword.exe
10:00:03  ID 1   winword.exe → powershell.exe -enc ...
10:00:04  ID 22  powershell.exe 查询 example.invalid
10:00:05  ID 3   powershell.exe 连接外部地址:443
10:00:07  ID 11  powershell.exe 写入 AppData\Local\Temp\update.exe
10:00:09  ID 1   powershell.exe → update.exe
10:00:12  ID 13  update.exe 写入 Run 键

Sysmon 的价值正体现在这里：每条事件只是积木，ProcessGuid 和时间把积木拼成完整叙事。

七、日志收集与企业部署

单机上可以使用事件查看器和 PowerShell，但企业环境应集中收集。

1. 常见架构

Windows 终端上的 Sysmon
      ├─ Windows Event Forwarding（WEC/WEF）
      ├─ SIEM Agent（Splunk UF、Elastic Agent 等）
      └─ 云日志采集代理
                    ↓
              集中日志平台
                    ↓
       解析 → 规则 → 关联 → 告警 → 调查

2. 部署前需要测量的指标

每类事件的 EPS（每秒事件数）；
单机每日事件量与存储量；
端点 CPU 和内存开销；
日志转发带宽；
日志通道覆盖前可保留的时间；
SIEM 许可或摄入成本；
规则命中率、误报率和调查价值；
Event ID 255 与采集延迟；
不同资产角色的噪声来源。

3. 日志容量配置

默认日志容量可能不足。可查看通道配置：

`1`	`wevtutil gl Microsoft-Windows-Sysmon/Operational`

例如将最大容量调整为 1 GB：

`1`	`wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824`

容量应根据事件速率、离线容忍时间和集中采集间隔计算，而不是机械照抄 1 GB。增加本地容量只能延长缓冲时间，不能代替可靠转发。

4. 配置版本管理

建议将配置放入 Git，并维护：

配置版本号；
适用的资产组；
Sysmon/Schema 兼容性；
每次新增或删除规则的原因；
预期影响的事件量；
测试用例和回滚版本；
发布、灰度和全量部署时间。

同时监控 Event ID 16，确认终端实际加载的配置发生了预期变化。

八、性能、噪声与调优

Sysmon 本身通常很轻量，但“轻量”不是“可以无脑全开”。性能和成本主要取决于事件类型、过滤策略以及终端工作负载。

1. 高噪声来源

Event ID 3：浏览器、代理、容器和后台服务会产生大量连接；
Event ID 7：每个进程可能加载大量 DLL；
Event ID 10：安全软件和诊断软件频繁访问其他进程；
Event ID 11：编译、缓存、浏览器和软件更新会大量创建文件；
Event ID 17–18：系统与应用程序会频繁使用命名管道。

2. 正确的调优步骤

在少量代表性资产上启用候选配置；
连续采集至少一个完整业务周期；
按 Event ID、Image、RuleName、路径、目标端口统计事件量；
找出“量大但调查价值低”的稳定活动；
使用多个字段构造精确排除；
运行攻击模拟和回归用例，验证检测覆盖没有丢失；
灰度发布并持续观察；
定期删除失效排除，防止配置只增不减。

3. 不安全的排除方式

以下规则通常过于宽泛：

排除所有 Microsoft 签名进程
排除整个 C:\Windows 目录
只按进程名排除 powershell.exe
排除所有 443 端口连接
排除某个可被普通用户写入的目录

攻击者可以利用系统自带程序、受信任签名程序、DLL 侧加载和可写目录绕过这类规则。排除条件越宽，越需要明确风险和回归测试。

九、Sysmon 的局限与常见误区

1. Sysmon 不会自动发现攻击

安装成功只代表开始记录，不代表具备检测能力。如果没有日志收集、字段解析、检测规则、资产上下文和响应流程，Sysmon 很容易变成“产生了很多日志，但没人使用”。

2. Sysmon 不能保证记录所有行为

它只记录自身支持、配置启用且未被过滤的事件。配置错误、版本差异、日志覆盖、采集代理故障、对抗性规避或组件异常都可能造成盲区。

3. 正常工具也可能表现得像攻击

PowerShell、WMI、PsExec、远程管理、进程访问和驱动加载都有合法用途。应基于用户、设备角色、父子进程、签名、路径、频率和时间窗口综合研判。

4. 哈希不是信誉结论

相同哈希可以帮助跨主机搜索，同一文件也可能因版本变化而产生不同哈希。合法签名也不代表行为一定安全。哈希和签名是上下文，不是最终结论。

5. Sysmon 本身也需要监控

应关注：

Event ID 4：服务意外停止；
Event ID 16：配置被意外修改；
Event ID 255：内部错误；
日志通道被清空或容量异常；
终端长时间没有心跳或事件；
配置版本与资产组不一致。

“没有告警”有时不是环境安全，而是传感器已经失效。

6. 不要把社区规则当成永久基线

操作系统、浏览器、安全软件和业务应用会变化，攻击技术也会变化。配置必须持续维护，并通过真实事件量和检测用例来验证。

十、推荐的落地路线

如果是第一次部署，可以按以下顺序推进。

阶段一：实验室验证

在虚拟机安装 Sysmon；
开启 Event ID 1、6、11、12–14、22；
使用 Event Viewer 和 PowerShell 熟悉字段；
主动执行进程、DNS、文件和注册表测试；
理解 include、exclude 与 RuleGroup。

阶段二：小范围试点

选择几台不同角色的终端；
引入社区配置作为起点；
统计事件量、性能与噪声；
建立浏览器、办公软件、开发工具和安全软件基线；
验证典型攻击链是否能被还原。

阶段三：集中分析

接入 WEC 或 SIEM；
统一字段解析和时间标准；
使用 ProcessGuid 构建进程与行为关联；
编写高置信度检测规则；
建立告警调查手册。

阶段四：持续运营

配置纳入 Git 和变更审批；
监控 Sysmon 自身健康度；
对排除项做周期复审；
使用攻击模拟做回归测试；
根据资产角色维护不同配置；
衡量规则命中、误报、漏报和调查价值。

十一、总结

Sysmon 的核心价值不在于某一个 Event ID，而在于它能把 Windows 主机上的离散行为转化为可关联的证据：

谁（User / ProcessGuid）
在什么时间（UtcTime）
由谁启动（ParentProcessGuid）
执行了什么（Image / CommandLine）
访问了什么（File / Registry / Process）
连接了哪里（DNS / IP / Port）
最终留下了什么结果（Create / Modify / Delete）

使用 Sysmon 时应始终记住三点：

它是遥测工具，不是自动判恶工具；
配置决定可见性，过滤也可能制造盲区；
真正的检测价值来自事件关联、环境基线和持续运营。

如果只是安装 Sysmon，得到的是更多日志；如果围绕安全目标设计配置、集中采集、关联分析并持续调优，得到的才是一套实用的 Windows 主机行为监控能力。

Windows安全 on 小雨

Sysmon：从原理到实战的 Windows 主机行为监控

Sysmon：从原理到实战的 Windows 主机行为监控

一、Sysmon 是什么

1. Sysmon、Windows 安全日志与 EDR 的区别

二、Sysmon 的工作原理

1. 核心组件

2. 为什么 ProcessGuid 很重要

3. 事件是证据，不是结论

三、理解 Sysmon 的事件模型

1. 最常用的事件 ID

2. Event ID 1 示例字段

四、安装、验证与卸载

1. 使用 Sysinternals 版本

2. Windows 内置可选功能

3. 验证是否正常工作

五、配置文件应该怎么写

1. 一个适合实验环境的起步配置

2. include 与 exclude 的逻辑

3. 用 RuleGroup 表达组合条件

4. 配置设计原则

5. 是否应该直接使用社区配置

六、如何用 Sysmon 做安全分析

1. 快速筛选进程创建事件

2. 场景一：Office 拉起脚本解释器

3. 场景二：疑似凭据窃取

4. 场景三：注册表持久化

5. 场景四：用时间线还原攻击链

七、日志收集与企业部署

1. 常见架构

2. 部署前需要测量的指标

3. 日志容量配置

4. 配置版本管理

八、性能、噪声与调优

1. 高噪声来源

2. 正确的调优步骤

3. 不安全的排除方式

九、Sysmon 的局限与常见误区

1. Sysmon 不会自动发现攻击

2. Sysmon 不能保证记录所有行为

3. 正常工具也可能表现得像攻击

4. 哈希不是信誉结论

5. Sysmon 本身也需要监控

6. 不要把社区规则当成永久基线

十、推荐的落地路线

阶段一：实验室验证

阶段二：小范围试点

阶段三：集中分析

阶段四：持续运营

十一、总结

参考资料

2. `include` 与 `exclude` 的逻辑