Windows Server Active Directory安全审计

Active Directory的日志就像一栋大楼里所有的监控探头，问题不在于没有录像，而在于99%的时间里根本没人去看，等到出事再回放时往往发现关键角度的摄像头早就坏了。绝大多数组织部署了AD之后，审计策略用的还是默认设置，甚至为了节省存储空间主动关闭了关键日志。这不是技术问题，是认知问题——很多人以为AD安全审计就是开启登录审核，实际上那只是冰山一角。

真正有效的AD安全审计需要覆盖三个维度：目录变更、认证活动、权限使用。目录变更告诉你谁修改了组织架构、组策略、架构定义；认证活动暴露谁在尝试登录、从哪里登录、用什么协议；权限使用则揭示具有高权限的账户到底干了什么。这三个维度缺一不可，任何一个盲区都可能是攻击者的突破口。

默认的审计策略基本是摆设。你需要通过组策略在域控制器上配置高级审计策略，而不是依赖传统安全日志里的那几项。具体路径是“计算机配置-策略-Windows设置-安全设置-高级审核策略配置”。这里有十几个类别，但真正需要重点关注的是以下几项：账户登录事件、账户管理、目录服务访问、登录事件、对象访问、策略更改、特权使用。

账户登录事件和登录事件很多人分不清。简单说，账户登录事件记录的是域控制器验证凭据的时刻，登录事件记录的是用户登录到某台具体机器的会话。攻击者用黄金票据或者白银票据做票据传递攻击时，往往只触发账户登录事件而不触发标准的登录事件。如果你只开了登录审核，就会漏掉这类攻击。两个都必须开，而且必须同时开启成功和失败审核。

目录服务访问这个类别尤其关键，但默认情况下它只记录访问行为，不会告诉你具体访问了哪个对象的哪个属性。要让它生效，你必须配合SACL使用。在ADSI编辑器中找到需要监控的敏感对象，比如Domain Admins组、Enterprise Admins组、关键服务账户、高管用户对象，在安全属性的高级选项中添加SACL条目，指定要审计的主体和要监控的写入或读取行为。这一步不做，目录服务访问审核就等于白开。

域控制器本地的事件日志保留策略默认是覆盖式的，安全日志大小上限通常只有几十MB。在中等规模的环境中，这个容量可能连一小时的日志都存不下。攻击者经常利用这一点，在行动前制造大量噪音日志把真正的攻击痕迹冲刷掉。你必须把日志实时转发出去，而不是依赖本地存储。

Windows事件转发是内置功能，可以配置订阅源域控制器将指定事件ID推送到收集器服务器。但实际部署中，更可靠的做法是使用Sysmon配合Windows事件转发，或者直接上商业SIEM方案。Sysmon能提供比内置安全日志更细粒度的进程创建、网络连接、文件创建、管道通信等信息，这些在追踪横向移动和凭据窃取时至关重要。

部署Sysmon时不要用默认配置文件，那个太吵了。你需要定制规则，至少包含以下监控点：lsass.exe的访问行为、域控制器上ntds.dit文件的读取、PowerShell和wmic的进程创建、从非系统账户发起的计划任务创建、对SAM注册表项的访问。这些是攻击者在AD环境中几乎必用的技术，盯住它们就能大幅提高检测率。

安全日志里的事件ID有上千个，但真正需要立即响应的事件不超过30个。以下是最核心的一组：事件ID 4625是登录失败，大量4625集中出现在某个账户上就是暴力破解或密码喷洒的信号；事件ID 4740是账户锁定，如果锁定发生在高价值账户上需要立刻排查；事件ID 4728和4756分别代表用户被添加到全局安全组和通用安全组，监控Domain Admins、Enterprise Admins、Schema Admins这几个组的成员变更；事件ID 5136是目录服务对象修改，配合SACL可以精确捕获特定属性的变更；事件ID 4768是TGT票据请求，如果伴随异常加密类型比如RC4而不是AES，可能是Kerberoasting攻击的前兆；事件ID 4771是Kerberos预认证失败，大量4771指向同一个服务主体名称意味着攻击者在爆破服务账户的密码。

还有一个容易被忽视的事件ID 4662，它记录了对AD对象的操作，包括读取和写入。当它和目录服务访问审核配合使用时，可以还原出某个账户在某个时间点对某个OU或对象执行了什么操作。这在追踪权限滥用时非常有用，比如有人偷偷给自己加了委派权限或者修改了某个服务连接点的属性。

服务账户是AD安全中最薄弱的环节之一。这些账户往往拥有超出实际需要的权限，密码从不轮换，而且因为不是真人使用，异常行为很难被发现。你需要定期审计所有服务账户的spn属性，检查是否存在重复的SPN注册，因为SPN冲突可以被利用来做Kerberoasting。同时要审计所有配置了非约束委派和约束委派的账户，非约束委派尤其危险，配置了非约束委派的服务器一旦被攻陷，攻击者可以模拟任何向它发起过Kerberos认证的用户。

查询非约束委派账户的PowerShell命令很简单，但很多人不知道怎么写：

Get-ADObject -Filter {UserAccountControl -band 0x80000} -Properties UserAccountControl, Name, SamAccountName

约束委派虽然相对安全，但需要检查委派列表中是否包含高价值服务，比如允许某个服务账户委派到域控制器的LDAP服务。这种配置一旦被滥用，攻击者就能以该服务账户的身份请求域控制器的服务票据，进而获得高权限访问。定期导出所有委派配置并人工审核，是目前最有效的做法。

GPO是攻击者在域环境中实现持久化的首选手段。修改一个GPO比直接添加域管理员账户更隐蔽，因为大多数组织不会频繁审计GPO的变更。你需要监控的不仅是GPO本身的修改，还包括GPO内部具体设置的变更。事件ID 5136可以捕获对GPO对象的修改，但前提是你已经对Policies容器配置了SACL。

更直接的方法是启用组策略的审核日志，路径在组策略管理控制台的每个GPO属性中。启用后，每次GPO被修改都会生成详细的变更记录，包括修改时间、修改者、具体改了什么设置。这些日志存储在域控制器的应用程序和服务日志中，需要一并转发到集中日志平台。重点关注对启动脚本、关机脚本、计划任务、软件安装、安全设置这几类GPO扩展的修改，它们是攻击者最常用的植入点。

AD安全审计不能只盯着日志，还要和防御措施联动。Credential Guard、Protected Users组、LSA保护这些机制本身不产生审计数据，但它们能改变攻击者的行为模式，迫使他们使用更容易被检测到的技术。比如启用了Credential Guard的机器上，mimikatz无法从LSASS中提取明文凭据，攻击者可能转而使用Kerberoasting或者DCSync，而这些技术都有对应的审计特征。

Protected Users组是一个被严重低估的防御机制。将高权限账户加入这个组后，强制使用Kerberos AES加密，禁用NTLM认证，禁止凭据缓存，票据生命周期缩短到4小时。从审计角度看，这意味着任何针对这些账户的NTLM认证尝试都是异常行为，应该直接触发告警。你可以在安全日志中筛选事件ID 4776来检测NTLM凭据验证，如果源账户属于Protected Users组，就是高危信号。

手动检查日志在2025年已经不可接受了。你需要建立自动化的审计流程，至少实现以下检测场景的自动告警：任何对高权限组的成员变更、任何新创建的具有SPN的账户、任何对GPO的修改、任何非工作时间的高权限账户登录、任何从非授权IP段发起的域控制器认证、任何对msDS-KeyCredentialLink属性的写入（这是Shadow Credentials攻击的特征）、任何对AdminSDHolder容器的修改。

实现方式可以基于Windows事件转发配合PowerShell脚本做定时查询，也可以使用Elastic Stack配合Winlogbeat做实时分析，或者直接采购成熟的AD审计产品。无论哪种方案，核心原则是告警必须推送到运维人员真正会看的地方，比如企业微信、钉钉、邮件，而不是躺在某个仪表盘里吃灰。告警规则也需要持续调优，避免误报太多导致告警疲劳，这是安全运维中最常见也最致命的失败模式。

AD安全审计不是一次性项目，而是需要持续投入的运营过程。攻击者的技术在进化，你的审计策略也必须跟着进化。今天有效的检测规则，明天可能就被绕过。唯一不变的原则是：记录一切，保留一切，自动化分析一切。当攻击发生时，你能依赖的只有那些被你认真对待过的日志数据。