เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 2) — หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น: กลไกของ VBS, HVCI และ Credential Guard

เคยมีช่วงที่สิทธิ์ผู้ดูแลระบบคือ “เป้าหมาย” ของผู้โจมตีบน Windows โหลดไดรเวอร์เคอร์เนลในฐานะผู้ดูแลระบบ ดัมพ์หน่วยความจำของโปรเซส LSASS แล้วคุณได้แฮชรหัสผ่านและตั๋ว Kerberos จากนั้นเป็นเพียงเรื่องเดินไปอีกเครื่องด้วยแฮชที่ขโมยมา

บน Windows 11 ปัจจุบันที่ Credential Guard กำลังรัน — สถานะเริ่มต้นตั้งแต่ 22H2 เป็นต้นไปบนอุปกรณ์ที่เข้าข้อกำหนดใบอนุญาต เช่น Enterprise และ Education บวกข้อกำหนดฮาร์ดแวร์ — คู่มือเล่นนั้นใช้ไม่ได้ ผู้โจมตีที่ยึดเคอร์เนลได้เต็มที่ค้นหน่วยความจำเท่าไรก็ได้ และแฮชจริงของข้อมูลรับรองโดเมนที่ถูกปกป้องไม่ถูกพบ “ใน OS นั้น” หากมันไม่รัน อันตรายแบบเก่ายังอยู่ จึงอ่านร่วมกับวิธียืนยันในภายหลังของบทความ

แล้วพวกมันอยู่ที่ไหน คำตอบคือ “อีกโลกหนึ่ง ที่สร้างในเครื่องเดียวกัน” ตามที่เราเห็นในตอนที่ 1 Windows ฝั่งโฮสต์รันใน root partition บน hypervisor (“Windows ของคุณรันอยู่ที่ไหนจริง ๆ?”) บทความนี้ต่อจากนั้นและตามเส้นขอบเขตอีกเส้นที่ hypervisor ลากในพาร์ติชันเดียวกัน

คำถามที่ตอนที่ 2 ตอบมีเพียงข้อเดียว

Windows วางความลับที่ทั้งผู้ดูแลระบบและเคอร์เนลอ่านไม่ได้ไว้ที่ไหน?

ผู้อ่านที่ตั้งใจ คือนักพัฒนาและผู้ปฏิบัติการที่เคยเห็นคำอย่าง Core isolation, Memory integrity และ Credential Guard บนหน้าจอตั้งค่าหรือในกรณีแก้ปัญหา และอยากเข้าใจของจริงจากกลไกขึ้นมา ข้อกำหนดเบื้องต้น คือ x64 Windows 10/11 หรือ Windows Server รุ่นปัจจุบัน (เช่นตอนที่ 1 การพูดถึงริงและ SLAT สมมติ x64 ส่วน Arm64 ใช้กลไกอื่น เช่น exception level) พื้นความรู้ที่ต้องมี คือแนวคิดพาร์ติชันและ SLAT ที่ครอบคลุมในตอนที่ 1 ความยากคือระดับกลาง เป้าหมายคือคำอธิบายโครงสร้าง ไม่ใช่วิธีตั้งค่าฟีเจอร์ความปลอดภัย

1. สรุปก่อนเลย

Windows เพิ่มแกนสิทธิ์ชื่อ VTL (Virtual Trust Level) และวางความลับใน VTL1 หน่วยความจำใน VTL1 อ่านจากเคอร์เนลธรรมดาที่รันใน VTL0 ไม่ได้ สิ่งที่เฝ้าขอบเขตไม่ใช่เคอร์เนลเอง แต่เป็น hypervisor ที่ถือตารางแปล SLAT

นั่นคือโครงของความปลอดภัยบนฐานการจำลองเสมือน (VBS) VBS ใช้ hypervisor สร้างสภาพแวดล้อมแยกและบรรจุฟีเจอร์ความปลอดภัยที่นั่น มันถูกออกแบบโดยสมมติว่าสภาพแวดล้อมแยกยังถูกปกป้องแม้เคอร์เนลถูกยึด¹

flowchart TB
    accTitle: สองโลกที่ VBS สร้าง
    accDescr: VTL0 และ VTL1 นั่งในพาร์ติชันเดียวกัน VTL0 ถือเคอร์เนลธรรมดาและแอป VTL1 ถือ Secure Kernel และฟีเจอร์ความปลอดภัยที่แยก และ hypervisor เฝ้าขอบเขต
    subgraph vtl0 ["VTL0 （โลกธรรมดา）"]
        apps["แอป （ริง 3）"]
        ntk["เคอร์เนล NT และไดรเวอร์ （ริง 0）"]
    end
    subgraph vtl1 ["VTL1 （โลกแยก）"]
        ium["ฟีเจอร์ความปลอดภัยที่แยก"]
        sk["Secure Kernel"]
    end
    hv["Hypervisor （บังคับขอบเขตผ่าน SLAT）"] --- vtl0
    hv --- vtl1
    ntk -.->|อ่านไม่ได้| ium

ภาพ 1: มีสองโลกใน Windows หนึ่งตัว และเคอร์เนล VTL0 เข้าถึงหน่วยความจำ VTL1 ไม่ได้

จุดสำคัญคือ นี่ไม่ใช่ “ยืนอีก VM หนึ่ง” VTL0 และ VTL1 อยู่ในพาร์ติชันเดียวกัน ใน Windows เดียวกัน เราจะดูทีละขั้นว่าการแยกนี้ถูกทำให้เป็นจริงอย่างไร

2. ข้อจำกัดของโมเดลริง — ผู้เฝ้าและผู้ถูกเฝ้านั่งที่ความสูงเดียวกัน

ความปลอดภัยแบบดั้งเดิมของ Windows สร้างบนบันไดริง (ระดับสิทธิ์) ยูสเซอร์โหมด (ริง 3) ถูกเฝ้าโดยเคอร์เนลโหมด (ริง 0) แล้วใครเฝ้าริง 0 — ไม่มีใครได้ ริง 0 คือสิทธิ์สูงสุด

โครงสร้างนี้มีจุดอ่อนเชิงโครงสร้างสองข้อ

• เคอร์เนลไม่ใช่แท่งเดียว ที่ริง 0 ไม่เพียง Windows เอง แต่ไดรเวอร์บุคคลที่สามจำนวนมากรัน หากตัวใดตัวหนึ่งมีช่องโหว่ ผู้โจมตีได้การรันโค้ดที่ริง 0
• จากริง 0 ทุกอย่างมองเห็น ไม่ว่าโปรเซสยูสเซอร์โหมดอย่าง LSASS จะป้องกันตัวเท่าไร หน่วยความจำของมันอ่านอิสระสำหรับผู้โจมตีที่ยึดเคอร์เนลได้ ทั้งแอตทริบิวต์การป้องกันและตารางเพจถูกจัดการโดยเคอร์เนลเอง

flowchart TB
    accTitle: เส้นทางขโมยข้อมูลรับรองในโมเดลริงแบบดั้งเดิม
    accDescr: ผู้โจมตีที่ยึดริง 0 ผ่านไดรเวอร์ที่มีช่องโหว่สามารถอ่านหน่วยความจำโปรเซส LSASS ด้วยอำนาจเต็มของเคอร์เนลและได้แฮชรหัสผ่าน
    mal["โค้ดผู้โจมตี"] -->|ใช้ช่องโหว่ไดรเวอร์| r0["ยึดการควบคุมริง 0"]
    r0 --> readall["อ่านหน่วยความจำจริงทั้งหมดได้"]
    readall --> lsass["ได้แฮชจากหน่วยความจำ LSASS"]
    lsass --> lateral["ถูกใช้เคลื่อนด้านข้างไปเครื่องอื่น"]

ภาพ 2: เพราะผู้เฝ้า (เคอร์เนล) และผู้ถูกเฝ้า (ความลับ) นั่งที่ความสูงเดียวกัน จุดอ่อนพื้นฐานคือหากริง 0 ล้ม ทุกอย่างล้ม

สิ่งที่ต้องการจึงคือ “ที่ที่สูงกว่าริง 0” ที่นั้นปรากฏแล้วในตอนที่ 1 hypervisor รันที่สิทธิ์สูงกว่าเคอร์เนลและผูกขาดการควบคุมสิทธิ์เข้าถึงหน่วยความจำของ CPU (SLAT) ตั้งแต่ต้น ภูมิภาคแยกที่ hypervisor เฝ้าถูกปกป้องแม้ต่อการเข้าถึงจากซอฟต์แวร์ OS ริง 0 (supervisor-mode)²

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["สถานะเรจิสเตอร์ของ VP"]
    vtl --> m3["กลไกอินเทอร์รัปต์"]
    m1 -.-> rule["VTL ต่ำกว่าแตะ VTL สูงกว่าไม่ได้"]
    m2 -.-> rule
    m3 -.-> rule

ภาพ 3: การทำให้ไม่เพียงหน่วยความจำ แต่ยังสถานะ CPU และอินเทอร์รัปต์เป็นโลกแยก คือชุดสามชิ้นที่ไม่ทิ้งช่องมอง

หากริง (0 และ 3) คือแกนที่แยก “OS และแอป” VTL คือแกนที่สองที่แยก “โลกธรรมดากับโลกแยก” สองแกนตั้งฉากกัน และใน VTL1 ก็มีเคอร์เนลโหมดกับยูสเซอร์โหมดเช่นกัน

flowchart TB
    accTitle: สี่ภูมิภาคที่สร้างจากสองแกนของริงและ VTL
    accDescr: แกนริงแยกเคอร์เนลโหมดกับยูสเซอร์โหมด แกน VTL แยกโลกธรรมดากับโลกแยก และการรวมให้สี่ภูมิภาค: แอปธรรมดา เคอร์เนล NT IUM trustlet และ Secure Kernel
    subgraph ax0 ["VTL0 （โลกธรรมดา）"]
        a0["ริง 3: แอปธรรมดา"]
        k0["ริง 0: เคอร์เนล NT และไดรเวอร์"]
    end
    subgraph ax1 ["VTL1 （โลกแยก）"]
        a1["ริง 3: IUM （trustlet）"]
        k1["ริง 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 ทำทุกอย่างแบบโปรเซสธรรมดาไม่ได้ การเรียกระบบส่วนใหญ่ถูกมาร์แชลไปยังเคอร์เนล NT ฝั่ง VTL0 และงานถูกขอที่นั่น³ VTL1 ไม่ใช่ “โลกบนที่ทำอะไรก็ได้” มันถูกสร้างให้เล็กโดยตั้งใจ ในฐานะห้องนิรภัยที่ถือความลับ ยิ่งโค้ดที่คุณนำเข้าห้องนิรภัยน้อย พื้นผิวโจมตียิ่งเล็ก

flowchart TB
    accTitle: ลำดับการเรียกระบบของ trustlet
    accDescr: trustlet ใน VTL1 ไม่จัดการการเรียกระบบส่วนใหญ่เอง มันมาร์แชลไปยังเคอร์เนล NT ของ VTL0 และรับเฉพาะผลลัพธ์ ซึ่งทำให้ VTL1 เล็ก
    tl["Trustlet （IUM ใน VTL1）"] --> sc{"ต้องการการเรียกระบบ"}
    sc -->|ในกรณีส่วนใหญ่| mar["คำขอถูกมาร์แชลไปยังเคอร์เนล NT ของ VTL0"]
    mar --> res["เฉพาะผลลัพธ์กลับมา"]
    res -.-> small["VTL1 ยังเล็ก ย่อพื้นผิวโจมตี"]

ภาพ 6: ห้องนิรภัยไม่มีสิ่งอำนวยความสะดวกของตนเอง มันจ้างงานจุกจิกออกไปและเฝ้าเฉพาะความลับ

4. HVCI — ตรวจความสมบูรณ์ของโค้ดเคอร์เนลในห้องนิรภัย

4.1. สิ่งที่กำลังถูกตรวจ

ฟีเจอร์ตัวแทนแรกที่นั่งบน VBS คือ Memory integrity — HVCI (hypervisor-protected code integrity) 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 Operational （event ID 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 ไม่ได้ ข้อเท็จจริงของการบล็อกยืนยันได้ใน Event Viewer ใต้ Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (event ID 3087 เป็นตัวแทน)⁵

“หลังเปิด Memory integrity อุปกรณ์ต่อพ่วงหยุดทำงาน” — ในหลายกรณี นั่นคือตัวตนจริงของปัญหา การตอบที่ถูกต้องคืออัปเดตเป็นไดรเวอร์ที่เข้ากันกับ HVCI การปิด Memory integrity ควรถือเป็นทางสุดท้ายที่ยกเลิกการป้องกันทั้งก้อน หากคุณเกี่ยวข้องกับการตรวจนี้จากมุมพัฒนาไดรเวอร์ ดูบทความไดรเวอร์ตัวกรองด้วย (“Windows Minifilter Drivers”)

flowchart TB
    accTitle: การแยกกรณีที่อุปกรณ์ต่อพ่วงหยุดทำงานภายใต้ Memory integrity
    accDescr: ระบุไดรเวอร์ที่ถูกบล็อกในล็อก CodeIntegrity Operational การตอบที่ถูกต้องคืออัปเดตเป็นรุ่นที่เข้ากันกับ HVCI ถามผู้ขายหากไม่มี และถือการปิดเป็นทางสุดท้ายที่ไม่ทำให้ถาวร
    sym["อุปกรณ์หยุดทำงานหลังเปิด Memory integrity"] --> log2["ระบุไดรเวอร์ที่ถูกบล็อกในล็อก CodeIntegrity"]
    log2 --> upd{"มีไดรเวอร์ที่เข้ากันกับ HVCI หรือไม่?"}
    upd -->|มี| fix2["อัปเดตและแก้ขณะเปิด HVCI ไว้"]
    upd -->|ไม่มี| ask2["ขอรุ่นที่เข้ากันจากผู้ขาย"]
    ask2 -.-> temp["การปิดเป็นทางสุดท้าย ไม่ใช่การตั้งค่าถาวร"]

ภาพ 10: สิ่งแรกที่ต้องดูไม่ใช่หน้าจอตั้งค่า แต่เป็นล็อก และ event ID 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 trustlet ที่รันใน IUM ใน VTL1⁶

• lsass.exe (VTL0) ยังรันเป็นเคาน์เตอร์หน้าสำหรับการประมวลผลการรับรองตามเดิม
• ความลับจริงถูกถือโดย LSAIso.exe (VTL1) และเข้าถึงจาก VTL0 ไม่ได้
• ทั้งสองสื่อสารผ่าน RPC (Remote Procedure Call)
• LSAIso ไม่โฮสต์ไดรเวอร์อุปกรณ์เลย และบรรจุเฉพาะไบนารีที่มีลายเซ็นขั้นต่ำ ลายเซ็นถูกตรวจด้วยใบรับรองที่ VBS เชื่อถือ⁶

flowchart TB
    accTitle: ตำแหน่งของข้อมูลรับรองเมื่อเปิด Credential Guard
    accDescr: lsass ใน VTL0 สื่อสารกับ LSAIso ใน VTL1 ผ่าน RPC ในฐานะเคาน์เตอร์หน้ารับรอง แฮชจริงและ 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: หลังลงชื่อเข้าใช้ ความลับจริงถูกเก็บใน LSAIso ใน VTL1 ทุกครั้งที่ต้องการการรับรอง lsass ใน VTL0 ขอการคำนวณผ่าน 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 service ticket (TGT ถูกปกป้อง)
• ข้อมูลรับรองของบัญชีท้องถิ่นและบัญชี Microsoft
• การขโมยอินพุตด้วยคีย์ล็อกเกอร์ และการโจมตีทางกายภาพ
• ข้อมูลรับรองบนเส้นทางที่ใช้ NTLMv1, MS-CHAPv2, Digest หรือ CredSSP
• ส่วนภายในของซอฟต์แวร์บุคคลที่สามที่จัดการข้อมูลรับรองเอง

นอกจากนี้ เมื่อเปิด Credential Guard แล้ว NTLMv1 การมอบหมาย Kerberos แบบไม่จำกัด เป็นต้น ใช้ไม่ได้ ดังนั้นระบบธุรกิจที่พึ่งพาการรับรองแบบเก่าต้องการการตรวจความเข้ากันได้⁸ ไม่ใช่ “เปิดแล้วจบ” แต่จับว่าอะไรอยู่ในและนอกขอบเขตการป้องกัน แล้วเติมส่วนที่เหลือด้วยการควบคุมอื่น — นั่นคือวิธีใช้ที่ถูกต้องในทางปฏิบัติ

flowchart TB
    accTitle: ขอบเขตการป้องกันของ Credential Guard
    accDescr: แฮช NTLM ของโดเมนและ TGT รวมถึงข้อมูลรับรองโดเมนที่เก็บไว้ ถูกปกป้อง ส่วน service ticket บัญชีท้องถิ่น คีย์ล็อกเกอร์ การโจมตีทางกายภาพ และข้อมูลรับรองที่แอปเก็บเองอยู่นอกขอบเขต
    scope{"ความลับนี้อยู่ฝั่งใดของขอบเขตการป้องกัน?"} --> inA["แฮช NTLM ของโดเมนและ TGT"]
    scope --> outA["Service ticket และบัญชีท้องถิ่น"]
    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 Memory integrity (HVCI) กำลังรัน

หากจะยืนยันสถานะการรันใน GUI ให้ดูช่อง “Virtualization-based security” ใน msinfo32 (บริการที่กำลังรันถูกแสดงรายการ เช่น “Hypervisor enforced Code Integrity”) สวิตช์ “Memory integrity” ใต้ “Device security > Core isolation” ในแอป Windows Security คือหน้าจอที่สะท้อนการตั้งค่า มันดูเปิดได้แม้ขณะที่ HVCI ไม่ได้รันจริง — รอรีบูตทันทีหลังเปิด หรือปัญหาความเข้ากันได้ตอนเริ่มต้น — จึงตัดสินว่ากำลังรันจาก msinfo32 หรือจาก SecurityServicesRunning ของ Win32_DeviceGuard⁵

ยังมีร่องรอยบนแท็บ Details ของ Task Manager บนเครื่องที่ VBS กำลังรัน คุณจะเห็นโปรเซสชื่อ “Secure System” LsaIso.exe คือโปรเซสที่ปรากฏเมื่อบริการ Isolated LSA ถูกโฮสต์ใน VTL1 และโดยปกติไม่ปรากฏในการตั้งค่าที่เปิดเฉพาะ HVCI อย่างไรก็ตาม การมีหรือไม่มีโปรเซสเป็นเพียงร่องรอย จึงตัดสินว่า Credential Guard กำลังรันจาก SecurityServicesRunning (ว่ามี 1 หรือไม่) ตามด้านบน ทั้งคู่เป็นหน้าต่างที่มองเห็นจาก VTL0 ซึ่งสอดคล้องกับโลกฝั่ง VTL1

flowchart TB
    accTitle: วิธีตรวจว่าฟีเจอร์ที่เกี่ยวข้องกับ VBS กำลังรัน
    accDescr: ยืนยันว่า VBS กำลังรันด้วยการสอบถาม Win32_DeviceGuard ตัดสิน Credential Guard และ HVCI จากค่า SecurityServicesRunning และดูล็อก 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 คือชั้นหนึ่งของการป้องกันเชิงลึกที่สมมติการถูกยึด และมีผลบนเครื่องไคลเอนต์ บน 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. “หาก Memory integrity ก่อปัญหา ก็แค่ปิด”

การปิดจะทำให้สิ่งต่าง ๆ ทำงานชั่วคราว แต่ถอดกำแพงต่อการฉีดโค้ดเข้าเคอร์เนลทั้งก้อน การตอบที่ถูกต้องคือระบุไดรเวอร์ที่ถูกบล็อกในล็อก CodeIntegrity ก่อน แล้วใช้รุ่นอัปเดตของผู้ขาย แม้คุณปิดชั่วคราวเพื่อการตรวจ เราแนะนำการปฏิบัติการที่ไม่ทำให้สิ่งนั้นเป็นการตั้งค่าถาวร

7.3. “ด้วย Credential Guard รหัสผ่านขโมยไม่ได้”

นั่นคือความมั่นใจเกินจากการปะปนขอบเขตการป้องกัน Service ticket บัญชีท้องถิ่น การกดแป้นเอง และข้อมูลรับรองที่แอปเก็บเองอยู่นอกขอบเขต⁸ ฟิชชิงและคีย์ล็อกเกอร์ต้องการการควบคุมอื่น (การรับรองหลายปัจจัย Windows Hello และการทบทวนการจัดการข้อมูลรับรองฝั่งแอป)

8. สรุป

• VBS ใช้ hypervisor สร้างสภาพแวดล้อมแยกและปกป้องฟีเจอร์ความปลอดภัยโดยสมมติว่าเคอร์เนลถูกยึดได้¹
• หน่วยของการแยกคือ VTL ปัจจุบันอิมพลีเมนต์สองระดับ คือ VTL0 (โลกธรรมดา) และ VTL1 (Secure Kernel และ IUM)²
• สาระของขอบเขตคือการป้องกันการเข้าถึงหน่วยความจำของ SLAT ซึ่งซอฟต์แวร์ในพาร์ติชัน — รวมเคอร์เนล — เปลี่ยนไม่ได้²
• HVCI รันการตรวจความสมบูรณ์ของโค้ดในสภาพแวดล้อมแยกและบังคับ “ไม่ปฏิบัติการได้จนกว่าการตรวจจะผ่าน” และ “เพจที่ปฏิบัติการได้เขียนไม่ได้”⁴ ราคาคือคุณต้องจัดการความเข้ากันได้ของไดรเวอร์⁵
• Credential Guard แยกแฮช NTLM ของข้อมูลรับรองโดเมนและ TGT เข้า LSAIso ใน VTL1 ตั้งแต่ Windows 11 22H2 เป็นต้นไป เปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าข้อกำหนดใบอนุญาต (Enterprise, Education) และข้อกำหนดฮาร์ดแวร์ (ใช้ร่วมกับการตรวจสถานะการรัน)⁶⁷
• คุณยืนยันสถานะการรันจาก SecurityServicesRunning ของ Win32_DeviceGuard ได้ (1 = Credential Guard, 2 = HVCI)⁹

ต่อในตอนที่ 3 “เครื่องเสมือนที่บูตในไม่กี่วินาที — WSL2, Windows Sandbox และคอนเทนเนอร์“

จนถึงตอนนี้เราดูการจำลองเสมือนจากฝั่ง “ความแข็งของการแยก” ตอนสุดท้ายดูจากฝั่งตรงข้ามคือ “ความเบา” และตามว่า VM น้ำหนักเบาที่ทิ้งน้ำหนักของ VM เต็มตัวกำลังตัดมุมที่ไหน

บทความที่เกี่ยวข้อง

• เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 1) — Windows ของคุณรันอยู่ที่ไหนจริง ๆ? Hypervisor และพาร์ติชัน
• เชิงลึกของหน่วยความจำ Windows (ตอนที่ 1) — วินาทีที่ที่อยู่เสมือนกลายเป็น RAM จริง: Page Fault จากต้นจนจบ
• เชิงลึกของ Windows I/O (ตอนที่ 6 ตอนจบ) — Filter Driver และ Minifilter: ทำไม Procmon และสแกนเนอร์แอนตี้ไวรัสจึงสกัด I/O ได้
• ถอดรหัสรหัสข้อผิดพลาดของ Windows — โครงสร้างสามชั้นของ Win32 Error, HRESULT และ NTSTATUS

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับสอบสวนความเข้ากันได้ระหว่างแอปพลิเคชัน Windows กับฟีเจอร์ความปลอดภัย วิเคราะห์ความล้มเหลวที่เกิดจากไดรเวอร์ และการตรวจทางเทคนิคของสภาพแวดล้อมเครื่องในองค์กร

• การพัฒนาแอปพลิเคชัน Windows
• การตรวจสอบบั๊กและวิเคราะห์หาสาเหตุที่แท้จริง
• การใช้ประโยชน์และโยกย้ายสินทรัพย์ซอฟต์แวร์เดิม
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

VBS (ความปลอดภัยบนฐานการจำลองเสมือน) กับ Core isolation เป็นสิ่งเดียวกันหรือไม่

พูดอย่างเคร่งครัด ต่างกัน VBS คือเทคโนโลยีรากฐานที่สร้างสภาพแวดล้อมแยกด้วย hypervisor และ "Core isolation" ในแอป Windows Security คือชื่อหน้าจอที่จัดกลุ่มการป้องกันหลายอย่างที่สร้างบน VBS ตัวแทนคือ "Memory integrity" ซึ่งหมายถึง HVCI (hypervisor-protected code integrity) ยืนยันสถานะการรันของแต่ละบริการด้วยการสอบถาม Win32_DeviceGuard ไม่ใช่จากการแสดงบนหน้าจอ

หน่วยความจำ VTL1 อ่านจริง ๆ ไม่ได้ แม้ด้วยสิทธิ์ผู้ดูแลระบบหรือจากไดรเวอร์เคอร์เนลหรือไม่

อ่านไม่ได้ การป้องกันการเข้าถึงหน่วยความจำราย VTL ถูกจัดการโดย hypervisor กับพื้นที่ที่อยู่จริงของพาร์ติชัน และซอฟต์แวร์ที่รันในพาร์ติชันเปลี่ยนไม่ได้ แม้โค้ดที่รันในเคอร์เนล (ริง 0) ก็ไม่ได้รับอนุญาตให้เข้าถึงหน่วยความจำ VTL1 จาก VTL0

ทำไมการเปิด Memory integrity (HVCI) จึงทำให้ไดรเวอร์หยุดทำงานได้

ในสภาพแวดล้อม HVCI เพจเคอร์เนลกลายเป็นปฏิบัติการได้ก็ต่อเมื่อผ่านการตรวจความสมบูรณ์แล้ว และการเขียนไปยังเพจที่ปฏิบัติการได้ไม่ได้รับอนุญาต ไดรเวอร์ที่ไม่มีลายเซ็น หรือไดรเวอร์ออกแบบเก่าที่เขียนทับหน่วยความจำที่ปฏิบัติการได้ เข้าเงื่อนไขนี้ไม่ได้และการโหลดถูกบล็อก คุณยืนยันการบล็อกในล็อก CodeIntegrity Operational (event ID 3087 เป็นต้น) ได้

Credential Guard ปกป้องอะไร และไม่ปกป้องอะไร

มันปกป้องแฮชรหัสผ่าน NTLM ของข้อมูลรับรองโดเมน Kerberos TGT และสิ่งที่แอปเก็บเป็นข้อมูลรับรองโดเมน ในสภาพแวดล้อมแยก Kerberos service ticket ข้อมูลรับรองของบัญชีท้องถิ่นและบัญชี Microsoft การขโมยอินพุตด้วยคีย์ล็อกเกอร์ และการโจมตีทางกายภาพอยู่นอกขอบเขต

ตรวจได้ที่ไหนว่า VBS กำลังรัน

ดูช่อง "Virtualization-based security" ใน msinfo32 หรือสอบถามคลาส Win32_DeviceGuard ในเนมสเปซ root/Microsoft/Windows/DeviceGuard จาก PowerShell หาก SecurityServicesRunning มี 1 Credential Guard กำลังรัน หากมี 2 Memory integrity (HVCI) กำลังรัน

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก