تقرير التحقق من إثبات المفهوم (PoC) RoguePlanet لـ Microsoft Defender

الغرض من التقرير ونطاقه

يتعلق هذا التقرير بالتحقق من إثبات المفهوم (PoC) RoguePlanet الموصوف علنًا والمرتبط بـ Microsoft Defender. عُرضت التقنية الموصوفة في وسائل الإعلام في 10 يونيو 2026 كتقنية تصعيد امتيازات محلية (LPE)، يمكن من خلالها لمستخدم محلي الحصول على امتيازات NT AUTHORITY\SYSTEM. أشارت الأوصاف العامة إلى أن الآلية تستخدم دوالًا يستخدمها Microsoft Defender عند معالجة ملف أو فحصه.

كان الغرض من الاختبار هو تحديد ما إذا كان يمكن إعداد الاستغلال وتنفيذه في بيئة مختبرية خاضعة للتحكم، ومراقبة كيفية تصرف آليات الحماية في Microsoft Defender على نظام Windows 11 محدّث. يغطي التقرير بيئة الاختبار، وحالة التحديثات، وإعدادات Microsoft Defender، وتجهيز بيئة الترجمة، ونتيجة الترجمة، واستجابة Defender، والتوصيات للحد من المخاطر.

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

المصادر المُشار إليها في المادة التي تم تحليلها:

• المقالة:

  https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html

• مستودع إثبات المفهوم العام:

  https://github.com/MSNightmare/RoguePlanet/tree/main

• مصدر مثبّت MSYS2:

  https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64

• مصدر Visual Studio:

  https://visualstudio.microsoft.com/insiders/?rwnlp=pl

بيئة الاختبار

تم تنفيذ إثبات المفهوم على محطة عمل عميل تعمل خارج نطاق Active Directory، في مجموعة العمل WORKGROUP. كان نظام التشغيل المثبّت على المحطة هو Microsoft Windows 11 Home، الإصدار 25H2، بمعمارية 64 بت.

في يوم تنفيذ إثبات المفهوم، كان النظام يحتوي على تحديثات الأمان لشهر يونيو 2026 مثبّتة، بالإضافة إلى تحديثات سابقة من مايو وأبريل 2026. وهذا يعني أن الاختبار أُجري على نظام Windows 11 25H2 محدّث، البناء 26200، بعد تثبيت أحدث التصحيحات الأمنية المتاحة في تاريخ الاختبار.

إعدادات Microsoft Defender

كان برنامج Microsoft Defender Antivirus نشطًا على محطة العمل المستخدمة للاختبار ويعمل في الوضع العادي. كانت خدمة الحماية تعمل ومفعّلة، وكانت الحماية من الفيروسات والحماية من برامج التجسس ومراقبة السلوك والحماية في الوقت الفعلي نشطة.

في يوم الاختبار، كانت توقيعات Microsoft Defender محدّثة. تم تحديث توقيعات مكافحة الفيروسات ومكافحة برامج التجسس وNIS في 10.06.2026 الساعة 13:27:32.

تم إجراء آخر فحص سريع في 08.06.2026 بين الساعة 15:00:36 و15:01:58، باستخدام إصدار التوقيعات 1.451.323.0. لم يكن قد تم إجراء فحص كامل سابقًا أو لم يكن سجله متاحًا، كما تشير إلى ذلك قيمة FullScanAge البالغة 4294967295 وغياب أوقات بدء وانتهاء الفحص الكامل.

تجهيز بيئة الترجمة

انتهت المحاولة الأولى لترجمة الكود من مستودع GitHub بخطأ ناتج عن غياب ملف الرأس winternl.h. أشارت الرسالة إلى أن النظام لا يحتوي على المجموعة الكاملة من ملفات رأس Windows SDK المطلوبة بواسطة الكود المُحلَّل.

الشكل 1. خطأ غياب ملف الرأس winternl.h أثناء محاولة الترجمة الأولى.

أشار الكود أيضًا إلى ملفات رأس أخرى متعلقة بـ Windows API وNT API، بما في ذلك windows.h وPsapi.h وntstatus.h وvirtdisk.h وshlwapi.h وtaskschd.h وbcrypt.h. لهذا السبب، كان من الضروري تجهيز بيئة ترجمة أكثر اكتمالًا وتثبيت مكونات SDK المناسبة.

الشكل 2. جزء من قائمة ملفات الرأس المطلوبة بواسطة الكود المُحلَّل.

محاولة استخدام MSYS2/MinGW-w64

في البداية، تم استخدام MSYS2/MinGW-w64 لتجهيز بيئة الترجمة. توفر هذه البيئة أدوات GNU لنظام Windows، بما في ذلك مترجمي gcc وg++. تتم إدارة الحزم في MSYS2 باستخدام pacman، الذي يؤدي دورًا مشابهًا لدور apt على أنظمة Linux أو winget على Windows.

الشكل 3. اكتمال تثبيت MSYS2.

باستخدام pacman، تم تثبيت سلسلة أدوات MinGW-w64 GCC/G++، أي مجموعة الأدوات التي تتيح ترجمة كود C/C++ لنظام Windows. تتضمن الحزمة، من بين مكونات أخرى، مترجم gcc، ومترجم g++ للغة C++، والرابط (Linker)، وملفات الرأس والمكتبات اللازمة لبناء تطبيقات تعمل في بيئة Windows. كان الغرض من هذه المحاولة هو التحقق مما إذا كان يمكن ترجمة الكود باستخدام سلسلة الأدوات المفتوحة المتاحة في MSYS2، دون استخدام Visual Studio.

الشكل 4. تثبيت حزم MSYS2/MinGW-w64 باستخدام pacman.

بعد التثبيت، تمت محاولة ترجمة الكود باستخدام g++. حدد الأمر مباشرةً المسار إلى ملف المصدر والمسار إلى الملف التنفيذي الناتج.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe

مشكلة وضع Unicode

كان المؤشر الأول المهم على وجود مشكلة في وضع Unicode هو رسائل المترجم المتعلقة بأنواع الأحرف غير المتوافقة. احتوت السجلات على أخطاء تفيد بأن قيمًا من النوع const wchar_t* أو wchar_t* لا يمكن تحويلها إلى LPCSTR أو LPSTR. كان هذا يعني أن الكود كان يمرر سلاسل أحرف عريضة إلى دوال Windows API، بينما كان المترجم يختار نسخ الدوال المخصصة للسلاسل التقليدية ANSI.

في Windows API، توجد العديد من الدوال بنسختين: نسخة ANSI، وتُعلَّم باللاحقة A، ونسخة Unicode، وتُعلَّم باللاحقة W. على سبيل المثال، يمكن ربط CreateFile كـ CreateFileA أو CreateFileW، وRegOpenKeyEx كـ RegOpenKeyExA أو RegOpenKeyExW. تتوقع نسخة A معاملات من النوع char* أو LPCSTR، بينما تتوقع نسخة W معاملات من النوع wchar_t* أو LPCWSTR.

في الحالة المُحلَّلة، استخدم الكود قيمًا حرفية بصيغة L"..." ومخازن مؤقتة من النوع wchar_t. في الوقت نفسه، أشارت رسائل الخطأ إلى أن المترجم اختار دوالًا مثل GetModuleHandleA وRegOpenKeyExA وRegQueryValueExA وGetWindowsDirectoryA وCreateFileA وwsprintfA. كان هذا مؤشرًا مباشرًا على أن الكود كُتب مع وضع Unicode في الاعتبار، لكن أمر الترجمة لم يعرّف UNICODE و_UNICODE.

لذلك تم فرض وضع Unicode بإضافة تعريفَي UNICODE و_UNICODE. بعد هذا التغيير، يجب ربط دوال Windows API التي لا تحتوي على لاحقة صريحة بالنسخ ذات اللاحقة W، مثل CreateFileW وRegOpenKeyExW وGetModuleHandleW وGetWindowsDirectoryW. أكدت حقيقة اختفاء بعض الأخطاء بعد هذا التغيير صحة التشخيص.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe -DUNICODE -D_UNICODE

ومع ذلك، بعد إزالة المشكلات المتعلقة بـ Unicode، بقيت أخطاء تشير إلى عدم توافق أعمق بين الكود وMinGW. تعلقت هذه الأخطاء، من بين أمور أخرى، بتعاريف مكررة للبنى FILE_BASIC_INFORMATION وFILE_RENAME_INFORMATION، التي كانت معرّفة في كود المصدر وفي ملفات رأس MinGW على حد سواء. بالإضافة إلى ذلك، اختلف إصدار FILE_RENAME_INFORMATION المتاح في MinGW عن الإصدار المتوقع بواسطة الكود، بما في ذلك غياب الحقل Flags.

نتجت أخطاء إضافية أيضًا عن نهج مترجم g++ الأكثر تقييدًا تجاه الأنواع، خاصةً مع أعلام التعداد (enum flags) ومؤشرات الدوال. تعلق هذا الأمر، من بين أمور أخرى، بالنوعين VIRTUAL_DISK_ACCESS_MASK وATTACH_VIRTUAL_DISK_FLAG، وكذلك بتمرير مؤشرات الدوال كـ void*. ونتيجة لذلك، اعتُبر MinGW غير مناسب لترجمة هذا الكود دون إجراء تعديلات كبيرة على كود المصدر.

5. الانتقال إلى MSVC وWindows SDK

بسبب مشكلات التوافق مع MinGW، تم تجهيز بيئة MSVC وWindows SDK. تم تحديد عبء العمل "تطوير سطح المكتب باستخدام C++" في مثبّت Visual Studio لأن الكود المُحلَّل كان تطبيق Windows أصليًا مكتوبًا بلغة C/C++ ويستخدم مكونات Windows API وWindows SDK مباشرةً. لم يكن مشروع .NET أو Python أو Node.js أو تطبيق ويب، لذا لم يتم تثبيت المكونات المتعلقة بتلك التقنيات.

الشكل 5. عبء العمل والمكونات المحددة في Visual Studio لتطبيقات سطح المكتب بلغة C++.

كان المكوّن الأكثر أهمية هو MSVC v143، مترجم Microsoft للغتي C/C++ المُخصص لبناء تطبيقات C/C++ لنظام Windows. تم اختياره لأن المحاولة السابقة للترجمة باستخدام MinGW/G++ تسببت في أخطاء توافق تتعلق بملفات الرأس والأنواع والبنى الخاصة بـ NT API. استخدم الكود آليات خاصة بنظام Windows، لذا كانت البيئة الأكثر توافقًا هي مترجم Microsoft مع المكتبات الموفرة بواسطة Windows SDK.

تم أيضًا تثبيت Windows 11 SDK. يحتوي هذا المكوّن على ملفات الرأس والمكتبات اللازمة لاستخدام دوال نظام Windows، بما في ذلك windows.h وwinternl.h وwinreg.h وprocessthreadsapi.h وvirtdisk.h ومكتبات الاستيراد .lib المستخدمة أثناء الربط. بالإضافة إلى ذلك، تم الاحتفاظ بأدوات CMake للغة C++ كمكوّن مساعد، مفيد عند تحليل مشاريع أكثر تعقيدًا.

بعد التثبيت، تم استخدام x64 Native Tools Command Prompt لـ VS Insiders — وهي واجهة سطر أوامر (CLI) بمسارات مضبوطة بشكل صحيح لمترجم cl.exe وWindows SDK ومكتبات الربط.

الشكل 6. تشغيل x64 Native Tools Command Prompt لـ VS Insiders.

6. الترجمة باستخدام MSVC

بعد الانتقال إلى MSVC، تقدم الكود بشكل ملحوظ في عملية البناء. لا يزال الأمر الأول يُرجع أخطاءً تتعلق بربط دوال Windows API بنسخ ANSI، لذا كان من الضروري إضافة تعريفَي UNICODE و_UNICODE أيضًا أثناء الترجمة باستخدام MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

الشكل 7. محاولة ترجمة باستخدام MSVC دون تهيئة كاملة لـ Unicode والربط.

بعد إضافة مفاتيح Unicode، تمت معالجة الكود بشكل أعمق، وحلّت أخطاء الربط LNK2019 محل أخطاء توافق ملفات الرأس والأنواع. كان هذا يعني أن المترجم أصبح قادرًا بالفعل على إنشاء ملف كائن (Object File)، بينما لم يستلم الرابط بعد جميع مكتبات الاستيراد المطلوبة بواسطة دوال Windows API المستخدمة.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe

الشكل 8. أخطاء الربط LNK2019 الخاصة بدوال Windows API.

تضمنت أخطاء الربط دوالًا مثل CreateProcessAsUserW وOpenProcessToken وAdjustTokenPrivileges وDuplicateTokenEx وGetTokenInformation وLookupPrivilegeValueW وRegOpenKeyExW وRegQueryValueExW. ترتبط هذه الدوال برموز الأمان (Security Tokens) والامتيازات وبدء العمليات في سياق مستخدم محدد وقراءة سجل النظام. يعلن ملف الرأس فقط عن وجود الدالة، لكن يجب أن يستلم الرابط مكتبة الاستيراد الصحيحة التي تشير إلى مكان تواجد تطبيقات تلك الدوال.

لحل أخطاء الربط، تمت إضافة مكتبة advapi32.lib. وهي مكتبة استيراد لنظام Windows توفر، من بين أمور أخرى، دوالًا متعلقة برموز الأمان والامتيازات وحسابات المستخدمين وسجل النظام. بعد إضافتها إلى مرحلة الربط، تمكن الرابط من حل الرموز الخارجية التي لم تكن محلولة سابقًا وإنشاء الملف التنفيذي.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe /link advapi32.lib

الشكل 9. نتيجة أمر الترجمة المُصحَّح.

الشكل 10. نتيجة الأمر الناجح.

الشكل 11. ملف rogue.exe الذي تم إنشاؤه في دليل العمل ~\Downloads\\

استجابة Microsoft Defender ونتيجة التنفيذ

أثناء التحقق، تم اكتشاف الملف التنفيذي الذي تم إنشاؤه فورًا بواسطة Microsoft Defender كـ Trojan:Win64/RoguePlanet.DA!MTB بمستوى خطورة "Severe". اقترح النظام إجراءات الحماية القياسية، مثل نقل الملف إلى العزل (Quarantine) أو حذفه.

الشكل 12. رسالة Windows التي تُعلم بأن الملف تم حظره كفيروس أو برنامج غير مرغوب فيه محتمل.

الشكل 13. كشف Microsoft Defender: Trojan:Win64/RoguePlanet.DA!MTB.

يعني هذا أن آليات الكشف في Defender حددت الأداة البرمجية المُجهزة على أنها ضارة أو يحتمل أن تكون خطيرة قبل أن تتمكن من التنفيذ بنجاح. من منظور حماية نقاط النهاية، هذه نتيجة إيجابية، لأن الحظر حدث في مرحلة الملف التنفيذي وليس فقط بعد ملاحظة آثار تنفيذ البرنامج.

بعد تعطيل الحماية في الوقت الفعلي مؤقتًا، أمكن تنفيذ الملف. تشير ملاحظة الاختبار إلى أنه بعد التنفيذ الثاني كان من الممكن الحصول على وحدة تحكم (Console) تعمل بامتيازات SYSTEM. تؤكد هذه النتيجة أن حماية Defender النشطة كانت مهمة في حظر الأداة البرمجية المختبرة.

الشكل 14. تنفيذ البرنامج في بيئة الاختبار بعد تعطيل الحماية في الوقت الفعلي.

الشكل 15. وحدة تحكم تعمل في سياق النظام في بيئة الاختبار.

تقييم المخاطر

لا يعني اكتشاف Microsoft Defender لملف محدد واحد أن خطر الثغرة قد تم القضاء عليه بالكامل. اكتشف Defender أداة برمجية معروفة أو مشابهة من أدوات إثبات المفهوم، بينما قد تتصرف نسخة معدلة من الكود، أو ترجمة مختلفة، أو بنية ملف متغيرة، أو مُحمّل آخر (Loader) بشكل مختلف فيما يتعلق بالكشف المستند إلى التوقيعات أو الكشف الاستدلالي (Heuristic). يجب التعامل مع نتيجة الاختبار على أنها تأكيد لفعالية طبقة الحماية الحالية ضد الأداة البرمجية المختبرة، وليس كدليل على أنه سيتم حظر كل متغير ممكن من التقنية.

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

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

9. التوصيات

يعد فرض إعدادات Microsoft Defender مركزيًا من خلال سياسات الأمان أمرًا بالغ الأهمية. يجب ألا يتمكن المستخدمون المحليون من تعطيل الحماية في الوقت الفعلي، أو إضافة استثناءات، أو السماح بتهديدات مكتشفة، أو تعديل إعدادات الحماية. في مثل هذا النموذج، يجب ألا يتمكن المستخدم من تجاوز الكشف بشكل مستقل عن طريق تحديد خيار مثل "Allow on device" أو عن طريق تعطيل الحماية مؤقتًا.

• فرض الحماية في الوقت الفعلي والحماية المقدمة عبر السحابة والإرسال التلقائي للعينات مركزيًا;

• منع المستخدمين من إدارة الاستثناءات والإجراءات الخاصة بالكشوفات;

• مراقبة أحداث Defender المتعلقة بالكشوفات والعزل ومحاولات السماح بالتهديدات والتغييرات في إعدادات الحماية;

• التعامل مع الكشف Trojan:Win64/RoguePlanet.DA!MTB كحدث أمني يتطلب التحليل;

• النظر في آليات إضافية تقيد تنفيذ الملفات التنفيذية غير المصرح بها، مثل قوائم السماح للتطبيقات (Application Allow-listing) أو WDAC أو AppLocker، وفقًا لقدرات البيئة.

الاستنتاجات النهائية

أكد الاختبار أن تجهيز الأداة البرمجية تطلب بيئة متوافقة مع سلسلة أدوات Microsoft الأصلية. أظهرت محاولة الترجمة باستخدام MinGW/G++ مشكلات توافق مع ملفات رأس وبنى NT API، بينما سمح الانتقال إلى MSVC وWindows SDK للعملية بالوصول إلى مرحلة الربط وإنشاء الملف التنفيذي في النهاية بعد إضافة مكتبة الاستيراد الصحيحة.

اكتشف Microsoft Defender الذي يعمل في الوضع العادي، مع توقيعات محدثة وحماية في الوقت الفعلي مفعّلة، الملف الذي تم إنشاؤه كـ Trojan:Win64/RoguePlanet.DA!MTB وحظر تنفيذه. هذه نتيجة اختبار إيجابية من منظور حماية نقاط النهاية.

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