Windows 安全审核策略与事件日志排查实务 ── 成为看得懂 4625 的信息系统人员

「从昨晚开始某个账户就一直在反复被锁定，请帮忙查一下原因」「想确认是否有人在尝试用离职员工的账户登录」「这台服务器，能查到什么时候谁执行了什么操作吗？」── 这些都是中小企业的信息系统负责人，或是向客户交付系统的开发者，某天突然会接到的请求。而这时能依靠的救命稻草，就是 Windows 的 Security 事件日志。

然而实际打开事件查看器后，等待着我们的往往是两种现实之一：想看的事件根本没有被记录（审核策略没有启用），或者被淹没在海量事件中根本读不下去（噪音充斥、日志臃肿不堪）。安全审核这种东西「只要启用就能记录」，但如果不设计好录什么、录到什么程度，真到关键时刻也派不上用场。

本文将基于截至 2026 年 8 月的第一手资料，整理审核策略的运作机制（基本与高级两大体系）、中小规模环境下至少应启用的子类别、4624/4625/4740/4688 等常见事件 ID 的解读方法、Security 日志的容量设计，直至用 PowerShell 排查的方法。如果说本站此前发布的NTLM 审核、SMB 签名、BitLocker、防火墙等文章讲的是「筑牢防线」，那么本文讲的就是「让事后能够确认发生了什么」，是把这些内容串联起来的续篇。

1. 先说结论

• 审核策略分为「基本」和「高级（Advanced Audit Policy）」两大体系，二者不能混用。微软明确指出，同时使用两者会导致审核结果出现无法预期的状态。请统一使用高级一侧（40 多个子类别）。¹
• 确认当前状态用 auditpol /get /category:*。无论来源是 GPO 还是本地设置，都能一览当前实际生效的审核配置。²
• 「全部启用」是绝对不能做的事。启用会产生海量事件的子类别，会让真正重要的事件被淹没在噪音中，还会影响性能。请以微软的基准建议为起点，只追加真正需要的部分。³⁴
• 登录成功是 4624，登录失败是 4625。4624 通过登录类型（Logon Type）（2=交互式、3=网络、10=远程桌面等）来区分「这是一次什么样的登录」。⁵
• 4625 可以通过 Status/Sub Status 代码判断失败原因。常见的有 0xC0000064（用户名不存在）、0xC000006A（密码错误）、0xC0000072（账户已被禁用）、0xC0000234（账户被锁定中）。⁶
• 事件「记录在哪台机器上」是确定的。4624/4625 记录在被访问的一侧机器上，而凭据验证（4776）和 Kerberos 预身份验证失败（4771）则记录在域控制器上。看错机器就会误判为「没有日志」。⁶⁷⁸
• Security 日志的「容器设计」（最大大小与保留方式）占了一半的分量。如果保留方式是覆盖模式，旧事件就会被逐步清除。请用 Get-WinEvent -ListLog Security 确认最大大小与记录数，再根据所需的保留天数反推扩容。⁹¹⁰
• 进程创建（4688）的命令行记录功能虽然强大，但代价是机密信息会以明文形式留在日志中。启用前请先检查各类脚本。¹¹¹²

2. 审核策略基础 ── 不要混用「基本」与「高级」

Windows 的审核策略分为两大体系。¹

• 基本审核策略：位于「本地策略 > 审核策略（Local Policies > Audit Policy）」下的 9 个类别设置，是早于 Windows Vista 就存在的旧体系。
• 高级审核策略（Advanced Audit Policy Configuration）：位于「安全设置 > 高级审核策略配置（Security Settings > Advanced Audit Policy Configuration）」下的 40 多个子类别设置。它把基本策略的 1 个类别拆分成多个子类别，例如基本策略中的「审核账户登录事件」这一项，在高级一侧就对应着 4 个子类别。在基本一侧启用 1 个类别，等同于把对应的全部子类别一次性启用，会连同不感兴趣的事件一起大量记录下来。¹

重要的是，这两大体系并不兼容。微软明确指出：「不要同时使用基本与高级两种策略，否则审核结果会出现无法预期的状态」。通过组策略应用高级审核策略后，该计算机原有的审核设置会先被清除，再应用高级一侧的设置，此后就只能可靠地通过高级一侧进行控制。在使用高级审核策略的环境中，应启用安全选项「审核：强制审核策略子类别设置（Windows Vista 或更高版本）以覆盖审核策略类别设置（Audit: Force audit policy subcategory settings to override audit policy category settings）」，防止基本一侧的设置反过来覆盖高级设置（独立计算机默认已启用此设置）。¹⁴

确认当前状态只需一条命令，请在管理员命令提示符中执行。²

rem 按子类别列出当前实际生效的审核设置
auditpol /get /category:*

rem 变更前的备份(CSV)与还原
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol 的输出，无论来源是 GPO 还是本地设置，反映的都是「最终实际生效的策略」，也可以用来核对「GPO 应该已经下发的设置为什么没有生效」这类问题。此外，审核设置本身一旦被更改就会记录事件 4719，因此「审核不知不觉间被关闭了」这种情况事后也能追溯。¹²

3. 至少应启用的子类别判断表

「先全部启用再说」是一步坏棋，理由很明确。举例来说，如果连特权使用类子类别的成功事件也一并审核，微软警告称事件量会变得极其庞大，导致难以从中找到其他条目，还会对性能造成影响。⁴ 日志容器（第 5 章）的容量是有限的，录入的噪音越多，真正需要的事件能保留的天数就越少。审核设计的本质，是决定「不录什么」。

微软针对工作站与服务器分别公开了基准建议与强化建议，可以作为出发点。³ 在此基础上，从中小规模环境「发生事件时至少要能查到这些」的角度整理出下表。

反过来，文件系统与注册表的对象访问审核、特权使用、包过滤类（如 5152）等，默认情况下不去碰它们才是稳妥的做法。这些子类别只有在配合有针对性的 SACL 设置，或是限定在排查期间内使用时才真正有价值，常年全开只会把日志空间吃光。⁴

4. 常见事件 ID 的解读方法

4.1. 4624 ── 登录成功事件按登录类型区分解读

4624 是「账户已成功登录（An account was successfully logged on）」，记录在创建登录会话的机器（被访问的一侧）上。⁵ 由于这是一个会被大量记录的事件，解读时首先要按登录类型（Logon Type）进行分类。⁵

同时需要留意的字段有：「新登录（New Logon）」中的账户名、「网络信息（Network Information）」中的源地址、「身份验证包（Authentication Package）」（NTLM 还是 Kerberos）、以及「提升的令牌（Elevated Token）」（是否为管理员特权会话）。如果只想追踪管理员特权登录，也可以使用记录在同一登录 ID 下的 4672（分配了特殊权限）。⁵

4.2. 4625 ── 用 Status/Sub Status 代码确定失败原因

4625 是「账户登录失败（An account failed to log on）」，记录在被尝试登录的机器上。⁶ 比起「失败原因（Failure Reason）」栏中的文字说明，通过 Status/Sub Status 的十六进制代码来判断更为可靠。常见代码如下。⁶

• 0xC0000064：用户名不存在。若短时间内连续出现，可能是账户枚举攻击的迹象
• 0xC000006A：密码错误。若针对特定账户连续出现，可能是密码猜测攻击的迹象
• 0xC000006D：用户名或身份验证信息无效
• 0xC000006F：不在允许的登录时间段内
• 0xC0000070：来自不被允许的工作站
• 0xC0000072：账户已被管理员禁用（对离职员工账户的尝试会出现在这里）
• 0xC000015B：该机器上不允许所请求的登录类型
• 0xC0000193：账户已过期
• 0xC0000234：账户锁定中

「谁・从哪里・为什么失败」由「目标账户 + 来源（工作站名称/IP 地址） + 该代码」这三项信息共同确定。第 6 章会给出一次性提取这三项信息的 PowerShell 脚本。

4.3. 4740 ── 锁定的来源看「呼叫方计算机名」

4740 是「用户账户已被锁定（A user account was locked out）」（子类别为用户账户管理）。这个事件中的主角是「呼叫方计算机名（Caller Computer Name）」字段，记录了触发锁定的那次登录尝试来自哪台计算机。¹⁶ 常规做法是先据此定位来源终端，再排查该终端上残留的旧凭据。原因大多是某种东西在密码更改后仍在继续使用旧凭据（已保存的凭据、断开却未结束的 RDP 会话、使用旧密码配置的服务或任务）。

有一点需要注意：4625 记录在接受登录尝试的一侧计算机上。如果原因是来源终端向文件服务器等发起的网络登录，来源终端自身的 Security 日志中不会留下 4625，痕迹会留在被访问服务器的 4625 中，或者——如果是域账户——留在 DC 一侧的 4776（NTLM）/4771（Kerberos 预身份验证失败）中。⁷⁸ 当「来源终端的日志中什么都没有」时，请去查看接受登录一侧的日志。

4.4. 4720 系列 ── 账户的创建・变更・组添加

账户管理相关的事件 ID 是连号排列的：4720（创建用户账户）¹⁷、4726（删除）、4738（变更），以及组一侧的成员添加/删除。需要注意的是，组成员的变更按组的类型使用不同的事件 ID：本地组为 4732/4733，全局组为 4728/4729，通用组为 4756/4757。¹⁴ Domain Admins 是全局组，因此向其中添加成员会记录在4728中 —— 如果只把 4732 设为告警条件，就会漏掉最应该关注的那个事件。这类事件在日常中大多是帮助台的常规操作记录，但「标准用户突然被添加进管理员组」「出现了谁都不知道的账户」，哪怕只发生一次也应立即进行调查。微软也把向特权组进行的意外成员添加，列为单次即应告警的事件示例。³

4.5. 4688 ── 进程创建。命令行记录是另一个开关

4688 是「已创建新进程（A new process has been created）」，每次创建进程时都会记录创建者账户、新进程的可执行文件路径、父进程以及令牌提升类型（Token Elevation Type）。¹¹ 这是一个能够回答「这台服务器上谁执行了什么」的高调查价值事件。

不过默认情况下不会记录命令行参数。只有另外启用「在进程创建事件中包含命令行（Include command line in process creation events）」这一组策略（管理模板 > 系统 > 审核进程创建）之后，4688 的「进程命令行（Process Command Line）」字段中才会填入参数。¹¹¹² 要追踪 powershell -EncodedCommand ... 这类可疑启动，这项设置事实上是必需的，但请先理解第 7 章所述的机密泄露风险，再决定是否启用。

4.6. 4698 ── 计划任务的创建

4698 是「已创建计划任务（A scheduled task was created）」，会记录任务名称与任务定义的完整 XML（包含执行命令）。由于注册计划任务是恶意软件在重启后仍能存活的常用手段，微软建议监视任务创建事件。¹⁵ 即便是业务中大量使用计划任务的环境，任务的创建本身也不是日常频繁发生的操作，因此噪音相对较小。

还有一个值得记住的是1102「审核日志已被清除（The audit log was cleared）」。清空 Security 日志必然会留下这条事件，因此当「日志变空了」时，可以据此区分是意外事故还是人为操作。¹⁸

5. 日志容器的设计 ── 最大大小与保留方式

在增加审核策略之前，先确认好接收这些事件的容器。Security 日志有最大大小和保留模式两个属性，在覆盖模式（默认配置）下，一旦达到最大大小，新事件就会覆盖最旧的事件。反过来，在保留模式（不覆盖）下，日志一旦写满，反而是新事件会被丢弃。¹⁰ 这两种行为都可能导致「不知不觉间日志就没了」，因此第一步是先了解当前的实际状态。

# 确认 Security 日志的容器状态: 保留模式・最大大小・当前记录数
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# 实际能追溯到多少天前(最旧事件的时间)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog 会一并返回日志的配置与记录数。⁹ 「最旧事件的时间」与当前时间的差值，就是实际的保留天数，如果这个天数不满足本公司的需求（事件调查中想要追溯的天数），就应该扩大最大大小。设置可以通过 wevtutil sl Security /ms:<字节数>，或通过组策略下发。¹⁰

另外，安全选项中还有一项名为「审核：如果无法记录安全审核则立即关闭系统（Audit: Shut down system immediately if unable to log security audits）」（即所谓的 CrashOnAuditFail）的设置。启用后一旦无法记录审核信息，系统就会以 STOP 错误 C0000244 停止运行。这是为绝不能遗漏审核证据的合规要求而设计的设置，默认为禁用。微软自身也提醒，攻击者可以通过故意产生大量事件，把它转化为强制关闭服务器的 DoS 手段，因此在一般的中小规模环境中不应轻易启用。¹⁹

6. 排查实务 ── 筛选、Get-WinEvent、导出

6.1. 用事件查看器进行筛选

如果只是单次调查，事件查看器就已经足够。打开 Security 日志，用「筛选当前日志（Filter Current Log）」指定事件 ID（例如 4625）和时间段。需要反复查看的条件，可以用「创建自定义视图（Create Custom View）」保存下来，下次一键即可打开。如果不只是想按事件 ID 筛选，还想按特定账户等条件缩小范围，可以在筛选对话框的 XML 选项卡中直接编辑 XPath 查询。

6.2. 用 Get-WinEvent 提取

记录数量多、涉及多个条件、需要定期执行的调查，请切换到 PowerShell 的 Get-WinEvent。要点在于使用能够在日志一侧完成过滤的 -FilterHashtable。⁹

# 获取最近 24 小时内的登录失败(4625)事件
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# 整理成「谁・从哪里・为什么」的表格
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

只要掌握这一套从事件的 XML 表示中提取 EventData 的方法，无论是 4624 还是 4688 都能照搬同样的思路。关于 Get-WinEvent 的筛选设计（FilterHashtable 与 XPath 的使用区分、慢查询的修复方法），在「用 Get-WinEvent 实务排查事件日志」中有详细说明。

6.3. 用 wevtutil 导出

对于调查对象机器上的日志，原则是趁被覆盖消失之前先导出保全。¹⁰

rem 将 Security 日志整体保全为 evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem 只用 XPath 筛选出 4625 并导出
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

导出的 .evtx 文件，可以在另一台机器上用 Get-WinEvent -Path C:\logs\security-20260801.evtx 以同样的方式解析。⁹ 先保全再解析的习惯，与崩溃调查中「先确保拿到 dump」的思路是一致的（参见「Windows应用的crash dump收集入门」）。

7. 常见陷阱 ── 现场最容易踩中的 4 个

（1）4688 的命令行会带出机密信息。 启用命令行记录后，所有进程的参数都会以明文形式写入 Security 日志。微软明确指出：「拥有安全事件读取权限的所有用户，都能读取任意进程的命令行参数，而参数中可能包含密码等机密信息」。¹² 只要有一个业务应用或脚本以 myapp.exe /user:admin /password:P@ssw0rd 这样的方式启动，就等于把机密公开给了所有能查看日志的人。启用之前，请先排查并修正以参数方式传递机密的地方。日志的保全与转发目的地，也需要采用同等级别的访问控制。

（2）不清楚日志写满时的行为就直接运维。 覆盖模式下旧证据会悄无声息地消失，不覆盖设置下新事件会被丢弃，CrashOnAuditFail 启用时则会连系统一起停止运行（第 5 章）。¹⁰¹⁹ 正确的做法是先弄清楚自己选择的是哪种行为，再准备好「趁消失之前收集」的机制（定期导出或日志采集平台）。

（3）域控制器与终端上应该查看的日志不同。 4624/4625 记录在被访问的机器上。⁵⁶ 另一方面，域账户的凭据验证（NTLM 的 4776）记录在对该凭据拥有权威的机器上，也就是说域账户会记录在 DC 上⁷，而 Kerberos 的预身份验证失败（4771）则只会记录在 DC 上。⁸ 「文件服务器上没有 4625」并不等于「没有发生攻击」，只有把 DC 一侧的 4776/4771 也一并比对，才能看到全貌。关于身份验证协议具体是如何流转的，请参见「图解 NTLM 与 Kerberos」。

（4）时钟不同步就无法比对。 把多台机器的日志并排比对，追踪「这条 4740 之前，哪台终端出现了 4625」这类工作，前提是各台机器的时钟是一致的。在域环境中，Kerberos 本身就对时钟偏差设有上限（默认 5 分钟），一旦超过这个范围，身份验证本身就会开始失败。²⁰ 从调查的角度看，别说 5 分钟，哪怕只有几秒钟的偏差也会让人误读事件的先后顺序，因此请把确认 w32time 的同步状态放在调查步骤的最前面。另外，事件的记录时间是以 UTC 保存的，显示时会依据查看所用机器的时区进行转换，因此在读取从海外据点或设置为 UTC 的服务器上取回的 evtx 文件时，请不要忘记进行时区换算。

8. 总结

• 审核策略分为「基本」与「高级」两大体系，混用会导致结果无法预期。请统一使用高级一侧，并先用 auditpol /get /category:* 确认当前状态，再进行设计。
• 「全部启用」会因噪音与日志膨胀而扼杀调查工作。请以微软的基准建议为起点，从第 3 章中以登录、账户管理、进程创建为核心的判断表开始入手。
• 4624 看登录类型，4625 看 Status/Sub Status 代码，4740 看呼叫方计算机名，4688 看父进程与命令行 ── 每个事件都有各自「应该看哪里」的关键点。
• 日志容器（最大大小、保留模式）占审核设计的一半分量。请确认实际能保留多少天，根据需求反推容量大小，并在消失之前完成导出或集中采集。
• 4688 的命令行记录，请先排查机密泄露的风险再启用。各机器记录位置的差异以及时钟同步，是比对调查的前提条件。
• 调查从事件查看器的筛选功能入手，如果需要反复执行就改用 Get-WinEvent -FilterHashtable，保全则用 wevtutil epl。不要打乱「先保全，再解析」的顺序。

相关文章

• 用 Get-WinEvent 实务排查事件日志 ── 筛选速度决定调查时间
• NTLM 停用会导致业务应用停止运行吗 ── 审核日志的获取方法与消除依赖的顺序
• 图解 NTLM 与 Kerberos ── 为什么认证会「回退」到 NTLM
• SMB 签名与 LDAP 通道绑定 ── 用实务收紧 NTLM 对策的「另一半」
• Windows 事件日志・ETW 入门 ── 让业务应用程序的日志接入操作系统标准机制
• Windows应用的crash dump收集入门 - 先搞清楚 WER / ProcDump / WinDbg怎么分工

相关咨询领域

合同会社小村软件（合同会社小村ソフト）提供 Windows 环境审核策略・日志设计方面的咨询，基于事件日志排查「何时・谁・做了什么」，并分析业务应用在身份验证・审核相关环节引发的故障原因。哪怕您现在还处于「被要求查一下日志，却不知道该从哪里下手」的阶段，也欢迎咨询。

• 故障排查・原因分析
• 技术咨询・设计评审
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

明明没有设置任何审核策略，Security 日志里却已经记录着 4624 和 4625，这是为什么？

这是因为 Windows 存在默认就已启用的审核子类别。例如「登录（Logon）」子类别，在 Windows 10 版本 1809 及以后的版本中，成功与失败均默认启用，所以哪怕什么都不设置，4624（成功）和 4625（失败）也会被记录下来。但在默认状态下，凭据验证（4776）或进程创建（4688）等排查时经常需要用到的许多事件，仍然不会被记录。自己的环境中当前启用了哪些审核，可以用 `auditpol /get /category:*` 确认。在此基础上，把不足的子类别在高级审核策略一侧明确启用，是实务中的标准套路。

想调查登录失败，却在目标服务器的 Security 日志里找不到 4625，该看哪里？

首先请确认一条原则：4625 记录在「登录被尝试的那台计算机」上。如果是用户终端上的登录失败，就看终端一侧；如果是访问文件服务器失败，就看文件服务器一侧。接下来用 `auditpol /get /category:*` 确认「登录」子类别的失败审核是否已启用。如果是域账户，往往会在域控制器一侧的凭据验证（4776）或 Kerberos 预身份验证失败（4771）中留下记录，当无法锁定具体终端时，从 DC 一侧入手反而更快。如果还是找不到，请确认日志是否因为覆盖而丢失了过去的部分（查看日志的最大大小与最旧事件的时间）。

进程创建（4688）的命令行记录应该启用吗？

这项设置调查价值极高，但必须先理解风险再决定是否启用。启用后，所有进程的命令行参数都会以明文形式记录到 Security 日志中。哪怕只有一个业务应用或脚本会把密码或 API 密钥通过命令行参数传递，这份机密就会暴露给所有能读取 Security 日志的人。微软自身也明确提到了这一注意事项。建议的顺序是：先排查自家的脚本是否存在以命令行参数传递机密的情况，修正之后再启用该设置。

Security 日志的最大大小应该设成多少？

正确的做法是从「希望在本地保留多少天的日志」反推，并不存在一个万能的数值。当前的设置与实际情况可以用 `Get-WinEvent -ListLog Security` 确认，最旧事件的时间与当前时间之差，就是「目前实际能保留的天数」。增加审核子类别会让事件量随之增加，因此每次变更设置后都必须重新确认这个实际保留天数。事件响应工作中经常需要用到几周甚至几个月前的日志，因此建议在日志被覆盖消失之前定期导出，或者通过日志采集机制汇总到其他机器上，以求安心。

账户锁定（4740）的原因该怎么查？

4740 事件的「呼叫方计算机名（Caller Computer Name）」字段是最初的线索，这里记录着触发锁定的那次登录失败来自哪台计算机。不过要注意，失败记录本身（4625）并不会留在发生源，而是留在接受登录尝试的一侧。如果是网络登录导致的，就按时间顺序追踪访问目标服务器的 4625，如果是域账户，则追踪域控制器上的 4776/4771。锁定定位到发生源终端后，要重点排查该终端上密码更改后仍在被使用的旧凭据，也就是已保存的凭据、断开却未结束的远程桌面会话，以及仍以旧密码配置的服务或计划任务。如果锁定反复发生，也请一并确认是否存在时钟不同步的问题。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。