RemoteMonologue: استغلال DCOM في فرض مصادقة NTLM

أيام الحصول على بيانات الاعتماد باستخدام Mimikatz من دون عناء، بكل إيجابياتها وسلبياتها، تقترب من نهايتها. مع تقوية Microsoft لدفاعاتها ضد سرقة بيانات الاعتماد ومواصلة تطوير حلول اكتشاف نقاط النهاية والاستجابة لها، تواجه تقنيات الفريق الأحمر التقليدية مثل الحركة الجانبية، وتنفيذ الحمولة، والوصول المباشر إلى خدمة النظام الفرعي لسلطة الأمان المحلية (LSASS) المزيد من التدقيق. ونتيجة لذلك، اضطر مجتمع الفريق الأحمر إلى استكشاف طرق بديلة لجمع بيانات الاعتماد من أنظمة Windows.

تخيل تحقيق نتائج قابلة للمقارنة من دون الحاجة إلى حمولة "متقدمة" أو الوصول إلى LSASS، وذلك ببساطة من خلال "العيش على أرض الواقع" والاستفادة من كائنات نموذج كائن العنصر (COM) غير المستغلة بشكل كافٍ. إذا كان ذلك يثير اهتمامك، فتابعنا، لأن هذه المدونة مليئة بالحيل الممتعة التي يمكنك استخدامها في مهمتك القادمة.

سنتناول بإيجاز أساسيات COM ونظيره الموزع، نموذج كائن العنصر الموزع (DCOM)، ونتناول بالتفصيل إعداد RunAs وسبب تأثير عمليات فرض المصادقة، ونقدم أداة جديدة لجمع بيانات الاعتماد - RemoteMonologue.

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

بالنسبة إلى هذه المدونة، المفاهيم الأساسية التي يجب فهمها هي ما يلي:

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

على المستوى العام، فكر في كائنات COM كوحدات مستقلة ذات عنصرين رئيسيين:

• الخصائص: تمثل حالة الكائن أو تكويناته.
• الدوال: تمثل الإجراءات التي يمكن للكائن تنفيذها. على سبيل المثال، قد يحتوي كائن COM على دالة لتشغيل عملية أو إنشاء ملف أو بدء طلب مصادقة.

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

قبل الحديث عن التفاصيل الممتعة، يوجد عنصر مهم من عناصر COM يجب مناقشته بمزيد من التفصيل. يعمل معرف التطبيق (AppID) في COM كآلية رئيسية لإدارة الأمان والهوية وسلوك وقت التشغيل لتطبيقات COM، خاصة في السيناريوهات التي تتضمن DCOM أو التطبيقات التي تتطلب سياقات أمنية محددة. عند تسجيل فئة COM مع معرّف AppID، فإنها ترث إعدادات الأمان المحددة لهذا المعرّف.

يتمثل إعداد الأمان ذو الأهمية الخاصة في مفتاح RunAs، والذي يحدد حساب المستخدم الذي سيُستخدم لتنفيذ كائن DCOM عند إنشاء المثيل. يمكن العثور على مفتاح RunAs في السجل ضمن:

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

في أثناء مراجعة وثائق Microsoft حول DCOM ومفتاح RunAs، برزت قيمة محددة: المستخدم التفاعلي. تعمل هذه القيمة على تكوين كائن DCOM لتنفيذه ضمن سياق أمان المستخدم المسجل دخوله حاليًا إلى جلسة وحدة التحكم الخاصة بالنظام. من منظور هجومي، هذا أمر مثير للاهتمام لأنه يمكن أن يسمح لنا بالاستفادة من كائنات DCOM للعمل كمستخدم آخر من دون معرفة بيانات اعتماد المستخدم المتأثر.

ليست جميع كائنات DCOM التي لديها معرّف AppID لها قيمة RunAs معينة على المستخدم التفاعلي. في الواقع، ما يقرب من نصف معرّفات AppIDs ليس لديها قيمة RunAs معينة على الإطلاق. لكن، ماذا لو أمكن إضافة قيمة RunAs أو تعديلها بما يتناسب مع أغراضنا؟

بشكل افتراضي، معرّف AppID في السجل يكون محميًا باستخدام قائمة نسبية للتحكم بالوصول(DACL)، ما يمنح TrustedInstaller امتيازات الملكية ويقصر صلاحيات المسؤولين المحليين على الوصول للقراءة فقط، كما هو موضح في الشكل 1.

ومع ذلك، يُمنح المسؤولون المحليون امتياز SeTakeOwnershipPrivilege، والذي يسمح لهم بالحصول على ملكية كائنات النظام، بما في ذلك مفاتيح السجل. ويُعد هذا الامتياز مهمًا لهذا الهجوم لأنه يتيح لنا تغيير ملكية المعرّف AppID. بمجرد تغيير الملكية، يمكننا منح أنفسنا أذونات تحكم كاملة في معرّف AppID وتعديل إعداداته لاحقًا لإضافة قيمة RunAs أو تغييرها.

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

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

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

توجد عدة مزايا رئيسية لفرض عمليات مصادقة NTLM بدلاً من تنفيذ تقنيات الحركة الجانبية التقليدية:

• تسجيل قيم تجزئة NTLMv1/NTLMv2 ومحاولة اختراقها في وضع عدم الاتصال
• إعادة توجيه قيم تجزئة NTLMv1 أو WebDAV NTLMv2 إلى خدمات الشبكة الأخرى، مثل LDAP أو SMB، لتنفيذ إجراءات كمستخدم متأثر
• تجنب نقل وتشغيل أي حمولة على النظام المستهدف، والذي عادةً ما يتطلب مزيدًا من التدقيق من أدوات الأمان
• تجنب التفاعل مع عملية LSASS، ما يقلل من مخاطر الاكتشاف

حتى تاريخ كتابة هذا المنشور، لم يكن توقيع LDAP وربط القناة مطلوبين أو مفروضين بشكل افتراضي على معظم وحدات التحكم في النطاق. وتُعد مزايا الأمان هذه مفروضة فقط على Windows Server 2025. وهذا يعني أنه إذا تمكنا من فرض مصادقة NTLMv1 أو WebDAV من النظام المستهدف، فيمكننا إعادة توجيهها إلى LDAP وتنفيذ الإجراءات بصفتنا المستخدم المتأثر. وبالمثل، لا يلزم وجود توقيع SMB بشكل افتراضي على خوادم Windows، باستثناء وحدات التحكم في النطاق.

ثمة أمر آخر مهم ينبغي أن يؤخذ في الحسبان وهو أن قيم تجزئة NTLMv1 يمكن اختراقها بسهولة باستخدام جداول قوس قزح، والتي شاركها علنًا Nic Losby في ديسمبر 2024. تقلل هذه الجداول بشكل كبير من الوقت والجهد اللازمين لاستعادة بيانات اعتماد NTLM من قيم تجزئة NTLMv1. للحصول على تجزئة NTLMv1 بدلاً من تجزئة NTLMv2، نعدل مفتاح التسجيل التالي على النظام المستهدف:

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

يؤدي تعيين قيمة LmCompatibilityLevel على 2 أو أقل إلى إجبار النظام على الرجوع إلى الإصدار NTLMv1 للمصادقة. ويكون هذا التعديل ممكنًا من خلال امتيازات المسؤول المحلي ويشار إليه عمومًا باسم "هجوم الرجوع إلى الإصدار الأقدم NetNLMv1".

أو يمكننا تسجيل مصادقة WebDAV وإعادة توجيهها إلى LDAP، حيث يمكن إعادة توجيه عمليات المصادقة المستندة إلى HTTP إلى هذه الخدمة. إذا لم تكن خدمة WebClient تعمل بالفعل بامتيازات وصول، فيمكننا تمكينها عن بُعد على النظام المستهدف. وبمجرد التمكين، يمكننا فرض مصادقة WebDAV NTLM على برنامج التجسس لدينا عن طريق تحديد اسم NetBIOS الخاص بالجهاز في مسار UNC. على سبيل المثال:

• \\MYHACKERBOX@80\giveme\creds.txt

لمزيد من المعلومات حول هجمات إعادة توجيه NTLM والبروتوكولات التي يمكن إعادة توجيهها إلى نقاط النهاية المختلفة، يُرجى الرجوع إلى المصدر التالي هنا.

في أثناء بحثي، حللت كائن DCOM المسمى ServerDataCollectorSet، والذي يحتوي على CLSID {03837546-098B-11D8-9414-505054503030}لتحديد الدوال والخصائص التي يمكن الاستفادة منها لفرض المصادقة. ومن بين الخصائص التي برزت DataManager، ولحسن الحظ، تضمن كائن COM هذا مكتبة أنواع، والتي تحدد دواله وخصائصه بمزيد من التفصيل.

باستخدام OleView.NET، استعرضت مكتبة أنواع ServerDataCollectorSet واكتشفت أن خاصية DataManager تحتوي على دالة Extract تتوقع معلمتين:

1. CabFilename - اسم ملف CAB المراد استخراجه.
2. DestinationPath – المسار المطلوب لاستخراج محتويات ملف CAB.

كان وجود معلمة CabFilename مثيرًا للاهتمام بشكل خاص لأنه يشير إلى إمكانية توفير مسار UNC، ما قد يؤدي إلى إجراء مصادقة الشبكة.

ولاختبار هذه النظرية، قدمت مسار UNC لمعلمة CabFilename التي تشير إلى نظامي (172.22.164.58) الذي يشغل Responder، كما هو موضح في الشكل 4. والنتيجة؟ لقد نجح الأمر! تمكنا من تسجيل تجزئة NTLMv2، كما هو موضح في الشكل 5.

بعد ذلك، اختبرت ما إذا كان من الممكن تسجيل بيانات الاعتماد الخاصة بمستخدم مختلف على نظام بعيد (172.22.166.170) عن طريق تعديل مفتاح RunAs الخاص بالدالة ServerDataCollectorSet. ولتحقيق ذلك، استخدمت خدمة السجل البعيد لإضافة قيمة المستخدم التفاعلي لمعرّف AppID {03837503-098B-11D8-9414-505054503030}.

بمجرد تسجيل دخول مستخدم آخر إلى النظام المستهدف (وهو في هذه الحالة، GALAXY\yoda)، وصلت إلى كائن DCOM المسمى ServerDataCollectorSet بصفتي GALAXY\Administrator ونفّذت دالة Extract نفسها الموضحة في الشكل 6. ومرة أخرى، نجحت في الحصول على بيانات المصادقة ؛ ولكن، هذه المرة من خلال GALAXY\yoda، كما هو موضح في الشكل 7. وذلك يوضح أن تعديل مفتاح RunAs إلى المستخدم التفاعلي يتيح لنا الاستفادة من كائنات DCOM لاختراق الجلسات من حلال مستخدمين آخرين.

يظهر مسار هذا الهجوم في المخطط أدناه.

يوجد كائن DCOM آخر مهم عرضة لفرض المصادقة وهو FileSystemImage، والذي يحتوي على CLSID{2C941FC5-975B-59BE-A960-9A2A262853A5}. ويُعد هذا الكائن فريدًا بشكل خاص لأن فرض المصادقة يُنفذ عن طريق تعديل الخاصية ببساطة بدلاً من استدعاء الدالة - وهي تقنية أقل شيوعًا في الهجمات المستندة إلى DCOM.

الخاصية المعنية هي WorkingDirectory، والتي تشير بشكل افتراضي إلى مجلد %TEMP% الخاص بالمستخدم التفاعلي. ومع ذلك، من خلال تغيير قيمة WorkingDirectory إلى مسار UNC الذي يشير إلى أداة التجسس لدينا، من الممكن تسجيل مصادقة NTLMv2، كما هو موضح في الشكلين 9 و10.

للتحقق من إمكاناته في اختراق جلسات العمل، اختبرت ذلك عن بُعد عن طريق ضبط مفتاح RunAs الخاص بمعرّف AppID {2C941FD1-975B-59BE-A960-9A2A262853A5} على المستخدم التفاعلي. أدى هذا التكوين إلى تشغيل كائن DCOM المسمى FileSystemImage لتنفيذه ضمن السياق الأمني للمستخدم النشط على النظام المستهدف. وكما هو متوقع، تمكنت من تسجيل تجزئة NTLMv2 الخاصة بهذا المستخدم.

توضح هذه التقنية أن عمليات فرض المصادقة يمكن تحقيقها من خلال تعديل الخصائص وكذلك الدوال، ومن ثَم توسيع نطاق الهجوم المحتمل لكائنات DCOM.

كائن DCOM الأخير الذي يستحق الحديث عنه هو UpdateSession، والذي يحتوي على CLSID.{4CB43D7F-7EEE-4906-8698-60DA1C38F2FE} عند مراجعة مكتبة الأنواع الخاصة به، برزت دالة AddScanPackageService لأنها تتطلب وسيطة serviceName، والأكثر إثارة للاهتمام، وسيطة scanFileLocation. يشير وجود scanFileLocation إلى أنه قد يقبل مسار UNC.

عند اختبار هذه النظرية، تمكنا من تسجيل مصادقة NTLMv2 بنجاح، ولكن بدلاً من تلقي بيانات اعتماد حساب المستخدم، تلقينا بيانات اعتماد حساب الجهاز، كما هو موضح أدناه.

وهذا الاكتشاف مثير للاهتمام بشكل خاص لأنه حتى بعد إضافة مفتاح RunAs وتعيينه إلى مستخدم تفاعلي، لا يزال كائن DCOM المسمى UpdateSession ينفذ عمليات الشبكة بصفته حساب الجهاز. إذن، ما سبب حدوث ذلك؟ الجواب البسيط هو أنه بينما يشغل كائن DCOM نفسه ضمن سياق الأمان الخاص بالمستخدم الذي يُنشئ المثيل أو المستخدم التفاعلي، فإن عمليات الشبكة تنفذها عملية منفصلة: svchost.exe. يُنقل مسار UNC إلى svchost.exe، والذي يُعيّن افتراضيًا دائمًا إلى حساب SYSTEM لتنفيذ هذه العمليات. ولذلك، لا يؤثر إعداد مفتاح RunAs في هذا السلوك.

على الرغم من أن مفتاح RunAs لا يؤثر في الحساب المستخدم في عمليات الشبكة، إلا أن تسجيل بيانات اعتماد حساب الجهاز لا يزال ذا قيمة في عدة سيناريوهات هجوم:

1. الحصول على أذونات DACL المهمة في Active Directory:
   يمكن لحسابات الأجهزة (مثل DOMAIN\MACHINE$) الحصول على أذونات لكائنات محددة في Active Directory قد تكون مفيدة للحركة الجانبية أو زيادة الامتيازات.
2. تزوير التذاكر الفضية لتعزيز التخفي:
   يمكننا استخدام تجزئة NTLM الخاصة بحساب على الجهاز لتزوير تذكرة فضية، ما يسمح لنا بانتحال هوية أي مستخدم على النظام وتنفيذ إجراءات مع تقليل مخاطر الاكتشاف.

وقد أُطلق على هذا الهجوم اسم RemoteMonologue، لأنه يعمل بشكل يشبه InternalMonologue، مع فارق رئيسي في أنه ينفذ الهجوم عن بُعد. طُورت الأداة باستخدام Python ومكتبة Impacket وهي تؤتمت عملية الهجوم.

توفر RemoteMonologue إمكانية استهداف أي من كائنات DCOM الثلاثة المذكورة (-dcom) لفرض المصادقة على أداة التجسس المحددة (-auth-to). بالإضافة إلى ذلك، تحتوي على وحدة نشر (-spray) للتحقق من صحة بيانات الاعتماد عبر أنظمة متعددة، مع ميزة إضافية تتمثل في تسجيل بيانات الاعتماد. وتدعم الأداة أيضًا هجوم الرجوع إلى الإصدار الأقدم NetNTLMv1 (-downgrade)، وتحتوي على خيار لتمكين خدمة WebClient بهدف تسهيل مصادقة HTTP (-webclient). وأخيرًا، تتضمن الأداة وحدة استعلام (-query) لتعداد المستخدمين الذين لديهم جلسة نشطة على النظام المستهدف.

فيما يلي مثال على تشغيل RemoteMonologue بهجوم الرجوع إلى الإصدار الأقدم NetNTLMv1 في أثناء استخدام Responder كأداة التجسس. بشكل افتراضي، في حال عدم تحديد خيار DCOM، تستخدم الأداة كائن DCOM المسمى ServerDataCollectorSet.

فيما يلي مثال آخر. هذه المرة، يُنفذ الهجوم باستخدام كائن DCOM المسمى FileSystemImage وتمكين خدمة WebClient من الحصول على مصادقة HTTP، والتي يُعاد توجيهها بعد ذلك إلى LDAP باستخدام ntlmrelayx.

للتصدي لهذه التقنيات الموضحة في هذه المدونة واكتشافها، يمكن تنفيذ عدة تدابير وقائية وتدابير الاكتشاف.

التدابير الوقائية:

1. تمكين توقيع LDAP وربط القناة: أعمل على تكوين فرض توقيع LDAP وربط القناة على وحدات التحكم في النطاق لحماية نقطة نهاية LDAP من هجمات إعادة التوجيه. ملاحظة: ستُفرض هذه الإعدادات بشكل افتراضي بدايةً من إصدار Windows Server 2025.
2. الترقية إلى أحدث إصدارات Windows: احرص على ترقية الخوادم إلى إصدار Windows Server 2025 والأجهزة إلى الإصدار 24H2 من Windows 11 للحد من هجمات الرجوع إلى إصدار أقدم من NetNTLM، حيث أُزيل NTLMv1 من هذه الإصدارات.
3. فرض توقيع SMB: مكّن توقيع SMB وافرضه على خوادم Windows لمنع هجمات إعادة توجيه SMB.
4. تطبيق سياسات كلمات مرور قوية: افرض متطلبات كلمات مرور قوية لجعل هجمات اختراق كلمات المرور أكثر صعوبة.

فرص الاكتشاف:

1. مراقبة الوصول عن بُعد إلى كائنات DCOM: تتبع الوصول إلى كائنات DCOM المتأثرة وخصائصها ودوالها الخاصة لتحديد النشاط غير المعتاد.
2. مراقبة تعديلات التسجيل: راقب التغييرات التي تطرأ على مفاتيح التسجيل RunAs وLmCompatibilityLevel.
3. تتبع نشاط خدمة WebClient: راقب الحالات التي يُجرى فيها تمكين خدمة WebClient عن بُعد، حيث يُستخدم ذلك لتسهيل عمليات مصادقة NTLM المستندة إلى HTTP.

يوضح هجوم RemoteMonologue إمكانية استغلال كائنات DCOM غير المستغلة لتنفيذ هجمات فرض مصادقة خفية من دون ملفات. من خلال تعديل خصائص محددة والاستفادة من تقنيات مثل الرجوع إلى الإصدار الأقدم NetNTLMv1، يمكن للمهاجمين اختراق حسابات المستخدمين وزيادة الامتيازات من دون نشر حمولات أو الوصول المباشر إلى عمليات حساسة مثل LSASS.

من خلال الاهتمام بتعزيز أمان الأنظمة الرئيسية، مثل فرض توقيع LDAP وتوقيع SMB وتعطيل البروتوكولات القديمة مثل NTLMv1، يمكن لفرق الحماية تقليل نطاق الهجوم بشكل كبير. وعلاوة على ذلك، يمكن أن تساعد المراقبة الفائقة لتعديلات التسجيل ونشاط DCOM وتغييرات الخدمات عن بُعد على اكتشاف هذه التقنيات في مراحلها المبكرة والحد من تأثيرها.