شرح PowerView: كيف تفهم أوامر الدومين وليش تختلف عن Get-ADUser وGet-ADGroupMember؟

تتابع شرحًا للاكتف دايركتوري وتشوف أمر Get-DomainUser. تفتحه في PowerShell عندك، وتطلع رسالة أن الأمر غير معروف. تبحث عن الحل، فتلقى شخصًا يستخدم Get-ADUser وشخصًا ثانيًا يقول إن عنده نسخة مختلفة من PowerView. المشكلة هنا غالبًا مو في الدومين؛ أنت تخلط بين أدوات لها أسماء قريبة لكن مصادرها وطريقة تجهيزها مختلفة.
خلنا نرتب الصورة بتجربة صغيرة: قراءة حساب تدريبي، ثم مراجعة أعضاء مجموعة، ثم مقارنة نفس السؤال بأوامر مايكروسوفت. بنستخدم أمثلة قراءة محددة، ونوضح المقصود بالنسخة الكلاسيكية بدل افتراض أن أي مشروع يحمل الاسم نفسه يطابقها. الهدف أنك إذا دخلت لاب جديد تعرف ماذا تسأل الأداة وكيف تفسر جوابها، لا أنك تحفظ قائمة طويلة من الدوال.
الصورة التالية من شرح PowerView في Oste’s Blog، وتعرض حقول المجموعة والعضو في لاب المصدر. ليست تنفيذًا لأسماء اللاب المستخدمة هنا، والغرض توضيح شكل الناتج. المصدر: https://05t3.github.io/posts/PowerView-Walkthrough/

قبل أي أمر: أي PowerView تقصد؟

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

جهّز جلسة معروفة المصدر ثم اختبر المساعدة

الأمثلة التالية تفترض أن مسؤول اللاب جهّز نسخة موثوقة ومعتمدة من الدوال في جلسة تدريب مصرح بها. لا يوجد هنا أمر ينزّل سكربتًا من الإنترنت ويشغله مباشرة. تعلّم فصل الحصول على الأداة ومراجعتها عن استخدامها، بدل دمج الخطوتين في سطر لا تقرأ محتواه.
بعد تجهيز الدوال، افحص ما هو متاح في الجلسة:
Get-Command Get-DomainUser
Get-Help Get-DomainUser -Full
الهدف أن تتأكد من وجود الاسم وتقرأ المعاملات المتاحة في النسخة المحملة. إذا كانت الدالة غير معروفة، فأنت ما وصلت بعد إلى مشكلة هوية أو اتصال بالدومين. راجع تجهيز الجلسة مع المسؤول، ولا تبدأ بتغيير إعدادات حماية الجهاز كي تجعل الاسم يظهر بأي طريقة.
إذا ظهرت الدالة، راجع المساعدة قبل استعارة أمر من فيديو. هل يقبل Domain؟ هل توجد Properties؟ ما صيغة Identity التي يتوقعها؟ هل الاسم في الشرح يخص نفس الدالة أم اسمًا قديمًا أو بديلًا؟ هذه أسئلة بسيطة، لكنها تختصر كثيرًا من المحاولات العشوائية.
لا تجعل رفع صلاحيات الجلسة أول خطوة تشخيص لكل خطأ. قد يكون السبب أنك تستخدم معاملًا غير موجود أو أنك لم تحمّل الدوال أصلًا. تغيير مستوى الصلاحيات يضيف متغيرًا جديدًا، وقد يوسع أثر التجربة من غير أن يعالج السبب الحقيقي.
وفي بيئة مؤسسة، تشغيل أداة اختبار يحتاج أن يكون ضمن الإجراء المسموح به. إذا أوقفها نظام الحماية، سجل الحدث وراجعه مع المسؤول عن المهمة. المطلوب هنا فهم القراءة والتحليل، وليس إخفاء الأداة أو تجاوز ضوابط التشغيل. اللاب المعزول مكان مناسب لتعلم السلوك بدون العبث بجهاز عمل فعلي.

أول تجربة: مستخدم واحد وخصيصتان فقط

حدد حسابًا تدريبيًا تعرف أنه موجود، مثل student داخل lab.test. في النسخة الكلاسيكية الموثقة، يمكن قراءة الحساب مع خصائص محددة هكذا:
Get-DomainUser -Identity student -Domain lab.test -Properties samaccountname,distinguishedname
لا تبدأ بطلب كل المستخدمين وكل الخصائص إذا كان سؤالك عن هوية واحدة. الناتج المحدود يسهل عليك مراجعة الكائن المقصود وموقعه، ويجعل سبب أي اختلاف أوضح.
اقرأ اسم الحساب والاسم المميز معًا. الأول يسهل التعرف عليه، والثاني يوضح مكان الكائن في بنية الدليل. إذا كنت تتوقع حسابًا في وحدة التدريب لكنه ظهر في مكان آخر، لا تعدّل المخرجات كي توافق توقعك؛ اسأل هل الحساب نُقل أو هل اخترت هوية غير التي يقصدها المسؤول.
الخطوة التالية هي المقارنة بأمر إدارة مناسب، إذا كانت وحدة مايكروسوفت متاحة ومصرحًا باستخدامها:
Get-ADUser -Identity student -Server dc01.lab.test | Select-Object SamAccountName,DistinguishedName
قبل المقارنة، تأكد أن الطرفين يراجعان نفس البيئة والكائن والوقت التقريبي. اختلاف الاسم أو الخادم أو سياق الهوية قد ينتج نتائج لا يمكن مقارنتها بعدل. لا تستخدم التجربة لتعلن أن أداة أفضل لمجرد أنها أرجعت صفوفًا أكثر.
النجاح في هذا التمرين يعني أنك عرفت الحساب الصحيح وفهمت ما جلبته كل أداة. لا يعني أنك أثبتّ صلاحياته على جهاز أو تطبيق، ولا أنه آمن أو غير آمن. هذه خصائص هوية في الدليل، ويمكن أن تكون نقطة بداية لسؤال عضوية أو تفويض لاحق.
جرب أيضًا حالة لا تتطابق مع الاسم المتوقع داخل لابك، وقارن رسالة الأداة أو الناتج الفارغ. التعامل مع الحالة السلبية يساعدك تفهم الفرق بين عدم وجود مطابق وبين فشل الاستعلام، بدل الاكتفاء بتجربة ناجحة واحدة ثم افتراض أنك فهمت كل الاحتمالات.

تجربة المجموعات: انتبه لأسماء حقول الناتج

لدينا مجموعة تدريبية اسمها LabReaders. لمعرفة أعضائها وفق الدالة الكلاسيكية الموثقة:
Get-DomainGroupMember -Identity LabReaders -Domain lab.test
اقرأ الناتج الأصلي أولًا قبل اختصاره. من الحقول المهمة في المثال الموثق اسم المجموعة واسم العضو ونوعه ومعرفه. بعد فهم ما يرجع، تستطيع اختيار حقول مفيدة للمراجعة:
Get-DomainGroupMember -Identity LabReaders -Domain lab.test | Select-Object GroupName,MemberName,MemberObjectClass,MemberSID
هذه الحقول تعبر عن علاقة مجموعة بعضو. لا تنقل قائمة أعمدة من أمر آخر لمجرد أن الوظيفتين متشابهتان. مثلًا، اختيار SamAccountName من ناتج لا يقدمه بهذا الاسم قد يعطيك عمودًا فارغًا ويجعلك تتهم الدالة بأنها لم تجمع الأسماء.
قارن بسؤال العضوية المباشرة باستخدام أمر مايكروسوفت:
Get-ADGroupMember -Identity LabReaders -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass,SID
هدف المقارنة هو نفس العلاقات، لا تطابق أسماء الأعمدة حرفيًا. اكتب معنى كل عمود في جدول ملاحظاتك: المجموعة المستهدفة، والعضو، ونوع الكائن، والمعرف. بعدها تقدر تقارن البيانات بدل مقارنة شكل العرض.
إذا وجدت عضوًا من نوع مجموعة، توقف واسأل هل المطلوب حصر المستوى المباشر أم التوسع إلى الأعضاء عبر التداخل. هذا قرار يغير السؤال، وليس خطوة شكلية تجعل الناتج «أكمل» دائمًا. أحيانًا تحتاج المستوى المباشر لمعرفة سبب التفويض، وأحيانًا تحتاج قائمة موسعة للمراجعة الدورية.
وإذا حذفت المجموعات الوسيطة من العرض قبل تحليلها، قد تفقد الجزء الذي يشرح وصول حساب قديم. احتفظ بالناتج الأصلي أو بالحقول التي تصف العلاقات، ثم أنشئ عرضًا مختصرًا للمستلم عند الحاجة. اختصار التقرير شيء، وإزالة الدليل من سجل العمل شيء آخر.

لا تبدّل Recurse وRecursive كأنهما نفس الكلمة

في الدالة الكلاسيكية Get-DomainGroupMember يوجد خيار Recurse. وفي أمر مايكروسوفت Get-ADGroupMember يسمى الخيار Recursive. تشابه الغرض العام لا يبرر نسخ المعامل من واحد إلى الآخر، ولا افتراض تطابق شكل النتائج في كل نسخة.
داخل لاب صغير، راجع مساعدة كل أمر ثم جرب السؤال الذي تحتاجه. توثيق PowerView الكلاسيكي يعرض في مثال التوسع حقول المجموعة والعضو عبر مستويات السلسلة، بينما يشرح توثيق مايكروسوفت رجوع الأعضاء النهائيين في التوسع المتداخل. لذلك قد يختلف عدد الصفوف ومعنى الصف بين الناتجين، حتى عندما يصفان نفس الحالة الأساسية.
خلنا نفترض أن LabReaders تضم مجموعة LabStudents، وأن student عضو في LabStudents. النتيجة التي تحفظ العلاقة الوسيطة تساعدك تشرح كيف وصل الحساب، بينما القائمة النهائية تساعدك تحصر الحسابات. إذا قارنت عدد الصفوف وحده، قد تحكم أن أداة فقدت بيانات وهي في الحقيقة تعرض نوعًا مختلفًا من الإجابة.
اكتب قبل التجربة ما تريد حفظه: هل تريد أسماء المستفيدين، أم كل علاقة في الطريق، أم التحقق من مسار واحد؟ بعد ذلك اختر شكل الناتج المناسب. هذه الطريقة تمنعك تبني تقريرًا من صفوف لا تتفق على معناها.
وإذا كنت تستخدم فرعًا مختلفًا من PowerView، لا تعتمد على وصف النسخة الكلاسيكية بدون مراجعة. بعض التفاصيل قد تتغير. احتفظ بمثال صغير تعرف بنيته لتختبر سلوك النسخة بدل اكتشاف الفرق لأول مرة داخل تقييم كبير. ثلاث مجموعات وحسابان في لاب واضح قد تعلمك أكثر من آلاف الصفوف التي لا تعرف مصدرها.

إذا اختلفت النتيجة بين الأداتين، امشِ بهذا الترتيب

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

تمرين مقارنة كامل تقدر تسويه في جلسة واحدة

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

متى تختار كل أداة، وأين ترجع للتوثيق؟

في مراجعة إدارية اعتيادية، الأدوات المعتمدة والمتوفرة لدى الجهة تسهّل إعادة العمل ومراجعة النتائج. وفي لاب تعليمي يتناول PowerView، فهم دواله ومخرجاته يساعدك قراءة الشروحات والتحقق من الافتراضات التي تعتمد عليها. الاختيار الجيد مرتبط بالمهمة والبيئة، وليس باسم يبدو أكثر هجومية.
لا تجعل وجود أداة مألوفة شرطًا للفهم. إذا عرفت كيف تُعرّف الهوية وكيف تُقرأ العضوية وما معنى كل صف، تقدر تتعلم واجهة جديدة بسرعة أكبر. وإذا حفظت أسماء الأوامر فقط، فأي تغيير في معامل أو حقل قد يوقفك رغم أن سؤال الدليل نفسه بسيط.
المستودع الأصلي وحالة أرشفته:
https://github.com/PowerShellMafia/PowerSploit
توثيق الدالة الكلاسيكية لقراءة المستخدمين:
https://powersploit.readthedocs.io/en/latest/Recon/Get-DomainUser/
توثيق الدالة الكلاسيكية لعضويات المجموعات:
https://powersploit.readthedocs.io/en/latest/Recon/Get-DomainGroupMember/
ولشرح تتبع العضوية خطوة بخطوة بأوامر مايكروسوفت، اقرأ مقال المجتمع:
https://courses.cyberpts.com/community/64/shrh-get-adgroupmember-lysh-almstkhdm-ywsl-llmjmwah-wasmh-mw-zahr-byn-aadayha
احتفظ دائمًا بالفرق بين سؤال الأداة وشكل مخرجاتها. قد يرجع سؤال واحد في هيئة حقول مختلفة، وقد يعطي أمران متشابهان إجابتين عن سؤالين مختلفين. فهم هذا الفرق هو الذي يخليك تستفيد من الأدوات بدل ما تتوه بين أسمائها.