Translated ['', 'src/pentesting-cloud/azure-security/az-device-registrat

src/pentesting-cloud/azure-security/az-device-registration.md

@@ -1,41 +1,41 @@
-# Az - Device Registration
+# Az - डिवाइस पंजीकरण
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Basic Information
 
-जब एक डिवाइस AzureAD में शामिल होता है, तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है।
+जब कोई डिवाइस AzureAD में शामिल होता है तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है।
 
-जब एक डिवाइस को रजिस्टर किया जाता है, तो **उपयोगकर्ता से उसके खाते के साथ लॉगिन करने के लिए कहा जाता है** (यदि आवश्यक हो तो MFA के लिए पूछता है), फिर यह डिवाइस रजिस्ट्रेशन सेवा के लिए टोकन अनुरोध करता है और फिर अंतिम पुष्टि प्रॉम्प्ट के लिए पूछता है।
+डिवाइस को रजिस्टर करते समय, **user is asked to login with his account** (जरूरत होने पर MFA मांगा जाएगा), उसके बाद यह device registration service के लिए tokens का अनुरोध करता है और फिर अंतिम पुष्टि का prompt दिखाता है।
 
-फिर, डिवाइस में दो RSA की जोड़े उत्पन्न होते हैं: **डिवाइस की** (**सार्वजनिक** कुंजी) जिसे **AzureAD** को भेजा जाता है और **परिवहन** कुंजी (**निजी** कुंजी) जिसे यदि संभव हो तो TPM में संग्रहीत किया जाता है।
+फिर, डिवाइस में दो RSA keypairs जनरेट किए जाते हैं: The **device key** (**public** key) जो **AzureAD** को भेजा जाता है और **transport** key (**private** key) जो संभव हो तो TPM में स्टोर किया जाता है।
 
-फिर, **ऑब्जेक्ट** **AzureAD** में उत्पन्न होता है (Intune में नहीं) और AzureAD डिवाइस को एक **प्रमाणपत्र** वापस देता है जिसे उसने हस्ताक्षरित किया है। आप यह जांच सकते हैं कि **डिवाइस AzureAD में शामिल है** और **प्रमाणपत्र** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा सुरक्षित है)।
+फिर, **object** **AzureAD** में जनरेट किया जाता है (not in Intune) और AzureAD डिवाइस को इसका द्वारा साइन किया गया एक **certificate** वापस देता है। आप यह जांच सकते हैं कि **device is AzureAD joined** और **certificate** के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा प्रोटेक्टेड है).:
 ```bash
 dsregcmd /status
 ```
-डिवाइस पंजीकरण के बाद, **प्राथमिक रिफ्रेश टोकन** LSASS CloudAP मॉड्यूल द्वारा अनुरोध किया जाता है और डिवाइस को दिया जाता है। PRT के साथ **सत्र कुंजी भी प्रदान की जाती है जिसे केवल डिवाइस ही डिक्रिप्ट कर सकता है** (परिवहन कुंजी की सार्वजनिक कुंजी का उपयोग करके) और इसे **PRT का उपयोग करने के लिए आवश्यक है।**
+After the device registration a **Primary Refresh Token** is requested by the LSASS CloudAP module and given to the device. With the PRT is also delivered the **session key encrypted so only the device can decrypt it** (using the public key of the transport key) and it's **needed to use the PRT.**
 
-PRT क्या है इसके बारे में अधिक जानकारी के लिए देखें:
+For more information about what is a PRT check:
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
-### TPM - ट्रस्टेड प्लेटफॉर्म मॉड्यूल
+### TPM - ट्रस्टेड प्लेटफ़ॉर्म मॉड्यूल
 
-**TPM** **कुंजी** **निकासी** से एक बंद डिवाइस (यदि PIN द्वारा सुरक्षित है) की सुरक्षा करता है और OS परत से निजी सामग्री को निकालने से।\
-लेकिन यह **TPM और CPU के बीच भौतिक कनेक्शन की निगरानी** करने या **SYSTEM** अधिकारों वाले प्रक्रिया से सिस्टम चलने के दौरान TPM में **क्रिप्टोग्राफिक सामग्री** का उपयोग करने से सुरक्षा नहीं करता है।
+**TPM** पावर-ऑफ डिवाइस से (यदि PIN से सुरक्षित हो) कुंजी **निकालने** और OS लेयर से प्राइवेट सामग्री निकालने के प्रयासों के खिलाफ **रक्षा** करता है।\
+लेकिन यह TPM और CPU के बीच भौतिक कनेक्शन को **sniffing** करने या सिस्टम चलने के दौरान **SYSTEM** अधिकारों वाले प्रोसेस से TPM में मौजूद **cryptographic material** का **उपयोग** करने के खिलाफ सुरक्षा नहीं करता।
 
-यदि आप निम्नलिखित पृष्ठ की जांच करते हैं, तो आप देखेंगे कि **PRT चुराना** उपयोगकर्ता की तरह पहुंच प्राप्त करने के लिए उपयोग किया जा सकता है, जो शानदार है क्योंकि **PRT डिवाइस में स्थित है**, इसलिए इसे उनसे चुराया जा सकता है (या यदि चुराया नहीं गया तो नए साइनिंग कुंजी उत्पन्न करने के लिए दुरुपयोग किया जा सकता है):
+If you check the following page you will see that **stealing the PRT** can be used to access like a the **user**, which is great because the **PRT is located devices**, so it can be stolen from them (or if not stolen abused to generate new signing keys):
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
-## SSO टोकनों के साथ डिवाइस पंजीकरण
+## Registering a device with SSO tokens
 
-एक हमलावर के लिए यह संभव होगा कि वह समझौता किए गए डिवाइस से Microsoft डिवाइस पंजीकरण सेवा के लिए एक टोकन अनुरोध करे और इसे पंजीकृत करे:
+It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:
 ```bash
 # Initialize SSO flow
 roadrecon auth prt-init
@@ -47,38 +47,38 @@ 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 अनुमतियाँ दी गई थीं**।
+जिससे आपको एक **प्रमाणपत्र मिलेगा जिसे आप भविष्य में PRTs के लिए अनुरोध करने के लिए इस्तेमाल कर सकते हैं**। इसलिए persistence बनाए रखना और **bypassing MFA** संभव हो जाता है क्योंकि नए डिवाइस को रजिस्टर करने के लिए उपयोग किया गया मूल PRT टोकन **पहले से ही MFA permissions granted था**।
 
 > [!TIP]
-> ध्यान दें कि इस हमले को करने के लिए आपको **नए उपकरणों को पंजीकृत करने** की अनुमति की आवश्यकता होगी। इसके अलावा, एक उपकरण को पंजीकृत करना यह नहीं दर्शाता कि उपकरण **Intune में नामांकित होने की अनुमति दी जाएगी**।
+> ध्यान रहें कि इस attack को करने के लिए आपको **register new devices** की permissions चाहिए होंगी। इसके अलावा, किसी डिवाइस को रजिस्टर करना यह नहीं दर्शाता कि डिवाइस को **allowed to enrol into 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)।
+> This attack was fixed in September 2021 as you can no longer register new devices using a SSO tokens. However, it's still possible to register devices in a legit way (having username, password and MFA if needed). Check: [**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)।
+यह संभव था कि आप **request a device ticket**, डिवाइस के मौजूदा टिकट को **overwrite** करें, और इस flow के दौरान **steal the PRT** करें (तो TPM से इसे steal करने की ज़रूरत नहीं रहती)। अधिक जानकारी के लिए [**check this talk**](https://youtu.be/BduCn8cLV1A).
 
 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
 
 > [!CAUTION]
-> हालाँकि, इसे ठीक किया गया था।
+> हालाँकि, इसे fix कर दिया गया।
 
-## WHFB कुंजी को ओवरराइट करें
+## WHFB key को ओवरराइट करना
 
-[**यहाँ मूल स्लाइड देखें**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
+[**Check the original slides here**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
 
-हमले का सारांश:
+Attack summary:
 
-- यह **SSO** के माध्यम से एक **उपकरण** से **पंजीकृत WHFB** कुंजी को **ओवरराइट** करना संभव है
-- यह **TPM सुरक्षा को पराजित करता है** क्योंकि कुंजी **नई कुंजी के निर्माण के दौरान स्निफ की जाती है**
-- यह **स्थिरता** भी प्रदान करता है
+- यह संभव है कि SSO के माध्यम से किसी **device** से **registered WHFB** key को **overwrite** किया जा सके
+- यह **TPM protection को defeat** करता है क्योंकि नई key के generation के दौरान key को **sniffed** किया जाता है
+- यह **persistence** भी प्रदान करता है
 
 <figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
 
-उपयोगकर्ता Azure AD ग्राफ़ के माध्यम से अपनी स्वयं की searchableDeviceKey संपत्ति को संशोधित कर सकते हैं, हालाँकि, हमलावर के पास टेनेट में एक उपकरण होना चाहिए (फ्लाई पर पंजीकृत या एक वैध उपकरण से प्रमाणपत्र + कुंजी चुराई गई) और AAD ग्राफ़ के लिए एक मान्य एक्सेस टोकन होना चाहिए।
+Users अपने own searchableDeviceKey property को Azure AD Graph के माध्यम से modify कर सकते हैं, हालांकि attacker के पास tenant में एक device होना चाहिए (on-the-fly registered या किसी legit device से stolen cert + key वाला) और AAD Graph के लिए एक valid access token होना चाहिए।
 
-फिर, यह एक नई कुंजी उत्पन्न करना संभव है:
+फिर, यह संभव है कि नई key generate की जाए:
 ```bash
 roadtx genhellokey -d <device id> -k tempkey.key
 ```
@@ -86,7 +86,7 @@ roadtx genhellokey -d <device id> -k tempkey.key
 
 <figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
 
-एक उपयोगकर्ता से **device code phishing** के माध्यम से एक एक्सेस टोकन प्राप्त करना संभव है और पिछले चरणों का दुरुपयोग करके **उसकी एक्सेस चुराना**। अधिक जानकारी के लिए देखें:
+यह संभव है कि किसी उपयोगकर्ता से **device code phishing** के माध्यम से access token प्राप्त किया जा सके और पिछले चरणों का दुरुपयोग करके **steal his access** किया जा सके। अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md