Kedalaman virtualisasi Windows (Bagian 2) — Memori yang bahkan kernel pun tidak bisa lihat: cara kerja VBS, HVCI, dan Credential Guard

Ada masa ketika hak administrator adalah “tujuan” bagi penyerang di Windows. Muat driver kernel sebagai administrator, dump memori proses LSASS, dan Anda punya hash kata sandi serta tiket Kerberos. Dari situ tinggal berjalan ke mesin lain dengan hash yang dicuri.

Di Windows 11 terkini dengan Credential Guard berjalan — keadaan bawaan dari 22H2 ke atas pada perangkat yang memenuhi syarat lisensi seperti Enterprise dan Education, plus syarat perangkat keras — playbook itu tidak bekerja. Penyerang yang telah sepenuhnya mengambil kernel dapat mencari memori sesuka hati, dan hash sungguhan kredensial domain yang dilindungi tidak ditemukan “di dalam OS itu”. Jika ia tidak berjalan, bahaya lama tetap ada, jadi baca ini bersama metode konfirmasi di kemudian hari di artikel.

Jadi di mana mereka? Jawabannya adalah “dunia lain, yang dibuat di dalam PC yang sama”. Seperti kita lihat di Bagian 1, Windows host berjalan di root partition di atas hypervisor (“Di mana Windows Anda sebenarnya berjalan?”). Artikel ini berlanjut dari situ dan mengikuti satu garis batas lagi yang digambar hypervisor di dalam partisi yang sama.

Pertanyaan yang dijawab Bagian 2 hanya satu.

Di mana Windows menaruh rahasia yang tidak dapat dibaca administrator maupun kernel?

Pembaca sasaran adalah pengembang dan operator yang telah melihat kata-kata seperti Core isolation, Memory integrity, dan Credential Guard di layar pengaturan atau dalam kasus pemecahan masalah, dan ingin memahami hal yang sesungguhnya dari mekanismenya. Prasyarat adalah Windows 10/11 x64 atau Windows Server terkini (seperti di Bagian 1, pembahasan ring dan SLAT mengasumsikan x64; Arm64 memakai mekanisme berbeda seperti exception level). Latar belakang yang dibutuhkan adalah konsep partisi dan SLAT yang dibahas di Bagian 1. Tingkat kesulitannya menengah. Tujuannya adalah penjelasan struktur, bukan how-to mengonfigurasi fitur keamanan.

1. Kesimpulan lebih dulu

Windows menambahkan sumbu hak yang disebut VTL (Virtual Trust Level) dan menaruh rahasia di VTL1. Memori di VTL1 tidak dapat dibaca dari kernel biasa yang berjalan di VTL0. Yang menjaga batasnya bukan kernel sendiri, melainkan hypervisor yang menahan tabel terjemahan SLAT.

Itu kerangka virtualization-based security (VBS). VBS memakai hypervisor untuk membuat lingkungan terisolasi dan menampung fitur keamanan di sana. Ia dirancang dengan asumsi bahwa lingkungan terisolasi tetap terlindungi bahkan jika kernel dikompromikan.¹

flowchart TB
    accTitle: Dua dunia yang dibuat VBS
    accDescr: VTL0 dan VTL1 duduk di dalam partisi yang sama; VTL0 menahan kernel biasa dan aplikasi, VTL1 menahan Secure Kernel dan fitur keamanan terisolasi, dan hypervisor menjaga batasnya
    subgraph vtl0 ["VTL0 (dunia biasa)"]
        apps["Aplikasi (ring 3)"]
        ntk["Kernel NT dan driver (ring 0)"]
    end
    subgraph vtl1 ["VTL1 (dunia terisolasi)"]
        ium["Fitur keamanan terisolasi"]
        sk["Secure Kernel"]
    end
    hv["Hypervisor (menegakkan batas lewat SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|Tidak bisa baca| ium

Gambar 1: Ada dua dunia di dalam satu Windows, dan kernel VTL0 tidak dapat mengakses memori VTL1.

Poin pentingnya adalah bahwa ini bukan “mendirikan VM lain”. VTL0 dan VTL1 berada di dalam partisi yang sama, di dalam Windows yang sama. Kita akan melihat bergiliran bagaimana pemisahan ini diwujudkan.

2. Batas model ring — penjaga dan yang dijaga duduk di ketinggian yang sama

Keamanan Windows tradisional dibangun di atas tangga ring (tingkat hak). Mode pengguna (ring 3) dijaga oleh mode kernel (ring 0). Jadi siapa yang menjaga ring 0 — tidak ada yang bisa. Ring 0 adalah hak tertinggi.

Struktur ini punya dua kelemahan struktural.

• Kernel bukan monolit. Di ring 0, bukan hanya Windows sendiri tetapi sejumlah besar driver pihak ketiga berjalan. Jika salah satu punya kerentanan, penyerang memperoleh eksekusi kode di ring 0.
• Dari ring 0, semuanya terlihat. Sebanyak apa pun proses mode pengguna seperti LSASS membela diri, memorinya bebas dibaca bagi penyerang yang telah mengambil kernel. Atribut perlindungan dan page table sama-sama dikelola oleh kernel sendiri.

flowchart TB
    accTitle: Jalur pencurian kredensial di model ring tradisional
    accDescr: Penyerang yang mengambil ring 0 lewat driver yang rentan dapat membaca memori proses LSASS dengan wewenang penuh kernel dan memperoleh hash kata sandi
    mal["Kode penyerang"] -->|Mengeksploitasi driver yang rentan| r0["Mengambil kendali ring 0"]
    r0 --> readall["Dapat membaca semua memori fisik"]
    readall --> lsass["Memperoleh hash dari memori LSASS"]
    lsass --> lateral["Disalahgunakan untuk gerakan lateral ke mesin lain"]

Gambar 2: Karena penjaga (kernel) dan yang dijaga (rahasia) duduk di ketinggian yang sama, kelemahan mendasarnya adalah jika ring 0 jatuh, semuanya jatuh.

Yang dibutuhkan, maka, adalah “tempat yang lebih tinggi dari ring 0”. Tempat itu sudah muncul di Bagian 1. Hypervisor berjalan pada hak yang lebih tinggi dari kernel dan memonopoli kendali izin akses memori CPU (SLAT) sejak awal. Wilayah terisolasi yang dijaga hypervisor dilindungi bahkan terhadap akses dari perangkat lunak OS ring-0 (mode supervisor).²

3. VSM dan VTL — menambahkan satu sumbu hak lagi

3.1. Virtual Trust Levels (VTL)

Keluarga fitur hypervisor yang menyediakan isolasi ini disebut VSM (Virtual Secure Mode). VSM adalah fondasi untuk Device Guard, Credential Guard, TPM virtual, dan sejenisnya.²

Konsep pusat VSM adalah VTL (Virtual Trust Level). Poin kuncinya sebagai berikut.²

• VTL bersifat hierarkis, dan semakin tinggi angkanya, semakin tinggi haknya. VTL0 adalah yang terendah; VTL1 lebih berhak daripada VTL0.
• Secara arsitektur hingga 16 tingkat didefinisikan, tetapi yang saat ini diimplementasikan adalah dua: VTL0 dan VTL1.
• Setiap VTL punya perlindungan akses memori independen. Perlindungan ini dikelola oleh hypervisor terhadap ruang alamat fisik partisi, jadi perangkat lunak sistem di dalam partisi tidak dapat mengubahnya.
• Prosesor virtual punya keadaan register dan mesin interrupt terpisah per VTL, dan VTL yang lebih rendah tidak dapat mengintip keadaan VTL yang lebih tinggi.

flowchart TB
    accTitle: Tiga independensi yang menyusun isolasi VTL
    accDescr: Perlindungan akses memori, keadaan register prosesor virtual, dan mesin interrupt independen per VTL, dan VTL yang lebih rendah tidak dapat menyentuh salah satunya di VTL yang lebih tinggi
    vtl["Yang independen per VTL"] --> m1["Perlindungan akses memori"]
    vtl --> m2["Keadaan register prosesor virtual"]
    vtl --> m3["Mesin interrupt"]
    m1 -.-> rule["VTL lebih rendah tidak bisa sentuh VTL lebih tinggi"]
    m2 -.-> rule
    m3 -.-> rule

Gambar 3: Membuat bukan hanya memori tetapi juga keadaan CPU dan interrupt menjadi dunia terpisah adalah set tiga bagian yang tidak meninggalkan lubang intip.

Jika ring (0 dan 3) adalah sumbu yang memisahkan “OS dan aplikasi”, VTL adalah sumbu kedua yang memisahkan “dunia biasa dan dunia terisolasi”. Kedua sumbu ortogonal, dan di dalam VTL1 ada mode kernel dan mode pengguna juga.

flowchart TB
    accTitle: Empat wilayah yang dibuat dua sumbu ring dan VTL
    accDescr: Sumbu ring memisahkan mode kernel dan mode pengguna, sumbu VTL memisahkan dunia biasa dan dunia terisolasi, dan kombinasinya menghasilkan empat wilayah: aplikasi biasa, kernel NT, trustlet IUM, dan Secure Kernel
    subgraph ax0 ["VTL0 (dunia biasa)"]
        a0["Ring 3: aplikasi biasa"]
        k0["Ring 0: kernel NT dan driver"]
    end
    subgraph ax1 ["VTL1 (dunia terisolasi)"]
        a1["Ring 3: IUM (trustlet)"]
        k1["Ring 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

Gambar 4: Kini ada dua sumbu hak, dan “apakah ini kernel?” serta “apakah ini dunia terisolasi?” menjadi pertanyaan terpisah.

3.2. Substansi batasnya adalah SLAT

Di Bagian 1 kita katakan bahwa tabel terjemahan tingkat kedua yang memetakan alamat fisik tamu (GPA) ke RAM sungguhan (SPA) — SLAT — dipegang oleh hypervisor. VSM memakai tepat sifat ini. Isolasi VTL dibuat memakai Hyper-V hypervisor dan SLAT.³

Ketika VTL1 menyatakan “memori ini tidak boleh ditunjukkan ke VTL0”, hypervisor menjatuhkan izin akses ke halaman itu dari tabel terjemahan VTL0. Sejak itu, bahkan jika kernel VTL0 mencoba menyentuh alamat itu, ia ditolak pada tahap terjemahan alamat CPU. Tidak berguna bagi kernel untuk menulis ulang page table sendiri sesuka hati. Page table (GVA→GPA) mungkin milik kernel, tetapi terjemahan di luar itu (GPA→SPA) dan izin akses akhir milik hypervisor.

flowchart TB
    accTitle: Alur di mana akses dari VTL0 ke memori VTL1 ditolak
    accDescr: Ketika kernel VTL0 mencoba membaca memori VTL1, ia dapat lolos page table sendiri tetapi ditolak oleh perlindungan akses SLAT, dan kendali pindah ke hypervisor
    try["Kernel VTL0 coba baca halaman VTL1"] --> pt["Lolos page table kernel sendiri"]
    pt --> slat{"Perlindungan akses SLAT mengizinkan?"}
    slat -->|Tidak diizinkan| deny["Hypervisor campur tangan dan menolak akses"]
    slat -->|Diizinkan| ok["Akses memori biasa"]
    deny -.-> point["Dilindungi di lapisan yang kernel tidak bisa ubah"]

Gambar 5: Penghalang duduk di luar kernel, dan perlindungan SLAT tidak dapat diubah oleh perangkat lunak di dalam partisi.

Di Bagian 1 seri memori kita menulis bahwa “VAD, PTE, dan atribut perlindungan memutuskan apakah akses diizinkan”. Di lingkungan VBS Anda dapat menatanya sebagai: setelah semuanya dilalui, pos pemeriksaan SLAT masih menunggu.

3.3. Secure Kernel dan IUM

Yang berjalan di dalam VTL1 bukan kernel NT biasa melainkan kernel kecil yang disebut Secure Kernel. Mode pengguna di VTL1 disebut IUM (Isolated User Mode), dan program yang berjalan di sana disebut trustlet (proses tepercaya).³

Trustlet tidak dapat melakukan segala yang dapat dilakukan proses biasa. Sebagian besar system call di-marshal ke kernel NT di sisi VTL0 dan pekerjaan diminta di sana.³ VTL1 bukan “dunia atas yang dapat melakukan apa pun”; ia dibangun kecil dengan sengaja, sebagai brankas yang menahan rahasia. Semakin sedikit kode yang dapat Anda bawa ke brankas, semakin kecil permukaan serangan.

flowchart TB
    accTitle: Alur system call trustlet
    accDescr: Trustlet di VTL1 tidak menangani sebagian besar system call sendiri; ia me-marshal mereka ke kernel NT VTL0 dan menerima hanya hasilnya, yang menjaga VTL1 tetap kecil
    tl["Trustlet (IUM di VTL1)"] --> sc{"System call dibutuhkan"}
    sc -->|Dalam sebagian besar kasus| mar["Permintaan di-marshal ke kernel NT VTL0"]
    mar --> res["Hanya hasil yang kembali"]
    res -.-> small["VTL1 tetap kecil, mengecilkan permukaan serangan"]

Gambar 6: Brankas tidak punya fasilitas sendiri; ia menyerahkan pekerjaan rutin dan terus menjaga hanya rahasia.

4. HVCI — memverifikasi integritas kode kernel di brankas

4.1. Apa yang diverifikasi

Fitur representatif pertama yang duduk di VBS adalah Memory integrity — HVCI (hypervisor-protected code integrity). Windows punya mekanisme integritas kode yang memeriksa driver dan biner mode kernel sebelum mereka start dan tidak memuat yang tanpa tanda tangan atau tidak tepercaya. HVCI menjalankan verifikasi ini di dalam lingkungan terisolasi VBS.¹

Alasan memindahkan logika verifikasi sendiri ke VTL1 justru kelemahan di Bagian 2. Jika kode verifikasi duduk di dalam kernel VTL0, penyerang yang telah mengambil kernel dapat menukar verifikasi itu. Jika ia di VTL1, tangan yang menukar tidak dapat menjangkaunya.

flowchart TB
    accTitle: Perbedaan yang dibuat oleh di mana kode verifikasi tinggal
    accDescr: Jika kode verifikasi duduk di dalam kernel VTL0 ia dapat dinonaktifkan dengan mengambil kernel, tetapi jika di VTL1 bahkan penyerang yang telah mengambil kernel tidak dapat menjangkaunya dan verifikasi terlindungi
    atk["Penyerang yang telah mengambil kernel"] --> q{"Di mana verifikasi integritas kode tinggal?"}
    q -->|"Di dalam kernel VTL0 (klasik)"| bad["Logika verifikasi dapat ditukar"]
    q -->|"Lingkungan terisolasi di VTL1 (HVCI)"| good["Penukaran di luar jangkauan"]
    bad --> res1["Kode tanpa tanda tangan dapat berjalan di kernel"]
    good --> res2["Verifikasi terus bekerja setelah kernel dikompromikan"]

Gambar 7: Jangan taruh pos pemeriksaan di dalam sisi yang mungkin ditembus — relokasi logika verifikasi itulah esensi HVCI.

4.2. Aturan untuk halaman yang dapat dieksekusi

Efek HVCI tidak terbatas pada “pemeriksaan saat start”. Ia juga membatasi alokasi memori kernel.⁴

• Halaman kernel menjadi dapat dieksekusi hanya setelah lulus verifikasi integritas kode.
• Halaman yang dapat dieksekusi tidak menjadi dapat ditulis (yang disebut W^X).

Ketika keduanya ada, bahkan jika kerentanan seperti buffer overflow membiarkan Anda menulis ulang memori kernel, Anda tidak dapat menaruh isi yang ditulis ulang itu ke eksekusi. Halaman yang dapat dieksekusi tidak dapat ditulis ulang, dan halaman yang dapat ditulis ulang tidak dapat dieksekusi.⁴ Landasan akhir izin eksekusi adalah hak eksekusi di sisi SLAT, yang tidak dapat dimanipulasi kernel VTL0.

flowchart TB
    accTitle: Sampai halaman kernel menjadi dapat dieksekusi di lingkungan HVCI
    accDescr: Permintaan memuat driver menerima verifikasi integritas kode di lingkungan terisolasi VBS; jika lulus ia diizinkan sebagai halaman yang dapat dieksekusi, tidak dapat ditulis, dan jika gagal ia diblokir dan dicatat di log CodeIntegrity
    load["Permintaan memuat dan mengeksekusi kode kernel"] --> verify{"Verifikasi integritas kode di lingkungan terisolasi"}
    verify -->|Lulus| exec["Diizinkan sebagai halaman dapat dieksekusi (tulis dilarang)"]
    verify -->|Gagal| block["Pemuatan diblokir"]
    block --> log["Dicatat di log CodeIntegrity Operational (event ID 3087)"]
    exec -.-> wx["Halaman yang dapat ditulis tetap tidak dapat dieksekusi"]

Gambar 8: Verifikasi aturan yang tidak membiarkan eksekusi dan penulisan hidup berdampingan dilakukan di sisi VTL1, dan kernel VTL0 tidak dapat membalikkannya.

Menelusuri ini dari sudut pandang penyerang membuat jelas bagaimana aturan itu berlaku.

flowchart TB
    accTitle: Alur di mana injeksi kode gagal di lingkungan HVCI
    accDescr: Bahkan jika kerentanan membiarkan Anda menulis ulang memori kernel, halaman yang dapat Anda tulis tidak dapat dieksekusi, dan halaman yang dapat dieksekusi tidak dapat ditulis ulang sejak awal, jadi kode yang diinjeksikan tidak dapat dimasukkan ke eksekusi
    inj["Coba rusak memori kernel lewat kerentanan"] --> which{"Halaman mana sasarannya?"}
    which -->|Halaman yang dapat ditulis| wok["Penulisan berhasil"]
    which -->|Halaman yang dapat dieksekusi| xfail["Penulisan sendiri mustahil"]
    wok --> nx["Tetapi halaman itu tidak dapat dieksekusi"]
    nx --> dead["Kode yang diinjeksikan tidak dapat dieksekusi"]
    xfail --> dead

Gambar 9: Makna tidak menyilangkan halaman yang dapat ditulis dengan halaman yang dapat dijalankan adalah bahwa pintu masuk mana pun yang Anda ambil, Anda menabrak jalan buntu.

4.3. Harga dalam kompatibilitas driver

Aturan ini bertabrakan dengan driver desain lama. Yang menulis ulang kodenya sendiri saat berjalan, tidak punya tanda tangan, atau menuntut memori yang sekaligus dapat dieksekusi dan dapat ditulis — driver semacam itu tidak dapat dimuat di lingkungan HVCI. Fakta pemblokiran dapat dikonfirmasi di Event Viewer di bawah Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (event ID 3087 representatif).⁵

“Setelah saya mengaktifkan Memory integrity, periferal berhenti bekerja” — dalam banyak kasus, itu identitas sungguhan gangguan. Respons yang tepat adalah memperbarui ke driver yang kompatibel HVCI; menonaktifkan Memory integrity harus dipikirkan sebagai pilihan terakhir yang menyerahkan perlindungan secara keseluruhan. Jika Anda terlibat dalam verifikasi ini dari sudut pengembangan driver, lihat juga artikel filter driver (“Driver minifilter Windows”).

flowchart TB
    accTitle: Mengisolasi kasus periferal berhenti bekerja di bawah Memory integrity
    accDescr: Identifikasi driver yang diblokir di log CodeIntegrity Operational; respons yang tepat adalah memperbarui ke versi yang kompatibel HVCI, meminta vendor jika tidak ada, dan memperlakukan penonaktifan sebagai pilihan terakhir yang tidak Anda buat permanen
    sym["Perangkat berhenti bekerja setelah Memory integrity diaktifkan"] --> log2["Identifikasi driver yang diblokir di log CodeIntegrity"]
    log2 --> upd{"Ada driver yang kompatibel HVCI?"}
    upd -->|Ya| fix2["Perbarui dan selesaikan sambil membiarkan HVCI nyala"]
    upd -->|Tidak| ask2["Minta vendor versi yang kompatibel"]
    ask2 -.-> temp["Menonaktifkan adalah pilihan terakhir, bukan pengaturan permanen"]

Gambar 10: Hal pertama yang harus dilihat bukan layar pengaturan melainkan log, dan event ID 3087 tahu siapa yang memblokir pemuatan.

5. Credential Guard — hash-nya ada di dalam LSAIso

5.1. LSASS dan LSAIso

Fitur representatif kedua yang duduk di VBS adalah jawaban atas misteri pembukaan: Credential Guard.

Windows tradisional menyimpan hash NTLM dan tiket Kerberos di memori proses LSA (lsass.exe). Ketika Credential Guard diaktifkan, penyimpanan rahasia yang dilindungi di antara ini — hash NTLM kredensial domain dan TGT Kerberos (Ticket Granting Ticket) — pindah ke LSAIso.exe, trustlet yang berjalan di IUM di VTL1.⁶

• lsass.exe (VTL0) terus berjalan sebagai meja depan pemrosesan autentikasi, seperti semula.
• Rahasia sungguhan dipegang oleh LSAIso.exe (VTL1) dan tidak dapat diakses dari VTL0.
• Keduanya berkomunikasi lewat RPC (Remote Procedure Call).
• LSAIso tidak menampung driver perangkat sama sekali, dan hanya menampung minimum biner bertanda tangan. Tanda tangan diverifikasi dengan sertifikat yang dipercaya VBS.⁶

flowchart TB
    accTitle: Di mana kredensial duduk ketika Credential Guard diaktifkan
    accDescr: lsass di VTL0 berkomunikasi dengan LSAIso di VTL1 lewat RPC sebagai meja depan autentikasi; hash dan TGT sungguhan kredensial domain yang dilindungi dipegang LSAIso, jadi penyerang yang memperoleh hak administrator di VTL0 dan dump lsass tetap tidak mendapat substansi yang dilindungi
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe (meja depan autentikasi)"]
        att["Penyerang (hak administrator)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe (brankas rahasia)"]
    end
    lsassP <-->|RPC| iso
    att -->|Dump memori| lsassP
    att -.->|Tidak bisa jangkau| iso

Gambar 11: Karena meja depan dan brankas dipisahkan, dump lsass tidak lagi menghasilkan hash sungguhan kredensial domain yang dilindungi.

Dari Windows 11 versi 22H2 ke atas, pada perangkat yang memenuhi syarat lisensi (Enterprise E3/E5, Education A3/A5) dan syarat perangkat keras, VBS dan Credential Guard diaktifkan secara bawaan. Di edisi seperti Pro, Credential Guard tidak diaktifkan secara otomatis (ada pengecualian, seperti ketika mesin yang diaktifkan di bawah lisensi yang memenuhi syarat kemudian diturunkan).⁷ “Playbook tidak lagi bekerja” di pembukaan bukan cerita tentang produk tambahan khusus; itu keadaan standar Windows terkini pada edisi sasaran.

flowchart TB
    accTitle: Alur kredensial dari masuk ke autentikasi
    accDescr: Setelah masuk rahasia sungguhan disimpan di LSAIso di VTL1; setiap kali autentikasi dibutuhkan, lsass di VTL0 meminta komputasi lewat RPC, dan hanya hasil pemrosesan autentikasi yang kembali ke VTL0 tanpa rahasia jangka panjang yang dilindungi sendiri dikembalikan
    signin["Pengguna masuk"] --> front["lsass menanganinya sebagai meja depan"]
    front --> store["Rahasia sungguhan disimpan di LSAIso"]
    auth["Permintaan autentikasi berikutnya"] --> front
    front -->|"Minta komputasi lewat RPC"| store
    store -->|"Mengembalikan hasil (tidak mengembalikan rahasia)"| front

Gambar 12: Rahasia jangka panjang yang dilindungi sendiri tidak pernah meninggalkan brankas; yang kembali ke VTL0 adalah hasil pemrosesan autentikasi, seperti tiket.

5.2. Ketahui dengan tepat apa yang tidak dilindungi

Credential Guard bukan perisai serba guna. Yang dilindungi adalah hash NTLM kredensial domain, TGT Kerberos (Ticket Granting Ticket), dan hal yang disimpan sebagai kredensial domain. Berikut berada di luar cakupan.⁸

• Tiket layanan Kerberos (TGT dilindungi)
• Kredensial akun lokal dan akun Microsoft
• Pencurian masukan oleh keylogger, dan serangan fisik
• Kredensial pada jalur yang memakai NTLMv1, MS-CHAPv2, Digest, atau CredSSP
• Bagian dalam perangkat lunak pihak ketiga yang mengelola kredensial sendiri

Juga, ketika Credential Guard diaktifkan, NTLMv1, delegasi Kerberos tanpa batasan, dan sejenisnya menjadi tidak dapat dipakai, jadi sistem bisnis yang bergantung pada autentikasi legacy membutuhkan pemeriksaan kompatibilitas.⁸ Bukan “aktifkan dan selesai”, melainkan pahami apa yang di dalam dan di luar jangkauan pertahanan dan isi sisanya dengan kontrol lain — itu cara yang benar memakainya dalam praktik.

flowchart TB
    accTitle: Jangkauan pertahanan Credential Guard
    accDescr: Hash NTLM domain dan TGT, serta kredensial domain yang disimpan, dilindungi, sementara tiket layanan, akun lokal, keylogger, serangan fisik, dan kredensial yang disimpan secara privat oleh aplikasi berada di luar cakupan
    scope{"Di sisi mana batas perlindungan rahasia ini berada?"} --> inA["Hash NTLM domain dan TGT"]
    scope --> outA["Tiket layanan dan akun lokal"]
    inA --> prot["Dilindungi di LSAIso"]
    outA --> unprot["Tidak dilindungi (kontrol lain dibutuhkan)"]
    unprot -.-> outB["Ketukan tombol, serangan fisik, dan penyimpanan privat aplikasi juga di luar cakupan"]

Gambar 13: Jangkauan pertahanan digambar dengan garis yang jelas, dan bagian luar garis diisi dengan autentikasi multifaktor dan desain sisi aplikasi.

6. Lihat sendiri

Anda dapat mengonfirmasi keadaan berjalan VBS dan setiap fitur di mesin sendiri.

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

Cara membacanya sebagai berikut.⁹

• Jika VirtualizationBasedSecurityStatus adalah 2, VBS diaktifkan dan berjalan.
• Jika SecurityServicesRunning berisi 1, Credential Guard sedang berjalan; jika berisi 2, Memory integrity (HVCI) sedang berjalan.

Untuk mengonfirmasi keadaan berjalan di GUI, lihat bidang “Virtualization-based security” di msinfo32 (layanan yang berjalan tercantum, seperti “Hypervisor enforced Code Integrity”). Toggle “Memory integrity” di bawah “Device security > Core isolation” di aplikasi Windows Security adalah layar yang mencerminkan pengaturan; ia dapat tampak nyala bahkan sementara HVCI tidak benar-benar berjalan — menunggu reboot tepat setelah pengaktifan, atau masalah kompatibilitas saat start — jadi nilai apakah ia berjalan dari msinfo32 atau dari SecurityServicesRunning milik Win32_DeviceGuard.⁵

Ada juga jejak di tab Details Task Manager. Pada mesin di mana VBS berjalan Anda akan melihat proses yang disebut “Secure System”. LsaIso.exe adalah proses yang muncul ketika layanan Isolated LSA di-host di VTL1, dan ia biasanya tidak muncul dalam konfigurasi di mana hanya HVCI yang diaktifkan. Ada atau tidaknya proses hanyalah jejak, walaupun, jadi nilai apakah Credential Guard berjalan dari SecurityServicesRunning (apakah berisi 1), seperti di atas. Keduanya adalah jendela yang terlihat dari VTL0 yang sesuai dengan dunia sisi VTL1.

flowchart TB
    accTitle: Cara memeriksa bahwa fitur terkait VBS sedang berjalan
    accDescr: Konfirmasikan bahwa VBS berjalan dengan mengkueri Win32_DeviceGuard, nilai Credential Guard dan HVCI dari nilai SecurityServicesRunning, dan lihat log CodeIntegrity untuk masalah driver
    q0["Win32_DeviceGuard"] --> q1{"Status VBS 2?"}
    q1 -->|Tidak| off["VBS tidak berjalan"]
    q1 -->|Ya| q2{"Berisi 1 atau 2?"}
    q2 -->|1| cg["Credential Guard nyala"]
    q2 -->|2| hvciR["HVCI nyala"]
    hvciR -.-> ev["CodeIntegrity 3087"]

Gambar 14: Konfirmasi keadaan berjalan dalam tiga tahap: VBS sendiri, setiap layanan di atasnya, dan log ketika masalah terjadi.

7. Tiga salah baca yang harus dihindari dalam praktik

7.1. “Melindungi hak administrator sudah cukup. VBS adalah cerita sisi server”

Yang dicegah Credential Guard adalah kerusakan yang menyebar setelah hak administrator diambil (ekfiltrasi hash dan gerakan lateral). Dengan kata lain VBS adalah satu lapisan pertahanan berlapis yang mengasumsikan kompromi, dan justru di PC klien ia efektif. Di Windows 11 yang memenuhi syarat, diaktifkan-secara-bawaan adalah standar, jadi postur yang tepat bukan “ini tidak ada hubungannya dengan kami” melainkan “kelola kompatibilitas dengan asumsi ia sudah berjalan”.

flowchart TB
    accTitle: Tahap kompromi dan di mana VBS berlaku
    accDescr: Akses awal dicakup kontrol lain seperti autentikasi multifaktor dan pelatihan; HVCI memblokir injeksi kode ke kernel setelah eskalasi hak; Credential Guard memblokir pencurian rahasia domain yang dilindungi dan gerakan lateral, tetapi tidak menjangkau rahasia di luar cakupannya
    s1["Akses awal (phishing dan sejenisnya)"] --> s2["Eskalasi hak"]
    s2 --> s3["Injeksi kode ke kernel"]
    s3 --> s4["Pencurian rahasia domain yang dilindungi dan gerakan lateral"]
    s1 -.-> d1["MFA, pelatihan, dan EDR mencakup ini"]
    s3 -.-> d2["HVCI memblokir langkah ini"]
    s4 -.-> d3["Credential Guard memblokir ini (rahasia yang dilindungi saja)"]

Gambar 15: VBS bukan teknologi “jangan biarkan mereka masuk”; ia teknologi “jangan biarkan mereka menang setelah mereka masuk”, dan tahap yang dijaganya berbeda.

7.2. “Jika Memory integrity menimbulkan masalah, tinggal matikan saja”

Mematikannya akan membuat segala berjalan untuk sementara, tetapi ia meruntuhkan penghalang terhadap injeksi kode ke kernel secara keseluruhan. Respons yang tepat adalah pertama-tama mengidentifikasi driver yang diblokir di log CodeIntegrity dan menerapkan versi yang diperbarui vendor. Bahkan jika Anda menonaktifkannya sementara untuk validasi, kami merekomendasikan operasi yang tidak membuat itu pengaturan permanen.

7.3. “Dengan Credential Guard, kata sandi tidak dapat dicuri”

Itu kelebihan percaya diri dari mencampuradukkan jangkauan pertahanan. Tiket layanan, akun lokal, ketukan tombol sendiri, dan kredensial yang disimpan secara privat oleh aplikasi berada di luar cakupan.⁸ Phishing dan keylogger membutuhkan kontrol lain (autentikasi multifaktor, Windows Hello, dan tinjauan manajemen kredensial di sisi aplikasi).

8. Ringkasan

• VBS memakai hypervisor untuk membuat lingkungan terisolasi dan melindungi fitur keamanan dengan asumsi kernel dapat dikompromikan.¹
• Satuan isolasi adalah VTL; saat ini dua tingkat diimplementasikan, VTL0 (dunia biasa) dan VTL1 (Secure Kernel dan IUM).²
• Substansi batasnya adalah perlindungan akses memori SLAT, yang perangkat lunak di dalam partisi — termasuk kernel — tidak dapat ubah.²
• HVCI menjalankan verifikasi integritas kode di lingkungan terisolasi dan menegakkan “tidak dapat dieksekusi sampai verifikasi lulus” serta “halaman yang dapat dieksekusi tidak dapat ditulis”.⁴ Harganya adalah Anda harus mengelola kompatibilitas driver.⁵
• Credential Guard mengisolasi hash NTLM kredensial domain dan TGT ke LSAIso di VTL1. Dari Windows 11 22H2 ke atas ia diaktifkan secara bawaan pada perangkat yang memenuhi syarat lisensi (Enterprise, Education) dan syarat perangkat keras (pakai ini bersama pemeriksaan keadaan berjalan).⁶⁷
• Anda dapat mengonfirmasi keadaan berjalan dari SecurityServicesRunning milik Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).⁹

Bersambung di Bagian 3, “Mesin virtual yang boot dalam hitungan detik — WSL2, Windows Sandbox, dan kontainer“.

Sejauh ini kita telah melihat virtualisasi dari sisi “kekuatan isolasi”. Edisi terakhir melihat dari sisi sebaliknya, “keringanan”, dan mengikuti di mana VM ringan yang membuang bobot VM penuh sedang memotong sudut.

Artikel terkait

• Kedalaman virtualisasi Windows (Bagian 1) — Di mana Windows Anda sebenarnya berjalan? Hypervisor dan partisi
• Kedalaman memori Windows (Bagian 1) — Saat alamat virtual menjadi RAM fisik: page fault dari awal sampai akhir
• Kedalaman I/O Windows (Bagian 6, terakhir) — Filter driver dan minifilter: mengapa Procmon dan pemindai antivirus dapat mencegat I/O
• Membaca kode kesalahan Windows — struktur tiga lapis kesalahan Win32, HRESULT, dan NTSTATUS

Area konsultasi terkait

KomuraSoft LLC menangani investigasi kompatibilitas antara aplikasi Windows dan fitur keamanan, analisis kegagalan yang disebabkan driver, dan validasi teknis lingkungan PC internal.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Pemanfaatan ulang dan migrasi aset yang ada
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apakah VBS (virtualization-based security) dan Core isolation hal yang sama?

Secara ketat, mereka berbeda. VBS adalah teknologi fondasi yang membuat lingkungan terisolasi dengan hypervisor, dan "Core isolation" di aplikasi Windows Security adalah nama layar yang mengelompokkan beberapa perlindungan yang dibangun di atas VBS. Yang representatif adalah "Memory integrity", yang merujuk pada HVCI (hypervisor-protected code integrity). Konfirmasikan keadaan berjalan setiap layanan dengan mengkueri Win32_DeviceGuard, bukan dari tampilan layar.

Bisakah memori VTL1 benar-benar tidak dibaca, bahkan dengan hak administrator atau dari driver kernel?

Tidak bisa. Perlindungan akses memori per-VTL dikelola oleh hypervisor terhadap ruang alamat fisik partisi, dan perangkat lunak yang berjalan di dalam partisi tidak dapat mengubahnya. Bahkan kode yang berjalan di kernel (ring 0) tidak diizinkan mengakses memori VTL1 dari VTL0.

Mengapa mengaktifkan Memory integrity (HVCI) dapat menghentikan driver bekerja?

Di lingkungan HVCI, halaman kernel menjadi dapat dieksekusi hanya setelah lulus verifikasi integritas, dan penulisan ke halaman yang dapat dieksekusi tidak diizinkan. Driver tanpa tanda tangan, atau driver desain lama yang menulis ulang memori yang dapat dieksekusi, tidak dapat memenuhi kendala ini dan pemuatannya diblokir. Anda dapat mengonfirmasi pemblokiran di log CodeIntegrity Operational (event ID 3087 dan sejenisnya).

Apa yang dilindungi Credential Guard, dan apa yang tidak dilindunginya?

Ia melindungi hash kata sandi NTLM kredensial domain, TGT Kerberos, dan hal yang disimpan aplikasi sebagai kredensial domain, di lingkungan terisolasi. Tiket layanan Kerberos, kredensial akun lokal dan akun Microsoft, pencurian masukan oleh keylogger, dan serangan fisik berada di luar cakupan.

Di mana saya dapat memeriksa apakah VBS sedang berjalan?

Lihat bidang "Virtualization-based security" di msinfo32, atau kueri kelas Win32_DeviceGuard di namespace root/Microsoft/Windows/DeviceGuard dari PowerShell. Jika SecurityServicesRunning berisi 1, Credential Guard sedang berjalan; jika berisi 2, Memory integrity (HVCI) sedang berjalan.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.