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

Dulu, bagi penyerang Windows, hak administrator adalah “garis finis”. Muat driver kernel sebagai administrator, dump memori proses LSASS, dan hash kata sandi serta tiket Kerberos sudah di tangan. Setelah itu tinggal berpindah ke mesin lain dengan hash yang dicuri.

Pada Windows 11 yang menjalankan Credential Guard — pada perangkat yang memenuhi syarat lisensi seperti Enterprise dan Education plus syarat perangkat keras, ini sudah keadaan bawaan sejak 22H2 — pola itu tidak lagi berlaku. Penyerang yang sudah menguasai kernel sepenuhnya boleh mencari memori sesuka hati, hash kredensial domain yang dilindungi itu sendiri tidak ditemukan “di dalam OS itu”. Jika Credential Guard tidak berjalan, risikonya sama seperti dulu, jadi baca bagian ini bersama metode konfirmasi di bawah.

Lalu di mana hash itu? Jawabannya: “dunia lain yang dibuat di dalam PC yang sama”. Seperti dibahas di Bagian 1, Windows host berjalan di root partition di atas hypervisor (“Di mana Windows Anda sebenarnya berjalan?”). Artikel ini kelanjutannya: menelusuri satu garis batas lagi yang ditarik hypervisor di dalam partisi yang sama.

Pertanyaan yang dijawab Bagian 2 hanya satu.

Di mana Windows menaruh rahasia yang tidak bisa dibaca, baik dengan hak administrator maupun oleh kernel?

Pembaca sasaran adalah pengembang dan staf operasional yang menemui istilah Isolasi inti, Integritas memori, dan Credential Guard di layar pengaturan atau saat menangani gangguan, dan ingin memahami substansinya dari mekanismenya. Lingkungan prasyarat adalah Windows 10/11 x64 atau Windows Server terkini (seperti Bagian 1, penjelasan ring dan SLAT mengasumsikan x64; Arm64 memakai mekanisme lain seperti exception level). Pengetahuan prasyarat adalah konsep partisi dan SLAT di Bagian 1. Tingkat kesulitannya menengah. Tujuannya penjelasan struktur, bukan panduan langkah konfigurasi fitur keamanan.

1. Kesimpulan lebih dulu

Windows menambahkan sumbu hak bernama VTL (Virtual Trust Level) dan menaruh rahasia di VTL1. Memori VTL1 tidak bisa dibaca dari kernel biasa yang berjalan di VTL0. Yang menjaga batas itu bukan kernel sendiri, melainkan hypervisor yang memegang tabel terjemahan SLAT.

Itulah kerangka virtualization-based security (VBS). VBS memakai hypervisor untuk membentuk lingkungan terisolasi, lalu menampung fitur keamanan di sana. Desainnya berangkat dari asumsi bahwa lingkungan terisolasi tetap terlindungi meski kernel dikompromikan.¹

flowchart TB
    accTitle: Dua dunia yang dibentuk VBS
    accDescr: Di dalam partisi yang sama ada VTL0 dan VTL1; VTL0 berisi kernel biasa dan aplikasi, VTL1 berisi 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 dibaca| ium

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

Poin pentingnya: ini bukan “menjalankan VM lain”. VTL0 dan VTL1 berada di dalam partisi yang sama, di dalam Windows yang sama. Bagaimana pemisahan itu diwujudkan akan dibahas berurutan.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 22, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

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

Keamanan Windows tradisional dibangun di atas tangga ring (tingkat hak). Mode pengguna (ring 3) dijaga oleh mode kernel (ring 0). Lalu 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 yang berjalan, melainkan juga banyak driver pihak ketiga. Jika salah satunya punya kerentanan, penyerang memperoleh eksekusi kode di ring 0.
• Dari ring 0, semuanya terlihat. Sebanyak apa pun proses mode pengguna seperti LSASS membela diri, memori itu bebas dibaca oleh penyerang yang sudah menguasai kernel. Atribut perlindungan maupun page table dikelola kernel sendiri.

flowchart TB
    accTitle: Jalur pencurian kredensial pada model ring tradisional
    accDescr: Penyerang yang menguasai 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["Menguasai ring 0"]
    r0 --> readall["Dapat membaca semua memori fisik"]
    readall --> lsass["Memperoleh hash dari memori LSASS"]
    lsass --> lateral["Disalahgunakan untuk pergerakan lateral ke mesin lain"]

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

Yang dibutuhkan, dengan kata lain, adalah “tempat yang lebih tinggi dari ring 0”. Tempat itu sudah muncul di Bagian 1. Hypervisor berjalan dengan hak yang lebih tinggi daripada kernel, dan sejak awal memonopoli kendali izin akses memori CPU (SLAT). 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 Level (VTL)

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

Konsep pusat VSM adalah VTL (Virtual Trust Level: tingkat kepercayaan virtual). Poin utamanya sebagai berikut.²

• VTL bersifat hierarkis, dan semakin besar angkanya, semakin tinggi haknya. VTL0 adalah yang terendah; VTL1 lebih tinggi haknya daripada VTL0.
• Secara arsitektur didefinisikan hingga 16 tingkat, tetapi yang saat ini diimplementasikan hanya dua: VTL0 dan VTL1.
• Setiap VTL memiliki perlindungan akses memori yang independen. Perlindungan ini dikelola hypervisor terhadap ruang alamat fisik partisi, sehingga perangkat lunak sistem di dalam partisi tidak dapat mengubahnya.
• Prosesor virtual memiliki keadaan register dan mekanisme 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 mekanisme 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["Mekanisme interrupt"]
    m1 -.-> rule["VTL lebih rendah tidak dapat menyentuh VTL lebih tinggi"]
    m2 -.-> rule
    m3 -.-> rule

Gambar 3: Menjadikan bukan hanya memori, melainkan juga keadaan CPU dan interrupt sebagai dunia terpisah, adalah tiga perangkat yang tidak menyisakan 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 pun ada mode kernel dan mode pengguna.

flowchart TB
    accTitle: Empat wilayah yang dibentuk 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 yang terpisah.

3.2. Substansi batasnya adalah SLAT

Di Bagian 1 disebutkan bahwa tabel terjemahan tingkat kedua yang memetakan guest physical address (GPA) ke RAM sungguhan (SPA) — SLAT — dipegang hypervisor. VSM memakai tepat sifat itu. Isolasi VTL dibentuk dengan Hyper-V hypervisor dan SLAT.³

Ketika VTL1 menyatakan “memori ini tidak boleh terlihat oleh VTL0”, hypervisor mencabut izin akses ke halaman itu dari tabel terjemahan untuk VTL0. Setelah itu, meski kernel VTL0 mencoba menyentuh alamat tersebut, permintaan ditolak pada tahap terjemahan alamat CPU. Menulis ulang page table milik kernel sendiri tidak ada gunanya. Page table (GVA→GPA) memang milik kernel, tetapi terjemahan selanjutnya (GPA→SPA) dan izin akses final adalah milik hypervisor.

flowchart TB
    accTitle: Alur penolakan akses dari VTL0 ke memori VTL1
    accDescr: Ketika kernel VTL0 mencoba membaca memori VTL1, page table miliknya sendiri dapat dilewati, tetapi perlindungan akses SLAT menolaknya dan kendali berpindah ke hypervisor
    try["Kernel VTL0 mencoba membaca halaman VTL1"] --> pt["Page table kernel sendiri dilewati"]
    pt --> slat{"Apakah perlindungan akses SLAT mengizinkan?"}
    slat -->|Tidak ada izin| deny["Hypervisor campur tangan dan menolak akses"]
    slat -->|Ada izin| ok["Akses memori biasa"]
    deny -.-> point["Dilindungi pada lapisan yang tidak dapat diubah kernel"]

Gambar 5: Temboknya berada di luar kernel, dan perlindungan SLAT tidak dapat diubah dari perangkat lunak di dalam partisi.

Di Bagian 1 seri memori tertulis bahwa “VAD, PTE, dan atribut perlindungan yang menentukan boleh tidaknya akses”. Di lingkungan VBS, setelah semuanya lulus, masih ada pos pemeriksaan SLAT — begitu ringkasannya.

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: mode pengguna terisolasi), dan program yang berjalan di sana disebut trustlet (proses tepercaya).³

Trustlet tidak dapat melakukan segala hal seperti proses biasa. Sebagian besar system call di-marshal ke kernel NT di sisi VTL0 dan diproses di sana.³ VTL1 bukan “dunia tingkat lebih tinggi yang bisa melakukan apa pun”, melainkan ruang brankas untuk menyimpan rahasia, dan sengaja dibuat kecil. Semakin sedikit kode yang boleh dibawa ke dalam brankas, semakin kecil permukaan serangan.

flowchart TB
    accTitle: Alur system call trustlet
    accDescr: Trustlet di VTL1 tidak memproses sebagian besar system call sendiri, melainkan me-marshal permintaan ke kernel NT VTL0 dan hanya menerima hasilnya, sehingga VTL1 tetap kecil
    tl["Trustlet (IUM di VTL1)"] --> sc{"System call diperlukan"}
    sc -->|Sebagian besar kasus| mar["Meminta kernel NT di VTL0"]
    mar --> res["Hanya menerima hasil"]
    res -.-> small["Sisi VTL1 tetap kecil dan permukaan serangan berkurang"]

Gambar 6: Brankas tidak punya fasilitas sendiri; pekerjaan rutin diminta ke luar, dan yang terus dijaga hanyalah rahasia.

4. HVCI — memverifikasi integritas kode kernel di dalam brankas

4.1. Apa yang diverifikasi

Fitur representatif pertama yang berdiri di atas VBS adalah Integritas memori — HVCI (hypervisor-protected code integrity). Windows memiliki mekanisme code integrity yang memeriksa driver dan biner mode kernel sebelum dijalankan, dan menolak memuat yang tidak bertanda tangan atau tidak tepercaya. HVCI menjalankan verifikasi itu di dalam lingkungan terisolasi VBS.¹

Alasan memindahkan logika verifikasi sendiri ke VTL1 adalah tepat kelemahan di bagian 2. Jika kode verifikasi berada di dalam kernel VTL0, penyerang yang menguasai kernel dapat menukar verifikasi itu. Jika berada di VTL1, tangan penukar tidak sampai.

flowchart TB
    accTitle: Perbedaan menurut tempat kode verifikasi diletakkan
    accDescr: Jika kode verifikasi ada di dalam kernel VTL0, penguasaan kernel menonaktifkannya; jika ada di VTL1, bahkan penyerang yang menguasai kernel tidak sampai, dan verifikasi tetap terjaga
    atk["Penyerang yang menguasai kernel"] --> q{"Di mana verifikasi code integrity berada?"}
    q -->|"Di dalam kernel VTL0 (tradisional)"| bad["Logika verifikasi dapat ditukar"]
    q -->|"Lingkungan terisolasi VTL1 (HVCI)"| good["Tangan penukar tidak sampai"]
    bad --> res1["Kode tanpa tanda tangan dapat dieksekusi di kernel"]
    good --> res2["Verifikasi terus berfungsi setelah kernel dikompromikan"]

Gambar 7: Inti HVCI adalah memindahkan logika verifikasi agar tidak diletakkan di dalam sisi yang berpeluang ditembus pos pemeriksaannya.

4.2. Aturan halaman yang dapat dieksekusi

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

• Halaman kernel baru menjadi dapat dieksekusi setelah lulus verifikasi code integrity.
• Halaman yang dapat dieksekusi tidak menjadi writable (yang disebut W^X).

Jika keduanya berlaku, bahkan jika kerentanan seperti buffer overflow memungkinkan memori kernel ditulis ulang, isi yang ditulis tidak dapat dijalankan. Halaman yang dapat dieksekusi tidak dapat ditulis ulang, dan halaman yang dapat ditulis tidak dapat dieksekusi.⁴ Landasan final izin eksekusi ada pada hak eksekusi di sisi SLAT, dan kernel VTL0 tidak dapat mengoperasikannya.

flowchart TB
    accTitle: Sampai halaman kernel menjadi dapat dieksekusi di lingkungan HVCI
    accDescr: Permintaan muat driver menjalani verifikasi code integrity di lingkungan terisolasi VBS; jika lulus, halaman diizinkan sebagai dapat dieksekusi dan tidak writable; jika gagal, diblokir dan dicatat di log CodeIntegrity
    load["Permintaan muat dan eksekusi kode kernel"] --> verify{"Verifikasi code integrity di lingkungan terisolasi"}
    verify -->|Lulus| exec["Diizinkan sebagai halaman dapat dieksekusi (penulisan tidak diizinkan)"]
    verify -->|Gagal| block["Pemuatan diblokir"]
    block --> log["Dicatat di log operasional CodeIntegrity (event ID 3087)"]
    exec -.-> wx["Halaman yang writable tetap tidak dapat dieksekusi"]

Gambar 8: Verifikasi aturan yang tidak memperbolehkan eksekusi dan penulisan sekaligus dilakukan di sisi VTL1, dan kernel VTL0 tidak dapat membatalkannya.

Menelusuri dari sudut pandang penyerang membuat cara kerja aturan ini lebih jelas.

flowchart TB
    accTitle: Alur gagalnya injeksi kode di lingkungan HVCI
    accDescr: Meski kerentanan memungkinkan memori kernel ditulis ulang, halaman yang berhasil ditulis tidak dapat dieksekusi, dan halaman yang dapat dieksekusi memang tidak dapat ditulis ulang, sehingga kode yang diinjeksikan tidak dapat dijalankan
    inj["Mencoba mengutak-atik memori kernel lewat kerentanan"] --> which{"Halaman mana yang disasar?"}
    which -->|Halaman yang writable| wok["Penulisan ulang berhasil"]
    which -->|Halaman yang dapat dieksekusi| xfail["Penulisan ulang itu sendiri tidak bisa"]
    wok --> nx["Namun halaman itu tidak dapat dieksekusi"]
    nx --> dead["Kode injeksi tidak dapat dijalankan"]
    xfail --> dead

Gambar 9: Makna tidak menyilangkan halaman yang bisa ditulis dan halaman yang bisa dijalankan terletak pada fakta bahwa kedua pintu masuk berujung jalan buntu.

4.3. Kompatibilitas driver sebagai imbalannya

Aturan ini bertabrakan dengan driver desain lama. Driver yang menulis ulang kodenya sendiri saat runtime, yang tidak bertanda tangan, atau yang meminta memori yang sekaligus dapat dieksekusi dan writable — driver seperti itu tidak dapat dimuat di lingkungan HVCI. Fakta pemblokiran dapat dicek di Event Viewer pada Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (event ID 3087 sebagai yang khas).⁵

Inti masalah “perangkat periferal berhenti bekerja setelah Integritas memori diaktifkan” pada banyak kasus adalah ini. Jalur penanganan yang benar adalah memperbarui ke driver versi yang mendukung HVCI; menonaktifkan Integritas memori sebaiknya dianggap langkah terakhir yang melepaskan seluruh perlindungan. Jika terlibat dalam verifikasi ini dari sisi pengembangan driver, artikel filter driver (“Minifilter driver Windows”) juga dapat dijadikan rujukan.

flowchart TB
    accTitle: Penelusuran masalah ketika perangkat periferal tidak bekerja karena Integritas memori
    accDescr: Identifikasi driver yang diblokir di log operasional CodeIntegrity; jalur utama adalah memperbarui ke versi yang mendukung HVCI; jika tidak ada, minta vendor; penonaktifan bukan pengaturan permanen melainkan langkah terakhir
    sym["Perangkat tidak bekerja setelah Integritas memori diaktifkan"] --> log2["Identifikasi sumber blokir di log CodeIntegrity"]
    log2 --> upd{"Ada driver versi yang mendukung HVCI?"}
    upd -->|Ada| fix2["Perbarui dan selesaikan sambil tetap aktif"]
    upd -->|Tidak ada| ask2["Minta versi yang mendukung kepada vendor"]
    ask2 -.-> temp["Penonaktifan adalah langkah terakhir, jangan dijadikan pengaturan permanen"]

Gambar 10: Yang dilihat pertama bukan layar pengaturan melainkan log; pelaku pemblokiran diketahui dari event ID 3087.

5. Credential Guard — hash ada di dalam LSAIso

5.1. LSASS dan LSAIso

Fitur representatif kedua yang berdiri di atas VBS adalah jawaban teka-teki di pembuka: Credential Guard.

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

• lsass.exe (VTL0) tetap berjalan sebagai pintu masuk pemrosesan autentikasi, seperti sebelumnya.
• Rahasia itu sendiri dipegang LSAIso.exe (VTL1) dan tidak dapat diakses dari VTL0.
• Keduanya berkomunikasi lewat RPC (remote procedure call).
• LSAIso tidak meng-host driver perangkat sama sekali, dan hanya menampung biner bertanda tangan seminimal mungkin. Tanda tangan diverifikasi dengan sertifikat yang dipercaya VBS.⁶

flowchart TB
    accTitle: Penempatan kredensial saat Credential Guard aktif
    accDescr: lsass di VTL0 berkomunikasi lewat RPC dengan LSAIso di VTL1 sebagai pintu masuk autentikasi; hash dan TGT kredensial domain yang dilindungi dipegang LSAIso, sehingga penyerang yang memperoleh hak administrator di VTL0 dan dump lsass tidak mendapatkan nilai yang dilindungi itu sendiri
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe (pintu masuk autentikasi)"]
        att["Penyerang (hak administrator)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe (brankas rahasia)"]
    end
    lsassP <-->|RPC| iso
    att -->|Dump memori| lsassP
    att -.->|Tidak sampai| iso

Gambar 11: Karena pintu masuk dan brankas dipisah, dump lsass pun tidak lagi menemukan hash kredensial domain yang dilindungi itu sendiri.

Sejak Windows 11 versi 22H2, pada perangkat yang memenuhi syarat lisensi (Enterprise E3/E5 dan Education A3/A5) serta syarat perangkat keras, VBS dan Credential Guard aktif secara bawaan. Pada edisi seperti Pro, Credential Guard tidak aktif otomatis (ada pengecualian, misalnya saat perangkat yang sebelumnya aktif dengan lisensi yang memenuhi syarat diturunkan).⁷ “Pola lama tidak berlaku” di pembuka bukan cerita produk tambahan khusus, melainkan keadaan standar Windows terkini pada edisi yang memenuhi syarat.

flowchart TB
    accTitle: Alur kredensial dari masuk hingga autentikasi
    accDescr: Setelah masuk, rahasia itu sendiri disimpan di LSAIso VTL1; setiap kali autentikasi diperlukan, lsass VTL0 meminta perhitungan lewat RPC, dan rahasia jangka panjang yang dilindungi tidak dikembalikan — yang kembali ke VTL0 hanya hasil pemrosesan autentikasi
    signin["Pengguna masuk"] --> front["lsass memproses sebagai pintu masuk"]
    front --> store["Rahasia itu sendiri disimpan di LSAIso"]
    auth["Permintaan autentikasi berikutnya"] --> front
    front -->|Meminta perhitungan lewat RPC| store
    store -->|"Mengembalikan hasil pemrosesan (rahasia tidak dikembalikan)"| front

Gambar 12: Rahasia jangka panjang yang dilindungi tidak keluar dari brankas; yang kembali ke VTL0 adalah hasil pemrosesan autentikasi seperti tiket.

5.2. Mengetahui dengan tepat apa yang tidak dilindungi

Credential Guard bukan perisai serba bisa. Yang dilindungi adalah hash NTLM kredensial domain, TGT Kerberos (ticket-granting ticket), dan data yang disimpan sebagai kredensial domain. Hal-hal berikut berada di luar cakupan.⁸

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

Selain itu, saat Credential Guard aktif, NTLMv1 dan unconstrained delegation Kerberos tidak dapat dipakai, sehingga sistem bisnis yang bergantung pada autentikasi warisan perlu dicek kompatibilitasnya.⁸ Bukan “aktifkan lalu selesai”, melainkan memahami dalam dan luar cakupan perlindungan lalu menutup sisanya dengan langkah lain — itulah cara pakai yang benar di lapangan.

flowchart TB
    accTitle: Cakupan perlindungan Credential Guard
    accDescr: Hash NTLM domain, TGT, dan kredensial domain yang disimpan dilindungi, sementara tiket layanan, akun lokal, keylogger, serangan fisik, dan kredensial yang disimpan aplikasi sendiri berada di luar cakupan
    scope{"Rahasia itu berada di sisi mana dari cakupan?"} --> inA["Hash NTLM domain dan TGT"]
    scope --> outA["Tiket layanan atau akun lokal"]
    inA --> prot["Dilindungi di LSAIso"]
    outA --> unprot["Tidak dilindungi (perlu langkah lain)"]
    unprot -.-> outB["Masukan keyboard, serangan fisik, dan penyimpanan mandiri aplikasi juga di luar cakupan"]

Gambar 13: Cakupan perlindungan digaris dengan tegas; sisi luar garis ditutup dengan autentikasi multifaktor atau rancangan di sisi aplikasi.

6. Memeriksa dengan mata sendiri

Status berjalan VBS dan masing-masing fitur dapat dicek di mesin sendiri.

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

Cara membacanya sebagai berikut.⁹

• Jika VirtualizationBasedSecurityStatus bernilai 2, VBS aktif dan sedang berjalan.
• Jika SecurityServicesRunning berisi 1, Credential Guard sedang berjalan; jika berisi 2, Integritas memori (HVCI) sedang berjalan.

Untuk melihat status lewat GUI, lihat kolom “Virtualization-based security” di msinfo32 (layanan yang sedang berjalan tercantum sebagai “Hypervisor enforced Code Integrity” dan sejenisnya). Tombol “Integritas memori” di “Keamanan perangkat > Isolasi inti” pada aplikasi Windows Security adalah layar yang mencerminkan pengaturan. Tombol itu dapat tampak aktif meski HVCI sebenarnya belum berjalan — misalnya menunggu reboot segera setelah diaktifkan, atau ada masalah kompatibilitas saat boot — jadi penentuan “sedang berjalan atau tidak” dilakukan dengan msinfo32 atau SecurityServicesRunning pada Win32_DeviceGuard.⁵

Jejak juga muncul di tab Details di Task Manager. Pada mesin yang menjalankan VBS, proses bernama “Secure System” (Secure System) terlihat. LsaIso.exe adalah proses yang muncul ketika layanan Isolated LSA di-host di VTL1, dan biasanya tidak muncul pada konfigurasi yang hanya mengaktifkan HVCI. Namun ada tidaknya proses hanyalah jejak, jadi penentuan apakah Credential Guard sedang berjalan dilakukan dengan SecurityServicesRunning di atas (apakah berisi 1). Keduanya adalah jendela yang terlihat dari VTL0, yang berhubungan dengan dunia sisi VTL1.

flowchart TB
    accTitle: Langkah konfirmasi status fitur terkait VBS
    accDescr: Kueri Win32_DeviceGuard untuk memastikan VBS berjalan, tentukan Credential Guard dan HVCI dari nilai SecurityServicesRunning, dan lihat log CodeIntegrity jika ada masalah driver
    q0["Kueri Win32_DeviceGuard"] --> q1{"Status VBS bernilai 2?"}
    q1 -->|Tidak| off["VBS tidak berjalan (cek syarat dan pengaturan)"]
    q1 -->|Ya| q2{"Nilai SecurityServicesRunning?"}
    q2 -->|Berisi 1| cg["Credential Guard sedang berjalan"]
    q2 -->|Berisi 2| hvciR["Integritas memori (HVCI) sedang berjalan"]
    hvciR -.-> ev["Masalah driver dicek di log CodeIntegrity (3087)"]

Gambar 14: Konfirmasi status maju dalam tiga tahap: VBS itu sendiri, masing-masing layanan di atasnya, lalu log saat terjadi masalah.

7. Tiga salah baca yang sebaiknya dihindari di lapangan

7.1. “Cukup jaga hak administrator. VBS urusan server”

Yang dicegah Credential Guard adalah perluasan kerusakan setelah hak administrator direbut (pengeluaran hash dan pergerakan lateral). Dengan kata lain VBS adalah satu lapisan pertahanan berlapis yang berangkat dari asumsi kompromi, dan justru relevan di PC klien. Pada Windows 11 yang memenuhi syarat, aktif secara bawaan adalah standar, jadi sikap yang benar bukan “itu tidak relevan bagi kami”, melainkan “kelola kompatibilitas dengan asumsi sudah berjalan”.

flowchart TB
    accTitle: Tahap kompromi dan tempat VBS bekerja
    accDescr: Invasi awal ditangani langkah lain seperti autentikasi multifaktor dan edukasi; injeksi kode ke kernel setelah eskalasi hak dihambat HVCI; pencurian rahasia domain yang dilindungi dan pergerakan lateral dihambat Credential Guard, tetapi tidak menjangkau rahasia di luar cakupan
    s1["Invasi awal (phishing dan sejenisnya)"] --> s2["Eskalasi hak"]
    s2 --> s3["Injeksi kode ke kernel"]
    s3 --> s4["Pencurian rahasia domain yang dilindungi dan pergerakan lateral"]
    s1 -.-> d1["Ditangani MFA, edukasi, dan EDR"]
    s3 -.-> d2["HVCI menghambat di sini"]
    s4 -.-> d3["Credential Guard menghambat (hanya yang dilindungi)"]

Gambar 15: VBS bukan teknologi “jangan sampai masuk”, melainkan teknologi “jangan sampai menang setelah masuk”, dengan tahap perlindungan yang berbeda.

7.2. “Kalau Integritas memori menimbulkan masalah, tinggal dinonaktifkan”

Jika dinonaktifkan, untuk sementara semuanya berjalan, tetapi tembok terhadap injeksi kode ke kernel dilepas seluruhnya. Jalur yang benar adalah mengidentifikasi driver yang diblokir di log CodeIntegrity, lalu menerapkan versi pembaruan dari vendor. Jika dinonaktifkan sementara untuk verifikasi, operasi yang disarankan adalah tidak menjadikannya pengaturan permanen.

7.3. “Kalau ada Credential Guard, kata sandi tidak bisa dicuri”

Itu keyakinan berlebih karena mencampuradukkan cakupan. Tiket layanan, akun lokal, masukan keyboard itu sendiri, dan kredensial yang disimpan aplikasi sendiri berada di luar cakupan.⁸ Phishing dan keylogger memerlukan langkah lain (autentikasi multifaktor, Windows Hello, peninjauan pengelolaan kredensial di sisi aplikasi).

8. Ringkasan

• VBS membentuk lingkungan terisolasi dengan hypervisor, 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, dan perangkat lunak di dalam partisi — termasuk kernel — tidak dapat mengubahnya.²
• HVCI menjalankan verifikasi code integrity di lingkungan terisolasi, dan memaksa “tidak dapat dieksekusi sampai verifikasi lulus” serta “halaman yang dapat dieksekusi tidak writable”.⁴ Imbalannya, kompatibilitas driver perlu dikelola.⁵
• Credential Guard mengisolasi hash NTLM dan TGT kredensial domain ke LSAIso di VTL1. Sejak Windows 11 22H2, pada perangkat yang memenuhi syarat lisensi (Enterprise dan Education) serta syarat perangkat keras, fitur ini aktif secara bawaan (dipakai bersama konfirmasi status berjalan).⁶⁷
• Status berjalan dapat dicek lewat SecurityServicesRunning pada Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).⁹

Lanjutannya adalah Bagian 3, “Mesin virtual yang menyala dalam hitungan detik — WSL2, Windows Sandbox, dan kontainer”.

Sampai di sini virtualisasi dilihat dari sisi “kekuatan isolasi”. Bagian terakhir, sebaliknya, menelusuri dari sisi “keringanan”: di mana VM ringan yang membuang bobot full VM mengambil jalan pintas.

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 ujung ke ujung
• Minifilter driver Windows
• Sistem kode error Windows — Win32, HRESULT, NTSTATUS

Area konsultasi terkait

Komura Soft LLC menangani investigasi kompatibilitas dengan fitur keamanan aplikasi Windows, analisis gangguan yang berasal dari driver, dan verifikasi teknis lingkungan PC internal.

• Pengembangan aplikasi Windows
• Investigasi gangguan dan analisis penyebab
• Pemanfaatan aset yang sudah ada dan dukungan migrasi
• Hubungi kami

Tautan rujukan

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 (keamanan berbasis virtualisasi) dan Isolasi inti itu hal yang sama?

Secara ketat, keduanya berbeda. VBS adalah teknologi fondasi yang membentuk lingkungan terisolasi dengan hypervisor. "Isolasi inti" di aplikasi Windows Security adalah nama layar yang merangkum beberapa perlindungan yang berdiri di atas VBS. Yang paling khas adalah "Integritas memori", yang merujuk pada HVCI (hypervisor-protected code integrity). Status berjalan masing-masing layanan dicek dengan kueri Win32_DeviceGuard, bukan dari tampilan layar.

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

Tidak bisa. Perlindungan akses memori per VTL dikelola 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 Integritas memori (HVCI) kadang membuat driver berhenti bekerja?

Di lingkungan HVCI, halaman kernel baru menjadi dapat dieksekusi 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 memenuhi kendala ini sehingga pemuatannya diblokir. Catatan pemblokiran dapat dicek di log operasional CodeIntegrity (event ID 3087 dan sejenisnya).

Apa yang dilindungi Credential Guard, dan apa yang tidak?

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

Di mana bisa dicek apakah VBS sedang berjalan?

Lihat kolom "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, Integritas memori (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.