هيكل `OB_CALLBACK` المذكور أعلاه غير موثق أيضًا، ويتم تعريفه على النحو التالي:```C
typedef struct OB_CALLBACK_t {
    USHORT Version;                           // usually 0x100
    USHORT OperationRegistrationCount;        // number of registered callbacks
    PVOID RegistrationContext;                // arbitrary data passed at registration time
    UNICODE_STRING AltitudeString;            // used to determine callbacks order
    struct OB_CALLBACK_ENTRY_t EntryItems[1]; // array of OperationRegistrationCount items
    WCHAR AltitudeBuffer[1];                  // is AltitudeString.MaximumLength bytes long, and pointed by AltitudeString.Buffer
} OB_CALLBACK;

جعل المؤشرين `Flink` و `Blink` لقائمة `LIST_ENTRY` الخاصة بـ `CallbackList` يشيران إلى `LIST_ENTRY` نفسها يجعل القائمة فارغة فعليًا. نظرًا لأن بنية `_OBJECT_TYPE` منشورة في رموز النواة، فإن هذه التقنية لا تعتمد على إزاحات/هياكل ثابتة. ومع ذلك، فإن لها بعض العيوب.

العيب الأول هو عدم القدرة على تعطيل الاستدعاءات من EDR فقط؛ بل تؤثر هذه التقنية على جميع استدعاءات الكائنات التي قد تكون مسجلة بواسطة برامج "شرعية". ومع ذلك، تجدر الإشارة إلى أن استدعاءات الكائنات لا تُستخدم بواسطة أي مكون مثبت مسبقًا في ويندوز 10 (في وقت كتابة هذا التقرير)، لذا فإن تعطيلها لا ينبغي أن يؤثر على استقرار الجهاز (حتى أكثر من ذلك إذا كان التعطيل مؤقتًا).

العيب الثاني هو أن عمليات مقابض العمليات أو مؤشرات الترابط متكررة جدًا (شبه مستمرة) في الأداء الطبيعي لنظام التشغيل. ونتيجة لذلك، إذا كانت بدائية كتابة النواة المستخدمة لا تستطيع إجراء كتابة `QWORD` "ذرية"، فهناك احتمال كبير أن يتم الوصول إلى مؤشر `_OBJECT_TYPE.CallbackList.Flink` بواسطة النواة في منتصف استبداله. على سبيل المثال، يمكن لبرنامج تشغيل MSI الضعيف `RTCore64.sys` إجراء كتابة `DWORD` فقط في كل مرة، لذا ستكون هناك حاجة إلى طلبي IOCTL منفصلين لاستبدال المؤشر، وبينهما تكون النواة عرضة لاستخدامه (مما يؤدي إلى تعطل). من ناحية أخرى، يمكن لبرنامج تشغيل DELL الضعيف `DBUtil_2_3.sys` إجراء كتابات بأحجام عشوائية في طلب IOCTL واحد، لذا فإن استخدام هذه الطريقة معه لا يخاطر بالتسبب في تعطل.

#### تعطيل استدعاءات الكائنات بالكامل
تقنية أخيرة وجدناها هي تعطيل دعم استدعاءات الكائنات بالكامل لمؤشرات الترابط والعمليات. داخل بنية `_OBJECT_TYPE` المقابلة لأنواع العمليات ومؤشرات الترابط يوجد حقل `TypeInfo`، الذي يتبع بنية `_OBJECT_TYPE_INITIALIZER` الموثقة. يحتوي الحقل الأخير على حقل بت `ObjectTypeFlags`، حيث تحدد العلامة `SupportsObjectCallbacks` ما إذا كان نوع الكائن الموصوف (عملية، مؤشر ترابط، سطح مكتب، رمز مميز، ملف، إلخ) يدعم تسجيل استدعاءات الكائنات أم لا. كما ذكرنا سابقًا، فقط أنواع الكائنات لعملية ومؤشر ترابط وسطح مكتب تدعم هذه الاستدعاءات على تثبيت ويندوز في وقت كتابة هذا التقرير.

نظرًا لأن بت `SupportsObjectCallbacks` يتم التحقق منه بواسطة `ObpCreateHandle` أو `ObDuplicateObject` قبل قراءة `CallbackList` (وقبل تنفيذ الاستدعاءات بالطبع)، فإن قلب البت في وقت تشغيل النواة يؤدي فعليًا إلى تعطيل تنفيذ جميع استدعاءات الكائنات.

العيب الرئيسي لهذه الطريقة هو ببساطة أن *KPP* ("*PatchGuard*") يراقب سلامة بعض (كل؟) بنى `_OBJECT_TYPE`، ويطلق [`0x109 Bug Check`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption) مع المعامل 4 يساوي `0x8`، مما يعني أنه تم تغيير بنية نوع كائن.

ومع ذلك، فإن القيام بالتعطيل / إعادة التمكين (والعمل "الضار" بينهما) بسرعة كافية يجب أن يكون كافيًا لـ "مسابقة" *PatchGuard* (إلا إذا كنت غير محظوظ وتم إجراء فحص دوري في اللحظة الخطأ).

### تجاوز EDR عن طريق فصل استدعاءات المرشحات الصغيرة (minifilters)
يسمح نظام مدير المرشحات (Filter Manager) في ويندوز لـ EDR بتحميل برنامج تشغيل "مرشح صغير" (minifilter) وتسجيل استدعاءات ليتم إخطاره بعمليات الإدخال/الإخراج، مثل فتح الملفات، القراءة، الكتابة، إلخ.

فيما يلي ملخص سريع للهياكل الداخلية المختلفة المستخدمة بواسطة مدير المرشحات:
- ينشئ مدير المرشحات "إطارًا" (`_FLTP_FRAME`) كهيكل جذر له؛
- يتم إنشاء بنية "حجم" (`_FLT_VOLUME`) لكل "قرص" يديره مدير المرشحات (يمكن أن يكون أقسامًا، نسخًا احتياطية للظل، أو أقراصًا خاصة تتوافق مع الأنابيب المسماة أو أنظمة الملفات البعيدة)؛
- لكل برنامج تشغيل مرشح صغير مسجل، يقابل بنية "مرشح" (`_FLT_FILTER`)، تصف خصائص مختلفة مثل العمليات التي يدعمها؛
- هذه المرشحات الصغيرة ليست كلها متصلة بكل حجم؛ يتم إنشاء بنية "مثيل" (`_FLT_INSTANCE`) لتمييز كل من ارتباطات المرشح<->الحجم؛
- تسجل المرشحات الصغيرة وظائف استدعاء يتم تنفيذها قبل و/أو بعد عمليات محددة (فتح ملف، كتابة، قراءة، إلخ). يتم وصف هذه الاستدعاءات في هياكل `_CALLBACK_NODE`، ويمكن الوصول إليها بطرق مختلفة:
  - يمكن العثور على مصفوفة من جميع `_CALLBACK_NODE` المنفذة بواسطة مثيل مرشح صغير في بنية `_FLT_INSTANCE`؛ يتم فهرسة المصفوفة برمز "الوظيفة الرئيسية" لـ IRP، وهو ثابت يمثل العمليات التي تعالجها الاستدعاءات (`IRP_MJ_CREATE`، `IRP_MJ_READ`، إلخ).
  - أيضًا، يتم تجميع جميع `_CALLBACK_NODE` المنفذة بواسطة مثيلات مرتبطة بحجم معين في قوائم مرتبطة، مخزنة في مصفوفة `_FLT_VOLUME.Callbacks.OperationLists` المفهرسة برموز الوظيفة الرئيسية لـ IRP.

يتم تصفح هذه الهياكل المختلفة بواسطة `EDRSandblast` لاكتشاف المرشحات المرتبطة ببرامج تشغيل متعلقة بـ EDR، ويتم تعداد عقد الاستدعاء التي تحتوي على وظائف المراقبة. لتعطيل تأثيرها، يتم فصل العقد من قوائمها، مما يجعلها غير مرئية مؤقتًا لمدير المرشحات.

بهذه الطريقة، خلال فترة محددة، يمكن لـ EDR أن يكون غير مدرك تمامًا لأي عمليات ملفات. مثال أساسي هو إنشاء ملف تفريغ لذاكرة lsass على القرص، والذي لن يؤدي إلى أي تحليل من EDR، وبالتالي لا اكتشاف بناءً على الملف نفسه.

### تجاوز EDR عن طريق تعطيل مزود ETW Microsoft-Windows-Threat-Intelligence

يسجل مزود `ETW Microsoft-Windows-Threat-Intelligence` بيانات حول استخدام بعض واجهات برمجة التطبيقات لويندوز المستخدمة بشكل خبيث في العادة. يشمل ذلك واجهة برمجة التطبيقات `nt!MiReadWriteVirtualMemory`، التي تستدعيها `nt!NtReadVirtualMemory` (التي تُستخدم لتفريغ ذاكرة `LSASS`) ويتم مراقبتها بواسطة دالة `nt!EtwTiLogReadWriteVm`.

يمكن لمنتجات EDR استهلاك السجلات المنتجة من مزود `ETW TI` من خلال خدمات أو عمليات تعمل، على التوالي، كـ `SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT` أو `PS_PROTECTED_ANTIMALWARE_LIGHT`، ومرتبطة ببرنامج تشغيل `Early Launch Anti Malware (ELAM)`.

كما نُشر بواسطة [`slaeryan` في منشور مدونة `CNO Development Labs`](https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider)، يمكن تعطيل مزود `ETW TI` بالكامل عن طريق تصحيح، في ذاكرة النواة، السمة `ProviderEnableInfo` الخاصة به إلى `0x0`. راجع منشور المدونة الرائع المذكور أعلاه لمزيد من المعلومات حول هذه التقنية.

على غرار إزالة استدعاءات النواة، يتم حساب إزاحات `ntoskrnl.exe` الضرورية (`nt!EtwThreatIntProvRegHandleOffset`، و `_ETW_REG_ENTRY`'s `GuidEntry`، و `_ETW_GUID_ENTRY`'s `ProviderEnableInfo`) في ملف `NtoskrnlOffsets.csv` لعدد من إصدارات نواة ويندوز.

### تجاوز EDR عن طريق تجاوز التوصيل في وضع المستخدم (userland hooking)
#### كيف يعمل التوصيل في وضع المستخدم
من أجل مراقبة الإجراءات التي تقوم بها العمليات بسهولة، غالبًا ما تنشر منتجات EDR آلية تسمى *التوصيل في وضع المستخدم*. أولاً، تسجل منتجات EDR استدعاء نواة (عادةً استدعاءات *تحميل الصورة* أو *إنشاء العملية*، انظر أعلاه) التي تسمح لها بأن يتم إخطارها عند بدء كل عملية.

عندما يتم تحميل عملية بواسطة ويندوز، وقبل أن تبدأ فعليًا، يكون EDR قادرًا على حقن بعض ملفات DLL المخصصة في مساحة عنوان العملية، والتي تحتوي على منطق المراقبة الخاص بها. أثناء التحميل، تقوم ملفات DLL هذه بحقن "*خطافات*" في بداية كل وظيفة من المقرر مراقبتها بواسطة EDR. في وقت التشغيل، عندما يتم استدعاء الوظائف المراقبة بواسطة العملية تحت المراقبة، تقوم هذه الخطافات بإعادة توجيه تدفق التحكم إلى بعض كود الإشراف الموجود في ملف DLL الخاص بـ EDR، مما يسمح له بفحص الوسائط وقيم الإرجاع لهذه الاستدعاءات.

في معظم الأحيان، تكون الوظائف المراقبة هي استدعاءات نظام (مثل `NtReadVirtualMemory`، `NtOpenProcess`، إلخ)، التي توجد تطبيقاتها في `ntdll.dll`. اعتراض استدعاءات دوال `Nt*` يسمح للمنتجات بأن تكون قريبة قدر الإمكان من الحدود بين وضع المستخدم ووضع النواة (مع البقاء في وضع المستخدم)، ولكن يمكن أيضًا مراقبة دوال من ملفات DLL ذات مستوى أعلى.

فيما يلي أمثلة لنفس الدالة، قبل وبعد أن يتم توصيلها بواسطة منتج EDR:```assembly
NtProtectVirtualMemory   proc near
	mov r10, rcx
	mov eax, 50h
	test byte ptr ds:7FFE0308h, 1
	jnz short loc_18009D1E5
	syscall
	retn
loc_18009D1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp			

#### كشف الخطافات
تمتلك الخطافات في مساحة المستخدم "ضعف" كونها موجودة في ذاكرة مساحة المستخدم، مما يعني أنها
قابلة للملاحظة والتعديل مباشرة من قبل العملية قيد المراقبة. للكشف التلقائي عن
الخطافات في مساحة عناوين العملية، الفكرة الرئيسية هي مقارنة الفروقات بين
ملف DLL الأصلي على القرص والمكتبة المقيمة في الذاكرة، التي قد تكون تم
تعديلها بواسطة EDR. لإجراء هذه المقارنة، يتبع EDRSandblast الخطوات التالية:
* يتم تعداد قائمة جميع ملفات DLL المحملة بفضل `InLoadOrderModuleList` الموجودة
  في `PEB` (لتجنب استدعاء أي API قد يكون مراقبًا ومريبًا)
* لكل DLL تم تحميله، يتم قراءة محتواه على القرص وتحليل رؤوسه. كما يتم
  تحليل المكتبة المقابلة الموجودة في الذاكرة لتحديد الأقسام، التصديرات،
  إلخ.
* يتم تحليل وتطبيق عمليات إعادة التوطين (Relocations) الخاصة بـ DLL، مع أخذ العنوان الأساسي
  للمكتبة المحملة المقابلة في الاعتبار. يتيح ذلك أن يكون محتوى كل من المكتبة
  في الذاكرة و DLL القادم من القرص متطابقين تمامًا (في الأقسام التي يتم فيها تطبيق
  عمليات إعادة التوطين)، مما يجعل المقارنة موثوقة.
* يتم تعداد الدوال المُصدَّرة ومقارنة البايتات الأولى من الإصدارات "في الذاكرة" و"على القرص".
  أي اختلاف يشير إلى تغيير تم إجراؤه بعد تحميل DLL، وبالتالي فمن المحتمل جدًا
  أن يكون خطاف EDR.

ملاحظة: يمكن تعميم العملية للعثور على اختلافات في أي مكان في الأقسام غير القابلة للكتابة
وليس فقط في بداية الدوال المُصدَّرة، على سبيل المثال إذا بدأت منتجات EDR في تطبيق
الخطافات في منتصف الدالة :) وبالتالي لا يُستخدم ذلك بواسطة الأداة، ولكن تم
تنفيذه في `findDiffsInNonWritableSections`.

من أجل تجاوز المراقبة التي تقوم بها هذه الخطافات، هناك تقنيات متعددة
ممكنة، ولكل منها مزايا وعيوب.

#### تجاوز الخطاف باستخدام ... إزالة الخطاف
الطريقة الأكثر بديهية لتجاوز المراقبة القائمة على الخطافات هي إزالة
الخطافات. نظرًا لأن الخطافات موجودة في ذاكرة يمكن للعملية نفسها الوصول إليها،
فيمكن للعملية ببساطة:
* تغيير صلاحيات الصفحة حيث يوجد الخطاف (RX -> RWX أو RW)
* كتابة البايتات الأصلية المعروفة بفضل محتوى DLL على القرص
* إعادة تغيير الصلاحيات إلى RX

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

ومع ذلك، له عيبان رئيسيان. من المحتمل أن EDR يراقب استخدام
`NtProtectVirtualMemory`، لذا فإن استخدامه لتغيير صلاحيات الصفحة التي تم
تثبيت الخطافات فيها هو (من الناحية النظرية على الأقل) فكرة سيئة. أيضًا، إذا تم
تنفيذ خيط بواسطة EDR ويقوم بفحص دوري لسلامة الخطافات، فقد يؤدي ذلك أيضًا
إلى إثارة بعض الاكتشاف.

للحصول على تفاصيل التنفيذ، راجع مسار الكود الخاص بالدالة `unhook()` عندما تكون
`unhook_method` هي `UNHOOK_WITH_NTPROTECTVIRTUALMEMORY`.

**ملاحظة مهمة: من أجل البساطة، تم تنفيذ هذه التقنية في EDRSandblast كتقنية
أساسية تستخدم *لعرض* تقنيات التجاوز الأخرى؛ كل منها يوضح كيفية الحصول
على نسخة غير مراقبة من `NtProtectVirtualMemory`، ولكنها تؤدي نفس العملية
بعد ذلك (إزالة خطاف معين).**

#### تجاوز الخطاف باستخدام ترامبولين مخصص
لتجاوز خطاف معين، من الممكن ببساطة "القفز فوقه" وتنفيذ بقية الدالة
كما هي. أولاً، يجب استعادة البايتات الأصلية للدالة المراقبة، التي تم
استبدالها بواسطة EDR لتثبيت الخطاف، من ملف DLL. في مثال الكود السابق،
ستكون هذه هي البايتات المقابلة للتعليمات التالية:```assembly
mov r10, rcx
mov eax, 50h

أخيرًا، نقوم بتجميع هذه الأوبكودات، وتخزينها في ذاكرة قابلة للتنفيذ (حديثة الإنشاء)، والاحتفاظ بمؤشر لها. يُطلق على هذا الكائن اسم "*trampoline*" ويمكن استخدامه بعد ذلك كمؤشر دالة، مكافئ تمامًا لدالة `NtProtectVirtualMemory` الأصلية.

الميزة الرئيسية لهذه التقنية، كما هو الحال في جميع التقنيات أدناه، هي أن الخطاف لا يتم محوه أبدًا، لذا يجب أن تنجح أي عملية تحقق من سلامة الخطافات التي يقوم بها نظام EDR. ومع ذلك، يتطلب الأمر تخصيص ذاكرة قابلة للكتابة ثم قابلة للتنفيذ، وهو أمر نموذجي لتخصيص الشيل كود، مما يجذب انتباه نظام EDR.

للحصول على تفاصيل التنفيذ، راجع مسار الكود الخاص بدالة `unhook()` عندما تكون `unhook_method` هي `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`. يُرجى تذكر أن التقنية معروضة فقط في تنفيذنا، وفي النهاية تُستخدم **لإزالة** الخطافات من الذاكرة، كما هو الحال في كل تقنية أدناه.

#### تجاوز الخطاف باستخدام الترامبولين الخاص بنظام EDR نفسه
لكي يعمل خطاف منتج EDR، يجب عليه حفظ الأوبكودات التي أزالها في مكان ما في الذاكرة. والأسوأ (*أو "الأفضل"، من وجهة نظر المهاجم*)، لاستخدام التعليمات الأصلية بشكل فعال، فمن المحتمل أن يكون نظام EDR قد خصص لنفسه *trampoline* في مكان ما لتنفيذ الدالة الأصلية بعد اعتراض الاستدعاء.

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

للعثور على الترامبولين في الذاكرة، نتصفح مساحة العنوان بالكامل باستخدام `VirtualQuery` بحثًا عن ذاكرة ملتزمة وقابلة للتنفيذ. لكل منطقة من هذه المناطق، نقوم بمسحها بحثًا عن تعليمة قفز تستهدف العنوان الذي يلي التعليمات المستبدلة (`NtProtectVirtualMemory+8` في مثالنا السابق). يمكن بعد ذلك استخدام الترامبولين لاستدعاء الدالة المُخطّط لها دون تفعيل الخطاف.

تعمل هذه التقنية بشكل جيد بشكل مفاجئ لأنها تستعيد جميع الترامبولينات تقريبًا على أنظمة EDR المختبرة. للحصول على تفاصيل التنفيذ، راجع مسار الكود الخاص بدالة `unhook()` عندما تكون `unhook_method` هي `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`.

#### تجاوز الخطاف باستخدام نسخة مكررة من DLL
طريقة بسيطة أخرى للحصول على نسخة غير مراقبة من دالة `NtProtectVirtualMemory` هي تحميل نسخة مكررة من مكتبة `ntdll.dll` في مساحة عنوان العملية. نظرًا لأنه يمكن تحميل مكتبتي DLL متطابقتين في نفس العملية، بشرط أن يكون لهما أسماء مختلفة، يمكننا ببساطة نسخ ملف `ntdll.dll` الشرعي إلى موقع آخر، وتحميله باستخدام `LoadLibrary` (أو إعادة تنفيذ عملية التحميل)، والوصول إلى الدالة باستخدام `GetProcAddress` على سبيل المثال.

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

ومع ذلك، تم تنفيذ هذه التقنية في `EDRSandblast`. للحصول على تفاصيل التنفيذ، راجع مسار الكود الخاص بدالة `unhook()` عندما تكون `unhook_method` هي `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY`.

#### تجاوز الخطاف باستخدام استدعاءات النظام المباشرة
من أجل استخدام الوظائف المتعلقة باستدعاءات النظام، يمكن للبرنامج إعادة تنفيذ استدعاءات النظام (بالتجميع) لاستدعاء ميزات نظام التشغيل المقابلة دون لمس الكود الموجود في `ntdll.dll`، والذي قد يكون مراقبًا من قبل نظام EDR. وهذا يتجاوز تمامًا أي خطافات على مستوى المستخدم تتم على دوال استدعاء النظام في `ntdll.dll`.

ومع ذلك، لهذا بعض العيوب. أولاً، هذا يعني القدرة على معرفة قائمة أرقام استدعاءات النظام للوظائف التي يحتاجها البرنامج، والتي تتغير مع كل إصدار من Windows. يتم التخفيف من هذا مع ذلك من خلال تنفيذ عدة إرشادات استدلالية يُعرف أنها تعمل في جميع الإصدارات السابقة من Windows NT (ترتيب تصديرات `Zw*` في `ntdll`، والبحث عن تعليمة `mov rax, #syscall_number` في دالة `ntdll` المرتبطة، إلخ.)، والتحقق من أن جميعها تُرجع نفس النتيجة (انظر `Syscalls.c` لمزيد من التفاصيل).

أيضًا، قد تكون الدوال التي ليست استدعاءات نظام من الناحية الفنية (مثل `LoadLibraryX`/`LdrLoadDLL`) مراقبة أيضًا، ولا يمكن إعادة تنفيذها ببساطة باستخدام استدعاء نظام.

تقنية استدعاءات النظام المباشرة منفذة في EDRSandblast. كما ذكرنا سابقًا، تُستخدم فقط لتنفيذ `NtProtectVirtualMemory` بأمان، وإزالة جميع الخطافات المكتشفة.

للحصول على تفاصيل التنفيذ، راجع مسار الكود الخاص بدالة `unhook()` عندما تكون `unhook_method` هي `UNHOOK_WITH_DIRECT_SYSCALL`.

### استغلال برامج التشغيل الثغرة
كما ذكرنا سابقًا، كل إجراء يتطلب قراءة أو كتابة في ذاكرة kernel يعتمد على برنامج تشغيل ثغرة لتوفير هذه البدائية. في EDRSanblast، يمكن إضافة دعم لبرنامج تشغيل جديد يوفر بدائية القراءة/الكتابة "بسهولة"، حيث يلزم تنفيذ ثلاث دوال فقط:
* دالة `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`، تنسخ `Size` بايت من عنوان kernel `Address` إلى المخزن المؤقت للمستخدم `Buffer`؛
* دالة `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`، تنسخ `Size` بايت من المخزن المؤقت للمستخدم `Buffer` إلى عنوان kernel `Address`؛
* دالة `CloseDriverHandle_DRIVERNAME()` تضمن إغلاق جميع المقابض لبرنامج التشغيل (مطلوبة قبل عملية الإلغاء المستقلة عن برنامج التشغيل، في الوقت الحالي).

كمثال، هناك برنامجان تشغيل مدعومان حاليًا بواسطة EDRSandblast، `RTCore64.sys`
(SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`)
و`DBUtils_2_3.sys` (SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`).
يجب تحديث الكود التالي في `KernelMemoryPrimitives.h` إذا كان برنامج التشغيل الثغرة المستخدم بحاجة إلى التغيير، أو إذا تم تنفيذ برنامج تشغيل جديد.```C
#define RTCore 0
#define DBUtil 1
// Select the driver to use with the following #define
#define VULN_DRIVER RTCore

#if VULN_DRIVER == RTCore
#define DEFAULT_DRIVER_FILE TEXT("RTCore64.sys")
#define CloseDriverHandle CloseDriverHandle_RTCore
#define ReadMemoryPrimitive ReadMemoryPrimitive_RTCore
#define WriteMemoryPrimitive WriteMemoryPrimitive_RTCore
#elif VULN_DRIVER == DBUtil
#define DEFAULT_DRIVER_FILE TEXT("DBUtil_2_3.sys")
#define CloseDriverHandle CloseDriverHandle_DBUtil
#define ReadMemoryPrimitive ReadMemoryPrimitive_DBUtil
#define WriteMemoryPrimitive WriteMemoryPrimitive_DBUtil
#endif

### الخيارات```
-h | --help             Show this help message and exit.
-v | --verbose          Enable a more verbose output.

Actions mode:

        audit                     Display the user-land hooks and / or Kernel callbacks without taking actions.
        dump                      Dump the process specified by --process-name (LSASS process by default), as '<process_name>' in the current directory or at the
                                  specified file using -o | --output <DUMP_FILE>.
        cmd                       Open a cmd.exe prompt.
        credguard                 Patch the LSASS process' memory to enable Wdigest cleartext passwords caching even if
                                  Credential Guard is enabled on the host. No kernel-land actions required.
        firewall                  Add Windows firewall rules to block network access for the EDR processes / services.
        load_unsigned_driver      Load the specified unsigned driver, bypassing Driver Signature Enforcement (DSE).
                                  WARNING: currently an experimental feature, only works if KDP is not present and enabled.

--usermode              Perform user-land operations (DLL unhooking).
--kernelmode            Perform kernel-land operations (Kernel callbacks removal and ETW TI disabling).


Hooking-related options:

--add-dll <dll name or path>            Loads arbitrary libraries into the process' address space, before starting
                                        anything.This can be useful to audit userland hooking for DLL that are not
                                        loaded by default by this program. Use this option multiple times to load
                                        multiple DLLs all at once.
                                        Example of interesting DLLs to look at: user32.dll, ole32.dll, crypt32.dll,
                                        samcli.dll, winhttp.dll, urlmon.dll, secur32.dll, shell32.dll...

--unhook-method <N>                     Choose the userland un-hooking technique, from the following:

        0                               Do not perform any unhooking (used for direct syscalls operations).
        1 (Default)                     Uses the (probably monitored) NtProtectVirtualMemory function in ntdll to remove all
                                        present userland hooks.
        2                               Constructs a 'unhooked' (i.e. unmonitored) version of NtProtectVirtualMemory, by                                        allocating an executable trampoline jumping over the hook, and remove all present
                                        userland hooks.
        3                               Searches for an existing trampoline allocated by the EDR itself, to get an 'unhooked'
                                        (i.e. unmonitored) version of NtProtectVirtualMemory, and remove all present userland
                                        hooks.
        4                               Loads an additional version of ntdll library into memory, and use the (hopefully                                        unmonitored) version of NtProtectVirtualMemory present in this library to remove all
                                        present userland hooks.
        5                               Allocates a shellcode that uses a direct syscall to call NtProtectVirtualMemory,                                        and uses it to remove all detected hooks

--direct-syscalls       Use direct syscalls to dump the selected process memory without unhooking unserland hooks.


BYOVD options:

--dont-unload-driver                    Keep the vulnerable driver installed on the host
                                        Default to automatically unsinstall the driver.
--no-restore                            Do not restore the EDR drivers' Kernel Callbacks that were removed.
                                        Default to restore the callbacks.
--vuln-driver <gdrv.sys>                Path to the vulnerable driver file.
                                        Default to 'gdrv.sys' in the current directory.
--vuln-service <SERVICE_NAME>           Name of the vulnerable service to intall / start.


Driver sideloading options:

--unsigned-driver <evil.sys>            Path to the unsigned driver file.
                                        Default to 'evil.sys' in the current directory.
--unsigned-service <SERVICE_NAME>       Name of the unsigned driver's service to intall / start.
--no-kdp                                Switch to g_CiOptions patching method for disabling DSE (default is callback swapping).


Offset-related options:

--nt-offsets <NtoskrnlOffsets.csv>      Path to the CSV file containing the required ntoskrnl.exe's offsets.
                                        Default to 'NtoskrnlOffsets.csv' in the current directory.
--fltmgr-offsets <FltmgrOffsets.csv>    Path to the CSV file containing the required fltmgr.sys's offsets
                                        Default to 'FltmgrOffsets.csv' in the current directory.
--wdigest-offsets <WdigestOffsets.csv>  Path to the CSV file containing the required wdigest.dll's offsets
                                        (only for the 'credguard' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
--ci-offsets <CiOffsets.csv>            Path to the CSV file containing the required ci.dll's offsets
                                        (only for the 'load_unsigned_driver' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
-i | --internet                         Enables automatic symbols download from Microsoft Symbol Server
                                        If a corresponding *Offsets.csv file exists, appends the downloaded offsets to the file for later use
                                        OpSec warning: downloads and drops on disk a PDB file for the corresponding image

Dump options:

-o | --dump-output <DUMP_FILE>          Output path to the dump file that will be generated by the 'dump' mode.
                                        Default to 'process_name' in the current directory.
--process-name <NAME>                   File name of the process to dump (defaults to 'lsass.exe')

## الكشف

من وجهة نظر المدافع (بائع EDR، مايكروسوفت، محللي SOC الذين يفحصون تتبع EDR، ...)، يمكن استخدام عدة مؤشرات للكشف عن هذا النوع من التقنيات أو منعها.

### القائمة البيضاء للسائقين

نظراً لأن كل إجراء يقوم به الأداة في ذاكرة وضع النواة يعتمد على سائق ضعيف لقراءة/كتابة محتوى عشوائي، يجب أن تخضع أحداث تحميل السائقين للتدقيق الشديد من قبل منتج EDR (أو محللي SOC)، وإثارة تنبيه عند أي تحميل غير معتاد للسائق، أو حتى حظر السائقين الضعفاء المعروفين. هذا النهج الأخير موصى به [حتى من قبل مايكروسوفت نفسها](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules): أي جهاز ويندوز مُمكّن HVCI (*حماية سلامة الكود المحمية بمراقب الآلة*) يحتوي على قائمة حظر للسائقين، وسيصبح هذا بشكل تدريجي سلوكاً افتراضياً على ويندوز (وهو بالفعل كذلك على ويندوز 11).

### فحوصات سلامة ذاكرة النواة

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

كملاحظة جانبية، يمكن حماية هذا النوع من هياكل البيانات عبر آلية [حماية بيانات النواة (KDP)](https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/) الحديثة، التي تعتمد على الأمان المستند إلى الآلة الافتراضية، لجعل مصفوفة استدعاءات النواة غير قابلة للكتابة دون استدعاء APIs الصحيحة.

يمكن تطبيق نفس المنطق على متغيرات ETW الحساسة مثل `ProviderEnableInfo`، الذي أساءت هذه الأداة استخدامه لتعطيل توليد أحداث ETW Threat Intelligence.

### الكشف في وضع المستخدم

المؤشر الأول على وجود عملية تحاول بنشاط التهرب من ربط وضع المستخدم هو الوصول إلى ملفات كل DLL المقابلة للوحدات المحملة؛ في التنفيذ العادي، نادراً ما تحتاج عملية وضع المستخدم إلى قراءة ملفات DLL خارج استدعاء `LoadLibrary`، خاصة `ntdll.dll`.

لحماية ربط API من الالتفاف، يمكن لمنتجات EDR التحقق بشكل دوري من أن الخطافات لم يتم تغييرها في الذاكرة، داخل كل عملية مراقبة.

أخيراً، للكشف عن تجاوز الربط (استغلال ترامبولين، استخدام استدعاءات نظام مباشرة، إلخ) الذي لا يتضمن إزالة الخطافات، يمكن لمنتجات EDR الاعتماد على استدعاءات النواة المرتبطة باستدعاءات النظام المستغلة (مثال: `PsCreateProcessNotifyRoutine` لاستدعاء النظام `NtCreateProcess`، `ObRegisterCallbacks` لاستدعاء النظام `NtOpenProcess`، إلخ)، وإجراء تحليل مكدس استدعاءات وضع المستخدم لتحديد ما إذا كان استدعاء النظام قد تم تشغيله من مسار عادي (`kernel32.dll` -> `ntdll.dll` -> استدعاء نظام) أو مسار غير عادي (مثال: `program.exe` -> استدعاء نظام مباشر).

## الإشادات

- تعداد وإزالة استدعاءات النواة:
  https://github.com/br-sn/CheekyBlinder

- بدائيات القراءة/الكتابة في ذاكرة النواة من خلال السائق الضعيف
  `Micro-Star MSI Afterburner`:
  https://github.com/Barakat/CVE-2019-16098/

- تعطيل موفر ETW Threat Intelligence:
  https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider

- تثبيت / إلغاء تثبيت السائق: https://github.com/gentilkiwi/mimikatz

- قائمة أولية بأسماء سائقين EDR:
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- تجاوز Credential Guard عن طريق إعادة تمكين `Wdigest` عبر تصحيح ذاكرة
  `LSASS`: https://teamhydra.blog/2020/08/25/bypassing-credential-guard/


## المؤلفون

[Thomas DIOT (Qazeer)](https://github.com/Qazeer/)
[Maxime MEIGNAN (themaks)](https://github.com/themaks)

## شكر للمساهمين
- [v1k1ngfr](https://github.com/v1k1ngfr): لتجاوز التحقق من توقيع السائق (عبر تصحيح `g_CiOptions`) ودعم سائق GDRV.sys
- [Windy Bug](https://github.com/0mWindyBug): لتجاوز التحقق من توقيع السائق المتوافق مع KDP (عبر *تبديل الاستدعاء*) ومساهمتهم الكبيرة في ميزة تجاوز minifilter


## الترخيص

ترخيص CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/