ralfhacker/kerbeus-bofBOF for Kerberos abuse (an implementation of some important features of the Rubeus).
केरबेरोस दुरुपयोग के लिए बीकन ऑब्जेक्ट फ़ाइलें। यह Rubeus प्रोजेक्ट की कुछ महत्वपूर्ण विशेषताओं का कार्यान्वयन है, जो C में लिखा गया है। यह प्रोजेक्ट C2 फ्रेमवर्क Cobalt Strike, Havoc, AdaptixC2 और Outflank C2 के साथ एकीकरण प्रदान करता है।
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 कार्रवाई आपूर्ति किए गए निर्दिष्ट 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 कार्रवाई आपूर्ति किए गए निर्दिष्ट /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 को फिर से लिखने के लिए भी किया जा सकता है।
krb_s4u /ticket:BASE64 /service:SPN {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/ptt] [/nopac] [/opsec] [/self]
krb_cross_s4u /ticket:BASE64 /service:SPN /targetdomain:DOMAIN /targetdc:DC {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/nopac] [/self]
ptt कार्रवाई LsaCallAuthenticationPackage() API के माध्यम से KERB_SUBMIT_TKT_REQUEST संदेश के साथ वर्तमान लॉगऑन सत्र के लिए एक /ticket:X (TGT या सेवा टिकट) सबमिट करेगी, या (यदि उन्नत है) /luid:ea4.. द्वारा निर्दिष्ट लॉगऑन सत्र के लिए। अन्य /ticket:X पैरामीटर की तरह, मान .kirbi फ़ाइल का base64 एन्कोडिंग हो सकता है।
krb_ptt /ticket:BASE64 [/luid:LOGONID]
purge कार्रवाई वर्तमान लॉगऑन सत्र से सभी केरबेरोस टिकटों को शुद्ध करेगी, या (यदि उन्नत है) /luid:0xA.. द्वारा निर्दिष्ट लॉगऑन सत्र के लिए।
krb_purge [/luid:LOGONID]
describe कार्रवाई एक /ticket:X मान (TGT या सेवा टिकट) लेती है, इसे पार्स करती है, और टिकट के मानों का वर्णन करती है। अन्य /ticket:X पैरामीटर की तरह, मान .kirbi फ़ाइल का base64 एन्कोडिंग हो सकता है।
krb_describe /ticket:BASE64
klist वर्तमान उपयोगकर्ता के लॉगऑन सत्र और केरबेरोस टिकटों के बारे में विस्तृत जानकारी सूचीबद्ध करेगा, यदि उन्नत नहीं है। यदि उन्नत संदर्भ (SYSTEM) से चलाया जाता है, तो सभी लॉगऑन सत्रों और संबंधित केरबेरोस टिकटों की जानकारी प्रदर्शित होती है। लॉगऑन और टिकट जानकारी एक विशिष्ट LogonID के लिए /luid:3ea.. के साथ प्रदर्शित की जा सकती है (यदि उन्नत है)।
krb_klist [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
dump कार्रवाई वर्तमान TGT और सेवा टिकट निकालेगी यदि उन्नत संदर्भ (SYSTEM) में है। यदि उन्नत नहीं है, तो वर्तमान उपयोगकर्ता के लिए सेवा टिकट निकाले जाते हैं।
krb_dump [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
triage कार्रवाई वर्तमान उपयोगकर्ता के केरबेरोस टिकटों की एक तालिका आउटपुट करेगी, यदि उन्नत नहीं है। यदि उन्नत संदर्भ (SYSTEM) से चलाया जाता है, तो सिस्टम पर सभी केरबेरोस टिकटों का वर्णन करने वाली एक तालिका प्रदर्शित होती है।
krb_triage [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
klist, triage और dump के लिए, टिकटों को /luid, /service और /client द्वारा फ़िल्टर किया जा सकता है।
SYSTEM संदर्भ की आवश्यकता है।
tgtdeleg होस्ट पर उन्नयन की आवश्यकता के बिना वर्तमान उपयोगकर्ता के लिए एक उपयोगी TGT प्राप्त करने के लिए केरबेरोस GSS-API का दुरुपयोग करता है। AcquireCredentialsHandle() का उपयोग वर्तमान उपयोगकर्ता के केरबेरोस सुरक्षा क्रेडेंशियल्स का हैंडल प्राप्त करने के लिए किया जाता है, और ISC_REQ_DELEGATE फ़्लैग और CIFS/DC.domain.com के लक्ष्य SPN के साथ InitializeSecurityContext() का उपयोग DC को भेजने के लिए एक नकली प्रतिनिधि संदर्भ तैयार करने के लिए किया जाता है। इसके परिणामस्वरूप GSS-API आउटपुट में एक AP-REQ होता है जिसमें प्रमाणक चेकसम में KRB_CRED होता है। सेवा टिकट सत्र कुंजी स्थानीय केरबेरोस कैश से निकाली जाती है और प्रमाणक में KRB_CRED को डिक्रिप्ट करने के लिए उपयोग की जाती है, जिसके परिणामस्वरूप एक उपयोगी TGT .kirbi होता है।
यदि स्वचालित लक्ष्य/डोमेन निष्कर्षण विफल हो रहा है, तो /target:SPN के साथ अप्रतिबंधित प्रतिनिधिमंडल के साथ कॉन्फ़िगर की गई सेवा का एक ज्ञात SPN निर्दिष्ट किया जा सकता है।
krb_tgtdeleg [/target:SPN]
kerberoasting का उपयोग उपयुक्त सेवा टिकट का अनुरोध करने के लिए किया जाता है। /ticket:X तर्क डोमेन उपयोगकर्ता के TGT टिकट को निर्दिष्ट करता है। /spn:X तर्क लक्ष्य SPN को निर्दिष्ट करता है। /domain और /dc तर्क वैकल्पिक हैं और अन्य कार्रवाइयों की तरह सिस्टम डिफ़ॉल्ट प्राप्त करते हैं।
/nopreauth:USER तर्क सेवा टिकटों का अनुरोध करने के लिए /spn:Y को पास की गई सेवा के साथ AS-REQ भेजने का प्रयास करेगा।
krb_kerberoasting /spn:SPN [/nopreauth:USER] [/dc:DC] [/domain:DOMAIN]
krb_kerberoasting /spn:SPN /ticket:BASE64 [/dc:DC]
यदि किसी डोमेन उपयोगकर्ता के पास केरबेरोस प्रीऑथेंटिकेशन सक्षम नहीं है, तो उपयोगकर्ता के लिए AS-REP सफलतापूर्वक अनुरोध किया जा सकता है, और संरचना के एक घटक को kerberoasting की तरह ऑफ़लाइन क्रैक किया जा सकता है। /user:X तर्क लक्ष्य उपयोगकर्ता को निर्दिष्ट करता है। /domain और /dc तर्क वैकल्पिक हैं, अन्य कार्रवाइयों की तरह सिस्टम डिफ़ॉल्ट प्राप्त करते हैं।
krb_asreproasting /user:USER [/dc:DC] [/domain:DOMAIN]
hash कार्रवाई एक /password:X और वैकल्पिक /user:USER और/या /domain:DOMAIN लेगी। यह पासवर्ड का rc4_hmac (NTLM) प्रतिनिधित्व उत्पन्न करेगी। यदि उपयोगकर्ता और डोमेन नाम निर्दिष्ट हैं, तो aes128_cts_hmac_sha1 और aes256_cts_hmac_sha1 हैश फॉर्म उत्पन्न होते हैं। AES कार्यान्वयन के लिए उपयोगकर्ता और डोमेन नाम का उपयोग साल्ट के रूप में किया जाता है।
krb_hash /password:PASSWORD [/user:USER] [/domain:DOMAIN]
changepw कार्रवाई उपयोगकर्ता के TGT .kirbi ब्लॉब को लेगी और निर्दिष्ट /new:PASSWORD मान के साथ MS kpasswd पासवर्ड परिवर्तन निष्पादित करेगी। यदि /dc निर्दिष्ट नहीं है, तो कंप्यूटर का वर्तमान डोमेन कंट्रोलर निकाला जाता है और पासवर्ड रीसेट ट्रैफ़िक के गंतव्य के रूप में उपयोग किया जाता है।
/targetuser और /targetdomain तर्कों का उपयोग अन्य उपयोगकर्ताओं का पासवर्ड बदलने के लिए किया जा सकता है, बशर्ते कि जिस उपयोगकर्ता का TGT है उसके पास पर्याप्त विशेषाधिकार हों।
ध्यान दें कि पासवर्ड बदलने के लिए उपयोगकर्ता के TGT या kadmin/changepw के लिए सेवा टिकट का उपयोग किया जा सकता है
krb_changepw /ticket:BASE64 /new:PASSWORD [/dc:DC] [/targetuser:USER] [/targetdomain:DOMAIN]
asktgt /cert:... को लागू करेंdescribe के आउटपुट का विस्तार करें