Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

एक समय था जब Windows पर हमलावर के लिए एडमिनिस्ट्रेटर विशेषाधिकार “लक्ष्य” थे। एडमिनिस्ट्रेटर के रूप में कर्नेल ड्राइवर लोड करें, LSASS प्रोसेस की मेमोरी डंप करें, और पासवर्ड हैश तथा Kerberos टिकट मिल जाते। वहाँ से चोरी किए हैश लेकर दूसरी मशीन तक चलना भर रह जाता।

वर्तमान Windows 11 पर Credential Guard चलते — 22H2 से उन डिवाइस पर डिफ़ॉल्ट अवस्था जो Enterprise और Education जैसी लाइसेंस आवश्यकताएँ तथा हार्डवेयर आवश्यकताएँ पूरी करते हैं — वह प्लेबुक काम नहीं करती। कर्नेल पूरी तरह लेने वाला हमलावर मेमोरी जितनी चाहे खोजे, और सुरक्षित डोमेन क्रेडेंशियल के वास्तविक हैश “उस OS के अंदर” नहीं मिलते। यदि वह चल न रहा हो, पुराना खतरा रहता है, इसलिए लेख में आगे की पुष्टि विधियों के साथ पढ़ें।

तो वे कहाँ हैं? उत्तर है “उसी PC के अंदर बनाई गई दूसरी दुनिया”। भाग 1 में हमने देखा, होस्ट Windows हाइपरवाइज़र के ऊपर रूट पार्टीशन में चलता है (“आपका Windows वास्तव में कहाँ चल रहा है?”)। यह लेख वहाँ से जारी रहता है और उसी पार्टीशन के अंदर हाइपरवाइज़र द्वारा खींची गई एक और सीमा रेखा अनुसरण करता है।

भाग 2 जो प्रश्न हल करता है वह केवल एक है।

Windows उन रहस्यों को कहाँ रखता है जिन्हें न एडमिनिस्ट्रेटर पढ़ सकता है न कर्नेल?

लक्षित पाठक वे डेवलपर और ऑपरेटर हैं जिन्होंने सेटिंग स्क्रीन या समस्या-निवारण मामले में Core isolation, Memory integrity और Credential Guard जैसे शब्द देखे हैं, और वास्तविक चीज़ तंत्र से समझना चाहते हैं। पूर्वापेक्षाएँ हैं x64 Windows 10/11 या वर्तमान Windows Server (भाग 1 की तरह, रिंग और SLAT की चर्चा x64 मानती है; Arm64 exception levels जैसे अलग तंत्र उपयोग करता है)। आवश्यक पृष्ठभूमि भाग 1 में कवर पार्टीशन और SLAT की अवधारणाएँ हैं। कठिनाई मध्यम है। उद्देश्य संरचना की व्याख्या है, सुरक्षा विशेषताएँ कॉन्फ़िगर करने का तरीका नहीं।

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

Windows ने VTL (Virtual Trust Level) नामक विशेषाधिकार अक्ष जोड़ा और रहस्य VTL1 में रखे। VTL1 की मेमोरी VTL0 में चलते साधारण कर्नेल से नहीं पढ़ी जा सकती। सीमा की रखवाली कर्नेल स्वयं नहीं, बल्कि SLAT अनुवाद तालिकाएँ रखने वाला हाइपरवाइज़र करता है।

यही वर्चुअलाइज़ेशन-आधारित सुरक्षा (VBS) का कंकाल है। VBS हाइपरवाइज़र से पृथक वातावरण बनाकर सुरक्षा विशेषताएँ वहाँ रखती है। यह इस धारणा पर डिज़ाइन है कि कर्नेल समझौता होने पर भी पृथक वातावरण सुरक्षित रहता है।¹

flowchart TB
    accTitle: VBS द्वारा बनाई दो दुनियाएँ
    accDescr: VTL0 और VTL1 एक ही पार्टीशन के अंदर बैठते हैं; VTL0 साधारण कर्नेल और ऐप रखता है, VTL1 Secure Kernel और पृथक सुरक्षा विशेषताएँ, और हाइपरवाइज़र सीमा की रखवाली करता है
    subgraph vtl0 ["VTL0（साधारण दुनिया）"]
        apps["ऐप（रिंग 3）"]
        ntk["NT कर्नेल और ड्राइवर（रिंग 0）"]
    end
    subgraph vtl1 ["VTL1（पृथक दुनिया）"]
        ium["पृथक सुरक्षा विशेषताएँ"]
        sk["Secure Kernel"]
    end
    hv["हाइपरवाइज़र（SLAT से सीमा लागू）"] --- vtl0
    hv --- vtl1
    ntk -.->|नहीं पढ़ सकता| ium

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

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

2. रिंग मॉडल की सीमाएँ — रक्षक और रक्षित एक ही ऊँचाई पर बैठते हैं

पारंपरिक Windows सुरक्षा रिंगों (विशेषाधिकार स्तरों) की सीढ़ी पर बनी। यूज़र मोड (रिंग 3) की रखवाली कर्नेल मोड (रिंग 0) करता है। तो रिंग 0 की रखवाली कौन करे — कोई नहीं कर सकता। रिंग 0 सर्वोच्च विशेषाधिकार है।

इस संरचना की दो संरचनात्मक कमज़ोरियाँ हैं।

• कर्नेल एकाश्म नहीं। रिंग 0 पर न केवल Windows स्वयं बल्कि बड़ी संख्या में तृतीय-पक्ष ड्राइवर चलते हैं। उनमें से किसी एक में भेद्यता हो तो हमलावर रिंग 0 पर कोड निष्पादन पाता है।
• रिंग 0 से सब दिखता है। LSASS जैसा यूज़र-मोड प्रोसेस कितना भी अपनी रक्षा करे, उसकी मेमोरी कर्नेल लेने वाले हमलावर के लिए स्वतंत्र पढ़ने योग्य है। सुरक्षा गुण और पेज तालिकाएँ कर्नेल स्वयं प्रबंधित करता है।

flowchart TB
    accTitle: पारंपरिक रिंग मॉडल में क्रेडेंशियल-चोरी पथ
    accDescr: भेद्य ड्राइवर से रिंग 0 लेने वाला हमलावर कर्नेल के पूर्ण अधिकार से LSASS प्रोसेस मेमोरी पढ़ सकता है और पासवर्ड हैश प्राप्त कर सकता है
    mal["हमलावर कोड"] -->|भेद्य ड्राइवर का शोषण| r0["रिंग 0 का नियंत्रण लेता"]
    r0 --> readall["सारी भौतिक मेमोरी पढ़ सकता"]
    readall --> lsass["LSASS मेमोरी से हैश पाता"]
    lsass --> lateral["अन्य मशीनों पर लेटरल मूवमेंट"]

चित्र 2: क्योंकि रक्षक (कर्नेल) और रक्षित (रहस्य) एक ही ऊँचाई पर बैठते हैं, मूल कमज़ोरी यह है कि रिंग 0 गिरे तो सब गिरता है।

तो जो चाहिए वह है “रिंग 0 से ऊँचा स्थान”। वह स्थान भाग 1 में पहले आ चुका। हाइपरवाइज़र कर्नेल से ऊँचे विशेषाधिकार पर चलता है और CPU की मेमोरी-पहुँच अनुमतियाँ (SLAT) जल्दी एकाधिकार में लेता है। हाइपरवाइज़र द्वारा रखवाली किया पृथक क्षेत्र रिंग-0 (सुपरवाइज़र-मोड) OS सॉफ़्टवेयर की पहुँच के विरुद्ध भी सुरक्षित है।²

3. VSM और VTL — विशेषाधिकार की एक और अक्ष जोड़ना

3.1. Virtual Trust Levels (VTL)

इस अलगाव देने वाली हाइपरवाइज़र विशेषताओं का परिवार VSM (Virtual Secure Mode) कहलाता है। VSM Device Guard, Credential Guard, वर्चुअल TPM आदि की बुनियाद है।²

VSM की केंद्रीय अवधारणा VTL (Virtual Trust Level) है। मुख्य बिंदु इस प्रकार हैं।²

• VTL पदानुक्रमित हैं, और संख्या जितनी ऊँची, विशेषाधिकार उतना ऊँचा। VTL0 निम्नतम है; VTL1 VTL0 से अधिक विशेषाधिकार प्राप्त है।
• वास्तुकला में 16 स्तर तक परिभाषित हैं, पर वर्तमान में लागू दो हैं: VTL0 और VTL1।
• हर VTL की स्वतंत्र मेमोरी पहुँच सुरक्षाएँ हैं। ये सुरक्षाएँ हाइपरवाइज़र पार्टीशन की भौतिक पता स्पेस के विरुद्ध प्रबंधित करता है, इसलिए पार्टीशन के अंदर सिस्टम सॉफ़्टवेयर उन्हें नहीं बदल सकता।
• वर्चुअल प्रोसेसर प्रति VTL अलग रजिस्टर अवस्था और इंटरप्ट मशीनरी रखता है, और निम्न VTL उच्च VTL की अवस्था नहीं झाँक सकता।

flowchart TB
    accTitle: VTL अलगाव बनाने वाली तीन स्वतंत्रताएँ
    accDescr: मेमोरी पहुँच सुरक्षाएँ, वर्चुअल-प्रोसेसर रजिस्टर अवस्था और इंटरप्ट मशीनरी प्रति VTL स्वतंत्र हैं, और निम्न VTL उच्च VTL में इनमें से किसी को नहीं छू सकता
    vtl["प्रति VTL क्या स्वतंत्र है"] --> m1["मेमोरी पहुँच सुरक्षाएँ"]
    vtl --> m2["वर्चुअल प्रोसेसर रजिस्टर"]
    vtl --> m3["इंटरप्ट मशीनरी"]
    m1 -.-> rule["निम्न VTL उच्च VTL नहीं छू सकता"]
    m2 -.-> rule
    m3 -.-> rule

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

यदि रिंग (0 और 3) वह अक्ष हैं जो “OS और ऐप” अलग करती हैं, तो VTL दूसरी अक्ष हैं जो “साधारण दुनिया और पृथक दुनिया” अलग करती हैं। दोनों अक्ष ऑर्थोगोनल हैं, और VTL1 के अंदर भी कर्नेल मोड और यूज़र मोड हैं।

flowchart TB
    accTitle: रिंग और VTL की दो अक्षों से बने चार क्षेत्र
    accDescr: रिंग अक्ष कर्नेल मोड और यूज़र मोड अलग करती है, VTL अक्ष साधारण दुनिया और पृथक दुनिया, और संयोजन चार क्षेत्र देता है: साधारण ऐप, NT कर्नेल, IUM ट्रस्टलेट, और Secure Kernel
    subgraph ax0 ["VTL0（साधारण दुनिया）"]
        a0["रिंग 3: साधारण ऐप"]
        k0["रिंग 0: NT कर्नेल और ड्राइवर"]
    end
    subgraph ax1 ["VTL1（पृथक दुनिया）"]
        a1["रिंग 3: IUM（ट्रस्टलेट）"]
        k1["रिंग 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

चित्र 4: अब विशेषाधिकार की दो अक्षें हैं, और “क्या यह कर्नेल है?” तथा “क्या यह पृथक दुनिया है?” अलग प्रश्न बन गए।

3.2. सीमा का सार SLAT है

भाग 1 में हमने कहा कि गेस्ट भौतिक पते (GPA) को वास्तविक RAM (SPA) पर मैप करने वाली द्वितीय-स्तर अनुवाद तालिकाएँ — SLAT — हाइपरवाइज़र रखता है। VSM ठीक इसी गुण का उपयोग करता है। VTL अलगाव Hyper-V हाइपरवाइज़र और SLAT से बनता है।³

जब VTL1 घोषित करता है “यह मेमोरी VTL0 को नहीं दिखानी”, हाइपरवाइज़र VTL0 की अनुवाद तालिकाओं से उस पेज की पहुँच अनुमति गिरा देता है। उसके बाद, यदि VTL0 कर्नेल उस पते को छूने की कोशिश करे, तो उसे CPU के पता-अनुवाद चरण पर अस्वीकार किया जाता है। कर्नेल अपनी पेज तालिकाएँ जितनी चाहे पुनर्लेखन करे व्यर्थ। पेज तालिकाएँ (GVA→GPA) कर्नेल की हो सकती हैं, पर उसके आगे का अनुवाद (GPA→SPA) और अंतिम पहुँच अनुमति हाइपरवाइज़र की हैं।

flowchart TB
    accTitle: VTL0 से VTL1 मेमोरी पहुँच अस्वीकार होने का प्रवाह
    accDescr: जब VTL0 कर्नेल VTL1 मेमोरी पढ़ने की कोशिश करता है, वह अपनी पेज तालिका पार कर सकता है पर SLAT पहुँच सुरक्षा अस्वीकार करती है, और नियंत्रण हाइपरवाइज़र को जाता है
    try["VTL0 कर्नेल VTL1 पेज पढ़ने की कोशिश"] --> pt["कर्नेल की अपनी पेज तालिका पार"]
    pt --> slat{"SLAT पहुँच सुरक्षा अनुमति दे?"}
    slat -->|अनुमति नहीं| deny["हाइपरवाइज़र हस्तक्षेप कर अस्वीकार"]
    slat -->|अनुमति| ok["साधारण मेमोरी पहुँच"]
    deny -.-> point["उस परत पर सुरक्षित जिसे कर्नेल नहीं बदल सकता"]

चित्र 5: बाधा कर्नेल के बाहर बैठती है, और SLAT सुरक्षाएँ पार्टीशन के अंदर सॉफ़्टवेयर नहीं बदल सकता।

मेमोरी श्रृंखला के भाग 1 में हमने लिखा कि “VAD, PTE और सुरक्षा गुण तय करते हैं कि पहुँच अनुमति है या नहीं”। VBS वातावरण में इसे ऐसे व्यवस्थित कर सकते हैं: वे सब पार होने के बाद भी SLAT चौकी अभी प्रतीक्षा में है।

3.3. Secure Kernel और IUM

VTL1 के अंदर जो चलता है वह साधारण NT कर्नेल नहीं बल्कि Secure Kernel नामक छोटा कर्नेल है। VTL1 में यूज़र मोड IUM (Isolated User Mode) कहलाता है, और वहाँ चलने वाले प्रोग्राम ट्रस्टलेट (विश्वसनीय प्रोसेस) कहलाते हैं।³

ट्रस्टलेट साधारण प्रोसेस की तरह सब कुछ नहीं कर सकता। अधिकांश सिस्टम कॉल VTL0 पक्ष के NT कर्नेल को मार्शल किए जाते हैं और काम वहाँ अनुरोधित होता है।³ VTL1 “सब कुछ कर सकने वाली ऊपरी दुनिया” नहीं; जानबूझकर छोटा बनाया गया रहस्य रखने वाला तिजोरी है। तिजोरी में जितना कम कोड ला सकें, हमला-सतह उतनी छोटी।

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

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

4. HVCI — तिजोरी में कर्नेल कोड अखंडता सत्यापित करना

4.1. क्या सत्यापित हो रहा है

VBS पर बैठने वाली पहली प्रतिनिधि विशेषता Memory integrity है — HVCI (hypervisor-protected code integrity)। Windows के पास कोड-अखंडता तंत्र है जो कर्नेल-मोड ड्राइवर और बाइनरी शुरू होने से पहले जाँचता है और अहस्ताक्षरित या अविश्वसनीय नहीं लोड करता। HVCI यह सत्यापन VBS के पृथक वातावरण के अंदर चलाता है।¹

सत्यापन तर्क स्वयं VTL1 में ले जाने का कारण ठीक धारा 2 की कमज़ोरी है। यदि सत्यापन कोड VTL0 कर्नेल के अंदर हो, तो कर्नेल लेने वाला हमलावर सत्यापन बदल सकता है। यदि वह VTL1 में हो, तो बदलने वाला हाथ पहुँच नहीं सकता।

flowchart TB
    accTitle: सत्यापन कोड कहाँ रहता है उससे अंतर
    accDescr: यदि सत्यापन कोड VTL0 कर्नेल के अंदर हो तो कर्नेल लेकर उसे अक्षम किया जा सकता है, पर यदि वह VTL1 में हो तो कर्नेल लेने वाला हमलावर भी नहीं पहुँच सकता और सत्यापन सुरक्षित रहता है
    atk["कर्नेल लेने वाला हमलावर"] --> q{"कोड-अखंडता सत्यापन कहाँ है?"}
    q -->|"VTL0 कर्नेल के अंदर（क्लासिक）"| bad["सत्यापन तर्क बदला जा सकता"]
    q -->|"VTL1 का पृथक वातावरण（HVCI）"| good["बदलना पहुँच से बाहर"]
    bad --> res1["अहस्ताक्षरित कोड कर्नेल में चल सकता"]
    good --> res2["कर्नेल समझौता के बाद भी सत्यापन चलता"]

चित्र 7: चौकी उस पक्ष के अंदर न रखें जो टूट सकता है — सत्यापन तर्क का वह स्थानांतरण HVCI का सार है।

4.2. निष्पादन योग्य पेजों के नियम

HVCI का प्रभाव “प्रारंभ पर निरीक्षण” तक सीमित नहीं। यह कर्नेल-मेमोरी आवंटन भी बाधित करता है।⁴

• कर्नेल पेज निष्पादन योग्य तभी बनता है जब कोड-अखंडता सत्यापन पार कर चुका हो।
• निष्पादन योग्य पेज लेखन योग्य नहीं बनता (तथाकथित W^X)।

जब ये दोनों लागू हों, तो बफ़र ओवरफ़्लो जैसी भेद्यता कर्नेल मेमोरी पुनर्लेखन दे भी दे, पुनर्लेखित सामग्री को निष्पादन में नहीं डाल सकते। निष्पादन योग्य पेज पुनर्लेखित नहीं हो सकता, और पुनर्लेखित हो सकने वाला पेज निष्पादित नहीं हो सकता।⁴ निष्पादन अनुमति का अंतिम आधार SLAT पक्ष का निष्पादन अधिकार है, जिसे VTL0 कर्नेल नहीं छेड़ सकता।

flowchart TB
    accTitle: HVCI वातावरण में कर्नेल पेज के निष्पादन योग्य बनने तक
    accDescr: ड्राइवर-लोड अनुरोध VBS के पृथक वातावरण में कोड-अखंडता सत्यापन पाता है; पार करे तो निष्पादन योग्य, गैर-लेखन पेज के रूप में अनुमति, विफल हो तो अवरुद्ध और CodeIntegrity लॉग में दर्ज
    load["कर्नेल कोड लोड और निष्पादन अनुरोध"] --> verify{"पृथक वातावरण में कोड-अखंडता सत्यापन"}
    verify -->|पार| exec["निष्पादन योग्य पेज अनुमति（लेखन वर्जित）"]
    verify -->|विफल| block["लोड अवरुद्ध"]
    block --> log["CodeIntegrity Operational लॉग（इवेंट ID 3087）"]
    exec -.-> wx["लेखन योग्य पेज निष्पादन योग्य नहीं रहते"]

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

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

flowchart TB
    accTitle: HVCI वातावरण में कोड इंजेक्शन विफल होने का प्रवाह
    accDescr: भेद्यता कर्नेल मेमोरी पुनर्लेखन दे भी दे, जिसे लिख सके वह पेज निष्पादन योग्य नहीं, और निष्पादन योग्य पेज पहले से पुनर्लेखित नहीं हो सकता, इसलिए इंजेक्टेड कोड निष्पादन में नहीं डाला जा सकता
    inj["भेद्यता से कर्नेल मेमोरी छेड़ने की कोशिश"] --> which{"लक्ष्य कौन सा पेज?"}
    which -->|लेखन योग्य पेज| wok["लेखन सफल"]
    which -->|निष्पादन योग्य पेज| xfail["लेखन स्वयं असंभव"]
    wok --> nx["पर वह पेज निष्पादन योग्य नहीं"]
    nx --> dead["इंजेक्टेड कोड निष्पादित नहीं हो सकता"]
    xfail --> dead

चित्र 9: लेखन योग्य पेजों को चलने योग्य पेजों से न मिलाने का अर्थ यह है कि जिस प्रवेश से जाएँ, बंद गली मिलती है।

4.3. ड्राइवर संगतता की कीमत

यह नियम पुराने-डिज़ाइन ड्राइवरों से टकराता है। जो रन टाइम पर अपना कोड पुनर्लेखन करते हैं, जिनके हस्ताक्षर नहीं, या जो निष्पादन योग्य और लेखन योग्य दोनों मेमोरी माँगते हैं — ऐसे ड्राइवर HVCI वातावरण में लोड नहीं हो सकते। अवरोध की पुष्टि Event Viewer में Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational के अंतर्गत कर सकते हैं (इवेंट ID 3087 प्रतिनिधि है)।⁵

“Memory integrity सक्षम करने के बाद परिधीय काम करना बंद कर गया” — कई मामलों में, परेशानी की वास्तविक पहचान यही है। उचित प्रतिक्रिया HVCI-संगत ड्राइवर पर अद्यतन है; Memory integrity अक्षम करना सुरक्षा समग्र छोड़ने वाला अंतिम उपाय माना जाना चाहिए। यदि ड्राइवर-विकास दृष्टि से इस सत्यापन में शामिल हैं, फ़िल्टर-ड्राइवर लेख भी देखें (“Windows Minifilter Drivers”)।

flowchart TB
    accTitle: Memory integrity में परिधीय बंद होने वाले मामले अलग करना
    accDescr: CodeIntegrity Operational लॉग में अवरुद्ध ड्राइवर पहचानें; उचित प्रतिक्रिया HVCI-संगत संस्करण पर अद्यतन, न हो तो विक्रेता से पूछें, और अक्षम करना अंतिम उपाय मानें जिसे स्थायी न बनाएँ
    sym["Memory integrity सक्षम करने के बाद डिवाइस बंद"] --> log2["CodeIntegrity लॉग में अवरुद्ध ड्राइवर"]
    log2 --> upd{"HVCI-संगत ड्राइवर है?"}
    upd -->|हाँ| fix2["अद्यतन कर HVCI ऑन रखते हल करें"]
    upd -->|नहीं| ask2["विक्रेता से संगत संस्करण माँगें"]
    ask2 -.-> temp["अक्षम करना अंतिम उपाय, स्थायी नहीं"]

चित्र 10: सबसे पहले सेटिंग स्क्रीन नहीं बल्कि लॉग देखें, और इवेंट ID 3087 जानता है कि लोड किसने रोका।

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

5.1. LSASS और LSAIso

VBS पर बैठने वाली दूसरी प्रतिनिधि विशेषता प्रारंभ के रहस्य का उत्तर है: Credential Guard।

पारंपरिक Windows NTLM हैश और Kerberos टिकट LSA प्रोसेस (lsass.exe) की मेमोरी में रखता था। Credential Guard सक्षम होने पर, इनमें से सुरक्षित रहस्यों का संग्रहण — डोमेन क्रेडेंशियल के NTLM हैश और Kerberos TGT (Ticket Granting Tickets) — LSAIso.exe में चला जाता है, VTL1 में IUM में चलने वाला ट्रस्टलेट।⁶

• lsass.exe (VTL0) पहले की तरह प्रमाणीकरण प्रोसेसिंग का फ्रंट डेस्क चलाता रहता है।
• वास्तविक रहस्य LSAIso.exe (VTL1) रखता है और VTL0 से पहुँच नहीं हो सकती।
• दोनों RPC (Remote Procedure Call) से संवाद करते हैं।
• LSAIso कोई डिवाइस ड्राइवर होस्ट नहीं करता, और केवल न्यूनतम हस्ताक्षरित बाइनरी रखता है। हस्ताक्षर उस प्रमाणपत्र से सत्यापित होते हैं जिस पर VBS भरोसा करता है।⁶

flowchart TB
    accTitle: Credential Guard सक्षम होने पर क्रेडेंशियल कहाँ बैठते हैं
    accDescr: VTL0 का lsass प्रमाणीकरण फ्रंट डेस्क के रूप में VTL1 के LSAIso से RPC संवाद करता है; सुरक्षित डोमेन क्रेडेंशियल के वास्तविक हैश और TGT LSAIso रखता है, इसलिए VTL0 में एडमिनिस्ट्रेटर विशेषाधिकार पाकर lsass डंप करने वाला हमलावर सुरक्षित सार नहीं पाता
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe（प्रमाणीकरण फ्रंट डेस्क）"]
        att["हमलावर（एडमिन विशेषाधिकार）"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe（रहस्यों की तिजोरी）"]
    end
    lsassP <-->|RPC| iso
    att -->|मेमोरी डंप| lsassP
    att -.->|पहुँच नहीं| iso

चित्र 11: क्योंकि फ्रंट डेस्क और तिजोरी अलग हुए, lsass डंप करने से सुरक्षित डोमेन क्रेडेंशियल के वास्तविक हैश नहीं मिलते।

Windows 11 संस्करण 22H2 से, उन डिवाइस पर जो लाइसेंस आवश्यकताएँ (Enterprise E3/E5, Education A3/A5) और हार्डवेयर आवश्यकताएँ पूरी करते हैं, VBS और Credential Guard डिफ़ॉल्ट से सक्षम हैं। Pro जैसे संस्करणों पर Credential Guard स्वतः सक्षम नहीं होता (अपवाद हैं, जैसे जब योग्य लाइसेंस के अधीन सक्षम मशीन बाद में डाउनग्रेड हो)।⁷ प्रारंभ का “प्लेबुक अब काम नहीं करती” विशेष ऐड-ऑन उत्पाद की कहानी नहीं; लक्षित संस्करणों पर वर्तमान Windows की मानक अवस्था है।

flowchart TB
    accTitle: साइन-इन से प्रमाणीकरण तक क्रेडेंशियल का प्रवाह
    accDescr: साइन-इन के बाद वास्तविक रहस्य VTL1 के LSAIso में संग्रहीत होते हैं; हर बार प्रमाणीकरण चाहिए तो VTL0 का lsass RPC से गणना अनुरोध करता है, और सुरक्षित दीर्घकालिक रहस्य स्वयं लौटाए बिना केवल प्रमाणीकरण प्रोसेसिंग का परिणाम VTL0 पर आता है
    signin["उपयोगकर्ता साइन इन करता"] --> front["lsass फ्रंट डेस्क के रूप में सँभालता"]
    front --> store["वास्तविक रहस्य LSAIso में संग्रहीत"]
    auth["बाद के प्रमाणीकरण अनुरोध"] --> front
    front -->|"RPC से गणना अनुरोध"| store
    store -->|"परिणाम लौटाता（रहस्य नहीं）"| front

चित्र 12: सुरक्षित दीर्घकालिक रहस्य स्वयं तिजोरी नहीं छोड़ते; VTL0 पर जो लौटता है वह प्रमाणीकरण प्रोसेसिंग का परिणाम है, जैसे टिकट।

5.2. ठीक जानें कि क्या सुरक्षित नहीं है

Credential Guard सर्व-उद्देश्य ढाल नहीं। जो सुरक्षित है वह डोमेन क्रेडेंशियल के NTLM हैश, Kerberos TGT (Ticket Granting Tickets), और डोमेन क्रेडेंशियल के रूप में संग्रहीत चीज़ें हैं। निम्नलिखित दायरे से बाहर हैं।⁸

• Kerberos सेवा टिकट (TGT सुरक्षित हैं)
• स्थानीय खातों और Microsoft खातों के क्रेडेंशियल
• कीलॉगर से इनपुट चोरी, और भौतिक हमले
• NTLMv1, MS-CHAPv2, Digest या CredSSP उपयोग करने वाले पथों के क्रेडेंशियल
• अपने आप क्रेडेंशियल प्रबंधित करने वाले तृतीय-पक्ष सॉफ़्टवेयर का आंतरिक भाग

साथ ही, Credential Guard सक्षम होने पर NTLMv1, अबाधित Kerberos डेलीगेशन आदि अनुपयोगी हो जाते हैं, इसलिए लेगेसी प्रमाणीकरण पर निर्भर व्यावसायिक प्रणालियों को संगतता जाँच चाहिए।⁸ “सक्षम करें और हो गया” नहीं, बल्कि रक्षा सीमा के अंदर और बाहर क्या है समझें और बाकी अन्य नियंत्रणों से भरें — व्यवहार में सही उपयोग यही है।

flowchart TB
    accTitle: Credential Guard की रक्षा सीमा
    accDescr: डोमेन NTLM हैश और TGT, तथा संग्रहीत डोमेन क्रेडेंशियल सुरक्षित हैं, जबकि सेवा टिकट, स्थानीय खाते, कीलॉगर, भौतिक हमले, और ऐप द्वारा निजी संग्रहीत क्रेडेंशियल दायरे से बाहर हैं
    scope{"यह रहस्य सुरक्षा सीमा के किस पक्ष?"} --> inA["डोमेन NTLM हैश और TGT"]
    scope --> outA["सेवा टिकट और स्थानीय खाते"]
    inA --> prot["LSAIso में सुरक्षित"]
    outA --> unprot["सुरक्षित नहीं（अन्य नियंत्रण चाहिए）"]
    unprot -.-> outB["कीस्ट्रोक्स, भौतिक हमले, ऐप-निजी स्टोर भी बाहर"]

चित्र 13: रक्षा सीमा स्पष्ट रेखा से खींची गई है, और रेखा के बाहर बहु-कारक प्रमाणीकरण तथा ऐप-पक्ष डिज़ाइन से भरा जाता है।

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

आप अपनी मशीन पर VBS और हर विशेषता की चलने अवस्था पुष्टि कर सकते हैं।

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

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

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

GUI में चलने अवस्था पुष्टि के लिए, msinfo32 में “Virtualization-based security” फ़ील्ड देखें (चल रही सेवाएँ सूचीबद्ध होती हैं, जैसे “Hypervisor enforced Code Integrity”)। Windows Security ऐप में “Device security > Core isolation” के अंतर्गत “Memory integrity” टॉगल सेटिंग प्रतिबिंबित करने वाली स्क्रीन है; सक्षम करने के तुरंत बाद रीबूट की प्रतीक्षा, या प्रारंभ पर संगतता समस्या, के दौरान HVCI वास्तव में न चलते भी ऑन दिख सकता है — इसलिए चल रहा है या नहीं msinfo32 या Win32_DeviceGuard के SecurityServicesRunning से आँकें।⁵

Task Manager के Details टैब पर भी निशान है। VBS चलते मशीन पर “Secure System” नामक प्रोसेस दिखेगा। LsaIso.exe वह प्रोसेस है जो Isolated LSA सेवा VTL1 में होस्ट होने पर आता है, और सामान्यतः केवल HVCI सक्षम कॉन्फ़िगरेशन में नहीं दिखता। प्रोसेस की उपस्थिति या अनुपस्थिति केवल निशान है, इसलिए Credential Guard चल रहा है या नहीं ऊपर की तरह SecurityServicesRunning (1 शामिल है या नहीं) से आँकें। दोनों VTL0 से दिखने वाली खिड़कियाँ हैं जो VTL1-पक्ष दुनिया से मेल खाती हैं।

flowchart TB
    accTitle: VBS-संबंधित विशेषताएँ चल रही हैं कैसे जाँचें
    accDescr: Win32_DeviceGuard क्वेरी से पुष्टि करें कि VBS चल रहा है, Credential Guard और HVCI SecurityServicesRunning मानों से आँकें, और ड्राइवर समस्याओं के लिए CodeIntegrity लॉग देखें
    q0["Win32_DeviceGuard"] --> q1{"VBS Status 2?"}
    q1 -->|नहीं| off["VBS नहीं चल रहा"]
    q1 -->|हाँ| q2{"1 या 2 शामिल?"}
    q2 -->|1| cg["Credential Guard ऑन"]
    q2 -->|2| hvciR["HVCI ऑन"]
    hvciR -.-> ev["CodeIntegrity 3087"]

चित्र 14: अवस्था पुष्टि तीन चरणों में आगे बढ़ती है: VBS स्वयं, उसके ऊपर हर सेवा, और समस्या आने पर लॉग।

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

7.1. “एडमिनिस्ट्रेटर विशेषाधिकार सुरक्षित करना पर्याप्त है। VBS सर्वर-पक्ष की कहानी है”

Credential Guard जो रोकता है वह एडमिनिस्ट्रेटर विशेषाधिकार लिए जाने के बाद नुकसान फैलना है (हैश निकालना और लेटरल मूवमेंट)। अर्थात् VBS समझौता मानने वाली रक्षा-गहराई की एक परत है, और प्रभावी क्लाइंट PC पर है। आवश्यकताओं को पूरा करने वाले Windows 11 पर, डिफ़ॉल्ट-से-सक्षम मानक है, इसलिए सही मुद्रा “हमसे संबंधित नहीं” नहीं बल्कि “पहले से चल रहा मानकर संगतता प्रबंधित करें” है।

flowchart TB
    accTitle: समझौते के चरण और VBS कहाँ प्रभावी होता है
    accDescr: प्रारंभिक पहुँच बहु-कारक प्रमाणीकरण और प्रशिक्षण जैसे अन्य नियंत्रण कवर करते हैं; HVCI विशेषाधिकार वृद्धि के बाद कर्नेल में कोड इंजेक्शन रोकता है; Credential Guard सुरक्षित डोमेन रहस्यों की चोरी और लेटरल मूवमेंट रोकता है, पर अपने दायरे से बाहर रहस्यों तक नहीं पहुँचता
    s1["प्रारंभिक पहुँच（फ़िशिंग आदि）"] --> s2["विशेषाधिकार वृद्धि"]
    s2 --> s3["कर्नेल में कोड इंजेक्शन"]
    s3 --> s4["सुरक्षित डोमेन रहस्य चोरी और लेटरल"]
    s1 -.-> d1["MFA, प्रशिक्षण और EDR कवर करते"]
    s3 -.-> d2["HVCI यह चरण रोकता"]
    s4 -.-> d3["Credential Guard रोकता（सुरक्षित रहस्य）"]

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

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

बंद करने से फिलहाल काम चलेगा, पर कर्नेल में कोड इंजेक्शन के विरुद्ध बाधा समग्र गिर जाती है। उचित प्रतिक्रिया पहले CodeIntegrity लॉग में अवरुद्ध ड्राइवर पहचानना और विक्रेता का अद्यतन संस्करण लागू करना है। यदि सत्यापन के लिए अस्थायी अक्षम करें, तो उस सेटिंग को स्थायी न बनाने वाला संचालन सुझाया जाता है।

7.3. “Credential Guard से पासवर्ड चोरी नहीं हो सकते”

वह रक्षा सीमा मिलाकर अतिविश्वास है। सेवा टिकट, स्थानीय खाते, कीस्ट्रोक्स स्वयं, और ऐप द्वारा निजी संग्रहीत क्रेडेंशियल दायरे से बाहर हैं।⁸ फ़िशिंग और कीलॉगर को अन्य नियंत्रण चाहिए (बहु-कारक प्रमाणीकरण, Windows Hello, और ऐप पक्ष पर क्रेडेंशियल प्रबंधन की समीक्षा)।

8. सारांश

• VBS हाइपरवाइज़र से पृथक वातावरण बनाता है और कर्नेल समझौता हो सकने की धारणा पर सुरक्षा विशेषताएँ सुरक्षित करता है।¹
• अलगाव की इकाई VTL है; वर्तमान में दो स्तर लागू हैं, VTL0 (साधारण दुनिया) और VTL1 (Secure Kernel और IUM)।²
• सीमा का सार SLAT मेमोरी पहुँच सुरक्षा है, जिसे पार्टीशन के अंदर सॉफ़्टवेयर — कर्नेल सहित — नहीं बदल सकता।²
• HVCI कोड-अखंडता सत्यापन पृथक वातावरण में चलाता है और “सत्यापन पार होने तक निष्पादन योग्य नहीं” तथा “निष्पादन योग्य पेज लेखन योग्य नहीं” लागू करता है।⁴ कीमत यह है कि ड्राइवर संगतता प्रबंधित करनी पड़ती है।⁵
• Credential Guard डोमेन क्रेडेंशियल के NTLM हैश और TGT को VTL1 के LSAIso में अलग करता है। Windows 11 22H2 से उन डिवाइस पर डिफ़ॉल्ट से सक्षम है जो लाइसेंस आवश्यकताएँ (Enterprise, Education) और हार्डवेयर आवश्यकताएँ पूरी करते हैं (चलने अवस्था की जाँच के साथ उपयोग करें)।⁶⁷
• चलने अवस्था Win32_DeviceGuard के SecurityServicesRunning से पुष्टि कर सकते हैं (1 = Credential Guard, 2 = HVCI)।⁹

जारी भाग 3 में, “सेकंडों में बूट होने वाली वर्चुअल मशीनें — WSL2, Windows Sandbox और कंटेनर“।

अब तक हमने वर्चुअलाइज़ेशन को “अलगाव की मज़बूती” पक्ष से देखा। अंतिम किस्त उलटी, “हल्केपन” पक्ष से देखती है, और अनुसरण करती है कि पूर्ण VM का भार छोड़ने वाली हल्की VM कहाँ काट-छाँट कर रही हैं।

संबंधित लेख

• Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन
• Windows मेमोरी की गहराई (भाग 1) — वर्चुअल पता के भौतिक RAM बनने का क्षण: पेज फ़ॉल्ट शुरू से अंत तक
• Windows I/O की गहराई (भाग 6, अंतिम) — फ़िल्टर ड्राइवर और मिनिफ़िल्टर: Procmon और एंटीवायरस I/O क्यों रोक सकते हैं
• Windows त्रुटि कोड पढ़ना — Win32 Errors, HRESULT और NTSTATUS की तीन-परत संरचना

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

KomuraSoft LLC Windows ऐप्लिकेशन और सुरक्षा विशेषताओं के बीच संगतता जाँच, ड्राइवर-जनित विफलताओं का विश्लेषण, और इन-हाउस PC वातावरण का तकनीकी सत्यापन सँभालता है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

क्या VBS (वर्चुअलाइज़ेशन-आधारित सुरक्षा) और Core isolation एक ही चीज़ हैं?

सख्ती से कहें तो अलग हैं। VBS वह बुनियादी तकनीक है जो हाइपरवाइज़र से पृथक वातावरण बनाती है, और Windows Security ऐप में "Core isolation" उस स्क्रीन का नाम है जो VBS पर बनी कई सुरक्षाओं को समूहित करती है। प्रतिनिधि है "Memory integrity", जो HVCI (hypervisor-protected code integrity) को कहता है। हर सेवा की चलने अवस्था स्क्रीन प्रदर्शन से नहीं, Win32_DeviceGuard क्वेरी से पुष्टि करें।

क्या VTL1 मेमोरी सचमुच नहीं पढ़ी जा सकती, एडमिनिस्ट्रेटर विशेषाधिकार या कर्नेल ड्राइवर से भी?

नहीं पढ़ी जा सकती। प्रति-VTL मेमोरी पहुँच सुरक्षाएँ हाइपरवाइज़र पार्टीशन की भौतिक पता स्पेस के विरुद्ध प्रबंधित करता है, और पार्टीशन के अंदर चलता सॉफ़्टवेयर उन्हें नहीं बदल सकता। कर्नेल (रिंग 0) में चलने वाला कोड भी VTL0 से VTL1 मेमोरी तक पहुँच की अनुमति नहीं पाता।

Memory integrity (HVCI) सक्षम करने से ड्राइवर काम करना क्यों बंद कर सकता है?

HVCI वातावरण में कर्नेल पेज निष्पादन योग्य तभी बनता है जब वह अखंडता सत्यापन पार कर चुका हो, और निष्पादन योग्य पेजों पर लेखन अनुमति नहीं। अहस्ताक्षरित ड्राइवर, या निष्पादन योग्य मेमोरी पुनर्लेखन करने वाला पुराने-डिज़ाइन ड्राइवर, यह बाधा पूरी नहीं कर सकता और उसका लोड अवरुद्ध होता है। अवरोध CodeIntegrity Operational लॉग (इवेंट ID 3087 आदि) में पुष्टि कर सकते हैं।

Credential Guard क्या सुरक्षित करता है, और क्या नहीं?

यह डोमेन क्रेडेंशियल के NTLM पासवर्ड हैश, Kerberos TGT, और ऐप ने डोमेन क्रेडेंशियल के रूप में जो संग्रहीत किया, उन्हें पृथक वातावरण में सुरक्षित करता है। Kerberos सेवा टिकट, स्थानीय खातों और Microsoft खातों के क्रेडेंशियल, कीलॉगर से इनपुट चोरी, और भौतिक हमले दायरे से बाहर हैं।

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

msinfo32 में "Virtualization-based security" फ़ील्ड देखें, या PowerShell से root/Microsoft/Windows/DeviceGuard नेमस्पेस में Win32_DeviceGuard क्लास क्वेरी करें। यदि SecurityServicesRunning में 1 हो तो Credential Guard चल रहा है; यदि 2 हो तो Memory integrity (HVCI) चल रहा है।

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

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

Go Komura

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

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