GreatXML: ثغرة Windows التي تحوّل Defender Offline Scan إلى مدخل خلفي على BitLocker

في 11 يونيو 2026 نشر الباحث المعروف باسم MSNightmare مستودعًا جديدًا يحمل اسم GreatXML. جاء النشر بعد يوم واحد فقط من RoguePlanet، وظهر بالتوازي على GitHub وعلى مرايا مرتبطة بمشروع Nightmare-Eclipse. ووفق المادة الأصلية، لم يكن هناك تنسيق إفصاح مسبق ولا CVE مخصص ولا رقعة متاحة وقت النشر.

GreatXML ليست ثغرة تقليدية من نوع Memory Corruption، ولا تعتمد على خطأ في Kernel، ولا تكسر خوارزمية BitLocker نفسها. بدل ذلك تستغل تفاعلًا بين Windows Recovery Environment المعروف باسم WinRE، وملفات Windows Answer Files، والحالة التي يدخل فيها النظام بعد استخدام Microsoft Defender Offline Scan.

المهم أيضًا أن GreatXML ليست وسيلة Initial Access. المهاجم يحتاج أولًا إلى صلاحيات Administrator حتى يستطيع الكتابة داخل قسم الاسترداد وزرع الملفات المطلوبة. بعدها تصبح قيمة الأداة في الاستمرارية والوصول إلى البيانات، لأن تغيير كلمات المرور أو فقد المهاجم وصوله البعيد لا يزيل الملفات المزروعة من قسم الاسترداد.

#الفكرة الأساسية وراء GreatXML

Windows Recovery Environment هو بيئة مصغرة من Windows تعمل خارج جلسة النظام المعتادة. تُستخدم هذه البيئة في الإصلاح وإعادة الضبط واستعادة النظام وبعض مهام الفحص الأمني، بما فيها Defender Offline Scan.

عندما يتم تشغيل Defender Offline Scan يدخل WinRE في حالة تشغيلية محددة تغيّر طريقة التعامل مع بعض الملفات الموجودة على قسم الاسترداد. من بين هذه الملفات Windows Answer Files، وهي ملفات إعدادات تلقائية يستخدمها Windows في سيناريوهات النشر والتثبيت والتهيئة.

هنا تظهر نقطة الاستغلال. إذا تم وضع ملف unattend.xml خبيث في جذر قسم الاسترداد، ومعه مكونات Recovery معدلة، يمكن لـ WinRE معالجة هذا الملف أثناء الإقلاع داخل سياق موثوق وقبل تحميل Windows بشكل طبيعي.

المصدر يصف أن المعالجة تحصل قبل تطبيق بعض الحدود الأمنية المعتادة وقبل تسجيل الدخول التفاعلي. وبذلك يستطيع ملف الإجابة توجيه WinRE إلى تنفيذ أوامر تفتح Shell في بيئة تستطيع رؤية وحدة التخزين المحمية بـ BitLocker.

هذه النقطة مهمة جدًا. GreatXML لا تفك تشفير BitLocker ولا تتجاوز الرياضيات الخاصة به، بل تستفيد من سياق موثوق يملك أصلًا إمكانية التعامل مع القرص أثناء عمل WinRE.

#لماذا BitLocker يصبح قابلًا للوصول

BitLocker مصمم لحماية البيانات وهي في حالة تخزين. لكن نظام Windows نفسه يحتاج في بعض الحالات إلى الوصول إلى القرص أثناء مهام الاسترداد والصيانة.

WinRE هو أحد هذه السياقات. لذلك تكون وحدة التخزين متاحة للبيئة وفق ظروف محددة حتى يستطيع النظام تنفيذ وظائف الإصلاح والاسترداد.

GreatXML تستفيد من هذا السياق الموثوق. بدل أن تنفذ WinRE خطوات الاسترداد الطبيعية فقط، يتم تمرير أوامر خبيثة عبر unattend.xml تجعل البيئة تفتح Shell يستطيع الوصول إلى البيانات الموجودة على القرص.

وبالتالي لا يحتاج المهاجم في تلك اللحظة إلى مفتاح BitLocker Recovery Key ولا إلى PIN ولا إلى تسجيل دخول بحساب Windows.

#القيد الأكبر في الاستغلال

الاستغلال ليس سحريًا ولا يعمل من حساب مستخدم عادي. العقبة الرئيسية هي أن الملفات يجب أن تُكتب في جذر قسم الاسترداد.

هذا القسم لا يكون Mounted عادة داخل Windows كقرص يمكن لأي مستخدم الوصول إليه. للوصول إليه من جلسة النظام يحتاج المهاجم إلى استخدام أدوات مثل diskpart لتعيين حرف Drive له، وهذه العملية تتطلب Command Prompt مرتفع الصلاحيات.

لذلك يجب أن يكون المهاجم قد حصل على Administrator بالفعل. هذه الحقيقة تغيّر تصنيف GreatXML بالكامل، لأنها تجعلها قدرة Post-Compromise وليست ثغرة تمنح الوصول الأولي إلى الجهاز.

القيمة هنا ليست الوصول من الصفر، بل تحويل نافذة قصيرة من الصلاحيات المرتفعة إلى وصول مستمر للبيانات لاحقًا.

#المرحلة الأولى: زرع الملفات داخل Recovery Partition

في المرحلة الأولى يكون المهاجم قد حصل بالفعل على Administrator. عندها يقوم بالوصول إلى قسم الاسترداد ونسخ عنصرين أساسيين إليه.

الأول هو ملف unattend.xml. هذا الملف يستخدم صيغة Windows Answer File القياسية، لكنه يحتوي على توجيهات خبيثة تجعل WinRE ينفذ أوامر يحددها المهاجم أثناء الإقلاع.

العنصر الثاني هو مجلد Recovery معدل، ويتضمن WindowsRE ومكونات معدلة مرتبطة ببيئة الاسترداد.

هذه المرحلة هي الوحيدة التي تحتاج وجودًا فعليًا للمهاجم داخل جلسة Windows الحية. بمجرد زرع الملفات، لا يحتاج المهاجم إلى البقاء متصلًا بالجهاز حتى يتم تشغيل السلسلة لاحقًا.

وهذا ما يجعل مرحلة File Placement أهم نقطة دفاعية أيضًا. فهي اللحظة التي يمكن أن ترى فيها أدوات الرصد نشاطًا واضحًا على النظام قبل أن ينتقل الاستغلال إلى WinRE.

#المرحلة الثانية: وضع الجهاز في حالة Defender Offline Scan

GreatXML تحتاج إلى أن يكون الجهاز في حالة WinRE المرتبطة بـ Defender Offline Scan.

المصدر يوضح أن أحد الشروط هو أن يكون Defender Offline Scan قد تم تشغيله على الجهاز في وقت سابق. إذا كان هذا قد حدث بالفعل فلا يحتاج المهاجم إلى إعداد إضافي قبل الدخول إلى WinRE.

عندها يمكن إعادة تشغيل الجهاز إلى Windows Recovery Environment باستخدام Shift + Restart من شاشة تسجيل الدخول أو من قائمة Start.

النقطة المهمة هنا أن Shift + Restart متاح حتى من Lock Screen، لذلك لحظة التفعيل نفسها لا تحتاج إلى جلسة مستخدم مصادق عليها.

إذا لم يكن Defender Offline Scan قد تم تشغيله من قبل، يستطيع المهاجم الذي يملك Administrator تشغيل الفحص من واجهة Defender. هذا يضع الجهاز في الحالة المطلوبة ويجدول الفحص ليعمل عند الإقلاع التالي إلى WinRE.

المصدر يشير أيضًا إلى أن الباحث يرى احتمال وجود مسار لا يحتاج فحصًا سابقًا، لكنه لم يلاحق هذا السيناريو ضمن البحث المنشور.

#المرحلة الثالثة: إقلاع WinRE وتنفيذ unattend.xml

عند دخول الجهاز إلى WinRE تبدأ المرحلة الأهم.

WinRE يقلع من قسم الاسترداد ويعالج ملف unattend.xml الذي زرعه المهاجم في المرحلة الأولى. لأن الملف بصيغة يفهمها Windows أصلًا، لا يحتاج الاستغلال إلى تحميل Parser خارجي أو تنفيذ تنسيق غير معروف.

التوجيهات الخبيثة تعمل داخل السياق الموثوق لبيئة الاسترداد. ووفق المصدر يحدث هذا قبل تحميل نظام التشغيل الطبيعي وقبل تسجيل الدخول وقبل مطالبة المستخدم ببيانات BitLocker في المسار المستهدف.

النتيجة هي Shell داخل WinRE يستطيع الوصول إلى وحدة التخزين المحمية بـ BitLocker. ومن هذه النقطة يستطيع المهاجم قراءة البيانات من القرص من دون الحاجة إلى Recovery Key أو PIN أو بيانات اعتماد المستخدم.

#لماذا يعتبر هذا تجاوزًا لـ BitLocker وليس كسرًا للتشفير

من السهل وصف النتيجة بأنها كسر لـ BitLocker، لكن هذا غير دقيق تقنيًا.

GreatXML لا تهاجم خوارزمية التشفير ولا تستخرج المفتاح عبر هجوم Cryptographic مباشر. كما أنها لا تعتمد على ضعف في AES أو على تجاوز حسابي للحماية.

الاستغلال يستفيد من سياق نظام شرعي يملك الوصول المطلوب أصلًا. المشكلة في طريقة تفاعل WinRE مع ملفات Answer Files والحالة التي يتركها Defender Offline Scan.

لهذا يوصف الاستغلال بشكل أدق بأنه BitLocker bypass primitive في سياق WinRE، وليس كسرًا للتشفير نفسه.

#لماذا GreatXML مفيدة للمهاجم بعد انتهاء الاختراق

لو حصل المهاجم على Administrator في جهاز ثم فقد الاتصال به لاحقًا، يمكن للمؤسسة عادة أن تغيّر كلمات المرور وتلغي الجلسات وتقطع الوصول البعيد.

لكن الملفات التي زرعت في قسم الاسترداد لا تختفي تلقائيًا مع هذه الإجراءات.

إذا كان للمهاجم وصول مادي لاحق إلى الجهاز، يستطيع تشغيل Shift + Restart من شاشة القفل والدخول إلى WinRE. عندها يتم تشغيل السلسلة المزروعة والوصول إلى البيانات المشفرة من دون تسجيل الدخول إلى Windows.

لهذا تعتبر GreatXML آلية Persistence موجهة للوصول إلى البيانات أكثر من كونها Persistence تقليدية للحفاظ على جلسة داخل النظام.

قيمتها تأتي من أنها تنقل نقطة السيطرة من Windows الحي إلى بيئة الاسترداد نفسها.

#ما الذي تحقق منه Cyderes

وفق المادة الأصلية، قام فريق Cyderes Howler Cell باختبار Proof of Concept على جهاز Windows 11 محدث بالكامل.

هذا التفصيل مهم لأنه يعني أن السلوك لم يكن مجرد فرضية مكتوبة أو سيناريو يعتمد على إصدار قديم غير مدعوم.

مع ذلك، المادة نفسها تؤكد أن القيد الأساسي يبقى موجودًا. المهاجم يحتاج Administrator لزرع الملفات، ويحتاج الجهاز إلى الحالة المرتبطة بـ Defender Offline Scan قبل تشغيل السلسلة.

#GreatXML داخل سلسلة Nightmare-Eclipse

GreatXML لا تظهر كأداة منفصلة عن سياق أكبر.

وفق المصدر، هي الأداة الثامنة تقريبًا التي نُشرت ضمن مجموعة Nightmare-Eclipse خلال نحو عشرة أسابيع. وهي أيضًا ثاني تجاوز لـ BitLocker في المجموعة بعد YellowKey.

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

من بينها BlueHammer المرتبطة بـ Windows Defender، وUnDefend التي تستهدف قدرات Defender، وRoguePlanet، وYellowKey المرتبطة بـ BitLocker، وGreenPlasma المرتبطة بـ CTFMON، وMiniPlasma المرتبطة بـ Cloud Files Mini Filter Driver، إضافة إلى RedSun التي ما زالت تفاصيلها التقنية العامة محدودة.

#نمط الاستهداف

اللافت في السلسلة أن عددًا كبيرًا من الأهداف ليس خدمات هامشية داخل Windows.

المصدر يلاحظ أن الاستهداف يتركز على مكونات تقدمها Microsoft باعتبارها جزءًا من الضمانات الأمنية الأساسية. Defender للحماية من البرمجيات الخبيثة، وBitLocker لحماية البيانات وهي في حالة تخزين، وCTFMON كمكوّن يعمل في معظم جلسات المستخدمين، وCloud Files Filter كجزء عميق من بنية النظام.

هذا ما جعل كاتب التحليل يرى أن السلسلة تبدو أقرب إلى Toolkit عملياتي بدل مجموعة عشوائية من الأخطاء.

لكن هنا يجب الانتباه إلى نقطة مهمة. هذا الربط بين الأدوات كسلسلة هجومية متكاملة هو Hypothesis تحليلية في المصدر، وليس إثباتًا بأن الأدوات استُخدمت فعليًا معًا في عملية واحدة.

#فرضية ربط الأدوات كسلسلة Kill Chain

المصدر يقترح قراءة الأدوات بالترتيب الذي قد يستخدمه Operator.

في البداية تأتي قدرات مثل RoguePlanet. كانت الأداة في أصلها مبنية للوصول إلى Arbitrary Code Execution عبر تعامل Defender مع ملفات موجودة على SMB Shares بعيدة مقدمة من صور .vhd أو .vhdx يتحكم بها المهاجم.

بحسب المادة، تحديث لمحرك Defender في منتصف مايو غيّر واجهات داخلية مرتبطة بـ mpengine!SysIO* وأغلق هذا المسار. النسخة المنشورة لاحقًا أصبحت Local Privilege Escalation بدل المسار الأولي.

بعد ذلك تأتي مرحلة Defense Evasion. هنا يضع التحليل UnDefend كأداة قد تستخدم لتعطيل أو تجاوز بعض قدرات Defender وتقليل Telemetry التي قد تنتجها الخطوات التالية.

ثم تأتي Privilege Escalation. المجموعة تشمل عدة مسارات مستقلة للوصول إلى SYSTEM عبر مكونات مختلفة.

BlueHammer تستهدف Defender وتصل إلى SYSTEM. GreenPlasma تستهدف CTFMON. MiniPlasma مرتبطة بـ Cloud Files Filter. وRoguePlanet توفر مسارًا إضافيًا من خلال Defender quarantine pipeline race.

#لماذا وجود عدة LPE مهم

المهاجم لا يحتاج أربع ثغرات Privilege Escalation في جهاز واحد.

لكن وجود عدة خيارات له قيمة عملياتية كبيرة لأن Local Privilege Escalation قد تكون حساسة لإصدار Windows أو Race Conditions أو اختلافات Hardware أو إعدادات الحماية.

المصدر يذكر أن RoguePlanet نفسها قد تكون Hit or Miss بين الأجهزة. قد تعمل بثبات على بعض الأجهزة وتفشل على أجهزة أخرى.

وجود أربع قدرات مستقلة للوصول إلى SYSTEM عبر ثلاثة Subsystems مختلفة يعطي المشغل مرونة أكبر داخل بيئة Enterprise مختلطة تضم Windows 10 وWindows 11 وإصدارات Build متعددة.

إذا فشل مسار في جهاز معين قد ينجح مسار آخر.

#مرحلة الوصول الفيزيائي والبيانات

بعد الوصول إلى SYSTEM على جهاز يعمل، يستطيع المهاجم التحكم محليًا بالنظام.

لكن أدوات مثل YellowKey وGreatXML تضيف بعدًا مختلفًا. بدل التركيز فقط على جلسة Windows النشطة، تمتد القدرة إلى سيناريوهات Physical Access والوصول إلى البيانات الموجودة على الجهاز.

هذا يشمل سيناريوهات مثل جهاز مفقود أو مسروق، أو وصول Evil Maid إلى لابتوب تنفيذي، أو وصول مختبري إلى جهاز يراد استخراج بياناته بعد فقد الجلسة الأصلية.

في هذا السياق تصبح GreatXML امتدادًا مهمًا لسلسلة تعتمد على الوصول المرتفع ثم تحويله إلى وصول مستمر للبيانات خارج نظام التشغيل الطبيعي.

#ما الذي يجعل مرحلة File Placement أهم نقطة للرصد

بعد انتقال الهجوم إلى WinRE تقل فرص الرؤية باستخدام أدوات EDR التقليدية.

الاستغلال لا يحتاج إلى إبقاء Process خبيث يعمل داخل جلسة Windows. ولا يحتاج إلى اتصال C2 مستمر حتى يؤدي وظيفته الأساسية.

لهذا يركز المصدر على مرحلة زرع الملفات داخل Recovery Partition باعتبارها النقطة الأكثر قابلية للكشف.

أي كتابة غير معتادة إلى جذر قسم الاسترداد يجب أن تعامل بجدية، خصوصًا إنشاء unattend.xml في هذا المكان.

كذلك إنشاء مجلدات جديدة باسم Recovery أو WindowsRE بواسطة عمليات غير نظامية يعتبر مؤشرًا مهمًا، لأن هذا النوع من التعديل لا يفترض أن يحدث عشوائيًا أثناء الاستخدام الطبيعي.

#مراقبة Defender Offline Scan

الجانب الثاني الذي يجب مراقبته هو Defender Offline Scan نفسه.

المصدر يقترح التنبيه عند جدولة أو بدء Offline Scan من سياق مستخدم غير متوقع، خصوصًا إذا سبق ذلك نشاط على قسم الاسترداد.

كما يفيد ربط أحداث تشغيل WinRE بعمليات Defender Offline Scan التي حدثت قبلها بفترة قصيرة.

إذا ظهر تسلسل يتضمن وصولًا مرتفعًا إلى Recovery Partition ثم تعديل ملفات ثم Offline Scan ثم إقلاع WinRE، فهذه سلسلة تستحق التحقيق الفوري.

#ما الذي يجب أن يبحث عنه المدافعون

أول مؤشر واضح هو كتابة ملف unattend.xml إلى جذر Recovery Partition بواسطة Process خارج سياقات Windows Update أو إعداد WinRE الطبيعية.

المؤشر الثاني هو إنشاء مجلدات Recovery أو WindowsRE جديدة في نفس القسم بواسطة Process غير نظامي.

المؤشر الثالث هو تشغيل أو جدولة Defender Offline Scan من User Context بطريقة غير معتادة.

المؤشر الرابع هو WinRE boot يحدث بعد Offline Scan غير معتاد، خصوصًا إذا سبقه وصول إلى قسم الاسترداد أو تغيير ملفات داخله.

كل واحدة من هذه الإشارات قد تكون شرعية منفردة في بعض السيناريوهات. لكن اجتماعها في تسلسل واحد يرفع مستوى الشبهة بشكل كبير.

#لماذا الاستجابة التقليدية للحادث قد لا تكفي

في كثير من الحوادث، تغيير Credential وإغلاق Remote Access يعتبر خطوة أساسية لاحتواء المهاجم.

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

قد يبدو الجهاز نظيفًا من منظور جلسة Windows الحالية، بينما يبقى مسار وصول إلى البيانات موجودًا في بيئة Recovery.

لهذا يجب أن تشمل الاستجابة للحوادث فحص Recovery Partition عندما يكون هناك دليل على وصول Administrator أو SYSTEM غير موثوق.

#النقطة الأهم في تصميم الهجوم

ما يجعل GreatXML مثيرة للاهتمام ليس تعقيد Payload نفسها فقط.

الاستغلال يعتمد على تجميع سلوكيات شرعية في Windows بطريقة تنتج حدود ثقة غير متوقعة.

WinRE ميزة شرعية. Defender Offline Scan ميزة شرعية. unattend.xml صيغة شرعية. وصول Administrator إلى الأقراص ميزة شرعية أيضًا.

لكن عندما تجتمع هذه العناصر في الترتيب الصحيح يصبح من الممكن تحويل بيئة الاسترداد إلى قناة وصول للبيانات.

وهذا النوع من الثغرات أصعب في المعالجة من خطأ Memory Safety بسيط، لأنه يقترب من Design-Level Abuse أكثر من كونه Bug منفصلًا يمكن إصلاحه بتغيير سطر أو دالة واحدة.

#لا يوجد Patch جذري في المصدر

المادة الأصلية تذكر أنه لم تكن هناك رقعة تعالج السبب الجذري وقت نشر التحليل.

ولهذا تركز توصيات الدفاع على Detection أكثر من Prevention الكامل.

إلى أن يتم تقييد طريقة معالجة unattend.xml داخل سياق WinRE المرتبط بـ Offline Scan، تبقى مراقبة قسم الاسترداد والتغييرات التي تسبقه أحد أهم خطوط الدفاع.

#الخلاصة

GreatXML لا تعطي المهاجم Administrator من الصفر ولا تكسر BitLocker تشفيريًا. هي قدرة Post-Compromise تستفيد من صلاحيات مرتفعة موجودة مسبقًا لزرع ملفات داخل Recovery Partition ثم تستخدم WinRE للوصول إلى البيانات في وقت لاحق.

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

وعند وجود وصول مادي لاحق يمكن تشغيل WinRE من شاشة القفل والوصول إلى القرص من خلال السياق الموثوق الذي توفره بيئة الاسترداد.

لهذا لا تبدو GreatXML كـ Zero-Day تقليدية فقط. هي مثال على كيف يمكن لميزات أمنية واستردادية شرعية داخل Windows أن تتحول إلى سطح هجوم عندما تتقاطع حدود الثقة بينها بطريقة لم تكن مقصودة.

وبالنسبة للمدافعين، أهم نقطة ليست مراقبة Shell بعد ظهورها داخل WinRE. أهم نقطة هي اكتشاف اللحظة التي تم فيها تجهيز الهجوم أصلًا، وهي لحظة الكتابة إلى Recovery Partition قبل أن يخرج التنفيذ من Windows الحي إلى بيئة الاسترداد.