RBCD وBloodHound: الفرق بين AllowedToAct وAddAllowedToAct، وكيف تراجع الثقة على المورد؟

تشوف خطًا في BloodHound اسمه AllowedToAct، ثم خطًا آخر باسم AddAllowedToAct. الاسمان قريبان، لكن السؤال الذي يجيب عنه كل واحد مختلف. الأول يرتبط بعلاقة تفويض موجودة، والثاني بقدرة على تعديل الإعداد الذي يحدد العلاقة. إذا خلطت الاثنين، قد تبحث عن طرف داخل قائمة الثقة وهو لا يوجد فيها أصلًا، أو تكتب أن حسابًا يستطيع تعديل الإعداد بينما الرسم يعرض له علاقة قائمة فقط. خلنا نمسك Resource-Based Constrained Delegation من جهة المورد ونرتب الأدلة: الكائن الذي يستقبل التفويض، الأطراف الموجودة، وصلاحيات تغيير هذا الحد. المثال تطبيق تعليمي على APP01 داخل lab.test، والمراجعة قراءة وتحليل في مختبر مصرح دون تعديل العلاقة أو تنفيذ انتحال لهوية أي مستخدم.

علاقة الثقة وحق تعديلها ليسا نفس الشيء

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

AllowedToAct وAddAllowedToAct يساعدانك تميز هذا الفرق داخل نموذج BloodHound. توثيق SpecterOps يربط AddAllowedToAct بقدرة تعديل خاصية msDS-AllowedToActOnBehalfOfOtherIdentity على الهدف. أما علاقة AllowedToAct فتصف إمكانية التصرف عبر RBCD باتجاه الكمبيوتر المحدد وفق المعلومات المجموعة وشروط النموذج.

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

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

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

ابدأ من الحساب الذي تعمل به الخدمة الخلفية

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

أمر القراءة المحدد:

Get-ADComputer -Identity APP01 -Server dc01.lab.test -Properties PrincipalsAllowedToDelegateToAccount | Select-Object Name,DistinguishedName,SID,PrincipalsAllowedToDelegateToAccount

Microsoft توضح استخدام الخاصية PrincipalsAllowedToDelegateToAccount لقراءة الأطراف التي يمكنها التصرف نيابة عن المستخدمين نحو خدمات تعمل بالحساب المقصود. الأمر لا ينشئ علاقة جديدة، ولا يضيف طرفًا، ولا يعطيك دليلًا على عملية وصول فعلية. اقرأ اسم الكائن وDistinguishedName حتى تتأكد أنك سألت عن المورد نفسه الذي ظهر في الرسم.

إذا ظهر WEB01، لا تحول النتيجة إلى «WEB01 يستطيع الوصول لكل شيء في الدومين». العلاقة لها هدف محدد وسياق تفويض، بينما صلاحيات المستخدم على الموارد وشروط المسار تبقى أسئلة أخرى. ضع الأثر في حد المورد الذي تراجعه، ثم اسأل عن حساسيته وعن الهوية التي يحتاجها التطبيق.

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

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

الخاصية الداخلية تصف التفويض، أما ACL الكائن فتصف إدارته

اسم الخاصية الداخلية msDS-AllowedToActOnBehalfOfOtherIdentity طويل، لكنه يشرح الغرض: تحديد من يسمح له بالتصرف نيابة عن هويات أخرى نحو الخدمات التي تعمل بهذا الحساب. توثيق Microsoft يصف استخدامها في فحوص الوصول المرتبطة بهذا السؤال، ويعرض تعريفها ضمن مخطط Active Directory.

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

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

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

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

كيف تقرأ خط BloodHound بدون القفز إلى الاستغلال؟

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

لعلاقة AllowedToAct، قارن الطرف بالإعداد المقروء من المورد في نفس الفترة. إن تطابقا، لديك دعم من مصدرين للحالة التي تراجعها. اسأل الآن عن المبرر: هل الطرف هو الواجهة المعتمدة؟ هل هناك طرف قديم؟ وهل الهوية والخدمة والعميل ضمن التصميم المقصود؟ تطابق الأدوات لا يعني أن التصميم مناسب، لكنه يعطيك أرضية أفضل للمناقشة.

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

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

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

ثلاث نتائج محتملة على نفس المورد

الأولى: APP01 يسمح لواجهة WEB01، والعلاقة مطابقة لوثيقة التطبيق، ومن يدير الإعداد هم المسؤولون المعتمدون ضمن نطاق واضح. هذه ليست ملاحظة سلبية لمجرد أنها تظهر في BloodHound. يمكنك توثيق العلاقة وحدود تحققك، ثم مراجعة أي شروط أخرى في الخطة دون افتعال مشكلة.

الثانية: APP01 يسمح أيضًا لواجهة قديمة OLDWEB لم يقدم الفريق حاجة لبقائها. لديك طرف إضافي في الثقة الحالية. الخطوة التالية تحديد مالكه واعتماد التطبيقات قبل المعالجة. وجود كلمة OLD في الاسم ليس الدليل؛ المقارنة مع التصميم الحالي وإجابة المالك والبيانات التشغيلية هي ما يفسر سبب اعتباره زائدًا.

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

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

وفي تحديد الأثر، قارن حساسية APP01 بما تستطيع الخدمة فعله وبمن يستخدم المسار. مورد بيانات تعليمية مختلف عن مورد حساس في العمل. لا تستخدم أعلى مستوى خطورة لمجرد وجود اختصار RBCD؛ اشرح لماذا يمثل هذا الحد خطرًا في البيئة التي راجعتها، وعلى أي دليل بنيت درجة الثقة في الاستنتاج.

خطط للمعالجة مع مالك التطبيق ومالك الهوية

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

إذا كان المطلوب تقليل قدرة إدارة الإعداد، راجع ACE المقصودة ومصدرها وما الوظائف الأخرى التي تمنحها. إزالة مجموعة كاملة من صلاحيات إدارة OU قد تؤثر في مهام دعم لا علاقة لها بـRBCD. التوصية الأفضل تصف الحق والنطاق غير المطلوب، وتطلب إعادة تصميم تفويض الإدارة على قدر الحاجة مع خطة تحقق.

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

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

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

ماذا تضع في تقرير RBCD وإعادة الاختبار؟

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

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

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

المراجع:
https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/cea4ac11-a4b2-4f2d-84cc-aebb4a4ad405
https://learn.microsoft.com/en-us/windows/win32/secauthz/aces-to-control-access-to-an-object-s-properties
https://bloodhound.specterops.io/resources/edges/allowed-to-act
https://bloodhound.specterops.io/resources/edges/add-allowed-to-act

إذا قدرت تفرق بين «من هو موثوق الآن؟» و«من يستطيع تغيير الثقة؟»، فقد أمسكت أهم جزء في مراجعة RBCD. الأدوات تساعدك تجمع الإجابة، لكن جودة العمل تأتي من ربطها بالمورد والهوية والتوقيت والحاجة الفعلية.

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

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