4. Windows日志体系与审计策略

Windows 的日志与审计能力并不是单一机制，而是由多个层次叠加而成。理解这些层次的分工，是后续做异常检测和溯源分析的前提。最上层是传统的事件日志（Event Log），它以 .evtx 文件形式落盘，按通道（Channel）组织，例如 Security、System、Application、Microsoft-Windows-PowerShell/Operational 等。事件日志记录的是“已经发生并被写入通道的事件”，结构稳定、字段规范，是审计取证最常用的数据源。

第二层是 ETW（Event Tracing for Windows）。ETW 是内核级的高性能跟踪机制，提供者（Provider）在运行时发布事件，消费者（Consumer）通过会话（Session）订阅。ETW 覆盖面远大于事件日志，很多事件默认不落盘，只在需要时由工具实时采集。事件日志本质上也可以看作 ETW 的一个消费者，但两者在采集时机、开销和字段丰富度上有明显差异。第三层是 Sysmon，它作为 ETW 消费者和内核回调的组合，把进程创建、网络连接、驱动加载、注册表修改等关键行为以固定 Event ID 写入 Microsoft-Windows-Sysmon/Operational 通道，弥补了默认安全日志在可见性上的不足。

安全审计策略是决定“哪些行为会被记录”的开关。在本地安全策略或组策略中，审计分为九大类：账户登录、账户管理、详细跟踪、DS 访问、登录/注销、对象访问、策略更改、特权使用、系统。每一类可设置为“成功”“失败”或“两者”。一个常见的误区是只开“成功”审计，导致攻击者的失败尝试（如暴力破解、权限提升失败）完全不可见。合理的基线通常是：登录/注销、账户管理、策略更改、特权使用同时开启成功与失败；对象访问按需开启，避免日志量爆炸。

配置方式上，命令行可用 auditpol 工具。例如开启登录/注销的成功与失败审计：

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
auditpol /get /category:"Logon/Logoff"

执行后 auditpol /get 会列出各子类别的当前状态，用于确认策略是否生效。若通过组策略下发，则对应“计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置 → 审核策略”。

在关键事件 ID 方面，安全日志中最值得关注的一组如下。登录相关：4624 登录成功、4625 登录失败、4634 注销、4647 用户发起注销、4648 使用显式凭据登录、4672 授予特殊特权。账户与策略：4720 创建用户、4726 删除用户、4732 添加到本地管理员组、4719 审计策略更改。进程与对象：4688 进程创建（需开启“审核进程创建”）、4657 注册表值修改。Sysmon 侧常用：1 进程创建、3 网络连接、7 镜像加载、11 文件创建、13 注册表值设置。

登录类型（Logon Type）是 4624/4625 事件中极易被忽略但信息量极大的字段。它解释了“这次登录是怎么发生的”。常见取值：2 交互式（本地键盘登录）、3 网络（如访问共享、SMB）、4 批处理（计划任务）、5 服务（服务账户启动）、7 解锁、8 网络明文（如 IIS 基本认证）、9 新凭据（runas /netonly）、10 远程交互（RDP）、11 缓存凭据（域用户离线登录）。

把事件 ID 与登录类型组合起来，就能形成有意义的判断。例如：同一账户短时间内出现大量 4625 且登录类型为 10，说明 RDP 正在被暴力尝试；出现 4624 且类型为 3、同时伴随 4672 特殊特权，可能意味着横向移动后获得了高权限网络会话；出现 4648 且类型为 9，往往与凭据传递或远程管理工具相关。再结合 4688 中记录的父进程与命令行，就能把“谁在什么时间、用什么方式、从哪台机器、执行了什么”串成一条可追溯的链。

需要强调的是，事件日志、ETW、Sysmon 三者不是替代关系，而是互补关系。事件日志提供稳定的审计基线，ETW 提供深度与实时性，Sysmon 提供默认缺失的行为可见性。审计策略则决定这条数据链的起点是否完整。只有三者协同，才能让后续的异常检测既有覆盖面，又有足够的上下文支撑判断。