أعماق الافتراضيّة في Windows (الجزء 2) ── ذاكرة لا تستطيع النواة حتّى رؤيتها: كيف يعمل VBS وHVCI وCredential Guard

أين يضع Windows أسراراً لا يستطيع مدير ولا النواة قراءتها؟ يبدأ الجزء 2 من هذا السؤال ويتبع كيف يعمل VBS وHVCI وCredential Guard.

على Windows التقليديّ، كان مهاجم حمّل برنامج تشغيل نواة بوصفه مديراً وفرّغ ذاكرة عمليّة LSASS يستطيع سرقة تجزئات كلمات المرور وتذاكر Kerberos واستخدامها للحركة الجانبيّة إلى أجهزة أخرى.

على Windows 11 مع تشغيل Credential Guard، لا تُحفَظ تجزئات بيانات اعتماد النطاق المحميّة في أيّ مكان تستطيع النواة العاديّة البحث فيه. على أجهزة تستوفي متطلّبات الترخيص (Enterprise وEducation وما شابه) ومتطلّبات العتاد، تُفعَّل هذه الحماية افتراضيّاً من 22H2 فصاعداً.¹ المتطلّبات وحالة التشغيل الفعليّة شيئان مختلفان، لذا لم يختفِ الخطر حيث لا يعمل.

أظهر الجزء 1 البنية التي يعمل فيها Windows المضيف في القسم الجذر فوق الـ hypervisor. ما يتبعه هذا المقال هو خطّ حدود إضافي، مرسوم داخل ذلك القسم نفسه.

«أعماق الافتراضيّة في Windows» ── الأجزاء الثلاثة كلّها

ننظر إلى hypervisor Windows نفسه بترتيب الأساس → عزل الأمان → التطبيق على آلات افتراضيّة خفيفة.

ما يفترضه هذا المقال

كيف تقرأ هذا المقال

1. الخلاصة أوّلاً

أضاف Windows محور امتياز يُسمَّى VTL (مستوى الثقة الافتراضي) ووضع الأسرار في VTL1. لا تستطيع النواة العاديّة التي تعمل في VTL0 قراءة ذاكرة VTL1. ما يحرس الحدّ ليس النواة نفسها بل الـ hypervisor، الذي يمسك جداول ترجمة SLAT.

ذلك هيكل الأمان المستند إلى الافتراضيّة (VBS). يستخدم VBS الـ hypervisor لإنشاء بيئة معزولة ويؤوي فيها ميزات أمنيّة. مصمَّم على مقدّمة أنّ البيئة المعزولة تبقى محميّة حتّى إن اختُرقت النواة.²

flowchart TB
    accTitle: العالمان اللذان ينشئهما VBS
    accDescr: يجلس VTL0 وVTL1 داخل القسم نفسه؛ يمسك VTL0 النواة العاديّة والتطبيقات، ويمسك VTL1 النواة الآمنة والميزات الأمنيّة المعزولة، ويحرس الـ hypervisor الحدّ
    subgraph vtl0 ["VTL0 (العالم العادي)"]
        apps["تطبيقات (الحلقة 3)"]
        ntk["نواة NT وبرامج التشغيل (الحلقة 0)"]
    end
    subgraph vtl1 ["VTL1 (العالم المعزول)"]
        ium["ميزات أمنيّة معزولة"]
        sk["النواة الآمنة"]
    end
    hv["الـ hypervisor (يفرض الحدّ عبر SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|لا تستطيع القراءة| ium

الشكل 1: ثمّة عالمان داخل Windows واحد، ولا تستطيع نواة VTL0 الوصول إلى ذاكرة VTL1.

النقطة المهمّة أنّ هذا ليس «إقامة آلة افتراضيّة أخرى». VTL0 وVTL1 داخل القسم نفسه، داخل Windows نفسه. ننظر بالدور كيف يُحقَّق هذا الانقسام.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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. يعمل الـ hypervisor بامتياز أعلى من النواة ويتولّى حصريّاً صلاحيّات وصول ذاكرة المعالج (SLAT) مبكّراً. منطقة معزولة يحرسها الـ hypervisor محميّة حتّى ضدّ الوصول من برمجيّات نظام تشغيل الحلقة 0 (وضع المشرف).³

3. VSM وVTLs ── إضافة محور امتياز إضافي

يسير هذا القسم بترتيب مجموعة الميزات التي توفِّر العزل (VSM) → مستويات العزل (VTLs) → الآليّة التي تفرض الحدّ (SLAT) → الشيفرة التي تعمل في الداخل. تتشابه الأسماء، لكنّها ليست الشيء نفسه.

3.1. مستويات الثقة الافتراضيّة (VTLs)

مجموعة ميزات الـ hypervisor التي توفِّر هذا العزل تُسمَّى VSM (الوضع الآمن الافتراضي). VSM أساس Device Guard وCredential Guard وTPM الافتراضي وما شابه.³

المفهوم المركزي لـ VSM هو VTL (مستوى الثقة الافتراضي). النقاط الرئيسة كالتالي.³

• VTLs هرميّة، وكلّما ارتفع الرقم ارتفع الامتياز. VTL0 الأدنى؛ VTL1 أكثر امتيازاً من VTL0.
• معماريّاً تُعرَّف حتّى 16 مستوى، لكنّ ما هو منفَّذ حالياً اثنان: VTL0 وVTL1.
• لكلّ VTL حمايات وصول ذاكرة مستقلّة. يدير الـ hypervisor هذه الحمايات على فضاء العناوين الفيزيائيّ للقسم، لذا لا تستطيع برمجيّات النظام داخل القسم تغييرها.
• يملك معالج افتراضي حالة سجلّات وآليّة مقاطعات منفصلة لكلّ 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: جعل لا الذاكرة فحسب بل أيضاً حالة المعالج والمقاطعات عالماً منفصلاً هو المجموعة الثلاثيّة التي لا تترك ثغرة نظر.

إن كانت الحلقات (0 و3) المحور الذي يفصل «نظام التشغيل والتطبيقات»، فـ VTLs محور ثانٍ يفصل «العالم العادي والعالم المعزول». المحوران متعامدان، وداخل VTL1 ثمّة وضع نواة ووضع مستخدم أيضاً.

flowchart TB
    accTitle: المناطق الأربع التي ينشئها محورا الحلقات وVTLs
    accDescr: يفصل محور الحلقات وضع النواة عن وضع المستخدم، ويفصل محور VTL العالم العادي عن العالم المعزول، وينتج الجمع أربع مناطق: تطبيقات عاديّة ونواة NT وtrustlets في IUM والنواة الآمنة
    subgraph ax0 ["VTL0 (العالم العادي)"]
        a0["الحلقة 3: تطبيقات عاديّة"]
        k0["الحلقة 0: نواة NT وبرامج التشغيل"]
    end
    subgraph ax1 ["VTL1 (العالم المعزول)"]
        a1["الحلقة 3: IUM (trustlets)"]
        k1["الحلقة 0: النواة الآمنة"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

الشكل 4: صارا الآن محوري امتياز، وصار «هل هي النواة؟» و«هل هو العالم المعزول؟» سؤالين منفصلين.

3.2. جوهر الحدّ هو SLAT

قال الجزء 1 إنّ جداول الترجمة من المستوى الثاني التي تسقط العناوين الفيزيائيّة للضيف (GPA) على RAM الفعلي (SPA)، أي SLAT، يمسكها الـ hypervisor. يستخدم VSM هذه الخاصّيّة بالضبط. يُبنى عزل VTL باستخدام hypervisor Hyper-V وSLAT.⁴

عندما يعلن VTL1 «هذه الذاكرة لا تُعرض لـ VTL0»، يزيل الـ hypervisor صلاحية الوصول لتلك الصفحة من جداول ترجمة VTL0. من ثمّ، حتّى إن حاولت نواة VTL0 لمس ذلك العنوان، تُرفَض في مرحلة ترجمة عناوين المعالج. لا يهمّ كيف تعيد النواة كتابة جداول صفحاتها.

قد تنتمي جداول الصفحات (GVA→GPA) إلى النواة، لكنّ الترجمة بعدها (GPA→SPA) وصلاحية الوصول النهائيّة تنتميان إلى الـ hypervisor.

flowchart TB
    accTitle: كيف يُرفَض وصول من VTL0 إلى ذاكرة VTL1
    accDescr: عندما تحاول نواة VTL0 قراءة ذاكرة VTL1، تستطيع المرور بجداول صفحاتها لكن تُرفَض بحماية وصول SLAT، وينتقل التحكّم إلى الـ hypervisor
    try["نواة VTL0 تحاول قراءة صفحة VTL1"] --> pt["تمرّ بجداول صفحات النواة نفسها"]
    pt --> slat{"هل تسمح حماية وصول SLAT؟"}
    slat -->|غير مسموح| deny["يتدخّل الـ hypervisor ويرفض الوصول"]
    slat -->|مسموح| ok["وصول ذاكرة عادي"]
    deny -.-> point["محميّ في طبقة لا تستطيع النواة تغييرها"]

الشكل 5: الحاجز يجلس خارج النواة، ولا تستطيع برمجيّات داخل القسم تغيير حماية SLAT.

قال الجزء 1 من سلسلة الذاكرة إنّ «VAD وPTE وسمات الحماية تقرِّر هل الوصول مسموح». في بيئة VBS تصير الصورة: بعد مرور كلّ تلك، ما يزال حاجز SLAT ينتظر.

3.3. النواة الآمنة وIUM

ما يعمل داخل VTL1 ليس نواة NT العاديّة بل نواة صغيرة تُسمَّى النواة الآمنة. وضع المستخدم في VTL1 يُسمَّى IUM (وضع المستخدم المعزول)، والبرامج التي تعمل هناك تُسمَّى trustlets (عمليّات موثوق بها).⁴

لا يستطيع trustlet فعل أيّ شيء يحبّه كما تستطيع عمليّة عاديّة. معظم استدعاءات نظامه تُمرَّر إلى نواة NT في جانب VTL0، التي تُطلَب لفعل العمل.⁴ VTL1 ليس «عالماً أعلى يستطيع فعل أيّ شيء»؛ إنّه مبنيّ صغيراً عمداً، بوصفه خزنة تمسك أسراراً. كلّما قلّت الشيفرة التي يمكن إدخالها إلى الخزنة صغر سطح الهجوم.

flowchart TB
    accTitle: تدفّق استدعاءات نظام trustlet
    accDescr: trustlet في VTL1 لا يعالج معظم استدعاءات النظام بنفسه؛ يمرّرها إلى نواة NT في VTL0 ويتلقّى النتيجة فقط، وهو ما يُبقي VTL1 صغيراً
    tl["Trustlet (IUM في VTL1)"] --> sc{"يلزم استدعاء نظام"}
    sc -->|في معظم الحالات| mar["يسأل نواة NT في VTL0"]
    mar --> res["يتلقّى النتيجة فقط"]
    res -.-> small["يبقى VTL1 صغيراً ويصغر سطح الهجوم"]

الشكل 6: للخزنة لا مرافق خاصّة؛ ترسل الأشغال إلى الخارج وتظلّ تحرس الأسرار فقط.

4. HVCI ── التحقّق من سلامة شيفرة النواة في الخزنة

الأمران اللذان يُستوعبان عن HVCI هما أين يُؤدَّى التحقّق وما المسموح على الذاكرة بعد التحقّق. ننظر إلى تلك الحماية أوّلاً، ثمّ إلى أثرها على توافق برامج التشغيل.

4.1. ما الذي يُتحقَّق منه

أوّل ميزة ممثّلة تجلس على VBS هي سلامة الذاكرة، أي HVCI (سلامة الشيفرة المحميّة بالـ hypervisor). يملك 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 (معرّف الحدث 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.

يمكن تأكيد واقعة الحظر في عارض الأحداث تحت Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (معرّف الحدث 3087 هو الممثّل).⁶

في حالات كثيرة، هذا ما وراء الشكوى «بعد أن فعَّلت سلامة الذاكرة، توقّف جهاز طرفي عن العمل». الإصلاح الصحيح التحديث إلى إصدار متوافق مع HVCI من برنامج التشغيل؛ ينبغي اعتبار تعطيل سلامة الذاكرة ملاذاً أخيراً يتخلّى عن الحماية بالجملة.

إن شاركت في هذا التحقّق من جانب تطوير برامج التشغيل، انظر أيضاً مقالة برامج تشغيل المرشّح («برامج تشغيل المرشّح المصغّر في Windows»).

flowchart TB
    accTitle: فرز عندما يتوقّف جهاز طرفي عن العمل تحت سلامة الذاكرة
    accDescr: حدِّد برنامج التشغيل المحظور في سجلّ CodeIntegrity Operational؛ الإصلاح الصحيح التحديث إلى إصدار متوافق مع HVCI، واسأل البائع إن لم يوجد، وعامل التعطيل ملاذاً أخيراً لا يُجعَل إعداداً دائماً
    sym["يتوقّف جهاز بعد تفعيل سلامة الذاكرة"] --> log2["حدِّد برنامج التشغيل المحظور في سجلّ CodeIntegrity"]
    log2 --> upd{"هل ثمّة برنامج تشغيل متوافق مع HVCI؟"}
    upd -->|نعم| fix2["حدِّث وحلّ مع إبقاء HVCI شغّالاً"]
    upd -->|لا| ask2["اسأل البائع عن إصدار متوافق"]
    ask2 -.-> temp["التعطيل ملاذ أخير، لا إعداد دائم أبداً"]

الشكل 10: أوّل ما يُنظَر إليه ليس شاشة الإعدادات بل السجلّ، ومعرّف الحدث 3087 يعرف أيّ برنامج تشغيل حُظِر.

5. Credential Guard ── التجزئات داخل LSAIso

حيث يحرس HVCI سلامة شيفرة النواة، يحرس Credential Guard بيانات الاعتماد. فكّر في مكتب الاستقبال الذي يقبل المصادقة والمكان الذي تُحفَظ فيه الأسرار شيئين منفصلين، فتقع البنية ونطاق الحماية في مواضعهما.

5.1. LSASS وLSAIso

ثاني ميزة ممثّلة تجلس على VBS هي الجواب عن لغز الافتتاح: Credential Guard.

كان Windows التقليدي يحتفظ بتجزئات NTLM وتذاكر Kerberos في ذاكرة عمليّة LSA (lsass.exe). عندما يُفعَّل Credential Guard، ينتقل تخزين الأسرار المحميّة من بينها، كتجزئات NTLM لبيانات اعتماد النطاق وTGT لـ Kerberos (تذاكر منح التذاكر)، إلى LSAIso.exe، trustlet يعمل في IUM في VTL1.⁷

• يظلّ lsass.exe (VTL0) يعمل مكتب استقبال لمعالجة المصادقة، كما كان.
• تمسك LSAIso.exe (VTL1) الأسرار الفعليّة ولا يمكن الوصول إليها من VTL0.
• يتواصل الاثنان عبر RPC (استدعاء إجراء بعيد).
• لا تستضيف LSAIso أيّ برامج تشغيل أجهزة على الإطلاق وتؤوي فقط الحدّ الأدنى من الملفّات التنفيذيّة الموقَّعة. تُتحقَّق التوقيعات مقابل شهادة يثق بها VBS.⁷

flowchart TB
    accTitle: أين تجلس بيانات الاعتماد عندما يُفعَّل Credential Guard
    accDescr: يتواصل lsass في VTL0، بوصفه مكتب استقبال المصادقة، مع LSAIso في VTL1 عبر RPC؛ وتمسك LSAIso التجزئات وTGT الفعليّة لبيانات اعتماد النطاق المحميّة، لذا مهاجم يحصل على صلاحيّات مدير في 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 فصاعداً، يُفعَّل VBS وCredential Guard افتراضيّاً على أجهزة تستوفي متطلّبات الترخيص (Enterprise E3/E5 وEducation A3/A5) ومتطلّبات العتاد. على إصدارات مثل Pro، لا يُفعَّل Credential Guard تلقائيّاً (ثمّة استثناءات، كجهاز فُعِّل تحت ترخيص مؤهِّل في الماضي ثمّ خُفِّض لاحقاً).¹

هذه حماية بيانات الاعتماد ليست شأن منتج إضافي خاصّ؛ إنّها الحالة القياسيّة لـ Windows الحالي على الإصدارات المؤهِّلة.

flowchart TB
    accTitle: تدفّق بيانات الاعتماد من تسجيل الدخول إلى المصادقة
    accDescr: بعد تسجيل الدخول تُحفَظ الأسرار الفعليّة في LSAIso في VTL1؛ وفي كلّ مرّة تلزم مصادقة، يطلب lsass في VTL0 الحساب عبر RPC، ولا يعود إلى VTL0 إلّا نتيجة معالجة المصادقة دون أن تُعاد الأسرار طويلة الأمد المحميّة نفسها أبداً
    signin["يسجِّل المستخدم الدخول"] --> front["يعالجه lsass مكتب استقبال"]
    front --> store["تُحفَظ الأسرار الفعليّة في LSAIso"]
    auth["طلبات مصادقة لاحقة"] --> front
    front -->|يطلب الحساب عبر RPC| store
    store -->|"يعيد النتيجة (لا السرّ أبداً)"| front

الشكل 12: الأسرار طويلة الأمد المحميّة نفسها لا تغادر الخزنة أبداً؛ ما يعود إلى VTL0 نتيجة معالجة المصادقة، كتذكرة.

5.2. اعرف بدقّة ما ليس محميّاً

بيانات الاعتماد المحميّة

Credential Guard ليس درعاً لكلّ غرض. ما يحميه هو تجزئات NTLM لبيانات اعتماد النطاق، وTGT لـ Kerberos (تذاكر منح التذاكر)، وأيّ شيء مخزَّن بوصفه بيانات اعتماد نطاق.

خارج النطاق

التالي خارج النطاق.⁸

• تذاكر خدمة 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 وكلّ ميزة على جهازك. اقرأ حالة VBS، الأساس، منفصلة عن حالة الخدمات التي تعمل فوقه.

6.1. افحص VBS والخدمات العاملة في PowerShell

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

اقرأ المخرجات كالتالي.⁹

• إن كان VirtualizationBasedSecurityStatus هو 2، فـ VBS مفعَّل ويعمل.
• إن احتوى SecurityServicesRunning على 1، يعمل Credential Guard؛ وإن احتوى على 2، تعمل سلامة الذاكرة (HVCI).

6.2. اقرأ msinfo32 وشاشة الإعدادات قراءة مختلفة

لفحص حالة التشغيل في واجهة رسوميّة، انظر حقل «Virtualization-based security» في msinfo32 (الخدمات العاملة مدرجة هناك، مثل «Hypervisor enforced Code Integrity»).

مفتاح «سلامة الذاكرة» تحت «أمان الجهاز > عزل النواة» في تطبيق أمان Windows شاشة تعكس الإعداد. يمكن أن يبدو شغّالاً بينما HVCI لا يعمل فعليّاً، كما أثناء إعادة تشغيل معلَّقة فور التفعيل أو عند مشكلة توافق عند البدء، لذا احكم هل يعمل من msinfo32 أو من SecurityServicesRunning في Win32_DeviceGuard.⁶

6.3. لا تحكم «يعمل» من وجود عمليّة وحدها

ثمّة أثر أيضاً في علامة تبويب التفاصيل في مدير المهام. على جهاز يعمل فيه VBS سترى عمليّة تُسمَّى «Secure System». LsaIso.exe العمليّة التي تظهر عندما تُستضاف خدمة Isolated LSA في VTL1، ولا تظهر عادة في تكوين فُعِّل فيه HVCI فقط.

غير أنّ وجود عمليّة أو غيابها أثر فقط، لذا احكم هل يعمل Credential Guard من SecurityServicesRunning (هل يحتوي 1)، كما وُصف أعلاه. كلاهما نافذتان، مرئيتان من VTL0، على العالم في جانب VTL1.

flowchart TB
    accTitle: إجراء فحص أنّ الميزات المرتبطة بـ VBS تعمل
    accDescr: أكِّد أنّ VBS يعمل بالاستعلام عن Win32_DeviceGuard، واحكم هل يعمل Credential Guard وHVCI من قيم SecurityServicesRunning، وانظر سجلّ CodeIntegrity لمشكلات برامج التشغيل
    q0["استعلم عن Win32_DeviceGuard"] --> q1{"هل حالة VBS هي 2؟"}
    q1 -->|لا| off["VBS لا يعمل (افحص المتطلّبات والإعدادات)"]
    q1 -->|نعم| q2{"ماذا يحتوي SecurityServicesRunning؟"}
    q2 -->|يحتوي 1| cg["Credential Guard يعمل"]
    q2 -->|يحتوي 2| hvciR["سلامة الذاكرة (HVCI) تعمل"]
    hvciR -.-> ev["لمشكلات برامج التشغيل، افحص سجلّ CodeIntegrity (3087)"]

الشكل 14: فحص الحالة يسير في ثلاث مراحل: VBS نفسه، وكلّ خدمة فوقه، والسجلّ عندما تحدث مشكلة.

7. ثلاث قراءات خاطئة تُتجنَّب في الممارسة

7.1. «حماية صلاحيّات المدير كافية. VBS قصّة جانب الخادم»

ما يمنعه Credential Guard هو انتشار الضرر بعد أخذ صلاحيّات المدير (استخراج التجزئات والحركة الجانبيّة). بعبارة أخرى VBS طبقة دفاع في العمق تفترض الاختراق، وعلى حواسيب العملاء تؤتي أكلها. على 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. «إن سبّبت سلامة الذاكرة مشكلة، عطِّلها فحسب»

تعطيلها سيجعل الأمور تعمل للحظة، لكنّه يزيل الحاجز ضدّ حقن الشيفرة في النواة بالجملة. الإصلاح الصحيح تحديد برنامج التشغيل المحظور أوّلاً في سجلّ CodeIntegrity ثمّ تطبيق الإصدار المحدَّث من البائع. حتّى عندما تعطِّله مؤقّتاً للتحقّق، نوصي بممارسة تشغيل لا تجعل ذلك إعداداً دائماً.

7.3. «مع Credential Guard، لا يمكن سرقة كلمات المرور»

ذلك ثقة زائدة وُلدت من خلط نطاق الحماية. تذاكر الخدمة والحسابات المحلّيّة وضغطات المفاتيح نفسها وبيانات الاعتماد التي يخزّنها تطبيق بنفسه خارج النطاق.⁸ التصيّد ومسجِّلات المفاتيح تحتاج ضوابط أخرى (مصادقة متعدّدة العوامل وWindows Hello ومراجعة كيفيّة إدارة التطبيق نفسه لبيانات الاعتماد).

8. الخلاصة

• يستخدم VBS الـ hypervisor لإنشاء بيئة معزولة ويحمي ميزات أمنيّة على افتراض أنّ النواة ستُخترَق.²
• وحدة العزل هي VTL؛ حالياً مستويان منفَّذان، VTL0 (العالم العادي) وVTL1 (النواة الآمنة وIUM).³
• جوهر الحدّ حماية وصول ذاكرة SLAT، التي لا تستطيع برمجيّات داخل القسم، بما فيها النواة، تغييرها.³
• يؤدّي HVCI تحقّق سلامة الشيفرة في البيئة المعزولة ويفرض «غير قابل للتنفيذ حتّى يمرّ التحقّق» و«الصفحات القابلة للتنفيذ غير قابلة للكتابة».⁵ الثمن أنّ توافق برامج التشغيل يجب إدارته.⁶
• يعزل Credential Guard تجزئات NTLM وTGT لبيانات اعتماد النطاق في LSAIso في VTL1. من Windows 11 22H2 فصاعداً يُفعَّل افتراضيّاً على أجهزة تستوفي متطلّبات الترخيص (Enterprise وEducation) ومتطلّبات العتاد (استخدم هذا مع فحص حالة التشغيل).⁷¹
• يمكن فحص حالة التشغيل من SecurityServicesRunning في Win32_DeviceGuard (1 = Credential Guard، 2 = HVCI).⁹

يتبع في الجزء 3، «آلات افتراضيّة تقلع في ثوانٍ ── WSL2 وWindows Sandbox والحاويات».

حتّى الآن نظرنا إلى الافتراضيّة من جانب «قوّة العزل». ينظر الجزء الأخير من الجانب المقابل، «الخفّة»، ويتبع أين تقتطع الآلات الافتراضيّة الخفيفة التي خلعت ثقل آلة افتراضيّة كاملة.

مقالات ذات صلة

• أعماق الافتراضيّة في Windows (الجزء 1) ── أين يعمل Windows فعليّاً؟ الـ hypervisor والأقسام
• أعماق ذاكرة Windows (الجزء 1) — اللحظة التي يصبح فيها العنوان الافتراضي ذاكرة RAM مادّيّة: خطأ الصفحة من البداية إلى النهاية
• أعماق إدخال/إخراج Windows (الجزء 6، الأخير) ── برامج تشغيل المرشّح والمرشّحات المصغّرة
• قراءة رموز أخطاء ويندوز — البنية ذات الطبقات الثلاث لـ Win32 وHRESULT وNTSTATUS

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تحقيقات التوافق بين تطبيقات Windows والميزات الأمنيّة، وتحليل الإخفاقات التي تسبّبها برامج التشغيل، والتحقّق التقني لبيئات الحواسيب الداخليّة.

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• إعادة استخدام الأصول القائمة والترحيل
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل VBS (الأمان المستند إلى الافتراضيّة) وعزل النواة (Core isolation) الشيء نفسه؟

بالمعنى الدقيق، مختلفان. VBS التقنيّة الأساسيّة التي تستخدم الـ hypervisor لإنشاء بيئة معزولة، و«Core isolation» في تطبيق أمان Windows اسم شاشة تجمع عدّة حمايات مبنيّة فوق VBS. الممثّل هو «سلامة الذاكرة»، الذي يشير إلى HVCI (سلامة الشيفرة المحميّة بالـ hypervisor). أكِّد حالة تشغيل كلّ خدمة فرديّة بالاستعلام عن Win32_DeviceGuard، لا ممّا تعرضه الشاشة.

هل حقّاً لا يمكن قراءة ذاكرة VTL1، حتّى بصلاحيّات مدير أو من برنامج تشغيل نواة؟

لا يمكن. حمايات وصول الذاكرة لكلّ VTL يديرها الـ hypervisor على فضاء العناوين الفيزيائيّ للقسم، ولا تستطيع البرمجيّات التي تعمل داخل القسم تغييرها. حتّى الشيفرة التي تعمل في النواة (الحلقة 0) غير مسموح لها بالوصول إلى ذاكرة VTL1 من VTL0.

لماذا يمكن أن يوقف تفعيل سلامة الذاكرة (HVCI) برنامج تشغيل عن العمل؟

في بيئة HVCI، تصير صفحة نواة قابلة للتنفيذ فقط بعد أن تمرّ بتحقّق السلامة، ولا تُسمَح الكتابة إلى صفحات قابلة للتنفيذ. برنامج تشغيل بلا توقيع، أو برنامج تشغيل بتصميم أقدم يعيد كتابة ذاكرة قابلة للتنفيذ، لا يستطيع استيفاء هذا القيد، فيُحظَر تحميله. يمكنك تأكيد الحظر في سجلّ CodeIntegrity Operational (معرّف الحدث 3087 وما شابه).

ماذا يحمي Credential Guard، وماذا لا يحمي؟

يحمي، في بيئة معزولة، تجزئات كلمات مرور NTLM لبيانات اعتماد النطاق، وTGT لـ Kerberos، وأيّ شيء خزّنه تطبيق بوصفه بيانات اعتماد نطاق. تذاكر خدمة Kerberos، وبيانات اعتماد الحسابات المحلّيّة وحسابات Microsoft، وسرقة الإدخال بمسجِّل مفاتيح، والهجمات الفيزيائيّة خارج النطاق.

أين يمكنني فحص ما إذا كان VBS يعمل؟

انظر حقل «Virtualization-based security» في msinfo32، أو استعلم عن صنف Win32_DeviceGuard في مساحة الأسماء root/Microsoft/Windows/DeviceGuard من PowerShell. إن احتوى SecurityServicesRunning على 1، يعمل Credential Guard؛ وإن احتوى على 2، تعمل سلامة الذاكرة (HVCI).

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.