Skip to content

Secure Kernel / IUM trustlet attack surface

VBS altında VTL1'de çalışan Secure Kernel (securekernel.exe) ve IUM trustlet'leri, normal-world ile secure-world arasındaki secure call / normal call sınırını ayrı ve yüksek değerli bir attack surface'e dönüştürür — bu not defensive/kavramsal bir katalog kaydıdır.

Mechanism

Invariant: VTL0'daki hiçbir kod VTL1 belleğine dokunamaz; iki dünya yalnızca dar, sürüm-kontrollü bir call table üzerinden konuşur

Virtualization-Based Security (VBS), Hyper-V hypervisor'ı ve SLAT (Second Level Address Translation) kullanarak Virtual Trust Level'ları yaratır. VTL1 Secure Kernel ile Isolated User Mode (IUM) trustlet'lerini barındırır; VTL0 ise normal NT kernel ve driver'larıdır. VTL'ler hierarchical'dır: VTL1, VTL0'dan daha privileged'dır ve VTL0 kernel'ı tamamen compromise olsa bile trustlet'lerin (ör. LSAISO.exe) user-mode page'lerine erişemez.

Bu izolasyon, iletişimi imkânsız kılmaz; onu tek bir dar kapıya sıkıştırır. Üç mekanizma vardır: NT'nin VTL1'den servis istediği secure calls, SK'nın VTL0'a geri düştüğü normal calls, ve trustlet'lerin SK'dan servis aldığı secure system calls. Kritik güvenlik invariant'ı şudur: Secure Kernel kasıtlı olarak küçüktür — trustlet'lere 50'den az secure system call expose eder ki attack surface minimal kalsın. Bir trustlet normal bir Win32 syscall'a ihtiyaç duyduğunda onu VTL0'a marshal eder; SK bu işleri kendisi implement etmez.

Sınır neden değerlidir: SK, VTL0'dan gelen input'a asla güvenemez. Bir secure call handler'ı NT'nin sağladığı bir pointer, handle veya MDL-backed buffer'ı yeterince validate etmezse, düşük-privileged VTL0 kernel'ı VTL1 içinde bir memory-corruption veya confused-deputy primitive'i elde eder — bu, VBS'in tüm güven modelini deviren bir privilege inversion'dır. Trustlet'in kendi parsing yüzeyi de (RPC, secure section'lar, policy metadata) aynı şekilde saldırılabilir bir sınırdır.

Walkthrough

Sadece kavramsal — kamuya açık Windows Internals writeup'larına defender bakışı; weaponize edilmiş exploit, offset veya gadget yok

Connor McGarr'ın "Secure Calls" writeup'ı bu sınırın nasıl işlediğini kamuya açık biçimde ortaya koyar. Amaç exploit üretmek değil, defender'ın hangi transition'ların hangi trust asymmetry'sini taşıdığını anlamasıdır.

Secure call yolu (NT → SK), yüksek seviyede:

  1. NT bir VTL1 servisine ihtiyaç duyar ve nt!VslpEnterIumSecureMode'u çağırır; parametreleri bir SECURE_CALL_ARGS yapısına paketler (secure call code + input/output buffer).
  2. Bu, nt!HvlSwitchToVsmVtl1'e iner; buradan HvCallVtlCall (hypercall code 0x11) ile bir vmcall issue edilir. Direkt VTL0→VTL1 geçişi yoktur; her transition'ı Hyper-V broker eder (VM exit → VTL1 VMCS load → vmresume).
  3. Execution VTL1'de securekernel!IumInvokeSecureService dispatcher'ında devam eder. SK, gelen call code'unu geçerli secure service table'ına karşı doğrular; desteklenmeyen bir code bugcheck'e yol açar.
  4. Handler, NT'den gelen argümanları — özellikle virtual-to-physical çevrim gerektiren MDL-backed buffer'ları ve opaque secure handle'ları — kendi içinde re-validate etmek zorundadır. Buradaki eksik validation, VTL0-kontrollü input'un VTL1'de bir corruption'a dönüştüğü noktadır.
  5. Dönüş securekernel!ShvlpVtlReturn (vmcall code 0x12) ile Hyper-V üzerinden VTL0'a geri döner.

Normal call yolu (SK → NT): SK, VTL0'da implement edilen bir servise (ör. file I/O) ihtiyaç duyduğunda, önceden yarattığı bir dedicated secure thread bir loop içinde bekler ve isteği nt!VslpDispatchIumSyscall üzerinden system service table index'iyle çalıştırır. Bu asimetri de bir güven sorunudur: SK, VTL0'dan dönen sonuca körü körüne güvenemez.

Defender'ın kavramsal fuzzing/görünürlük mantığı (weaponize değil)

Kamuya açık araştırma (SkBridge gibi harness'ler), secure call'ların normalde inline ve hardcoded parametrelerle invoke edildiğini, bu yüzden bu interface'in dışarıya kapalı olduğunu gösterir. Defensif değeri: hangi secure call code'larının hangi input tipini (handle vs. MDL vs. scalar) taşıdığını bir envanter olarak tutmak, yeni eklenen handler'ların yüzeyini takip etmeyi sağlar.

Detection

  • VBS/VSM gerçekten çalışıyor mu: msinfo32 → Virtualization-based security → "Running" ve services listesinde hypervisor-enforced code integrity. Beklenen fleet'te sessizce "Not enabled" olan host'lar anomalidir.
  • Trustlet bütünlüğü: LSAISO.exe / LSASS isolation'ının beklenen host'larda mevcut olduğunu envanterle. IsSecureProcess ile (via ProcessBasicInformation extended info) bir process'in gerçekten secure olup olmadığı doğrulanabilir; olması gereken trustlet'in secure flag'inin düşmesi red flag'dir.
  • Trustlet'e enjeksiyon denemeleri: CreateRemoteThread, VirtualAllocEx, WriteProcessMemory, DLL load veya user-mode APC'nin bir IUM process'e karşı denenmesi tasarımca beklenmedik biçimde fail eder; bu başarısız çağrılar (özellikle LSAISO hedefli) telemetride credential-theft göstergesidir.
  • Bugcheck pattern'i: Geçersiz/desteklenmeyen secure call code'ları SK tarafında bugcheck üretir; secure-kernel-kaynaklı crash'lerin ani artışı, sınırı zorlayan bir aktivitenin işareti olabilir.
  • BYOVD ile VTL0 compromise: VTL1'e doğrudan girilemediği için saldırganlar önce VTL0 kernel R/W arar; bilinen vulnerable driver load'larını (blocklist hash'leri) izlemek bu ilk adımı yakalar.

Mitigation

  • VBS + HVCI'yi UEFI lock ile zorunlu kıl: Memory Integrity ve VSM'i mandatory enforcement + UEFI lock ile aç ki config sessizce zayıflatılamasın; Credential Guard'ı (LSAISO trustlet'i) etkinleştir.
  • VBS downgrade koruması: Secure kernel / ci.dll gibi VBS binary'lerinin eski-vulnerable sürümlere rollback'ini revocation policy (SkuSiPolicy / vulnerable-binary blocklist) ile engelle — aksi halde sınırın kendisi unpatch edilebilir (bkz. VBS downgrade EoP).
  • Attack surface minimizasyonu Microsoft tarafında: SK'nın <50 secure system call ile küçük tutulması bilinçli bir design mitigation'dır; savunma tarafında bunu patch cadence ile eşleştir — yeni secure call handler'ları içeren SK güncellemelerini öncelikli uygula.
  • VTL0'ı sertleştir: Sınırın ilk adımı VTL0 kernel primitive'i olduğundan, Vulnerable Driver Blocklist / WDAC, least-privilege admin token dağıtımı ve driver attack-surface reduction, trustlet sınırına ulaşmayı zorlaştırır.
  • Debug/inject yüzeyini kapalı tut: IUM process'lere attach/inject default olarak engellidir; bu davranışı zayıflatan test/debug policy'lerini production'da devre dışı bırak.

References

See also