VBS（以虛擬化為基礎的安全性）和核心隔離是同一件事嗎？

嚴格來說不同。VBS 是用 Hypervisor 建立隔離環境的基礎技術，Windows 安全性應用程式裡的「核心隔離」是把建立在 VBS 上的數項保護歸在一起的畫面名稱。代表性的是「記憶體完整性」，指的是 HVCI（由 Hypervisor 保護的程式碼完整性）。各服務的執行狀態請查詢 Win32_DeviceGuard，不要從畫面顯示判斷。

就算有系統管理員權限，或從核心驅動程式，真的讀不到 VTL1 記憶體嗎？

讀不到。每個 VTL 的記憶體存取保護由 Hypervisor 對分割區的實體位址空間管理，分割區內執行的軟體無法變更。即使是在核心（ring 0）執行的程式碼，也不被允許從 VTL0 存取 VTL1 記憶體。

為什麼啟用記憶體完整性（HVCI）會讓驅動程式不能用？

在 HVCI 環境中，核心分頁只有通過完整性驗證後才會變成可執行，而且不允許寫入可執行分頁。未簽署的驅動程式，或會改寫可執行記憶體的舊設計驅動程式，無法滿足這項限制，載入會被擋下。可在 CodeIntegrity Operational 記錄（事件識別碼 3087 等）確認擋下。

Credential Guard 保護什麼，不保護什麼？

它在隔離環境中保護網域認證資料的 NTLM 密碼雜湊、Kerberos TGT，以及應用程式以網域認證資料儲存的內容。Kerberos 服務票證、本機帳號與 Microsoft 帳號的認證資料、鍵盤側錄對輸入的竊取，以及實體攻擊，都不在範圍內。

要在哪裡確認 VBS 是否在跑？

看 msinfo32 的「以虛擬化為基礎的安全性」欄位，或從 PowerShell 查詢 root/Microsoft/Windows/DeviceGuard 命名空間的 Win32_DeviceGuard 類別。若 SecurityServicesRunning 含有 1，Credential Guard 在跑；若含有 2，記憶體完整性（HVCI）在跑。

Windows 虛擬化的深層（第 2 回）── 連核心都看不到的記憶體：VBS、HVCI 與 Credential Guard 如何運作

2026年08月22日 03:00 · Go Komura · Windows, 虛擬化, 安全性, VBS, HVCI, Credential Guard

曾經有一段時間，系統管理員權限對 Windows 上的攻擊者來說是「目標」。以系統管理員載入核心驅動程式、傾印 LSASS 處理程序的記憶體，就能拿到密碼雜湊與 Kerberos 票證。從那裡只是帶著偷來的雜湊走到另一台機器。

在 Credential Guard 正在執行的現行 Windows 11 上──從 22H2 起，在符合 Enterprise、Education 等授權需求以及硬體需求的裝置上，這是預設狀態──那套劇本行不通。就算完全拿下核心的攻擊者把記憶體搜遍，受保護網域認證資料的真正雜湊也找不到「在那個作業系統裡面」。若沒有在跑，舊的危險仍在，因此請和本文後半的確認方法一起讀。

那麼它們在哪裡？答案是「同一台 PC 裡做出來的另一個世界」。如第 1 回所見，主機 Windows 跑在 Hypervisor 之上的根分割區（「你的 Windows 其實跑在哪裡？」）。本文從那裡繼續，追 Hypervisor 在同一個分割區裡再畫下的一條邊界。

第 2 回要回答的問題只有一個。

Windows 把系統管理員和核心都讀不到的秘密放在哪裡？

對象讀者是在設定畫面或疑難排解案例中看過核心隔離、記憶體完整性、Credential Guard 這些詞，想從機制往上理解實物的開發者與維運人員。前提環境是 x64 Windows 10/11 或現行 Windows Server（與第 1 回相同，對 ring 與 SLAT 的討論假設 x64；Arm64 使用例外層級等不同機制）。所需背景是第 1 回談過的分割區與 SLAT 概念。難度為中階。目標是結構解說，不是安全性功能的設定操作說明。

1. 先講結論

Windows 加了一條稱為 VTL（Virtual Trust Level）的特權軸，把秘密放在 VTL1。VTL1 的記憶體無法從跑在 VTL0 的一般核心讀取。守住邊界的不是核心本身，而是持有 SLAT 轉譯表的 Hypervisor。

那就是以虛擬化為基礎的安全性（VBS）的骨架。VBS 用 Hypervisor 建立隔離環境，並把安全性功能放進去。它的設計假設即使核心被攻陷，隔離環境仍受保護。¹

flowchart TB
    accTitle: VBS 做出的兩個世界
    accDescr: VTL0 與 VTL1 坐在同一個分割區裡；VTL0 持有一般核心與應用程式，VTL1 持有 Secure Kernel 與隔離的安全性功能，Hypervisor 守住邊界
    subgraph vtl0 ["VTL0（一般世界）"]
        apps["應用程式（ring 3）"]
        ntk["NT 核心與驅動程式（ring 0）"]
    end
    subgraph vtl1 ["VTL1（隔離世界）"]
        ium["隔離的安全性功能"]
        sk["Secure Kernel"]
    end
    hv["Hypervisor（經 SLAT 強制邊界）"] --- vtl0
    hv --- vtl1
    ntk -.->|讀不到| ium

圖 1: 一個 Windows 裡有兩個世界，VTL0 核心無法存取 VTL1 記憶體。

重點是這不是「再拉起另一台虛擬機器」。VTL0 與 VTL1 在同一個分割區、同一個 Windows 裡面。我們依序看這道分裂如何實現。

2. Ring 模型的極限 ── 守護者與被守護者坐在同一高度

傳統 Windows 安全性建立在 ring（特權層級）的階梯上。使用者模式（ring 3）由核心模式（ring 0）守護。那麼誰守護 ring 0──沒有人能。Ring 0 是最高特權。

這個結構有兩項結構弱點。

核心不是一塊整石。在 ring 0，不只 Windows 本身，大量第三方驅動程式也在跑。其中任何一個有漏洞，攻擊者就取得 ring 0 的程式碼執行。
從 ring 0 看得到一切。無論 LSASS 這類使用者模式處理程序怎麼自衛，對拿下核心的攻擊者來說，它的記憶體可以自由讀取。保護屬性與分頁表一樣由核心自己管理。

flowchart TB
    accTitle: 傳統 ring 模型中的認證資料竊取路徑
    accDescr: 經由有漏洞的驅動程式拿下 ring 0 的攻擊者，能以核心的完整權限讀取 LSASS 處理程序記憶體並取得密碼雜湊
    mal["攻擊者程式碼"] -->|利用有漏洞的驅動程式| r0["拿下 ring 0"]
    r0 --> readall["能讀取全部實體記憶體"]
    readall --> lsass["從 LSASS 記憶體取得雜湊"]
    lsass --> lateral["被濫用於側向移動到其他機器"]

圖 2: 因為守護者（核心）與被守護者（秘密）坐在同一高度，根本弱點是 ring 0 倒下，一切就倒下。

那麼需要的是「比 ring 0 更高的地方」。那個地方在第 1 回已經出現。Hypervisor 以高於核心的特權執行，並早早獨占 CPU 記憶體存取權限（SLAT）的控制。Hypervisor 守護的隔離區域，即使面對來自 ring 0（監督者模式）作業系統軟體的存取也受保護。²

3. VSM 與 VTL ── 再加一條特權軸

3.1. Virtual Trust Levels（VTL）

提供這份隔離的 Hypervisor 功能家族稱為 VSM（Virtual Secure Mode）。VSM 是 Device Guard、Credential Guard、虛擬 TPM 等的基礎。²

VSM 的中心概念是 VTL（Virtual Trust Level）。重點如下。²

VTL 是階層式的，數字越高，特權越高。VTL0 最低；VTL1 比 VTL0 更有特權。
架構上定義最多 16 層，但目前實作的是兩層：VTL0 與 VTL1。
每個 VTL 有獨立的記憶體存取保護。這些保護由 Hypervisor 對分割區的實體位址空間管理，因此分割區內的系統軟體無法變更。
虛擬處理器對每個 VTL 有分開的暫存器狀態與中斷機制，較低的 VTL 不能偷看較高 VTL 的狀態。

flowchart TB
    accTitle: 構成 VTL 隔離的三項獨立
    accDescr: 記憶體存取保護、虛擬處理器暫存器狀態、中斷機制依 VTL 獨立，較低的 VTL 碰不到較高 VTL 的任何一項
    vtl["每個 VTL 獨立的項目"] --> m1["記憶體存取保護"]
    vtl --> m2["虛擬處理器暫存器狀態"]
    vtl --> m3["中斷機制"]
    m1 -.-> rule["較低 VTL 碰不到較高 VTL"]
    m2 -.-> rule
    m3 -.-> rule

圖 3: 不只記憶體，連 CPU 狀態與中斷都做成另一個世界，這三件一套才不留窺視孔。

若 ring（0 與 3）是分開「作業系統與應用程式」的軸，VTL 就是分開「一般世界與隔離世界」的第二條軸。兩軸正交，VTL1 裡面也有核心模式與使用者模式。

flowchart TB
    accTitle: Ring 與 VTL 兩軸做出的四個區域
    accDescr: Ring 軸分開核心模式與使用者模式，VTL 軸分開一般世界與隔離世界，組合產生四個區域：一般應用程式、NT 核心、IUM trustlet、Secure Kernel
    subgraph ax0 ["VTL0（一般世界）"]
        a0["Ring 3：一般應用程式"]
        k0["Ring 0：NT 核心與驅動程式"]
    end
    subgraph ax1 ["VTL1（隔離世界）"]
        a1["Ring 3：IUM（trustlet）"]
        k1["Ring 0：Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

圖 4: 現在有兩條特權軸，「是不是核心？」與「是不是隔離世界？」變成分開的問題。

3.2. 邊界的實質是 SLAT

第 1 回說過，把客體實體位址（GPA）對應到真正 RAM（SPA）的第二層轉譯表──SLAT──由 Hypervisor 持有。VSM 用的正好是這個性質。VTL 隔離是用 Hyper-V Hypervisor 與 SLAT 做出來的。³

當 VTL1 宣告「這塊記憶體不要給 VTL0 看」，Hypervisor 就從 VTL0 的轉譯表拿掉該分頁的存取權限。從那時起，即使 VTL0 核心想碰那個位址，也會在 CPU 的位址轉譯階段被拒絕。核心怎麼改寫自己的分頁表都沒用。分頁表（GVA→GPA）也許屬於核心，但那之後的轉譯（GPA→SPA）與最終存取權限屬於 Hypervisor。

flowchart TB
    accTitle: 從 VTL0 存取 VTL1 記憶體被拒絕的流程
    accDescr: VTL0 核心嘗試讀取 VTL1 記憶體時，能通過自己的分頁表，但被 SLAT 存取保護拒絕，控制權交給 Hypervisor
    try["VTL0 核心嘗試讀取 VTL1 分頁"] --> pt["通過核心自己的分頁表"]
    pt --> slat{"SLAT 存取保護允許嗎？"}
    slat -->|不允許| deny["Hypervisor 介入並拒絕存取"]
    slat -->|允許| ok["一般記憶體存取"]
    deny -.-> point["在核心無法變更的那一層受保護"]

圖 5: 屏障坐在核心外面，分割區內的軟體無法變更 SLAT 保護。

記憶體系列第 1 回寫過「VAD、PTE 與保護屬性決定是否允許存取」。在 VBS 環境可以整理成：那些全部通過之後，還有一道 SLAT 檢查點在等。

3.3. Secure Kernel 與 IUM

在 VTL1 裡跑的不是一般 NT 核心，而是稱為 Secure Kernel 的小型核心。VTL1 的使用者模式稱為 IUM（Isolated User Mode），在那裡跑的程式稱為 trustlet（受信任的處理程序）。³

Trustlet 不能像一般處理程序那樣什麼都做。多數系統呼叫會編組到 VTL0 端的 NT 核心，在那裡請求工作。³ VTL1 不是「什麼都能做的上層世界」；它被刻意做小，作為持有秘密的金庫。能帶進金庫的程式碼越少，攻擊面越小。

flowchart TB
    accTitle: Trustlet 系統呼叫的流程
    accDescr: VTL1 的 trustlet 多數系統呼叫不自己處理；把它們編組到 VTL0 的 NT 核心，只收回結果，讓 VTL1 保持精小
    tl["Trustlet（VTL1 的 IUM）"] --> sc{"需要系統呼叫"}
    sc -->|多數情況| mar["要求被編組到 VTL0 的 NT 核心"]
    mar --> res["只收回結果"]
    res -.-> small["VTL1 保持精小，縮小攻擊面"]

圖 6: 金庫沒有自己的設施；雜務外包，只繼續守護秘密。

4. HVCI ── 在金庫裡驗證核心程式碼完整性

4.1. 正在驗證什麼

坐在 VBS 上的第一個代表性功能是記憶體完整性──HVCI（由 Hypervisor 保護的程式碼完整性）。Windows 有一套程式碼完整性機制，在核心模式驅動程式與二進位啟動前檢查，不載入未簽署或不受信任的。HVCI 把這份驗證跑在 VBS 的隔離環境裡。¹

把驗證邏輯本身搬進 VTL1 的理由，正好是第 2 節的弱點。若驗證程式碼坐在 VTL0 核心裡，拿下核心的攻擊者就能把驗證換掉。若它在 VTL1，那隻要換掉的手搆不到。

flowchart TB
    accTitle: 驗證程式碼住在哪裡造成的差異
    accDescr: 若驗證程式碼坐在 VTL0 核心裡，拿下核心就能停用它；若在 VTL1，即使拿下核心的攻擊者也搆不到，驗證受保護
    atk["已拿下核心的攻擊者"] --> q{"程式碼完整性驗證住在哪？"}
    q -->|"在 VTL0 核心裡（傳統）"| bad["驗證邏輯能被換掉"]
    q -->|"VTL1 的隔離環境（HVCI）"| good["換掉搆不到"]
    bad --> res1["未簽署程式碼能在核心執行"]
    good --> res2["核心被攻陷後驗證仍繼續運作"]

圖 7: 不要把檢查點放進可能被突破的那一側──驗證邏輯的這次搬家，就是 HVCI 的本質。

4.2. 可執行分頁的規則

HVCI 的效果不限於「啟動時檢查」。它也約束核心記憶體配置。⁴

核心分頁只有通過程式碼完整性驗證後才會變成可執行。
可執行分頁不會變成可寫（所謂 W^X）。

這兩條到位後，即使緩衝區溢位這類漏洞讓你改寫核心記憶體，也不能把改寫後的內容拿去執行。可執行分頁不能改寫，能改寫的分頁不能執行。⁴ 執行權限的最終後盾是 SLAT 端的執行權，VTL0 核心無法操作。

flowchart TB
    accTitle: HVCI 環境中核心分頁變成可執行之前
    accDescr: 驅動程式載入要求在 VBS 隔離環境接受程式碼完整性驗證；通過則允許為可執行、不可寫的分頁，失敗則擋下並記錄到 CodeIntegrity 記錄
    load["要求載入並執行核心程式碼"] --> verify{"隔離環境中的程式碼完整性驗證"}
    verify -->|通過| exec["允許為可執行分頁（禁止寫入）"]
    verify -->|失敗| block["載入被擋下"]
    block --> log["CodeIntegrity 記錄（3087）"]
    exec -.-> wx["可寫分頁維持不可執行"]

圖 8: 「執行與寫入不能共存」這條規則的驗證在 VTL1 端做，VTL0 核心無法推翻。

從攻擊者的視角追一次，規則如何生效就清楚了。

flowchart TB
    accTitle: HVCI 環境中程式碼注入失敗的流程
    accDescr: 即使漏洞讓你改寫核心記憶體，能寫的分頁不可執行，可執行分頁一開始就不能改寫，因此注入的程式碼無法被拿去執行
    inj["嘗試經漏洞竄改核心記憶體"] --> which{"目標是哪一個分頁？"}
    which -->|可寫分頁| wok["寫入成功"]
    which -->|可執行分頁| xfail["寫入本身不可能"]
    wok --> nx["但那個分頁不可執行"]
    nx --> dead["注入的程式碼無法被執行"]
    xfail --> dead

圖 9: 不讓可寫分頁與可跑分頁交叉的意義是：無論從哪個入口進，都會撞上死路。

4.3. 驅動程式相容性的代價

這條規則會撞上舊設計的驅動程式。執行期改寫自己的程式碼、沒有簽章，或要求同時可執行又可寫的記憶體──這類驅動程式在 HVCI 環境無法載入。擋下的事實可在事件檢視器的 Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational 確認（事件識別碼 3087 是代表性的）。⁵

「啟用記憶體完整性之後，某個周邊不能用了」──很多時候，那就是問題的真正身分。正確回應是更新到相容 HVCI 的驅動程式；停用記憶體完整性應想成放棄整份保護的最後手段。若從驅動程式開發的角度參與這份驗證，也請看篩選驅動程式文章（「Windows 迷你篩選驅動程式」）。

flowchart TB
    accTitle: 記憶體完整性下周邊不能用時的隔離
    accDescr: 在 CodeIntegrity Operational 記錄找出被擋下的驅動程式；正確回應是更新到相容 HVCI 的版本，沒有就問廠商，把停用當成不要做成永久設定的最後手段
    sym["啟用記憶體完整性後裝置不能用"] --> log2["在 CodeIntegrity 記錄找出被擋下的驅動程式"]
    log2 --> upd{"有相容 HVCI 的驅動程式嗎？"}
    upd -->|有| fix2["更新並在維持 HVCI 開啟下解決"]
    upd -->|沒有| ask2["向廠商要求相容版本"]
    ask2 -.-> temp["停用是最後手段，不是永久設定"]

圖 10: 第一個該看的不是設定畫面而是記錄，事件識別碼 3087 知道是誰擋下了載入。

5. Credential Guard ── 雜湊在 LSAIso 裡面

5.1. LSASS 與 LSAIso

坐在 VBS 上的第二個代表性功能，就是開頭那個謎的答案：Credential Guard。

傳統 Windows 把 NTLM 雜湊與 Kerberos 票證放在 LSA 處理程序（lsass.exe）的記憶體裡。啟用 Credential Guard 後，其中受保護秘密的儲存──網域認證資料的 NTLM 雜湊與 Kerberos TGT（Ticket Granting Ticket）──移到 LSAIso.exe，一個跑在 VTL1 的 IUM 裡的 trustlet。⁶

lsass.exe（VTL0）繼續像以前一樣，作為驗證處理的櫃台執行。
真正的秘密由 LSAIso.exe（VTL1）持有，無法從 VTL0 存取。
兩者經由 RPC（遠端程序呼叫）通訊。
LSAIso 完全不安置裝置驅動程式，只安置最少的已簽署二進位。簽章用 VBS 信任的憑證驗證。⁶

flowchart TB
    accTitle: 啟用 Credential Guard 時認證資料坐在哪裡
    accDescr: VTL0 的 lsass 作為驗證櫃台，經 RPC 與 VTL1 的 LSAIso 通訊；受保護網域認證資料的真正雜湊與 TGT 由 LSAIso 持有，因此在 VTL0 取得系統管理員權限並傾印 lsass 的攻擊者仍拿不到受保護的實質
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe（驗證櫃台）"]
        att["攻擊者（系統管理員權限）"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe（秘密的金庫）"]
    end
    lsassP <-->|RPC| iso
    att -->|記憶體傾印| lsassP
    att -.->|搆不到| iso

圖 11: 因為櫃台與金庫被分開，傾印 lsass 再也拿不到受保護網域認證資料的真正雜湊。

從 Windows 11 版本 22H2 起，在符合授權需求（Enterprise E3/E5、Education A3/A5）與硬體需求的裝置上，VBS 與 Credential Guard 預設啟用。在 Pro 等版本，Credential Guard 不會自動啟用（有例外，例如先前在符合資格的授權下啟用的機器後來降級）。⁷ 開頭「劇本行不通」不是特殊附加產品的故事；那是目標版本上現行 Windows 的標準狀態。

flowchart TB
    accTitle: 從登入到驗證的認證資料流程
    accDescr: 登入後真正的秘密儲存在 VTL1 的 LSAIso；每次需要驗證時，VTL0 的 lsass 經 RPC 請求計算，只有驗證處理的結果回到 VTL0，受保護的長期秘密本身不會被傳回
    signin["使用者登入"] --> front["lsass 作為櫃台處理"]
    front --> store["真正的秘密儲存在 LSAIso"]
    auth["後續驗證要求"] --> front
    front -->|"經 RPC 請求計算"| store
    store -->|"傳回結果（不傳回秘密）"| front

圖 12: 受保護的長期秘密本身從不離開金庫；回到 VTL0 的是驗證處理的結果，例如票證。

5.2. 精確知道什麼不受保護

Credential Guard 不是萬能盾。受保護的是網域認證資料的 NTLM 雜湊、Kerberos TGT（Ticket Granting Ticket），以及以網域認證資料儲存的內容。以下不在範圍內。⁸

Kerberos 服務票證（TGT 受保護）
本機帳號與 Microsoft 帳號的認證資料
鍵盤側錄對輸入的竊取，以及實體攻擊
使用 NTLMv1、MS-CHAPv2、Digest 或 CredSSP 的路徑上的認證資料
自行管理認證資料的第三方軟體內部

此外，啟用 Credential Guard 後，NTLMv1、未受限的 Kerberos 委派等會不能用，因此依賴舊式驗證的業務系統需要相容性檢查。⁸ 不是「啟用就結束」，而是掌握防禦範圍內外，其餘用其他控制補上──那才是實務上正確的用法。

flowchart TB
    accTitle: Credential Guard 的防禦範圍
    accDescr: 網域 NTLM 雜湊與 TGT，以及已儲存的網域認證資料受保護；服務票證、本機帳號、鍵盤側錄、實體攻擊，以及應用程式私下儲存的認證資料不在範圍內
    scope{"這個秘密在保護邊界的哪一側？"} --> inA["網域 NTLM 雜湊與 TGT"]
    scope --> outA["服務票證與本機帳號"]
    inA --> prot["在 LSAIso 受保護"]
    outA --> unprot["不受保護（需要其他控制）"]
    unprot -.-> outB["按鍵、實體攻擊、應用程式私下儲存也不在範圍"]

圖 13: 防禦範圍畫得很清楚，線外用多重要素驗證與應用程式端設計來補。

6. 自己看一看

你可以在自己的機器上確認 VBS 與各功能的執行狀態。

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

讀法如下。⁹

若 VirtualizationBasedSecurityStatus 為 2，VBS 已啟用且正在執行。
若 SecurityServicesRunning 含有 1，Credential Guard 在跑；若 含有 2，記憶體完整性（HVCI） 在跑。

要在圖形介面確認執行狀態，看 msinfo32 的「以虛擬化為基礎的安全性」欄位（正在執行的服務會被列出，例如「Hypervisor enforced Code Integrity」）。Windows 安全性應用程式「裝置安全性 > 核心隔離」底下的「記憶體完整性」開關是反映設定的畫面；剛啟用後等重新開機、或啟動時的相容性問題，可能看起來開著但 HVCI 其實沒在跑──因此是否在跑，要從 msinfo32 或 Win32_DeviceGuard 的 SecurityServicesRunning 判斷。⁵

工作管理員的詳細資料索引標籤上也有痕跡。VBS 正在執行的機器會看到稱為「Secure System」的處理程序。LsaIso.exe 是 Isolated LSA 服務被託管在 VTL1 時出現的處理程序，只啟用 HVCI 的組態通常不會出現。不過處理程序有無只是痕跡，Credential Guard 是否在跑仍如上所述，從 SecurityServicesRunning（是否含有 1）判斷。兩者都是從 VTL0 看得見、對應 VTL1 端世界的視窗。

flowchart TB
    accTitle: 如何檢查 VBS 相關功能正在執行
    accDescr: 查詢 Win32_DeviceGuard 確認 VBS 在跑，從 SecurityServicesRunning 的值判斷 Credential Guard 與 HVCI，驅動程式問題則看 CodeIntegrity 記錄
    q0["Win32_DeviceGuard"] --> q1{"VBS Status 為 2？"}
    q1 -->|否| off["VBS 沒在跑"]
    q1 -->|是| q2{"含有 1 或 2？"}
    q2 -->|1| cg["Credential Guard 開"]
    q2 -->|2| hvciR["HVCI 開"]
    hvciR -.-> ev["CodeIntegrity 3087"]

圖 14: 狀態確認分三階段：VBS 本身、其上的各服務，以及出問題時的記錄。

7. 實務上要避開的三種誤讀

7.1. 「保護系統管理員權限就夠了。VBS 是伺服器端的故事」

Credential Guard 防止的是系統管理員權限被拿下之後損害擴散（雜湊外洩與側向移動）。也就是說 VBS 是假設已被攻陷的縱深防禦的一層，而且在用戶端 PC 上才有效。在符合需求的 Windows 11 上，預設啟用是標準，因此正確姿態不是「這和我們無關」，而是「假設它已經在跑來管理相容性」。

flowchart TB
    accTitle: 攻陷階段與 VBS 生效的位置
    accDescr: 初始存取由多重要素驗證與教育訓練等其他控制涵蓋；HVCI 擋下權限提升後對核心的程式碼注入；Credential Guard 擋下受保護網域秘密的竊取與側向移動，但搆不到範圍外的秘密
    s1["初始存取（釣魚等）"] --> s2["權限提升"]
    s2 --> s3["對核心的程式碼注入"]
    s3 --> s4["竊取受保護網域秘密與側向移動"]
    s1 -.-> d1["MFA、教育訓練與 EDR 涵蓋這裡"]
    s3 -.-> d2["HVCI 擋下這一步"]
    s4 -.-> d3["Credential Guard 擋下這裡（僅受保護的秘密）"]

圖 15: VBS 不是「別讓他們進來」的技術；它是「進來之後別讓他們贏」的技術，守護的階段不同。

7.2. 「記憶體完整性出問題，關掉就好」

關掉當下會讓事情能動，但同時整面拆掉對核心程式碼注入的屏障。正確回應是先在 CodeIntegrity 記錄找出被擋下的驅動程式，套用廠商的更新版本。即使為了驗證暫時停用，我們建議不要把那變成永久設定的運作方式。

7.3. 「有了 Credential Guard，密碼就偷不走」

那是把防禦範圍搞混的過度自信。服務票證、本機帳號、按鍵本身，以及應用程式私下儲存的認證資料，都不在範圍內。⁸ 釣魚與鍵盤側錄需要其他控制（多重要素驗證、Windows Hello，以及應用程式端認證資料管理的審查）。

8. 總結

VBS 用 Hypervisor 建立隔離環境，並在假設核心可能被攻陷的前提下保護安全性功能。¹
隔離單位是 VTL；目前實作兩層，VTL0（一般世界）與 VTL1（Secure Kernel 與 IUM）。²
邊界的實質是 SLAT 記憶體存取保護，分割區內的軟體──包括核心──無法變更。²
HVCI 在隔離環境跑程式碼完整性驗證，並強制「驗證通過前不可執行」與「可執行分頁不可寫」。⁴ 代價是必須管理驅動程式相容性。⁵
Credential Guard 把網域認證資料的 NTLM 雜湊與 TGT 隔離到 VTL1 的 LSAIso。從 Windows 11 22H2 起，在符合授權需求（Enterprise、Education）與硬體需求的裝置上預設啟用（請和執行狀態檢查一起使用）。⁶⁷
可從 Win32_DeviceGuard 的 SecurityServicesRunning 確認執行狀態（1 = Credential Guard，2 = HVCI）。⁹

續篇見第 3 回，「數秒就能啟動的虛擬機器 ── WSL2、Windows Sandbox 與容器」。

到目前為止，我們從「隔離的強度」這一側看虛擬化。最終回從相反的「輕」這一側看，追那些丟掉完整虛擬機器重量的輕量虛擬機器，到底在哪裡省。

參考連結

Microsoft Learn, Virtualization-based Security (VBS). 關於 VBS 使用硬體虛擬化與 Windows Hypervisor 建立隔離環境，並在假設核心可能被攻陷的前提下把它當成作業系統的信任根；記憶體完整性在該隔離環境裡跑核心模式程式碼完整性驗證；以及 SLAT 是 VBS 的硬性需求。 ↩ ↩² ↩³
Microsoft Learn, Virtual Secure Mode. 關於 VSM 是 Device Guard、Credential Guard、虛擬 TPM 等的基礎；對隔離區域的存取只經由 Hypervisor 控制，即使面對 ring-0 作業系統軟體也受保護；VTL 是階層式的，最多 16 層中實作 2 層；以及每個 VTL 的記憶體存取保護無法由分割區內的系統軟體變更。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Isolated User Mode (IUM) Processes. 關於 VSM 使用 Hyper-V Hypervisor 與 SLAT 建立 VTL；Secure Kernel 與 IUM 跑在 VTL1；trustlet 把系統呼叫編組到 VTL0 核心；以及 LSAIso 跑在 VTL1 並經 RPC 與 lsass 通訊。 ↩ ↩² ↩³
Microsoft Learn, Memory integrity and virtualization-based security. 關於記憶體完整性（HVCI）在隔離環境跑程式碼完整性驗證，以及核心記憶體分頁只有通過驗證後才會變成可執行、可執行分頁不會變成可寫。 ↩ ↩² ↩³
Microsoft Learn, Memory integrity and VBS enablement. 關於在相容硬體上全新安裝 Windows 11 時記憶體完整性預設啟用；在 msinfo32 與 Windows 安全性應用程式確認狀態；以及經 CodeIntegrity Operational 記錄的事件識別碼 3087 確認被擋下的驅動程式。 ↩ ↩² ↩³
Microsoft Learn, How Credential Guard works. 關於啟用 Credential Guard 時 LSA 與 Isolated LSA 處理程序（LSAIso.exe）通訊以儲存秘密；儲存的資料由 VBS 保護，作業系統其餘部分無法存取；以及 Isolated LSA 處理程序不安置裝置驅動程式，只安置最少的已驗證簽章二進位。 ↩ ↩² ↩³
Microsoft Learn, Credential Guard overview. 關於從 Windows 11 版本 22H2 起，在符合授權、硬體與軟體需求且未被明確停用的裝置上 Credential Guard 預設啟用；符合資格的版本／授權為 Enterprise（E3/E5）與 Education（A3/A5），Pro 不在範圍；以及先前在符合資格授權下啟用的 Pro 機器降級後仍是預設啟用對象。 ↩ ↩²
Microsoft Learn, Credential Guard protection limits. 關於服務票證、本機帳號、鍵盤側錄、實體攻擊等不在 Credential Guard 保護範圍；TGT 受保護而服務票證不受保護；以及啟用後 NTLMv1 與未受限委派會不能用。 ↩ ↩² ↩³
Microsoft Learn, Enable virtualization-based protection of code integrity. 關於如何經 Win32_DeviceGuard 類別確認 VBS 與記憶體完整性的狀態，以及 SecurityServicesRunning 值的意義（1 是 Credential Guard，2 是記憶體完整性）。 ↩ ↩²

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

與本主題相關的服務

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

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。

查看服務聯絡我們

常見問題

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

VBS（以虛擬化為基礎的安全性）和核心隔離是同一件事嗎？: 嚴格來說不同。VBS 是用 Hypervisor 建立隔離環境的基礎技術，Windows 安全性應用程式裡的「核心隔離」是把建立在 VBS 上的數項保護歸在一起的畫面名稱。代表性的是「記憶體完整性」，指的是 HVCI（由 Hypervisor 保護的程式碼完整性）。各服務的執行狀態請查詢 Win32_DeviceGuard，不要從畫面顯示判斷。
就算有系統管理員權限，或從核心驅動程式，真的讀不到 VTL1 記憶體嗎？: 讀不到。每個 VTL 的記憶體存取保護由 Hypervisor 對分割區的實體位址空間管理，分割區內執行的軟體無法變更。即使是在核心（ring 0）執行的程式碼，也不被允許從 VTL0 存取 VTL1 記憶體。
為什麼啟用記憶體完整性（HVCI）會讓驅動程式不能用？: 在 HVCI 環境中，核心分頁只有通過完整性驗證後才會變成可執行，而且不允許寫入可執行分頁。未簽署的驅動程式，或會改寫可執行記憶體的舊設計驅動程式，無法滿足這項限制，載入會被擋下。可在 CodeIntegrity Operational 記錄（事件識別碼 3087 等）確認擋下。
Credential Guard 保護什麼，不保護什麼？: 它在隔離環境中保護網域認證資料的 NTLM 密碼雜湊、Kerberos TGT，以及應用程式以網域認證資料儲存的內容。Kerberos 服務票證、本機帳號與 Microsoft 帳號的認證資料、鍵盤側錄對輸入的竊取，以及實體攻擊，都不在範圍內。
要在哪裡確認 VBS 是否在跑？: 看 msinfo32 的「以虛擬化為基礎的安全性」欄位，或從 PowerShell 查詢 root/Microsoft/Windows/DeviceGuard 命名空間的 Win32_DeviceGuard 類別。若 SecurityServicesRunning 含有 1，Credential Guard 在跑；若含有 2，記憶體完整性（HVCI）在跑。

作者檔案

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

Go Komura

小村軟體有限公司代表

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

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽