Sysmon 与 Windows 日志聚合

关键词：Sysmon、事件聚合、Windows Event Forwarding、进程创建、配置驱动 难度：进阶 前置知识：事件日志结构（03）、注册表取证（02）

一、概述

自带事件日志撑不起入侵检测。缺陷有两头：

1. 默认什么都不记。4688（进程创建）要先开「审计进程创建」，而 Windows 默认不开。命令行、哈希、父子链，一样都没有。
2. 记了就留不住。日志定长循环覆盖，Security 默认 20 MB，活动多的机器几小时就冲干净。

Sysmon（Sysinternals 的工具）以驱动形式常驻内核，把进程创建（带完整命令行与哈希）、网络连接、DLL 加载、注册表操作写进独立通道 Microsoft-Windows-Sysmon/Operational。

这一篇解决三件事：它记什么、怎么配（配错等于没开）、怎么集中采集（把易覆盖的日志变成远端副本）。

在取证流程中的位置：本篇横跨部署期与取证期两个阶段，这一点和同板块其他文章不同。取证期它是一次性证据解析（导出 .evtx 后离线分析，与 事件日志深度分析 的方法完全一致）；部署期它是一套需要提前落地的采集设施，错过事发时点就永远补不回来。所以如果检材上没有 Sysmon 通道，本篇第三章第 3 步（确认是否部署）会在 30 秒内给出阴性结论，然后你在第四章第 1 组里找替代路径——这时 Sysmon 相关的所有结论都不成立，必须换成原生日志加 MFT 加 Prefetch 的组合。上游依赖是事件日志的解析基础与注册表持久化位置（注册表取证），Sysmon 事件 12/13/14 的判读直接建立在 Run 键与服务键的知识上。

本篇处理的证据形态，是一个通道加一份 XML 配置：

配置文件是本篇最容易出事的地方：一个 <ProcessCreate> 里既能写 <Image path="...">，也能写 <CommandLine condition="contains"> 和 <ParentImage>，条件之间是与关系，<Image> 支持 is / contains / begin with / end with 及 exclude 变体。排除项写错一个进程名，就等于给它开了一扇免检门——第二章会把这套匹配语义讲透。

本篇能回答什么：某个时间窗内系统上执行过哪些程序、命令行与哈希是什么、父子链是否合理、DNS 与出站连接指向哪里、注册表持久化位置被写过什么、文件创建时间是否被篡改、某个进程是否被远程线程注入。

本篇不能回答什么：Sysmon 没有部署就是没有，此时所有阴性结论都不成立，而且原生日志无法补上缺失的部分——4688 不带哈希，SRUM 的粒度与保留期都不同。Sysmon 是存在性日志：它只记录"配置范围内发生过的事件"，配置里被 <exclude> 掉的对象等于不存在，而且被排除的记录不会留痕，你事后无法判断某类事件是没发生还是被过滤了。日志被清空或被配置改成不记录后，仍会继续产生"正常"的新事件——只有时间戳断层，没有"清空"这个事件本身。另外命令行与哈希证明的是"这样一件程序跑起来了"，证明不了它做了什么，后续行为要看文件、注册表、网络三类事件；GrantedAccess 判读也不能替代对目标进程内存的实际分析。

读者前提：需要先掌握 .evtx 的导出与字段解析（能读 EventData 的 XML 结构、知道 Properties 集合只给值不给字段名这件事），否则拿到 Sysmon 日志也只能干瞪眼；需要理解 LogonId 与 ProcessGuid 这两个关联字段的含义——前者把事件挂到登录会话上，后者把同一进程的多条事件串起来，这一步做不对，父子链和注入结论全部断裂；还需要知道审计策略与 Sysmon 过滤器是两套独立的开关，前者管原生日志，后者管 Sysmon，两者不通。

二、核心原理

2.1 Sysmon 的工作方式

sysmon.exe（用户态 CLI） → 发送配置 XML → SysmonDrv.sys（内核驱动）
                                              ↓ ETW
                        Microsoft-Windows-Sysmon/Operational.evtx

• 驱动在系统调用层捕获行为；用户态进程本身是攻击面（rootkit 可挂钩它）。
• 配置是 XML，经 sysmon.exe -c config.xml 下发。配置变更通常需要重启（是否支持热重载以实际版本为准）。
• 日志落在 C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx（注意 %4 是通道分隔符的编码，勿漏）。

推论只有一条，但很实用：Sysmon 日志和 Security 是两个独立文件。wevtutil cl Security 清不掉 Sysmon 日志。只清了 Security 的攻击者若没意识到 Sysmon 存在，就等于把最高质量的那份证据留在了原地。

2.2 ★ 事件 ID 清单

Sysmon 沿用 WMI 事件编号（1–25），但不是每个编号都会产生数据，集合还随版本变。下面按取证价值分类。

报告中必须写明所用的 Sysmon 版本与 schemaVersion。

A. 进程与线程（最核心）

B. 文件、镜像与内核

2.3 与原生日志的互补关系

没有任何单一工件能证明入侵。Sysmon 的价值在与原生日志互补：

LogonId 是整篇的关联枢纽。4624 告诉你「用户 X 在 23:12 以类型 3 登录，LogonId=0x3E7」，Sysmon 事件 1 告诉你「这个 LogonId 下启动了哪些进程」。把两者按 LogonId 串起来，得到的是一条完整的攻击会话。

2.4 集中化采集：为什么必须转发

单机 Sysmon 日志照样会被覆盖——上限有限，而攻击者只要知道通道名就能清。

所以企业环境的做法是双写：

Sysmon 驱动
    ├─→ 本地 .evtx（缓冲，便于单机取证）
    └─→ Windows Event Forwarding（WEF）→ 远程订阅源（日志服务器 / SIEM）

WEF 是 Windows 内置的转发机制：日志通道订阅 Microsoft-Windows-Sysmon/Operational，经 WinRM 推给远程 Collector，终端上不用装 EDR agent。

取证上的意义很直接：只要日志已经推到远端，本地被清空也不影响结论。

三、操作步骤

3.1 第 1 步：先确认系统是否部署了 Sysmon

这一步必须最先做。绝大多数终端默认没有 Sysmon，查不到不是异常。

# 活系统：查通道是否存在及其上限
Get-WinEvent -ListLog 'Microsoft-Windows-Sysmon/Operational' -ErrorAction SilentlyContinue |
  Select LogName, RecordCount, FileSize, MaximumSizeInBytes, LogMode

# 离线：从镜像定位日志、驱动与用户态程序
fls -o 2048 -r -p /work/DigiForensics.dd | grep -i 'Sysmon'
# → /Windows/System32/sysmon64.exe            （Win8+ 无 32 位版）
# → /Windows/System32/drivers/SysmonDrv.sys
# → /Windows/System32/winevt/Logs/Microsoft-Windows-Sysmon%4Operational.evtx

3.2 第 2 步：配置 Sysmon（现场部署的正确做法）

配置不当等于白开：默认配置只记事件 1 和 6，网络、注册表、DNS 全无。

<Sysmon schemaVersion="4.60">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <CommandLine condition="is not contains">\WmiPrvSE.exe</CommandLine>
    </ProcessCreate>
    <NetworkConnect onmatch="exclude">
      <DestinationIp condition="is any of">127.0.0.1;192.168.0.0/16;10.0.0.0/8;172.16.0.0/12;fe80::/10;::1</DestinationIp>
    </NetworkConnect>
    <FileCreate onmatch="exclude">
      <TargetFilename condition="is any of">%SystemRoot%\Prefetch\*;%SystemRoot%\Temp\*</TargetFilename>
    </FileCreate>
    <RegistryEvent onmatch="exclude">
      <TargetObject condition="is any of">\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\*</TargetObject>
    </RegistryEvent>
  </EventFiltering>
  <Hashes>sha256,sha1,md5,imphash</Hashes>
  <ProcessAccess onmatch="exclude">
    <GrantedAccess condition="is any of">0x1000;0x1010;0x100000;0x100010;0x100020;0x100038</GrantedAccess>
  </ProcessAccess>
  <FileCreateStreamHash>on</FileCreateStreamHash>
  <DNSQuery onmatch="exclude">
    <QueryName condition="is any of">\*.microsoft.com;*.windowsupdate.com;*.msftconnecttest.com</QueryName>
  </DNSQuery>
</Sysmon>

sysmon64.exe -accepteula -i Sysmon.xml     # 安装并加载配置
sysmon64.exe -c Sysmon.xml                 # 更改配置（部分版本需重启）
sysmon64.exe -d                            # 卸载（先归档日志！）
sysmon64.exe -h                            # 版本与支持的 schema
sysmon64.exe -z                            # 检查配置是否被 hash 锁定
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:268435456   # 调大到 256 MB

⚠️ 不调大日志上限，繁忙终端的 Sysmon 日志同样会被循环覆盖。

3.3 第 3 步：解析 Sysmon 日志

# 3.3.1 转 CSV：EventData 字段名成列，便于统计
EvtxECmd.exe -f C:\evidence\Sysmon.evtx --csv C:\evidence\sysmon_out
# → Sysmon_Operational.csv，列为 TimeCreated / Id / Image / CommandLine /
#   ParentImage / User / Hashes / TargetFilename / DestinationIp ...

# 3.3.2 活系统直查：★ 用 ToXml 按字段名取（见第 03 篇）
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} -MaxEvents 5000 |
  ForEach-Object {
    [xml]$x = $_.ToXml(); $d=@{}; $x.Event.EventData.Data | %{ $d[$_.Name]=$_.'#text' }
    [pscustomobject]@{ Time=$_.TimeCreated; Image=$d['Image']; Cmd=$d['CommandLine'];
                       Parent=$d['ParentImage']; Hashes=$d['Hashes'] }
  } | Format-Table -AutoSize -Wrap

核心查询场景（CSV 版，列号以实际表头为准）：