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

This commit is contained in:
Translator
2026-03-31 16:59:11 +00:00
parent cab456cd72
commit 928b371ace
@@ -1,98 +1,171 @@
# Az - Tokens & Publieke Toepassings
# Az - Tokens & Public Applications
{{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting
Entra ID is Microsoft se wolkgebaseerde identiteit- en toegangsbestuursplatform (IAM), wat dien as die fundamentele verifikasie- en magtigingstelsel vir dienste soos Microsoft 365 en Azure Resource Manager. Azure AD implementeer die OAuth 2.0 magtigingsraamwerk en die OpenID Connect (OIDC) verifikasieprotokol om toegang tot hulpbronne te bestuur.
Entra ID is Microsoft se wolkgebaseerde identity and access management (IAM) platform, en dien as die fundamentele verifikasie- en autorisasie-stelsel vir dienste soos Microsoft 365 en Azure Resource Manager. Azure AD implementeer die OAuth 2.0 authorization raamwerk en die OpenID Connect (OIDC) verifikasieprotokol om toegang tot hulpbronne te bestuur.
### OAuth
Belangrike deelnemers in OAuth 2.0:
1. **Resource Server (RS):** Beskerm hulpbronne wat deur die resource owner besit word.
2. **Resource Owner (RO):** Tipies 'n eindgebruiker wat die beskermde hulpbronne besit.
3. **Client Application (CA):** 'n Toepassing wat toegang tot hulpbronne namens die resource owner soek.
4. **Authorization Server (AS):** Gee access tokens aan client applications nadat dit hulle geverifieer en gemagtig het.
1. **Resource Server (RS):** Beskerm hulpbronne wat aan die resource owner behoort.
2. **Resource Owner (RO):** Gewoonlik 'n eindgebruiker wat die beskermde hulpbronne besit.
3. **Client Application (CA):** 'n toepassing wat namens die resource owner toegang tot hulpbronne soek.
4. **Authorization Server (AS):** Gee toegangstokens uit aan clienttoepassings nadat hulle geverifieer en gemagtig is.
Scopes en Toestemming:
- **Scopes:** Fynkorrelige toestemmings op die resource server wat toegangsvlakke spesifiseer.
- **Consent:** Die proses waardeur 'n resource owner 'n client application toestemming gee om hulpbronne met spesifieke scopes te gebruik.
- **Scopes:** Fynkorrelige toestemmings wat op die resource server gedefinieer is en wat toegangsvlakke spesifiseer.
- **Consent:** Die proses waardeur 'n resource owner 'n client application toestemming gee om toegang tot hulpbronne met spesifieke scopes te .
Microsoft 365-integrasie:
- Microsoft 365 gebruik Azure AD vir IAM en bestaan uit verskeie "first-party" OAuth-toepassings.
- Hierdie toepassings is diep geïntegreer en het dikwels onderling afhanklike diensverhoudings.
- Om die gebruikerservaring te vereenvoudig en funksionaliteit te behou, verleen Microsoft "implied consent" of "pre-consent" aan hierdie first-party toepassings.
- **Implied Consent:** Sekere toepassings word outomaties **toegang tot spesifieke scopes gegee sonder eksplisiete gebruiker- of administrateurgoedkeuring**.
- Hierdie vooraf-toegestemde scopes is tipies verborge vir beide gebruikers en administrateurs, wat dit minder sigbaar maak in standaard bestuurderskoppelvlakke.
- **Implied Consent:** Sekere toepassings word outomaties **toegang gegee tot spesifieke scopes sonder uitdruklike gebruiker- of administrateurgoedkeuring**.
- Hierdie vooraf-toegewe scopes is tipies verberg vir beide gebruikers en administrateurs, wat dit minder sigbaar maak in standaard bestuurskoppelvlakke.
Tipes Client Applications:
1. **Confidential Clients:**
- Besit hul eie credentials (bv. wagwoorde of sertifikate).
- Kan hulself **veilig verifieer** by die authorization server.
- Kan hulself veilig verifieer teen die authorization server.
2. **Public Clients:**
- Het geen unieke credentials nie.
- Kan nie veilig by die authorization server verifieer nie.
- **Sekuriteitsimplikasie:** 'n Aanvaller kan 'n public client application naboots wanneer hy tokens versoek, aangesien daar geen meganisme is vir die authorization server om die legitimiteit van die toepassing te verifieer nie.
- Kan nie veilig teen die authorization server verifieer nie.
- **Security Implication:** 'n aanvaller kan 'n public client application nadoen wanneer tokens versoek word, aangesien daar geen meganisme is vir die authorization server om die wettigheid van die toepassing te verifieer nie.
## Verifikaasietokens
### ROPC / Password Grant
Daar is **drie tipes tokens** wat in OIDC gebruik word:
Die OAuth2 **Resource Owner Password Credentials** (**ROPC**) vloei gebruik 'n direkte `POST` na https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token met `grant_type=password`, `username`, `password`, `client_id`, en die versoekte `scope`. In Entra ID is dit hoofsaaklik interessant vir **public clients** omdat die aanvaller Microsoft first-party client IDs of enige ander toegelate public client kan hergebruik sonder om 'n geheim te benodig.
```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.
- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Die kliënt bied hierdie token aan die resource server om **toegang tot hulpbronne** te kry. Dit kan slegs gebruik word vir 'n spesifieke kombinasie van gebruiker, client en hulpbron en **kan nie herroep word** totdat dit verstryk nie — dit is standaard 1 uur.
- **ID Tokens**: Die kliënt ontvang hierdie **token van die authorization server**. Dit bevat basiese inligting oor die gebruiker. Dit is **gekoppel aan 'n spesifieke kombinasie van gebruiker en client**.
- **Refresh Tokens**: Verskaf aan die kliënt saam met die access token. Word gebruik om **nuwe access en ID tokens te kry**. Dit is gekoppel aan 'n spesifieke kombinasie van gebruiker en client en kan herroep word. Standaard verstryking is **90 dae** vir inaktive refresh tokens en **geen verstryking vir aktiewe tokens** (deur van 'n refresh token is dit moontlik om nuwe refresh tokens te kry).
- 'n Refresh token behoort gekoppel te wees aan 'n **`aud`**, aan sekere **scopes**, en aan 'n **tenant** en dit behoort slegs in staat te wees om access tokens vir daardie aud, scopes (en niks meer) en tenant te genereer. Dit is egter nie die geval met **FOCI applications tokens** nie.
- 'n Refresh token is versleuteld en slegs Microsoft kan dit ontsleutel.
- Om 'n nuwe refresh token te kry herroep nie die vorige refresh token nie.
### Entra ID Sign-In Log Bypass Classes
Some historical Entra ID bugs allowed **password validation** or even **full token issuance** without generating the expected **Entra ID sign-in log** entry. These cases were fixed, but the techniques are still useful to understand how auth pipelines can fail in ways that leave **downstream token use visible** while the **upstream sign-in telemetry is absent**.
#### 1. Foreign-tenant endpoint for stealth password validation
As die versoek aan die token endpoint van 'n **different tenant GUID** gestuur word, kan Entra steeds verifieer of die ingediende wagwoord korrek is vir die gegewe gebruikersnaam voordat die stroom misluk omdat die gebruiker nie in daardie vreemde tenant bestaan nie. Histories het dit toegelaat:
- **Password spraying / credential validation** sonder 'n ooreenstemmende sign-in log in die slagoffer-tenant
- 'n Verskil in respons wat openbaar of die wagwoordstap geslaag het
- Geen token issuance nie, maar minder telemetrie as 'n normale mislukte aanmelding
#### 2. Force a post-password failure
As 'n parameter wat gebruik word ná credential validation ongeldig is, soos 'n ongeldig `client_id`, kan die algehele transaksie misluk selfs al was die wagwoord reeds korrek. Histories het dit 'n **failed** login-uitsig gegee terwyl dit weggesteek het dat die wagwoordgissing geslaag het.
Die patroon om te onthou is:
- **Password check succeeds**
- 'n Later valideringsstap misluk
- Die log verteenwoordig die finale transaksie-toestand, maar nie die suksesvolle wagwoord-valideringsstap nie
#### 3. Trigger logging failure with oversized-but-valid values
Die gevaarlikste klas is wanneer die versoek sintakties geldig bly, outentisering slaag, **tokens are returned**, maar 'n paar **logged field** groot genoeg is om die logging pipeline te breek. Gemelde voorbeelde sluit in:
- Herhaling van geldige scopes duisende kere, soos `openid openid openid ...`
- Voorsiening van 'n buitensporig lang maar steeds aanvaarbare **User-Agent** header
Dit dui op 'n algemene klas probleme waar:
1. Entra valideer geloofsbriewe en versoek-sintaksis
2. Die token word suksesvol uitgereik
3. Logging probeer 'n rou, gebruiker-beheerde veld bewaar
4. Die log-skryf misluk as gevolg van lengte- of skema-aanname
5. Die gebruiker kry 'n geldige token sonder 'n ooreenstemmende sign-in rekord
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)"
```
#### Jag-/verdedigingsnota
Moet nie aanvaar dat elke geldige tokengebruik 'n ooreenstemmende Entra-aanmeldingsgebeurtenis sal hê nie. Wanneer jy verdagte Graph-aktiwiteit ondersoek, korreleer:
- **Nie-interaktiewe aanmeldingslogboeke**
- **Graph Activity Logs**
- **IP-adres**, **gebruiker-/objek-ID**, **sessie-/korrelasie-identifiseerders**, en **tydvensters**
Een praktiese verifikasiemetode is om 'n vermoedelike onsigbare sukses tussen twee normale mislukte aanmeldings te plaas en dan te verifieer of die verwagte volgorde `Failed -> Successful -> Failed` die middelste gebeurtenis mís ná die innamevertraging. As daar downstream Graph-aktiwiteit bestaan maar die aanmeldingslog nie, beskou dit as 'n potensiële **aanmeldingsloggaping** of **token replay**-toestand.
## Authentication Tokens
Daar is drie tipes tokens wat in OIDC gebruik word:
- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Die kliënt dien hierdie token voor aan die hulpbronbediener om hulpbronne te **benader**. Dit kan slegs gebruik word vir 'n spesifieke kombinasie van gebruiker, kliënt en hulpbron en **kan nie herroep word** totdat dit verval nie — dit is standaard 1 uur.
- **ID Tokens**: Die kliënt ontvang hierdie **token van die authorization server**. Dit bevat basiese inligting oor die gebruiker. Dit is **gebind aan 'n spesifieke kombinasie van gebruiker en kliënt**.
- **Refresh Tokens**: Verskaf aan die kliënt saam met die access token. Gebruik om **nuwe access- en ID-tokens te kry**. Dit is gebind aan 'n spesifieke kombinasie van gebruiker en kliënt en kan herroep word. Standaardverval is **90 dae** vir inaktiewe refresh tokens en **geen verval vir aktiewe tokens** (van 'n refresh token is dit moontlik om nuwe refresh tokens te kry).
- 'n Refresh token behoort gekoppel te wees aan 'n `aud`, aan sekere **scopes**, en aan 'n **tenant** en dit behoort slegs in staat te wees om access tokens te genereer vir daardie aud, scopes (en nie meer nie) en tenant. Dit is egter nie die geval met **FOCI applications tokens** nie.
- 'n Refresh token is enkripteer en slegs Microsoft kan dit ontsleutel.
- Om 'n nuwe refresh token te kry, herroep dit nie die vorige refresh token nie.
> [!WARNING]
> Inligting vir **conditional access** word **gestoor** binne die **JWT**. Dus, as jy die **token vanaf 'n toegelate IP-adres** versoek, sal daardie **IP** in die token **gestoor** word en dan kan jy daardie token vanaf 'n **nie-toegelate IP gebruik om toegang tot die hulpbronne te kry**.
> Inligting vir **conditional access** word **gestoor** binne die **JWT**. Dus, as jy die **token vanaf 'n toegelate IP-adres** versoek, sal daardie **IP** in die token **bewaar** word en kan jy daardie token dan vanaf 'n **nie-toegelate IP** gebruik om toegang tot die hulpbronne te kry.
### Access Tokens "aud"
Die veld aangedui in die "aud" veld is die **resource server** (die toepassing) wat gebruik word om die aanmelding uit te voer.
Die opdrag `az account get-access-token --resource-type [...]` ondersteun die volgende tipes en elk van hulle sal 'n spesifieke "aud" by die resulterende access token voeg:
Die opdrag `az account get-access-token --resource-type [...]` ondersteun die volgende tipes en elk van hulle sal 'n spesifieke "aud" in die resulterende access token voeg:
> [!CAUTION]
> Neem kennis dat die volgende net die APIs is wat deur `az account get-access-token` ondersteun word, maar daar is meer.
> Let daarop dat die volgende net die APIs is wat deur `az account get-access-token` ondersteun word, maar daar is meer.
<details>
<summary>aud voorbeelde</summary>
- **aad-graph (Azure Active Directory Graph API)**: Gebruik om toegang tot die legacy Azure AD Graph API (deprekated) te kry, wat toepassings toelaat om gidsdata in Azure Active Directory te lees en te skryf.
- **aad-graph (Azure Active Directory Graph API)**: Word gebruik om toegang te kry tot die legacy Azure AD Graph API (deprecated), wat toepassings toelaat om gidsdata in Azure Active Directory (Azure AD) te lees en te skryf.
- `https://graph.windows.net/`
* **arm (Azure Resource Manager)**: Gebruik om Azure-hulpbronne te bestuur deur die Azure Resource Manager API. Dit sluit operasies in soos die skep, opdateer en verwyder van hulpbronne soos virtuele masjiene, stoortoestelle, en meer.
- **arm (Azure Resource Manager)**: Word gebruik om Azure-hulpbronne te bestuur deur die Azure Resource Manager API. Dit sluit bewerkings in soos die skep, opdatering en verwydering van hulpbronne soos virtual machines, storage accounts, en meer.
- `https://management.core.windows.net/ or https://management.azure.com/`
- **batch (Azure Batch Services)**: Gebruik om toegang tot Azure Batch te kry, 'n diens wat grootskaalse parallelle en hoë-prestasietoepassings in die wolk effektief moontlik maak.
- **batch (Azure Batch Services)**: Word gebruik om toegang te kry tot Azure Batch, 'n diens wat grootskaalse parallelle en hoë-prestasie-rekenaartoepassings doeltreffend in die cloud moontlik maak.
- `https://batch.core.windows.net/`
* **data-lake (Azure Data Lake Storage)**: Gebruik om met Azure Data Lake Storage Gen1 te kommunikeer, wat 'n skaalbare data-opberging- en analitiese diens is.
- **data-lake (Azure Data Lake Storage)**: Word gebruik om met Azure Data Lake Storage Gen1 te kommunikeer, wat 'n skaalbare datastoor- en analitiese diens is.
- `https://datalake.azure.net/`
- **media (Azure Media Services)**: Gebruik om toegang tot Azure Media Services te kry, wat wolkgebaseerde media-verwerking en leweringsdienste vir video- en oudio-inhoud bied.
- **media (Azure Media Services)**: Word gebruik om toegang te kry tot Azure Media Services, wat wolkgebaseerde mediasverwerking- en afleweringsdienste vir video- en klankinhoud bied.
- `https://rest.media.azure.net`
* **ms-graph (Microsoft Graph API)**: Gebruik om toegang tot die Microsoft Graph API te kry, die eenvormige eindpunt vir Microsoft 365-diensdata. Dit stel jou in staat om data en insigte van dienste soos Azure AD, Office 365, Enterprise Mobility en Security-dienste te kry.
- **ms-graph (Microsoft Graph API)**: Word gebruik om toegang te kry tot die Microsoft Graph API, die verenigde endpoint vir Microsoft 365-diensdata. Dit laat jou toe om data en insigte van dienste soos Azure AD, Office 365, Enterprise Mobility en Security-dienste te benader.
- `https://graph.microsoft.com`
- **oss-rdbms (Azure Open Source Relational Databases)**: Gebruik om toegang tot Azure Database-dienste vir open-source relationele databasis-motors soos MySQL, PostgreSQL, en MariaDB te kry.
- **oss-rdbms (Azure Open Source Relational Databases)**: Word gebruik om toegang te kry tot Azure Database-dienste vir open-source relationele databasismotors soos MySQL, PostgreSQL, en MariaDB.
- `https://ossrdbms-aad.database.windows.net`
</details>
### Access Tokens Scopes "scp"
Die scope van 'n access token word binne die scp sleutel in die access token JWT gestoor. Hierdie scopes definieer waartoe die access token toegang het.
Die scope van 'n access token word gestoor binne die `scp` sleutel in die access token se JWT. Hierdie scopes definieer waarna die access token toegang het.
As 'n JWT toegelaat word om 'n spesifieke API te kontak maar **nie die scope** het om die versoekte aksie uit te voer nie, sal dit **nie in staat wees om die aksie uit te voer** met daardie JWT nie.
As 'n JWT toegelaat word om 'n spesifieke API te kontak maar **nie die scope het** om die versoekte aksie uit te voer nie, sal dit **nie die aksie kan uitvoer** met daardie JWT nie.
### Get refresh & access token example
```python
@@ -144,32 +217,32 @@ scopes=["https://graph.microsoft.com/.default"],
)
pprint(new_azure_cli_bearer_tokens_for_graph_api)
```
### Other access token fields
### Ander access token-velde
- **appid**: Application ID wat gebruik is om die token te genereer
- **appidacr**: Die Application Authentication Context Class Reference dui aan hoe die client geverifieer is; vir 'n public client is die waarde 0, en as 'n client secret gebruik is is die waarde 1
- **appidacr**: Die Application Authentication Context Class Reference dui aan hoe die client geverifieer is; vir 'n public client is die waarde 0, en as 'n client secret gebruik is, is die waarde 1
- **acr**: Die Authentication Context Class Reference-claim is "0" wanneer die eindgebruiker se verifikasie nie aan die vereistes van ISO/IEC 29115 voldoen het nie.
- **amr**: Die Authentication method dui aan hoe die token geverifieer is. 'n Waarde van “pwd” dui aan dat 'n wagwoord gebruik is.
- **groups**: Dui die groepe aan waarvan die principal 'n lid is.
- **iss**: Die iss identifiseer die security token service (STS) wat die token gegenereer het. e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (die uuid is die tenant ID)
- **oid**: Die object ID van die principal
- **tid**: Tenant ID
- **iat, nbf, exp**: Uitgereik op (wanneer dit uitgereik is), Nie voor (kan nie voor hierdie tyd gebruik word nie, gewoonlik dieselfde waarde as iat), Vervaltyd.
- **iat, nbf, exp**: Issued at (wanneer dit uitgegee is), Not before (kan nie voor hierdie tyd gebruik word nie, gewoonlik dieselfde waarde as iat), Expiration time (vervaltyd).
## FOCI Tokens Privilege Escalation
## FOCI Tokens Bevoegdheid-eskalasie
Eerder is genoem dat refresh tokens gekoppel behoort te wees aan die **scopes** waarmee dit gegenereer is, aan die **application** en **tenant** waarvoor dit gegenereer is. As enige van hierdie perke gebreek word, is dit moontlik om privileges te eskaleer, aangesien dit moontlik sal wees om access tokens te genereer vir ander resources en tenants waartoe die gebruiker toegang het en met meer scopes as wat oorspronklik bedoel was.
Voorheen is genoem dat refresh tokens gekoppel moet wees aan die **scopes** waarmee dit gegenereer is, aan die **application** en **tenant** waarvoor dit gegenereer is. As enigsins een van hierdie grense gebreek word, is dit moontlik om privilegies te eskaleer, aangesien dit moontlik sal wees om access tokens te genereer vir ander resources en tenants waartoe die gebruiker toegang het en met meer scopes as oorspronklik bedoel.
Boonop, **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) omdat, soos die [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) noem: "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."
Boonop is **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) omdat, soos die [**docs**] noem: "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."
Verder, neem kennis dat die FOCI applications openbare applications is, so **no secret is needed** om by die bediener te verifieer.
Boonop, neem kennis dat die FOCI applications openbare toepassings is, so **no secret is needed** om by die bediener te autentikeer.
Die bekende FOCI clients wat in die [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) gerapporteer is, kan by [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv) gevind word.
Die bekende FOCI clients wat in die [**original research**] gerapporteer is, kan [**found here**].
### Get different scope
### Kry 'n ander scope
In aansluiting by die vorige voorbeeldkode, word in hierdie kode 'n nuwe token versoek vir 'n ander scope:
Gevolg op die vorige voorbeeldkode, in hierdie kode word 'n nuwe token vir 'n ander scope aangevra:
```python
# Code from https://github.com/secureworks/family-of-client-ids-research
azure_cli_bearer_tokens_for_outlook_api = (
@@ -204,57 +277,58 @@ pprint(microsoft_office_bearer_tokens_for_graph_api)
```
## NAA / BroCI (Nested App Authentication / Broker Client Injection)
A BroCI refresh token is 'n brokered token-uitruilingspatroon waar 'n bestaande refresh token gebruik word met bykomende broker-parameters om tokens te versoek as 'n ander vertroude first-party app.
A BroCI refresh token is 'n brokered token exchange pattern waar 'n bestaande refresh token gebruik word met ekstra broker parameters om tokens as 'n ander trusted first-party app te versoek.
Hierdie refresh tokens moet in daardie broker-konteks gemint wees (n gewone refresh token kan gewoonlik nie as 'n BroCI refresh token gebruik word nie).
These refresh tokens must be minted in that broker context (a regular refresh token usually cannot be used as a BroCI refresh token).
### Doel en bedoeling
### Doel en oogmerk
Die doel van BroCI is om 'n geldige gebruikersessie van 'n broker-capable app-ketting te hergebruik en tokens aan te vra vir 'n ander vertroude app/resource-paar. Dit laat dus toe om "escalate privileges" vanaf die oorspronklike token.
Die doel van BroCI is om 'n geldige user session uit 'n broker-capable app ketting te hergebruik en tokens aan te vra vir 'n ander trusted app/resource pair. Dit maak dit moontlik om bevoegdhede vanaf die oorspronklike token te "escalate privileges".
Van 'n offensiewe perspektief is dit belangrik omdat:
Vanuit 'n offensiewe perspektief is dit belangrik omdat:
- Dit kan pre-consented first-party app-paaie ontsluit wat nie met standaard refresh-uitruilings toeganklik is nie.
- Dit kan access tokens teruggee vir hoë-waarde APIs (byvoorbeeld Microsoft Graph) onder app-identiteite met wye delegated permissions.
- Dit brei post-authentication token pivoting-geleenthede uit buite klassieke FOCI client switching.
- Dit kan pre-consented first-party app paths ontsluit wat nie toeganklik is met standaard refresh exchanges nie.
- Dit kan access tokens vir hoë-waarde APIs teruggee (byvoorbeeld Microsoft Graph) onder app identities met uitgebreide delegated permissions.
- Dit brei post-authentication token pivoting opportunities uit bo en behalwe klassieke FOCI client switching.
Wat in 'n NAA/BroCI refresh token verander, is nie die sigbare token-formaat nie, maar die issuance context en broker-verwante metadata wat Microsoft valideer tydens brokered refresh-operasies.
Wat verander in 'n NAA/BroCI refresh token is nie die sigbare token-formaat nie, maar die **issuance context** en broker-related metadata wat Microsoft valideer tydens brokered refresh operations.
NAA/BroCI token exchanges is nie dieselfde as 'n gewone OAuth refresh exchange nie.
NAA/BroCI token exchanges are **not** the same as a regular OAuth refresh exchange.
- 'n Gewone refresh token (byvoorbeeld verkry via device code flow) is gewoonlik geldig vir standaard `grant_type=refresh_token` operasies.
- 'n BroCI-versoek sluit addisionele broker-konteks in (`brk_client_id`, broker `redirect_uri`, en `origin`).
- Microsoft valideer of die aangebiedde refresh token in 'n ooreenstemmende brokered-konteks gemint is.
- Daarom misluk baie "normale" refresh tokens in BroCI-versoeke met foute soos `AADSTS900054` ("Specified Broker Client ID does not match ID in provided grant").
- Jy kan gewoonlik nie 'n gewone refresh token in kode "omskakel" na 'n BroCI-geldige een nie.
- Jy benodig 'n refresh token wat reeds deur 'n verenigbare brokered flow uitgegee is.
- 'n Regular refresh token (byvoorbeeld obtained via device code flow) is gewoonlik geldig vir standaard `grant_type=refresh_token` operations.
- 'n BroCI request sluit addisionele broker context in (`brk_client_id`, broker `redirect_uri`, en `origin`).
- Microsoft valideer of die aangebiedde refresh token geskep is in 'n matching brokered context.
- Daarom misluk baie "normal" refresh tokens in BroCI requests met foute soos `AADSTS900054` ("Specified Broker Client ID does not match ID in provided grant").
- Jy kan gewoonlik nie 'n normal refresh token in code na 'n BroCI-valid een "convert" nie.
- Jy benodig 'n refresh token wat reeds deur 'n compatible brokered flow uitgereik is.
Check die web **<https://entrascopes.com/>** om BroCI-gekonfigureerde apps en die trust relationships wat hulle het te vind.
Check die web **<https://entrascopes.com/>** om BroCI-configured apps en die trust relationships wat hulle het te vind.
### Mental model
### Mentaal model
Dink aan BroCI as:
`user session -> brokered refresh token issuance -> brokered refresh call (brk_client_id + redirect_uri + origin) -> access token for target trusted app/resource`
As enige deel van daardie broker-ketting nie saamstem nie, misluk die uitruiling.
As enige deel van daardie broker-ketting nie ooreenstem nie, misluk die exchange.
### Waar om 'n BroCI-geldige refresh token te vind
Een praktiese manier is deur blaaier-portalverkeer te versamel:
Een praktiese manier is browser portal traffic collection:
1. Sign in to `https://entra.microsoft.com` (or Azure portal).
1. Teken aan by `https://entra.microsoft.com` (of Azure portal).
2. Open DevTools -> Network.
3. Filter vir:
- `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. Identifiseer die brokered token response en kopieer `refresh_token`.
5. Gebruik daardie refresh token met ooreenstemmende BroCI parameters (`brk_client_id`, `redirect_uri`, `origin`) wanneer jy tokens vir target apps versoek (byvoorbeeld ADIbizaUX / Microsoft_Azure_PIMCommon scenarios).
### Common errors
### Algemene foute
- `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.
- `AADSTS900054`: Die refresh token context stem nie ooreen met die verskafde broker tuple (`brk_client_id` / `redirect_uri` / `origin`) nie, of die token is nie van 'n brokered portal flow nie.
- `AADSTS7000218`: Die gekose client flow verwag 'n confidential credential (`client_secret`/assertion), dikwels gesien wanneer mens device code met 'n non-public client probeer gebruik.
<details>
<summary>Python BroCI refresh helper (broci_auth.py)</summary>
@@ -532,24 +606,24 @@ raise SystemExit(main())
## Waar om tokens te vind
Vanuit 'n aanvaller se perspektief is dit baie interessant om te weet waar dit moontlik is om access and refresh tokens te vind wanneer byvoorbeeld die PC van 'n slagoffer gekompromitteer is:
Uit 'n aanvaller se perspektief is dit baie nuttig om te weet waar dit moontlik is om access and refresh tokens te vind, byvoorbeeld wanneer die PC van 'n slagoffer gekompromitteer is:
- Inside **`<HOME>/.Azure`**
- Binne **`<HOME>/.Azure`**
- **`azureProfile.json`** bevat inligting oor gebruikers wat in die verlede aangemeld was
- **`clouds.config contains`** bevat inligting oor subskripsies
- **`service_principal_entries.json`** bevat applications credentials (tenant id, clients and secret). Slegs in Linux & macOS
- **`msal_token_cache.json`** bevat access tokens en refresh tokens. Slegs in Linux & macOS
- **`service_principal_entries.bin`** and msal_token_cache.bin word in Windows gebruik en is met DPAPI versleuteld
- **`msal_http_cache.bin`** is 'n cache van HTTP-aanvrae
- Laai dit: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
- **`clouds.config contains`** info about subscriptions
- **`service_principal_entries.json`** bevat application credentials (tenant id, clients and secret). Only in Linux & macOS
- **`msal_token_cache.json`** bevat access tokens and refresh tokens. Only in Linux & macOS
- **`service_principal_entries.bin`** and msal_token_cache.bin are used in Windows and are encrypted with DPAPI
- **`msal_http_cache.bin`** is 'n cache van HTTP-versoeke
- Load it: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
- **`AzureRmContext.json`** bevat inligting oor vorige aanmeldings wat Az PowerShell gebruik het (maar geen credentials nie)
- Binne **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** is verskeie `.bin`-lêers met **access tokens**, ID tokens en rekeninginligting wat met die gebruiker se DPAPI versleuteld is.
- Dit is moontlik om meer **access tokens** te vind in die `.tbres`-lêers binne **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`**, wat 'n base64 bevat wat met DPAPI versleuteld is en access tokens bevat.
- In Linux en macOS kan jy **access tokens, refresh tokens en id tokens** van Az PowerShell (indien gebruik) kry deur `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` uit te voer
- In Windows genereer dit slegs id tokens.
- Dit is moontlik om te sien of Az PowerShell in Linux en macOS gebruik is deur te kontroleer of `$HOME/.local/share/.IdentityService/` bestaan (alhoewel die ingeslote lêers leeg en nutteloos is)
- As die gebruiker met die blaaier in Azure aangemeld is, volgens hierdie [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) is dit moontlik om die authentication flow te begin met 'n **redirect to localhost**, die blaaier outomaties die aanmelding te laat goedkeur, en die refresh token te ontvang. Neem kennis dat net 'n paar FOCI applications redirect to localhost toelaat (soos az cli of die PowerShell module), dus moet hierdie applications toegelaat wees.
- Nog 'n opsie soos in die blog verduidelik is om die tool [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) te gebruik wat enige toepassing kan gebruik omdat dit die **OAuth code sal kry om dan 'n refresh token vanaf die titel van die finale auth** bladsy te kry deur die redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient` te gebruik.
- Binne **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** is daar verskeie `.bin` lêers met **access tokens**, ID tokens en rekeninginligting wat met die gebruiker se DPAPI geënkripteer is.
- Dit is moontlik om meer **access tokens** te vind in die `.tbres` lêers binne **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** wat 'n base64 bevat wat met DPAPI geënkripteer is en access tokens sluit.
- In Linux en macOS kan jy **access tokens, refresh tokens and id tokens** van Az PowerShell (indien gebruik) kry deur `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` te run
- In Windows genereer dit net id tokens.
- Dit is moontlik om te sien of Az PowerShell in Linux en macOS gebruik is deur na te gaan of `$HOME/.local/share/.IdentityService/` bestaan (alhoewel die ingeslote lêers leeg en nutteloos is)
- As die gebruiker met die browser by Azure aangemeld is, is dit volgens hierdie [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) moontlik om die authentication flow te begin met 'n **redirect to localhost**, die browser outomaties die login te laat magtig, en die refresh token te ontvang. Let daarop dat daar slegs 'n paar FOCI applications is wat redirect to localhost toelaat (soos az cli of die powershell module), dus moet daardie applications toegestaan wees.
- 'n Ander opsie wat in die blog verduidelik word, is om die tool [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) te gebruik wat enige application kan gebruik omdat dit die OAuth code kry om daarna 'n refresh token te kry uit die titel van die finale auth page deur die redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient` te gebruik.
## Verwysings
@@ -557,5 +631,6 @@ Vanuit 'n aanvaller se perspektief is dit baie interessant om te weet waar dit m
- [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}}