mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-11 20:45:21 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -10,7 +10,7 @@ az-basic-information/
|
||||
|
||||
## Metodología de Pentesting/Red Team de Azure
|
||||
|
||||
Para auditar un entorno de AZURE, es muy importante saber: qué **servicios se están utilizando**, qué está **siendo expuesto**, quién tiene **acceso** a qué, y cómo están conectados los servicios internos de Azure y los **servicios externos**.
|
||||
Para auditar un entorno AZURE, es muy importante saber: qué **servicios se están utilizando**, qué está **siendo expuesto**, quién tiene **acceso** a qué, y cómo están conectados los servicios internos de Azure y los **servicios externos**.
|
||||
|
||||
Desde el punto de vista de un Red Team, el **primer paso para comprometer un entorno de Azure** es conseguir obtener algunas **credenciales** para Azure AD. Aquí tienes algunas ideas sobre cómo hacerlo:
|
||||
|
||||
@@ -23,7 +23,7 @@ Desde el punto de vista de un Red Team, el **primer paso para comprometer un ent
|
||||
- `/home/USERNAME/.azure`
|
||||
- `C:\Users\USERNAME\.azure`
|
||||
- El archivo **`accessTokens.json`** en `az cli` antes de 2.30 - Jan2022 - almacenaba **tokens de acceso en texto claro**
|
||||
- El archivo **`azureProfile.json`** contiene **info** sobre el usuario conectado.
|
||||
- El archivo **`azureProfile.json`** contiene **información** sobre el usuario conectado.
|
||||
- **`az logout`** elimina el token.
|
||||
- Versiones anteriores de **`Az PowerShell`** almacenaban **tokens de acceso** en **texto claro** en **`TokenCache.dat`**. También almacena **ServicePrincipalSecret** en **texto claro** en **`AzureRmContext.json`**. El cmdlet **`Save-AzContext`** se puede usar para **almacenar** **tokens**.\
|
||||
Usa `Disconnect-AzAccount` para eliminarlos.
|
||||
@@ -33,7 +33,7 @@ Usa `Disconnect-AzAccount` para eliminarlos.
|
||||
- [Phishing de Autenticación con Código de Dispositivo](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
|
||||
- [**Password Spraying** de Azure](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
|
||||
|
||||
Incluso si no has **comprometido a ningún usuario** dentro del inquilino de Azure que estás atacando, puedes **recolectar algo de información** de él:
|
||||
Incluso si **no has comprometido a ningún usuario** dentro del inquilino de Azure que estás atacando, puedes **recolectar algo de información** de él:
|
||||
|
||||
{{#ref}}
|
||||
az-unauthenticated-enum-and-initial-entry/
|
||||
|
||||
@@ -58,7 +58,7 @@ Entra ID es un servicio de **gestión de identidad y acceso basado en la nube**
|
||||
|
||||
### Servicios de Dominio de Entra (anteriormente Azure AD DS)
|
||||
|
||||
Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrecer **servicios de dominio administrados compatibles con entornos tradicionales de Windows Active Directory**. Soporta protocolos heredados como LDAP, Kerberos y NTLM, permitiendo a las organizaciones migrar o ejecutar aplicaciones más antiguas en la nube sin desplegar controladores de dominio locales. Este servicio también soporta Políticas de Grupo para gestión centralizada, haciéndolo adecuado para escenarios donde cargas de trabajo heredadas o basadas en AD necesitan coexistir con entornos modernos en la nube.
|
||||
Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrecer **servicios de dominio gestionados compatibles con entornos tradicionales de Windows Active Directory**. Soporta protocolos heredados como LDAP, Kerberos y NTLM, permitiendo a las organizaciones migrar o ejecutar aplicaciones más antiguas en la nube sin desplegar controladores de dominio locales. Este servicio también soporta la Política de Grupo para la gestión centralizada, haciéndolo adecuado para escenarios donde cargas de trabajo heredadas o basadas en AD necesitan coexistir con entornos modernos en la nube.
|
||||
|
||||
## Principales de Entra ID
|
||||
|
||||
@@ -80,11 +80,11 @@ Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrece
|
||||
Puedes consultarlos en [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) pero entre otras acciones, un miembro podrá:
|
||||
|
||||
- Leer todos los usuarios, Grupos, Aplicaciones, Dispositivos, Roles, Suscripciones y sus propiedades públicas
|
||||
- Invitar Invitados (_se puede desactivar_)
|
||||
- Invitar a Invitados (_se puede desactivar_)
|
||||
- Crear grupos de seguridad
|
||||
- Leer membresías de grupos no ocultos
|
||||
- Agregar invitados a grupos de propiedad
|
||||
- Crear nueva aplicación (_se puede desactivar_)
|
||||
- Crear nuevas aplicaciones (_se puede desactivar_)
|
||||
- Agregar hasta 50 dispositivos a Azure (_se puede desactivar_)
|
||||
|
||||
> [!NOTE]
|
||||
@@ -149,7 +149,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
1. **ID de Aplicación (Client ID):** Un identificador único para tu aplicación en Azure AD.
|
||||
2. **URIs de Redirección:** URLs donde Azure AD envía respuestas de autenticación.
|
||||
3. **Certificados, Secretos y Credenciales Federadas:** Es posible generar un secreto o un certificado para iniciar sesión como el principal de servicio de la aplicación, o para otorgar acceso federado a ella (por ejemplo, Github Actions). 
|
||||
1. Si se genera un **certificado** o **secreto**, es posible que una persona **inicie sesión como el principal de servicio** con herramientas CLI al conocer el **ID de aplicación**, el **secreto** o **certificado** y el **inquilino** (dominio o ID).
|
||||
1. Si se genera un **certificado** o **secreto**, es posible que una persona **inicie sesión como el principal de servicio** con herramientas CLI conociendo el **ID de aplicación**, el **secreto** o **certificado** y el **inquilino** (dominio o ID).
|
||||
4. **Permisos de API:** Especifica qué recursos o APIs puede acceder la aplicación.
|
||||
5. **Configuraciones de Autenticación:** Define los flujos de autenticación soportados por la aplicación (por ejemplo, OAuth2, OpenID Connect).
|
||||
6. **Principal de Servicio**: Un principal de servicio se crea cuando se crea una Aplicación (si se hace desde la consola web) o cuando se instala en un nuevo inquilino.
|
||||
@@ -157,7 +157,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
|
||||
### Permisos de Consentimiento Predeterminados
|
||||
|
||||
**Consentimiento del usuario para aplicaciones**
|
||||
**Consentimiento de usuario para aplicaciones**
|
||||
|
||||
- **No permitir el consentimiento del usuario**
|
||||
- Se requerirá un administrador para todas las aplicaciones.
|
||||
@@ -170,13 +170,13 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
- profile - ver el perfil básico del usuario
|
||||
- email - ver la dirección de correo electrónico del usuario
|
||||
- **Permitir el consentimiento del usuario para aplicaciones (Predeterminado)**
|
||||
- Todos los usuarios pueden consentir que cualquier aplicación acceda a los datos de la organización.
|
||||
- Todos los usuarios pueden consentir cualquier aplicación para acceder a los datos de la organización.
|
||||
|
||||
**Solicitudes de consentimiento de administrador**: Predeterminado **No**
|
||||
|
||||
- Los usuarios pueden solicitar consentimiento de administrador para aplicaciones a las que no pueden consentir
|
||||
- Si **Sí**: Es posible indicar Usuarios, Grupos y Roles que pueden consentir solicitudes
|
||||
- Configura también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración 
|
||||
- Configurar también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración 
|
||||
|
||||
### **Identidad Administrada (Metadatos)**
|
||||
|
||||
@@ -184,8 +184,8 @@ Las identidades administradas en Azure Active Directory ofrecen una solución pa
|
||||
|
||||
Hay dos tipos de identidades administradas:
|
||||
|
||||
- **Asignadas por el sistema**. Algunos servicios de Azure permiten **habilitar una identidad administrada directamente en una instancia de servicio**. Cuando habilitas una identidad administrada asignada por el sistema, se crea un **principal de servicio** en el inquilino de Entra ID confiado por la suscripción donde se encuentra el recurso. Cuando se **elimina el recurso**, Azure automáticamente **elimina** la **identidad** por ti.
|
||||
- **Asignadas por el usuario**. También es posible que los usuarios generen identidades administradas. Estas se crean dentro de un grupo de recursos dentro de una suscripción y se creará un principal de servicio en el EntraID confiado por la suscripción. Luego, puedes asignar la identidad administrada a una o **más instancias** de un servicio de Azure (múltiples recursos). Para identidades administradas asignadas por el usuario, la **identidad se gestiona por separado de los recursos que la utilizan**.
|
||||
- **Asignadas por el sistema**. Algunos servicios de Azure te permiten **habilitar una identidad administrada directamente en una instancia de servicio**. Cuando habilitas una identidad administrada asignada por el sistema, se crea un **principal de servicio** en el inquilino de Entra ID confiado por la suscripción donde se encuentra el recurso. Cuando se **elimina el recurso**, Azure automáticamente **elimina** la **identidad** por ti.
|
||||
- **Asignadas por el usuario**. También es posible que los usuarios generen identidades administradas. Estas se crean dentro de un grupo de recursos dentro de una suscripción y se creará un principal de servicio en el EntraID confiado por la suscripción. Luego, puedes asignar la identidad administrada a una o **más instancias** de un servicio de Azure (múltiples recursos). Para las identidades administradas asignadas por el usuario, la **identidad se gestiona por separado de los recursos que la utilizan**.
|
||||
|
||||
Las Identidades Administradas **no generan credenciales eternas** (como contraseñas o certificados) para acceder como el principal de servicio adjunto a ella.
|
||||
|
||||
@@ -221,7 +221,7 @@ Ejemplo:
|
||||
|
||||
## Roles y Permisos
|
||||
|
||||
**Los roles** son **asignados** a **principales** en un **alcance**: `principal -[HAS ROLE]->(scope)`
|
||||
**Los roles** son **asignados** a **principales** en un **alcance**: `principal -[TIENE ROL]->(alcance)`
|
||||
|
||||
**Los roles** asignados a **grupos** son **heredados** por todos los **miembros** del grupo.
|
||||
|
||||
@@ -237,9 +237,9 @@ Dependiendo del alcance al que se asignó el rol, el **rol** podría ser **hered
|
||||
|
||||
### Roles Integrados
|
||||
|
||||
[De la documentación: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[El control de acceso basado en roles de Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) tiene varios **roles integrados de Azure** que puedes **asignar** a **usuarios, grupos, principales de servicio y identidades administradas**. Las asignaciones de roles son la forma en que controlas **el acceso a los recursos de Azure**. Si los roles integrados no satisfacen las necesidades específicas de tu organización, puedes crear tus propios [**roles personalizados de Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
[De la documentación: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[El control de acceso basado en roles de Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) tiene varios **roles integrados de Azure** que puedes **asignar** a **usuarios, grupos, principales de servicio e identidades administradas**. Las asignaciones de roles son la forma en que controlas **el acceso a los recursos de Azure**. Si los roles integrados no satisfacen las necesidades específicas de tu organización, puedes crear tus propios [**roles personalizados de Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
|
||||
Los roles **integrados** se aplican solo a los **recursos** para los que están **destinados**, por ejemplo, consulta estos 2 ejemplos de **roles integrados sobre recursos de Cómputo**:
|
||||
Los **roles integrados** se aplican solo a los **recursos** para los que están **destinados**, por ejemplo, consulta estos 2 ejemplos de **roles integrados sobre recursos de Cómputo**:
|
||||
|
||||
| [Lector de Copia de Seguridad de Disco](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Proporciona permiso al cofre de copia de seguridad para realizar copias de seguridad de disco. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
@@ -295,7 +295,7 @@ Ejemplo de JSON de permisos para un rol personalizado:
|
||||
### Orden de permisos
|
||||
|
||||
- Para que un **principal tenga acceso a un recurso**, necesita que se le otorgue un rol explícito (de cualquier manera) **que le otorgue ese permiso**.
|
||||
- Una asignación de rol explícita de **denegación tiene prioridad** sobre el rol que otorga el permiso.
|
||||
- Una **asignación de rol de denegación explícita tiene prioridad** sobre el rol que otorga el permiso.
|
||||
|
||||
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
|
||||
|
||||
@@ -303,14 +303,14 @@ Ejemplo de JSON de permisos para un rol personalizado:
|
||||
|
||||
El Administrador Global es un rol de Entra ID que otorga **control total sobre el inquilino de Entra ID**. Sin embargo, no otorga permisos sobre los recursos de Azure por defecto.
|
||||
|
||||
Los usuarios con el rol de Administrador Global tienen la capacidad de '**elevar' a Administrador de Acceso de Usuario en el Grupo de Gestión Raíz de Azure**. Así que los Administradores Globales pueden gestionar el acceso en **todas las suscripciones y grupos de gestión de Azure.**\
|
||||
Los usuarios con el rol de Administrador Global tienen la capacidad de '**elevar' a Administrador de Acceso de Usuario en el Grupo de Gestión Raíz de Azure**. Por lo tanto, los Administradores Globales pueden gestionar el acceso en **todas las suscripciones y grupos de gestión de Azure.**\
|
||||
Esta elevación se puede hacer al final de la página: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Políticas de Azure
|
||||
|
||||
**Las Políticas de Azure** son reglas que ayudan a las organizaciones a asegurar que sus recursos cumplan con estándares específicos y requisitos de cumplimiento. Permiten **hacer cumplir o auditar configuraciones en recursos de Azure**. Por ejemplo, puedes prevenir la creación de máquinas virtuales en una región no autorizada o asegurar que todos los recursos tengan etiquetas específicas para el seguimiento.
|
||||
**Las Políticas de Azure** son reglas que ayudan a las organizaciones a garantizar que sus recursos cumplan con estándares específicos y requisitos de cumplimiento. Permiten **hacer cumplir o auditar configuraciones en recursos de Azure**. Por ejemplo, puedes prevenir la creación de máquinas virtuales en una región no autorizada o asegurarte de que todos los recursos tengan etiquetas específicas para su seguimiento.
|
||||
|
||||
Las Políticas de Azure son **proactivas**: pueden detener la creación o modificación de recursos no conformes. También son **reactivas**, permitiéndote encontrar y corregir recursos no conformes existentes.
|
||||
|
||||
@@ -323,12 +323,12 @@ Las Políticas de Azure son **proactivas**: pueden detener la creación o modifi
|
||||
|
||||
**Algunos ejemplos:**
|
||||
|
||||
1. **Asegurar el Cumplimiento con Regiones Específicas de Azure**: Esta política asegura que todos los recursos se desplieguen en regiones específicas de Azure. Por ejemplo, una empresa podría querer asegurar que todos sus datos se almacenen en Europa para cumplir con el GDPR.
|
||||
2. **Hacer Cumplir Estándares de Nomenclatura**: Las políticas pueden hacer cumplir convenciones de nomenclatura para los recursos de Azure. Esto ayuda a organizar e identificar fácilmente los recursos según sus nombres, lo cual es útil en entornos grandes.
|
||||
1. **Asegurar el Cumplimiento con Regiones Específicas de Azure**: Esta política asegura que todos los recursos se desplieguen en regiones específicas de Azure. Por ejemplo, una empresa podría querer asegurarse de que todos sus datos se almacenen en Europa para cumplir con el GDPR.
|
||||
2. **Hacer Cumplir Normas de Nomenclatura**: Las políticas pueden hacer cumplir convenciones de nomenclatura para los recursos de Azure. Esto ayuda a organizar e identificar fácilmente los recursos según sus nombres, lo cual es útil en entornos grandes.
|
||||
3. **Restringir Ciertos Tipos de Recursos**: Esta política puede restringir la creación de ciertos tipos de recursos. Por ejemplo, se podría establecer una política para prevenir la creación de tipos de recursos costosos, como ciertos tamaños de VM, para controlar costos.
|
||||
4. **Hacer Cumplir Políticas de Etiquetado**: Las etiquetas son pares clave-valor asociados con recursos de Azure utilizados para la gestión de recursos. Las políticas pueden hacer cumplir que ciertas etiquetas deben estar presentes, o tener valores específicos, para todos los recursos. Esto es útil para el seguimiento de costos, propiedad o categorización de recursos.
|
||||
5. **Limitar el Acceso Público a Recursos**: Las políticas pueden hacer cumplir que ciertos recursos, como cuentas de almacenamiento o bases de datos, no tengan puntos finales públicos, asegurando que solo sean accesibles dentro de la red de la organización.
|
||||
6. **Aplicar Automáticamente Configuraciones de Seguridad**: Las políticas pueden usarse para aplicar automáticamente configuraciones de seguridad a los recursos, como aplicar un grupo de seguridad de red específico a todas las VMs o asegurar que todas las cuentas de almacenamiento utilicen cifrado.
|
||||
6. **Aplicar Automáticamente Configuraciones de Seguridad**: Las políticas pueden usarse para aplicar automáticamente configuraciones de seguridad a los recursos, como aplicar un grupo de seguridad de red específico a todas las VMs o asegurarse de que todas las cuentas de almacenamiento utilicen cifrado.
|
||||
|
||||
Ten en cuenta que las Políticas de Azure pueden adjuntarse a cualquier nivel de la jerarquía de Azure, pero se utilizan **comúnmente en el grupo de gestión raíz** o en otros grupos de gestión.
|
||||
|
||||
@@ -352,7 +352,7 @@ Ejemplo de política de Azure en json:
|
||||
```
|
||||
### Herencia de Permisos
|
||||
|
||||
En Azure **los permisos pueden ser asignados a cualquier parte de la jerarquía**. Eso incluye grupos de gestión, suscripciones, grupos de recursos y recursos individuales. Los permisos son **heredados** por los **recursos** contenidos de la entidad donde fueron asignados.
|
||||
En Azure **los permisos se pueden asignar a cualquier parte de la jerarquía**. Eso incluye grupos de gestión, suscripciones, grupos de recursos y recursos individuales. Los permisos son **heredados** por los **recursos** contenidos de la entidad donde fueron asignados.
|
||||
|
||||
Esta estructura jerárquica permite una gestión eficiente y escalable de los permisos de acceso.
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Az - Tokens & Public Applications
|
||||
# Az - Tokens y Aplicaciones Públicas
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Información Básica
|
||||
|
||||
Entra ID es la plataforma de gestión de identidad y acceso (IAM) basada en la nube de Microsoft, que sirve como el sistema fundamental de autenticación y autorización para servicios como Microsoft 365 y Azure Resource Manager. Azure AD implementa el marco de autorización OAuth 2.0 y el protocolo de autenticación OpenID Connect (OIDC) para gestionar el acceso a los recursos.
|
||||
|
||||
@@ -13,7 +13,7 @@ Entra ID es la plataforma de gestión de identidad y acceso (IAM) basada en la n
|
||||
1. **Servidor de Recursos (RS):** Protege los recursos propiedad del propietario del recurso.
|
||||
2. **Propietario del Recurso (RO):** Típicamente un usuario final que posee los recursos protegidos.
|
||||
3. **Aplicación Cliente (CA):** Una aplicación que busca acceso a recursos en nombre del propietario del recurso.
|
||||
4. **Servidor de Autorización (AS):** Emite tokens de acceso a las aplicaciones cliente después de autenticar y autorizar.
|
||||
4. **Servidor de Autorización (AS):** Emite tokens de acceso a las aplicaciones cliente después de autenticarlas y autorizarlas.
|
||||
|
||||
**Ámbitos y Consentimiento:**
|
||||
|
||||
@@ -38,21 +38,21 @@ Entra ID es la plataforma de gestión de identidad y acceso (IAM) basada en la n
|
||||
- No pueden autenticarse de forma segura ante el servidor de autorización.
|
||||
- **Implicación de Seguridad:** Un atacante puede suplantar una aplicación cliente pública al solicitar tokens, ya que no hay un mecanismo para que el servidor de autorización verifique la legitimidad de la aplicación.
|
||||
|
||||
## Authentication Tokens
|
||||
## Tokens de Autenticación
|
||||
|
||||
Hay **tres tipos de tokens** utilizados en OIDC:
|
||||
|
||||
- [**Tokens de Acceso**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** El cliente presenta este token al servidor de recursos para **acceder a los recursos**. Solo se puede usar para una combinación específica de usuario, cliente y recurso y **no puede ser revocado** hasta su expiración - que es de 1 hora por defecto.
|
||||
- [**Tokens de Acceso**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** El cliente presenta este token al servidor de recursos para **acceder a los recursos**. Solo se puede usar para una combinación específica de usuario, cliente y recurso y **no puede ser revocado** hasta su expiración, que es de 1 hora por defecto.
|
||||
- **Tokens de ID**: El cliente recibe este **token del servidor de autorización**. Contiene información básica sobre el usuario. Está **vinculado a una combinación específica de usuario y cliente**.
|
||||
- **Tokens de Actualización**: Proporcionados al cliente con el token de acceso. Se utilizan para **obtener nuevos tokens de acceso e ID**. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es **90 días** para tokens de actualización inactivos y **sin expiración para tokens activos** (es posible obtener nuevos tokens de actualización a partir de un token de actualización).
|
||||
- Un token de actualización debe estar vinculado a un **`aud`**, a algunos **ámbitos**, y a un **inquilino** y solo debería poder generar tokens de acceso para ese aud, ámbitos (y no más) e inquilino. Sin embargo, este no es el caso con **tokens de aplicaciones FOCI**.
|
||||
- **Tokens de Actualización**: Proporcionados al cliente junto con el token de acceso. Se utilizan para **obtener nuevos tokens de acceso e ID**. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es de **90 días** para tokens de actualización inactivos y **sin expiración para tokens activos** (es posible obtener nuevos tokens de actualización a partir de un token de actualización).
|
||||
- Un token de actualización debe estar vinculado a un **`aud`**, a algunos **ámbitos**, y a un **inquilino** y solo debería poder generar tokens de acceso para ese aud, ámbitos (y no más) e inquilino. Sin embargo, este no es el caso con los **tokens de aplicaciones FOCI**.
|
||||
- Un token de actualización está cifrado y solo Microsoft puede descifrarlo.
|
||||
- Obtener un nuevo token de actualización no revoca el token de actualización anterior.
|
||||
|
||||
> [!WARNING]
|
||||
> La información para **acceso condicional** está **almacenada** dentro del **JWT**. Así que, si solicitas el **token desde una dirección IP permitida**, esa **IP** será **almacenada** en el token y luego puedes usar ese token desde una **IP no permitida para acceder a los recursos**.
|
||||
|
||||
### Access Tokens "aud"
|
||||
### Tokens de Acceso "aud"
|
||||
|
||||
El campo indicado en el campo "aud" es el **servidor de recursos** (la aplicación) utilizado para realizar el inicio de sesión.
|
||||
|
||||
@@ -65,36 +65,36 @@ El comando `az account get-access-token --resource-type [...]` admite los siguie
|
||||
|
||||
<summary>ejemplos de aud</summary>
|
||||
|
||||
- **aad-graph (Azure Active Directory Graph API)**: Utilizado para acceder a la API de Azure AD Graph heredada (obsoleta), que permite a las aplicaciones leer y escribir datos de directorio en Azure Active Directory (Azure AD).
|
||||
- **aad-graph (API de Azure Active Directory Graph)**: Utilizado para acceder a la API de Azure AD Graph heredada (obsoleta), que permite a las aplicaciones leer y escribir datos de directorio en Azure Active Directory (Azure AD).
|
||||
- `https://graph.windows.net/`
|
||||
|
||||
* **arm (Azure Resource Manager)**: Utilizado para gestionar recursos de Azure a través de la API de Azure Resource Manager. Esto incluye operaciones como crear, actualizar y eliminar recursos como máquinas virtuales, cuentas de almacenamiento, y más.
|
||||
- `https://management.core.windows.net/ o https://management.azure.com/`
|
||||
|
||||
- **batch (Azure Batch Services)**: Utilizado para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera eficiente en la nube.
|
||||
- **batch (Servicios de Azure Batch)**: Utilizado para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera eficiente en la nube.
|
||||
- `https://batch.core.windows.net/`
|
||||
|
||||
* **data-lake (Azure Data Lake Storage)**: Utilizado para interactuar con Azure Data Lake Storage Gen1, que es un servicio de almacenamiento y análisis de datos escalable.
|
||||
* **data-lake (Almacenamiento de Azure Data Lake)**: Utilizado para interactuar con Azure Data Lake Storage Gen1, que es un servicio de almacenamiento y análisis de datos escalable.
|
||||
- `https://datalake.azure.net/`
|
||||
|
||||
- **media (Azure Media Services)**: Utilizado para acceder a Azure Media Services, que proporciona servicios de procesamiento y entrega de medios basados en la nube para contenido de video y audio.
|
||||
- **media (Servicios de Azure Media)**: Utilizado para acceder a Azure Media Services, que proporcionan servicios de procesamiento y entrega de medios basados en la nube para contenido de video y audio.
|
||||
- `https://rest.media.azure.net`
|
||||
|
||||
* **ms-graph (Microsoft Graph API)**: Utilizado para acceder a la API de Microsoft Graph, el punto de acceso unificado para los datos de servicios de Microsoft 365. Permite acceder a datos e información de servicios como Azure AD, Office 365, Enterprise Mobility y servicios de Seguridad.
|
||||
* **ms-graph (API de Microsoft Graph)**: Utilizado para acceder a la API de Microsoft Graph, el punto de acceso unificado para los datos de servicios de Microsoft 365. Permite acceder a datos e información de servicios como Azure AD, Office 365, Enterprise Mobility y servicios de Seguridad.
|
||||
- `https://graph.microsoft.com`
|
||||
|
||||
- **oss-rdbms (Azure Open Source Relational Databases)**: Utilizado para acceder a los servicios de base de datos de Azure para motores de bases de datos relacionales de código abierto como MySQL, PostgreSQL y MariaDB.
|
||||
- **oss-rdbms (Bases de Datos Relacionales de Código Abierto de Azure)**: Utilizado para acceder a los servicios de base de datos de Azure para motores de bases de datos relacionales de código abierto como MySQL, PostgreSQL y MariaDB.
|
||||
- `https://ossrdbms-aad.database.windows.net`
|
||||
|
||||
</details>
|
||||
|
||||
### Access Tokens Scopes "scp"
|
||||
### Ámbitos de Tokens de Acceso "scp"
|
||||
|
||||
El ámbito de un token de acceso se almacena dentro de la clave scp dentro del JWT del token de acceso. Estos ámbitos definen a qué tiene acceso el token de acceso.
|
||||
|
||||
Si un JWT tiene permitido contactar una API específica pero **no tiene el ámbito** para realizar la acción solicitada, **no podrá realizar la acción** con ese JWT.
|
||||
|
||||
### Get refresh & access token example
|
||||
### Ejemplo de obtención de token de actualización y acceso
|
||||
```python
|
||||
# Code example from https://github.com/secureworks/family-of-client-ids-research
|
||||
import msal
|
||||
@@ -121,7 +121,6 @@ device_flow
|
||||
pprint(azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
|
||||
|
||||
# DECODE JWT
|
||||
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
|
||||
"""Decodes base64 encoded JWT blob"""
|
||||
@@ -149,7 +148,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
Anteriormente se mencionó que los tokens de actualización deben estar vinculados a los **alcances** con los que se generaron, a la **aplicación** y al **inquilino** para el que se generaron. Si se rompe alguno de estos límites, es posible escalar privilegios, ya que será posible generar tokens de acceso a otros recursos e inquilinos a los que el usuario tiene acceso y con más alcances de los que se pretendía originalmente.
|
||||
|
||||
Además, **esto es posible con todos los tokens de actualización** en la [plataforma de identidad de Microsoft](https://learn.microsoft.com/en-us/entra/identity-platform/) (cuentas de Microsoft Entra, cuentas personales de Microsoft y cuentas sociales como Facebook y Google) porque, como mencionan los [**documentos**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Los tokens de actualización están vinculados a una combinación de usuario y cliente, pero **no están vinculados a un recurso o inquilino**. Un cliente puede usar un token de actualización para adquirir tokens de acceso **a través de cualquier combinación de recurso e inquilino** donde tenga permiso para hacerlo. Los tokens de actualización están encriptados y solo la plataforma de identidad de Microsoft puede leerlos."
|
||||
Además, **esto es posible con todos los tokens de actualización** en la [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (cuentas de Microsoft Entra, cuentas personales de Microsoft y cuentas sociales como Facebook y Google) porque, como mencionan los [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Los tokens de actualización están vinculados a una combinación de usuario y cliente, pero **no están vinculados a un recurso o inquilino**. Un cliente puede usar un token de actualización para adquirir tokens de acceso **a través de cualquier combinación de recurso e inquilino** donde tenga permiso para hacerlo. Los tokens de actualización están encriptados y solo la Microsoft identity platform puede leerlos."
|
||||
|
||||
Además, tenga en cuenta que las aplicaciones FOCI son aplicaciones públicas, por lo que **no se necesita ningún secreto** para autenticarse en el servidor.
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
|
||||
## Registrando un dispositivo con tokens SSO
|
||||
|
||||
Sería posible para un atacante solicitar un token para el servicio de registro de dispositivos de Microsoft desde el dispositivo comprometido y registrarlo:
|
||||
Sería posible que un atacante solicitara un token para el servicio de registro de dispositivos de Microsoft desde el dispositivo comprometido y lo registrara:
|
||||
```bash
|
||||
# Initialize SSO flow
|
||||
roadrecon auth prt-init
|
||||
@@ -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>
|
||||
|
||||
@@ -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 **phishing de código de dispositivo** 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
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Enumeration Tools
|
||||
# Az - Herramientas de Enumeración
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -34,7 +34,7 @@ Instrucciones de la [**documentación**](https://learn.microsoft.com/en-us/power
|
||||
```bash
|
||||
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
||||
```
|
||||
2. Instale la última versión estable de PowerShell:
|
||||
2. Instala la última versión estable de PowerShell:
|
||||
```sh
|
||||
brew install powershell/tap/powershell
|
||||
```
|
||||
@@ -57,13 +57,13 @@ Sigue este enlace para las [**instrucciones de instalación¡**](https://learn.m
|
||||
|
||||
Los comandos en Azure CLI están estructurados utilizando un patrón de: `az <servicio> <acción> <parámetros>`
|
||||
|
||||
#### Depuración | MitM az cli
|
||||
#### Depurar | MitM az cli
|
||||
|
||||
Usando el parámetro **`--debug`** es posible ver todas las solicitudes que la herramienta **`az`** está enviando:
|
||||
```bash
|
||||
az account management-group list --output table --debug
|
||||
```
|
||||
Para hacer un **MitM** a la herramienta y **ver todas las solicitudes** que está enviando manualmente, puedes hacer:
|
||||
Para realizar un **MitM** a la herramienta y **verificar todas las solicitudes** que está enviando manualmente, puedes hacer:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Bash" }}
|
||||
|
||||
@@ -28,12 +28,12 @@ Hay diferentes formas en que una máquina puede estar conectada a la nube:
|
||||
|
||||
En Azure AD, hay diferentes tipos de tokens con limitaciones específicas:
|
||||
|
||||
- **Tokens de acceso**: Utilizados para acceder a APIs y recursos como Microsoft Graph. Están vinculados a un cliente y recurso específicos.
|
||||
- **Tokens de actualización**: Emitidos a aplicaciones para obtener nuevos tokens de acceso. Solo pueden ser utilizados por la aplicación a la que fueron emitidos o un grupo de aplicaciones.
|
||||
- **Tokens de actualización primarios (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.
|
||||
- **Claves de Windows Hello for Business (WHFB)**: Utilizadas para autenticación sin contraseña. Se utilizan para obtener Tokens de Actualización Primarios.
|
||||
- **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.
|
||||
|
||||
El tipo de token más interesante es el Token de Actualización Primario (PRT).
|
||||
El tipo de token más interesante es el Primary Refresh Token (PRT).
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
@@ -43,11 +43,11 @@ az-primary-refresh-token-prt.md
|
||||
|
||||
Desde la **máquina comprometida a la nube**:
|
||||
|
||||
- [**Pasar la Cookie**](az-pass-the-cookie.md): Robar cookies de Azure del navegador y usarlas para iniciar sesión
|
||||
- [**Volcar tokens de acceso de procesos**](az-processes-memory-access-token.md): Volcar la memoria de procesos locales sincronizados con la nube (como excel, Teams...) y encontrar tokens de acceso en texto claro.
|
||||
- [**Phishing del Token de Actualización Primario**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Phishing del PRT para abusar de él
|
||||
- [**Pasar el PRT**](pass-the-prt.md): Robar el PRT del dispositivo para acceder a Azure impersonándolo.
|
||||
- [**Pasar el Certificado**](az-pass-the-certificate.md)**:** Generar un certificado basado en el PRT para iniciar sesión de una máquina a otra
|
||||
- [**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**:
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Cuando se ejecuta, el script DeployGPO.ps1 realiza las siguientes acciones:
|
||||
|
||||
Al ejecutar este script, los administradores del sistema deben proporcionar dos parámetros principales: **ServicePrincipalId** y **ServicePrincipalClientSecret**. Además, requiere otros parámetros como el dominio, el FQDN del servidor que aloja el recurso compartido y el nombre del recurso compartido. También se deben proporcionar más detalles como el ID del inquilino, el grupo de recursos y otra información necesaria al script.
|
||||
|
||||
Se genera un secreto cifrado en el directorio AzureArcDeploy en el recurso compartido especificado utilizando cifrado DPAPI-NG. El secreto cifrado se almacena en un archivo llamado encryptedServicePrincipalSecret. La evidencia de esto se puede encontrar en el script DeployGPO.ps1, donde el cifrado se realiza llamando a ProtectBase64 con $descriptor y $ServicePrincipalSecret como entradas. El descriptor consiste en los SIDs del grupo de Computadoras de Dominio y Controladores de Dominio, asegurando que el ServicePrincipalSecret solo pueda ser descifrado por los Controladores de Dominio y los grupos de seguridad de Computadoras de Dominio, como se indica en los comentarios del script.
|
||||
Se genera un secreto cifrado en el directorio AzureArcDeploy en el recurso compartido especificado utilizando cifrado DPAPI-NG. El secreto cifrado se almacena en un archivo llamado encryptedServicePrincipalSecret. La evidencia de esto se puede encontrar en el script DeployGPO.ps1, donde el cifrado se realiza llamando a ProtectBase64 con $descriptor y $ServicePrincipalSecret como entradas. El descriptor consiste en los SIDs del grupo de Computadoras de Dominio y Controladores de Dominio, asegurando que el ServicePrincipalSecret solo pueda ser descifrado por los Controladores de Dominio y grupos de seguridad de Computadoras de Dominio, como se indica en los comentarios del script.
|
||||
```powershell
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -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.
|
||||
```powershell
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
@@ -43,7 +43,7 @@ runas /user:fake01$ /netonly powershell
|
||||
```powershell
|
||||
.\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr
|
||||
```
|
||||
Al tener el TGT de nuestra cuenta de computadora almacenado en memoria, podemos usar el siguiente script para descifrar el secreto del principal del servicio.
|
||||
Al tener el TGT para nuestra cuenta de computadora almacenado en memoria, podemos usar el siguiente script para descifrar el secreto del principal del servicio.
|
||||
```powershell
|
||||
Import-Module .\AzureArcDeployment.psm1
|
||||
|
||||
@@ -54,7 +54,7 @@ $ebs
|
||||
```
|
||||
Alternativamente, podemos usar [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG).
|
||||
|
||||
En este punto, podemos recopilar la información restante necesaria para conectarnos a Azure desde el archivo ArcInfo.json, que se almacena en el mismo recurso compartido de red que el archivo encryptedServicePrincipalSecret. Este archivo contiene detalles como: TenantId, servicePrincipalClientId, ResourceGroup, y más. Con esta información, podemos usar Azure CLI para autenticarnos como el service principal comprometido.
|
||||
En este punto, podemos recopilar la información restante necesaria para conectarnos a Azure desde el archivo ArcInfo.json, que se almacena en el mismo recurso compartido de red que el archivo encryptedServicePrincipalSecret. Este archivo contiene detalles como: TenantId, servicePrincipalClientId, ResourceGroup, y más. Con esta información, podemos usar Azure CLI para autenticar como el service principal comprometido.
|
||||
|
||||
## Referencias
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Local Cloud Credentials
|
||||
# Az - Credenciales de Nube Local
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,17 +10,17 @@ Los tokens y datos sensibles se almacenan localmente por Azure CLI, lo que plant
|
||||
|
||||
1. **Tokens de Acceso**: Almacenados en texto plano dentro de `accessTokens.json` ubicado en `C:\Users\<username>\.Azure`.
|
||||
2. **Información de Suscripción**: `azureProfile.json`, en el mismo directorio, contiene detalles de la suscripción.
|
||||
3. **Archivos de Registro**: La carpeta `ErrorRecords` dentro de `.azure` puede contener registros con credenciales expuestas, tales como:
|
||||
3. **Archivos de Registro**: La carpeta `ErrorRecords` dentro de `.azure` podría contener registros con credenciales expuestas, tales como:
|
||||
- Comandos ejecutados con credenciales incrustadas.
|
||||
- URLs accedidas utilizando tokens, que pueden revelar información sensible.
|
||||
- URLs accedidas usando tokens, que podrían revelar información sensible.
|
||||
|
||||
### Azure PowerShell
|
||||
|
||||
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 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 utilizando el comando `Save-AzContext`, que debe usarse con precaución para prevenir accesos no autorizados.
|
||||
2. **Secretos de Principal 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
|
||||
|
||||
@@ -33,7 +33,7 @@ Considerando el almacenamiento de datos sensibles en texto plano, es crucial ase
|
||||
|
||||
- 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 cuando sea posible.
|
||||
- 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.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.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 se puede usar 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 puede ser utilizada 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:
|
||||
|
||||
@@ -26,7 +26,7 @@ mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrom
|
||||
```
|
||||
Para Azure, nos importan las cookies de autenticación, incluyendo **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** y **`ESTSAUTHLIGHT`**. Estas están presentes porque el usuario ha estado activo en Azure recientemente.
|
||||
|
||||
Simplemente navega a login.microsoftonline.com y agrega la cookie **`ESTSAUTHPERSISTENT`** (generada por la opción “Mantener sesión iniciada”) o **`ESTSAUTH`**. Y estarás autenticado.
|
||||
Simplemente navega a login.microsoftonline.com y añade la cookie **`ESTSAUTHPERSISTENT`** (generada por la opción “Mantener sesión iniciada”) o **`ESTSAUTH`**. Y estarás autenticado.
|
||||
|
||||
## Referencias
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Primary Refresh Token (PRT)
|
||||
# Az - Token de Actualización Primario (PRT)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## **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ía otorgarte acceso a varios recursos de la víctima en la nube eludiendo MFA.
|
||||
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.
|
||||
|
||||
Pasos:
|
||||
|
||||
|
||||
@@ -24,9 +24,9 @@ Windows puede entonces **intercambiar este TGT parcial por un TGT completo** sol
|
||||
|
||||
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**.
|
||||
|
||||
## Abusando de la Confianza de Cloud Kerberos para obtener Administrador de Dominio <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
## Abusando de la Confianza de Kerberos en la Nube para obtener Administrador de Dominio <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
|
||||
Cuando AzureAD genera un **TGT parcial**, lo hará utilizando 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**.
|
||||
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**.
|
||||
|
||||
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.
|
||||
|
||||
@@ -39,11 +39,11 @@ El éxito del ataque y la obtención de privilegios de Administrador de Dominio
|
||||
- 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 administrador de dominio, pero no debe ser miembro de grupos típicos de administradores de AD para evitar la generación de TGTs 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 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 está prefijada 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.
|
||||
- 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.
|
||||
|
||||
### El ataque completo <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
|
||||
Consulte el post 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/)
|
||||
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}}
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Az - Default Applications
|
||||
# Az - Aplicaciones Predeterminadas
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Check the techinque in:** [**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) and [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
**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 obtener información más detallada, puede visitar la publicación original del blog.
|
||||
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}}
|
||||
|
||||
@@ -8,11 +8,11 @@ Para sincronizar un nuevo usuario **de AzureAD al AD on-prem** estos son los req
|
||||
|
||||
- El **usuario de AzureAD** necesita tener una dirección proxy (un **buzón**)
|
||||
- No se requiere licencia
|
||||
- No debe **estar ya sincronizado**
|
||||
- No **debe estar ya sincronizado**
|
||||
```powershell
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
Cuando se encuentra un usuario como estos en AzureAD, para **acceder desde el AD local** solo necesitas **crear una nueva cuenta** con el **proxyAddress** el correo electrónico SMTP.
|
||||
Cuando se encuentra un usuario como estos en AzureAD, para **acceder a él desde el AD local** solo necesitas **crear una nueva cuenta** con el **proxyAddress** el correo electrónico SMTP.
|
||||
|
||||
Automáticamente, este usuario será **sincronizado desde AzureAD al usuario del AD local**.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Federation
|
||||
# Az - Federación
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
[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.
|
||||
|
||||
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.
|
||||
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 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.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -24,10 +24,10 @@ En cualquier configuración de federación hay tres partes:
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
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.
|
||||
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.
|
||||
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 deseas aprender más sobre la autenticación SAML y ataques comunes, ve a:**
|
||||
|
||||
@@ -35,26 +35,26 @@ En cualquier configuración de federación hay tres partes:
|
||||
https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
{{#endref}}
|
||||
|
||||
## Pivoting
|
||||
## Pivotar
|
||||
|
||||
- AD FS es un modelo de identidad basado en reclamos.
|
||||
- "..los reclamos son simplemente declaraciones (por ejemplo, nombre, identidad, grupo), hechas sobre los usuarios, que se utilizan principalmente para autorizar el acceso a aplicaciones basadas en reclamos ubicadas en cualquier parte de Internet."
|
||||
- Los reclamos 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.
|
||||
- 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!
|
||||
- En ADFS, la SAML Response es firmada por un certificado de firma de token.
|
||||
- Si el certificado está 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** podría 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 ticket dorado](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/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.
|
||||
|
||||
@@ -67,9 +67,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 que un servicio de dominio comparta 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 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 **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 ticket dorado. 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 ticket dorado. 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:
|
||||
|
||||
@@ -97,7 +97,7 @@ Para adquirir la **clave privada**, es necesario acceder a la **cuenta de usuari
|
||||
# Role Name
|
||||
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
|
||||
```
|
||||
Con toda la información, es posible olvidar una SAMLResponse válida como el usuario que deseas suplantar usando [**shimit**](https://github.com/cyberark/shimit)**:**
|
||||
Con toda la información, es posible olvidar un SAMLResponse válido como el usuario que deseas suplantar usando [**shimit**](https://github.com/cyberark/shimit)**:**
|
||||
```bash
|
||||
# Apply session for AWS cli
|
||||
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
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Información Básica
|
||||
|
||||
[De la documentación:](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 la 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.
|
||||
[De la documentación:](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.
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -17,13 +17,13 @@ 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**.
|
||||
|
||||
**PHS** es requerido para características como **Protección de Identidad** y Servicios de Dominio AAD.
|
||||
**PHS** es necesario para características como **Protección de Identidad** y Servicios de Dominio AAD.
|
||||
|
||||
## Pivotando
|
||||
|
||||
Cuando PHS está configurado, algunas **cuentas privilegiadas** se crean automáticamente:
|
||||
|
||||
- La cuenta **`MSOL_<installationID>`** se crea automáticamente en el AD local. Esta cuenta recibe un rol de **Cuentas de Sincronización de Directorio** (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 AD local. Esta cuenta recibe un rol de **Cuentas de Sincronización de Directorio** (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**.
|
||||
- Se crea una cuenta **`Sync_<nombre del servidor ADConnect local>_installationID`** en Azure AD. Esta cuenta puede **restablecer la contraseña de CUALQUIER usuario** (sincronizado o solo en la nube) en Azure AD.
|
||||
|
||||
Las contraseñas de las dos cuentas privilegiadas anteriores se **almacenan en un servidor SQL** en el servidor donde **Azure AD Connect está instalado.** Los administradores pueden extraer las contraseñas de esos usuarios privilegiados en texto claro.\
|
||||
@@ -33,7 +33,7 @@ Es posible extraer la configuración de una de las tablas, siendo una de ellas e
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
La **configuración encriptada** está encriptada con **DPAPI** y contiene las **contraseñas del usuario `MSOL_*`** en el AD local y la contraseña de **Sync\_\*** en AzureAD. Por lo tanto, comprometer estas es posible para elevar privilegios en el AD y en AzureAD.
|
||||
La **configuración encriptada** está encriptada con **DPAPI** y contiene las **contraseñas del usuario `MSOL_*`** en AD local y la contraseña de **Sync\_\*** en AzureAD. Por lo tanto, comprometer estas es posible para elevar privilegios en el AD y en AzureAD.
|
||||
|
||||
Puedes encontrar una [visión general completa de cómo se almacenan y desencriptan estas credenciales en esta charla](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
@@ -47,7 +47,7 @@ Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAc
|
||||
#Azure AD module
|
||||
Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
|
||||
```
|
||||
### Abusing MSOL\_*
|
||||
### Abusando de MSOL\_*
|
||||
```powershell
|
||||
# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
|
||||
Get-AADIntSyncCredentials
|
||||
@@ -61,7 +61,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
|
||||
### Abusando de Sync\_\*
|
||||
|
||||
Comprometendo la cuenta **`Sync_*`** es posible **restablecer la contraseña** de cualquier usuario (incluidos los Administradores Globales)
|
||||
Comprometiendo la cuenta **`Sync_*`** es posible **restablecer la contraseña** de cualquier usuario (incluidos los Administradores Globales)
|
||||
```powershell
|
||||
# This command, run previously, will give us alse the creds of this account
|
||||
Get-AADIntSyncCredentials
|
||||
@@ -96,9 +96,9 @@ También es posible volcar la contraseña de este usuario.
|
||||
> [!CAUTION]
|
||||
> Otra opción sería **asignar permisos privilegiados a un principal de servicio**, que el usuario **Sync** tiene **permisos** para hacer, y luego **acceder a ese principal de servicio** como una forma de privesc.
|
||||
|
||||
### SSO Sin Costuras
|
||||
### Seamless SSO
|
||||
|
||||
Es posible usar SSO Sin Costuras con PHS, que es vulnerable a otros abusos. Revísalo en:
|
||||
Es posible usar Seamless SSO con PHS, que es vulnerable a otros abusos. Revísalo en:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
|
||||
@@ -12,7 +12,7 @@ az-primary-refresh-token-prt.md
|
||||
```
|
||||
Dsregcmd.exe /status
|
||||
```
|
||||
En la sección del Estado SSO, deberías ver el **`AzureAdPrt`** configurado en **SÍ**.
|
||||
En la sección del estado SSO, deberías ver el **`AzureAdPrt`** configurado en **SÍ**.
|
||||
|
||||
<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -34,11 +34,11 @@ La cookie PRT se llama en realidad **`x-ms-RefreshTokenCredential`** y es un JSO
|
||||
"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 principal 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`.
|
||||
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 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 utiliza 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).
|
||||
|
||||
@@ -48,10 +48,10 @@ Por lo tanto, incluso si el PRT no puede ser extraído porque está ubicado dent
|
||||
|
||||
## 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 del **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 **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 del **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 utiliza 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.
|
||||
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
|
||||
|
||||
@@ -80,7 +80,7 @@ O usando [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
```powershell
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
Entonces puedes usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obtener un nuevo PRT (ejecuta la herramienta desde un proceso del usuario a atacar):
|
||||
Luego puedes usar [**roadtoken**](https://github.com/dirkjanm/ROADtoken) para obtener un nuevo PRT (ejecuta la herramienta desde un proceso del usuario a atacar):
|
||||
```powershell
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
@@ -146,21 +146,21 @@ 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 pasar por el proceso nuevamente. Si no lo hace, deberías estar bien.
|
||||
> 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, 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. 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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) y para entender su aplicación, consulta [Ataque Pass-the-cookie](az-pass-the-cookie.md).
|
||||
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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 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 en profundidad 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/)
|
||||
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.
|
||||
@@ -180,14 +180,14 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
<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.
|
||||
Extrae también la clave de sesión (el **`KeyValue`** del campo **`ProofOfPossesionKey`**) que puedes ver resaltada a continuación. Esto está encriptado y necesitaremos usar nuestras claves maestras de DPAPI para desencriptarlo.
|
||||
|
||||
<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 descifrarlo**. Puedes usar los siguientes comandos para hacerlo:
|
||||
Para **desencriptar** 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 desencriptarlo**. Puedes usar los siguientes comandos para hacerlo:
|
||||
```
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
|
||||
@@ -220,7 +220,7 @@ 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.
|
||||
> 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 desaparece, deberías estar bien.
|
||||
|
||||
#### Opción 2 - roadrecon usando PRT
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Permissions for a Pentest
|
||||
# Az - Permisos para un Pentest
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user