analyst کے پاس پہلے سے ہی lab-linux پر ایک شیل (shell) موجود ہے، اور CORP.LOCAL\svcuser پہلے سے LAB-WIN01 میں سائن ان ہوتا ہے۔ ان میں سے کوئی بھی ابتدائی رسائی (foothold) انتظامی (administrative) کارروائی کا نتیجہ نہیں ہے۔ جائزے کا بنیادی سوال یہ ہے کہ کیا مقامی کنفیگریشن کی کوئی غلطی کسی اکاؤنٹ کو مقامی استحقاق کی حد (privilege boundary) عبور کر کے root یا SYSTEM تک رسائی دیتی ہے، اور کیا ہم کسی ایکسپلائٹ (exploit) کو چلائے بغیر اس خطرے کو ثابت کر سکتے ہیں؟ جب اکاؤنٹ، کنفیگریشن اور ضروری شرائط (prerequisites) سب آپس میں مطابقت رکھتے ہوں، تو sudoers میں کوئی مجاز کمانڈ، سروس کا قابلِ تحریر (writable) پاتھ، یا محفوظ شدہ اسناد (credentials) کافی ثبوت ثابت ہو سکتے ہیں۔
اس کورس کا تمام کام مخصوص آف لائن Ubuntu 22.04 اور Windows Server 2022 لیبز کے اندر ہوتا ہے جو ہماری ملکیت ہیں یا جن کا جائزہ لینے کے لیے ہمیں واضح اجازت حاصل ہے۔ یہ طریقہ کار قابلِ دفاع نتائج (findings) فراہم کرتا ہے، نہ کہ پے لوڈز (payloads)، ایکسپلائٹیشن چینز (exploitation chains) یا سراغ رسانی سے بچنے کے اقدامات۔ Ubuntu پر، sudo کی درخواست اور اس کے نتیجے سے /var/log/auth.log اور سسٹم جرنل میں اجازت (authorization) کے شواہد مل سکتے ہیں، جبکہ Windows پر استحقاق (privilege) سے متعلق سرگرمی کا تعلق متعلقہ سیکیورٹی لاگ یا سروس کے شواہد سے ہونا چاہیے۔
یہ مخصوص لیب استحقاق کی حد اور اس سے متعلقہ شواہد کے ذخیروں (evidence stores) کو نمایاں کرتی ہے:
یہ خاکہ ظاہر کرتا ہے کہ ‘اینومریشن’ (enumeration) کا عمل ہوسٹ (host) سے کیوں شروع ہوتا ہے۔ متعلقہ کنفیگریشن اور اس کے استعمال کے شواہد عام طور پر استحقاق (privilege) کی ایک ہی حد کے مخالف اطراف میں موجود ہوتے ہیں، لہذا کسی نتیجے (finding) تک پہنچنے کے لیے محض کسی ایک مشکوک سیٹنگ کے بجائے دونوں چیزوں کی ضرورت ہوتی ہے۔
چونکہ کسی ظاہری حد کا ہونا خود بخود اس کے پار جانے کا راستہ نہیں بناتا، اس لیے اینومریشن کے ہر مرحلے سے چار باہم مربوط نتائج حاصل ہوتے ہیں۔ مفروضوں کی فہرست (hypothesis list) ممکنہ ‘ویکٹر کلاسز’ (vector classes) کا ایک درجہ بند مجموعہ ہوتی ہے، جیسے کہ تفویض کردہ (delegated) لینکس کمانڈز، شیڈولڈ ٹاسکس، ونڈوز سروس کی کمزور کنفیگریشن، یا نان ایڈمنسٹریٹو اکاؤنٹ کے لیے ظاہر (exposed) ہونے والے اسناد (credentials)۔ مفروضہ بذاتِ خود کوئی حتمی نتیجہ نہیں ہوتا؛ یہ نتیجہ تب بنتا ہے جب ہوسٹ کی کنفیگریشن اس ویکٹر کی پیشگی شرائط (prerequisites) کو پورا کرتی ہو۔
مثال کے طور پر، اگر کوئی ‘تجزیہ کار’ (analyst) بلند استحقاق (elevated permission) والی کوئی ایگزیکییوٹیبل فائل دیکھتا ہے تو یہ خود بخود استحقاق میں اضافے (privilege escalation) کا ثبوت نہیں ہوتا۔ ہمیں یہ تعین کرنا ہوتا ہے کہ فائل کا مالک کون ہے، آیا تجزیہ کار اس پر اثر انداز ہو سکتا ہے، کون سا بااختیار (privileged) جزو اسے چلاتا ہے، اور آیا ایگزیکیوشن کا سیاق و سباق (context) واقعی ‘روٹ’ (root) تک پہنچتا ہے یا نہیں۔ ونڈوز کے معاملے میں بھی، صرف کسی سروس کو دیکھ لینا کافی نہیں ہوتا؛ ہمیں سروس اکاؤنٹ، بائنری پاتھ، ایکسیس کنٹرول، اور CORP.LOCAL\svcuser کے پاس موجود اجازتوں (permissions) کی معلومات درکار ہوتی ہیں۔
یہی شواہد دفاع کرنے والے (defender) کے سوال کا جواب بھی فراہم کرتے ہیں۔ اوبنٹو (Ubuntu) پر، منظور شدہ اور مسترد شدہ sudo سرگرمیوں سے کال کرنے والے اکاؤنٹ، ٹارگٹ صارف، ورکنگ ڈائریکٹری اور کمانڈ کی شناخت کی جا سکتی ہے؛ جبکہ /etc/sudoers اور /etc/sudoers.d/ جیسی پالیسی فائلیں یہ وضاحت کرتی ہیں کہ اس عمل کی اجازت کیوں دی گئی تھی۔ دفاع کرنے والا ان ریکارڈز کا موازنہ تفویض کے مطلوبہ اصول (delegation rule) سے کر سکتا ہے اور غیر معمولی بااختیار کمانڈز یا پالیسی فائلوں میں غیر متوقع تبدیلیوں پر الرٹ جاری کر سکتا ہے۔
جائزے کے نتائج ایک ممکنہ راستے (plausible route) اور رپورٹ کیے جانے کے قابل ‘استحقاق میں اضافے کی صورتحال’ (privilege-escalation condition) کے درمیان فرق واضح کرتے ہیں: