Kerbeus-BOF

---

केरबेरोस दुरुपयोग के लिए बीकन ऑब्जेक्ट फ़ाइलें। यह Rubeus प्रोजेक्ट की कुछ महत्वपूर्ण विशेषताओं का कार्यान्वयन है, जो C में लिखा गया है। यह प्रोजेक्ट C2 फ्रेमवर्क Cobalt Strike, Havoc, AdaptixC2 और Outflank C2 के साथ एकीकरण प्रदान करता है।

टिकट अनुरोध और नवीनीकरण

asktgt

asktgt कार्रवाई निर्दिष्ट उपयोगकर्ता और एन्क्रिप्शन कुंजी (/rc4 या /aes256) के लिए कच्चा AS-REQ (TGT अनुरोध) ट्रैफ़िक बनाएगी। /password फ़्लैग का उपयोग हैश के बजाय किया जा सकता है - इस स्थिति में /enctype:X डिफ़ॉल्ट रूप से RC4 होगा। यदि कोई /domain निर्दिष्ट नहीं है, तो कंप्यूटर का वर्तमान डोमेन निकाला जाता है, और यदि कोई /dc निर्दिष्ट नहीं है, तो सिस्टम के वर्तमान डोमेन कंट्रोलर के लिए भी ऐसा ही किया जाता है। यदि प्रमाणीकरण सफल होता है, तो परिणामी AS-REP को पार्स किया जाता है और KRB-CRED (एक .kirbi, जिसमें उपयोगकर्ता का TGT शामिल है) को base64 ब्लॉब के रूप में आउटपुट किया जाता है। /ptt फ़्लैग "पास-द-टिकट" करेगा और परिणामी केरबेरोस क्रेडेंशियल को वर्तमान लॉगऑन सत्र पर लागू करेगा। साथ ही, एक और ऑप्सेक नोट: वर्तमान लॉगऑन सत्र में एक समय में केवल एक TGT लागू किया जा सकता है, इसलिए पिछला TGT हटा दिया जाता है जब /ptt विकल्प का उपयोग करके नया टिकट लागू किया जाता है।

अनुरोधों को वास्तविक अनुरोधों के अधिक अनुरूप बनाने के लिए, /opsec फ़्लैग का उपयोग किया जा सकता है, यह पहले बिना प्री-ऑथेंटिकेशन के एक प्रारंभिक AS-REQ भेजेगा, यदि यह सफल होता है, तो परिणामी AS-REP को डिक्रिप्ट किया जाता है और TGT वापस किया जाता है, अन्यथा प्री-ऑथेंटिकेशन के साथ एक AS-REQ भेजा जाता है।

PAC के बिना TGT का अनुरोध /nopac स्विच का उपयोग करके किया जा सकता है। /nopreauth फ़्लैग का उपयोग प्री-ऑथेंटिकेशन के बिना AS-REQ भेजने के लिए किया जा सकता है।

krb_asktgt /user:USER /password:PASSWORD [/domain:DOMAIN] [/dc:DC] [/enctype:{rc4|aes256}] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /aes256:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /rc4:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac]
krb_asktgt /user:USER /nopreauth [/domain:DOMAIN] [/dc:DC] [/ptt]

asktgs

asktgs कार्रवाई आपूर्ति किए गए निर्दिष्ट TGT /ticket:X का उपयोग करके कच्चा TGS-REQ/TGS-REP सेवा टिकट अनुरोध बनाएगी/पार्स करेगी। यह मान अवश्य .kirbi फ़ाइल का base64 एन्कोडिंग होना चाहिए। यदि /dc निर्दिष्ट नहीं है, तो कंप्यूटर का वर्तमान डोमेन कंट्रोलर निकाला जाता है और अनुरोध ट्रैफ़िक के गंतव्य के रूप में उपयोग किया जाता है। /ptt फ़्लैग "पास-द-टिकट" करेगा और परिणामी सेवा टिकट को वर्तमान लॉगऑन सत्र पर लागू करेगा। एक या अधिक /service:X SPN अवश्य निर्दिष्ट किए जाने चाहिए, अल्पविराम से अलग किए गए।

निर्मित TGS-REQ में समर्थित एन्क्रिप्शन प्रकार RC4_HMAC और AES256_CTS_HMAC_SHA1 होंगे। इस स्थिति में, KDC द्वारा लौटाए गए सेवा टिकट के निर्माण के लिए उच्चतम पारस्परिक रूप से समर्थित एन्क्रिप्शन का उपयोग किया जाएगा। यदि आप RC4 या AES256 कुंजियों को बाध्य करना चाहते हैं, तो /enctype:[rc4 or aes256] का उपयोग करें।

अनुरोधों को वास्तविक अनुरोधों के अधिक अनुरूप बनाने के लिए, /opsec फ़्लैग का उपयोग किया जा सकता है, यह एक अतिरिक्त TGS-REQ स्वचालित रूप से भेजने का कारण भी बनेगा जब किसी ऐसे खाते के लिए सेवा टिकट का अनुरोध किया जाता है जो अप्रतिबंधित प्रतिनिधिमंडल के लिए कॉन्फ़िगर किया गया है।

/u2u फ़्लैग को उपयोगकर्ता-से-उपयोगकर्ता टिकटों का अनुरोध करने के लिए लागू किया गया था। साथ में /tgs:X तर्क (लक्ष्य खातों के TGT की आपूर्ति के लिए उपयोग किया जाता है), /service:X तर्क उस खाते का उपयोगकर्ता नाम हो सकता है जिसके लिए आपूर्ति किया गया TGT है (/tgs:X तर्क के साथ)। /targetuser:X तर्क target user's उपयोगकर्ता नाम के साथ PA-FOR-USER PA डेटा अनुभाग सम्मिलित करके किसी अन्य खाते का PAC अनुरोध करेगा।

/keyList फ़्लैग को केरबेरोस कुंजी सूची अनुरोधों के लिए लागू किया गया था। इन अनुरोधों को /ticket:BASE64 पैरामीटर में केवल-पढ़ने के डोमेन कंट्रोलर से एक जाली आंशिक TGT का उपयोग करना चाहिए। इसके अलावा, /spn:x फ़ील्ड को डोमेन के भीतर KRBTGT SPN पर सेट किया जाना चाहिए, जैसे KRBTBT/domain.local।

krb_asktgs /ticket:BASE64 /service:SPN1,SPN2,... [/domain:DOMAIN] [/dc:DC] [/tgs:BASE64] [/targetdomain:DOMAIN] [/targetuser:USER] [/enctype:{rc4|aes256}] [/ptt] [/keylist] [/u2u] [/opsec]

renew

renew कार्रवाई आपूर्ति किए गए निर्दिष्ट /ticket:X का उपयोग करके कच्चा TGS-REQ/TGS-REP TGT नवीनीकरण आदान-प्रदान बनाएगी/पार्स करेगी। यह मान .kirbi फ़ाइल का base64 एन्कोडिंग होना चाहिए। यदि /dc निर्दिष्ट नहीं है, तो कंप्यूटर का वर्तमान डोमेन कंट्रोलर निकाला जाता है और नवीनीकरण ट्रैफ़िक के गंतव्य के रूप में उपयोग किया जाता है। /ptt फ़्लैग "पास-द-टिकट" करेगा और परिणामी केरबेरोस क्रेडेंशियल को वर्तमान लॉगऑन सत्र पर लागू करेगा।

krb_renew /ticket:BASE64 [/dc:DC] [/ptt]

प्रतिबंधित प्रतिनिधिमंडल दुरुपयोग

यदि कोई उपयोगकर्ता (या कंप्यूटर) खाता प्रतिबंधित प्रतिनिधिमंडल के लिए कॉन्फ़िगर किया गया है (अर्थात इसके msds-allowedtodelegateto फ़ील्ड में SPN मान है) तो इस कार्रवाई का उपयोग लक्ष्य SPN/सर्वर तक पहुंच के दुरुपयोग के लिए किया जा सकता है।

एक TL;DR स्पष्टीकरण यह है कि प्रतिबंधित प्रतिनिधिमंडल सक्षम वाला खाता किसी भी उपयोगकर्ता के रूप में स्वयं के लिए टिकट का अनुरोध कर सकता है, एक प्रक्रिया जिसे S4U2self के रूप में जाना जाता है। किसी खाते को ऐसा करने की अनुमति देने के लिए, उसके useraccountcontrol गुण में TrustedToAuthForDelegation सक्षम होना चाहिए, कुछ ऐसा जो केवल उन्नत उपयोगकर्ता ही डिफ़ॉल्ट रूप से संशोधित कर सकते हैं। इस टिकट में डिफ़ॉल्ट रूप से FORWARDABLE फ़्लैग सेट होता है। सेवा तब इस विशेष रूप से अनुरोधित टिकट का उपयोग खाते के msds-allowedtodelegateto फ़ील्ड में निर्दिष्ट किसी भी सेवा प्रिंसिपल नाम (SPN) के लिए सेवा टिकट का अनुरोध करने के लिए कर सकती है। तो संक्षेप में, यदि आपके पास TrustedToAuthForDelegation सेट और msds-allowedtodelegateto में मान वाले खाते का नियंत्रण है, तो आप खाते के msds-allowedtodelegateto फ़ील्ड में सेट SPN के लिए डोमेन में किसी भी उपयोगकर्ता के रूप में प्रस्तुत कर सकते हैं।

S4U2self टिकट का उपयोग तब S4U2proxy प्रक्रिया को निष्पादित करने के लिए /tgs:Y पैरामीटर (base64 ब्लॉब) के रूप में किया जा सकता है। खाते के लिए एक मान्य msds-allowedtodelegateto मान प्रदान किया जाना चाहिए (/service:X)।

/altservice पैरामीटर हमें परिणामी KRB-CRED फ़ाइल में किसी भी सेवा नाम को प्रतिस्थापित करने की अनुमति देता है। एक या अधिक वैकल्पिक सेवा नाम प्रदान किए जा सकते हैं, अल्पविराम से अलग किए गए (/altservice:cifs,HOST,...)।

TGS-REQ को वास्तविक अनुरोधों के अधिक अनुरूप बनाने के लिए, /opsec फ़्लैग का उपयोग किया जा सकता है।

कुछ परिस्थितियों में, S4U2Self टिकट का उपयोग संरक्षित उपयोगकर्ताओं का प्रतिरूपण करने के लिए किया जा सकता है ताकि अनुरोध करने वाले सिस्टम पर विशेषाधिकार बढ़ाए जा सकें, जैसा कि यहां चर्चा की गई है। इस उद्देश्य के लिए, /self फ़्लैग और /altservice:X तर्क का उपयोग एक उपयोगी सेवा टिकट उत्पन्न करने के लिए किया जा सकता है।

S4U2Self रेफरल जाली बनाने के लिए, केवल विश्वास कुंजी की आवश्यकता है। /targetdomain:X तर्क का उपयोग /self फ़्लैग के साथ और /targetdc तर्क के बिना करके, यह /ticket:X के साथ आपूर्ति किए गए टिकट को S4U2Self रेफरल के रूप में मानेगा और केवल अंतिम S4U2Self सेवा टिकट का अनुरोध करेगा। /altservice:X का उपयोग परिणामी टिकट में sname को फिर से लिखने के लिए भी किया जा सकता है।