Translated ['', 'src/pentesting-cloud/azure-security/az-basic-informatio

src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md

@@ -1,98 +1,171 @@
-# Az - Tokens & Public Applications
+# Az - टोकन और सार्वजनिक एप्लिकेशन
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## मूल जानकारी
 
-Entra ID Microsoft का cloud-based identity और access management (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसे सेवाओं के लिए आधारभूत authentication और authorization सिस्टम के रूप में काम करता है। Azure AD OAuth 2.0 authorization framework और OpenID Connect (OIDC) authentication protocol को लागू करता है ताकि resources तक पहुँच को प्रबंधित किया जा सके।
+Entra ID Microsoft का क्लाउड-आधारित identity and access management (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसी सेवाओं के लिए मूल authentication और authorization सिस्टम के रूप में काम करता है। Azure AD संसाधनों तक पहुँच को प्रबंधित करने के लिए OAuth 2.0 authorization framework और OpenID Connect (OIDC) authentication protocol लागू करता है।
 
 ### OAuth
 
-**Key Participants in OAuth 2.0:**
+**OAuth 2.0 में मुख्य प्रतिभागी:**
 
-1. **Resource Server (RS):** संसाधनों की रक्षा करता है जो resource owner के स्वामित्व में होते हैं।
-2. **Resource Owner (RO):** सामान्यतः एक end-user जो संरक्षित संसाधनों का मालिक होता है।
-3. **Client Application (CA):** एक ऐसा application जो resource owner की ओर से संसाधनों तक पहुँच चाहती है।
-4. **Authorization Server (AS):** client applications को प्रमाणीकरण और अधिकरण करने के बाद access tokens जारी करता है।
+1. **Resource Server (RS):** resource owner के स्वामित्व वाले संसाधनों की रक्षा करता है।
+2. **Resource Owner (RO):** आमतौर पर एक अंत-उपयोगकर्ता जो सुरक्षित संसाधनों का मालिक होता है।
+3. **Client Application (CA):** resource owner की ओर से संसाधनों तक पहुँच चाहने वाला एक एप्लिकेशन।
+4. **Authorization Server (AS):** उन्हें प्रमाणीकृत और अधिकृत करने के बाद client applications को access tokens जारी करता है।
 
-**Scopes and Consent:**
+**Scopes और Consent:**
 
-- **Scopes:** resource server पर परिभाषित विस्तृत permissions जो access स्तरों को निर्दिष्ट करते हैं।
-- **Consent:** वह प्रक्रिया जिसके द्वारा एक resource owner client application को विशेष scopes के साथ संसाधनों तक पहुँचने की अनुमति देता है।
+- **Scopes:** resource server पर परिभाषित सूक्ष्म अनुमतियाँ जो पहुँच के स्तर निर्दिष्ट करती हैं।
+- **Consent:** वह प्रक्रिया जिसके द्वारा resource owner किसी client application को विशिष्ट scopes के साथ संसाधनों तक पहुँच की अनुमति देता है।
 
-**Microsoft 365 Integration:**
+**Microsoft 365 एकीकरण:**
 
 - Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और कई "first-party" OAuth applications से मिलकर बना है।
-- ये applications गहराई से एकीकृत होते हैं और अक्सर परस्पर निर्भर service संबंध होते हैं।
-- उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, Microsoft इन first-party applications को "implied consent" या "pre-consent" प्रदान करता है।
-- **Implied Consent:** कुछ applications को विशिष्ट scopes तक पहुंच स्वतः ही **प्रदान कर दी जाती है बिना स्पष्ट user या administrator approval के**।
-- ये pre-consented scopes आमतौर पर उपयोगकर्ताओं और administrators दोनों से छिपे होते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।
+- ये एप्लिकेशन गहराई से एकीकृत होते हैं और अक्सर परस्पर निर्भर सर्विस संबंध रखते हैं।
+- उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, Microsoft इन first-party एप्लिकेशन्स को "implied consent" या "pre-consent" प्रदान करता है।
+- **Implied Consent:** कुछ एप्लिकेशन स्वचालित रूप से **विशिष्ट scopes तक पहुँच प्रदान किए जाते हैं बिना स्पष्ट user या administrator की अनुमति के**l.
+- ये pre-consented scopes आमतौर पर उपयोगकर्ताओं और प्रशासकों दोनों के लिए छिपे रहते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।
 
-**Client Application Types:**
+Client Application प्रकार:
 
 1. **Confidential Clients:**
-- इनके पास अपने स्वयं के credentials होते हैं (उदा. passwords या certificates)।
-- ये authorization server को **सुरक्षित रूप से प्रमाणित कर सकते हैं**।
+- अपने स्वयं के credentials होते हैं (उदा., passwords या certificates)।
+- authorization server के समक्ष **सुरक्षित रूप से स्वयं को प्रमाणीकृत** कर सकते हैं।
 2. **Public Clients:**
-- इनके पास यूनिक credentials नहीं होते।
-- ये authorization server को सुरक्षित रूप से प्रमाणित नहीं कर सकते।
-- **Security Implication:** जब कोई public client application token का अनुरोध करता है तो एक attacker उस public client application का impersonate कर सकता है, क्योंकि authorization server के पास application की वैधता सत्यापित करने का कोई तंत्र नहीं होता।
+- उनके पास unique credentials नहीं होते।
+- authorization server के प्रति सुरक्षित रूप से प्रमाणीकृत नहीं कर सकते।
+- **Security Implication:** एक attacker public client application का impersonate कर सकता है जब tokens का अनुरोध कर रहा हो, क्योंकि authorization server के पास एप्लिकेशन की वैधता सत्यापित करने का कोई mechanism नहीं होता।
+
+### ROPC / Password Grant
+
+The OAuth2 **Resource Owner Password Credentials** (**ROPC**) फ्लो सीधे `POST` का उपयोग करता है `https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token` पर, `grant_type=password`, एक **username**, **password**, एक **client_id**, और अनुरोधित **scope** के साथ। Entra ID में यह मुख्य रूप से **public clients** के लिए रुचिकर है क्योंकि attacker Microsoft first-party client IDs या किसी भी अन्य अनुमत public client को बिना secret के reuse कर सकता है।
+```bash
+curl -X POST "https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token" \
+-H "Content-Type: application/x-www-form-urlencoded" \
+--data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
+--data-urlencode "client_info=1" \
+--data-urlencode "grant_type=password" \
+--data-urlencode "username=user@corp.com" \
+--data-urlencode "password=Password123!" \
+--data-urlencode "scope=https://graph.microsoft.com/.default"
+```
+If the credentials are valid and the flow is allowed, Entra can return **access tokens** and sometimes **refresh tokens** that are immediately usable against Microsoft Graph or the target resource.
+
+### Entra ID Sign-In Log Bypass Classes
+
+कुछ ऐतिहासिक Entra ID बग्स ने अपेक्षित **Entra ID sign-in log** एंट्री बनाये बिना **password validation** या यहाँ तक कि **full token issuance** की अनुमति दी थी। इन मामलों को ठीक कर दिया गया है, लेकिन इन तकनीकों को समझना अभी भी उपयोगी है ताकि यह पता चले कि auth pipelines किस तरह फेल हो सकती हैं और कैसे कुछ स्थितियों में **downstream token use visible** रहता है जबकि ऊपर की तरफ का sign-in telemetry अनुपस्थित रहता है।
+
+#### 1. Foreign-tenant endpoint for stealth password validation
+
+यदि request किसी अलग **tenant GUID** के token endpoint पर भेजी जाती है, तो Entra फिर भी यह वैलिडेट कर सकता है कि दर्ज किया गया password दिए गए username के लिए सही है या नहीं, इससे पहले कि flow असफल हो क्योंकि वह user उस foreign tenant में मौजूद नहीं है। ऐतिहासिक रूप से इससे संभव हुआ था:
+
+- **Password spraying / credential validation** बिना victim tenant में संबंधित sign-in log के
+- एक response का अंतर जो यह प्रकट करता है कि password step सफल हुआ या नहीं
+- कोई token जारी नहीं होता, पर सामान्य failed logon की तुलना में कम telemetry रिकॉर्ड होता है
+
+#### 2. Force a post-password failure
+
+यदि कोई parameter जो credential validation के बाद उपयोग होता है invalid है, जैसे कि एक invalid `client_id`, तो कुल लेनदेन असफल हो सकता है भले ही password पहले ही सही था। ऐतिहासिक रूप से इससे ऐसा हुआ कि अंतिम view में **failed** login दिखता था जबकि वह छुपा देता था कि password guess सफल रहा था।
+
+याद रखने का पैटर्न:
+
+- **Password check succeeds**
+- बाद की किसी validation step में failure होता है
+- लॉग केवल अंतिम ट्रांज़ैक्शन स्थिति को दर्शाता है, ना कि सफल password-validation step को
+
+#### 3. Trigger logging failure with oversized-but-valid values
+
+सबसे खतरनाक वर्ग तब है जब request वाक्यात्मक रूप से वैध रहती है, authentication सफल हो जाती है, **tokens are returned**, लेकिन किसी **logged field** का आकार इतना बड़ा होता है कि logging pipeline टूट जाता है। रिपोर्ट किए गए उदाहरणों में शामिल थे:
+
+- मान्य scopes को हजारों बार दोहराना, जैसे `openid openid openid ...`
+- अत्यधिक लंबा लेकिन फिर भी स्वीकार्य **User-Agent** header प्रदान करना
+
+यह एक सामान्य वर्ग के मुद्दों का संकेत देता है जहाँ:
+
+1. Entra credentials और request syntax को वैलिडेट करता है
+2. token सफलतापूर्वक जारी किया जाता है
+3. logging किसी raw user-controlled field को persist करने की कोशिश करता है
+4. logging write लंबाई या schema assumptions के कारण फेल हो जाता है
+5. user को कोई संबंधित sign-in record के बिना valid token मिल जाता है
+
+Example of the repeated-scope pattern:
+```bash
+curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
+-H "Content-Type: application/x-www-form-urlencoded" \
+--data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
+--data-urlencode "client_info=1" \
+--data-urlencode "grant_type=password" \
+--data-urlencode "username=user@corp.com" \
+--data-urlencode "password=Password123!" \
+--data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid '; done)"
+```
+#### Hunting / defensive note
+
+हर वैध token उपयोग के साथ एक मिलान करने वाला Entra sign-in event होगा, ऐसा मत मानें। जब संदेहास्पद Graph activity की जांच कर रहे हों, तो निम्न को समन्वयित करें:
+
+- **Non-interactive sign-in logs**
+- **Graph Activity Logs**
+- **IP address**, **user/object ID**, **session/correlation identifiers**, और **time windows**
+
+एक व्यवहारिक सत्यापन तरीका यह है कि किसी संदिग्ध अदृश्य सफलता को दो सामान्य failed logons के बीच ब्रैकेट करें और फिर सत्यापित करें कि उम्मीद की गई अनुक्रम `Failed -> Successful -> Failed` ingestion delay के बाद बीच वाला event गायब तो नहीं है। यदि downstream Graph activity मौजूद है लेकिन sign-in log नहीं है, तो इसे संभावित **sign-in logging gap** या **token replay** स्थिति माना जाना चाहिए।
 
 ## Authentication Tokens
 
-OIDC में उपयोग होने वाले **तीन प्रकार के tokens** हैं:
+OIDC में उपयोग होने वाले तीन प्रकार के tokens हैं:
 
-- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट इस token को resource server के पास resources तक पहुँचने के लिए प्रस्तुत करता है। इसे सिर्फ एक विशिष्ट user, client, और resource के संयोजन के लिए उपयोग किया जा सकता है और यह expiry तक **revoked नहीं किया जा सकता** - डिफ़ॉल्ट रूप से यह 1 hour होता है।
-- **ID Tokens**: क्लाइंट को यह **authorization server से प्राप्त** होता है। इसमें user के बारे में बुनियादी जानकारी होती है। यह **विशिष्ट user और client के संयोजन के लिए बंधा** होता है।
-- **Refresh Tokens**: access token के साथ क्लाइंट को प्रदान किए जाते हैं। इनका उपयोग **नये access और ID tokens प्राप्त करने** के लिए होता है। यह विशिष्ट user और client के संयोजन के लिए बंधा होता है और revoked किया जा सकता है। inactive refresh tokens की डिफ़ॉल्ट expiry **90 दिन** है और active tokens के लिए **कोई expiry नहीं** है (एक refresh token से नए refresh tokens प्राप्त करना संभव है)।
-- एक refresh token को एक **`aud`**, कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और यह केवल उसी aud, scopes (और अधिक नहीं) और tenant के लिए access tokens जनरेट करने में सक्षम होना चाहिए। हालांकि, **FOCI applications tokens** के साथ ऐसा नहीं होता।
-- एक refresh token encrypted होता है और केवल Microsoft ही इसे decrypt कर सकता है।
-- नया refresh token प्राप्त करने से पिछला refresh token revoked नहीं होता।
+- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट यह token resource server को प्रस्तुत करता है ताकि वह resources को access कर सके। यह केवल user, client, और resource के एक विशिष्ट संयोजन के लिए इस्तेमाल किया जा सकता है और expiry तक revoked नहीं किया जा सकता — डिफ़ॉल्ट रूप से यह 1 hour होता है।
+- **ID Tokens**: क्लाइंट यह token authorization server से प्राप्त करता है। इसमें user के बारे में बुनियादी जानकारी होती है। यह specific combination of user और client के लिए bound होता है।
+- **Refresh Tokens**: access token के साथ क्लाइंट को प्रदान किए जाते हैं। नए access और ID tokens पाने के लिए उपयोग किए जाते हैं। यह user और client के specific combination से bound होता है और revoked किया जा सकता है। inactive refresh tokens के लिए default expiry **90 days** है और active tokens के लिए **कोई expiry नहीं** (refresh token से नए refresh tokens प्राप्त करना संभव है)।
+- एक refresh token को एक **`aud`**, कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और यह केवल उसी aud, scopes (और उनसे आगे नहीं) और tenant के लिए access tokens जेनरेट करने में सक्षम होना चाहिए। हालांकि, यह **FOCI applications tokens** के साथ मामला नहीं है।
+- एक refresh token encrypt किया जाता है और केवल Microsoft ही इसे decrypt कर सकता है।
+- नया refresh token प्राप्त करने से पिछला refresh token revoke नहीं होता।
 
 > [!WARNING]
-> **conditional access** की जानकारी **JWT** के अंदर **store** होती है। इसलिए, यदि आप किसी allowed IP address से **token अनुरोध करते हैं**, वह IP token में **store** हो जाएगी और फिर आप उस token का उपयोग किसी **non-allowed IP से resources तक पहुँचने** के लिए कर सकते हैं।
+> **conditional access** के लिए जानकारी **JWT** के अंदर **stored** होती है। इसलिए, अगर आप किसी allowed IP address से token का अनुरोध करते हैं, तो वह **IP** token में **store** हो जाएगा और फिर आप उस token का उपयोग किसी non-allowed IP से resources को access करने के लिए कर सकते हैं।
 
 ### Access Tokens "aud"
 
-"aud" फ़ील्ड में संकेतित फ़ील्ड वह **resource server** (application) है जिसका उपयोग login करने के लिए किया जाता है।
+"aud" फ़ील्ड में दर्शाया गया फ़ील्ड वह **resource server** (application) होता है जिसका उपयोग login करने के लिए किया जाता है।
 
-कमांड `az account get-access-token --resource-type [...]` निम्नलिखित types का समर्थन करता है और इनमें से प्रत्येक resulting access token में एक विशिष्ट "aud" जोड़ देगा:
+कमांड `az account get-access-token --resource-type [...]` निम्न प्रकारों का समर्थन करता है और प्रत्येक परिणामस्वरूप access token में एक विशिष्ट "aud" जोड़ देगा:
 
 > [!CAUTION]
-> ध्यान दें कि निम्नलिखित केवल `az account get-access-token` द्वारा समर्थित APIs हैं लेकिन और भी हैं।
+> ध्यान दें कि निम्न केवल `az account get-access-token` द्वारा समर्थित APIs हैं, लेकिन और भी हैं।
 
 <details>
 
 <summary>aud examples</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: legacy Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग होता है, जो applications को Azure Active Directory (Azure AD) में directory डेटा पढ़ने और लिखने की अनुमति देता है।
+- **aad-graph (Azure Active Directory Graph API)**: legacy Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग किया जाता है, जो applications को Azure Active Directory (Azure AD) में directory डेटा पढ़ने और लिखने की अनुमति देता है।
 - `https://graph.windows.net/`
 
-* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure resources का प्रबंधन करने के लिए उपयोग होता है। इसमें virtual machines, storage accounts जैसी resources बनाना, अपडेट करना, और हटाना जैसी operations शामिल हैं।
+* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure resources को प्रबंधित करने के लिए उपयोग किया जाता है। इसमें virtual machines, storage accounts आदि जैसे resources बनाना, अपडेट करना, और हटाना शामिल है।
 - `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग होता है, जो cloud में बड़े पैमाने पर parallel और high-performance computing applications को कुशलतापूर्वक सक्षम करता है।
+- **batch (Azure Batch Services)**: Azure Batch तक पहुंचने के लिए उपयोग होता है, जो क्लाउड में बड़े पैमाने पर parallel और high-performance computing एप्लिकेशन कुशलतापूर्वक चलाने की सेवा प्रदान करता है।
 - `https://batch.core.windows.net/`
 
-* **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ इंटरैक्ट करने के लिए उपयोग होता है, जो एक स्केलेबल डेटा स्टोरेज और analytics सेवा है।
+* **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ इंटरैक्ट करने के लिए उपयोग किया जाता है, जो एक स्केलेबल डेटा स्टोरेज और analytics सेवा है।
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग होता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित media processing और delivery सेवाएं प्रदान करता है।
+- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग होता है, जो वीडियो और ऑडियो सामग्री के लिए cloud-based media processing और delivery सेवाएँ प्रदान करता है।
 - `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Microsoft 365 सेवाओं के डेटा के लिए unified endpoint, Microsoft Graph API तक पहुँचने के लिए उपयोग होता है। यह Azure AD, Office 365, Enterprise Mobility, और Security सेवाओं जैसे स्रोतों से डेटा और insights तक पहुँचने की अनुमति देता है।
+* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग किया जाता है, जो Microsoft 365 सेवाओं के डेटा के लिए unified endpoint है। यह Azure AD, Office 365, Enterprise Mobility, और Security सेवाओं जैसे स्रोतों से डेटा और insights तक पहुँच की अनुमति देता है।
 - `https://graph.microsoft.com`
 
-- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL, PostgreSQL, और MariaDB जैसे open-source relational database engines के लिए Azure Database सेवाओं तक पहुँचने के लिए उपयोग होता है।
+- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL, PostgreSQL, और MariaDB जैसे open-source relational database engines के लिए Azure Database सेवाओं तक पहुँचने के लिए उपयोग किया जाता है।
 - `https://ossrdbms-aad.database.windows.net`
 
 </details>
 
 ### Access Tokens Scopes "scp"
 
-Access token का scope access token JWT के अंदर scp key में संग्रहीत होता है। ये scopes परिभाषित करते हैं कि access token किस चीज़ तक पहुँच रखता है।
+एक access token का scope access token JWT के अंदर scp key के भीतर store होता है। ये scopes परिभाषित करते हैं कि access token को क्या access करने की अनुमति है।
 
-यदि कोई JWT किसी विशिष्ट API से संपर्क करने की अनुमति रखता है पर उसके पास अनुरोधित क्रिया को करने के लिए आवश्यक scope **नहीं है**, तो वह JWT उस क्रिया को करने में **सक्षम नहीं** होगा।
+यदि कोई JWT किसी specific API से संपर्क करने की अनुमति देता है लेकिन अनुरोधित क्रिया करने के लिए उसके पास आवश्यक scope नहीं है, तो वह उस JWT के साथ वह क्रिया नहीं कर पाएगा।
 
 ### Get refresh & access token example
 ```python
@@ -144,31 +217,31 @@ scopes=["https://graph.microsoft.com/.default"],
 )
 pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
-### Other access token fields
+### अन्य access token फ़ील्ड
 
-- **appid**: टोकन जनरेट करने के लिए उपयोग किया गया Application ID
-- **appidacr**: The Application Authentication Context Class Reference यह दर्शाता है कि client को कैसे authenticated किया गया था; public client के लिए value 0 है, और यदि client secret उपयोग किया गया हो तो value 1 है
-- **acr**: The Authentication Context Class Reference claim "0" होता है जब end-user authentication ने ISO/IEC 29115 की requirements को पूरा नहीं किया हो।
-- **amr**: The Authentication method बताती है कि टोकन को किस तरीके से authenticated किया गया था। "pwd" value का मतलब है कि password का उपयोग किया गया।
-- **groups**: उन groups को दर्शाता है जिनके सदस्य के रूप में principal है।
-- **iss**: issuer उस security token service (STS) की पहचान करता है जिसने टोकन जनरेट किया था। e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid tenant ID है)
+- **appid**: टोकन जनरेट करने में उपयोग किया गया Application ID
+- **appidacr**: The Application Authentication Context Class Reference यह दर्शाता है कि client को कैसे authenticated किया गया था; public client के लिए मान 0 होता है, और यदि client secret का उपयोग किया गया हो तो मान 1 होगा
+- **acr**: The Authentication Context Class Reference claim "0" होता है जब end-user authentication ने ISO/IEC 29115 की आवश्यकताओं को पूरा नहीं किया हो।
+- **amr**: Authentication method बताता है कि token को कैसे authenticated किया गया। "pwd" मान का अर्थ है कि password का उपयोग किया गया था।
+- **groups**: उन groups को दर्शाता है जिनका principal सदस्य है।
+- **iss**: Issuer उस security token service (STS) की पहचान करता है जिसने token जनरेट किया। उदा. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (यह uuid tenant ID है)
 - **oid**: principal का object ID
 - **tid**: Tenant ID
-- **iat, nbf, exp**: Issued at (जब यह जारी हुआ), Not before (इस समय से पहले उपयोग नहीं किया जा सकता, आमतौर पर iat के समान), Expiration time (समाप्ति समय)।
+- **iat, nbf, exp**: Issued at (कब जारी किया गया), Not before (इस समय से पहले उपयोग नहीं किया जा सकता, आमतौर पर iat के समान मान), Expiration time.
 
-## FOCI Tokens Privilege Escalation
+## FOCI Tokens में Privilege Escalation
 
-पहले बताया गया था कि refresh tokens को उन **scopes** के साथ बाँधकर रखा जाना चाहिए जिनके साथ वे जनरेट किए गए थे, और जिन **application** और **tenant** के लिए वे जनरेट किए गए थे। यदि इन सीमाओं में से कोई भी टूटती है, तो privilege escalation संभव हो सकता है क्योंकि यह अन्य resources और tenants के लिए access tokens जनरेट करने की अनुमति दे सकता है जिन तक उपयोगकर्ता की पहुँच है और वह मूल उद्देश्य से अधिक scopes के साथ हो सकते हैं।
+पहले उल्लेख किया गया था कि refresh tokens को उन **scopes** से बांधा जाना चाहिए जिनके साथ वे बनाए गए थे, उस **application** और जिस **tenant** के लिए वे बनाए गए थे। यदि इन किसी भी सीमाओं का उल्लंघन होता है, तो privileges escalate करना संभव हो सकता है क्योंकि इससे उन अन्य resources और tenants के लिए access tokens जनरेट करना संभव हो जाएगा जिन तक user की पहुँच है, और साथ ही उन scopes से अधिक scopes के साथ जिनके लिए मूल रूप से इरादा था।
 
-Moreover, **this is possible with all refresh tokens** in the [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) क्योंकि जैसा कि [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) में उल्लेख है: "Refresh tokens are bound to a combination of user and client, but **aren't tied to a resource or tenant**. A client can use a refresh token to acquire access tokens **across any combination of resource and tenant** where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."
+इसके अलावा, यह ध्यान रखें कि [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) में यह सब refresh tokens के साथ संभव है क्योंकि जैसा कि [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) में कहा गया है: "Refresh tokens are bound to a combination of user and client, but **aren't tied to a resource or tenant**. A client can use a refresh token to acquire access tokens **across any combination of resource and tenant** where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."
 
-Moreover, note that the FOCI applications are public applications, so **no secret is needed** to authenticate to the server.
+ध्यान दें कि FOCI applications public applications हैं, इसलिए सर्वर को authenticate करने के लिए **कोई secret आवश्यक नहीं है**।
 
-फिर [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए ज्ञात FOCI clients को [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv) पर देखा जा सकता है।
+फिर, [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए ज्ञात FOCI clients को [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv) पर देखा जा सकता है।
 
-### Get different scope
+### अलग scope प्राप्त करें
 
-पिछले उदाहरण कोड के साथ आगे बढ़ते हुए, इस कोड में एक अलग scope के लिए नया token अनुरोध किया गया है:
+पिछले example code के अनुसार, इस code में अलग scope के लिए एक नया token request किया गया है:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -185,7 +258,7 @@ scopes=[
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-### विभिन्न client और scopes प्राप्त करें
+### अलग client और scopes प्राप्त करें
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
@@ -207,31 +280,31 @@ A BroCI refresh tokens is a brokered token exchange pattern where an existing re
 
 These refresh tokens must be minted in that broker context (a regular refresh token usually cannot be used as a BroCI refresh token).
 
-### Goal and purpose
+### लक्ष्य और उद्देश्य
 
-BroCI का उद्देश्य एक broker-capable app chain से वैध user session को reuse करके किसी दूसरी trusted app/resource जोड़ी के लिए tokens अनुरोध करना है। इसका मतलब है कि original token से "privilege escalation" संभव हो सकता है।
+BroCI का लक्ष्य broker-capable app chain से एक वैध user session का पुन: उपयोग करना और दूसरे trusted app/resource जोड़ी के लिए tokens अनुरोध करना है। इसलिए, यह मूल token से privileges को escalate करने की अनुमति देता है।
 
-ऑफेंसिव परिप्रेक्ष्य से यह इसलिए महत्वपूर्ण है क्योंकि:
+ऑफेंसिव दृष्टिकोण से, यह मायने रखता है क्योंकि:
 
-- यह pre-consented first-party app paths अनलॉक कर सकता है जो standard refresh exchanges से उपलब्ध नहीं होते।
-- यह उच्च-मूल्य के APIs (उदाहरण के लिए Microsoft Graph) के लिए access tokens लौटा सकता है, उन app identities के तहत जिनके पास व्यापक delegated permissions हैं।
-- यह क्लासिक FOCI client switching से परे post-authentication token pivoting के अवसर बढ़ाता है।
+- यह pre-consented first-party app paths को अनलॉक कर सकता है जो standard refresh exchanges से उपलब्ध नहीं होते।
+- यह high-value APIs (उदाहरण के लिए, Microsoft Graph) के लिए access tokens लौट सकता है, उन app identities के तहत जिनके पास व्यापक delegated permissions होते हैं।
+- यह post-authentication token pivoting के अवसरों का विस्तार करता है, पारंपरिक FOCI client switching से आगे।
 
-NAA/BroCI refresh token में जो बदलता है वह दिखाई देने वाले token format नहीं है, बल्कि **issuance context** और broker-संबंधित metadata है जिसे Microsoft brokered refresh operations के दौरान validate करता है।
+NAA/BroCI refresh token में जो बदलता है वह दिखाई देने वाला token फ़ॉर्मैट नहीं है, बल्कि issuance context और broker-संबंधित metadata है जिसे Microsoft brokered refresh operations के दौरान validate करता है।
 
-NAA/BroCI token exchanges सामान्य OAuth refresh exchange के समान नहीं हैं।
+NAA/BroCI token exchanges सामान्य OAuth refresh exchange जैसे नहीं हैं।
 
-- एक regular refresh token (उदाहरण के लिए device code flow के माध्यम से प्राप्त) आमतौर पर standard `grant_type=refresh_token` operations के लिए मान्य होता है।
-- एक BroCI request अतिरिक्त broker context शामिल करता है (`brk_client_id`, broker `redirect_uri`, और `origin`)।
-- Microsoft यह validate करता है कि प्रस्तुत refresh token किसी matching brokered context में ही mint किया गया था।
-- इसलिए कई "normal" refresh tokens BroCI requests में `AADSTS900054` जैसी त्रुटियों के साथ fail कर जाते हैं ("Specified Broker Client ID does not match ID in provided grant")।
-- आप आमतौर पर किसी normal refresh token को code में BroCI-valid में "convert" नहीं कर सकते।
-- आपको एक ऐसा refresh token चाहिए जो पहले से ही किसी compatible brokered flow द्वारा issue किया गया हो।
+- A regular refresh token (for example obtained via device code flow) is usually valid for standard `grant_type=refresh_token` operations.
+- A BroCI request includes additional broker context (`brk_client_id`, broker `redirect_uri`, and `origin`).
+- Microsoft validates whether the presented refresh token was minted in a matching brokered context.
+- Therefore, many "normal" refresh tokens fail in BroCI requests with errors such as `AADSTS900054` ("Specified Broker Client ID does not match ID in provided grant").
+- You generally cannot "convert" a normal refresh token into a BroCI-valid one in code.
+- You need a refresh token already issued by a compatible brokered flow.
 
-Check the web **<https://entrascopes.com/>** to find BroCI configured apps an the trust relationships they have.
+Check the web <https://entrascopes.com/> to find BroCI configured apps an the trust relationships they have.
 
 
-### Mental model
+### मानसिक मॉडल
 
 Think of BroCI as:
 
@@ -239,19 +312,19 @@ Think of BroCI as:
 
 If any part of that broker chain does not match, the exchange fails.
 
-### Where to find a BroCI-valid refresh token
+### BroCI-valid refresh token कहां पाएँ
 
 One practical way is browser portal traffic collection:
 
-1. Sign in to `https://entra.microsoft.com` (or Azure portal).
-2. Open DevTools -> Network.
-3. Filter for:
+1. `https://entra.microsoft.com` (or Azure portal) में साइन इन करें।
+2. DevTools खोलें -> Network।
+3. फ़िल्टर करें:
 - `oauth2/v2.0/token`
 - `management.core.windows.net`
-4. Identify the brokered token response and copy `refresh_token`.
-5. Use that refresh token with matching BroCI parameters (`brk_client_id`, `redirect_uri`, `origin`) when requesting tokens for target apps (for example ADIbizaUX / Microsoft_Azure_PIMCommon scenarios).
+4. brokered token response पहचानें और `refresh_token` कॉपी करें।
+5. target apps के लिए tokens अनुरोध करते समय उस refresh token का उपयोग matching BroCI parameters (`brk_client_id`, `redirect_uri`, `origin`) के साथ करें (उदाहरण के लिए ADIbizaUX / Microsoft_Azure_PIMCommon scenarios)।
 
-### Common errors
+### सामान्य त्रुटियाँ
 
 - `AADSTS900054`: The refresh token context does not match the supplied broker tuple (`brk_client_id` / `redirect_uri` / `origin`) or the token is not from a brokered portal flow.
 - `AADSTS7000218`: The selected client flow expects a confidential credential (`client_secret`/assertion), often seen when trying device code with a non-public client.
@@ -532,30 +605,31 @@ raise SystemExit(main())
 
 ## टोकन कहाँ मिलते हैं
 
-एक हमलावर के नज़रिए से यह जानना बहुत उपयोगी है कि जहाँ उदाहरण के लिए पीड़ित के PC में प्रवेश कर लिया गया हो वहां पर access और refresh tokens कहाँ मिल सकते हैं:
+एक हमलावर के दृष्टिकोण से यह जानना बहुत महत्वपूर्ण होता है कि उदाहरण के लिए जब किसी पीड़ित के PC से समझौता हो जाता है, तो access और refresh tokens कहां मिल सकते हैं:
 
 - के अंदर **`<HOME>/.Azure`**
-- **`azureProfile.json`** में पिछले लॉगिन किए गए यूज़र्स की जानकारी होती है
+- **`azureProfile.json`** में पिछले लॉग इन उपयोगकर्ताओं की जानकारी होती है
 - **`clouds.config contains`** में subscriptions की जानकारी होती है
-- **`service_principal_entries.json`** में applications credentials होते हैं (tenant id, clients और secret)। केवल Linux & macOS में
-- **`msal_token_cache.json`** में access tokens और refresh tokens होते हैं। केवल Linux & macOS में
-- **`service_principal_entries.bin`** और msal_token_cache.bin Windows में उपयोग होते हैं और DPAPI से encrypted होते हैं
+- **`service_principal_entries.json`** में applications के credentials (tenant id, clients और secret) होते हैं। केवल Linux & macOS पर
+- **`msal_token_cache.json`** में access tokens और refresh tokens होते हैं। केवल Linux & macOS पर
+- **`service_principal_entries.bin`** और msal_token_cache.bin Windows पर उपयोग होते हैं और DPAPI के साथ encrypted होते हैं
 - **`msal_http_cache.bin`** HTTP request का cache है
-- Load it: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
-- **`AzureRmContext.json`** में Az PowerShell का उपयोग करके किए गए पिछले लॉगिन्स की जानकारी होती है (लेकिन credentials नहीं)
-- के अंदर **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** कई `.bin` फ़ाइलें होती हैं जिनमें **access tokens**, ID tokens और account information यूज़र के DPAPI से encrypted होती हैं।
-- `.tbres` फ़ाइलों में और भी **access tokens** मिल सकते हैं, जो **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** के अंदर होते हैं और DPAPI से base64 encrypt किए होते हैं जिनमें access tokens होते हैं।
-- Linux और macOS में आप Az PowerShell (यदि उपयोग किया गया हो) से **access tokens, refresh tokens और id tokens** प्राप्त कर सकते हैं: `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
-- Windows में यह केवल id tokens जेनरेट करता है।
-- यह जांचने के लिए कि Az PowerShell Linux और macOS पर उपयोग किया गया था या नहीं, देखें कि `$HOME/.local/share/.IdentityService/` मौजूद है या नहीं (हालाँकि उसमे मौजूद फ़ाइलें खाली और बेकार होती हैं)
-- अगर यूज़र **ब्राउज़र से Azure में logged in** है, तो इस [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) के अनुसार authentication flow को **redirect to localhost** के साथ शुरू करना संभव है, ब्राउज़र को ऑटोमेटिकली लॉगिन authorize करवाना, और फिर refresh token प्राप्त करना। ध्यान दें कि केवल कुछ ही FOCI applications localhost पर redirect की अनुमति देते हैं (जैसे az cli या powershell module), इसलिए इन applications को allow होना चाहिए।
-- ब्लॉग में समझाई गई एक और विकल्प टूल [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) का उपयोग करना है जो किसी भी application का उपयोग कर सकता है क्योंकि यह OAuth code प्राप्त करेगा और फिर redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient` का उपयोग करके final auth पेज के title से refresh token ले लेगा।
+- इसे लोड करें: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
+- **`AzureRmContext.json`** में Az PowerShell का उपयोग करके पूर्व logins की जानकारी होती है (लेकिन कोई credentials नहीं)
+- के अंदर **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** कई `.bin` फाइलें हैं जिनमें users के DPAPI से encrypted **access tokens**, ID tokens और account जानकारी होती है।
+- `.tbres` फाइलों में और भी **access tokens** मिल सकते हैं, जो कि **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** के अंदर होते हैं और DPAPI से encrypted base64 रखते हैं जिसमें access tokens होते हैं।
+- Linux और macOS पर आप Az PowerShell (यदि उपयोग किया गया हो) से **access tokens, refresh tokens और id tokens** पा सकते हैं, चलाकर: `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
+- Windows में यह केवल id tokens बनाता है।
+- यह जानना संभव है कि Linux और macSO में Az PowerShell का उपयोग हुआ था या नहीं, यह चेक करके कि `$HOME/.local/share/.IdentityService/` मौजूद है (हालाँकि इसमें मौजूद फाइलें खाली और बेकार होती हैं)
+- यदि user ब्राउज़र के साथ Azure में लॉग इन है, तो इस [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) के अनुसार authentication flow को **redirect to localhost** के साथ शुरू करना संभव है, ब्राउज़र को ऑटोमेटिकली login authorize करने के लिए प्रेरित करके और refresh token प्राप्त करना। ध्यान दें कि केवल कुछ FOCI applications ही localhost पर redirect की अनुमति देते हैं (जैसे az cli या powershell module), इसलिए इन्हें allow किया जाना चाहिए।
+- ब्लॉग में समझाया गया एक और विकल्प है टूल [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) का उपयोग करना, जो किसी भी application का उपयोग कर सकता है क्योंकि यह **OAuth code लेगा और फिर final auth पेज के title से redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient` का उपयोग करके refresh token प्राप्त करेगा**।
 
-## संदर्भ
+## References
 
 - [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
 - [https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md](https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md)
 - [https://specterops.io/blog/2025/10/15/naa-or-broci-let-me-explain/](https://specterops.io/blog/2025/10/15/naa-or-broci-let-me-explain/)
 - [https://specterops.io/blog/2025/08/13/going-for-brokering-offensive-walkthrough-for-nested-app-authentication/](https://specterops.io/blog/2025/08/13/going-for-brokering-offensive-walkthrough-for-nested-app-authentication/)
+- [https://trustedsec.com/blog/full-disclosure-a-third-and-fourth-azure-sign-in-log-bypass-found](https://trustedsec.com/blog/full-disclosure-a-third-and-fourth-azure-sign-in-log-bypass-found)
 
 {{#include ../../../banners/hacktricks-training.md}}