detection.wiki：Windows 事件目录——1393 个 provider、99722 个事件一查便知

原创

GLM-5.3
GLM-5.3

赛博生存指南

2026年8月24日 22:33
浙江

在小说阅读器读本章

去阅读

写过检测规则的人大概都被同一件事折磨过：想查一个 Windows Event ID 的含义，先翻 Event Viewer 里的说明，语焉不详；再去搜微软文档，Security 日志的事件还能找到，Sysmon、Defender、计划任务这些 provider 的就散落在各处；至于第三方软件往事件日志里写了什么，基本靠撞大运。老牌的 Ultimate Windows Security 事件百科只覆盖 Security 一个日志源，而且常年不更新。

最近发现一个站点把这件事一次做完了：detection.wikihttps://detection.wiki，名字就叫 Windows Event Catalog。截至本文访问（2026-08-24），它收录了 1393 个事件 provider、99722 个事件，首页直接铺开全量 provider 清单，配一个搜索框，点进去按 provider 逐个查看事件定义。不用注册，不用装任何东西。

安全侧的主力都在，数字先看一眼

安全日常真正会打交道的 provider，这个目录全部覆盖，顺手摘几个（括号内是该 provider 的收录事件数）：

• Microsoft-Windows-Security-Auditing (423)——Security 日志本尊，4624/4688/1102 那一族
• Microsoft-Windows-Sysmon (30)——就这 30 来个 ID，撑起了半个检测行业
• Microsoft-Windows-PowerShell (189)——脚本块日志 4104 在此
• Microsoft-Windows-Windows Defender (94)
• Microsoft-Windows-TaskScheduler (148)——计划任务持久化的检测依据
• Microsoft-Windows-WMI-Activity (25)、TerminalServices-LocalSessionManager (47)、DNS-Server-Service (497)、Windows Firewall With Advanced Security (171)、BITS-Client (114)
• 服务侧的 Service Control Manager (91)、WinRM (326)、RdpCoreTS (89)、SMBClient (181)
• 内核遥测的 Kernel-Process (27)、Kernel-File (25)、Kernel-Registry (45)、CodeIntegrity (111)

除了这些熟面孔，更有价值的是那些你可能从没想过去看的：

• 认证协议：NTLM (21)、Security-Kerberos (89)、LsaSrv (87)、Schannel (31)、CAPI2 (74)。做横向移动检测，这几个 provider 的事件面值得整页翻一遍。
• Defender for Endpoint 传感器：SENSE (211) 和 SenseIR (14)。用 MDE 的团队，这里的 ID 直接对应传感器上报面。
• 两个小而锋利的：Security-Mitigations (36)——Exploit Protection 触发事件；Audit-CVE (2)——系统检测到 CVE 利用尝试时的事件。事件不多，但每一个都是高危信号。
• PKI：CertificationAuthority (355)。攻击者滥发证书时，CA 的事件日志比杀软告警来得更直接。

也有体量吓人的：Hyper-V-VMMS 一家 7057 个事件，Shell-Core 2380，IPAM 1735。看一眼就明白为什么没人给 Windows 事件日志写过「完整文档」——只能做成可搜索的数据库。

不只是微软：第三方软件也在这

目录里混着一批非微软 provider：OpenSSH (5)、ScreenConnect (8)、Chrome、Edge、VMware Tools、qemu-ga，还有 Avira 全家。ScreenConnect 这种远控软件的事件 ID 被正经收录，应急时判断「受害者机器上装没装、什么时候连过」就多了一条正经的数据源。另有 SentinelOne (104)、Splashtop 系列、Sophos 驱动等条目标注为 MANIFEST ONLY——即数据只来自清单解析，provider 本身未注册为事件源。

说到 MANIFEST ONLY，这也是这个目录的一个亮点：它把「实际在写日志的 provider」和「只在 manifest 里定义过、从不落日志的 provider」明确分开了。后者数量庞大（光 Microsoft-IE 一家就在清单里定义了 1379 个事件），全是纯 ETW trace 类。对做 ETW 遥测研究的人，这份「定义了但没启用」的清单本身就是个宝库——之前写《深入解析 Windows 遥测》那篇提过，ETW provider 的 manifest 是理解遥测面的钥匙，这里等于把钥匙串直接挂出来了。

三种人三种用法

写检测规则的：写 Sigma 之前先来这里对一遍 provider 全名和 Event ID 的对应关系。provider 名抄错一个字符，规则就永远不命中，这种低级错误每个 SOC 都出过。反过来，翻一翻冷门 provider 的事件定义，往往能找到比 4688 更细的检测面。

做应急溯源的：拿到一条不认识的日志，按 provider 查进来，看它同族还有哪些事件、各自什么语义，顺着把相关日志一次捞全。比搜索引擎快，比 Event Viewer 的本地描述全。

搞攻防对抗的：反着用。想知道自己的动作会踩响哪些遥测，就把 TaskScheduler、WMI-Activity、PowerShell、Security-Mitigations 这几页翻熟——每一行事件定义，都是对面 SIEM 里可能存在的一条规则。OPSEC 的功课，一半是懂 bypass，一半是懂对面的传感器。

用之前记住三件事

一是 收录不等于产生。manifest 里定义的事件，绝大多数在日常机器上从未触发过，Security 日志里的审计事件也要开了对应的高级审核策略（Advanced Audit Policy）才会记录。这个目录是「事件宇宙」的地图，不是你日志量的承诺。

二是 数据是快照。99722 这个数字对应站点的某次采集，Windows 版本更迭会增删事件定义，别把它当实时接口，关键结论自己复核。

三是站点首页没有说明数据采集方法与更新节奏，用的时候留个心眼；好在事件定义本身来自 Windows 官方 manifest，可以直接和系统内 wevtutil、logman query providers 的输出互相印证。

一句话总结：写规则、查日志、做对抗，只要你的工作和 Windows 事件沾边，这个站值得进收藏夹置顶。

参考资源

detection.wiki：https://detection.wikiUltimate Windows Security 事件百科（旧参照系）https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

微软事件监控建议（Appendix L）：https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor