Sysmon 主机遥测

为什么不能只靠 Windows 自带日志

默认的 4688（进程创建）有一个致命缺陷：默认不记录命令行。于是日志里只有 powershell.exe，没有 -EncodedCommand 后面那串 base64——而这恰恰是判断它在干什么的唯一线索。

Sysmon 的价值就是补上命令行（Process Create 事件的 CommandLine 字段），以及一批默认没有的事件类型：网络连接、驱动加载、文件创建时间变更、跨进程内存访问。

Sysmon 不是 Wazuh，两者别搞混

先分清两个东西的角色，这是最容易搞错的一层：

Sysmon          = 日志增强器（装在终端上，产出更详细的事件）
Wazuh           = 收集者与分析器（装在服务端，接收、关联、告警）

关系一句话：Wazuh 读取 Sysmon 的日志。Sysmon 自己不做告警、不做关联、不存历史——它只负责把「进程链、命令行、网络连接」这些细节写进事件日志，剩下的全部交给 Wazuh。两者配合起来，就是一套「低配 EDR 的核心能力」：看得见谁启动了谁、带了什么参数、连去了哪里。

只装 Wazuh 不装 Sysmon，检测能力直接砍半；只装 Sysmon 不收进 Wazuh，日志散在各台机器上，攻击者有充足时间把它删掉。

装在哪

位置	是否安装	说明
终端 PC	必须	每一台 Windows 终端，没有例外
域控服务器	建议	域控上的进程行为同样关键
办公宿主机	看情况	如果是日常办公机，装上；纯运维跳板可以按需

Windows 事件日志（安全、PowerShell、系统）和 Sysmon 日志统一进 Wazuh，不要为 Sysmon 单独建一套收集——两套管道维护成本翻倍，关联分析时还要再对齐一次。

部署

# 下载签名校验过的安装包，用 hash 验证后再装
Invoke-WebRequest https://download.sysinternals.com/files/Sysmon.zip -OutFile Sysmon.zip
Expand-Archive Sysmon.zip -DestinationPath Sysmon
& .\Sysmon\sysmon.exe -accepteula -i sysmon.xml

配置文件用 XML 落地并纳入版本控制，比命令行参数可靠——参数敲错一位不会报错，XML 写错会直接拒绝加载。第一版配置别自己从零写，从社区里经过大量生产验证的公开配置起步（如 SwiftOnSecurity 版本），再按自己的环境裁剪——自己写的第一版必然误报遍地。

最小可用配置

<Sysmon schemaVersion="4.90">
  <EventFiltering>
    <!-- 1：进程创建，带命令行 -->
    <ProcessCreate onmatch="include">
      <Image condition="is not any">C:\Windows\System32\WerFault.exe</Image>
    </ProcessCreate>

    <!-- 3：网络连接 -->
    <NetworkConnect onmatch="include">
      <DestinationPort condition="is any">80,443,445,3389,5985,5986</DestinationPort>
    </NetworkConnect>

    <!-- 5：进程终止（只记关键进程，量大时开） -->
    <ProcessTerminate onmatch="include">
      <Image condition="end with">\lsass.exe</Image>
    </ProcessTerminate>

    <!-- 7：镜像加载 -->
    <ImageLoad onmatch="exclude">
      <Image condition="end with">\system32\*.dll</Image>
    </ImageLoad>

    <!-- 8 / 25：远程线程创建 -->
    <CreateRemoteThread onmatch="exclude">
      <SourceImage condition="end with">\svchost.exe</SourceImage>
    </CreateRemoteThread>

    <!-- 11：文件创建（只记可执行类后缀，量能降一个数量级） -->
    <FileCreate onmatch="include">
      <TargetFilename condition="end with">.exe,.dll,.ps1,.bat,.vbs</TargetFilename>
    </FileCreate>

    <!-- 22：DNS 查询（排除 rdp 相关，量大） -->
    <DnsQuery onmatch="exclude">
      <QueryName condition="end with">_msdcs</QueryName>
    </DnsQuery>
  </EventFiltering>
</Sysmon>

每一条 onmatch="exclude" 都要有对应的 exclude 块，否则那一类事件会被完全丢弃。这是 Sysmon 配置最常见的错误，而且不报错——只是某类事件突然没有了。

事件 ID 速查

ID	事件	为什么重要
1	ProcessCreate	带命令行；核心
3	NetworkConnect	出站连接，能和 Suricata 的流量对上
5	ProcessTerminate	排查「谁杀掉了防护进程」
7	ImageLoad	DLL 侧载的证据
8	CreateRemoteThread	进程注入
10	ProcessAccess	lsass 被访问（凭据窃取）
11	FileCreate	落地了什么
22	DnsQuery	域名请求，横向移动的线索
23	FileDelete	文件被删且无法恢复，通常是清理痕迹

23 出现时基本可以判定有人在抹迹。

与其他日志的拼接

单看 Sysmon 只能说「发生了什么」，要说清「为什么」，需要三个来源对齐：

Sysmon    1    → 进程与命令行（10:12:33 powershell.exe -enc ...）
Security 4624 → 是哪个账号发起的（10:12:30 用户登录成功）
Suricata        → 那段时间这个主机在往外发什么（10:12:20 收到 3.2MB 压缩数据）

时间对齐是前提。域控的日志里有 Event ID 4656（机器时间改变）可以用来验证有没有人在调时间。Sysmon 的时间戳本身不带时区，跨机器比对之前先确认采集端的时区一致。

采集与保留

日志留在本机上的唯一后果是：攻击者有充足时间把它删掉。集中收集是这一整节的最后一步，也是让前面所有配置有意义的一步——Wazuh 的部署方式见平台章节。

保留策略上，本机保留 24 小时足够应急，中心端按月归档。Sysmon 日志量大，本机长期留会撑爆系统盘——这不是理论风险，我第一次部署时 C 盘就是这么满的。