AI日志监控检测到“PC死机导致的账户锁定”的案例 #
BASTION 的 Windows 客户端监控检测到公司内部人工账户出现异常锁定。通过 Slack 消息确认了来源 IP，调查后发现原因是设备死机。从检测到查明根本原因：5 分钟。
事件经过 #
BASTION 的定期分析报告中出现了一条陌生的记录。
问题出在 admin-user。这是一个人工账户，已被锁定 16 次。当时完全不清楚是什么原因导致的。
通过 Slack 确认来源 IP #
BASTION 具备通过 Slack 进行交互式分析的功能。
根本原因 #
检查来源 IP 对应的设备后发现，Windows 11 处于死机状态。
即使设备死机、画面已冻结，它仍会在后台持续向 AD 发送身份验证请求。如果密码变更后仍存在旧的缓存凭据，每次验证都会失败，账户最终就会被锁定。
重启该设备后，锁定问题就停止了。
一种典型模式 #
“设备死机导致的账户锁定”是 IT 运维中常见的问题。但传统方式下，通常只有“已锁定”这一事件会上报到服务台，而查明来源设备则需要人工排查 AD 事件日志。BASTION 将检测与来源 IP 的确认自动化，整个流程只需在 Slack 中提出一个问题即可完成。
BASTION 是如何检测到这一问题的 #
1. Windows 客户端日志采集 #
我们组织内的 Windows 客户端通过 GPO 自动部署了 NXLog（一款开源日志转发代理）。各设备的事件日志（Security、System、Application、PowerShell 等）会以 syslog 格式转发至 BASTION 服务器。
在 BASTION 服务器端，rsyslog 会自动为每个主机名创建目录并存储日志。一旦新设备开始通过 NXLog 发送日志，就会自动纳入监控范围，无需手动注册设备。
2. 设备自动分类 #
当出现新主机时，BASTION 的 LLM 会读取日志样本并自动判断“该设备是 Windows 客户端”还是“这是一台 Linux 服务器”。系统会根据分类结果自动应用相应的监控模板。
对于 Windows 客户端，以下项目会自动纳入监控。
| 类别 | 监控项目 |
|---|---|
| 身份验证异常 | 登录失败激增、账户锁定、特权登录、非工作时间登录 |
| 进程执行 | PowerShell EncodedCommand、下载器模式、LOLBin 执行 |
| 设备 | USB 大容量存储设备连接 |
| 账户变更 | 用户创建、管理员组添加、服务安装、任务创建 |
3. 通过定期分析检测异常 #
每 15 分钟运行一次定期分析，由 LLM 读取所有主机的摘要并判断是否存在异常。在本案例中，“人工账户被锁定 16 次”被判定为中等及以上严重程度，详细报告随即自动发送至 Slack。
4. 通过交互式查询进行深入分析 #
在定期报告中看到“admin-user=16 次锁定”后，只需在 Slack 中提及该告警，即可完成来源 IP 的确认，无需人工翻查 AD 事件日志。
本案例的经验总结 #
误报排除规则的 90% 在于“排除什么” #
如果没有排除 svc-ldap（LDAP 集成）和 DC-01$（Kerberos 计算机账户），每次都会上报数百条“异常”，而人工账户的这 16 次事件也会被淹没在噪声之中。通过消除噪声，真正的异常才能凸显出来。
“检测 → 通知 → 调查”全部在 Slack 内完成的价值 #
传统工作流程是“打开 AD 事件查看器 → 筛选事件 4625 → 按账户名缩小范围 → 查找来源 IP”，即使是有经验的用户也需要 10 分钟以上。而使用 BASTION，检测由 cron 自动执行，调查只需在 Slack 中提问即可，整个过程无需切换任何画面即可完成。
客户端监控只需“指定 syslog 目标”即可开始 #
通过 GPO 部署 NXLog 并配置好 syslog 目标后，所有客户端 PC 都会自动纳入监控。BASTION 会读取日志内容，自动判断设备类型，并应用相应的监控模板。设备的增加或移除均无需人工干预。
总结 #
BASTION 的 Windows 客户端监控在我们自身的环境中检测到了一次异常的账户锁定。从检测到查明来源设备：约 5 分钟。我们所做的仅仅是在 Slack 中提出了一个问题。
本次原因只是一台普通的死机设备，但同样的检测机制对外部的暴力破解攻击同样有效。无论来源 IP 是内部还是外部，区别只在于应对方式，检测与确认的流程本身并无不同。
BASTION 是一项在封闭环境中提供 AI 安全监控的服务。
