diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f61a27c2f..48a80565e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -420,6 +420,7 @@ - [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md) - [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md) - [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md) + - [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md) - [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md) - [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md) - [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md) @@ -442,21 +443,19 @@ - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md) - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md) - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md) - - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md) - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md) - - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md) - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md) - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md) - - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md) - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md) - - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md) - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md) - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md) - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md) - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md) - - [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md) - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index 7c06b156f..e63057628 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,13 +4,13 @@ ## Pass the Certificate (Azure) -In macchine collegate ad Azure, è possibile autenticarsi da una macchina all'altra utilizzando certificati che **devono essere emessi da Azure AD CA** per l'utente richiesto (come soggetto) quando entrambe le macchine supportano il meccanismo di autenticazione **NegoEx**. +In macchine collegate ad Azure, è possibile autenticarsi da una macchina all'altra utilizzando certificati che **devono essere emessi da Entra ID CA** per l'utente richiesto (come soggetto) quando entrambe le macchine supportano il meccanismo di autenticazione **NegoEx**. In termini super semplificati: -- La macchina (client) che avvia la connessione **ha bisogno di un certificato da Azure AD per un utente**. -- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (utilizzando la chiave di sessione e il contesto di sicurezza) e **la invia ad Azure AD** -- Azure AD verifica la firma JWT utilizzando la chiave di sessione del client e il contesto di sicurezza, controlla la validità del PRT e **risponde** con il **certificato**. +- La macchina (client) che avvia la connessione **ha bisogno di un certificato da Entra ID per un utente**. +- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (utilizzando la chiave di sessione e il contesto di sicurezza) e **la invia a Entra ID**. +- Entra ID verifica la firma JWT utilizzando la chiave di sessione del client e il contesto di sicurezza, controlla la validità del PRT e **risponde** con il **certificato**. In questo scenario e dopo aver raccolto tutte le informazioni necessarie per un attacco [**Pass the PRT**](pass-the-prt.md): diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md deleted file mode 100644 index 9133adfff..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md +++ /dev/null @@ -1,7 +0,0 @@ -# Az - Phishing Primary Refresh Token (Microsoft Entra) - -{{#include ../../../banners/hacktricks-training.md}} - -**Controlla:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index 4a0d4c125..55dc1a3f9 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -2,6 +2,258 @@ {{#include ../../../banners/hacktricks-training.md}} -**Controlla il post in** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) anche se un altro post che spiega lo stesso può essere trovato in [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +## Cos'è un Primary Refresh Token (PRT)? + +Un **Primary Refresh Token (PRT)** è un token di refresh a lungo termine utilizzato nell'autenticazione di Azure AD (Entra ID), analogo a un Kerberos TGT. Viene emesso al momento del login dell'utente su un dispositivo unito ad Azure AD e può essere utilizzato per richiedere token di accesso per varie applicazioni senza richiedere nuovamente le credenziali. Ogni PRT è accompagnato da una **session key** (chiamata anche chiave di Proof-of-Possession) -- una chiave simmetrica utilizzata per firmare le richieste e dimostrare che il client possiede il PRT. Il PRT stesso è un blob opaco e crittografato (non leggibile dal client), mentre la session key viene utilizzata per **firmare** un JWT contenente il PRT quando si richiedono token. In altre parole, il possesso del PRT da solo non è sufficiente; un attaccante ha bisogno della session key per dimostrare la legittimità, simile alla necessità di avere sia un Kerberos TGT che la sua session key per l'autenticazione. + +Su Windows, il PRT e la session key sono memorizzati nella cache nel processo LSASS tramite il plugin CloudAP. Se un dispositivo ha un **TPM** (Trusted Platform Module), Azure AD associa le chiavi al TPM per una maggiore sicurezza. Ciò significa che sui dispositivi dotati di TPM, la session key è memorizzata o utilizzata all'interno del TPM in modo tale che non possa essere letta direttamente dalla memoria in circostanze normali. Se non è disponibile alcun TPM (ad esempio, molte VM o sistemi più vecchi), le chiavi vengono mantenute in software e protette con crittografia DPAPI. In entrambi i casi, un attaccante con privilegi amministrativi o esecuzione di codice sulla macchina può tentare di **dumpare il PRT e la session key dalla memoria** come parte della post-exploitation, e poi usarli per impersonare l'utente nel cloud. A differenza dei token di refresh tipici (che sono solitamente specifici per l'applicazione), un PRT è più ampio, consentendo al tuo dispositivo di richiedere token per quasi tutte le risorse o servizi integrati in Entra ID. + +## Come funziona un PRT? + +Ecco una semplificazione di come opera un PRT: + +1. **Registrazione del Dispositivo:** + +- Quando il tuo dispositivo (come un laptop Windows o un telefono cellulare) si unisce o si registra con Entra ID, si autentica utilizzando le tue credenziali (nome utente/password/MFA). + +- Dopo un'autenticazione riuscita, Entra ID emette un PRT legato specificamente al tuo dispositivo. + +2. **Memorizzazione del Token:** + +- Il PRT è memorizzato in modo sicuro sul tuo dispositivo, spesso protetto da funzionalità hardware come il Trusted Platform Module (TPM), garantendo che sia difficile per le parti non autorizzate estrarlo o abusarne. + +3. **Single Sign-On (SSO):** + +- Ogni volta che accedi a un'applicazione protetta da Entra ID (ad esempio, app Microsoft 365, SharePoint, Teams), il tuo dispositivo utilizza silenziosamente il PRT memorizzato per richiedere e ottenere un token di accesso specifico per quell'app. + +- Non è necessario inserire ripetutamente le tue credenziali perché il PRT gestisce l'autenticazione in modo trasparente. + +4. **Rinnovo e Sicurezza:** + +- I PRT hanno una lunga durata (tipicamente intorno ai 14 giorni), ma vengono continuamente rinnovati finché il tuo dispositivo è attivamente in uso. + +- Se il tuo dispositivo viene compromesso o perso, gli amministratori possono revocare il tuo PRT da remoto, bloccando immediatamente l'accesso non autorizzato. + +### Perché i PRT sono potenti? + +- **Accesso Universale:** A differenza dei token tipici limitati a un'app o risorsa, un PRT può facilitare l'accesso a tutti i servizi integrati in Entra ID. + +- **Sicurezza Migliorata:** Con protezioni hardware integrate (come il TPM), i PRT garantiscono una memorizzazione e un utilizzo sicuri dei token. + +- **Esperienza Utente:** I PRT migliorano significativamente l'esperienza utente riducendo le richieste di autenticazione frequenti e abilitando un vero SSO senza soluzione di continuità. + +## Come sapere se un PRT è presente? + +- Controlla se il PRT è presente: +```bash +# Execute +dsregcmd /status +## Check if the value of AzureAdPrt is set to YES +``` +- Controlla se protetto da TPM: +```bash +Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned +# TpmPresent/Ready = True indicates the device can bind secrets to TPM. + +dsregcmd /status +# In Device State / WHfB prerequisites you’ll typically see: +# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key; +# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound. +# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test). +``` +## Dump e utilizza PRT non protetti + +Secondo [questo post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) sui dispositivi Windows **senza binding TPM**, il PRT e la sua chiave di sessione vivono in LSASS (plug-in CloudAP). Con admin locale/SYSTEM su quel dispositivo, il blob PRT e la chiave di sessione crittografata con DPAPI possono essere **letti da LSASS, la chiave di sessione decrittografata tramite DPAPI, e la chiave di firma derivata** per coniare un cookie PRT valido (`x‑ms‑RefreshTokenCredential`). Hai bisogno sia del PRT che della sua chiave di sessione: la stringa PRT da sola non è sufficiente. + +### Mimikatz +```bash +privilege::debug +sekurlsa::cloudap +``` +Il **campo PRT** contiene il token di refresh crittografato (tipicamente una stringa base64), e KeyValue nel ProofOfPossessionKey è la chiave di sessione crittografata con DPAPI (anch'essa base64). + +Quindi, dall'output di **`sekurlsa::cloudap`**, copia il blob base64 da **`KeyValue`** all'interno del campo `ProofOfPossessionKey` (questa è la chiave di sessione crittografata con DPAPI). Questa chiave crittografata non può essere utilizzata così com'è – deve essere decrittografata utilizzando le credenziali DPAPI del sistema. + +Poiché la crittografia DPAPI per i segreti di sistema richiede il contesto di sistema della macchina, eleva il tuo token a SYSTEM e utilizza il modulo DPAPI di Mimikatz per decrittografare: +```bash +token::elevate +dpapi::cloudapkd /keyvalue: /unprotect +``` +Il `token::elevate` impersonerà il SYSTEM e il comando `dpapi::cloudapkd` con `/unprotect` utilizzerà la chiave master DPAPI per decrittografare il blob KeyValue fornito. Questo produce la chiave di sessione in chiaro e anche la Derived Key e il Context associati utilizzati per la firma: +- **Chiave chiara** – la chiave di sessione di 32 byte in testo normale (rappresentata come una stringa esadecimale). +- **Derived Key** – una chiave di 32 byte derivata dalla chiave di sessione e da un valore di contesto (di seguito maggiori dettagli). +- **Context** – un contesto casuale di 24 byte utilizzato durante la derivazione della chiave di firma per il cookie PRT. + +> [!NOTE] +> Se questo non funziona per impersonare l'utente, controlla la sezione seguente utilizzando **`AADInternals`**. + +Poi, puoi anche usare mimikatz per generare un cookie PRT valido: +```bash +# Context is obtained from papi::cloudapkd /keyvalue: /unprotect +# Derivedkey is obtained from papi::cloudapkd /keyvalue: /unprotect +# PRT is obtained from sekurlsa::cloudap (filed "Prt" +dpapi::cloudapkd /context: /derivedkey: /prt: +``` +Mimikatz produrrà un JWT firmato (il `PRT cookie`) dopo la riga “Signature with key”, che contiene il PRT ed è firmato utilizzando la chiave derivata. Questo JWT può essere copiato e poi utilizzato in una sessione web. Ad esempio, un attaccante può aprire un browser, andare su `login.microsoftonline.com` e impostare un cookie chiamato `x-ms-RefreshTokenCredential` con il valore di questo JWT. Quando il browser si aggiorna o naviga, Azure AD tratterà la sessione come autenticata (il PRT cookie è presentato come se fosse avvenuto SSO), e emetterà un codice di autorizzazione o un token di accesso per la risorsa specificata. In pratica, si naviga verso una risorsa come Office 365 o il portale Azure; la presenza di un valido PRT cookie significa che Azure AD concederà accesso senza ulteriori login (bypassando MFA, poiché il PRT è già autenticato). + +Si potrebbe anche utilizzare **`roadtx`** e **`roadrecon`** con il PRT del PRT cookie per impersonare l'utente *(TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)*. + + +### AADInternals + +Il modulo PowerShell **`AADInternals`** può essere utilizzato anche con il PRT e la chiave di sessione ottenuti in precedenza per generare un token PRT valido. Questo è utile per automatizzare il processo di ottenimento di un nuovo token PRT con nonce, che può essere utilizzato per recuperare token di accesso per Azure AD Graph API o altre risorse: +```bash +# Code from https://aadinternals.com/post/prt/ +# Add the PRT to a variable +$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc" + +# Add padding +while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="} + +# Convert from Base 64 +$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) + +# Add the session key (Clear key) to a variable +$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808" + +# Convert to byte array and base 64 encode +$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne '')) + +# Generate a new PRTToken with nonce +$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey + +# Get an access token for MS Graph API +Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken +``` +Questo ottiene un cookie PRT fresco (con un nonce) e poi lo utilizza per recuperare un token di accesso per l'Azure AD Graph API (dimostrando l'accesso cloud per conto dell'utente). AADInternals astrae gran parte della crittografia e utilizza componenti Windows o la propria logica in background. + +## Abusare dei PRT protetti + +Nonostante le protezioni menzionate, un attaccante che ha già compromesso un dispositivo (come utente locale o anche SYSTEM) può comunque **abusare del PRT per ottenere nuovi token di accesso** sfruttando le API del broker di token e i componenti di sicurezza di Windows. Invece di **estrarre** il PRT o la chiave grezza, l'attaccante essenzialmente **"chiede" a Windows di utilizzare il PRT per suo conto**. Nelle sezioni seguenti, delineiamo le tecniche attualmente valide per abusare dei PRT e delle loro chiavi di sessione su dispositivi Windows aggiornati dove sono in vigore le protezioni TPM. Tutte queste tecniche assumono accesso post-sfruttamento sulla macchina target e **si concentrano sull'abuso dei flussi di autenticazione integrati** (non sono necessarie vulnerabilità non corrette). + +### Architettura del Token Broker di Windows e Flusso SSO + +I moderni Windows gestiscono l'autenticazione cloud tramite un **token broker** integrato, che include componenti sia in modalità utente che in LSASS (Local Security Authority). I pezzi chiave di questa architettura includono: + +- **Plugin CloudAP di LSASS:** Quando un dispositivo è unito ad Azure AD, LSASS carica pacchetti di autenticazione cloud (ad es. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) che gestiscono i PRT e le richieste di token. LSASS (in esecuzione come SYSTEM) orchestra la memorizzazione, il rinnovo e l'uso del PRT, e interagisce con il TPM per eseguire operazioni crittografiche (come firmare una sfida PRT con la chiave di sessione). + +- **Web Account Manager (WAM):** Il Windows Web Account Manager è un framework in modalità utente (accessibile tramite API COM/WinRT) che consente ad applicazioni o browser di richiedere token per account cloud senza richiedere credenziali. WAM funge da broker tra le applicazioni utente e il sicuro PRT supportato da LSASS/TPM. Ad esempio, la libreria MSAL di Microsoft e alcuni componenti del sistema operativo utilizzano WAM per acquisire silenziosamente token utilizzando il PRT dell'utente connesso. + +- **BrowserCore.exe e interfacce COM del Token Broker:** Per SSO del browser, Windows include un componente chiamato **BrowserCore.exe** (situato sotto *Windows Security\BrowserCore*). Questo è un host di messaggistica nativo utilizzato dai browser (Edge, Chrome tramite un'estensione, ecc.) per ottenere un token SSO derivato dal PRT per il login ad Azure AD. Sotto il cofano, BrowserCore sfrutta un oggetto COM fornito da `MicrosoftAccountTokenProvider.dll` per recuperare un cookie/token basato su PRT. In sostanza, questa interfaccia COM è un'API "token broker" di prima parte che qualsiasi processo in esecuzione come utente può chiamare per ottenere un token SSO (a condizione che l'utente abbia un PRT valido in LSASS). + +Quando un utente unito ad Azure AD cerca di accedere a una risorsa (ad esempio, il Portale Azure), il flusso è tipicamente: un'applicazione chiama l'interfaccia COM di WAM o BrowserCore, che a sua volta comunica con LSASS. LSASS utilizza il PRT e la chiave di sessione (protetta da TPM) per produrre un **token SSO** -- spesso chiamato **cookie PRT** -- che viene poi restituito all'applicazione o al browser. Il cookie PRT è un JWT speciale contenente il PRT crittografato e un nonce, firmato con una chiave derivata dalla chiave di sessione del PRT. Questo cookie viene inviato ad Azure AD (in un'intestazione `x-ms-RefreshTokenCredential`) per dimostrare che il dispositivo e l'utente detengono un PRT valido, consentendo ad Azure AD di emettere token di accesso e refresh OAuth standard per varie applicazioni. È importante notare che qualsiasi richiesta di Autenticazione Multi-Fattore (MFA) presente nel PRT sarà trasferita nei token ottenuti tramite questo processo SSO, il che significa che i token derivati dal PRT possono soddisfare le risorse protette da MFA. + +### Furto di Token a Livello Utente (Non-Admin) + +Quando un attaccante ha **esecuzione di codice a livello utente**, la protezione TPM del PRT non impedisce all'attaccante di ottenere token. L'attaccante **sfrutta le API del Token Broker di Windows integrate**: + +#### **BrowserCore (MicrosoftAccountTokenProvider COM)** + +BrowserCore espone una classe COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) per recuperare i cookie PRT. Questa API COM è invocata legittimamente dai browser (estensioni Chrome/Edge) per SSO di Azure AD. + +- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** +```bash +RequestAADRefreshToken.exe --uri https://login.microsoftonline.com +``` +*(Restituisce un token di aggiornamento Azure AD o un cookie PRT)* + +- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)** +```bash +ROADtoken.exe --nonce +roadrecon auth --prt-cookie +``` +*(Genera nonce, invoca BrowserCore per ottenere il cookie PRT, quindi lo riscatta tramite ROADtools)* + + +### **API del Web Account Manager (WAM)** + +Gli attaccanti utilizzano librerie di autenticazione Microsoft legittime (**MSAL**, **API WAM**, **WebAuthenticationCoreManager**) da processi a livello utente per recuperare silenziosamente i token sfruttando il PRT protetto da TPM. + + +- **[aadprt](https://posts.specterops.io/)** +```bash +execute-assembly aadprt.exe +``` +*(Recupera il cookie PRT tramite interfacce COM)* + +- **[listwamaccounts](https://posts.specterops.io/)** +```bash +execute-assembly listwamaccounts.exe +``` +*(Elenca gli account Azure AD connessi tramite WAM; identifica i target dei token)* + +- **Esempio Generico (PowerShell con MSAL)**: +```powershell +$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build() +$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result +$result.AccessToken +``` +*(Silenziosamente ottiene un token di accesso sfruttando il PRT)* + +#### Abuso di Token a Livello Amministratore / SYSTEM + +Se l'attaccante si eleva a **Amministratore o SYSTEM**, può impersonare direttamente qualsiasi utente connesso ad Azure AD e utilizzare le stesse **API del broker di token COM/WAM**. I PRT protetti da TPM non impediscono questa emissione legittima di token. + +### **Impersonificazione dell'Utente e Recupero del Token** + +Admin/SYSTEM potrebbe impersonare sessioni in esecuzione di altri utenti per invocare BrowserCore o WAM per la generazione di token. + +Per questo basta impersonare il processo utente (ad es., `explorer.exe`) e invocare le API del broker di token utilizzando qualsiasi tecnica commentata nella sezione precedente. + +### **Interazione Diretta con LSASS e Broker di Token (Avanzato)** + +Un amministratore può ancora lavorare con LSASS per abusare del PRT: ad esempio, un admin potrebbe iniettare codice in LSASS o chiamare funzioni interne di CloudAP per indurre LSASS a produrre un token. La ricerca di Dirk-jan ha notato che un admin può “interagire con le chiavi PRT in LSASS utilizzando API crittografiche”. In pratica, questo potrebbe significare utilizzare le funzioni di LSASS (tramite una tecnica come l'API hooking o RPC, se disponibile) per generare un cookie PRT. Un altro approccio è sfruttare qualsiasi finestra in cui la chiave di sessione potrebbe apparire in memoria – ad esempio, nel momento del rinnovo del PRT o della registrazione del dispositivo quando è decrittografato per l'uso. Tali attacchi sono notevolmente più complessi e situazionali. Una tattica amministrativa più diretta è abusare degli handle o delle cache di token esistenti: LSASS memorizza nella cache i token di aggiornamento recentemente emessi per le app in memoria (crittografati con DPAPI). Un attaccante SYSTEM determinato potrebbe tentare di estrarre questi token protetti da DPAPI (utilizzando la chiave master dell'utente, che un admin può ottenere) per rubare direttamente i token di aggiornamento per applicazioni specifiche. Tuttavia, il metodo più semplice e generico rimane l'impersonificazione e l'uso delle interfacce del broker di token documentate, poiché queste garantiscono che Azure AD emetta nuovi token (con tutte le corrette affermazioni) piuttosto che tentare di decifrare la crittografia. + +## Phishing dei PRT + +Abusa del flusso **OAuth Device Code** utilizzando l'**ID client del Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) e la risorsa del **Device Registration Service (DRS)** per ottenere un **token di aggiornamento che può essere aggiornato a un Primary Refresh Token (PRT)** dopo aver registrato un **dispositivo malevolo**. + +### **Perché funziona** + +- **PRT** è **legato al dispositivo** e consente **SSO per (quasi) qualsiasi app protetta da Entra**. +- La combinazione **Broker client + DRS** consente a un **token di aggiornamento** rubato di essere **scambiato per un PRT** una volta registrato un dispositivo. +- **MFA non viene bypassato**: l'**utente esegue MFA** durante il phishing; le **affermazioni MFA si propagano** nel PRT risultante, consentendo all'attaccante di accedere alle app **senza ulteriori richieste**. + +**Prerequisiti**: + +- **Autenticazione utente tramite Device Code** utilizzando l'**ID client del Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) e le **scopes/resource DRS** (ad es., **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** o **`https://enrollment.manage.microsoft.com/`**). +- **L'utente può registrare dispositivi** in Entra ID (**predefinito: consentito**, ma può essere limitato o soggetto a quota). +- **Nessuna politica CA di blocco** che **disabiliti il Device Code** o **richieda dispositivi conformi/ibridi** per le app target (queste non fermeranno l'emissione del PRT, ma **bloccheranno** **l'uso** per accedere ad app protette). +- **Host controllato dall'attaccante** per eseguire il flusso e mantenere i token/le chiavi del dispositivo. + +**Flusso di Attacco**: + +1. **Iniziare l'autenticazione con Device Code** con **client_id = Broker** e **scopo/richiesta DRS**; mostrare il **codice utente** alla vittima. +```bash +curl -s -X POST \ +"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \ +-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \ +-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile" +``` +2. **La vittima accede al sito di Microsoft** (UI legittima) e completa **MFA** → **l'attaccante riceve un token di refresh con ambito DRS** per il client Broker. + +3. **Registrare un dispositivo malevolo** nel tenant utilizzando quel token di refresh (l'oggetto dispositivo viene creato e collegato alla vittima). + +4. **Aggiornare a un PRT** scambiando il **token di refresh + identità/chiavi del dispositivo** → **PRT** legato al dispositivo dell'attaccante. + +5. **(Persistenza opzionale)**: se l'MFA era recente, **registrare una chiave Windows Hello for Business** per mantenere **accesso a lungo termine senza password**. + +6. **Abuso**: riscattare il **PRT** (o coniare un **cookie PRT**) per ottenere **token di accesso** per **Exchange/Graph/SharePoint/Teams/app personalizzate** come l'utente. + + +### Strumenti Pubblici e Proof-of-Concept + +- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatizza il flusso OAuth, la registrazione del dispositivo e gli aggiornamenti dei token. +- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Script a comando singolo che automatizza il phishing del codice dispositivo in chiavi PRT+WHfB. + + +## Riferimenti + +- [Post di Dirkjan su PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [Post di Dirkjan sul phishing dei PRT](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [Post di Dirkjan sull'abuso dei PRT](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) +- Post di SpecterOps su [Richiesta di Token di Richiesta Azure AD](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +- [Post di AADInternals sui PRT](https://aadinternals.com/post/prt/) +- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md index cf3faf36d..883362128 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md @@ -4,13 +4,13 @@ ## **Informazioni di Base** -Come spiegato in [**questo video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), alcuni software Microsoft sincronizzati con il cloud (Excel, Teams...) potrebbero **memorizzare i token di accesso in chiaro nella memoria**. Quindi, semplicemente **dumpando** la **memoria** del processo e **greppando per i token JWT** potrebbe concederti accesso a diverse risorse della vittima nel cloud bypassando l'MFA. +Come spiegato in [**questo video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), alcuni software Microsoft sincronizzati con il cloud (Excel, Teams...) potrebbero **memorizzare i token di accesso in chiaro nella memoria**. Quindi, semplicemente **dumpando** la **memoria** del processo e **greppando per i token JWT** potresti ottenere accesso a diverse risorse della vittima nel cloud bypassando l'MFA. Passaggi: 1. Dumpa i processi di excel sincronizzati con l'utente EntraID con il tuo strumento preferito. 2. Esegui: `string excel.dmp | grep 'eyJ0'` e trova diversi token nell'output -3. Trova i token che ti interessano di più e esegui strumenti su di essi: +3. Trova i token che ti interessano di più e utilizza strumenti su di essi: ```bash # Check the identity of the token curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq @@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/site curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq ## Finally, download a file from that drive: -┌──(magichk㉿black-pearl)-[~] -└─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` **Nota che questi tipi di token di accesso possono essere trovati anche all'interno di altri processi.** diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index dc0889d9e..652967cd3 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -4,46 +4,72 @@ **Questo post è un riassunto di** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **che può essere consultato per ulteriori informazioni sull'attacco. Questa tecnica è anche commentata in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** -## Informazioni di base +## Panoramica della Relazione di Fiducia Kerberos -### Fiducia +**Cloud Kerberos Trust (Entra ID -> AD)** -- Questa funzionalità (parte di Windows Hello for Business) stabilisce una fiducia unidirezionale in cui l'AD on-prem **si fida di Entra ID** per emettere ticket Kerberos per l'AD. Abilitandola si crea un oggetto computer **AzureADKerberos$** nell'AD (che appare come un Domain Controller in sola lettura) e un account **`krbtgt_AzureAD`** collegato (un KRBTGT secondario). Entra ID detiene le chiavi per questi account e può emettere TGT Kerberos "parziali" per gli utenti AD. I domain controller AD onoreranno questi ticket, ma con restrizioni simili a RODC: per impostazione predefinita, **i gruppi ad alta privilegio (Domain Admins, Enterprise Admins, ecc.) sono *negati*** e gli utenti normali sono autorizzati. Questo impedisce a Entra ID di autenticare gli amministratori di dominio tramite la fiducia in condizioni normali. Tuttavia, come vedremo, un attaccante con privilegi sufficienti in Entra ID può abusare di questo design di fiducia. -Quando viene stabilita una fiducia con Azure AD, un **Read Only Domain Controller (RODC) viene creato nell'AD.** L'**account computer RODC**, chiamato **`AzureADKerberos$`**. Inoltre, viene creato un account secondario `krbtgt` chiamato **`krbtgt_AzureAD`**. Questo account contiene le **chiavi Kerberos** utilizzate per i ticket che Azure AD crea. +## Pivoting da Entra ID a On-Prem AD -Pertanto, se questo account viene compromesso, potrebbe essere possibile impersonare qualsiasi utente... anche se ciò non è vero perché questo account è impedito dal creare ticket per qualsiasi gruppo privilegiato AD comune come Domain Admins, Enterprise Admins, Administrators... +**Scenario:** L'organizzazione target ha **Cloud Kerberos Trust** abilitato per l'autenticazione senza password. Un attaccante ha ottenuto privilegi di **Global Administrator** in Entra ID (Azure AD) ma non controlla ancora l'AD on-prem. L'attaccante ha anche un accesso alla rete a un Domain Controller (tramite VPN o una VM Azure in rete ibrida). Utilizzando la fiducia cloud, l'attaccante può sfruttare il controllo di Azure AD per ottenere un accesso a livello di **Domain Admin** nell'AD. -> [!CAUTION] -> Tuttavia, in uno scenario reale ci saranno utenti privilegiati che non sono in quei gruppi. Quindi il **nuovo account krbtgt, se compromesso, potrebbe essere utilizzato per impersonarli.** +**Prerequisiti:** -### Kerberos TGT +- **Cloud Kerberos Trust** è configurato nell'ambiente ibrido (indicatore: esiste un account RODC `AzureADKerberos$` nell'AD). -Inoltre, quando un utente si autentica su Windows utilizzando un'identità ibrida, **Azure AD** emetterà un **ticket Kerberos parziale insieme al PRT.** Il TGT è parziale perché **AzureAD ha informazioni limitate** dell'utente nell'AD on-prem (come l'identificatore di sicurezza (SID) e il nome).\ -Windows può quindi **scambiare questo TGT parziale per un TGT completo** richiedendo un ticket di servizio per il servizio `krbtgt`. +- L'attaccante ha diritti di **Global Admin (o Hybrid Identity Admin)** nel tenant di Entra ID (questi ruoli possono utilizzare l'**API di sincronizzazione** di AD Connect per modificare gli utenti di Azure AD). -### NTLM +- Almeno un **account utente ibrido** (esiste sia in AD che in AAD) su cui l'attaccante può autenticarsi. Questo potrebbe essere ottenuto conoscendo o reimpostando le sue credenziali o assegnando un metodo senza password (ad es. un Temporary Access Pass) per generare un Primary Refresh Token (PRT) per esso. -Poiché potrebbero esserci servizi che non supportano l'autenticazione kerberos ma NTLM, è possibile richiedere un **TGT parziale firmato utilizzando una chiave `krbtgt` secondaria** includendo il campo **`KERB-KEY-LIST-REQ`** nella parte **PADATA** della richiesta e poi ottenere un TGT completo firmato con la chiave `krbtgt` primaria **includendo l'hash NT nella risposta**. +- Un **account target AD on-prem** con privilegi elevati che *non* è nella politica di "negazione" predefinita RODC. In pratica, un ottimo obiettivo è l'**account di sincronizzazione AD Connect** (spesso chiamato **MSOL_***), che ha diritti DCSync (replicazione) in AD ma di solito non è membro dei gruppi di amministrazione integrati. Questo account di solito non è sincronizzato con Entra ID, rendendo il suo SID disponibile per impersonare senza conflitto. -## Abusare della Cloud Kerberos Trust per ottenere Domain Admin +**Passi dell'Attacco:** -Quando AzureAD genera un **TGT parziale**, utilizzerà i dettagli che ha sull'utente. Pertanto, se un Global Admin potesse modificare dati come l'**identificatore di sicurezza e il nome dell'utente in AzureAD**, quando richiede un TGT per quell'utente, l'**identificatore di sicurezza sarebbe diverso**. +1. **Ottenere Accesso all'API di sincronizzazione Azure AD:** Utilizzando l'account Global Admin, acquisire un token di accesso per l'**API di Provisioning (sync) di Azure AD**. Questo può essere fatto con strumenti come **ROADtools** o **AADInternals**. Ad esempio, con ROADtools (roadtx): +```bash +# Using roadtx to get an Azure AD Graph token (no MFA) +roadtx gettokens -u -p --resource aadgraph +``` +*(In alternativa, `Connect-AADInt` di AADInternals può essere utilizzato per autenticarsi come Global Admin.)* -Non è possibile farlo tramite Microsoft Graph o Azure AD Graph, ma è possibile utilizzare l'**API che Active Directory Connect** utilizza per creare e aggiornare utenti sincronizzati, che possono essere utilizzati dai Global Admins per **modificare il nome SAM e il SID di qualsiasi utente ibrido**, e poi se ci autentichiamo, otteniamo un TGT parziale contenente il SID modificato. +2. **Modifica gli attributi On-Prem di un utente ibrido:** Sfrutta l'**API di sincronizzazione di Azure AD** per impostare l'**Identificatore di Sicurezza (SID) onPremises** e il **SAMAccountName onPremises** di un utente ibrido scelto per corrispondere all'account AD target. Questo informa efficacemente Azure AD che l'utente cloud corrisponde all'account on-prem che vogliamo impersonare. Utilizzando il toolkit open-source **ROADtools Hybrid**: +```bash +# Example: modify a hybrid user to impersonate the MSOL account +python3 modifyuser.py -u -p \ +--sourceanchor \ +--sid --sam +``` +> L'`sourceAnchor` (ID immutabile) dell'utente è necessario per identificare l'oggetto Azure AD da modificare. Lo strumento imposta il SID on-prem e il nome account SAM dell'utente ibrido ai valori del target (ad esempio, il SID e il SAM dell'account MSOL_xxxx). Azure AD normalmente non consente di modificare questi attributi tramite Graph (sono di sola lettura), ma l'API del servizio di sincronizzazione lo consente e gli Amministratori Globali possono invocare questa funzionalità di sincronizzazione. -Nota che possiamo fare questo con AADInternals e aggiornare gli utenti sincronizzati tramite il cmdlet [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a). +3. **Ottenere un TGT parziale da Azure AD:** Dopo la modifica, autenticati come utente ibrido su Azure AD (ad esempio, ottenendo un PRT su un dispositivo o utilizzando le proprie credenziali). Quando l'utente accede (soprattutto su un dispositivo Windows unito al dominio o a Entra), Azure AD emetterà un **TGT Kerberos parziale (TGT****AD**) per quell'account perché Cloud Kerberos Trust è abilitato. Questo TGT parziale è crittografato con la chiave AzureADKerberos$ RODC e include il **SID target** che abbiamo impostato. Possiamo simulare questo richiedendo un PRT per l'utente tramite ROADtools: +```bash +roadtx getprt -u -p -d +``` +Questo genera un file `.prt` contenente il TGT parziale e la chiave di sessione. Se l'account era solo cloud, Azure AD include comunque un TGT_AD nella risposta PRT. -### Prerequisiti dell'attacco +4. **Scambiare il TGT parziale per un TGT completo (su AD):** Il TGT parziale può ora essere presentato al Domain Controller on-prem per ottenere un **TGT completo** per l'account target. Facciamo questo eseguendo una richiesta TGS per il servizio `krbtgt` (il servizio TGT principale del dominio) -- essenzialmente aggiornando il biglietto a un TGT normale con un PAC completo. Sono disponibili strumenti per automatizzare questo scambio. Ad esempio, utilizzando lo script di ROADtools Hybrid: +```bash +# Use the partial TGT from the PRT file to get a full TGT and NTLM hash +python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash +``` +Questo script (o equivalenti di Impacket) contatterà il Domain Controller e recupererà un TGT valido per l'account AD target, inclusa l'hash NTLM dell'account se viene utilizzata l'estensione Kerberos speciale. L'estensione **`KERB-KEY-LIST-REQ`** è inclusa automaticamente per chiedere al DC di restituire l'hash NTLM dell'account target nella risposta crittografata. Il risultato è una cache di credenziali (`full_tgt.ccache`) per l'account target *o* l'hash della password NTLM recuperato. -Il successo dell'attacco e il conseguimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti: +5. **Impersonare il Target e Elevare a Domain Admin:** Ora l'attaccante controlla effettivamente **l'account AD target**. Ad esempio, se il target era l'account **MSOL** di AD Connect, ha diritti di replica sulla directory. L'attaccante può eseguire un attacco **DCSync** utilizzando le credenziali di quell'account o il TGT Kerberos per estrarre gli hash delle password da AD (incluso l'account di dominio KRBTGT). Ad esempio: +```bash +# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash) +secretsdump.py 'AD_DOMAIN/$@' -hashes : LOCAL +``` +Questo estrae tutti gli hash delle password degli utenti AD, fornendo all'attaccante l'hash KRBTGT (permettendo loro di forgiare biglietti Kerberos di dominio a piacimento) e di fatto privilegi di **Domain Admin** su AD. Se l'account target fosse un altro utente privilegiato, l'attaccante potrebbe utilizzare il TGT completo per accedere a qualsiasi risorsa di dominio come quell'utente. -- La capacità di alterare gli account tramite l'API di sincronizzazione è cruciale. Questo può essere ottenuto avendo il ruolo di Global Admin o possedendo un account di sincronizzazione AD Connect. In alternativa, il ruolo di Hybrid Identity Administrator sarebbe sufficiente, poiché consente di gestire AD Connect e stabilire nuovi account di sincronizzazione. -- La presenza di un **account ibrido** è essenziale. Questo account deve essere modificabile con i dettagli dell'account vittima e deve essere accessibile per l'autenticazione. -- L'identificazione di un **account vittima target** all'interno di Active Directory è una necessità. Sebbene l'attacco possa essere eseguito su qualsiasi account già sincronizzato, il tenant Azure AD non deve aver replicato gli identificatori di sicurezza on-premises, necessitando la modifica di un account non sincronizzato per procurare il ticket. -- Inoltre, questo account dovrebbe possedere privilegi equivalenti a quelli di Domain Admin ma non deve essere un membro dei gruppi tipici di amministratori AD per evitare la generazione di TGT non validi da parte del RODC di AzureAD. -- Il target più adatto è l'**account Active Directory utilizzato dal servizio AD Connect Sync**. Questo account non è sincronizzato con Azure AD, lasciando il suo SID come un target valido, e possiede intrinsecamente privilegi equivalenti a quelli di Domain Admin a causa del suo ruolo nella sincronizzazione degli hash delle password (supponendo che la Password Hash Sync sia attiva). Per i domini con installazione espressa, questo account è prefissato con **MSOL\_**. Per altri casi, l'account può essere individuato enumerando tutti gli account dotati di privilegi di Replica Directory sull'oggetto dominio. +6. **Pulizia:** Facoltativamente, l'attaccante può ripristinare il `onPremisesSAMAccountName` e il SID originali dell'utente Azure AD modificato tramite la stessa API o semplicemente eliminare qualsiasi utente temporaneo creato. In molti casi, il successivo ciclo di sincronizzazione di Azure AD Connect ripristinerà automaticamente le modifiche non autorizzate sugli attributi sincronizzati. (Tuttavia, a questo punto il danno è fatto -- l'attaccante ha privilegi DA.) + +> [!WARNING] +> Abusando del meccanismo di fiducia e sincronizzazione del cloud, un Global Admin di Azure AD può impersonare quasi *qualsiasi* account AD non esplicitamente protetto dalla politica RODC, anche se quell'account non è mai stato sincronizzato con il cloud. In una configurazione predefinita, questo **colma una fiducia completa dalla compromissione di Azure AD alla compromissione di AD on-prem**. + + +## Riferimenti + +- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) -### L'attacco completo -Controllalo nel post originale: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md deleted file mode 100644 index 9a0d54eab..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ /dev/null @@ -1,9 +0,0 @@ -# Az - Applicazioni Predefinite - -{{#include ../../../../banners/hacktricks-training.md}} - -**Controlla la tecnica in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) e [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) - -Il post del blog discute una vulnerabilità di escalation dei privilegi in Azure AD, che consente agli Amministratori delle Applicazioni o agli Account di Sincronizzazione On-Premise compromessi di elevare i privilegi assegnando credenziali alle applicazioni. La vulnerabilità, derivante dal comportamento "di design" della gestione delle applicazioni e dei principi di servizio di Azure AD, colpisce in particolare le applicazioni predefinite di Office 365. Sebbene sia stata segnalata, la questione non è considerata una vulnerabilità da Microsoft a causa della documentazione del comportamento di assegnazione dei diritti di amministratore. Il post fornisce approfondimenti tecnici dettagliati e consiglia revisioni regolari delle credenziali dei principi di servizio negli ambienti Azure AD. Per ulteriori informazioni dettagliate, puoi visitare il post originale del blog. - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md similarity index 76% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md index 4feb7488e..c1ff45419 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md @@ -4,9 +4,10 @@ ## Informazioni di base -[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**La federazione** è un insieme di **domini** che hanno stabilito **fiducia**. Il livello di fiducia può variare, ma tipicamente include **autenticazione** e quasi sempre include **autorizzazione**. Una federazione tipica potrebbe includere un **numero di organizzazioni** che hanno stabilito **fiducia** per un **accesso condiviso** a un insieme di risorse. +[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) -Puoi **federare il tuo ambiente on-premises** **con Azure AD** e utilizzare questa federazione per l'autenticazione e l'autorizzazione. Questo metodo di accesso garantisce che tutta l'**autenticazione degli utenti avvenga on-premises**. Questo metodo consente agli amministratori di implementare livelli di controllo degli accessi più rigorosi. La federazione con **AD FS** e PingFederate è disponibile. +>**La federazione** è un insieme di **domini** che hanno stabilito **fiducia**. Il livello di fiducia può variare, ma tipicamente include **autenticazione** e quasi sempre include **autorizzazione**. Una federazione tipica potrebbe includere un **numero di organizzazioni** che hanno stabilito **fiducia** per un **accesso condiviso** a un insieme di risorse. +>Puoi **federare il tuo ambiente on-premises** **con Azure AD** e utilizzare questa federazione per l'autenticazione e l'autorizzazione. Questo metodo di accesso garantisce che tutta l'**autenticazione degli utenti avvenga on-premises**. Questo metodo consente agli amministratori di implementare livelli di controllo degli accessi più rigorosi. La federazione con **AD FS** e PingFederate è disponibile.
@@ -20,13 +21,11 @@ In qualsiasi configurazione di federazione ci sono tre parti: - Identity Provider (IdP) - Service Provider (SP) -(Immagini da https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) +
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-
- -1. Inizialmente, un'applicazione (Service Provider o SP, come la console AWS o il client web vSphere) viene accessibile da un utente. Questo passaggio potrebbe essere bypassato, portando direttamente il client all'IdP (Identity Provider) a seconda dell'implementazione specifica. +1. Inizialmente, un'applicazione (Service Provider o SP, come la console AWS o il client web vSphere) viene accessibile da un utente. Questo passaggio potrebbe essere bypassato, portando il client direttamente all'IdP (Identity Provider) a seconda dell'implementazione specifica. 2. Successivamente, lo SP identifica l'IdP appropriato (ad es., AD FS, Okta) per l'autenticazione dell'utente. Quindi crea una SAML (Security Assertion Markup Language) AuthnRequest e reindirizza il client all'IdP scelto. -3. L'IdP prende il controllo, autenticando l'utente. Dopo l'autenticazione, una SAMLResponse viene formulata dall'IdP e inoltrata allo SP attraverso l'utente. +3. L'IdP prende il controllo, autenticando l'utente. Dopo l'autenticazione, una SAMLResponse viene formulata dall'IdP e inoltrata allo SP tramite l'utente. 4. Infine, lo SP valuta la SAMLResponse. Se convalidata con successo, implicando una relazione di fiducia con l'IdP, all'utente viene concesso l'accesso. Questo segna il completamento del processo di accesso, consentendo all'utente di utilizzare il servizio. **Se vuoi saperne di più sull'autenticazione SAML e sugli attacchi comuni vai a:** @@ -38,8 +37,8 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html ## Pivoting - AD FS è un modello di identità basato su claims. -- "..le claims sono semplicemente affermazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, utilizzate principalmente per autorizzare l'accesso a applicazioni basate su claims situate ovunque su Internet." -- Le claims per un utente sono scritte all'interno dei token SAML e poi firmate per fornire riservatezza da parte dell'IdP. +- "..le claims sono semplicemente affermazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, che vengono utilizzate principalmente per autorizzare l'accesso a applicazioni basate su claims situate ovunque su Internet." +- Le claims per un utente sono scritte all'interno dei token SAML e vengono quindi firmate per fornire riservatezza da parte dell'IdP. - Un utente è identificato da ImmutableID. È globalmente unico e memorizzato in Azure AD. - L'ImmutableID è memorizzato on-prem come ms-DS-ConsistencyGuid per l'utente e/o può essere derivato dal GUID dell'utente. - Maggiori informazioni in [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims) @@ -48,15 +47,15 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html - In ADFS, la SAML Response è firmata da un certificato di firma del token. - Se il certificato è compromesso, è possibile autenticarsi su Azure AD come QUALSIASI utente sincronizzato con Azure AD! -- Proprio come il nostro abuso di PTA, il cambio password per un utente o MFA non avrà alcun effetto perché stiamo falsificando la risposta di autenticazione. +- Proprio come il nostro abuso di PTA, la modifica della password per un utente o MFA non avrà alcun effetto perché stiamo falsificando la risposta di autenticazione. - Il certificato può essere estratto dal server AD FS con privilegi DA e poi può essere utilizzato da qualsiasi macchina connessa a Internet. - Maggiori informazioni in [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) ### Golden SAML -Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica dell'IdP, la **risposta** potrebbe essere **firmata** o **crittografata** utilizzando la **chiave privata dell'IdP**. Questa procedura consente al **Service Provider (SP)** di confermare l'autenticità della SAMLResponse, assicurando che sia stata effettivamente emessa da un IdP fidato. +Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica dell'IdP, la **risposta** potrebbe essere **firmata** o **crittografata** utilizzando la **chiave privata dell'IdP**. Questa procedura consente al **Service Provider (SP)** di confermare l'autenticità della SAMLResponse, assicurandosi che sia stata effettivamente emessa da un IdP fidato. -Si può tracciare un parallelo con l'[attacco golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), dove la chiave che autentica l'identità e i permessi dell'utente (KRBTGT per i golden ticket, chiave privata di firma del token per il golden SAML) può essere manipolata per **falsificare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP. +Si può tracciare un parallelo con l'[attacco golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), dove la chiave che autentica l'identità e i permessi dell'utente (KRBTGT per i golden ticket, chiave privata di firma del token per il golden SAML) può essere manipolata per **falsificare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente di impersonare qualsiasi utente, concedendo accesso non autorizzato allo SP. I Golden SAML offrono alcuni vantaggi: @@ -83,7 +82,7 @@ I requisiti per eseguire un attacco golden SAML includono: _Solo gli elementi in grassetto sono obbligatori. Gli altri possono essere compilati a piacere._ -Per acquisire la **chiave privata**, è necessario l'accesso all'**account utente AD FS**. Da lì, la chiave privata può essere **esportata dal negozio personale** utilizzando strumenti come [mimikatz](https://github.com/gentilkiwi/mimikatz). Per raccogliere le altre informazioni richieste, puoi utilizzare il modulo Microsoft.Adfs.Powershell come segue, assicurandoti di essere connesso come utente ADFS: +Per acquisire la **chiave privata**, è necessario avere accesso all'**account utente AD FS**. Da lì, la chiave privata può essere **esportata dal negozio personale** utilizzando strumenti come [mimikatz](https://github.com/gentilkiwi/mimikatz). Per raccogliere le altre informazioni richieste, puoi utilizzare il modulo Microsoft.Adfs.Powershell come segue, assicurandoti di essere connesso come utente ADFS: ```bash # From an "AD FS" session # After having exported the key with mimikatz @@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file - # Save SAMLResponse to file python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml ``` -
+
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
### On-prem -> cloud ```bash diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md new file mode 100644 index 000000000..478266e5f --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md @@ -0,0 +1,29 @@ +# Attacchi Vari sulla Identità Ibrida + +{{#include ../../../../banners/hacktricks-training.md}} + + +## Forzare la Sincronizzazione degli utenti di Entra ID con on-prem + +Come menzionato in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), era possibile cambiare il valore di **`ProxyAddress`** all'interno di un utente AD nell'AD on-prem aggiungendo l'email di un utente admin di Entra ID e assicurandosi anche che il UPN dell'utente in AD e in Entra ID corrispondesse (questo è di nuovo l'Entra ID), come **`SMTP:admin@domain.onmicrosoft.com`**. E questo **forzerebbe la sincronizzazione di questo utente** da Entra ID all'AD on-prem, quindi se la password dell'utente era nota, poteva essere utilizzata per **accedere all'admin usato in Entra ID.** + +Per sincronizzare un nuovo utente da Entra ID all'AD on-prem, questi sono i requisiti, gli unici requisiti sono: + +- Controllare gli attributi di un utente nell'AD on-prem (o avere permessi per creare nuovi utenti) +- Conoscere l'utente solo cloud per sincronizzare da Entra ID all'AD on-prem +- Potresti anche aver bisogno di essere in grado di cambiare l'attributo immutableID dall'utente di Entra ID all'utente di AD on-prem per fare un **hard match**. + + +> [!CAUTION] +> Entra ID non consente più di sincronizzare gli admin da Entra ID all'AD on-prem. +> Inoltre, questo **non bypasserà MFA**. + + + +## Riferimenti + +- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) +- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/) +- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md similarity index 87% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md index 91dd7f12c..7143edcec 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md @@ -8,14 +8,14 @@ In PTA **le identità** sono **synchronize** ma **le password non lo sono** come in PHS. -L'autenticazione è convalidata nell'AD on-prem e la comunicazione con il cloud avviene tramite un **agente di autenticazione** in esecuzione su un **server on-prem** (non deve essere necessariamente sul DC on-prem). +L'autenticazione è convalidata nell'AD on-prem e la comunicazione con il cloud avviene tramite un **agente di autenticazione** in esecuzione su un **server on-prem** (non deve essere sul DC on-prem). ### Flusso di autenticazione
-1. Per **accedere**, l'utente viene reindirizzato a **Azure AD**, dove invia il **nome utente** e la **password** -2. Le **credenziali** sono **crittografate** e impostate in una **coda** in Azure AD +1. Per **accedere** l'utente viene reindirizzato a **Azure AD**, dove invia il **nome utente** e la **password** +2. Le **credenziali** sono **crittografate** e messe in una **coda** in Azure AD 3. L'**agente di autenticazione on-prem** raccoglie le **credenziali** dalla coda e le **decrittografa**. Questo agente è chiamato **"Pass-through authentication agent"** o **agente PTA.** 4. L'**agente** **convalida** le credenziali contro l'**AD on-prem** e invia la **risposta** **indietro** a Azure AD che, se la risposta è positiva, **completa l'accesso** dell'utente. @@ -68,7 +68,7 @@ Get-AADIntPTASpyLog -DecodePasswords # Read the file or use this to read the pas Remove-AADIntPTASpy # Remove the backdoor ``` > [!NOTE] -> Se l'**installazione fallisce**, ciò è probabilmente dovuto alla mancanza dei [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe). +> Se l'**installazione fallisce**, è probabile che ciò sia dovuto a [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe) mancanti. Questo backdoor farà: @@ -80,7 +80,7 @@ Questo backdoor farà: > Quando il servizio AzureADConnectAuthenticationAgent viene riavviato, PTASpy viene “scaricato” e deve essere reinstallato. > [!CAUTION] -> Dopo aver ottenuto i **privilegi GA** nel cloud, è possibile **registrare un nuovo agente PTA** e **ripetere** i **passaggi precedenti** per **autenticarsi utilizzando qualsiasi password** e anche, **ottenere le password in chiaro.** +> Dopo aver ottenuto i **privilegi GA** nel cloud, è possibile **registrare un nuovo agente PTA** e **ripetere** i passaggi **precedenti** per **autenticarsi utilizzando qualsiasi password** e anche, **ottenere le password in chiaro.** ### Seamless SSO diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md deleted file mode 100644 index a12730782..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ /dev/null @@ -1,30 +0,0 @@ -# Az- Sincronizzazione Nuovi Utenti - -{{#include ../../../../banners/hacktricks-training.md}} - -## Sincronizzazione degli utenti AzureAD on-prem per l'escalation da on-prem ad AzureAD - -Per sincronizzare un nuovo utente **da AzureAD all'AD on-prem** ci sono i seguenti requisiti: - -- L'**utente AzureAD** deve avere un indirizzo proxy (una **cassetta postale**) -- La licenza non è necessaria -- Non deve **essere già sincronizzato** -```bash -Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl -``` -Quando un utente come questi viene trovato in AzureAD, per **accedervi dall'AD on-prem** è sufficiente **creare un nuovo account** con il **proxyAddress** l'email SMTP. - -In automatico, questo utente sarà **sincronizzato da AzureAD all'utente AD on-prem**. - -> [!CAUTION] -> Nota che per eseguire questo attacco **non hai bisogno di Domain Admin**, hai solo bisogno di permessi per **creare nuovi utenti**. -> -> Inoltre, questo **non bypasserà MFA**. -> -> Inoltre, è stato segnalato che **la sincronizzazione degli account non è più possibile per gli account admin**. - -## References - -- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) - -{{#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 820ae4af7..989d943c6 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 @@ -9,7 +9,7 @@ ### Ruolo: Amministratore dei Ruoli Privilegiati -Questo ruolo contiene le autorizzazioni granulari necessarie per poter assegnare ruoli ai soggetti e per dare più autorizzazioni ai ruoli. Entrambe le azioni potrebbero essere abusate per escalare i privilegi. +Questo ruolo contiene le autorizzazioni granulari necessarie per poter assegnare ruoli ai principi e per dare più autorizzazioni ai ruoli. Entrambe le azioni potrebbero essere abusate per escalare i privilegi. - Assegna ruolo a un utente: ```bash @@ -61,7 +61,7 @@ az ad app credential reset --id --create-cert ``` ### `microsoft.directory/applications.myOrganization/credentials/update` -Questo consente le stesse azioni di `applications/credentials/update`, ma limitate alle applicazioni a directory singola. +Questo consente le stesse azioni di `applications/credentials/update`, ma limitate ad applicazioni a directory singola. ```bash az ad app credential reset --id --append ``` @@ -110,7 +110,7 @@ az ad sp credential reset --id --append ``` ### `microsoft.directory/servicePrincipals/owners/update` -Simile alle applicazioni, questo permesso consente di aggiungere ulteriori proprietari a un service principal. Possedere un service principal consente di controllare le sue credenziali e i suoi permessi. +Simile alle applicazioni, questo permesso consente di aggiungere ulteriori proprietari a un service principal. Possedere un service principal consente di controllare le sue credenziali e i permessi. ```bash # Add new owner spId="" @@ -136,7 +136,7 @@ Queste autorizzazioni consentono di disabilitare e abilitare i service principal Nota che per questa tecnica l'attaccante avrà bisogno di ulteriori autorizzazioni per prendere il controllo del service principal abilitato. ```bash -bashCopy code# Disable +# Disable az ad sp update --id --account-enabled false # Enable @@ -164,13 +164,21 @@ az rest --method POST \ --headers "Content-Type=application/json" \ --body "{\"id\": \"$credID\"}" ``` +### Applicazioni Privilege Escalation + +**Come spiegato in [questo post](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)** era molto comune trovare applicazioni predefinite che hanno **API permissions** di tipo **`Application`** assegnate a loro. Un'API Permission (come chiamata nella console di Entra ID) di tipo **`Application`** significa che l'applicazione può accedere all'API senza un contesto utente (senza un accesso utente all'app), e senza necessitare di ruoli di Entra ID per consentirlo. Pertanto, è molto comune trovare **applicazioni ad alta privilegio in ogni tenant di Entra ID**. + +Quindi, se un attaccante ha qualche permesso/ruolo che consente di **aggiornare le credenziali (segreto o certificato) dell'applicazione**, l'attaccante può generare una nuova credenziale e poi usarla per **autenticarsi come l'applicazione**, guadagnando tutti i permessi che l'applicazione ha. + +Nota che il blog menzionato condivide alcune **API permissions** di comuni applicazioni predefinite di Microsoft, tuttavia, qualche tempo dopo questo rapporto Microsoft ha risolto questo problema e ora non è più possibile accedere come applicazioni Microsoft. Tuttavia, è ancora possibile trovare **applicazioni personalizzate con privilegi elevati che potrebbero essere abusate**. + --- ## Gruppi ### `microsoft.directory/groups/allProperties/update` -Questo permesso consente di aggiungere utenti a gruppi privilegiati, portando a un'escalation dei privilegi. +Questo permesso consente di aggiungere utenti a gruppi privilegiati, portando a un'escalation di privilegi. ```bash az ad group member add --group --member-id ``` @@ -208,7 +216,7 @@ az rest --method PATCH \ ### Privesc dei Gruppi Dinamici -Potrebbe essere possibile per gli utenti elevare i privilegi modificando le proprie proprietà per essere aggiunti come membri di gruppi dinamici. Per ulteriori informazioni, controlla: +Potrebbe essere possibile per gli utenti elevare i privilegi modificando le proprie proprietà per essere aggiunti come membri di gruppi dinamici. Per ulteriori informazioni controlla: {{#ref}} dynamic-groups.md @@ -218,7 +226,7 @@ dynamic-groups.md ### `microsoft.directory/users/password/update` -Questo permesso consente di reimpostare la password per gli utenti non amministratori, consentendo a un potenziale attaccante di elevare i privilegi su altri utenti. Questo permesso non può essere assegnato a ruoli personalizzati. +Questo permesso consente di reimpostare la password per utenti non amministratori, permettendo a un potenziale attaccante di elevare i privilegi su altri utenti. Questo permesso non può essere assegnato a ruoli personalizzati. ```bash az ad user update --id --password "kweoifuh.234" ``` @@ -242,7 +250,7 @@ az rest --method PATCH \ ``` ## Politiche di Accesso Condizionale e bypass MFA -Le politiche di accesso condizionale configurate in modo errato che richiedono MFA potrebbero essere eluse, controlla: +Le politiche di accesso condizionale mal configurate che richiedono MFA possono essere eluse, controlla: {{#ref}} az-conditional-access-policies-mfa-bypass.md @@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md ### `microsoft.directory/devices/registeredOwners/update` -Questa autorizzazione consente agli attaccanti di assegnare a se stessi il ruolo di proprietari dei dispositivi per ottenere il controllo o l'accesso a impostazioni e dati specifici del dispositivo. +Questa autorizzazione consente agli attaccanti di assegnarsi come proprietari dei dispositivi per ottenere il controllo o l'accesso a impostazioni e dati specifici del dispositivo. ```bash deviceId="" userId="" diff --git a/src/pentesting-cloud/azure-security/az-services/az-front-door.md b/src/pentesting-cloud/azure-security/az-services/az-front-door.md new file mode 100644 index 000000000..8e3216aee --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md @@ -0,0 +1,18 @@ +# Az - File Shares + +{{#include ../../../banners/hacktricks-training.md}} + +## RemoteAddr Bypass + +Questo **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** spiega come, quando si configurano alcune restrizioni di rete con Azure Front Door, è possibile filtrare in base a **`RemoteAddr`** o **`SocketAddr`**. La principale differenza è che **`RemoteAddr`** utilizza effettivamente il valore dall'intestazione HTTP **`X-Forwarded-For`**, rendendo molto facile eludere questa restrizione. + +Per eludere questa regola, possono essere utilizzati strumenti automatizzati che **brute-force gli indirizzi IP** fino a trovare uno valido. + +Questo è menzionato nella [documentazione Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction). + + +## References + +- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass) + +{{#include ../../../banners/hacktricks-training.md}}