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

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

@@ -15,18 +15,18 @@ Entra ID è la piattaforma di gestione dell'identità e degli accessi (IAM) basa
 3. **Applicazione Client (CA):** Un'applicazione che cerca di accedere alle risorse per conto del proprietario delle risorse.
 4. **Server di Autorizzazione (AS):** Emissione di token di accesso alle applicazioni client dopo averle autenticate e autorizzate.
 
-**Ambiti e Consenso:**
+**Scopes e Consenso:**
 
-- **Ambiti:** Permessi granulari definiti sul server delle risorse che specificano i livelli di accesso.
-- **Consenso:** Il processo mediante il quale un proprietario delle risorse concede a un'applicazione client il permesso di accedere alle risorse con ambiti specifici.
+- **Scopes:** Permessi granulari definiti sul server delle risorse che specificano i livelli di accesso.
+- **Consenso:** Il processo mediante il quale un proprietario delle risorse concede a un'applicazione client il permesso di accedere alle risorse con specifici scopes.
 
 **Integrazione con Microsoft 365:**
 
 - Microsoft 365 utilizza Azure AD per IAM ed è composto da più applicazioni OAuth "di prima parte".
 - Queste applicazioni sono profondamente integrate e spesso hanno relazioni di servizio interdipendenti.
 - Per semplificare l'esperienza dell'utente e mantenere la funzionalità, Microsoft concede "consenso implicito" o "pre-consenso" a queste applicazioni di prima parte.
-- **Consenso Implicito:** Alcune applicazioni sono automaticamente **concesse accesso a specifici ambiti senza approvazione esplicita dell'utente o dell'amministratore**.
-- Questi ambiti pre-consentiti sono tipicamente nascosti sia agli utenti che agli amministratori, rendendoli meno visibili nelle interfacce di gestione standard.
+- **Consenso Implicito:** Alcune applicazioni sono automaticamente **concesse accesso a specifici scopes senza approvazione esplicita dell'utente o dell'amministratore**.
+- Questi scopes pre-consentiti sono tipicamente nascosti sia agli utenti che agli amministratori, rendendoli meno visibili nelle interfacce di gestione standard.
 
 **Tipi di Applicazioni Client:**
 
@@ -44,10 +44,10 @@ Ci sono **tre tipi di token** utilizzati in OIDC:
 
 - [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Il client presenta questo token al server delle risorse per **accedere alle risorse**. Può essere utilizzato solo per una specifica combinazione di utente, client e risorsa e **non può essere revocato** fino alla scadenza - che è di 1 ora per impostazione predefinita.
 - **ID Tokens**: Il client riceve questo **token dal server di autorizzazione**. Contiene informazioni di base sull'utente. È **legato a una specifica combinazione di utente e client**.
-- **Refresh Tokens**: Forniti al client con il token di accesso. Utilizzati per **ottenere nuovi token di accesso e ID**. È legato a una specifica combinazione di utente e client e può essere revocato. La scadenza predefinita è **90 giorni** per i token di refresh inattivi e **nessuna scadenza per i token attivi** (da un token di refresh è possibile ottenere nuovi token di refresh).
-- Un token di refresh dovrebbe essere legato a un **`aud`**, a alcuni **ambiti**, e a un **tenant** e dovrebbe essere in grado di generare token di accesso solo per quel aud, ambiti (e non di più) e tenant. Tuttavia, questo non è il caso con i **token delle applicazioni FOCI**.
-- Un token di refresh è crittografato e solo Microsoft può decrittografarlo.
-- Ottenere un nuovo token di refresh non revoca il token di refresh precedente.
+- **Refresh Tokens**: Forniti al client con il token di accesso. Utilizzati per **ottenere nuovi token di accesso e ID**. È legato a una specifica combinazione di utente e client e può essere revocato. La scadenza predefinita è di **90 giorni** per i refresh token inattivi e **nessuna scadenza per i token attivi** (da un refresh token è possibile ottenere nuovi refresh token).
+- Un refresh token dovrebbe essere legato a un **`aud`**, a degli **scopes**, e a un **tenant** e dovrebbe poter generare solo token di accesso per quel aud, scopes (e non di più) e tenant. Tuttavia, questo non è il caso con i **token delle applicazioni FOCI**.
+- Un refresh token è crittografato e solo Microsoft può decrittografarlo.
+- Ottenere un nuovo refresh token non revoca il refresh token precedente.
 
 > [!WARNING]
 > Le informazioni per **l'accesso condizionale** sono **memorizzate** all'interno del **JWT**. Quindi, se richiedi il **token da un indirizzo IP consentito**, quell'**IP** sarà **memorizzato** nel token e poi puoi utilizzare quel token da un **IP non consentito per accedere alle risorse**.
@@ -63,13 +63,13 @@ Il comando `az account get-access-token --resource-type [...]` supporta i seguen
 
 <details>
 
-<summary>esempi di aud</summary>
+<summary>aud examples</summary>
 
 - **aad-graph (Azure Active Directory Graph API)**: Utilizzato per accedere all'API Azure AD Graph legacy (deprecata), che consente alle applicazioni di leggere e scrivere dati di directory in Azure Active Directory (Azure AD).
 - `https://graph.windows.net/`
 
 * **arm (Azure Resource Manager)**: Utilizzato per gestire le risorse Azure tramite l'API Azure Resource Manager. Questo include operazioni come la creazione, l'aggiornamento e la cancellazione di risorse come macchine virtuali, account di archiviazione e altro.
-- `https://management.core.windows.net/ o https://management.azure.com/`
+- `https://management.core.windows.net/ or https://management.azure.com/`
 
 - **batch (Azure Batch Services)**: Utilizzato per accedere ad Azure Batch, un servizio che consente applicazioni di calcolo parallelo e ad alte prestazioni su larga scala in modo efficiente nel cloud.
 - `https://batch.core.windows.net/`
@@ -77,7 +77,7 @@ Il comando `az account get-access-token --resource-type [...]` supporta i seguen
 * **data-lake (Azure Data Lake Storage)**: Utilizzato per interagire con Azure Data Lake Storage Gen1, che è un servizio di archiviazione e analisi dei dati scalabile.
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Utilizzato per accedere ad Azure Media Services, che forniscono servizi di elaborazione e distribuzione dei media basati sul cloud per contenuti video e audio.
+- **media (Azure Media Services)**: Utilizzato per accedere ad Azure Media Services, che forniscono servizi di elaborazione e distribuzione multimediale basati sul cloud per contenuti video e audio.
 - `https://rest.media.azure.net`
 
 * **ms-graph (Microsoft Graph API)**: Utilizzato per accedere all'API Microsoft Graph, l'endpoint unificato per i dati dei servizi Microsoft 365. Consente di accedere a dati e informazioni da servizi come Azure AD, Office 365, Enterprise Mobility e servizi di sicurezza.
@@ -90,9 +90,9 @@ Il comando `az account get-access-token --resource-type [...]` supporta i seguen
 
 ### Access Tokens Scopes "scp"
 
-L'ambito di un token di accesso è memorizzato all'interno della chiave scp all'interno del JWT del token di accesso. Questi ambiti definiscono a cosa ha accesso il token di accesso.
+Lo scope di un token di accesso è memorizzato all'interno della chiave scp all'interno del JWT del token di accesso. Questi scopes definiscono a cosa ha accesso il token di accesso.
 
-Se un JWT è autorizzato a contattare un'API specifica ma **non ha l'ambito** per eseguire l'azione richiesta, **non sarà in grado di eseguire l'azione** con quel JWT.
+Se un JWT è autorizzato a contattare un'API specifica ma **non ha lo scope** per eseguire l'azione richiesta, **non sarà in grado di eseguire l'azione** con quel JWT.
 
 ### Get refresh & access token example
 ```python
@@ -148,7 +148,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 
 - **appid**: ID dell'applicazione utilizzato per generare il token
 - **appidacr**: Il riferimento alla classe di contesto di autenticazione dell'applicazione indica come il client è stato autenticato; per un client pubblico il valore è 0, e se viene utilizzato un segreto del client il valore è 1
-- **acr**: Il claim del riferimento alla classe di contesto di autenticazione è "0" quando l'autenticazione dell'utente finale non ha soddisfatto i requisiti della ISO/IEC 29115.
+- **acr**: Il claim del riferimento alla classe di contesto di autenticazione è "0" quando l'autenticazione dell'utente finale non ha soddisfatto i requisiti di ISO/IEC 29115.
 - **amr**: Il metodo di autenticazione indica come il token è stato autenticato. Un valore di “pwd” indica che è stata utilizzata una password.
 - **groups**: Indica i gruppi di cui il principale è membro.
 - **iss**: L'emittente identifica il servizio di token di sicurezza (STS) che ha generato il token. e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (l'uuid è l'ID del tenant)
@@ -185,7 +185,7 @@ scopes=[
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-### Ottieni diversi client e scope
+### Ottieni client e scope diversi
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
@@ -201,6 +201,26 @@ scopes=["https://graph.microsoft.com/.default"],
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
+## Dove trovare i token
+
+Dal punto di vista di un attaccante, è molto interessante sapere dove è possibile trovare i token di accesso e di aggiornamento quando, ad esempio, il PC di una vittima è compromesso:
+
+- Dentro **`<HOME>/.Azure`**
+- **`azureProfile.json`** contiene informazioni sugli utenti connessi in passato
+- **`clouds.config contiene`** informazioni sulle sottoscrizioni
+- **`service_principal_entries.json`** contiene le credenziali delle applicazioni (tenant id, client e segreto). Solo in Linux e macOS
+- **`msal_token_cache.json`** contiene token di accesso e token di aggiornamento. Solo in Linux e macOS
+- **`service_principal_entries.bin`** e **`msal_token_cache.bin`** sono utilizzati in Windows e sono crittografati con DPAPI
+- **`msal_http_cache.bin`** è una cache delle richieste HTTP
+- Caricalo: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
+- **`AzureRmContext.json`** contiene informazioni sui login precedenti utilizzando Az PowerShell (ma nessuna credenziale)
+- Dentro **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** ci sono diversi file `.bin` con **token di accesso**, token ID e informazioni sugli account crittografati con il DPAPI degli utenti.
+- È possibile trovare ulteriori **token di accesso** nei file `.tbres` dentro **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** che contengono un base64 crittografato con DPAPI con token di accesso.
+- In Linux e macOS puoi ottenere **token di accesso, token di aggiornamento e token ID** da Az PowerShell (se utilizzato) eseguendo `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
+- In Windows questo genera solo token ID.
+- È possibile vedere se Az PowerShell è stato utilizzato in Linux e macOS controllando se esiste `$HOME/.local/share/.IdentityService/` (anche se i file contenuti sono vuoti e inutili)
+- Se l'utente è **connesso a Azure con il browser**, secondo questo [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) è possibile avviare il flusso di autenticazione con un **reindirizzamento a localhost**, far autorizzare automaticamente il login dal browser e ricevere il token di aggiornamento. Nota che ci sono solo poche applicazioni FOCI che consentono il reindirizzamento a localhost (come az cli o il modulo PowerShell), quindi queste applicazioni devono essere autorizzate.
+
 ## Riferimenti
 
 - [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)