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 事件日誌。
本案例的啟示 #
誤報排除規則有九成在於「該排除什麼」 #
若當初沒有排除 svc-ldap（LDAP 整合）與 DC-01$（Kerberos 電腦帳戶），每次都會通報數百筆「異常」，人員帳戶的那 16 次事件就會被淹沒在雜訊之中。透過消除雜訊，真正的異常才能凸顯出來。
「偵測 → 通知 → 調查」全程在 Slack 內完成的價值 #
傳統工作流程是「開啟 AD 事件檢視器 → 篩選事件 4625 → 依帳戶名稱縮小範圍 → 找出來源 IP」，即使是熟練的使用者也要花上 10 分鐘以上。使用 BASTION 後，偵測由排程自動執行，調查只需在 Slack 中提問即可，整個流程無需任何畫面切換即可完成。
客戶端監控只需「指向 Syslog」即可開始 #
透過 GPO 部署 NXLog 並設定 syslog 傳送目的地後，所有客戶端 PC 便會自動納入監控。BASTION 會讀取日誌內容，自動判斷裝置類型並套用適當的監控範本。裝置的新增或移除都無需人工介入。
總結 #
BASTION 的 Windows 客戶端監控在我們自身的環境中偵測到了異常帳戶鎖定。從偵測到鎖定來源裝置：約耗時 5 分鐘，我們只在 Slack 中提出了一個問題。
原因雖是平凡的裝置當機，但同樣的偵測機制對外部暴力破解攻擊同樣有效。來源 IP 是內部或外部，只會改變後續的應對方式，偵測與鎖定的流程本身並無不同。
BASTION 是一項在封閉環境中提供 AI 安全監控的服務。
