# 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** **कुंजी** **निकासी** से एक बंद डिवाइस (यदि PIN द्वारा सुरक्षित है) की सुरक्षा करता है और OS परत से निजी सामग्री को निकालने से।\
लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की निगरानी** करने या **SYSTEM** अधिकारों वाले प्रक्रिया से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने से सुरक्षा नहीं करता है।

यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** उपयोगकर्ता की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है):

{{#ref}}
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
{{#endref}}

## SSO टोकनों के साथ डिवाइस पंजीकरण

एक हमलावर के लिए यह संभव होगा कि वह समझौता किए गए डिवाइस से Microsoft डिवाइस पंजीकरण सेवा के लिए एक टोकन अनुरोध करे और इसे पंजीकृत करे:
```bash
# Initialize SSO flow
roadrecon auth prt-init
.\ROADtoken.exe <nonce>

# Request token with PRT with PRT cookie
roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <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)।

<figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>

> [!CAUTION]
> हालाँकि, इसे ठीक किया गया था।

## WHFB कुंजी को ओवरराइट करें

[**यहाँ मूल स्लाइड देखें**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)

हमले का सारांश:

- यह **SSO** के माध्यम से एक **उपकरण** से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है
- यह **TPM सुरक्षा को पराजित करता है** क्योंकि कुंजी **नई कुंजी के निर्माण के दौरान स्निफ की जाती है**
- यह **स्थिरता** भी प्रदान करता है

<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>

उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक उपकरण होना चाहिए (फ्लाई पर पंजीकृत या एक वैध उपकरण से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए।

फिर, यह एक नई कुंजी उत्पन्न करना संभव है:
```bash
roadtx genhellokey -d <device id> -k tempkey.key
```
और फिर searchableDeviceKey की जानकारी को PATCH करें:

<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>

एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी एक्सेस चुराना**। अधिक जानकारी के लिए देखें:

{{#ref}}
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
{{#endref}}

<figure><img src="../../images/image (37).png" alt=""><figcaption></figcaption></figure>

## संदर्भ

- [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}}