DCSync في BloodHound: كيف تراجع صلاحيات النسخ في Active Directory بدون استخراج أسرار؟

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

ليش صلاحية النسخ تختلف عن قراءة دليل المستخدمين؟

في أغلب البيئات، يستطيع حساب عادي قراءة جزء كبير من معلومات الدليل التي تحتاجها تطبيقات الشركة. أسماء المستخدمين والمجموعات وعلاقاتها ليست مساوية لبيانات المصادقة الحساسة. لذلك لا يصح أن تنظر إلى حساب قادر على الاستعلام عن المستخدمين وتقول إن عنده DCSync. يوجد فرق بين قراءة خصائص متاحة عبر LDAP وبين حقوق خاصة مرتبطة بتكرار بيانات الدليل.
توضح Microsoft أن DS-Replication-Get-Changes حق ممتد لتكرار التغييرات من Naming Context معين. وتوضح أن DS-Replication-Get-Changes-All يتعلق بتكرار بيانات الدومين السرية. هذا الفرق الصغير في الاسم كبير في المعنى. وجود كلمة All ليس مجرد زيادة في عدد الصفوف التي يراها حساب التقارير؛ نحن نتكلم عن فئة بيانات ذات حساسية مختلفة.
خلنا نفترض أن فريق التقارير عنده خدمة تعرض أسماء الموظفين وأقسامهم. تحتاج الخدمة قراءة حقول محددة، ولا يصبح منحها حقوق نسخ بيانات حساسة منطقيًا لمجرد أنها «تقرأ من AD». في المقابل، قد توجد خدمة مزامنة لها حاجة موثقة لحقوق خاصة. الحكم المهني يتوقف على الوظيفة الفعلية، ونطاق الحق، وحماية هوية الخدمة، ومن يملك التحكم بها.
تبدأ المراجعة بتمييز هذه الحالات بدل جمعها تحت عبارة واحدة مثل صلاحيات عالية. هذا يساعد صاحب النظام يفهم السبب، ويساعدك أنت تتجنب توصية تزيل حقًا من مكوّن أساسي دون دراسة. اسأل ما البيانات المطلوبة وما الآلية المستخدمة ومن اعتمد التفويض، ثم قارن هذه الحاجة مع الحالة المقروءة فعلًا.

اقرأ علاقة DCSync كتركيب صلاحيات، مب سجل تنفيذ

توثيق BloodHound يصف علاقة DCSync بوصفها اجتماع GetChanges وGetChangesAll، ويجعل وجهتها كائن Domain. ظهورها يعبّر عن قدرة مستنتجة من الصلاحيات التي جُمعت. لا يقول إن الحساب استخرج بيانات، ولا يثبت أن شخصًا أساء استخدامها، ولا يحدد وقت حادث سابق.
إذا عرضت الأداة علاقة من مجموعة إلى الدومين، تحتاج معرفة أعضاء المجموعة والمسارات التي توصل إليها. قد يستفيد حساب من العضوية مباشرة، أو من مجموعة متداخلة، أو من القدرة على تغيير عضوية جهة مخولة. كل حالة لها دليل مختلف وتوصية مختلفة. لا تستبدل هذا التحليل بصورة لمسار أحمر ثم تنهي الفحص.
افتح تفاصيل العقد والعلاقة في نسخة BloodHound التي تعمل عليها، وسجل معرف الحساب والدومين وتاريخ الجمع. إذا كان ملف الجمع قديمًا، عامل النتيجة كفرضية تحتاج تحققًا حاليًا. قد يكون الفريق أزال العضوية أمس، بينما الرسم لا يزال يعرضها. وقد يكون الحساب تغير اسمه دون أن تتغير هويته، لذلك تفيد مطابقة SID بدل الاعتماد على الاسم الظاهر فقط.
النقطة المهمة أن الأدوات تلخص علاقات معقدة لتسهيل البحث، لكنها لا تلغي حاجتك لفهم المصدر. راجع نتيجة المجموعة مع بيانات الدليل الحالية، وحدد هل تتكلم عن حق مباشر أم أثر عضوية أم مسار تحكم. عندما تفصل هذه الطبقات، تقدر تشرح لماذا توجد المشكلة وأين يمكن كسرها بأقل تغيير ممكن.

نطاق الحق: على أي Naming Context وأي كائن؟

Naming Context أو NC جزء من بنية الدليل يجري التعامل معه كوحدة ضمن سياق التكرار. في هذا المثال نهتم بسياق الدومين lab.test. لا يكفي أن تجد اسم حق ممتد داخل ملف أذونات ثم تقول إنه ينطبق على كل الغابة. موضع الإذن والجهة المستفيدة ونوع التطبيق عناصر أساسية في الاستنتاج.
ابدأ بتحديد الدومين الذي فحصته، ووحدة التحكم التي قرأت منها، والاسم المميز لجذر الدومين. في بيئة تدريب مجهزة بـRSAT تستطيع قراءة الهوية الأساسية بأمر مثل: Get-ADDomain -Identity lab.test -Server dc01.lab.test | Select-Object DNSRoot,DistinguishedName,DomainSID. الناتج يساعدك تربط دليل الصلاحيات بكائن واضح، ولا يعطي بمفرده حكمًا على حقوق النسخ.
لو كان عندك أكثر من دومين، احتفظ بسجل منفصل لكل واحد. اسم المجموعة قد يتشابه، لكن SID الدومين والهوية الكاملة يمنعان خلط النتائج. كذلك لا تعتبر اتصالك بوحدة تحكم أخرى توسعة تلقائية للتصريح. مراجعة نطاق اختبارك تأتي قبل توسعة نطاق الاستعلام، خصوصًا إذا كانت الخدمة تتعامل مع عدة جهات أو بيئات.
في دليل النتيجة اكتب الكائن الذي وُجد عليه التفويض، لا تكتب «الشبكة كاملة» لأن التأثير يبدو كبيرًا. وإذا لم تستطع الوصول إلى ACL المطلوبة، اذكر هذا القيد واطلب تصديرًا معتمدًا من الفريق المسؤول. الصراحة بشأن حدود القراءة أفضل من بناء نتيجة واسعة على استعلام جزئي أو على اسم مجموعة يوحي بالقوة.

كيف تتبع المستفيد الحقيقي من الإذن؟

افترض أن مجموعة اسمها DirectorySyncOperators ظهرت مستفيدة من الحقوق. عندك ثلاث مسائل: أعضاء المجموعة الحاليون، من يستطيع تعديلها، وهل الحساب المستخدم للمزامنة داخلها بسبب حاجة فعلية. قراءة الأعضاء نقطة بداية، وليست كل المراجعة. الاسم المنظم لا يضمن أن العضوية منظمة.
استعلام القراءة في المختبر قد يكون: Get-ADGroupMember -Identity DirectorySyncOperators -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass,DistinguishedName. إذا ظهر عضو من نوع group، راجع مساره بشكل مستقل. لا تكتب أن قائمة المستوى الأول تمثل كل الأشخاص المستفيدين، ولا تتجاهل حسابات الكمبيوتر والخدمة لأنها ليست أسماء موظفين.
في ورقة العمل ضع سطرًا لكل مسار مؤثر: المستخدم، المجموعة الأولى، المجموعة المخولة، الحق على الدومين. ثم أضف عمودًا لمن يستطيع تعديل العضوية. قد لا يملك حساب الدعم حق النسخ اليوم، لكنه يملك صلاحية إضافة نفسه إلى مجموعة مخولة؛ هذا مسار تحكم مختلف عن الاستفادة المباشرة. يجب أن يظهر الفرق في التقرير حتى تكون المعالجة مفهومة.
اسأل عن مالك المجموعة وطريقة الموافقة على التغييرات. وجود مالك مسمى لا يثبت أن المراجعة تجري، لكنه يعطي نقطة متابعة. إذا لم يوجد صاحب واضح، تصبح إزالة الأعضاء المؤقتين والقدامى أصعب. وأثناء توثيق العضويات لا تنشر الأسماء الحقيقية في مقال أو تذكرة عامة؛ احتفظ بالتفاصيل في مساحة المشروع، واستخدم مثالًا اصطناعيًا عند مشاركة الدروس مع الآخرين.

قراءة ACL: التفاصيل التي تغيّر النتيجة

ACL قائمة الأذونات المرتبطة بالكائن. كل ACE داخلها يحمل معلومات عن الهوية والحق وطريقة التطبيق. عند مراجعة حقوق ممتدة، من المهم مطابقة معرف الحق مع تعريفه بدل تخمينه من ترجمة العرض. تسجل Microsoft معرف Get-Changes وهو 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2، ومعرف Get-Changes-All وهو 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2.
هذه المعرفات تفيد عند تفسير تصدير أذونات أُخذ بأداة معتمدة. لا يعني العثور على المعرف في النص وحده أن الحساب المطلوب مستفيد منه؛ تحتاج قراءة نوع ACE والجهة والكائن والسياق. وإذا احتوى التصدير على أسماء عرض فقط، اطلب توضيح الربط بين الاسم والحق بدل افتراض أن كل ExtendedRight هو نفس الصلاحية.
تجنب اختزال القراءة إلى علامة Allow منفردة. تفسير الوصول الفعلي قد يتأثر بمسار عضويات وهوية مختلفة وأذونات أخرى، لذلك اجمع المعلومات التي تخص الحالة كاملة. كما أن وجود حق إدارة الأذونات نفسه يستحق متابعة منفصلة: يستطيع تغيير من يحصل على الحق، لكنه ليس نفس حق النسخ الحالي. هذه الفروق تجعل الرسم أقل بساطة، لكنها تجعل المعالجة أكثر دقة.
إذا استخدمت واجهة Windows أو تصدير ACL، سجّل طريقة القراءة والوقت والكائن، وأرفق الجزء الذي يثبت الاستنتاج فقط. لا تحتاج عشرات الصفحات من أذونات لا علاقة لها بالنتيجة. يساعد مقتطف منظم مع تفسير واضح أكثر من ملف ضخم يُلقى على صاحب النظام ويُطلب منه اكتشاف المشكلة بنفسه.

سيناريو عملي: حساب تقارير دخل مجموعة المزامنة

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

المعالجة بدون تعطيل خدمة المزامنة

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

وش يكفي لإثبات النتيجة في التقرير؟

الدليل الجيد يربط السبب بالأثر دون حمل أسرار لا يحتاجها التقرير. أرفق هوية المجموعة والحساب الاصطناعية أو الحقيقية داخل المساحة المصرح بها، ومقتطف الأذونات، ومسار العضوية، ووقت التحقق. ثم وضح لماذا لا يحتاج الحساب المقصود هذه الحقوق وفق وظيفة التطبيق الموثقة.
اكتب مثلًا: «حساب خدمة التقارير يستفيد عبر مجموعة مخولة من حقوق تكرار تتضمن بيانات حساسة على دومين المشروع، رغم أن وظيفته المعتمدة قراءة بيانات تنظيمية محددة». هذه صياغة تحدد الاستنتاج وحدوده. لا تقل إن بيانات كل المستخدمين سُرقت إذا لم يحدث ذلك، ولا تحول قدرة تقنية إلى ادعاء حادث.
تحديد الخطورة يأخذ حساسية الحق واتساع الدومين وسهولة التحكم بالحساب ومدى وجود حاجة مشروعه. لا تضع رقمًا بناء على اسم DCSync وحده، ولا تخفضها لأن الحساب ليس Domain Admin. نوع الصلاحية هو الموضوع، والعضوية الإدارية المشهورة ليست الطريق الوحيد إلى تأثير كبير.
خلال إعادة الاختبار احتفظ بنتيجة قبل وبعد على نفس الكائن والحساب. تحقق من قراءة حالية، لا من صور قديمة، واذكر إن بقيت خدمة مشروعة مخولة. الهدف مب الوصول إلى دومين بلا أي حقوق نسخ؛ الهدف إزالة الوصول غير الضروري وحماية الوصول الضروري. بهذا تكون النتيجة مفيدة لفريق التشغيل وفريق الأمن معًا، وتقدر تشرحها للقارئ بدون أمر واحد لاستخراج أسرار.
المراجع: تعريف Get-Changes في Microsoft: https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes وتعريف Get-Changes-All: https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all وتفسير علاقة DCSync في BloodHound: https://bloodhound.specterops.io/resources/edges/dc-sync . قراءة هذه المراجع هنا لفهم الحقوق وبنية العلاقة؛ لا تحتاج أقسام تشغيل الهجوم كي تثبت زيادة التفويض في مراجعة أذونات. وأي اختلاف بين جمع الأداة والقراءة الحالية يستحق تفسيرًا مستقلًا قبل اعتماد الإغلاق.