شرح SharpHound بالعربي: اجمع بيانات الدومين وافهم وش دخل فعلًا إلى BloodHound

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

وش الفرق بين أداة الجمع وواجهة التحليل؟

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

قبل التشغيل: اكتب السؤال في سطر واحد

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

اختيار نوع الجمع يغيّر معنى النتيجة

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

تأكد من النسخة والبيئة قبل نسخ الأمر

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

تجربة أولى لجمع عضويات المجموعات

داخل اللاب المصرح، ومن جلسة الحساب التدريبي المناسبة، استخدم هذا المثال بعد التأكد من توافقه مع مساعدة نسختك:
./SharpHound.exe --CollectionMethods Group --Domain lab.test --OutputDirectory .
الجزء الأول يشغّل الملف من المجلد الحالي. اختيار Group يحدد سؤال العضويات، واسم الدومين يحدد البيئة، والنقطة الأخيرة تعني استخدام المجلد الحالي لحفظ الناتج. اختَر مجلد عمل مخصصًا تستطيع الكتابة فيه، بحيث ما تختلط ملفات هذه التجربة بملفات تجارب سابقة.
قبل ضغط Enter، اقرأ الأمر بصوتك أو اكتبه بصياغة عربية قصيرة: «أجمع عضويات المجموعات من دومين التدريب وأحفظ الناتج هنا». إذا ما قدرت تشرح أحد أجزائه، خذ دقيقة وافهمه. هذه العادة البسيطة تفيدك مع أي أداة ثانية، خصوصًا إذا أصبحت الأوامر أطول وفيها خيارات كثيرة.
راقب بداية التشغيل ونهايته وما يظهر بينهما من تحذيرات. لا تكتف بصورة لآخر سطر. دوّن وقت التنفيذ والحساب المستخدم والطريقة المختارة. هذه التفاصيل تساعدك عند مقارنة ملفين يحملان أسماء متشابهة، أو عندما يسألك شخص آخر: هل هذه الخريطة تصف اللاب قبل تغيير العضوية أو بعده؟
المثال تعليمي محدود، وليس تصريحًا لفحص شبكة عمل كاملة أو ضمانًا بأن كل البيانات المتوقعة ستكون قابلة للقراءة في أي بيئة.

طلع ملف مضغوط؛ وش أراجع قبل رفعه؟

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

بعد الاستيراد: اختبر علاقة تعرفها مسبقًا

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

ثلاث حالات متشابهة ظاهريًا، لكن تشخيصها مختلف

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

لا تصلح مشكلة الاتصال بتعطيل الحماية

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

تمرين مقارنة يعطيك فهمًا أفضل من تكرار التشغيل

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

وش تكتب في ملاحظاتك أو تقريرك؟

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

المراجع والخطوة اللي بعدها

ابدأ الآن بتجربة عضوية واحدة تستطيع شرحها من الطرفين: من أين جُمعت، وكيف ظهرت، وما الذي تثبته، وما الذي لا تثبته. بعد ما تضبطها، انتقل إلى مراجعة أذونات كائنات الدليل بوصفها سؤالًا جديدًا له بياناته وحدوده. ما تحتاج تجمع كل شيء في أول جلسة عشان تعتبر أنك تعلمت الأداة.
لشرح قراءة الخريطة نفسها، ارجع لمقال المجتمع «شرح BloodHound بالعربي: كيف تقرأ أول خريطة صلاحيات وتطلع منها بفهم؟»:
https://courses.cyberpts.com/community/60/shrh-bloodhound-balarby-kyf-tqra-awl-khryth-slahyat-wttla-mnha-bfhm
توثيق أنواع الجمع والخيارات لدى SpecterOps:
https://bloodhound.specterops.io/collect-data/ce-collection/sharphound-flags
تعريف أداة الجمع وتوافقها مع نسخة المجتمع:
https://bloodhound.specterops.io/collect-data/ce-collection/sharphound
مصدر الصورة الخارجية: إعلان SpecterOps لنسخة المجتمع، بقلم Andy Robbins، بتاريخ 8 أغسطس 2023:
https://specterops.io/blog/2023/08/08/bloodhound-community-edition-a-new-era/
راجع توثيق نسختك قبل التنفيذ؛ أسماء الخيارات وسلوك الإصدارات قد يتغيران. أما عادة تحديد السؤال ومراجعة التغطية وتوثيق حدود النتيجة، فهي الشيء الذي يستحق تبقى عليه حتى لو غيرت أداة الجمع بالكامل.