# Az - Device Registration {{#include ../../banners/hacktricks-training.md}} ## Basic Information जब एक डिवाइस AzureAD में शामिल होता है, तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है। जब एक डिवाइस को रजिस्टर किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछता है), फिर यह डिवाइस रजिस्ट्रेशन सेवा के लिए टोकन का अनुरोध करता है और फिर अंतिम पुष्टि प्रॉम्प्ट के लिए पूछता है। फिर, डिवाइस में दो RSA कीपैर बनाए जाते हैं: **डिवाइस की** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **ट्रांसपोर्ट** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है। फिर, **ऑब्जेक्ट** **AzureAD** में (Intune में नहीं) उत्पन्न होता है और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे इसके द्वारा हस्ताक्षरित किया गया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD से जुड़ा है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)। ```bash dsregcmd /status ``` डिवाइस पंजीकरण के बाद, **प्राथमिक रिफ्रेश टोकन** LSASS CloudAP मॉड्यूल द्वारा अनुरोध किया जाता है और डिवाइस को दिया जाता है। PRT के साथ **सत्र कुंजी भी प्रदान की जाती है जिसे केवल डिवाइस ही डिक्रिप्ट कर सकता है** (परिवहन कुंजी के सार्वजनिक कुंजी का उपयोग करके) और इसे **PRT का उपयोग करने के लिए आवश्यक है।** PRT क्या है, इसके बारे में अधिक जानकारी के लिए देखें: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ### TPM - ट्रस्टेड प्लेटफॉर्म मॉड्यूल **TPM** **कुंजी** **निकासी** के खिलाफ एक बंद डिवाइस (यदि पिन द्वारा सुरक्षित है) से और OS परत से निजी सामग्री निकालने से **सुरक्षा** करता है।\ लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की स्निफिंग** या **SYSTEM** अधिकारों वाले प्रक्रिया से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने के खिलाफ **सुरक्षा** नहीं करता है। यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** **उपयोगकर्ता** की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है): {{#ref}} az-lateral-movement-cloud-on-prem/pass-the-prt.md {{#endref}} ## SSO टोकनों के साथ डिवाइस पंजीकरण एक हमलावर के लिए समझौता किए गए डिवाइस से Microsoft डिवाइस पंजीकरण सेवा के लिए एक टोकन अनुरोध करना और इसे पंजीकृत करना संभव होगा: ```bash # Initialize SSO flow roadrecon auth prt-init .\ROADtoken.exe # Request token with PRT with PRT cookie roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie # Custom pyhton script to register a device (check roadtx) registerdevice.py ``` जो आपको **प्रमाणपत्र देगा जिसका उपयोग आप भविष्य में PRTs के लिए पूछने के लिए कर सकते हैं**। इसलिए स्थिरता बनाए रखना और **MFA को बायपास करना** क्योंकि नए डिवाइस को पंजीकृत करने के लिए उपयोग किया गया मूल PRT टोकन **पहले से ही MFA अनुमतियाँ दी गई थीं**। > [!TIP] > ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक डिवाइस को पंजीकृत करना यह नहीं दर्शाता कि डिवाइस **Intune में नामांकित होने की अनुमति दी जाएगी**। > [!CAUTION] > यह हमला सितंबर 2021 में ठीक किया गया था क्योंकि आप अब SSO टोकन का उपयोग करके नए उपकरणों को पंजीकृत नहीं कर सकते। हालाँकि, यह अभी भी एक वैध तरीके से उपकरणों को पंजीकृत करना संभव है (यदि आवश्यक हो तो उपयोगकर्ता नाम, पासवर्ड और MFA होना)। जांचें: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md)। ## एक डिवाइस टिकट को ओवरराइट करना यह **डिवाइस टिकट** **अनुरोध** करने, डिवाइस के वर्तमान को **ओवरराइट** करने और प्रवाह के दौरान **PRT चुराने** के लिए संभव था (इसलिए इसे TPM से चुराने की आवश्यकता नहीं है। अधिक जानकारी के लिए [**इस वार्ता की जांच करें**](https://youtu.be/BduCn8cLV1A)।
> [!CAUTION] > हालाँकि, इसे ठीक कर दिया गया था। ## WHFB कुंजी को ओवरराइट करें [**यहाँ मूल स्लाइड देखें**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) हमले का सारांश: - यह **SSO** के माध्यम से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है - यह **TPM सुरक्षा को पराजित करता है** क्योंकि कुंजी **नई कुंजी के निर्माण के दौरान स्निफ की जाती है** - यह **स्थिरता** भी प्रदान करता है
उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक डिवाइस होना चाहिए (फ्लाई पर पंजीकृत या एक वैध डिवाइस से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए। फिर, एक नई कुंजी उत्पन्न करना संभव है: ```bash roadtx genhellokey -d -k tempkey.key ``` और फिर searchableDeviceKey की जानकारी को PATCH करें:
एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी पहुंच चुराना**। अधिक जानकारी के लिए देखें: {{#ref}} az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md {{#endref}}
## संदर्भ - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A) - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g) - [https://www.youtube.com/watch?v=AFay_58QubY](https://www.youtube.com/watch?v=AFay_58QubY) {{#include ../../banners/hacktricks-training.md}}