analyst के पास पहले से ही lab-linux पर एक शेल है, और CORP.LOCAL\svcuser पहले से ही LAB-WIN01 में साइन-इन करता है। इनमें से कोई भी फ़ुटहोल्ड एडमिनिस्ट्रेटिव नतीजा नहीं है। असेसमेंट का सवाल यह है कि क्या कोई लोकल कॉन्फ़िगरेशन एरर किसी अकाउंट को लोकल प्रिविलेज बाउंड्री पार करके root या SYSTEM तक पहुँचने देता है, और क्या हम बिना किसी एक्सप्लॉइट को चलाए उस जोखिम को साबित कर सकते हैं। sudoers में कोई परमिटेड कमांड, राइटेबल सर्विस पाथ, या स्टोर किया गया क्रेडेंशियल काफ़ी सबूत हो सकता है, जब अकाउंट, कॉन्फ़िगरेशन और ज़रूरी शर्तें सभी एक साथ हों।
इस कोर्स का सारा काम तय ऑफ़लाइन Ubuntu 22.04 और Windows Server 2022 लैब्स के अंदर होता है, जो हमारे हैं या जिन्हें असेस करने के लिए हमें साफ़ तौर पर अधिकार मिला है। इस तरीके से ऐसे नतीजे मिलते हैं जिन्हें साबित किया जा सके, न कि पेलोड, एक्सप्लॉइटेशन चेन या बचाव के तरीके। Ubuntu पर, sudo रिक्वेस्ट और उसके नतीजे से /var/log/auth.log और सिस्टम जर्नल में ऑथराइज़ेशन के सबूत मिल सकते हैं, जबकि Windows में प्रिविलेज एक्टिविटी को संबंधित सिक्योरिटी लॉग या सर्विस के सबूत से जोड़ा जाना चाहिए।
तय लैब प्रिविलेज बाउंड्री और उसके सबूतों के स्टोरेज को साफ़ तौर पर दिखाती है:
यह डायग्राम दिखाता है कि एन्यूमरेशन (enumeration) होस्ट से क्यों शुरू होता है। संबंधित कॉन्फ़िगरेशन और उसके इस्तेमाल के सबूत आमतौर पर एक ही प्रिविलेज बाउंड्री (अधिकार सीमा) के विपरीत किनारों पर होते हैं, इसलिए किसी निष्कर्ष पर पहुँचने के लिए सिर्फ़ एक संदिग्ध सेटिंग के बजाय दोनों चीज़ों की ज़रूरत होती है।
क्योंकि कोई दिखाई देने वाली बाउंड्री उसके आर-पार जाने का रास्ता नहीं बनाती, इसलिए हर एन्यूमरेशन प्रक्रिया चार जुड़े हुए आउटपुट देती है। हाइपोथिसिस लिस्ट (परिकल्पना सूची) संभावित वेक्टर क्लास का एक क्रमबद्ध सेट होती है, जैसे कि डेलीगेटेड लिनक्स कमांड, शेड्यूल किए गए टास्क, कमज़ोर विंडोज़ सर्विस कॉन्फ़िगरेशन, या नॉन-एडमिनिस्ट्रेटिव अकाउंट के सामने आए क्रेडेंशियल। हाइपोथिसिस कोई निष्कर्ष नहीं है। यह निष्कर्ष तब बनता है जब होस्ट कॉन्फ़िगरेशन वेक्टर की ज़रूरी शर्तों को पूरा करता है।
उदाहरण के लिए, अगर कोई analyst ज़्यादा परमिशन वाली एग्जीक्यूटेबल फ़ाइल देखता है, तो इससे एलिवेशन (अधिकार बढ़ना) साबित नहीं होता। हमें यह पता लगाना होगा कि फ़ाइल का मालिक कौन है, क्या analyst उसे प्रभावित कर सकता है, कौन सा प्रिविलेज्ड कंपोनेंट उसे चलाता है, और क्या एग्जीक्यूशन कॉन्टेक्स्ट असल में root तक पहुँचता है। विंडोज़ में इसके बराबर की स्थिति सिर्फ़ किसी सर्विस को देखना नहीं है। हमें सर्विस अकाउंट, बाइनरी पाथ, एक्सेस कंट्रोल और CORP.LOCAL\svcuser के पास मौजूद परमिशन की ज़रूरत होती है।
यही सबूत डिफेंडर के सवाल का जवाब देते हैं। Ubuntu पर, स्वीकार की गई और अस्वीकार की गई sudo गतिविधि से इनवोकिंग अकाउंट, टारगेट यूज़र, वर्किंग डायरेक्टरी और कमांड की पहचान की जा सकती है; /etc/sudoers और /etc/sudoers.d/ जैसी पॉलिसी फ़ाइलें बताती हैं कि कार्रवाई की अनुमति क्यों दी गई थी। एक डिफेंडर उन रिकॉर्ड्स की तुलना तय डेलीगेशन नियम से कर सकता है और असामान्य प्रिविलेज्ड कमांड या पॉलिसी फ़ाइलों में अप्रत्याशित बदलावों पर अलर्ट हो सकता है।
असेसमेंट आउटपुट एक संभावित रास्ते और रिपोर्ट करने लायक प्रिविलेज-एस्केलेशन स्थिति के बीच अंतर बताते हैं: