Windows Virtualization Internals (भाग 2) — वो मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

एक समय था जब Windows पर attacker के लिए Administrator privileges “goal” थे। Administrator के तौर पर kernel driver load करो, LSASS process की memory dump करो, और password hash तथा Kerberos tickets मिल जाते। वहाँ से चोरी किए hash लेकर दूसरी machine तक चलना भर रह जाता।

Current Windows 11 पर Credential Guard चलते — 22H2 से उन devices पर default state जो Enterprise और Education जैसी license requirements तथा hardware requirements पूरी करते हैं — वह playbook काम नहीं करती। Kernel पूरी तरह लेने वाला attacker memory जितनी चाहे search करे, और protected domain credentials के actual hash “उस OS के अंदर” नहीं मिलते। यदि वह चल न रहा हो, पुराना खतरा रहता है, इसलिए लेख में आगे की confirmation methods के साथ पढ़ें।

तो वे कहाँ हैं? उत्तर है “उसी PC के अंदर बनाई गई दूसरी दुनिया”। भाग 1 में हमने देखा, host Windows hypervisor के ऊपर root partition में चलता है (“आपका Windows वास्तव में कहाँ चल रहा है?”)। यह लेख वहाँ से जारी रहता है और उसी partition के अंदर hypervisor द्वारा खींची गई एक और boundary line follow करता है।

भाग 2 जो सवाल हल करता है वह केवल एक है।

Windows उन secrets को कहाँ रखता है जिन्हें न Administrator पढ़ सकता है न kernel?

Target readers वे developers और operators हैं जिन्होंने settings screen या troubleshooting case में Core isolation, Memory integrity और Credential Guard जैसे शब्द देखे हैं, और actual चीज़ mechanism से समझना चाहते हैं। Prerequisites हैं x64 Windows 10/11 या current Windows Server (भाग 1 की तरह, rings और SLAT की चर्चा x64 मानती है; Arm64 exception levels जैसे अलग mechanism use करता है)। Required background भाग 1 में cover किए partitions और SLAT के concepts हैं। Difficulty intermediate है। उद्देश्य structure की व्याख्या है, security features configure करने का तरीका नहीं।

1. पहले निष्कर्ष

Windows ने VTL (Virtual Trust Level) नामक privilege axis जोड़ा और secrets VTL1 में रखे। VTL1 की memory VTL0 में चलते ordinary kernel से read नहीं की जा सकती। Boundary की रखवाली kernel स्वयं नहीं, बल्कि SLAT translation tables रखने वाला hypervisor करता है।

यही virtualization-based security (VBS) का skeleton है। VBS hypervisor से isolated environment बनाकर security features वहाँ रखती है। यह इस assumption पर design है कि kernel compromise होने पर भी isolated environment सुरक्षित रहता है।¹

flowchart TB
    accTitle: VBS द्वारा बनाई दो दुनियाएँ
    accDescr: VTL0 और VTL1 एक ही partition के अंदर बैठते हैं; VTL0 ordinary kernel और apps रखता है, VTL1 Secure Kernel और isolated security features, और hypervisor boundary की रखवाली करता है
    subgraph vtl0 ["VTL0（ordinary दुनिया）"]
        apps["apps（ring 3）"]
        ntk["NT kernel और drivers（ring 0）"]
    end
    subgraph vtl1 ["VTL1（isolated दुनिया）"]
        ium["isolated security features"]
        sk["Secure Kernel"]
    end
    hv["hypervisor（SLAT से boundary enforce）"] --- vtl0
    hv --- vtl1
    ntk -.->|read नहीं कर सकता| ium

चित्र 1: एक Windows के अंदर दो दुनियाएँ हैं, और VTL0 kernel VTL1 memory तक access नहीं कर सकता।

महत्त्वपूर्ण बिंदु यह है कि यह “दूसरा VM खड़ा करना” नहीं। VTL0 और VTL1 उसी partition के अंदर, उसी Windows के अंदर हैं। यह split कैसे साकार होता है इसे बारी-बारी देखेंगे।

2. Ring model की सीमाएँ — protector और protected एक ही height पर बैठते हैं

Traditional Windows security rings (privilege levels) की सीढ़ी पर बनी। User mode (ring 3) की रखवाली kernel mode (ring 0) करता है। तो ring 0 की रखवाली कौन करे — कोई नहीं कर सकता। Ring 0 highest privilege है।

इस structure की दो structural कमज़ोरियाँ हैं।

• Kernel monolithic नहीं। Ring 0 पर न केवल Windows स्वयं बल्कि बड़ी संख्या में third-party drivers चलते हैं। उनमें से किसी एक में vulnerability हो तो attacker ring 0 पर code execution पाता है।
• Ring 0 से सब दिखता है। LSASS जैसा user-mode process कितना भी अपनी रक्षा करे, उसकी memory kernel लेने वाले attacker के लिए freely readable है। Security attributes और page tables kernel स्वयं manage करता है।

flowchart TB
    accTitle: Traditional ring model में credential-theft path
    accDescr: Vulnerable driver से ring 0 लेने वाला attacker kernel के पूर्ण अधिकार से LSASS process memory पढ़ सकता है और password hash प्राप्त कर सकता है
    mal["attacker code"] -->|vulnerable driver का exploit| r0["ring 0 का control लेता"]
    r0 --> readall["सारी physical memory पढ़ सकता"]
    readall --> lsass["LSASS memory से hash पाता"]
    lsass --> lateral["अन्य machines पर lateral movement"]

चित्र 2: क्योंकि protector (kernel) और protected (secrets) एक ही height पर बैठते हैं, मूल कमज़ोरी यह है कि ring 0 गिरे तो सब गिरता है।

तो जो चाहिए वह है “ring 0 से ऊँचा स्थान”। वह स्थान भाग 1 में पहले आ चुका। Hypervisor kernel से ऊँचे privilege पर चलता है और CPU की memory-access permissions (SLAT) जल्दी exclusive control में लेता है। Hypervisor द्वारा रखवाली किया isolated region ring-0 (supervisor-mode) OS software की access के against भी सुरक्षित है।²

3. VSM और VTL — privilege की एक और axis जोड़ना

3.1. Virtual Trust Levels (VTL)

इस isolation देने वाली hypervisor features का परिवार VSM (Virtual Secure Mode) कहलाता है। VSM Device Guard, Credential Guard, virtual TPM आदि की foundation है।²

VSM की central concept VTL (Virtual Trust Level) है। मुख्य बिंदु इस प्रकार हैं।²

• VTL hierarchical हैं, और संख्या जितनी ऊँची, privilege उतना ऊँचा। VTL0 lowest है; VTL1 VTL0 से अधिक privileged है।
• Architecture में 16 levels तक defined हैं, पर currently implement दो हैं: VTL0 और VTL1।
• हर VTL की independent memory access protections हैं। ये protections hypervisor partition के physical address space के against manage करता है, इसलिए partition के अंदर system software उन्हें change नहीं कर सकता।
• Virtual processor प्रति VTL अलग register state और interrupt machinery रखता है, और lower VTL higher VTL की state नहीं झाँक सकता।

flowchart TB
    accTitle: VTL isolation बनाने वाली तीन स्वतंत्रताएँ
    accDescr: Memory access protections, virtual-processor register state और interrupt machinery प्रति VTL independent हैं, और lower VTL higher VTL में इनमें से किसी को नहीं छू सकता
    vtl["प्रति VTL क्या independent है"] --> m1["memory access protections"]
    vtl --> m2["virtual processor registers"]
    vtl --> m3["interrupt machinery"]
    m1 -.-> rule["lower VTL higher VTL नहीं छू सकता"]
    m2 -.-> rule
    m3 -.-> rule

चित्र 3: न केवल memory बल्कि CPU state और interrupts को भी अलग दुनिया बनाना वह तीन-टुकड़ा set है जिसमें झाँकने की window नहीं बचती।

यदि rings (0 और 3) वह axis हैं जो “OS और apps” अलग करती हैं, तो VTL दूसरी axis हैं जो “ordinary दुनिया और isolated दुनिया” अलग करती हैं। दोनों axes orthogonal हैं, और VTL1 के अंदर भी kernel mode और user mode हैं।

flowchart TB
    accTitle: Rings और VTL की दो axes से बने चार regions
    accDescr: Ring axis kernel mode और user mode अलग करती है, VTL axis ordinary दुनिया और isolated दुनिया, और combination चार regions देता है: ordinary apps, NT kernel, IUM trustlets, और Secure Kernel
    subgraph ax0 ["VTL0（ordinary दुनिया）"]
        a0["ring 3: ordinary apps"]
        k0["ring 0: NT kernel और drivers"]
    end
    subgraph ax1 ["VTL1（isolated दुनिया）"]
        a1["ring 3: IUM（trustlets）"]
        k1["ring 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

चित्र 4: अब privilege की दो axes हैं, और “क्या यह kernel है?” तथा “क्या यह isolated दुनिया है?” अलग सवाल बन गए।

3.2. Boundary का सार SLAT है

भाग 1 में हमने कहा कि guest physical addresses (GPA) को actual RAM (SPA) पर map करने वाली second-level translation tables — SLAT — hypervisor रखता है। VSM ठीक इसी property का उपयोग करता है। VTL isolation Hyper-V hypervisor और SLAT से बनता है।³

जब VTL1 घोषित करता है “यह memory VTL0 को नहीं दिखानी”, hypervisor VTL0 की translation tables से उस page की access permission गिरा देता है। उसके बाद, यदि VTL0 kernel उस address को छूने की कोशिश करे, तो उसे CPU के address-translation stage पर reject किया जाता है। Kernel अपनी page tables जितनी चाहे rewrite करे व्यर्थ। Page tables (GVA→GPA) kernel की हो सकती हैं, पर उसके आगे का translation (GPA→SPA) और अंतिम access permission hypervisor की हैं।

flowchart TB
    accTitle: VTL0 से VTL1 memory access reject होने का flow
    accDescr: जब VTL0 kernel VTL1 memory पढ़ने की कोशिश करता है, वह अपनी page tables पार कर सकता है पर SLAT access protection reject करती है, और control hypervisor को जाता है
    try["VTL0 kernel VTL1 page पढ़ने की कोशिश"] --> pt["kernel की अपनी page table पार"]
    pt --> slat{"SLAT access protection अनुमति दे?"}
    slat -->|अनुमति नहीं| deny["hypervisor intervene कर reject"]
    slat -->|अनुमति| ok["ordinary memory access"]
    deny -.-> point["उस layer पर सुरक्षित जिसे kernel change नहीं कर सकता"]

चित्र 5: Barrier kernel के बाहर बैठती है, और SLAT protections partition के अंदर software change नहीं कर सकता।

Memory series के भाग 1 में हमने लिखा कि “VAD, PTE और security attributes तय करते हैं कि access अनुमति है या नहीं”। VBS environment में इसे ऐसे व्यवस्थित कर सकते हैं: वे सब पार होने के बाद भी SLAT checkpoint अभी प्रतीक्षा में है।

3.3. Secure Kernel और IUM

VTL1 के अंदर जो चलता है वह ordinary NT kernel नहीं बल्कि Secure Kernel नामक छोटा kernel है। VTL1 में user mode IUM (Isolated User Mode) कहलाता है, और वहाँ चलने वाले programs trustlets (trusted processes) कहलाते हैं।³

Trustlet ordinary process की तरह सब कुछ नहीं कर सकता। अधिकांश system calls VTL0 पक्ष के NT kernel को marshal किए जाते हैं और काम वहाँ request होता है।³ VTL1 “सब कुछ कर सकने वाली ऊपरी दुनिया” नहीं; जानबूझकर छोटा बनाया गया secrets रखने वाला vault है। Vault में जितना कम code ला सकें, attack surface उतनी छोटी।

flowchart TB
    accTitle: Trustlet की system call का flow
    accDescr: VTL1 का trustlet अधिकांश system calls स्वयं नहीं सँभालता; उन्हें VTL0 NT kernel को marshal करता है और केवल result पाता है, जिससे VTL1 छोटा रहता है
    tl["trustlet（VTL1 में IUM）"] --> sc{"system call चाहिए"}
    sc -->|अधिकांश मामलों में| mar["request VTL0 NT kernel को marshal"]
    mar --> res["केवल result लौटता है"]
    res -.-> small["VTL1 छोटा रहता, attack surface सिकुड़ती"]

चित्र 6: Vault की अपनी सुविधाएँ नहीं; वह काम-काज बाहर सौंपता है और केवल secrets की रखवाली करता रहता है।

4. HVCI — vault में kernel code integrity validate करना

4.1. क्या validate हो रहा है

VBS पर बैठने वाली पहली representative feature Memory integrity है — HVCI (hypervisor-protected code integrity)। Windows के पास code-integrity mechanism है जो kernel-mode drivers और binaries start होने से पहले जाँचता है और unsigned या untrusted नहीं load करता। HVCI यह validation VBS के isolated environment के अंदर चलाता है।¹

Validation logic स्वयं VTL1 में ले जाने का कारण ठीक section 2 की कमज़ोरी है। यदि validation code VTL0 kernel के अंदर हो, तो kernel लेने वाला attacker validation बदल सकता है। यदि वह VTL1 में हो, तो बदलने वाला हाथ पहुँच नहीं सकता।

flowchart TB
    accTitle: Validation code कहाँ रहता है उससे अंतर
    accDescr: यदि validation code VTL0 kernel के अंदर हो तो kernel लेकर उसे disable किया जा सकता है, पर यदि वह VTL1 में हो तो kernel लेने वाला attacker भी नहीं पहुँच सकता और validation सुरक्षित रहता है
    atk["kernel लेने वाला attacker"] --> q{"code-integrity validation कहाँ है?"}
    q -->|"VTL0 kernel के अंदर（classic）"| bad["validation logic बदला जा सकता"]
    q -->|"VTL1 का isolated environment（HVCI）"| good["बदलना access से बाहर"]
    bad --> res1["unsigned code kernel में चल सकता"]
    good --> res2["kernel compromise के बाद भी validation चलता"]

चित्र 7: Checkpoint उस पक्ष के अंदर न रखें जो टूट सकता है — validation logic का वह relocation HVCI का सार है।

4.2. Executable pages के नियम

HVCI का प्रभाव “start पर inspection” तक सीमित नहीं। यह kernel-memory allocation भी constrain करता है।⁴

• Kernel page executable तभी बनता है जब code-integrity validation pass कर चुका हो।
• Executable page writable नहीं बनता (तथाकथित W^X)।

जब ये दोनों लागू हों, तो buffer overflow जैसी vulnerability kernel memory rewrite दे भी दे, rewritten content को execution में नहीं डाल सकते। Executable page rewrite नहीं हो सकता, और rewrite हो सकने वाला page execute नहीं हो सकता।⁴ Execute permission का अंतिम आधार SLAT पक्ष का execute right है, जिसे VTL0 kernel नहीं छेड़ सकता।

flowchart TB
    accTitle: HVCI environment में kernel page के executable बनने तक
    accDescr: Driver-load request VBS के isolated environment में code-integrity validation पाता है; pass करे तो executable, non-writable page के रूप में अनुमति, fail हो तो block और CodeIntegrity log में दर्ज
    load["kernel code load और execute request"] --> verify{"isolated environment में code-integrity validation"}
    verify -->|pass| exec["executable page अनुमति（write वर्जित）"]
    verify -->|fail| block["load block"]
    block --> log["CodeIntegrity Operational log（event ID 3087）"]
    exec -.-> wx["writable pages executable नहीं रहते"]

चित्र 8: Execute और write साथ न रहने देने वाले नियम का validation VTL1 पक्ष पर होता है, और VTL0 kernel उसे उलटा नहीं सकता।

Attacker की दृष्टि से इसे trace करें तो स्पष्ट होता है कि नियम कैसे प्रभावी होता है।

flowchart TB
    accTitle: HVCI environment में code injection fail होने का flow
    accDescr: Vulnerability kernel memory rewrite दे भी दे, जिसे लिख सके वह page executable नहीं, और executable page पहले से rewrite नहीं हो सकता, इसलिए injected code execution में नहीं डाला जा सकता
    inj["vulnerability से kernel memory छेड़ने की कोशिश"] --> which{"लक्ष्य कौन सा page?"}
    which -->|writable page| wok["write सफल"]
    which -->|executable page| xfail["write स्वयं असंभव"]
    wok --> nx["पर वह page executable नहीं"]
    nx --> dead["injected code execute नहीं हो सकता"]
    xfail --> dead

चित्र 9: Writable pages को runnable pages से न मिलाने का अर्थ यह है कि जिस entry से जाएँ, बंद गली मिलती है।

4.3. Driver compatibility की कीमत

यह नियम पुराने-design drivers से टकराता है। जो runtime पर अपना code rewrite करते हैं, जिनके signatures नहीं, या जो executable और writable दोनों memory माँगते हैं — ऐसे drivers HVCI environment में load नहीं हो सकते। Block की confirmation Event Viewer में Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational के अंतर्गत कर सकते हैं (event ID 3087 representative है)।⁵

“Memory integrity enable करने के बाद peripheral काम करना बंद कर गया” — कई मामलों में, परेशानी की actual पहचान यही है। उचित प्रतिक्रिया HVCI-compatible driver पर update है; Memory integrity disable करना security समग्र छोड़ने वाला last resort माना जाना चाहिए। यदि driver-development दृष्टि से इस validation में शामिल हैं, filter-driver लेख भी देखें (“Windows Minifilter Drivers”)।

flowchart TB
    accTitle: Memory integrity में peripheral बंद होने वाले cases अलग करना
    accDescr: CodeIntegrity Operational log में blocked driver पहचानें; उचित प्रतिक्रिया HVCI-compatible version पर update, न हो तो vendor से पूछें, और disable करना last resort मानें जिसे permanent न बनाएँ
    sym["Memory integrity enable करने के बाद device बंद"] --> log2["CodeIntegrity log में blocked driver"]
    log2 --> upd{"HVCI-compatible driver है?"}
    upd -->|हाँ| fix2["update कर HVCI ऑन रखते हल करें"]
    upd -->|नहीं| ask2["vendor से compatible version माँगें"]
    ask2 -.-> temp["disable करना last resort, permanent नहीं"]

चित्र 10: सबसे पहले settings screen नहीं बल्कि log देखें, और event ID 3087 जानता है कि load किसने रोका।

5. Credential Guard — hash LSAIso के अंदर हैं

5.1. LSASS और LSAIso

VBS पर बैठने वाली दूसरी representative feature शुरुआत के secret का उत्तर है: Credential Guard।

Traditional Windows NTLM hashes और Kerberos tickets LSA process (lsass.exe) की memory में रखता था। Credential Guard enable होने पर, इनमें से protected secrets का storage — domain credentials के NTLM hashes और Kerberos TGT (Ticket Granting Tickets) — LSAIso.exe में चला जाता है, VTL1 में IUM में चलने वाला trustlet।⁶

• lsass.exe (VTL0) पहले की तरह authentication processing का front desk चलाता रहता है।
• Actual secrets LSAIso.exe (VTL1) रखता है और VTL0 से access नहीं हो सकती।
• दोनों RPC (Remote Procedure Call) से संवाद करते हैं।
• LSAIso कोई device driver host नहीं करता, और केवल minimal signed binaries रखता है। Signatures उस certificate से validate होते हैं जिस पर VBS भरोसा करता है।⁶

flowchart TB
    accTitle: Credential Guard enable होने पर credentials कहाँ बैठते हैं
    accDescr: VTL0 का lsass authentication front desk के रूप में VTL1 के LSAIso से RPC संवाद करता है; protected domain credentials के actual hash और TGT LSAIso रखता है, इसलिए VTL0 में Administrator privileges पाकर lsass dump करने वाला attacker protected सार नहीं पाता
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe（authentication front desk）"]
        att["attacker（admin privileges）"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe（secrets का vault）"]
    end
    lsassP <-->|RPC| iso
    att -->|memory dump| lsassP
    att -.->|access नहीं| iso

चित्र 11: क्योंकि front desk और vault अलग हुए, lsass dump करने से protected domain credentials के actual hash नहीं मिलते।

Windows 11 version 22H2 से, उन devices पर जो license requirements (Enterprise E3/E5, Education A3/A5) और hardware requirements पूरी करते हैं, VBS और Credential Guard default से enable हैं। Pro जैसे editions पर Credential Guard automatically enable नहीं होता (exceptions हैं, जैसे जब योग्य license के अधीन enable मशीन बाद में downgrade हो)।⁷ शुरुआत का “playbook अब काम नहीं करती” special add-on product की कहानी नहीं; targeted editions पर current Windows की standard state है।

flowchart TB
    accTitle: Sign-in से authentication तक credentials का flow
    accDescr: Sign-in के बाद actual secrets VTL1 के LSAIso में store होते हैं; हर बार authentication चाहिए तो VTL0 का lsass RPC से computation request करता है, और protected long-term secrets स्वयं लौटाए बिना केवल authentication processing का result VTL0 पर आता है
    signin["user sign in करता"] --> front["lsass front desk के रूप में सँभालता"]
    front --> store["actual secrets LSAIso में store"]
    auth["बाद के authentication requests"] --> front
    front -->|"RPC से computation request"| store
    store -->|"result लौटाता（secret नहीं）"| front

चित्र 12: Protected long-term secrets स्वयं vault नहीं छोड़ते; VTL0 पर जो लौटता है वह authentication processing का result है, जैसे tickets।

5.2. ठीक जानें कि क्या protect नहीं है

Credential Guard all-purpose shield नहीं। जो protect है वह domain credentials के NTLM hashes, Kerberos TGT (Ticket Granting Tickets), और domain credentials के रूप में store की गई चीज़ें हैं। निम्नलिखित scope से बाहर हैं।⁸

• Kerberos service tickets (TGT protect हैं)
• Local accounts और Microsoft accounts के credentials
• Keylogger से input theft, और physical attacks
• NTLMv1, MS-CHAPv2, Digest या CredSSP use करने वाले paths के credentials
• अपने आप credentials manage करने वाले third-party software का internal भाग

साथ ही, Credential Guard enable होने पर NTLMv1, unconstrained Kerberos delegation आदि unusable हो जाते हैं, इसलिए legacy authentication पर निर्भर business systems को compatibility check चाहिए।⁸ “Enable करें और हो गया” नहीं, बल्कि protection boundary के अंदर और बाहर क्या है समझें और बाकी अन्य controls से भरें — व्यवहार में सही उपयोग यही है।

flowchart TB
    accTitle: Credential Guard की protection boundary
    accDescr: Domain NTLM hashes और TGT, तथा stored domain credentials protect हैं, जबकि service tickets, local accounts, keyloggers, physical attacks, और app द्वारा privately stored credentials scope से बाहर हैं
    scope{"यह secret protection boundary के किस पक्ष?"} --> inA["domain NTLM hashes और TGT"]
    scope --> outA["service tickets और local accounts"]
    inA --> prot["LSAIso में protect"]
    outA --> unprot["protect नहीं（अन्य controls चाहिए）"]
    unprot -.-> outB["keystrokes, physical attacks, app-private store भी बाहर"]

चित्र 13: Protection boundary स्पष्ट रेखा से खींची गई है, और रेखा के बाहर multi-factor authentication तथा app-side design से भरा जाता है।

6. स्वयं देखें

आप अपनी machine पर VBS और हर feature की running state confirm कर सकते हैं।

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

पढ़ने का तरीका इस प्रकार है।⁹

• यदि VirtualizationBasedSecurityStatus 2 हो, VBS enable है और चल रहा है।
• यदि SecurityServicesRunning में 1 हो, Credential Guard चल रहा है; यदि 2 हो, Memory integrity (HVCI) चल रहा है।

GUI में running state confirm करने के लिए, msinfo32 में “Virtualization-based security” field देखें (चल रही services listed होती हैं, जैसे “Hypervisor enforced Code Integrity”)। Windows Security app में “Device security > Core isolation” के अंतर्गत “Memory integrity” toggle setting reflect करने वाली screen है; enable करने के तुरंत बाद reboot की प्रतीक्षा, या start पर compatibility problem, के दौरान HVCI वास्तव में न चलते भी ऑन दिख सकता है — इसलिए चल रहा है या नहीं msinfo32 या Win32_DeviceGuard के SecurityServicesRunning से आँकें।⁵

Task Manager के Details tab पर भी निशान है। VBS चलते machine पर “Secure System” नामक process दिखेगा। LsaIso.exe वह process है जो Isolated LSA service VTL1 में host होने पर आता है, और normally केवल HVCI enable configuration में नहीं दिखता। Process की उपस्थिति या अनुपस्थिति केवल निशान है, इसलिए Credential Guard चल रहा है या नहीं ऊपर की तरह SecurityServicesRunning (1 शामिल है या नहीं) से आँकें। दोनों VTL0 से दिखने वाली windows हैं जो VTL1-पक्ष दुनिया से मेल खाती हैं।

flowchart TB
    accTitle: VBS-related features चल रही हैं कैसे check करें
    accDescr: Win32_DeviceGuard query से confirm करें कि VBS चल रहा है, Credential Guard और HVCI SecurityServicesRunning values से आँकें, और driver problems के लिए CodeIntegrity log देखें
    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: State confirmation तीन चरणों में आगे बढ़ती है: VBS स्वयं, उसके ऊपर हर service, और problem आने पर log।

7. व्यवहार में बचने वाली तीन गलत पढ़तें

7.1. “Administrator privileges सुरक्षित करना पर्याप्त है। VBS server-side की कहानी है”

Credential Guard जो रोकता है वह Administrator privileges लिए जाने के बाद नुकसान फैलना है (hash निकालना और lateral movement)। अर्थात् VBS compromise मानने वाली defense-in-depth की एक layer है, और प्रभावी client PC पर है। Requirements को पूरा करने वाले Windows 11 पर, default-से-enable standard है, इसलिए सही posture “हमसे संबंधित नहीं” नहीं बल्कि “पहले से चल रहा मानकर compatibility manage करें” है।

flowchart TB
    accTitle: Compromise के चरण और VBS कहाँ प्रभावी होता है
    accDescr: Initial access MFA और training जैसे अन्य controls cover करते हैं; HVCI privilege escalation के बाद kernel में code injection रोकता है; Credential Guard protected domain secrets की चोरी और lateral movement रोकता है, पर अपने scope से बाहर secrets तक नहीं पहुँचता
    s1["initial access（phishing आदि）"] --> s2["privilege escalation"]
    s2 --> s3["kernel में code injection"]
    s3 --> s4["protected domain secrets चोरी और lateral"]
    s1 -.-> d1["MFA, training और EDR cover करते"]
    s3 -.-> d2["HVCI यह चरण रोकता"]
    s4 -.-> d3["Credential Guard रोकता（protected secrets）"]

चित्र 15: VBS “अंदर न आने दें” technique नहीं; “अंदर आने के बाद जीतने न दें” technique है, और जिस चरण की रखवाली करती है वह अलग है।

7.2. “यदि Memory integrity समस्या करे, बस बंद कर दें”

बंद करने से फिलहाल काम चलेगा, पर kernel में code injection के against barrier समग्र गिर जाती है। उचित प्रतिक्रिया पहले CodeIntegrity log में blocked driver पहचानना और vendor का updated version apply करना है। यदि validation के लिए temporary disable करें, तो उस setting को permanent न बनाने वाला operation सुझाया जाता है।

7.3. “Credential Guard से passwords चोरी नहीं हो सकते”

वह protection boundary मिलाकर overconfidence है। Service tickets, local accounts, keystrokes स्वयं, और app द्वारा privately stored credentials scope से बाहर हैं।⁸ Phishing और keyloggers को अन्य controls चाहिए (multi-factor authentication, Windows Hello, और app पक्ष पर credential management की review)।

8. सारांश

• VBS hypervisor से isolated environment बनाता है और kernel compromise हो सकने की assumption पर security features protect करता है।¹
• Isolation की इकाई VTL है; currently दो levels implement हैं, VTL0 (ordinary दुनिया) और VTL1 (Secure Kernel और IUM)।²
• Boundary का सार SLAT memory access protection है, जिसे partition के अंदर software — kernel सहित — change नहीं कर सकता।²
• HVCI code-integrity validation isolated environment में चलाता है और “validation pass होने तक executable नहीं” तथा “executable page writable नहीं” लागू करता है।⁴ कीमत यह है कि driver compatibility manage करनी पड़ती है।⁵
• Credential Guard domain credentials के NTLM hashes और TGT को VTL1 के LSAIso में isolate करता है। Windows 11 22H2 से उन devices पर default से enable है जो license requirements (Enterprise, Education) और hardware requirements पूरी करते हैं (running state की जाँच के साथ उपयोग करें)।⁶⁷
• Running state Win32_DeviceGuard के SecurityServicesRunning से confirm कर सकते हैं (1 = Credential Guard, 2 = HVCI)।⁹

जारी भाग 3 में, “सेकंडों में boot होने वाली virtual machines — WSL2, Windows Sandbox और containers“।

अब तक हमने virtualization को “isolation की मज़बूती” पक्ष से देखा। अंतिम किस्त उलटी, “हल्केपन” पक्ष से देखती है, और follow करती है कि full VM का भार छोड़ने वाली lightweight VM कहाँ काट-छाँट कर रही हैं।

संबंधित लेख

• Windows Virtualization Internals (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? Hypervisor और partitions
• Windows Memory Internals (भाग 1) — Virtual address के physical RAM बनने का क्षण: page fault शुरू से अंत तक
• Windows I/O Internals (भाग 6, अंतिम) — Filter drivers और minifilters: Procmon और antivirus I/O क्यों रोक सकते हैं
• Windows error codes पढ़ना — Win32 Errors, HRESULT और NTSTATUS की तीन-layer structure

संबंधित परामर्श क्षेत्र

KomuraSoft LLC Windows applications और security features के बीच compatibility check, driver-related failures का analysis, और in-house PC environment का technical validation सँभालता है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• मौजूदा संपत्तियों का पुनरुपयोग और माइग्रेशन
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

क्या VBS (virtualization-based security) और Core isolation एक ही चीज़ हैं?

Strictly कहें तो अलग हैं। VBS वो foundation technology है जो hypervisor से isolated environment बनाती है, और Windows Security app में "Core isolation" उस screen का नाम है जो VBS पर बनी कई protections को group करती है। Representative है "Memory integrity", जो HVCI (hypervisor-protected code integrity) को कहता है। हर service की running state screen display से नहीं, Win32_DeviceGuard query से confirm करें।

क्या VTL1 memory सचमुच read नहीं की जा सकती, Administrator privileges या kernel driver से भी?

Read नहीं की जा सकती। Per-VTL memory access protections hypervisor partition के physical address space के against manage करता है, और partition के अंदर चलता software उन्हें change नहीं कर सकता। Kernel (ring 0) में चलने वाला code भी VTL0 से VTL1 memory तक access की अनुमति नहीं पाता।

Memory integrity (HVCI) enable करने से driver काम करना क्यों बंद कर सकता है?

HVCI environment में kernel page executable तभी बनता है जब वह integrity validation pass कर चुका हो, और executable pages पर write अनुमति नहीं। Unsigned driver, या executable memory rewrite करने वाला पुराने-design driver, यह constraint पूरी नहीं कर सकता और उसका load block होता है। Block CodeIntegrity Operational log (event ID 3087 आदि) में confirm कर सकते हैं।

Credential Guard क्या protect करता है, और क्या नहीं?

यह domain credentials के NTLM password hash, Kerberos TGT, और app ने domain credentials के रूप में जो store किया, उन्हें isolated environment में protect करता है। Kerberos service tickets, local accounts और Microsoft accounts के credentials, keylogger से input theft, और physical attacks scope से बाहर हैं।

VBS चल रहा है या नहीं कहाँ check करूँ?

msinfo32 में "Virtualization-based security" field देखें, या PowerShell से root/Microsoft/Windows/DeviceGuard namespace में Win32_DeviceGuard class query करें। यदि SecurityServicesRunning में 1 हो तो Credential Guard चल रहा है; यदि 2 हो तो Memory integrity (HVCI) चल रहा है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।