يمتلك الحساب analyst بالفعل واجهة أوامر (shell) على النظام lab-linux، بينما يقوم الحساب CORP.LOCAL\svcuser بتسجيل الدخول إلى النظام LAB-WIN01. ولا تُعد أي من نقطتي التمركز هاتين نتاجاً لصلاحيات إدارية. يتمحور سؤال التقييم حول ما إذا كان خطأ في الإعدادات المحلية يسمح لأي من الحسابين بتجاوز حدود الصلاحيات المحلية للوصول إلى مستوى root أو SYSTEM، وما إذا كان بإمكاننا إثبات هذا الخطر دون تنفيذ ثغرة استغلال (exploit). قد يُشكل وجود أمر مسموح به في ملف sudoers، أو مسار خدمة قابل للكتابة، أو بيانات اعتماد مخزنة دليلاً كافياً عند توافق الحساب والإعدادات والمتطلبات الأساسية.
تقتصر جميع الأعمال في هذه الدورة التدريبية على بيئات المختبرات الثابتة وغير المتصلة بالإنترنت (Ubuntu 22.04 و Windows Server 2022) التي نمتلكها أو التي لدينا تفويض صريح بتقييمها. وتنتج هذه المنهجية نتائج قابلة للإثبات والتوثيق، وليس حمولات برمجية (payloads) أو سلاسل استغلال أو خطوات للتهرب من أنظمة الحماية. ففي نظام Ubuntu، قد يترك طلب sudo ونتيجته أدلة تفويض في الملف /var/log/auth.log وفي سجل النظام (system journal)، بينما يجب ربط أنشطة الصلاحيات في نظام Windows بسجل الأمان (Security log) ذي الصلة أو بأدلة الخدمة المعنية.
تتيح بيئة المختبر الثابتة إمكانية رؤية حدود الصلاحيات ومواضع تخزين الأدلة المتعلقة بها:
يوضح هذا الرسم البياني سبب بدء عملية الحصر (enumeration) على المضيف. عادةً ما يقع كل من الإعداد ذي الصلة ودليل استخدامه على جانبين متقابلين من حدود الصلاحيات نفسها؛ لذا يتطلب تحديد “نتيجة” (finding) وجود كلا العنصرين، وليس مجرد إعداد مشبوه منعزل.
نظراً لأن وجود حدود ظاهرة لا يعني بالضرورة توفر مسار لاجتيازها، فإن كل جولة حصر تنتج أربع مخرجات مترابطة. تتمثل قائمة الفرضيات في مجموعة مصنفة من فئات المتجهات المحتملة، مثل أوامر Linux المفوضة، أو المهام المجدولة، أو إعدادات خدمات Windows الضعيفة، أو بيانات الاعتماد المكشوفة لحساب غير إداري. لا تُعد الفرضية “نتيجة” بحد ذاتها، بل تصبح كذلك فقط عندما تستوفي إعدادات المضيف المتطلبات الأساسية للمتجه.
على سبيل المثال، مجرد رؤية المحلل (analyst) لملف قابل للتنفيذ يتمتع بصلاحيات مرتفعة لا يثبت حدوث تصعيد للصلاحيات. يجب علينا تحديد مالك الملف، وما إذا كان بإمكان المحلل التأثير عليه، والمكون ذو الصلاحيات الذي يقوم بتنفيذه، وما إذا كان سياق التنفيذ يصل فعلياً إلى مستوى الجذر (root). أما في نظام Windows، فالأمر لا يقتصر على مجرد ملاحظة وجود خدمة؛ إذ نحتاج إلى معرفة حساب الخدمة، ومسار الملف الثنائي (binary path)، وعناصر التحكم في الوصول، والصلاحيات التي يمتلكها الحساب CORP.LOCAL\svcuser.
توفر الأدلة نفسها إجابات لأسئلة المدافعين عن النظام. ففي نظام Ubuntu، يمكن لأنشطة sudo (سواء المقبولة أو المرفوضة) تحديد الحساب المُشغِّل، والمستخدم المستهدف، ودليل العمل، والأمر المستخدم؛ كما توضح ملفات السياسة -مثل /etc/sudoers و/etc/sudoers.d/- سبب السماح بهذا الإجراء. ويمكن للمدافع مقارنة هذه السجلات بقاعدة التفويض المقصودة، وإصدار تنبيهات بشأن الأوامر غير المعتادة التي تتطلب صلاحيات عالية أو التغييرات غير المتوقعة في ملفات السياسة.
تساعد مخرجات التقييم في التمييز بين المسار المحتمل (plausible route) وحالة تصعيد الصلاحيات التي تستوجب الإبلاغ عنها: