gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-30 22:50:43 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

Browse Source
This commit is contained in:
Translator
2025-07-30 04:13:44 +00:00
parent c64edb578f
commit e5884d1170
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md
View File

@@ -19,7 +19,7 @@ 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_<id>$@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.
- Nell'AD, viene creato o l'Account di Servizio **`provAgentgMSA`** con un SamAccountName come **`pGMSA_<id>$@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.
> [!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).
@@ -29,7 +29,7 @@ Affinché questo funzioni, alcuni principali vengono creati sia in Entra ID che
## Sincronizzazione della Password
La sezione è molto simile a quella di:
Questa sezione è molto simile a quella di:
{{#ref}}
az-connect-sync.md
@@ -37,7 +37,7 @@ az-connect-sync.md
- **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.
- **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.
- **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
@@ -81,13 +81,13 @@ 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 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 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
../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
{{#endref}}
Per quanto riguarda la persistenza, [questo post del blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggerisce che è possibile utilizzare [**dnSpy**](https://github.com/dnSpy/dnSpy) per backdoorare il dll **`Microsoft.Online.Passwordsynchronisation.dll`** situato in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** che viene utilizzato dall'agente Cloud Sync per eseguire la sincronizzazione delle password, facendolo esfiltrare gli hash delle password degli utenti sincronizzati a un server remoto. Gli hash vengono generati all'interno della classe **`PasswordHashGenerator`** e il post del blog suggerisce di aggiungere del codice in modo che la classe appaia così (nota l'uso di `System.Net` e l'uso di `WebClient` per esfiltrare gli hash delle password):
Per quanto riguarda la persistenza, [questo post del blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggerisce che è possibile utilizzare [**dnSpy**](https://github.com/dnSpy/dnSpy) per backdoorare il dll **`Microsoft.Online.Passwordsynchronisation.dll`** situato in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** che viene utilizzato dall'agente Cloud Sync per eseguire la sincronizzazione delle password, facendolo esfiltrare gli hash delle password degli utenti sincronizzati a un server remoto. Gli hash vengono generati all'interno della classe **`PasswordHashGenerator`** e il post del blog suggerisce di aggiungere del codice in modo che la classe appaia così (nota l'uso di `use System.Net` e l'uso di `WebClient` per esfiltrare gli hash delle password):
```csharp
using System;
using System.Net;
@@ -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 quelle 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 queste 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):
> - 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.
> - 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).