域账户被爆破锁了五年，每次都现场救火——终于腾出手搭了一个事件看板

公司的域环境从几年前开始，断断续续遭到外部的暴力破解（Brute Force）攻击——攻击目标既有域管理员账号，也有普通员工账号。每一次的表现都差不多：Windows 安全日志里出现一连串事件 ID 4740（“用户账户被锁定”），受影响的员工发现自己登不进去，IT 这边收到求助后现场处理。

五年，同一套救火动作

翻查历史记录，这类事件反复出现，每次的处理方式几乎是同一套模板：

• 用 Get-WinEvent -FilterHashtable @{logname='security'; id=4740} 在域控制器上把最近的锁定事件抓出来，人工过一遍受影响的账号；
• 怀疑是某个进程或会话在不停重试密码，手动找到相关进程直接结束；
• 某一次攻击规模扩大到一整个周末、几十个账号先后被锁，只能一条一条把事件记录抄进表格，标注锁定时间、涉及账号、来源域控制器；
• 群发一封邮件通知受影响的同事：“您的账户近期因来自外部的重复登录尝试被系统自动锁定，这是我们安全系统在多次失败尝试后自动触发的保护机制，如有疑问请联系 IT”，并顺带提醒近期有钓鱼邮件冒充内部人员，涉及打款变更务必电话核实。

这套动作能解决眼前的问题——账号解锁了、同事能登录了——但每次事件结束后什么都没有留下：没有趋势图，没有”这个月比上个月更频繁还是更少”，甚至连”这次和上次是不是同一个攻击源”都说不清楚。每一次新的锁定潮来了，都是从零开始翻日志。

终于腾出手，搭一个真正的看板

某次锁定事件处理完，决定不能再这样一次次从零翻日志——用开源的 PowerShell 模块组合搭一个本地化的 AD 事件可视化看板：

Install-Module Dashimo -Force
Install-Module PSWinReportingV2 -Force
Install-Module -Name PSWriteHTML -Force

PSWinReportingV2 负责按类型抓取域控制器上的各类审计事件——不只是账户锁定，还包括用户变更、计算机对象变更、组成员变更、组策略变更、安全日志被清空等一整套”AD 上到底发生了什么”的完整画面。Dashimo 把这些结构化数据渲染成一个可以在浏览器里打开、按标签页分类的 HTML 看板：计算机变更、组变更、用户变更、组策略变更、日志清空，五个标签页各自独立。

第一次跑，看板是空的——这不是失败

配置好脚本、指定要查询的域控制器、跑起来之后打开生成的 HTML 看板——多数标签页显示”No data available to display”。第一反应容易觉得是脚本没配对、权限不够、或者哪里漏了参数。

但换个角度看：这份看板抓取的时间窗口是”最近 3 天”，而这几天恰好没有发生新的攻击潮。看板显示空白，恰恰是它在如实反映”这段时间安全，没有异常事件”——这不是工具坏了，是工具第一次真正开始工作。过去几年”救火”这件事从来没有一个可以在平静的日子里打开看一眼的地方，现在有了：平时打开是空的，说明一切正常；下一次攻击潮来了，同一个看板会立刻显示出锁定事件的时间分布、涉及的账号数量，不再需要从头现场拼日志。

一个”平时是空的”看板，价值恰恰在于下一次不平静的时候它已经就位

教训

1. 反复出现但每次都”处理完就结束”的安全事件，是投资可观测性工具的最强信号——如果同一类事件已经发生了三次以上，且每次都靠人工翻日志，说明缺的不是应急能力，是留存下来的可视化历史；
2. 看板第一次运行结果是空的，先问”这个时间窗口本该有数据吗”，再怀疑配置错了——空结果和错误结果是两种完全不同的信号，混为一谈会让人错失”工具已经工作正常”的信息；
3. 给受影响的用户群发说明邮件时，把”这是自动防护机制触发，不是你的问题”说清楚——账户被锁定本身已经够让人不安，附带的钓鱼提醒也顺手把这次事件转化成一次安全意识的强化，而不只是一次事故通知；
4. 多年积累的开源运维工具生态（PSWinReportingV2、Dashimo 这类）往往比现场手搓脚本更快搭出可用的看板——遇到”这个问题反复出现，我该自己写一套统计脚本吗”的念头时，先花十分钟搜一下是不是已经有人把这条路走过了。