From c8a4b08387e473b8b2119554d4bee0159751bde1 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 30 Jul 2025 04:41:27 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo --- .../README.md | 8 +++--- .../az-arc-vulnerable-gpo-deploy-script.md | 4 +-- .../az-cloud-kerberos-trust.md | 18 ++++++------ .../az-cloud-sync.md | 18 ++++++------ .../az-connect-sync.md | 22 +++++++-------- .../az-domain-services.md | 12 ++++---- .../az-federation.md | 14 +++++----- .../az-hybrid-identity-misc-attacks.md | 6 ++-- .../az-pass-the-certificate.md | 2 +- .../az-pass-the-cookie.md | 2 +- .../az-primary-refresh-token-prt.md | 28 +++++++++---------- .../az-pta-pass-through-authentication.md | 12 ++++---- .../seamless-sso.md | 16 +++++------ 13 files changed, 82 insertions(+), 80 deletions(-) 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 61f43c77e..e81819c77 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 @@ -10,15 +10,15 @@ Questa sezione tratta le tecniche di pivoting per spostarsi da un tenant Entra I - [**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. -- [**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. +- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Come effettuare il pivoting da Entra ID a AD quando è configurato Cloud Kerberos Trust. Un Global Admin in Entra ID (Azure AD) può abusare di 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. -- [**Cloud Sync**](az-cloud-sync.md): Come abusare del Cloud Sync per spostarsi dal cloud all'AD on-premises e viceversa. +- [**Cloud Sync**](az-cloud-sync.md): Come abusare di Cloud Sync per spostarsi dal cloud all'AD on-premises e viceversa. -- [**Connect Sync**](az-connect-sync.md): Come abusare del Connect Sync per spostarsi dal cloud all'AD on-premises e viceversa. +- [**Connect Sync**](az-connect-sync.md): Come abusare di Connect Sync per spostarsi dal cloud all'AD on-premises e viceversa. - [**Domain Services**](az-domain-services.md): Cos'è il servizio Azure Domain Services e come effettuare il pivoting da Entra ID all'AD che genera. -- [**Federation**](az-federation.md): Come abusare della Federation per spostarsi dal cloud all'AD on-premises e viceversa. +- [**Federation**](az-federation.md): Come abusare della Federazione per spostarsi dal cloud all'AD on-premises e viceversa. - [**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. 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 f36adfea7..b8b2a91c7 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 @@ -11,7 +11,7 @@ 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 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 anche 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 misconfigurazioni. +Ci sono diversi metodi per ottenere un account macchina all'interno di un ambiente AD. Uno dei più comuni è sfruttare il limite 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/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md index 652788a5c..3349266d3 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md @@ -1,12 +1,12 @@ # Az - Cloud Kerberos Trust -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} **Questo post è un riassunto di** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **che può essere consultato per ulteriori informazioni sull'attacco. Questa tecnica è anche commentata in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** ## 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$** 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. +**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 quelle di un RODC: per impostazione predefinita, **i gruppi ad alta privilegio (Domain Admins, Enterprise Admins, ecc.) sono *negati*** e gli utenti ordinari 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 @@ -16,22 +16,22 @@ - **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 **synchronization** 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 **sincronizzazione** 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 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. +- Un **account target AD on-prem** con privilegi elevati che *non* è nella policy di "negazione" predefinita del 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 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): +1. **Ottenere Accesso all'API di Sincronizzazione Azure AD:** Utilizzando l'account Global Admin, acquisire un token di accesso per l'API di **Provisioning (sync) di Azure AD**. Questo può essere fatto con strumenti come **ROADtools** o **AADInternals**. Ad esempio, con ROADtools (roadtx): ```bash # Using roadtx to get an Azure AD Graph token (no MFA) roadtx gettokens -u -p --resource aadgraph ``` *(In alternativa, `Connect-AADInt` di AADInternals può essere utilizzato per autenticarsi come Global Admin.)* -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**: +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 di destinazione. 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 \ @@ -44,7 +44,7 @@ python3 modifyuser.py -u -p \ ```bash roadtx getprt -u -p -d ``` -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. +Questo genera 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 @@ -60,7 +60,7 @@ 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` 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.) +6. **Pulizia:** Facoltativamente, l'attaccante può ripristinare il `onPremisesSAMAccountName` e il SID originali dell'utente Azure AD modificato tramite la stessa API o semplicemente eliminare qualsiasi utente temporaneo creato. In molti casi, il successivo ciclo di sincronizzazione di Azure AD Connect ripristinerà automaticamente le modifiche non autorizzate sugli attributi sincronizzati. (Tuttavia, a questo punto il danno è fatto -- l'attaccante ha privilegi DA.) > [!WARNING] > Abusando del meccanismo di fiducia e sincronizzazione del cloud, un Global Admin di Azure AD può impersonare quasi *qualsiasi* account AD non esplicitamente protetto dalla politica RODC, anche se quell'account non è mai stato sincronizzato con il cloud. In una configurazione predefinita, questo **colma una fiducia completa dalla compromissione di Azure AD alla compromissione di AD on-prem**. @@ -72,4 +72,4 @@ Questo estrae tutti gli hash delle password degli utenti AD, fornendo all'attacc -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index d7eb0c0c7..8624cebf2 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -1,6 +1,7 @@ # Az - Cloud Sync -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} + ## Informazioni di Base @@ -19,26 +20,27 @@ Affinché questo funzioni, alcuni principali vengono creati sia in Entra ID che - 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 sono 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. +- Nell'AD, viene creata la Service Account **`provAgentgMSA`** con un SamAccountName come **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), oppure una personalizzata 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 creata quella predefinita. > [!WARNING] -> Tra le altre autorizzazioni, l'Account di Servizio **`provAgentgMSA`** ha autorizzazioni DCSync, consentendo **a chiunque lo comprometta di compromettere l'intera directory**. Per ulteriori informazioni su [DCSync controlla questo](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). +> Tra le altre autorizzazioni, la Service Account **`provAgentgMSA`** ha autorizzazioni DCSync, consentendo **a chiunque la comprometta di compromettere l'intera directory**. Per ulteriori informazioni su [DCSync controlla questo](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!NOTE] > Per impostazione predefinita, gli utenti di gruppi privilegiati noti come Domain Admins con l'attributo **`adminCount` a 1 non vengono sincronizzati** con Entra ID per motivi di sicurezza. Tuttavia, altri utenti che fanno parte di gruppi privilegiati senza questo attributo o che sono assegnati a privilegi elevati direttamente **possono essere sincronizzati**. ## 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 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. +- **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. + ## Pivoting ### AD --> Entra ID @@ -81,7 +83,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i {{#endref}} > [!NOTE] -> 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 gli utenti sincronizzati all'interno di quei gruppi li ricevano anche, oppure **potrebbero essere utilizzati gruppi dinamici**, quindi controlla sempre le regole dinamiche e i potenziali modi per abusarne: +> Nota che non c'è modo di 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 gli utenti sincronizzati all'interno di quei gruppi li ricevano anche, 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,7 +129,7 @@ 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 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): @@ -148,4 +150,4 @@ az rest \ --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \ --headers "Content-Type=application/json" ``` -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md index 4e86ef9c6..35304b479 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md @@ -1,8 +1,8 @@ # Az - Connect Sync -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} -## Informazioni di Base +## Informazioni di base [From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) I servizi di sincronizzazione Microsoft Entra Connect (Microsoft Entra Connect Sync) sono un componente principale di Microsoft Entra Connect. Si occupa di tutte le operazioni relative alla sincronizzazione dei dati di identità tra il tuo ambiente on-premises e Microsoft Entra ID. @@ -16,16 +16,16 @@ Il **Connect Sync** è fondamentalmente il modo "vecchio" di Azure per **synchro az-cloud-sync.md {{#endref}} -### Principali Generati +### 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**. -- Questo significa che chiunque comprometta questo account sarà in grado di compromettere il dominio on-premise. +- 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 speciali di default. - In Entra ID, il Service Principal **`ConnectSyncProvisioning_ConnectSync_`** viene creato con un certificato. -## Sincronizzare le Password +## Sincronizzare le password -### Sincronizzazione dell'Hash della Password +### Sincronizzazione dell'hash della password Questo componente può essere utilizzato anche per **synchronizzare le password da AD in Entra ID** in modo che gli utenti possano utilizzare le loro password AD per connettersi a Entra ID. Per questo, è necessario consentire la sincronizzazione dell'hash della password nell'agente Microsoft Entra Connect Sync installato in un server AD. @@ -40,7 +40,7 @@ Quando un utente on-prem vuole accedere a una risorsa Azure, **l'autenticazione > [!NOTE] > Per impostazione predefinita, gli utenti di gruppi privilegiati noti come Domain Admins con l'attributo **`adminCount` a 1 non vengono sincronizzati** con Entra ID per motivi di sicurezza. Tuttavia, altri utenti che fanno parte di gruppi privilegiati senza questo attributo o che hanno privilegi elevati assegnati direttamente **possono essere sincronizzati**. -### Scrittura della Password +### 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 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**. @@ -50,7 +50,7 @@ Gli amministratori di dominio e altri utenti appartenenti a gruppi privilegiati - Utenti assegnati privilegi elevati direttamente. - Utenti del gruppo **`DNSAdmins`**. -- Utenti del gruppo **`Group Policy Creator Owners`** che hanno creato GPO e li hanno assegnati a OUs saranno in grado di modificare i GPO che hanno creato. +- Utenti del gruppo **`Group Policy Creator Owners`** che hanno creato GPO e li hanno assegnati a OUs saranno in grado di modificare le GPO che hanno creato. - Utenti del **`Cert Publishers Group`** che possono pubblicare certificati in Active Directory. - Utenti di qualsiasi altro gruppo con privilegi elevati senza l'attributo **`adminCount` a 1**. @@ -128,7 +128,7 @@ Questa applicazione è creata senza avere alcun ruolo di gestione di Entra ID o Si menziona che lo SP di questa applicazione può ancora essere utilizzato per eseguire alcune azioni privilegiate utilizzando un'API non documentata, ma finora non è stata trovata alcuna PoC a mia conoscenza.\ In ogni caso, pensando che ciò possa essere possibile, sarebbe interessante esplorare ulteriormente come trovare il certificato per accedere come questo service principal e provare ad abusarne. -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. +Questo [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) è stato pubblicato poco prima del passaggio 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 pubblicati i seguenti strumenti: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils). @@ -137,7 +137,7 @@ Dalla mia esperienza, il certificato non è più memorizzato nel luogo in cui il ### Abusare di Sync\_\* [DEPRECATED] > [!WARNING] -> In precedenza, un utente chiamato `Sync_*` era stato creato in Entra ID con autorizzazioni molto sensibili assegnate, che consentivano di eseguire azioni privilegiate come modificare la password di qualsiasi utente o aggiungere una nuova credenziale a un service principal. Tuttavia, dal gennaio 2025, questo utente non viene più creato per impostazione predefinita poiché ora viene utilizzata l'Applicazione/SP **`ConnectSyncProvisioning_ConnectSync_`**. Tuttavia, potrebbe essere ancora presente in alcuni ambienti, quindi vale la pena controllarlo. +> In precedenza, un utente chiamato `Sync_*` era stato creato in Entra ID con permessi molto sensibili assegnati, che consentivano di eseguire azioni privilegiate come modificare la password di qualsiasi utente o aggiungere una nuova credenziale a un service principal. Tuttavia, dal gennaio 2025, questo utente non viene più creato per impostazione predefinita poiché ora viene utilizzato l'Application/SP **`ConnectSyncProvisioning_ConnectSync_`**. Tuttavia, potrebbe essere ancora presente in alcuni ambienti, quindi vale la pena controllarlo. Compromettere l'account **`Sync_*`** rende possibile **reimpostare la password** di qualsiasi utente (inclusi gli Amministratori Globali) ```bash @@ -199,4 +199,4 @@ seamless-sso.md - [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/) - [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} 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 index 4789ea658..3c69cbb7a 100644 --- 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 @@ -1,10 +1,10 @@ # Az - Microsoft Entra Domain Services -{{#include ../../../../banners/hacktricks-training.md}} +{{#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). +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 essi). 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. @@ -32,12 +32,12 @@ 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.** +Il pivoting da Entra ID a un AD creato con Domain Services è semplice, basta aggiungere un utente nel gruppo **`AAD DC Administrators`**, accedere via 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. +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 permessi interessanti. Inoltre, **dumpa tutte le password degli utenti dal dominio** e prova a crackerle 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. +> 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 molto facilmente mantenere la persistenza senza che gli amministratori di Azure se ne accorgano o siano in grado di rimuoverla. ### Enumerazione ```bash @@ -83,4 +83,4 @@ fi done done <<< "$vm_list" ``` -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md index c4796f246..41e219d5b 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md @@ -1,6 +1,6 @@ # Az - Federation -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informazioni di base @@ -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 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. +- "..le claims 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 claims per un utente sono scritte all'interno dei token SAML e vengono quindi firmate per fornire riservatezza da parte dell'IdP. - Un utente è identificato da ImmutableID. È globalmente unico e memorizzato in Azure AD. - L'ImmutableID è memorizzato on-prem come ms-DS-ConsistencyGuid per l'utente e/o può essere derivato dal GUID dell'utente. - Maggiori informazioni in [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims) @@ -48,12 +48,12 @@ 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 quindi può essere utilizzato da qualsiasi macchina connessa a Internet. +- Il certificato può essere estratto dal server AD FS con privilegi DA e poi può essere utilizzato da qualsiasi macchina connessa a Internet. - Maggiori informazioni in [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) ### Golden SAML -Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica dell'IdP, la **risposta** potrebbe essere **firmata** o **crittografata** utilizzando la **chiave privata dell'IdP**. Questa procedura consente al **Service Provider (SP)** di confermare l'autenticità della SAMLResponse, assicurandosi che sia stata effettivamente emessa da un IdP fidato. +Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica dell'IdP, la **risposta** potrebbe essere **firmata** o **crittografata** utilizzando la **chiave privata dell'IdP**. Questa procedura consente al **Service Provider (SP)** di confermare l'autenticità della SAMLResponse, assicurando 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 **forgiare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP. @@ -82,7 +82,7 @@ I requisiti per eseguire un attacco golden SAML includono: _Solo gli elementi in grassetto sono obbligatori. Gli altri possono essere compilati a piacere._ -Per acquisire la **chiave privata**, è necessario avere accesso all'**account utente AD FS**. Da lì, la chiave privata può essere **esportata dal negozio personale** utilizzando strumenti come [mimikatz](https://github.com/gentilkiwi/mimikatz). Per raccogliere le altre informazioni richieste, puoi utilizzare il modulo Microsoft.Adfs.Powershell come segue, assicurandoti di essere connesso come utente ADFS: +Per acquisire la **chiave privata**, è necessario l'accesso all'**account utente AD FS**. Da lì, la chiave privata può essere **esportata dal negozio personale** utilizzando strumenti come [mimikatz](https://github.com/gentilkiwi/mimikatz). Per raccogliere le altre informazioni richieste, puoi utilizzare il modulo Microsoft.Adfs.Powershell come segue, assicurandoti di essere connesso come utente ADFS: ```bash # From an "AD FS" session # After having exported the key with mimikatz @@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http: - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed) - [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) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md index 6ee270278..4147f4193 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md @@ -1,6 +1,6 @@ -# Attacchi Vari su Identità Ibrida +# Attacchi Vari sulla Identità Ibrida -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Forzare la Sincronizzazione degli utenti di Entra ID con on-prem @@ -26,4 +26,4 @@ Per sincronizzare un nuovo utente da Entra ID all'AD on-prem, questi sono i requ - [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/) - [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/) -{{#include ../../../../banners/hacktricks-training.md}} +{{#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 64ce0124c..dd630b329 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 @@ -9,7 +9,7 @@ In macchine collegate ad Azure, è possibile autenticarsi da una macchina all'al In termini super semplificati: - La macchina (client) che avvia la connessione **ha bisogno di un certificato da Entra ID per un utente**. -- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (utilizzando la chiave di sessione e il contesto di sicurezza) e **la invia a Entra ID**. +- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (usando 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**](az-primary-refresh-token-prt.md): 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 c416f41aa..9d5640bef 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 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: +La parte difficile è che quei **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: {{#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 f6983e12c..3dfaeb209 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,7 +4,7 @@ ## 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** (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. +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 Proof-of-Possession key) -- 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 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. @@ -40,7 +40,7 @@ Ecco una semplificazione di come opera un PRT: - **Sicurezza Migliorata:** Con protezioni hardware integrate (come il TPM), i PRT garantiscono una memorizzazione e un utilizzo sicuri dei token. -- **Esperienza Utente:** I PRT migliorano significativamente l'esperienza utente riducendo le richieste di autenticazione frequenti e abilitando un vero SSO senza soluzione di continuità. +- **Esperienza Utente:** I PRT migliorano significativamente l'esperienza dell'utente riducendo le richieste di autenticazione frequenti e abilitando un vero SSO senza soluzione di continuità. ## Come sapere se un PRT è presente? @@ -63,12 +63,12 @@ dsregcmd /status ``` ## 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 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. +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 (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). +2. La **Session Key viene estratta successivamente**. Dato che questa chiave è inizialmente emessa e poi ri-cifrata dal dispositivo locale, richiede decrittografia 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 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 @@ -92,7 +92,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue: [!NOTE] @@ -105,7 +105,7 @@ 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 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). +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 si fosse verificato SSO), e emetterà un codice di autorizzazione o un token di accesso per la risorsa specificata. In pratica, si navigerebbe 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). 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)*. @@ -143,7 +143,7 @@ Questo ottiene un cookie PRT fresco (con un nonce) e poi lo utilizza per recuper ```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. +- 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'affermazione MFA perché il PRT che ho usato in questo caso aveva anche un'affermazione MFA. ```bash roadtx browserprtauth roadtx describe < .roadtools_auth @@ -158,7 +158,7 @@ roadrecon auth --prt-cookie --prt-context --derives-key [!NOTE] -> Quando il servizio AzureADConnectAuthenticationAgent viene riavviato, PTASpy è “scaricato” e deve essere reinstallato. +> Quando il servizio AzureADConnectAuthenticationAgent viene riavviato, PTASpy viene “scaricato” e deve essere reinstallato. > [!CAUTION] > Dopo aver ottenuto i **privilegi GA** nel cloud, è possibile **registrare un nuovo agente PTA** e **ripetere** i **passaggi precedenti** per **autenticarsi utilizzando qualsiasi password** e anche, **ottenere le password in chiaro.** @@ -95,4 +95,4 @@ seamless-sso.md - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta) - [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md index f0aa9456d..a7802fdd8 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md @@ -1,14 +1,14 @@ # Az - Seamless SSO -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Informazioni di base -[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. +[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 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 **accede gli utenti** quando sono **su un PC unito a un dominio on-prem**. +Fondamentalmente, Azure AD Seamless SSO **accede gli utenti** quando si trovano **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). @@ -65,11 +65,11 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234 wmic useraccount get name,sid # Get the user SIDs ``` -Ulteriori informazioni per configurare Firefox per lavorare con il seamless SSO possono essere [**trovate in questo post del blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). +Ulteriori informazioni per configurare Firefox per lavorare con SSO senza soluzione di continuità possono essere [**trovate in questo post del blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). ### Ottenere gli hash dell'account AZUREADSSOACC$ -La **password** dell'utente **`AZUREADSSOACC$` non cambia mai**. Pertanto, un amministratore di dominio potrebbe compromettere l'**hash di questo account**, e poi usarlo per **creare silver tickets** per connettersi ad Azure con **qualsiasi utente on-prem sincronizzato**: +La **password** dell'utente **`AZUREADSSOACC$` non cambia mai**. Pertanto, un amministratore di dominio potrebbe compromettere il **hash di questo account** e poi usarlo per **creare biglietti silver** per connettersi ad Azure con **qualsiasi utente on-prem sincronizzato**: ```bash # Dump hash using mimikatz Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"' @@ -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 es. alice) ```bash # Using your machine's password or NTLM hash python3 getST.py -dc-ip 192.168.1.10 \ @@ -177,7 +177,7 @@ Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, pos > [!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/) @@ -188,4 +188,4 @@ Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, pos - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) - [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}}