Windows 安全性稽核原則與事件記錄調查實務 ── 成為看得懂 4625 的資訊系統人員

「從昨晚開始，某個帳戶就一直反覆遭到鎖定，請幫忙查一下原因」「想確認是否有人嘗試用離職員工的帳戶登入」「這台伺服器，能不能知道什麼時候、誰執行了什麼？」── 這些都是中小企業的資訊系統負責人，或是把系統交付給客戶的開發者，某天突然會收到的委託。而這時能夠依靠的，就是 Windows 的 Security 事件記錄檔。

然而實際打開事件檢視器，等在那裡的是兩種現實。想看的事件根本沒有被記錄(稽核原則沒有啟用)，或是被大量事件淹沒而讀不下去(充滿雜訊、記錄檔肥大化)。安全性稽核是一種「啟用了就會記錄」的機制，但如果不設計要記錄什麼、記錄到什麼程度，真正需要的時候就派不上用場。

flowchart TB
    accTitle: 打開事件檢視器後等待你的兩種現實
    accDescr: 打開事件檢視器後，可能是稽核原則沒有啟用而想看的事件沒有被記錄，也可能是充滿雜訊、記錄檔肥大化而使想看的內容被大量事件淹沒讀不下去，兩者都需要事先設計要記錄什麼、記錄到什麼程度
    open["打開事件檢視器"] --> real{"等在那裡的現實是?"}
    real -->|沒有記錄下來| none["想看的事件未被記錄"]
    real -->|被淹沒| noise["事件太多而讀不下去"]
    none -.-> cause1["稽核原則未啟用"]
    noise -.-> cause2["充滿雜訊、記錄檔肥大化"]
    none --> design["設計要記錄什麼、記錄到什麼程度"]
    noise --> design

圖 1: 不是「沒有記錄下來」，就是「被淹沒而讀不下去」。兩者的原因都是沒有設計記錄的範圍。

本文把「為了讓調查有記錄可用而該做的設定」與「從留下的記錄追查原因的步驟」分開整理。 內容涵蓋稽核原則的機制(基本與進階兩個系統)、中小規模環境中最低限度應啟用的子類別、4624/4625/4740/4688 的判讀方式、Security 記錄檔的容量設計，以及用 PowerShell 調查的方法。技術性的說明依據的是 2026 年 8 月當下的第一手資料。

若說本站先前處理過的 NTLM 稽核、SMB 簽章、BitLocker、防火牆這幾篇文章談的是「築牢防禦」，那麼本文談的則是「讓事後能夠確認發生過什麼」，是把這些文章串連起來的續篇。

1. 先講結論

要讓記錄真正能用於調查，必須同時湊齊三件事：「記錄必要的內容」「在正確的機器上讀正確的欄位」「在消失之前先保全」。 重點是不要只做到「啟用稽核」就收工。

準備做設定的人: 統一到進階這一側，只記錄必要的內容

• 稽核原則有「基本」與「進階(Advanced Audit Policy)」兩個系統，不可以混用。Microsoft 明確指出，兩者並用會讓稽核結果變成無法預期的狀態。請統一採用進階這一側(40 個以上的子類別)。¹
• 確認現況用 auditpol /get /category:*。無論來源是 GPO 還是本機設定，都可以一覽目前實際生效的稽核設定。²
• 不可以「全部啟用」。啟用會產生大量事件的子類別，會讓真正重要的事件被雜訊淹沒，也會影響效能。請以 Microsoft 的基準建議為出發點，只補上必要的項目。³⁴

正在做調查的人: 不要只看事件 ID，還要確認記錄位置與欄位

• 登入成功是 4624，失敗是 4625。4624 要透過登入類型(2=互動式、3=網路、10=遠端桌面等)來判讀「這是什麼樣的登入」。⁵
• 4625 可透過 Status/Sub Status 代碼確定失敗原因。常見的有 0xC0000064=不存在的使用者名稱、0xC000006A=密碼錯誤、0xC0000072=已停用的帳戶、0xC0000234=正處於鎖定中。⁶
• 每個事件「會記錄在哪台機器上」都是固定的。4624/4625 記錄在被存取的那一端，認證驗證(4776)記錄在對該認證資訊具有權威的機器上(網域帳戶就是網域控制站)，Kerberos 事前驗證失敗(4771)則記錄在網域控制站。查錯機器就會誤判成「沒有記錄」。⁶⁷⁸

兩邊都需要: 設計記錄的保留方式與機密資訊的處理方式

• Security 記錄檔有一半取決於容器的設計(最大容量與保留方式)。若保留方式是覆寫模式，舊事件就會依序被擠掉。用 Get-WinEvent -ListLog Security 確認最大容量與筆數，再從需要的保留天數反推擴大容量。⁹¹⁰
• 處理程序建立(4688)的命令列記錄非常強大，但代價是機密資訊會以明文留在記錄檔中的風險。啟用前請先檢查各類指令碼。¹¹¹²

依目的與症狀選擇該讀的地方

如果已經接到調查委託，請先依 6.3 把記錄保全下來，確認第 7 章關於記錄位置與時間同步的注意事項，再去讀第 4 章對應的事件。 如果是要把設定理順，請先用第 2 章與第 5 章確認現況，再進入第 3 章。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 34 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 稽核原則的基礎 ── 不要混用「基本」與「進階」

2.1. 先弄清楚設定位置與粒度的差別

Windows 的稽核原則有兩個系統。¹

• 基本稽核原則: 位於「本機原則 > 稽核原則」下的 9 個類別設定。這是從 Windows Vista 之前就存在的舊系統。
• 進階稽核原則(Advanced Audit Policy Configuration): 位於「安全性設定 > 進階稽核原則設定」下 40 個以上的子類別設定。這是把基本原則中的 1 個類別拆解成多個子類別的結果，例如基本原則中的「稽核帳戶登入事件」這 1 項，在進階這一側就有 4 個子類別與之對應。在基本原則那一側啟用 1 個類別，等同於把對應的所有子類別全部啟用，連不感興趣的事件也會被大量記錄下來。¹

2.2. 統一到進階這一側，防止基本這一側覆寫

重要的是，這兩個系統並不相容。Microsoft 明確寫著「不要同時使用基本與進階。稽核結果會變成無法預期的狀態」。

用群組原則套用進階稽核原則時，該台電腦既有的稽核設定會先被清除，然後才套用進階這一側的設定，此後也只能靠進階這一側才能確實控制。

在使用進階這一側的環境中，請啟用安全性選項「稽核: 強制稽核原則子類別設定」，讓基本這一側的設定不會覆寫過來(獨立運作的機器預設就是啟用)。¹⁴

flowchart TB
    accTitle: 基本與進階稽核原則的關係
    accDescr: 基本稽核原則與進階稽核原則並不相容，兩者並用會讓稽核結果變成無法預期的狀態，因此要統一到進階這一側並啟用強制子類別設定，防止基本這一側覆寫
    basic["基本稽核原則（9 個類別）"] --> both{"兩者都使用?"}
    adv["進階稽核原則（40 個以上的子類別）"] --> both
    both -->|是| bad["稽核結果變成無法預期的狀態"]
    both -->|否| unify["統一到進階這一側"]
    unify --> force["啟用強制稽核原則子類別設定"]
    force -.-> guard["防止基本這一側的設定覆寫"]

圖 2: 兩個系統並不相容。統一到進階這一側，用「強制」設定防止基本這一側覆寫。

2.3. 用 auditpol 確認「結果上正在生效的設定」

確認現況只需要一行指令。請在系統管理員的命令提示字元中執行。²

下面的範例是顯示現況、變更前的備份、還原這三項各自獨立的操作。請先確認顯示結果，變更之前先做備份。/restore 那一行是需要還原時才執行的，並不是為了確認現況而接著執行的步驟。

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，所以「不知不覺間稽核被停用了」這種情況也可以事後追查。¹²

flowchart TB
    accTitle: auditpol 看到的是結果上生效的原則
    accDescr: auditpol 的輸出無論來源是 GPO 還是本機設定，都是結果上正在生效的稽核原則，可用於 GPO 設定未反映時的比對，而稽核設定本身的變更則會記錄為事件 4719 供事後追查
    gpo["以 GPO 配發的設定"] --> eff["結果上正在生效的原則"]
    local["本機的設定"] --> eff
    eff --> get["用 auditpol /get 一覽"]
    get -.-> diff["可用於 GPO 未反映時的比對"]
    change["稽核設定本身的變更"] -.-> e4719["記錄為 4719，可事後追查"]

圖 3: auditpol 不問來源，回傳的是「正在生效的設定」。稽核設定的變更本身則留在 4719。

3. 最低限度應啟用的子類別判斷表

3.1. 不採取「全部啟用」的理由

「先全部啟用再說」是一步壞棋，理由很明確。舉例來說，Microsoft 就警告過，若把特殊權限使用類的子類別連成功都一起稽核，事件量會變得極為龐大，不但難以在其中找到其他項目，也會對效能造成影響。⁴ 記錄檔的容器(第 5 章)是有限的，記錄的雜訊越多，真正需要的事件能保留的天數就被削減得越多。所謂稽核設計，就是決定「不記錄什麼」。

flowchart TB
    accTitle: 全部啟用之所以是壞棋的理由
    accDescr: 啟用所有子類別會產生大量事件，使真正重要的事件被雜訊淹沒並影響效能，在有限的記錄檔容器中還會削減必要事件的保留天數
    all["啟用所有子類別"] --> flood["產生大量事件"]
    flood --> noise["真正重要的事件被淹沒"]
    flood --> perf["影響效能"]
    flood --> keep["保留天數被削減"]
    noise --> lesson["決定不記錄什麼才是稽核設計"]
    perf --> lesson
    keep --> lesson

圖 4: 「全部啟用」會讓真正重要的事件被淹沒。決定不記錄什麼，才是稽核設計。

3.2. 以基準建議為出發點，挑選需要的記錄

Microsoft 已依工作站/伺服器分別公開基準建議與強化建議，這可以作為出發點。³ 在此基礎上，以中小規模環境「事件發生時最低限度想看到這些」的觀點整理出來的，就是下表。這是以 Microsoft 的建議為出發點、屬於本文的判斷表，並不是一份可以一體適用於所有環境的設定清單。

3.3. 會大量記錄的項目，要縮小對象與期間

反過來說，檔案系統或登錄檔的物件存取稽核、特殊權限使用、封包篩選類(如 5152 等)，預設不要去碰會比較穩妥。這些項目只有在鎖定對象的 SACL 設定，或釐清原因時的限定期間內才真正有用，若常態全開就會把記錄檔吃光。⁴

flowchart TB
    accTitle: 大量事件類子類別的處理方式
    accDescr: 檔案系統或登錄檔的物件存取稽核、特殊權限使用與封包篩選類若常態全開就會把記錄檔吃光，唯有搭配鎖定對象的 SACL 設定或釐清原因時的限定期間才真正有用
    heavy["大量事件類子類別"] --> use{"要怎麼啟用?"}
    heavy -.-> ex1["物件存取稽核"]
    heavy -.-> ex2["特殊權限使用、封包篩選類"]
    use -->|常態全開| eat["把記錄檔吃光"]
    use -->|鎖定對象的 SACL| ok1["有用"]
    use -->|釐清原因時的限定期間| ok2["有用"]

圖 5: 物件存取與特殊權限使用不要常態全開。縮小對象與期間才真正有用。

4. 常見事件 ID 的判讀方式

要把「是哪個事件」「留在哪台機器上」「要看哪個欄位」當成一組來確認。 登入看 4.1 與 4.2，鎖定看 4.3，帳戶變更看 4.4，被執行的處理看 4.5 與 4.6，這些都是入口。實際調查時，請先依 6.3 的方法保全。

4.1. 4624 ── 登入成功要依登入類型分開判讀

4624 是「帳戶已成功登入」，記錄在建立登入工作階段的那台機器(被存取的那一端)上。⁵ 由於是會大量記錄的事件，判讀時要先依登入類型分類。⁵

依類型分類之後，再看帳戶、來源與權限

要一併查看的欄位是「新登入」的帳戶名稱、「網路資訊」的來源位址、「驗證套件」(是 NTLM 還是 Kerberos)，以及「提升的權杖」(是否為系統管理員權限的工作階段)。如果只想追蹤系統管理員權限的登入，也可以使用以相同登入 ID 記錄的 4672(已指派特殊權限)。⁵

flowchart TB
    accTitle: 判讀 4624 的步驟
    accDescr: 會大量記錄的 4624 要先依登入類型分類，再確認帳戶名稱與來源、驗證套件、提升的權杖，而系統管理員權限的登入則與相同登入 ID 的 4672 比對
    ev["4624 登入成功"] --> type["依登入類型分類"]
    type --> fields["確認主要欄位"]
    fields -.-> f1["帳戶名稱與來源"]
    fields -.-> f2["驗證套件"]
    fields -.-> f3["提升的權杖"]
    fields --> admin["追蹤系統管理員權限"]
    admin -.-> e4672["相同登入 ID 的 4672"]

圖 6: 4624 先依登入類型分類再讀欄位。特殊權限登入則與 4672 相互關聯。

4.2. 4625 ── 失敗原因用 Status/Sub Status 代碼確定

4625 是「帳戶登入失敗」，記錄在被嘗試登入的那台機器上。⁶ 比起「失敗原因」欄位的文字說明，用 Status/Sub Status 的十六進位代碼來判讀更為確實。常見的代碼如下。⁶

先用 Status/Sub Status 讀出失敗原因

• 0xC0000064: 不存在的使用者名稱。若短時間內連續出現，就是帳戶列舉攻擊的徵兆
• 0xC000006A: 密碼錯誤。若針對特定帳戶連續出現，就是密碼猜測攻擊的徵兆
• 0xC000006D: 使用者名稱或認證資訊不正確
• 0xC000006F: 超出允許的時間範圍
• 0xC0000070: 來自未經允許的工作站
• 0xC0000072: 已被系統管理員停用的帳戶(對離職員工帳戶的嘗試會出現在這裡)
• 0xC000015B: 這台機器不允許所要求的登入類型
• 0xC0000193: 已過期的帳戶
• 0xC0000234: 正處於鎖定中

把目標帳戶、來源與失敗原因組合起來

「是誰、從哪裡、為什麼失敗」，要靠目標帳戶+來源(工作站名稱/IP 位址)+這個代碼這三件一組來確定。6.2 中附有一次擷取這三項的 PowerShell。

flowchart TB
    accTitle: 確定 4625 失敗原因的流程
    accDescr: 4625 的失敗原因要用 Status/Sub Status 的十六進位代碼確定，從代碼的趨勢讀出攻擊徵兆後，再加上目標帳戶與來源，以三件一組來鎖定
    ev["4625 登入失敗"] --> code["確認 Sub Status 代碼"]
    code --> sign{"代碼的趨勢是?"}
    sign -->|0xC0000064 連續出現| enum["帳戶列舉的徵兆"]
    sign -->|0xC000006A 連續出現| guess["密碼猜測的徵兆"]
    sign -->|0xC0000072| disabled["對離職員工帳戶的嘗試"]
    enum --> triple["以三件一組確定"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["目標帳戶+來源+代碼"]

圖 7: 失敗原因用代碼確定，再與目標帳戶、來源合成三件一組來判讀。

4.3. 4740 ── 鎖定的發生源就看「呼叫端電腦名稱」

找出發生源: 4740 的呼叫端電腦名稱

4740 是「使用者帳戶已被鎖定」(子類別為使用者帳戶管理)。這個事件的主角是「呼叫端電腦名稱(Caller Computer Name)」欄位，其中記錄著引發鎖定的登入嘗試是從哪台電腦來的。¹⁶ 在這裡鎖定發生源裝置，再清查那台裝置上殘留的舊認證資訊，就是標準做法。

原因幾乎都是某個在密碼變更後仍持續使用舊認證資訊的東西(已儲存的認證資訊、一直維持中斷連線狀態的 RDP 工作階段、以舊密碼設定的服務或工作)。

flowchart TB
    accTitle: 帳戶鎖定調查的標準做法
    accDescr: 用 4740 的呼叫端電腦名稱鎖定發生源裝置，再清查那台裝置上殘留的已儲存認證資訊、一直維持中斷連線狀態的 RDP 工作階段，以及以舊密碼設定的服務或工作
    ev["4740 發生鎖定"] --> caller["確認呼叫端電腦名稱"]
    caller --> src["鎖定發生源的裝置"]
    src --> sweep["清查舊的認證資訊"]
    sweep -.-> c1["已儲存的認證資訊"]
    sweep -.-> c2["一直維持中斷連線狀態的 RDP 工作階段"]
    sweep -.-> c3["以舊密碼設定的服務或工作"]

圖 8: 從 4740 的「呼叫端電腦名稱」鎖定發生源，再清查那台裝置上的舊認證資訊。

找出失敗的證跡: 不是發生源，也要看接受請求的那一端

有一點要注意。4625 記錄的位置是接受登入嘗試的那一端電腦。如果原因是發生源裝置對檔案伺服器等發出的網路登入，發生源裝置本身的 Security 記錄檔裡不會留下 4625，證跡會留在存取目標伺服器的 4625，若是網域帳戶則留在網域控制站端的 4776(NTLM)/4771(Kerberos 事前驗證失敗)。⁷⁸ 當「發生源裝置的記錄裡什麼都沒有」時，請去查看接受請求的那一端。

調查的流程可以整理成: 用 4740 的呼叫端找出發生源 → 依時間順序比對存取目標的 4625 或網域控制站的 4776/4771 → 確認發生源裝置上已儲存的認證資訊、服務、工作等。找出發生源，和找出失敗事件記錄在哪裡，是兩件不同的事。

flowchart TB
    accTitle: 失敗證跡所留下的機器
    accDescr: 網路登入的失敗不會留在發生源裝置本身，而是記錄在接受登入嘗試的存取目標伺服器的 4625 上，若是網域帳戶則在網域控制站端的 4776 或 4771 也會留下證跡
    src["發生源裝置（本身不會留下 4625）"] -->|網路登入| target["存取目標伺服器"]
    target -.-> e4625["記錄 4625"]
    src -->|網域帳戶的驗證| dc["網域控制站"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

圖 9: 4625 留在接受請求的那一端。發生源裝置上什麼都沒有時，就去看存取目標伺服器與網域控制站端。

4.4. 4720 系列 ── 帳戶的建立、變更與群組成員新增

把帳戶的變更和群組成員的變更分開

帳戶管理類的事件編號是連號排列的。4720(建立使用者帳戶)¹⁷、4726(刪除)、4738(變更)，以及群組這一側的成員新增/移除。

群組成員的變更要注意事件 ID 會依群組種類而分開。本機群組是 4732/4733，全域群組是 4728/4729，通用群組是 4756/4757。¹⁴ Domain Admins 是全域群組，所以新增到該群組會記錄在 4728 ── 如果只把 4732 當成警示條件，就會漏掉最想看到的事象。

對系統管理員群組的非預期新增，即使只有一次也要查

日常情況下這只是服務台作業的記錄，但「標準使用者突然被加入系統管理員群組」「出現了沒有人知道的帳戶」，即使只發生一次也應立刻列為調查對象。Microsoft 也把對特權群組的非預期成員新增，列為單次即應警示的範例。³

flowchart TB
    accTitle: 群組種類與成員新增事件
    accDescr: 對群組新增成員的事件 ID 會依群組種類分開，本機群組記錄在 4732、全域群組記錄在 4728、通用群組記錄在 4756，因此新增到全域群組 Domain Admins 要看 4728
    add["對群組新增成員"] --> kind{"群組的種類是?"}
    kind -->|本機| lg["記錄在 4732"]
    kind -->|全域| gg["記錄在 4728"]
    kind -->|通用| ug["記錄在 4756"]
    gg -.-> da["新增到 Domain Admins 在這裡"]
    lg -.-> miss["只監控 4732 會漏掉"]

圖 10: 成員新增的事件 ID 依群組種類而分開。新增到 Domain Admins 是 4728。

4.5. 4688 ── 處理程序建立。命令列記錄是另一個開關

處理程序建立稽核能看出什麼

4688 是「已建立新的處理程序」，每次建立處理程序時，都會記錄建立的帳戶、新處理程序的執行檔路徑、父處理程序，以及權杖提升類型。¹¹ 這是一個能回答「這台伺服器上是誰執行了什麼」的、調查價值很高的事件。

要留下命令列，需要另一項設定與事前檢查

不過預設不會記錄命令列引數。必須另外啟用「在處理程序建立事件中包含命令列」這項群組原則(系統管理範本 > 系統 > 稽核處理程序建立)，4688 的「處理程序命令列」欄位才會填入引數。¹¹¹² 要追查像 powershell -EncodedCommand ... 這類可疑的啟動，這項設定事實上是必要的，但請先理解第 7 章所述的機密混入風險再啟用。請先讀第 7 章，把以引數傳遞機密資訊的地方修正之後再做設定。

flowchart TB
    accTitle: 4688 與命令列記錄的關係
    accDescr: 啟用處理程序建立稽核後 4688 會記錄帳戶、執行檔路徑與父處理程序，但命令列引數要另外啟用一項群組原則才會被記錄，而且有機密資訊以明文寫入的風險
    audit["啟用處理程序建立稽核"] --> ev["記錄 4688"]
    ev -.-> base["帳戶、路徑、父處理程序"]
    ev --> args{"也想看引數?"}
    args -->|維持預設| none["命令列為空"]
    args -->|追加啟用 GPO| cmd["記錄引數"]
    cmd -.-> risk["機密資訊以明文寫入的風險"]

圖 11: 4688 的命令列記錄是另一個開關。啟用之前要先檢查機密混入的風險。

4.6. 4698 ── 排程工作的建立

4698 是「已建立排程工作」，會記錄工作名稱以及工作定義的完整 XML(包含執行命令)。由於登錄排程工作是惡意程式在重新開機後仍能存活的常見手法，Microsoft 建議監控工作建立事件。¹⁵ 即使是業務上大量使用排程工作的環境，「建立」本身也不是日常會發生的事，所以雜訊相對較小。

flowchart TB
    accTitle: 以登錄工作達成持續化與 4698
    accDescr: 惡意程式為了在重新開機後仍能存活，常以登錄排程工作為常見手法，因此監控工作建立時記錄的 4698，就能追到包含執行命令的工作定義
    mal["惡意程式的持續化"] --> task["登錄工作以求存活"]
    task --> ev["記錄 4698"]
    ev -.-> xml["包含執行命令的完整 XML"]
    ev --> watch["監控工作建立即可偵測"]
    watch -.-> low["建立並非日常發生，雜訊小"]

圖 12: 持續化的常見手法登錄工作會留在 4698。從定義 XML 全文可以追到執行命令。

記錄本身是否被清除，還要確認 1102

另一個值得記住的是 1102「稽核記錄檔已清除」。清除 Security 記錄檔一定會留下這個事件，所以在「記錄變成空的」時，可以用它來釐清是故障還是人為操作。¹⁸

flowchart TB
    accTitle: 用 1102 釐清記錄是否被清除
    accDescr: 清除 Security 記錄檔一定會留下 1102，因此當記錄變成空的時候，只要確認有沒有 1102，就能釐清究竟是清除操作還是故障
    empty["記錄變成空的"] --> rule["清除一定會留下 1102"]
    rule --> check{"有沒有 1102?"}
    check -->|有| op["曾經執行過清除操作"]
    check -->|沒有| acc["懷疑是故障的可能性"]

圖 13: 清除 Security 記錄檔一定會留下 1102。空的記錄就用有沒有 1102 來釐清是故障還是操作。

5. 記錄檔容器的設計 ── 最大容量與保留

5.1. 滿了之後，失去的是「舊記錄」還是「新記錄」

在增加稽核原則之前，先確認承接的容器。Security 記錄檔有最大容量與保留模式，在覆寫模式(常見的預設組態)下，一旦達到最大容量，新事件就會覆寫最舊的事件。反過來在保留模式(不覆寫)下，記錄檔一旦滿了，被捨棄的反而是新事件。¹⁰ 這兩種行為都可能造成「回過神來才發現記錄不見了」，所以要先掌握現況。

5.2. 從實際還留著的天數，思考需要的容量

# 確認 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:<位元組數>，或透過群組原則配發。¹⁰

容量要從「想保留幾天份」來思考。 增加稽核子類別會使事件量增加，因此變更設定之後，請重新確認實際還留著的天數。也需要在被覆寫之前定期匯出，或彙整到另一台機器的維運做法。

flowchart TB
    accTitle: 從保留天數反推的容量設計
    accDescr: 用 Get-WinEvent 的 ListLog 確認組態與筆數，再從最舊事件的時間求出實際的保留天數，若不足以滿足事件調查想回溯的天數就擴大最大容量
    check["用 ListLog 確認組態與筆數"] --> oldest["確認最舊事件的時間"]
    oldest --> days["算出實際的保留天數"]
    days --> enough{"足以滿足需求?"}
    enough -->|足夠| keep["維持目前的容量"]
    enough -->|不足| grow["擴大最大容量"]
    grow -.-> how["用 wevtutil sl 或 GPO 設定"]

圖 14: 確認實際還留著的天數，從想回溯的天數反推決定最大容量。

5.3. CrashOnAuditFail 不是用來解決容量不足的設定

另外，安全性選項中有一項「稽核: 如果無法記錄安全性稽核則立即關閉系統」(俗稱 CrashOnAuditFail)的設定。啟用時一旦無法記錄稽核，系統就會以 STOP 錯誤 C0000244 停止。這是為了絕對不能遺失稽核軌跡的驗證需求而設的設定，預設為停用。

Microsoft 本身也提醒，攻擊者可能產生大量事件、刻意讓伺服器停止，把它轉化成 DoS，一般中小規模環境不應輕易啟用。¹⁹

flowchart TB
    accTitle: 記錄檔滿了時的行為
    accDescr: 保留的組態有覆寫模式與不覆寫模式兩種，在不覆寫模式下一旦無法記錄稽核，若另一項獨立設定 CrashOnAuditFail 也已啟用，系統就會以 STOP 錯誤 C0000244 停止
    full["Security 記錄檔達到最大容量"] --> mode{"保留的組態是?"}
    mode -->|覆寫模式| ow["最舊的事件被覆寫"]
    mode -->|不覆寫| drop["新事件被捨棄"]
    ow -.-> lost["兩者都會造成回過神來記錄不見了"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail 也啟用?"}
    caf -->|是| crash["以 STOP 錯誤 C0000244 停止"]

圖 15: 保留的組態有覆寫與捨棄兩種。CrashOnAuditFail 是另一項獨立設定，在無法記錄時讓系統停止。

6. 調查的實務 ── 篩選、Get-WinEvent、匯出

實際動手的順序是「先用 6.3 保全 → 再用 6.1 或 6.2 分析」。 這裡依調查手段分別說明。單次調查用事件檢視器，筆數多或要反覆進行的調查則用 PowerShell。

6.1. 在事件檢視器中篩選

單次調查用事件檢視器就足夠。打開 Security 記錄檔，用「篩選目前的記錄檔」指定事件 ID(例如 4625)與期間。會反覆查看的條件，用「建立自訂檢視」儲存起來，下次只要點一下就好。若不只想用事件 ID，還想用特定帳戶等條件篩選，可以在篩選對話方塊的 XML 分頁中直接編輯 XPath 查詢。

6.2. 使用 Get-WinEvent 擷取

筆數多的調查、多重條件、定期執行時，就切換到 PowerShell 的 Get-WinEvent。重點是使用讓篩選在伺服器端生效的 -FilterHashtable。⁹

flowchart TB
    accTitle: 調查手段的區分使用
    accDescr: 單次調查用事件檢視器的篩選就足夠，會反覆查看的條件存成自訂檢視，筆數多的調查或多重條件與定期執行則切換到 Get-WinEvent
    q{"是什麼樣的調查?"}
    q -->|單次| viewer["用事件檢視器篩選"]
    q -->|會反覆查看的條件| view["存成自訂檢視"]
    q -->|大量、多重條件、定期| ps["切換到 Get-WinEvent"]
    ps -.-> hash["用 FilterHashtable 篩選"]

圖 16: 單次用事件檢視器，要反覆進行就用自訂檢視，筆數一多就用 Get-WinEvent。

依 ID 與期間篩選，取出目標帳戶、來源與失敗原因

下面的前半段取得最近 24 小時的 4625。後半段則是取出 XML 各欄位，依帳戶、Status、SubStatus、來源的組合分別統計筆數的範例。最後的表格不是個別事件依時間排列的清單，而是把相同組合出現幾次，依由多到少顯示出來。

# 取得最近 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 讀取必要欄位的套路，也可以用在其他事件上

只要備妥這一套從事件的 XML 表示形式中抽出 EventData 的套路，無論是 4624 還是 4688，都能用同樣的要領重複使用。關於 Get-WinEvent 的篩選設計(FilterHashtable 與 XPath 的區分使用、慢查詢的修正方式)，在「使用 Get-WinEvent 有效率地調查事件記錄」中有詳細說明。

flowchart TB
    accTitle: 抽出 EventData 的整形套路
    accDescr: 把用 Get-WinEvent 取得的事件轉換成 XML 表示形式，再抽出 EventData 的各欄位整形成表格，這套做法不限於 4625，在 4624 或 4688 上也能用同樣的要領重複使用
    get["用 Get-WinEvent 取得"] --> xml["把事件轉換成 XML 表示形式"]
    xml --> pull["抽出 EventData"]
    pull --> shape["整形成表格並統計"]
    shape -.-> reuse["4624 或 4688 也是同樣要領"]

圖 17: 從 XML 表示形式抽出 EventData 再做成表格的套路，換了事件 ID 一樣能重複使用。

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 拿到另一台機器分析

匯出的 .evtx 可以在另一台機器上用 Get-WinEvent -Path C:\logs\security-20260801.evtx 以同樣的方式分析。⁹ 先保全再分析的習慣，和當機調查中「先確保傾印檔」的思路是一樣的(參見「Windows 當機傾印收集入門」)。

flowchart TB
    accTitle: 先保全再分析的流程
    accDescr: 用 wevtutil epl 把調查對象機器的 Security 記錄檔匯出成 evtx 檔案加以確保，再在另一台機器上用 Get-WinEvent 的 Path 指定以同樣方式分析
    target["調查對象機器"] --> export["用 wevtutil epl 保全成 evtx"]
    export --> copy["帶到另一台機器"]
    copy --> analyze["用 Get-WinEvent -Path 分析"]
    export -.-> note["在因覆寫消失之前確保"]

圖 18: 先保全，然後才分析。只要確保成 evtx，就能在另一台機器上一樣地調查。

7. 陷阱 ── 現場容易踩到的 4 個

7.1. 4688 的命令列上會夾帶機密資訊

啟用命令列記錄後，所有處理程序的引數都會以明文寫進 Security 記錄檔。Microsoft 明確指出「所有具有安全性事件讀取存取權的使用者，都能讀取任何處理程序的命令列引數。引數中可能包含密碼等機密資訊」。¹² 只要業務應用程式或指令碼中有一個是用 myapp.exe /user:admin /password:P@ssw0rd 這種方式啟動的，那就等於把機密資訊公開給所有能看記錄檔的人。

啟用之前，要先找出以引數傳遞機密資訊的地方並加以修正。記錄檔的保全與轉送目的地，也需要相同等級的處理規格。

flowchart TB
    accTitle: 啟用命令列記錄的順序
    accDescr: 4688 的命令列記錄在啟用之前要先找出以引數傳遞機密資訊的業務應用程式或指令碼，遵守修正相關之處後再啟用的順序，並對記錄檔的保全與轉送目的地要求相同等級的處理規格
    audit["找出以引數傳遞機密資訊之處"] --> found{"有符合的嗎?"}
    found -->|有| fix["修正傳遞的地方"]
    found -->|沒有| on["啟用命令列記錄"]
    fix --> on
    on -.-> dest["保全與轉送目的地也是相同等級"]

圖 19: 命令列記錄要「先找出並修正，再啟用」。順序反過來就會造成機密外洩。

7.2. 不清楚記錄檔滿了會有什麼行為就在維運

覆寫模式下舊證跡會悄悄消失，設定為不覆寫時新事件會被捨棄，啟用 CrashOnAuditFail 的話則連系統都會停止(第 5 章)。¹⁰¹⁹ 正確做法是掌握自己選的是哪一種行為，並準備好「在消失之前先蒐集起來」的機制(定期匯出或記錄收集平台)。

7.3. 網域控制站與裝置該看的記錄不一樣

4624/4625 記錄在被存取的機器上。⁵⁶ 另一方面，網域帳戶的認證驗證(NTLM 的 4776)記錄在對該認證資訊具有權威的機器上，也就是網域帳戶記錄在網域控制站⁷，而 Kerberos 的事前驗證失敗(4771)則只會記錄在網域控制站。⁸ 「檔案伺服器上沒有 4625=沒有發生攻擊」並不成立，唯有再比對網域控制站端的 4776/4771，才能拼出完整的全貌。至於哪種驗證通訊協定如何運作，請參考「圖解 NTLM 與 Kerberos」。

7.4. 時間同步一有偏差就無法比對

把多台機器的記錄並排、追查「這個 4740 的前一刻是哪台裝置出現了 4625」這種作業，前提是各機器的時鐘要對得上。在網域環境中，Kerberos 本身就對時鐘偏差設有上限(預設 5 分鐘)，一旦超過，驗證本身就會開始失敗。²⁰ 從調查的角度來看，別說 5 分鐘，就連數秒的偏差都會讓人誤讀前後關係，所以請把確認 w32time 的同步狀態排在調查步驟的最前面。

此外，事件的記錄時間是以 UTC 儲存，顯示時則依照檢視機器的時區，因此在讀取從海外據點或設定為 UTC 的伺服器取得的 evtx 時，請不要忘記換算時區。

flowchart TB
    accTitle: 時間同步與比對調查的前提
    accDescr: 把多台機器的記錄依時間順序比對的調查，前提是各機器的時鐘要對得上，數秒的偏差就會讓人誤讀前後關係，超過預設 5 分鐘的偏差更會讓 Kerberos 驗證本身失敗，因此要把 w32time 的同步確認排在調查步驟的最前面
    merge["比對多台機器的記錄"] --> pre["前提是時鐘要對得上"]
    pre --> skew{"時鐘的偏差是?"}
    skew -->|對得上| ok["可以依時間順序追查"]
    skew -->|數秒的偏差| misread["誤讀前後關係"]
    skew -->|超過預設 5 分鐘| kerb["Kerberos 驗證失敗"]
    pre -.-> first["把 w32time 的確認排在步驟最前面"]

圖 20: 多台機器的比對以對時為前提。就連數秒的偏差也會導致前後關係的誤讀。

8. 總結

要把 Windows 的 Security 記錄檔用於調查，必須把記錄的範圍、要讀的位置與項目、保全的機制一起設計。

要把設定理順時

稽核原則不要混用「基本」與「進階」，統一採用進階這一側。用 auditpol /get /category:* 確認現況，以 Microsoft 的基準建議為出發點，從第 3 章以登入、帳戶管理、處理程序建立為主軸的判斷表開始著手。一旦「全部啟用」，就會因雜訊與肥大化而讓調查變得困難。

記錄檔的容器(最大容量、保留模式)佔了稽核設計的一半。確認實際還留著的天數，從需求反推決定容量，並在消失之前匯出或彙整。4688 的命令列記錄，要先檢查機密混入的風險再啟用。

要進行調查時

先保全，然後才分析。用 wevtutil epl 確保下來，確認各機器的記錄位置與時間同步之後再開始讀。單次調查用事件檢視器的篩選，要反覆進行的調查則用 Get-WinEvent -FilterHashtable。

判讀時的關鍵是，4624 看登入類型，4625 看 Status/Sub Status，4740 看呼叫端電腦名稱，4688 看父處理程序與命令列。不要只憑事件 ID 判斷，要確認那是記錄在哪裡的什麼資訊，並比對必要的記錄。

相關文章

• 使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間
• NTLM 廢除會讓業務應用程式停擺嗎 ── 稽核記錄的擷取方式，以及消除相依性的順序
• 圖解 NTLM 與 Kerberos ── 為什麼驗證會「回退」到 NTLM
• SMB 簽章與 LDAP 通道繫結 ── 在實務中補齊 NTLM 對策的「剩餘一半」
• Windows 事件記錄・ETW 入門 ── 讓業務應用程式的日誌搭上 OS 標準機制
• Windows 當機傾印收集入門 - WER/ProcDump/WinDbg

相關諮詢領域

合同會社小村軟體提供 Windows 環境的稽核原則與記錄設計諮詢、以事件記錄為依據的「何時、是誰、做了什麼」調查，以及業務應用程式在驗證與稽核方面引發問題的原因解析。即使還停留在「被要求查看記錄，但不知道該從哪裡下手」的階段也沒關係。

• 缺陷調查・原因分析
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

明明沒有設定任何稽核原則，為什麼 Security 記錄檔中卻已經記錄了 4624 或 4625？

這是因為 Windows 有預設就啟用的稽核子類別。例如「登入」子類別，在 Windows 10 版本 1809 以後，成功與失敗兩者都是預設啟用的，所以即使什麼都沒設定，4624(成功)與 4625(失敗)也會被記錄下來。不過維持預設狀態時，像是認證驗證(4776)或處理程序建立(4688)這類調查時會想要的事件，大多不會被記錄。自己所在的環境目前啟用了哪些項目，可以用 auditpol /get /category:* 確認。在此基礎上，把不足的子類別在進階稽核原則那一側明確啟用，就是實務上的標準做法。

想要調查登入失敗，但在目標伺服器的 Security 記錄檔中卻找不到 4625。應該查看哪裡？

首先請確認一項原則：4625 會記錄在「嘗試登入的那台電腦」上。如果是使用者裝置上的登入失敗，就在該裝置端；如果是存取檔案伺服器失敗，就在檔案伺服器端。接著用 auditpol /get /category:* 確認「登入」子類別的失敗稽核是否已啟用。若是網域帳戶，通常在網域控制站端的認證驗證(4776)或 Kerberos 事前驗證失敗(4771)中也會留下記錄，當無法鎖定是哪台裝置時，從網域控制站端著手調查反而更快。若仍然找不到，請確認是否因記錄檔覆寫而使過去的記錄消失(檢查記錄檔的最大容量與最舊事件的時間)。

應該啟用處理程序建立(4688)的命令列記錄嗎？

這項設定的調查價值非常高，但也是一項必須先理解風險再決定是否啟用的設定。啟用後，所有處理程序的命令列引數都會以明文形式記錄在 Security 記錄檔中。只要有一個以命令列傳遞密碼或 API 金鑰的指令碼或業務應用程式，那份機密資訊就會變成所有能讀取 Security 記錄檔的人都看得到。Microsoft 本身也明確指出了這個注意事項。建議的順序是：先檢查自家的指令碼是否有以命令列引數傳遞機密資訊，修正相關之處後，再啟用這項設定。

Security 記錄檔的最大容量應該設為多少？

正確做法是從「希望手邊保留幾天份」反推回去，並沒有一個放諸四海皆準的數值。目前的設定與實際狀況可以用 Get-WinEvent -ListLog Security 確認，最舊事件的時間與目前時間之差，就是「實際上目前保留的天數」。增加稽核子類別會使事件量增加，因此變更設定後，務必重新確認這個實際保留天數。在事件應變中，經常需要用到數週到數個月前的記錄，因此建議在記錄因覆寫而消失之前定期匯出，或透過記錄收集機制彙整到另一台機器上，會比較安心。

帳戶鎖定(4740)的原因該如何調查？

4740 事件的「呼叫端電腦名稱(Caller Computer Name)」欄位是最初的線索。這裡記錄的是引發鎖定的失敗登入是從哪台電腦發出的。不過請注意，失敗記錄本身(4625)並不會留在發生源那一端，而是留在接受登入嘗試的那一端。如果是源自網路登入，就依時間順序追查存取目標伺服器的 4625，若是網域帳戶則追查網域控制站的 4776/4771。確定發生源裝置之後，接著要在該裝置端清查是否有在密碼變更後仍持續使用舊認證資訊的項目，也就是已儲存的認證資訊、一直維持中斷連線狀態的遠端桌面工作階段，以及使用舊密碼設定的服務或排程工作。若鎖定反覆發生，也請一併確認時間同步是否有偏差。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。